Databázový model - Database model
Model databáze je typ datového modelu , který určuje logickou strukturu databáze . Zásadně určuje, jakým způsobem lze data ukládat, organizovat a manipulovat s nimi. Nejpopulárnějším příkladem databázového modelu je relační model , který používá formát založený na tabulce.
Typy
Mezi běžné logické datové modely pro databáze patří:
- Jedná se o nejstarší formu databázového modelu. Byl vyvinut společností IBM pro IMS (Information Management System). Je to soubor organizovaných dat ve stromové struktuře. Záznam DB je strom skládající se z mnoha skupin nazývaných segmenty. Používá jeden k mnoha vztahům. Přístup k datům je také předvídatelný.
- Síťový model
- Relační model
- Model entity – vztah
- Objektový model
- Dokumentový model
- Model entity – atribut – hodnota
- Hvězdné schéma
Objektově-relační databázi kombinuje dvě příbuzné struktury.
Fyzické datové modely zahrnují:
Mezi další modely patří:
- Asociativní model
- Korelační model
- Multidimenzionální model
- Vícehodnotový model
- Sémantický model
- XML databáze
- Pojmenovaný graf
- Triplestore
Vztahy a funkce
Daný systém správy databází může poskytovat jeden nebo více modelů. Optimální struktura závisí na přirozené organizaci dat aplikace a na požadavcích aplikace, které zahrnují rychlost transakce (rychlost), spolehlivost, udržovatelnost, škálovatelnost a náklady. Většina systémů pro správu databází je postavena na jednom konkrétním datovém modelu, i když je možné, že produkty nabízejí podporu pro více než jeden model.
Různé fyzické datové modely mohou implementovat jakýkoli daný logický model. Většina databázového softwaru nabídne uživateli určitou úroveň kontroly při ladění fyzické implementace, protože provedené volby mají významný vliv na výkon.
Model není jen způsob strukturování dat: definuje také sadu operací, které lze s daty provádět. Relační model například definuje operace, jako je výběr ( projekt ) a připojení . Ačkoli tyto operace nemusí být v konkrétním dotazovacím jazyce explicitní , poskytují základ, na kterém je postaven dotazovací jazyk.
Plochý model
Model byt (nebo stůl) se skládá z jednoho, dvou-rozměrné pole datových prvků, kde se předpokládá, že jsou podobné hodnoty všichni členové daný sloupec, a všichni členové řadě se předpokládá, že souvisejí s navzájem. Například sloupce pro jméno a heslo, které mohou být použity jako součást databáze zabezpečení systému. Každý řádek by měl konkrétní heslo přidružené k jednotlivému uživateli. Sloupce tabulky mají často přidružený typ, který je definuje jako znaková data, informace o datu nebo čase, celá čísla nebo čísla s plovoucí desetinnou čárkou. Tento tabulkový formát je předchůdcem relačního modelu.
Rané datové modely
Tyto modely byly populární v šedesátých, sedmdesátých letech minulého století, ale v dnešní době se nacházejí především ve starých starších systémech . Vyznačují se především navigací se silným spojením mezi jejich logickými a fyzickými reprezentacemi a nedostatky v nezávislosti na datech .
Hierarchický model
V hierarchickém modelu jsou data organizována do stromové struktury , což pro každého záznamu znamená jednoho rodiče. Pole řazení uchovává sourozenecké záznamy v určitém pořadí. Hierarchické struktury byly široce používány v počátečních systémech pro správu databází na sálových počítačích, jako je Information Management System (IMS) od IBM , a nyní popisují strukturu dokumentů XML . Tato struktura umožňuje vzájemný vztah mezi dvěma typy dat. Tato struktura je velmi účinná k popisu mnoha vztahů v reálném světě; recepty, obsah, řazení odstavců/veršů, vnořené a seřazené informace.
Tato hierarchie se používá jako fyzické pořadí záznamů v úložišti. Přístup k záznamům se provádí navigací dolů datovou strukturou pomocí ukazatelů kombinovaných se sekvenčním přístupem. Z tohoto důvodu je hierarchická struktura pro určité databázové operace neúčinná, pokud pro každý záznam není zahrnuta také úplná cesta (na rozdíl od pole pro odkaz nahoru a řazení). Takováto omezení byla v pozdějších verzích IMS kompenzována dalšími logickými hierarchiemi uloženými na základní fyzické hierarchii.
Síťový model
Síťový model rozšiřuje hierarchické struktuře, která umožňuje mnoho-to-many vztahy ve stromové struktuře, která umožňuje více rodičů. Byl nejpopulárnější, než byl nahrazen relačním modelem, a je definován specifikací CODASYL .
Síťový model organizuje data pomocí dvou základních konceptů, nazývaných záznamy a sady . Záznamy obsahují pole (která mohou být organizována hierarchicky, jako v programovacím jazyce COBOL ). Sady (neplést s matematickými sad) definují one-to-many vztahy mezi záznamů: jednoho majitele, mnoho členů. Záznam může být vlastníkem v libovolném počtu sad a členem v libovolném počtu sad.
Sada se skládá z kruhových propojených seznamů, kde se jeden typ záznamu, vlastník sady nebo rodič, objeví jednou v každém kruhu a druhý typ záznamu, podřízený nebo podřízený, se může v každém kruhu objevit vícekrát. Tímto způsobem lze vytvořit hierarchii mezi jakýmikoli dvěma typy záznamů, např. Typ A je vlastníkem B. Současně může být definována další sada, kde B je vlastníkem A. Všechny sady tedy obsahují obecný směrovaný graf (vlastnictví definuje směr) nebo síťová konstrukce. Přístup k záznamům je buď sekvenční (obvykle u každého typu záznamu), nebo pomocí navigace v kruhových propojených seznamech.
Síťový model je schopen reprezentovat redundanci v datech efektivněji než v hierarchickém modelu a od uzlu předchůdce k potomkovi může existovat více než jedna cesta. Operace síťového modelu jsou ve stylu navigace: program udržuje aktuální pozici a přechází z jednoho záznamu do druhého sledováním vztahů, kterých se záznam účastní. Záznamy lze také vyhledat zadáním klíčových hodnot.
Ačkoli to není základní funkce modelu, síťové databáze obecně implementují nastavené vztahy pomocí ukazatelů, které přímo řeší umístění záznamu na disku. To poskytuje vynikající výkon při načítání na úkor operací, jako je načítání databáze a reorganizace.
Produkty populární databázový systém, který využíval to bylo Cincom Systems ‚Celkem a Culliner ‘ s IDMS . IDMS získal značnou zákaznickou základnu; v 80. letech přijal kromě původních nástrojů a jazyků také relační model a SQL.
Většina objektových databází (vynalezených v devadesátých letech) používá navigační koncept k zajištění rychlé navigace v sítích objektů, přičemž obecně používají identifikátory objektů jako „chytré“ ukazatele na související objekty. Objektivita/DB například implementuje pojmenované vztahy typu jedna ku jedné, jedna k mnoha, mnoho k jedné a mnoho k mnoha pojmenovaným vztahům, které mohou procházet databázemi. Mnoho objektových databází také podporuje SQL , což kombinuje silné stránky obou modelů.
Model obráceného souboru
V obráceném souboru nebo invertovaném indexu jsou obsahy dat použity jako klíče ve vyhledávací tabulce a hodnoty v tabulce jsou ukazateli na umístění každé instance dané položky obsahu. Toto je také logická struktura současných databázových indexů , které mohou používat pouze obsah z konkrétních sloupců ve vyhledávací tabulce. Převrácený model, datový soubor můžete dát indexy v sadě souborů vedle stávajících plochých databázové soubory, aby se účinně přímo k potřebné záznamy v těchto souborech.
Tento datový model je pozoruhodný pomocí systému ADABAS DBMS společnosti Software AG , zavedeného v roce 1970. Společnost ADABAS si získala značnou zákaznickou základnu a existuje a je podporována dodnes. V osmdesátých letech přijal kromě svých původních nástrojů a jazyků také relační model a SQL.
Dokumentově orientovaná databáze Clusterpoint používá model invertovaného indexování k rychlému fulltextovému vyhledávání například pro datové objekty XML nebo JSON .
Relační model
.PNG)
Relační model byl představen EF Codd v roce 1970 jako způsob, jak vydělat systémů pro správu databází více nezávislé na jakékoliv konkrétní aplikaci. Jedná se o matematický model definovaný z hlediska predikátové logiky a teorie množin a jeho implementace byly používány sálovými, středními a mikropočítačovými systémy.
Produkty, které jsou obecně označovány jako relační databáze, ve skutečnosti implementují model, který je pouze aproximací matematického modelu definovaného Coddem. V modelech relačních databází se široce používají tři klíčové termíny: relace , atributy a domény . Relace je tabulka se sloupci a řádky. Pojmenované sloupce relace se nazývají atributy a doména je sada hodnot, které atributy mohou nabývat.
Základní datovou strukturou relačního modelu je tabulka, kde jsou informace o konkrétní entitě (řekněme zaměstnanci) zastoupeny v řádcích (nazývaných také řazené kolekce členů ) a sloupcích. „ Relace “ v „relační databázi“ tedy odkazuje na různé tabulky v databázi; relace je sada n -tic. Sloupce vyjmenovávají různé atributy entity (například jméno zaměstnance, adresu nebo telefonní číslo) a řádek je skutečnou instancí entity (konkrétního zaměstnance), která je reprezentována vztahem. Výsledkem je, že každá tuple tabulky zaměstnanců představuje různé atributy jednoho zaměstnance.
Všechny relace (a tedy tabulky) v relační databázi musí dodržovat některá základní pravidla, aby byly považovány za relace. Za prvé, pořadí sloupců je v tabulce nevýznamné. Za druhé, v tabulce nemohou být stejné n -tice ani řádky. A za třetí, každá n -tice bude obsahovat jednu hodnotu pro každý ze svých atributů.
Relační databáze obsahuje více tabulek, každou podobnou té v modelu „ploché“ databáze. Jednou ze silných stránek relačního modelu je, že v zásadě jakákoli hodnota vyskytující se ve dvou různých záznamech (patřících do stejné tabulky nebo do různých tabulek) implikuje vztah mezi těmito dvěma záznamy. Přesto, aby byla vynucena explicitní omezení integrity , vztahy mezi záznamy v tabulkách mohou být také definovány explicitně, identifikací nebo neidentifikací vztahů rodič-dítě charakterizovaných přiřazením mohutnosti (1: 1, (0) 1: M, M: M ). Tabulky mohou mít také určený jeden atribut nebo sadu atributů, které mohou fungovat jako „klíč“, který lze použít k jedinečné identifikaci každé n -tice v tabulce.
Klíč, který lze použít k jedinečné identifikaci řádku v tabulce, se nazývá primární klíč. Klíče se běžně používají ke spojování nebo kombinování dat ze dvou nebo více tabulek. Například zaměstnanec stůl může obsahovat sloupec s názvem Umístění který obsahuje hodnotu, která odpovídá klíč k umístění tabulky. Klíčové jsou také klíče při vytváření indexů, které usnadňují rychlé načítání dat z velkých tabulek. Libovolný sloupec může být klíčový, nebo lze více sloupců seskupit do složeného klíče. Není nutné předem definovat všechny klíče; sloupec lze použít jako klíč, i když jím původně nebyl zamýšlen.
Klíč, který má vnější, v reálném světě význam (například jméno osoby, kniha je ISBN , nebo sériové číslo automobilu) je někdy nazýván „přírodní“ klíč. Pokud není vhodný žádný přirozený klíč (přemýšlejte o mnoha lidech jménem Brown ), lze přiřadit libovolný nebo náhradní klíč (například poskytnutím identifikačních čísel zaměstnanců). V praxi má většina databází jak generované, tak přirozené klíče, protože generované klíče lze interně použít k vytváření odkazů mezi řádky, které se nedají přerušit, zatímco přirozené klíče lze použít, méně spolehlivě, pro vyhledávání a pro integraci s jinými databázemi. (Například záznamy ve dvou nezávisle vyvinutých databázích mohou být spárovány podle čísla sociálního zabezpečení , kromě případů, kdy jsou čísla sociálního zabezpečení nesprávná, chybí nebo se změnila.)
Nejběžnějším dotazovacím jazykem používaným u relačního modelu je Structured Query Language ( SQL ).
Rozměrový model
Trojrozměrný model je speciální úprava relační model použitý k reprezentaci dat v datových skladech tak, že data mohou být snadno shrnut pomocí on-line analytické zpracování nebo OLAP dotazy. V dimenzionálním modelu se databázové schéma skládá z jediné velké tabulky faktů, které jsou popsány pomocí dimenzí a měr. Dimenze poskytuje kontext skutečnosti (například kdo se zúčastnil, kdy a kde se to stalo a její typ) a používá se v dotazech ke seskupení souvisejících faktů dohromady. Dimenze bývají diskrétní a často jsou hierarchické; umístění může například zahrnovat budovu, stát a zemi. Míra je veličina popisující skutečnost, například příjmy. Je důležité, aby opatření bylo možné smysluplně agregovat - například příjmy z různých míst lze sčítat.
V dotazu OLAP jsou vybrány dimenze a fakta jsou seskupena a agregována k vytvoření souhrnu.
Dimenzionální model je často implementován nad relační model pomocí hvězdicového schématu , skládajícího se z jedné vysoce normalizované tabulky obsahující fakta a okolních denormalizovaných tabulek obsahujících každou dimenzi. Alternativní fyzická implementace, nazývaná schéma sněhové vločky , normalizuje víceúrovňové hierarchie v rámci dimenze do více tabulek.
Datový sklad může obsahovat více dimenzionálních schémat, která sdílí tabulky dimenzí, což umožňuje jejich společné použití. Přijetí standardní sady dimenzí je důležitou součástí dimenzionálního modelování .
Jeho vysoký výkon učinil z dimenzionálního modelu nejoblíbenější databázovou strukturu pro OLAP.
Post-relační databázové modely
Produkty nabízející obecnější datový model než relační model jsou někdy klasifikovány jako postrelační . Alternativní termíny zahrnují „hybridní databáze“, „objektově rozšířené RDBMS“ a další. Datový model v těchto produktech zahrnuje vztahy, ale není omezen informačním principem EF Codda , který vyžaduje, aby
všechny informace v databázi musí být obsazeny výslovně z hlediska hodnot ve vztazích a žádným jiným způsobem
-
Některá z těchto rozšíření relačního modelu integrují koncepty z technologií, které předcházejí datu relačního modelu. Například umožňují znázornění směrovaného grafu se stromy na uzlech. Německá společnost sones implementuje tento koncept do svého GraphDB .
Některé postrelační produkty rozšiřují relační systémy o nerelační funkce. Ostatní dorazili na téměř stejné místo přidáním relačních prvků do předrelačních systémů. Paradoxně to umožňuje produktům, které jsou historicky pre-relační, jako je PICK a MUMPS , učinit věrohodné tvrzení, že je postrelační.
Prostorový model prostředků (RSM) je nerelační datový model založený na vícerozměrné klasifikaci.
Grafický model
Grafové databáze umožňují ještě obecnější strukturu než síťová databáze; jakýkoli uzel může být připojen k jakémukoli jinému uzlu.
Vícehodnotový model
Vícehodnotové databáze jsou „hrudkovitá“ data, protože mohou ukládat přesně stejným způsobem jako relační databáze, ale také umožňují úroveň hloubky, kterou může relační model aproximovat pouze pomocí dílčích tabulek. To je téměř totožné se způsobem, jakým XML vyjadřuje data, kde dané pole/atribut může mít více správných odpovědí současně. Multivalue lze považovat za komprimovanou formu XML.
Příkladem je faktura, která může být ve vícehodnotových nebo relačních datech viděna jako (A) Tabulka záhlaví faktury - jeden záznam na fakturu a (B) Tabulka podrobností faktury - jeden záznam na řádkovou položku. V modelu s více hodnotami máme možnost ukládat data jako v tabulce, přičemž vložená tabulka představuje detail: (A) Tabulka faktur - jeden záznam na fakturu, žádné další tabulky nejsou potřeba.
Výhodou je, že atomičnost Faktury (koncepční) a Faktury (reprezentace dat) je individuální. Výsledkem je také menší počet čtení, méně problémů s referenční integritou a dramatický pokles hardwaru potřebného k podpoře daného objemu transakcí.
Objektově orientované databázové modely
V devadesátých letech bylo paradigma objektově orientovaného programování aplikováno na databázovou technologii a vytvořil nový databázový model známý jako objektové databáze . Cílem je zabránit nesouladu objektově -relační impedance - režii převodu informací mezi jejich reprezentací v databázi (například jako řádky v tabulkách) a její reprezentací v aplikačním programu (typicky jako objekty). Ještě dále lze typový systém používaný v konkrétní aplikaci definovat přímo v databázi, což umožňuje databázi vynucovat stejné invarianty integrity dat. Objektové databáze také zavádějí klíčové myšlenky objektového programování, jako je zapouzdření a polymorfismus , do světa databází.
Pro ukládání objektů do databáze byla vyzkoušena řada těchto způsobů. Některé produkty přistupovaly k problému od konce programování aplikací tím, že objekty manipulované programem byly trvalé . To obvykle vyžaduje přidání nějakého druhu dotazovacího jazyka, protože konvenční programovací jazyky nemají schopnost najít objekty na základě jejich informačního obsahu. Jiní zaútočili na problém od konce databáze definováním objektově orientovaného datového modelu pro databázi a definováním databázového programovacího jazyka, který umožňuje úplné programovací možnosti i tradiční dotazovací zařízení.
Objektové databáze utrpěly kvůli nedostatku standardizace: ačkoli standardy byly definovány ODMG , nikdy nebyly implementovány dostatečně dobře, aby byla zajištěna interoperabilita mezi produkty. Objektové databáze se však úspěšně používají v mnoha aplikacích: obvykle ve specializovaných aplikacích, jako jsou inženýrské databáze nebo databáze molekulární biologie, než v běžném komerčním zpracování dat. Myšlenky na objektovou databázi však zachytili relační prodejci a ovlivnili rozšíření těchto produktů a skutečně jazyka SQL .
Alternativou k překládání mezi objekty a relačními databázemi je použití knihovny ORM ( Object – Relational Mapping ).
