Objektově relační model

RMD – zhodnocení modelu Objektové paradigma OR model dat

Vladimíra Zádová, KIN, EF TUL

PDS

Objektově relační model Klasifikace DBMS zdroj: Stonebraker M., 1996 Schopnost vyhledaní, podpora víceuživatel. služeb

R DBMS

OR DBMS

Souborové systémy

OO DBMS

Složitost dat, rozšiřitelnost

• • • •

Souborové systémy - jednoduchá data, nemají požadavky na dotazy nad daty (Word) OO DBMS - zpracovávají složitá data, nemají významné požadavky na vyhledávání (CAD…) RDBMS - jednoduchá data, komplexní požadavky na dotazy ORDBMS komplexní data, komplexní požadavky na dotazy Vladimíra Zádová, KIN, EF TUL

PDS

1

Silné stránky RDBM • silný teoretický základ • teorie podporovaná vývojem SQL - je standardní jazyk pro definici a manipulaci dat v relační databázi • jednoduchost a vhodnost pro OLTP • podpora nezávislosti dat


PDS

Slabé stránky RDBM (1) slabá reprezentace reálných entit – normalizace vede k tomu, že relace nekorespondují s entitami reálného světa – fragmentace reálných entit do mnoha relací • při dotazování dochází k mnoha spojením

(2) semantic overloading (semantické zahlcení) – relace je jediný konstrukt - pro reprezentaci dat i vztahů • nemá mechanismus pro odlišení entit a vztahů • pro reprezentaci vztahu (binárního) s kardinalitou M:N vytváří 3 relace , 1 je vztahová


PDS

2

Slabé stránky RDBM (3) slabá podpora integrity a omezení (enterprise contraints) – týká se validity a konzistence uložených dat • (typy omezení - doménová, entitní a referenční integrita) • mnoho komerčních systémů nepodporuje plně , pak je nutné vystavět je v aplikacích -může vést k duplikaci i nekonzistenci


PDS

Slabé stránky RDBM (4) homogenní datová struktura – RMD předpokládá horizontální i vertikální homogenitu • horizontální homogenita - každý řádek musí být komponován ze stejných atributů • vertikální homogenita - hodnoty atributů (sloupců) relace musí být ze stejných domén • průnik řádku a sloupce musí být atomická hodnota ( atribut je atomický)

– pevná struktura je příliš omezující pro reálné objekty – př. Letadlo - není vnořování částí, subčástí… požadavek komplexního objektu - kontejner – v mnoha RDBM nyní umožněno vkládání BLOB (Binary Large Object) Vladimíra Zádová, KIN, EF TUL

PDS

3

Slabé stránky RDBM • BLOB – obsahuje binární datovou reprezentaci -obraz, video nebo audio sekvence, rozsáhlé nestrukturované objekty – BLOB nemůže obsahovat jiný BLOB » není složený objekt (composite object) » DBMS nezná jeho obsah nebo jeho interní strukturu » to zabraňuje provádění dotazů dovnitř, na jeho obsah Př.: obrázek je uložen jako BLOB v RDBM - ale může být jen uložen a zobrazen, nelze manipulovat s jeho vnitřní strukturou


PDS

Slabé stránky RDBM (5) omezení operací – má pouze pevnou množinu operací - množinové operace, operace s řádky - nelze rozšířit – to je omezující model chování pro objekty reálného světa

(6) obtížná manipulace s rekurzivními otázkami – př. relace : R{c-zam, c- ved} kde c- zam je uvedeno číslo zaměstnance a c-ved -číslo jeho bezprostředního nadřízeného (vyplněno pro všechny zaměstnance) • chci znát všechny vedoucí zaměstnance - přímé a nepřímé


PDS

4

Slabé stránky RDBM (7) Impedance mismatch (neshoda ) = vnoření SQL do procedurálního jazyka - dvou odlišných paradigmat (deklarativního, neprocedurálního a procedurálního jazyka )

– potíže • SQL poskytuje typy “navíc” DATE a INTERVAL - třeba konverze ( asi 30 % programátor. kapacity ) • při užití dvou různých typů systémů není možná automatická kontrola aplikace jako celku

– důvod: • SQL -92 postrádá výpočení úplnost – neobsahuje příkazy typu IF-THEN -ELSE , DO WHILE, FOR CASE – ty musí být implementovány prg. – embedded SQL - umožňuje uplatnit SQL příkazy v procedurálním jazyce Vladimíra Zádová, KIN, EF TUL

