Relační databáze. Primární klíče

• Překlad

Šířím pokračování překladu série článků pro začátečníky.
V současnosti a následujících - více informací o podstatě.
Start - .

4. TABULKY A PRIMÁRNÍ KLÍČE

V tabulce je 6 lekcí. Všech 6 je různých, ale pro každou lekci jsou v tabulce uloženy hodnoty stejných polí, konkrétně: tutorial_id (ID lekce), title (title) a category (kategorie). tutorial_id – primární klíč lekce tabulky. Primární klíč je hodnota, která je jedinečná pro každý záznam v tabulce.
V níže uvedené tabulce zákazníků je primárním klíčem customer_id. V tento případ primární klíč je také jedinečná hodnota (číslo) pro každý záznam.

Primární klíče v každodenním životě

Několik příkladů

• Číslo objednávky, které obdržíte při nákupu v internetovém obchodě, může být primárním klíčem některé tabulky objednávek v databázi tohoto obchodu, protože. je to jedinečná hodnota.
• Číslo sociálního pojištění může být primárním klíčem v nějaké tabulce v databázi vládních agentur, protože je také unikátní jako v předchozím příkladu.
• Číslo faktury lze použít jako primární klíč v databázové tabulce, která ukládá faktury vystavené zákazníkům.
• Číselné číslo zákazníka se často používá jako primární klíč v tabulce zákazníků.

Co mají tyto příklady společného? Skutečnost, že u všech je jako primární klíč zvolena jedinečná, neopakující se hodnota pro každý záznam. Znovu. Hodnoty pole databázové tabulky vybrané jako primární klíč jsou vždy jedinečné.

Co charakterizuje primární klíč? Charakteristika primárního klíče.

Primární klíč se používá pro identifikace záznamy v tabulce, takže každý záznam je jedinečný. Další přirovnání... Když zavoláte servis technická podpora, operátor vás většinou vyzve, abyste uvedl nějaké číslo (smlouva, telefon apod.), podle kterého vás lze v systému identifikovat.
Pokud jste zapomněli své číslo, operátor Help Desku vás požádá o další informace, které vás jednoznačně identifikují. Například kombinace vašich narozenin a příjmení. Mohou být také primárním klíčem, nebo spíše jejich kombinací.

Primární klíč je jedinečný.

Primární klíč má vždy jedinečnou hodnotu. Představte si, že jeho hodnota není jedinečná. Potom jej nebylo možné použít k identifikaci údajů v tabulce. To znamená, že jakákoli hodnota primárního klíče se může ve sloupci, který je vybrán jako primární klíč, vyskytnout pouze jednou. RDBMS jsou navrženy tak, aby vám zabránily vložit duplikáty do pole primárního klíče, zobrazí se chyba.
Ještě jeden příklad. Představte si, že máte tabulku s poli first_name a last_name a jsou tam dva záznamy:

| křestní_jméno | příjmení |
| vasya |dýně |
| vasya |dýně |

Tito. jsou dva Vasyové. Chcete vybrat konkrétní Vasyu z tabulky. Jak to udělat? Rekordy se neliší. Zde se hodí primární klíč. Přidáme sloupec id (klasická verze syntetického primárního klíče) a ...

id | křestní_jméno | příjmení |
1 | vasya |dýně |
2 | vasya |dýně |

Nyní je každý Vasya jedinečný.

Typy primárních klíčů.

Primárním klíčem je obvykle číselná hodnota. Může to být ale i jakýkoli jiný datový typ. Není běžnou praxí používat řetězec jako primární klíč (řetězec je kus textu), ale teoreticky i prakticky je to možné.
Složené primární klíče.
Primární klíč se často skládá z jednoho pole, ale může to být i kombinace více sloupců, například dva (tři, čtyři ...). Pamatujte však, že primární klíč je vždy jedinečný, což znamená, že kombinace n-tého počtu polí, v tomto případě 2, musí být jedinečná. Později vám o tom řeknu více.

Automatické číslování.

Pole primárního klíče je často, ale ne vždy, zpracováváno samotnou databází. Relativně vzato můžete databázi sdělit, aby každému záznamu při jeho vytvoření automaticky přiřadila jedinečnou číselnou hodnotu. Databáze obvykle začíná číslovat od 1 a zvyšuje toto číslo pro každou položku o jednu. Takový primární klíč se nazývá auto-incrementing nebo auto-numbered. Použití kláves automatického zvýšení − dobrá cesta nastavit jedinečné primární klíče. Klasický název pro takový klíč je náhradní primární klíč [Jak bylo uvedeno výše. - Cca. překlad]. Tento klíč neobsahuje užitečné informace, vztahující se k entitě (objektu), informace o které jsou uloženy v tabulce, proto se nazývá náhradní.

