Relačné databázy

Relačnú databázu tvorí jedna alebo viacero súvisiacich tabuliek, ktorých štruktúra je tvorená stĺpcami a riadkami.

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

Vzťah je stôl;

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

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

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

Entita je akákoľvek rozlíšiteľná entita, ktorá je uložená v databáze.

Kľúčové polia

Každý vzťah v databáze musí obsahovať pole (alebo kolekciu niekoľkých polí), ktoré jedinečne identifikujú každý záznam 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.

Rozlišujú sa tieto 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).

Externý (sekundárny) kľúč- jedno alebo viac polí vzťahu, ktoré poskytujú prepojenie na primárny kľúč iného vzťahu.

V závislosti od počtu polí tvoriacich kľúč sa rozlišujú:

Jednoduchý kľúč- pozostáva z jedného atribútu, ktorý jednoznačne identifikuje záznam (číslo žiackej knižky).

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 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ť. Ako primárny kľúč by ste nemali používať krstné mená alebo priezviská ľudí, pretože sa môžu opakovať a v rovnakom vzťahu môžu byť ľudia 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 zmeny v zložení osôb. zaznamenané v databázach.

Pri výbere primárneho kľúča by ste mali vziať 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 by ste tiež mali vziať do úvahy, ž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 vzťahoch spojených 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 nemajú žiadny skutočný význam. Takéto polia môžu byť kód alebo číslo, tieto polia obsahujú iba číselné označenie reťazca 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 sa nemenia. Priezvisko, telefónne číslo, adresa atď. môže sa 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éria a číslo pasu; samostatne séria a číslo pasu nemôžu 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á.

• Preklad

Poznámka prekladateľa: aj keď je článok dosť starý (publikovaný pred 2 rokmi) a má hlasný názov, 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 mocné relačné databázy sú zraniteľné? Znamená to, že časy relačných databáz sú a čoskoro budú preč? V tomto článku sa pozrieme na populárny drift nerelačných databáz pre rôzne situácie a uvidíme, či to ovplyvní 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 ukončiť relačné ukladanie. Samozrejme, žiadna z týchto revolúcií sa nekonala a jedna z nich ani trochu neotriasla pozíciou relačných databáz.

Začnime so základmi

Relačná databáza je kolekcia tabuliek (entít). Tabuľky sa skladajú zo stĺpcov a riadkov (dvojíc). Obmedzenia možno definovať v rámci tabuliek, medzi tabuľkami existujú vzťahy. Pomocou SQL môžete spúšťať dotazy, ktoré vracajú množiny údajov 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), najčastejšie sa na spájanie používajú rovnaké stĺpce, ktoré definujú vzťahy medzi tabuľkami. Normalizácia je proces štruktúrovania dátového modelu s cieľom zabezpečiť konzistentnosť a neredundanciu dát.

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 histórie relačných databáz neustále ponúkali najlepšiu kombináciu jednoduchosti, robustnosti, flexibility, výkonu, škálovateľnosti a interoperability pri správe údajov.

Na zabezpečenie všetkých týchto funkcií je však relačné úložisko vnútorne neuveriteľne zložité. Napríklad jednoduchý dotaz SELECT môže mať stovky potenciálnych ciest vykonávania, ktoré optimalizátor vyhodnotí priamo za behu. Toto všetko je pred používateľmi skryté, ale v rámci RDBMS vytvára plán vykonávania založený na veciach, ako sú algoritmy odhadu nákladov, a ktorý je najvhodnejší pre dopyt.

Problémy s relačnými databázami

Zatiaľ čo relačné úložisko poskytuje najlepšiu kombináciu jednoduchosti, robustnosti, flexibility, výkonu, škálovateľnosti a kompatibility, nemusí nevyhnutne fungovať lepšie na každom z nich ako podobné systémy, ktoré sa zameriavajú na jednu konkrétnu vlastnosť. Nebol to veľký problém, pretože drvivá dominancia relačných DBMS prevážila akékoľvek nedostatky. Ak však konvenčné RDB nespĺňali potreby, vždy existovali alternatívy.

Dnes je situácia trochu iná. Rôznorodosť aplikácií rastie a s tým rastie aj dôležitosť uvedených funkcií. A ako počet databáz rastie, jedna funkcia začína zatieniť všetky ostatné. Je to škálovateľnosť. Keďže stále viac aplikácií beží v podmienkach vysokej záťaže, ako sú webové služby, ich požiadavky na škálovateľnosť sa môžu veľmi rýchlo meniť a dramaticky rásť. Prvý problém môže byť veľmi ťažké vyriešiť, ak máte relačnú databázu umiestnenú na svojom vlastnom serveri. Predpokladajme, že zaťaženie servera sa cez noc strojnásobilo. Ako rýchlo môžete aktualizovať 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 tento server minie zdroje, budete musieť pridať ďalšie počítače a rozložiť záťaž medzi ne. Tu začína hrať komplexnosť relačných databáz proti škálovateľnosti. Ak sa pokúsite zvýšiť počet serverov nie len na niekoľko, ale na stovky alebo tisíce, zložitosť sa rádovo zvýši a vlastnosti, ktoré robia relačné databázy tak atraktívnymi, rýchlo znížia na nulu šance na ich použitie ako platforma pre veľké distribuované systémy.

Aby zostali konkurencieschopní, musia predajcovia cloudu nejako bojovať s týmto obmedzením, pretože čo je to za cloud platformu 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é sú škálovateľnejšie, 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 nájsť v kontexte dokumentovo orientovaných, atribútovo orientovaných, distribuovaných databáz (hoci môžu byť aj relačné), rozdelených triedených polí, distribuovaných hašovacích tabuliek a úložiska. typu. Hoci každý z týchto názvov označuje špecifické vlastnosti systému, všetky sú variáciami témy, ktorú budeme nazývať úložisko párov kľúč – hodnota.

Akokoľvek to však nazvete, tento „nový“ typ databázy nie je až taký nový a vždy sa používal predovšetkým pre aplikácie, pre ktoré by boli relačné databázy nevhodné. Bez potreby škálovateľnosti na webe a cloude však tieto systémy neboli veľmi žiadané. Teraz je úlohou určiť, ktorý typ úložiska je vhodnejší pre konkrétny systém.
Relačné databázy a úložiská kľúč-hodnota sa zásadne líšia 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 sa skladajú zo stĺpcov a riadkov a riadky sa skladajú z hodnôt stĺpcov. Všetky riadky v jednej tabuľke majú rovnakú štruktúru.	Pre domény môžete nakresliť analógiu s tabuľkami, ale na rozdiel od tabuliek pre domény nie je definovaná dátová štruktúra. 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ôzne štruktúry.
Dátový model 1 je preddefinovaný. Je silne typovaný a 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 predišlo duplicite údajov. Normalizácia vytvára 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 kľúč-hodnota 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 záznamov. Doména môže napríklad obsahovať informácie o zákazníkoch a objednávkach. To znamená, že údaje sú zvyčajne duplikované medzi rôznymi doménami. 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 nie je potrebné spájať údaje z rôznych tabuliek. Pri používaní relačnej databázy by ste museli použiť spojenia, aby ste mohli zoskupiť potrebné informácie na jednom mieste.

