Transcript
Obiektowe Bazy Danych
Paweł Ciach
Plan prezentacji: • Oczekiwania wobec Obiektowych Baz Danych
• Język Obiektowych Baz Danych • Trochę o formalnych ramach struktury i zachowania • Dostępne standardy • Dlaczego Obiektowe Bazy Danych się nie przyjęły
• Alternatywne podejścia do zagadnienia • Bazy semi-strukturalne • Mapowanie R/O • Inne
Oczekiwania wobec OBD W RDBMS brakuje nam:
• Atrybutów złożonych - składowe atrybutów trzeba deklarować indywidualnie jako atrybuty relacji (np. Adres osoby) • Atrybutów zbiorowych - trzeba je reprezentować w innym schemacie relacyjnym (np. Podwładni osoby) • Agregacje i specjalizacje - konieczność posługiwania się indywidualnym schematem relacyjnym ze specjalnymi więzami integralności (np. Pracownik jest Osobą, albo Pracownik ma kierowcę) • Gdy nie ma możliwości dobrania klucza głównego wśród atrybutów, trzeba dokładać klucz sztuczny
• Niezgodność impedancji (Technologiczna i kulturowa)
Oczekiwania wobec OBD Przykład: Chcemy zamodelować przedsiębiorstwo produkujące samochody. Model musi spełniać następujące warunki: • firma ma nazwę, centralę, kilka oddziałów i dyrektora. • oddziały mają nazwę, biuro, kierownika i pracowników.
• pojazdy mają nazwę modelu, kolor i producenta. • samochody mają nadwozie i napęd. Napęd ma silnik i skrzynię biegów. Silnik ma ilość koni i pojemność. • osoby mają nazwisko, wiek, miejsce zamieszkania i prywatny tabor.
• pracownicy to osoby ze specyficznymi kwalifikacjami, wynagrodzeniem i z rodziną.
Oczekiwania wobec OBD Jak to można zamodelować relacyjnie (pomijając pewne elementy): Firma IDFirmy INT NOT NULL Nazwa VARCHAR NOT NULL Ulica VARCHAR NOT NULL Miejscowosc VARCHAR NOT NULL Dyrektor INT NOT NULL PRIMARY KEY (IDFirmy) FOREIGN KEY (Dyrektor) REFERENCES Pracownik (NrPrac)
Oddział IDFirmy INT NOT NULL NazwaOddz VARCHAR NOT NULL Ulica VARCHAR NOT NULL Miejscowosc VARCHAR NOT NULL Kierownik INT NOT NULL PRIMARY KEY (IDFirmy,NazwaOddz) FOREIGN KEY (IDFirmy) REFERENCES Firma FOREIGN KEY (Kierownik) REFERENCES Pracownik (NrPrac)
PracOddz IDFirmy INT NOT NULL NazwaOddz VARCHAR NOT NULL Prac INT NOT NULL PRIMARY KEY (IDFirmy, NazwaOddz, Prac) FOREIGN KEY (IDFirmy) REFERENCES Firma FOREIGN KEY (NazwaOddz) REFERENCES Oddział FOREIGN KEY(Prac) REFERENCES Pracownik (NrPrac)
Osoba NrOsoby INT NOT NULL Nazwisko VARCHAR NOT NULL ... Pracownik NrPrac INT NOT NULL Nazwisko VARCHAR NOT NULL ... FOREIGN KEY (NrPrac) REFERENCES Osoba (NrOsoby)
Oczekiwania wobec OBD Teraz zróbmy na naszym modelu danych zapytanie: Szukamy pracowników o nazwisku Kowalski zatrudnionego w oddziale Gliwice firmy GM: SELECT NrPrac FROM Firma, Oddział, PracOddz, Pracownik WHERE Firma.Nazwa = ‘GM’ AND Firma.IDFirmy = Oddział.IDFirmy AND Oddział.Miejscowość = ‘Gliwice’ AND Oddział.IDFirmy = PracOddz.IDFirmy AND Oddział.NazwaOddz = PracOddz.NazwaOddz
AND PracOddz.Prac = Pracownik.NrPrac AND Pracownik.Nazwisko = ‘Kowalski’;
Oczekiwania wobec OBD A jak można sobie wyobrazić modelowanie tego w OBD - poniżej odpowiednie klasy: Firma: [
Oddział: [
Adres: [
Nazwa : String,
Nazwa : String,
Ulica : String,
Centrala : Adres,
Biuro : Adres,
Miejscowość : String ]
Oddziały: { Oddział },
Kierownik : Pracownik,
Dyrektor: Pracownik ]
Pracownicy : { Pracownik } ]
Osoba: [
Pracownik is-a Osoba: [
Nazwisko : String,
Kwalifikacje: { String }
Wiek : Integer,
Wynagrodzenie : Integer
MiejsceZam : Adres,
Rodzina : { Osoba } ]
Tabor : { Pojazd } ]
Oczekiwania wobec OBD Teraz zróbmy teraz zapytanie na obiektowym modelu zapytanie, używając obiektowej adaptacji SQLa: Znowu szukamy pracowników o nazwisku Kowalski zatrudnionego w oddziale Gliwice firmy GM: select e from e in Pracownik, c in Firma, s in Oddział
where c.Nazwa = ‘GM’ and s in c.Oddziały and s.Biuro.Miejscowość = ‘Gliwice’ and e in s.Pracownicy and e.Nazwisko = ‘Kowalski’;
Oczekiwania wobec OBD To były cechy związane z aspektami strukturalnymi OBD. Ale to jeszcze nie wszystko: Aspekt behawioralny - chcemy mieć to co jest w innych językach obiektowych: • Enkapsulacja - chcemy mieć możliwość tworzenia abstrakcyjnych typów danych. Do klasy można przydzielać metody. Z zewnątrz zachowanie jest widoczne jako zbiór sygnatur. • Przeciążanie, przesłanianie i późne wiązanie Oczywiście, chcemy też mieć to co mamy w RDBMSach: • Trwałość - i rozróżnianie obiektów trwałych i ulotnych,
• Kontrola przy pracy wielu użytkowników (Transakcje powinny być ACID - Atomically, Consistency, Isolated, Durable) - w pewnym stopniu problemem mogą być tutaj metody. • Zarządzanie pamięcią pomocniczą, odtwarzanie
Języki OBD Na kolejnych przykładach będziemy budować podobny do SQL język OBD tak żeby zrozumieć jakie cechy powinien mieć taki język. Proste wybieranie obiektów. OIDs - identyfikatory obiektów (jak referencje) - do wykorzystania w dalszym przetwarzaniu:
select f from f in Pojazd where model = ‘Vectra’; Natomiast wszystkie atrybuty obiektu uzyskamy wykonując: select * from Pojazd where model = ‘Vectra’;
Języki OBD Wyrażenia ścieżkowe. Proste: select * from Pojazd where kolor = ‘zielony’ and Producent.Nazwa = ‘Ford’; Można w klauzuli select: select Dyrektor.Wynagrodzenie from Firma where Centrala.Miejscowosc = ‘Rzym’ W klauzuli where: select * from Firma where Centrala = = Dyrektor.MiejsceZam Uwaga: ‘= = ‘ identyczność obiektów (OIDów), a nie wartości. Jak chcemy porównać miejscowość, to już nie można użyć ‘= = ‘: select * from Firma where Centrala.Miejscowość = Dyrektor.MiejsceZam.Miejscowość; Zmienne w wyrażeniu ścieżkowym: select Tabor[x].Napęd.Silnik.Moc from Pracownik where x in Samochód
Języki OBD Jawne złączanie: select p,f from p in Osoba, f in Pojazd where P.Nazwisko = f.producent.Dyrektor.Nazwisko; Metody:
select a1, a2 from a1 in Pracownik, a2 in Pracownik where a1.Zastępca (a2); select Wiek from Osoba where Nazwisko = ‘Kowalski’
Języki OBD Zbiory obiektów. Odpowiednik perspektyw: MojaRodzina := select p from Osoba where Nazwisko = ‘Kowalski’ select Nazwisko from MojaRodzina where Wiek > 50 Podzapytania: select Nazwa from (select Producent from Pojazd where Kolor = ‘niebieski’) select count(f) from f in Firma where Dyrektor in (select a from a in Pracownik where Wynagrodzenie > 200 000)
Języki OBD Problem: zbiory zbiorów Weźmy: select f.Oddziały.Pracownicy.Wynagrodzenie from f in Firma W wyrażeniu ścieżkowym nie możemy zastosować atrybutu Pracownicy do wyniku f.Oddziały, bo ten ostatni jest zbiorem - powstaje błąd typu. Możliwe obejście - jawne usunięcie zagnieżdżenia za pomocą operatora spłaszczenia: flatten(select flatten ( flatten (f.Oddziały).Pracownicy).Wynagrodzenie from f in Firma)
Języki OBD Dziedziczenie. Nazwisko w Pracownik zostało odziedziczone z Osoba. select Kwalifikacje from Pracownik where Nazwisko = ‘Kowalski’ Szukamy tych osób które mają ponad 50 lat i nie są pracownikami.
select * from p in Osoba where Wiek > 50 and p not in Pracownik
Trochę o formalizmach Mamy schemat struktury (Scstruct) i zachowania (Scbehaw). Opowiem tylko o tym pierwszym. Całość wygląda to mniej więcej tak:
Trochę o formalizmach T - Type, indukcyjnie:
• prymitywy należą do T • Krotka: [A1:t1..An:tn] należy do T o ile Ai to różne atrybuty, i ti należą do T (typ krotkowy) • {t} należy do T jeżeli t należy do T (typ zbiorowy) Values - poprzez dom: • dom(prymityw) - wszystkie możliwe wartości prymitywu • dom([A1:t1..An:tn]) := ([A1:v1..An:vn] gdzie vi należy do dom (ti) • dom({t}) := ({v1..,vn} gdzie vi należy do dom(t))
Trochę o formalizmach Dokładamy klasy - kolejny warunek do Type:
C jest podzbiorem T, gdzie C - skończony podzbiór nazw klas I analogiczne do Values: dom( c ) = OID dla każdego c należącego do C Mamy również hierarchię klas - częściowy porządek IsA na C, z klasą object taką, że dla każdego c należącego do C, c IsA object. Jeżeli c IsA c’, to c jest podklasą, c’ jest nadklasą. Równolegle, definiujemy porządek <= na Type (T), jako najmniejszy częściowy porządek zamknięty ze względu na reguły (any - odpowiednik object): • c IsA c’ => c <= c’ dla c,c’ należących do C • t=[A1:t1..An:tn], t’=[A1’:t1’..Am’:tm’] jeżeli n >= m i dla każdegoAi’:ti’ z t’ istnieje Aj:tj z t gdzie Ai’ = Aj i tj <= ti’, to będzie też t <= t’ • Jeżeli t <= t’ to rwnież {t} <= {t’} • t <= any dla każdego t należącego do T
Trochę o formalizmach Schemat struktury to 3-ka: Scstruct = (C, IsA, type), gdzie C - sk. zb. nazw klas, type:C->T - przypisuje typ klasie.
Schematy strukturalne są dobrze utworzone o ile: C IsA C’ implikuje type(C) <= type(C’) Teraz chcemy zbudować d(Scstruct) odzwierciedlając Scstruct. Obiekt - (o, v), gdzie o to identyfikator z Object, v wartość z Values. Przydzielmy obiekty do klas: Bazowe rozszerzenie: Przypisanie zbioru identyfikatorów obiektów do nazwy klas w C. Jeżeli o należy do inst( c) dla c należącego do C, to c nosi nazwę klasy bazowej dla o.
Rozszerzenie dla odwzorowania inst, to Inst, które przypisuje zbiór identyfikatorów obiektów do nazw klas c należących do C, z uwzględnieniem hierarchii IsA: Inst( c ) = inst ( c ) {o|o inst (c’), c’ C, c’ IsA c} Np. inst(Object) = {}, Inst(Object) = {wszystkie obiekty}
Trochę o formalizmach Teraz możemy zdefiniować sobie d(Scstruct) = (inst, val), gdzie inst jest bazowym rozszerzeniem, a val: Objects->Values, jest odwzorowaniem o własności: o inst( c), c C => val(o) dom (typ( c)) Classes C
type
inst
Objects O
Types T dom
val
Values V
W tym modelu brakuje jeszcze ponownego używania atrybutów w klasach podrzędnych oraz dziedziczenia wartości domyślnych.
Trochę o formalizmach A dlaczego brakuje? Rozważmy klasy Pracownik i Osoba: Pracownik IsA Osoba
type(Osoba) = [ Nazwisko : string, ... ] type(Pracownik) = [Kwalifikacje: {string}, ...] Wydaje się, że jest dobrze - intuicyjnie, Pracownik powinien dziedziczyć atrybuty Osoba, ponieważ Pracownik IsA Osoba. Ale warunek dobrego utworzenia z definicji schematu strukturalnego - c IsA c’ => type( c) <= type (c’) nie jest spełniony - nie jest prawdą, że type(Pracownik) <= type(Osoba) Trzeba jeszcze: • poluzować warunek type( c) <= type (c’) definiując Type (Funkcja typu uwzględniająca dziedziczenie)
• zająć się wartościami domyślnymi (Funkcja Val uwzględniająca wartości domyślne) • na koniec trzeba coś zrobić z konfliktami dziedziczenia - podając definicję schematu wolnego od konfliktów. • No i jeszcze schemat behawioralny...
Standardy OBD Istotne są 2 standardy: • SQL3 - podejście obiektowo-relacyjne. • ODMG-93 - Object Database Management Group (podgrupa OMG)
Ten drugi ma następujące cechy: • Model obiektu wywodzi się z ogólniejszego modelu OMG (wykorzystywany do implementacji CORBA) • Język definiowania obiektów (ODL) oparty o IDL • Język zapytań (OQL) - nie jest oparty o SQL3 • Ma powiązania do obiektowych języków programowania (w szczególności do Smalltalka, C++, Javy).
Obiektowe bazy danych przegrały bo • Relacyjne bazy danych mają potężną reprezentację na rynku. SZBD są rozwiązaniami stabilnymi, przetestowanymi i działającymi od lat. Wydano olbrzymie ilości środków w rozbudowę tych narzędzi - są to w tej chwili jedne z najbardziej skomplikowanych aplikacji. • Firmy produkujące bazy danych zdecydowały na model obiektoworelacyjny. Tak naprawdę (przynajmniej w początkowej fazie) to był tylko marketingowy buzzword - ale z pewnością zniechęciło to sporą grupę osób do obiektowych bazy danych. • Pojawił się model przetwarzania wielowarstwowego. Oferowane przez ODB możliwości przetwarzania po stronie bazy danych straciły sens wobec używania application serverów w celu wykonywania scentralizowanych obliczeń.
Alternatywy Podejście semi-strukturalne. Przykład: LORE • W przeciwieństwie do tradycyjnych modeli danych, gdzie narzuca się sztywny schemat danych, w przypadku baz semi-strukturalnych struktura jest elastyczna, • Reprezentacja danych - etykietowany graf skierowany, • Elastyczne języki zapytań potrafiące obsługiwać nieregularności struktury danych, • Gdy dane są nieregularne, w modelu relacyjnym w takim celu używa się null - brzydkie, nieprzyjemne i niewygodne, w obiektowych bazach dziedziczenie i typy złożone mogą pomóc - ale wciąż może być potrzebna większa elastyczność • Duże wyzwania implementacyjne - np. indeksowanie.
Alternatywy Mapowanie obiektów na relacje. Kwestie do rozwiązania: • W najprostszym przypadku atrybuty klas mapują się na atrybuty tabel. Ale trzeba pamiętać o typach, • Mapowanie metod na atrybuty relacyjne, • Shadow information - wspominany już w kontekście OBD problem sztucznych kluczy głównych • Dziedziczenie - można: • Zmapować całą hierarchię na jedną tabelę • Zmapować wszystkie klasy nie-abstrakcyjne na tabelki • Zmapować wszystkie klasy na tabelki Dobrym pomysłem jest nie robić tego ręcznie, ale użyć automatu takiego jak hibernate.
Alternatywy Dziedzina jest szeroka i atakowana z bardzo wielu miejsc. Technologie/rozwiązania związane z OBD obejmują: • XML - trochę podobny do semi-strukturalnych baz, ale są do dyspozycji potężne narzędzia do definicji schematu - DTD i XML-Schema. Bardzo szeroko wspierany. Istnieją bazy XML-owe - np. Tamino. XML ewoluował z zupełnie innego miejsca niż pozostałe technologie - od SGML, czyli języka stworzonego na potrzeby poligrafii.
• JDO - Java Data Objects - przeźroczysta trwałość obiektów. • Technologie pokroju EJB (warto przyjrzeć się EJB Query Language adaptacji OQL), CORBA, DCOM, Web services - wszystkie dostarczają dodatkową warstwę abstrakcji ukrywając logikę biznesową. W szczególności może oznaczać to obiektową reprezentację bazy danych.
Bibliografia • Lausen Georg, Vossen Gottfried, Obiektowe bazy danych, WNT 2000 • http://www.db.ucsd.edu/cse132B/FormalODB.pdf • http://www.agiledata.org/essays/mappingObjects.html • http:// www.hibernate.org
• http://www-db.stanford.edu/lore • http:// www.w3c.org