PDS

Slabé stránky RDBM • Nevhodnost pro dlouhotrvající transakce • transakce v obchodních procesech jsou zpravidla krátké, paralelní řízení dlouhých není vhodné • obtížnost změny schémat


PDS

5

Objektovost ORMD


• • • •

PDS

Třída/objekt x typ entity/entita Zapouzdření Dědičnost Polymorfismus

• Identifikace objektu – OID • Způsob komunikace mezi objekty, vztah mezi objekty Vladimíra Zádová, KIN, EF TUL

PDS

6

Objektové paradigma - zapozdřenost zapouzdřenost ( encapsulation) je uzavřenost objektu vůči okolí zapouzdření vede k logickému chování objektů a konzistenci stavů – v objektu obsažené atributy a metody jsou vůči sobě viditelné – metody vykonávají činnost nad atributy objektu – část atributů a metod je soukromá, z vnějšku neviditelná a nepřístupná – metody objektu jsou jedinou možností jak pracovat s vnitřními atributy objektu • zasíláním zpráv , které vyvolají metody objektu.


PDS

Objektové paradigma - dědičnost a polymorfismus • dědičnost je uplatnění generalizace • třídy mohou vytvářet hierarchie (jednu i více) – třída nižší úrovně (potomek) dědí všechny vlastnosti třídy vyšší úrovně (rodiče) – zděděné vlastnosti (data i metody) • lze doplnit speciálními ( u metod i dat) • či je nahradit (metody)


PDS

7

Objektové paradigma - dědění - rozšíření – podtřída je rozšířením nadtřídy, pokud obsahuje další metody, které nemají stejné rozhraní jako metody nadtřídy při dědění metod může nastat, že objekty mohou reagovat na tutéž zprávu různě: – zpráva vyvolává metodu se stejným názvem a parametry ale může být v dané třídě (podtřídě) implementována různě - tato vlastnost se nazývá polymorfismus, je nejčastěji realizována zastíněním


PDS

vztahy mezi třídami a objekty • link je instancí asociace, asociace je abstrakcí linku • asociace – je vztah mezi třídami (binární, n-ární vztah) – je skupina linků se společnou strukturou a společnou semantikou • link – je spojení mezi objekty, objekty po kterém může být předána zpráva – vysílající objekt prostřednictvím zprávy požaduje • zaslání dat, či provedení operace • linky téže asociace spojují objekty těchže tříd Vladimíra Zádová, KIN, EF TUL

PDS

8

Objektový přístup - vztahy mezi třídami • asociace může být – obecná • jednostranná – pouze jedna třída zná rozhraní druhé třídy • oboustranná – obě třídy znají rozhraní druhé třídy

– agregace • je speciálním případem asociace • objekt agregující třídy obsahuje jiné objekty ( skládá se z), – t.j.objekt může být kontejnerem, který obsahuje objekty jiné třídy


PDS

Objektový přístup - agregace • agregované objekty většinou přístupné agregujícího objektu - kontejneru

prostřednictvím

• komunikace mezi kontejnerem a jeho objekty (přenos požadavku) se uskutečňuje: – propagací • kontejner řeší úkol jeho předáním svým objektům

– výběrem • kontejner předá úkol vybranému objektu

– oběžníkem • úkol řeší ten objekt, který se přihlásil na dotaz kontejneru

•

pokud objekty budou obsaženy ve více kontejnerech, pak je jeden kontejner vlastní ( a tím rozhoduje o jeho existenci), ostatní užívají Vladimíra Zádová, KIN, EF TUL

PDS

9

OID - object identifier • každému objektu je přiřazeno OID, když je objekt vytvořen – je generován systémem • uživatel nemůže měnit, max může číst, ideálně není vůbec viditelný

– je jedinečný, neměnný po dobu existence objektu • unikátnost platí v rámci celého systému • nebude znovu použito pro jiné objekty ani po skončení existence objektu • nezávisí na hodnotách jeho atributů


PDS

OID – OID zajistí unikátní identifikaci objektu • tím automaticky poskytuje entitní integritu • je silnější omezení než entitní integrita v RMD, kde unikátnost je zajištěna v rámci relace – v RMD PK zajišťuje entitní integritu - je tedy založeno na hodnotách atributů

– objekt se může odkazovat na jiné objekty nebo je obsahovat (musí platit, že objekt existuje)


PDS

10

OID • výhody užití OID – – – – –

