Struktura dokumentu indeksu

Dokument indeksu Lucene w systemie Mercury DB oparty jest o dane składowane w relacyjnej bazie danych.

Poniższy diagram prezentuje poszczególne składowe dokumentu.

Przechowywanie dokumentu w indeksie

Architektura przechowywanych danych w relacyjnej bazie danych sprawia, że jednemu dokumentowi indeksu Lucene odpowiada jeden wpis (wiersz) w tabeli reprezentującej encję Case. Charakter obiektowości przechowywanych danych wprowadza konieczność budowania powiazań pomiędzy zaindeksowanymi dokumentami. Aby dokładniej to wyjaśnić przeanalizujmy poniższy przypadek obiektu sprawy złożonej:

{
	"mrcCaseHeader": {
		"typeCode": "EliClient",
		"dirty": false,
		"pkPropertyName": "clientID"
	},
	"clientID": "22377",
	"clientName": "Dobry Klient",
	"clientLogo": "n/a",
	"clientAddress": {
		"mrcCaseHeader": {
			"typeCode": "EliAddress",
			"dirty": false,
			"pkPropertyName": "correlationId"
		},
		"correlationId": "22377",
		"county": "pleszewski",
		"community": "Pleszew",
		"city": "Brzezie",
		"street": "ul. Zawidowicka",
		"buildingNumber": "5",
		"status": "W budowie",
		"isContract": "false",
		"coordinationMeetingPlanedDate": "17-10-2018",
		"orders": [],
		"source": null
	}
}

Mamy sprawę nadrzędną (EliClient, rodzic) oraz sprawę podrzędną (EliAddress, dziecko). Ich dane przechowywane są jako oddzielne wiersze w tabeli. Powiązanie, które pomiędzy nimi istnieje (pole clientAddress w sprawie nadrzędnej), w relacyjnej bazie zapisane jest jako wiersz encji Case2SubCase. Aby odzwierciedlić to powiązanie w zaindeksowanych dokumentach, silnik indeksowania HgDB dodaje odpowiednie pola zarówno do dokumentu sprawy nadrzędnej jak i podrzędnej.

Do dokumentu sprawy nadrzędnej dodane zostanie pole o nazwie utworzonej wg reguły: <nazwa_pola>_<nawa_pola_z_id_sprawy>, czyli w naszym przypadku, używając nazewnictwa modelu 3.0, clientAddress_mrc_Case_id z wartością odpowiadającą identyfikatorowi sprawy podrzędnej. To pozwoli silnikowi HgDB zrealizowanie odpowiedniego zapytania wiążącego, wyszukanie sprawy podrzędnej o odpowiednim identyfikatorze.

Do dokumentu sprawy podrzędnej dodane zostaną dwa pola wielowartościowe:

• parentFields  - pole z nazwą pola wiążącego, do którego z w naszym przypadku zostanie dodana wartość "clientAddress"
• parentTypes  - pole z nazwą typu sprawy nadrzędnej, do którego z w naszym przypadku zostanie dodana wartość "EliClient"

To pozwoli silnikowi HgDB na zbudowanie odpowiedniego zapytania pozwalającego na znalezienie sprawy nadrzędnej. 

Zasady budowania nazw pól

W dokumencie indeksu Lucene możemy wyróżnić dwa główne rodzaje pól: pola stałe/predefiniowane i pola dynamiczne. Dla każdego rodzaju zostały stworzone inne zasady tworzenia nazewnictwa pól indeksu Lucene.

Pola stałe/predefiniowane spraw

Pola stałe/predefiniowane to pola pochodzące z encji (pola reprezentują kolumny relacji w bazie danych).

Poniżej przedstawiono zasady nazewnictwa pól ze względu na ich przydział do kategorii:

1. TypeCode - pola reprezentujące dane dotyczące definicji kodu typu sprawy albo typu dokumentu powiązanego ze sprawą. W zależności od wykorzystywanego modelu nazewnictwa w systemie do podstawowych nazw pól encji dodawany jest prefiks:
   1. dla typów obiektów spraw to typeTypeCode dla modelu 2.0 oraz typeCode dla modelu 3.0. Przykład nazwy pola dla modelu 3.0: "mrc_typeCodeValue".
   2. dla typów obiektów dokumentów to c2docTypeTypeCode dla modelu 2.0 oraz c2docTypeCode dla modelu 3.0.