5. PROPOJENÍ TABULEK S CIZÍMI KLÍČI

• definování, které entity do něj chcete uložit
• Jaké jsou vztahy mezi těmito entitami?

Jeden k mnoha.

Jedna věc je nyní důležitá – že pro vztah jeden k mnoha dva samostatné tabulky. Jeden pro zákazníky, druhý pro objednávky. Pojďme si to trochu procvičit vytvořením těchto dvou tabulek.

Jaké informace budeme ukládat? Pojďme vyřešit první otázku.

Navrhujeme zákaznický stůl.

Objednávky skutečně patří zákazníkům, ale objednávka nikoli minimální blok informací, který odkazuje na zákazníky (tj. tento blok lze rozdělit na menší: například datum objednávky, dodací adresa objednávky atd.).
Níže uvedená pole představují minimum informací, které se vztahují na zákazníky:

• customer_id (primární klíč) – ID zákazníka
• first_name - jméno
• last_name - patronymic
• adresa - adresa
• PSČ- PSČ
• země - země
• narození_datum - datum narození
• uživatelské jméno – registrační jméno uživatele (přihlášení)
• heslo - heslo

Pojďme k samotnému vytvoření této tabulky v SQLyog (můžete samozřejmě použít jakýkoli jiný program). Následuje příklad toho, jak může tabulka v SQLyog vypadat po vytvoření. Všechno grafické aplikace pro správu databází mají přibližně stejnou strukturu rozhraní. Můžete také vytvořit tabulku s příkazový řádek bez použití grafického nástroje.

Vytvoření tabulky v SQLyog. Všimněte si, že je zaškrtnuto políčko primárního klíče (PK) pro pole customer_id. Pole customer_id je primární klíč. Je také zaškrtnuto políčko Auto Incr, což znamená, že databáze automaticky nahradí jedinečnou číselnou hodnotu, která se od nuly pokaždé zvýší o jednu.

Navrhneme tabulku zakázek.
Jaké jsou minimální informace, které potřebujeme k objednávce?

• order_id (primární klíč) – identifikátor objednávky
• order_date - datum a čas objednávky
• zákazník - zákazník, který zadal objednávku

Níže je příklad tabulky v SQLyog.

Tyto dvě tabulky ( klientů A objednávky) souvisí, protože pole zákazník v tabulce objednávek odkazuje na primární klíč ( zákaznické identifikační číslo) zákaznické tabulky. Takovému spojení se říká vztah cizího klíče. Cizí klíč byste si měli představit jako jednoduchou kopii (kopii hodnoty) primárního klíče jiné tabulky. V našem případě hodnota pole zákaznické identifikační číslo od stolu klientů zkopírován do tabulky objednávky při vkládání každého záznamu. Každá objednávka je tedy vázána na klienta. A každý klient může mít spoustu zakázek, jak je uvedeno výše.

Vytvořte vztah cizího klíče.

Možná se ptáte: „Jak se mohu ujistit nebo jak zjistím, že na pole zákazníka v tabulce objednávek odkazuje pole customer_id v tabulce zákazníků.“ Odpověď je jednoduchá – nemůžete to udělat, protože jsem vám ještě neukázal, jak vytvořit připojení.
Níže je okno SQLyog s oknem, které jsem použil k vytvoření vztahu mezi tabulkami.

Vytvořte vztah cizího klíče mezi tabulkami objednávek a zákazníků.

V okně výše můžete vidět, jak je pole zákazníka tabulky objednávek vlevo propojeno s primárním klíčem (id_zákazníka) tabulky zákazníků vpravo.

Nyní, když se podíváte na data, která by mohla být v tabulkách, uvidíte, že tyto dvě tabulky spolu souvisí.

Objednávky jsou spojeny se zákazníky prostřednictvím pole zákazníka, které odkazuje na tabulku zákazníků.

Na obrázku vidíte, že klient mary zadal tři objednávky, zákazník pablo umístil jeden a klient John- nikdo.
Můžete se zeptat: „A Co To si všichni tito lidé objednali?" Tento dobrá otázka. Možná jste očekávali, že objednané položky uvidíte v tabulce objednávek. Ale toto špatný příklad design. Jak byste vložili více produktů do jedné položky? Zboží jsou samostatné entity, které by měly být uloženy v samostatné tabulce. A vztah mezi tabulkami objednávky A zboží bude vztah jeden k mnoha. Budu o tom mluvit dále.

6. VYTVOŘENÍ DIAGRAMU PROPOJENÍ ENTIT

Esence.

V kontextu návrh databáze podstata je něco, co zaslouží vlastní tabulku ve vašem databázovém modelu. Když navrhujete databázi, musíte je definovat entity na systému, pro který databázi vytváříte. Jde spíše o dialog s klientem nebo se sebou samým, abyste zjistili, s jakými daty bude váš systém pracovat.