efektivnost - OID požaduje min. paměť rychlost při nalezení objektů nemohou být modifikovány uživatelem uživatel se vyhne údržbě integrity nezávislost na obsahu


PDS

Atributy v objektech • jednoduché atributy – primitivní typy - real, integer, string

• komplexní atributy obsahují – kolekce • např. atribut prodavači obsahuje kolekci objektů • reprezentují vztahy mezi objekty, obsahují kolekce hodnot, které jsou samy objekty

– odkazy - referenční atributy • obsahově podobný jako FK v RMD


PDS

11

Objektový model • OODM (objektově orientovaný datový model) – je datový model vycházející z objektového paradigmatu • OO = OO DB + OODBMS – OODB je perzistentní a sdílená množina objektů definovaných OODM – problematika v nejednotnosti přístupu, někteří autoři dokonce nepovažují za základ dědičnost – např. Khoshafian a Abnous v r. 1990 definují OO DBMS jako: • objektová orientace = ADT + dědičnost + objekty • OODBMS = objektová orientace + databáze


PDS

OR DBMS


PDS

12

Objektově relační databáze ( OR DBMS) • synonyma “ rozšířená relační“ (Extended ERDBMS) a "objektově-relační“(OR DBMS) či Universal Server (Universal DBMS - UDBMS) • obsahují některé OO rysy – zapouzdření, dědičnost, polymorfismus, dynamickou vazbu metod, complex object, OID • vložení triggerů (metod, procedur) do databáze je považováno za „objektovost“ • mohou mít uplatněny jen některé z těchto rysů

• vždy vycházejí z RDBMS - základních relací a SQL • ORDBMS je specifikována v rozšíření SQL standardu — SQL3 •

Do této kategorie patří např. Informix, IBM, Oracle a Unisys. Vladimíra Zádová, KIN, EF TUL

PDS

Rozšiřitelnost, uživatelsky definované typy a funkce Požadavek: manipulace BLOB (v RSŘBD atomický) Rozšiřitelnost: možnost přidávání nových datových typů + programů (funkce) „zabalených“ do speciálního modulu

⇒

UDT (uživatelsky definované typy) UDF (uživatelsky definované funkce) Problém: zapojení do relačního SŘBD DB/2: relační extendery Informix: DataBlades univerzální servery ORACLE: cartridges Sybase:

Component Integration Layer. Vladimíra Zádová, KIN, EF TUL

PDS

13

Rozšiřitelnost, uživatelsky definované typy a funkce Př.: DB/2 obrazový, video, audio, textový, mapy, časové řady VideoCharger (audio a video objekty v reálném čase), XML

Př.: Informix v r. 1999 více než 25 DataBlades: analýza dat pomocí fuzzy logiky, čištění (pro datové sklady), zpracování dokumentů v ruském jazyce

Př.: Oracle interMedia - cartridge pro prostorové objekty, časové řady, vyhledávání ve vizuálních informacích (obrázcích)


PDS

Objektově relační model • Výhody – znovupoužívání a sdílení • vyplývá ze schopnosti rozšířit DBMS server k vykonání funkcionality centrálně ( př. prostorové datové typy(spatial data) - body, přímky, polygony a s tím spojené funkce - výpočet vzdáleností, určení zda je částí, překrývání, částí polygonů)

• umístění na serveru a možnost sdílení funkcionality ve všech aplikacích

– využití RDBM – není tak drahé a nepřístupné, je ověřené – evoluční vývoj bez ztráty užitku původního

• Nevýhody – vyčítáno puristy z obou stran - málo objektovosti, odklon od RDBM


PDS

14

Objektově relační model • manifest 3.generace databázových systémů – publikován CADF - (Committee for Advanced DBMS Function) – cíle: • bohatost typů, dědičnost,funkce zahrnující metody a zapouzdření • přiřazení unikátních identifikátorů - pokud není uživatelem def. PK • přístupy k databázi - pomocí neprocedurálního jazyka vysoké úrovně • ….

• současné implementace ORSŘBD zatím v počátcích – paralela: výtky OOSŘBD - málo databázové výtky ORSŘBD - málo objektové • chybí vývojové prostředky, nové metodologie • největší problém a současně výhoda: univerzálnost Vladimíra Zádová, KIN, EF TUL

PDS

ORDBMS • ORDBMS "přidávají objektovost do tabulek“ jsou nadmnožinou RDBMS • Rozšíření relačního modelu o objekty a konstrukty pro manipulaci nových datových typů • základ tabulka, ale data mohou mít bohatší datovou strukturu abstraktní datové typy (ADT) – rozšíření relačního modelu o objekty a konstrukty pro manipulaci nových datových typů

