Projektowanie systemów informacyjnych - si.pjwstk.edu.pl · Projektowanie systemów...
Transcript of 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
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 ś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.
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 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.
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 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.
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 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.
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 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.
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 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 ...
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. 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.
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 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!
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 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.)
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 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.
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 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).
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 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.
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ą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.
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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 16
Proces projektowania logicznego
PROJEKTOWANIELOGICZNE
wysokiego poziomuNIEZALEŻNE OD TYPU BD
PROJEKTOWANIELOGICZNE
ZALEŻNE OD TYPU BD
Schematpojęciowy
Charakterystykailościowa danych
Opis docelowegomodelu BD
Wymaganiaużytkowe
PROJEKTOWANIELOGICZNE
Schemat logicznydla docelowegomodelu BD
Schematpojęciowy
Opis docelowegomodelu BD
Wymaganiaużytkowe
Schemat logicznydla docelowegomodelu BD
Charakterystykailościowa danych
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. 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..*]
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 18
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:
PracownikIdPracNazwisko
PracujeWPracownikIdPracNazwisko
FirmaIdFirmyNazwa
PracFirmaIdPracIdFirmy
FirmaIdFirmyNazwa
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ó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.
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 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.
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ł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
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
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
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
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
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 25
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
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
Pracownikgodzinowy
Pracowniketatowy
Pracownikna zlecenie
Pracownik nieemerytowany
Pracownikemerytowany
status
płacowystosunek
do emerytury
Płace pracownika
Emeryturapracownika
Pracownik
Płace pracownika
Emerytura pracownika
Specjalizacjewg płac
Specjalizacjewg emerytury
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 27
Jak obejść brak wielo-dziedziczenia:
użycie dziedziczenia i delegacji
Pracownik
Pracownikgodzinowy
Pracowniketatowy
Pracownikna zlecenie
Pracownik nieemerytowany
Pracownikemerytowany
status
płacowystosunek
do emerytury
Emeryturapracownika
Dziedziczenie Delegacja
Pracownik
Emerytura pracownika
Specjalizacjewg płac
Specjalizacjewg emerytury
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 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
Pracownikna zlecenie
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ż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.
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ż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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 31
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).
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 (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
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.
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.
PracownikIdPracNazwisko
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.
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ś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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 35
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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 36
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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 37
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.
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ś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
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 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.
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 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.
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)
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)
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.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 43
Przejście na model relacyjny - przykłady (2)
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
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)
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
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ż)
PRACOWNIKNazwiskoPracDataUrodzPrac
Różnica wkluczach
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)
KLIENTId_KlientaNazwa_Klienta
TOWARId_Towaru Nazwa_Towaru
SPRZEDAWCAId_SprzedawcyNazwa_Sprzedawcy
Ilość_TowaruData_Sprzedaży
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 *
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)
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 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.