Politechnika Śląska, Instytut Informatyki

Politechnika Śląska, Instytut Informatyki
Generacje baz danych • systemy plików (ISAM i VSAM) • systemy hierarchicznych baz danych (ISM, System 2000) • systemy baz danych CODASYL (m.in. IDS, IDMS) • relacyjne bazy danych • obiektowe bazy danych Gliwice 2005

Wady dotychczasowych rozwiązań
• zbyt prosty model danych (szczególnie relacyjny), • proste typy danych (integer, string), • System Zarządzania Bazą Danych nie oferuje mechanizmów do reprezentacji np. związków agregacji i zarządzania nimi, • zbyt wolne działanie systemów baz danych z programami użytkowymi wymagającymi szybkich i skomplikowanych obliczeń (programy symulacyjne), • brak narzędzi do reprezentowania i zarządzania temporalnymi aspektami baz danych (m.in.: pojęciem czasu, wersjami obiektów i schematu).

Wymagania stawiane bazom danych piątej generacji
• zachowanie wszystkich użytecznych cech, charakteryzujących relacyjne bazy danych (zapytania, automatyczna optymalizacja zapytań, sterowanie współbieżnością, ...), • reprezentowanie i posługiwanie się złożonymi, zagnieżdżonymi obiektami, • definiowanie dowolnych typów danych i operowanie nimi, • reprezentowanie i zarządzanie zmianami w bazie danych (wersje obiektów, wersje schematów), • reprezentowanie i operowanie pojęciami hierarchii i agregacji; • zarządzanie długotrwałymi transakcjami.

Obiektowy model danych
Jest modelem danych, którego podstawą są pojęcia obiektowości, m.in.: obiekt, klasa, dziedziczenie, hermetyzacja Prace nad ustandaryzowaniem pojęć obiektowych w dziedzinie baz danych prowadzone są m.in.: przez ODMG (ang. Object Database Management Group). Standard zaproponowany przez ODMG stworzony został w oparciu o trzy istniejące standardy dotyczące: • baz danych (SQL-92), • obiektów (OMG), • obiektowych języków programowania (ANSI).

Podstawowe pojęcia obiektowego modelu danych
reprezentuje sobą konkretny pojedynczy byt (książkę, osobę, samochód), charakteryzowany poprzez opis stanu (atrybuty obiektu) i zachowania tego bytu (metody obiektu) • obiekt • tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja

Podstawowe pojęcia Przykład obiektu Obiekt KONTO Wypłać Wpłać Porównaj
Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł 34567 Właściciel Jan Nowak Upoważniony Ewa Nowak .... Podstawowe pojęcia Obiekt

to taka własność obiektu, która pozwala odróżnić go od każdego innego obiektu • obiekt • tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja zdolność do istnienia obiektów poza czasem działania systemu zarządzania bazą danych

miejsce przechowywania tych informacji dotyczących obiektów (tzw. inwariantami obiektów), które są dla nich niezmienne, wspólne lub dotyczą całej ich populacji • obiekt • tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja miejsce przechowywania (specyfikacji i definicji) takich cech grupy podobnych obiektów, które są dla nich niezmienne: atrybutów, metod, ograniczeń dostępu, dozwolonych operacji na obiektach

