Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki.

Podobne prezentacje


Prezentacja na temat: "K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki."— Zapis prezentacji:

1 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 15 i 16: Od modelu obiektowego do relacyjnej bazy danych

2 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 2 Dlaczego obiektowość zastępuje model relacyjny? W modelu relacyjnym odwzorowanie percepcji świata jest ograniczone środkami implementacyjnymi. W rezultacie, schemat relacyjny gubi część semantyki danych. Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego. Chodzi o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości, a myśleniem o danych i procesach, które zachodzą na danych. Percepcja świataModel pojęciowyModel struktur danych... Dłogofalową tendencją w rozwoju SZBD jest uzyskanie zgodności pomiędzy tymi modelami.

3 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 3 Zalety baz danych Wysoka niezawodność, efektywność i stabilność Bezpieczeństwo i prywatność danych, spójność i integralność przetwarzania Automatyczne sprawadzanie warunków integralności danych Wielodostęp, przetwarzanie transakcji Rozszerzalność (zarówno dodawanie danych jak i dodawanie ich rodzajów) Możliwość geograficznego rozproszenia danych Dostęp poprzez języki zapytań (SQL, OQL) Zintegrowanie z dużą liczbą narzędzi i udogodnień Bazy danych mają bezwględną przewagę nad konstruowaniem aplikacji przy pomocy języków obiektowych takich jak C++ i Java. Uzyskanie niżej wymienionych własności w tych językach bez wspomagania ze strony SZBD może okazać się nieosiagalne nawet dla bardzo wydajnych i doswiadczonych zespołów programistycznych.

4 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 4 Obiektowość kontra model relacyjny Model relacyjny przegrał konfrontację z obiektowością w strefie intelektualnej; trwał w tej strefie tylko lat. Nie istnieje użytkowa własność systemów relacyjnych, która nie mogłaby być zrealizowana w systemach obiektowych. Powstało szereg systemów relacyjnych, dojrzałych technicznie i użytecznych, ale posiadających zasadnicze odstępstwa od założeń modelu relacyjnego. Teorie matematyczne związane z modelem relacyjnym są nieadekwatne do praktyki. Zalety wynikające z matematyzacji dziedziny baz danych okazały się iluzją (nie pierwszą tego typu w informatyce) SQL ma zalety, ale jest językiem tworzonym ad hoc, niesystematycznym, nieregularnym, nieortogonalnym, bez istotnego podkładu teoretycznego. Nowy standard SQL3 jest ogromny, eklektyczny, z dość przypadkowymi pomysłami. Tworzone są ideologie i systemy eklektyczne, obiektowo-relacyjne. Nieregularne, trudne do standardyzacji, dekadenckie. Generowana jest mnogości mitów i fałszywych stereotypów dotyczacych zalet modelu relacyjnego. Twórcy systemów relacyjnych wzmacniają ich interfejsy o pojęcia obiektowe, oraz umożliwiają obiektowe perspektywy relacyjnych struktur danych.

5 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 5 Garby modelu relacyjnego (1) Z góry ustalony konstruktor typu danych (relacja), rozszerzany ad hoc przez wytwórców systemów relacyjnych; brak złożonych obiektów. Informacje o pojęciach wyróżnialnych i manipulowalnych w rzeczywistości są rozproszone w krotkach wielu tablic. Skojarzenie tych informacji następuje w zapytaniach SQL, przez co wzrasta ich złożoność oraz czas wykonania. Optymalizacja zapytań nie zawsze jest skuteczna. Brak wyspecjalizowanych środków do realizacji powiązań pomiędzy danymi. Brak środków do przechowywania danych proceduralnych. Wszelkie informacje wykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych, BLOBy, aktywne reguły,...) są implementowane ad hoc. Brak środków hermetyzacji i modularyzacji: wykroczenie przeciwko zasadom abstrakcji i oddzielenia implementacji od specyfikacji.

6 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 6 Garby modelu relacyjnego (2) Brak uniwersalności środków dostępu do danych, powodujący konieczność zanurzenia ich w uniwersalne języki programowania niższego poziomu; (niezgodność impedancji, impedance mismatch). Niespełnione obietnice co do przetwarzania makroskopowego. Ubogie możliwości relacyjnych struktur danych powodują znaczne zwiększenie długości kodu aplikacji. Połączenie SQL z językiem programowania wymaga również dodatkowego kodu (szacuje się na 30%). Łącznie kod aplikacji (w porównaniu do systemów obiektowych) może zawierać nawet 70% nadmiarowego kodu. Brak możliwości rozszerzania typów, ignorowanie zasad bezpieczeństwa typologicznego. Niespójne mechanizmy wartości zerowych, brak wariantów.

