Wyklad 15 i 16 (PDF, 493K, 48 slajdow, 24 stron)

Transkrypt

Projektowanie systemów informacyjnych
Wykład 15 i 16:
Od modelu obiektowego
do relacyjnej bazy danych
Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1
Dlaczego obiektowość zastępuje model relacyjny?
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
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.
Dłogofalową tendencją w rozwoju SZBD jest uzyskanie
zgodności pomiędzy tymi modelami.
Zalety baz danych
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.
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ń
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ó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.
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.
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.
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 ...
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.
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!
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.)
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 mieć 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.
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 (normalizacjadenormalizacja).
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.
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 obiektoworelacyjnych 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żane 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) definiowane 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.
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
Schemat
pojęciowy
Charakterystyka
ilościowa danych
Charakterystyka
ilościowa danych
Opis docelowego
modelu BD
PROJEKTOWANIE
LOGICZNE
wysokiego poziomu
NIEZALEŻNE OD TYPU BD
Wymagania
użytkowe
Schemat
pojęciowy
PROJEKTOWANIE
LOGICZNE
Opis docelowego
modelu BD
Wymagania
użytkowe
Schemat logiczny
dla docelowego
modelu BD
PROJEKTOWANIE
LOGICZNE
ZALEŻNE OD TYPU BD
Schemat logiczny
dla docelowego
modelu BD
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
Zawód[0..*]
Pracownik
Id
Nazwisko
Wyszkolenie
Id
Zawód
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
Wypłata[0..*]
Zarobki
Id
NrWypłaty
Wypłata
Pracownik
Id
Nazwisko
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
PracujeW
Firma
IdFirmy
Nazwa
Pracownik
IdPrac
Nazwisko
IdFirmy
Firma
IdFirmy
Nazwa
Dla liczności m:n należy zaimplementować jako trzy tablice:
Pracownik PracujeW
IdPrac
Nazwisko
Firma
IdFirmy
Nazwa
Pracownik
IdPrac
Nazwisko
PracFirma
IdPrac
IdFirmy
Firma
IdFirmy
Nazwa
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.
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.
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.
A
A B C dyskr
B
C
A
AB
B
Użycie tablicy dla każdej klasy.
Zamiana generalizacji na
powiązania łączące nadklasę ze
wszystkimi podklasami.
C
A
A
B
AC
C
B
C
Przykład obejścia braku dziedziczenia
PIT
Kwota do zwrotu
Należny podatek
Podstawa opodatkowania
Rok
PIT pojedyncz podatnika
Adres
dodatkowe
pole
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
Adres
Kwota do zwrotu
Należny podatek
Rok
PIT małżeństwa
Adres męża
Adres żony
Kwota do zwrotu
Należny podatek
Rok
PIT
Id_pitu
Kwota do zwrotu
Należny podatek
Rok
Id_pitu
Adres
PIT małżeństwa
Id_pitu
Adres męża
Adres żony
Zalety i wady metod obejścia braku dziedziczenia
Cecha
Jedna tablica Tablica dla klasy Tablica dla każdej
dla hierarchii
konkretnej
klasy
Łatwość implementacji
Prosta
Średnia
Trudna
Łatwość dostępu do danych
Prosta
Prosta
Średnia
Łatwość przypisania OID
Prosta
Średnia
Średnia
Bardzo duże
Duże
Małe
Bardzo szybki
Szybki
Wolny
Wspomaganie dla polimorfizmu
Słabe
Średnie
Duże
Konsumpcja pamięci
Duża
Mała
Mała
Związanie informacji
Szybkość dostępu
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
Obejście braku wielodziedziczenia
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.
Specjalizacje klasy zależą od aspektu
Przykład:
Pracownik
stosunek
do emerytury
status
płacowy
Pracownik
godzinowy
Pracownik
etatowy
Pracownik
na zlecenie
Pracownik nie
emerytowany
Pracownik
emerytowany
Pracownik godzinowy nie emerytowany
Pracownik
Specjalizacje
wg płac
Specjalizacje
wg emerytury
Jak obejść brak wielo-dziedziczenia:
delegacja z użyciem ról
Pracownik
Płace
pracownika
Emerytura
pracownika
status
płacowy
Pracownik
godzinowy
Pracownik
etatowy
stosunek
do emerytury
Pracownik
na zlecenie
Pracownik nie
emerytowany
Pracownik
Płace
pracownika
Emerytura
pracownika
Specjalizacje
wg płac
Specjalizacje
wg emerytury
Pracownik
emerytowany
użycie dziedziczenia i delegacji
Dziedziczenie
Delegacja
Pracownik
Emerytura
pracownika
status
płacowy
Pracownik
godzinowy
Pracownik
etatowy
stosunek
do emerytury
Pracownik
na zlecenie
Pracownik nie
emerytowany
Pracownik
emerytowany
Pracownik
Emerytura
pracownika
Specjalizacje
wg emerytury
Specjalizacje
wg płac
zagnieżdżona generalizacja
Permutacja
Permutacjaklas
klas
Pracownik
status
płacowy
Pracownik
godzinowy
Pracownik
etatowy
stosunek
do emerytury
Pracownik
godzinowy nie
emerytowany
Pracownik
godzinowy
emerytowany
Pracownik
na zlecenie
stosunek
do emerytury
Pracownik
etatowy nie
emerytowany
Pracownik
etatowy
emerytowany
stosunek
do emerytury
Pracownik na
zlecenie nie
emerytowany
Pracownik na
zlecenie
emerytowany
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.
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.
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.
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).
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:
Pracownicy
PrzynależnośćDoZZ
Pracownicy
IdPrac
34
25
46
73
23
IdPrac
25
73
46
IdPrac
34
25
46
73
23
Nazwisko
Kowalski
Malinowski
Nowak
Grot
Leski
ZwiązekZaw
Solidarność
OPZZ
Solidarność
Nazwisko
Kowalski
Malinowski
Nowak
Grot
Leski
ZwiązekZaw
NULL
Solidarność
Solidarność
OPZZ
NULL
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
Brak wartości zerowych, objętość
danych zmniejszyła się o 40%.
BadanieKrwi
IdPrac
GrupaKrwi
DataBadaniaGrKrwi
Wydajność może być gorsza ze
względu na złączenia lub lepsza ze
względu na zmianę charakterystyki
buforowania krotek.
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]
Pracownik
IdPrac: char[5]
Nazwisko: char[20]
IdZZ: char[5]
Załóżmy, że w zakładzie pracy działa 10 związków
zawodowych, zaś pracowników jest 1000. Łatwo
policzyć, że rozmiar tablicy będzie 125 000 znaków.
Dodatkowo, występuje możliwość drobnych i grubych
błędów w pisowni nazwy związku.
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.
Podział poziomy klasy
Na podstawie przewidywanych charakterystyk ilościowych przetwarzania.
Klasa 1
Klasa 1
As1
As11
As12
Klasa 2
a1
a2
m1
m2
Klasa 21
a1
a2 ...?
m1
m2 ...?
Klasa 22
a1 ...?
a2
m1 ...?
m2
As2
As21
As22
Klasa 3
Klasa 3
Niekiedy przy takim podziale w niektórych klasach
można zredukować atrybuty i/lub metody.
Podział pionowy klasy
Na podstawie przewidywanych charakterystyk ilościowych przetwarzania oraz
przewidywanej pielęgnacyjności kodu aplikacji.
Klasa 1
Klasa 1
As1
Klasa 2
a1
a2
a3
a4
m1
m2
m3
m4
As2
Klasa 3
As12 ?
As11 ?
Klasa 2
a1
a2
m1
m2
Klasa 2
a3
a4
m3
m4
As22 ?
As21 ?
Klasa 3
Klucze kandydujące
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.
Dla
Dlaasocjacji:
asocjacji:Kombinacja
Kombinacjakluczy
kluczyklas
klasobiektów.
obiektów.
Osoba
Osoba
PosiadaAkcje
Stolica
PracujeW
Firma
Klucz kandydujący:
(Osoba + Firma)
Kraj
Firma
Miasto
Klucz kandydujący:
(Osoba)
Klucze kandydujące:
(Kraj) lub (Miasto)
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
Pracownik
Nazwisko
Data_ur
Nr_PESEL
Nr_prac
Nr_na_wydziale
Wydział
Id_wydziału
1
Nazwisko + Data_ur
2
Nr_PESEL
3
Nr_prac
4
Nr_na_wydziale
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.
Charakterystyka ilościowa danych
INFORMACJE OPISUJĄCE DANE:
• ZAJĘTOŚĆ PAMIĘCI (liczba wystąpień danych)
• ZMIENNOŚĆ (spodziewany przyrost w czasie)
KLIENT
zakupił
śr.1000
50000+200 mies.
10000 + 50 mies.
śr.50
TOWAR
30000 + 150 mies.
Charakterystyki ilościowe pozwalają określić własności fizyczne struktury danych.
Istnieje sporo zaleceń i analiz pozwalających wykorzystać te własności.
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)
Przejście na model relacyjny - przykłady (1)
Klient
IdKlienta
NazwaKlienta
ma
InfoDostawy
AdresDostawy
KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy)
Klient
IdKlienta
NazwaKlienta
posiada
KartaKredytowa
IdKarty
TypKarty
LimitKarty
Klient (Id_Klienta, Nazwa_Klienta)
KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty)
Projektant nie zdecydował się na jedną
tablicę, gdyż założył, że będzie zbyt dużo
wartości zerowych.
Kobieta
IdKobiety
NazwiskoKobiety
Mężczyzna
IdMężczyzny
NazwiskoMężczyzny
DataŚlubu
Kobieta( IdKobiety, NazwiskoKobiety )
Mężczyzna( IdMężczyzny, NazwiskoMężczyzny )
Ślub( IdKobiety, IdMężczyzny, DataŚlubu )
STUDENT
1+
1+
Id_Studenta
Nazwisko_Studenta
Suma_Pkt_Studenta
KURS
Id_Kursu
Nazwa_Kursu
Ocena_semestr
Semestr
STUDENT (Id_Studenta, Nazwisko_Studenta, Suma_Pkt_Studenta)
KURS (Id_Kursu, Nazwa_Kursu)
STUDENT_ZAPISANY_NA_KURSY (Id_Studenta, Id_Kursu, Semestr, Ocena_semestr)
Miasto
NazwaMiasta
LiczbaMieszkM
LeżyW
Województwo
NazwaWojewództwa
Wojewoda
LiczbaMieszkW
Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM)
Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW)
SPRZEDAWCA
Nazwisko_S
Nr_Tel_S
ZAMÓWIENIE
Id_Zamów
Data_Zamów
Upust_w_Zamów
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)
PRACOWNIK
NazwiskoPrac
DataUrodzPrac
jest_przełożonym
jest_podwładnym
podległość
M:N
PRACOWNIK (NazwiskoPrac, DataUrodzPrac)
PODLEGŁOŚĆ (NazwiskoPracPrzełoż, NazwiskoPracPodwład)
1:N
PRACOWNIK (NazwiskoPrac, DataUrodzPrac)
PODLEGŁOŚĆ(NazwiskoPracPodwład, NazwiskoPracPrzełoż)
Różnica w
kluczach
1:1
PRACOWNIK (NazwiskoPrac, DataUrodzPrac, NazwiskoPracPrzełoż)
TOWAR
Id_Towaru
Nazwa_Towaru
KLIENT
Id_Klienta
Nazwa_Klienta
sprzedaż
SPRZEDAWCA
Id_Sprzedawcy
Nazwa_Sprzedawcy
Ilość_Towaru
Data_Sprzedaży
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)
Firma
Nazwa
Miejsce *
FZ
Zatrudnienie
Wypłata *
Ocena *
PZ
Osoba
Nazwisko
Imię *
Adres *
Pracownik
Zawód *
Firma( NrF, Nazwa)
Lokal( NrF, Miejsce)
Zatrudnienie( NrF, NrP)
Pracownik( NrP, NrOs)
Oceny( NrOceny, Ocena, NrF, NrP)
Dochód( NrDochodu, Wypłata, NrF, NrP)
Osoba( NrOs, Nazwisko)
Wyszkolenie( Zawód, NrP)
Imiona( NrOs, Imię)
Adresy( NrOs, Adres)
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 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 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.

Wyklad 15 i 16 (PDF, 493K, 48 slajdow, 24 stron)

Transkrypt

Podobne dokumenty

Kliknij aby pobrać dokument w formacie PDF

Folia stretch czarna 1,5 kg

ISO-CONNECT VARIO XD, ISO-CONNECT VARIO XD Wiśniowa

folia pryzmatyczna

Folia stretch - halinex.com.pl

FOLIA DO SZYB BLACK 50X300 CM

folia kablowa