Krokodýlovy databáze | DM / Atributy entit a vztahů

< Entity a vztahy mezi nimi | Tutoriál informační analýzy | Entity >

Vlastnosti a charakteristiky objektů nebo vztahů mezi objekty v datových modelech nazýváme atributy. Například příjmení a jméno zákazníka, jeho adresa, nebo ohodnocení provedené naší firmou, jsou v našem pohledu na svět atributy zákazníka. Informace o tom, kolik pokusů o absolvování předmětu má již za sebou student, který si ten předmět zapsal, je atributem onoho vztahu "student si zapsal předmět" – ten atribut může mít hodnotu "poprvé", "podruhé", ....

Atribut vztahu je něco, co není atributem žádné z entit jako takové, ale je to charakteristika souvislosti mezi některými entitami – uvažujme například zakázkovou výrobu: Používájí se různé druhy materiálu a vyrábí se různé výrobky. Množství spotřebovaného materiálu na určitý výrobek je různé pro různé druhy materiálu. Pro odlišné výrobky, na které se použil stejný materiál, je spořebované množství jiné. Takže spotřeba materiálu na nějaký výrobek není vlastností toho výrobku samotného ani není vlastností materiálu samotného, ale je to charakteristika použití konkrétního materiálu na konkrétní výrobek. "Množství" je atribut vztahu "druh materiálu byl použit na výrobek".
Pokud by se nejednalo o zákázkovou výrobu, ale o typovou, pak co bylo dříve řečeno o jednotlivých výrobkách, řekneme o typech výrobků.

Na pomezí konceptuální správnosti je, když jako atribut entity modelujeme charakteristiku nějaké jiné entity – k tomu nás často vede praktická potřeba omezit model, a onu jinou entitu do modelu již nezahrnout (například bychom jako atribut zboží modelovali jméno firmy výrobce toho zboží, ale výrobce jako entitu bychom v modelu již neměli). Později pak může vzniknout potřeba onu dříve nezahrnutou entitu do modelu přidat (budeme si chtít o firmách výrobců také vést záznamy), a ten atribut (jméno firmy výrobce u zboží) bude muset být nahrazen odpovídajícím vztahem (vztahem zboží k výrobci toho zboží, jméno firmy se pak stane atributem entity výrobce). Taková změna vede ke komplikacím (náročným a nákladným), a je dobré uvážit, jestli se jich nevyvarujeme hned zpočátku.
Tady se uplatní zkušenost nebo znalý odhad, protože hranice oblasti, pro kterou se databáze navrhuje, vždy nějaká bude. Takže jde o to, co se může do oblasti zájmu dostat, a co nejspíš zůstane vně. Jiný příklad: v některých logovacích systémech se nabízejí alternativí metody autentizace, například na základě rodného jména matky. Je nanejvýš nepravděpodobné, že by i identita matky nebo další údaje o matce byly někdy v budoucnu v podobém systému vedeny v nějakých záznamech.

Členění podle procesního charakteru

Atributy entit můžeme dělit na identifikační, tj. sloužící k identifikaci, a popisné atributy. Toto členění je účelové, je o tom, jak budou uživatelé informace vyhledávat, což se využije při optimalizaci realizace databáze. Členění z tohoto hlediska může být ještě jemnější, můžeme rozlišovat identifikátory, ostatní vyhledávací atributy a popisné atributy. Identifikátory se od ostatních vyhledávacích atributů odlišují tím, že podle identifikárorů se očekává nalezení jediného objektu, zatímco v případě obecných vyhledávacích atributů předpokládáme, že může být nalezeno více objektů. U popisných atributů se nepředpokládá jejich využívání pro vyhledávání objektů, spíše budou poskytovány až po nalezení objektu nějak jinak.
Toto rozdělení je však relativní, závisí na pravidlech platných v dané věcné oblasti a na očekávání uživatelů. To vše se může časem měnit. Očekávání je ovlivněno technologickými možnostmi, například zatímco úředník je schopen ověřovat identitu osoby podle fotografie, počítačová technologie je v tomto ohledu méně schopná. Pokrok však může tyto poměry změnit. Jako příklad možné změny pravidla uvažme, že rodná čísla zaměstnanců můžeme považovat za jejich identifikátory do té doby, než zjistíme, že dvěma osobám mohla být přidělana stejná rodná čísla.
Zjišťování způsobů identifikace má nicméně při analýze jeden důležitý význam, a to že to je pomůcka při potížích s rozpoznáním toho, co modelujeme. Když se ptáme, jak se zkoumané věci identifikují, pomáhá nám to uvědomit si, co těmi věcmi vlastně myslíme. Například, jestli v analýze pro knihovnu dojdeme k tomu, že uvažované objekty se identifikují pomocí ISBN, máme na mysli knižní tituly, ale pokud pro dané ISBN je možno nalézt více uvažovaných objektů a k identifikaci slouží čárový kód, pak se asi jedná o výtisky knih.

