17.2: Semantisk overload
frihedsgraderne i oprettelse af nye relationer med CREATE TABLE. Men en række problemer med SELECT kan dog undg˚ as selvom, der indføres nye attributter i relationer. Konstruktionen SELECT * bør undg˚ as til fordel for SELECT att1, att2,..., attn idet et givet program, s˚ a kun skal ændres, hvis det har anvendelse af nye attributter, og s˚ a skulle det vist under alle omstændigheder ændres. Om andre end RDBMSer har lettere ved at indføre skemaændringer er vist tvivlsomt. rede Databaser Fordele og ulemper ved objektorienterede databaser C&B hævder, i øvrigt som mange andre, at OODM modellerer virkeligheden bedre. Det betyder angiveligt, at man fx kan danne komplekse objekter af simple objekter. Man m˚ a spørge sig selv om, for hvem dette er en fordel? Svaret kan kun være for programmøren, der derved slipper for at aggregere objekter ved læsning. Den relationelle model, der har datauafhængighed som en fundamental ting, og som bygger p˚ a integritet uden redundans og nulls opbygger sin logiske struktur p˚ a dette fundament. kvaliteten sikres gennem normalisering. Datauafhængigheden har alts˚ a derved en strukturel p˚ avirkning p˚ a databasens design. Strukturen er beregnet p˚ a at data ser s˚ adan ud i hvile, dvs mens de ikke bruges. Heroverfor hævdes det nu at virkeligheden skal afbildes bedre af OODM. Det betyder at data ˚ abenbart bør opbevares i den form hvori de bruges, n˚ ar de er ”i luften”, dvs n˚ ar de er under behandling. Jeg vil mene, at p˚ astanden bunder i det, som C&B lidt senere kalder en ulempe, nemlig at OODM mangler en model. Jeg mener at det s˚ aledes kan hævdes, med lige s˚ a stor ret, at n˚ ar den moderne objektorienterede programmør gerne vil se verden objektorienteret, s˚ a er det af programmeringsmæssige ˚ arsager. Det kan der være overbevisende programmeringstekniske argumenter for. Nedarvning og dermed genbrug af kode er væsentlige faktorer. Dataadministratoren, der skal dække alle systemers behov, ser det som et form˚ al at gøre dette med alle de nødvendige data, og kun med de nødvendige data. Dvs uden redundans og p˚ a en m˚ ade s˚ a programmøren kan opbygge sit objekt ved læsning, lade det være et objekt under behandling, og lægge det pænt p˚ a plads efter brug. 2. 26.14 Jeg har prøvet at lave to diagrammer, et UML-diagram over databasen og et traditionelt ERdiagram. Begge diagrammer er ukomplette med hensyn til attributter, og er s˚ aledes kun antydninger af løsninger. C&B fremhæver ikke en bestemt diagramtype som OO-diagrammet. I praksis bruges ofte UML. Jeg synes, at der gode grunde til at vælge diagram/modelleringsværktøj med omhu. Jf en interessant artikel Death by UML Fever. Man kan argumentere for at væsentlige nuancer g˚ ar tabt, især omkring relationer mellem entiteterne. Nogle relationer afbildes i UML som associationer (streger), mens andre afbildes som klasser (rektangler), sidstnævnte gælder N:M-relationer, der derfor visuelt adskiller sig fra øvrige relationer. Det lader til at man blander den semantiske/konceptuelle model ER, sammen med den logiske model, implementeringsmodellen, som kan være relationel eller her OO. Den semantiske model skal være nøjagtigt lige s˚ a simpel som den virkelighed, der skal modelleres. Husk, at den ogs˚ a skal danne grundlag for en dialog med brugeren, om hvorvidt denne f˚ ar sit system, s˚ adan som han ønsker det. Men lad os se diagrammerne: mmmm
©nml
153