Analýza a modelování dat Přednáška 5
Objektově orientované databáze
Relační databáze data uložena v logicky provázaných tabulkách přes cizí klíče výhoda jednoduchost, intuitivnost, naplnění myšlenky oddělení programu a dat nevýhoda data rozdělena do mnoha tabulek zvláště pokud dodržujeme normální formy relací obtížněji se realizují složitější vztahy mezi daty
Relační a objektové databáze neexistují datové typy s vnitřní strukturou komplikovanější vyhledávání v relačních databázích operace přirozené spojení několika tabulek objektový model a objektové databáze představují renesanci síťového modelu
Objektové databáze počátky objektových databází rok 1989 manifest skupiny ALTAIR (později skupina O 2 ): The OO database system manifesto, 1 st Int. Conf. on OO and Deductive DB, Tokyo rok 1990 memorandum Third generation database system manifesto, Memorandum No. UCB/ERL M90/28, University of California, Berkeley
Objektové databáze počátky standardizace: skupina ODMG (Object Data Management Group), www.odbmg.org od r. 2001 se zabývala standardizací OODBS The Object Data Management Standard: ODMG 3.0, r. 2001 definuje ODL, OQL, vnoření (binding) do programovacích jazyků současnost: činnost ODMG převzala v r. 2006 OMG, pracovní skupina Object Database Technology Working Group (ODBT WG)
Objektové databáze objektové SŘBD v r. 1991 13 komerčních OOSŘBD dnes existují pouze v několika desítkách výrobků malý nárůst svět se vydal cestou objektově relačních SŘBD levnější, relační DB jsou zaběhlé, obava ze složitých systémů
IRIS, GemStone Příklady OOSŘBD izolované systémy s vlastními jazyky Ontos, Object Design, Objectivity, Versant Object Technology architektura klient/server, společné platformy - C++, XWindow, UNIX Workstations ITASCA (Orion), O2 podpora verzování, definiční a manipulační jazyk, výpočetní úplnost, evoluce schématu
Gemstone Příklad OOSŘBD vznik: pol. 80. let jako databázové rozšíření SmallTalku produkt firmy GemTalk Systems posl. verze 8.2 z roku 2016 dodržuje standardy CORBA a ODMG CORBA (Common Object Request Broker Architecture) standard pro komunikaci (volání funkcí) v distribuovaném prostředí
EyeDB Příklad OOSŘBD open source OOSŘBD založen na standardu ODMG 3.0
Vlastnosti OODBS 1. Podporuje více kolekcí relační databáze obsahují pouze tabulky objektové databáze podporují: Set MultiSet Bag Dictionary Array List Ordered Collection
Vlastnosti OODBS 2. Rozlišuje třídy objektů a kolekce objektů třída objektů: realizace objektů kolekce objektů: úložiště objektů kolekce může obsahovat i objekty z různých tříd, pokud mají nějaké společné vlastnosti
Vlastnosti OODBS 3. Objekty mají datové složky a metody datová složka může být objekt metody mohou provádět i složitější operace (výpočet dat), nikoliv pouze get_, set_ do metod můžeme rozpustit chování programu v pojetí OODBS se jako atributy označují datové složky i metody
Vlastnosti OODBS 4. Každý objekt má svoji identitu OID (Object Identifier) jednoznačný identifikátor objektu přidělený SŘBD před uživatelem mohou být skryté plní funkci ukazatele na objekt do virtuální paměti v OODBS není potřeba vytvářet klíče
ODL Jazyky v OODBS Object Definition Language popis objektového schématu OQL Object Query Language dotazovací jazyk definice jazyků se objevuje v ODMG 3.0, implementace se mohou lišit dle SŘBD
Úvod do ODL Definice tříd v ODL podobá se definici třídy v C++/Java class <název třídy> { [readonly] attribute <datový typ> <jm atributu>; <definice metod> // komentář };
Definice tříd v ODL class CTENAR { attribute string RC; attribute string jmeno; attribute string prijmeni; attribute Date dat_zapisu; attribute string adresa; };
objekt Datové typy v ODL instance třídy má jednoznačný identifikátor OID obsah se může měnit literál typy: atomický literál kolekce složený literál pole pevné délky
Atomický literál string (řetězec) char (znak) boolean (true nebo false) float (reálné číslo) short (krátké celé číslo) long (dlouhé celé číslo) enum (výčet)
class Kurz { Atomický literál attribute string nazev; attribute enum sekce {1, 2, 3, 4, 5, 6, 7, 8}; }; výčtový datový typ může být specifikován i symbolicky attribute enum sekce {JEDNA, DVA, TRI };
Složené literály skládají se z pevného počtu literálů nebo objektů odpovídají strukturám v jazyce C struct <jméno>{ <datový typ> <jméno elementu>;... };
struct Adresa { string ulice; short cislo; string mesto; char psc[5]; }; Složené literály
Složené literály class CTENAR { attribute string RC; attribute string jmeno; attribute string prijmeni; attribute Date dat_naroz; attribute Adresa adr; };
Kolekce kolekce literálů nebo objektů set množina (neuspořádaná kolekce), bez duplicit bag (batoh) neuspořádaná kolekce s duplicitami list: uspořádaný seznam elementů array: uspořádaná kolekce elementů s danou pozicí (indexem) - velikost pole se dynamicky přizpůsobuje
dictionary Kolekce neuspořádaná kolekce dvojic klíč-hodnota bez duplicit analogie mapy v knihovně STL Definice atributu typu kolekce připomíná instance generických tříd v C++/Javě list <long> set <Date>
Operace (metody) třída může mít definované operace bez parametrů i s parametrem <návratový typ> <název> (); <návratový typ> <název> (<typ parametru> <název parametru>,...); operace mohou vyhazovat výjimky <návratový typ> <název> (<typ parametru> <název parametru>,...) raises (<seznam výjimek>);
Poznámka: Operace (metody) ve striktní verzi ODL se ještě parametry označují jako vstupní, výstupní nebo vstupně-výstupní klíčová slova in, out, inout před datovým typem parametru
Operace class Student { attribute string jmeno; attribute Date datum_nar; // uživatelem definovaný složený atribut attribute Addresa adresa; // operace short vek( ); boolean zapisuje_si(in string kurz, in short semestr); };
Definice asociací asociace - vztahy mezi objekty asociace je termín z UML 1:1, 1:N, M:N v definici třídy je nutné definovat asociaci jako obousměrnou vždy definovat také inverzní asociaci asociace se vztahem (1:N), (M:N) se definují pomocí kolekcí set, list, bag, array
Definice asociací OSŘBD zajišťuje referenční integritu: maže neplatné odkazy vytváří inverzní vztahy vlastní definice asociací klíčová slova relationship, inverse relationship <cíl> <identifikátor> inverse <inverzní_cesta>
Příklad Student jméno dat_nar adresa vek zapisuje_si 0..* má_zapsany si_zapsal 0..* Kurz nazev sekce zapis
Příklad Student jméno dat_nar adresa vek zapisuje_si ma_zapsany { Set } { Set } si_zapsal Kurz nazev sekce zapis kurzy studenti
Příklad class Student (extent studenti) { attribute string jmeno; attribute Date datum_nar; attribute Addresa adresa; }; short vek( ); boolean zapisuje_si(in string kurz, in short semestr); relationship set<kurz> si_zapsal inverse Student::ma_zapsany;
Příklad class Kurz (extent kurzy) { attribute string nazev; attribute enum sekce {1, 2, 3, 4, 5, 6, 7, 8}; }; short zapis( ); relationship set<student> ma_zapsany inverse Kurz::si_zapsal;
Klíče vzhledem k existenci OID není nutné definovat primární klíč klíč lze definovat pomocí klíčového slova key klíčem může být atribut nebo množina atributů hodnota musí být unikátní
Klíče class Student (extent studenti key cislo) { attribute long cislo; attribute string jmeno; attribute Date datum_nar; attribute Addresa adresa; short vek( ); boolean zapisuje_si(in string kurz, in short semestr); relationship set<kurz> si_zapsal inverse Student::ma_zapsany; };
Dědění třída může dědit od jiné třídy (od předka) dědění se specifikuje klíčovým slovem extends nezaměňovat s extent class Student extends Osoba (extent studenti key cislo) { attribute long cislo;
Vytvoření instance Novak Student ( číslo: 1045, jmeno: "Pavel Novák", datum_nar: 02.12.1975, address: {ulice "Dejvická", cislo 523, mesto "Praha 6", psc "16000"} );