wtorek, 8 lipca 2014

Entity Relationship Model w Enterprise Architect

Rdzeniem programu Enterprise Architect był od początku UML. Jednakże program ten nadaje się świetnie do modelowania przy użyciu wielu innych notacji, wśród nich jest również Entity Relationship Model. Zamiast tego pojęcia stosuje się również nierzadko Entity Relationship Diagram (ERD) zwany po polsku diagramem związków encji. Notacja ERD straciła wiele na znaczeniu w ciągu ostatnich lat, a nawet dziesięcioleci i ustąpiła pola na rzecz diagramów klas UML. ERD służy do modelowania strukturalnego, zaś UML do obiektowego. Zatem strukturalny język modelowania w wielu zastosowaniach został zastąpiony przez język obiektowy.
Nic w tym dziwnego, skoro niegdyś w inżynierii oprogramowania królowały języki strukturalne, a obecnie języki obiektowe. Modelowanie, które jest w swojej istocie powiązane z programowaniem zatem idzie w parze z tymi przemianami.



Czy to znaczy, że nie ma już miejsca na zastosowanie ERD?

Diagramy związków encji służą do analizowania i opisania struktur danych na poziomie koncepcyjnym. Mimo, że logika systemów i aplikacji bywa często modelowana zgodnie z paradygmatem programowania obiektowego, to dane przetwarzane przez systemy są przechowywane w relacyjnych bazach danych. A relacyjne bazy danych w swej naturze są strukturalne.
Zatem ERD może być nadal stosowane do graficznej reprezentacji logicznej struktury bazy danych.
Zanim jednak zdecydujemy się na zastosowanie ERD, warto mieć na uwadze, że nie powinno się bezkrytycznie stosować różnych notacji na jednym diagramie. W związku z tym, jeśli chcielibyśmy modelować logikę działania systemu przy użyciu UML, wówczas logiczny model danych warto zamodelować również w UML.

Jak wyglądają diagramy ERD?

O ile konwencja diagramów klas UML jest ściśle określona i diagramy stworzone w różnych narzędziach są czytelne dla każdego, to w przypadku ERD istnieje wiele różnych konwencji. Każda z tych konwencji stosuje różne symbole graficzne do pokazania związków między encjami. Zdecydowanie jest to jedna z wad tej notacji.
Lista konwencji ERD:
  • Chen notation - Stworzona przez Petera Chena w 1976 roku. Kluczowe wyróżniki tej konwencji to relacje prezentowane w postaci rombów oraz atrybuty encji jako owale.
  • Crow's foot - konwencja, która jest stosowana najczęściej i wspierana przez największą liczbę narzędzi. Encje są wyrażane jako prostokąty, relacje jako linie pomiędzy nimi. Określony zestaw kształtów na końcach tych linii wyraża krotności.
  • Bachman notation - prekursor diagramów związków encji. Relacje są reprezentowane w postaci strzałek.
  • Barker's notation - stworzona przez Richarda Barkera, Iana Palmera i Harry'ego Ellisa. Jest zbliżona do Crow's foot. Opcjonalność powiązań jest na przykład przedstawiona jako przerywana linia.
  • EXPRESS - został sformalizowany jako standard ISO-10303-11. Wspiera typy danych, enumeracje, dziedziczenie, agregacje. Z grubsza pozwala uzyskać podobny zakres informacyjny, co UML.
  • IDEF1X - Integrated DEFinition for Information Modeling. Dość rozbudowany język modelowania oparty o swój własny metamodel oraz o proces modelowania składający się z pięciu faz (inicjacja, definiowanie encji, definiowanie powiązań, kluczowe definicje, definiowanie atrybutów).
  • Martin notation - Do modelowania związków encji wykorzystuje kilka relacji (and/or branch, top to bottom, side to top, side to side). Krotności są wyrażane podobnie, jak w przypadku UML: 1, *, 1...*, 0...1. Ponadto umożliwia również modelowanie zdarzeń (event) oraz aktywności (activity).
  • (min, max)-notation - autorstwa Jean-Raymond Abrial. Zaproponował on przede wszystkim metodę określania krotności jako minimalną i maksymalną. Na przykład "(0,1)" to w UML "0..1", a "(1,N)" to w UML "1..*".
  • Merise - stosowana głównie we Francji. Encje są wyrażane tradycyjnie - jako prostokąt, atrybuty podobnie jak w UML, związki między encjami - asocjacje są opatrzone nazwami w owalach.