Hoci 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 hlavnými 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 jednom zázname.
Namiesto toho musí záznam objednávky 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 dátovom modeli, systém správy databázy 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ú, vymazávajú a vyhľadávajú pomocou volaní metódy API.
SQL dotazy môžu získať údaje z jednej tabuľky aj 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 zabudovanú logiku, ako sú spúšťače, uložené procedúry a funkcie.	Celá logika obchodnej a dátovej integrity je obsiahnutá v kóde aplikácie.

Interakcia s aplikáciami

Obchody s kľúčovou hodnotou: výhody

Takéto systémy majú oproti relačnému úložisku 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 spoločne hosťujete svoj vlastný systém a plánujete hosťovať tucet alebo sto serverov, ktoré sa musia vyrovnať s rastúcou záťažou vášho úložiska údajov, potom sú vašou voľbou obchody s hodnotou kľúča.

Pretože sú ľahko a dynamicky rozšíriteľné, sú užitočné aj pre predajcov, ktorí poskytujú platformu webového úložiska pre viacerých nájomníkov. Takáto databáza predstavuje 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 prakticky bez obmedzení zväčšovať veľkosť platformy v závislosti od zaťaženia.

Prirodzenejšia integrácia kódu

Relačný dátový model a kódový objektový model sú zvyčajne zostavené 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á jednoznačnú a rýchlo dosiahnuteľnú hodnotu a môže zabrať pomerne veľa času, ktorý by mohol byť vynaložený na vývoj 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.

Ostatné argumenty pre používanie obchodov s kľúčovými hodnotami, ako napríklad „relačné databázy môžu byť nemotorné“ (mimochodom, netuším, čo to znamená), sú menej presvedčivé. Ale skôr, ako sa stanete zástancom takýchto úložísk, pozrite si nasledujúcu časť.

Obchody s kľúčovou hodnotou: nevýhody

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

Ďalšou výhodou relačných databáz je, že vás nútia prejsť procesom vývoja dátového modelu. Ak máte dobrý návrh modelu, databáza bude obsahovať logickú štruktúru, ktorá plne odráža štruktúru uložených údajov, ale je v rozpore so štruktúrou aplikácie. Dáta sa tak stávajú nezávislými od aplikácie. To znamená, že iná aplikácia môže používať rovnaké údaje a logiku aplikácie možno zmeniť bez akýchkoľvek zmien základného modelu. 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 dátovej štruktúre.

A nezabudnite na kompatibilitu. Na rozdiel od relačných databáz má cloudové úložisko oveľa menej spoločných štandardov. Hoci sa koncepčne nelíšia, všetky majú rôzne API, rozhrania požiadaviek a svoje špecifiká. Preto je lepšie dôverovať svojmu predajcovi, pretože ak sa niečo stane, nemôžete ľahko prejsť k inému poskytovateľovi služieb. A vzhľadom na skutočnosť, že takmer všetky moderné obchody kľúč-hodnota sú v beta 2, je dôvera ešte riskantnejšia ako v prípade relačných databáz.

Obmedzená analýza údajov

Všetky cloudové úložiská sú zvyčajne postavené na type viacnásobného prenájmu, č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 dotazov. Napríklad v SimpleDB nemôže dopyt trvať dlhšie ako 5 sekúnd. Google AppEngine Datastore nemôže získať viac ako 1 000 záznamov na požiadavku 3.

Tieto obmedzenia nie sú desivé pre jednoduchú logiku (vytváranie, aktualizácia, mazanie a získavanie malého počtu záznamov). Ale čo ak sa vaša aplikácia stane populárnou? Máte veľa nových používateľov a veľa nových údajov a teraz chcete používateľom vytvoriť nové skúsenosti alebo dáta nejakým spôsobom využiť. To je miesto, kde sa môžete zblázniť aj s jednoduchými dopytmi na analýzu údajov. Funkcie ako sledovanie vzorov používania aplikácií alebo systém odporúčaní založený na histórii používateľov môžu byť prinajlepšom zložité. A v najhoršom prípade sú jednoducho nemožné.

V tomto prípade je pre analýzu lepšie vytvoriť samostatnú databázu, ktorá bude naplnená údajmi z vášho úložiska kľúč-hodnota. Vopred si premyslite, ako sa to dá urobiť. Budete server hostiť v cloude alebo samostatne? Vyskytnú sa nejaké problémy v dôsledku oneskorenia signálu medzi vami a vaším poskytovateľom? Podporuje vaše úložisko tento prenos údajov? Ak máte 100 miliónov záznamov a môžete naraz vziať 1 000 záznamov, koľko 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á, ale 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 repozitárov, ako sú SimpleDB, Google AppEngine Datastore a SQL Data Services.

Amazon: SimpleDB

SimpleDB je obchod orientovaný na atribúty kľúč – hodnota, 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 „Opis produktu1“, „Popis produktu2“ 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 byť väčšia ako 1 terabajt.

Jednou z kľúčových vlastností SimpleDB je použitie modelu prípadnej konzistencie. Tento model je vhodný pre prácu s viacerými vláknami, ale pamätajte na to, že po zmene hodnoty atribútu v zázname nemusia nasledujúce čí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 zákazníkom len preto, že vaše údaje boli v čase predaja nekonzistentné.

Google AppEngine 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 si ho predstaviť ako zjednodušené rozhranie na interakciu s BigTable.

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

Toto je úložisko údajov, ktoré budete s najväčšou pravdepodobnosťou používať pri vývoji pomocou Google AppEngine. Na rozdiel od SimpleDB však nemôžete 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 zadarmo, 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žívať mimo cloudu tak, že si ich nainštalujete sami. Takmer všetky tieto projekty sú mladé, vo verzii alfa alebo beta a s otvoreným zdrojom. S otvoreným zdrojom si možno viac uvedomujete potenciálne problémy a obmedzenia ako pri proprietárnych produktoch.

CouchDB

CouchDB je bezplatná a open source databáza orientovaná na dokumenty. Ako formát na ukladanie údajov sa používa JSON. CouchDB má za cieľ vyplniť medzeru medzi dokumentovými a relačnými databázami pomocou „zobrazení“. Takéto zobrazenia obsahujú údaje z dokumentov vo forme podobnej tabuľkovým a umožňujú vám vytvárať indexy a spúšťať dotazy.

CouchDB v súčasnosti nie je skutočne distribuovanou databázou. Má replikačné funkcie na udržanie synchronizácie údajov medzi servermi, ale toto nie je druh distribúcie potrebný na vybudovanie vysoko škálovateľného prostredia. Vývojári CouchDB na tom však pracujú.