2. TypeKind - pola reprezentujące dane dotyczące rodzaju typu sprawy albo powiązanego ze sprawą dokumentu. W zależności od wykorzystywanego modelu nazewnictwa w systemie do podstawowych nazw pól encji dodawany jest prefiks:
   1. dla rodzajów spraw to typeTypeKind dla modelu 2.0 oraz typeKind dla modelu 3.0. Przykład nazwy pola dla modelu 3.0: "mrc_typeKindValue".
   2. dla rodzajów dokumentów to c2docTypeTypeKind dla modelu 2.0 oraz c2docTypeKind dla modelu 3.0.
3. TypeCase - pola reprezentujące dane dotyczące definicji typu (wersję typu) sprawy lub powiązanego ze sprawą dokumentu. W zależności od wykorzystywanego modelu nazewnictwa w systemie do podstawowych nazw pól encji dodawany jest prefiks:
   1. dla typów obiektów spraw to type. Przykład nazw pól dla modelu 3.0: "mrc_typeRootVersionContextID", "mrc_typeTypeName".
   2. dla typów obiektów dokumentów to c2docType.
4. Source - pola reprezentujące źródło pochodzenia sprawy albo powiązanego ze sprawą dokumentu. Do podstawowych nazw pól encji dodawany jest prefiks
   
   1. dla obiektów spraw to grSrc. 
   2. dla obiektów dokumentów to c2docSrc. Przykład nazwy pola dla modelu 3.0: "mrc_c2docSrcName".
5. KtmNumber - pola reprezentujące dane powiązanego ze sprawą symbolu indeksu KTM (zobacz Kod Towarowo-Materiałowy). Prefiks nazwy pola to grKtm. Przykład nazwy pola dla modelu 3.0: "mrc_grKtmDescription".
6. GroupCase - pola reprezentujące dane grupy spraw. Prefiks nazwy pola to gr.
7. Participant - pola reprezentujące dane partycypantów sprawy (dane uczestników sprawy, klientów, których dotyczy sprawa). Prefiksy nazw pól: grParticipant, Groclin, grApplicant. Są to pola wielowartościowe. Przykład nazwy pola dla modelu 3.0: "mrc_grClientIdentity".
8. Case - pola reprezentujące pola predefiniowane dotyczące sprawy, nazywane również "polami nagłówka sprawy" - zobacz opis CaseHeader. Do nazw pól nie jest dodawany żaden dodatkowy prefiks. Przykład nazwy pola status dla modelu 3.0: "mrc_status".
9. QuickTask - pola reprezentujące "szybkie zadania" (Quick Tasks) powiązane z sprawą. Prefiks nazwy pola to qt. Przykład nazwy pola dla modelu 3.0: "mrc_qtReplyText".
10. Comment - pola reprezentujące komentarze powiązane z sprawą. Prefiks nazwy pola to comm. Przykład nazwy pola dla modelu 3.0: "mrc_commContent".
11. CaseDocument - pola reprezentujące dokumenty powiązane z sprawą. Prefiks nazwy pola to c2doc. Przykład nazwy pola dla modelu 3.0: "mrc_c2docSubject".
12. InitStatus - - pola reprezentujące inicjalny status dokumentu powiązanego z sprawą. Prefiks nazwy pola to c2docInitStat. Przykład nazwy pola dla modelu 3.0: "mrc_c2docInitStatName".

Pola dynamiczne - pola obiektów

Pola dynamiczne, to pola, których nazwy oraz ich definicje przechowywane są jako metadane w bazie danych. 

Mamy trzy rodzaje pól dynamicznych dla których zdefiniowano inne zasady tworzenia ich nazewnictwa:

1. Pola podstawowe - pola reprezentujące pola proste obiektu sprawy. Nazwy pól są takie jak je zdefiniowano w obiekcie.