Trudno się nie pogubić w takim gąszczu różnych standardów, które powstawały bądź to równolegle, bądź jako rozwinięcie czy modyfikacje innych. Najbardziej znane z nich to: Chen notation oraz Crow's foot.

Dostępne konwencje ERD w EA

Jeśli chcielibyśmy w EA utworzyć nowy diagram ERD, wówczas prędzej czy później trafimy do okna, które pozwala na wybór typu diagramu.
W wersjach EA: Corporate, Business and Software Engineering, Systems Engineering oraz Ultimate znaleźć można MDG o nazwie Entity Relationship Diagrams. To MDG zawiera tylko jeden typ diagramu o nazwie Entity Relationship. Nie oznacza to jednak, że tylko jeden typ diagramów ERD jest wspierany przez EA.

Chen notation

Wyżej przedstawiona droga utworzenia diagramu ERD poprzez MDG Entity Relationship Diagrams umożliwia skorzystanie z Chen notation
Poniższy diagram to przykład takiego diagramu pokazujący dwie encje powiązane ze sobą relacją "jeden do wielu" wraz z pokazaniem dwóch atrybutów jednej z encji.
Przykład diagramu ERD w konwencji Chen notation

Można odnieść wrażenie, że na tym kończą się możliwości EA w zakresie diagramów typu ERD.
Okazuje się, że nie jest to prawdą...

Crow's foot

W celu stworzenia diagramu ERD w tej konwencji należy utworzyć po prostu diagram... klas UML!
Po stworzeniu takiego diagramu wystarczy w dowolnym momencie zmienić jedną z jego właściwości, aby przestał to być diagram UML, a stał się diagramem ERD.
Aby przedstawić model danych przy użyciu konwencji Crow's foot należy otworzyć okno właściwości diagramu (prawy przycisk myszy na pustym miejscu diagramu, a następnie wybieramy z menu kontekstowego Properties). Na zakładce Connectors z listy rozwijalnej Connector Notation należy zamiast UML 2.1 wybrać Information Engineering.
Po takiej operacji aktualna i przyszła zawartość diagramu zostaje "przekonwertowana" na Crow's foot. Przykładowy diagram ERD przedstawiający taki sam zakres informacyjny, co dla wcześniej omawianej konwencji wygląda następująco:
Przykład diagramu ERD w konwencji Crow's foot

IDEF1X

Aby uzyskać diagram w konwencji IDEF1X wystarczy analogicznie, jak powyżej zmienić Connector Notation dla diagramu, z tym że tym razem na IDEF1X
Przykładowy diagram ERD w tej konwencji wygląda następująco:
Przykład diagramu ERD w konwencji IDEF1X
Możliwości stosowania IDEF1X są jednak znacząco ograniczone i nie obejmują swoim zakresem wszystkich typów elementów i relacji zdefiniowanych w metamodelu IDEF1X.

Podsumowanie

ERD służy do modelowania struktur danych i związków między nimi na poziomie koncepcyjnym. Z poziomu koncepcyjnego projektant baz danych może uzyskać fizyczny model dla relacyjnej bazy danych.
Sparx Systems Enterprise Architect wspiera trzy konwencje modelowania związków encji (ERD). Są to:
  • Chen notation,
  • Crow's foot,
  • IDEF1X.
Niestety metody dojścia do uzyskania efektów w każdej z tych konwencji nie są spójne i intuicyjne.
Jednakże dzięki takiemu podejściu producenta EA okazuje się, że możemy tworzyć diagramy ERD nie znając w ogóle notacji ERD. Wystarczy istniejący diagram UML jednym ruchem "przekonwertować" na ERD w konwencji Crow's foot lub IDEF1X.

1 komentarz:

  1. Piotr,
    zrobiłeś kawal dobrej roboty na tym Blogu. Szkoda że zawiesiłeś pisanie i że nie ma tu dużej ilości komentarzy, ale moim zdaniem jest to wina złego podchodzenia przez społeczeństwo do pojęcia projektowania systemów informatycznych. Bardzo duża liczba programistów, w szczególności Freelancerów, nie stosuje UML`a w swoich projektach i tak naprawdę nie wiem, jak dają sobie radę z modelowaniem danych w głowie na bieżąco! Przecież tak się nie da. Zawsze potrzebna jest gruntowna analiza i przynajmniej 4-5 diagramów aby system był tak dobry jak się tego oczekuje.

    OdpowiedzUsuń