Vezměme si jako příklad internetový obchod. Internetový obchod prodává zboží. Produkt se může stát samozřejmou entitou v systému internetového obchodu. Zboží objednalklientů. Tady jsme s vámi a viděli jsme další dvě zjevné entity: objednávky A klientů.

Zakázku platí klient… to je zajímavé. Vytvoříme v databázi našeho internetového obchodu samostatnou tabulku pro platby? Možná. Jsou ale platby minimálním údajem, který se vztahuje na objednávky? I to je možné.

Pokud si nejste jisti, pak si jen rozmyslete, jaké platební údaje chcete uchovávat. Možná budete chtít zachovat způsob platby nebo datum splatnosti. Ale to je stále minimum informací, které by mohly být relevantní objednat. Formulaci můžete změnit. Způsob platby - způsob platby objednávky. Datum platby – datum platby objednávky. Proto nevidím potřebu dělat Platby do samostatné tabulky, i když koncepčně byste mohli platby vyčlenit jako entitu, protože platby si můžete představit jako kontejner informací (způsob platby, datum platby).

Nebuďme příliš akademičtí.

Jak vidíte, v samotné databázi je rozdíl mezi entitou a tabulkou, tzn. není to totéž. Specialisté v oboru informační technologie může být v tomto tématu VELMI akademický a pedantský. Nejsem takový specialista. Tento rozdíl závisí na vašem úhlu pohledu na vaše data, vaše informace. Pokud se podíváte na datové modelování z hlediska software, pak můžete skončit se spoustou entit, které nelze přenést přímo do databáze. V tomto tutoriálu se na data díváme přísně z databázové perspektivy a v našem malém světě je entitou tabulka.

Vydržte, jste opravdu blízko k získání doktorátu v databázích.

Jak vidíte, určování entit, které má váš systém, je trochu intelektuální proces, který vyžaduje určité zkušenosti a často podléhá změnám, revizím, myšlenkám, ale samozřejmě to není žádná raketová věda.

Diagram vztahů mezi entitami může být poměrně velký, pokud pracujete na složité aplikaci. Některé grafy mohou obsahovat stovky nebo dokonce tisíce tabulek.

Spojení.

Tak. Říkal jsem ti o připojení jeden k mnoha a více o připojeních vám řeknu v pozdějších částech tohoto průvodce, takže se tím nyní nebudu dále zdržovat. Pamatujte, že důležitou součástí je rozhodování o tom, jaké vztahy budou mít vaše entity. návrh databáze a tato zapojení jsou zobrazena ve schématu entita-vztah.

Jsou definovány tři hlavní třídy entit:

1) Tyč je nezávislý subjekt. Jména jsou umístěna v obdélníku.

2) Asociativní Vztah mnoho k mnoha mezi dvěma nebo více entitami. S asociacemi se zachází jako s úplnou entitou. Mohou se účastnit jiných sdružení a mít sadu atributů.

A. Označení (označující entitu) jsou vztahy mnoho ku jedné nebo jedna ku jedné mezi dvěma entitami. Od charakteristiky se liší tím, že nezávisí na označující entitě.

3) Charakteristický(charakteristika) - vztah mnoho ku jedné nebo jedna ku jedné mezi dvěma entitami. Je to zvláštní případ spolku. Jediným účelem charakteristiky je popsat nebo objasnit nějakou jinou entitu. Existence charakteristiky zcela závisí na charakterizované entitě.

Klíč nebo potenciální klíč je pouze soubor atributů, podle jejichž hodnot lze jednoznačně najít požadovanou instanci entity.

Minimalita znamená, že lexikálně z množiny libovolného atributu neumožňuje identifikovat entitu těmi zbývajícími.

Jeden z klíčů je považován za primární klíč a zbytek se nazývá alternativní. Klíč sestávající z jednoho atributu se potenciálně nazývá jednoduchý. Primární klíč jádrové entity není dovoleno nabývat nedefinované hodnoty, jinak nastává rozporuplná situace - objeví se neidentitní, a tedy neexistující instance jádrové entity. Ze stejných důvodů je nutné zajistit jednoznačnost primárního klíče.

Pokud entita C spojuje entity A a B, pak musí obsahovat cizí klíče odpovídající primárním klíčům entit A a B.

Pro každý cizí klíč je třeba vyřešit tři otázky:

1) Může další cizí klíč nabývat nedefinovaných hodnot (hodnoty null), zkrátka může existovat nějaká instance entity, pro kterou je známá cílová entita určená cizím klíčem.

2) Co by se mělo stát, když se pokusíte odstranit cílovou entitu, na kterou odkazuje cizí klíč.