7 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 7 Czy model relacyjny był pomyłką ludzkości? Poglądy są podzielone. Na korzyść tej tezy przemawia fakt, że podstawowym założeniem było wykorzystanie matematycznych własności relacji. Od strony systemów komercyjnych, korzyści z matematyki są iluzją. Po co więc ograniczenia struktur danych i interfejsów, rzekomo wymuszone przez matematykę? Relational databases set the commercial data processing industry back at least ten years. (Dr. Henry G. Baker, Comm. ACM 35/4, 1992) Jest to oczywiście twierdzenie niesprawdzalne. Nie wiadomo jak potoczyłaby się dziedzina baz danych, gdyby nie model relacyjny. Podstawowym wkładem modelu relacyjnego była nie matematyka, a założenie o logicznej niezależności danych: uwolnienie programisty od myślenia nad niskim poziomie, w kategoriach fizycznej organizacji danych. Jakkolwiek to założenie pojawiło się w czasach przed modelem relacyjnym, dopiero systemy relacyjne uczyniły go powszechnie obowiązujacym faktem. Tak czy inaczej, pozostaje rzeczywistość, której szybko zmienić się nie da...

8 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 8 Rzeczywistość... (1) Dla 90% rzeczywistych projektów systemy relacyjne są wystarczające. To powoduje zredukowanie zainteresowania systemami czysto obiektowymi. Łączne światowe inwestycje (komercyjne, akademickie, organizacyjne) w systemy relacyjnych baz danych są szacowane na ponad 100 miliardów dolarów. Jest mało prawdopodobne, że te inwestycje będą w krótkim czasie powtórzone dla modeli i systemów obiektowych baz danych. Nie oznacza to, że nie mają one szans; raczej, że ich rozwój, osiągnięcie dojrzałości i popularności będzie trwać dłużej niż przypuszcza wielu fanów obiektowości. Chyba, że nastąpi skok jakościowy... Nadzieje są związane z systemami obiektowo-relacyjnymi, które wzbogacają systemy relacyjne o pewne cechy obiektowości. Jest to podejście ewolucyjne. Pytanie, czy kiedyś zredukują złożoność odwzorowania modelu pojęciowego na model implementacyjny, pozostaje jednak otwarte. Wiele aplikacji potrzebuje tylko warstwy trwałych danych, która w istocie jest ukryta przed użytkownikiem. Użytkownik dokonuje operacji na danych poprzez pewien z góry ustalony interfejs, który całkowicie izoluje go od struktury BD. Niskie nakłady na pielęgnację ( maintenance ) oprogramowania jest podstawowym wymaganiem biznesu. Model obiektowy umożliwia zmniejszenie tych nakładów. Przejście na model relacyjny powoduje zwiększenie kosztów pielęgnacji kodu.

9 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 9 Rzeczywistość... (2) Zdania SQL wkodowane do aplikacji obiektowej i operujące bezpośrednio na nazwach relacji i atrybutów są w wielu przypadkach niekorzystne, gdyż zmniejszają możliwości ponownego użycia oraz zmiany schematu. Znacznie lepszym rozwiązaniem jest dynamiczny SQL, który odwołuje się do informacji znajdującej się w katalogach. (Jest on jednak nieco wolniejszy.) Automatyczne generatory interfejsów w SQL (takie jak TopLink) mogą okazać się zbyt wolne. Wiele aplikacji obiektowych musi przystosować się do danych spadkowych (legacy data), z reguły relacyjnych. Nie powinno to jednak oznaczać, że (świadomego lub podświadomego) przykrojenia projektu obiektowego do zastanych danych. Raczej, trzeba przeprowadzić reinżynierię w celu stwierdzenia, z jakim modelem obiektowym mamy do czynienia w spadkowej bazie danych. Powszechną pomyłką jest kojarzenie z obiektowymi bazami danych interfejsów bazujących na SQL takich jak ODBC i JDBC. Jakkolwiek posiadają one cechy obiektowości (klasy), są to cechy interfejsów użytkownika, a nie wspomaganie odwzorowania modelu obiektowego na schemat relacyjny. Java + relacyjna baza danych + JDBC nie tworzy obiektowej bazy danych!

10 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 10 Rzeczywistość... (3) Złączenia (joins) są wolne. Mimo sprawnych metod, takich jak hash join, sort&merge join, optymalizacji zapytań, itd, złączenia powodują poważny narzut na wydajność. Należy ich unikać, np. poprzez denormalizację lub wykorzystanie dodatkowej wiedzy semantycznej. Klucze tablic nie powinny mieć znaczenia w dziedzinie przedmiotowej (co jest w poprzek głównej doktrynie modelu relacyjnego). Nawet trywialne zmiany w dziedzinie biznesu mogą podważyć dokonany wcześniej wybór klucza. Klucze tablic nie powinny być złożone; powinny być jednym atrybutem (co podważa sens dziesiątków prac teoretycznych). Praktyka pokazała, że złożone klucze (poza relacjami modelującymi związki) są powodem poważnych trudności wielu projektów. (Ale istnieją też poglądy odwrotne.)

