UML: PROJEKTOWANIE I MODELOWANIE BAZ DANYCH, MODELE I DIAGRAMY

          Każdy stosunkowo duży system należy odpowiednio zaprojektować, wymodelować oraz opracować.
Implementowana baza danych nie będzie raczej istniała sama dla siebie, tylko będzie tworzyła cały system, więc będzie składnikiem oprogramowania, aplikacji. Dlatego ważne jest, aby przedstawić całą koncepcję, a nie tylko jej część.
W niniejszym wpisie zostaną omówione wszystkie te kwestie z perspektywy całego systemu, a nie samej bazy danych.
 

1. UML (Unified Modeling Language)

 
          Jest to ujednolicony język modelowania – łączy w sobie powszechne akceptowane pojęcia pochodzące z wielu metod i metodologii podejścia obiektowego. Ma zastosowanie w dowolnej dziedzinie i jest niezależny od języka i platformy. Stąd też architekci oprogramowania mogą modelować aplikacje dowolnego typu, stroić dowolny system operacyjny, język programowania lub sieć. Narzędzia takie jak Rational Rose są obecnie często używane do tworzenia diagramów UML, ponieważ umożliwiają one twórcom oprogramowania opracowywanie zrozumiałych modeli służących do specyfikowania, wizualizacji, konstruowania i dokumentowania komponentów systemów programistycznych.
 

Język UML definiuje dziewięć rodzajów diagramów podzielonych na dwie kategorie:

1). Diagramy strukturalne:

     ● diagramy klas;
     ● diagramy obiektów;
     ● diagramy komponentów;
     ● diagramy wdrożenia;

2). Diagramy behawioralne:

     ● diagramy przypadków użycia;
     ● diagramy sekwencji;
     ● diagramy kolaboracji;
     ● diagramy stanów;
     ● diagramy aktywności.
 
 

2. OBJECT ORIENTED MODEL (OOM)

 
          OOM (Object Oriented Model) – model zorientowany obiektowo – to graficzne przedstawienie w formie diagramu obiektów, klas oraz atrybutów. Diagram klas jest wykresem UML, który zawiera klasy i interfejsy wraz z ich relacjami, co dostarcza logicznego widoku wszystkiego, albo części systemu oprogramowania.
Tworzymy go w celu uproszczenia współdziałania przedmiotów w systemie, który modelujemy. Jeżeli chodzi o klasy i relacje między tymi klasami to wyrażają one statyczną strukturę systemu. Klasa opisuje komplet przedmiotów i związków.

3. PHYSICAL DATA MODEL (PDM)

 
          PDM (Physical Data Model) – fizyczny model danych – prezentuje graficznie, za pomocą diagramu wszystkie element składające się na bazę danych, a więc: encje, pola, klucze, relacje, indeksy, widoki, procedury i wyzwalacze. Owy model współpracuje z wieloma rodzajami systemów zarządzania bazą danych, jednak ja skupiam się na MsSQL.
Ten model jest na tyle elastycznym rozwiązaniem, że nie ma większego problemu z jego utworzeniem. Mamy możliwość utworzenia go oczywiście od podstaw, ale ciekawszym, jak i o wiele bardziej przydatnym rozwiązaniem jest przekształcenie utworzonego wcześniej konceptualnego modelu danych (CDM – Conceptual Data Model) właśnie na fizyczny model danych (PDM) jak i mamy możliwość wykreować go na podstawie istniejącej już bazy danych, czy choćby z samego skryptu SQL.

          Wcześniej wspomniane oprogramowanie Sybase PowerDesigner umożliwia przekształcenie diagramu klas UML do fizycznego modelu danych.
Podczas transformacji jest dostępny raport zwracający uwagi i błędy, więc tworzone modele i diagramy są ujednolicone, spójne dając gwarancję ich poprawności.
Mało tego, program umożliwia generowanie różnego kodu SQL, w tym kompatybilnego z MsSQL Server, więc w rezultacie otrzymujemy gotowy skrypt do „odpalenia” na „F5”.
 
 

4. OPIS MODELU KONCEPTUALNEGO

 
WSTĘPNY OPIS ŚRODOWISKA FUNKCJONOWANIA SYSTEMU:

Opis środowiska funkcjonowania systemu będącego aplikacją bazodanową dla wypożyczalni płyt DVD:
● „Aplikacja bazodanowa dla wypożyczalni płyt DVD” będzie to system stworzony specjalnie na potrzeby wypożyczalni płyt DVD. Będzie służył do gromadzenia wszelkich danych dotyczących filmów (produkcja filmowa, gatunki filmowe, role artystów w filmach, recenzje filmów, widoki graficzne okładek, dostępność filmów oraz ich cenę) oraz klientów (imię, nazwisko, pesel, telefon, dokładne miejsce zamieszkania, e-mail oraz dokładną datę i czas wpisu do bazy).
● Poza oczywistymi funkcjami, czyli wypożyczaniem i oddawaniem filmów, aplikacja będzie umożliwiała przeglądanie bazy filmów i klientów według wszystkich możliwych kryteriów.
● System będzie przedstawiał statystyki filmowe wg tytułu, produkcji i gatunku na podstawie wypożyczania filmów oraz statystyki klientów wypożyczających najwięcej i najmniej filmów.
 

SZCZEGÓŁOWE OPISANIE FUNKCJONOWANIA SYSTEMU:

Aplikacja bazodanowa dla wypożyczalni płyt DVD będzie systemem zarządzającym filmami i będzie przechowywała informacje o:
● filmach, które będą aktualnie na stanie lub wypożyczone przez konkretnych klientów
● klientach, którzy mają (lub nie mają w danej chwili) wypożyczony film lub filmy.
 

SZCZEGÓŁOWE OKREŚLENIE FUNKCJI SYSTEMU:

Przewidziane funkcje, jakie ma spełniać aplikacja bazodanowa dla wypożyczalni płyt DVD są następujące:
● Magazynowanie filmów:
W bazie będą znajdowały się filmy różnego gatunku oraz różnych producentów wraz z wieloma rolami granymi przez wielu artystów.
● Magazynowanie klientów:
W bazie będą znajdowali się klienci, którzy mogą mieć wypożyczonych kilka filmów jednocześnie bądź wcale. Każdy klient w bazie zawiera potrzebne do prawidłowego działania aplikacji dane osobowe oraz dane na temat zamieszkania.
● Wypożyczanie filmów:
Każdy klient zapisany w bazie będzie mógł wypożyczyć film (lub filmy), który jest dostępny.
● Oddawanie filmów:
Każdy klient, który wypożyczył film (lub filmy) będzie musiał ten film (lub filmy) oddać.
● Magazynowanie filmów wypożyczonych:
W bazie będą znajdowały się filmy wypożyczone przez klientów. Każdy wypożyczony film będzie zawierał informacje o kliencie, który go wypożyczył oraz daty wypożyczenia filmu i jego oddania oraz należność, jaką klient będzie zobowiązany uregulować.
● Blokowanie wypożyczenia filmów, których nie ma na stanie:
System będzie anulował każdą próbę wypożyczenia filmu, którego aktualnie nie będzie na stanie.
● Wyszukiwanie filmów oraz klientów wg różnych kryteriów:
Klientów oraz filmy będzie można wyszukiwać w bazie według wszystkich możliwych kryteriów.
● Ststystyki:
System będzie umożliwiał przeglądanie statystyk:
     → Filmów – według tych, które są najczęściej oraz najmniej (lub w ogóle) wypożyczane, według produkcji oraz gatunku.
     → Klientów – którzy wypożyczają najwięcej oraz najmniej filmów.
 

UWARUNKOWANIA PRAWNE DZIAŁALNOŚCI:

Biorąc pod uwagę uwarunkowania prawne działalności, system będzie zapewniał:
● Bezpieczeństwo i ochronę danych osobowych:
Jednym z ważniejszych aspektów prawnych będzie zapewnienie w systemie „Aplikacji bazodanowej dla wypożyczalni płyt DVD” bezpieczeństwa danych osobowych zawartych w bazie danych.
● Wgląd użytkowników do własnych danych osobowych:
Zgodnie z ustawą o ochronie danych osobowych, osoby, których dane osobowe są zawarte w bazie danych, będą miały prawo do wglądu swoich danych osobowych.
● Możliwość zmiany danych osobowych wyłącznie przez upoważnione osoby:
Zgodnie z ustawą o ochronie danych osobowych, osoby, których dane osobowe są zawarte w bazie danych, mają prawo do korekty swoich danych osobowych, których może dokonać tylko osoba obsługująca aplikację.
● Wykorzystywanie danych osobowych:
Zebrane dane osobowe są wykorzystywane wyłącznie do prawidłowej pracy systemu bazodanowego i nie będą rozpowszechniane na zewnątrz innym instytucjom prywatnym i państwowym.
 
 

