projektowanie systemów informacyjnych - si.pjwstk.edu.pl · projektowanie systemów...

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


Dlaczego obiektowość zastępuje model relacyjny?

W modelu relacyjnym odwzorowanie percepcji świata jest ograniczone środkamiimplementacyjnymi. W rezultacie, schemat relacyjny gubi część semantykidanych. 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 świata Model pojęciowy Model struktur danych

... ......

... ... ...

... ... ...

... ... ...

... ......

... ... ...

Dłogofalową tendencją w rozwoju SZBD jest uzyskanie

zgodności pomiędzy tymi modelami.


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 pomocyjęzyków obiektowych takich jak C++ i Java. Uzyskanie niżej wymienionych własnościw tych językach bez wspomagania ze strony SZBD może okazać się nieosiagalnenawet dla bardzo wydajnych i doswiadczonych zespołów programistycznych.


Obiektowość kontra model relacyjny

Model relacyjny przegrał konfrontację z obiektowością w strefie intelektualnej;trwał w tej strefie tylko 10 -15 lat. Nie istnieje użytkowa własność systemówrelacyjnych, 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 dopraktyki. 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. Nowystandard 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ścimitó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.


Garby modelu relacyjnego (1)

Z góry ustalony konstruktor typu danych (relacja), rozszerzany ad hoc przezwytwórców systemów relacyjnych; brak złożonych obiektów. Informacje opojęciach wyróżnialnych i manipulowalnych w rzeczywistości są rozproszone wkrotkach wielu tablic.

Skojarzenie tych informacji następuje w zapytaniach SQL, przez co wzrasta ichzłożoność oraz czas wykonania. Optymalizacja zapytań nie zawsze jestskuteczna.

Brak wyspecjalizowanych środków do realizacji powiązań pomiędzy danymi.

Brak środków do przechowywania danych proceduralnych. Wszelkie informacjewykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych,BLOBy, aktywne reguły,...) są implementowane ad hoc.

Brak środków hermetyzacji i modularyzacji: wykroczenie przeciwko zasadomabstrakcji i oddzielenia implementacji od specyfikacji.


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 doprzetwarzania makroskopowego.

Ubogie możliwości relacyjnych struktur danych powodują znaczne zwiększeniedługości kodu aplikacji. Połączenie SQL z językiem programowania wymagarównież dodatkowego kodu (szacuje się na 30%). Łącznie kod aplikacji (wporównaniu do systemów obiektowych) może zawierać nawet 70%nadmiarowego kodu.

Brak możliwości rozszerzania typów, ignorowanie zasad bezpieczeństwatypologicznego.

Niespójne mechanizmy wartości zerowych, brak wariantów.


Czy model relacyjny był pomyłką ludzkości?

Poglądy są podzielone. Na korzyść tej tezy przemawia fakt, że podstawowymzałożeniem było wykorzystanie matematycznych własności relacji. Od stronysystemów komercyjnych, korzyści z matematyki są iluzją. Po co więc ograniczeniastruktur danych i interfejsów, rzekomo “wymuszone” przez matematykę?

“Relational databases set the commercial data processing industry back at leastten 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 ologicznej niezależności danych: uwolnienie programisty od myślenia nad niskimpoziomie, w kategoriach fizycznej organizacji danych. Jakkolwiek to założeniepojawiło się w czasach przed modelem relacyjnym, dopiero systemy relacyjneuczyniły go powszechnie obowiązujacym faktem.

Tak czy inaczej, pozostaje rzeczywistość, której szybko zmienić się nie da ...


Rzeczywistość ... (1)Dla 90% rzeczywistych projektów systemy relacyjne są wystarczające. Topowoduje zredukowanie zainteresowania systemami czysto obiektowymi.

