Data Dictionary w EA

Data Dictionary to jedna z technik dokumentowania danych przetwarzanych przez system. Załóżmy, że mamy do czynienia z istniejącą aplikacją, która przechowuje dane w dużej relacyjnej bazie danych. Aby lepiej poznać struktury, w których dane są przechowywane warto zapoznać się ze schematem bazy danych. Taki schemat można zaimportować do programu Enterprise Architect.

Zaimplementowana w EA funkcjonalność importu schematu bazy danych (Import DB schema from ODBC) powoduje utworzenie klas ze stereotypem <<table>> wraz z ich atrybutami. Dodatkowo możliwe jest automatyczne umieszczenie takich tabel na diagramie klas. Dzięki temu możemy się posiłkować wizualizacją samych tabel i powiązań między nimi.

Poniższy diagram prezentuje przykład prostego schematu bazy danych opracowany dla aplikacji służącej do rejestrowania i raportowania wydatków pracowniczych.

Taki diagram wygląda dość czytelnie, ale pod warunkiem, że tabel jest niewiele. W przypadku większych struktur diagram może stać się nieczytelny, a samo rozmieszczenie zawartości diagramu może okazać się czasochłonne.

Jako alternatywę można stosować technikę Data Dictionary. Technika ta służy do opisu standardowych definicji elementów danych, ich znaczeń i możliwych wartości w formie tabelarycznej. Taka forma ze swej natury nie jest jednak stworzona do wizualizacji powiązań między tabelami. Data Dictionary zawiera definicje wszystkich atrybutów i wskazuje, w jaki sposób one składają się na większe struktury, czyli tabele.

Jak zatem wyglądałby Data Dictionary dla zmieszczonego powyżej przykładu?

Jest to tabela uzyskana jako wynika odpowiedniego zapytania. Taki widok pozostawia jeszcze trochę do czynienia. Na szczęście można przeciągnąć nagłówek kolumny o nazwie Table_Name na pole oznaczone tekstem Drag a column header here to group by that column.
Po tej operacji uzyskamy następujący efekt.

Data Dictionary może być przydatny dla projektantów, analityków, testerów aby upewnić się, czy wszystkie zainteresowane strony zgadzają się co do formatu i zawartości informacji przetwarzanych przez system. Dla zespołów wsparcia i administratorów może być przydatne w rozwiązywaniu problemów z działaniem systemu. Zebranie takich definicji w repozytorium EA może sprawić, że taka informacja będzie dostępna dla wszystkich zainteresowanych w jednym miejscu.

Metoda uzyskania widoku typu Data Dictionary nie została zaimplementowana w łatwy sposób w narzędziu. Sparx Systems zawarł jedynie krótką wzmiankę na ten temat w dokumencie "Data Modeling. From Conceptual Model to DBMS". Zamieszczono tam treść zapytania SQL, które po zapisaniu w programie pozwala wygenerować odpowiedni widok.
Data Dictionary (EAP):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
iif(t_attribute.IsOrdered, "PK", "") as PrimaryKey,
iif(t_attribute.IsCollection, "FK", "") as ForeignKey ,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
iif(t_attribute.IsStatic, "Unique", "") as isUnique,
iif(t_attribute.AllowDuplicates, "NotNull","") as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Niestety składnia SQL jest wrażliwa na silnik bazodanowy wykorzystywany jako repozytorium dla projektów Enterprise Architect. Powyższe zapytanie działać będzie tylko w przypadku plików EAP. Jeśli zamiast pliku lokalnego korzystamy z repozytorium w postaci bazy danych, wówczas konieczne jest przebudowanie tego zapytania.
Poniżej to samo zapytanie (z jednym wyjątkiem - dodatkowo zwracane są opisy atrybutów, czyli zawartość pola Notes) przygotowane dla repozytoriów EA pod kontrolą MySQL.
Data Dictionary (MySQL):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
t_attribute.Notes,
CASE WHEN t_attribute.IsOrdered THEN "PK" ELSE "" END as PrimaryKey,
CASE WHEN t_attribute.IsCollection THEN "FK" ELSE "" END as ForeignKey,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
CASE WHEN t_attribute.IsStatic THEN "Unique" ELSE "" END as isUnique,
CASE WHEN t_attribute.AllowDuplicates THEN "NotNull" ELSE "" END as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Na koniec warto dodać, że gdybyśmy w jednym repozytorium EA przechowywali schematy kilku baz danych, wówczas wszystkie tabele mogłyby się ze sobą wymieszać. Aby temu zapobiec można w ostatniej linii dopisać dodatkowy warunek ograniczający zakres zwracanych tabel tylko do gałęzi pakietów wybranej w oknie Project Browser.
Ostatnia linia wyglądałaby wówczas następująco:
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table" and t_object.Package_ID In(#Branch#)

Data type - typy własne

Tworząc model klas w języku UML mamy możliwość określenia typów atrybutów. W artykule Typy danych atrybutów opisałem, jakie są możliwe do wyboru primitive types w zależności od wybranego języka programowania.
W wielu przypadkach typy proste nie są wystarczające. Kod aplikacji z reguły będzie zawierać typy złożone, charakterystyczne dla danego rozwiązania.

Data type - typy danych atrybutów

Aby rozpocząć opracowanie dowolnego typu diagramu klas (class diagram) w języku UML wystarczy w programie Enterprise Architect dodać nowy diagram typu class. Jednak, gdy dochodzimy do momentu, kiedy należy stworzone klasy wzbogacić o atrybuty może się okazać, że lista dostępnych typów danych nie do końca odpowiada naszym oczekiwaniom.

Domyślnie, po instalacji EA, każda nowo zakładana klasa ma przypisany od razu język programowania: Java. 

Gdy dla takiej klasy wyświetlimy listę dostępnych typów atrybutów, to możemy znaleźć:

• boolean,
• byte,
• char,
• double,
• float,
• int,
• long,
• short. 

W każdym przypadku można również wybrać <none> lub wybrać typ spośród innych klas w modelu (w szczególności Datatype lub enumeration).

Dociekliwy użytkownik może zajrzeć do specyfikacji UML, aby upewnić się, skąd wynikają takie, a nie inne możliwe wartości. 

A w specyfikacji UML możemy wyczytać, że istnieje coś takiego, jak primitive type. W pewnym uproszczeniu jest to typ danych reprezentujący atomowe wartości, na przykład wartości, które nie posiadają żadnych części składowych lub struktury. Mogą one precyzować semantykę lub operacje zdefiniowane poza UML (np. w matematyce). Język UML sam zawiera następujące primitive type:

• Boolean,
• Integer,
• UnlimitedNatural,
• String.

Już na pierwszy rzut oka widać, że ta lista jest zgoła odmienna od tej, którą widzimy w EA. Czy EA nie jest zgodny z UML?

Nieporozumienie wynika z domyślnego języka Java przypisanego do klasy. 

Zmieńmy zatem język klasy z Java na <none> (żaden).

I zobaczmy, jakie są dostępne typy atrybutów:

Wartości na liście zmieniły się. Teraz są zgodne ze specyfikacją UML.

Okazuje się, że zanim przystąpimy do modelowania danych, warto czasem odpowiednio skonfigurować narzędzie. Bowiem, gdy w modelu istnieje już wiele klas i stwierdzimy, że trzeba zmienić ich język, a co za tym idzie - typy atrybutów, może to kosztować nieco pracy.

Istnieją w tej kwestii dwie szkoły: pierwsza z nich - purystyczna - optuje za tym, aby model domeny (zwany również modelem dziedziny) był niezależny od platformy programistycznej (PIM - Platform-Independent Model). Druga szkoła - pragmatyczna - stoi na stanowisku, że model domeny powinien być opracowany w taki sposób, aby zautomatyzować jego ewentualne przekształcenie w model specyficzny dla określonej platformy programistycznej (PSM - Platform-Specific Model). 

Jeśli chcemy tworzyć w oderwaniu od Javy, można zmienić domyślny język dla generowania kodu w ustawieniach EA.  Menu: Tools --> Options, zakładka Source Code Engineering.

Wybór wartości <none> z listy rozwijalnej sprawi, że wszystkie dodawane klasy nie będą miały przypisanego żadnego języka.

A jeśli ktoś jest ciekawy, gdzie są zdefiniowane typy danych dla poszczególnych języków, to można otworzyć okno Code Datatypes dostępne z menu Settings.

Z poziomu tego okna można również dodać definicję innego języka (Add Product) oraz modyfikować dostępne typy danych. Własne definicje można dystrybuować poprzez mechanizm Export/Import Reference Data.