5. WYSZCZEGÓLNIENIE WYMAGAŃ APLIKACJI

          Podczas projektowania i wdrażania systemu informatycznego jednym z najistotniejszych aspektów jest szczegółowa specyfikacja wymagań funkcjonalnych oraz niefunkcjonalnych, jakie ma spełniać. W odniesieniu do aplikacji bazodanowej na potrzeby wypożyczalni płyt DVD będą to:
● Wymagania mające na celu utrzymanie danych w spójności, gdyż nie będzie można dopuścić do wystąpienia żadnych anomalii w bazie danych.
● Czas dostępu do danych, który będzie musiał być jak najkrótszy, jednak wyższy priorytet ma tutaj spójność danych.
● Przenośność aplikacji, czyli możliwość jej działania na różnych systemach operacyjnych jak i urządzeniach elektronicznych.
● Sposób zachowania programu w sytuacjach krytycznych oraz w przypadkach wystąpień różnych błędów czy awarii (zarówno programowych jak i sprzętowych – technicznych).
● Możliwość uzyskania przez użytkownika aplikacji wsparcia technicznego.
 
 

6. OPRACOWANIE MODELU KONCEPTUALNEGO

 
PROJEKT STRUKTUR DANYCH I SCHEMATU BAZY DANYCH:
 

Model relacyjny danych:

Relacyjny model danych składa się z trzech podstawowych elementów:
● Relacyjnych struktur danych.
● Operatorów relacyjnych umożliwiających tworzenie, przeszukiwanie i modyfikację informacji zawartych w bazie danych.
● Więzów integralności określających wartości danych.
 

Schemat relacyjnej bazy danych:

Schemat bazy danych określa zbiór pojęć używanych do opisywania własności konkretnego wycinka świata rzeczywistego, istotnych z punktu widzenia danego zastosowania. Baza danych to model logicznie spójny, służący określonemu celowi. W związku z powyższym baza danych nie powinna przyjąć takiego stanu, który nie jest nigdy osiągalny w modelowanej rzeczywistości.

Określenie rodzaju gromadzonych danych:

Poniższa tabela przedstawia typy danych występujące w relacyjnej bazie danych utworzonych za pomocą języka SQL w środowisku MsSQL Server, które zostaną w określony sposób użyte w systemie.
 

Oto lista typów danych występujących w bazie wraz z określeniem ich użycia:
● INT – krotki kolumn identyfikujących wszystkie relacje w bazie danych.
● TINYINT – wartości w kolumnie określającej dostępność filmów.
● SMALLMONEY – opisujący cenę każdego filmu.
● DATETIME – automatycznie wykorzystywany w chwili wpisywania nowych klientów do bazy, wykonywania transakcji wypożyczania filmu oraz obliczania terminu oddania filmu.
● VARCHAR – opisujący większość atrybutów encji, takich jak tytuł filmu, imię i nazwisko klienta, oraz opisy filmów, które różnią się od pozostałych atrybutów znacznie większą liczbą znaków.
● IMAGE – służący do przechowywania plików będących graficznym odpowiednikiem tytułu każdego filmu (okładki płyt DVD).
 

Struktura danych:

Podstawową strukturą danych w aplikacji jest relacja będąca podzbiorem iloczynu kartezjańskiego dwóch zbiorów przedstawiających dopuszczalne wartości. W bazie danych relacja przedstawiana jest w postaci tabeli jako zbiór krotek, które posiadają taką samą strukturę, ale różne wartości. Każda krotka odpowiada jednemu wierszowi tablicy oraz posiada co najmniej jeden atrybut odpowiadający pojedynczej kolumnie tablicy. Każdą relację (tablicę) określa kilka następujące wartości:
● krotki (wiersze) są unikalne
● atrybuty (kolumny) są unikalne
● kolejność krotek (wierszy) nie ma znaczenia
● kolejność atrybutów (kolumn) nie ma znaczenia
● wartości atrybutów (pól) są atomowe.
Poprzez strukturę danych rozumiemy także związki między relacjami oraz ograniczenia.