Voldemortov projekt

Projekt Voldemort je distribuovaná databáza kľúč-hodnota navrhnutá tak, aby sa škálovala na veľké množstvo serverov. Zrodil sa počas vývoja LinkedIn a bol použitý pre niekoľko systémov s vysokými požiadavkami na škálovateľnosť. Projekt Voldemort tiež používa model konečnej konzistencie.

Mongo

Mongo je databáza vyvinutá v 10gen Geir Magnusson a Dwight Merriman (ktorého možno poznáte z DoubleClick). Rovnako ako CouchDB, aj Mongo je databáza orientovaná na dokumenty, ktorá ukladá údaje vo formáte JSON. Mongo je však skôr objektová základňa ako čistý obchod s hodnotou kľúča.

Mrholenie

Drizzle predstavuje veľmi odlišný prístup k riešeniu problémov, na ktoré sú obchody s kľúčom a hodnotou navrhnuté. Drizzle začal ako pobočka MySQL 6.0. Neskôr vývojári odstránili množstvo funkcií (vrátane zobrazení, 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é úložisko párov kľúč – hodnota:

1. Vaše údaje sú výrazne orientované na dokumenty a sú vhodnejšie pre dátový model kľúč-hodnota ako pre relačný dátový model.
2. Váš model domény je vysoko objektovo orientovaný, takže používanie úložiska kľúč-hodnota zníži množstvo kódu navyše, ktorý potrebujete na transformáciu údajov.
3. Dátový sklad je lacný a ľahko sa integruje s webovými službami vášho predajcu.
4. Vaším hlavným záujmom je vysoká škálovateľnosť na požiadanie.

Pri rozhodovaní si však uvedomte obmedzenia konkrétnych databáz a riziká, s ktorými sa stretnete, ak sa rozhodnete používať nerelačné databázy.

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 - údaje už môžu byť neaktuálne, článok je z februára 2009.

voldemort

mrholenie

Pridať značky

Databáza (DB) je súhrn informácií o objektoch, procesoch, udalostiach alebo javoch, organizovaných v súlade s určitými pravidlami a uchovávaných v pamäti počítača, týkajúcich sa určitej tematickej oblasti, témy alebo úlohy. Je organizovaná tak, aby bola zabezpečená informačná potreba používateľov, ako aj pohodlné ukladanie tohto zberu údajov ako celku, tak aj akejkoľvek jeho časti.

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. Každý riadok tabuľky obsahuje údaje o jednom objekte (napríklad auto, počítač, zákazník) a v stĺpcoch tabuľky sú rôzne charakteristiky týchto objektov - atribúty (napríklad číslo motora, značka procesora, telefónne čísla firiem resp. zákazníci).

Riadky v tabuľke sa nazývajú záznamy. Všetky záznamy tabuľky majú rovnakú štruktúru - pozostávajú z polí (údajových prvkov), v ktorých sú uložené atribúty objektu (obr. 1). Každé pole záznamu obsahuje jednu charakteristiku objektu a predstavuje daný typ údajov (napríklad textový reťazec, číslo, dátum). Primárny kľúč sa používa na identifikáciu záznamov. Primárny kľúč je množina polí tabuľky, ktorých kombinácia hodnôt jedinečne identifikuje každý záznam v tabuľke.

Ryža. 1. Názvy predmetov v tabuľke

Na prácu s údajmi sa používajú systémy správy databáz (DBMS). Hlavné funkcie DBMS:

Definícia údajov (popis štruktúry databázy);

Spracovanie dát;

Správa údajov.

Vývoj štruktúry databázy je najdôležitejšou úlohou riešenou pri návrhu databázy. Štruktúra databázy (množina, forma a vzťahy jej tabuliek) je jedným z hlavných návrhových rozhodnutí pri vytváraní aplikácií pomocou databázy. DB štruktúra vytvorená vývojárom je opísaná v DBMS datadefinition language.

Akýkoľvek DBMS vám umožňuje vykonávať nasledujúce operácie s údajmi:

Pridávanie záznamov do tabuliek;

Odstránenie záznamov z tabuľky;

Aktualizácia hodnôt niektorých polí v jednom alebo viacerých záznamoch v tabuľkách databázy;

Vyhľadajte jeden alebo viac záznamov, ktoré zodpovedajú danej podmienke.

Na vykonanie týchto operácií sa používa dotazovací mechanizmus. Výsledkom vykonávania dotazov je buď množina záznamov vybraných podľa určitých kritérií, alebo zmeny v tabuľkách. Dotazy do databázy sa vytvárajú v jazyku špeciálne vytvorenom na tento účel, ktorý sa nazýva „štruktúrovaný dotazovací jazyk“ (SQL – Structured Query Language).

Správa údajov sa bežne chápe ako ochrana údajov pred neoprávneným prístupom, podpora režimu práce s údajmi pre viacerých používateľov a zabezpečenie integrity a konzistencie údajov.

II. Sieťový model

III. Relačný model

nahrávanielúka

hierarchické a sieťové modely cudzie kľúče

4. Relačný dátový model

Relačná databáza

* Postoj

* Atribút stĺpce (polia) tabuľky.

* Dátový typ

* Pripojenie kľúč.

* Únia

Hlavný funkcie RDBMS sú:

· Definícia údajov

· Spracovanie dát

· Správa údajov

Microsoft Access

Databázové okno v Accesse

Spôsoby práce s predmetmi

Tlačidlá pre prácu s databázovými objektmi sa nachádzajú na Paneli nástrojov okna databázy:

Otvorené- umožňuje prepnúť do režimu úpravy tabuľky, vykonania dotazu, načítania formulára, zostavenia zostavy, spustenia makra.

Konštruktér- poskytuje prechod do režimu nastavenia zvoleného objektu.

Vytvorte- umožňuje začať vytvárať nový objekt zvoleného typu.

7. Práca s tabuľkami

Ak chcete vytvoriť tabuľku, musíte prejsť do zoznamu tabuliek a kliknúť na tlačidlo Vytvorte ... Objaví sa nové dialógové okno Nový stôl:

Tabuľku v Accesse môžete vytvoriť niekoľkými spôsobmi:

· Zostavte nový stôl "od nuly" pomocou Konštruktér;

· Behať Sprievodca tabuľkou- špeciálny program, ktorý ponúka vytvorenie tabuľky v režime krok za krokom na základe štandardných riešení dostupných v Accesse;

· Importujte databázovú tabuľku zo súboru ľubovoľného programu, napríklad FoxPro alebo Excel.

Nastavenie názvu poľa

Názov poľa sa nastavuje v stĺpci Názov poľa... Názov môže mať až 64 znakov a sú povolené akékoľvek znaky okrem bodky, výkričníka a lomených zátvoriek. Duplicitné názvy polí nie sú povolené.

Definícia dátového typu

Pre každé pole musíte zadať typ údajov, ktoré obsahuje. Typ údajov sa vyberá zo zoznamu, ktorý je možné vyvolať kliknutím do stĺpca Dátový typ... Access funguje s nasledujúcimi typmi údajov:

Ø Text- na ukladanie obyčajného textu s maximálne 255 znakmi.

Ø Pole MEMO- na ukladanie veľkého množstva textu až do 65 535 znakov.

Ø Číselné- na ukladanie reálnych čísel.

Ø Dátum Čas- na uloženie kalendárnych dátumov a aktuálneho času.

Ø peňažný- tieto polia obsahujú peňažné sumy.

Ø Počítadlo- na definovanie jedinečného systémového kľúča pre tabuľku. Zvyčajne sa používa na postupné číslovanie záznamov. Keď sa do tabuľky pridá nový záznam, hodnota tohto poľa sa zvýši o 1 (jedna). Hodnoty v takýchto poliach sa neaktualizujú.

Ø Boolean - pre ukladanie dát, preberanie hodnôt: Áno alebo Nie.

Ø Pole objektu OLE- na ukladanie objektov vytvorených v iných aplikáciách.

Popis vlastností poľa

Ako už bolo uvedené, charakteristiky jednotlivých polí sú definované v poli vlastností polí (záložka). generál). Každé pole má špecifický súbor vlastností v závislosti od typu poľa. Niekoľko typov polí má podobné sady vlastností polí. Hlavné vlastnosti polí sú uvedené nižšie.