2. Pola skonfliktowane - pola reprezentujące pola proste obiektu sprawy, których nazewnictwo jest w konflikcie z nazewnictwem pól stałych/predefiniowanych. W zależności od wykorzystywanego modelu nazewnictwa pól, mamy następujące zasady tworzenia nazwy pola:

   Dla modelu 2.0 nazewnictwa, z powodu braku prefiksu mrc_ w nazwach pól stałych, problem konfliktów nazw pól występował bardzo często. Dla modelu 3.0, dzięki prefiksowi mrc_, wystąpienie konfliktów w nazewnictwie pól zostało zminimalizowane do minimum. Nie używaj nazw pól, które występują w zbiorze pól stałych/predefiniowanych.

   1. dla modelu 2.0 do nazwy pola dodawany jest prefiks custom_. Przykład: pole obiektu o nazwie "status" przyjmie nazwę "custom_status".
   2. dla modelu 3.0 do nazwy pola dodawany jest sufiks _custom. Przykład: pole obiektu o nazwie "mrc_status" przyjmie nazwę "mrc_status_custom".
3. Klucze obce  - Case2SubCase - pola wskazujące na powiązania pomiędzy sprawami głównymi (nadrzędnymi) i zależnymi (podrzędnymi). Takie pola budowane są według następującej reguły:
   1. dla modelu 2.0: <nazwa_pola>_luceneDocId. Przykład: "address_luceneDocId".
   2. dla modelu 3.0: <nazwa_pola>_mrc_Case_id. Przykład: "address_mrc_Case_id".

Pola stałe nieskategoryzowane

Są to pola, które są wykorzystywane przez mechanizmy wewnętrzne bazy HgDB, lecz można je również wykorzystać do wyszukiwania spraw w indeksie Lucene.

Lista pól:

1. Pole parentFields  - pole typu łańcucha znakowego (String), dodawane do dokumentu sprawy podrzędnej, wielowartościowe, zawiera nazwy pól spraw nadrzędnych, z którymi jest ona powiązana. Pole wspiera budowanie powiązań pomiędzy indeksowanymi dokumentami - powiązań pomiędzy sprawami głównymi (nadrzędnymi) i zależnymi (podrzędnymi). Przykład wartości pola: "address". 
   1. dla modelu 2.0 nazwa pola jest taka jak jest (as is).
   2. dla modelu 3.0 do nazwy pola dodawany jest prefiks mrc_ czyli przyjmie nazwę "mrc_parentFields".
2. Pole parentTypes  - pole typu łańcucha znakowego (String), dodawane do dokumentu sprawy podrzędnej, wielowartościowe, zawiera nazwy typów spraw nadrzędnych, z którymi jest ona powiązana. Pole wspiera budowanie powiązań pomiędzy indeksowanymi dokumentami - powiązań pomiędzy sprawami głównymi (nadrzędnymi) i zależnymi (podrzędnymi). Przykład wartości pola: "FsmService".

Typy pól indeksu Lucene

Jako, że typ pola ma wpływ na wykorzystywany przez indeks mechanizm wyszukiwania, alternatywnym pojęciem dla typu pola jest pojęcie "typu wyszukiwania".

Podstawowe typy pól (typy wyszukiwania):

• TextField - pole typu tekstowego, wyszukiwanie pełno tekstowe, bez rozróżniania wielkich i małych liter.
• StringField - pole typu prostego łańcucha znakowego, jedno wyrażenie, słowo. Najczęściej przeznaczone do definiowania wartości typu kod, akronim lub identyfikator.  Wyszukiwanie z rozróżnianiem małych i wielkich liter.
• LongField - pole liczbowe, liczba całkowita, długa. Wyszukiwanie liczb, zakresy liczb.
• DateField - pole daty. Podczas indeksowania wartość pola z datą przekształcana jest do wartości liczby milisekund, do typu "LongField". Pozwala na budowanie zakresu wyszukiwania.
• IntField - pole liczbowe, liczba całkowita. "krótka".
• FloatField - pole liczbowe, zmiennoprzecinkowe.
• DoubleField - pole liczbowe, zmiennoprzecinkowe.
• CompositeIdField - pole reprezentujące wartości kluczy złożonych encji. Wartość takiego pola przekształcana jest do typu "StringField". Przykład: encja CaseDocument ma pole "id" klucza złożonego typu CaseDocumentPK. Wartość takiego pola indeksowana jest w postaci:
  "{\"caseId\":\"" + getCaseId() + "\", \"objectId\":\"" + objectId + "\", \"versionSeriesId\":\"" + versionSeriesId + "\"}" 
