Relační databáze. Relační databázový model

RELAČNÍ DATABÁZE A JEJÍ VLASTNOSTI. TYPY VZTAHŮ MEZI VZTAHOVÝMI TABULKAMI

Relační databáze je sada vzájemně propojených tabulek, z nichž každá obsahuje informace o objektech určitého typu. Řádek tabulky obsahuje data o jednom objektu (například produktu, zákazníkovi) a sloupce tabulky popisují různé vlastnosti tyto objekty - atributy (například jméno, kód produktu, informace o zákazníkovi). Záznamy, tedy řádky tabulky, mají stejnou strukturu – skládají se z polí, která ukládají atributy objektů. Každé pole, tedy sloupec, popisuje pouze jednu charakteristiku objektu a má přesně definovaný datový typ. Všechny záznamy mají stejná pole, pouze zobrazují různé informační vlastnosti objektu.

V relační databázi musí mít každá tabulka primární klíč, pole nebo kombinaci polí, které jednoznačně identifikují každý řádek v tabulce. Pokud se klíč skládá z několika polí, nazývá se složený. Klíč musí být jedinečný a musí jednoznačně identifikovat položku. Podle hodnoty klíče lze nalézt jeden záznam. Klíče se také používají k uspořádání informací v databázi.

Tabulky relační databáze musí splňovat požadavky relační normalizace. Normalizace vztahů je formální aparát omezení tvorby tabulek, který umožňuje eliminovat duplicitu, zajišťuje konzistenci těch uložených v databázi a snižuje mzdové náklady na údržbu databáze.

Nechte vytvořit tabulku Student, která bude obsahovat následující pole: číslo skupiny, celé jméno, číslo záznamu, datum narození, název odbornosti, název fakulty. Taková organizace ukládání informací bude mít řadu nevýhod:

• duplikace informací (u každého studenta se opakuje název odbornosti a fakulty), objem databáze se proto zvýší;
• postup aktualizace informací v tabulce je obtížný, protože je nutné každou z nich upravit záznamy v tabulce.

Normalizace tabulek je navržena tak, aby tyto nedostatky vyřešila. Dostupný tři normální formy vztahů.

První normální forma. Relační tabulka je redukována na první normální formu tehdy a pouze tehdy, pokud žádný z jejích řádků neobsahuje více než jednu hodnotu v žádném z jejích polí a žádné z jejích klíčových polí není prázdné. Pokud tedy chcete získat informace z tabulky Student podle jména studenta, pak by pole Celé jméno mělo být rozděleno na části Příjmení, Jméno, Patronyma.

Druhá normální forma. Relační tabulka je definována ve druhé normální formě, pokud splňuje požadavky první normální formy a všechna její pole, která nejsou zahrnuta v primárním klíči, jsou plně funkčně závislá na primárním klíči. Pro převedení tabulky do druhé normální formy je nutné určit funkční závislost polí. Funkční závislost polí je závislost, ve které pouze jedna hodnota popisného atributu odpovídá určité hodnotě klíčového atributu v instanci informačního objektu.

Třetí normální forma. Tabulka je ve třetí normální formě, pokud splňuje požadavky druhé normální formy a žádné z jejích neklíčových polí není funkčně závislé na jiných neklíčových polích. Například v tabulce Student (číslo skupiny, celé jméno, číslo knihy záznamů, Datum narození, Vedoucí) tři pole - číslo knihy záznamů, číslo skupiny, Vedoucí jsou v tranzitivní závislosti. Číslo skupiny závisí na čísle knihy záznamů a vedoucí závisí na čísle skupiny. Pro odstranění tranzitivní závislosti je nutné přenést některá pole tabulky Student do jiné tabulky Group. Tabulky budou mít následující podobu: Student (č. skupiny, celé jméno, číslo v klasifikační knize, datum narození), skupina (č. skupiny, ředitel).

S relačními tabulkami jsou možné následující operace:

• Slučování tabulek se stejnou strukturou. Výsledkem je společná tabulka: nejprve první, pak druhá (zřetězení).
• Průnik tabulek se stejnou strukturou. Výsledek - jsou vybrány ty záznamy, které jsou v obou tabulkách.
• Odečítání tabulek se stejnou strukturou. Výsledek - jsou vybrány ty záznamy, které nejsou v subtrahendu.
• Ukázka (horizontální podmnožina). Výsledek - jsou vybrány záznamy, které splňují určité podmínky.
• Projekce (vertikální podmnožina). Výsledkem je relace obsahující některá pole ze zdrojových tabulek.
• Kartézský součin dvou tabulek Záznamy ve výsledné tabulce se získají zřetězením každého záznamu v první tabulce s každým záznamem v tabulce druhé.

Relační tabulky mohou být vzájemně propojeny, takže data lze načítat z více tabulek současně. Tabulky jsou propojeny, aby se nakonec zmenšila velikost databáze. Vztah každé dvojice tabulek je uveden, pokud mají stejné sloupce.

Existují následující typy informační odkazy:

• jedna ku jedné;
• one-to-many;
• mnoho-k-mnoho.

Komunikace jeden na jednoho předpokládá, že jeden atribut první tabulky odpovídá pouze jednomu atributu druhé tabulky a naopak.

Vztah jeden k mnoha předpokládá, že jeden atribut první tabulky odpovídá několika atributům druhé tabulky.

Vztah mnoho k mnoha předpokládá, že jeden atribut první tabulky odpovídá několika atributům druhé tabulky a naopak.

Databáze (DB) je soubor informací organizovaných v souladu s určitými pravidly a uchovávaných v paměti počítače o objektech, procesech, událostech nebo jevech souvisejících s určitou tematickou oblastí, tématem nebo úkolem. Je organizován tak, aby byly zajištěny informační potřeby uživatelů a také pohodlné uložení tohoto souboru dat, a to jako celku i jakékoli jeho části.

Relační databáze je sada vzájemně propojených tabulek, z nichž každá obsahuje informace o objektech určitého typu. Každý řádek tabulky obsahuje údaje o jednom objektu (například auto, počítač, klient) a sloupce tabulky obsahují různé charakteristiky těchto objektů - atributy (například číslo motoru, značka procesoru, telefonní čísla firem). nebo klienti).

Řádky tabulky se nazývají záznamy. Všechny tabulkové položky mají stejnou strukturu – skládají se z polí (datových prvků), v nichž jsou uloženy atributy objektů (obr. 1). Každé pole záznamu obsahuje jednu charakteristiku objektu a je daným datovým typem (například textový řetězec, číslo, datum). Primární klíč slouží k identifikaci záznamů. Primární klíč je sada polí v tabulce, jejíž kombinace hodnot jednoznačně identifikuje každý záznam v tabulce.

Rýže. 1. Názvy objektů v tabulce

Pro práci s daty se používají systémy pro správu databází (DBMS). Hlavní funkce DBMS:

Definice dat (popis struktury databáze);

Zpracování dat;

Správa dat.

Vývoj struktury databáze je nejdůležitějším úkolem, který je třeba při návrhu databáze řešit. Struktura databáze (množina, forma a vztahy jejích tabulek) je jedním z hlavních návrhových rozhodnutí při vytváření aplikací využívajících databázi. Struktura databáze vytvořená vývojářem je popsána v jazyce DBMS pro definici dat.

Jakýkoli DBMS vám umožňuje provádět následující operace s daty:

Přidávání záznamů do tabulek;

Odstranění záznamů z tabulky;

Aktualizace hodnot některých polí v jednom nebo více záznamech v databázových tabulkách;

Vyhledejte jeden nebo více záznamů, které odpovídají zadané podmínce.

K provádění těchto operací se používá dotazovací mechanismus. Výsledkem provádění dotazu je buď sada záznamů vybraných podle určitých kritérií, nebo změny v tabulkách. Požadavky na databázi jsou vytvářeny v jazyce speciálně vytvořeném pro tento účel, který se nazývá „jazyk strukturované dotazy» (SQL - Structured Query Language).

Správa dat je obvykle chápána jako ochrana dat před neoprávněným přístupem, podpora víceuživatelského režimu práce s daty a zajištění integrity a konzistence dat.

Normalizace

normální formy

viz také

• relační model
• Relační DBMS

Podívejte se, co je "Relational DB" v jiných slovnících:

Relační databáze- Relační databáze databáze založená na relačním datovém modelu. Slovo „relační“ pochází z angličtiny. vztah (vztah). Používá se pro práci s relačními databázemi relační DBMS. Používání relační databázeúdaje byly ... ... Wikipedie

Relační DBMS- Relační DBMS (RDBMS; jinak Relational Database Management System, RDBMS) DBMS, která spravuje relační databáze. Pojem relační (anglický vztahový vztah) je spojen s vývojem známého anglického specialisty na ... ... Wikipedia

Prostorová DB- Relační databáze ukládají data ve dvourozměrném formátu, ve kterém jsou datové tabulky prezentovány jako řádky a sloupce. Vícerozměrné databázové systémy nabízejí rozšíření tohoto systému o umožnění vícerozměrného zobrazení dat. K ... ... Wikipedie

Algebra Codd- Obsah 1 Relační operátory 1.1 Kompatibilita vztahů ... Wikipedie

OLAP- (anglické online analytické zpracování, analytické zpracování v reálném čase) technologie zpracování dat, která spočívá v přípravě souhrnných (agregovaných) informací na základě velkých datových polí strukturovaných podle ... ... Wikipedie

Kategorie gramatiky- Gramatická kategorie je uzavřený systém vzájemně se vylučujících a protichůdných gramatických významů (gramů), který specifikuje rozdělení rozsáhlého souboru slovních tvarů (nebo malého souboru vysokofrekvenčních tvarů slov s ... ... Wikipedia

ORM- může také znamenat: anglicky. Object Role Model, rus. Metodika modelu objektové role koncepční design informačních systémů včetně vlastního grafického zápisu. Obsah 1 Úkol ... Wikipedie

DBMS

DBMS souborového serveru- Systém pro správu databází (DBMS) specializovaný program(obvykle sada programů) určených k organizaci a údržbě databáze. K vytváření a správě informační systém DBMS je nezbytný ve stejném rozsahu jako pro ... ... Wikipedii

Relační algebra- Relační algebra je uzavřený systém operací s relacemi v relačním datovém modelu. Operace relační algebry se také nazývají relační operace. Počáteční soubor 8 operací navrhl E. Codd v 70. letech a ... ... Wikipedia

knihy

• Relační databáze. Manuál, Jennifer Widom. Relační databáze napsali známí vědci ze Stanfordu Jeffrey Ullman a Jennifer Weed. Autoři nabízejí uživatelsky orientovaný přístup k ... Koupit za 1074 rublů
• Relační databáze, Ullman D., Weed D. Knihu „Relační databáze“ napsali známí vědci Stanfordské univerzity Jeffrey Ullman a Jennifer Weed. Autoři navrhují uživatelsky orientovaný přístup k…

Relační databáze - základní pojmy

Často, když mluvíme o databázi, mají na mysli prostě nějaké automatické ukládání dat. Tato reprezentace není zcela správná. Proč tomu tak je, bude uvedeno níže.

Databáze je totiž v užším slova smyslu určitý soubor dat nezbytných pro práci (aktuální data). Data jsou však abstrakcí; nikdo nikdy neviděl „jen data“; nevznikají a neexistují samy o sobě. Data jsou odrazem objektů reálného světa. Nechte si například uložit informace o přijatých dílech na sklad. Jak se v databázi zobrazí objekt reálného světa – detail? Chcete-li odpovědět na tuto otázku, musíte vědět, jaké vlastnosti nebo aspekty součásti budou relevantní, nezbytné pro práci. Mezi nimi může být název dílu, jeho hmotnost, rozměry, barva, datum výroby, materiál, ze kterého je vyroben atd. V tradiční terminologii se objekty reálného světa, o kterých jsou informace uloženy v databázi, nazývají entity (toto slovo ať čtenáře neděsí – jde o obecně přijímaný termín) a jejich skutečné vlastnosti se nazývají atributy.

Každá vlastnost určitého objektu je hodnotou atributu. Například motorová část má hodnotu hmotnostního atributu 50, což odráží skutečnost, že tento motor váží 50 kilogramů.

Bylo by chybou předpokládat, že se v databázi odrážejí pouze fyzické objekty. Dokáže vstřebat informace o abstrakcích, procesech, jevech – tedy o všem, s čím se člověk při své činnosti setkává. Takže například databáze může uchovávat informace o objednávkách dodávek dílů do skladu (ačkoli se nejedná o fyzický objekt, ale o proces). Atributy entity "objednávka" budou název dodávaného dílu, množství dílů, název dodavatele, dodací lhůta atd.

Objekty reálného světa jsou mezi sebou propojeny mnoha komplexními závislostmi, které je třeba brát v úvahu při informačních činnostech. Například díly dodávají do skladu jejich výrobci. Mezi atributy dílu proto musí být zahrnut atribut „jméno výrobce“. To však nestačí, protože mohou být potřebné další informace o výrobci konkrétního dílu - jeho adresa, telefonní číslo atd. To znamená, že databáze musí obsahovat nejen informace o dílech a objednávkách, ale také informace o jejich výrobcích. Kromě toho by databáze měla odrážet vazby mezi díly a výrobci (každý díl vyrábí konkrétní výrobce) a mezi objednávkami a díly (každá objednávka je zadána na konkrétní díl). Všimněte si, že v databázi by měly být uloženy pouze relevantní, významné vztahy.

V širokém slova smyslu je tedy databáze souborem popisů objektů reálného světa a vztahů mezi nimi, které jsou relevantní pro konkrétní aplikační oblast. V následujícím budeme vycházet z této definice a v průběhu prezentace ji upřesňovat.

Relační datový model

Takže jsme získali představu o tom, co je uloženo v databázi. Nyní musíme pochopit, jak se entity, atributy a vztahy mapují na datové struktury. To je určeno datovým modelem.

Tradičně jsou všechny DBMS klasifikovány podle základního datového modelu. Je obvyklé vyčlenit hierarchické, síťové a relační datové modely. Někdy je k nim přidán datový model seznamu účtování. V souladu s tím hovoří o hierarchickém, síťovém, relačním DBMS nebo DBMS založené na seznamech příspěvků.

Z hlediska prevalence a popularity jsou dnes relační DBMS mimo konkurenci. Staly se de facto oborovým standardem, a proto se domácí uživatel bude muset ve své praxi vypořádat s relačním DBMS. Pojďme se rychle podívat na relační datový model, aniž bychom se pouštěli do jeho detailů.

Byl vyvinut Coddem již v letech 1969-70 na základě matematické teorie vztahů a je založen na systému pojmů, z nichž nejdůležitější jsou tabulka, relace, řádek, sloupec, primární klíč, cizí klíč.

Relační databáze je taková, ve které jsou všechna data prezentována uživateli ve formuláři obdélníkové stoly datové hodnoty a všechny operace s databází jsou redukovány na manipulaci s tabulkami. Tabulka se skládá z řádků a sloupců a má název, který je v rámci databáze jedinečný. Tabulka odráží typ objektu reálného světa (entity) a každý řádek představuje konkrétní objekt. Tabulka dílů tedy obsahuje informace o všech dílech uložených ve skladu a její řádky jsou sady hodnot atributů pro konkrétní díly. Každý sloupec tabulky je sada hodnot určitého atributu objektu. Sloupec Materiál je tedy souborem hodnot „Ocel“, „Cín“, „Zinek“, „Nikl“ atd. Sloupec Množství obsahuje nezáporná celá čísla. Hodnoty ve sloupci Hmotnost jsou reálná čísla rovnající se hmotnosti dílu v kilogramech.

Tyto hodnoty se neobjevují ze vzduchu. Vybírají se ze sady všech možných hodnot pro atribut objektu, nazývaný doména. Hodnoty ve sloupci materiál se tedy vybírají z množiny názvů všech možných materiálů - plasty, dřevo, kovy atd. Proto je v zásadě nemožné, aby se ve sloupci Materiál objevila hodnota, která není v odpovídající doméně, například „voda“ nebo „písek“.

Každý sloupec má název, který se obvykle píše v horní části tabulky ( Rýže. 1). Musí být jedinečný v rámci tabulky, ale různé tabulky mohou mít sloupce se stejným názvem. Každá tabulka musí mít alespoň jeden sloupec; Sloupce jsou v tabulce uspořádány podle pořadí, v jakém se jejich názvy objevují při vytváření tabulky. Na rozdíl od sloupců nemají řádky názvy; jejich pořadí v tabulce není definováno a jejich počet není logicky omezen.

Obrázek 1. Základní pojmy databáze.

Vzhledem k tomu, že řádky v tabulce nejsou seřazeny, není možné vybrat řádek podle jeho pozice - mezi nimi není „první“, „druhý“, „poslední“. Každá tabulka má jeden nebo více sloupců, jejichž hodnoty jednoznačně identifikují každý z jejích řádků. Takový sloupec (nebo kombinace sloupců) se nazývá primární klíč. V tabulce dílů je primárním klíčem sloupec Číslo dílu. V našem příkladu má každý díl ve skladu jedno číslo, pomocí kterého jsou potřebné informace načteny z tabulky dílů. Proto je v této tabulce primárním klíčem sloupec Číslo dílu. Hodnoty v tomto sloupci nelze duplikovat – v tabulce dílů nesmí být řádky, které mají stejnou hodnotu ve sloupci Číslo dílu. Pokud tabulka tento požadavek splňuje, nazývá se relace.

Vztah tabulek je základním prvkem relačního datového modelu. Je podporován cizími klíči. Zvažte příklad, ve kterém databáze ukládá informace o běžných zaměstnancích (tabulka Zaměstnanci) a vedoucích pracovníků (tabulka Manažer) v organizaci ( Rýže. 2). Primárním klíčem tabulky Manažer je sloupec Číslo (například osobní číslo). Sloupec Příjmení nemůže sloužit jako primární klíč, protože ve stejné organizaci mohou pracovat dva manažeři se stejným příjmením. Každý zaměstnanec je podřízen jedinému vedoucímu, což by se mělo projevit v databázi. Tabulka Zaměstnanec obsahuje sloupec Číslo manažera a hodnoty v tomto sloupci se vybírají ze sloupce Číslo v tabulce Manažer (viz obrázek 1). Rýže. 2). Sloupec Číslo manažera je cizí klíč v tabulce Zaměstnanec.

Obrázek 2. Vztah databázových tabulek.

Tabulky nelze ukládat a zpracovávat, pokud v databázi nejsou žádná „data o datech“, jako jsou deskriptory tabulek, deskriptory sloupců atd. Obvykle se nazývají metadata. Metadata jsou také prezentována v tabulkové formě a uložena v datovém slovníku.

Kromě tabulek lze v databázi ukládat i další objekty, jako jsou formuláře obrazovek, sestavy (sestavy), pohledy (pohledy) a dokonce i aplikace, které s databází pracují.

Pro uživatele informačního systému nestačí, že databáze pouze odráží objekty reálného světa. Je důležité, aby taková reflexe byla jednoznačná a konzistentní. V tomto případě se říká, že databáze splňuje podmínku integrity.

Aby byla zaručena správnost a vzájemná konzistence dat, jsou na databázi uvalena určitá omezení, která se nazývají omezení integrity dat.

Existuje několik typů omezení integrity. Je například vyžadováno, aby hodnoty ve sloupci tabulky byly vybrány pouze z odpovídající domény. V praxi se berou v úvahu složitější integritní omezení, například referenční integrita. Jeho podstata spočívá v tom, že cizí klíč nemůže být ukazatelem na neexistující řádek v tabulce. Omezení integrity jsou implementována pomocí speciálních nástrojů, o kterých bude pojednáno v Sek.Databázový server .

jazyk SQL

Data v počítačové podobě nejsou sama o sobě pro uživatele zajímavá, pokud neexistují žádné prostředky, jak se k nim dostat. Přístup k datům je realizován formou dotazů do databáze, které jsou formulovány ve standardním dotazovacím jazyce. Dnes je pro většinu DBMS tímto jazykem SQL.

Vznik a vývoj tohoto jazyka jako prostředku pro popis přístupu k databázi je spojen s vytvořením teorie relačních databází. prototyp jazyk SQL vznikl v roce 1970 jako součást výzkumného projektu System/R v laboratoři IBM Santa Teresa. SQL je nyní standardem pro rozhraní se systémy správy relačních databází. Jeho popularita je tak velká, že vývojáři nerelačních DBMS (například Adabas) dodávají svým systémům SQL rozhraní.

Jazyk SQL má oficiální standard - ANSI/ISO. Většina vývojářů DBMS tento standard dodržuje, ale často jej rozšiřuje o implementaci nových možností zpracování dat. Nové mechanismy správy dat, které budou popsány v Sek.Databázový server , lze použít pouze prostřednictvím speciálních příkazů SQL, které nejsou obecně součástí jazykového standardu.

SQL není programovací jazyk ve své tradiční podobě. Nepíšou se na něm programy, ale dotazy do databáze. Proto je SQL deklarativní jazyk. To znamená, že může být použit k formulaci toho, co je třeba získat, ale nemůže naznačit, jak by to mělo být provedeno. Konkrétně, na rozdíl od procedurálních programovacích jazyků (C, Pascal, Ada), SQL neobsahuje takové příkazy jako if-then-else, for, while atd.

Nebudeme se podrobně zabývat syntaxí jazyka. Dotkneme se toho jen v míře nezbytné pro pochopení jednoduchých příkladů. S jejich pomocí budou ukázány nejzajímavější mechanismy zpracování dat.

SQL dotaz se skládá z jednoho nebo více příkazů, jeden po druhém, oddělených středníkem. Tabulka 1 níže uvádí nejdůležitější operátory, které jsou součástí standardu ANSI/ISO SQL.

Tabulka 1. Základní operátory jazyka SQL.

SQL dotazy používají názvy, které jednoznačně identifikují databázové objekty. Jedná se zejména o název tabulky (Detail), název sloupce (Name) a také názvy dalších objektů v databázi, které patří k dalším typům (například názvy procedur a pravidel), které budou diskutováno v Sek.Databázový server . Spolu s jednoduchými názvy se používají i názvy komplexní - např. kvalifikovaný název sloupce definuje název sloupce a název tabulky, do které patří (Detail.Weight). Pro zjednodušení budou v příkladech názvy psány v ruštině, i když v praxi se to nedoporučuje.

Každý sloupec v jakékoli tabulce ukládá určité typy dat. Rozlišovat základní typy data - znakové řetězce pevné délky, celá čísla a reálná čísla a další datové typy - znakové řetězce proměnné délky, měna, datum a čas, logická data (dvě hodnoty - "TRUE" a "FALSE"). V SQL můžete použít číselné, řetězcové, znakové, datové a časové konstanty.

Podívejme se na pár příkladů.

Dotaz "zjistit počet dílů na skladě pro všechny typy dílů" je implementován následovně:

SELECT Název, Množství

OD Detail;

Výsledkem dotazu bude tabulka se dvěma sloupci – Název a Množství, které jsou převzaty z původní tabulky Detail. Tento dotaz v podstatě umožňuje získat vertikální projekci původní tabulky (přesněji vertikální podmnožinu sady řádků tabulky). Ze všech řádků tabulky podrobností se vytvoří řádky, které obsahují hodnoty převzaté ze dvou sloupců – Název a Množství.

Dotaz "jaké díly vyrobené z oceli jsou skladem?", formulovaný v SQL, vypadá takto:

OD Detail

WHERE Materiál = "Ocel";

Výsledkem tohoto dotazu bude také tabulka obsahující pouze ty řádky ve zdrojové tabulce, které mají ve sloupci Materiál hodnotu "Ocel". Tento dotaz umožňuje získat horizontální projekci tabulky podrobností (hvězdička v příkazu SELECT znamená, že jsou vybrány všechny sloupce z tabulky).

Dotaz „určete název a počet dílů na skladě, které jsou vyrobeny z plastu a váží méně než pět kilogramů“ by zněl takto:

SELECT Název, Množství

OD Detail

KDE Materiál = "Plast"

A Hmotnost< 5;

Výsledkem dotazu je tabulka se dvěma sloupci – Název, Množství, která obsahuje název a počet dílů vyrobených z plastu a vážících méně než 5 kg. Ve skutečnosti je operace výběru operací vytvoření nejprve vodorovného promítání (najděte všechny řádky tabulky dílů, pro které Materiál = "Plast" a Hmotnost< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Jedním z prostředků k zajištění rychlý přístup k tabulkám, jsou indexy. Index je struktura databáze, která je ukazatelem na určitý řádek tabulky. Databázový rejstřík se používá stejným způsobem jako rejstříkový rejstřík v knize. Obsahuje hodnoty převzaté z jednoho nebo více sloupců určitého řádku tabulky a odkaz na tento řádek. Hodnoty v indexu jsou uspořádány, což umožňuje výkon DBMS rychlé hledání ve stole.

Předpokládejme, že dotaz je formulován do databáze Warehouse:

SELECT Název Množství, Materiál

OD Detail

WHERE Číslo = "T145-A8";

Pokud pro tuto tabulku neexistují žádné indexy, pak pro provedení tohoto dotazu musí DBMS prohledat celou tabulku podrobností, postupně z ní vybírat řádky a kontrolovat podmínky výběru pro každý z nich. U velkých tabulek bude dokončení takového dotazu trvat velmi dlouho.

Pokud byl dříve vytvořen index ve sloupci Číslo detailu tabulky, pak se doba hledání v tabulce zkrátí na minimum. Index bude obsahovat hodnoty ze sloupce Number a odkaz na řádek s touto hodnotou v tabulce Part. Při provádění dotazu DBMS nejprve najde hodnotu "T145-A8" v indexu (a udělá to rychle, protože index je uspořádán a jeho řádky jsou malé) a poté pomocí odkazu v indexu určí fyzické umístění hledaného řádku.

Index se vytvoří pomocí příkazu SQL CREATE INDEX. V tento příklad operátor

VYTVOŘTE UNIKÁTNÍ INDEX Index součásti

ON Detail (číslo);

vytvoří index s názvem "Index součásti" ve sloupci Číslo tabulky součástí.

Pro uživatele DBMS nejsou zajímavé jednotlivé příkazy jazyka SQL, ale nějaká jejich posloupnost, navržená jako jeden celek a dávající z jeho pohledu smysl. Každá taková sekvence SQL příkazů implementuje určitou akci na databázi. Provádí se v několika krocích, z nichž každý provádí nějaké operace s databázovými tabulkami. Ano, v bankovní systém převod určité částky z krátkodobého účtu na dlouhodobý se provádí ve více operacích. Mezi nimi - výběr částky z krátkodobého účtu, připsání na dlouhodobý účet.

Pokud dojde k selhání v procesu provádění této akce, například když je první operace dokončena, ale druhá ne, budou peníze ztraceny. Jakákoli akce s databází proto musí být provedena zcela nebo neprovedena vůbec. Tato akce se nazývá transakce.

Zpracování transakcí závisí na protokolu, který se používá k vrácení transakcí a obnovení stavu databáze. Více podrobností o transakcích bude projednáno v Sek.Zpracování transakcí .

Na závěr diskuzi o jazyku SQL ještě jednou zdůrazňujeme, že se jedná o dotazovací jazyk. Nemůžete napsat žádný složitý aplikační program, který pracuje s databází. Pro tento účel moderní DBMS používají jazyk čtvrté generace (Forth Generation Language - 4GL), který má jak hlavní rysy procedurálních jazyků třetí generace (3GL), jako je C, Pascal, Ada, tak schopnost vkládat SQL. příkazy v textu programu, stejně jako ovládací prvky uživatelského rozhraní (nabídky, formuláře, uživatelský vstup atd.). Dnes je 4GL jedním z de facto standardů nástrojů pro vývoj databázových aplikací.

relační model

Model relační databáze navrhl v roce 1969 matematik a výzkumník IBM E.F. Codd (E.F. Codd). Některé počáteční informace o relačních databázích jsou obsaženy v přehledovém článku „ DB a DBMS” 2. Vzhledem k tomu, že v současnosti dominují relační databáze, v tomto článku (a také v článcích “ Popis dat”, “Zpracování dat" A " Návrh databáze” 2) nejpodstatnější koncepty relačního modelu jsou zvažovány podrobně.

Hned si všimneme, že teorie relačních databází byla původně formulována v přísném matematickém jazyce a jedná se o striktní, formálně definované matematické pojmy. nejlepší způsob popsat podstatu věcí. Přitom ve většině případů je možné bez větší újmy obětovat přísnost terminologie ve prospěch transparentnosti prezentace, o což se pokusíme.

Hlavní myšlenka relačního modelu je následující. Databáze se skládá z řady neuspořádaných tabulky(V nejjednodušším případě - z jedné tabulky). S tabulkami lze manipulovat prostřednictvím neprocedurálních (deklarativních) operací - žádosti, jehož výsledky jsou zároveň tabulkami.

Často slovo "relační" ( vztahový) v termínu „relační model“ se vykládá na základě skutečnosti, že vztahy jsou založeny v relační databázi ( vztahovat) mezi tabulkami. Toto vysvětlení je pohodlné, ale není přesné. V původní Coddově terminologii jsou termíny spojení ( vztahy), atributy ( atributy) a n-tice ( n-tice) byly použity tam, kde většina z nás používá známější výrazy tabulky, sloupce (pole) a řádky (záznamy).

Při sestavování infoologického modelu předmětné oblasti (viz „ DB a DBMS”, “Návrh databáze“2) vyniknout entity(předměty), popište je vlastnosti a (charakteristiky, atributy), nezbytné pro účely modelování, a jsou stanoveny vztahy mezi entitami. Ve fázi přechodu z infologického na datalogický relační model se objevují tabulky. Každá entita je obvykle reprezentována jednou tabulkou. Každý řádek tabulky (jeden záznam) odpovídá jedné instanci entity a každé pole popisuje nějakou vlastnost (atribut).

Pokud například potřebujeme uložit informace o lidech, včetně příjmení, křestního jména, příjmení, DIČ, země bydliště a data narození každého, pak je entitou osoba a zadaná data jsou atributy. Samotná entita se přirozeně stává názvem tabulky.

stůl "Muž"

Relační model vyžaduje, aby každý řádek v tabulce byl jedinečný, tzn. aby se libovolné dva řetězce lišily hodnotou alespoň jednoho atributu.

Tradiční tabulková forma užitečné, když chcete prezentovat samotná data. Pokud vás, jako ve výše uvedeném příkladu, zajímá pouze struktura- názvy polí, pak z hlediska srozumitelnosti, snadného použití v diagramech a úspory místa je vhodnější je znázornit takto:

Klíče

klíč tabulkynazývá se pole nebo skupina polí obsahující jedinečné hodnoty v dané tabulce. Klíč jednoznačně identifikuje odpovídající řádek tabulky. Pokud se klíč skládá z jednoho pole, je často nazýván jednoduchý pokud z několika - kompozitní. Ve výše uvedeném příkladu je klíčem pole DIČ (předpokládáme, že DIČ jsou v rámci země jedinečná).

Zvažte příklad tabulky se složeným klíčem. Stránky s předpověďmi počasí často prezentují následující informace: pro každé datum uveďte předpokládanou teplotu v noci, ráno, odpoledne a večer. K uložení těchto informací můžete použít tabulku v následujícím formuláři:

V této tabulce nejsou klíče ani pole Datum, ani Denní čas, ani Teplota - v každém z těchto polí se mohou hodnoty opakovat. Kombinace polí Datum+Čas dne je však jedinečná a jednoznačně identifikuje řádek tabulky. Toto je složený klíč.

Často nastává situace, kdy volba klíče není jednoznačná. Vraťme se k prvnímu příkladu. Předpokládejme, že kromě příjmení, jména, patronyma, DIČ, data narození je nutné uložit sérii a číslo občanského pasu a sérii a číslo zahraničního pasu. Tabulka bude vypadat takto.

V této tabulce si můžete vybrat až tři klíče. Jeden z nich je jednoduchý (TIN), další dva jsou složené (Série + Číslo občanského pasu a Série + Číslo zahraničního pasu). V takové situaci si vývojář vybere klíč, který je nejpohodlnější z hlediska organizace databáze (obecně klíč, jehož nalezení hodnoty zabere nejméně času). Zvolený klíč je v tomto případě často označován jako hlavní klíč, popř hlavní, klíč a další kombinace sloupců, ze kterých můžete vytvořit klíč - možný, nebo alternativní klávesy. Všimněte si, že v tabulce je vždy alespoň jeden možný klíč, protože řádky se nemohou opakovat, a proto je zaručeno, že kombinace všech sloupců je možným klíčem.

Při zobrazování tabulek primární klíče tabulky jsou identifikovány. Příslušná pole jsou například často podtržena. A Microsoft Access zvýrazní klíčová pole tučně.

Častěji než s nejednoznačností klíče se vývojáři potýkají s tím, že v datech, která chtějí uložit, chybí klíč. Podobná skutečnost může být zjištěna v procesu analýzy předmětné oblasti. Chcete-li například uložit jednoduchý seznam osob - jména, příjmení, patronymie a data narození, pak v této sadě atributů není vůbec žádný klíč - lze si představit situaci, kdy dva různých lidí uvedené údaje jsou totožné. V tomto případě musíte uměle zavést další pole, například jedinečné osobní číslo. Takový klíč se někdy v literatuře nazývá náhrada. Poměrně často se z důvodu efektivity zavádí také náhradní klíč. Pokud má například tabulka dlouhý složený klíč, pak vývojáři často zavádějí další krátký číselný náhradní klíč a činí z něj primární klíč. To se často dělá, i když existuje jednoduchý klíč, který má „nepohodlný“ (neefektivní pro vyhledávání) datový typ, například řetězec. Takové operace již nesouvisí s teorií, ale často se s nimi setkáváme v praxi.

Pozorný čtenář si může všimnout, že klíč lze téměř vždy rozšířit (pokud nezahrnuje všechna pole tabulky) zahrnutím nadbytečných polí. Formálně takový klíč zůstane klíčem, ale z praktického hlediska jde jen o hru pojmů. Takové klíče nejsou ani považovány za možné, protože je vždy nutné usilovat o minimalizaci délky (složitosti) klíče.

Normální formy, normalizace

Ne každá tabulka, kterou můžeme nakreslit na papír nebo ve Wordu, může být tabulkou relační databáze. A ne každá tabulka, kterou lze použít v relační databázi, je správná z hlediska požadavku relačního modelu.

Za prvé, vyžaduje, aby všechna data v jednom sloupci byla stejného typu(typy viz“Popis dat“2). Z tohoto pohledu níže uvedený příklad ani nemá smysl rozebírat:

Za druhé, vyžaduje, aby tabulka měla přiřazený primární klíč.

Tyto požadavky jsou nutné, ale nestačí. Teorie relačních databází zavádí koncepty tzv. „normálních forem“ – požadavků na uspořádání dat v tabulkách. Normální formuláře jsou číslovány postupně, protože požadavky jsou přísnější. Ve správně navržené databázi jsou tabulky alespoň ve třetí normální formě. Podle toho budeme uvažovat první tři normální formy. Připomeňme, že máme co do činění s tabulkami, které splňují dva hlavní požadavky formulované výše.

První normální forma (1NF)

První normální forma diktuje, že všechna data obsažená v tabulce musí být atomická.(nedělitelný). Seznam odpovídajících atomových datových typů určuje DBMS. Požadavek 1NF je zcela přirozený. To znamená, že každé pole každého záznamu by mělo obsahovat pouze jednu hodnotu, ale ne pole nebo jinou datovou strukturu. Zde je smysluplný příklad tabulky, která není v 1NF. Předpokládejme, že máme seznamy známek studentů v nějakém předmětu.

Protože hodnota pole Grades není atomická, tabulka nesplňuje požadavky 1NF.

O možný způsob prezentace seznamu hodnocení je napsána v metodických doporučeních k článku "DB design" 2.

Druhá normální forma (2NF)

O tabulce se říká, že je ve druhé normální formě, pokud je v 1NF a každý neklíčový sloupec je zcela závislý na primárním klíči. Jinými slovy, hodnota každého pole musí být plně určena hodnotou primárního klíče. Je důležité si uvědomit, že závislost na primárním klíči je chápána právě jako závislost na klíči jako celku, nikoli na jeho jednotlivé složce (v případě složeného klíče). Zde je příklad tabulky, která není v 2NF. Abychom to udělali, vraťme se k příkladu předpovědi počasí a přidejte do tabulky další sloupec - čas východu slunce (toto je zcela věrohodný příklad, tento druh informací se často uvádí na stránkách s předpověďmi počasí).

Jak si pamatujeme, tato tabulka má složený klíč Datum + denní čas. Pole Teplota je zcela závislá na primárním klíči – nejsou s ním žádné problémy. Ale pole Východ slunce závisí pouze na poli Datum, Denní čas přirozeně neovlivňuje čas východu Slunce.

Zde je na místě položit si otázku: jaký je praktický význam 2NF? Jaké je použití těchto omezení? Ukázalo se, že je velký. Řekněme, že ve výše uvedeném příkladu vývojář ignoruje požadavky 2NF. Za prvé, pravděpodobně dojde k tzv nadbytek- ukládání nadbytečných dat. Pokud je totiž u jednoho záznamu s daným datem již uložen čas východu slunce, tak u všech ostatních záznamů s daným datem by měl být stejný a obecně řečeno není potřeba jej ukládat.

Věnujme pozornost slovům „měl by být“. A pokud ne? Na úrovni databáze to totiž není nijak kontrolováno – klíč v tabulce je složený, stejná data mohou být (a nejspíš budou). A žádná formální omezení (a naše chápání, že „toto nemůže být“ na takové neplatí) nezakazují specifikaci jiný čas východ slunce na stejné datum.

Třetí normální forma (3NF)

O tabulce se říká, že je v 3NF, pokud je 2NF a všechny neklíčové sloupce jsou vzájemně nezávislé.

Je vhodné chápat vzájemnou závislost sloupců následovně: sloupce jsou vzájemně závislé, pokud nemůžete změnit jeden z nich, aniž byste změnili druhý.

Zde je příklad tabulky, která není v 3NF. Zvažte jednoduchý příklad notebook pro ukládání domácích telefonů lidí žijících případně v různých regionech země.

Tato tabulka má závislost mezi neklíčovými sloupci City a City Code, takže tabulka není v 3NF.

Všimněte si, že přítomnost výše uvedené závislosti určuje vývojář analýzou předmětné oblasti - takovou kolizi nelze vidět žádnými formálními metodami. Když změníte vlastnosti oblasti předmětu, závislost mezi sloupci může zmizet. Pokud jsou například v rámci stejného města zadány různé kódy (jako 495 a 499 v Moskvě), odpovídající sloupce přestanou souviset, pokud jde o porušení požadavků 3NF.

V teorii relačních databází jsou uvažovány i formy vyššího řádu - Boyce-Coddova normální forma, 4NF, 5NF a ještě vyšší. Tyto formy nemají velký praktický význam a vývojáři se zpravidla vždy zastaví u 3NF.

Normalizace databáze

Normalizace je proces převedení databázových tabulek do zvolené normální formy. Normalizace na 2NF zpravidla vede k rozkladu - rozdělení jedné tabulky na několik. Normalizaci na 3NF lze obvykle provést odstraněním závislých (vypočítaných) sloupců. V některých případech se při normalizaci na 3NF musí také provést rozklad.

Vícetabulkové databáze, vztahy mezi tabulkami, cizí klíče

V praxi jsou jednotabulkové databáze poměrně vzácné, jelikož z hlediska modelování doménové databáze přítomnost jedné tabulky znamená přítomnost jedné entity. Přítomnost několika entit zase obvykle znamená existenci vztahů mezi nimi.

Aniž bychom si stanovili cíl kompletního návrhu databáze, uvažujme příklad, který nám umožní demonstrovat vztahy v databázích s více tabulkami.

Předpokládejme, že máme co do činění se školou, ve které jsou studenti seskupení do tříd a učitelé, kteří vyučují některé předměty. Okamžitě rozlišujeme čtyři entity: studenty, učitele, třídy a předměty. Tyto entity nám již poskytují čtyři tabulky.

Dále se musíme rozhodnout o atributech entit – jaký druh informací budeme ukládat. Jelikož je náš příklad čistě ilustrativní, pokusíme se minimalizovat množství uložených informací. Domluvme se, aby si každý žák uložil příjmení a jméno, pro třídu - číslo paralely a písmeno identifikující třídu uvnitř paralely, pro učitele - příjmení, jméno a patronymie, pro předmět - pouze jeho název.

Nyní musíme vyřešit problém s primárními klíči. Tabulky studentů a učitelů v zásadě nemají klíč, proto do nich zavedeme náhradní číselný klíč - číslo. Tabulky tříd a položek mají obecně klíče. V tabulce tříd je klíč složený, je tvořen atributy Parallel Number + Letter a v tabulce objektů je jednoduchý klíč tvořen jediným polem - názvem objektu. Připomeňme, že když jsme mluvili o klíčích, zmínili jsme, že náhradní klíče se často přidávají z důvodů efektivity ve snaze zbavit se složených klíčů nebo klíčových polí nepohodlných typů, jako jsou řetězce. Takto to uděláme. Ke každé z tabulek přidáme náhradní číselný klíč.

Ve výsledku získáme následující sadu tabulek odpovídající popsaným entitám.

Když pochopíme, jakou předmětovou oblastí se zabýváme, víme, že naše entity neexistují samy o sobě - ​​jsou spojeny některými vztahy, které jsme nastínili výše. Jak je ale technicky propojit? Zde se neobejdete bez zavedení dalších polí a dokonce i dodatkových tabulek. Pojďme se zabývat vztahy mezi entitami v pořádku.

Chcete-li přiřadit studenta k určité třídě, vytvořte další pole Číslo třídy v tabulce "Student". (Je jasné, že jeho typ se musí zcela shodovat s typem pole Číslo třídy v tabulce „Třída“.) Nyní můžeme propojit tabulky „Student“ a „Třída“ porovnáním hodnot polí Číslo třídy (my nepojmenoval tato pole náhodou stejně, v praxi se to často dělá pro snadnou navigaci ve vazebných polích). Všimněte si, že jeden záznam v tabulce „Třída“ může odpovídat mnoha záznamům v tabulce „Student“ (a v praxi tomu tak velmi pravděpodobně je – je těžké si představit třídu jednoho žáka). Říká se, že takové tabulky spolu souvisí vztahem „ jeden k mnoha". A zavolá se pole čísla třídy v tabulce „Student“. cizí klíč. Jak vidíte, účelem cizích klíčů je propojovat tabulky. Všimněte si, že cizí klíč vždy odkazuje na primární klíč. propojená tabulka(tj. cizí klíč je na straně "mnoho"). Zavolá se cizí primární klíč rodičovský, i když se tento termín používá méně často.

Pojďme ilustrovat, co bylo řečeno, pomocí diagramu ve stylu Microsoft Access (další informace o „datovém schématu“ Accessu naleznete v článku "Popis dat" 2).

Nyní se zamysleme nad učiteli a předměty. Při analýze předmětové oblasti (jediný způsob - koneckonců je nemožné extrahovat skutečný stav věcí ze samotného formálního modelu) si všimneme, že typ spojení mezi entitami „učitel“ a „předmět“ je jiný než uvažováno výše. Vždyť nejen jeden předmět může učit mnoho učitelů, ale jeden učitel může učit mnoho předmětů. Mezi těmito entitami tedy existuje spojení „ mnoho pro mnoho". Zde již nestačí zavádět další pole (zkuste to!). Vztahy many-to-many jsou vždy vyřešeny zavedením další tabulky. Jmenovitě organizujeme tabulku „Učitel-předmět“, která má následující strukturu:

Tabulka "Učitel-předmět"

Tato tabulka má složený klíč vytvořený ze dvou polí. Tabulka „Učitel“ i tabulka „Předmět“ souvisí s touto tabulkou ve vztahu jeden k mnoha (samozřejmě v obou případech je „mnoho“ na straně „Učitel-předmět“). Podle toho jsou v tabulce „Učitel-Předmět“ dva cizí klíče (oba jsou součástí složeného primárního klíče, což není zakázáno), které slouží k propojení s odpovídajícími tabulkami.

V praxi kromě uvažovaných vztahů „one-to-many“ a „many-to-many“ existuje také „ jeden k jednomu". Z hlediska teorie není takový vztah zajímavý, protože dvě tabulky spojené vztahem jedna ku jedné lze vždy jednoduše spojit do jedné. Ve skutečných databázích se však k optimalizaci zpracování dat používá vztah jedna ku jedné. Ilustrujme výše uvedené na příkladu.

Předpokládejme, že uchováváme mnoho různých informací o lidech - údaje o jejich různých dokumentech, telefonní čísla, adresy atd. S největší pravděpodobností bude většina těchto údajů používána velmi zřídka. A často nám stačí jen příjmení, jméno, patronymie a telefonní číslo. Pak má smysl uspořádat dvě tabulky a propojit je ve vztahu jedna ku jedné. V jedné (malé) tabulce pro ukládání často používaných informací, ve druhé - zbytek. Tabulky propojené ve vztahu jedna ku jedné mají přirozeně stejný primární klíč.

Pravidla integrity

Relační model definuje dva hlavní pravidla integrita databáze: integrita objektu a referenční integrita.

Pravidlo integrity objektů velmi jednoduché. To vyžaduje, aby primární klíče tabulek neobsahovaly hodnoty null (null)..

pravidlo referenční integritavyžaduje, aby cizí klíče neobsahovaly hodnoty nekonzistentní s nadřazenými klíči. Vrátíme-li se k výše uvedenému příkladu, měli bychom například požadovat, aby studenti patřili pouze do třídy, jejíž číslo je uvedeno v tabulce „Třídy“.

Většina DBMS je schopna monitorovat integritu dat (to samozřejmě vyžaduje patřičné úsilí od vývojáře ve fázi popisu datových struktur). Zejména se používají mechanismy k udržení referenční integrity. kaskádové operace. Kaskádování znamená zejména, že když je z „nadřazené“ tabulky odstraněn záznam, který souvisí s jinou tabulkou vztahem jedna k mnoha, všechny související záznamy jsou automaticky odstraněny z tabulky „mnoho“ (samotným DBMS bez zásahu uživatele). A to je přirozené, protože takové záznamy „visí ve vzduchu“, už s ničím nesouvisejí.

Indexování

Indexování je nesmírně důležité z hlediska praktická aplikace, ale volitelná věc z hlediska čisté teorie. Hlavním účelem indexace je optimalizace (zrychlení) vyhledávání (a podle toho i některé další operace s databází). Indexování v každém případě vyžaduje další zdroje (zap fyzické úrovni nejčastěji se vytvářejí speciální indexové soubory). Indexování může dokonce zpomalit operace související s úpravou dat, takže jsou indexovány tabulky, které se obvykle jen zřídka mění a často prohledávají.

Indexový soubor je velmi podobný knižnímu rejstříku. Pro každou hodnotu indexu je uložen seznam řádků tabulky, který obsahuje daná hodnota. Proto pro vyhledávání nemusíte procházet celou tabulku - stačí se podívat do indexu. Pokud jsou však záznamy změněny, může být nutné index znovu sestavit. A to chce čas navíc.

O výklad teorie relačních databází v rámci základního kurzu informatiky samozřejmě nemůže být řeč! Přesto je tento článek pro naši encyklopedii velmi důležitý, protože v tento případ máme co do činění s látkou, kterou nelze plně prezentovat v hodinách, ale učitel ji musí zvládnout. Proč?

Jednak proto, že řada pojmů se studuje právě v rámci základního kurzu. Jedná se jak o tabulkovou reprezentaci dat, tak o tabulkové klíče. A všichni víme, že je velmi obtížné kvalifikovaně a přesně uvést pouze některé pojmy, aniž bychom uvedli celkový obraz.

Za druhé, prováděním jednoduchých databázových dotazů s dětmi (příslušný materiál je uveden v článku "Zpracování dat" 2), je nutné se zabývat tabulkami, které jsou z hlediska teorie relace správné. Není nutné studentům vysvětlovat, že tyto tabulky jsou správné, ale „kdyby jen ..., pak by tabulka byla špatná“, ale je nepřípustné používat špatné příklady.

V profilovém kurzu informatiky může být situace zásadně odlišná. Nejdůležitější a mimořádně produktivní formou práce ve specializovaných třídách je projektová práce. V rámci vzdělávacích projektů je možné a nutné vyvíjet jednoduché databáze a zde se bez základů uvedené teorie neobejde. Je však třeba vzít v úvahu následující:

Simulované předmětové oblasti neměl by být příliš velký;

Studenti by je měli velmi dobře znát (v tomto smyslu není projekt „Škola“, který je pro každého pěkně otravný, tou nejhorší volbou!);

Je naivní očekávat, že po vyslechnutí základů teorie budou studenti schopni sami něco navrhnout. Každý krok je třeba podniknout s nimi a podrobně zdůvodnit jejich jednání.