11 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 11 Konieczność odwzorowania modelu obiektowego na relacyjny Sprzymierzeńcem wszystkich wdrożonych technologii baz danych, w tym relacyjnych, jest ogromna bezwładność rynku zastosowań, który niechętnie zmienia swoje preferencje ze względu na zainwestowane duże pieniądze i czas. Klient baz danych nie tylko nie lubi kosztownych zmian; musi mi e ć także pewność, że nie pozostanie sam w swojej dziedzinie działalności lub rejonie geograficznym i może liczyć na zarówno środowisko specjalistów jak i ogólną kulturę techniczną wytworzoną w związku z daną technologią. Systemy relacyjne opanowały dużą grupę nisz ekologicznych i można przyjąć jako pewnik, że pozostaną w nich przez kilka, kilkanaście, lub nawet kilkadziesiąt lat. Systemy obiektowe muszą poszukiwać innych nisz, które nie są zagospodarowane przez wcześniejsze technologie. Natomiast w dziedzinie projektowania baz danych odwrót od modelu relacyjnego nastąpił bardzo szybko (Chen, 1976, model encja-związek). Obecnie nie istnieje metoda projektowania nie oparta w jakiś sposób o pojęcia obiektowe.

12 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 12 Podejścia do integracji projektu obiektowego z systemami relacyjnymi System relacyjny jako back-end, tj. baza implementacyjna. Na czubku systemu relacyjnego budowany jest front-end, tj. zestaw interfejsów do zarządzania złożonymi obiektami, klasami, dziedziczeniem, itd. Podejście mające sporo opracowań oraz zaimplementowany co najmniej jeden prototyp (Starburst). Wady: Podejście wymaga budowy nowego systemu; narzuty relacyjnego back-end na czasy wykonania mogą być istotne i trudne do wyeliminowania. Obiektowe perspektywy nad strukturą relacyjną - możliwość na razie w strefie akademickiej z kilku powodów (aktualizacja perspektyw, wydajność,...). Odwzorowanie obiektowego projektu na struktury relacyjne. Podejście tradycyjne (znane z modelu encja-związek). Wady: niemożliwość odwzorowania wszystkich detali schematu obiektowego, zniekształcenie semantyki danych, konieczność wprowadzania sztucznych cech do schematu (niektórych atrybutów, itd.). Problemem może być konieczność kompromisu pomiędzy zajętością pamięci a czasami dostępu (normalizacja- denormalizacja).

13 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 13 Zalecana infrastruktura projektów obiektowych Graficzny interfejs użytkownika (GUI) Warstwa programów aplikacyjnych C++, Smaltalk, Java Warstwa obiektów biznesowych Warstwa odwzorowania obiektów na relacje SQL System zarządzania relacyjną bazą danych Relacyjna baza danych Ścisłe przestrzeganie warstwowości tej architektury ma istotne znaczenie dla pielęgnacyjności oprogramowania. Nieco trudne jest zbudowanie uniwersalnego interfejsu pomiędzy obiektami biznesowymi i relacjami. Zbudowanie tej infrastruktury może być bardzo korzystne dla firmy realizującej wiele projektów obiektowych.