• SubQuery - pola złożone, do których przypisana jest sprawa podrzędna. Aby wykorzystać to pole w wyszukiwaniu należy jego nazwę użyć jako prefiks odseparowany znakiem kropki, np. "address.mrc_Case_id". 

Nazwy pól stałych/predefiniowanych

Stałe pola pochodzące z encji reprezentujących dane przechowywane w relacyjnej bazie danych.

Comment

Nazwy pól indeksu Lucene reprezentujące encję Comment.

TypeCode

Nazwy pól indeksu Lucene reprezentujące encję TypeCode. Możemy wyróżnić typy dokumentów i typy spraw. W celu ułatwienia wyszukiwania dokumentów do nazw pół je reprezentujących dodano składową c2doc (wiersze z nazwami pól typów dokumentów zostały wyróżnione innym kolorem).

TypeCase

Nazwy pól indeksu Lucene reprezentujące encję TypeCase. Encja zawiera pole "isDocument" informujące o tym czy dany typ sprawy jest typem reprezentującym metadane dokumentu czy obiektu sprawy. W celu ułatwienia wyszukiwania dokumentów do nazw typów je reprezentujących dodano składową c2doc (wiersze z nazwami pól typów dokumentów zostały wyróżnione innym kolorem).

QuickTask

Nazwy pól indeksu Lucene reprezentujące encję QuickTask.

TypeKind

Nazwy pól indeksu Lucene reprezentujące encję TypeKind. Możemy wyróżnić typy dokumentów i typy spraw. W celu ułatwienia wyszukiwania dokumentów do nazw pół je reprezentujących dodano składową c2doc (wiersze z nazwami pól typów dokumentów zostały wyróżnione innym kolorem).

GroupCase

Nazwy pól indeksu Lucene reprezentujące encję GroupCase.

Source

Nazwy pól indeksu Lucene reprezentujące encję Source. Możemy wyróznić typy dokumentów i typy spraw. W celu ułatwienia wyszukiwania dokumentów do nazw pół je reprezentujących dodano składową c2doc (wiersze z nazwami pól typów dokumentów zostały wyróżnione innym kolorem).

Case

Nazwy pól indeksu Lucene reprezentujące encję Case.

CaseDocument

Nazwy pól indeksu Lucene reprezentujące encję CaseDocument.

Participant

Nazwy pól indeksu Lucene reprezentujące encję Participant. Encja ta zawiera pole "kind", którego wartość reprezentuje rodzaj powiązanego ze sprawą petenta. Aby uzyskać relację pomiędzy poszczególnymi elementami składającymi się na opis dodano odpowieni element składowy w nazwie pola indeksu Lucene.

KtmNumber

Nazwy pól indeksu Lucene reprezentujące encję KtmNumber.

InitStatus

Nazwy pól indeksu Lucene reprezentujące encję InitStatus.

Case2SubCase

Nazwy pól indeksu Lucene reprezentujące encję Case2SubCase.

Predefiniowane typy złożone pól

Jest możliwość zdefiniowania pola typu "COMPLEX" ze wskazaniem implementacji klasy, która reprezentowała takie pole. Obecnie Mercury 3.0 (Hgdb) ma wbudowaną obsługę dwóch klas.

CaseClient

Nazwy pól indeksu Lucene reprezentujące klasę pro.ibpm.mercury.values.beans.CaseClient.

CaseApplicant

Nazwy pól indeksu Lucene reprezentujące klasę pro.ibpm.mercury.values.beans.CaseApplicant.