Náhradní klíč

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 13. června 2016; kontroly vyžadují 9 úprav .

Náhradní klíč  je konceptem teorie relačních databází .

Toto je další pole služby přidané k existujícím informačním polím tabulky, jehož jediným účelem je sloužit jako primární klíč . Hodnota tohoto pole není tvořena na základě žádných jiných dat z databáze , ale je generována uměle.

Příklad

Předpokládejme, že máme dvě tabulky - "Lidé" a "Účtenky". Osoba je identifikována čtyřmi poli - příjmení, jméno, patronymie, datum narození. V tabulce „Příjmy“ je uvedeno, komu přesně je určena.

osoba jméno1 | jméno2 | jméno3 | datum narození | adresa -------------------------------------------------- ------- Ivanov | Ivan | Ivanovič | 1. ledna 1971 | Svatý. Wikipedie, 1 účtovat jméno_osoby1 | jméno_osoby2 | jméno_osoby3 | osoba_datum_narozeni | datum | částka | je placený -------------------------------------------------- ---------------------------------------------- Ivanov | Ivan | Ivanovič | 1. ledna 1971 | 1. února 2011 | 2000,00 | Ano Ivanov | Ivan | Ivanovič | 1. ledna 1971 | 1. března 2011 | 1000,00 | Ne

Přidáním pole technického čísla (často nazývaného „id“) do obou tabulek takový základ získáme.

osoba id | jméno1 | jméno2 | jméno3 | datum narození | adresa -------------------------------------------------- ---------------- 12345 | Ivanov | Ivan | Ivanovič | 1. ledna 1971 | Svatý. Wikipedie, 1 účtovat id | person_id | datum | částka | je placený -------------------------------------------------- 56789 | 12345 | 1. února 2011 | 2000,00 | Ano 67890 | 12345 | 1. března 2011 | 1000,00 | Ne

Nyní se na účtenkách nevztahuje „Ivanov Ivan Ivanovič, narozený 1. ledna 1971“, ale „osoba č. 12345“.

Implementace

Zástupný klíč je obvykle jednoduše číselné pole vyplněné hodnotami ze vzestupné číselné sekvence. To lze provést pomocí spouštěčů nebo sekvencí . V řadě DBMS (například PostgreSQL , Sybase , MySQL [1] nebo SQL Server [2] ) existuje pro taková pole speciální datový typ - číselné pole, ve kterém při přidání záznamu do tabulky, automaticky se zapíše číselná hodnota, která je pro tuto tabulku jedinečná - tedy n. "autoincrement" ( anglicky  autoincrement ) nebo seriál v terminologii PostgreSQL.

V případě, že by databáze mohla být potenciálně použita při replikaci, číselné pole nemůže poskytnout jedinečnost a UUID v té či oné podobě se používají jako náhradní primární klíče k zajištění jedinečnosti.

Důvody pro použití

Neměnnost. Hlavní výhodou náhradního klíče je, že se téměř nikdy nemění, protože nenese žádné informace z předmětné oblasti, a je tedy minimálně závislý na změnách, které se v něm odehrávají. Změna náhradního klíče obvykle vyžaduje mimořádné okolnosti (viz důvod „flexibility“ níže).

Atributy přirozeného klíče se mohou čas od času změnit – například osoba si může změnit své jméno nebo příjmení, získat nový pas , který nahradí ztracený. V tomto případě vyvstává potřeba tzv. „kaskádových změn“ – při změně hodnoty přirozeného klíče, aby byla zachována referenční integrita , musí systém provést příslušné změny všech hodnot cizích klíčů, které odkazují na klíč se mění. Ve velkých databázích to může být značná režie.

Zaručená jedinečnost. Zdaleka ne vždy je možné zaručit, že jedinečnost přirozeného klíče nebude časem narušena. Různé vnější faktory mohou vést k tomu, že dříve jedinečný přírodní klíč může za nových okolností ztratit svou jedinečnost. Náhradní klíč tento nedostatek neobsahuje.