14 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 14 Obiektowo-relacyjne bazy danych Ostatnio karierę robi termin uniwersalny serwer (universal server), dający możliwość zastosowania systemu do przechowywania i przetwarzania obiektów, relacji, danych multimedialnych, itd. Podstawą ideologiczną systemów obiektowo- relacyjnych jest zachowanie sprawdzonych technologii relacyjnych (np. SQL) i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych. Systemy te powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunku obiektowości. Liczą na pozycję systemów relacyjnych na rynku i odwołują się do ich wiernej klienteli. Kluczowymi produktami tej technologii są systemy: Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne. Systemy te są wyposaża n e w atrakcyjne cechy umożliwiające efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne ( spatial), abstrakcyjne typy danych (ADT), metody (funkcje i procedury) d efiniowane przez użytkownika w różnych językach (C, C++, VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Stosunek tej technologii do projektów czysto obiektowych nie jest do końca jasny.Wydaje się, że mimo postępu, w większości implikują one problemy z odwzorowaniem modelu obiektowego.

15 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 15 Projektowanie logiczne Tradycyjny termin (nie mający związku z logiką matematyczną) oznaczający odwzorowanie modelu pojęciowego (np. encja-związek lub obiektowego) na model lub wyrażenia języka opisu danych konkretnego SZBD. Podstawowe problemy przy przechodzeniu na schemat logiczny: Nie ma możliwości przechowywania wielu wartości jednego atrybutu Każda tablica musi byc wyposażona w unikalny klucz Powiązania muszą być zaimplementowane jako tablice/relacje z kluczami obcymi Nie można zagnieżdżać danych Występują ograniczenia na rozmiar krotek, wartości elementarne i typy danych Brak dziedziczenia i wielodziedziczenia Brak wariantów (natomiast są wartości zerowe) Konieczność istnienia klucza (wartości identyfikującej krotkę) w każdej tablicy. Dodatkowo należy uwzględnić: Cechy ilościowe (charakterystyka ilościowa danych i funkcji) Unikanie redundancji w danych (normalizacja 2NF, 3NF, BCNF). Wymagania użytkowe: czas odpowiedzi, utylizacja pamięci (denormalizacja) Przejście na schemat logiczny nie może być całkowicie automatyczne.

16 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 16 Proces projektowania logicznego PROJEKTOWANIE LOGICZNE wysokiego poziomu NIEZALEŻNE OD TYPU BD PROJEKTOWANIE LOGICZNE ZALEŻNE OD TYPU BD Schemat pojęciowy Charakterystyka ilościowa danych Opis docelowego modelu BD Wymagania użytkowe PROJEKTOWANIE LOGICZNE Schemat logiczny dla docelowego modelu BD Schemat pojęciowy Opis docelowego modelu BD Wymagania użytkowe Schemat logiczny dla docelowego modelu BD Charakterystyka ilościowa danych

17 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 17 Sprowadzenie do pierwszej formy normalnej - odwzorowanie powtarzalnych atrybutów Tablice relacyjne nie mogą przechowywać wielokrotnych wartości atrybutów. Model obiektowy (np. w UML) umożliwia zadeklarowanie takich atrybutów. Jest regułą, że takie atrybuty należy odwzorować jako odrębne tablice. Pojawią się także nowe atrybuty. Pierwsza sytuacja: wartości powtarzalne nie mogą być identyczne. Pracownik Id Nazwisko Wyszkolenie Id Zawód Pracownik Id Nazwisko Wypłata[0..*] Druga sytuacja: wartości powtarzalne mogą być identyczne. Ten przypadek umożliwia rownież odwzorowanie sytuacji gdy porządek wielokrotnych wartości jest istotny, poprzez wybór dodatkowego klucza (takiego jak NrWypłaty), który ustali ten porządek. Pracownik Id Nazwisko Zarobki Id NrWypłaty Wypłata Pracownik Id Nazwisko Zawód[0..*]

18 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 18 Sprowadzenie do pierwszej formy normalnej - odwzorowanie związków/asocjacji Dla liczności 1:1 można zaimplementować jako jedną tablicę: Państwo Nazwa Stolica Miasto Państwo Nazwa Stolica Dla liczności 1:n można zaimplementować jako dwie tablice: (Atrybuty związku na ogół powodują konieczność zastosowania następnej metody.) Pracownik IdPrac Nazwisko Firma IdFirmy Nazwa PracujeW Pracownik IdPrac Nazwisko IdFirmy Firma IdFirmy Nazwa Dla liczności m:n należy zaimplementować jako trzy tablice: Pracownik IdPrac Nazwisko PracujeW Pracownik IdPrac Nazwisko Firma IdFirmy Nazwa PracFirma IdPrac IdFirmy Firma IdFirmy Nazwa

19 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 19 Odwzorowanie złożonych obiektów Podstawowymi metodami jest spłaszczenie ich struktury (zamiana atrybutów złożonych na proste), usunięcie powtarzalnych atrybutów oraz różne formy normalizacji (2NF, 3NF, 4NF, BCNF). Po tych zabiegach złożony obiekt jest reprezentowany jako zestaw krotek, często w wielu tablicach. Informacja o złożonym obiekcie jest utrzymywana w strukturze relacyjnej w postaci tzw. integralności referencyjnej (referential integrity). Polega ona na tym, że dla każdego klucza obcego (foreign) musi istnieć krotka posiadająca taki sam klucz główny (primary). Nie wszystkie systemy relacyjne podtrzymują systemowo integralność referencyjną. Integralność referencyjna nie jest w stanie odwzorować całej semantyki złożonych obiektów. Np. zgubiona jest informacja, co jest korzeniem obiektu, zgubione są reguły hermetyzacji obiektu, zgubiona jest semantyka operacji na obiektach, np. semantyka usuwania. Istnieją propozycje wprowadzenia dodatkowej informacji do struktury tablic umożliwiających przechowanie pełnej semantyki złożonych obiektów.

20 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 20 Odwzorowanie metod/operacji Model relacyjny nie przewiduje specjalnych środków. Najczęściej są one odwzorowane na poziomie programów aplikacyjnych jako procedury napisane w w klasycznych lub obiektowych językach programowania i dedykowane do obsługi pewnej tablicy/tablic w relacyjnej bazie danych. Niekiedy w systemach relacyjnych mogą być odwzorowane w postaci procedur baz danych (w SQL) lub w postaci aktywnych reguł. Odwzorowanie polimorfizmu, przesłaniania, dynamicznego wiązania i hermetyzacji jest w zasadzie niemożliwe. Programista może napisać procedurę, która w środku ma przełączenie explicite na różne przypadki specjalizacji klas.

21 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 21 Trzy metody obejścia braku dziedziczenia Użycie jednej tablicy dla całego drzewka klas poprzez zsumowanie wszystkich występujących atrybutów i powiązań w tym drzewie oraz ewentualnie dodanie dodatkowego atrybutu - dyskryminatora wariantu. Użycie tablic dla każdej klasy konkretnej. Usunięcie klas abstrakcyjnych i przesunięcie ich atrybutów/powiązań do klas konkretnych. Użycie tablicy dla każdej klasy. Zamiana generalizacji na powiązania łączące nadklasę ze wszystkimi podklasami. A CB A B C dyskr A CB A BA C A CB A CB

22 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 22 Przykład obejścia braku dziedziczenia PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedyncz podatnika Adres PIT małżeństwa Adres męża Adres żony PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Adres Adres męża Adres żony Rodzaj PIT dodatkowe pole PIT małżeństwa Adres męża Adres żony Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedyncz podatnika Adres Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedyncz podatnika Id_pitu Adres PIT małżeństwa Id_pitu Adres męża Adres żony PIT Id_pitu Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok

23 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 23 Zalety i wady metod obejścia braku dziedziczenia Cecha Łatwość implementacji Łatwość dostępu do danych Łatwość przypisania OID Związanie informacji Szybkość dostępu Wspomaganie dla polimorfizmu Konsumpcja pamięci Jedna tablica dla hierarchii Prosta Bardzo duże Bardzo szybki Słabe Duża Tablica dla klasy konkretnej Średnia Prosta Średnia Duże Szybki Średnie Mała Tablica dla każdej klasy Trudna Średnia Małe Wolny Duże Mała

24 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 24 Prowadzenie słownika danych Jest konieczne dla przechowania informacji o sposobie odwzorowania modelu obiektowego na strukturę relacyjną. Co powinien zawierać wiersz takiego słownika? Nazwę odwzorowywanej klasy Nazwę odwzorowanego atrybutu tej klasy Nazwę kolumny, w którą taki atrybut jest odwzorowany Nazwę tablicy, która zawiera tę kolumnę. Niekiedy potrzebna jest także następująca informacja: Nazwę bazy danych, w którą odwzorowany jest dany fragment modelu Wskazanie, czy dany atrybut jest używany jako klucz główny Wskazanie, czy dany atrybut jest używany jako klucz obcy

25 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 25 Pracownik godzinowy nie emerytowany Obejście braku wielodziedziczenia Pracownik status płacowy stosunek do emerytury Specjalizacje klasy zależą od aspektu Jest często konieczne, ale psuje strukturę logiczną modelu i komplikuje pielęgnację oprogramowania. Może odbyć się na poziomie modelu obiektowego. Można też bezpośrednio zastosować metody zaproponowane dla obejścia braku dziedziczenia. Przykład: Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Pracownik nie emerytowany Pracownik emerytowany Pracownik Specjalizacje wg płac Specjalizacje wg emerytury

26 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 26 Jak obejść brak wielo-dziedziczenia: delegacja z użyciem ról Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Pracownik nie emerytowany Pracownik emerytowany status płacowy stosunek do emerytury Płace pracownika Emerytura pracownika Pracownik Płace pracownika Emerytura pracownika Specjalizacje wg płac Specjalizacje wg emerytury

27 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 27 Jak obejść brak wielo-dziedziczenia: użycie dziedziczenia i delegacji Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Pracownik nie emerytowany Pracownik emerytowany status płacowy stosunek do emerytury Emerytura pracownika DziedziczenieDelegacja Pracownik Emerytura pracownika Specjalizacje wg płac Specjalizacje wg emerytury

28 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 28 Jak obejść brak wielo-dziedziczenia: zagnieżdżona generalizacja Pracownik status płacowy stosunek do emerytury Permutacja klas stosunek do emerytury stosunek do emerytury Pracownik godzinowy nie emerytowany Pracownik godzinowy emerytowany Pracownik etatowy nie emerytowany Pracownik etatowy emerytowany Pracownik na zlecenie nie emerytowany Pracownik na zlecenie emerytowany Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie

29 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 29 Brak wielo-dziedziczenia - zalecenia Jeżeli klasa ma kilka super-klas, wszystkie jednakowo ważne, najlepiej użyć delegacji, która zachowuje symetrię modelu. Jeżeli jedna super-klasa wyraźnie dominuje, zaś inne są mniej ważne, tę jedną zaimplementować poprzez dziedziczenie, zaś pozostałe przez delegację. Jeżeli liczba kombinacji klas jest mała, można rozpatrywać zagnieżdżoną generalizację. Jeżeli jedna superklasa ma zdecydowanie więcej cech niż pozostałe lub może powodować wąskie gardło w wydajności, wyróżnić tę superklasę poprzez dziedziczenie. Przy zagnieżdżonej generalizacji, najważniejszy czynnik powinien być pierwszym kryterium podziału; pozostałe dalej, w hierarchii ważności. Unikać zagnieżdżonych generalizacji, jeżeli duża ilość kodu musi być powtórzona. Te zalecenia mogą okazać się nieistotne o ile zdecydujemy się bezpośrednio obejść brak wielodziedziczenia metodami takimi samymi jak dla obejścia dziedziczenia.

30 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 30 Zależność funkcyjna (functional dependency) pomiędzy atrybutami: wartość atrybutu A2 zależy od wartości atrybutu A1, jeżeli dla każdego wyobrażalnego stanu bazy danych, dla każdej wartości atrybutu A2 można przyporządkować dokładnie jedna wartość atrybutu A1; A2 = f(A1) Każdy atrybut jest funkcyjnie zależny od klucza. Druga forma normalna (2NF): nie ma atrybutów, które zależą funkcyjnie od części klucza. Trzecia forma normalna (3NF): nie ma zależności funkcyjnych tranzytywnych, tj.nie ma różnych atrybutów A1, A2, A3 takich, że A3 = f(A2) i A2 = f(A1). BCNF - każdy determinant (argument funkcji) jest kluczem kandydującym. Mocniejszy warunek od 3NF, nie zawsze realizowalny. Inne formy normalne - znaczenie marginalne. Normalizacja - 2NF, 3NF, BCNF,... Polega na zdekomponowaniu tablic na dwie lub więcej celem uniknięcia niekorzystnych własności: redundancji w danych oraz zwiazanych z redundancją anomalii aktualizacyjnych.

31 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 31 Krytyka normalizacji Temat jest zdecydowanie przegrzany przez teoretyków baz danych (niewspółmierna złożoność teorii w stosunku do użyteczności). Głównym jej zastosowaniem jest zamulanie podręczników dla studentów. Praktyczna przydatność normalizacji jest znikoma. Dlaczego? Wbrew wczesnym opiniom, teoria normalizacji nie może być samodzielną metodą projektowania, ponieważ przykrywa nikłą część aspektów projektu. Może być niekiedy przydatna jako pomocnicze narzędzie do jego walidacji. Zależności funkcyjne są bardzo mętną (nieczytelną) formą wyrażania semantyki danych. Muszą one być zadane a priori przez projektantów, co często jest równie trudne jak przerobienie całego modelu od podstaw. Jako skutek, metodyki oparte na modelu encja-związek i metodyki obiektowe w naturalny sposób prowadzą do znormalizowanych schematów. Podejście top-down oraz tendencja do dekompozycji/separowania pojęć również w naturalny sposób prowadzą do znormalizowanych schematów. Czynniki inne niż zależności funkcyjne mogą okazać się bardziej istotne (wydajność --> denormalizacja).

32 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 32 Denormalizacja Odwrotność normalizacji: połączenie dwóch lub więcej tablic relacyjnych w jedną. Denormalizacja jest konsekwencją dwóch problemów: - niskiej efektywności operacji złączenia - zbytniego skomplikowania struktury relacyjnej bazy danych utrudniajacej pielęgnację oprogramowania. Z reguły, denormalizacja polega na wykonaniu zewnętrznego złączenia (outer join) dwóch lub więcej tablic: Nazwisko Kowalski Malinowski Nowak Grot Leski IdPrac PracownicyPrzynależnośćDoZZ IdPrac ZwiązekZaw Solidarność OPZZ Solidarność Pracownicy Nazwisko Kowalski Malinowski Nowak Grot Leski IdPrac ZwiązekZaw NULL Solidarność OPZZ NULL

33 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 33 Analiza wartości zerowych Analiza ta, podobnie do zależności funkcjonalnych, może nam przynieść informację o konieczności zdekomponowania tablicy na dwie lub więcej. Pracownik IdPrac Nazwisko NazwiskoPanieńskie[0..1] GrupaKrwi[0..1] DataBadaniaGrKrwi[0..1] Zapełnione w 25% przypadków Zapełnione w 10% przypadków } To rozwiązanie implikuje, że ok. połowy BD będzie zapełnione wartościami zerowymi. Pracownik IdPrac Nazwisko Mężatka IdPrac NazwiskoPanieńskie BadanieKrwi IdPrac GrupaKrwi DataBadaniaGrKrwi Brak wartości zerowych, objętość danych zmniejszyła się o 40%. Wydajność może być gorsza ze względu na złączenia lub lepsza ze względu na zmianę charakterystyki buforowania krotek.

