Często pomijanym aspektem podczas zajęć z baz danych jest projektowanie. Studenci cenią sobie wiedzę praktyczną i starają się zapoznać z aplikacjami służącymi do wykonywania baz danych lub całych systemów informatycznych, ale nie są zainteresowani teorią, której znajomość jest niezbędna do wykonania nowej bazy danych (stąd później liczne próby przechowania danych niemal tak jak w Excelu). Żeby uzupełnić nieco tę lukę, przedstawię tu w dużym uproszczeniu jeden ze sposobów wykonania nowej bazy danych: diagram związków encji.

Jak już wiadomo (z wykładów z poprzedniego semestru) baza danych jest modelem pewnego fragmentu otaczającego nas świata. rzeczywistego (najczęściej rzeczywistego, gdyż możemy opisywać światy wirtualne, a nawet urojone - o ile odbiorca systemu jest skłonny zapłacić za taką pracę). Ów fragment nazywany jest obszarem analizy i podczas tych zajęć interesuje nas uproszczony model sprzedaży artykułów spożywczych. Można ów model przekształcić na diagram związków encji i na jego podstawie przeanalizować, czy baza danych będzie poprawnie odzwierciedlać zdarzenia zachodzące w świecie rzeczywistym (i to zanim baza zostanie wykonana, co zmniejsza koszty produkcji oprogramowania).

Zanim powstanie diagram, należy poznać obszar analizy. W tym celu przeprowadza się wywiady z odbiorcami bazy danych, z ekspertami, analizuje się przepisy prawne itp. Mając na uwadze ograniczenia czasowe w prowadzeniu zajęć ograniczmy się tylko do krótkiego opisu:

"Klient może kupić wiele towarów. Może też zamówić sobie dostawę do domu, ale wtedy musi podać swój dokładny adres oraz imię i nazwisko i najlepiej numer telefonu. W takim wypadku płaci przy odbiorze towaru, a gdy kupuje w sklepie - płaci przy wyjściu. Każdy klient jest obsłużony przez jakiegoś pracownika - kasjera lub dostawcę."

Spróbujmy wyodrębnić z tego krótkiego opisu (zaznaczone podkreśleniem) istotne obiekty funkcjonujące w świecie rzeczywistym. W tym celu osoby początkujące mogą posłużyć się diagramem Venna (zaawansowani potrafią z tego opisu stworzyć diagram związków encji). Diagram Venna to rysunek obiektów świata rzeczywistego. Nie musi to byś wierny rysunek - wystarczą jakieś symbole.

Zauważmy, że w podanym opisie pojawiają się (przynajmniej) następujące obiekty: klienci, pracownicy, zamówienia (gdzie mozna zapisać także zakupy) i towary. Można wyróżnić w tym modelu więcej obiektów, ale utrudniłoby to jego zarówno przedstawienie jak i zrozumienie. Obiekty odrysowujemy na diagramie Venna i obiekty tej samej klasy grupujemy w zbiory (tu 4 zbiory: klientów, pracowników, zamówień i towarów). Pomiędzy poszczególnymi obiektami rysujemy linie, które symbolizują zależności tych obiektów zachodzące w świecie rzeczywistym.

Poprawne odrysowanie diagramu Venna jest bardzo istotne dla dalszego etapu projektowania - wykonania diagramu związków encji, ponieważ wpływa na związki encji. Przyjrzyjmy się dokładnie powyższemu rysunkowi. Jak widać po przykładzie klienta "Robert Miakowski": jeden klient może złożyć wiele zamówień (oczywiście może też złożyć jedno zamówienie). Czy poprawną sytuacją w świecie rzeczywistym jest znajomość klienta, który nie składał żadnego zamówienia? Z pozoru wydaje się, że to błędna sytuacja: kto podawałby swoje dane osobowe, a nic nie zamawiał (na diagramie taką osobą jest "Mariusz Białek")? Jednak okazuje się, że taka sytuacja może mieć miejsce, gdy firma zakupi dane osobowe potencjalnych klientów (np.: osób mieszkających w okolicy). Analizujmy dalej związki między klientami, a zamówieniami, ale tym razem od strony zamówień. Okazuje się, że dane zamówienie jest składane przez najwyżej jednego klienta i że mogą być zamówienia takie, że klient jest nieznany. Podobne zależności występują pomiędzy pracownikami, a zamówieniami: dany pracownik może obsługiwać wiele zamówień, ale dane zamówienie MUSI być obsłużone przez jednego pracownika. Ciekawe zależności występują pomiędzy towarami, a zamówieniami. Okazuje się, że KAŻDE zamówienie dotyczy przynajmniej jednego towaru, ale może też dotyczyć wielu towarów (np.: "zamówienie 301"), a z kolei towar może być zamawiany wielokrotnie w różnych zamówieniach (np.: "pizza"), ale też może istnieć towar, który nie był nigdy zamawiany (np.: dopiero się pojawił w sprzedaży lub jest zbyt drogi, aby był kupiony - tu: "truskawki w cieście" i "papryka zielona").

