Projektowanie bazy danych Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Możliwości projektowe Relacyjna baza danych Obiektowa baza danych Relacyjno-obiektowa baza danych Inne rozwiązanie (np. XML) Oracle IBM Microsoft MySQL inne Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Cel projektowy UML UML SQL Klasy Tabele Kwerendy atrybuty operacje relacje pola klucze relacje Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Strategia postępowania model klas  struktura danych struktura danych  model klas struktura danych działająca model klas dopasowywany do możliwości bazy danych brak odniesienia do potrzeb specyfikacja wymagań na nowo interpretowana (podwójna praca) niepewna jakość!!! model klas jest sprawdzony i poprawny struktura bazy danych może być optymalizowana do potrzeb jakość pod kontrolą Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Problemy do rozwiązania Identyfikacja klas wymagających przechowywania w bazie danych Odwzorowanie klas trwałych w tabele i kwerendy Identyfikacja instancji Realizacja mechanizmu dziedziczenia w systemie relacyjnej bazy danych Ograniczenia związane ze standardowymi typami danych Realizacja złożonych typów danych Realizacja agregacji i asocjacji Optymalizacja dostępu tabel Realizacja operacji klas Stworzenie fizycznej struktury bazy danych Zapewnienie spójności danych w związku ze zmianami projektowymi Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Identyfikacja klas trwałych Klasa trwała jest to klasa obiektów, o których informacje muszą być przechowywane pomiędzy kolejnymi sesjami. Nie każda klasa trwała jest przechowywana w bazie danych (np. log systemowy). Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Odwzorowanie klas trwałych w tabele i kwerendy Klient + Nazwisko: string + Imię: string + Adres: Adres «list» Klienci «table» Klienci «storage» ID {PK} Nazwisko: VARCHAR Imię: VARCHAR Adres: ... Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Identyfikacja instancji (1) Instancje pamięci operacyjnej są identyfikowane przez adres – może się zmienić po przechowaniu w bazie danych i ponownym załadowaniu do pamięci. Wniosek – trzeba zapewnić inny, unikalny identyfikator. Identyfikatory oparte o pozornie unikalne dane, jak np. numer PESEL, mogą być zawodne. Identyfikator cyfrowy – 32 bitowy zapewnia 4 mld różnych encji, lecz jest unikalny tylko wtedy, gdy jest nadawany przez jeden serwer. Identyfikator cyfrowy 16-bajtowy jest zawsze unikalny (GUID), lecz nie jest typem standardowym SQL. Klasa modelowa musi przechowywać identyfikator w pamięci. Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Identyfikacja instancji (2) Klient «table» KlienciTbl # ID: INT + Nazwisko: string + Imię: string + Adres: Adres «storage» ID: INT {PK} Nazwisko: VARCHAR Imię: VARCHAR Adres: ... Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Rozwiązanie problemu dziedziczenia (1) Każda hierarchia klas zajmuje jedną tabelę, która przechowuje wszystkie atrybuty z całej hierarchii. Klient «table» KlienciTbl «storage» #ID +Adres ID Nazwisko Imię Nazwa Adres Osoba Firma +Nazwisko +Imię +Nazwa Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Rozwiązanie problemu dziedziczenia (2) Każda klasa w hierarchii ma własną tabelę, w której przechowuje własne atrybuty, również dziedziczone. Klasa, która nie tworzy instancji nie jest przechowywana «table» Firmy Klient +Adres ID {PK} Nazwa Adres «storage» «table» Osoby Osoba Firma ID {PK} Nazwisko Imię Adres #ID +Nazwisko +Imię #ID +Nazwa «storage» Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Rozwiązanie problemu dziedziczenia (3) Każda klasa w hierarchii ma własną tabelę, w której przechowuje tylko własne atrybuty, nie dziedziczone. Tabela nadrzędna ma relacje do tabel pochodnych. «table» Klienci Klient «storage» «table» Firmy #ID +Adres ID {PK} Adres ID {FK} Nazwa «storage» «table» Osoby Osoba Firma ID {FK} Nazwisko Imię +Nazwisko +Imię +Nazwa «storage» Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Problemy z typami danych Typy standardowe Typy niestandardowe Typy numeryczne INTEGER (INT), SMALLINT NUMERIC (P, S), DECIMAL (P, S) FLOAT (P), REAL, DOUBLE PRECISION Typy znakowe CHAR (n), VARCHAR, NATIONAL CHAR (n), NATIONAL VARCHAR VARCHAR2 Typy daty i czasu DATE, TIME, DATETIME, TIMESTAMP INTERVAL Int64 Wide String Extended Real Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Realizacja typu wyliczanego «enum» Status «table» Status «storage» nieznany w-realizacji zrealizowany ID: INT Nazwa: VARCHAR Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Atrybuty złożone Atrybuty złożonych typów danych mogą być spłaszczane Klient «storage» «table» Klienci # ID: INT + Nazwisko: string + Imię: string + Adres: Adres ID: INT {PK} Nazwisko: VARCHAR Imię: VARCHAR Adres_Kod:VARCHAR Adres_Miejscowość: ... Adres_Nr: VARCHAR Adres + Kod: string + Miejscowość: string + Ulica: string + Nr: string Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Atrybuty wielokrotne Atrybuty wielokrotne są realizowane jako osobne tabele Klient «storage» «table» Klienci # ID: INT + Nazwisko: string + Imię: string + Tel[*]: string ID: INT {PK} Nazwisko: VARCHAR Imię: VARCHAR «table» NrTel ID: INT {FK} Nr: VARCHAR Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Agregacje i asocjacje Asocjacje wiele-wiele, wielostronne i asocjacje z własnymi atrybutami są realizowane przez osobne tablice. Pozostałe asocjacje i agregacje są realizowane jako relacje 1-1 i 1-wiele. Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Optymalizacja dostępu do tabel Definiowanie indeksów drugorzędnych «table» Klienci ID: INT {PK} Nazwisko: VARCHAR {FK, NotNull} Imię: VARCHAR {FK,NotNull} Adres_Kod:VARCHAR Adres_Miejscowość: VARCHAR {FK} Adres_Nr: VARCHAR NIP: VARCHAR {FK} «PK» Primary_Key () «FK» Nazwisko_i_Imię () «FK» Miejscowość () «FK» NIP () {Unique, NotNull} Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Operacje klas Realizowane w klasach modelowych Realizowane w procedurach SQL «append» «update» «delete» Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Stworzenie fizycznej struktury danych CREATE TABLE tbl_Klient ( ID INT NOT NULL, Nazwisko VARCHAR NOT NULL, Imie VARCHAR NOT NULL PRIMARY KEY (ID) ); Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Zmiany projektowe Instrukcja SQL ALTER TABLE Z typu wyliczanego nie można usuwać elementów. Zwracać uwagę na zmianie zakresu i precyzji danych przy zmianie typów. Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych

Projektowanie bazy danych Literatura Dennis A., Haley Wixom B., Tegarden D.: System Analysis & Design. An Object-Oriented Approach with UML, John Wiley & Sons, Inc., USA 2001 Geoffrey Sparks: Database Modeling in UML, http://www.techonline.com/community/tech_topic/uml Coad P., Yourdon E.: Projektowanie obiektowe, Read Me, Warszawa 1994 Celko J.,: SQL. Zaawansowane techniki programowania, MIKOM 1999 Dokumentacja i Jakość Oprogramowania Projektowanie bazy danych