Pojem relačný (anglicky relationship - relationship) je spojený s vývojom známeho amerického špecialistu v oblasti databázových systémov, zamestnanca IBM, Dr. E. Codda (Codd EF, A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, jún 1970), ktorí prvýkrát použili termín "relačný dátový model".

Relačný prístup bol dlho považovaný za pohodlný formálny nástroj na analýzu databáz, ktorý nemal praktické vyhliadky, pretože jeho implementácia si vyžadovala príliš veľké strojové zdroje. Až s nástupom osobných počítačov sa začali rozširovať relačné a príbuzné systémy, ktoré nechávali len malý priestor pre iné modely.

Tieto modely sa vyznačujú jednoduchou dátovou štruktúrou, užívateľsky príjemnou tabuľkovou reprezentáciou a schopnosťou využívať na spracovanie dát formálny aparát relačnej algebry a relačného kalkulu.

Relačný model je zameraný na organizáciu údajov vo forme dvojrozmerných tabuliek. Každá relačná tabuľka je dvojrozmerné pole a má nasledujúce vlastnosti:

• - každý prvok tabuľky je jedným údajovým prvkom; neexistujú žiadne opakujúce sa skupiny;
• - všetky stĺpce v tabuľke sú homogénne, t.j. všetky prvky v stĺpci majú rovnaký typ (číselný, znakový atď.) a dĺžku;
• - každý stĺpec má jedinečný názov;
• - v tabuľke nie sú žiadne rovnaké riadky;
• - poradie riadkov a stĺpcov môže byť ľubovoľné. Tabuľka tohto druhu sa nazýva relácia.

Databáza vytvorená pomocou vzťahov sa nazýva relačná databáza.

Vzťahy sú prezentované ako tabuľky, ktorých riadky zodpovedajú n-ticám alebo záznamom a stĺpce zodpovedajú atribútom vzťahov, doménam, poliam.

Pole, ktorého každá hodnota jednoznačne identifikuje príslušný záznam, sa nazýva jednoduchý kľúč (pole kľúča). Ak sú záznamy jednoznačne definované hodnotami niekoľkých polí, potom má takáto databázová tabuľka zložený kľúč.

Ak chcete prepojiť dve relačné tabuľky, musíte zadať kľúč prvej tabuľky do kľúča druhej tabuľky (kľúče sa môžu zhodovať); v opačnom prípade musíte do štruktúry prvej tabuľky zaviesť cudzí kľúč - kľúč druhej tabuľky.

Po navrhnutí relačného dátového modelu E.F. Codd vytvoril aj nástroj na pohodlnú prácu s reláciami – relačná algebra. Každá operácia tejto algebry používa jednu alebo viac tabuliek (relácií) ako svoje operandy a vo výsledku vytvára novú tabuľku, t.j. umožňuje "rezať" alebo "lepiť" tabuľky.

To, čo zásadne odlišuje relačné modely od sieťových a hierarchických, možno povedať nasledovne: hierarchické a sieťové dátové modely majú spojenie podľa štruktúry a relačné majú spojenie podľa hodnoty.

Návrh databázy sa tradične považuje za veľmi náročnú úlohu. Relačné technológie výrazne zjednodušujú túto úlohu.

Oddelením logickej a fyzickej vrstvy systému zjednodušuje proces mapovania „vrstvy skutočného sveta“ do štruktúry, ktorú môže systém priamo podporovať. Pretože samotný relačný rámec je koncepčne jednoduchý, umožňuje implementáciu malých a/alebo jednoduchých (a teda ľahko vytvoriteľných) databáz, akými sú napríklad osobné databázy, ktoré by sa v starších, zložitejších systémoch nikdy ani nepovažovali za možné.

Teória a disciplína normalizácie môže pomôcť tým, že ukáže, čo sa stane, keď vzťahy nie sú prirodzene štruktúrované.

Relačný dátový model je vhodný najmä pre použitie v databázach distribuovanej architektúry – umožňuje prístup k akýmkoľvek informačným prvkom uloženým v uzloch počítačovej siete. Osobitnú pozornosť je potrebné venovať vysokoúrovňovému aspektu relačného prístupu, ktorým je viacnásobné spracovanie záznamov. Výrazne sa tým zvyšuje potenciál relačného prístupu, ktorý nie je možné dosiahnuť pri spracovávaní jedného záznamu naraz a predovšetkým ide o optimalizáciu.

Tento model vám umožňuje určiť:

• operácie na ukladanie a získavanie údajov;
• Obmedzenia súvisiace so zabezpečením integrity údajov.

Na zvýšenie efektivity práce v mnohých DBMS relačného typu boli prijaté obmedzenia, ktoré zodpovedajú prísnemu relačnému modelu.

Mnoho relačných DBMS prezentuje databázové súbory používateľovi v tabuľkovom formáte so záznamami ako riadkami a ich poliami ako stĺpcami. V tabuľkovej forme sa informácie vnímajú oveľa jednoduchšie. V databáze na fyzickej úrovni sú však dáta uložené spravidla v súboroch obsahujúcich sekvencie záznamov.

Hlavnou výhodou relačnej DBMS je možnosť spájať databázové súbory na základe určitých vzťahov.

Zo štrukturálneho hľadiska sú relačné modely jednoduchšie a homogénnejšie ako hierarchické a sieťové modely. V relačnom modeli každý doménový objekt zodpovedá jednému alebo viacerým vzťahom. Ak je potrebné explicitne definovať vzťah medzi objektmi, vyjadruje sa ako vzťah, v ktorom sú identifikátory súvisiacich objektov prítomné ako atribúty. V relatívnom modeli sú objekty predmetnej oblasti a väzby medzi nimi reprezentované rovnakými informačnými štruktúrami, čo značne zjednodušuje samotný model.

DBMS sa považuje za relačný, ak sú splnené tieto dve podmienky navrhnuté E. Coddom:

• podporuje štruktúru relačných údajov;
• · realizuje aspoň operácie výberu, projekcie a prepojenia vzťahov.

Následne vzniklo množstvo relačných DBMS, ktoré do určitej miery spĺňajú túto definíciu. Mnohé DBMS sú podstatnými rozšíreniami relačného modelu, zatiaľ čo iné sú zmiešané a podporujú viaceré datalogické modely.

K dnešnému dňu zostávajú relačné databázy najbežnejšie vďaka svojej jednoduchosti a prehľadnosti, a to ako v procese tvorby, tak aj na úrovni používateľa.

Hlavnou výhodou relačných databáz je kompatibilita s najpopulárnejším dotazovacím jazykom SQL.

Jediným dotazom v tomto jazyku môžete spojiť niekoľko tabuliek do dočasnej tabuľky a vystrihnúť z nej potrebné riadky a stĺpce (výber a zobrazenie). Keďže štruktúra tabuľky relačnej databázy je pre používateľov intuitívna, jazyk SQL je jednoduchý a ľahko sa učí. Relačný model má solídny teoretický základ, na ktorom je založený vývoj a implementácia relačných databáz. V dôsledku popularity generovanej úspechom relačného modelu sa SQL stal hlavným jazykom pre relačné databázy.

Zistili sa však aj nedostatky uvažovaného databázového modelu:

• - keďže všetky polia jednej tabuľky musia obsahovať konštantný počet polí vopred určených typov, je potrebné vytvárať ďalšie tabuľky, ktoré zohľadňujú jednotlivé charakteristiky prvkov pomocou cudzích kľúčov. Tento prístup značne komplikuje vytváranie akýchkoľvek zložitých vzťahov v databáze;
• - vysoká pracovná náročnosť manipulácie s informáciami a zmeny vzťahov.

RELAČNÁ DATABÁZA A JEJ VLASTNOSTI. TYPY VZŤAHOV MEDZI VZŤAHOVÝMI TABUĽKAMI

Relačná databáza je súbor vzájomne prepojených tabuliek, z ktorých každá obsahuje informácie o objektoch určitého typu. Riadok tabuľky obsahuje údaje o jednom objekte (napríklad produkt, zákazník) a stĺpce tabuľky popisujú rôzne charakteristiky týchto objektov - atribúty (napríklad názov, kód produktu, informácie o zákazníkovi). Záznamy, teda riadky tabuľky, majú rovnakú štruktúru – pozostávajú z polí, v ktorých sú uložené atribúty objektu. Každé pole, t. j. stĺpec, popisuje iba jednu charakteristiku objektu a má presne definovaný dátový typ. Všetky záznamy majú rovnaké polia, len zobrazujú rôzne informačné vlastnosti objektu.

V relačnej databáze musí mať každá tabuľka primárny kľúč, pole alebo kombináciu polí, ktoré jedinečne identifikujú každý riadok v tabuľke. Ak kľúč pozostáva z niekoľkých polí, nazýva sa zložený. Kľúč musí byť jedinečný a musí jednoznačne identifikovať položku. Jeden záznam možno nájsť podľa hodnoty kľúča. Kľúče sa tiež používajú na organizáciu informácií v databáze.

Tabuľky relačnej databázy musia spĺňať požiadavky relačnej normalizácie. Normalizácia vzťahov je formálnym aparátom obmedzení tvorby tabuliek, ktorý umožňuje eliminovať duplicitu, zabezpečuje konzistenciu údajov uložených v databáze a znižuje mzdové náklady na údržbu databázy.

Nechajte si vytvoriť tabuľku Študent, ktorá obsahuje tieto polia: číslo skupiny, celé meno, číslo záznamu, dátum narodenia, názov odboru, názov fakulty. Takáto organizácia ukladania informácií bude mať niekoľko nevýhod:

• duplikácia informácií (pre každého študenta sa opakuje názov odboru a fakulty), preto sa objem databázy zvýši;
• postup aktualizácie informácií v tabuľke je náročný, pretože je potrebné každú z nich upraviť záznamy v tabuľke.

Na odstránenie týchto nedostatkov je navrhnutá normalizácia tabuľky. Dostupné tri normálne formy vzťahov.

Prvá normálna forma. Relačná tabuľka sa zredukuje na prvú normálnu formu vtedy a len vtedy, ak žiadny z jej riadkov neobsahuje viac ako jednu hodnotu v žiadnom z jej polí a žiadne z jej kľúčových polí nie je prázdne. Ak teda chcete získať informácie z tabuľky Študent podľa mena študenta, potom by pole Celé meno malo byť rozdelené na časti Priezvisko, Meno, Patronymické meno.

Druhá normálna forma. Relačná tabuľka je definovaná v druhej normálnej forme, ak spĺňa požiadavky prvej normálnej formy a všetky jej polia, ktoré nie sú zahrnuté v primárnom kľúči, sú plne funkčne závislé od primárneho kľúča. Aby sa tabuľka dostala do druhej normálnej formy, je potrebné určiť funkčnú závislosť polí. Funkčná závislosť polí je závislosť, v ktorej iba jedna hodnota deskriptívneho atribútu zodpovedá určitej hodnote kľúčového atribútu v inštancii informačného objektu.

Tretia normálna forma. Tabuľka je v tretej normálnej forme, ak spĺňa požiadavky druhej normálnej formy a žiadne z jej nekľúčových polí nie je funkčne závislé od iných nekľúčových polí. Napríklad v tabuľke Žiak (Číslo skupiny, Celé meno, Číslo knihy, Dátum narodenia, Riaditeľ) sú v tranzitívnej závislosti tri polia - Číslo triedy, Číslo skupiny, Riaditeľ. Číslo skupiny závisí od čísla knihy záznamov a riaditeľ závisí od čísla skupiny. Na odstránenie tranzitívnej závislosti je potrebné preniesť niektoré polia tabuľky Študent do inej tabuľky Skupiny. Tabuľky budú mať nasledovnú formu: Študent (č. skupiny, celé meno, číslo v klasifikačnom liste, dátum narodenia), skupina (č. skupiny, riaditeľ).

S relačnými tabuľkami sú možné nasledujúce operácie:

• Zlučovanie tabuliek s rovnakou štruktúrou. Výsledkom je spoločná tabuľka: najprv prvá, potom druhá (reťazenie).
• Priesečník tabuliek s rovnakou štruktúrou. Výsledok - vyberú sa tie záznamy, ktoré sú v oboch tabuľkách.
• Odčítanie tabuliek s rovnakou štruktúrou. Výsledok - vyberú sa tie záznamy, ktoré nie sú v subtrahende.
• Vzorka (horizontálna podmnožina). Výsledok – vyberú sa záznamy, ktoré spĺňajú určité podmienky.
• Projekcia (vertikálna podmnožina). Výsledkom je relácia obsahujúca niektoré polia zo zdrojových tabuliek.
• Kartézsky súčin dvoch tabuliek Záznamy vo výslednej tabuľke sa získajú zreťazením každého záznamu v prvej tabuľke s každým záznamom v druhej tabuľke.

Relačné tabuľky môžu byť navzájom prepojené, takže údaje možno získavať z viacerých tabuliek súčasne. Tabuľky sú navzájom prepojené, aby sa v konečnom dôsledku zmenšila veľkosť databázy. Vzťah každej dvojice tabuliek je poskytnutý, ak majú rovnaké stĺpce.

Existujú nasledujúce typy informačných odkazov:

• jeden na jedného;
• jeden k mnohým;
• mnoho-k-mnohým.

Komunikácia jeden na jedného predpokladá, že jeden atribút prvej tabuľky zodpovedá iba jednému atribútu druhej tabuľky a naopak.

Vzťah jeden k mnohým predpokladá, že jeden atribút prvej tabuľky zodpovedá niekoľkým atribútom druhej tabuľky.

Vzťah medzi mnohými predpokladá, že jeden atribút prvej tabuľky zodpovedá niekoľkým atribútom druhej tabuľky a naopak.

Relačné databázy

Relačná databáza pozostáva z jednej alebo viacerých súvisiacich tabuliek, ktoré sú štruktúrované do stĺpcov a riadkov.

Relačné databázy používajú nasledujúcu notáciu:

Vzťah - tabuľka;

Pole - súbor záznamov rovnakého typu pre niekoľko objektov (stĺpec);

Tuple (záznam) - riadok tabuľky obsahujúci množinu niekoľkých záznamov zodpovedajúcich jednému objektu;

Atribút - záznam v riadku jedného poľa.

Entita - akýkoľvek rozlíšiteľný objekt, o ktorom sú informácie uložené v databáze.

Kľúčové polia

Každý databázový vzťah musí obsahovať pole (alebo kombináciu niekoľkých polí), ktoré jednoznačne identifikujú každý záznam vo vzťahu. Takéto polia vám umožňujú prepojiť údaje z niekoľkých vzťahov a v konečnom dôsledku vytvoriť jednu databázu. Tieto polia sa nazývajú kľúčové polia.

Existujú nasledujúce typy kľúčov:

Potenciálny kľúč- pole, ktorého atribúty zabezpečujú jedinečnosť záznamu (takýchto polí môže byť viacero).

primárny kľúč- jeden z potenciálnych kľúčov vybraný ako hlavný (spravidla má minimálnu dĺžku atribútu).

Cudzí (sekundárny) kľúč Jedno alebo viac polí vo vzťahu, ktoré poskytujú prepojenie na primárny kľúč iného vzťahu.

V závislosti od počtu polí tvoriacich kľúč existujú:

jednoduchý kľúč- pozostáva z jedného atribútu, ktorý jednoznačne identifikuje záznam (číslo evidenčnej knihy študenta).

Kompozitný kľúč- pozostáva z dvoch alebo viacerých atribútov, ktorých súhrn jednoznačne určuje záznam (séria a číslo pasu osoby).

Ak má vzťah jedinečné pole, ktoré jedinečne identifikuje každý záznam vo vzťahu, možno ho použiť ako primárny kľúč, ale hodnoty jeho atribútov sa musia pre všetky záznamy líšiť. Mená ani priezviská ľudí by ste nemali používať ako primárny kľúč, pretože sa môžu opakovať a v jednom vzťahu sa môžu objaviť osoby s rovnakým menom a priezviskom. Aj keď sú v súčasnosti priezviská všetkých osôb zaregistrovaných v databáze odlišné, pole priezviska by sa nemalo používať ako kľúčové pole, pretože záznamy vo vzťahu sa môžu časom meniť v dôsledku zmien v zložení zaznamenaných osôb. v databázach.

Pri výbere primárneho kľúča by ste mali brať do úvahy aj to, že atribúty poľa kľúča nemôžu byť prázdne. Ak pole povoľuje hodnoty null, nemalo by sa používať ako primárny kľúč.

Pri výbere primárneho kľúča je tiež potrebné mať na pamäti, že jeho hodnoty by sa nemali meniť. Ak sa zmení, potom je potrebné zabezpečiť, aby informácie o tejto zmene boli aktualizované vo všetkých ohľadoch súvisiacich s týmto poľom. Použitie primárneho kľúča s konštantnou hodnotou uľahčuje synchronizáciu medzi vzťahmi v databáze.

Často sa ako primárny kľúč vyberá umelo vytvorené pole, ktorého hodnoty atribútov v skutočnosti nedávajú zmysel. Tieto polia môžu byť Kód alebo číslo, tieto polia obsahujú len číselné označenie riadku a často toto označenie nastavuje počítač pomocou počítadla. Takéto kódy sa na rozdiel od polí obsahujúcich skutočné údaje nemenia, pretože Priezvisko, telefónne číslo, adresa atď. sa môže meniť a opakovať.

V prípade, že jedinečnosť záznamu nemožno zabezpečiť jedným poľom, použije sa zložený kľúč, tvorený dvomi alebo viacerými poľami. Príkladom zloženého kľúča môžu byť polia s číslom série a čísla pasu, samostatne číslo série a číslo pasu nemôže zaručiť jedinečnosť záznamu, pretože existujú pasy s rovnakou sériou, ako aj s rovnakým číslom, ale súčasná zhoda série a počtu dvoch pasov je nemožná.

Relačná databáza - základné pojmy

Často, keď hovoríme o databáze, majú na mysli jednoducho nejaký druh automatizovaného ukladania údajov. Táto reprezentácia nie je úplne správna. Prečo je to tak, ukážeme nižšie.

V užšom zmysle slova je databáza určitý súbor údajov potrebných na prácu (aktuálne údaje). Údaje sú však abstrakciou; nikto nikdy nevidel „len dáta“; nevznikajú a neexistujú samy od seba. Dáta sú odrazom objektov reálneho sveta. Ak chcete napríklad uložiť informácie o dieloch prijatých na sklad. Ako sa v databáze zobrazí objekt skutočného sveta – detail? Aby ste mohli odpovedať na túto otázku, musíte vedieť, aké vlastnosti alebo aspekty časti budú relevantné, potrebné pre prácu. Medzi nimi môže byť názov dielu, jeho hmotnosť, rozmery, farba, dátum výroby, materiál, z ktorého je vyrobený atď. V tradičnej terminológii sa objekty reálneho sveta, o ktorých sú informácie uložené v databáze, nazývajú entity (nech toto slovo čitateľa nevystraší - ide o všeobecne akceptovaný pojem) a ich skutočné vlastnosti sa nazývajú atribúty.

Každá vlastnosť konkrétneho objektu je hodnotou atribútu. Napríklad motorová časť má hodnotu hmotnostného atribútu 50, čo odráža fakt, že tento motor váži 50 kilogramov.

Bolo by chybou predpokladať, že v databáze sa odrážajú iba fyzické objekty. Dokáže absorbovať informácie o abstrakciách, procesoch, javoch – teda o všetkom, s čím sa človek pri svojej činnosti stretáva. Takže napríklad databáza môže uchovávať informácie o objednávkach na dodávku dielov do skladu (hoci nejde o fyzický objekt, ale o proces). Atribútmi entity „objednávka“ bude názov dodávaného dielu, množstvo dielov, názov dodávateľa, dodacia lehota a pod.

Objekty reálneho sveta sú navzájom prepojené mnohými zložitými závislosťami, ktoré treba brať do úvahy pri informačných aktivitách. Napríklad diely dodávajú do skladu ich výrobcovia. Preto musí byť medzi atribútmi dielu zahrnutý aj atribút „názov výrobcu“. To však nestačí, pretože môžu byť potrebné ďalšie informácie o výrobcovi konkrétneho dielu - jeho adresa, telefónne číslo atď. To znamená, že databáza musí obsahovať nielen informácie o dieloch a objednávkach, ale aj informácie o ich výrobcoch. Okrem toho by databáza mala odrážať vzťahy medzi dielmi a výrobcami (každý diel vyrába špecifický výrobca) a medzi objednávkami a dielmi (každá objednávka sa robí na konkrétny diel). Všimnite si, že v databáze by mali byť uložené iba relevantné, zmysluplné vzťahy.

V najširšom zmysle slova je teda databáza súborom popisov objektov reálneho sveta a vzťahov medzi nimi, ktoré sú relevantné pre určitú oblasť použitia. V nasledujúcom texte budeme vychádzať z tejto definície a v priebehu prezentácie ju spresníme.

Relačný dátový model

Takže sme získali predstavu o tom, čo je uložené v databáze. Teraz musíme pochopiť, ako sa entity, atribúty a vzťahy mapujú na dátové štruktúry. Toto je určené dátovým modelom.

Tradične sú všetky DBMS klasifikované podľa základného dátového modelu. Je zvykom vyčleniť hierarchické, sieťové a relačné dátové modely. Niekedy sa k nim pridáva dátový model zoznamu príspevkov. V súlade s tým hovoria o hierarchickom, sieťovom, relačnej DBMS alebo DBMS založenej na zoznamoch príspevkov.

Z hľadiska prevalencie a popularity sú dnes relačné DBMS mimo konkurencie. Stali sa de facto priemyselným štandardom, a preto sa domáci používateľ bude musieť vo svojej praxi vysporiadať s relačným DBMS. Poďme sa rýchlo pozrieť na relačný dátový model bez toho, aby sme sa ponorili do jeho detailov.

Vyvinul ho Codd ešte v rokoch 1969-70 na základe matematickej teórie vzťahov a je založený na systéme pojmov, z ktorých najdôležitejšie sú tabuľka, vzťah, riadok, stĺpec, primárny kľúč, cudzí kľúč.

Relačná databáza je taká databáza, v ktorej sa používateľovi prezentujú všetky údaje vo forme pravouhlých tabuliek údajových hodnôt a všetky operácie s databázou sú zredukované na manipuláciu s tabuľkami. Tabuľka sa skladá z riadkov a stĺpcov a má názov, ktorý je v rámci databázy jedinečný. Tabuľka odráža typ objektu reálneho sveta (entitu) a každý riadok predstavuje konkrétny objekt. Tabuľka Diel teda obsahuje informácie o všetkých dieloch uložených v sklade a jej riadky sú sady hodnôt atribútov pre konkrétne diely. Každý stĺpec tabuľky je množina hodnôt konkrétneho atribútu objektu. Stĺpec Materiál je teda súborom hodnôt „Oceľ“, „Cín“, „Zinok“, „Nikel“ atď. Stĺpec Množstvo obsahuje nezáporné celé čísla. Hodnoty v stĺpci Hmotnosť sú reálne čísla, ktoré sa rovnajú hmotnosti dielu v kilogramoch.

Tieto hodnoty sa neobjavia z ničoho nič. Vyberajú sa z množiny všetkých možných hodnôt pre atribút objektu, ktorý sa nazýva doména. Hodnoty v stĺpci materiál sa teda vyberajú z množiny názvov všetkých možných materiálov - plasty, drevo, kovy atď. Preto je v zásade nemožné, aby sa v stĺpci Materiál objavila hodnota, ktorá nie je v príslušnej doméne, napríklad „voda“ alebo „piesok“.

Každý stĺpec má názov, ktorý je zvyčajne napísaný v hornej časti tabuľky ( Ryža. jeden). Musí byť jedinečný v rámci tabuľky, ale rôzne tabuľky môžu mať stĺpce s rovnakým názvom. Každá tabuľka musí mať aspoň jeden stĺpec; Stĺpce sú v tabuľke usporiadané podľa poradia, v akom sa ich názvy zobrazujú pri vytváraní tabuľky. Na rozdiel od stĺpcov riadky nemajú názvy; ich poradie v tabuľke nie je definované a ich počet nie je logicky obmedzený.

Obrázok 1. Základné pojmy databázy.

Keďže riadky v tabuľke nie sú zoradené, nie je možné vybrať riadok podľa jeho polohy - medzi nimi nie je „prvý“, „druhý“, „posledný“. Každá tabuľka má jeden alebo viac stĺpcov, ktorých hodnoty jednoznačne identifikujú každý z jej riadkov. Takýto stĺpec (alebo kombinácia stĺpcov) sa nazýva primárny kľúč. V tabuľke dielov je primárnym kľúčom stĺpec Číslo dielu. V našom príklade má každý diel v sklade jedno číslo, podľa ktorého sa potrebné informácie získavajú z tabuľky dielov. Preto je v tejto tabuľke primárnym kľúčom stĺpec Číslo dielu. Hodnoty v tomto stĺpci nemožno duplikovať – v tabuľke dielov nesmú byť riadky, ktoré majú rovnakú hodnotu v stĺpci Číslo dielu. Ak tabuľka spĺňa túto požiadavku, nazýva sa relácia.

Vzťah tabuliek je základným prvkom relačného dátového modelu. Je podporovaný cudzími kľúčmi. Uvažujme o príklade, v ktorom databáza ukladá informácie o bežných zamestnancoch (tabuľka zamestnancov) a manažéroch (tabuľka manažérov) v organizácii ( Ryža. 2). Primárnym kľúčom tabuľky Manažér je stĺpec Číslo (napríklad osobné číslo). Stĺpec Priezvisko nemôže slúžiť ako primárny kľúč, pretože dvaja manažéri s rovnakým priezviskom môžu pracovať v rovnakej organizácii. Každý zamestnanec je podriadený jedinému vedúcemu, čo by sa malo prejaviť v databáze. Tabuľka Zamestnanec obsahuje stĺpec Číslo manažéra a hodnoty v tomto stĺpci sa vyberajú zo stĺpca Číslo v tabuľke Manažér (pozri obrázok 1). Ryža. 2). Stĺpec Číslo manažéra je cudzí kľúč v tabuľke Zamestnanec.

Obrázok 2. Vzťah databázových tabuliek.

Tabuľky nemožno ukladať a spracovávať, ak v databáze nie sú žiadne „údaje o údajoch“, ako sú deskriptory tabuliek, deskriptory stĺpcov atď. Zvyčajne sa nazývajú metadáta. Metadáta sú tiež prezentované v tabuľkovej forme a uložené v dátovom slovníku.

Okrem tabuliek môžu byť v databáze uložené aj ďalšie objekty, ako sú formuláre obrazovky, zostavy (zostavy), pohľady (pohľady) a dokonca aj aplikácie, ktoré pracujú s databázou.

Používateľom informačného systému nestačí, že databáza iba odráža objekty reálneho sveta. Je dôležité, aby takáto reflexia bola jednoznačná a konzistentná. V tomto prípade sa hovorí, že databáza spĺňa podmienku integrity.

Aby bola zaručená správnosť a vzájomná konzistentnosť údajov, sú na databázu uvalené určité obmedzenia, ktoré sa nazývajú obmedzenia integrity údajov.

Existuje niekoľko typov obmedzení integrity. Vyžaduje sa napríklad, aby sa hodnoty v stĺpci tabuľky vyberali iba z príslušnej domény. V praxi sa berú do úvahy komplexnejšie obmedzenia integrity, napríklad referenčná integrita. Jeho podstata spočíva v tom, že cudzí kľúč nemôže byť ukazovateľom na neexistujúci riadok v tabuľke. Obmedzenia integrity sa implementujú pomocou špeciálnych nástrojov, o ktorých sa bude diskutovať v Sek.Databázový server .

jazyk SQL

Samotné údaje v počítačovej forme nie sú pre používateľa zaujímavé, ak nie sú k dispozícii žiadne prostriedky na prístup k nim. Prístup k údajom je realizovaný formou dotazov do databázy, ktoré sú formulované v štandardnom dotazovacom jazyku. Dnes je pre väčšinu DBMS týmto jazykom SQL.

Vznik a vývoj tohto jazyka ako prostriedku na popis prístupu k databáze je spojený s vytvorením teórie relačných databáz. Prototyp jazyka SQL vznikol v roku 1970 ako súčasť výskumného projektu System / R, na ktorom sa pracovalo v laboratóriu IBM Santa Teresa. SQL je teraz štandardom pre rozhranie so systémami správy relačných databáz. Jeho popularita je taká veľká, že vývojári nerelačných DBMS (napríklad Adabas) dodávajú svojim systémom SQL rozhranie.

Jazyk SQL má oficiálny štandard - ANSI/ISO. Väčšina vývojárov DBMS dodržiava tento štandard, ale často ho rozširuje o implementáciu nových možností spracovania údajov. Nové mechanizmy správy údajov, ktoré budú popísané v Sek.Databázový server , možno použiť iba prostredníctvom špeciálnych príkazov SQL, ktoré nie sú všeobecne zahrnuté v jazykovej norme.

SQL nie je programovací jazyk vo svojej tradičnej forme. Nepíšu sa na ňom programy, ale dopyty do databázy. Preto je SQL deklaratívny jazyk. To znamená, že môže byť použitý na formulovanie toho, čo je potrebné získať, ale nemôže naznačovať, ako by sa to malo robiť. Najmä na rozdiel od procedurálnych programovacích jazykov (C, Pascal, Ada) SQL neobsahuje také príkazy ako if-then-else, for, while atď.

Nebudeme sa podrobne zaoberať syntaxou jazyka. Dotkneme sa ho len v rozsahu potrebnom na pochopenie jednoduchých príkladov. S ich pomocou budú znázornené najzaujímavejšie mechanizmy spracovania údajov.

SQL dotaz pozostáva z jedného alebo viacerých príkazov, ktoré sú oddelené bodkočiarkou. Tabuľka 1 nižšie uvádza najdôležitejšie operátory, ktoré sú súčasťou štandardu ANSI/ISO SQL.

Tabuľka 1. Základné operátory jazyka SQL.

SQL dotazy používajú názvy, ktoré jednoznačne identifikujú databázové objekty. Ide najmä o názov tabuľky (Detail), názov stĺpca (Name), ako aj názvy ďalších objektov v databáze, ktoré patria do doplnkových typov (napríklad názvy procedúr a pravidiel), ktoré budú diskutované v Sek.Databázový server . Spolu s jednoduchými názvami sa používajú aj zložité názvy - napríklad kvalifikovaný názov stĺpca definuje názov stĺpca a názov tabuľky, do ktorej patrí (Detail.Weight). Pre jednoduchosť budú v príkladoch názvy napísané v ruštine, hoci v praxi sa to neodporúča.

Každý stĺpec v akejkoľvek tabuľke ukladá určité typy údajov. Existujú základné dátové typy – reťazce znakov s pevnou dĺžkou, celé čísla a reálne čísla a ďalšie dátové typy – reťazce znakov s premenlivou dĺžkou, menové jednotky, dátum a čas, logické dáta (dve hodnoty – „TRUE“ a „FALSE“ ). V SQL môžete použiť číselné, reťazcové, znakové, dátumové a časové konštanty.

Pozrime sa na pár príkladov.

Dotaz „určiť počet dielov na sklade pre všetky typy dielov“ je implementovaný nasledovne:

VYBERTE názov, množstvo

OD Detail;

Výsledkom dopytu bude tabuľka s dvoma stĺpcami – Názov a Množstvo, ktoré sú prevzaté z pôvodnej tabuľky Detail. Tento dotaz vám v podstate umožňuje získať vertikálnu projekciu pôvodnej tabuľky (presnejšie vertikálnu podmnožinu množiny riadkov tabuľky). Zo všetkých riadkov tabuľky podrobností sa vytvoria riadky, ktoré obsahujú hodnoty prevzaté z dvoch stĺpcov – Názov a Množstvo.

Dotaz „aké diely vyrobené z ocele sa uchovávajú na sklade?“, formulovaný v SQL, vyzerá takto:

OD Detail

WHERE Materiál = "oceľ";

Výsledkom tohto dotazu bude aj tabuľka obsahujúca len tie riadky v zdrojovej tabuľke, ktoré majú v stĺpci Materiál hodnotu „Oceľ“. Tento dotaz vám umožňuje získať horizontálnu projekciu tabuľky podrobností (hviezdička v príkaze SELECT znamená, že sú vybraté všetky stĺpce z tabuľky).

Dotaz „určte názov a počet dielov na sklade, ktoré sú vyrobené z plastu a vážia menej ako päť kilogramov“ by bol napísaný takto:

VYBERTE názov, množstvo

OD Detail

KDE Materiál = "Plast"

A Hmotnosť< 5;

Výsledkom dopytu je tabuľka s dvoma stĺpcami – Názov, Množstvo, ktorá obsahuje názov a počet dielov vyrobených z plastu s hmotnosťou menšou ako 5 kg. Operácia výberu je v skutočnosti operácia, pri ktorej sa najprv vytvorí horizontálna projekcia (nájdite všetky riadky tabuľky dielov, pre ktoré je materiál = "plast" a hmotnosť< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Indexy sú jedným z nástrojov, ktoré poskytujú rýchly prístup k tabuľkám. Index je štruktúra databázy, ktorá je ukazovateľom na konkrétny riadok tabuľky. Databázový index sa používa rovnakým spôsobom ako indexový index v knihe. Obsahuje hodnoty prevzaté z jedného alebo viacerých stĺpcov konkrétneho riadka tabuľky a odkaz na tento riadok. Hodnoty v indexe sú usporiadané, čo umožňuje DBMS rýchlo vyhľadať tabuľku.

Predpokladajme, že dopyt je formulovaný do databázy Warehouse:

SELECT Názov Množstvo, Materiál

OD Detail

WHERE Číslo = "T145-A8";

Ak pre túto tabuľku neexistujú žiadne indexy, na vykonanie tohto dotazu musí DBMS prehľadať celú tabuľku podrobností, postupne z nej vyberať riadky a kontrolovať podmienky výberu pre každý z nich. Pri veľkých tabuľkách bude dokončenie takéhoto dotazu trvať veľmi dlho.

Ak bol predtým vytvorený index v stĺpci Číslo detailu tabuľky, potom sa čas vyhľadávania v tabuľke skráti na minimum. Index bude obsahovať hodnoty zo stĺpca Number a odkaz na riadok s touto hodnotou v tabuľke Part. Pri vykonávaní dotazu DBMS najskôr nájde v indexe hodnotu „T145-A8“ (a urobí to rýchlo, pretože index je usporiadaný a jeho riadky sú malé) a potom určí fyzické umiestnenie hľadaného riadku. odkazom v indexe.

Index sa vytvorí pomocou príkazu SQL CREATE INDEX. V tomto príklade operátor

VYTVORTE UNIKÁTNY INDEX Index dielov

ON Detail (číslo);

vytvorí index s názvom "Index dielov" v stĺpci Číslo tabuľky dielov.

Pre užívateľa DBMS nie sú zaujímavé jednotlivé príkazy jazyka SQL, ale nejaká ich postupnosť, navrhnutá ako jeden celok a dávajúca z jeho pohľadu zmysel. Každá takáto sekvencia SQL príkazov implementuje určitú akciu v databáze. Vykonáva sa v niekoľkých krokoch, z ktorých každý vykonáva nejaké operácie s databázovými tabuľkami. Takže v bankovom systéme sa prevod určitej sumy z krátkodobého účtu na dlhodobý vykonáva v niekoľkých operáciách. Medzi nimi - výber sumy z krátkodobého účtu, pripísanie na dlhodobý účet.

Ak dôjde k zlyhaniu v procese vykonávania tejto akcie, napríklad keď je prvá operácia dokončená, ale druhá nie, peniaze sa stratia. Preto musí byť akákoľvek akcia s databázou vykonaná úplne alebo vôbec. Táto akcia sa nazýva transakcia.

Spracovanie transakcií sa spolieha na protokol, ktorý sa používa na vrátenie transakcií a obnovenie stavu databázy. Viac podrobností o transakciách sa bude diskutovať v Sek.Spracovanie transakcie .

Na záver diskusie o jazyku SQL ešte raz zdôrazňujeme, že ide o dopytovací jazyk. Nemôžete napísať žiadny zložitý aplikačný program, ktorý pracuje s databázou. Na tento účel moderné DBMS používajú jazyk štvrtej generácie (Forth Generation Language - 4GL), ktorý má hlavné vlastnosti tretej generácie procedurálnych jazykov (3GL), ako sú C, Pascal, Ada, a schopnosť vložiť SQL. príkazy v texte programu, ako aj ovládacie prvky používateľského rozhrania (menu, formuláre, vstup používateľa atď.). Dnes je 4GL jedným z de facto štandardov nástrojov na vývoj databázových aplikácií.

• Preklad

Poznámka prekladateľa: aj keď je článok dosť starý (publikovaný pred 2 rokmi) a má veľké meno, stále poskytuje dobrú predstavu o rozdieloch medzi relačnými databázami a databázami NoSQL, ich výhodách a nevýhodách a poskytuje aj stručný prehľad nerelačného ukladania.

V poslednej dobe sa objavilo veľa nerelačných databáz. To naznačuje, že ak chcete prakticky neobmedzenú škálovateľnosť na požiadanie, potrebujete nerelačnú databázu.

Ak je to pravda, znamená to, že výkonné relačné databázy sa stali zraniteľnými? Znamená to, že časy relačných databáz sú a čoskoro budú preč? V tomto článku sa pozrieme na populárny trend nerelačných databáz v rôznych situáciách a uvidíme, či to ovplyvňuje budúcnosť relačných databáz.

Relačné databázy existujú približne 30 rokov. Počas tejto doby vypuklo niekoľko revolúcií, ktoré mali skoncovať s relačným ukladaním. Samozrejme, žiadna z týchto revolúcií sa nekonala a žiadna neotriasla pozíciou relačných databáz ani o kúsok.

Začnime so základmi

Relačná databáza je množina tabuliek (entít). Tabuľky sa skladajú zo stĺpcov a riadkov (dvojíc). V rámci tabuliek je možné definovať obmedzenia, medzi tabuľkami existujú vzťahy. Pomocou SQL môžete spúšťať dotazy, ktoré vracajú množiny údajov získaných z jednej alebo viacerých tabuliek. V rámci jedného dotazu sa získavajú údaje z viacerých tabuliek ich spájaním (JOIN), na spájanie sa najčastejšie používajú rovnaké stĺpce, ktoré definujú vzťahy medzi tabuľkami. Normalizácia je proces štruktúrovania dátového modelu, aby sa zabezpečila koherencia a nedostatok redundancie v dátach.

K relačným databázam sa pristupuje prostredníctvom systémov riadenia relačných databáz (RDBMS). Takmer všetky databázové systémy, ktoré používame, sú relačné, ako napríklad Oracle, SQL Server, MySQL, Sybase, DB2, TeraData atď.

Dôvody tejto dominancie nie sú zrejmé. Počas existencie relačných databáz neustále ponúkali najlepšiu kombináciu jednoduchosti, stability, flexibility, výkonu, škálovateľnosti a interoperability pri správe údajov.

Na poskytovanie všetkých týchto funkcií sú však relačné obchody vnútorne neuveriteľne zložité. Napríklad jednoduchý dotaz SELECT môže mať stovky potenciálnych ciest vykonávania, ktoré optimalizátor vyhodnocuje v čase dotazu. Toto všetko je pred používateľmi skryté, ale interne RDBMS vytvára plán vykonávania založený na veciach, ako sú algoritmy odhadu nákladov, ktoré najlepšie zodpovedajú dopytu.

Problémy relačných databáz

Zatiaľ čo relačné obchody poskytujú najlepšiu kombináciu jednoduchosti, odolnosti, flexibility, výkonu, škálovateľnosti a interoperability, nemusia nevyhnutne prekonávať podobné systémy zamerané na jednu funkciu v žiadnej z týchto oblastí. Nebol to veľký problém, keďže celková dominancia relačných DBMS prevážila nad akýmikoľvek nedostatkami. Ak však konvenčné RDB nespĺňali potreby, vždy existovali alternatívy.

Dnes je situácia trochu iná. Rozmanitosť aplikácií rastie a s tým rastie aj význam týchto funkcií. A ako počet databáz rastie, jedna funkcia začína zatieniť všetky ostatné. Toto je škálovateľnosť. Keďže stále viac aplikácií beží pod veľkým zaťažením, ako sú webové služby, ich požiadavky na škálovateľnosť sa môžu veľmi rýchlo meniť a rásť. Prvý problém môže byť veľmi ťažké vyriešiť, ak máte relačnú databázu hosťovanú na svojom vlastnom serveri. Predpokladajme, že zaťaženie servera sa cez noc strojnásobí. Ako rýchlo môžete upgradovať hardvér? Riešenie druhého problému spôsobuje ťažkosti aj v prípade použitia relačných databáz.

Relačné databázy sa dobre škálujú iba vtedy, ak sú umiestnené na jednom serveri. Keď sa prostriedky tohto servera vyčerpajú, budete musieť pridať ďalšie počítače a rozložiť záťaž medzi ne. A tu začína hrať komplexnosť relačných databáz proti škálovateľnosti. Ak sa pokúsite zvýšiť počet serverov nie na niekoľko, ale na sto alebo tisíc, zložitosť sa rádovo zvýši a vlastnosti, vďaka ktorým sú relačné databázy také atraktívne, rapídne znížia šance na ich použitie ako platformy. pre veľké distribuované systémy na nulu.

Aby si predajcovia cloudových služieb udržali konkurencieschopnosť, musia sa s týmto obmedzením nejako vysporiadať, pretože čo je cloudová platforma bez škálovateľného úložiska dát. Preto majú predajcovia iba jednu možnosť, ak chcú používateľom poskytnúť škálovateľný úložný priestor. Musíte použiť iné typy databáz, ktoré majú vyššiu schopnosť škálovania, aj keď za cenu iných funkcií dostupných v relačných databázach.

Tieto výhody, ako aj existujúci dopyt po nich, viedli k vlne nových systémov správy databáz.

Nová vlna

Tento typ databázy sa bežne označuje ako úložisko hodnôt kľúča. V skutočnosti neexistuje žiadny oficiálny názov, takže ho môžete vidieť v kontexte distribuovaných databáz orientovaných na dokumenty, atribúty (hoci môžu byť aj relačné), rozdelených triedených polí, distribuovaných hašovacích tabuliek a obchodov. typ hodnoty. Aj keď každý z týchto názvov odkazuje na špecifické funkcie systému, všetky sú variáciami toho, čo budeme nazývať obchod s hodnotou kľúča.

Akokoľvek to chcete nazvať, tento „nový“ typ databázy nie je až taký nový a vždy sa používal hlavne pre aplikácie, pre ktoré by bolo použitie relačných databáz nevhodné. Bez potreby škálovateľnosti webu a cloudu však tieto systémy zostali málo žiadané. Teraz je úlohou určiť, ktorý typ úložiska je vhodnejší pre konkrétny systém.
Relačné databázy a sklady kľúč-hodnota sú zásadne odlišné a sú navrhnuté tak, aby riešili rôzne problémy. Porovnanie charakteristík vám umožní pochopiť rozdiel medzi nimi, ale začnime týmto:

Vlastnosti skladovania

Relačná databáza	Úložisko párov kľúč – hodnota
Databáza sa skladá z tabuliek, tabuľky obsahujú stĺpce a riadky a riadky sa skladajú z hodnôt stĺpcov. Všetky riadky jednej tabuľky majú rovnakú štruktúru.	Pre domény môžete nakresliť analógiu s tabuľkami, ale na rozdiel od tabuliek domény nedefinujú dátovú štruktúru. Doména je schránka, do ktorej môžete vložiť čokoľvek chcete. Záznamy v rámci tej istej domény môžu mať rôznu štruktúru.
Dátový model 1 je preddefinovaný. Je silne typovaný, obsahuje obmedzenia a vzťahy na zabezpečenie integrity údajov.	Záznamy sú identifikované kľúčom, pričom každý záznam má priradený dynamický súbor atribútov.
Dátový model je založený na prirodzenej reprezentácii obsiahnutých údajov, nie na funkčnosti aplikácie.	V niektorých implementáciách môžu byť atribúty iba reťazce. V iných implementáciách majú atribúty jednoduché dátové typy, ktoré odrážajú typy používané pri programovaní: celé čísla, polia reťazcov a zoznamy.
Dátový model je normalizovaný, aby sa zabránilo duplicite údajov. Normalizácia generuje vzťahy medzi tabuľkami. Vzťahy spájajú údaje z rôznych tabuliek.	Vzťahy medzi doménami, ako aj v rámci jednej domény nie sú explicitne definované.

Žiadne pripojenia

Obchody s hodnotou kľúča sú orientované na záznamy. To znamená, že všetky informácie súvisiace s daným záznamom sú uložené spolu s ním. Doména (ktorú si môžete predstaviť ako tabuľku) môže obsahovať nespočetné množstvo rôznych položiek. Doména môže napríklad obsahovať informácie o zákazníkoch a objednávkach. To znamená, že údaje majú tendenciu byť duplikované v rôznych doménach. Toto je prijateľný prístup, pretože miesto na disku je lacné. Hlavná vec je, že umožňuje ukladať všetky súvisiace údaje na jednom mieste, čo zlepšuje škálovateľnosť, pretože odpadá potreba spájať údaje z rôznych tabuliek. Pri použití relačnej databázy by bolo potrebné použiť spoje na zoskupenie potrebných informácií na jednom mieste.

Zatiaľ čo potreba vzťahu na ukladanie párov kľúč-hodnota dramaticky klesá, vzťahy sú stále potrebné. Takéto vzťahy zvyčajne existujú medzi primárnymi subjektmi. Napríklad objednávkový systém by mal záznamy, ktoré obsahujú údaje o zákazníkoch, produktoch a objednávkach. Nezáleží na tom, či sú tieto údaje v jednej doméne alebo vo viacerých. Pointa je, že keď zákazník zadá objednávku, pravdepodobne nebudete chcieť uchovávať informácie o zákazníkovi a objednávke v rovnakom zázname.
Namiesto toho by záznam objednávky mal obsahovať kľúče, ktoré poukazujú na zodpovedajúce záznamy o zákazníkoch a produktoch. Keďže záznamy môžu uchovávať akékoľvek informácie a vzťahy nie sú definované v samotnom údajovom modeli, systém správy databáz nebude schopný kontrolovať integritu vzťahov. To znamená, že môžete vymazať zákazníkov a produkty, ktoré si objednali. Za zabezpečenie integrity údajov je plne zodpovedná aplikácia.

Prístup k údajom

Relačná databáza	Úložisko párov kľúč – hodnota
Údaje sa vytvárajú, aktualizujú, odstraňujú a dopytujú sa pomocou jazyka SQL (Structured Query Language).	Údaje sa vytvárajú, aktualizujú, odstraňujú a dopytujú sa pomocou volaní metódy API.
SQL dotazy môžu získať údaje z jednej tabuľky alebo z viacerých tabuliek pomocou spojení.	Niektoré implementácie poskytujú syntax podobnú SQL na špecifikovanie podmienok filtra.
SQL dotazy môžu zahŕňať agregácie a komplexné filtre.	Často môžete použiť iba základné porovnávacie operátory (=, !=,<, >, <= и =>).
Relačná databáza zvyčajne obsahuje vstavanú logiku, ako sú spúšťače, uložené procedúry a funkcie.	Celá obchodná logika a logika integrity údajov je obsiahnutá v kóde aplikácie.

Interakcia s aplikáciami

Key-Value Stores: Výhody

Oproti relačným obchodom majú takéto systémy dve odlišné výhody.

Vhodné pre cloudové služby

Prvou výhodou skladov kľúč-hodnota je, že sú jednoduchšie, a teda škálovateľnejšie ako relačné databázy. Ak spoluhostujete svoj vlastný systém a plánujete umiestniť za svoje úložisko údajov tucet alebo sto serverov, ktoré budú musieť zvládnuť rastúce zaťaženie, potom sú vašou voľbou obchody s hodnotou kľúča.

Vzhľadom na skutočnosť, že takéto úložiská sa ľahko a dynamicky rozširujú, sú užitočné aj pre predajcov, ktorí poskytujú platformu webového úložiska pre viacerých nájomníkov. Takáto databáza je relatívne lacné pamäťové médium s veľkým potenciálom škálovateľnosti. Používatelia zvyčajne platia len za to, čo používajú, no ich potreby môžu rásť. Predajca bude môcť dynamicky a takmer bez obmedzení zväčšovať veľkosť platformy v závislosti od zaťaženia.

Prirodzenejšia integrácia s kódom

Relačný dátový model a kódový objektový model sú zvyčajne konštruované odlišne, čo vedie k určitej nekompatibilite. Vývojári riešia tento problém napísaním kódu, ktorý mapuje relačný model na objektový model. Tento proces nemá žiadnu jasnú a rýchlo dosiahnuteľnú hodnotu a môže zabrať pomerne veľa času, ktorý mohol stráviť vývojom samotnej aplikácie. Medzitým mnohé obchody s pármi kľúč – hodnota ukladajú údaje do štruktúry, ktorá sa prirodzenejšie mapuje na objekty. To môže výrazne skrátiť čas vývoja.

Iné argumenty pre používanie obchodov kľúč-hodnota, ako napríklad „Relačné databázy môžu byť neohrabané“ (mimochodom, netuším, čo to znamená), sú menej presvedčivé. Ale skôr, ako sa stanete zástancom takýchto trezorov, prečítajte si nasledujúcu časť.

Key-Value Stores: Nevýhody

Obmedzenia v relačných databázach zaručujú integritu údajov na najnižšej úrovni. Údaje, ktoré nespĺňajú obmedzenia, sa do databázy fyzicky dostať nemôžu. V obchodoch s hodnotami kľúča neexistujú žiadne takéto obmedzenia, takže kontrola integrity údajov spočíva výlučne na aplikáciách. Každý kód má však chyby. Zatiaľ čo chyby v dobre navrhnutej relačnej databáze zvyčajne nevedú k problémom s integritou údajov, chyby v obchodoch s hodnotami kľúča zvyčajne vedú.

Ďalšou výhodou relačných databáz je, že vás nútia prejsť procesom vývoja dátového modelu. Ak ste model dobre navrhli, potom bude databáza obsahovať logickú štruktúru, ktorá plne odráža štruktúru uložených údajov, ale je v rozpore so štruktúrou aplikácie. Údaje sa tak stávajú nezávislými od aplikácie. To znamená, že iná aplikácia môže používať rovnaké dáta a logiku aplikácie možno meniť bez akýchkoľvek zmien v základnom modeli. Ak chcete urobiť to isté s ukladaním hodnôt kľúča, zvážte nahradenie procesu návrhu relačného modelu návrhom triedy, ktorý vytvára generické triedy založené na prirodzenej štruktúre údajov.

A nezabudnite na kompatibilitu. Na rozdiel od relačných databáz má cloudové úložisko oveľa menej spoločných štandardov. Hoci sú koncepčne rovnaké, všetky majú rôzne API, rozhrania dotazov a svoje vlastné špecifiká. Preto radšej dôverujte svojmu predajcovi, pretože ak sa niečo stane, nebudete môcť jednoducho prejsť k inému poskytovateľovi služieb. A vzhľadom na skutočnosť, že takmer všetky moderné obchody kľúč-hodnota sú vo verzii beta 2, dôvera sa stáva ešte riskantnejšou ako v prípade relačných databáz.

Obmedzená analýza údajov

Zvyčajne sú všetky cloudové úložiská postavené na báze viacerých nájomníkov, čo znamená, že veľký počet používateľov a aplikácií používa rovnaký systém. Aby sa predišlo „ukradnutiu“ celého systému, predajcovia zvyčajne nejakým spôsobom obmedzujú vykonávanie požiadaviek. Napríklad v SimpleDB nemôže dopyt bežať dlhšie ako 5 sekúnd. V Google AppEngine Datastore nemôžete získať viac ako 1 000 záznamov v jednom dotaze 3 .

Tieto obmedzenia nie sú hrozné pre jednoduchú logiku (vytváranie, aktualizácia, mazanie a získavanie malého počtu záznamov). Čo ak sa však vaša aplikácia stane populárnou? Získali ste veľa nových používateľov a veľa nových údajov a teraz chcete vytvoriť nové používateľské skúsenosti alebo z údajov nejakým spôsobom profitovať. Tu sa môžete vážne prerušiť s vykonávaním aj jednoduchých dotazov na analýzu údajov. Funkcie, ako je sledovanie vzorov používania aplikácií alebo systém odporúčaní založený na histórii používateľov, môže byť prinajlepšom ťažké implementovať. A v najhoršom prípade - jednoducho nemožné.

V tomto prípade je pre analytikov lepšie vytvoriť samostatnú databázu, ktorá bude naplnená údajmi z vášho úložiska kľúč-hodnota. Premýšľajte dopredu, ako sa to dá urobiť. Budete server hostiť v cloude alebo samostatne? Vyskytnú sa problémy v dôsledku oneskorenia signálu medzi vami a vaším ISP? Podporuje vaše úložisko tento prenos dát? Ak máte 100 miliónov záznamov a môžete naraz vziať 1 000 záznamov, ako dlho bude trvať prenos všetkých údajov?

Neuprednostňujte však škálovateľnosť. Bude to zbytočné, ak sa vaši používatelia rozhodnú využívať služby inej služby, pretože tá poskytuje viac možností a nastavení.

Cloud-ové úložisko

Mnoho poskytovateľov webových služieb ponúka obchody s hodnotami kľúča pre viacerých nájomníkov. Väčšina z nich spĺňa vyššie uvedené kritériá, avšak každá má svoje vlastné charakteristické črty a líši sa od vyššie opísaných noriem. Pozrime sa na konkrétne príklady úložiska, ako sú SimpleDB, Google AppEngine Datastore a SQL Data Services.

Amazon: SimpleDB

SimpleDB je obchod s kľúčovými hodnotami orientovaný na atribúty, ktorý je súčasťou Amazon WebServices. SimpleDB je v beta verzii; užívatelia ho môžu využívať zadarmo – pokiaľ ich potreby nepresiahnu určitú hranicu.

SimpleDB má niekoľko obmedzení. Po prvé, čas vykonania dotazu je obmedzený na 5 sekúnd. Po druhé, neexistujú žiadne iné typy údajov ako reťazce. Všetko sa ukladá, získava a porovnáva ako reťazec, takže na porovnanie dátumov ich budete musieť previesť do formátu ISO8601. Po tretie, maximálna veľkosť ľubovoľného reťazca je 1024 bajtov, čo obmedzuje veľkosť textu (napríklad popisu produktu), ktorý môžete uložiť ako atribút. Keďže je však dátová štruktúra flexibilná, toto obmedzenie môžete obísť pridaním atribútov ProductDescription1, ProductDescription2 atď. Obmedzený je ale aj počet atribútov – maximálne 256 atribútov. Zatiaľ čo SimpleDB je v beta verzii, veľkosť domény je obmedzená na 10 gigabajtov a celá databáza nemôže presiahnuť 1 terabajt.

Jednou z kľúčových vlastností SimpleDB je použitie modelu (model prípadnej konzistencie). Tento model je vhodný pre viacvláknové spracovanie, ale pamätajte na to, že po zmene hodnoty atribútu v zázname nemusia nasledujúce operácie čítania tieto zmeny vidieť. Pravdepodobnosť takéhoto vývoja udalostí je pomerne nízka, je však potrebné si to uvedomiť. Nechcete predať posledný lístok piatim kupujúcim len preto, že vaše údaje boli v čase predaja nekonzistentné.

Google App Engine Data Store

AppEngine Datastore od Google je postavený na BigTable, internom systéme na ukladanie štruktúrovaných dát Google. AppEngine Datastore neposkytuje priamy prístup k BigTable, ale možno ho považovať za zjednodušené rozhranie na interakciu s BigTable.

AppEngine Datastore podporuje viac typov údajov v rámci jednej položky ako SimpleDB. Napríklad zoznamy, ktoré môžu obsahovať kolekcie v rámci položky.

S najväčšou pravdepodobnosťou budete toto úložisko údajov používať pri vývoji s Google AppEngine. Na rozdiel od SimpleDB však nebudete môcť používať AppEngine Datastore (alebo BigTable) mimo webových služieb Google.

Microsoft: SQL Data Services

SQL Data Services je súčasťou platformy Microsoft Azure. SQL Data Services je bezplatná, v beta verzii a má limity veľkosti databázy. SQL Data Services je samostatná aplikácia – doplnok k mnohým SQL serverom, ktoré ukladajú údaje. Tieto obchody môžu byť relačné, ale pre vás je SDS obchod s kľúčovou hodnotou, rovnako ako produkty opísané vyššie.

Necloudové úložisko

Existuje aj množstvo úložísk, ktoré môžete použiť mimo cloudu tak, že si ich nainštalujete sami. Takmer všetky tieto projekty sú mladé, alfa alebo beta a open source. S otvoreným zdrojom si možno viac uvedomujete potenciálne problémy a obmedzenia ako pri produktoch s uzavretým zdrojom.

CouchDB

CouchDB je bezplatná databáza s otvoreným zdrojom a orientovaná na dokumenty. Ako formát na ukladanie údajov sa používa JSON. CouchDB má za cieľ preklenúť priepasť medzi databázami založenými na dokumentoch a relačnými databázami pomocou „zobrazení“. Tieto zobrazenia obsahujú údaje z dokumentov v podobe tabuľky a umožňujú vám vytvárať indexy a spúšťať dotazy.

V súčasnosti CouchDB nie je skutočne distribuovaná databáza. Má replikačné funkcie, ktoré vám umožňujú synchronizovať údaje medzi servermi, ale toto nie je druh distribúcie, ktorý je potrebný na vybudovanie vysoko škálovateľného prostredia. Vývojári CouchDB na tom však pracujú.

Projekt Voldemort

Projekt Voldemort je distribuovaná databáza kľúč-hodnota navrhnutá na horizontálne škálovanie na veľkom počte serverov. Zrodil sa počas vývoja LinkedIn a bol použitý pre niekoľko systémov, ktoré majú vysoké požiadavky na škálovateľnosť. Projekt Voldemort tiež používa model konečnej konzistencie.

Mongo

Mongo je databáza vyvíjaná v 10gen Geir Magnusson a Dwight Merriman (ktorého možno poznáte z DoubleClick). Rovnako ako CouchDB, Mongo je databáza založená na dokumentoch, ktorá ukladá údaje vo formáte JSON. Mongo je však viac objektovou základňou ako čistým obchodom s hodnotou kľúča.

Mrholenie

Drizzle má veľmi odlišný prístup k riešeniu problémov, na ktoré sú obchody s kľúčovou hodnotou navrhnuté. Drizzle začal ako jedna z vetiev MySQL 6.0. Neskôr vývojári odstránili množstvo funkcií (vrátane pohľadov, spúšťačov, kompilovaných výrazov, uložených procedúr, vyrovnávacej pamäte dotazov, ACL a niektorých dátových typov), aby vytvorili jednoduchší a rýchlejší DBMS. Drizzle sa však stále dá použiť na ukladanie relačných údajov. Cieľom vývojárov je vybudovať semi-relačnú platformu určenú pre webové a cloudové aplikácie bežiace na systémoch so 16 a viac jadrami.

Riešenie

V konečnom dôsledku existujú štyri dôvody, prečo by ste si pre svoju aplikáciu mohli vybrať nerelačný ukladací priestor párov kľúč – hodnota:

1. Vaše údaje sú výrazne orientované na dokumenty a viac sa hodia pre dátový model kľúč – hodnota ako pre relačný model.
2. Váš model domény je silne objektovo orientovaný, takže použitie úložiska kľúč-hodnota zníži množstvo dodatočného kódu na transformáciu údajov.
3. Ukladanie dát je lacné a ľahko integrované s webovými službami vášho predajcu.
4. Vaším hlavným problémom je vysoká škálovateľnosť na požiadanie.

Pri rozhodovaní si však uvedomte obmedzenia konkrétnych databáz a riziká, ktorým budete čeliť, ak sa vydáte cestou používania nerelačných databáz.

Pre všetky ostatné požiadavky je lepšie zvoliť starý dobrý relačný DBMS. Sú teda odsúdení na zánik? Samozrejme, že nie. Aspoň zatiaľ.

1 - tu je podľa mňa vhodnejší výraz "dátová štruktúra", ale ponechal pôvodný dátový model.
2 - s najväčšou pravdepodobnosťou mal autor na mysli, že z hľadiska svojich možností sú nerelačné databázy nižšie ako relačné.
3 - možno sú údaje už neaktuálne, článok je z februára 2009.

Voldemort

mrholenie

Pridať značky