Existují tři možná řešení Tento problém:

Kaskádové

Omezení

Nastavení na konkrétní hodnotu

3) Co by se mělo stát při pokusu o aktualizaci primárního klíče cílové entity, na kterou odkazuje nějaký cizí klíč.

Pro každý cizí klíč v návrhu databáze je tedy nutné specializovat nejen pole nebo kombinaci polí tvořících tento cizí klíč, ale také odpovědi na výše uvedené otázky.

Datové typy a domény.

Relační datový model se vyznačuje jednoduchou datovou strukturou a uživatelsky přívětivou prezentací.

Relační model je navržen tak, aby organizoval data ve formě dvourozměrných tabulek. Relační tabulka je dvourozměrné pole a má následující vlastnosti:

1) Každý prvek tabulky je jeden datový prvek

2) Všechny sloupce v tabulce jsou homogenní – všechny prvky ve sloupci mají stejný datový typ a délku

3) Každý sloupec má jedinečný název

4) V tabulce nejsou žádné shodné řádky

5) Pořadí řady sloupců může být libovolné

Typy dat

Jakákoli data používaná při programování mají své vlastní datové typy. Relační model vyžaduje, aby použité datové typy byly jednoduché.

Obecně se datové typy dělí do tří skupin:

1) Jednoduché datové typy

2) Strukturované datové typy

3) referenční datové typy

Jednoduché (atomické) datové typy nemají vnitřní strukturu. Tento typ dat se nazývá skalární. Patří mezi ně logické, číselné a řetězcové datové typy. Pojem atomicita je spíše relativní. Datový typ řetězec lze tedy považovat za jednorozměrné pole znaků a celočíselný typ data jako sadu bitů. Důležité je zde pouze to, že při přechodu na takové nízká úroveň ztrácí se sémantika, tedy význam dat.

Strukturování datových typů je určeno k definování komplexních datových struktur, které jsou konstruovány ze základních prvků, které zase mohou mít vnitřní strukturu (pole, záznamy, struktury).

Referenční datový typ je určen k poskytování schopnosti ukazovat na jiná data. Tento datový typ je určen pro jazyky procedurálního typu, které mají paměťové oblasti pro ukládání dat.

Pro relační model datový typ použitých dat není tak důležitý. Požadavek, aby byl datový typ jednoduchý, je třeba chápat tak, že v relační operace vnitřní datová struktura nesmí být brána v úvahu.

Doména porno.ru

V relačním datovém modelu je koncept datového typu úzce spjat s konceptem domény, což lze považovat za zpřesnění datového typu.

doména - sémantický koncept. Lze si to představit jako podmnožinu hodnot nějakého datového typu.

Vlastnosti domény:

1) doména má v databázi jedinečný název

2) doména je definována na nějakém jednoduchém datovém typu nebo na jiné doméně

3) doména může mít nějakou logickou podmínku, která umožňuje popis podmnožiny dat platných pro danou doménu.

4) doména nese určitou sémantickou zátěž

Například nějakou doménu D, což znamená „věk zaměstnance“, lze popsat jako nějakou podmnožinu množiny přirozených čísel

D=(nϵN: n ≥ 18 an ≤ 60)

Rozdíl mezi doménou pojmu podmnožina spočívá právě v tom, že doména odráží sémantiku určitého předmětová oblast. Může existovat několik domén, které se shodují jako podmnožina, ale mají různé významy. Například domény „hmotnost části" a „dostupné množství" lze stejně popsat jako soubor nezáporných celých čísel, ale význam těchto domén bude odlišný a budou se jednat o různé domény. Hlavním významem domény je, že domény omezují srovnání. Není logicky správné porovnávat hodnoty různých domén, i když jsou stejného typu. Syntakticky správné je vrátit seznam všech dílů, jejichž hmotnost dílu je větší než dostupné množství neodpovídá významu pojmů množství a hmotnost.

5. Relace a jejich vlastnosti, atributy a n-tice.
Koncept vztahu je základním konceptem relačního datového modelu. Atribut vztahu:<Имя_атрибута: Имя_домена>. Názvy atributů musí být v rámci vztahu jedinečné. Názvy atributů jsou často stejné jako odpovídající názvy domén. Nějaká relace R definovaná na množině domén D 1 ,D 2 ,…D n obsahuje dvě části: hlavičku a tělo. Hlavička vztahu obsahuje pevný počet atributů vztahu.

(,,…)

(,,… ).

R( ,,…).

Stejný vztah nelze zobrazit různé tabulky, do kterého řádky jdou jiné pořadí

3) Atributy nejsou seřazeny zleva doprava. Protože každý atribut má v rámci vztahu jedinečný název, na pořadí atributů nezáleží. Stejný vztah může být reprezentován různými tabulkami, ve kterých jsou sloupce v jiném pořadí.

