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 >