34 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 34 Analiza długich/złożonych wartości Podobnie do wartości zerowych i zależności funkcyjnych, analiza długich wartości może być również podstawą zdekomponowania tablicy na dwie lub więcej. Te same metody mogą dotyczyć złożonych atrybutów. Pracownik IdPrac: char[5] Nazwisko: char[20] ZwiązekZawodowy: char[100] Załóżmy, że w zakładzie pracy działa 10 związków zawodowych, zaś pracowników jest Łatwo policzyć, że rozmiar tablicy będzie znaków. Dodatkowo, występuje możliwość drobnych i grubych błędów w pisowni nazwy związku. Pracownik IdPrac: char[5] Nazwisko: char[20] IdZZ: char[5] ZwiązekZawodowy IdZZ: char[5] Nazwa: char[100] Po tym zabiegu rozmiar bazy danych zredukował się 4-krotnie. Jak poprzednio, wydajność może być gorsza ze względu na złączenia lub lepsza ze względu na zmianę charakterystyki buforowania krotek.

35 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 35 Podział poziomy klasy Klasa 2 a1 a2 m1 m2 Klasa 1 Klasa 3 As1 As2 Klasa 21 a1 a2...? m1 m2...? Klasa 1 Klasa 3 As11 As21 Klasa 22 a1...? a2 m1...? m2 As12 As22 Niekiedy przy takim podziale w niektórych klasach można zredukować atrybuty i/lub metody. Na podstawie przewidywanych charakterystyk ilościowych przetwarzania.