Další členění, podobně účelové jako to předchozí, je na povinné atributy a nepovinné. Týká se toho, zda danou vlastnost má každý objekt daného entitního typu eventuálně zda je o každém známa. Očividným účelem tohoto členění je odlišit, zda danou hodnotu v databázi u každého objektu nalezneme či nikoli. Tato otázka má důležitý analytický význam – připomeňme, že vytváříme "infomodel" – model informací dostupných pro danou oblast.
Z tohoto ohledu může být vhodné odlišit případy kdy něco nevíme, od případů kdy to není. Například, ačkoli každý člověk má hmotnost, ne o každém víme, jakou. Na druhou stranu ne každé zboží má hmotnost, u software nebo jiných služeb tomu tak není. Nebo jiný příklad, u někoho nemáme zapsáno telefonní číslo proto, že žádné nemá, u jiného prostě proto, že toto číslo neznáme. Toto odlišení má svůj význam, protože to, co neznáme ale existuje to, to se můžeme později dozvědět, ale co neexistuje, to nemůžeme. U "neexistujích hodnot" můžeme s jistotou říci, že nemají žádnou z konkrétních hodnot, u neznámých toto říci nemůžeme (nějakou hodotu mají, jen nevíme, kterou). Složitější je to s ostatním porovnáváním, například otázka zda hmotnost je větší než ... nebo menší než .... u objektů, které nemají hmotnost, záleží na interpretaci, a například může být účelové považovat jejich hmotnost za 0 kg. Ne u všech kvantitativních údajů je však podobná náhrada vhodná, například věk první menstruace není u mužských pacientů vhodné falsifikovat nějakým náhradním číslem. Nebo pro výši zaměstnaneckého účtu ve firemní prodejně u zaměstanců, kteří si účet nezaložili, by jakýkoli číslený údaj mohl podávat zavádějící informace.
V úředních formulářích bývá zvykem proškrtnout políčko v případech, když příslušný údaj neexistuje, a nechat ho nevyplněné, když nevíme.

Další účelové členění je na stálé a měnící se atributy. Stálé je například datum narození, měnící se je počet dětí zaměstance. Informace, které se nemění, můžeme zaznamenat jinými prostředky, než ty co se mění; očekávání uživatelů je jiné, a z toho plynou jiné nároky na zajištění jejich potřeb.
Měnícím se atributům je třeba při analýze věnovat větší pozornost – otázkou je, zda má být dostupná informace o předchozích stavech, či stačí znát jen aktuální stav. Pokud je to ten první případ, může být navíc požadována dostupnost informace o časové platnosti předchozích stavů, tedy jak probíhala historie.
Zvláštní kapitolou jsou fluktuující veličiny, kdy jejich stav se mění neustále. Například krevní tlak pacienta či cena komodity na burze. Tehdy přichází do úvahy otázka, zda mají být některé stavy této veličiny zapomenuty, a zaznamenávat se mají jen některé.

Při všech výše uvedených členěních je otázkou, zda má informační systém vymáhat příslušné pravidlo: Zda má u identifikátorů kontrolovat jejich unikátnost a nepřipustit vložení hodnoty, která se v jiném záznamu nějakého objektu daného typu v databázi již vyskytuje. Zda má vymáhat zadání povinného údaje. Zda má zakázat změnu údaje, který má být stálý...

Vícenásobnost

