Krokodýlovy databáze | DM / Power Designer – Jak a proč udělat alternativní klíče

Někdy existuje více alternativních zůsobů identifikace, které chceme v databázi podpořit. To znamená, že chceme, aby na úrovni SQL databáze zajišťovala unikátnost daného atributu či dané kombinace atributů v tabulce pro entitu.

Například v rámci informačního systému může mít každý uživatel jedinečné ID, generované třeba i automaticky, a zároveň potřebujeme zajistit, že každý uživatel bude mít svůj unikátní login. Nebo zaměstnancům přidělujeme zaměstnanecké číslo, ale zároveň se potřebujeme pro účely správy plateb pojistného spolehnout na unikátnost zaznamenaných rodných čísel u jednotlivých zaměstnanců.

Proč to děláme? – Někdy jde o tento důvod: Pro účely efektivní kontroly referenční integity a zároveň kvůli efektivitě vykonávání JOINů podél vazeb cizí klíč - primární klíč volíme obvykle velmi efektivní primární identifikátory. Ale protože sémantické identifikátory (jako například výše míněný login uživatele) se za provozu databáze budou jistě využívat k vyhledávání záznamů, musíme zvážit, které z nich to budou, a u kterých se vyplatí či je potřeba kontrolovat unikátnost. – Při rozhodování, zda pro entitní typ či tabulku definovat určitý atribut či kombinaci atributů jako alternativní identifikátor, zvažme i toto:

Kontola unikátnosti znamená režijní náklady při provozu databáze, v použitých paměťových kapacitách i v procesorovém času
Informaci, že daný atribut či kombinace atributů je unikátní, může využít optimalizátor vykonávání SQL dotazů (programátor při psaní dotazu může brát v úvahu business pravidla, a nikoli záměry databázového administrátora)
Samozřejmě, existuje-li business potřeba pravidlo unikátnosti zajistit, není nad čím váhat.

Příklad V následujícím příkladu máme nadtyp OSOBA a jeho podtyp PRAV. OS. (právnická osoba). Podtyp zdědí primární identifikátor nadtypu, tj. DIČ, a chceme, aby v rámci tohoto podtypu PRAV. OS. platila ještě unikátnost aributu IČO. Obrázek ukazuje situaci, kdy byl již označen atribut DIČ jako primární pro entitu OSOBA (a tím i po všechny její podtypy), ale IČO je zatím jen obyčejný atribut právnických osob:

Poklepeme na objekt entity PRAV.OS., a v dialogu vlastností vybereme kartu Identifiers. Na této kartě je seznam všech identifikátorů dané entity, eventuálně je mezi nimi i identifikátor odpovídající atributu či kombinaci atributů, které jsme označili jako primary (a tedy mají v zobazení entity značku <pi>). Pro entitu PRAV.OS. však žádný primary nebyl označen (to je správně, primary identifikaci zdědí od nadtypu). Přidání dalšího, alternativního, identifikátoru uděláme po zmáčknutí tlačítka podle obrázku:

Můžeme vepsat Name a Code pro nový identifikátor (může ale nemusí být stejné jako jméno nějakého atributu):

Poklepeme (doubleckick) na volič příslušného řádku,

(potvrdíme event. varující dialog o použití změn) a dostaneme dialog o vlastnostech tohoto identifikátoru. Na kartě Attributes stiskneme tlačítko na přidání atributů, z nichž bude nový identifikátor složen:

Dostaneme dialog na výběr z atributů entity, zaškrtneme ten či ty atributy, které mají tvořit nový alternativní identifikátor:

Potvrdíme, a vracíme se do předchozího dialogu o vlastnostech identifikátoru. Atributy, které jsme vybrali, jsou zde zobrazeny.

Potvrďte i tento dialog, a v modelu vidíme vyznačení nového alterantivního identifikátoru:

Příklad Jiný příklad, kde primární i alterativní identifikátory jsou v jednom a tomže entitním typu:

Příklad Pokud potřebujeme do alternativní identifikace zahrnout i některu z identifkačních závislostí či prostý cizí klíč,

nelze to dělat v konceptuálním modelu (CDM), ale až ve fyzickém (PDM). Postup je analogický výše popsanému postupu v CDM, s tím rozdílem, že jde o Keys a Columns. Ve fyzickém:

< Dědičnost | Power Designer postupně | Fyzický model a SQL >