36 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 36 Podział pionowy klasy Klasa 2 a1 a2 a3 a4 m1 m2 m3 m4 Klasa 1 Klasa 3 As1 As2 Klasa 2 a1 a2 m1 m2 Klasa 1 Klasa 3 As11 ? As21 ? Klasa 2 a3 a4 m3 m4 As12 ? As22 ? Na podstawie przewidywanych charakterystyk ilościowych przetwarzania oraz przewidywanej pielęgnacyjności kodu aplikacji.

37 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 37 Klucze kandydujące Dla asocjacji: Kombinacja kluczy klas obiektów. Firma Osoba PosiadaAkcje Klucz kandydujący: (Osoba + Firma) Firma Osoba PracujeW Klucz kandydujący: (Osoba) Miasto Kraj Stolica Klucze kandydujące: (Kraj) lub (Miasto) Dla każdej klasy trzeba rozpatrzyć atrybut (lub ich kombinację), które mogą być kluczem. Jeżeli takich atrybutów nie ma, wówczas należy powołać klucz sztuczny (generowany automatycznie OID). Migracja kluczy: kluczem kandydującym klasy lub związku może być także kombinacja atrybutów innych klas lub związków, które przeciąga się poprzez związki asocjacji.

38 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 38 Wybór klucza Może być wiele kluczy kandydujących ale tylko jeden klucz główny Kryteria wyboru klucza głównego: LICZBA OPERACJI, korzystających z danej klasy, odwołujących się bezpośrednio poprzez dany klucz TYP KLUCZA * klucze proste przed złożonymi * klucze wewnętrzne przed zewnętrznymi * klucze krótsze przed dłuższymi Może być wiele kluczy kandydujących ale tylko jeden klucz główny Kryteria wyboru klucza głównego: LICZBA OPERACJI, korzystających z danej klasy, odwołujących się bezpośrednio poprzez dany klucz TYP KLUCZA * klucze proste przed złożonymi * klucze wewnętrzne przed zewnętrznymi * klucze krótsze przed dłuższymi Pracownik Nazwisko Data_ur Nr_PESEL Nr_prac Nr_na_wydziale Wydział Id_wydziału Nazwisko + Data_ur Nr_PESEL Nr_prac Nr_na_wydziale

