Objektově orientované datové modely. Objektově orientovaný model

Základní pojmy

Definice 1

Objektově orientovaný model reprezentace dat umožňuje identifikovat jednotlivé databázové záznamy.

Databázové záznamy a jejich funkce zpracování jsou propojeny mechanismy podobnými odpovídajícím nástrojům, které jsou implementovány v objektově orientovaných programovacích jazycích.

Definice 2

Grafické znázornění Struktura objektově orientované databáze je strom, jehož uzly představují objekty.

Standardní typ (například řetězec - tětiva) nebo uživatelem vytvořený typ ( třída), popisuje vlastnosti objektu.

Na obrázku 1 je objekt LIBRARY rodičem objektů instance tříd CATALOG, SUBSCRIBER a ISSUES. Různé objekty typu BOOK mohou mít jednoho nebo různé rodiče. Objekty typu BOOK, které mají stejného rodiče, musí mít alespoň různá přístupová čísla (jedinečná pro každou instanci knihy), ale stejné hodnoty vlastnosti autor, název, udk A isbn.

Logické struktury objektově orientované a hierarchické databáze jsou navenek podobné. Liší se především metodami manipulace s daty.

Když provádíte akce s daty v objektově orientovaném modelu, použijte logické operace, které jsou vylepšeny zapouzdřením, dědičností a polymorfismem. S určitým omezením můžete používat operace, které jsou podobné příkazům SQL (například při vytváření databáze).

Při vytváření a úpravách databáze se automaticky tvoří a následně upravují indexy (indexové tabulky), které obsahují informace pro implementaci rychlé hledání data.

Definice 3

cílová zapouzdření– omezení rozsahu názvu vlastnosti na hranice objektu, ve kterém je definován.

Pokud je například k objektu CATALOG přidána vlastnost, která specifikuje telefonní číslo autora a má jméno telefon, pak budou získány stejnojmenné vlastnosti pro objekty CATALOG a SUBSCRIBER. Význam vlastnosti je určen objektem, ve kterém je zapouzdřena.

Definice 4

Dědictví, opak zapouzdření, je zodpovědný za rozšíření rozsahu vlastnosti na všechny potomky objektu.

Například všem objektům BOOK, které jsou potomky objektu CATALOG, lze přiřadit vlastnosti nadřazeného objektu: autor, název, udk A isbn.

Pokud je nutné rozšířit působení mechanismu dědičnosti na objekty, které nejsou bezprostředními příbuznými (například na dva potomky stejného rodiče), je v jejich společném předkovi definována vlastnost abstraktního typu. břišní svaly.

Takže vlastnosti číslo A lístek v objektu LIBRARY jsou zděděny všemi podřízenými objekty LENDING, BOOK a SUBSCRIBER. Proto jsou hodnoty této vlastnosti tříd SUBSCRIBER a ISSUANCE stejné - 00015 (obrázek 1).

Definice 5

Polymorfismus umožňuje stejnému programovému kódu pracovat s heterogenními daty.

Jinými slovy, připouští v objektech odlišné typy mít metody (funkce nebo procedury) se stejným názvem.

Vyhledávání v objektově orientované databázi je určit podobnost mezi objektem, který uživatel určí, a objekty, které jsou uloženy v databázi.

Výhody a nevýhody objektově orientovaného modelu

Hlavní výhoda objektově orientovaný datový model na rozdíl od relačního modelu je schopnost zobrazovat informace o složitých vztazích objektů. Uvažovaný datový model umožňuje definovat samostatný databázový záznam a jeho funkce zpracování.

NA nedostatky objektově orientovaný model zahrnuje vysokou koncepční složitost, nepohodlné zpracování dat a nízkou rychlost provádění dotazů.

K dnešnímu dni jsou takové systémy poměrně rozšířené. Patří mezi ně DBMS:

• postgres,
• orion,
• duhovka,
• ODBJupiter,
• Versant,
• Objektivita/DB,
• sklad předmětů,
• statický,
• drahokam
• g základ.

PostrelačníModelka

Klasický relační model předpokládá nedělitelnost dat uložených v polích tabulkových záznamů. Postrelační model je rozšířený relační model, který odstraňuje omezení nedělitelnosti dat. Model umožňuje vícehodnotová pole – pole, jejichž hodnoty se skládají z podhodnot. Sada hodnot pro pole s více hodnotami je považována za samostatnou tabulku vloženou do hlavní tabulky.