• atributy n-tic jsou složité typy, včetně hní hnízdě zděných relací relací • kompatibilita s existujícími relačními jazyky (tvoří podmnožinu) – pokud nevyužijeme žádné objektové rozšíření jsou ekvivalentní SQL2 – proto omezená podpora dědičnosti, polymorfismu, referencí a integrace s programovacím jazykem.

• zachovány jsou relační základy včetně deklarativního přístupu k datům Vladimíra Zádová, KIN, EF TUL PDS

15

Rozšíření základních datových typů uživatelsky definované typy • SQL-92 – – – –

omezená škála datových typů a operací číselné, znakový řetězec, datum, čas, interval atomicita pro každý typ definuje přesnou množinu operátorů a funkcí


PDS

Charakteristiky rozšíření Charakteristické rysy kvalitního OR systému • Rozšíření základních datových typů • Složité objekty • Dědičnost • Pravidla

• Uživatelsky definované funkce a operátory k uživatelsky definovaným datovým typům Vladimíra Zádová, KIN, EF TUL

PDS

16

Rozšíření základních datových typů • CREATE TYPE – obdoba CREATE DOMAIN


PDS

Procedury a funkce programy vyvolatelné v SQL: procedury a funkce – procedury mají parametry typu IN, OUT, INOUT – funkce mají parametry jen typu IN, vracejí hodnotu

konstrukce programů: – hlava i tělo v SQL (buď 1 SQL příkaz nebo BEGIN…END) – hlava v SQL, tělo externě definované

volání programů: – procedura: CALL jméno_procedury(p1,p2,…,pn) – funkce: funkcionálně f(x,y)

v ADT přibudou metody


PDS

17

Uživatelsky definované funkce - k typům definovaným uživatelem • funkce lze psát –

v SQL • Funkce psané v SQL se při vykonávání dotazu rozvinou • Zjednodušuje dotazy , nesníží výkonnost • Server provede za běhu substituci v dotazu

–

jazyku třetí generace ( C, VB, Java..) • funkce jsou „neprůhledné“, při vykonání se zavolají (nejdou rozvinout)


PDS

CREATE FUNCTION jméno_ funkce (t1,t2….) RETURNING jméno_typu AS [jmeno souboru| db výraz] LANGUAGE [jazyk rutiny]


PDS

18

Uživatelsky definované operátory • operátor – z hlediska syntaxe je funkcí se dvěma argumenty – v SQL je speciálním druhem funkce se dvěma argumenty a odlišnou notací – vytvoření: • vytvoření funkce • svázání se symbolem operátoru


PDS

CREATE OPERATOR BINDING jmeno_operatoru TO jmeno_funkce


PDS

19

SLOŽITÉ OBJEKTY • objekty složené z několika základních nebo uživatelsky definovaných datových typů • základní: – řádek – množiny (kolekce) – odkazy


PDS

Konstruktor typu řádek CREATE ROW TYPE jméno_typu ( jmeno_složky dat_typ, ……….) Pozn.: složky mohou být základními typy i typ řádek, množina , odkaz)

Použití: 1. tabulka jako kontejner – použití k vytvoření řady tabulek , které obsahují instance stejného typu 2. použít do sloupce tabulky (složky datového typu) Vladimíra Zádová, KIN, EF TUL

PDS

20

Př.

CREATE ROW TYPE t_zamestnanec ( jmeno VARCHAR(30), Nastup DATE).

Tabulka jako kontejner:

CREATE TABLE zamestnanec OF TYPE t_zamestnanec. jako sloupec tabulky:

CREATE TABLE funkce ( c_funkce Integer,….. zamestnanec t_zamestnanec) spojení funkce se zaměstnancem, který tuto funkci vykonává


PDS

konstruktory kolekce (collection)

• je dán libovolný typ T, potom collection (T) musí být také datový typ. • vyžadována podpora kolekcí: – – – –

jednoduchých datových typů řádků kolekcí odkazů

– Pozn: SQL3 návrh konstruktorů množiny, multimnožiny a seznamu; každý klade na členství v množině jiné nároky


PDS

21

Konstruktor typu odkaz (references, pointers) • Je dán libovolný typ T, potom ref (T) musí být také datový typ, který se dá použít jako typ libovolného sloupce tabulky • odkaz na : – řádek – kolekci – Jednoduchý datový typ


