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#)