Na Obr. 2.6 je na příkladu informací na fakturách a zboží pro srovnání znázorněna prezentace stejných dat pomocí relačních (a) a postrelačních (b) modelů. Obrázek ukazuje, že ve srovnání s relačním modelem v post relační model data jsou uložena efektivněji a zpracování nevyžaduje operaci spojení dat mezi dvěma tabulkami.

Faktury

Nad hlavou

Rýže. 2.6. Datové struktury relačních a postrelačních modelů

Vzhledem k tomu, že postrelační model umožňuje ukládání nenormalizovaných dat v tabulkách, vzniká problém zajištění integrity a konzistence dat. Tento problém je vyřešen zahrnutím vhodných mechanismů do DBMS.

Důstojnost Postrelační model je schopnost reprezentovat množinu souvisejících relačních tabulek jednou postrelační tabulkou. To zajišťuje vysokou viditelnost prezentace informací a zvýšení efektivity jejich zpracování.

nevýhoda Postrelační model je složitost řešení problému zajištění integrity a konzistence uložených dat.

Uvažovaný postrelační datový model je podporován uniVers DBMS. Mezi další DBMS založené na postrelačním datovém modelu patří také systémy Bubba a Dasdb.

Vícerozměrný model

Vícerozměrný přístup k reprezentaci dat se objevil téměř současně s relačním, ale zájem o vícerozměrné DBMS se začal šířit od poloviny 90. let. Impulsem byl v roce 1993 článek E. Codda. Formuloval 12 základních požadavků na systémy třídy OLAP (OnLine Analytical Processing), z nichž nejdůležitější souvisí se schopnostmi koncepční reprezentace a zpracování vícerozměrných dat.

Ve vývoji pojmů informační systémy lze rozlišit dva směry:

Operační (transakční) systémy zpracování;

Systémy analytické zpracování(systémy na podporu rozhodování).

Relační DBMS byly určeny pro informační systémy zpracování provozních informací a jsou v této oblasti velmi efektivní. V systémech analytického zpracování se ukázalo, že jsou poněkud neohrabané a nedostatečně flexibilní. Vícerozměrné DBMS jsou zde efektivnější.

Multidimenzionální DBMS jsou vysoce specializované DBMS určené pro interaktivní analytické zpracování informací. Hlavními koncepty používanými v těchto DBMS jsou agregovatelnost, historicita a předvídatelnost.

Agregovatelnost data znamenají zvažování informací na různých úrovních jejich zobecnění. V informačních systémech závisí míra podrobnosti prezentace informací pro uživatele na jejich úrovni: analytik, uživatel, manažer, manažer.

Historickosti data zahrnují zajištění vysoké úrovně statické povahy dat samotných a jejich vztahů, stejně jako povinnou vazbu dat na čas.

Předvídatelnost zpracování dat zahrnuje nastavení predikčních funkcí a jejich aplikaci na různé časové intervaly.

Vícerozměrnost datového modelu neznamená vícerozměrnost digitální vizualizace dat, ale vícerozměrné logické znázornění informační struktury při popisu a operacích manipulace s daty.

Ve srovnání s relačním modelem má vícerozměrná organizace dat vyšší viditelnost a informační obsah. Pro ilustraci na Obr. Obrázek 2.7 ukazuje relační (a) a vícerozměrné (b) znázornění stejných dat o objemech prodeje automobilů.

Základní pojmy vícerozměrných datových modelů: dimenze a buňka.

Měření je množina dat stejného typu, která tvoří jednu z ploch hyperkrychle. Ve vícerozměrném modelu hrají rozměry roli indexů, které slouží k identifikaci konkrétních hodnot v hyperkrychlových buňkách.

Buňka je pole, jehož hodnota je jednoznačně určena pevnou sadou měření. Typ pole je nejčastěji definován jako číselný. V závislosti na tom, jak se tvoří hodnoty určité buňky, to může být proměnná (hodnoty se mění a lze je načíst z externího zdroje dat nebo generovat programově) nebo vzorec (hodnoty, jako jsou buňky tabulkového vzorce, se počítají podle předem definovaných vzorců).

Rýže. 2.7. Relační a vícerozměrná reprezentace dat