PDS

Příklad CREATE ROW TYPE t_oddeleni ( nazev CHAR(30) vedouci CHAR(20) telef t_telef Typ vozy set(t_vuz) vedouci_odd ref(t_zamestnanec) REFERENCES (zamestnanec) pracovnici set(ref(t_zamestnanec) REFERENCES (zamestnanec))).

řádek Kolekce řádků Kolekce odkazů

CREATE TABLE oddeleni of type t_oddeleni Vladimíra Zádová, KIN, EF TUL

PDS

22

Manipulace s typem řádek - rozšíření standardního SQL 1. UDF mohou přijímat argumenty nebo vracet návratové hodnoty typu řádek CREATE FUNCTION premie (t_zamestnanec arg1) RETURNING int AS SELECT arg1.plat * 0,1

SELECT z.jmeno FROM zamestnanec z

SELECT premie(z) FROM zamestnanec WHERE z.jmeno = „MIKE“


Typ řádek

WHERE premie(z) > 1000

PDS

Tečková notace (Path expression) – Jmeno_ tabulky.jmeno_sloupce • Odkazuje na sloupce tabulky, lze užit i k odkazům na sloupce typu řádek SELECT telef.cislo FROM oddeleni WHERE nazev = „obuv“ Pozn.: cislo je jen dílčí pole ze sloupce telef (typ řádek)

SELECT nazev FROM oddeleni WHERE telef.oblast = „510“ – Jmeno_atributu(jmeno_funkce) • řádek, v němž jméno funkce představuje jméno atributu ( každý jeho atribut má jednu funkci)

SELECT nazev FROM oddeleni WHERE oblast(telef) = „510“ Vladimíra Zádová, KIN, EF TUL

PDS

23

Manipulace s kolekcemi řádků – Tečková notace SELECT název FROM oddeleni WHERE „FORD“ in vozy.jmeno Pozn.: vozy.jmeno definují množinu


PDS

Příklad CREATE ROW TYPE t_oddeleni ( nazev CHAR(30) vedouci CHAR(20) telef t_telef Typ vozy set(t_vuz) vedouci_odd ref(t_zamestnanec) REFERENCES (zamestnanec) pracovnici set(ref(t_zamestnanec) REFERENCES (zamestnanec))).

řádek Kolekce řádků Kolekce odkazů

CREATE TABLE oddeleni of type t_oddeleni Vladimíra Zádová, KIN, EF TUL

PDS

24

odkazy = náhrada PK, FK Viz tab. Oddeleni: vedouci je FK obsahujícím číslo zaměstnance – vedoucího daného oddelení ( viz DSY – PK=FK při spojení) vedouci_odd - identifikace téhož • Konceptuálně = ukazatel na typ řádku v tabulce (skutečná hodnota uložená v poli vedoucí oddělení je OID )

– Podpora odkazů vyžaduje rozšíření SQL • funkci DEREF –vrací skutečný řádek - při zadání odkazu • Podporu funkcí, které přijímají argumenty, či vracejí výsledky typu odkaz SELECT vedoucí_odd FROM oddeleni ………… vrátí odkaz na zaměstnance- vedoucího ( OID) SELECT DEREF(vedouci_odd) FROM oddeleni ……………..funkce přijme odkaz na vedoucího, vrací řádek na který odkazuje Vladimíra Zádová, KIN, EF TUL

PDS

Odkazy deref/ref CREATE FUNCTION dej_vedouci (varchar(30) arg1) RETURNING t-zamestnanec AS SELECT deref(vedoucí_odd) FROM oddeleni WHERE oddeleni = arg1)

Funkce REF - slouží k získání hodnoty OID SELECT REF(DEREF(dej_vedouci)) FROM oddeleni WHERE nazev=„obuv)

UPDATE oddeleni SET vedouci_odd = (SELECT REF(zamestnanec) FROM zamestnanec

zavedeni nového vedouciho UPDATE oddeleni SET vedouci = „MAREK“ WHERE Nazev = „obuv“

WHERE jmeno = „MAREK“) Vladimíra Zádová, KIN, EF TUL

PDS

25

SELECT DEREF(vedouci_odd).nastup, DEREF(vedouci_odd).plat FROM oddeleni

Užití vazba PK-FK x ref (=OID) odkazy bezpečnější, garantují unikátnost a neměnnost OID, ale méně „čitelné“


PDS