4) Všechny hodnoty atributů jsou atomické.

Z vlastností vztahu vyplývá, že ne každá tabulka umí definovat vztahy. K tomu potřebuje mít jednoduchou strukturu, neobsahovat shodné řádky, kterýkoli z jeho sloupců musí obsahovat data pouze jednoho typu a všechny použité datové typy musí být jednoduché.

Problém návrhu logiky relační databáze data mining spočívá v informovaném rozhodnutí o tom, z jakých vztahů by se databáze měla skládat a jaké atributy by tyto vztahy měly mít.

Relační datový model opravuje dva základní požadavky na integritu, které musí být podporovány v jakémkoli relačním DBMS.

1) Požadavek integrity entity, který spočívá v tom, že každá n-tice jakékoli relace musí být odlišitelná od jakékoli jiné n-tice této relace, to znamená, že každá relace musí obsahovat primární klíč.

2) Požadavek na referenční integritu (požadavek na integritu cizího klíče) je, že pro každou hodnotu cizího klíče v odkazovaném vztahu je . Musí existovat n-tice se stejnou hodnotou primárního klíče nebo hodnota cizího klíče musí být null.

Primární klíč je jedinečná charakteristika pro každý záznam v tabulce. Access podporuje dva typy primárních klíčů: jednoduchý a složený.

Obsazení jednoduchý klíč jedno z již existujících polí tabulky může fungovat, pokud v tomto poli nejsou žádné prázdné a duplicitní hodnoty. Příklady takových polí mohou být čísla strojů, inventární čísla, identifikační kódy. Složený klíč je vytvořen jako kombinace dvou nebo více datových prvků. Pro tabulku Zaměstnanci je například teoreticky možné jako primární klíč použít kombinaci dvou polí Příjmení a Jméno. Je ale dost možné, že se ve firmě objeví další zaměstnanec se stejným jménem a příjmením jako někdo, kdo již pracuje.

Je zřejmé, že na pole (pole), které se prohlašují za primární klíč, jsou kladeny poměrně přísné požadavky. Proto je běžnou praxí vytvořit speciální pole identifikačního pole, které plní funkce klíče (například Kód zákazníka, Kód objednávky). S přidáním každého nový záznam v tabulce je toto pole vyplněno speciální hodnotou (obvykle číselnou), která jednoznačně identifikuje záznam. V Přístupová aplikace Takové číslování můžete uspořádat díky datovému typu Counter, který každému novému záznamu přiřadí číslo a vygeneruje posloupnost čísel s krokem 1 (nebo náhodně).

Pro klíče v Accessu platí základní pravidla:

Pro usnadnění je klíčové pole obvykle uvedeno jako první ve struktuře tabulky;

Pokud má tabulka definovaný primární klíč, Access automaticky zablokuje zadávání duplicitních hodnot nebo hodnot Null (prázdných) do tohoto pole;

Access automaticky třídí záznamy tabulky podle primárního klíče;

Pole primárního klíče je index, který urychluje třídění a vyhledávání záznamů.

Chcete-li nastavit tabulku na primární klíč a dokončit její vytváření v zobrazení Návrh, postupujte takto:

V režimu návrhu vyberte pole, které bude hrát roli primárního klíče;

Klepněte na tlačítko Pole klíče na panelu nástrojů Tvůrce tabulek nebo vyberte příkaz hlavní nabídky Upravit - Pole klíče (vedle názvu vybraného pole se zobrazí symbol klíče);

Po zadání klíčového pole je třeba tabulku uložit, pro to je třeba kliknout na tlačítko Uložit na panelu nástrojů Návrhář tabulek a v okně, které se otevře, zadat název tabulky a kliknout na tlačítko OK.

Pokud primární klíč není definován, zobrazí se při opuštění režimu návrhu varování a Access vás před zavřením tabulky vyzve k vytvoření pole klíče.

17. Typy spojů a jejich realizace. Referenční integrita a její prosazování.

V relační databázi se vztahy vyhýbají redundanci dat. Když například vytvoříte databázi obsahující informace o knihách, můžete skončit s tabulkou nazvanou "Knihy", která ukládá podrobnosti o každé knize, jako je její název, datum vydání a vydavatel. Kromě toho existují další informace o vydavateli, které si možná budete chtít ponechat, jako je jeho telefonní číslo, adresa a PSČ. Pokud je uložíte do tabulky s knihami, pak se bude telefonní číslo nakladatele opakovat u každé jím vydané knihy.

Správnější možností je umístit informace o vydavatelích do samostatné tabulky "Vydavatelé". V tomto případě bude tabulka "Knihy" obsahovat odkazy na záznamy tabulky "Vydavatelé".