V příkladu na Obr. 2,7 b hodnota každé buňky Objem prodeje jednoznačně určeno kombinací časové dimenze Prodejní měsíc a modely aut. V praxi je často zapotřebí více měření. Příklad 3D modelúdaje jsou uvedeny na Obr. 2.8.

Rýže. 2.8. Příklad 3D modelu

Stávající vícerozměrné DBMS používají dvě hlavní schémata organizace dat: hyperkubická a polykubická.

V polykubický Schéma předpokládá, že několik hyperkrychlí s různými rozměry as různými rozměry lze definovat v databázi jako plochy. Příkladem systému, který podporuje polykubickou variantu databáze, je Oracle Express Server.

Když hyperkubický Schéma předpokládá, že všechny buňky jsou definovány stejnou sadou měření. To znamená, že pokud je v databázi několik hyperkrychlí, všechny mají stejný rozměr a stejné rozměry.

Hlavní důstojnost multidimenzionální datový model představuje pohodlí a efektivitu analytického zpracování velkého množství časově souvisejících dat.

nevýhoda multidimenzionální datový model je jeho těžkopádnost pro ty nejjednodušší běžné úkoly operativní zpracování informace.

Příklady systémů, které podporují vícerozměrné datové modely, jsou Essbase, Media Multi-matrix, Oracle Express Server, Cache. Existují softwarové produkty, jako je Media / MR, které umožňují současně pracovat s vícerozměrnými a relačními databázemi.

Objektově orientovaný model

V objektově orientovaném modelu je možné při prezentaci dat identifikovat jednotlivé databázové záznamy. Vztahy mezi záznamy a jejich funkcemi zpracování se vytvářejí pomocí mechanismů podobných odpovídajícím zařízením v objektově orientovaných programovacích jazycích.

Standardizovaný objektově orientovaný model je popsán v doporučeních standardu ODMG-93 (Object Database Management Group - skupina pro správu objektově orientované databáze).

Zvažte zjednodušený model objektově orientované databáze. Struktura objektově orientované databáze je graficky znázorněna jako strom, jehož uzly jsou objekty. Vlastnosti objektů jsou popsány nějakým standardním nebo uživatelem vytvořeným typem (definovaným jako třída). Hodnota vlastnosti typu class je objekt, který je instancí odpovídající třídy. Každý objekt instance třídy je považován za potomka objektu, ve kterém je definován jako vlastnost. Objekt instance třídy patří do její třídy a má jednoho rodiče. Generické vztahy v databázi tvoří propojenou hierarchii objektů. Příklad logické struktury objektově orientované knihovnické databáze je uveden na Obr. 2.9. Zde je objekt typu Knihovna je rodič objektů instance třídy Odběratel, Katalog A vydání. Různé typy objektů knihy a mohou mít stejné nebo různé rodiče. Objekty typu Rezervovat, které mají stejného rodiče, se musí lišit alespoň o přístupové číslo (jedinečné pro každou instanci knihy), ale musí mít stejné hodnoty vlastností isb n udk, jména e a autor.

Logická struktura objektově orientované databáze je navenek podobná struktuře hierarchické databáze. Hlavní rozdíl mezi nimi je ve způsobech manipulace s daty.

K provádění akcí s daty v uvažovaném databázovém modelu se používají logické operace rozšířené o objektově orientované mechanismy zapouzdření, dědičnosti a polymorfismu.

Zapouzdření omezuje rozsah názvu vlastnosti na objekt, ve kterém je definován. Pokud tedy v objektu typu Katalog přidat vlastnost, která určuje telefonní číslo autora knihy a má název telefon, pak získáme stejnojmenné vlastnosti pro objekty Odběratel A Katalog. Význam takové vlastnosti bude určen objektem, ve kterém je zapouzdřena.

Dědictví, naopak rozšiřuje rozsah majetku na všechny potomky objektu. Tedy pro všechny objekty typu Rezervovat, což jsou potomci objektu typu Katalog, můžete přiřadit vlastnosti nadřazeného objektu: isbn, udk, název A autor. Pokud je nutné rozšířit mechanismus dědičnosti na objekty, které nejsou bezprostředními příbuznými (například mezi dvěma potomky stejného rodiče), pak abstraktní vlastnost typu břišní svaly. Tedy definice abstraktních vlastností lístek A číslo v objektu Knihovna způsobí, že tyto vlastnosti zdědí všechny podřízené objekty Odběratel, Rezervovat A Problémy A. Není náhodou, že se proto nemovitost cení lístek třídy Odběratel A vydání znázorněno na Obr. 2.9 jsou stejné - 00015.