39 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 39 Wybór klucza obiektu - zalecenia Klucz nie powinien mieć znaczenia w dziedzinie przedmiotowej. Istnieje sporo przykładów wskazujących na to, że (poza nielicznymi przypadkami, np. PESEL) klucz mający znaczenie semantyczne powoduje niekorzystne efekty. Np. jeżeli kluczem jest nr telefonu osoby, wówczas funkcjonowanie systemu jest uzależnione od przypadkowych zmian tych numerów jak również zmian przypisania numerów do osób. Podobnie np. dla kombinacji Nazwisko, Imię, RokUrodzenia, ImięOjca. W większości, klucz powinien być generowany automatycznie. Problemem może okazać się dostęp do danej przechowującej ostatnio nadany klucz. Staje się ona wąskim gardłem dla transakcji, gdyż transakcja tworząca nowy obiekt musi zablokować tę daną aż do potwierdzenia. Inne transakcje muszą czekać, aby nie było możliwości dwukrotnego nadania tego samego klucza. Może to powodować nieakceptowalne narzuty na czasy wykonania. Jedno z rozwiązań (S.W.Ambler): klucz mam postać HIGH:LOW. HIGH jest unikalną liczbą, generowaną dla każdej sesji użytkownika na podstawie w/w danej. LOW jest kolejnym numerem obiektu utworzonego wewnątrz tej sesji.

40 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 40 Charakterystyka ilościowa danych INFORMACJE OPISUJĄCE DANE: ZAJĘTOŚĆ PAMIĘCI (liczba wystąpień danych) ZMIENNOŚĆ (spodziewany przyrost w czasie) INFORMACJE OPISUJĄCE DANE: ZAJĘTOŚĆ PAMIĘCI (liczba wystąpień danych) ZMIENNOŚĆ (spodziewany przyrost w czasie) KLIENT TOWAR zakupił Charakterystyki ilościowe pozwalają określić własności fizyczne struktury danych. Istnieje sporo zaleceń i analiz pozwalających wykorzystać te własności. śr.50śr mies mies mies.

41 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 41 Charakterystyka ilościowa procesów INFORMACJE OPISUJĄCE PROCESY: OPERACJE ELEMENTARNE (FUNKCJE UŻYTKOWE) TYP (on-line, batch) CZĘSTOTLIWOŚĆ ZACHODZENIA (ew. dodatkowo rozkład w czasie) FORMA (ręczna, automatyczna) SPOSÓB WYZWALANIA (warunki - zdarzenia - wyzwalacze) DOSTĘP DO ELEMENTÓW MODELU DANYCH (Tablica krzyżowa, związek ze schematami nawigacji w strukturze danych) INFORMACJE OPISUJĄCE PROCESY: OPERACJE ELEMENTARNE (FUNKCJE UŻYTKOWE) TYP (on-line, batch) CZĘSTOTLIWOŚĆ ZACHODZENIA (ew. dodatkowo rozkład w czasie) FORMA (ręczna, automatyczna) SPOSÓB WYZWALANIA (warunki - zdarzenia - wyzwalacze) DOSTĘP DO ELEMENTÓW MODELU DANYCH (Tablica krzyżowa, związek ze schematami nawigacji w strukturze danych)

