Modelowanie danych

W poprzednim odcinku mówiliśmy o podstawowym elemencie projektowania - strukturze projektu. Jak nasi Czytelnicy zapewne pamiętają, opisaliśmy strukturę projektu traktując ją jako swego rodzaju przepis postępowania, pozwalający w logiczny i konsekwentny sposób przejść od wymagań użytkownika do realizującego je systemu informatycznego. Oczywiście tego rodzaju recepta to nie wszystko. Nie wystarczy wiedzieć, co i w jakiej kolejności należy wykonywać. Trzeba jeszcze wiedzieć JAK zrealizować poszczególne czynności. Realizacja etapów, kroków i zadań w projekcie informatycznym polega na ogół na tworzeniu różnego rodzaju dokumentów. Są nimi np. diagramy, dokumenty tekstowe, analizy wolumetryczne, fragmenty kodu, struktury danych, plany pracy itd. Tak więc, kolejnym etapem metodyki strukturalnej jest zestaw technik służących do tworzenia powyższych produktów.

Najbardziej znane i popularne techniki, dotyczące etapów analizy i projektowania to, modelowanie danych z wykorzystaniem diagramów, nazywanych modelami danych lub (częściej, ale brzydziej) diagramami związków encji oraz modelowanie procesów na podstawie diagramów przepływu danych. Pozwalają one na dość proste, czytelne i w miarę jednoznaczne opisanie dwóch podstawowych składników systemu: struktury jego danych oraz sposobu ich przetwarzania. W tym artykule zajmiemy się modelowaniem danych, w następnym zaś powiemy o diagramach DFD i Analizie Funkcyjnej.

Modelowanie danych

Technika modelowania danych ma w cyklu projektowym kilka zastosowań. Po pierwsze, pozwala na uzgodnienie z użytkownikiem zakresu informacji przetwarzanej i przechowywanej przez przyszły system informacyjny. Po drugie, pozwala określić logiczne zależności między danymi, które są - lub mogą być - istotne z punktu widzenia danych nowego systemu. Po trzecie, stanowiąc model niezależny od docelowego środowiska implementacji (DBMS, system operacyjny, sprzęt) pozwala jednocześnie na proste -często automatyczne - przejęcie do definicji bazy danych.

Można by długo rozpisywać się na temat modelowania danych, jednak kierując się przedwojenną mądrością ("koń jaki jest, każdy widzi") pokażemy po prostu przykładowy, prosty model danych dla hipotetycznego systemu obsługi i rejestracji zamówień. Wyobraźmy sobie przedsiębiorstwo handlowe zamierzające zautomatyzować proces przetwarzania zamówień. Zamówienia składane są przez klientów i dotyczą produktów dostarczanych przez dostawców. W czasie pierwszych rozmów z użytkownikami, analityk mógłby stworzyć następujący model danych.

Tego typu diagram będzie charakterystyczny dla wielu metodyk strukturalnych. Występujące niekiedy różnice dotyczą zwykle szczegółów notacji.

Jak widać, model danych jest diagramem zawierającym wiele obiektów, zwanych obiektami informacyjnymi lub encjami. Odpowiadają one tym obiektom automatyzowanego systemu, dla których chcemy przechowywać jakieś informacje. Ważną cechą encji jest pewna ich ogólność - służą raczej klasyfikowaniu, niż wyodrębnianiu konkretnych obiektów. Dlatego przykładami encji w naszym systemie są: Zamówienie, Klient, Produkt. Nie będzie zaś zwykle encją zamówienie nr 12/12/1993, klient "Borys Stokalski" czy produkt "Kompaktowa smażalnica do jajek". Te ostatnie można uznać za wystąpienia konkretnych encji.

Oprócz samych encji na diagramach pokazujemy zależności (związki) między danymi systemu. Przedstawiają je różne linie łączące encje. Jak widać, zależności, o których mówimy przy okazji modelowania danych, zawsze wiążą ze sobą wystąpienia różnych encji (zawsze dwóch).