Aby byla zachována synchronizace, musí být zachována integrita dat mezi tabulkami Books a Publishers. Vztahy integrity dat zajišťují, že data v jedné tabulce odpovídají datům v jiné. Například každá kniha v tabulce Knihy je přidružena ke konkrétnímu vydavateli v tabulce Vydavatelé. Nemůžete přidat knihu do tabulky pro vydavatele, který není v databázi.

Typy vztahů mezi tabulkami

Komunikace se provádí srovnáváním dat v klíčových sloupcích; obvykle se jedná o sloupce, které mají v obou tabulkách stejný název. Ve většině případů je primární klíč jedné tabulky, který obsahuje jedinečný identifikátor pro každý řádek, mapován na cizí klíč jiné tabulky. Například každý z titulů k prodeji lze přiřadit k jeho objemu prodeje vytvořením sloupce PublishingID v tabulce Knihy (primární klíč) a sloupce PublishingID v tabulce Prodej (cizí klíč).

Mezi tabulkami existují tři typy vztahů. Typ vytvořeného vztahu závisí na tom, jak jsou definovány související sloupce.

One-to-Many vztahy

Vztah jeden k mnoha je nejběžnějším typem vztahu. S takovým vztahem může každý řádek tabulky A odpovídat mnoha řádkům tabulky B, ale každý řádek tabulky B může odpovídat pouze jednomu řádku tabulky A. Mezi tabulkami je například vytvořen vztah jeden k mnoha "Vydavatelé" a "Knihy": každý z nakladatelů může vydat mnoho knih, ale každou knihu vydává pouze jeden vydavatel.

Vztah jeden k mnoha se vytvoří, když pouze jeden z přidružených sloupců má jedinečné omezení nebo je primárním klíčem.

V aplikaci Access je strana vztahu jedna k mnoha, které odpovídá primární klíč, označena symbolem klíče. Strana vztahu, které cizí klíč odpovídá, je označena symbolem nekonečna.

Mnoho k mnoha vztahům

Při vytváření vztahu mnoho k mnoha může každý řádek tabulky A odpovídat mnoha řádkům tabulky B a naopak. Takový vztah je vytvořen pomocí třetí tabulky, nazývané spojení, jejíž primární klíč se skládá z cizích klíčů spojených s tabulkami A a B. Například mezi tabulkami „Autoři“ a „Knihy“ je vytvořen vztah many-to-many. pomocí vztahů vztah jedna k mnoha mezi každou z těchto tabulek a tabulkou BookAuthors. Primární klíč tabulky BookAuthors je kombinací sloupců AuthorID (primární klíč tabulky Autoři) a BookID (primární klíč tabulky Titles).

Vztahy jeden k jednomu

Při vytváření vztahu jedna ku jedné může každý řádek tabulky A odpovídat pouze jednomu řádku tabulky B a naopak. Vztah jedna ku jedné se vytvoří, když jsou oba související sloupce primárními klíči nebo mají jedinečná omezení.

Tento druh vztahu se používá zřídka, protože v takové situaci mohou být související data obvykle uložena ve stejné tabulce. Vztah jedna ku jedné můžete použít v následujících případech.

Chcete-li rozdělit tabulku obsahující příliš mnoho sloupců.

Z bezpečnostních důvodů izolovat část stolu.

Pro ukládání údajů o krátkodobém použití je nejjednodušším způsobem, jak je odstranit, vymazat tabulku.

Pro ukládání dat relevantních pouze pro podmnožinu hlavní tabulky.

V aplikaci Access je strana vztahu 1:1, které odpovídá primární klíč, označena symbolem klíče. Strana vztahu, které cizí klíč odpovídá, je také označena symbolem klíče.

Vytváření vztahů mezi tabulkami

Při vytváření vztahu mezi tabulkami nemusí mít související pole stejný název. Musí však mít stejný datový typ, pokud pole, které je primárním klíčem, není typu "Počítadlo". Pole typu "Počítadlo" může být přidruženo k poli typu "Numeric" pouze v případě, že vlastnost FieldSize (velikost pole) každého z nich je nastavena na stejnou hodnotu. Můžete například přidružit sloupce typu Count a Numeric, pokud je vlastnost FieldSize každého nastavena na Long Integer. I když jsou oba přidružené sloupce typu Numeric, hodnota vlastnosti FieldSize pro obě pole musí být stejná.

Primární klíč je pole v tabulce, které jednoznačně identifikuje každý řádek/záznam v databázové tabulce. Primární klíče musí obsahovat jedinečné hodnoty. Primární klíč sloupce nemůže mít hodnotu.

