Sprawa vs. obiekt

Info

Mercury DB® jest również nazywany „bazą spraw”. Spróbujmy sobie teraz wyjaśnić czym jest pojęcie „sprawy” w interpretacji systemu. Sprawa to dowolny obiekt opisany przez typ i jego parametry. Długo się zastanawiałem w jaki sposób nazwać podstawową jednostkę definiującą taki obiekt. Słowo Object zarezerwowane jest przez wiele języków programowania stąd też pojawiło się pojęcie Case (sprawa), które w tym przypadku staje się jego synonimem. Pojęcie Case, ma również swoje odniesienie do pojęć biznesowych, które sobą reprezentuje w szeregu zastosowań praktycznych. Sprawa to reprezentacja obiektu umowy, kontrahenta, komputera, samochodu i nieskończonej liczby rzeczy, które nas otaczają, a chcielibyśmy je ewidencjonować w postaci elektronicznej. W dokumencie pojawia się wiele pojęć takie jak „obiekt złożony”, „sprawa zależna”, „sprawa nadrzędna”, „typ”, „parametry typu”, które mogą być różnie interpretowane. W dalszej części postaramy się wyjaśnić na podstawie konkretnego przykładu co te pojęcia oznaczają z punktu widzenia systemu Mercury DB®. Odniesiemy się do przykładu definicji obiektu danych w systemie IBM BPM, w którym posługujemy się pojęciem „Business Object” (BO, obiekt biznesowy).

Obiekt prosty i obiekt złożony

Definicja przykładowego obiektu biznesowego TestMrcObject

Obiekt, w interpretacji systemu Mercury DB (HgDB) 3.0 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 (przy okazji, obiekt ten jest „obiektem prostym”, zawiera tylko pola proste: name typu String, priv typu String oraz pole users, które jest listą prostych 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:

Definicja przykładowego obiektu biznesowego TestMrcObject

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 (HgDB) 3.0 jako samodzielny byt.
• Obiekt TestUser stał się sprawą prostą i może istnieć w systemie Mercury DB (HgDB) 3.0 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.

Ograniczenia nazewnictwa pól

Istnieją ograniczenia związane z stosowanym nazewnictwem pól obiektu np. pole w reprezentowanym przez sprawę obiekcie (prostym lub złożonym) nie może nazywać się mrcCaseHeader.

Ograniczenia liczby pól

W chwili obecnej, w obiekcie (prostym lub złożonym) reprezentowanym przez sprawę może być maksymalnie 128 pól.

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 vdefinicja 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 (HgDB) 3.0 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.