Z zależnościami wiąże się ważna właściwość - moc. Przyjrzyjmy się bliżej związkowi między klientem a zamówieniem: symbole na linii przedstawiającej ten związek mówią, że każdy Klient Składa wiele Zamówień ("kurza łapka" przy encji Zamówienie), ale może też nie składać żadnego ("kółko" przy encji Zamówienie). Każde Zamówienie może być Złożone Przez co najmniej i co najwyżej jednego Klienta (kreski po stronie encji Klient).

Tego typu związki - wiążące wystąpienia jednej encji z potencjalnie wieloma wystąpieniami innej (jeden klient - potencjalnie wiele zamówień) nazywane są związkami 1:N ("jeden do wielu"). Z uwagi na moc związków możemy też wyróżnić inne ich typy - a więc 1:1 i N:N ("jeden do jeden" i "wielu do wielu"). Nasz przykładowy model danych zwiera wiele związków N:N - np. związek Zamówienia i Produkty. Produkty mogą być zamawiane w wielu zamówieniach, zaś każde zamówienie dotyczyć wielu produktów.

Nasz model, choć prosty i zapewne bez trudu rozumiany przez użytkownika, nie jest jednak ostatecznym produktem analizy. Okazuje się bowiem, że związki N:N są nieprzydatne z punktu widzenia struktury bazy danych. W trakcie analizy zostają więc wyeliminowane poprzez wprowadzenie nowych encji i zależności 1:N. Nasz przykładowy model danych, po dokonaniu dalszej analizy zmieniłby się zapewne na model podobny do następującego:

Taki model wydaje się już być bliższy ideałowi. Aby jednak na jego podstawie wygenerować schemat bazy danych, należy jeszcze określić jakie są atrybuty poszczególnych encji. Niektóre z tych atrybutów będą miały szczególne zaczenie, jako jednoznaczne wyróżniki wystąpień poszczególnych encji. Takie wyróżniki przyjęło się nazywać kluczami encji.

Dokładniejsza analiza atrybutów encji, czasem przy zastosowaniu techniki zwanej normalizacją, prowadzi często do dalszego rozbicia modelu danych. Celem tych czynności jest doprowadzenie naszej specyfikacji do takiej postaci, która umożliwi przechowywanie istotnych danych systemu bez niepotrzebnych duplikacji i przy zachowaniu wszystkich ważnych dla użytkownika zależności.

Teraz łatwo jest już przejść do definicji bazy danych. W relacyjnej bazie danych encje stają się relacjami, atrybuty - kolumnami, klucze encji - kluczami relacji. Związki realizowane są przez odpowiednie rozmieszczenie "obcych" atrybutów kluczowych - np. klucz encji Zamówienie, może stać się częścią klucza encji Pozycja Zamówienia. Takie przejście może być w prosty sposób wykonane automatycznie, przez odpowiednie narzędzie wspomagające pracę nad projektem. Aby jednak naprawdę rzetelnie zaprojektować strukturę i schemat bazy danych, potrzebny jest jeszcze jeden element. Tym elementem są informacje wolumetryczne. Wolumetria określa szacowania rozmiaru i częstości operacji dokonywanych na encjach i związkach. One to pozwalają wyliczyć zapotrzebowanie na pamięć dyskową i zoptymalizować wiele parametrów tworzonej bazy danych.

Modelowanie danych wymaga od analityka odrobiny doświadczenia, a w fazie tworzenia modelu fizycznego (związanego z konkretną implementacją), także dobrej znajomości wybranego systemu bazy danych. Każdy projekt kryje w sobie wiele zagadek, trudności interpretacyjnych i "nietypowych" problemów. Jednakże doświadczony analityk może stworzyć za pomocą tej techniki jednoznaczną, zrozumiałą dla użytkownika i niezależną od implementacji specyfikację. Faktem jest, że modelowanie danych jest chyba dzisiaj najbardziej popularną techniką metodyk strukturalnych.