Kolekce odkazů SELECT pracovnici FROM oddeleni WHERE nazev = „obuv“

….. Vrací kolekci OID

SELECT deref(*) FROM TABLE (SELECT pracovnici FROM oddeleni WHERE nazev = „obuv“) SELECT deref(*).nastup FROM TABLE (SELECT pracovnici FROM oddeleni WHERE nazev = „obuv“) Vladimíra Zádová, KIN, EF TUL

PDS

26

Dědičnost - umožňuje sdružovat složené typy do hierarchie dědičnosti - nadtyp, podtyp - pomocí under - podpora vícenásobné dědičnosti – od více supertypů - Pokud nejednoznačnost (z obou dědí stejné jméno, jiná specifikace – různé přístupy- potlačení, či jiná ošetření)

- podpora modularity a konzistence při opakujícím se využití prvků schématu - platí pouze pro datové typy – doporučení vytvořit typy, pak je přiřadit tabulkám - typ nemá nemá paměť paměť,, pro ulož uložení ení instancí instancí typu tř třeba vytvoř vytvořit tabulky Vladimíra Zádová, KIN, EF TUL

PDS

Dědičnost - podpora dědičnosti dat a funkcí - podpora přetížení (polymorfismus) - schopnost odlišit funkce pro podtypy a nadtypy

- typy a tabulky musí představovat samostatný koncept - typová hierarchie, odděleně definované tabulky (tabulka jako kontejner)

- podpora vícenásobné dědičnosti - dědění subtypu od dvou odlišných supertypů Vladimíra Zádová, KIN, EF TUL

PDS

27

Dědičnost -příklad CREATE TYPE t_osoba ( jmeno varchar(30)) CREATE TYPE t_zamestnanec ( plat int, nastup date adresa varchar(30) město varchar (30) stat varchar(30) PSC int) Under t_osoba. CREATE TYPE t_student ( Prospech decimal) UNDER t_osoba


PDS

Vícenásobná dědičnost - příklad CREATE TYPE zamestnany_student( procento decimal) UNDER t_zamestnanec, t_student


PDS

28

Dědičnost –příklad CREATE TABLE osoba of type t_osoba. CREATE TABLE zamestnanec OF TYPE t_zamestnanec UNDER osoba. CREATE TABLE student OF TYPE t_student UNDER osoba.

CREATE TABLE zamestnaný_student OF TYPE t_zamestnany_student UNDER student, zamestnanec . Vladimíra Zádová, KIN, EF TUL

PDS

Dědičnost manipulace SELECT jmeno FROM zamestnanec WHERE plat = 10 000. – obor hodnot = tab. zaměstnanec a všechny pod ním SELECT jmeno FROM ONLY(zamestnanec) WHERE plat = 10 000 – obor hodnot - pouze tabulka zamestnanec ( ne zamestnani studenti) Vladimíra Zádová, KIN, EF TUL

PDS

29

Dědičnost funkcí – Dědičnost chování - UDF dána argumenty funkce Př.: CREATE FUNCTION vyssi_plat (t_zamestnanec arg1) Returns BOOLEAN AS SELECT arg1.plat > (SELECT plat FROM zamestnanec WHERE jmeno = „B“)


PDS

Manipulace SELECT z.jmeno FROM ONLY ( zamestnanec ) z WHERE vyssi_plat (z) SELECT z.jmeno FROM zamestnanec z WHERE vyssi_plat (z) ………..pokud není žádná funkce definována pro zamestnany_student, pak dědi tuto funkci Vladimíra Zádová, KIN, EF TUL

PDS

30

Pravidla Událost – podmínka – akce = při výskytu události a splnění podmínky je akce vykonána Pravidla: Aktualizace - aktualizace Dotaz - aktualizace Aktualizace - dotaz Dotaz - dotaz CREATE RULE


PDS

Objektově relační model • Výhody – znovupoužívání a sdílení • vyplývá ze schopnosti rozšířit DBMS server k vykonání funkcionality centrálně ( př. prostorové datové typy(spatial data) - body, přímky, polygony a s tím spojené funkce - výpočet vzdáleností, určení zda je částí, překrývání, částí polygonů)

• umístění na serveru a možnost sdílení funkcionality ve všech aplikacích

– využití RDBM – není tak drahé a nepřístupné, je ověřené – evoluční vývoj bez ztráty užitku původního

• Nevýhody – vyčítáno puristy z obou stran - málo objektovosti, odklon od RDBM


PDS

31

Objektově relační model

Recommend Documents