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 |
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). |
Panel | |
---|---|
Na tej stronie:
|
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 typuString
. - „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 sprawyTestRole
orazTestUser
to sprawy zależne w stosunku doTestMrcObject
, aTestMrcObject
to sprawa nadrzędna w stosunku doTestRole
orazTestUser
.
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.
Warning |
---|
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’. |
Info |
---|
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), podtypMap
(wszystkie „obiekty złożone” nierozpoznane jako „sprawy” – nie posiadające pola „mrcCaseHeader”, są traktowane jako typLOB
) - definicja o nazwie „indexedMap” jako obiekt typu
LOB
(Large Object), podtypIndexedMap
(wszystkie „obiekty złożone” nierozpoznane jako „sprawy” – nie posiadające pola „mrcCaseHeader”, są traktowane jako typLOB
) - 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:
- Wersja typu sprawy o nazwie TestRole posiadać będzie:
- definicja o nazwie „name” na pozycji 1
- definicja o nazwie „priv” na pozycji 2
- definicja o nazwie „users” na pozycji 3
- Wersja typu sprawy o nazwie TestUser posiadać będzie:
- definicja o nazwie „id” na pozycji 1
- definicja o nazwie „userName” na pozycji 2
- definicja o nazwie „fullName” na pozycji 3
- definicja o nazwie „isActive” na pozycji 4
- definicja o nazwie „isTechnical” na pozycji 5
- definicja o nazwie „locale” na pozycji 6
- definicja o nazwie „timeZone” na pozycji 7
- Wersja typu sprawy o nazwie TestMrcObject posiadać będzie:
- definicja o nazwie „role” na pozycji 1
- definicja o nazwie „user” na pozycji 2
- definicja o nazwie „listStr” na pozycji 3
- definicja o nazwie „listInt” na pozycji 4
- definicja o nazwie „listDec” na pozycji 5
- definicja o nazwie „map” na pozycji 6
- definicja o nazwie „indexedMap” na pozycji 7
- definicja o nazwie „listMap” na pozycji 8
- 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.
Powiązane strony
Content by Label