Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Projektowanie bazy danych

Podobne prezentacje


Prezentacja na temat: "Projektowanie bazy danych"— Zapis prezentacji:

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

2 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

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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

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

15 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

16 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

17 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

18 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

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

20 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

21 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

22 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, 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


Pobierz ppt "Projektowanie bazy danych"

Podobne prezentacje


Reklamy Google