Obiekt prosty i obiekt złożony

Obiekt, w interpretacji systemu Mercury DB® to zbiór pól o określonej nazwie i określonym typie. Możemy wyróżnić dwa rodzaje obiektów:

• „Obiekt prosty” to zbiór pól, których definicje oparte są o typy proste takie jak: String, Integer, Number, Decimal, Date itp. lub listy, których elementy oparte o typy proste jak np., lista elementów typu String.
• „Obiekt złożony”, to zbiór pól, pośród których definicją typu są inne „obiekty proste” lub „obiekty złożone”

W podanym przykładzie obiekt TestMrcObject jest „obiektem złożonym” ponieważ pole o nazwie „role” jest typu TestRole (który jest „obiektem prostym”, zawiera pola „name” typu String, pole „priv” typu String oraz pole „users”, które jest listą elementów typu String). Analogicznie jest z polem „user”, którego typ to inny „obiekt prosty” o nazwie TestUser.

Sprawa prosta i sprawa złożona

Każdy system musi posiadać umiejętność jednoznacznej identyfikacji danych. W odniesieniu do relacyjnych baz danych sposobem na jednoznaczną identyfikację wiersza jest definiowanie klucza głównego. W systemie Mercury DB rolę takiego klucza głównego pełni pole o nazwie „mrcCaseHeader” (nazwa ta jest stała i niezmienna) o typie MrcCaseHeader (opis obiektu znajdziemy w dalszej części tego dokumentu). Zatem aby przekształcić „obiekt prosty” lub „obiekt złożony” w sprawę należy dodać pole o wspomnianej nazwie do ich definicji:

Wyróżniamy następujące rodzaje spraw:

• „sprawa prosta” – sprawa powstała w oparciu o „obiekt prosty”, czyli jest zbiorem pól, których typy to typy proste takie jak: String, Integer, Number, Decimal, Date itp. lub listy, których elementy oparte o typy proste jak np., lista elementów typu String oraz posiada pole „mrcCaseHeader” typu MrcCaseHeader.
• „sprawa złożona” – sprawa powstała w oparciu o „obiekt złożony”, czyli w zbiorze pól są pola, których definicją typu są inne „sprawy proste” lub „sprawy złożone” oraz posiada pole mrcCaseHeader typu MrcCaseHeader.. „Sprawy proste” i „sprawy złożone” będące definicją pola innej sprawy złożonej nazywać też będziemy „sprawami zależnymi”, a samą sprawę złożoną, w stosunku do jej składowych nazywać będziemy „sprawą nadrzędną”. Podsumujmy:
  • „sprawa zależna” = sprawa prosta lub złożona będąca składnikiem innej sprawy złożonej w stosunku do tej sprawy
  • „sprawa nadrzędna” = sprawa złożona w stosunku do swoich składowych.

W przedstawionym przykładzie:

• Obiekt TestRole stał się sprawą prostą i może istnieć w systemie Mercury DB jako samodzielny byt.
• Obiekt TestUser stał się sprawą prostą i może istnieć w systemie Mercury DB jako samodzielny byt.
• Obiekt TestMrcObject stał się sprawą złożoną i jednocześnie sprawy TestRole oraz TestUser to sprawy zależne w stosunku do TestMrcObject, a TestMrcObject to sprawa nadrzędna w stosunku do TestRole oraz TestUser.

Warto podkreślić, że o ile definicja sprawy złożonej TestMrcObject nie może istnieć bez definicji TestRole oraz TestUser o tyle TestRole oraz TestUser mogą stanowić osobne i niezależne byty.

Typ sprawy, parametry sprawy

Musimy doprecyzować terminy pojęć „typu”, „parametru” i ich interpretację przez system Mercury DB. Pomimo, że ich nazwy wydają się intuicyjne trzeba tej kwestii poświęcić chwilę.

Wyróżniamy następujące pojęcia związane z określeniem typu sprawy:

• Kod typu, nazwa grupująca różne wersje typów, jest reprezentowany przez obiekt encji TypeCode (opisany dalszej części)
• Wersja typu, jest reprezentowana przez obiekt encji TypeCase (opisany dalszej części). Wersja posiada swoją nazwę, która najczęściej jest taka sama jak „kod typu” przez co jest popełniany błąd mylenia kodu z wersją i odwrotnie. Bardzo często „Kod typu” oraz „Wersja typu” jest określana jednym znaczeniem „typ sprawy” co niestety, niejednokrotnie, może prowadzić do nieporozumień.
• Parametr typu, który jest reprezentowany przez obiekt encji TypeParam (opisany dalszej części). Jest to powiązanie pomiędzy definicją parametru a wersją typu. Każdy parametr typu ma zdefiniowaną, z góry określoną pozycję występowania w danej wersji typu. Zmiana definicji lub pozycji implikuje utworzenie nowej wersji typu.
• Definicja parametru, to powiązanie pomiędzy nazwą pola a jego typem. Jest ona reprezentowana przez obiekt encji ParamDefinition (opisany dalszej części)