Ø Veľkosť poľa- maximálna dĺžka textového poľa (štandardne 50 znakov) alebo dátový typ číselného poľa. Odporúčame, aby ste túto vlastnosť nastavili na minimálnu povolenú hodnotu, pretože menšie údaje sa spracúvajú rýchlejšie.

Ak je typ údajov číselný, platia nasledujúce hodnoty vlastností Veľkosť poľa:

Komentujte... Ak skonvertujete pole na menšiu veľkosť, môže dôjsť k strate údajov.

Ø Formát poľa- formát pre zobrazenie údajov na obrazovke alebo tlač. Zvyčajne sa používa predvolený formát.

Ø Desatinné miesta- nastavuje počet desatinných miest za desatinnou čiarkou pre číselné a menové dátové typy.

Ø Vstupná maska- definuje formu, v ktorej sa zadávajú údaje do poľa (nástroj automatizácie zadávania údajov).

Ø Podpis- označenie pre pole, ktoré bude použité na zobrazenie poľa v tabuľke, formulári alebo zostave. Ak táto hodnota nie je zadaná, ako podpis sa použije názov poľa.

Ø Predvolená hodnota- štandardná hodnota, ktorá sa automaticky zadá do poľa pri generovaní nového dátového záznamu.

Ø Podmienka na hodnote- nastavuje obmedzenia na zadávané hodnoty, čím umožňuje kontrolu nad správnosťou zadávania údajov.

Ø Chybná správa- nastavuje text hlásenia zobrazeného na obrazovke v prípade porušenia podmienky na hodnote.

Ø Požadované pole- určuje, či toto pole môže obsahovať hodnoty Null ​​(t. j. zostať prázdne), alebo či sa do tohto poľa musia zadať údaje.

Ø Indexované pole- slúži na vyhľadávanie a triedenie záznamov podľa hodnoty uloženej v tomto poli, ako aj na automatické odstraňovanie duplicitných záznamov. Polia typu MEMO, OLE objekt a Hypertextový odkaz nemožno indexovať.

Definovanie kľúčového poľa

Po zadaní charakteristík všetkých polí musíte vybrať aspoň jedno kľúčové pole. Ako kľúčové polia sa spravidla vytvárajú polia, ktoré majú neduplikované údaje alebo polia s typom údajov Počítadlo ... V každom prípade pole kľúča nesmie obsahovať duplicitné údaje. Ak chcete definovať kľúč, vyberte požadované pole (alebo polia) a stlačte tlačidlo Kľúčové pole Upraviť ... Naľavo od značky sa zobrazí kľúčový obrázok.

Uloženie tabuľky

Pred zadaním informácií je potrebné uložiť premietanú tabuľku: stlačte tlačidlo Uložiť na paneli nástrojov alebo príslušný príkaz v p.m. Súbor a zadajte názov tabuľky, po ktorom sa na obrazovke zobrazí otázka „Vytvoriť kľúčové pole teraz?“. (Áno alebo nie)

Ak je odpoveď „ Áno", Potom Access automaticky vytvorí pole s názvom" Kód "a typ údajov Počítadlo , ak " nie", - potom sa tabuľka vytvorí bez poľa kľúča. V takom prípade musíte vytvorenú tabuľku otvoriť v režime Konštruktér a definujte "ručne" kľúčové pole.

Zadávanie údajov

Ak chcete prepnúť tabuľku do režimu zadávania informácií, musíte sa prepnúť do režimu Tabuľky... Polia sa vypĺňajú postupne. Z jedného poľa do druhého sa pohodlne prechádza stlačením Tab(alebo kombinácia Shift + Tab- v opačnom smere). Ak bola tabuľka navrhnutá s predvolenými hodnotami pre niektoré polia, tieto hodnoty sa automaticky objavia v príslušných poliach. Záznamy v tabuľke je možné presúvať, kopírovať a mazať rovnakým spôsobom ako v tabuľkách, teda najprv vybrať riadky a potom vykonať požadovanú operáciu. Stĺpec je možné vybrať kliknutím na hlavičku. Pomocou tejto metódy je možné stĺpce posúvať doľava a doprava drag and drop(ťahaj a pusť).

V prípade potreby sa môžete vrátiť do režimu Konštruktér... To umožňuje opraviť niečo v štruktúre tabuľky.

Triedenie údajov v tabuľke

Údaje v tabuľke je možné zoradiť vzostupne alebo zostupne. Ak to chcete urobiť, musíte umiestniť kurzor myši do ľubovoľnej bunky stĺpca, ktorého hodnoty budú zoradené z položky. Nahrávky vybrať tím Triedenie alebo stlačte príslušné tlačidlo na paneli.

8. Vytváranie väzieb medzi databázovými tabuľkami

Vzťah medzi tabuľkami je stanovený definovaním v jednej tabuľke ( podriadený) poľa zodpovedajúceho kľúču inej tabuľky ( hlavný). Vytvorený odkaz prepojí záznamy obsahujúce rovnaké hodnoty v zadanom poli. Prepojenia, ktoré vytvoríte, neskôr použije Access v dotazoch, formulároch alebo zostavách.

Poznámky.

Ø Obe prepojené polia musia mať rovnaké Dátový typ.

Ø Vlastnosti Veľkosť poľa pre obe prepojené polia číselný typ by mala byť rovnaká.