Někdy se k dané entitě nebo vztahu může vázat více charakteristik stejné povahy. Například film můžeme ohodnotit jako animovaný, fantasy, humorný. Zájmy, které o sobě uvede nějaká osoba, mohou být fotografování, cestování a architektura. K partnerské firmě můžeme mít zapsáno více telefonních čísel. V případě filmů lze každou z uvedených charakteristik nazvat "žánr", ve případě osob "záliba", v případě firem "telefonní číslo". Když pak k entitě "film" modelujeme atribut "žánr", k jednotlivému filmu bude možno zapsat více údajů do tohoto atributu. Podobně, když k entitě "osoba" modelujeme atribut "záliba", u jednotlivé osoby může být uvedeno více zálib. K entitě "firma" modelujeme atribut "telefon", a v něm může být uvedeno více telefoních čísel.
Takovéto atributy jsou vícehodnotové.
Někteří teoretici odmítají vícehodnotové atributy. Snaha vyhnout se jim v konceptuálních modelech však vede k vytváření nepřirozených entitních typů, které nemají odpovídající obsah v modelované realitě – neodrážejí objekty, ale pouze údaje (viz první odstavec v kapitole o entitách).

Pragmatika informace

Informace, které modelujeme jako atributy, mají mít povahu údajů nebo dokumentů. Údaje mohou být kvantitativní, časové, prostorové, identifikační, popisné, hodnotící či zařazovací; dokumenty obsahují komplexní sdělení o entitě nebo vztahu. Tuto pragmatiku informace je třeba si uvědomit již při analýze, tj. k čemu takový údaj nebo dokument může sloužit. S kvantitativními údaji lze dělat výpočty, časové údaje lze chronologicky řadit a lze vyhodnocovat časový interval mezi nimi. Zařazovací údaj souvisí s tím, jaké kategorie jsou zvoleny pro možnosti zařazení.
Například, telefonní číslo je popisný nebo identifikační údaj, u kterého potřebujeme rozeznat jednolivé cifry jak jdou po sobě. Jedná se tedy o kód, nikoli o kvantitativní údaj = číslo. Běžné pojmenování (telefonní "číslo") neodpovídá kategorii "číslo" v informatice: čísla udávají množství nebo počet, eventuelně pořadí.

Skladba informace

Některé údaje tvoří skupiny, které chápeme jako celek, a tento celek nějak nazýváme. Například skupinu údajů "ulice", "číslo domu", "PSČ", "město" nazýváme "adresa" – "adresa" má vnitřní strukturu, má složky "ulice", "číslo domu", "PSČ", "město"; je z těchto údajů složena. Uživatelský požadavek na "adresu" je jednoznačný a srozumitelný, navíc konstrukce "adresa" se ve vyjadřování často vyskytuje. V modelu, který usiluje o věrnost realitě, modelujeme složený (strukturovaný) atribut "adresa" - kromě jiného, dosáhneme tak větší přehlednosti modelu. Takovéto zanořování skladby můžeme aplikovat v dalších úrovních, pokud je to potřeba: složený atribut "adresa" může být součástí složeniny "kontaktní údaje", zahrnující "telefon", "icq", "email"...

Odvozené atributy

Podobně jako odvoditelné vztahy, i odvoditelné atributy mají v konceptuálním modelu místo jen tehdy, pokud je k tomu nějaký speciální důvod. Takovým důvodem může být to, že k uvažovanému atributu se váže nějaké pravidlo, které se má v aplikační oblasti dodržovat. Pak je potřeba v konceptuálním modelu ten atribut označit jako odvozený, a zaznamenat, jakým způsobem se odvozuje.
Například v kontextu městské knihovny je důležitý věk čtenáře, podmínky půjčování se řídí věkem čtenáře. Můžeme tedy "věk" modelovat jako atribut entity "čtenář". Ale protože u každého čtenáře bude zaznamenáno jeho datum narození, dá se jeho věk z data narození vypočítat. Takže atribut "věk" označíme jako odvozený, a poznamenáme, že věk se určuje podle narozenin a roku narození.
U odvoditelných atributů je nutno zvážit, zda se budou odvozovat na požádání (jako třeba "věk"), nebo zda se budou v databázi ukládat (jako třeba "pohlaví" u pojištěnce zdravotní pojišťovny, to se dá také odvodit z rodného čísla).

< Entity a vztahy mezi nimi | Tutoriál informační analýzy | Entity >