Łączne światowe inwestycje (komercyjne, akademickie, organizacyjne) w systemyrelacyjnych baz danych są szacowane na ponad 100 miliardów dolarów. Jest małoprawdopodobne, że te inwestycje będą w krótkim czasie powtórzone dla modeli isystemów obiektowych baz danych. Nie oznacza to, że nie mają one szans; raczej, żeich rozwój, osiągnięcie dojrzałości i popularności będzie trwać dłużej niż przypuszcza wielufanó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 modelimplementacyjny, pozostaje jednak otwarte.

Wiele aplikacji potrzebuje tylko warstwy trwałych danych, która w istocie jestukryta przed użytkownikiem. Użytkownik dokonuje operacji na danych poprzezpewien z góry ustalony interfejs, który całkowicie izoluje go od struktury BD.

Niskie nakłady na pielęgnację (maintenance) oprogramowania jest podstawowymwymaganiem biznesu. Model obiektowy umożliwia zmniejszenie tych nakładów.Przejście na model relacyjny powoduje zwiększenie kosztów pielęgnacji kodu.


Rzeczywistość ... (2)

Zdania SQL “wkodowane” do aplikacji obiektowej i operujące bezpośrednio nanazwach relacji i atrybutów są w wielu przypadkach niekorzystne, gdyżzmniejszają możliwości ponownego użycia oraz zmiany schematu. Znacznielepszym rozwiązaniem jest dynamiczny SQL, który odwołuje się do informacjiznajdują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 dozastanych 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ówbazujących na SQL takich jak ODBC i JDBC. Jakkolwiek posiadają one cechyobiektowości (klasy), są to cechy interfejsów użytkownika, a nie wspomaganieodwzorowania modelu obiektowego na schemat relacyjny.Java + relacyjna baza danych + JDBC nie tworzy obiektowej bazy danych!


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 narzutna wydajność. Należy ich unikać, np. poprzez denormalizację lub wykorzystaniedodatkowej wiedzy semantycznej.

Klucze tablic nie powinny mieć znaczenia w dziedzinie przedmiotowej (cojest w poprzek głównej doktrynie modelu relacyjnego). Nawet trywialne zmianyw dziedzinie biznesu mogą podważyć dokonany wcześniej wybór klucza.

Klucze tablic nie powinny być złożone; powinny być jednym atrybutem (copodważa sens dziesiątków prac teoretycznych). Praktyka pokazała, że złożoneklucze (poza relacjami modelującymi związki) są powodem poważnych trudnościwielu projektów. (Ale istnieją też poglądy odwrotne.)


Konieczność odwzorowania modelu obiektowego

na relacyjny

Sprzymierzeńcem wszystkich wdrożonych technologii baz danych, w tymrelacyjnych, jest ogromna bezwładność rynku zastosowań, który niechętniezmienia swoje preferencje ze względu na zainwestowane duże pieniądze i czas.

Klient baz danych nie tylko nie lubi kosztownych zmian; musi mieć takżepewność, że nie pozostanie sam w swojej dziedzinie działalności lub rejoniegeograficznym 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 nawetkilkadziesią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 modelurelacyjnego nastąpił bardzo szybko (Chen, 1976, model encja-związek). Obecnienie istnieje metoda projektowania nie oparta w jakiś sposób o pojęcia obiektowe.


Podejścia do integracji projektu

obiektowego z systemami relacyjnymi

System relacyjny jako back-end, tj. baza implementacyjna. Na czubku systemurelacyjnego budowany jest front-end, tj. zestaw interfejsów do zarządzaniazłożonymi obiektami, klasami, dziedziczeniem, itd. Podejście mające sporoopracowań oraz zaimplementowany co najmniej jeden prototyp (Starburst).Wady: Podejście wymaga budowy nowego systemu; narzuty relacyjnego back-endna czasy wykonania mogą być istotne i trudne do wyeliminowania.

Obiektowe perspektywy nad strukturą relacyjną - możliwość na razie w strefieakademickiej z kilku powodów (aktualizacja perspektyw, wydajność,...).