42 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 42 Przejście na model relacyjny - przykłady (1) KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy) Klient (Id_Klienta, Nazwa_Klienta) KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty) Klient IdKlienta NazwaKlienta InfoDostawy AdresDostawy ma Klient IdKlienta NazwaKlienta KartaKredytowa IdKarty TypKarty LimitKarty posiada Projektant nie zdecydował się na jedną tablicę, gdyż założył, że będzie zbyt dużo wartości zerowych.

43 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 43 Przejście na model relacyjny - przykłady (2) DataŚlubu Mężczyzna IdMężczyzny NazwiskoMężczyzny Kobieta IdKobiety NazwiskoKobiety Kobieta( IdKobiety, NazwiskoKobiety ) Mężczyzna( IdMężczyzny, NazwiskoMężczyzny ) Ślub( IdKobiety, IdMężczyzny, DataŚlubu ) 1+ STUDENT (Id_Studenta, Nazwisko_Studenta, Suma_Pkt_Studenta) KURS (Id_Kursu, Nazwa_Kursu) STUDENT_ZAPISANY_NA_KURSY (Id_Studenta, Id_Kursu, Semestr, Ocena_semestr) STUDENT Id_Studenta Nazwisko_Studenta Suma_Pkt_Studenta KURS Id_Kursu Nazwa_Kursu Ocena_semestr Semestr

44 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 44 Przejście na model relacyjny - przykłady (3) SPRZEDAWCA(Nazwisko_S, Nr_Tel_S) ZAMÓWIENIE (Id_Zamów, Data_Zamów) NAPISANE_ZAMÓWIENIA (Id_Zamów, Nazwisko_S, Upust_w_Zamów) Miasto NazwaMiasta LiczbaMieszkM Województwo NazwaWojewództwa Wojewoda LiczbaMieszkW LeżyW Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM) Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW) ZAMÓWIENIE Id_Zamów Data_Zamów SPRZEDAWCA Nazwisko_S Nr_Tel_S Upust_w_Zamów

45 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 45 Przejście na model relacyjny - przykłady (4) podległość jest_podwładnymjest_przełożonym M:N PRACOWNIK (NazwiskoPrac, DataUrodzPrac) PODLEGŁOŚĆ (NazwiskoPracPrzełoż, NazwiskoPracPodwład) 1:N PRACOWNIK (NazwiskoPrac, DataUrodzPrac) PODLEGŁOŚĆ(NazwiskoPracPodwład, NazwiskoPracPrzełoż) 1:1 PRACOWNIK (NazwiskoPrac, DataUrodzPrac, NazwiskoPracPrzełoż) PRACOWNIK NazwiskoPrac DataUrodzPrac Różnica w kluczach

46 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 46 Przejście na model relacyjny - przykłady (5) sprzedaż KLIENT (Id_Klienta, Nazwa_Klienta) TOWAR (Id_Towaru, Nazwa_Towaru) SPRZEDAWCA (Id_Sprzedwcy, Nazwa_Sprzedawcy) SPRZEDAŻ (Id_Klienta, Id_Sprzedawcy, Id_Towaru, Data_Sprzedaży, Ilość_Towaru) KLIENT Id_Klienta Nazwa_Klienta TOWAR Id_Towaru Nazwa_Towaru SPRZEDAWCA Id_Sprzedawcy Nazwa_Sprzedawcy Ilość_Towaru Data_Sprzedaży

47 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 47 Przejście na model relacyjny - przykłady (6) Firma Nazwa Miejsce * Pracownik Zawód* Osoba Nazwisko Imię * Adres * Zatrudnienie Wypłata * Ocena * FZPZ Firma (NrF, Nazwa) Lokal (NrF,Miejsce) Zatrudnienie (NrF,NrP) Pracownik (NrP,NrOs) Osoba (NrOs, Nazwisko) Wyszkolenie ( Zawód,NrP) Dochód (NrDochodu,Wypłata,NrF, NrP) Imiona (NrOs,Imię) Adresy (NrOs,Adres) Oceny (NrOceny, Ocena,NrF,NrP)

48 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 48 Różnice na poziomie kodu w języku zapytań Zapytanie Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu: OQL: select p.Adres from Firma as f, f.FZ.PZ as p where Radom in f.Miejsce SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = Radom and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs Zapytanie w SQL jest znacz nie dłużs ze od zapytania w OQL głównie wskutek tego, że pojawiły się w nim złączeniowe predykaty (takie jak k.NrF=z.NrF i następne ), które kojarzą informację semantyczną zgubioną podczas odwzorowania schematu obiektowego na schemat relacyjny. To skojarzenie, oprócz wymienionej porcji dodatkowego kodu, wymaga od programisty dokładnego rozumienia nieformalnej semantyki schematu. Zminimalizowanie złączeń w SQL jest celem denormalizacji.


Pobierz ppt "K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki."

Podobne prezentacje


Reklamy Google