Flexibilita. Protože náhradní klíč není informativní, lze jej volně vyměnit. Předpokládejme, že se spojí dvě firmy s podobnou databázovou strukturou; zaměstnanec je identifikován síťovým přihlášením . Aby klíč zůstal ve výsledné databázi jedinečný, musíte do něj přidat další pole – „z jaké společnosti jste přišli“. V případě náhradních klíčů stačí vydat nové klíče zaměstnancům jedné z firem.

Účinnost. Jak je ukázáno v příkladu výše, odkazy se pohodlněji ukládají jako celá čísla než jako objemné přirozené klíče. Kromě toho žádost

SELECT * FROM person INNER JOIN bill ON person . id = účet . person_id ;

menší a rychlejší než

SELECT * FROM person AS p INNER JOIN bill AS b ON p . jméno1 = b . jméno_osoby1 A p . jméno2 = b . jméno_osoby2 A p . jméno3 = b . jméno_osoby3 A p . datum_narozeni = b . datum_narozeni osoby ;

Zjednodušení programování. Některé programátorské úlohy lze například tímto způsobem oddělit od struktury databáze.

function getId ( $aTableName , $aFieldName , $aFieldValue ) { $sqFieldValue = mysql_real_escape_string ( $aFieldValue ); $qry = <<< QQQ SELECT id FROM `$aTableName` WHERE `$aFieldName`='$sqFieldValue'; QQQ ; if ( ! ( $result = mysql_query ( $qry ))) zemřít ( mysql_error ()); if ( ! ( $ar = mysql_fetch_array ( $result ))) return null ; return $ar [ 0 ]; }

Tento kód v PHP , dynamicky psaném jazyce, již předpokládá, že existuje pouze jedno klíčové pole. V tradičních jazycích jako C++ nebo Java by klíčem nemělo být pouze jedno pole, ale pole nějakého známého typu. Proto ORM spoléhají na to, že odkazy na objekty jsou čísla nebo GUID .

Nevýhody

Zranitelnost generátoru klíčů. [3] Například pomocí čísel klíčů můžete zjistit, kolik záznamů se v databázi objevilo za určité období.

Nedostatek informací. Ruční kontrola databáze se stává složitější, objevují se INNER JOINtam, kde se bez nich obejdete. Z tohoto důvodu výčtová pole často používají klíče s krátkým řetězcem.

země sportovce id | jméno1 | jméno2 | ID země | název ---+----------+-------+----------- ----+------- A1 | Ivanov | Ivan | RUS RUS | Rusko A2 | Petrenko | Petr | UKR UKR | Ukrajina A3 | Smith | John | USA USA | USA

Někdy data ze své podstaty podléhají přenosu z databáze do databáze (například mezi lokální a centralizovanou databází, experimentální a pracovní verzí). Při přijímání nových dat pro ně musí DBMS vygenerovat vlastní náhradní klíče.

Způsobí, že správce přeskočí normalizaci . Přidání náhradních klíčů je snazší než správné, vezmeme-li v úvahu duplikaci a poměry „1:∞“, rozdělíme databázi do tabulek a položíme jedinečné indexy .

Problémy s optimalizací. DBMS musí udržovat dva indexy , náhradní a přirozený. Jak již bylo zmíněno výše, mohou se objevit INNER JOINtam, kde nejsou potřeba.

Nedobrovolná vazba vývojáře na chování generátoru klíčů v konkrétní DBMS. Vývojář může například předpokládat, že se dříve objevila zpráva s menším klíčem.

Poznámky

  1. ↑ Referenční příručka MySQL – Použití atributu AUTO_INCREMENT
  2. ↑ SQL Server 2008 Books Online – IDENTITY (vlastnictví)
  3. ↑ Ta zatracená přírůstková ID / Sudo Null IT News
 Databáze
Koncepty
Objekty
Klíče
SQL
Komponenty