Odwzorowanie obiektowego projektu na struktury relacyjne. Podejścietradycyjne (znane z modelu encja-związek).Wady: niemożliwość odwzorowania wszystkich detali schematu obiektowego,zniekształcenie semantyki danych, konieczność wprowadzania sztucznych cech doschematu (niektórych atrybutów, itd.). Problemem może być koniecznośćkompromisu pomiędzy zajętością pamięci a czasami dostępu (normalizacja-denormalizacja).


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 przestrzeganiewarstwowości tej

architektury ma istotneznaczenie dla

pielęgnacyjnościoprogramowania.

Nieco trudne jestzbudowanie

uniwersalnego interfejsupomiędzy obiektami

biznesowymi i relacjami.

Zbudowanie tejinfrastruktury może byćbardzo korzystne dla

firmy realizującej wieleprojektów obiektowych.


Obiektowo-relacyjne bazy danych

Ostatnio karierę robi termin „uniwersalny serwer” (universal server), dającymoż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) iwprowadzanie na ich wierzchołku innych własności, w tym obiektowych.

Systemy te powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunkuobiektowości. Liczą na pozycję systemów relacyjnych na rynku i odwołują się doich wiernej klienteli.

Kluczowymi produktami tej technologii są systemy: Informix Universal Server, DB2Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server iinne. Systemy te są wyposażane w atrakcyjne cechy umożliwiające efektywną produkcjęaplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiektyBLOB, CLOB i pliki binarne), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT),metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C, C++,VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice ozmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Stosunektej technologii do projektów czysto obiektowych nie jest do końca jasny.Wydaje się, że mimopostępu, w większości implikują one problemy z odwzorowaniem modelu obiektowego.


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.


Proces projektowania logicznego

PROJEKTOWANIELOGICZNE

wysokiego poziomuNIEZALEŻNE OD TYPU BD


ZALEŻNE OD TYPU BD

Schematpojęciowy

Charakterystykailościowa danych

Opis docelowegomodelu BD

Wymaganiaużytkowe


Schemat logicznydla docelowegomodelu BD

Schematpojęciowy

Opis docelowegomodelu BD

Wymaganiaużytkowe

Schemat logicznydla docelowegomodelu BD

Charakterystykailościowa danych


Sprowadzenie do pierwszej formy normalnej -

odwzorowanie powtarzalnych atrybutów

Tablice relacyjne nie mogą przechowywać wielokrotnych wartości atrybutów. Modelobiektowy (np. w UML) umożliwia zadeklarowanie takich atrybutów. Jest regułą, że takieatrybuty należy odwzorować jako odrębne tablice. Pojawią się także nowe atrybuty.

Pierwsza sytuacja: wartości powtarzalne nie mogą być identyczne.

PracownikIdNazwisko

WyszkolenieIdZawód

PracownikIdNazwiskoWypłata[0..*]

Druga sytuacja: wartości powtarzalne mogą być identyczne. Ten przypadek umożliwiarownież odwzorowanie sytuacji gdy porządek wielokrotnych wartości jest istotny, poprzezwybór dodatkowego klucza (takiego jak NrWypłaty), który ustali ten porządek.

PracownikIdNazwisko

ZarobkiIdNrWypłatyWypłata

PracownikIdNazwiskoZawód[0..*]


Sprowadzenie do pierwszej formy normalnej -

odwzorowanie związków/asocjacjiDla liczności 1:1 można zaimplementować jako jedną tablicę:

PaństwoNazwa

StolicaMiasto

PaństwoNazwaStolica

Dla liczności 1:n można zaimplementować jako dwie tablice:(Atrybuty związku na ogół powodują konieczność zastosowania następnej metody.)

PracownikIdPracNazwisko

FirmaIdFirmyNazwa

PracujeW

PracownikIdPracNazwiskoIdFirmy

FirmaIdFirmyNazwa

Dla liczności m:n należy zaimplementować jako trzy tablice:


PracujeWPracownikIdPracNazwisko

FirmaIdFirmyNazwa

PracFirmaIdPracIdFirmy

FirmaIdFirmyNazwa


Odwzorowanie złożonych obiektów

