Projektowanie relacyjnych baz danych Wprowadzenie do systemów baz danych

Funkcje bazy danych Baza danych jest modelem pewnego fragmentu rzeczywistości zwanego obszarem analizy Informacje przechowywane w bazie danych są zazwyczaj próbą reprezentowania właściwości niektórych obiektów w świecie rzeczywistym (obszarze analizy) Najczęściej bazy danych tworzy się do modelowania i wspomagania pracy organizacji gospodarczych, państwowych lub politycznych Bazy danych stanowią część systemów informacyjnych organizacji, które je tworzą (dla własnych potrzeb)

Etapy tworzenia bazy danych Ustalenie wymagań odbiorcy Modelowanie konceptualne Modelowanie logiczne Modelowanie fizyczne Realizacja bazy danych

Metody projektowania Diagram związków encji (diagram E-R) Metoda diagramu związków encji nie wymaga zgromadzenia danych przed przystąpieniem do projektowania bazy danych Dane są wprowadzane do bazy po jej zaprojektowaniu Projektowanie polega na analizie rzeczywistości Alternatywną metodą jest normalizacja, która wymaga zidentyfikowania całego zbioru danych przed przystąpieniem do projektowania struktury bazy danych. Celem projektowania jest podzielenie zbioru danych na logiczne grupy. Metoda stosowana, gdy przed przystąpieniem do projektowania mamy już zgromadzone dane np. w arkuszach kalkulacyjnych MS Excell lub w formie ksiąg papierowych Projektowanie polega na analizie zgromadzonych danych Obie metody powinny prowadzić do tego samego wyniku, a przynajmniej do podobnego

Metoda diagramów związków encji Rozpoznanie encji występujących w obszarze analizy Określenie związków zachodzących pomiędzy encjami Stworzenie diagramu związków encji Przekształcenie diagramu w schemat relacyjnej bazy danych

Encja Encja – pewien aspekt „świata rzeczywistego”, który istnieje niezależnie i może być jednoznacznie zidentyfikowany Encją może być rzecz, która w organizacji jest rozpoznawana jako rzecz istniejąca niezależnie i unikatowo zidentyfikowana Encją może być nie tylko rzecz istniejąca w przestrzeni ale i zdarzenie istniejące w czasie (np. sprzedaż) lub pojęcie (np. zamówienie, zaliczenie, dzierżawa) Jako aspekt świata rzeczywistego encja jest scharakteryzowana pewną liczbą właściwości – atrybutów Encja jest abstrakcją złożoności pewnej dziedziny Jeśli trzeba przechowywać dane na temat wielu właściwości jakiejś rzeczy, to taka rzecz jest prawdopodobnie encją

Przykłady encji Encja klient posiadająca atrybuty: nazwisko, imię, nr telefonu, adres, rabat itp. Encja towar posiadająca atrybuty: nazwa, producent, jakość, cena itp. Encja sprzedaż posiadająca atrybuty: klient, towar, ilość, data itp. W bazie danych encjom będą odpowiadały krotki (wiersze), a atrybutom kolumny. Tabela będzie jest zbiorem encji tego samego typu (tej samej klasy).

Określenie identyfikatorów encji Spośród atrybutów należy wybrać jeden lub kilka jednoznacznie identyfikujące encje tej samej klasy Identyfikowanie encji (obiektów) za pomocą dużej liczby atrybutów jest złym rozwiązaniem, dlatego należy poszukiwać jednego atrybutu identyfikującego encje (obiekty) tej samej klasy, a jeśli takiego atrybutu nie ma, należy go utworzyć poprzez: Dodanie do encji specjalnego atrybutu zawierającego identyfikator obiektu; zwykle o nazwie id_nazwa_obiektu Zwykle w celu identyfikacji encje numerujemy W bazie danych identyfikator przekształci się w klucz główny tabeli, który wymusi integralność encji

Określenie związków Związek jest pewnym powiązaniem miedzy encjami Między encjami klient i sprzedaż zachodzi następujący związek klient może uczestniczyć w wielu aktach sprzedaży, w jednej sprzedaży uczestniczy jeden klient – jest to związek jeden do wiele w bazie danych związkowi jeden do wiele odpowiada klucz obcy Między encjami klient i towar zachodzi następujący związek klient może kupić wiele towarów, towar może być kupiony przez wielu klientów - jest to związek wiele do wiele w bazie danych związek wiele do wiele zapisuje się w osobnej tabeli, w omawianym przykładzie będzie to tabela sprzedaż – związek między towarem a klientem jest związkiem pośrednim (poprzez sprzedaż)

Liczebność związku Związek jeden do jeden (1:1) Pracownik używa jednego samochodu służbowego Samochód służbowy jest używany przez jednego pracownika Związek jeden do wiele (1:N) Samochód służbowy jest używany przez wielu pracowników Związek wiele do wiele (N:M) Pracownik używa wielu samochodów służbowych Można określić maksymalną liczebność związku Student może studiować maksymalnie na 2 wydziałach