Przykładowa tabela [FILMY] zawierająca atrybuty:

Encje, atrybuty i ich typy:

W powyższym diagramie związków encji przedstawiającym konceptualny model danych relacyjnej bazy danych dla wypożyczalni płyt DVD widzimy osiem encji, mianowicie: FILMY, PRODUKCJA, GATUNEK, REŻYSERIA, ROLA, ROLAwFILMIE, ARTYSTA i WYPOŻYCZONE.
Encje te zawierają wszystkie potrzebne informacje na temat filmów, klientów, filmów aktualnie wypożyczonych i stanów filmów w danym czasie, czyli atrybuty wraz z ich typami danych oraz klucze główne.
 

Związki między encjami, ich liczebność i uczestnictwo encji:

W modelu tym mamy styczność z wieloma związkami (relacjami) między encjami, i są to:
● Produkcja filmu:
Opis: przynależność produkcji do filmu;
Liczebność: jeden do wielu (1, N);
jedna produkcja może być przypisana do wielu filmów, natomiast jeden film może być przypisany tylko do jednej produkcji;
Uczestnictwo: FILMY – wymagane; PRODUKCJA – opcjonalne;
każdy film musi być przypisany do producenta, ale nie każdy producent musi być przypisany do filmu;
● Gatunek filmu:
Opis: przynależność gatunku do filmu;
Liczebność: jeden do wielu (1, N);
jeden gatunek może być przypisany do wielu filmów, natomiast jeden film może być przypisany tylko do jednego gatunku;
Uczestnictwo: FILMY – wymagane; PRODUKCJA – opcjonalne;
każdy film musi być przypisany do gatunku, ale nie każdy gatunek musi być przypisany do filmu;
● Wypożyczony film:
Opis: wypożyczenie filmu;
Liczebność: jeden do wielu (1, N);
jeden film może być wypożyczony tyle razy jednocześnie, ile jest jego na stanie, natomiast jeden film wypożyczony jest przypisany tylko do jednego filmu;
Uczestnictwo: FILMY – opcjonalne; WYPOZYCZONE – wymagane;
każdy wypożyczony film musi być przypisany do filmu, ale nie każdy film musi być w danym czasie wypożyczony;
● Klient wypożyczył:
Opis: klient wypożycza film;
Liczebność: jeden do wielu (1, N);
jeden klient może wypożyczyć kilka filmów, natomiast jeden wypożyczony film jest przypisany tylko do jednego klienta;
Uczestnictwo: KLIENT – opcjonalne; WYPOZYCZONE – wymagane;
każdy wypożyczony film musi być przypisany tylko do jednego klienta, ale jeden klient może mieć wypożyczonych kilka filmów lub wcale;
● Rola artysty w filmie:
Opis: artysta gra różne role w różnych filmach;
Liczebność: wiele do wielu (N, M);
wiele filmów musi mieć wiele ról (aktor, scenariusz, reżyseria, muzyka, zdjęcia) oraz artysta może grać kilka ról w jednym filmie;
Uczestnictwo: ROLAwFILMIE – wymagane; FILM – wymagane;
filmy muszą mieć przypisane role, oraz role muszą być przypisane do filmów;
 

Uwarunkowania technologiczne:

Z punktu widzenia uwarunkowania technologicznego baza danych dla wypożyczalni płyt DVD jest przewidziana do adaptacji w systemie bazodanowym Microsoft SQL Server. Jest to relacyjna baza danych, która poprzez relacje encji umożliwia nam pozyskiwanie i tworzenie spójnych danych. Bazę tworzą encjie, odpowiednio będące ze sobą w relacji. Przykładowymi encjami systemu będą: filmy, klienci, gatunki filmów, produkcja filmów, role, role aktorów w filmach oraz artyści. Każda z tych encji zawiera wszystkie wymagane atrybuty oraz klucze główne, kandydujące i obce.
W bazie danych zaimplementowanych będzie sporo funkcji, m.in. takich jak:
● Ograniczenia:
– NOT NULL – oznaczające, że krotka nie może być pusta;
– deklaracja klauzuli DEFAULT – która pozwala definiować wartość domyślną;
– CHECK – który wymusza wprowadzenie poprawnych danych w odpowiednim formacie;
● Perspektywy:
– VIEW – czyli pojedyncze wirtualne tabele wywiedzione z innych tabel;
● Indeksy:
– INDEX – dzięki któremu dane nie są wyszukiwane kolejno, tylko po indeksach;
● Procedury przechowywane:
– PROCEDURE – pozwalające na częste wykonywanie zaawansowanych zapytań bez obciążania servera;
● Wyzwalacze:
– CASCADE UPDATE/INSERT/DELETE – czyli specjalne procedury przechowywane modyfikujące, wstawiające i usuwające dane;
● Transakcje:
– TRANSACTION – czyli wykonywane programy, które tworzą logiczną jednostkę przetwarzania w bazie danych;
● Nadawanie praw użytkownikom:
– GRANT, DENY, REVOKE – pozwalające na określenie praw użytkowników do danych oraz do operacji wykonywanych na tych danych;
● Zaawansowane wyszukiwanie danych:
– SELECT, ORDER BY, JOIN, LIKE, HAVING, WHERE– umożliwiające wyszukiwanie wg różnych kryteriów;
● Funkcje agregujące:
– AVG, COUNT, SUM, MIN, MAX – obliczające średnią arytmetyczną, zliczającą, sumującą, wartości minimalne i maksymalne;
● Replikacja danych:
Nie możemy dopuścić do utraty danych, więc baza każdej nocy, po dniu, w którym była modyfikowana zostanie automatycznie replikowana.
 
 

7. OPIS MODELU LOGICZNEGO I FIZYCZNEGO SYSTEMU ODWZOROWUJĄCYCH MODEL KONCEPTUALNY I UWZGLĘDNIAJĄCYCH WYMAGANIA IMPLEMENTACJI

 
MODELOWANIE DANYCH:

Modelowanie danych jest procesem szczególnej analizy danych, mającej na celu stworzenie modelu systemu informacyjnego pozwalającego operować informacjami dotyczącymi określonego celu projektu fragmentu rzeczywistości, ale niejako od góry, a nie od podstaw, jak w przypadku normalizacji.

Normalizacja zaczyna się zebraniem danych, które mają być przechowywane w bazie danych, podczas kiedy modelowanie danych polega na określeniu tematów mających znaczenie dla projektu oraz charakterystycznych dla nich cech. W efekcie powstaje koceptualny model danych (Conceptual Data Model – CDM), czyli zbiór specyficznych dla danego projektu wymagań dotyczących danych. Model ten jest następnie przekształcany w fizyczny model danych (Physical Data Model – PDM). Normalizacja może posłużyć dla sprawdzenia otrzymanego fizycznego modelu danych, a przynajmniej jego krytycznych części.

Modelowanie danych pozwala na łatwe wprowadzanie zmian do projektu w każdej chwili, bez potrzeby ponownego przeprowadzania analizy danych, co często okazuje się rzetelną strategią.
Jednak, żeby dogłębnie zrozumieć, przeanalizować oraz rozwiązać problem, należy wcześniej przygotować kilka diagramów, które szczegółowo są opisane poniżej.
 

DIAGRAM PRZYPADKÓW UŻYCIA:

Diagram przypadków użycia (Use Case) definiuje interakcje pomiędzy użytkownikami a systemem w konkretnym scenariuszu, czyli przebiegu wydarzeń, nie wchodząc w szczegóły implementacji. Schemat przedstawiać będzie wszelkie czynności, jakie wykonuje osoba obsługująca aplikację. Pokazuje on wymagania, jakie systemowi narzucają korzystające z niego osoby. Jako jeden z prostszych i bardziej intuicyjnych diagramów, doskonale nadaje się do zaprezentowania nabywcom właśnie tego typu aplikacji.

Schemat przypadków użycia składa się z aktorów, przypadku użycia i komunikacji (przedstawionych w formie kresek pomiędzy aktorami a przypadkami). Można również wiązać ze sobą przypadki użycia, łącząc include, extend i generalizację. Pierwsze z nich określa czynności, które muszą się wydarzyć, gdy zachodzi określony przypadek użycia. Include używa się zazwyczaj, gdy dana czynność musi być wykonana w kilku różnych przypadkach. Związek typu extend pomiędzy przypadkami użycia to ewentualne rozszerzenie przypadku o dodatkową funkcjonalność.

Zatem diagram przypadków użycia jest wykorzystywany do:
● wyrażania wymagań systemu;
● komunikacji z użytkownikami końcowymi i ekspertami z określonej dziedziny;
● testowania systemu.