Podstawowymi metodami jest spłaszczenie ich struktury (zamiana atrybutówzłożonych na proste), usunięcie powtarzalnych atrybutów oraz różne formynormalizacji (2NF, 3NF, 4NF, BCNF).

Po tych zabiegach złożony obiekt jest reprezentowany jako zestaw krotek, często wwielu tablicach.

Informacja o złożonym obiekcie jest utrzymywana w strukturze relacyjnej wpostaci tzw. integralności referencyjnej (referential integrity). Polega ona na tym,że dla każdego klucza obcego (foreign) musi istnieć krotka posiadająca taki samklucz główny (primary). Nie wszystkie systemy relacyjne podtrzymują systemowointegralność referencyjną.

Integralność referencyjna nie jest w stanie odwzorować całej semantyki złożonychobiektó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 dostruktury tablic umożliwiających przechowanie pełnej semantyki złożonychobiektów.


Odwzorowanie metod/operacji

Model relacyjny nie przewiduje specjalnych środków.

Najczęściej są one odwzorowane na poziomie programów aplikacyjnych jakoprocedury napisane w w klasycznych lub obiektowych językach programowania idedykowane do obsługi pewnej tablicy/tablic w relacyjnej bazie danych.

Niekiedy w systemach relacyjnych mogą być odwzorowane w postaci procedur bazdanych (w SQL) lub w postaci aktywnych reguł.

Odwzorowanie polimorfizmu, przesłaniania, dynamicznego wiązania i hermetyzacjijest w zasadzie niemożliwe. Programista może napisać procedurę, która w środkuma przełączenie explicite na różne przypadki specjalizacji klas.


Trzy metody obejścia braku dziedziczenia

Użycie jednej tablicy dla całegodrzewka klas poprzez zsumowaniewszystkich występującychatrybutów i powiązań w tymdrzewie oraz ewentualnie dodaniedodatkowego atrybutu -dyskryminatora wariantu.

Użycie tablic dla każdej klasykonkretnej. Usunięcie klasabstrakcyjnych i przesunięcie ichatrybutów/powiązań do klaskonkretnych.

Użycie tablicy dla każdej klasy.Zamiana generalizacji napowiązania łączące nadklasę zewszystkimi podklasami.

A

CB

A B C dyskr

A

CB

A B A C

A

CB

A

CB


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


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


Rok


Adres

Kwota do zwrotu

Należny podatek


Rok


Id_pitu

Adres

PIT małżeństwa

Id_pitu

Adres męża

Adres żony

PIT

Id_pitu

Kwota do zwrotu

Należny podatek


Rok


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

Prosta

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

Średnia

Małe

Wolny

Duże

Mała


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


Pracownik godzinowy nie emerytowany

Obejście braku wielodziedziczenia

Pracownikstatus

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:

Pracownikgodzinowy

Pracowniketatowy

Pracownikna zlecenie

Pracownik nieemerytowany

Pracownikemerytowany

Pracownik

Specjalizacjewg płac

Specjalizacjewg emerytury


Jak obejść brak wielo-dziedziczenia:

delegacja z użyciem ról

Pracownik

Pracownikgodzinowy

Pracowniketatowy




status

płacowystosunek

do emerytury

Płace pracownika

Emeryturapracownika

Pracownik

Płace pracownika

Emerytura pracownika





użycie dziedziczenia i delegacji

Pracownik

Pracownikgodzinowy

Pracowniketatowy




status

płacowystosunek

do emerytury

Emeryturapracownika

Dziedziczenie Delegacja

Pracownik

Emerytura pracownika





zagnieżdżona generalizacja

Pracownik

status

płacowy

stosunek

do emerytury

Permutacja klasPermutacja klas

stosunek

do emerytury

stosunek

do emerytury

Pracownik godzinowy nieemerytowany

Pracownikgodzinowyemerytowany

Pracownik etatowy nieemerytowany

Pracowniketatowy

emerytowany

Pracownik nazlecenie nieemerytowany

Pracownik nazlecenie

emerytowany

Pracownikgodzinowy