Jeżeli dobrze zastanowiliśmy się nad zależnościami w diagramie Venna, to możemy przekształcić go na diagram związków encji. Podczas tej konwersji zbiory obiektów przekształcamy na encje, a zależności pomiędzy obiektami na związki encji:

Przyjmuje się, że nazwa encji jest rzeczownikiem w licznie pojedynczej (nie jest to jednak obowiązkowe), a tabeli w liczbie mnogiej. Z tego powodu na powyższym diagramie w prostokątach symbolizujących encje pojawiły się nazwy: "klient", "pracownik", "zamówienie", "towar". Zauważmy też, że pomiędzy encjami pojawiły się specjalnie oznakowane kreski, które symbolizują związki encji. Sposobów na ich oznakowanie jest kilka i niewiele się od siebie różnią. Tu użyte jest oznakowanie wg notacji Martin-McClure'a, czyli: "okrąg" oznacza słowo "może", "kreska" - musi, a "wronie pazury" na zakończeniu symbolu - "do wielu". Czytając te związki widzimy, że:

• "Jeden klient może złożyć wiele zamówień"
• "Każde zamówienie może być złożone przez maksymalnie jednego klienta"
• "Każdy pracownik może obsłużyć wiele zamówień"
• "Każde zamówienie musi być obsłużone przez jednego pracownika"
• "Każde z zamówień dotyczy przynajmniej jednego towaru"
• "Każdy towar może być składnikiem wielu zamówień".

Nie istnieje taki RDBMS, który obsługuje związki wiele do wielu, a taki właśnie związek zachodzi pomiędzy towarem, a zamówieniem. Związki te muszą zostać usunięte z diagramu w wyniku zastąpienia ich dwoma związkami jeden do wielu i encją przejściową (tzn. istnieją odpowiednie narzędzia do projektowania, które zrobią to automatycznie, ale nadają one niezrozumiałe nazwy tworzonym encjom przejściowym i potrafią też robić błędy).

W tym wypadku zostanie dodana encja "szczegół zamówienia". I dwa związki jeden do wielu, które należy czytać:

• "Każde zamówienie musi posiadać przynajmniej jeden szczegół zamówienia"
• "Każdy szczegół zamówienia musi być składnikiem jednego zamówienia"
• "Każdy szczegół zamówienia musi dotyczyć jednego towaru"
• "Każdy towar może należeć do wielu szczegółów zamówienia".

Po wykonaniu diagramu (już bez związków wiele do wielu) określamy jeszcze jakie atrybuty powinna posiadać każda z encji (czyli określamy cechy obiektów ze świata rzeczywistego). Dodatkowo określmy, czy podanie wartości do danego atrybutu jest wymagane (NOT NULL), czy nie (NULL). Ponadto ważną sprawą jest opisanie znaczenia zarówno encji jak i ich atrybutów. Te opisy to fragment tzw. metadanych (dane o danych), a bez nich wybieranie informacji z bazy jest mocno utrudnione (w wypadku dużych, złożonych systemów - niemożliwe, ponieważ nie wiemy jakie informacje wybieramy).

Tak określone encje i ich atrybuty to odpowiedniki tabel i ich kolumn. Związki encji, to odpowiedniki kluczy obcych. Przed przekształceniem diagramu związków encji w układ tabel wybieramy SZBD, w którym będzie wykonana nowa baza danych i określamy typ danych dla każdej kolumny. Służą do tego celu specjalne aplikacje (zaliczające się do narzędzi CASE), gdyż każdy z SZBD obsługuje nieco inne typy danych. Jeżeli chodzi o metadane, to tylko niektóre z SZBD posiadają możliwość zapamiętania dodatkowych opisów tabel i kolumn (np.: poleceniem COMMENT ON w przypadku Oracle, czy właściwością Opis tabeli lub Opis pola w przypadku Accessa).