Polymorfismus v objektově orientovaných programovacích jazycích znamená schopnost stejného programového kódu pracovat s heterogenními daty. Jinými slovy to znamená, že objekty různých typů mohou mít metody (procedury nebo funkce) se stejnými názvy. Během provádění objektového programu fungují stejné metody s různými objekty v závislosti na typu argumentu. Ve vztahu k uvažovanému příkladu polymorfismus znamená, že objekty třídy Rezervovat mít různé rodiče ze třídy Katalog, může mít jinou sadu vlastností. Tedy programy pro práci s objekty třídy Rezervovat může obsahovat polymorfní kód.

Vyhledávání v objektově orientované databázi spočívá ve zjišťování podobností mezi objektem zadaným uživatelem a objekty uloženými v databázi.

Rýže. 2.9. Logická struktura knihovnické databáze

Hlavní důstojnost objektově orientovaný datový model ve srovnání s relačním je schopnost zobrazovat informace o komplexních vztazích objektů. Objektově orientovaný datový model umožňuje identifikovat jeden databázový záznam a definovat funkce pro jeho zpracování.

nevýhody objektově orientovaného modelu jsou vysoká koncepční složitost, nepohodlnost zpracování dat a nízká rychlost vyřizování žádostí.

Objektově orientované DBMS zahrnují POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Objektově orientovaný model

V objektově orientovaném modelu je možné při prezentaci dat identifikovat jednotlivé databázové záznamy. Vztahy mezi databázovými záznamy a jejich funkcemi zpracování se vytvářejí pomocí mechanismů podobných odpovídajícím zařízením v objektově orientovaných programovacích jazycích.

Standardizovaný objektově orientovaný model je popsán v doporučeních standardu ODMG-93 (Object Database Management Group). Dosud nebylo možné plně implementovat doporučení ODMG-93. Pro ilustraci klíčové myšlenky Zvažte poněkud zjednodušený model objektově orientované databáze.

Struktura objektově orientované databáze (například Versant Object Database, Object Store atd.) je graficky znázorněna jako strom, jehož uzly jsou objekty. Vlastnosti objektu jsou popsány nějakým standardním typem (například řetězec - řetězec) nebo uživatelem vytvořeným typem (definovaným jako třída).

Hodnota vlastnosti typu string je znakový řetězec. Hodnota vlastnosti typu class je objekt, který je instancí odpovídající třídy. Každý objekt – instance třídy je považována za potomka objektu, ve kterém je definována jako vlastnost. Objekt je instancí třídy, která patří do její třídy a má jednoho rodiče. Generické vztahy v databázi tvoří koherentní hierarchii objektů.

Logická struktura objektově orientované databáze je navenek podobná struktuře hierarchické databáze. Hlavní rozdíl mezi nimi je ve způsobech manipulace s daty.

K provádění akcí s daty v uvažovaném databázovém modelu se používají logické operace rozšířené o objektově orientované mechanismy zapouzdření, dědičnosti a polymorfismu.

Operace podobné příkazům lze používat v omezené míře. jazyk SQL(například pro vytvoření databáze).

Vytvoření a úprava databáze je doprovázena automatickým vytvářením a následnou úpravou indexů (indexových tabulek) obsahujících informace pro rychlé vyhledání dat.

Podívejme se stručně na pojmy zapouzdření, dědičnost a polymorfismus ve vztahu k objektově orientovanému databázovému modelu.

Zapouzdření omezuje rozsah názvu vlastnosti na objekt, ve kterém je definován.

Dědictví naopak rozšiřuje rozsah majetku na všechny potomky objektu.

Polymorfismus v objektově orientovaných programovacích jazycích znamená schopnost stejného programového kódu pracovat s heterogenními daty. Jinými slovy to znamená, že objekty různých typů mohou mít metody (procedury nebo funkce) se stejnými názvy. Během provádění objektového programu fungují stejné metody s různými objekty v závislosti na typu argumentu. Vyhledávání v objektově orientované databázi spočívá v hledání podobností mezi objektem zadaným uživatelem a objekty uloženými v databázi. Uživatelsky definovaný objekt nazývaný objekt cíle (vlastnost objektu typu goal) může být obecně podmnožinou celé hierarchie objektů uložené v databázi. Cílový objekt, stejně jako výsledek provádění dotazu, lze uložit do samotné databáze.

Hlavní výhodou objektově orientovaného datového modelu ve srovnání s relačním je schopnost zobrazovat informace o komplexních vztazích objektů. Objektově orientovaný datový model umožňuje identifikovat jeden databázový záznam a definovat funkce pro jeho zpracování.

Nevýhodou objektově orientovaného modelu je vysoká koncepční složitost, nepohodlnost zpracování dat a nízká rychlost provádění dotazu.

Typy dat

Zpočátku byly DBMS využívány především k řešení finančních a ekonomických problémů. Současně, bez ohledu na prezentační model, byly v databázích použity následující hlavní datové typy:

• číselné. Příklad hodnot dat: 0,43; 328; 2E+5;
• znak (alfanumerický). Příklady datových hodnot: "Pátek", "řetězec", "programátor";
• data určená pomocí speciálního typu "Datum" nebo jako normální znaková data. Příklady datových hodnot: 12/1/97, 2/23/1999.

V různých DBMS se tyto typy mohou navzájem nevýznamně lišit v názvu, rozsahu hodnot a typu reprezentace. Následně se začaly objevovat specializované systémy zpracování dat v nových oblastech použití, například geoinformace, zpracování obrazu videa atd. V tomto ohledu začali vývojáři zavádět do tradičních DBMS nové typy dat. Mezi relativně nové datové typy patří následující:

• dočasné a datum-čas, určené k ukládání informací o čase a (nebo) datu. Příklad hodnot dat: 01/31/85 (datum), 9:10:03 (čas), 03/6/1960 12:00 (datum a čas);
• znak variabilní délka určený k uložení textové informace velká délka, jako je dokument;
• binární, určený k uložení grafické objekty, audio a video informace, prostorové, chronologické a další speciální informace. Například v MS Access je tímto typem datový typ "OLE Object Field", který umožňuje ukládat grafická data do databáze ve formátu BMP (Bitmap) a automaticky je zobrazovat při práci s databází;
• hypertextové odkazy určené k ukládání odkazů na různé zdroje (uzly, soubory, dokumenty atd.) umístěné mimo databázi, například na internetu, firemní síť intranet nebo pevný disk počítače.

V moderních DBMS různé modely dat, lze použít všechny uvedené typy dat.

V objektově orientovaném modelu (OOM) je možné při prezentaci dat identifikovat jednotlivé databázové záznamy. Vztahy mezi databázovými záznamy a jejich funkcemi zpracování se vytvářejí pomocí mechanismů podobných odpovídajícím zařízením v objektově orientovaných programovacích jazycích.

Standardní OOM popsané v doporučeních standardu ODMG-93 (Object Database Management Group - skupina pro správu objektově orientovaných databází). Dosud nebylo možné plně implementovat doporučení ODMG-93. Pro ilustraci klíčových myšlenek zvažte poněkud zjednodušený model objektově orientované databáze.

Struktura OO DB je graficky znázorněna jako strom, jehož uzly jsou objekty. Vlastnosti objektu jsou popsány nějakým standardním typem (například řetězec - řetězec) nebo uživatelem vytvořeným typem (definovaným jako třída).

Hodnota vlastnosti typu string je znakový řetězec. Hodnota vlastnosti typu class je objekt, který je instancí odpovídající třídy. Každý objekt instance třídy je považován za potomka objektu, ve kterém je definován jako vlastnost. Objekt instance třídy patří do její třídy a má jednoho rodiče. Generické vztahy v databázi tvoří propojenou hierarchii objektů.

Příklad logické struktury OO DB knihovnictví je uveden na Obr. 3.14. Zde je objekt typu LIBRARY rodičem objektů instance tříd SUBSCRIBER, CATALOG a ISSUANCE. Různé objekty typu BOOK, které mají stejného rodiče, se musí lišit alespoň o přístupové číslo (jedinečné pro každou instanci knihy), ale mají stejné hodnoty vlastností isbn, udk, titul A autor.

Obr.3.14. Logická struktura knihovnické databáze

Logická struktura OO databáze je navenek podobná struktuře hierarchické databáze. Hlavní rozdíl mezi nimi je ve způsobech manipulace s daty. K provádění akcí s daty v databázi OOM se používají logické operace rozšířené o objektově orientované mechanismy zapouzdření, dědičnosti a polymorfismu. Operace podobné příkazům SQL lze v omezené míře používat (například k vytvoření databáze).

Vytvoření a úprava databáze je doprovázena automatickým vytvářením a následnou úpravou indexů (indexových tabulek) obsahujících informace pro rychlé vyhledání dat.

Podívejme se krátce na pojmy zapouzdření, dědičnost a polymorfismus ve vztahu k OOM databáze.

Zapouzdření omezuje rozsah názvu vlastnosti na objekt, ve kterém je definován. Pokud tedy k objektu typu CATALOG přidáte vlastnost, která specifikuje telefonní číslo autora knihy a má jméno telefon, pak získáme stejnojmenné vlastnosti pro objekty SUBSCRIBER a CATALOG. Význam takové vlastnosti bude určen objektem, ve kterém je zapouzdřena.

Dědictví, místo toho rozšiřuje rozsah vlastnosti na všechny potomky objektu. Všem objektům typu BOOK, které jsou potomky objektu typu CATALOG, lze tedy přiřadit vlastnosti nadřazeného objektu: isbn, udk, titul A autor. Pokud je nutné rozšířit působení mechanismu dědičnosti na objekty, které nejsou bezprostředními příbuznými (například mezi dvěma potomky stejného rodiče), pak je v jejich společném předku definována abstraktní vlastnost typu abs. Tedy definice abstraktních vlastností lístek A číslo v objektu LIBRARY způsobí, že všechny podřízené objekty SUBSCRIBER, BOOK a LENDER zdědí tyto vlastnosti. Není náhodou, že se proto nemovitost cení lístek třídy SUBSCRIBER a ISSUANCE uvedené na obrázku budou stejné - 00015.

Polymorfismus v objektově orientovaných programovacích jazycích znamená schopnost stejného programového kódu pracovat s heterogenními daty. Jinými slovy to znamená, že objekty různých typů mohou mít metody (procedury nebo funkce) se stejnými názvy. Během provádění objektového programu fungují stejné metody s různými objekty v závislosti na typu argumentu. Ve vztahu k naší OO DB polymorfismus znamená, že objekty třídy BOOK, které mají jiné rodiče než třída CATALOG, mohou mít jinou sadu vlastností. V důsledku toho mohou programy pro práci s objekty třídy BOOK obsahovat polymorfní kód.

Vyhledávání v OO DB spočívá ve zjištění podobnosti mezi objektem zadaným uživatelem a objekty uloženými v databázi. Uživatelsky definovaný objekt nazývaný objekt cíle (vlastnost objektu typu goal) může být obecně podmnožinou celé hierarchie objektů uložené v databázi. Cílový objekt, stejně jako výsledek provádění dotazu, lze uložit do samotné databáze. Příklad dotazu na čísla čtenářských průkazů a jména předplatitelů, kteří dostali do knihovny alespoň jednu knihu, je na Obr. 3.15.

Hlavní důstojnost OOM data ve srovnání s relačními je schopnost zobrazovat informace o složitých vztazích objektů. OOM data umožňují identifikovat jeden záznam databáze a určit funkce jejich zpracování.

nevýhoda OOM jsou vysoká koncepční složitost, nepohodlnost zpracování dat a nízká rychlost provádění dotazů.

Obr.3.15. Fragment databáze s cílovým objektem

Vraťme se znovu k problému Orders, prezentovaném ve formě relačního datového modelu na obr. 3.8 a uvažujte jej z hlediska objektově orientované databáze. Existují celkem tři třídy: klienti», « Objednávky" A " Zboží". Předměty třídy" klienti» jsou konkrétní zákazníci; vlastnosti třídy - číslo klienta, jméno klienta město, stav atd. Metody třídy - " Vytvořit objednávku», « Zaplatit účet" a tak dále. Metoda je nějaká operace, kterou lze aplikovat na objekt; metoda je to, co by měl objekt dělat. Třída odpovídající tabulce " Podrobnosti o objednávce", není požadováno. Data tabulky mohou být součástí třídy " Objednávky". Přítomnost ve třídě klienti» metoda « Vytvořit objednávku"vede k interakci s objekty tříd" Objednávky" A " Zboží". V tomto případě uživatel nemusí o této interakci objektů vědět. Uživatel přistupuje pouze k objektu " Objednávky"a používá metodu" Vytvořit objednávku". Skutečnost dopadu na jiné databáze může být uživateli skryta. Pokud metoda Vytvořit objednávku", podle pořadí, odkazuje na metodu " Zkontrolujte bonitu zákazníka“, pak může být tato skutečnost také skryta před uživatelem. V relační databáze ah data k provádění stejných funkcí, musíte napsat procedury v jazyce Visual Základní pro Aplikace (VBA).

V 90. letech 20. století vznikly experimentální prototypy systémů pro správu databází OO. V současné době jsou takové systémy široce používány. Konkrétně se jedná o následující DBMS: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltech Plus Research and Production Center) a Iris , Orion and Postgres.

Coddův relační model byl prvním formalizovaným a obecně přijímaným datovým modelem. V tomto modelu, stejně jako ve všech následujících, byly rozlišeny tři aspekty – strukturální, holistický a manipulativní. Datové struktury v relačním modelu jsou založeny na plochých normalizovaných vztazích, omezení integrity jsou vyjádřena pomocí logiky prvního řádu a nakonec je manipulace s daty založena na relační algebra nebo ekvivalentní relační kalkul. Jak mnoho výzkumníků poznamenává, úspěch relačního datového modelu je z velké části způsoben tím, že byl založen na přísném matematický aparát teorie množin, relace a logika prvního řádu. Návrháři jakéhokoli konkrétního relačního systému považovali za svou povinnost prokázat shodu s jejich konkrétní model data obecného relačního modelu, která fungovala jako měřítko „relativnosti“ systému.

Hlavní úskalí objektově orientovaného datového modelování pramení ze skutečnosti, že takto vyvinutý matematický aparát, na kterém by mohl být založen obecný objektově orientovaný datový model, neexistuje. Do značné míry tedy stále neexistuje základní objektově orientovaný model. Na druhou stranu někteří autoři tvrdí, že obecný objektově orientovaný datový model v klasickém slova smyslu nelze definovat z důvodu nevhodnosti klasické koncepce datového modelu pro objektově orientované paradigma.

Jeden z nejznámějších teoretiků v oblasti datových modelů, Beery, nabízí obecně formální rámec pro OODB, který není zdaleka úplný a není datovým modelem v tradičním slova smyslu, ale umožňuje výzkumníkům a vývojářům systémů OODB alespoň mluvit stejným jazykem (pokud ovšem nebudou vyvíjeny a podporovány věty Beeri). Bez ohledu na osud těchto návrhů považujeme za užitečné je krátce převyprávět.

Za prvé, v souladu s praxí mnoha OODB, se navrhuje rozlišovat dvě úrovně objektového modelování: nižší (strukturální) a horní (behaviorální). Podporováno na strukturální úrovni složité objekty, jejich identifikace a odrůdy spojení "isa". Databáze je kolekce datových prvků propojených vztahem „část třídy“ nebo „je atributem“. Databázi lze tedy považovat za orientovaný graf. Důležitý bod je udržovat spolu s konceptem objektu i koncept hodnoty (později uvidíme, jak moc je na tom postaven jeden z úspěšných objektově orientovaných DBMS O2).

Důležitým aspektem je jasné oddělení databázového schématu a databáze samotné. Primárními koncepty úrovně schématu OODB jsou typy a třídy. Je třeba poznamenat, že ve všech systémech, které používají pouze jeden koncept (buď typ nebo třídu), je tento koncept nevyhnutelně přetížen: typ implikuje přítomnost určité sady hodnot určených datovou strukturou tohoto typu; třída také předpokládá přítomnost množiny objektů, ale tato množina je definována uživatelem. Typy a třídy tedy hrají různé role a přísnost a jednoznačnost vyžadují současnou podporu pro oba koncepty.

Beery nepředkládá úplný formální model strukturální úrovně OODB, ale vyjadřuje důvěru, že současná úroveň porozumění je dostatečná k formalizaci takového modelu. Pokud jde o úroveň chování, byl navržen pouze obecný přístup k logickému aparátu potřebnému k tomu (logika první úrovně nestačí).

Beeryho důležitý, i když ne opodstatněný předpoklad je, že tradiční dvě vrstvy – schéma a data – pro OODB nestačí. Pro přesná definice OODB vyžaduje úroveň metaschématu, jejíž obsah musí definovat typy objektů a vztahů povolených na úrovni schématu databáze. Metaschéma by pro OODB měla hrát stejnou roli jako strukturální část relačního datového modelu pro schémata relačních databází.