Pracowniketatowy



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żepowodować wąskie gardło w wydajności, wyróżnić tę superklasę poprzezdziedziczenie.

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.


Zależność funkcyjna (functional dependency) pomiędzy atrybutami: wartośćatrybutu A2 zależy od wartości atrybutu A1, jeżeli dla każdego wyobrażalnegostanu 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ęściklucza.

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. Mocniejszywarunek 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ęcianiekorzystnych własności: redundancji w danych oraz zwiazanych z redundancjąanomalii aktualizacyjnych.


Krytyka normalizacjiTemat 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żaniasemantyki danych. Muszą one być zadane a priori przez projektantów, coczęsto jest równie trudne jak przerobienie całego modelu od podstaw.

Jako skutek, metodyki oparte na modelu encja-związek i metodyki obiektowe wnaturalny 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).


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 (outerjoin) dwóch lub więcej tablic:

Nazwisko

KowalskiMalinowskiNowakGrotLeski

IdPrac

3425467323

Pracownicy PrzynależnośćDoZZ

IdPrac

257346

ZwiązekZaw

SolidarnośćOPZZSolidarność

Pracownicy

Nazwisko

KowalskiMalinowskiNowakGrotLeski

IdPrac

3425467323

ZwiązekZaw

NULLSolidarnośćSolidarnośćOPZZNULL


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.

PracownikIdPracNazwiskoNazwiskoPanień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.


MężatkaIdPracNazwiskoPanieńskie

BadanieKrwiIdPracGrupaKrwiDataBadaniaGrKrwi

Brak wartości zerowych, objętośćdanych zmniejszyła się o 40%.

Wydajność może być gorsza zewzględu na złączenia lub lepsza zewzględu na zmianę charakterystykibuforowania krotek.


Analiza długich/złożonych wartości

Podobnie do wartości zerowych i zależności funkcyjnych, analiza długich wartościmoże być również podstawą zdekomponowania tablicy na dwie lub więcej. Tesame metody mogą dotyczyć złożonych atrybutów.

PracownikIdPrac: char[5]Nazwisko: char[20]ZwiązekZawodowy: char[100]

Załóżmy, że w zakładzie pracy działa 10 związkówzawodowych, zaś pracowników jest 1000. Łatwopoliczyć, że rozmiar tablicy będzie 125 000 znaków.Dodatkowo, występuje możliwość drobnych i grubychbłędów w pisowni nazwy związku.

PracownikIdPrac: char[5]Nazwisko: char[20]IdZZ: char[5]

ZwiązekZawodowyIdZZ: char[5]Nazwa: char[100]

Po tym zabiegu rozmiar bazy danychzredukował się 4-krotnie.

Jak poprzednio, wydajność może być gorsza ze względu na złączenia lub lepsza zewzględu na zmianę charakterystyki buforowania krotek.


Podział poziomy klasy

Klasa 2a1

a2

m1

m2

Klasa 1

Klasa 3

As1

As2

Klasa 21a1

a2 ...?

m1

m2 ...?

Klasa 1

Klasa 3

As11

As21

Klasa 22a1 ...?

a2

m1 ...?

m2

As12

As22

Niekiedy przy takim podziale w niektórych klasachmożna zredukować atrybuty i/lub metody.

Na podstawie przewidywanych charakterystyk ilościowych przetwarzania.


Podział pionowy klasy

Klasa 2a1

a2

a3

a4

m1

m2

m3

m4

Klasa 1

Klasa 3

As1

As2

Klasa 2a1

a2

m1

m2

Klasa 1

Klasa 3

As11 ?

As21 ?

Klasa 2a3

a4

m3

m4

As12 ?

As22 ?

Na podstawie przewidywanych charakterystyk ilościowych przetwarzania orazprzewidywanej pielęgnacyjności kodu aplikacji.


Klucze kandydujące

Dla asocjacji: Kombinacja kluczy klas obiektów. 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żekombinacja atrybutów innych klas lub związków, które “przeciąga się” poprzezzwiązki asocjacji.


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średniopoprzez 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średniopoprzez dany klucz