Tak jak wcześniej wspomniano „Kod typu” to po prostu nazwa grupująca różne wersje typów. Jako obiekt encji jest on wykorzystywany do tworzenia powiązań pomiędzy typami spraw i innymi encjami występującymi w systemie (z wyjątkiem encji reprezentującej sprawę, która jest bezpośrednio powiązana z określoną wersją typu).

Wróćmy do naszego przykładu i rozbijmy go na czynniki pierwsze w kontekście interpretacji analizowanych pojęć. Przypomnijmy, zdefiniowaliśmy sprawę o nazwie TestMrcObject:

W tym przypadku „kod typu” przyjmie następujące wartości:

• Dla sprawy prostej TestRole: wartość „TestRole”
• Dla sprawy prostej TestUser: wartość „TestUser”
• Dla sprawy złożonej TestMrcObject: wartość „TestMrcObject”

Po zapisie sprawy do systemu Mercury powstaną następujące wersje typów:

• Dla sprawy prostej TestRole: wersja typu o nazwie „TestRole”
• Dla sprawy prostej TestUser: wersja typu o nazwie „TestUser”
• Dla sprawy złożonej TestMrcObject: wersja typu o nazwie „TestMrcObject”

Każda z powstałych wersji zawierać będzie listę parametrów, które są uporządkowanym zbiorem „definicji parametrów” na określonych pozycjach. W naszym przypadku powstaną następujące definicje parametrów:

• definicja o nazwie „name”, o typie prostym String
• definicja o nazwie „priv”, o typie prostym String
• definicja o nazwie „users”, jako lista elementów typie prostym String
• definicja o nazwie „id”, o typie prostym Integer
• definicja o nazwie „userName”, o typie prostym String
• definicja o nazwie „fullName”, o typie prostym String
• definicja o nazwie „isActive”, o typie prostym Integer
• definicja o nazwie „isTechnical”, o typie prostym Integer
• definicja o nazwie „locale”, o typie prostym String
• definicja o nazwie „timeZone”, o typie prostym String
• definicja o nazwie „listStr”, jako lista elementów o typie prostym String
• definicja o nazwie „listInt”, jako lista elementów o typie prostym Integer
• definicja o nazwie „listDec”, jako lista elementów o typie prostym Decimal
• definicja o nazwie „map”, jako obiekt typu LOB (Large Object), podtyp Map (wszystkie „obiekty złożone” nierozpoznane jako „sprawy” – nie posiadające pola „mrcCaseHeader”, są traktowane jako typ LOB)
• definicja o nazwie „indexedMap” jako obiekt typu LOB (Large Object), podtyp IndexedMap (wszystkie „obiekty złożone” nierozpoznane jako „sprawy” – nie posiadające pola „mrcCaseHeader”, są traktowane jako typ LOB)
• definicja o nazwie „listMap” jako obiekt typu LOB
• definicja o nazwie „listDates” jako lista elementów typie prostym Date
• definicja o nazwie „role”, której typem jest „sprawa zależna”, wersja typu o kodzie „TestRole”
• definicja o nazwie „user”, której typem jest „sprawa zależna”, wersja typu o kodzie „TestUser”

A zatem poszczególne wersje typów będą miały następujące parametry:

1. Wersja typu sprawy o nazwie TestRole posiadać będzie:
   1. definicja o nazwie „name” na pozycji 1
   2. definicja o nazwie „priv” na pozycji 2
   3. definicja o nazwie „users” na pozycji 3
2. Wersja typu sprawy o nazwie TestUser posiadać będzie:
   1. definicja o nazwie „id” na pozycji 1
   2. definicja o nazwie „userName” na pozycji 2
   3. definicja o nazwie „fullName” na pozycji 3
   4. definicja o nazwie „isActive” na pozycji 4
   5. definicja o nazwie „isTechnical” na pozycji 5
   6. definicja o nazwie „locale” na pozycji 6
   7. definicja o nazwie „timeZone” na pozycji 7
3. Wersja typu sprawy o nazwie TestMrcObject posiadać będzie:
   1. definicja o nazwie „role” na pozycji 1
   2. definicja o nazwie „user” na pozycji 2
   3. definicja o nazwie „listStr” na pozycji 3
   4. definicja o nazwie „listInt” na pozycji 4
   5. definicja o nazwie „listDec” na pozycji 5
   6. definicja o nazwie „map” na pozycji 6
   7. definicja o nazwie „indexedMap” na pozycji 7
   8. definicja o nazwie „listMap” na pozycji 8
   9. definicja o nazwie „listDates” na pozycji 9

Podsumowując: przykład miał za zadanie pokazać w jaki sposób poszczególne składowe obiektu są interpretowane przez system Mercury DB® i jakie są różnice w pojmowaniu pewnych terminów związanych z obiektowością. Jak pokaże dalsza lektura definicje encji TypeCode, TypeCase, TypeParam oraz ParamDefinition nie są takie proste jak to teraz przedstawiono, a to dlatego że stanowią one również wsparcie dla innych funkcjonalności systemu, między innymi mechanizmów generacji formularzy do edycji danych spraw.

Dla podstawowej funkcjonalności systemu Mercury jaką jest przechowywanie danych o dowolnych sprawach przedstawione przekształcenie obiektu do postaci sprawy jest całkowicie wystarczające.