(tworzenie nowego obiektu)
Konstrukcja kodu klasy w pseudojęzyku programowania Klasa Pracownik { numer PESEL; tekst(30) Nazwisko; tekst(20) Imię; tekst(30) Stanowisko; Pracownik (numer p, tekst n, tekst i, tekst s) { PESEL = p; Nazwisko = n; Imię = i; Stanowisko = s; } dodaj() { zapisz_na_listę_pracowników();} usuń() {usuń_z _listy_pracowników();} typ rekordu (parametry obiektu) Metody (aktywność obiektu) (tworzenie nowego obiektu) Konstruktor

referencja do tworzonego obiektu
Wywołanie konstruktora – tworzenie jednostkowego wystąpienia danej klasy (czyli obiektu) referencja do tworzonego obiektu konstruktor – generacja jednostkowego wystąpienia klasy – obiektu Pracownik jn = new Pracownik ( , „Nowak”, „Jan”, „lekarz”); (...) Pracownik ak = new Pracownik ( , „Kowalski”, „Adam”, „szef”);

• tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja tworzenie klas na podstawie klas już istniejących

Dziedziczenie – LSP (Liskov's Substitutability Principle)
– zasada zamienialności Zasada zamienialności głosi, że w każdym miejscu programu, gdzie może być użyty pewien obiekt klasy K, może być także użyty obiekt, którego klasą jest podklasa klasy K.

Nazwany zbiór obiektów aktualnie należących do danej klasy
Ekstensja Nazwany zbiór obiektów aktualnie należących do danej klasy

Ekstensja klasy PRACOWNIK
OSOBA Nazwisko Babacki RokUr 1940 Nazwisko Abacki RokUr 1948 Nazwisko Nowak RokUr 1951 Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) Nazwisko Kowalska RokUr 1975 Ekstensja klasy OSOBA Zarobek 2000 Dział zabawki Zarobek 2500 Zarobek 3000 Dział sprzedaż Ekstensja klasy PRACOWNIK Uwaga! Różne ekstensje mogą mieć wspólne części

• tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja zamknięcie pewnego zestawu bytów programistycznych w "kapsułę" (obiekt, klasę moduł, etc.) o dobrze określonych granicach

Hermetyzacja ortogonalna
Dowolna własność obiektu (atrybut, metoda) może być prywatna lub publiczna Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu PRACOWNIK PRACOWNIK NAZWISKO Nowak ROK_UR 1951 NAZWISKO Nowak ZAROBEK 2500 DZIAŁ Zabawki DZIAŁ Zabawki ZarobekNetto() {...}; Podatek(){...}; ZarobekNetto() ZmieńZarobek(...) {...}; ZmieńZarobek(...) Wiek() { return RokBież - ROK_UR }; Wiek()

• tożsamość obiektu • trwałość • klasa (hierarchia klas) • dziedziczenie • hermetyzacja • agregacja związek pomiędzy klasami obiektów, modelujący stosunek całości do jej części

Przykłady - dziedziczenie i agregacja
CAutor PtString msImie PtString msNazwisko CLektura int miNrKlasy; int miCzyObow; CAutor *mAutor; CKsiążka int miISBN; PtString msTytul; double mdCena

Przykłady - hierarchia klas
COsoba msPesel char[12] msImie PtString msNazwisko PtString CAbstrPrac miNrP int mJezyki cset<PtString> CPracownik mdPensja double miEtat tTypEtatu mtDataZatrudnienia PtDate mtDataZwolnienia PtDate CStazysta mdPlaca double mtDataPoczStaz PtDate mtDataKonStaz PtDate CZleceniobiorca mdStawka double

Obiektowa baza danych • Zbiór obiektów, ich stan, zachowanie się i związki występujące między nimi, określone zgodnie z obiektowym modelem danych • Zorientowany obiektowo system, który umożliwia zarządzanie bazą danych • System, który dziedziczy wszystkie zasadnicze cechy technologii obiektowej (istnienie złożonych obiektów, tożsamość obiektów, enkapsulacja danych i procedur, dziedziczenie, funkcje polimorficzne) i baz danych (trwałość danych, oddzielenie logicznego i fizycznego poziomu danych, zarządzanie wielodostępem, odtwarzanie spójnego stanu danych po awariach, zarządzanie transakcjami i in.)

Porównanie relacyjnych i obiektowych baz danych (0)
relacyjne obiektowe przykłady systemów • Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access • GemStone, O2, Persistence, Versant, POET, Objectivity, ODI stan na dzisiaj • Dominuje w zastosowaniach komercyjnych (ok. 95% rynku baz danych) • Mniej popularne, jednak dobrze rokują na przyszłość

relacyjne obiektowe • Obiekt w bazie reprezentuje obiekt w świecie rzeczywistym • Typ obiektowy (klasa) – definicja złożonego typu danych (może zawierać inne typy obiektowe lub ich kolekcje) • Procedury (metody) i operatory do manipulowania danymi • Identity-based • Enkapsulacja • Dziedziczenie: strukturalne potomek dziedziczy strukturę danych behawioralne: potomek dziedziczy metody i operatory • Dane zawarte w tabelach • Tabele składają się z kolumn • Typy predefiniowane • Liczba wierszy zmienna • Value-based • Nie ma wskaźników, lecz klucze zewnętrzne

relacyjne obiektowe z a l e t y • niezależność od języka programowania • sprawdzone, dobrze zdefiniowana teoria • możliwość zarządzania wielka ilością danych • możliwość złożonych kryteriów wyszukiwawczych • możliwość dostępu do danych fizycznych • dobre mechanizmy kontroli dostępu do danych • mechanizmy perspektyw • dość łatwa reprezentacja świata • dokładnie reprezentuje złożone zależności miedzy obiektami • łatwość działania na złożonych obiektach • duża podatność na zmiany • możliwość definiowania własnych typów, metod • dobra integracja z językami programowania ogólnego przeznaczenia (np. C++, Smalltalk) • ujednolicony model pojęciowy - obiektowe podejście do analizy, projektowania i implementacji

relacyjne w a d y obiektowe • dla trudniejszych problemów bardzo dużo tabel • mało naturalna reprezentacja danych • ograniczona podatność na zmiany • brak złożonych typów danych • trudne operowanie na danych złożonych • trudne operowanie na danych rozproszonych w sieci heterogenicznej • niezgodność z modelem używanym przez języki ogólnego przeznaczenia (impedance mismatch) • powiązanie z jednym językiem programowania • słaba obsługa przeszukiwania danych • brak powszechnie zaakceptowanego języka zapytań • brak możliwości optymalizacji zapytań • trudny lub nawet niemożliwy dostęp do fizycznych danych • słaba kontrola dostępu • małe możliwości optymalizacji pracy serwera

relacyjne lepsze gdy ... obiektowe • dane mają złożoną lub zagnieżdżoną strukturę zdefiniowaną przez użytkownika • dane tworzą hierarchie • dane są rozproszone w sieci heterogenicznej • dane dynamicznie zmieniają rozmiar • dane są proste, niezagnieżdżone, łatwe do umieszczenia w tablicy • dane mają postać bierną, a procesy korzystające z danych stale się zmieniają • często trzeba wyszukiwać dane spełniające różnorodne warunki

Języki zapytań do bazy danych pożądane cechy • wysoki poziom – dający możliwość prostego zapisu złożonych operacji • deklaratywność – ukierunkowany na określanie warunków, jakie musi spełniać rezultat wyszukiwania, a nie sposobu poszukiwania • efektywność i optymalizowalność • uniwersalność – dla dowolnego schematu bazy danych • zamkniętość i kompletność – zapewnia to możliwość wykorzystania wyników zapytania jako wejścia do innych zapytań) oraz zapewniający odpowiedniki dla każdego pojęcia rozpatrywanego modelu w zakresie przetwarzania Gliwice 2005