Ø Ak je kľúčové pole hlavnej tabuľky poľom s typom údajov Počítadlo, potom môže byť toto pole spojené s číselným poľom v podriadenej tabuľke. V tomto prípade pre číselné pole súvisiacej tabuľky pre vlastnosť Veľkosť poľa musí byť nastavené na Dlhé celé číslo .

Integrita údajov

Integrita údajov Je súbor pravidiel, ktoré udržiavajú správne vzťahy medzi záznamami v súvisiacich tabuľkách a chránia údaje pred náhodnými zmenami alebo vymazaním.

Tieto pravidlá zahŕňajú:

Ø Do podriadenej tabuľky nie je možné zadávať záznamy, ktoré nesúvisia so záznamom hlavnej tabuľky.

Ø V hlavnej tabuľke nemôžete zmeniť hodnotu kľúčového poľa, ak sú v podriadenej tabuľke k nemu priradené záznamy.

Ø Záznamy nemožno vymazať v hlavnej tabuľke, ak sú k nej priradené záznamy v podriadenej tabuľke.

Kaskádové operácie

Integrita údajov v prepojených tabuľkách je zabezpečená dvoma typmi kaskádových operácií:

Ø kaskádové operácie aktualizácie;

Ø kaskádové operácie odstránenia.

Tieto operácie možno zapnúť a vypnúť začiarknutím príslušných políčok: "Kaskádová aktualizácia prepojených polí" a "Kaskádové odstránenie prepojených polí".

Ak je začiarknuté políčko „Kaskádová aktualizácia súvisiacich polí“, potom akékoľvek zmeny v hodnote kľúčového poľa v hlavnej tabuľke, ktorá je na strane „jedna“ vo vzťahu 1: M, automaticky zaktualizujú zodpovedajúce hodnoty ​vo všetkých súvisiacich záznamoch.

Keď pri odstraňovaní záznamu z hlavnej tabuľky začiarknete políčko Kaskádové mazanie prepojených tabuliek, je zabezpečené automatické mazanie prepojených záznamov v podriadených tabuľkách.

Odstránenie (zmena) odkazov

Ø Otvorte okno Dátová schéma;

Ø aktivovať odkaz, ktorý sa má vymazať (zmeniť) ľavým tlačidlom myši;

Ø Kliknutím pravým tlačidlom myši vyvolajte kontextovú ponuku a vyberte príkaz Odstrániť (Zmeniť), resp.

9. Typy vzťahov medzi tabuľkami

Existujú tri typy vzťahov medzi tabuľkami:

Jeden k jednému (1:1). Hodnota kľúča v každom zázname v hlavnej tabuľke môže zodpovedať hodnotám v pridruženom poli iba v jednom zázname v podriadenej tabuľke. V tomto prípade možno vzťah medzi tabuľkami vytvoriť iba prostredníctvom kľúčových polí oboch tabuliek.

Jeden k mnohým (1: M). Hodnota kľúča v každom zázname v hlavnej tabuľke môže zodpovedať hodnotám v pridružených poliach vo viacerých záznamoch v podriadenej tabuľke. Tento typ vzťahu sa v relačných databázach používa pomerne často.

Many-to-many (M:M). Vyskytuje sa medzi dvoma tabuľkami, keď jeden záznam z prvej tabuľky A (výstupný odkaz) môže byť spojený s viac ako jedným záznamom inej tabuľky B (prijímanie), jeden záznam z inej tabuľky môže byť spojený s viac ako jedným záznamom prvý stôl... Táto schéma sa realizuje iba pomocou tretej spojovacej tabuľky, ktorej kľúč spojenia pozostáva z najmenej dvoch polí. Tieto polia sú polia cudzieho kľúča v tabuľkách A a B. Primárny kľúč pre tabuľku spojenia je zvyčajne kombináciou cudzích kľúčov.

Ak sú medzi tabuľkami prepojenia typu M:M, vytvorí sa dodatočná priesečníková tabuľka, pomocou ktorej sa vzťah M:M zredukuje na dve prepojenia typu 1:M. Access vám neumožňuje definovať priamy vzťah M:M medzi dvoma tabuľkami.

10. Vytváranie žiadostí

Spustenie žiadosti

Spustenie požiadavky na vykonanie z okna Konštruktér musíte kliknúť na tlačidlo na paneli nástrojov " Beh» ! alebo vykonajte príkaz Vyžiadať / spustiť... Výsledky vzorkovania údajov na požiadanie sa zobrazujú na obrazovke v režime tabuľky.

Tvorba výberových podmienok

Zoznam operátorov používaných pri zadávaní výrazov je nasledujúci:

Ø operátorov prirovnania:

= (rovná sa)

<> (nerovná sa)

> (viac)

>= (nie menej)

< (menší)

<= (nie viac)

MEDZI- umožňuje nastaviť rozsah hodnôt. Syntax: Medzi"výraz" A"Výraz" (napríklad: MEDZI 10 A 20 znamená to isté ako booleovský výraz >= 10 A<= 20).

IN- umožňuje zadať zoznam hodnôt použitých na porovnanie (operand je zoznam uzavretý v zátvorkách). Napríklad: IN(„Brest“, „Minsk“, „Grodno“) znamená to isté ako logický výraz „Brest“ ALEBO"Minsk" ALEBO"Grodno".

Ø hlavolam operátori:

A(napríklad:> = 10 AND<=20)

ALEBO(napríklad:<50 OR >100)

NIE(napríklad: Is Not Null je pole obsahujúce nejakú hodnotu).

Ø operátor PÁČI SA MI TO- kontroluje dodržiavanie text alebo Memo polia podľa daného vzoru charakteru.

Tabuľka symbolov šablóny

Príklady použitia operátora Páči sa mi to:

LIKE "C *"- riadky začínajúce znakom C;

LIKE "[A - Z] #"- ľubovoľný znak od A po Z a číslicu;

LIKE "[! 0 - 9 ABC] * # #"- riadky začínajúce akýmkoľvek znakom okrem číslic alebo písmen A, B, C a končiace 2 číslicami;

Komplexné výberové kritériá

Často je potrebné vyberať záznamy podľa podmienky, ktorá je určená pre viacero polí tabuľky alebo podľa viacerých podmienok pre jedno pole. V tomto prípade aplikujte "I-dotazy"(záznamy vyberte len vtedy, ak sú splnené všetky podmienky) a ALEBO otázky(výber záznamov pri splnení aspoň jednej z podmienok).

Pri nastavovaní „ ALEBO dotaz»Každá podmienka výberu by mala byť umiestnená na samostatnom riadku Dopytový formulár.

Pri nastavovaní „ Pýtam sa»Každá podmienka výberu musí byť umiestnená na jednom riadku, ale v rôznych poliach Dopytový formulár.

Tieto operácie môžu byť špecifikované explicitne pomocou operátorov ALEBO a A resp.

Funkcie Iif () a Formát ().

Funkcia IIf (podmienka; ak je pravda; ak je nepravda)- vráti jeden z dvoch argumentov v závislosti od výsledku vyhodnotenia výrazu.

Funkcia Formát (výraz; vyhlásenie o formáte)- vráti reťazec obsahujúci výraz naformátovaný podľa pokynov na formátovanie.

Pre výrazy Dátum Čas v príkaze o formátovaní môžete použiť nasledujúce znaky:

I. Hierarchický model

II. Sieťový model

III. Relačný model

V relačnom modeli sú informácie prezentované vo forme pravouhlých tabuliek. Každá tabuľka pozostáva z riadkov a stĺpcov a má v rámci databázy jedinečný názov. Na druhej strane každý riadok ( nahrávanie) takejto tabuľky obsahuje informácie týkajúce sa iba jedného konkrétneho objektu a každého stĺpca ( lúka) tabuľka má jedinečný názov pre svoju tabuľku.

Relačné databázy (RDB), na rozdiel od hierarchické a sieťové modely umožňujú organizovať vzťahy medzi tabuľkami kedykoľvek. Na tento účel RDB zaviedla mechanizmus cudzie kľúče... Každá tabuľka databázy má aspoň jedno pole, ktoré slúži ako prepojenie na inú tabuľku. V terminológii RDB sa takéto polia nazývajú polia cudzieho kľúča. Pomocou cudzích kľúčov môžete prepojiť ľubovoľné databázové tabuľky v ktorejkoľvek fáze práce s databázou.

4. Relačný dátový model

Relačná databáza (RDB) je súbor najjednoduchších dvojrozmerných logicky prepojených tabuliek-relácií, ktorý pozostáva zo súboru polí a záznamov odrážajúcich určitú tematickú oblasť.

Relačný dátový model navrhol E. Codd, renomovaný americký databázový špecialista. Základné koncepty tohto modelu boli prvýkrát publikované v roku 1970. Ako vzdelaný matematik Codd navrhol použiť na spracovanie údajov aparát teórie množín (zjednotenie, prienik, rozdiel, karteziánsky súčin). Ukázal, že akákoľvek reprezentácia údajov sa redukuje na zbierku dvojrozmerných tabuliek špeciálneho typu, v matematike známych ako relácia (v angličtine - relácia, odtiaľ názov - relačné databázy).

Jednou z hlavných myšlienok Codda bolo, že vzťah medzi údajmi by mal byť stanovený v súlade s ich vnútorným logickým vzťahom. Druhým dôležitým princípom, ktorý navrhol Codd, je, že v relačných systémoch môže jeden príkaz spracovať celé dátové súbory, kým predtým bol jedným príkazom spracovaný iba jeden záznam.

Základné koncepty relačných databáz (RDB)

* Postoj- informácie o objektoch rovnakého typu, napríklad o zákazníkoch, objednávkach, zamestnancoch. V relačnej databáze je vzťah uložený ako tabuľka.

* Atribút- určitý údaj o určitom objekte - napríklad adresa klienta alebo mzda zamestnanca. Atribút je zvyčajne uložený ako stĺpce (polia) tabuľky.

* Dátový typ- pojem, ktorý je v relatívnom modeli plne ekvivalentný zodpovedajúcemu pojmu v algoritmických jazykoch. Množina podporovaných dátových typov je určená DBMS a môže sa značne líšiť od systému k systému.

* Pripojenie- spôsob, akým informácie v jednej tabuľke súvisia s informáciami v inej tabuľke. Odkazy sa vytvárajú pomocou zodpovedajúcich polí tzv kľúč.

* Únia- proces spájania tabuliek alebo dotazov na základe zodpovedajúcich hodnôt určitých atribútov.

Pravidlá (normalizácia) pre budovanie relačnej databázy

Normalizácia je proces reorganizácie údajov odstránením opakujúcich sa skupín a iných rozporov, aby sa tabuľky dostali do formy, ktorá umožňuje konzistentnú a správnu úpravu údajov. Konečným cieľom normalizácie je získať návrh databázy, v ktorom sa každý fakt objaví len na jednom mieste, t.j. redundancia informácií je vylúčená.

1. Každé pole akejkoľvek tabuľky musí byť jedinečné.

2. Každá tabuľka musí mať jedinečný identifikátor ( primárny kľúč), ktoré môžu pozostávať z jedného alebo viacerých polí tabuľky.

3. Pre každú hodnotu primárneho kľúča musí existovať jedna a len jedna hodnota ktoréhokoľvek z údajových stĺpcov a táto hodnota musí súvisieť s objektom tabuľky (čiže tabuľka nesmie obsahovať údaje, ktoré nepatria do objekt definovaný primárnym kľúčom, ale aj informácie v tabuľke by mali objekt plne popisovať).

4. Malo by byť možné zmeniť hodnoty akéhokoľvek poľa (nie je zahrnuté v primárnom kľúči), čo by nemalo znamenať zmenu iného poľa (tj nemali by existovať žiadne vypočítané polia).

5. Systémy správy databáz (DBMS)

Údržba databáz v počítačovom prostredí je realizovaná softvérovými nástrojmi - databázovými manažérskymi systémami, ktoré sú súborom softvérových a jazykových nástrojov na všeobecné alebo špecializované účely potrebných na vytváranie databáz na strojových médiách, ich udržiavanie v aktuálnosti a organizáciu. pristupovať k nim rôznym používateľom v podmienkach prijatej technológie spracovania údajov.

DBMS - sú to riadiace programy, ktoré zabezpečujú všetky manipulácie s databázami: vytváranie databázy, jej udržiavanie, používanie mnohými používateľmi atď., to znamená, že implementujú komplexný súbor funkcií pre centralizovanú správu databázy a slúžia záujmom používateľov.

DBMS si možno predstaviť ako softvérový shell, ktorý sedí medzi databázou a používateľom. Zabezpečuje centralizovanú kontrolu ochrany a integrity údajov, prístupu k údajom, ich spracovania, reportingu na báze databázy a ďalších operácií a postupov.

Systém správy relačných databáz (RDBMS)

Súbor nástrojov na správu RDB sa nazýva systém správy relačných databáz ktoré môžu obsahovať pomocné programy, aplikácie, služby, knižnice, nástroje na vytváranie aplikácií a ďalšie komponenty. Vďaka prepojeniu pomocou spoločných kľúčových polí možno informácie v RDB kombinovať z mnohých tabuliek do jednej sady výsledkov.

Hlavný funkcie RDBMS sú:

· Definícia údajov- aké informácie sa budú ukladať, nastaviť štruktúru databázy a ich typ.

· Spracovanie dát- môžete vybrať ľubovoľné polia, triediť a filtrovať údaje. Dáta môžete kombinovať a sumarizovať.

· Správa údajov- opraviť a doplniť údaje.

6. Všeobecná charakteristika DBMS ACCESS

Microsoft Access Je funkčne kompletný relačný DBMS, ktorý poskytuje všetky potrebné nástroje na definovanie a spracovanie dát, ako aj na ich správu pri práci s veľkým množstvom informácií. Jeho rôzne verzie sú súčasťou softvérového balíka MS Office a fungujú v prostredí Windows (3.11 / 95/98/2000 / XP).

Databázové okno v Accesse

Po vytvorení nového databázového súboru alebo otvorení existujúceho okna programu Access v pracovnom priestore sa zobrazí okno databázy:

Dátový model je súbor dátových štruktúr a operácií na ich spracovanie. Pomocou dátového modelu môžete vizualizovať štruktúru objektov a vzťahy vytvorené medzi nimi. Terminológiu dátových modelov charakterizujú pojmy „údajový prvok“ a „záväzné pravidlá“. Údajová položka popisuje akúkoľvek množinu údajov a pravidlá viazania určujú algoritmy pre vzťah údajových položiek. K dnešnému dňu bolo vyvinutých veľa rôznych dátových modelov, ale v praxi sa používajú tri hlavné. Alokujte hierarchické, sieťové a relačné dátové modely. V súlade s tým hovoria o hierarchickom, sieťovom a relačnej DBMS.

О Hierarchický dátový model. Hierarchicky usporiadané údaje sú v každodennom živote veľmi bežné. Napríklad štruktúra vysokej školy je viacúrovňová hierarchická štruktúra. Hierarchická (stromová) databáza pozostáva z usporiadanej množiny prvkov. V tomto modeli z pôvodných prvkov vznikajú ďalšie prvky a z týchto prvkov zasa ďalšie prvky. Každé dieťa má len jedného rodiča.

Organizačné schémy, zoznamy materiálov, obsah kníh, projektové plány a mnohé ďalšie zbierky údajov môžu byť prezentované hierarchicky. Integrita väzieb medzi predkami a potomkami je automaticky zachovaná. Základné pravidlo: žiadny potomok nemôže existovať bez svojho rodiča.

Hlavnou nevýhodou tohto modelu je nutnosť použiť hierarchiu, ktorá bola vložená do základu databázy pri návrhu. Potreba neustálej reorganizácie dát (a častokrát aj nemožnosť tejto reorganizácie) viedla k vytvoreniu všeobecnejšieho modelu – siete.

О Sieťový dátový model. Sieťový prístup k organizovaniu údajov je rozšírením hierarchického prístupu. Tento model sa líši od hierarchického v tom, že každý vygenerovaný prvok môže mať viac ako jeden nadradený prvok. ■

Keďže sieťová databáza môže priamo reprezentovať všetky typy vzťahov obsiahnuté v údajoch príslušnej organizácie, tieto údaje možno navigovať, skúmať a vyhľadávať rôznymi spôsobmi, to znamená, že sieťový model nie je spojený len jednou hierarchiou. Na zostavenie dotazu na sieťovú databázu je však potrebné ponoriť sa hlboko do jej štruktúry (mať po ruke schému tejto databázy) a vyvinúť mechanizmus na navigáciu v databáze, čo je významnou nevýhodou tejto databázy. Model.

O relačnom dátovom modeli. Základnou myšlienkou relačného dátového modelu je reprezentovať akýkoľvek súbor údajov ako dvojrozmernú tabuľku. V najjednoduchšom prípade relačný model popisuje jednu dvojrozmernú tabuľku, ale najčastejšie tento model popisuje štruktúru a vzťahy medzi niekoľkými rôznymi tabuľkami.

Relačný dátový model

Čiže účelom informačného systému je spracovávať údajov o predmety skutočný svet, berúc do úvahy spojenia medzi objektmi. V teórii DB sa dáta často označujú ako atribúty a predmety - subjektov. Objekt, atribút a spojenie sú základnými pojmami I.S.

Objekt(alebo entita) je niečo, čo existuje a rozoznateľné, to znamená, že objekt možno nazvať tým „niečím“, pre ktoré existuje názov a spôsob, ako rozlíšiť jeden podobný objekt od druhého. Napríklad každá škola je objekt. Predmety sú tiež osoba, trieda v škole, firma, zliatina, chemická zlúčenina atď. Predmetmi môžu byť nielen hmotné predmety, ale aj abstraktnejšie pojmy, ktoré odrážajú skutočný svet. Napríklad udalosti, regióny, umelecké diela; knihy (nie ako tlačené produkty, ale ako diela), divadelné predstavenia, filmy; právne normy, filozofické teórie a pod.

Atribút(alebo daný)- je to nejaký indikátor, ktorý charakterizuje určitý objekt a nadobúda určitú číselnú, textovú alebo inú hodnotu pre konkrétnu inštanciu objektu. Informačný systém pracuje so súbormi objektov navrhnutých vo vzťahu k danej tematickej oblasti, s využitím špecifických hodnoty atribútov(údaje) určitých objektov. Vezmime si napríklad hodiny v škole ako zbierku predmetov. Počet žiakov v triede je daný, ktorý nadobúda číselnú hodnotu (jedna trieda má 28, druhá 32). Názov triedy je daný, ktorý má textový význam (jedna má 10A, druhá 9B atď.).

Vývoj relačných databáz sa začal koncom 60. rokov 20. storočia, keď sa objavili prvé články diskutovajúce; možnosť využitia pri návrhu databáz zaužívaných a prirodzených spôsobov prezentácie údajov - takzvané tabuľkové datalogické modely.

Za zakladateľa teórie relačných databáz je považovaný zamestnanec IBM Dr. E. Codd, ktorý publikoval 6 (článok z júna 1970 Relačný model dát pre veľké zdieľané dátové banky(Relačný dátový model pre veľké kolektívne dátové banky). Tento článok bol prvý, ktorý použil výraz „relačný dátový model“. Teória relačných databáz, vyvinutá v 70. rokoch v Spojených štátoch Dr. E. Coddom, má silný matematický základ, ktorý popisuje pravidlá pre efektívne organizovanie údajov. Teoretický základ vypracovaný E. Coddom sa stal základom pre rozvoj teórie návrhu databáz.

E. Codd, vzdelaním matematik, navrhol použiť na spracovanie údajov aparát teórie množín (zjednotenie, prienik, rozdiel, karteziánsky súčin). Dokázal, že každý súbor údajov môže byť reprezentovaný ako dvojrozmerné tabuľky špeciálneho druhu, známe v matematike ako „relácie“.

Relačný uvažuje sa taká databáza, v ktorej sa používateľovi prezentujú všetky údaje vo forme pravouhlých tabuliek hodnôt údajov a všetky operácie s databázou sú zredukované na manipulačné tabuľky.

Stôl pozostáva z stĺpce (polia) a linky (záznamy); má názov, ktorý je v rámci databázy jedinečný. tabuľky odráža Typ objektu skutočný svet (esencia), a každý z nej reťazec je špecifický objekt. Každý stĺpec v tabuľke predstavuje kolekciu hodnôt pre konkrétny atribút objektu. Hodnoty sa vyberajú z množiny všetkých možných hodnôt atribútu objektu, ktorý sa nazýva doména.

Vo svojej najvšeobecnejšej forme je doména definovaná špecifikovaním nejakého základného dátového typu, ku ktorému patria prvky domény, a ľubovoľného logického výrazu aplikovaného na dátové prvky. Ak je pri vyhodnocovaní logickej podmienky na dátovej položke výsledok „pravda“, potom táto položka patrí do domény. V najjednoduchšom prípade je doména definovaná ako platný potenciálny súbor hodnôt rovnakého typu. Napríklad zber dátumov narodenia všetkých zamestnancov predstavuje „doménu dátumu narodenia“ a mená všetkých zamestnancov tvoria „doménu mena zamestnanca“. Doména dátumu narodenia má dátový typ na ukladanie informácií o bodoch v čase a doména mena zamestnanca musí byť znakový dátový typ.

Ak dve hodnoty pochádzajú z rovnakej domény, môžete tieto dve hodnoty porovnať. Napríklad, ak sú dve hodnoty z domény dátumu narodenia, môžete ich porovnať a určiť, ktorý zamestnanec je starší. Ak sú hodnoty prevzaté z rôznych domén, ich porovnanie nie je povolené, pretože to s najväčšou pravdepodobnosťou nedáva zmysel. Napríklad z porovnania mena a dátumu narodenia zamestnanca nevyjde nič isté.

Každý stĺpec (pole) má svoj názov, ktorý sa zvyčajne píše v hornej časti tabuľky. Pri návrhu tabuliek v rámci konkrétneho DBMS je možné vybrať pre každé pole jeho Typ, to znamená definovať súbor pravidiel pre jeho zobrazenie, ako aj definovať tie operácie, ktoré možno vykonávať s údajmi uloženými v tomto poli. Sady typov sa môžu líšiť od DBMS k DBMS.

Názov poľa musí byť v tabuľke jedinečný, avšak rôzne tabuľky môžu mať polia s rovnakým názvom. Každá tabuľka musí mať aspoň jedno pole; polia sú v tabuľke usporiadané podľa poradia ich názvov pri jej vytvorení. Na rozdiel od polí reťazce nemajú mená; ich poradie v tabuľke nie je definované a ich počet nie je logicky obmedzený.

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ľúč... Umelé pole sa často zavádza do číselných záznamov v tabuľke. Takýmto poľom môže byť napríklad jeho poradové číslo, ktoré dokáže zabezpečiť jedinečnosť každého záznamu v tabuľke. Kľúč musí mať nasledujúce vlastnosti.

Jedinečnosť. V žiadnom okamihu žiadne dve rôzne n-tice vzťahu nemajú rovnakú hodnotu pre kombináciu atribútov zahrnutých v kľúči. To znamená, že v tabuľke nemôžu byť dva riadky, ktoré majú rovnaké identifikačné číslo alebo číslo pasu.

Minimalita.Žiadny z atribútov zahrnutých v kľúči nemožno vylúčiť z kľúča bez narušenia jedinečnosti. To znamená, že nie je potrebné vytvárať kľúč, ktorý obsahuje číslo pasu aj identifikačné číslo. Na jedinečnú identifikáciu n-tice stačí použiť ktorýkoľvek z týchto atribútov. Do kľúča by ste tiež nemali zahrnúť nejedinečný atribút, to znamená, že je zakázané používať kombináciu identifikačného čísla a mena zamestnanca ako kľúča. Vylúčením mena zamestnanca z kľúča môžete stále jednoznačne identifikovať každý riadok.

Každý vzťah má aspoň jeden možný kľúč, keďže súhrn všetkých jeho atribútov spĺňa podmienku jedinečnosti – vyplýva to zo samotnej definície vzťahu.

Jeden z možných kľúčov je náhodne vybraný ako primárny kľúč. Ostatné možné kľúče, ak nejaké existujú, sa berú ako alternatívne kľúče. Ak napríklad vyberiete identifikačné číslo ako primárny kľúč, číslo pasu bude alternatívnym kľúčom.

Vzťah tabuliek je základným prvkom relačného dátového modelu. Je podporovaná cudzie kľúče.

Pri popise modelu relačnej databázy sa pre rovnaký koncept často používajú rôzne výrazy v závislosti od úrovne popisu (teória alebo prax) a systému (Access, SQL Server, dBase). Tabuľka 2.3 sumarizuje použité pojmy.

Tabuľka 2.3. Databázová terminológia

Teória databáz ____________ Relačné databázy _________ SQL Server __________

Tabuľka relácií

Tuple Record Row

Pole atribútu ________________ Stĺpec

Relačné databázy

Relačná databáza je množina vzťahov obsahujúcich všetky informácie, ktoré musia byť uložené v databáze. To znamená, že databáza predstavuje množinu tabuliek potrebných na uloženie všetkých údajov. Tabuľky relačných databáz spolu logicky súvisia Požiadavky na dizajn relačnej databázy možno zhrnúť do niekoľkých pravidiel.

О Každá tabuľka má v databáze jedinečný názov a skladá sa z riadkov rovnakého typu.

О Každá tabuľka pozostáva z pevného počtu stĺpcov a hodnôt. Do jedného stĺpca v riadku nemožno uložiť viac ako jednu hodnotu. Ak je napríklad tabuľka s údajmi o autorovi, dátume vydania, náklade a pod., tak stĺpec s menom autora nemôže obsahovať viac ako jedno priezvisko. Ak knihu napísali dvaja alebo viacerí autori, budete musieť použiť ďalšie tabuľky.

О V tabuľke nikdy nebudú dva riadky, ktoré by sa navzájom duplikovali. Riadky sa musia líšiť aspoň o jednu hodnotu, aby bolo možné jednoznačne identifikovať ktorýkoľvek riadok v tabuľke.

О Každý stĺpec má priradený názov, ktorý je v rámci tabuľky jedinečný; je preň nastavený špecifický dátový typ tak, že v tomto stĺpci sú umiestnené homogénne hodnoty (dátumy, priezviská, telefónne čísla, peňažné sumy atď.).

О Kompletný informačný obsah databázy je prezentovaný vo forme explicitných hodnôt samotných údajov a tento spôsob prezentácie je jediný. Napríklad vzťah medzi tabuľkami je založený na údajoch uložených v zodpovedajúcich stĺpcoch a nie na základe akýchkoľvek ukazovateľov, ktoré umelo definujú vzťah.

О Pri spracovaní údajov môžete voľne odkazovať na ktorýkoľvek riadok alebo stĺpec tabuľky. Hodnoty uložené v tabuľke neobmedzujú poradie, v ktorom sa k údajom pristupuje. popis stĺpca,