Znaczenie podstawowych terminów związanych z bazami danych
Dane
(z ang. data) symbole używane do reprezentacji obiektu np.: "Jan Kowalski", 27091963
Obiekt
(z ang. object) wyodrębniony przedmiot, osoba lub istota, pojęcie lub zdarzenie
Informacje
(z ang. informations) zinterpretowane dane, którym nadano znaczenie np.:Pacjent: "Jan Kowalski", Data urodzenia pacjenta: 27 wrzesień 1963 r.
System informacyjny
(z ang. informations system) zestaw metod tworzenia, przechowywania, aktualizacji i udostępniania informacji
System informatyczny
system informacyjny zrealizowany przy pomocy techniki komputerowej
Baza danych
(z ang. database) jako podstawowy element systemu informatycznego jest zbiorem danych o wybranym obszarze analizy
Obszar analizy
(z ang. universe of discourse) wybrany fragment otaczającej nas rzeczywistości, który zawiera w sobie encje
Encja
(z ang. entity) istotna klasa obiektów występujących w analizowanym modelu świata rzeczywistego
Atrybut encji
(z ang. entity attribute) właściwość obiektu uwzględnionego w obszarze analizy
Związek encji
(z ang. entity relationship) zależność pomiędzy encjami (zazwyczaj dwoma)
Instancja encji
jeden obiekt należący do danej klasy obiektów (encji)
Diagram związków encji
(z ang. entity relationship diagram - ERD) graficzna reprezentacja encji i ich związków w formie diagramu
Intensjonalna część bazy danych
(inaczej: projekt bazy danych lub schemat bazy danych - z ang. database schema) tabele i ich kolumny, a także klucze - wyodrębnione na podstawie encji i ich związków
Ekstensjonalna część bazy danych
dane przechowywane w bazie danych
System zarządzania bazą danych - SZBD
(z ang. database management system - DBMS) narzędzie administrujące bazą danych i zapewniające efektywny dostęp, ochronę danych przed niepowołanych dostępem, wielodostęp, aktualizację danych
Relacyjna baza danych
(z ang. relational database) baza danych operująca danymi w postaci tabel zwanych też relacjami
System zarządzania relacyjną bazą danych - SZRBD
(z ang. relational database management system - RDBMS) narzędzie administrujące relacyjną bazą danych
Znaczenie wybranych skrótów
CASE
(z ang. Computer Aided Software Engineering) wspomagana komputerowo inżynieria oprogramowania
MRP
(z ang. Material Requirements Planning) planowanie potrzeb materiałowych
MRP II
(z ang. Manufacturing Resource Planning) planowanie zasobów produkcyjnych
ERP
(z ang. Enterprise Resource Planning) planowanie zasobów finansowych
EDI
(z ang. Electronic Data Interchange) elektroniczna wymiana danych
Projektowanie systemu informatycznego
Diagram związków encji jest jednym ze sposobów przedstawienia modelu logicznego bazy danych. Jest to rysunek encji i związków pomiędzy nimi, który ułatwia analizę wybranego obszaru świata rzeczywistego modelowanego w bazie danych.
Baza danych jest modelem pewnego fragmentu otaczającego nas świata rzeczywistego. Ów fragment nazywany jest obszarem analizy i podczas tych zajęć interesuje nas uproszczony model składania zamówień przy sprzedaży bombonierek. 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, przegląda zasoby Sieci (np.: Firma Cukiernicza "Solidarność"), analizuje dokumenty firmy itp. "Klient może kupić (lub zamówić do późniejszego odbioru) wiele, różnych bombonierek. Klient może dostać fakturę VAT jako dokument płatniczy do zamówienia lub transakcja kupna-sprzedaży może zostać zafiskalizowana (wtedy, gdy klient przy zakupie płaci gotówką). Klientem może być firma (podmiot gospodarczy) lub osoba fizyczna. Jeżeli zamówienie zostanie źle przyjęte, a wystawiono już do niego fakturę VAT, to wystawiamy do zamówienia kolejną fakturę: fakturę korygującą, a następnie przyjmujemy ponownie zamówienie. Przyjmujemy, że zamówienie dotyczy tylko jednego klienta (w rzeczywistości może to być: osoba zamawiająca, odbiorca i płatnik) i jest ono obsługiwane przez jednego pracownika. Niekiedy musimy informować klientów o zawartości bombonierek (o czekoladkach), jeżeli wymagają oni tych informacji."
Spróbujmy wyodrębnić z tego krótkiego opisu 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ę (tu sztucznie wyróżnione) następujące obiekty: klienci, pracownicy, zamówienia, bombonierki, czekoladki, faktury. Można wyróżnić w tym modelu więcej obiektów, ale utrudniłoby to jego zarówno przedstawienie jak i zrozumienie (np.: nasza firma może być kilkoma podmiotami gospodarczymi). Zaobserwowane obiekty odrysowujemy na diagramie Venna i obiekty tej samej klasy grupujemy w zbiory (tu 6 zbiorów: klientów, pracowników, zamówień, bombonierek, czekoladek i faktur). Pomiędzy poszczególnymi obiektami rysujemy linie, które symbolizują zależności pomiędzy tymi obiektami zachodzące w świecie rzeczywistym.
Przyjrzyjmy się dokładnie powyższemu rysunkowi i przeanalizujmy związki, które zachodzę pomiędzy poszczególnymi obiektami.
* Jak widać na 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 (to efekt wcześniejszego założenia) i że mogą być zamówienia takie, że klient jest nieznany, a sytuacja taka ma miejsce wtedy, gdy anonimowa osoba kupuje towar i płaci gotówką, a fakt ten jest rejestrowany tylko w urządzeniu fiskalnym - drukarce lub kasie. * Podobne zależności występują pomiędzy pracownikami, a zamówieniami: dany pracownik może obsługiwać wiele zamówień (gdy jest on kasjerem lub sprzedawcą np. "Stanisław Kowalski", ale nie musi - gdy jest on załóżmy dyrektorem np. "Jan Nowak") oraz dane zamówienie MUSI być obsłużone przez jednego pracownika (też efekt założenia, że pracownik jest jeden, jednak musi ktoś w imieniu firmy zamówienie przyjąć). * Ciekawe zależności występują pomiędzy bombonierkami, 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.: bombonierka "Czekoladowe party"), 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: bombonierka "Czekoladowy słoń"). * Podobne do powyższych zależności występują pomiędzy bombonierkami, a czekoladkami - KAŻDA bombonierka zawiera w sobie przynajmniej jeden typ czekoladki, a każda z czekoladek danego typu może być zapakowana do różnych typów bombonierek. Sytuacja dotycząca czekoladki "Czekoladka mleczna" może sygnalizować stan polegający na tym, że znamy już co będzie składnikiem nowego typu bombonierki, który jest dopiero w produkcji. * Ostatnimi interesującymi zależnościami są te zachodzące pomiędzy zamówieniem, a fakturą. Jak widać z diagramu Venna do zamówienia możemy wystawić maksymalnie dwie faktury, ale każda faktura musi dotyczyć jednego zamówienia (nie wykonujemy faktur zbiorczych - uproszczenie projektu). Faktury VAT i korygujące mogą mieć wspólną numerację (to zastosujemy), ale mogą być oddzielnie numerowane.
W praktyce diagram Venna nie jest wykonywany, gdyż byłby niecztelny (zbyt wiele zależności pomiędzy obiektami utrudnia odczytanie diagramu) dla większej ilości obiektów przy złożonych modelach wykonywanych w zastosowaniach profesjonalnych. Ta technika została przedstawiona dla ułatwienia zrozumienia bardzo prostego projektu bazy danych.
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 takie jak: "klient", "pracownik", "zamówienie" i inne. Zauważmy też, że pomiędzy encjami pojawiły się specjalnie oznakowane kreski, które symbolizują związki encji. Jak już wspominałem, sposobów na ich oznakowanie jest kilka. 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". Odczyt powyższego diagramu jest prostszy niż diagramu Venna. Czytając związki encji (czytamy w obie strony związku) widzimy, że:
* "Jeden klient może złożyć wiele zamówień" * "Zamówienie może być złożone przez maksymalnie jednego klienta" * "Pracownik może przyjąć wiele zamówień" * "Zamówienie musi być przyjęte przez jednego pracownika" * "Każde z zamówień dotyczy przynajmniej jednego typu bombonierki, ale może wielu" * "Każdy typ bombonierki może być składnikiem wielu zamówień". * "Każdy typ bombonierki zawiera przynajmniej jeden typ czekoladki" * "Każdy typ czekoladki może być składnikiem wielu typów bombonierek" * "Do każdego zamówienia możemy wystawić maksymalnie dwie faktury" * "Każda faktura musi być wystawiona tylko do jednego zamówienia"
Analizowany przez nas projekt nie nadaje się do zastosowań profesjonalnych, a dzieje się tak m.in. dlatego, że nie uwzględniamy w nim konkretnych dostaw towaru. Przyjmujemy, że mamy zawsze pełne magazyny niepsujących się bombonierek i z tego powodu mówiąc bombonierka mamy na myśli raczej typ bombonierki, a nie konkretną bombonierkę z konkretnej dostawy. Z tego powodu przeczytałem związki encji mówiąc o typach bombonierek, czy typach czekoladek. W przyjętym modelu bombonierka ma zawsze taką samą cenę (pamiętaną dla bombonierki), a tymczasem powinien być do niej przypisany cennik, który obowiązuje w danym okresie czasu. Pomijamy ten problem w celu uproszczenia projektu.
Nie istnieje taki System zarządzania relacyjną bazą danych, który obsługuje związki wiele do wielu, a takie właśnie związki zachodzą pomiędzy bombonierką i zamówieniem oraz czekoladką i bombonierką. Związki te muszą zostać usunięte z diagramu w wyniku zastąpienia ich dwoma związkami jeden do wielu i encją przejściową.