• TYP KLUCZA* klucze proste przed złożonymi* klucze wewnętrzne przed zewnętrznymi* klucze krótsze przed dłuższymi

Pracownik

NazwiskoData_urNr_PESELNr_pracNr_na_wydziale

Wydział

Id_wydziału

1

2

3

4

Nazwisko + Data_ur

Nr_PESEL

Nr_prac

Nr_na_wydziale


Wybór klucza obiektu - zalecenia

Klucz nie powinien mieć znaczenia w dziedzinie przedmiotowej. Istnieje sporoprzykł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 jestuzależnione od przypadkowych zmian tych numerów jak również zmian przypisanianumeró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 nadanyklucz. Staje się ona wąskim gardłem dla transakcji, gdyż transakcja tworząca nowyobiekt musi zablokować tę daną aż do potwierdzenia. Inne transakcje muszączekać, aby nie było możliwości dwukrotnego nadania tego samego klucza. Możeto powodować nieakceptowalne narzuty na czasy wykonania.

Jedno z rozwiązań (S.W.Ambler): klucz mam postać HIGH:LOW. HIGH jestunikalną liczbą, generowaną dla każdej sesji użytkownika na podstawie w/w danej.LOW jest kolejnym numerem obiektu utworzonego wewnątrz tej sesji.


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 TOWARzakupił

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.100030000 + 150 mies.10000 + 50 mies.

50000+200 mies.


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)


Przejście na model relacyjny - przykłady (1)

KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy)

Klient (Id_Klienta, Nazwa_Klienta)KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty)

KlientIdKlientaNazwaKlienta

InfoDostawyAdresDostawy

ma

KlientIdKlientaNazwaKlienta

KartaKredytowaIdKartyTypKartyLimitKarty

posiada

Projektant nie zdecydował się na jednątablicę, gdyż założył, że będzie zbyt dużowartości zerowych.



DataŚlubu

MężczyznaIdMężczyznyNazwiskoMężczyzny

KobietaIdKobietyNazwiskoKobiety

Kobieta( IdKobiety, NazwiskoKobiety )Mężczyzna( IdMężczyzny, NazwiskoMężczyzny )Ślub( IdKobiety, IdMężczyzny, DataŚlubu )

1+ 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)

STUDENTId_Studenta

Nazwisko_Studenta

Suma_Pkt_Studenta

KURSId_Kursu

Nazwa_Kursu

Ocena_semestr

Semestr



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)

MiastoNazwaMiastaLiczbaMieszkM

WojewództwoNazwaWojewództwaWojewodaLiczbaMieszkW

LeżyW

Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM)Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW)

ZAMÓWIENIEId_ZamówData_Zamów

SPRZEDAWCANazwisko_SNr_Tel_S

Upust_w_Zamów



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ż)

PRACOWNIKNazwiskoPracDataUrodzPrac

Różnica wkluczach



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)

KLIENTId_KlientaNazwa_Klienta

TOWARId_Towaru Nazwa_Towaru

SPRZEDAWCAId_SprzedawcyNazwa_Sprzedawcy

Ilość_TowaruData_Sprzedaży



Firma

Nazwa

Miejsce *

Pracownik

Zawód *

Osoba

Nazwisko

Imię *

Adres *

Zatrudnienie

Wypłata *

Ocena *

FZ PZ

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)


Różnice na poziomie kodu w języku zapytań

Zapytanie „Podaj adresy pracowników pracujących w firmach zlokalizowanych wRadomiu”:

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 znacznie dłuższe 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 schematuobiektowego na schemat relacyjny. To skojarzenie, oprócz wymienionej porcjidodatkowego kodu, wymaga od programisty dokładnego rozumienia nieformalnejsemantyki schematu.

Zminimalizowanie złączeń w SQL jest celem denormalizacji.

projektowanie systemów informacyjnych - si.pjwstk.edu.pl · projektowanie systemów...

Documents