Existuje mnoho dalších publikací souvisejících s tématem objektově orientovaných datových modelů, ale ty se buď dotýkají spíše specifických problémů, nebo používají pro tuto recenzi příliš vážný matematický aparát (někteří autoři například definují objektově orientovaný datový model na základě teorie kategorií).

Pro ilustraci současného stavu se krátce podíváme na vlastnosti konkrétního datového modelu používaného v objektově orientovaném DBMS O2 (samozřejmě se také nejedná o datový model v klasickém slova smyslu).

O2 podporuje objekty a hodnoty. Objekt je pár (identifikátor, hodnota) a objekty jsou zapouzdřeny, tzn. jejich hodnoty jsou dostupné pouze prostřednictvím metod - procedur připojených k objektům. Hodnoty mohou být atomické nebo strukturní. Strukturální hodnoty jsou konstruovány z hodnot nebo objektů reprezentovaných jejich identifikátory pomocí konstruktorů set, n-tice a seznam. Prvky strukturních hodnot jsou přístupné prostřednictvím předdefinovaných operací (primitiv).

Jsou možné dva druhy organizace dat: třídy, jejichž instance jsou objekty, které zapouzdřují data a chování, a typy, jejichž instancemi jsou hodnoty. Každá třída je spojena s typem, který popisuje strukturu instancí třídy. Typy jsou definovány rekurzivně na základě atomických typů a dříve definovaných typů a tříd pomocí konstruktorů. Behaviorální stránka třídy je definována sadou metod.

Objekty a hodnoty lze pojmenovat. Pojmenování objektu nebo hodnoty je spojeno s jeho dlouhodobým uložením (perzistencí): jakékoli pojmenované objekty nebo hodnoty jsou dlouhodobé; jakýkoli předmět nebo hodnota, která je součástí jiného pojmenovaného předmětu nebo hodnoty, je trvanlivá.

Pomocí speciální nápovědy dané při definování třídy je možné dosáhnout dlouhodobého uložení jakéhokoli objektu této třídy. V tomto případě systém automaticky vygeneruje nastavenou hodnotu, jejíž název je shodný s názvem třídy. Tato sada zaručeně obsahuje všechny objekty tato třída.

metoda - programovací kód Přidružený k určité třídě a aplikovatelný na objekty této třídy. Definování metody v O2 probíhá ve dvou krocích. Nejprve je deklarován podpis metody, tzn. jeho název, třídu, typy argumentů nebo třídy a typ nebo třídu výsledku. Metody mohou být veřejné (přístupné z objektů jiných tříd) nebo soukromé (přístupné pouze v rámci dané třídy). Ve druhé fázi je implementace třídy určena v jednom z programovacích jazyků O2 (jazyky jsou podrobněji popsány v další části naší recenze).

Model O2 podporuje vícenásobnou dědičnost tříd na základě vztahu nadtyp/podtyp. Je povoleno přidávat a/nebo předefinovat atributy a metody v podtřídě. Případné nejasnosti ve vícenásobné dědičnosti (pojmenováním atributů a metod) se řeší buď přejmenováním, nebo explicitním určením zdroje dědičnosti. Objekt podtřídy je objektem každé nadtřídy, ze které je podtřída odvozena.

Je podporována předdefinovaná třída "Object", která je kořenem mřížky tříd; jakákoli jiná třída je implicitním potomkem třídy "Object" a dědí předdefinované metody ("is_same", "is_value_equal" atd.).

Specifikem modelu O2 je možnost deklarovat další „exkluzivní“ atributy a metody pro pojmenované objekty. To znamená, že konkrétní pojmenovaná instance třídy může mít typ, který je podtypem typu třídy. Tyto atributy samozřejmě nefungují standardních metod třídy, ale konkrétně pro pojmenovaný objekt lze definovat další (nebo přepsané standardní) metody, pro které jsou již k dispozici další atributy. Je zdůrazněno, že další atributy a metody nejsou vázány na konkrétní objekt, ale na název, který mohou následovat různé objekty v různých časech. Implementace exkluzivních atributů a metod vyžaduje vývoj technik pozdního vázání.

V další části se mimo jiné budeme zabývat vlastnostmi programovacích jazyků a dotazů systému O2, které samozřejmě úzce souvisí se specifiky datového modelu.