Języki zapytań do OBD pożądane cechy • hermetyzacja • przeciążanie, przesłanianie i późniejsze wiązanie – wiązanie implementacji z wywołaniem metody – odsunięcie decyzji o tym co ma zostać wykonane do czasu uruchomienia • zapytania ad hoc – umożliwienie użytkownikowi komunikacji z bazą danych na wysokim poziomie abstrakcji (SQL) • zarządzanie wersjami • rozszerzalność  na poziomie pojęciowym – możliwość definiowania nowych typów i konstruktorów (oprócz wstępnie zdefiniowanych) specyficznych dla danej aplikacji bez różnicy w obsłudze  na poziomie wewnętrznym – możliwość wprowadzenia do systemu nowych struktur pamięci (np.: do przechowywania danych multimedialnych) Gliwice 2005

Języki zapytań do OBD Co stanowi problem? • brak standardów – ze względu na złożoność struktur występujących w OBD oraz braku formalnego modelu OBD • sprzeczność z zasadą hermetyzacji zakładającą, że wartości danych nie powinny być bezpośrednio dostępne dla użytkownika • wybór punktu wyjścia przy projektowaniu obiektowego języka zapytań Gliwice 2005

SQL - OQL Różnice Politechnika Śląska, Instytut Informatyki SQL OQL Typ rekordu Klasa Krotka (rekord) Obiekt Tabela Kolekcja obiektów Schemat bazy danych Kolekcja klas Gliwice 2005