Tabulka může mít pouze jeden primární klíč, který se může skládat z jednoho nebo více polí. Pokud je jako primární klíč použito více polí, nazývají se složený klíč.

Pokud má tabulka primární klíč definovaný pro libovolné pole, nemůžete mít dva záznamy, které mají stejnou hodnotu těchto polí.

Poznámka– Tyto koncepty můžete použít při vytváření databázových tabulek.

Vytvoření primárního klíče

Zde je syntaxe pro definování atributu ID jako primárního klíče v tabulce Zákazníci.

VYTVOŘIT TABULKU ZÁKAZNÍCI(ID INT NENÍ NULL, JMÉNO VARCHAR (20) NENÍ NULL, VĚK INT NENÍ NULL, ZNAK ADRESY (25) , PLAT DESETINNÉ (18, 2), PRIMÁRNÍ KLÍČ (ID));

Chcete-li vytvořit omezení primárního klíče ve sloupci "ID", když tabulka CUSTOMERS již existuje, použijte následující syntaxi SQL:

ZÁKAZNÍCI ALTER TABLE PŘIDAT PRIMÁRNÍ KLÍČ (ID);

Poznámka

Pokud k přidání primárního klíče použijete příkaz ALTER TABLE, sloupce primárního klíče již musí být deklarovány jako nenulové (pokud byla tabulka vytvořena jako první).

Chcete-li definovat primární klíč ve více sloupcích, použijte syntaxi SQL níže:

VYTVOŘIT TABULKU ZÁKAZNÍCI(ID INT NENÍ NULL, JMÉNO VARCHAR (20) NENÍ NULL, VĚK INT NENÍ NULL, ZNAK ADRESY (25) , PLAT DESETINNÉ (18, 2), PRIMÁRNÍ KLÍČ (ID, JMÉNO));

Chcete-li vytvořit omezení primárního klíče ve sloupcích "ID" a "NAME", když tabulka CUSTOMERS již existuje, použijte následující syntaxi SQL.

ALTER TABLE ZÁKAZNÍCI PŘIDAT OMEZENÍ PK_CUSTID PRIMÁRNÍ KLÍČ(ID, JMÉNO);

Odebrání primárního klíče

Omezení primárního klíče můžete z tabulky vymazat pomocí syntaxe uvedené níže.

ZÁKAZNÍCI ALTER TABLE DROP PRIMÁRNÍ KLÍČ;

• PRIMÁRNÍ KLÍČ - primární klíč tabulky.
• UNIQUE - jedinečný klíč tabulky.
• CIZÍ KLÍČ- cizí klíč, poskytuje odkaz na jinou tabulku a zaručuje referenční integritu mezi nadřazeným a dětské stoly.

Poznámka k terminologii

Pokud jste jako autor tohoto kurzu v tom, že rádi hledáte odpovědi na otázku, která vás zajímá komplexně, v různých dílech různých autorů, pak jste si nemohli nevšimnout určitého zmatku v definicích hlavní (master) -> podřízený (detail) tabulky. Připomeňme, že hlavní tabulka je často označována jako nadřazená tabulka a podřízená tabulka jako podřízená tabulka.

To je pravděpodobně způsobeno tím, jak jsou tyto definice interpretovány v lokálních a SQL serverech DBMS.

V lokálním DBMS je hlavní tabulka ta, která obsahuje hlavní data, a podřízená tabulka je ta doplňková. Vezměte si například tři související tabulky. První obsahuje údaje o prodeji, druhý obsahuje údaje o produktu a třetí obsahuje údaje o zákaznících:

Rýže. 18.1.

Zde jsou hlavní informace uloženy v prodejní tabulce, proto jsou hlavní (nadřazené). dodatečné informace jsou uloženy v tabulkách zboží a kupujících, jsou tedy děti. Je to pochopitelné: jedna dcera nemůže mít dvě biologické matky, ale jedna matka je docela schopná porodit dvě dcery.

Ale databázové servery SQL mají jinou definici vztahů: když jedno pole v tabulce odkazuje na pole v jiné tabulce, je to tzv. cizí klíč. A pole, na které odkazuje, se nazývá rodič popř primární klíč. Tabulka, která má cizí klíč (odkaz na záznam v jiné tabulce), se často nazývá podřízená tabulka a tabulka s rodičovský klíč- rodič. I v definici vztahů se říká, že rodič může mít pouze jeden unikátní záznam, na který může odkazovat více záznamů. dětský stůl.