Uczestnictwo Uczestnictwo dotyczy udziału encji w związku Uczestnictwo jest wymagane, gdy każda instancja encji musi brać udział w związku Uczestnictwo jest opcjonalne, gdy chociaż jedna encja nie musi brać udziału w związku Każdej ocenie musi być przyporządkowany student, który ją otrzymał Mogą istnieć studenci, którzy nie mają jeszcze żadnej oceny Kółko oznacza opcjonalny udział encji w związku (przykłady na następnym slajdzie)

Przykłady notacji związków (notacja Martina) Klient musi posiadać jedno lub wiele kont Konto musi należeć do jednego i tylko jednego klienta Klient może posiadać jedno lub wiele kont Konto musi należeć do jednego i tylko jednego klienta Klient może posiadać jedno lub wiele kont Konto może należeć do jednego klienta Klient musi posiadać jedno konto Konto może należeć do jednego klienta

Prosty diagram związków encji (bez atrybutów) Sprzedaż Klient Towar

Przykład diagramu uzyskanego programem MS Visio

Przykład diagramu uzyskanego programem DBDesigner 4

Przekształcenie diagramu w schemat relacyjnej bazy danych Dla każdej encji tworzona jest tabela Identyfikatory encji stają się kluczami głównymi tabel Atrybuty stają się atrybutami relacji (nagłówkami kolumn tabeli) Związki jeden do wiele realizowane są za pomocą klucza obcego w tabeli po stronie wiele Związek jeden do jeden można zrealizować za pomocą klucza obcego plus ograniczenie UNIQUE po stronie wiele Opcjonalność po stronie wiele można kontrolować dodając lub nie ograniczenie NOT NULL Związek rekurencyjny jeden do wiele przekształca się do tabeli z kluczem obcym odwołującym się do klucza głównego tej samej tabeli

Oprogramowanie CASE Oprogramowanie CASE pozwala na tworzenie diagramów związków encji, które są automatycznie przekształcane w relacyjną bazę danych Oprogramowanie CASE umożliwia też synchronizację bazy danych z diagramem Przykłady: Oracle Designer, Oracle SQL Developer Data Modeler Early Adopter, MS Visio Enterprise Architect, DBDesigner 4 (Open Source), MySQL Workbench, dbWrench,

Tworzenie tabel słownikowych Kiedy wartości pewnego atrybutu należą do pewnego skończonego zbioru, wartości tych nie należy wpisywać ręcznie, ale wybierać z listy wartości zapisanych w tabeli zwanej tabelą słownikową Tabele słownikowe eliminują możliwość popełnienia błędu i usprawniają działanie aplikacji

Dodatkowe warunki integralności Przy pomocy klauzuli NOT NULL można wskazać, do których kolumn zawsze trzeba wpisywać dane, a do których nie Przy pomocy klauzuli CHECK można zapobiec prostym błędom przy wprowadzaniu danych np. zapobiec wpisaniu przyszłej daty urodzenia Przy pomocy klauzuli UNIQUE można wymusić unikalność pewnych atrybutów np. nr PESEL czy NIP, co uniemożliwi wpisane 2 razy jednej osoby do bazy Dodanie do bazy danych wyzwalaczy i procedur wyzwalanych kontrolujących integralność (SQL-3+)

Dodanie indeksów do tabel Dodawanie indeksów przyspiesza wyszukiwanie danych, ale spowalnia ich wprowadzanie Standardowo tworzy się indeksy na kluczach głównych tabel Dodatkowo Jeśli będziemy wyszukiwali klientów po nazwisku należy utworzyć indeks na atrybucie nazwisko Możliwość tworzenia unikalnych indeksów pozwala na dodatkową kontrolę integralności Aby zabezpieczyć się przed dwukrotnym wprowadzeniem do bazy danych klienta o tym samym nazwisku i imieniu należy utworzyć unikalny indeks na tych atrybutach

Administrowanie danymi Administrowanie danymi jest funkcją, związaną z zarządzaniem, planowaniem i dokumentowaniem zasobów danych jakiejś organizacji Kluczową ideą koncepcji administrowania danymi jest spostrzeżenie, że dane, podobnie jak kapitał, kadry itp., powinny być traktowane jako zasoby wymagające zarządzania W wielu organizacjach zgromadzone dane są podstawą ich funkcjonowania

Potrzeba administrowania danymi W tej samej organizacji jest tworzonych wiele aplikacji, które używają różnych definicji tych samych danych Dane przechowywane przez wiele różnych aplikacji są niespójne Osoby podejmujące decyzje w organizacji otrzymują niezgodne między sobą dane pochodzące z różnych źródeł w tej organizacji Osoby podejmujące decyzje otrzymują dane za późno, aby móc je użyć Osoby podejmujące decyzje otrzymują za dużo nieistotnych danych Istnieją braki w zebranych danych Działy w organizacji nie mają jasnego wyobrażenia, po co zbierają pewne dane