DIAGRAM AKTYWNOŚCI:

Diagram aktywności (Activity Diagram – AD) – jest graficznym przedstawieniem procesu lub procesów, na które składają się obiekty tworzące całą aplikację bądź interesującą nas jej część. Za pomocą tego typu diagramów z łatwością można wyimaginować aspekty programowania wielowątkowego, jak i dogłębnie je przeanalizować.

Schemat aktywności składa się z kilku podstawowych zagadnień:
● aktywności – którą definiujemy jako funkcję wykonywaną przez określony obiekt systemu; funkcjonalność ta może mieć także charakter sekwencyjny, obejmujący kilka obiektów;
● przejść – które występują po wykonaniu funkcji oraz zrealizowaniu wszystkich warunków nałożonych na określone przejście;
● synchronizacji – która polega na równorzędnym wykonywaniu aktywności przez kilka obiektów.

Z powodu złożoności aplikacji przedstawiona zostanie tylko jedna funkcja (spośród ośmiu) systemu: „wypożyczenie filmu”. Jeżeli chodzi o pozostałe funkcje, to będą one analogiczne do tej.

DIAGRAM SEKWENCJI:

Diagram sekwencji (Sequency Diagram – SD) – jest jednym z modeli zachowania opisującym system od strony jego dynamiki. Ponadto można za jego pomocą przedstawić w sposób graficzny procesy, jakie zachodzą w systemie. Diagram sekwencji ilustruje wszystkie aktory oraz obiekty, które partycypują w interakcji, jak i wszystkie wygenerowane przez nie zdarzenia przedstawione w sposób chronologiczny. Jest on odwzorowaniem zdarzeń przedstawionych na diagramie przypadków użycia z tą różnicą, że na dwóch płaszczyznach: poziomej i pionowej, odpowiadających odpowiednio obiektom i czasowi.
 

Schemat tworzą podstawowe elementy takie jak:

● aktor – oznaczony w diagramie ludzikiem;
● obiekt – przedstawiony za pomocą prostokąta;
● linia życia – pionowa, przerywana linia, przedstawiająca czas istnienia danego elementu;
● aktywacja – prostokąt na linii życia, ilustrujący czas wykonania danej operacji;
● bodźce – różnego rodzaju strzałki:

Z powodu złożoności aplikacji przedstawione zostanie tylko jedno zdarzenie systemu: „dodawanie filmu”. Jeżeli chodzi o pozostałe zdarzenia, to będą one analogiczne do tego.

8. MODEL LOGICZNY

 
DIAGRAM ZWIĄZKÓW ENCJI:

Model danych można reprezentować na kilka sposobów, jednym z nich są diagramy związków encji (Entity Relationship Diagrams – ERD). Przewidziany celem projektu obszar analizy jest w diagramach związków encji reprezentowany przez elementy takie jak:
● ENCJE:
Encja to inaczej obiekt, pewien aspekt fragmentu rzeczywistego świata opisywanego projektem, który to aspekt można jednoznacznie odróżnić od innych w danym fragmencie rzeczywistości. Pojęcie encji jest zazwyczaj używane jako synonim typu encji, jest to dopuszczalne, należy jednak zdawać sobie sprawę z różnicy pomiędzy tymi dwoma pojęciami. Encja jest instancją typu encji. Inaczej mówiąc typ encji jest kategorią, do której zaliczają się wszystkie encje danego typu. Modelując dane należy dla wyodrębnienia encji posługiwać się następującą zasadą: „Encja w konceptualnym modelu danych tworzonym w oparciu o diagramy związków encji należy uczynić te rzeczy z rozpatrywanego fragmentu rzeczywistego świata, dla których trzeba przechowywać dane na temat wielu ich właściwości”. Należy przy tym zauważyć, ze użyty termin nie odnosi się tylko i wyłącznie do obiektów fizycznych czy materialnych, ale także może być obiektem takim jak klient lub film, czy też zdarzeniem lub pojęciem, jak wypożyczenie filmu czy zamówienie na jego wypożyczenie. Encje, a właściwie typ encji oznacza się na diagramie jako prostokąt. W oddzielonej poziomą linią górnej części wpisuje się nazwę typu encji.
● ZWIĄZKI:
Związek odzwierciedla zależności pomiędzy encjami, przy czym rozpatrywane są jedynie zależności bezpośrednie. Pomiędzy dwoma encjami może zachodzić więcej niż jeden związek. Ze związkiem kojarzone są następujące pojęcia:
Związek oznacza się na diagramie jako linie łączące encje. Zakończenia linii odzwierciedlają liczebność związku. Z kolei liczebność określa ilość instancji danego typu encji biorących udział w związku.
Możliwe określenia liczebności to:
– Jeden do jednego – 1:1;
– Jeden do wielu – 1:N;
– Wiele do wielu – M:N.
Liczebność łatwo jest określić na podstawie faktów ze świata rzeczywistego dotyczących danych rzeczy, sprowadza się to do wyrażenia dwóch asercji na ich temat opartych o te fakty, na przykład: każdy klient może (ale wcale nie musi) mieć wypożyczony filmu oraz każdy film może być (ale wcale nie musi) wypożyczony lub wypożyczony wielu klientom (w zależności od ilości danego filmu na stanie).
Uczestnictwo określa status encji w danym związku i może być wymagane lub opcjonalne. Podobnie jak w przypadku liczebności uczestnictwo łatwo jest określić wyrażając dwie asercje w oparciu o fakty ze świata rzeczywistego: każdy film musi mieć określony gatunek filmu ale nie każdy gatunek filmu musi być przypisany do filmu.
W tym przykładzie uczestnictwo encji gatunek filmu w związku jest opcjonalne, natomiast wymagane jest uczestnictwo encji film.
Uczestnictwo w związku można także definiować przy pomocy pojęcia liczebności maksymalnej i minimalnej dla danego związku. Określenie liczebności minimalnej na 0 po stronie danej encji uczestniczącej w związku oznacza opcjonalność uczestnictwa tej encji. Określenie liczebności minimalnej na 1 oznacza, ze encja ta jest w danym związku wymagana.
W przypadku uczestnictwa opcjonalnego rysowane jest kółko po stronie danej encji natomiast w przypadku uczestnictwa wymaganego poprzeczna kreska.
● ATRYBUTY:
Każdy typ encji charakteryzuje sie pewnym zbiorem cech, właściwości, które nazywa sie atrybutami. Wartości przypisywane atrybutom odróżniają od siebie poszczególne instancje encji. I tak, atrybutem encji film z całą pewnością będzie numer identyfikacyjny filmu, tytuł, opis, czas trwania, gatunek, produkcja, kod kreskowy, dostępność oraz cena. Ze zbioru atrybutów danego typu encji wybiera sie jeden lub więcej atrybutów na identyfikator instancji encji, w modelu fizycznym znajdzie on odzwierciedlenie jako klucz główny relacji. W tym przypadku niewątpliwie najlepszym identyfikatorem encji jest numer identyfikacyjny filmu, który jest z natury unikatowy lub kod kreskowy filmu, który także spełnia warunki na klucz główny.
Nazwy atrybutów wpisujemy w dolną część prostokąta oznaczającego encje. Nazwę atrybutu będącego identyfikatorem należy podkreślić. Jest dopuszczalnym dodawanie obok nazwy atrybutu jego typu lub domeny, do której należy, a która również określa jego typ. Częstszym i wygodniejszym dla dużych projektów, a w przypadku podania nazwy domeny koniecznym jest uzupełnienie diagramu związków encji o słownik danych.

9. MODEL FIZYCZNY

 
FIZYCZNY MODEL DANYCH:

PDM (Physical Data Model) – fizyczny model danych – prezentuje graficznie, za pomocą diagramu wszystkie element składające się na bazę danych, a więc: encje, pola, klucze, relacje, indeksy, widoki, procedury i wyzwalacze. Owy model współpracuje z wieloma rodzajami systemów zarządzania bazą danych, jednak ja skupiam się na MsSQL.
Ten model jest na tyle elastycznym rozwiązaniem, że nie ma większego problemu z jego utworzeniem. Mamy możliwość utworzenia go oczywiście od podstaw, ale ciekawszym, jak i o wiele bardziej przydatnym rozwiązaniem (wcześniej już wspomnianym) jest przekształcenie utworzonego wcześniej konceptualnego modelu danych (CDM – Conceptual Data Model) właśnie na fizyczny model danych (PDM) jak i mamy możliwość wykreować go na podstawie istniejącej już bazy danych, czy choćby z samego skryptu SQL.