Takže ve výše uvedeném příkladu má prodejní tabulka dva cizí klíče: ID produktu a ID zákazníka. A obě tabulky na pravé straně obrázku mají rodičovský klíč"Identifikátor". Vzhledem k tomu, že jeden zákazník nebo produkt se může v prodejní tabulce objevit více než jednou, ukazuje se, že obě tabulky na pravé straně obrázku jsou rodiče a tabulka vlevo je dítě. Protože teď studujeme InterBase-SQL databázový server, těmito definicemi se budeme řídit v následujících přednáškách. Abychom si nad tímto zmatkem nelámali hlavu, okamžitě se dohodneme: dětský stůl má cizí klíč ( FOREIGN KEY ) do jiné tabulky.

PRIMÁRNÍ KLÍČ

PRIMÁRNÍ KLÍČ- primární klíč, je jedním z hlavních typů omezení v databázi. Primární klíč je určen k jednoznačné identifikaci záznamu v tabulce a musí být jedinečný. Primární klíče PRIMARY KEY jsou v tabulkách, které se nazývají parent (Parent). Nezaměňujte primární klíč s primárními indexy lokálních databází, primární klíč není index, ale omezení. Při vytváření primárního klíče InterBase automaticky vytvoří pro něj jedinečný index . Pokud však tvoříme jedinečný index, toto se nevytvoří omezení primárního klíče. Tabulka může mít pouze jeden PRIMÁRNÍ KLÍČ.

Předpokládejme, že máme tabulku se seznamem zaměstnanců. Pole Příjmení může obsahovat stejné hodnoty(jmenovec), takže jej nelze použít jako primární klíč. Málokdy, ale najdou se jmenovci, kteří se navíc jmenují stejně. Ještě vzácnější, ale existují plnohodnotní jmenovci, takže ani všechna tři pole "Příjmení" + "Jméno" + "Patronym" nemohou zaručit jedinečnost záznamu a nemohou být primárním klíčem. V tomto případě je východiskem, stejně jako dříve, přidání pole - identifikátoru, které obsahuje sériové číslo tato osoba. Taková pole se obvykle dělají auto-inkrementací (o organizaci auto-inkrementačních polí si povíme v dalších přednáškách). Tak,

primární klíč - jedná se o jedno nebo více polí v tabulce, jejichž kombinace je pro každý záznam jedinečná.

Pokud má primární klíč jeden sloupec (jak je tomu nejčastěji), použije se specifikátor PRIMARY KEY, když definice sloupce:

CREATE TABLE Prim_1(Stolbec1 INT NOT NULL PRIMÁRNÍ KLÍČ, Stolbec2 VARCHAR(50))

Pokud je primární klíč postaven na několika sloupcích, pak je specifikátor umístěn po definování všech polí:

CREATE TABLE Prim_2(Stolbec1 INT NENÍ NULL, Stolbec2 VARCHAR(50) NOT NULL, PRIMÁRNÍ KLÍČ (Stolbec1, Stolbec2))

Jak můžete vidět z příkladů, primární klíč musí mít nutně omezení sloupců NOT NULL.

UNIKÁTNÍ

UNIKÁTNÍ- jedinečný klíč. Specifikátor UNIQUE označuje, že všechny hodnoty tohoto pole musí být jedinečné, a proto ani taková pole nemohou obsahovat hodnoty. NULA. Můžeme říci, že unikátní UNIKÁTNÍ klíč je alternativní primární klíč, ale existují rozdíly. Hlavním rozdílem je, že musí existovat pouze jeden primární klíč, zatímco jedinečných klíčů může být několik. Omezení UNIQUE také nelze vytvořit na stejné sadě sloupců, která byla použita pro omezení PRIMARY KEY nebo jiné omezení UNIQUE. Jedinečné klíče, stejně jako primární klíče, se nacházejí v tabulkách, které jsou rodiči jiných tabulek.

Sloupec deklarovaný s omezením UNIQUE, jako je primární klíč, lze použít k vynucení referenční integrity mezi nadřazeným a dětské stoly. Zatímco cizí klíč dětský stůl bude odkazovat na tato pole. Stejně jako v případě primárního klíče, když je vytvořen jedinečný klíč, automaticky se pro něj vytvoří klíč. jedinečný index. Ale ne naopak. Příklad vytvoření tabulky s jedním primárním a dvěma jedinečnými klíči:

CREATE TABLE Prim_3(Stolbec1 INT NOT NULL PRIMAR KEY, Stolbec2 VARCHAR(50) NOT NULL UNIQUE, Stolbec3 FLOAT NOT NULL UNIQUE)

CIZÍ KLÍČ

CIZÍ KLÍČ- externí klíč. Jedná se o velmi výkonný nástroj pro zajištění referenční integrity mezi tabulkami, který umožňuje nejen sledovat přítomnost správné odkazy ale také je automaticky spravovat. Cizí klíče jsou obsaženy v tabulkách, které jsou potomky ( Child ) jiných tabulek. Referenční integrita je zajištěna právě cizím klíčem, který odkazuje na primární resp