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 >