Składnia OQL • klauzula celu • klauzula zakresu • klauzula kwalifikacji określa atrybuty wyjściowe SELECT służy do wiązania zmiennych obiektowych ze zbiorami instancji klas FROM służy do specyfikacji warunków za pomocą logicznych kombinacji predykatów WHERE Gliwice 2005

Jasmine Etapy formułowania zapytania • zdefiniowanie zmiennej, do której zostanie przypisany wynik zapytania • wykonanie zapytania • wyświetlenie wyników Gliwice 2005

Jasmine Możliwe typy zmiennej • zmienna może reprezentować encję, literał atomowy, klasę, krotkę oraz kolekcje powyższych • typy kolekcji:  Bag – nieuporządkowana kolekcja wartości o zmiennej ilości elementów, dozwolone duplikaty  Set – nieuporządkowana kolekcja wartości o zmiennej ilości elementów, niedozwolone duplikaty  List – uporządkowana kolekcja wartości o zmiennej ilości elementów, dozwolone duplikaty Gliwice 2005

Jasmine Przykłady deklaracji zmiennej Person p; //p – instancja klasy Person lub jej podklasy Bag<Person> pp; //pp- zbiór p String s; //s – łańcuch znaków Bag<String> ss; //ss – zbiór s; Person class PC; //PC – klasa Person lub jej podklasa Bag<Person class> PCS; //PCS- kolekcja PC [Intereger hours, Integer minutes, Real seconds] timestamp; // timestamp – krotka, składająca się z trzech elementów, TS – opcjonalna nazwa klasy krotki Gliwice 2005

Jasmine Przykłady zapytań Bag<Osoba> o; o = Osoba from Osoba; o.print();  Bag<[String i, String n, Integer w]> d_o; d_o = [o.imie, o.nazwisko, o.wiek()] from Osoba o;  Bag<[String i, String n, Integer w]> d_o; d_o = [o.imie, o.nazwisko, o.wiek()] from Osoba o where o.wiek() < 40;  Gliwice 2005

Jasmine Przykłady zapytań - cd Bag<Pracownik> p; p = Pracownik from Pracownik; p.count().print();  p = Pracownik from Pracownik alone; p.count().print();  Bag<[String p1, String p2, String k1, String k2]> pk; pk = [o.imie,o.nazwisko,o.kierownik.imie,o.kierownik.nazwisko] from Osoba o where o.kierownik != NIL;  Gliwice 2005

Jasmine Przykład metody Politechnika Śląska, Instytut Informatyki defaultCF wykCF; addProcedure Integer Osoba::instance:wiek() language: "odql" description:"Zwraca wiek osoby" { Date curr_date; curr_date=Date.getCurrent(); return(curr_date.part(YEAR)-self.data_ur.part(YEAR)) Gliwice 2005

Politechnika Śląska, Instytut Informatyki

Podobne prezentacje

Prezentacja na temat: "Politechnika Śląska, Instytut Informatyki"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Politechnika Śląska, Instytut Informatyki

Podobne prezentacje

Prezentacja na temat: "Politechnika Śląska, Instytut Informatyki"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres