Page 1

“ 49 ” Spørgsm˚ alet om Datamodeller, Databaser og alting, Svar p˚ a Niels M¨ uller Larsen 14. april 2009


2

©nml


Forord “Forty-two” yelled Loonquawl “is that all you’ve got to show for seven and a half millions years’ work”? “I checked it very thoroughly,” said the computer, “and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you’ve never actually known what the question is.” “But it was the Great Question! The Ultimate Question of Life, the Universe and Everything,” howled Loonquawl. “Yes.” said Deep Thought with the air of one who suffers fools gladly, “but what actually is it?” A slow stupefied silence crept over the men as they stared at the computer and then at each other. Well, you know it’s just Everything . . . everything . . . offered Phouchg weakly. “Exactly!” said Deep Thought. “So once you do know what the question actually is, you’ll know what the answer means.” “Oh, terrific,” muttered Phouchg, flinging aside his notebook and wiping away a tiny tear. “Look, all right, all right,” said Loonquawl, “can you just please tell us the question?” “The Ultimate Question?” “Yes!” “Of Life, the Universe and Everthing?” “Yes!” Deep Thought pondered for a moment. “Tricky,” he said. “But can you do it?” cried Loonquawl. Deep Thought pondered for another long moment. Finally: “No,” he said firmly. Both men collapsed onto their chairs in despair. “But I’ll tell you who can,” said Deep Thought. They both looked up sharply. “Who? Tell us!” ... “I speak of none but the computer that is to come after me,” intoned Deep Thought, his voice regaining its accustomed declamatory tones. “A computer whose merest operational parameters I am not worthy to calculate-and yet I will design it for you. A computer that can calculate the Question to the Ultimate Answer, a computer of such infinite and subtle complexity that organic life itself shall form part of its operational matrix. And you yourselves shall take on new forms and go down into the computer to navigate its ten-million-year program! Yes! I shall design this computer for you. And I shall name it also onto you. And it shall be called . . . the Earth.” Phouchg gaped at Deep Thought. “What a dull name,” he said ...[citat fra Adams (1979) kapitel 28.]

Nu hvor vi er s˚ a meget klogere, kunne vi overveje om the Earth ikke snarere skulle være Deep Thought V2. Det m˚ a dog ligge fast, at the Earth ten-million-year program selvfølgelig er Open Source Software. Jeg har haft lejlighed til at skrivebordsteste1 dele af denne software. Nok til at kunne konstatere, at svaret p˚ a the Ultimate Question umuligt kan være 42. Det kan ikke blive andet end 49, hvilket jo unægteligt er noget ganske andet. 1

Et historisk fænomen fra dengang computere ikke stod p˚ a hvert skrivebord, men var noget man fik “tid p˚ a” af og til. Siger mest om testerens alder.

3


Om det betyder noget, er det i sagens natur svært at sige noget om før spørgsm˚ alet foreligger. Denne uventede udvikling2 kan medføre, at the Earth program mere realistisk bliver the fifteen-million-year program. Bemærk, at “you yourselves shall take on new forms and go down into the computer” for at deltage i arbejdet p˚ a at finde spørgsm˚ alet. Livet er for deltagere, ikke for tilskuere.

Kære Læser Det tør være en selvfølge, at n˚ ar man skriver andet end notater, skriver man for at blive læst. Det gælder ikke mindst, n˚ ar man sætter sig for at skrive en lærebog. Denne bog er skrevet til og for den naive læser. Inden nogen bliver fornærmet over dette prædikat, skal jeg først sige, at det i min ordbog er det man p˚ a nydansk kalder et plusord. Min naive læser møder frem med ˚ abenhed og uden faglige fordomme for at lære noget teori, som hun siden kan bruge i praksis p˚ a en bevidst m˚ ade. Er vi ikke kommet videre end den relationelle model? Passer det ikke d˚ arligt med objektorientering? Hvorfor modellerer han ikke med hint værktøj, som jo er bedre? Hvorfor gøre s˚ a meget ud af normalisering, ødelægger det ikke performance? Hvad gør lidt redundans, gentagelse fremmer forst˚ aelsen, og det fremmer dog performance? Hvorfor er nulls forbudt, n˚ ar der vitterligt er ting vi ikke ved, s˚ a m˚ a vi vel acceptere det? Svarene p˚ a alle disse spørgsm˚ al er en række rungende nej ’er. Mit m˚ al er at læseren gennem forst˚ aelse af teori forst˚ ar hvorfor. Min naive læser er fordomsløs, og ˚ aben for teori og læring. Min læser lytter selv og frigør sig fra myter, fordomme og historier fra dem, der kun kender teorien perifert og/eller p˚ a anden h˚ and. Min naive læser “take on new forms and go down into the computer” for selv at finde svaret. Indtil da, blæser det i vinden. Niels M¨ uller Larsen

2

En stor tak til Douglas Adams og Prof. Wendy Hall.

4

©nml


Indhold 1 Introduktion 1.1 Introduktion . . . . . . . . . . . . . . . . 1.1.1 Databasebegrebet . . . . . . . . . 1.1.2 Den officielle databaseterminologi . 1.1.3 Databasen som model . . . . . . . 1.2 Identifikation af data . . . . . . . . . . . . 1.3 Et konkret eksempel . . . . . . . . . . . . 1.4 Data og Metadata . . . . . . . . . . . . . 1.4.1 Data . . . . . . . . . . . . . . . . . 1.4.2 For f˚ a data, for mange data . . . . 1.5 Standarder . . . . . . . . . . . . . . . . . 1.6 Læsevejledning . . . . . . . . . . . . . . . 1.6.1 Alternativt ... . . . . . . . . . . . . 1.6.2 Hertil kommer . . . . . . . . . . . 1.7 Øvelser til kapitel 1 . . . . . . . . . . . . . 1.7.1 Øvelser vedrørende tabel 1.1 . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

11 11 11 12 12 14 14 14 14 16 17 18 18 18 19 19

2 Datamodeller 2.1 Abstraktioner - en verden og dens billede . 2.1.1 Data eller processer - to synsvinkler 2.1.2 Fortolkning af data . . . . . . . . . . 2.1.3 Tid . . . . . . . . . . . . . . . . . . 2.1.4 Definition . . . . . . . . . . . . . . . 2.2 Databasesystemer . . . . . . . . . . . . . . 2.3 Brugergrænseflader . . . . . . . . . . . . . . 2.4 Øvelser til kapitel 2 . . . . . . . . . . . . . . 2.4.1 Øvelser datamodeller . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

21 21 21 22 23 23 24 24 24 24

3 Semantisk datamodellering 3.1 Modelværktøjer . . . . . . . . . . . . . . . . . 3.2 ER-modellen . . . . . . . . . . . . . . . . . . 3.2.1 Entiteter og relationer . . . . . . . . . 3.2.2 Entitet og entitetsklasse . . . . . . . . 3.2.3 Relationer og relationsklasser . . . . . 3.2.4 Attributter . . . . . . . . . . . . . . . 3.2.5 Nøgler . . . . . . . . . . . . . . . . . . 3.2.6 Entiteter og Relationer set indefra . . 3.2.7 Kardinalitet . . . . . . . . . . . . . . . 3.2.8 Deltagelsestype . . . . . . . . . . . . . 3.2.9 Svage entiteter . . . . . . . . . . . . . 3.2.10 ER-model i diagramform, et eksempel

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

27 27 28 28 29 30 31 33 33 34 34 37 38

5


INDHOLD

3.3

3.4

3.2.11 Relationer - genbesøgt . . . . . . . . . EER-modellen . . . . . . . . . . . . . . . . . 3.3.1 Superklasser, subklasser og nedarvning 3.3.2 Generalisering . . . . . . . . . . . . . 3.3.3 Specialisering . . . . . . . . . . . . . . 3.3.4 Generalisering og specialisering . . . . 3.3.5 Relationer af højere grad . . . . . . . Øvelser til kapitel 3 . . . . . . . . . . . . . . . 3.4.1 Øvelser i ER-modellen . . . . . . . . . 3.4.2 Øvelser i EER-modellen . . . . . . . .

4 Den Relationelle Model 4.1 Verden i følge Date . . . . . . . 4.2 Definition af struktur . . . . . . 4.2.1 Tupel . . . . . . . . . . 4.2.2 Relation . . . . . . . . . 4.3 Definition af regler . . . . . . . 4.3.1 Nøglebegreber . . . . . 4.3.2 Entitetsintegritet . . . . 4.3.3 Referentiel integritet . . 4.4 Operationer . . . . . . . . . . . 4.4.1 Algebra . . . . . . . . . 4.4.2 Beroligelse . . . . . . . 4.4.3 Calculus . . . . . . . . . 4.5 Øvelser til kapitel 4 . . . . . . . 4.5.1 Skab en biblioteksmodel

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

38 44 45 46 46 48 50 52 52 53

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

55 55 56 56 56 57 57 58 58 58 59 61 61 62 62

. . . . . . . . . . . . . . . . . . . .

63 63 64 64 65 65 66 66 67 67 67 68 69 69 69 71 71 71 74 74 74

5 Normalisering 5.1 Funktionel Afhængighed . . . . . . . . . . . . . . . 5.1.1 Funktionel afhængighed eller fuld funktionel 5.2 Kvalitetskrav til databasen . . . . . . . . . . . . . 5.3 Første Normalform . . . . . . . . . . . . . . . . . . 5.3.1 En definition . . . . . . . . . . . . . . . . . 5.3.2 Et problematisk eksempel . . . . . . . . . . 5.3.3 Repeterende gruppe . . . . . . . . . . . . . 5.3.4 Problemets løsning - Paco’s princip . . . . 5.4 Anden Normalform . . . . . . . . . . . . . . . . . . 5.4.1 En definition . . . . . . . . . . . . . . . . . 5.4.2 Det problematiske eksempel . . . . . . . . . 5.5 Tredje Normalform . . . . . . . . . . . . . . . . . . 5.5.1 En definition . . . . . . . . . . . . . . . . . 5.5.2 Det problematiske eksempel . . . . . . . . . 5.6 Boyce-Codd Normalformen . . . . . . . . . . . . . 5.6.1 En definition . . . . . . . . . . . . . . . . . 5.6.2 Et illustrativt eksempel . . . . . . . . . . . 5.7 Øvelser til kapitel 5 . . . . . . . . . . . . . . . . . . 5.7.1 bla bla . . . . . . . . . . . . . . . . . . . . . 5.7.2 Øvelse n . . . . . . . . . . . . . . . . . . . . 6

. . . . . . . . afhængighed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

©nml


INDHOLD 6 Fra ER til RM 6.1 Transformation af ER-model 6.1.1 Første skridt . . . . . 6.1.2 Andet skridt . . . . . 6.1.3 Tredje skridt . . . . . 6.1.4 Fjerde skridt . . . . . 6.1.5 Femte skridt . . . . . 6.1.6 Sjette skridt . . . . . . 6.1.7 Syvende skridt . . . . 6.1.8 Ottende skridt . . . . 6.1.9 Niende skridt . . . . . 6.2 Øvelser til kapitel 6 . . . . . . 6.2.1 Øvelse . . . . . . . . . 6.2.2 Øvelse . . . . . . . . . 6.2.3 Øvelse . . . . . . . . . 6.2.4 Øvelse . . . . . . . . . 6.2.5 Øvelse . . . . . . . . . 6.2.6 Øvelse . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

75 75 75 76 76 79 80 81 81 82 83 84 84 84 84 85 85 85

7 Databasesystemer - DBMSer 7.1 Client/server . . . . . . . . . . 7.2 Databasesystemet . . . . . . . 7.3 “And the nominees are ...” . . . 7.4 “Vinderen er” . . . . . . . . . . 7.5 Øvelser til kapitel 7 . . . . . . . 7.5.1 Installation af RDBMS

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

87 87 88 88 90 90 90

8 Structured Query Language 8.1 SQLs Systematik . . . . . . 8.1.1 SQL-92 struktur . . 8.1.2 SQL-2003 struktur . 8.2 Øvelser til kapitel 8 . . . . . 8.2.1 bla bla . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

91 93 94 94 95 95

9 SQL Tutorial - SQL Skema 9.1 Eksempeldatabasen . . . . . . . . 9.2 SQL Schema - indledning . . . . 9.2.1 Skab en database . . . . . 9.2.2 Datatyper . . . . . . . . . 9.2.3 Nøgler . . . . . . . . . . . 9.3 Relationer . . . . . . . . . . . . . 9.3.1 CREATE TABLE . . . . 9.3.2 Yderligere regler . . . . . 9.3.3 ALTER TABLE . . . . . 9.3.4 DROP TABLE . . . . . . 9.4 Domæner . . . . . . . . . . . . . 9.4.1 CREATE DOMAIN . . . 9.5 En praktisk digression . . . . . . 9.5.1 CREATE GENERATOR 9.6 SQL Schema - sikkerhed . . . . . 9.6.1 GRANT . . . . . . . . . . 9.6.2 REVOKE . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

97 97 98 98 98 100 100 100 101 103 105 105 105 106 106 107 107 107

©nml

. . . . .

. . . . .

7


INDHOLD 9.7

Øvelser til kapitel 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.7.1 Øvelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

10 SQL Tutorial - SQL Data 10.1 SELECT . . . . . . . . . . . . . . . . . 10.1.1 SELECT-eksempler . . . . . . . 10.1.2 JOIN - SELECT fra mere end en 10.1.3 Indlejret SELECT . . . . . . . . 10.2 INSERT . . . . . . . . . . . . . . . . . . 10.2.1 INSERT - alternativ syntaks . . 10.2.2 INSERT med brug af generator . 10.3 UPDATE . . . . . . . . . . . . . . . . . 10.4 DELETE . . . . . . . . . . . . . . . . . 10.5 Øvelser til kapitel 10 . . . . . . . . . . . 10.5.1 Øvelse . . . . . . . . . . . . . . .

. . . . . . . . tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

109 109 109 115 118 121 121 122 122 123 124 124

11 SQL Tutorial VIEWS, Virtuelle relationer 125 11.1 Øvelser til kapitel 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 11.1.1 Øvelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 11.1.2 Øvelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 12 SQL Tutorial - Sikkerhed 12.1 Transaktioner i Databasesystemet 12.1.1 Samtidighed og Flerbrugeri 12.1.2 Commit og rollback . . . . 12.2 Sikkerhed gennem SQL . . . . . . 12.2.1 Grant og revoke . . . . . . 12.3 Sikkerhedskopiering . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

13 Den Relationelle Model og SQL - Et kritisk tilbageblik

127 127 127 127 127 127 128 131

14 Videreg˚ aende Programmering i Databasesystemet 137 14.1 Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 14.2 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 15 Case til illustration af en udviklingsmetode 15.1 Datamodellering . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.2 ER-modellering . . . . . . . . . . . . . . . . . . . . . . 15.1.3 Logisk transaktionsafprøvning . . . . . . . . . . . . . . 15.1.4 Analyse af fleksibilitet og fremtidige informationskrav 15.1.5 Transformation fra ER til RM . . . . . . . . . . . . . 15.1.6 Normalisering . . . . . . . . . . . . . . . . . . . . . . . 15.2 Udvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.1 Relationer implementeres . . . . . . . . . . . . . . . . 15.2.2 Testdata . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.3 Transaktionsafprøvning, igen . . . . . . . . . . . . . . 15.2.4 Strukturmodel . . . . . . . . . . . . . . . . . . . . . . 15.2.5 Programmering af funktioner . . . . . . . . . . . . . . 15.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.1 Testdata . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.2 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . 8

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

139 139 139 140 142 143 143 145 146 146 146 146 146 146 146 146 147 147

©nml


INDHOLD 15.4 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 15.4.1 Forberedelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 15.4.2 Ibrugtagning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 16 Distribuerede Databaser

149

17 Objektorienterede Databasesystemer 151 17.1 Fysisk repræsentation af data . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 17.2 Semantisk overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 18 Databasen p˚ a World Wide Web 155 18.1 Datamodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 18.2 Web-grænsefladen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 18.3 PHP-programmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 19 Datavarehuse 19.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2 Datamodellering . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2.1 Den relationelle model . . . . . . . . . . . . . . . . . . . . 19.2.2 Den dimensionale model - relational OLAP . . . . . . . . 19.2.3 Den Multidimensionale Model - Multidimensional OLAP 19.3 Et datavarehuseksempel . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

157 157 158 158 159 162 162

20 XML og Databaser

163

21 Afrunding

165

A Dummy appendiks

167

B UML

169

C Eksempeldatabasen til kapitel 9 og 10

171

D Binary Large Objects from outer space 175 D.1 Binary Large Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 E MySQL-variant af BLOB-h˚ andtering

177

F M˚ alinger og myter om RDBMSer

179

Litteratur

183

©nml

9


INDHOLD

10

©nml


Kapitel 1

Introduktion 1.1

Introduktion

Begrebet database er en s˚ a integreret del af moderne it, at vi ikke længere stiller spørgsm˚ altegn ved det. Det er s˚ a etableret, at vi betragter det som en naturlig del af vore omgivelser. Et af denne bogs hovedform˚ al er at afdække, hvad vi finder bag begrebet. Hvad dets indhold er. En ganske bred og rummelig definition kunne være at en database er en samling af data, som har med hinanden at gøre. De er relaterede til hinanden. Om data siger Langefors (1977): ar information om Data svarer til diskrete 1 , registrerede fakta om fænomener, hvormed vi f˚ virkeligheden.

1.1.1

Databasebegrebet

En database kan udgøre, eller være en del af et informationssystem. De enkelte opbevarede fakta har ofte ikke nogen konkret individuel værdi, men anvendt i forskellige konstellationer med andre fakta fremkommer en merværdi, som vi kan kalde for viden. Med den ovenfor givne definition kan en database indeholde data om musik, musikgenrer, musikere mv. Vi kunne kalde dette for en musikdatabase. Det kunne være bibliotekets katalog, der samler data om bøger (materialer), titler, forfattere, genrer, emner etc. Vi ser , at der er mange tænkelige databaser. Fælles for dem er det, at de er brugernes. Intet af det nævnte antyder en bestemt teknologisk opbevaringsform. En database kunne s˚ aledes være en privatpersons notater om sin musiksamling, opbevaret i et noteshæfte. Et andet eksempel kunne være kort, som børn samler p˚ a og bytter med. Det tredje eksempel er velkendt for de fleste, over en vis alder m˚ aske, som nogle skabe med skuffer, hvor skufferne er fyldt med kartotekskort p˚ a et bibliotek. I resten af denne bog vil vi dog tage det udgangspunkt, at databasen er anbragt p˚ a en computer og elektronisk, digitalt behandlet, og ikke som i de nævnte eksempler mere eller mindre manuelt og analogt ajourført. Den elektroniske database kan være h˚ andteret af en række programmer fremstillet med den konkrete databases form˚ al for øje, eller den kan være varetaget af et stykke programmel, et databasesystem, DBMS2 , der er generelt, og derfor kan anvendes som værktøj i sammenhæng med mange forskellige databaser. Det er s˚ aledes vigtigt, at man i sin sprogbrug skelner mellem en database, som en konkret forekomst i overensstemmelse med den givne definition, og et databasesystem, som den software (de programmer) der udfører opgaven, jf. højre søjle i figur 1.2, der netop handler om implementering. 1 2

Enkeltst˚ aende, i modsætning til kontinuerte. DataBase Management System

11


Kapitel 1: Introduktion

1.1.2

Den officielle databaseterminologi

Hele begrebsapparatet omkring databaser cementeredes i 1970’erne med baggrund i en række forskeres værker og en begyndende standardisering indenfor omr˚ adet. Man kan sige, at det først p˚ a dette tidspunkt blev en teoretisk videnskabelig disciplin. The ANSI/X3/SPARC 3 Study Group on Data Base Management Systems ofte lidt sparsommeligt kaldet ANSI/SPARC Study Group udførte et arbejde, der beskrev emneomr˚ adet og herunder udformede den s˚ akaldte ANSI/SPARC-arkitektur. Et kerneomr˚ ade i denne arkitektur var 3-skema-modellen, der ses i figur 1.1.

Eksternt lag

Applikation

Applikation

Applikation

Eksternt skema

Eksternt skema

Eksternt skema

Konceptuelt lag

Internt lag

Konceptuelt skema

Internt skema

Figur 1.1: ANSI/SPARC-arkitekturens 3-skema-model. Det interne lag kunne eller burde m˚ aske retteligt kaldes det fysiske lag, idet det beskæftiger sig med den konkrete computers operativsystems filsystems m˚ ade at behandle data p˚ a. ANSI/SPARC har valgt betegnelsen konceptuel, begrebsmæssig, om det midterste niveau, og dette er ikke i overensstemmelse med normal dansk sprogbrug, der bruger disse betegnelser om det højeste abstraktionsniveau, der i denne forfatters terminologi vil blive kaldt det semantiske niveau. N˚ ar Rønnow and Jacobsen (1989) kalder deres bog “Design af begrebsmæssige datamodeller”, mener de s˚ aledes “design af semantiske datamodeller” i nærværende forfatters sprogbrug. Semantisk datamodellering er en af grundsøjlerne i denne fremstilling. Har man valgt at kalde det interne lag for fysisk lag, kunne man mere passende bruge betegnelsen det logiske lag om det konceptuelle lag. Øverst i ANSI/SPARC-modellen har vi det eksterne lag, der viser, at applikationer kan opfatte en database i sin helhed, eller dele af den i overensstemmelse med applikationens eget form˚ al. Har mange applikationer adgang til en database vil der alts˚ a ofte være tale om mange forskellige udsnit, views, p˚ a databasen.

1.1.3

Databasen som model

En anden synsvinkel er, at en database er en abstraktion af virkeligheden, den er ikke virkeligheden. I ordet abstraktion, der jo betyder forenkling, ligger s˚ aledes at databasen ikke er 3

ANSI er American National Standards Institute, svarende til DS, Dansk Standard i Danmark. X3 er kodebetegnelsen for ANSIs Committee on Computers and Information Processing. SPARC er et akronym for X3s Standards Planning and Requirements Committee. I vore dage har X3 skiftet navn til NCITS, National Committee on Information Technology Standards.

12

©nml


1.1: Introduktion

virkeligheden men blot en model heraf, og at databasen ikke er en komplet model af virkeligheden, men blot en model af den del af virkeligheden, der er relevant for et givet form˚ al. Elmasri and Navathe (2003) kalder det en miniverden. Her vil vi bruge begrebet model om databasen p˚ a samme m˚ ade som en arkitekt laver en model af et (kommende) bygningsværk.

Figur 1.2: Diagram til indkredsning af bogens emner. I forlængelse af denne synsvinkel er det vigtigt at fremhæve, at databasen ikke er en model for modellens skyld. Den er blevet til med et form˚ al for øje. Oftest et relativt konkret form˚ al, det være sig som en del af et informationssystem, der leverer viden til nogle brugere, eller for eksempel som en del af et system der bruges til operationelt at styre en virksomhed. Denne bog vil gennemg˚ a og diskutere to forskellige m˚ ader, hvorp˚ a vi kan modellere data. Den første er Entity-Relationship-modellen, der bruges til beskrivelse af data p˚ a en relativt brugernær m˚ ade. ER-modellen kaldes her en semantisk model af data, jf. ogs˚ a her figur 1.2. Den anden model er den relationelle model af data. Den relationelle model er en logisk model, i figur 1.2 visualiseret p˚ a et lavere abstraktionsniveau. En logisk datamodel beskrevet matematisk-logisk og med veldefinerede komponenter og egenskaber er en nødvendig forudsætning for p˚ a en ensartet m˚ ade at kunne skrive den software, som et DBMS udgør. Den logiske datamodel kaldes ogs˚ a af og til for en implementeringsmodel, s˚ aledes ogs˚ a hos Elmasri and Navathe (2003). N˚ ar den relationelle model bruges kaldes implementeringen for RDBMS4 . Vi skal se, at den relationelle model udgør s˚ adant et grundlag. Vi skal ogs˚ a se, at p˚ a trods af en sund datamodel er det lykkedes forfatterne af standarder og softwarefabrikanterne, at opn˚ a mindre end ideelle DBMS-implementeringer. Figur 1.2 har som sit centrale element kolonnen med ANSI/SPARCs betegnelser for interesseniveauerne. I øvrigt er figurens tragtform øverst en antydning af, at ER-modellen kan bruges til at beskrive databaser af mange typer. Nogle af disse, og det er dem denne bog beskæftiger sig med, bliver implementeret ved hjælp af den relationelle model p˚ a det logiske niveau. 4

Relational DBMS.

©nml

13


Kapitel 1: Introduktion

1.2

Identifikation af data

Lad os se et par eksempler p˚ a situationsbeskrivelser, der kan give anledning til analyse med henblik p˚ a udvikling af informationssystemer. “En afdelingsleder i en virksomhed ønsker at sikre sig et overblik og en registrering over sine medarbejderes kompetencer. Da hans ansvarsomr˚ ade er inddelt i en række delomr˚ ader med hver sin foresatte, som ogs˚ a har ansvar for den interne information for omr˚ adet, er det naturligt tildele denne foresatte ansvar for registreringen af kompetencer og kursusaktivitet indenfor sit delomr˚ ade.” I eksemplet er fremhævet de ord, der kunne have interesse i et analysearbejde. Lad os se et andet kort eksempel. “En uddannelsesinstitution ønsker et system, der muliggør nogle administrative lettelser. Institutionens studerende er organiserede i klasser hørende til bestemte uddannelser. En given klasse følger p˚ a et klassetrin en suite af fag, der læses af institutionens lærere. I et tilfældigt semester læses fagene af konkrete lærere, ikke nødvendigvis samme lærere som i øvrige semestre. De studerende skal kunne orientere sig om hvilke fag de skal følge fordelt p˚ a klassetrin gennem uddannelsen, og de skal kunne se hvilke kurser, dvs. kombinationer af fag og lærer, der udbydes i et givet semester. Man skal kunne se klasselister ligesom man skal kunne orientere sig om bestemte læreres mulige fag.” Det turde fremg˚ a af begge disse eksempler, at det p˚ a ingen m˚ ade er entydigt, hvad alle begreberne indeholder. Det er begreber, hvis betydning m˚ a diskuteres og præciseres med de involverede parter i de to organisationer, ligesom der kan være kombinationer af begreber, der ikke umiddelbart er synlige, men først bliver det gennem den nævnte dialog. I et s˚ adant arbejde vil det ogs˚ a fremg˚ a, at i videreudvikling af eksisterende systemer er frihedsgraderne med hensyn til fortolkning og formning af begrebernes betydning ikke s˚ a store som de kunne være, hvis der var tale om udvikling af nye systemer, hvortil der endnu ikke er vedtaget regler. Med andre ord kan modellørens indflydelse p˚ a det modellerede variere.

1.3

Et konkret eksempel

Vi skal se et konkret eksempel p˚ a en database, der er en model af (en del af) en undervisningsinstitutions informationssystem. Tabel 1.1 best˚ ar af et antal tabeller, der beskriver studerende, deres uddannelses fag og disses konkrete implementering i kurser i et givet semester. Endelig er der data om opn˚ aede resultater samt hvilke fag, der udgør forudsætninger for deltagelsen i andre fags kurser.

1.4

Data og Metadata

N˚ ar vi modellerer en database til et informationssystem m˚ a vi nødvendigvis fortælle om disse data til det DBMS, som vi har valgt. Det kan ikke siges at være en naturlov, men m˚ aske en praktisk ekstra detalje, hvis DBMSet ikke skal ud i en række ekstra foranstaltninger for at opbevare disse oplysninger. I den implementeringsmodel, som denne fremstilling primært skal beskæftige sig med, fordi den er den overvældende meste anvendte, er det en definitorisk forudsætning at DBMSet opbevarer disse data om vore data, metadata, p˚ a samme m˚ ade som den opbevarer vore egne brugerdata.

1.4.1

Data

I eksempeldatabasen fra tabel 1.1 i afsnit 1.3 ser vi en række tabeller. Vi ser, at hver tabel har et navn. Hver tabel har en header, der viser nogle kolonneoverskrifter. Dette er minimumsindholdet for tabellerne. Herefter har hver tabel et varierende antal rækker, vi vil senere 14

©nml


1.4: Data og Metadata

Studerende StudentNummer

Navn

Klasse

Uddannelse

17

Alexandersen

00A

MDU

8

Benjaminsen

99X

DMU

23

Christoffersen

00A

MDU

Afdeling

Fag FagNummer

Navn

Lektioner

3500

Basisfag

4

3520

Interaktion

4

MDU

3521

Databaser

8

MDU

3670

GSU

6

DMU

3631

Semiotik

3530

Kommunikation

MDU 4

MDU

Karakterliste StudentNummer

KursusId

Karakter

17

120

9

17

101

8

8

114

11

8

101

9

8

145

11

Kursus Forudsaetning

KursusId

FagNummer

Semester

Aar

Laerer

67

3670

efter˚ ar

2000

Oksbjerre

For fag

Forudsaetning

73

3520

efter˚ ar

2000

Larsen

3521

3520

101

3521

for˚ ar

2001

Arnfast

3521

3670

114

3670

efter˚ ar

1999

Madsen

3520

3500

120

3520

efter˚ ar

2000

Larsen

3520

3500

145

3530

efter˚ ar

2000

Iversen

Tabel 1.1: En eksempeldatabase fra en undervisningsinstitution.

©nml

15


Kapitel 1: Introduktion

kalde dem tupler5 , med dataindhold svarende til de kolonner, der er nævnt i headeren. N˚ ar vi siger, at et minimumsindhold er en header, har vi s˚ aledes ogs˚ a sagt, at antallet af rækker med data kan variere fra 0 til mange. De dataværdier, der findes i hver kolonne, tilhører en datatype. Navn er en tekststreng, lektioner er et heltal. Karakter er ogs˚ a et heltal, der oven i købet lever op til at tilhøre en nærmere defineret delmængde af heltallene. Gyldige karakterer er den værdimængde, som værdien for karakter skal leve op til. Læseren vil observere, at der er data, der g˚ ar igen i flere tabeller. Disse værdier kan bruges til at finde referencer mellem tabellerne, hvorved vi kan sammenstikke beslægtede data fra flere tabeller p˚ a en meningsfyldt m˚ ade.

1.4.2

For f˚ a data, for mange data

Vi skal i forbifarten allerede her se p˚ a et par problematiske forhold, der er nyttige at have kendskab til fra starten. Problemerne handler om henholdsvis for f˚ a data og for mange data. 1.4.2.1

For f˚ a data - null

I visse situationer mangler vi værdi til en eller flere kolonner i en tabel i databasen. Vi siger at en kolonne uden data er null 6 . Null er ingenting, intet, og kan derfor selvfølgelig ikke typebestemmes. Kast et blik p˚ a tabel 1.2. I rækken med FagNummer-værdien 3500 er der intet indhold i kolonnen Afdeling. Der st˚ ar ikke mellemrumstegn eller andet. Der st˚ ar intet, null. Det samme er tilfældet i rækken med FagNummer-værdien 3531 for kolonnen Lektioner. Her st˚ ar ingenting, null. I første tilfælde burde der have st˚ aet en streng som værdi, i det andet tilfælde et tal. Det kan med god ret hævdes, at de p˚ agældende rækker er kvalitativt forskellige fra tabellens øvrige rækker. Det kan derfor med liges˚ a god ret diskuteres om de overhovedet bør være der. Fag FagNummer

Navn

Lektioner

3500

Basisfag

4

3520

Interaktion

4

MDU

3521

Databaser

8

MDU

3670

GSU

6

DMU

3531

Semiotik

3530

Kommunikation

Afdeling

MDU 4

MDU

Tabel 1.2: Tabel med manglende værdier. Nogle g˚ ar p˚ a kompromis, og siger ja, hvorfor ikke. Andre, som undertegnede, siger nej, de bør ikke være der. Eksemplet er indrettet som det er af pædagogiske grunde. De liberale g˚ ar af og til s˚ a vidt som til at tale om null-værdier, hvilket er en sproglig fejl. Værdier tilhører typer, datatyper. Intet tilhører selvfølgelig ikke nogen datatype og kan derfor ikke betegnes som en værdi. Prøv at overveje om man kan sammenligne 4 lektioner med afdelingsbetegnelsen MDU. Er de ens? Er de forskellige? Kan man nu sammenligne den manglende information om antal lektioner med den manglende information om afdeling? Naturligvis kan man ikke det. Intet er ikke sammenligneligt. Vi skal i bogens løb se, hvordan det altid er muligt at designe databaser, som muliggør dataregistrering uden nulls. Denne bog vil herefter anse muligheden for null i databaser for d˚ arligt design, der g˚ ar p˚ a uønsket kompromis med teorierne. 5

Fra den relationelle faglige terminologi. Ordet findes ikke i selv store engelsk/amerikanske ordbøger. Oprindeligt tuple, der rimer p˚ a couple med hensyn til udtale. 6 Null er engelsk fagsprog for ingenting. I mangel af et mundret dansk ord bruges det her.

16

©nml


1.5: Standarder

1.4.2.2

For mange data - Redundans

Det ideelle antal data i databasen m˚ a være det, som man har brug for. Ikke mindre, ikke mere. Tag nu tabel 1.1 som eksempel. Skift dennes karakterlistetabel ud med eksemplet i tabel 1.3, og vi har et tydeligt eksempel p˚ a det vi kalder redundans, unødige ekstraforekomster af dataværdier i databasen. Det ses, at student nummer 17 hedder Alexandersen. Det ses jo til overm˚ al igen i databasetabellens næste række ogs˚ a. Det er registreret to gange. For nummer 8, Benjaminsen, er det tre gange. Disse tal er i tillæg til at navnene allerede er registrerede i studerende-tabellen. Netop det, at blot vises to gange er m˚ aske det mindste problem ved redundans, selv om det jo optager unødig plads p˚ a computerens lagermedium, og det har sin omkostning. Det er et større problem, hvis Alexandersen nu gifter sig og skifter navn til Andersen, ikke fordi Andersen ikke er fint, men fordi vi skal gennemføre rettelsen (mindst) to gange. I tilfældet Benjaminsen oven i købet tre gange. Gøres dette p˚ a en personlig computer ved individuel sagsbehandling tager det for lang tid. Skrives der programmer for at gøre det, er dette spild af tid, n˚ ar man ved rettidig omhu kunne nøjes med at have informationen en gang, og dermed kun skulle vedligeholde den en gang. Karakterliste StudentNummer

Navn

KursusId

Karakter

17

Alexandersen

120

9

17

Alexandersen

101

8

8

Benjaminsen

114

11

8

Benjaminsen

101

9

8

Benjaminsen

145

11

Tabel 1.3: Tabel med redundans. Et andet problem ved redundans er det, at n˚ ar data kan forekomme flere gange, s˚ a vil forekomsterne kunne blive forskellige. Student nummer 17 kunne et sted være Alexandersen og et andet Alexandrovitch. Hvilken forekomst er da den rigtige, og hvilken tør vi dermed stole p˚ a? Hvilken skal rettes? Eller slettes? Det design, der vises i tabel 1.1, hvor den studerende navn opbevares i studerendetabellen og kun der, mens fagtabellen slet ikke viser navn, er klart det bedste design. Man kan sige at en database i sin helhed er et udsagn om den virkelighed, som database skal afspejle. Vi ønsker, at databasen skal være sand. Den skal være tro mod virkeligheden. Vi skal ogs˚ a i dette tilfælde i bogens løb se, hvordan det er muligt at designe databaser uden redundans. Denne bog vil herefter anse det for d˚ arligt design, hvis en database har redundante data.

1.5

Standarder

Som bruger af databaser er man, som indenfor andre omr˚ ader af it, normalt godt stillet, hvis omr˚ adet er dækket af en vis standardisering. Helst internationale standarder anerkendt at ISO7 direkte eller gennem en af dens medlemsinstitutioner. I nogle sammenhænge er modeller standardiserede, det mest kendte eksempel er vel ISOs 7-lags OSI8 model, der beskriver datakommunikation. P˚ a databaseomr˚ adet skulle vi s˚ a lede efter en standardisering af de modeller, der beskriver den del af ANSI/SPARC-modellens beskrevne modeller, der ligger ud over det rent fysiske niveau, som varetages af det konkrete operativsystems filsystem. 7 8

International Standards Organization. Open Systems Interconnection.

©nml

17


Kapitel 1: Introduktion

N˚ ar det gælder en datamodels operationer som implementeret gennem SQL9 , s˚ a findes SQL standardiseret gennem ISO 9075. Kapitel 8 har detaljerne om b˚ ade sproget SQL og standardiseringen heraf.

1.6

Læsevejledning

Enhver lærebogsforfatter ser naturligvis helst, at alt det skrevne bliver offer for læserens glubende appetit p˚ a viden indenfor domænet. Man m˚ a imidlertid lægge vægt p˚ a det læringsniveau, der ønskes opn˚ aet. Bogens grundlæggende del udgøres af kapitel 1 og 2 bør læses uanset læringens slutm˚ al. I et første databasekursus, hvor kendskab til og viden om domænet er et tilstrækkeligt læringsniveau, rækker det i denne bog at læse om datamodellering først og siden om den relationelle model. Det drejer sig om kapitlerne 3 - 4. Skal læseren opn˚ a et anvendelsesniveau, hvilket vil sige, at hun skal bringe sig i stand til at bruge databaser i praksis p˚ a et kvalificeret niveau er dette ikke nok. Hun m˚ a yderligere grundigt sætte sig ind i hvordan databasen skabes p˚ a baggrund af en semantisk model, samt i databasemodellens operationer og studere det sprog, der hører til modellen. I nærværende tilfælde betyder dette at bogens SQL tutorial bliver nødvendig læsning. Kapitlerne 6 og 8 10. Kapitel 5 er anbragt, hvor det forekommer logisk, n˚ ar man læser bogens sekventielt fra ende til anden. I et kursus kunne man vælge at gennemg˚ a dette materiale efter SQLgennemgangen for at give den studerende en chance for at erhverve sig et praktisk perspektiv. Det korte kapitel 7 om valg af RDBMS har nogle overvejelser om sammenhængen mellem teori og praktisk “anskaffelig” software. Det har ingen væsentlig teori, og kan springes over, hvis man i forvejen har et RDBMS, hvorp˚ a man evt. vil udføre bogens eksempler.

1.6.1

Alternativt ...

Overgangen mellem en udviklet semantisk datamodel og dens implementering som relationel database er et kærneomr˚ ade og p˚ a det punkt bringer bogen en systematik, der kan anvendes som checkliste, og samtidig tilvejebringes en anden systematik, normalisering, der sætter læseren i stand til at evaluere egne semantiske modeller og andres implementeringer. Kapitlerne 3 - 6 er nødvendig læsning, hvis man selv skal udarbejde datamodeller eller skal vurdere andres arbejde med samme.

1.6.2

Hertil kommer

Skal en læsers fremtidige brug af databaser ske gennem systemudvikling, programmering, er det nødvendigt i tillæg til denne bog at sætte sig ind i det/de aktuelle programmeringssprogs implementering af SQL-anvendelse. I denne bog er vist eksempler p˚ a udvikling af internetbaserede distribuerede applikationer, af og til kaldet web-applikationer. I den henseende er kapitlerne om SQLs anvendelse fra PHP at betragte som et eksempel p˚ a SQL brugt gennem et programmeringssprog. P˚ a dette punkt stiller bogen nogle forudsætningsmæssige krav til læserens om forst˚ aelse af internettets natur som client/server-system. 9

Structured Query Language.

18

©nml


1.7: Øvelser til kapitel 1

1.7 1.7.1 1.7.1.1

Øvelser til kapitel 1 Øvelser vedrørende tabel 1.1 Øvelse

Find relationer mellem records/tabeller i noternes eksempeldatabase, tabel 1.1. Fremgangsm˚ ade: Lav en fotokopi og tegn streger p˚ a tegningen. Fremlæg og argumenter! 1.7.1.2

Øvelse

Find nogle forespørgsels- og opdateringsoperationer, der kan tænkes p˚ a eksempeldatabasen. Dette skal ikke foregribe SQL, som læres senere, men giv et bud i almindeligt naturligt sprog p˚ a en udskrift, en skærmvisning, en opdatering, en sletning eller lignende. Prøv at overveje og argumentere for at eksemplet kan tilfredsstille det tænkte. 1.7.1.3

Øvelse

Hvad er redundans? Er der redundans i eksempeldatabasen, tabel1.1? Hvad er forskellen p˚ a ukontrolleret og kontrolleret redundans? Giv venligst et par eksempler. Husk at Google er din ven! 1.7.1.4

Øvelse

Forklar hvad null er. Prøv at finde argumenter for og imod at tillade nulls i attributterne i databasens tabeller. 1.7.1.5

Øvelse

Kan man forestille sig indskrænkninger, regler om eksempeldatabasens tabeller, s˚ a integriteten sikres og bevares?

©nml

19


Kapitel 1: Introduktion

20

Šnml


Kapitel 2

Datamodeller 2.1

Abstraktioner - en verden og dens billede ”Ceci n’est pas une pipe” – Rene Magritte

Informationsteknologien (IT) er en nødvendighed i dagens organisationer. De kunne ikke overleve uden. De fleste vil anerkende denne bredt formulerede p˚ astand. IT-systemer manifesterer sig (ikke kun, men primært) gennem informationssystemer. Vi, som er medarbejdere i disse organisationer, f˚ ar fra informationssystemerne den information, som bliver til viden og indsigt om det miljø, som informationssystemet opererer i og er en del af. Man kan s˚ aledes sige, at informationssystemet danner en model af sit miljø. Ikke en model af hele den virkelige verden, men blot den del af virkeligheden, som vedrører organisationen. Vi siger om en s˚ adan model, at den ikke er en virkelighed i sig selv, men at den er et billede af en virkelighed, og at den derfor er en abstraktion. Skabelsen af et nyt informationssystem kræver yderligere et lag abstraktion. Vi er nødt til at danne en model af det system, vi skal til at udvikle, og hvis vi ser organisationens hidtidige systemer som abstraktion af en virkelighed, bygger vi s˚ aledes ovenp˚ a denne, n˚ ar vi modellerer det nye system. Det er m˚ aske form˚ alstjenligt at nævne, at vi kan komme ud for at skulle modellere ikke blot den fysiske realitet, men ogs˚ a ideer, begreber og simulationer af virkeligheden.

2.1.1

Data eller processer - to synsvinkler

Med Rønnow and Jacobsen (1989) kan vi sige, at skabelsen af en model af et nyt informationssystem kan ske p˚ a baggrund af to forskellige synsvinkler. Man kan vælge enten at se p˚ a de processer som de informationer skal udsættes for af det nye system, eller man kan vælge at starte med at koncentrere sig om de involverede informationer, det nye systems data. Vi siger, at vi skelner mellem en proces-drevet og en data-drevet metodik i systemudviklingsprocessen. I de senere ˚ ar kan man ogs˚ a se en udvikling af de s˚ akaldt objekt-orienterede systemudviklingsmetoder, hvor man kombinerer datas informationsindhold med de processer, som naturligt er knyttede til disse data. En af denne bogs grundteser er dog, at vi er nødt til at forst˚ a netop informationsindholdet i vore data og disses indbyrdes sammenhænge og struktur for at kunne gøre disse data uafhængige, s˚ a vidt muligt, af ændringer i den m˚ ade hvorp˚ a vi vil bruge dem. Indenfor database-omr˚ adet og i øvrigt ogs˚ a inden for datavarehuse, som et specialtilfælde af databaser, ser vi ofte en spin-off effekt fra de systemer, vi allerede har udviklet. De danner nemlig ofte baggrund for den kreativitet, der leder frem til nye informationsbehov og dermed 21


Kapitel 2: Datamodeller

ofte til nye kombinationer og sammenhænge i anvendelsen af de data vi har til r˚ adighed. P˚ a den baggrund er det svært at se bort fra den data-drevne metodik i systemudviklingen, og derved f˚ ar samtidig datamodellen og især dens fleksibilitet en helt afgørende rolle. Førend vi begynder at diskutere struktur skal det fremhæves, at p˚ a det mest detaljerede niveau manifesterer datamodellen sig gennem data. Langefors (1977) siger: Data svarer til diskrete 1 , registrerede fakta om fænomener, hvormed vi f˚ ar information om virkeligheden. Information er den vidensforøgelse, der kan opn˚ as ved 2 bearbejdning data .

2.1.2

Fortolkning af data

Ovenst˚ aende citat om data findes ogs˚ a i Tsichritzis and Lochovsky (1982), som er et fundamentalt værk om datamodeller. Dette værk fortsætter med en diskussion af nødvendigheden af at adskille data fra deres fortolkning. Netop dette er en vigtig pointe. Citatet er en praktisk og lidt bred definition. Begrebet information definerer Nudansk Ordbog som “viden som bringes videre” bruges indenfor informationsteknologien i betydningen data som bringes videre, jf. definitionen p˚ a data ovenfor og den tidligere givne fra Elmasri and Navathe (2003), se 1. Dette informationsbegreb er forskelligt fra Langefors. Nørretranders (1991) har i øvrigt i kapitel 1 og 2 nogle interessante og væsentlige informationer om information som begreb. For at klargøre denne sprogbrug kan man sige, at data er det simple begreb. Færre eller flere data, der udsættes for en behandling, herunder opbevaring eller formidling, kalder vi information, der s˚ aledes er det mere komplekse begreb. Anvendelsen af information kan resultere i viden, hvis information tillægges en passende mængde fortolkning. Viden er s˚ aledes det mest komplekse begreb. Viden eksisterer efter denne forfatters opfattelse ikke opbevaret i et informationssystem, men fremkommer i en brugers bevidsthed ved anvendelse af informationssystemet. Dette betyder, at den viden en bruger opn˚ ar ved fortolkning af indhentet information bliver, hvis den opbevares, til information for en efterfølgende bruger. Til klargøring heraf vil ovenst˚ aende definition blive reformuleret s˚ aledes: Data svarer til diskrete, registrerede fakta om fænomener. Gennem bearbejdning og eller lagring af data f˚ as information om fænomenernes univers. Viden opst˚ ar ved fortolkning og bearbejdning af information. Fortolkning af information overlades brugere, og netop dette kan frembyde et problem. Hvad sker der, hvis to forskellige brugere fortolker de samme data? De er selvsagt hver især i stand til at fremhæve deres egen fortolkning. Mange brugeres anvendelse af samme information ˚ abner s˚ aledes mulighed for mange mulige fortolkninger af denne information. En ændring i betydning vil s˚ aledes ogs˚ a medføre, at mange brugere skal revurdere deres fortolkning af de p˚ agældende data. Konklusionen af dette m˚ a være, at det er nyttigt og hensigtsmæssigt at registrere fortolkningsregler, s˚ aledes at brugerne kan læse dem, og dermed ikke længere helt s˚ a frit kunne fortolke de p˚ agældende data. Vi skal senere se, at man i begrebsmæssig datamodellering indbygger en fortolkning i modellen. Det medfører naturligvis, at efter implementering af den begrebsmæssige model er brugerne nødt til at forholde sig til den nu indbyggede fortolkning. Til slut en enkelt bemærkning til den netop anvendte terminologi. Begrebet bruger skal forst˚ as bredt. Det kan være et program, men det kan ogs˚ a være en person. I nogle sammenhænge bruges begrebet agent om en s˚ adan bruger, se fx. Elsom-Cook (2001), kapitel 1 og 2. 1 2

Enkeltst˚ aende, i modsætning til kontinuerte. Denne forfatters oversættelse.

22

©nml


2.1: Abstraktioner - en verden og dens billede

2.1.3

Tid

Det er selvfølgelig nødvendigt at beskæftige sig med data for at diskutere datamodellering. Langefors (1977) betragter et udeleligt (atomart) dataelement fra en mængde, som best˚ aende af <elementnavn, elementegenskab, elementegenskabsværdi, tid>. Det tidsmæssige aspekt er jo naturligt i visse sammenhænge, idet det kan være interessant at kunne registrere et informationsindhold med en tidsdimension som et aspekt af informationen. Der er imidlertid nogle problemer ved tid som en integreret del af en information. Disse problemer gør, at f˚ a eller ingen datamodeller indeholder dette tidsaspekt. Vil man bevare en tidsdimension i sin model har man to muligheder. Enten m˚ a den modelleres ind som et selvstændigt element med egen værdi, eller man kunne indføre en eller anden form for sortering, der medfører forgænger- og efterfølger-forekomster og derved afspejler et tidsmæssigt forløb. Vi skal senere se, at den relationelle model ikke har noget valg, idet sorteringsaspektet ikke kan rummes i denne model. Da vi i denne bog vil koncentrere os om den relationelle model, indser vi allerede nu at temporale data, som de kaldes, m˚ a modelleres som selvstændige data. Langefors tidsbegreb i et dataelement betyder s˚ aledes i praksis, at dataindholdet i en model er et øjebliksbillede af en virkelighed, og at hvis data ændres, st˚ ar vi overfor et nyt øjebliksbillede, hvorved det forrige er tabt.

2.1.4

Definition

N˚ ar vi skal beskrive sammenhænge mellem de data vi indtil nu har diskuteret, m˚ a vi se p˚ a de kombinationsmuligheder, der findes og dermed beskrive de strukturelle forekomster de kan antage. Befolkningen med data af en model med disse strukturelle kombinationsobjekter kræver en vis orden, idet alternativet selvfølgelig er anarki med deraf følgende manglende mulighed for at forudse modellens anvendelse. Den orden der kræves udtrykkes gennem nogle beskrevne begrænsninger til strukturernes opførsel, og deres indbyrdes sammenhænge. Det engelske begreb herfor er constraints, der netop betyder begrænsninger. Ser vi modellen som en virkelighed i sig selv er disse begrænsninger at sammenligne med et samfunds love og regler for dets elementers ageren med og mod hinanden. Da en datamodel imidlertid ikke blot er en statisk afbildning af en virkelighed, men ogs˚ a en dynamisk organisme i sig selv er det i denne bog fundet bedst at bruge begrebet regler, som den generelle oversættelse af constraints. Vi n˚ ar efterh˚ anden frem til følgende formelle definition af en datamodel: M =G+O hvor M er modellen, G er en mængde af generatorer og O en mængde af operationer. Man kan sige, at generatorer er beskrivelse af modellen og den hvorp˚ a den skal opfattes. Tsichritzis and Lochovsky (1982) hævder, at det kan være nyttigt at se p˚ a to typer af generatorer, nemlig de strukturelle og de der beskriver regler. Herved f˚ ar vi formuleringen: M = Gs + Gc + O hvor Gs er generatorer, der beskriver struktur, og Gc er generatorer, der beskriver regler (constraints). I database-terminologi findes et begreb, skema, der refererer til de før nævnte kombinationsobjekter, disses egenskaber (attributter) og den sammenhæng, der er mellem egenskaberne. I denne sprogbrug f˚ ar sidstnævnte formel nu følgende udseende, idet skemaerne og deres struktur afspejler generatorerne: M = Ss + Sc + O ©nml

23


Kapitel 2: Datamodeller

I mere daglig tale ville vi sige, at en datamodel best˚ ar af en strukturel beskrivelse, nogle regler, samt en beskrivelse af de operationer, som kan anvendes p˚ a de strukturelle objekter i modellen under overholdes af reglerne. Denne definition af en datamodel er det, vi kalder en logisk datamodel, og dens placering ses i figur 1.2 i kolonnen datamodeller. I det omfang datamodellen hviler p˚ a matematisk/logisk teori og sunde videnskabelige metoder har vi en basis, der gør det muligt at vurdere og analysere forskellige implementeringer heraf p˚ a systematisk vis.

2.2

Databasesystemer

Tilvejebringelse af et databasesystem i den praktiske verden sker ved programmering af et softwaresystem, der realiserer de generatorer, regler og operatorer, som vi netop har beskrevet i forbindelse med diskussion af, hvad en model egentlig er. En s˚ adan implementering er det Database Management System, DBMS, der tidligere er nævnt, jf. figur 1.2. Med denne figurs terminologi, der forudser bogens udvikling henimod en beskrivelse af relationelle systemer, s˚ a kaldes implementeringen Relational Database Management System (RDBMS). Af figuren skulle fremg˚ a, at implementeringen af den relationelle model sker ved et RDBMS. Dette system har sin ene, logiske, grænseflade vendt mod brugeren/programmøren, og tillader at denne med RDBMS som værktøj skaber en implementering af sin konkrete model i en database. Den anden grænseflade, som RDBMSet har vender mod operativsystemets filsystem, og er uden interesse for brugeren eller programmøren. Databasesystemet manifesterer sig oftest gennem en server, der h˚ andterer overholdelsen af de strukturelle skemaer og de dertil knyttede regler. En vigtig komponent i denne server er en fortolker af de operationer, der modtages interaktivt eller programmatisk. Set ud fra en mere abstrakt synsvinkel kan man sige, at RDBMSet skal stille henholdsvis Ss , Sc og O til r˚ adighed for en bruger ved at tilvejebringe programmel, der realiserer grænseflader hertil for brugeren. Ud over disse definitoriske behov, skal et ordentligt system ogs˚ a opfylde mere traditionelt systemadministrative behov, som for eksempel ved at have et ordentligt backup-program.

2.3

Brugergrænseflader

Databasesystemets interaktive brugergrænseflade, en klient, stiller systemets operationer til r˚ adighed for en bruger, der interaktivt ønsker at etablere, h˚ andtere eller nedlægge sin database. Et s˚ adant program modtager brugerens input og foretager en syntaktisk kontrol af det modtagne og sender derefter det modtagne videre til serverens fortolker, der centralt for flere klienter kan fortolke operationer semantisk og f˚ a dem udført, hvorefter svar sendes tilbage til klientprogrammet. Der findes selvfølgelig en anden grænseflade for brugeren end den interaktive klient. Det er muligt at indlejre operationsanmodninger i et traditionelt problemorienteret programmeringssprog, s˚ aledes at dette under udførelsen sender disse anmodninger videre til serveren til fortolkning og udførelse. I det lys kan det siges, at der ved systemudvikling med inddragelse af et databasesystem opst˚ ar et antal klienter i forhold til systemet.

2.4

Øvelser til kapitel 2

2.4.1

Øvelser datamodeller

2.4.1.1

Øvelse

Hvad ligger der i tidsbegrebet i forbindelse med en datamodel? Hvordan s˚ a databasen ud i g˚ ar, og hvordan ser den ud i dag? 24

©nml


2.4: Øvelser til kapitel 2

Hvad var momsprocenten for tre ˚ ar siden p˚ a denne dato? Kan databasen fortælle noget om det? 2.4.1.2

Øvelse

Findes der andre logiske datamodeller end den relationelle, og hvordan fordeler udbredelsen sig? Husk at Google er din ven!

©nml

25


Kapitel 2: Datamodeller

26

Šnml


Kapitel 3

Semantisk datamodellering “Take care of the sense, and the sounds will take care of themselves.” (The Duchess in Alice in Wonderland) – Lewis Carroll Vender vi for en stund tilbage til figur 1.2 fra kapitel 1 skal vi nu gennemg˚ a en datamodel, der ikke ved første øjekast lever op til den netop fremlagte definition af en s˚ adan. Vi vil se p˚ a data p˚ a et niveau, hvor der ikke er mening i konkret at tale om operationer p˚ a data p˚ a mere præcis m˚ ade, end at vi kan f˚ a lagrede data til r˚ adighed til behandling. En model p˚ a dette høje abstraktionsniveau kaldes en begrebsmæssig eller konceptuel datamodel. Den semantiske datamodel skildrer den m˚ ade, hvorp˚ a data hænger sammen i en organisation, eller mere generelt i den del af virkeligheden, som vi ønsker beskrevet med en database. Denne model er egnet til at diskutere med nogle brugere, idet den bygger p˚ a en overskuelig, oftest grafisk, metode med en relativt enkel beskrivelsform. Overfor dette st˚ ar den relationelle model, der definerer en struktur for datas logiske opbevaring, samt et antal operationer, der skal kunne udføres p˚ a disse data og deres struktur i fuld overensstemmelse med definitionen i aledes poskapitel 2. Man kunne vælge at kalde dette for en implementeringsmodel. Det skal s˚ tuleres, at den begrebsmæssige models anvendelse i et givet systemudviklingsprojekt udgør en forudsætning for skabelsen af en konkret database i overensstemmelse med den relationelle datamodel. Her vil vi ogs˚ a beskrive en udviklingsmetode, hvori begrebsmæssig modellering udgør en tidlig fase, og hvor et af de beskrevne senere skridt netop er en transformation af den udviklede semantiske model til en database, der overholder den relationelle models forskrifter.

3.1

Modelværktøjer

I vore dage findes der to gængst anvendte beskrivelsesværktøjer, som man kunne kalde semantiske datamodeller, men som retteligt er værktøjer til beskrivelse af semantiske modeller. N˚ ar man betragter data, p˚ avirker man dem p˚ a samme m˚ ade som det siges at observation af elementarpartikler i fysikken p˚ avirker disse partiklers opførsel. Hvilken betydning har dette? I denne sammenhæng betyder det, at data “i hvile” p˚ a en computers lagermedier, det være sig harddisk, cdrom eller lignende, ikke nødvendigvis behøver at tage sig ud p˚ a samme m˚ ade som data “i flugt”, det vil sige som indlæste data under brug af et program. De to situationer afspejler to forskellige tilstande, som disse data kan befinde sig i, og der er derfor m˚ aske grund til at have (mindst) to forskellige beskrivelsesformer for disse tilstande. Den ene af de meget udbredte beskrivelsesformer er Entity-Relationship-modellen, ofte blot kaldet ER-modellen. Den stammer fra midten af 70’erne og er skabt af og beskrevet i Chen (1976). Dens form˚ al og sigte er alene beskrivelse af de virkelighedsfænomener, entiteter, 27


Kapitel 3: Semantisk datamodellering

som vi i et givet system gerne vil arbejde med, og deres indbyrdes sammenhænge, deres relationer 1 . Den anden beskrivelsesform er Unified Modelling Language, UML, der er nyere og nært knyttet til den objektorienterede tankegang, der har vundet s˚ a meget udbredelse. UML har et noget bredere sigte end ER-modellen, og herunder er det et vigtigt værktøj ikke blot til beskrivelse af data og deres sammenhænge men ogs˚ a deres konkrete anvendelse, idet værktøjet a de p˚ agældende data. UML vinder bruges til at beskrive de metoder2 , som kan anvendes p˚ frem sammen med objektorienteret systemudvikling.

ER

UML

Procesdrevet

Datadrevet

Figur 3.1: Udviklingsmetoder og -værktøjer. Det er denne forfatters opfattelse, at der i ER-modellens beskrivelse af datas sammenhænge er nogle nuancer til stede især om relationerne mellem entiteterne, som g˚ ar tabt ved anvendelse af UML. Derfor vælger denne bog ER-modellen til netop beskrivelsen af semantiske datamodeller. Til andre og mere konkrete, mindre abstrakte, beskrivelser vil UML være et naturligt valg. Man kan ogs˚ a anskue anvendeligheden af modelleringsværktøjerne som visualiseret i figur 3.1. Der er tale om en glidende overgang mellem metoderne.

3.2

ER-modellen

I sin oprindelige artikel om ER-modellen siger Chen (1976), at man i studiet af en datamodel m˚ a beskæftige sig med en opfattelse af data p˚ a fire beskrivelsesniveauer: 1. Information som vi forbinder med entiteter og relationer. 2. Informationsstrukturen, det vil sige hvilke data vi vælger at lade være egenskaber ved entiteter og relationer. 3. Logiske datastrukturer. Datastrukturer set uafhængigt af valgt opbevaringsform. 4. Fysiske datastrukturer afhængige af opbevaringsform, det vil sige som de h˚ andteres af filsystemet. Figur 3.2 viser som en udvidelse til en tidligere vist figur, hvordan disse niveauer kan opfattes parallelt til ANSI/SPARC-modellens opfattelse.

3.2.1

Entiteter og relationer

En entitet er en specifik ting, fysisk eller begrebsmæssig, som indg˚ ar i vores forestillingsverden om et kommende system, hvorfor den m˚ a indg˚ a i vores model. En studerende, en ud1

Relationer, engelsk: relationships. M˚ a ikke forveksles med relation, som det anvendes i relationelle model, hvor det er et matematisk begreb. 2 Metode er objektorienteret terminologi for begrebet funktion.

28

©nml


3.2: ER-modellen Datamodel

ANSI/SPARCarkitekturens notation

fx ER-modellen

Eksternt niveau (user views)

fx Relationelle Model

konceptuelt niveau

Ingen, ie. Operativsystemets filsystem

Internt niveau

Implementering

Chens notation

Databasens semantik, ie. diagram og information

1. Entiteters og relationers informationsindhold

Databasens relationer (tabeller)

Databasens fysiske beskrivelse

2. Entiteters og relationers strukturerede dataindhold

3. Datas logiske struktur

4. Datas fysiske struktur

Figur 3.2: En gentagelse af figur 1.2, men udvidet med Chens niveauer. dannelsesinstitution, en klasse eller en uddannelse kunne være eksempler p˚ a entiteter. En relation 3 kan her defineres som den forbindelse eller association, der er mellem entiteter.

Figur 3.3: En simpel relation mellem to entiteter. En studerende g˚ ar i en klasse er et eksempel p˚ a en relation mellem entiteterne studerende og klasse. ER-modellens tegneteknik vil afbilde dette som vist i figur 3.3. Entiteter afbildes som rektangler, mens relationer afbildes som rhomber.

3.2.2

Entitet og entitetsklasse

Vi er nødt til at foretage en sondring med henblik p˚ a at klargøre sprogbrugen omkring entiteter. Vi siger at entiteter kategoriseres i entitetsklasser, hvilket i eksemplet i figuren betyder, at en specifik studerende, en forekomst, tilhører entitetsklassen Studerende. Vi opfatter entitetsklassen Studerende som en matematisk mængde, hvilket betyder, at vi skal kunne afgøre om en given entitet tilhører mængden. Matematisk-logisk siger man, at der til en entitetsklasse er knyttet et prædikat. Dette tillader at der p˚ a en given forekomst kan foretages en test, der med resultatet sand eller falsk vil afsløre om forekomsten tilhører entitetsklassen. Chen (1976) har en anden væsentlig pointe om entitetsklasser, nemlig at de betragtet som matematiske mængder ikke nødvendigvis er disjunkte, se figur 3.4. En given entitet kan samtidigt tilhøre flere entitetsklasser, hvilket kan afgøres i overensstemmelse med hver entitetsklasses prædikat. I praksis betyder dette, at en given studerende kunne tilhøre enten en entitetsklasse som heltidsstuderende eller deltidsstuderende, hvis vi har defineret s˚ adanne. Disse entitetsklasser siges s˚ a at være overlappende i forhold til studerende. Heltidsstud3

Det bør gentage, at relation er et uheldigt ord, selvom det er den anerkendte danske betegnelse. Ordet vil senere i forbindelse med den relationelle model blive brugt om en matematisk relation, der implementeres som en tabel. De tilsvarende engelske betegnelser er i ER-modellen er relationship og i den relationelle model relation.

©nml

29


Kapitel 3: Semantisk datamodellering

Figur 3.4: Illustration af entiteter og entitetsklasser set med mængdelærens øjne. erende eller deltidsstuderende er i dette eksempel ægte delmængder af studerende, hvilket betyder, at alle medlemmer af heltidsstuderende og deltidsstuderende ogs˚ a er studerende. De i denne model disjunkte i forhold til hinanden. Et andet eksempel kunne være, at en person, der tilhører entitetsklassen lærer, m˚ aske samtidig kan følge et kursus som medlem af entitetsklassen studerende. De lærere, der s˚ aledes ogs˚ a er studerende siges at udgøre en delmængde af entitetsklassen studerende. Medlemmer af entitetsklassen lærere overlapper entitetsklassen studerende, men er ikke en ægte delmængde, da ikke alle lærere ogs˚ a er studerende.

3.2.3

Relationer og relationsklasser

Svarende til entiteter og entitetsklasser er der ogs˚ a grund til at sondre mellem relationer og relationsklasser. Vi s˚ a i det simple ER-diagram i figur 3.3, at relationen der var en association mellem to entitetsklasser. Chen generaliserer det og formulerer det matematisk s˚ aledes: R = {[e1 , e2 , ... , en ] |e1 ∈ E1 , e2 ∈ E2 , ... , en ∈ En } Denne formel læses s˚ aledes: En ER-relation, er en association af entiteter [e1 , e2 , ... , en ] , hvorom det gælder, at entiteten e1 tilhører entitetsklassen E1 , entiteten e2 tilhører entitetsklassen E2 etc. op til at entiteten en tilhører entitetsklassen En . Det kan udtrykkes s˚ aledes, at en relation er en association af n entiteter tilhørende hver sin entitetsklasse. En relation er ogs˚ a en specifik forekomst blandt et antal, der alle tilhører samme relationsklasse. Værdien af n i Chens definition kan teoretisk variere s˚ aledes at 1 ≤ n ≤ ∞. Praktisk modelleringsarbejde vil dog sjældent føre til store værdier af n. aet navn p˚ a dansk4 (og engelsk). Engelsksproget Figur 3.5 viser de relationsgrader, der har f˚ faglitteratur anvender ofte begrebet n-ary om relationer af n’te grad. Begrebet er s˚ aledes tilsyneladende fagligt officielt, men sprogligt uofficielt. Det findes ikke i engelske ordbøger. Det ville m˚ aske være nærliggende at kalde dette for n-ær p˚ a dansk. Denne betegnelse er dog b˚ ade fagligt og sprogligt uofficiel. Figurens a) kaldes ogs˚ a i dele af litteraturen en rekursiv relation. Udover de knapt s˚ a mundrette danske betegnelser viser figuren blandt andet ogs˚ a, e), at diagrammeringsformen ikke nødvendigvis altid kræver alt i rette vinkler. Navngivning af relationer er ofte et valg mellem flere muligheder. Se p˚ a figur 3.3. Her er navnet p˚ a relationen g˚ ar i. Den samme relation kunne ud fra formuleringen “en klasse har mange studerende” være kaldt har. Valget er arbitrært og afspejler hvad designeren finder naturligt. Modellen forhindrer ikke, at flere relationer har samme navn, selvom dette senere eventuelt vil medføre visse referenceproblemer. 4

I overensstemmelse med Dansk Sprognævn, http://www.dsn.dk.

30

©nml


3.2: ER-modellen

Figur 3.5: Relationer af stigende grad.

3.2.4

Attributter

N˚ ar det overhovedet er interessant at beskæftige sig med en given entitet, er det selvfølgelig fordi, den har visse egenskaber, der motiverer vores interesse. For skolen er den studerende interessant fordi vedkommende g˚ ar i en af skolens klasser, og derved bliver nogle egenskaber ved den studerende relevante. Den studerendes fornavn, efternavn, adresse og telefonnummer er nogle eksempler. Egenskaber kaldes attributter. Attributter indg˚ ar ikke i ER-modellens oprindelige tegnetekniske begrebsapparat, men er senere blevet tegnet som ovaler, navngivet med den p˚ agældende attribut. Se p˚ a eksemplet i figur 3.6. I følge Chen (1976) defineres en attribut som en funktion, der foretager en afbildning fra en entitetsklasse eller en relationsklasse ind i en værdimængde eller det kartesiske produkt af værdimængder. Matematisk har Chen formuleret det som: f : Ei → Vi eller f : Ei → Vi1 × Vi2 × · · · × Vin eller f : Ri → Vi eller f : Ri → Vi1 × Vi2 × · · · × Vin Chen har formuleret det i en enkelt sætning. Det er her bredt ud for overskuelighedens skyld. Mere dagligdags kan dette udtrykkes som at attributternes værdier fra en entitet eller en relation kan antage de værdier som tilhører de respektive domæners værdimængder. Et domæne er defineret som tilhørende en bestemt datatype med den værdimængde som dette indebærer, eventuelt begrænset yderligere gennem nogle særlige regler for domænet. Figur 3.6 viser yderligere to interessante aspekter om relationer. De kan selv have attributter, og de identificeres af de entiteter, som de associerer. I figurens eksempel er attributten deltagelsesbrøk ikke en egenskab ved hverken lærer eller udviklingsprojekt, idet attributten semantisk afhænger af b˚ ade lærer og udviklingsprojekt. ©nml

31


Kapitel 3: Semantisk datamodellering

Figur 3.6: ER-diagram med indtegnede attributter. 3.2.4.1

Sammensatte attributter

I daglig tale bruger vi ofte begrebet adresse, n˚ ar vi m˚ aske i virkeligheden har gadenavn, gadenummer, sted, postnummer, postdistrikt (by) og af og til endda land. Der utvivlsomt fordelagtigt at modellere med de s˚ akaldt atomare attributter, idet det giver os adgang til en højere grad af præcision i tabellen og dermed ogs˚ a, som vi skal se senere, at etablere en integritetskontrol baseret p˚ a datatype, som vi ikke kan h˚ andhæve p˚ a et sammensat felt. Se tegneeksemplet i figur 3.7.

Figur 3.7: Eksempel med de to flerværdiede attributter Navn og Adresse.

3.2.4.2

Flerværdiede attributter

Der gives situationer i virkeligheden, der overordnet set afspejles bedst af s˚ akaldte flerværdiattributter. En typisk enkeltværdiattribut kunne være fødselsdag eller postnummer. Litteraturens standardeksempel p˚ a en flerværdiet attribut er attributten farve i en bil-entitet. P˚ a 32

©nml


3.2: ER-modellen

et senere tidspunkt, n˚ ar nogle flere modelleringsparametre er diskuteret, skal vi se et praktisk eksempel p˚ a model, og de modelleringsmæssige ændringer, som forekomsten af flerværdiede attributter kan eller bør medføre. Se afsnit 3.2.9.1.

3.2.5

Nøgler

En stor del af nytteværdien ved at registrere entiteter elektronisk hidrører fra, at den enkelte entitets attributter kan findes frem og gøres til genstand for en eller anden behandling, elektronisk eller manuel. Forudsætningen for at en konkret entitet kan findes frem blandt alle de entiteter, der tilhører entitetsklassen, er at entiteten kan identificeres. Der skal minimum være en kombination af attributter, hvis værdier entydigt identificerer netop denne entitet frem for nogen anden i klassen. Den eller de kombinationer af attributter kaldes en supernøgle. En kandidatnøgle er nu en hvilken som helst supernøgle om hvilken det gælder, at ingen ægte delmængde af den ogs˚ a er en supernøgle. Med andre ord: en kandidatnøgle er en minimal supernøgle, en supernøgle uden overflødige felter. Det er nu designerens opgave blandt kandidaterne at udvælge den, som vi primært vil bruge til identifikation. Denne udvalgte kaldes en primærnøgle. De resterende kandidatnøgler kan herefter kaldes alternativnøgler. I ER-modellen anføres primærnøglen understreget. Chen (1976) skriver, at hvis man ikke kan finde oplagt egnet nøgle blandt en entitets attributter, kan man definere en attribut til entiteten s˚ a man ad den vej opn˚ ar entydighed. I litteraturen støder man ogs˚ a p˚ a de mere uofficielt beskrivende begreber som nøgleattribut om en attribut, der indg˚ ar i en nøgle, og sammensat nøgle om en nøgle med flere nøgleattributter. Da en relation som nævnt identificeres af de indg˚ aende entiteter, i figur 3.6 identificeres den konkrete relation af relationsklassen deltager i af primærnøglerne fra entiteterne lærer og udviklingsprojekt. Chen (1976) gør eksplicit opmærksom p˚ a, at disse identificerende primærnøgler ikke er attributter i relationen, hvis eneste attribut s˚ aledes er deltagelsesbrøken. Denne opfattelse er uomtvistelig p˚ a det semantiske niveau, men vil sikkert være en “vanskelig” abstraktion for en læser, der er interesseret i, hvordan dette implementeres. Her m˚ a der imidlertid henvises til at vi senere, n˚ ar dette implementeres i den relationelle model, løser dette problem ved at tilføje de deltagende entiteters primærnøgler til relationen, men at dette sker p˚ a ANSI/SPARC-modellens konceptuelle niveau, et lavere abstraktionsniveau. Jævnfør figur 3.2.

3.2.6

Entiteter og Relationer set indefra

Vi har i forrige afsnit set attributter defineret som værdier der opfylder nogle regler for det domæne de tilhører. Vi har ogs˚ a set at b˚ ade entiteter og relationer kan indeholde attributter. Da vi samtidigt kun hidtil har defineret entiteter meget løst, som noget vi er interesseret i at vide noget om, og relationer i kraft af deres ydre, nemlig som associationer mellem entiteter, er det p˚ a tide at definere entiteter og relationer indefra. Da de begge indeholder attributter er deres indre ens. Lad os kalde dem X for ikke at vælge side: X = {[x1 , x2 , ... , xn ] |x1 ∈ V1 , x2 ∈ V2 , ... , xn ∈ Vn } Hvor [x1 , x2 , ... , xn ]er entitetens eller relationens attributter. En entitet og en relation er s˚ aledes defineret som et antal attributter, der tilhører hver sin værdimængde. Vi skal senere se, at dette netop er definitionen p˚ a en relation i den relationelle models forstand. Vi kan derfor allerede nu konkludere, at i den relationelle model blive b˚ ade entiteter og relationships til relationer i den relationelle model. Dette er interessant og nyttigt at vide, n˚ ar vi har en færdig ER-model. ©nml

33


Kapitel 3: Semantisk datamodellering

3.2.7

Kardinalitet

Udover entiteter, relationer og attributter har ER-modellen yderligere to vigtige modelparametre, der specificerer vigtige egenskaber ved den modellerede virkelighed. Det drejer sig om henholdsvis kardinalitet og deltagelsestype. Begge er udsagn om relationer. Lad os først se p˚ a kardinaliteten. Kardinalitet har noget med tal at gøre. Mængdetallene hedder p˚ a engelsk cardinal numbers.

Figur 3.8: Kardinalitetangivelser i et ER-diagram. Lad os tage udgangspunkt i figur 3.3, der neutralt beskriver at studerende i vores model g˚ ar i klasser. For yderligere nuancering af dette har vi nogle beskrivelsesmuligheder i diagrammet, se figur 3.8. Hvis vi forestiller os, at en afdeling har en (1) leder, og at en leder leder en (1) afdeling, s˚ a anføres det i figuren som beskrevet under a). Der er tilføjet to 1-tal ved diagrammets relationsfigur. Mere verbalt kunne det udtrykkes som værende en 1:1-relation. Er den virkelighed vores model skal afspejle, at en studerende g˚ ar i en (1) klasse, og at en klasse har et antal studerende, s˚ a kan det gøres som i figurens eksempel b). Vi siger at klasse-studerende er en 1:N-relation. I diagrammet anføres disse angivelser, 1:N eller N:1 som egenskaber ved relationen, ved at anføre betegnelser som 1 og N ved siden af den relevante relation. En studerende kan være medlem af en gruppe med henblik p˚ a projektarbejde. Den studerende kan oven i købet, m˚ aske samtidigt, være medlem af et antal grupper. Samtidig best˚ ar en gruppe af et antal studerende. Dette kaldes en mange-til-mange relation. I modellen anføres dette som N:M, der p˚ aføres diagrammet. Værdier for mange (N eller M) opfylder betingelsen N = {n|0 ≤ n ≤ ∞}.

3.2.8

Deltagelsestype

Den anden væsentlige modelparameter omkring relationer er deltagelsestypen. Vi er interesserede i at vide, hvordan en given entitet indg˚ ar i en relation. En studerende g˚ ar i en klasse, figur 3.9 a). Mere korrekt skulle man fortolke diagrammets del a) s˚ aledes at en studerende kan g˚ a i en klasse, og at en klasse kan best˚ a af flere, mange studerende. Man kunne skærpe formuleringen og sige, at en studerende skal g˚ a i en klasse. I vores model vil dette betyde, at der er krav om at alle studerende indg˚ ar i relationen g˚ ar i. Vi kalder i modellen dette for total eller tvungen deltagelse. Tvungen deltagelse anføres i diagrammet ved at associationen tegnes som en dobbeltstreg. Figurens eksempel b) viser dette. Omvendt kan man diskutere, om en klasse skal have studerende. Svaret hertil er tilsyneladende umiddelbart ja. En klasse kan dog p˚ a et givet tidspunkt komme ud for, at der ikke er studerende. Der kan have været det tidligere. Højt frafald. Der kan komme studerende senere. Klassen er netop oprettet, men der er endnu ingen studerende i den. Principielt kan man 34

©nml


3.2: ER-modellen

s˚ aledes have entiteter, der i øjeblikket ikke indg˚ ar i en relation. Dette kaldes i modellen for partiel eller frivillig deltagelse. Frivillig deltagelse anføres i diagrammet som en enkeltstreg. Indirekte ser vi s˚ aledes her en bekræftelse af, at p˚ a N-siden af en relation med partiel deltagelse kan N antage værdien 0. Diagrammets eksempel c) viser den semantik, der ligger i, at en klasse ikke kan eksistere uden at den har studerende. Den tvungne deltagelse ligger her p˚ a 1-siden.

Figur 3.9: Diagrammer med deltagelsestyper. Til spørgsm˚ alet om hvorvidt en relation kan have tvungen deltagelse til alle sine associerede entiteter, er svaret, at det rent teoretisk ikke kan lade sig gøre, idet de deltagende entiteter s˚ a forudsætter hinandens eksistens. I praksis kan et computersystem dog opn˚ a en quasi-samtidighed, der medfører, at en klasse kunne oprettes samtidig med sin første studerende og derfor passe til afbildningen. Det er derfor vigtigt at erindre sig, at vi netop er i færd med semantisk datamodellering, en beskrivelse af en uteoretisk virkelighedsnær situation. Figurens eksempel d er s˚ aledes alligevel tilladt, idet vi kan have en regel om at alle studerende skal g˚ a i en klasse og at alle klasser har studerende i den praktiske virkelighed, der her modelleres. Den praktiske “hvem kom først hønen eller ægget”-problemstilling løses ved hjælp af en mekanisme kaldet transaktioner, som en programmeret, tilnærmet samtidighed under implementeringen af det modellerede system. Man ser ofte diagrameksempler, hvor der hverken er anført kardinalitet eller deltagelsestype. Her vil man tegne alle associationer som enkeltstreger og selvfølgelig uden kardinalitetsangivelser. S˚ adanne diagrammer er ikke “ulovlige”, men oftest blot udtryk for overordnede sammenhænge, der skal illustrere uden at g˚ a i detaljer. 3.2.8.1

Forekomstdiagrammer

Af og til har man brug for visuelt, overordnet at illustrere forhold omkring forekomster. Hertil kan bruges Venn-diagrammer med indtegnede entiteter. I figur 3.10 er de gr˚ a ovaler illustration af nogle entitets- henholdsvis relations-klasser. I hver oval figur er antydet nogle forekomster. det kan gøres ganske uformelt ved blot at anføre fx. nogle nøgleværdier eller lignende. Forekomstdiagrammerne er et hjælpemiddel, der har sin oprindelse i mængdelæren. Det kan være særdeles nyttigt til klargøring af en problemstilling. I figurens eksempel a) fremg˚ ar det af forekomstdiagrammet at b˚ ade entitetsklassen studerende og klasse har partiel deltagelse i relationsklassen g˚ ar i. Der ses b˚ ade en studerende, S9 og en klasse, K2, der ikke deltager i g˚ ar i-relationer. Modsætningsvis ses i eksempel b) at alle ©nml

35


Kapitel 3: Semantisk datamodellering

Figur 3.10: To ER-diagrammer med hver sit Venn-diagram til illustration af forekomster.

36

Šnml


3.2: ER-modellen

studerende deltager i g˚ ar i-forekomster. Dette er ikke nok til at kunne sige med sikkerhed, at studerende har total deltagelse. Forekomstdiagrammet kan højst antyde, at dette kunne være tilfældet. I entitetsklassen klasse, kan forekomsterne derimod entydigt bekræfte, at entitetsklassen har partiel deltagelse. Der eksisterer mindst en forekomst, der ikke deltager i relationsklassen. En alternativ m˚ ade at illustrere forekomster p˚ a vil være som i kapitel 1, tabel 1.1. Tabellerne bruges, hvis man har brug for en mere detaljeret visualisering.

3.2.9

Svage entiteter

Se nu p˚ a figur 3.11, hvor nogle entiteter og relationer er tegnede med dobbeltstreger. Dette symbol henviser til svage entiteter. En svag entitet er en entitet, der ikke har nogen eksistensberettigelse i sig selv, men som supplerer med data om en entitet, der allerede findes.

Figur 3.11: Eksempel p˚ a diagrammering af svag entitet. I diagrammet kan vi se kontaktadresse som et eksempel herp˚ a. Det er muligt, at en studerende er registreret med attributter som fx. Id, gade, telefonnummer og og postnummer, men i vore dage har vi jo mobiltelefonnummer, telefon p˚ a arbejde, telefon i sommerhuset etc. Da ikke alle studerende har alle disse ekstra telefonnumre, vil vi nødigt have s˚ adanne attributter i hovedentiteten, idet de jo s˚ a i mange tilfælde ikke ville have meningsfyldt indhold. De ville være null. For at modellere disse informationer alligevel indfører man en ekstra entitet til opbevaring heraf. En svag entitet vil kun blive oprettet, hvis der er behov for den. En studerendes kontaktadresse er svag, fordi den er uinteressant og skal slettes, hvis vi ikke længere har netop denne studerende. Man siger, at den svage entitet er svag overfor sin eksistentielle forudsætning. Den relation der associerer en entitet med en svag entitet kaldes en identificerende relation. Den tegnes ogs˚ a med dobbeltstreger. En svag entitet har altid total deltagelse i den identificerende relation. 3.2.9.1

Flerværdiede attributter

Vi har tidligere nævnt flerværdiede attributter, som et eksempel p˚ a attributter i en entitet. Man vil normalt anse flerværdiede attributter for at være et udtryk for en lidt unuanceret modellering, men det kan af og til vise sig, at en attribut, hidtil anset for at være normal, ved nærmere analyse viser sig at være flerværdiet. Disse attributter kan indeholde et antal værdier, ingen, en eller flere. Ingen værdier kan sammenlignes med diskussionen umiddelbart herover om svage entiteter. P˚ a grund af risikoen for nulls kan vi ikke lide disse attributter. Samtidig ved vi ikke konkret hvor mange attributværdier, der højst kan forekomme, og dermed giver de yderligere usikkerhedsmomenter. Se nu p˚ a eksemplet i figur 3.12. ©nml

37


Kapitel 3: Semantisk datamodellering

Figur 3.12: Ommodellering af flerværdiet attribut. Fra a) til b). I eksemplet er vist en modelleret entitet, Medarbejder, med en flerværdiet attribut Uddannelse, hvoraf medarbejderen kan have ingen, en eller flere. I afsnittet om svage entiteter s˚ a vi eksemplet p˚ a en studerende, der kunne have ingen, en eller flere kontaktadresser. Vi vælger derfor som generel løsningsstrategi, n˚ ar vi støder p˚ a flerværdiede attributter, at oprette en svag entitet med den p˚ agældende attribut.

3.2.10

ER-model i diagramform, et eksempel

Diagrammet i figur 3.13 indeholder en realistisk model af et bibliotek. Det tilsigter ikke at være komplet i forhold til et virkeligt bibliotekssystem, ligesom det ikke tilsigter at være et komplet ER-eksempel. Det indeholder eksempler p˚ a de modelkonstruktioner, der netop er diskuteret i teksten herover, og skal illustrere hvordan de simple komponenter bygges sammen til mere komplekse modeller. Det overlades til læseren at analysere diagrammets indhold nærmere.

3.2.11

Relationer - genbesøgt

I diagrammet figur 3.5 fra afsnit 3.2.3 er vist en række eksempler p˚ a relationer af forskellige grader. Den efterfølgende række af mere konkrete eksempler, har været med binære relationer. Man kan med en vis ret spørge sig, om det afspejler realiteternes verden. I praksis vil vi finde, at langt de fleste relationer netop er binære, og vi vælger derfor oftest af diskutere ud fra netop dem. Der er dog jævnligt eksempler p˚ a b˚ ade unære og n-ære relationer, s˚ a derfor vil vi diskutere disse nu med den viden om kardinalitet og deltagelsestype, der er opn˚ aet p˚ a dette tidspunkt. Samtidig er der der nogle specialtilfælde af anvendelse af relationer, som ikke har været berørt hidtil. Nogle af disse vil ogs˚ a blive diskuteret her. Lad os tage udgangspunkt i modellen afbildet i figur 3.14. Figuren viser en lidt mere kompleks model vedrørende medarbejdere i en virksomheds afdelinger. En afdeling kan have medarbejdere, mens en medarbejder skal arbejde i en afdeling. P˚ a samme tid er der yderligere en relation mellem de samme to entiteter. En afdeling skal ledes af en medarbejder, mens en medarbejder kan være leder for en afdeling. Det er en væsentlig pointe, at har man brug for flere relationer mellem to entitetsklasser, s˚ a 38

©nml


3.2: ER-modellen

Figur 3.13: Model af en del af et bibliotekssystem.

Figur 3.14: Eksempel med unĂŚre relationer og flere relationer mellem samme entiteter.

Šnml

39


Kapitel 3: Semantisk datamodellering

opretter man dem. 3.2.11.1

Unære 1:1-relationer

En unær relation er en relation, der kun involverer en enkelt entitetsklasse. Det betyder i praksis at en forekomst i denne klasse vil relatere til en anden forekomst i samme klasse. I diagrammet (figur 3.14) ser vi at medarbejder indg˚ ar i to unære relationer. En medarbejder er leder for et antal medarbejdere. En medarbejder er modsat ledet af en medarbejder. Det kan være nyttigt at anføre roller p˚ a relationsstregerne i diagrammet som en tydeligere semantisk information. Nytteværdien viser sig især ved en kardinalitet p˚ a 1:N. En medarbejder kan være coach for højst en kollega, mens en medarbejder kan blive coachet af en kollega. rollerne er som eksempel ogs˚ a her anført i diagrammet, men da kardinaliteten er 1:1, tilfører rolleangivelsen ikke rigtigt nogen ekstra information om relationens betydning, hvorfor den med fordel kunne fjernes igen. Ser vi herefter p˚ a unære 1:1-relationer med varierende deltagelsestype viser de fire diagrameksempler i figur 3.15 de fire tænkelige variationer. I a) har vi nogle dansere, der hver især m˚ aske indg˚ ar i et dansepar. Der er partiel deltagelse p˚ a begge sider af relationen. I de øvrige eksempler er der varierende grad af deltagelse for de to sider af relationen. Ved overvejelse af semantikken vil de fleste nok være enige om, at eksempel c) er semantisk identisk med eksempel b). Dette er en følge af at relationen er unær og har kardinaliteten 1:1.

Figur 3.15: Unære 1:1-relationer. Det overlades nu læseren at overveje, om der er semantisk forskel p˚ a eksempel b/c, som vi er enige om er identiske, og eksempel d). Det kan anbefales b˚ ade for en databasedesigners egen og for vedkommendes interessenters skyld at vælge en ensartet diagrammering af denne situation fra diagram til diagram. En verbal beskrivelse vil være nyttig i tillæg til diagrammet. Læseren kan ogs˚ a overveje hvilken situation, der forekommer realistisk i en tilfældig sportsdanserforening, idet vi husker, at modellen skal afspejle den virkelighed, der skal dækkes af 40

©nml


3.2: ER-modellen

det system, som diagrammet er en tidlig del af designet for. Uden at foregribe læserens analyse af de semantiske forskelle mellem eksemplerne b, c og d, kan det overvejes at modellere med en entitet dansepar i stedet for en sportsdanser, hvis modelleringen ikke er som i eksempel a). Det vil sige, at hvis man ikke har andre form˚ al med at fastholde individualiteten af sportsdanserne, sl˚ ar man simpelthen parrene sammen, s˚ a de i stedet for at være to forekomster af samme entitetsklasse bliver en forekomst af en anden entitet, dansepar.

3.2.11.2

Unære 1:N-relationer

Lad os nu diskutere unære 1:N-relationer. Her kunne et eksempel være en sejlsportsbesætning p˚ a en b˚ ad. En s˚ adan besætning best˚ ar af sejlere, der spiller nogle roller p˚ a b˚ aden. Det kunne diagrammeres som i figur 3.16.

Figur 3.16: Unære 1:N-relationer Vi ser ogs˚ a her fire muligheder i systematikken. Eksempel a) viser, at sejlklubben har nogle medlemmer, sejlere, der hver især m˚ aske indg˚ ar i en besætning, og hvis de gør det, har en rolle som enten skipper eller gast p˚ a b˚ aden. Den partielle deltagelse p˚ a begge sider af relationen muliggør, at man kan have delvise besætninger registreret p˚ a et givet tidspunkt. I eksempel b) har en besætning en skipper og m˚ aske nogle gaster. M˚ aske en realistisk mulighed, hvis man vil illustrere, at en skipper vælger sin besætning. Eksempel c) er den modsatte situation. Her kan man have en besætning, men endnu ingen skipper. Formentlig knapt s˚ a realistisk. Den sidste situation, eksempel d) er m˚ aske den, der stemmer mest med den vanlige forestilling om en klub med b˚ ade og besætninger. I klubben skal enhver sejler være medlem af en besætning, enten i rollen som skipper eller som gast. ©nml

41


Kapitel 3: Semantisk datamodellering

3.2.11.3

Ternære og højere relationsgrader

Vi skal først se nogle eksempler p˚ a ternære relationer fra virkelighedens verden. Som tidligere nævnt er de binære relationer lang de mest almindelige, men b˚ ade unære, som vi har set, og ternære findes. I figur 3.17 er vist tre eksempler p˚ a ternære relationer.

Figur 3.17: Eksempler p˚ a ternære relationer. I eksempel a) kan vi forestille os et firma, hvor sælgerne er udstyrede med firmabiler. Alle sælgere har en, og firmaet har ingen biler, der ikke er knyttet til en medarbejder. Kardinaliteterne bestemmes ved at se p˚ a kombinationer af to deltagende entiteter, og derefter spørge, hvor mange af den tredje svarer til den valgte kombination. En medarbejder i en afdeling har præcist en (1) bil. En bil i en afdeling er knyttet til præcist en (1) medarbejder. Ingen andre kan bruge den. En bil/medarbejder-kombination hører til en (1) afdeling. Deltagelsestyperne bestemmes p˚ a samme m˚ ade som vi har set tidligere. Alle biler er knyttede til medarbejdere. Bil har s˚ aledes total deltagelse i har-relationen. Ikke alle medarbejdere har biler og ikke alle afdelinger har det. I det p˚ agældende firma var det jo netop kun salgsafdelingens medarbejdere, og m˚ aske enkelte særligt udvalgte ledere, der fik stillet bil til r˚ adighed. Med andre ord er der partiel deltagelse for afdeling og medarbejder. Vi ser en 1:1:1-relation. Eksempel b) viser en model hvor en virksomhed har en række projekter. Der er leverandører til projekterne, men til et givet projekt leverer en leverandør kun en vare. En leverandør/vare42

©nml


3.2: ER-modellen

kombination kan leveres til et antal forskellige projekter. Belønningen for leverandøren, der kun leverer en vare til et projekt er at projekt/vare-kombinationen kun har denne ene leverandør. Eksemplet illustrerer en 1:1:N-relation, en-en-mange med partiel deltagelse p˚ a alle sider. Det tredje eksempel, c), viser en 1:M:N-relation, en-mange-mange. Vi har et filmproduktionsselskab, der indg˚ ar kontrakter med filmskuespillere til deres film. En skuespiller i en film er knyttet til et produktionsselskab. Produktionsselskabets film har et antal skuespillere, og produktionsselskabet og skuespillerne kan lave aftaler om flere film sammen. Kun film har i denne ternære relation total deltagelse. 3.2.11.4

Er ternære relationer nødvendige?

En del af litteraturen refererer til at en lang række CASE-værktøjer ikke kan modellere med højere relationsgrader en binære, og anviser mulige løsninger med henblik p˚ a at reducere relationsgraden til binær. Hvis den virkelighed, der skal beskrives i modellen, bedst og mest forst˚ aeligt beskrives i en ternær relation, skal man ikke lade sig diktere af et tilfældigt softwareværktøjs mangler. Man modellerer selvfølgelig sin ternære relation, bøjer softwaren eller finder et andet værktøj.

Figur 3.18: Lidt mere detaljeret eksempel p˚ a ternær relation fra en undervisningsinstitution. Til illustration af denne situation leverer Elmasri and Navathe (2003) et godt eksempel. Figur 3.18 viser et eksempel p˚ a en mange-mange-mange-relation (N:M:L) fra en uddannelsesinstitution. Lærere underviser i semestrene i forskellige fag. En lærer kan i et semester undervise i flere fag. Et fag kan i et givet semester læses af flere lærere. En lærer kan undervise i et af sine fag i flere semestre. S˚ aledes kardinaliteterne. Et b˚ ade realistisk og normalt model-fragment fra en uddannelsesinstitution. Ser vi p˚ a denne model isoleret modellerer den smukt den ønske situation i ethvert semester. Der er dog et problem ved fragmentet. Vi kan ikke se om designeren har tænkt p˚ a, at hvis der i et givet semester ikke er en forekomst af en fag/lærer-kombination, s˚ a mister vi information hvilke fag den p˚ agældende lærer kan undervise i. Den ternære relation kræver netop alle tre entiteter for at kunne eksistere. Der findes en løsning til dette. Vi skal dog først i figur 3.19 se eksemplet fra figur 3.18 tegnet som binære relationer. Vi vil nu undersøge om denne kombination giver samme information som den ovenfor viste ternære ©nml

43


Kapitel 3: Semantisk datamodellering

relation. For at tage det sidste først. relationen magter, løser skavanken nævnt ovenfor. Den kan jo netop bevare data om en lærers mulige fag. Læses_i fortæller, at en lærer har undervist i et givet semester, men ikke hvad den p˚ agældende har undervist i.

Figur 3.19: Figur 3.18 tegnet som et net af binære relationer. Slutteligt fortæller relationen udbydes_i om hvilke fag, der udbydes i et givet semester, men ikke noget af hvilken lærer eller hvilke lærere. Vi ser alts˚ a allerede her, at der ikke nødvendigvis er en forbindelse fra lærer til fag i et givet semester med mindre kardinaliteterne er s˚ adan, at magter er en 1:1-relation, dvs. at en lærer magter et fag og et fag kun magtes af den ene lærer. Vi kan s˚ aledes konkludere, at der er situationer, hvor de binære relationer ikke kan afspejle den information, som den ternære relation kan. Netop derfor er det nødvendigt, at designeren til bunds analyserer betydningen, semantikken, af enhver situation og p˚ a det grundlag beslutter hvilken kombination af binære og ternære relationer den ønskede model skal have. I den skitserede situation vil den ideelle situation være en model der ser ud som i figur 3.20. I figurens illustration er angivet en kardinalitet for magter p˚ a N:M som fordrer at den ternære relation ikke bortkastes. Var magter en 1:N-relation ville løsningen være den samme. Læser kan ikke undværes. Det kan derimod de to øvrige binære relationer fra figur 3.19.

3.3

EER-modellen

Vi s˚ a tidligere i afsnittet om svage entiteter, afsnit 3.2.9, et eksempel p˚ a at modellen skal afspejle nogle væsentlige forhold om entiteter i modellen. I tilfældet svage entiteter var problemstillingen at nogle entiteter havde indhold til yderligere attributter og andre ikke. Vi modellerede med svage entiteter for at undg˚ a nulls i et større eller mindre antal forekomster indenfor den p˚ agældende entitetsklasse. Vi skal nu se nogle eksempler p˚ a modelleringsbehov, der ikke umiddelbart er dækket af ER-modellen. Der er derfor p˚ a et senere tidspunkt opst˚ aet udvidelser i ER-modellens leksikon. Inklusive disse udvidelser kaldes modellen Enhanced Entity Relationship Model, der i daglig tale hos nogle bliver til EER-modellen. 44

©nml


3.3: EER-modellen

Figur 3.20: Løsningen er oftest en kombination.

3.3.1

Superklasser, subklasser og nedarvning

Kast et blik p˚ a biblioteksmodellen i figur 3.13. Her findes entiteten l˚ aner. Nu er l˚ anere en slags personer, og havde vi haft en mere komplet model af biblioteket ville vi ogs˚ a have set bibliotekets ansatte, kald dem biblioteksmedarbejdere, som ogs˚ a er personer. Man forestille sig en entitet person, hvoraf nogle er l˚ anere, andre gruppen bibliotekarer, andre er administratorer etc. Hver af disse grupper udgør en delmængde af gruppen personer, og vi vil nu rubricere hver af disse som sin egen entitet som en subklasse under superklassen person. En subklasse er en entitet, som udgør en ægte delmængde af en anden entitet, som derfor kaldes en superklasse. Konstruktionen kaldes ogs˚ a enten en superklasse/subklasserelation eller en klasse/subklasserelation. Man skal m˚ aske her bemærke brugen af ordet relation. Disse konstruktioner er alts˚ a relationer af en særlig type. Af definitionen som en ægte delmængde fremg˚ ar det, at ingen entitet kan være medlem af en subklasse uden ogs˚ a at være medlem af dens superklasse. Den omvendte restriktion eksisterer derimod ikke. Et entitet, der er medlem af en superklasse, behøver ikke nødvendigvis at være medlem af en af dens subklasser. Entiteter er jo definerede i kraft af deres egenskaber og de relationer, hvori de indg˚ ar, deres type. Man kan s˚ aledes sige, at en biblioteksmedarbejder er en person. En l˚ aner er en person. Begrebet er en, p˚ a engelsk fagsprog IS-A, eller blot ISA, bruges ofte i litteraturen som den faglige betegnelse for subklassen i forhold til superklassen. Rent tegneteknisk kan den skitserede situation fremstilles som vist i figur 3.21. Udvidelserne til de hidtil brugte elementer i ER-diagrammer er den cirkulære figur, der symboliserer relationen mellem super- og subklasse, samt den U-formede figur p˚ a stregen mellem relation og subklasse. I en færdig model vil man som designer ogs˚ a tage stilling til om en superklasse samtidigt kan tilhøre flere af subklasserne, eller kun være i en af dem. Man ser i diagrammerne ofte anbragt et “d” for disjunkt i det cirkulære symbol, hvis entiteten kun kan være en af grupperne. Alternativt “o” for overlappende. Det bør være indlysende, at der nu er tale om en mulighed for at effektivisere modellen, s˚ aledes at de fælles egenskaber s˚ asom navn, adresse, postnummer, telefonnummer etc. modelleres som attributter p˚ a superklassen, mens de egenskaber, der alene knytter sig til rollen som medlem af en eller flere af subklasserne, kun modelleres som attributter p˚ a den eller de relevante af disse. ©nml

45


Kapitel 3: Semantisk datamodellering

Figur 3.21: EER-diagram med super-/subklasserelation. Da en biblioteksmedarbejder er en person taler man om, at entiteten biblioteksmedarbejder nedarver som type fra person og s˚ aledes ogs˚ a besidder alle de attributter der er tilknyttet person i tillæg til de specielle attributter, der er tilknyttet i kraft af rollen som biblioteksmedarbejder. For fuldstændighedens skyld skal det tilføjes, at figur 3.21 kan ses som en udvidelse eller ændring af modellen i figur 3.13, der s˚ aledes kunne være tegnet som i figur 3.22. Det fremg˚ ar af figuren, at subentiteter kan indg˚ a i relationer p˚ a nøjagtig samme m˚ ade som alle andre entiteter.

3.3.2

Generalisering

Lad os antage, at vi i modelleringen af et bibliotekssystem erkender, at vi har modelleret entitetsklasserne vist i figur 3.23. De har jo en række fællestræk, som er en overvejelse værd. De har attributterne: CPRnr, Fornavn, Efternavn, Adresse, Postnr til fælles. Vi kan derfor vælge at modellere yderligere en entitetsklasse, som vi kunne kalde person. Person indeholder nu netop de fællestræk, og samtidig fjerne disse fra de først definerede entitetsklasser. Denne proces at identificere og isolere fælles attributter i en ny entitetsklasse, hvortil de oprindelig entitetsklasser er subklasser kaldes en generalisering. Det er selvfølgelig en væsentlig pointe, at der bevares en relation mellem den nye entitetsklasse og de oprindelige entitetsklasser. Dette gøres netop ved at lade dem indg˚ a i en super-/subklasserelation. Derved fremhæves netop at biblioteksmedarbejder er en person, og at en l˚ aner er en person.Den s˚ aledes udvidede og mere nøjagtige model ser herefter ud som i figur 3.24. Figuren viser samtidig et eksempel p˚ a, at i den virkelighed, som modellen skal afspejle, er det muligt at tilhøre mere end en subklasse. Der er overlap mellem subklasserne.

3.3.3

Specialisering

I afsnittet om generalisering s˚ a vi, at der p˚ a baggrund af to modellerede entitetsklasser, om hvilke vi havde fælles informationsbehov, dannede sig en mere nuanceret model ved generaliseringen. Analyserer vi nu videre p˚ a den konkrete model, erkender vi snart, at vi med hensyn til biblioteksmedarbejderne har været lidt for upræcise. Der er imidlertid ogs˚ a i den udvidede ER-model hjælp at hente i denne situation, som jo ligner et spejlbillede af generaliseringen. Biblioteksmedarbejderne er ikke s˚ a ensartede som først antaget, og vi indser, at de mere præcist kan inddeles i et antal grupper, fx. bibliotekarer, studentermedhjælpere og m˚ aske ved store biblioteker administratorer og endnu flere. I figur 3.24 ser vi ogs˚ a, at der er modelleret en attribut timeløn, som vedrører de timelønnede studentermedhjælpere og andre attributter, uddannet_˚ ar, speciale og lønskalatrin, som kun vedrører bibliotekarer. Det 46

©nml


3.3: EER-modellen

Figur 3.22: Super-/subklasserelationen kombineret med biblioteksdiagrammet.

Figur 3.23: Kandidater til en generalisering. Šnml

47


Kapitel 3: Semantisk datamodellering

Figur 3.24: Diagram af et eksempel p˚ a en generalisering i bibliotekssystemet.

vil medføre, at vi for enhver forekomst af en bibliotekar i systemet ville have null i attributten timeløn, mens vi modsat i enhver forekomst af en studentermedhjælper ville f˚ a ar, speciale og lønskalatrin. Løsningen er enkel. Vi foretager nulls i attributterne uddannet ˚ en specialisering og opretter to eller flere nye subklasser efter behov til beskrivelse af hver speciel medarbejdertype. Specialisering er den proces, hvorved vi definerer et antal subentiteter, subklasser, i forhold til en allerede modelleret entitet. Denne f˚ ar s˚ a følgelig, som ogs˚ a nævnt ovenfor, betegnelsen superklasse. ade Figur 3.25 viser det aktuelle fragment af biblioteksmodellen efter at der er foretaget b˚ den tidligere nævnte generalisering og derefter en specialisering.

3.3.4

Generalisering og specialisering

For at resumere er generalisering den proces hvorved vi skaber en superklasse med de fælles attributter fra en række allerede modellerede entitetsklasser, der s˚ a blive subklasser til den nye entitetsklasse. Specialisering er den omvendte proces, nemlig den, hvor vi p˚ a baggrund af en allerede modelleret entitetsklasse opdager, at den reelt dækker over flere klasser, som vi s˚ a opretter som subklasser og tildeler de relevante attributter, der fjernes fra superklassen. Ved generalisering undg˚ ar vi uønsket redundans i databasen. Ved specialisering undg˚ ar vi nulls. I b˚ ade generalisering og specialisering er der mulighed for at modellere h˚ andhævelse at flere regler. man vil bemærke at figur 3.25 viser begge typer sammenfald. L˚ aner og biblioteksmedarbejder er overlappende, mens bibliotekar og studentermedhjælper er disjunkte klasser. Med hensyn til deltagelsestype viser modellen kun total deltagelse. En person i dette system skal være l˚ aner og/eller biblioteksmedarbejder, og en biblioteksmedarbejder skal være enten bibliotekar eller studentermedhjælper. Som det tidligere er nævnt er det dog tænkeligt i nogle modeller, at en superklasse ikke tilhører nogen subklasse, hvilket i givet fald ville være partiel deltagelse angivet med en enkeltstreg for den p˚ agældende generalisering eller specialisering. 48

©nml


3.3: EER-modellen

Figur 3.25: Specialiserings-/generaliseringshierarki i en og samme model

Šnml

49


Kapitel 3: Semantisk datamodellering

3.3.5

Relationer af højere grad

Vi s˚ a i afsnit 3.2.11.3, at ternære og andre relationer af højere grad kunne være problematiske. De dækker af og til over semantiske forhold, der kun med besvær kan dækkes af den normale ER-model, mens EER-modellen har nogle muligheder, der kan hjælpe. Lad os et øjeblik vende tilbage til figur 3.20, hvor vi endte med en kombination af en ternær og en binær relation til løsning af et modelleringsproblem. Problemet var at en ternær relation alene ikke ville kunne bevare ønsket information under alle omstændigheder, og samtidig kunne en serie binære relationer ikke rumme den ønskede semantik. EER-modellen tilbyder et alternativ til den nævnte figur. Lad os først reformulere problemstillingen. Vi ønsker en model der kan rumme information om, hvilke fag institutionen udbyder i et givet semester og hvilken lærere, der afholder kurserne. Det resulterede i en ternær relation suppleret med en binær, der skulle bevare data om hvilke fag, der kunne læses af hvilke lærere. Denne information kunne ellers g˚ a tabt. Hvis vi i stedet formulerer det s˚ aledes: Institutionen fag/lærer-kombinationer udbydes i et semester.

Figur 3.26: Ugyldigt modelforsøg. Relationer er mellem entiteter!

Dette ville den ukyndige ER-designer fejlagtigt kunne tegne som vist i figur 3.26. Tegningen er ukorrekt og ikke i overensstemmelse med ER-modellen, hvor relationer forbinder entiteter. Her er forsøgt at relatere en relation og en entitet. Det g˚ ar ikke. EER-modellen tilbyder i stedet en aggregering. En aggregering er netop en opfattelse af en binære relation med sine to deltagende entiteter som et samlet hele. Vi tegner en aggregering som vist i figur3.27, eksempel a). En entitetslignende kasse uden om det aggregerede. Denne aggregering tildeler EER egenskaber som en entitet, og derfor kan vi nu relatere den til semester, og problemet er løst. I forbifarten er det værd at nævne, som figuren ogs˚ a antyder, at deltagelse i en aggregering ikke forhindrer de deltagende entiteter i at indg˚ a i helt traditionelle relationer. Elmasri and Navathe (2003) tilbyder p˚ a dette sted ogs˚ a en traditionel ER-løsning af den samme problemstilling. det kunne tyde p˚ a, at ogs˚ a de har en forkærlighed for den klassiske ER-models enkelhed, hvor det er muligt. Løsningen med en ternær, identificerende relation og en svag entitet, ses i figur 3.27 som eksempel b). Det overlades med sindsro til læseren selv at forsikre sig om, at det semantiske indhold er det ønskede. 50

©nml


3.3: EER-modellen

Figur 3.27: Aggregering, a), et EER-begreb, efterfulgt af et ER-alternativ, b).

Šnml

51


Kapitel 3: Semantisk datamodellering

3.4

Øvelser til kapitel 3

3.4.1

Øvelser i ER-modellen

3.4.1.1

Øvelse

Skitser en model over studerende, deres klasser og fag. Brug gerne eksempeldatabasen fra kapitel 1 som oplæg, men der ønskes flere detaljer! Beslut hvilke entiteter, relationer og attributter, som indg˚ ar i modellen. Tegn diagrammet. Kommenter modellen med de nøgleord der er givet for dagens lektion. 3.4.1.2

Øvelse

Modeller gruppedannelsen i en klasse med henblik p˚ a et gruppeprojektarbejde. Tegn diagrammet og beskriv ogs˚ a overvejelserne med den gældende terminologi. Kan problemet løses p˚ a mere end en m˚ ade? Hvis ja, hvordan? Hvis ikke, hvorfor? 3.4.1.3

Øvelse

Hvilke nøglebegreber arbejder vi med? Hvordan er de indbyrdes sammenhænge mellem disse begreber? 3.4.1.4

Øvelse

Du skal lave en model til en database for et folkeregistersystem, der skal kunne opbevare og vise informationer om mænd og kvinder, deres ægteskaber og deres børn. Systemet skal kunne vise, hvem der var gift ved ˚ arets start, hvem der indgik ægteskab i løbet af ˚ aret og hvem der blev skilt i løbet af ˚ aret. Systemets skal ogs˚ a kunne udskrive en liste over under-18-˚ arige, med angivelse af hvem faren er, og hvem moren er. Det ønskes ogs˚ a angivet om barnet er ”ægte” eller ej. Prøv at overveje hvordan en dato for at afg˚ a ved døden kunne introduceres i modellen uden at medføre nulls i modellen. 3.4.1.5

Øvelse

”En virksomhed ønsker at lave og køre en database over de kurser, som dens medarbejdere kommer p˚ a. Hvert kursus tilbydes med henblik p˚ a at passe til et teknologiomr˚ ade, der anses for at være vigtigt for virksomheden af strategiske ˚ arsager. Hvert teknologiomr˚ ade har en medarbejder udnævnt som leder. Denne leder har ansvaret for omr˚ adets webside, med det form˚ al at informere alle medarbejdere om omr˚ adets situation. De medarbejdere der p˚ a en given dag var p˚ a kursus bestyres af databasen.” Man kunne spørge brugerne om bl. a. følgende: Hvilke medarbejderegenskaber, kursusegenskaber og egenskaber om teknologiomr˚ ader ønskes opbevaret? Skal et teknologiomr˚ ade have en leder? Kan en medarbejder være leder for mere end et teknologiomr˚ ade? Skal et kursus tilhøre et teknologiomr˚ ade ? Kan et kursus tilhøre mere end et teknologiomr˚ ade? Kan en medarbejder tage det samme kursus mere end en gang? Forslag til entiteternes udseende: Medarbejder [id, efternavn, fornavn, titel, løn] Kursus [id, navn, varighed] Teknologiomr˚ ade [id, navn, URI]

Skitser nogle svar til spørgsm˚ alene, tegn ER-diagrammet, der viser svarene. 52

©nml


3.4: Øvelser til kapitel 3

3.4.1.6

Øvelse

Se p˚ a modellen i figur 3.28.

Figur 3.28: Problematisk ER-model. Modellen er problematisk. Find problemerne og foresl˚ a i et nyt ER-diagram en alternativ model, der løser dem. Det kan være en nyttig teknik at skitsere nogle forekomster af entiteter og relationer og se p˚ a forbindelserne mellem dem. Tip: Prøv at besvare spørgsm˚ alet: P˚ a hvilken uddannelse underviser en bestemt lærer, fx. medarbejder M17? 3.4.1.7

Øvelse

Se p˚ a modellen i illustrationen i figur

Figur 3.29: En anden problematisk model. Modellen er problematisk. Find problemerne og foresl˚ a en ændring, der løser dem. Det kan være en nyttig teknik at skitsere nogle forekomster af entiteter og relationer og se p˚ a forbindelserne mellem dem. Tip: Prøv at besvare spørgsm˚ alet: Hvilken uddannelse er den studerende S33 i gang med.

3.4.2 3.4.2.1

Øvelser i EER-modellen Øvelse

I en klasse har hver studerende særlige kvalifikationer indenfor to (2) fagomr˚ ader af Kommunikation, Virksomheden, Design og Interaktion. I skal nu modellere gruppedannelsen omkring projektarbejder i semestret. Der kan køre et antal projekter samtidigt. Man kan kun deltage i projektarbejde indenfor sit specialeomr˚ ade. Man kan kun være et sted ad gangen. N˚ ar et projekt er afsluttet udskrives en liste over gruppemedlemmernes bidrag i timer per særligt kvalifikationsomr˚ ade. Projektregnskabet med timer flyttes derefter over p˚ a et offline-medie og slettes fra databasen. P˚ a et hvilket som helst tidspunkt, før under eller efter afslutningen af projekter, skal der kunne informeres om den enkeltes særlige specialefag. 3.4.2.2

Øvelse

Lav en model af en skoledatabase, der skal have FAG, KLASSE, KLASSETRIN, SEMESTER og LÆRER repræsenterede. Modellen skal kunne muliggøre udtræk af et klasseskema for et givet semester. Der skal kunne laves klasselister og lister over hvilke lærerteams hver klasse har. 3.4.2.3

Øvelse

En sportsklub vil oprette en ny afdeling til dyrkelse af sportsgrenen bandy. Til administration skal registreres medlemmer med information om cprnr, medlemsnummer, navn, adresse, etc. Administrationen skal blandt andet kunne producere medlemslister ©nml

53


Kapitel 3: Semantisk datamodellering

over medlemmer under 25 ˚ ar med henblik p˚ a opn˚ aelse af støttemidler fra kommunens fritidsog kulturforvaltning. Hvert medlem forpligter sig til at hverve to støttemedlemmer, der ikke selv er spillere. Kald dem passive medlemmer. Det skal til enhver tid være klart hvilket medlem, der har hvervet hvilket støttemedlem. Klubben etablerer en udstyrsbank p˚ a baggrund ag en donation. Banken skal kunne udl˚ ane udstyr i form af stave af forskellige længder, dragter af varierende størrelse, hjælme ogs˚ a af mange størrelser samt skøjter af flere fabrikater og størrelser. For hver udstyrselement skal registreres en pris og en dato for indkøbet. Udover ovennævnte liste til støtteform˚ al skal der kunne vises medlemslister. Der skal kunne laves en liste over udl˚ ant udstyr, samt en total liste ovewr bankens udstyr med angivelse af alle data om udstyret. Konstruer en ER-model over de nødvendige dataelementer. Diagrammet skal vise b˚ ade entiteter og relationer, samt attributter for b˚ ade entiteter og relationer. Argumenter for modellen.

54

©nml


Kapitel 4

Den Relationelle Model “If you are going to play the game, you’d better know all the rules.” – Barbara Jordan Den helt overvældende dominerenede model i databaseteorien i dag, og i øvrigt gennem mere end 30 ˚ ar, er den relationelle model, som tænkt og beskrevet af Codd (1970), og i øvrigt raffineret og detaljeret i en lang række artikler i de følgende ˚ ar. N˚ ar denne model introduceres her umiddelbart efter gennemgangen af den semantiske model, ER-modellen, er det vigtigt straks at udrydde en udbredt misforst˚ aelse. Den relationelle model har ikke sit navn fra muligheden for at relatere dataindhold i en tabel med dataindhold i en anden tabel. Misforst˚ aelsen synes udbredt ogs˚ a i IT-kredse, der normalt burde været bedre informerede om eget domæne; men det er og bliver en misforst˚ aelse. Den relationelle model har sit navn fra sit grundlæggende strukturelement, den matematiske relation. Vi kalder ofte i daglig tale dette begreb for en tabel, hvilket der kan være god grund til som vi straks skal se. En relation er et specialtilfælde af en matematisk mængde. En mængde i matematikken er en samling af elementer, hvorom det skal være let at konstatere om et givet enkeltelement er medlem eller om det ikke er medlem af mængden. En relation, som specialtilfælde, er en mængde, hvori alle elementer er unika, hvilket vil sige, at der i en relation ikke findes to (eller flere) ens elementer. Læs mere om den matematiske baggrund hos fx Feil (2003). Det fremg˚ ar indirekte, at n˚ ar medlemmerne af en relation skal være unikke, m˚ a de kunne sammenlignes for at konstatere dette. Heraf følger at medlemmerne alle skal være af samme grad, idet de ellers ikke kunne sammenlignes. Det betyder p˚ a almindeligt dansk, at alle rækker skal være lige lange, hvilket blandt andet medfører at nulls ingen plads har i en relation.

4.1

Verden i følge Date

En af den relationelle teoris bannerførere Date (2000b), som ellers er kendt for en streng formalisme tager et uformelt kig p˚ a den relationelle model idet han skriver, at det blandt andet indebærer: 1. Et strukturelt aspekt idet han skriver: “The data in the database is perceived by the user as tables, and nothing but tables.” 2. Et integritetsaspekt, hvorom han skriver: “Those tables satisfy certain integrity constraints.” 3. Minipulativt aspekt, hvor han skriver: “The operators available to the user for manipulating those tables–e.g. for purposes of data retrieval–are operators that derive tables 55


Kapitel 4: Den Relationelle Model

from tables. Of those operators, three particularly important ones are restrict, project, and join.” Vi bør her erindre os kapitel 2, hvori vi udledte, blandt andet p˚ a baggrund af Tsichritzis and Lochovsky (1982), at en datamodel kunne defineres som: M = Ss + Sc + O Eller i naturligt sprog: En model best˚ ar af en strukturel beskrivelse, en regelbeskrivelse og nogle operatorer alts˚ a nøjagtigt de tre komponenter Date nævner. I sin nyeste bog Date (2005), bevarer han denne yderst nyttige inddeling af beskrivelsen af modellen.

4.2

Definition af struktur

4.2.1

Tupel

Vi skal til illustration af den strukturelle beskrivelse, først se p˚ a Date (2005), som har en præcis beskrivelse af først det strukturelle grundelement tuplen. Definitionen relaterer begrebet til kendte datalogiske grundbegreber: Lad T1 , T2 , ..., Tn (n ≥ 0) være datatypenavne 1 , ikke nødvendigvis alle forskellige. Associer nu med hvert Ti et unikt attributnavn, Ai . Hver type-navn-kombination kaldes en attribut. Associer nu med hver attribut en værdi, vi af typen Ti . Hver attribut-værdi-kombination kaldes en komponent. Mængden af alle komponenter kaldes en tupelværdi, eller kort en tupel over attributterne A1 , A2 , ..., An . Værdien af n kaldes tuplens grad 2 . Mængden af alle n attributter kaldes tuplens hovede. Det er vigtigt at bemærke sig, at den relationelle model, jf. denne tupel-definition, har et væsentligt integritetsskabende element i komponenten, der sikrer sammenhængen mellem type og værdi. I starten af dette kapitel n˚ aede vi som en indirekte slutning frem til at nulls ikke havde plads i den relationelle model. Med ovenst˚ aende definition kan de formelt udelades, idet null ikke tilhører nogen type, og alene af den grund ikke kan optræde i nogen tupel. Lad os illustrere inden det bliver alt for abstrakt, se tabel 4.1.

Attributter (Tuplens hovede) Komponenter

Typer Navne Tupelværdi (Tupel)

T1 A1 v1

T2 A2 v2

... ... ...

Tn An vn

Tabel 4.1: Afbildning af en tupel i overensstemmelse med Dates definition.

4.2.2

Relation

Date definerer relationer s˚ aledes, idet han selvfølgelig bruger den netop viste tupel-definition: Lad {H} være et tupel-hovede og lad t1 , t2 , ..., tm hvor m ≥ 0, være forskellige tupler med hovedet {H}. Kombination r af {H} og mængden af tupler {t1 , t2 , ..., tm } er en relationsværdi, eller kort relation over attributterne A1 , A2 , ..., An , hvor A1 , A2 , ..., An er attributterne i {H}. Relationens hovede er {H}. r har samme attributter (og s˚ aledes ogs˚ a samme attributnavne og datatyper) som hovedet. Kroppen af r er mængden af tupler {t1 , t2 , ..., tm }. Værdien af m er relationens kardinalitet. 1 2

Typer kaldes ogs˚ a ofte i databasesammenhæng for domæner. Jf. Chen (1976). En tupels grad kan være unær, binær, ternær, etc.

56

©nml


4.3: Definition af regler

Definitionen siger det ikke direkte, men relationens grad er de indg˚ aende tuplers grad. Det er væsentligt her, at se opfattelsen af en relation som en relationsværdi, dvs. at se relationen som en variabel, der ligesom alle variabler p˚ a et givet tidspunkt har en værdi. Værdien af denne variabel ændrer sig, n˚ ar en deltagende tupel ændrer sig og n˚ ar relationens kardinalitet ændrer sig ved sletning eller tilføjelse af tupler. Dates definition er illustreret i tabel 4.2. Tupel/Relationshovede tupel 1 tupel 2 ... tupel m

{H} t1 t2 ... tm

A1 v1 v1 v1 v1

A2 v2 v2 v2 v2

... ... ... ... ...

An vn vn vn vn

Tabel 4.2: En relation r med et hovede og en mængde af tupler med samme hovede. Et helt konkret eksempel, r = M edarbejder, ses i tabel 4.3, der indeholder en header {H} = {F ornavn, F dselsdag, ..., Antal prrende}, og et antal tupler, alle med samme header {H}. Medarbejder tupel 1 tupel 2

Fornavn Niels Peter

Fødselsdag 25. Nov. 1945 17. Mar. 1949

... ... ...

Antal p˚ arørende 3 2

Tabel 4.3: En afbildning af en konkret relation Medarbejder. Den matematiske regel, der gør de viste tabeller til relationer er s˚ aledes, at der i definitionen nævnes forskellige tupler, hvilket vil sige, at der i tabellerne ikke findes ens rækker. De viste domæner er Fornavn, Fødselsdag og Antal p˚ arørende. Den til fornavn hørende værdimængde er alle gyldige fornavne, evt. inklusive initialer. Fødselsdage tilhører mængden af alle gyldige fødselsdage, som vel m˚ a tilhøre gyldige datoer, der ligger et antal tilbage i fortiden. Antal p˚ arørende m˚ a formodes at være et heltal I = {i|i ≥ 0}. Læseren vil her spore en vis mangel p˚ a præcision i angivelse af konkrete domæner. Det skyldes selvfølgelig, at eksemplet repræsenterer en afbildning af en model, hvor det er brugeren af modellen, der m˚ a bidrage med præcisionen, for eksempel angivelsen af domænet for fødselsdage, som datoer der altid er mindst 18 ˚ ar tilbage i fortiden. Dette vil afspejle, at den modellerede virksomhed har en regel om at medarbejdere skal være mindst 18 ˚ ar gamle.

4.3

Definition af regler

Den relationelle model har to grundlæggende konsekvenser i form af regler. De er entitetsintegritet og referentiel integritet, Date (2005). Disse to er grundlæggende en del af enhver database, der skabes i modellens billede. Det er en ironisk sidebemærkning at netop Date fremhæver dette s˚ a tydeligt med brug af ER-lignende terminologi, idet han adskillige steder viser en lettere nedladende holdning overfor ER-modellen til semantisk brug.

4.3.1

Nøglebegreber

Modellen bruger ogs˚ a en række nøglebegreber, der finder anvendelse i forbindelse med h˚ andhævelsen af modellens regler. Nøglebegreberne er tidligere gennemg˚ aet i afsnit 3.2.5 i kapitel 3, da de ogs˚ a finder anvendelse i ER-modellen. Vi resumerer her i tabelform: ©nml

57


Kapitel 4: Den Relationelle Model

Supernøgle Kandidatnøgle Primærnøgle Alternativnøgle Fremmednøgle

4.3.2

Den relationelle models nøglebegreber Enhver kombination af en tupels attributter, hvis værdier entydigt kan identificere netop denne tupel. Enhver supernøgle hvoraf ingen ægte delmængde ogs˚ a er en supernøgle. En atomar supernøgle. Den kandidatnøgle, der vælges til normalt at blive brugt til identifikation af tuplen. De kandidatnøgler, der ikke blev udnævnt til primærnøgle. En kombination at attributter, der refererer en primærnøgle i en anden relation.

Entitetsintegritet

Entitetsintegritet betyder, at enhver tupel i en relation skal kunne identificeres entydigt. Det følger af, at den relationelle model bygger p˚ a matematiske relationer, hvor dette er et krav. Det er en omskrivning af, at der skal eksistere (mindst) en kandidatnøgle, og at denne skal indeholde en værdi. Date indser selv det kuriøse i, at formuleringen indirekte medfører, at der kan være ikke-nøgle-attributter uden værdi (null ), men det kan ikke gælde for nøgleattributter. Date siger selv, at den relationelle models fader, Codd, accepterede nulls. Der viser sig s˚ a mange uønskede problemer i kølvandet p˚ a accept af nulls i databaserne, at denne forfatter hælder meget kraftigt til Dates rigoristiske holdning til dem. N˚ ar entitetsintegritet betyder at alle tupler skal være unikke, er det nødvendigt at definere hvad dette betyder. Det gøres omvendt ved at definere tupel-lighed, Date (2005): Tuplerne tj og tj+1 er “lig med hinanden” hvis og kun hvis de har de samme attributter, A1 , A2 , ..., An – med andre ord, de er af samme type 3 –og at det for alle i (i = 1, 2, ..., n) gælder, at vi af Ai i tj er lig med vi af Ai i tj+1 . Det betyder p˚ a lidt mere almindeligt dansk, at to tupler er lig med hinanden, hvis de to tupler har de samme attributter, og at de attribut for attribut har samme værdi.

4.3.3

Referentiel integritet

Referentiel integritet siger noget om den m˚ ade, hvorp˚ a man etablerer referencer mellem en databases forskellige relationer i den relationelle model. Referentiel integritet betyder, at der m˚ a ikke eksistere fremmednøgler, der refererer ikke eksisterende forekomster i den refererede tabel. Man kunne som eksempel forestille sig, at en person-relation havde en attribut postnummer defineret som en fremmednøgle. Referentiel integritet betyder nu, at der ikke i person m˚ atte findes en værdi for postnummer, der ikke findes som nøgle i en forekomst i en postdistrikt-relation.

4.4

Operationer

Som det ogs˚ a blev nævnt i citaterne fra Date (2000b) er operatorerne ikke traditionelle binære regneoperatorer, endsige operatorer, der leverer simple værdier, skalarer, som svar ved brug. De udleder tabeller fra tabeller, som den nøjagtige oversættelse siger. De opfatter tabellerne som den relationelle model originalt har tænkt dem, nemlig som mængder. Som følge deraf er de fundamentale operatorer meget lig dem vi finder i mængdelæren, og de kan i vid udstrækning illustreres p˚ a samme m˚ ade. 3

Det betyder ikke kun, at de er i samme relation, der kan være andre relationer, hvor tuplerne har samme type, struktur.

58

©nml


4.4: Operationer

4.4.1

Algebra

Den relationelle model stiller et antal operatorer og en tildelingsoperator til r˚ adighed. Sidstnævnte muliggør, at resultatet af de manipulative operationer stilles til brugerens disposition. Tildelingen sker altid i form af en relation. Figur 4.1 viser i mængdelærens Venn-diagrammer de fundamentale operationer i algebraen. Da relationer normalt i daglig tale omtales som tabeller er Venn-diagrammets figurer her gjort firkantede, hvor det for de to førstnævnte operationer visuelt er klargjort, at projektion og selektion arbejder p˚ a henholdsvis kolonner og rækker i tabellen. En projektion udtrækker et antal kolonner fra samtlige tupler i en given relation og stiller dem til r˚ adighed for brugeren som en ny relation. Den udtrykkes algebraisk som RR ← πa1 ,a2 ,...,an (R1) hvor R1 er inputrelationen og RR resultatet. En selektion4 udvælger en mere eller mindre begrænset del af relationens totale antal tupler og stiller disse til r˚ adighed som en ny relation. Den tilsvarende algebraiske notation er her RR ← σ<selekteringsbetingelse> (R1) Selekteringsbetingelsen kan fx. være a1 ≥ 117. Operationerne foreningsmængde, fællesmængde og differens arbejder p˚ a to relationer. Fællesmængden stiller i resultatrelationen alle tupler, der forekommer i begge specificerede relationer, til r˚ adighed i en resultatrelation. Kalder vi de indg˚ aende relationer for R1 og R2, samt resultatet for RR udtrykkes det algebraisk som RR ← R1 ∩ R2 Foreningsmængden afleverer i sit resultat alle tupler, der forekommer i enten den ene eller den anden, evt. i begge, af to specificerede relationer. Fællesmængden kan udtrykkes som RR ← R1 ∪ R2 Differens udtager differensmængden fra to relationer til resultatet. Det betyder at den fra en relation udtager alle tupler, der ikke ogs˚ a forekommer i en anden specificeret relation. Algebraisk: RR ← R1 − R2 Ser vi nu videre p˚ a tabel 4.4, har vi her de resterende simple algebraiske operationer PRODUKT, DIVISION og JOIN. Produkt, ogs˚ a kaldet kartesisk produkt efter den gamle matematiker Descartes, udføre det, at den i resultatmængen har enhver forekomst i den ene inputmængde (R1) parret med enhver forekomst i den anden inputmængde (R2). Division afbilder i resultatmængden alle forekomster fra den ene inputmængde, dividenden (R1), som matcher alle forekomster i divisormængden (R2). Join er en operation, der resulterer i en relation, der parrer relaterede tupler fra to inputrelationer i resultatet. Parringen kan foreg˚ a p˚ a en række forskellige m˚ ader. De er implementerede i den relationelle calculus, og vil blive gennemg˚ aet der. Her skal blot fort fortælles, at man normalt udfører join p˚ a en eller flere attributter, der er fælles mellem inputrelationernes tupler. Den hyppigst anvendte join er den hvori, man sammenligner en enkelt attributværdi i en tupel med en tilsvarende attributværdi i en tupel i en anden relation. Matcher de, projiceres de ønskede attributter over i resultatrelationen. Denne type kaldes en equijoin. Da 4

I modellens engelske terminologi en restrict.

©nml

59


Kapitel 4: Den Relationelle Model

Figur 4.1: Den relationelle models algebra.

a)

c)

RR a f R1 R2 a g a f b f b g b g c c f c g (Kartesisk) produkt. RR ← R1 × R2 R1 a1 j1 a2 j2 a3 j3

b)

R1 a f a g a h b f c g

R2 f h

RR a

Division. RR ← R1 ÷ R2

R2 RR j1 b1 a1 j1 b1 j2 b2 a2 j2 b2 j3 b3 a3 j3 b3 (Natural) Join. RR ← R1 ? R2a

Tabel 4.4: Produkt, Division og Join fra den relationelle models algebra. 60

©nml


4.4: Operationer

man normalt i resultatet kun vil se en enkelt projektion af den attribut, har man defineret en variant af join, natural join, der foretager en projektion s˚ a kun attributten fra den ene af de to inputrelationer vises. Den generelle join-operator er ./parm , hvor parm fortæller noget om attributnavn til operationen. Natural join, som jo er en forenkling, bruger en anden operator og behøver ikke nævne attributnavne, da der ikke opst˚ ar tvetydighed. Jf. tabel 4.4. Algebraen er er proceduralt sprog, Date (2000b) kalder det foreskrivende 5 i betydningen, at det angiver for computeren, hvordan den skal gøre for at tilfredsstille programmørens informationsbehov. De fleste kendte programmeringssprog er s˚ adan. En algebraisk forespørgsel kan for eksempel verbalt formuleres s˚ aledes: 1. Udfør en join af tupler fra bog og bogemne p˚ a attributten emnenummer 2. Udvælg dernæst de tupler, hvor pris overstiger 500 DKR 3. Projicer emne, titel og pris ud i et resultat

4.4.2

Beroligelse

Den læser, der allerede nu m˚ atte være bekymret over den relationelle algebras for de fleste lidt uvante notation, kan vi berolige med, at algebraen ikke er implementeret andetsteds end i eksperimentel form i uddannelsesprojekter. Databasesystemerne har med standardiseringen i ryggen valgt at implementere den relationelle models operationer i form af relationel calculus, som vi nu skal se p˚ a.

4.4.3

Calculus

I modsætning til algebraen som den relationelle models procedurale sprog, har vi en anden mulighed, den relationelle calculus der bygger p˚ a den matematiske logik (udsagnslogik med sandhedstabeller og prædikater med variabler). Calculus er et ikke-proceduralt, deklarativt sprog. Date (2000b) kalder det beskrivende 6 i betydningen, at det angiver for computeren hvad programmøren gerne vil se i sit resultat. Computeren, mere præcist, databasesystemet, m˚ a s˚ a finde ud af hvordan det tilvejebringes. Programmet formuleres i en enkelt calculus-sætning. Hvis vi skal prøve at formulere ovenst˚ aende algebra-program som calculus, ville det blive noget i retning af: 1. Hent emne, titel og pris for bøger, hvorom det gælder at der eksisterer en bog og et emne med samme emnenummer, og som har en pris p˚ a mere end 500 DKR. Den generelle formulering af en s˚ adan forespørgsel ser s˚ aledes ud: {t1 .Aj , t2 .Ak , ..., tn .Am | CON D(c1 , c2 , ..., cn , cn+1 , cn+2 , ..., cn+m )} Som i almindeligt naturligt sprog vil være: Hent attribut Aj fra tupel t1 , attribut Ak fra tupel t2 , attribut Am fra tupel tn , hvis de findes at opfylde betingelserne c1 , c2 osv. En betingelse ci kan eksempelvis være udtrykt som ti .A = tj .B, m˚ aske et udtryk for at nøgleværdien i den ene tupel skal være lig med nøgleværdien i den anden tupel. Det kan vises, selvom vi her skal afst˚ a fra det, at algebraen og den relationelle calculus er logisk ækvivalente. Ethvert udtryk i det ene sprog vil kunne udtrykkes i det andet. Det betyder blandt andet, at hvis man vil lave en teoretisk beskrivelse af en problemstilling, har man frit valg mellem de to notationsformer. Det er et spørgsm˚ al om personlig stil, hvad man vil vælge. 5 6

Engelsk: Prescriptive. Engelsk: Descriptive.

©nml

61


Kapitel 4: Den Relationelle Model

Den oprindelige calculus kaldes tuple relational calculus, og burde m˚ aske blot hedde relations-calculus. Der er senere formuleret en alternativ domain relational calculus, hvor variablerne, som er en del af de matematisk-logiske prædikater, varierer over domæner i stedet for tupler. Relations-calculus har dannet teoretisk grundlag for det sprog der, med alle sine teoretiske mangler og uklarheder, i praksis er implementeret i langt de fleste databasesystemer, sproget SQL, Structured Query Language, som vil blive gennemg˚ aet fra kapitel 8.

4.5 4.5.1

Øvelser til kapitel 4 Skab en biblioteksmodel

Vi skal modellere i ER, et bibliotek. I et skolemiljø, hvor studerende skal g˚ a i klasser og hvor lærerne underviser klasser i fag i givne semestre, er b˚ ade lærere og studerende l˚ anere. L˚ anerne skal kunne l˚ ane og reservere bøger. Ved udl˚ an er l˚ aneperioden højst 30 dage, og ved reservation angives en dato, hvorefter bogen ikke længere har interesse. Bøgerne er primært fagbøger, der er organiseret i en række emner, der kan anvendes som søgekriterier. Der skal ogs˚ a kunne søges p˚ a forfattere. Gem besvarelsen til senere brug. Besvarelsen bør indeholde et ER-diagram med skriftlig argumentation for objekternes tilstedeværelse og deres indhold af attributter. Kardinalitet og deltagelsestype skal ligeledes diskuteres. Der ønskes ogs˚ a en diskussion af valg af nøgler for modellens objekter, samt diskussion af fremmednøgler, der er nødvendige for modellens integritet.

62

©nml


Kapitel 5

Normalisering “... the formal principles I’m going to present in this chapter represent the one small piece of science in what is otherwise a mostly artistic endeavor.” – Chris Date (om Database Design Theory i Date (2005).) Den relationelle model indeholder nogle retningslinjer til sikring af hvad man kunne kalde godt design for en given database. N˚ ar processen med overgang fra ER-modellen til den relationelle model er gennemført, er det vigtigt, at have nogle objektive regler, hvormed det resulterende design kan efterprøves. I sin oprindelige beskrivelse af den relationelle model skriver Codd (1970), at relationer skal være normaliserede. Hermed mente han blot, at data skulle være definerede som tilhørende domæner best˚ aende af atomare (udelelige) værdier. Denne oprindelige betydning af normaliseret svarer til, hvad vi i dag kender som første normalform (1NF), som vi diskuterer senere i dette kapitel. Codd bruger denne betydning af normalisering som en del af argumentationen for at relationer overhovedet kan afbildes i tabeller, og som baggrund for at det er muligt at definere en første ordens calculus, hvilket vil sige en calculus, hvormed vi kan behandle enkelte tupler1 fra relationer i modsætning til at behandle hele relationer, jf. Date (2000a). Det er heller ikke muligt i den relationelle model, at forestille sig nøgleværdier, der ikke er atomare. Generelt kan det derfor siges, at en væsentlig del af den relationelle model beror p˚ a, at det er muligt at sikre sig nøgleværdier, der muliggør, at hver forekomst i en relation er unik. Heraf følger, at vi er nødt til at interessere os detaljeret for, hvordan de enkelte attributter i en relation er knyttet til hinanden, men især til nøglefelterne. Disse indbyrdes relationer mellem attributter kaldes funktionelle afhængigheder.

5.1

Funktionel Afhængighed

Først ˚ aret efter sin oprindelige artikel kommer Codd (1971) eksplicit ind p˚ a begrebet funktionel afhængighed. Herunder anvender han afhængighedsdiagrammer og den notation vi i dag bruger til beskrivelse af disse afhængigheder. Funktionel afhængighed, X → Y , der udtales Y er funktionelt afhængig af X, eller X medfører 2 Y, betyder, at for et hvilket som helst tupel-par, hvorom det gælder at de har samme X-værdi, tn [X] = tm [X], vil det ogs˚ a gælde, at de har samme Y-værdi, tn [Y ] = tm [Y ]. I eksempelform kan vi sige, at hvis stilling er funktionelt afhængig af personnavn, og Larsen optræder i en relation som lektor, s˚ a kan den samme Larsen ikke et andet sted i samme relation optræde som inspektør. 1 2

Senere realiseret som SELECT-instruksens WHERE-specifikation i SQL. Ordet bruges som et forsøg p˚ a at finde en mere mundret fordanskning end ’X er determinant for Y’. Begrebet determinant bruges, som vi snart skal se, i definitionen af Boyce-Codd Normal Form.

63


Kapitel 5: Normalisering

Det skal bemærkes, at funktionel afhængighed er et udsagn om et relationsskema, dvs. om en konkret relation, og ikke om relationens værdi p˚ a et givet tidspunkt. Dette betyder, at man ikke ved at betragte forekomsterne i en tabel kan sige med sikkerhed om en funktionel afhængighed er sand. Derimod kan det muligvis ud fra forekomsterne sluttes, at den er falsk.

5.1.1

Funktionel afhængighed eller fuld funktionel afhængighed

Begrebet afhængighed bruges her lidt anderledes end det bruges i almindelig daglig sprogbrug. Her kommer et eksempel, der skal tjene til klargøring af begrebet. Lad os antage, at i et eller andet system har man brug for at opbevare en information om kendingsbogstaver p˚ a biler. Kendingsbogstaver er nationale, hvilket betyder, at de varierer fra land til land, ikke fra landsdel til landsdel. Heraf følger selvfølgelig, at et forslag til en relation som: REGION: [Land, Provins, Kendingsbogstaver, Telefonomr˚ adenummer, ...]

ville være et udtryk for d˚ arligt design. Tabelskitsen antyder, at der for kendingsbogstaver er en funktionel afhængighed af land og provins, alts˚ a ikke af land alene. Den ville medføre at kendingsbogstaverne ville blive opbevaret igen og igen som redundante data. En gang for hver provins i et land. I stedet burde man vælge: REGION: [Land, Provins, Telefonomr˚ adenummer, ...] LAND: [Land, Kendingsbogstaver, ...]

et design med telefonomr˚ adenumre for hver provins, men nationale kendingsbogstaver til biler. Vi placerer kendingsbogstaverne i netop denne relation, fordi de er fuldt funktionelt afhængige af attributten land. De er associeret til land, og de kunne eventuelt udgøre en egnet kandidatnøgle i relationen land. Disse funktionelle afhængigheder ses ofte beskrevet s˚ aledes: {Land, P rovins} → T elef onomrdenr, ... for REGIONs vedkommende og Land → Kendingsbogstaver, ... for LANDs vedkommende. Andre steder finder man det grafisk fremstillet som i figur 5.1. I denne figur er situation a) afbildet som REGION før vi delte den i to. Eksempel b) viser afhængighederne efter delingen, som netop beskrevet. Valget af illustrationsform for funktionelle afhængigheder er en smagssag. Vælger vi den grafiske kan man sige, som vi skal se i dette kapitel, at pilene, der markerer en afhængighed, bør udg˚ a fra nøglefelterne, alle nøglefelterne og intet andet end nøglefelterne. P˚ astanden er en forenkling, men ligger tæt p˚ a sandheden. Lad os resumere og sige, at begrebet fuld funktionel afhængighed defineres som en attributs afhængighed af en hel kandidatnøgle. Vi siger ogs˚ a at kandidatnøglen er determinant for ikkenøgle-attributten. Funktionel afhængighed betyder herefter, at der er en afhængighed af en kandidatnøgle, men ikke nødvendigvis af hele kandidatnøglen.

5.2

Kvalitetskrav til databasen

Et objektivt kvalitetskrav er det, at et objekt er det, som det udgiver sig for at være. Objektet database giver sig ud for at være et prædikat om det, som databasen handler om. I den matematiske logik kan man, n˚ ar man kender værdien af de variabler, som et prædikat indebærer, afgøre om prædikatet er sandt eller falsk. Allerede i afsnit 1.4.2 i kapitel 1 s˚ a vi p˚ a problemerne omkring for mange data og for f˚ a. Redundans og nulls er eksempler p˚ a at en database f˚ ar svært ved at leve op til kravet om at 64

©nml


5.3: Første Normalform

Figur 5.1: Funktionelle afhængigheder i diagramform. Vedrører REGION og LAND. være et prædikat. Vi har netop herover set, at funktionelle afhængigheder spiller en rolle for om redundans kan opst˚ a i en database. Med henblik p˚ a at kunne vurdere en databases kvalitet gennemfører vi derfor en proces, normalisering, for at kontrollere hver enkelt relationsskema for overholdelse af de objektive krav. Normaliseringen er en proces, der underkaster relationerne en række prøver af stigende sværhedsgrad. Lever en relation op til kravet stillet i definitionen af 1. normalform, 1NF, udsættes den derefter for kravene definerede i 2. normalform, 2NF, etc. Der er defineret fem normalformer nummereret fra 1 til 5. P˚ a et tidspunkt ville Codd redefinere 3NF for at skabe mere klarhed. I den nye definition opstod en normalform, som ved nærmere undersøgelse viste sig at være en lidt sværere prøve at leve op til end den oprindelige 3NF. Derved opstod s˚ a Boyce-Codd normalformen. Codd arbejde sammen med Boyce om formuleringen. BCNF, som den ogs˚ a kaldes, er alts˚ a i sværhedsgrad rubriceret mellem 3NF og 4NF. Elmasri and Navathe (2003) skriver et sted at godt design betyder, at alle relationer i en database skal leve op til mindst 3NF. Man bør stramme dette kvalitetskriterium til at sætte grænsen ved BCNF. Vi skal nedenfor se hvorfor. Langt de fleste relationer, der opfylder dette krav, vil p˚ a grund af deres struktur automatisk leve op til b˚ ade 4NF og 5NF.

5.3

Første Normalform

5.3.1

En definition

Der findes ingen 0NF. Det betyder, at relationer, der ikke opfylder 1NF, kaldes unormaliserede. Codd (1970) taler om normaliserede relationer i ubestemt form, blot de opfylder det fundamentale krav, at er defineret p˚ a domæner, hvis elementer er atomare, dvs. at de ikke kan opdeles yderligere. Man ser ofte kravet om en nøgle som en del af definitionen p˚ a første normalform. Dette m˚ a anses for en misforst˚ aelse, da normaliseringsteorien er bygget op omkring de funktionelle afhængigheder og derfor forudsætter kandidatnøgler i relationer. Første normalform er i øvrigt den eneste, som Codd havde med fra starten. De øvrige er alle kommet til senere. Codds definition p˚ a første normalform er s˚ aledes: En relation, som er defineret over domæner, hvis elementer er atomare, dvs. udelelige, siges at være normaliseret. ˚ Aret efter i Codd (1971), som i øvrigt beskæftiger sig med yderligere normalisering, hedder det, næsten skjult i et appendiks: ©nml

65


Kapitel 5: Normalisering

En relation er p˚ a første normalform, hvis ingen af dens domæner har elementer, der i sig selv er mængder. og En unormaliseret relation er en relation, der ikke er p˚ a første normalform.

5.3.2

Et problematisk eksempel

Lad os se et eksempel p˚ a et relationsudkast med flere problemstillinger. De understregede felter udgør en kandidatnøgle. FAKTURA: [Fakturanr,Kundenr,Dato,Navn,Gade,Postnr,By,Fakturalinier]

Hvor en fakturalinje kunne best˚ a af et varenummer, varenavn, et antal og en pris per enhed. Forekomsterne i FAKTURA kunne p˚ a et givet tidspunkt være som i tabel 5.1. FAKTURA Fnr

Knr

Dato

Navn

Gade

Postnr

By

Vnr1

Vnvn1

Antal1

Pris1

Vnr2

Vnvn2

Antal2

Pris2

1001

17

3/8/2005

Asen

Aagade

8033

Aaby

901

Kabel

1

59.95

<null>

<null>

<null>

<null>

1002

18

3/8/2005

Bsen

Boulevarden

8043

BCity

901

Kabel

2

52.00

902

USB1x

1

91.25

1003

21

3/8/2005

Csen

C-vej

8053

City

901

Kabel

1

59.95

903

USB2x

4

118.00

1009

17

4/8/2005

Aser

Aagade

8033

Aaby

903

USB2x

1

118,00

<null>

<null>

<null>

<null>

1021

17

5/8/2005

Asen

Aagade

8033

Aaby

902

USB1x

1

91.25

<null>

<null>

<null>

<null>

...

...

Tabel 5.1: Eksempel p˚ a forekomster

5.3.3

Repeterende gruppe

Vi kan analysere de viste forekomster og konstatere nogle problemer. For det første er de fem viste forekomster ikke lige lange. Det er rimeligt at antage, at ikke alle fakturaer indeholder lige mange fakturalinjer. N˚ ar vi skal specificere en relation som en tabel, er vi tvunget til at gøre en antagelse om tabellens bredde, idet attributterne skal navngives individuelt. Afsættes plads til tre fakturalinjer vil det af og til passe med virkeligheden, men lige s˚ a ofte omfatter en faktura kun en eller to fakturalinjer, og i atter andre tilfælde vil der være behov for fire eller flere. Dette vil give anledning til at der i nogle tilfælde vil være for f˚ a data i forhold til specifikationen, og hvad skal vi s˚ a stille op med de uudfyldte attributter? I andre tilfælde vil vi være nødt til at fakturere en kundes varekøb over et antal fakturaer, hvilket forekommer uhensigtsmæssigt. Vi kunne oven i købet blive nødt til at overveje kandidatnøglens udseende, for at undg˚ a dubletter, hvis der skal faktureres ad flere gange p˚ a en enkelt dato. Disse var praktiske overvejelser, men der er ogs˚ a teoretiske. Tabelskitsen lever ikke op til definitionen p˚ a en relation, En attribut tilhører et domæne, der indebærer en datatype. En uudfyldt attribut afspejler, at der ikke er nogen værdi, hvilket jo ikke kan være af nogen datatype. Med andre ord en manglende attribut, en modstrid i forhold til definitionen p˚ a en relation, der netop kræver at alle tupler er af samme grad. Se kapitel 4. SQL ˚ abner mulighed for null s i databasen p˚ a steder, hvor vi ikke kender værdier eller steder hvor der ingen værdier er, men vi ser alts˚ a allerede her, at disse ingen plads har i den relationelle model. 66

©nml


5.4: Anden Normalform

5.3.4

Problemets løsning - Paco’s princip

Problemer i forhold til normaliseringsreglerne løses efter et ensartet princip uanset hvilket normalform, der for˚ arsager problemet. Løsningen best˚ ar s˚ aledes altid i, at vi deler den tvivlsomme relation i to relationer p˚ a en s˚ adan m˚ ade, at der ikke forekommer informationstab ved delingen. P˚ a baggrund af en særligt vellykket undervisningssituation vil vi fremover vælge, sprogligt elegant, at kalden denne løsningsmetode for Paco’s princip. Lad os gennemføre delingen i forhold til det viste eksempel. Vi startede med FAKTURA: [Fakturanr,Kundenr,Dato,Navn,Gade,Postnr,By,Fakturalinier]

Da problemet opstod omkring fakturalinjerne, m˚ a vi have disse isoleret i en relation for sig. For at undg˚ a informationstab er denne ny relation selvfølgelig nødt til at inkludere de nøglefelter, der er nødvendige for at referere fakturalinjerne til en bestemt faktura. Efter delingen kunne de resulterende relationer være FAKTURA: [Fakturanr,Kundenr,Dato,Navn,Gade,Postnr,By] FAKTURALINIE: [Fakturanr,Kundenr,Løbenr,Varenr,Varenavn,Antal,Pris] FAKTURA Navn Gade

Fnr

Knr

Dato

Postnr

By

1001

17

3/8/2005

Asen

Aagade

8033

Aaby

1002

18

3/8/2005

Bsen

Boulevarden

8043

BCity

1003

21

3/8/2005

Csen

C-vej

8053

City

1009

17

4/8/2005

Aser

Aagade

8033

Aaby

1021

17

5/8/2005

Asen

Aagade

8033

Aaby

... ...

Tabel 5.2: Faktura-relationen efter deling Da nu hver fakturalinje optræder i sin egen tupel, viser det sig nødvendigt at indføre yderligere et identifikationselement for at sikre, at den enkelte linje entydigt kan identificeres. Derfor oprettes som ny attribut et løbenummer som en del af nøglen. Herefter vil en faktura udpeget ved fakturanummer og kundenummer kunne refereres af et antal fakturalinjer gennem netop fakturanummer og kundenummer. Vi ser at delingen af den oprindelige relation i to mere præcist kan siges at være to projektioner af den oprindelig relation i den relationelle algebras betydning. Dette løsningsprincip indebærer, at vi efter delingen skal verificere, at de to resulterende relationer tilsammen opfylder den oprindelige relations informationsform˚ al, hvilket i mere teknisk forstand betyder, at en natural join vil kunne bringe den oprindelige relation tilbage. Man taler om at delingen skal være reversibel, der m˚ a ikke g˚ a information tabt. Efter deling underkaster vi de nye relationer undersøgelse i forhold til normaliseringsreglerne. Den oprindelige relation undersøges igen for at sikre, at den ikke havde flere problemer i forhold til den aktuelle normalform. Den nye relation undersøges “forfra”, fra og med første normalform. Det viste eksempel vil resultere i følgende forekomster, jf. tabel 5.2 og 5.3. Vi ser to relationer, hvori de respektive tupler har ens bredde. Der er ikke længere nulls i relationerne.

5.4 5.4.1

Anden Normalform En definition

Codd (1971) definerer anden normalform, 2NF, s˚ aledes: ©nml

67


Kapitel 5: Normalisering FAKTURALINIE Varenr Varenavn

Fnr

Knr

Løbenr

Antal

Pris

1001

17

1

901

1002

18

1

901

Kabel

1

59.95

Kabel

2

52.00

1002

18

2

1003

21

1

902

USB1x

1

91.25

901

Kabel

1

59.95

1003

21

2

903

USB2x

4

118.00

903

USB2x

1

118,00

902

USB1x

1

91.25

... 1009

17

1 ...

1021

17

1

Tabel 5.3: Forekomsterne af fakturalinier efter delingen. En relation R er p˚ a anden normalform, hvis den er p˚ a første normalform, og hvis enhver ikke-nøgle-attribut er fuldt funktionelt afhængig af enhver kandidatnøgle i R. Vi ser af formuleringen at relationer p˚ a 2NF udgør en ægte delmængde af relationer p˚ a 1NF. R2N F ⊂ R1N F . Udover kravet om 1NF skal yderligere nogle betingelser være opfyldt. Date (2000a), som er en b˚ ade historisk og analytisk gennemgang af den relationelle model, strammer definitionen en smule idet han definerer en optimal 2NF, der siger: En samling relationer er p˚ a optimal 2NF hvis 1. alle relationer i samlingen er p˚ a 2NF og 2. samlingen indeholder s˚ a f˚ a relationer som muligt, der alle skal være i overensstemmelse med 1. Det skal fremhæves, at der ikke nødvendigvis kun er en mulig samling relationer. Der kan være flere, der opfylder samme prædikat om virksomhedens virkelighed.

5.4.2

Det problematiske eksempel

Lad os se p˚ a resultatet af FAKTURA-relationens deling for at kunne leve op til 1NF FAKTURA: [Fakturanr,Kundenr,Dato,Navn,Gade,Postnr,By]

De funktionelle afhængigheder i forhold til nøgleattributterne er her {F akturanr, Kundenr} → Dato Kundenr → N avn, Gade, P ostnr, By Hertil kommer en afhængighed af en ikke-nøgle-attribut P ostnr → By I forhold til nøgleattributterne har vi her en attribut, Dato, der er fuldt funktionelt afhængig af primærnøglen, mens de resterende fire ikke-nøgle-attributter nok er funktionelt afhængige af primærnøglen, men kun fuldt funktionelt afhængige af en del af den, nemlig af kundenr. FAKTURA-relationen lever derfor ikke op til 2NF, hvorfor den m˚ a deles jf. princippet beskrevet i afsnit 5.3.4. Principielt burde vi tale om funktionel afhængighed af alle 68

©nml


5.5: Tredje Normalform

kandidatnøgler, men da vi her kun har angivet primærnøglen, er sprogbrugen lidt upræcis, teoretisk set. Vi anvender Paco’s princip og deler relationen, s˚ aledes at attributterne følger de funktionelle afhængigheder. Herved fremkommer FAKTURA: [Fakturanr,Kundenr,Dato] KUNDE: [Kundenr,Navn,Gade,Postnr,By]

Disse to resulterende relationer lever op til 2NF. Tabel 5.4 viser de to relationer, der kommer ud af FAKTURA-relationens deling i følge 2NF. FAKTURALINIE-relationen frembyder ingen problemer i forhold til 2NF, som læseren vil kunne forvisse sig om. FAKTURA Fnr

Knr

Dato

1001

17

3/8/2005

1002

18

3/8/2005

1003

21

3/8/2005

1009

17

4/8/2005

1021

17

5/8/2005

KUNDE

og

Knr

Navn

Gade

Postnr

By

17

Asen

Aagade

8033

Aaby

18

Bsen

Boulevarden

8043

BCity

21

Csen

C-vej

8053

City

Tabel 5.4: FAKTURA-relationen efter 2NF-delingen. Dette mellemresultat, har medført at vi ogs˚ a har f˚ aet løst et andet problem. De redundante kundedata, der forekom i de tidligere tabeller afslørede, som den opmærksomme læser sikkert har opdaget, at kunde 17’s efternavn var forkert stavet i en af fakturaerne. N˚ ar vi nu efter 2NF-delingen kun har en forekomst af hver kunde i KUNDE-relationen kan dette problem ikke længere opst˚ a.

5.5

Tredje Normalform

5.5.1

En definition

Vi vender os igen til Codd (1971), der definerer 3NF s˚ aledes: En relation R er p˚ a tredje normalform, hvis den er p˚ a anden normalform og det gælder, at ingen ikke-nøgle-attribut er transitivt afhængig af nogen kandidatnøgle i R. Bemærk ogs˚ a her, at der ligesom i definitionen p˚ a 2NF tales om ikke-nøgle-attributter i forhold til kandidatnøgler, og ikke kun i forhold til primærnøgler. P˚ a samme m˚ ade bør det ogs˚ a fremhæves, at relationer p˚ a 3NF udgør en ægte delmængde af relationer p˚ a 2NF, R3N F ⊂ R2N F , idet kravet er opfyldelse af 2NF og hertil opfyldelse af den yderligere betingelse om transitiv afhængighed.

5.5.2

Det problematiske eksempel

Analyserer vi de to resulterende relationer efter delingen under undersøgelsen for 2NF, se tabel 5.4, viser FAKTURA-relationen ingen problemer. Da den kun indeholder den ene ikkenøgleattribut, kan der i sagens natur ikke være indbyrdes afhængigheder mellem ikke-nøgleattributterne. ©nml

69


Kapitel 5: Normalisering

Den nyopst˚ aede KUNDE-relation afslører ved nærmere analyse af de funktionelle afhængigheder, som er Kundenr → N avn, Gade, P ostnr, By men endvidere P ostnr → By, at den ikke er i overensstemmelse med 3NF, der netop forbyder transitive afhængigheder. Denne erkendelse ses ikke i forekomstdiagrammet, men viser sig ved kendskab til postnummersystemet. Den transitive afhængighed er her, at Kundenr → P ostnr og at P ostnr → By. Vi siger, at by er transitivt afhængig af kandidatnøglen. Den FAKTURALINIE-relation, der opstod ved deling i henhold til 1NF, og som overlevede analysen omkring 2NF, har et tilsvarende problem. Her viser problemet sig i forekomstdiagrammet, tabel 5.3. Forekomsterne viser redundans omkring varenavne. Hvis en vare er solgt flere gange forekommer b˚ ade varenummeret og varenavnet hver gang. De funktionelle afhængigheder i FAKTURALINIE er {F nr, Knr, Lobenr} → V arenr, V arenavn, Antal, P ris men ogs˚ a V arenr → V arenavn, P ris Her er den transitive afhængighed {F nr, Knr, Lobenr} → V arenr men ogs˚ a V arenr → V arenavn, P ris, alts˚ a er varenavn og pris transitivt afhængige af kandidatnøglen. Vi er derfor nødsagede til at anvende Paco’s princip p˚ a b˚ ade KUNDE- og FAKTURALINIErelationerne. Delingen fremg˚ ar af den reviderede forekomsttabel i tabel 5.5. KUNDE Knr

Navn

17 18 21

POSTDISTRIKT

Gade

Postnr

Postnr

By

Asen

Aagade

8033

8033

Aaby

Bsen

Boulevarden

8043

8043

BCity

Csen

C-vej

8053

8053

City

FAKTURALINIE Fnr

Knr

Løbenr

Varenr

Antal

Pris

1001

17

1

901

1

59.95

1002

18

1

901

2

52.00

VARE

1002

18

2

902

1

91.25

Varenr

1003

21

1

901

1

59.95

901

Kabel

1003

21

2

903

4

118.00

902

USB1x

91.25

903

USB2x

118.00

... 1009

17

1

903

1

118.00

902

1

59.95

Varenavn

Pris 59.95

... 1021

17

1

Tabel 5.5: Den tredje deling, denne gang til 3NF KUNDE-relationen bevarer sin attribut postnummer, der skal bruges som fremmednøgle til at opfylde referencereglen til den nye relation POSTDISTRIKT, der har postnummer som nøgle. Postdistriktet indeholder attributten by, der nu ikke længere forekommer redundant i hver kunderegistrering, men kun en gang per postnummer. P˚ a tilsvarende m˚ ade deles FAKTURALINIE, der bevarer attributten antal fordi det hører til her, og varenummer for, som fremmednøgle, at kunne referere til vareregistreringer i den nye relation VARE. Vare har varenummer som nøgle og indeholder attributterne varenavn og pris. Det kan forekomme at være et brud p˚ a logikken, at pris er bevaret som attribut i fakturalinie, n˚ ar den findes i vare. ˚ Arsagen er, at der kan være grund til at tillade afvigelser 70

©nml


5.6: Boyce-Codd Normalformen

fra varens listepris i forbindelse med et salg. Berettigelsen af den overvejelse er ikke generel, men m˚ a gøres for et konkret systems model.

5.6

Boyce-Codd Normalformen

5.6.1

En definition

Teoretikerne opdagede allerede i starten af 70’erne, at der i undtagelsestilfælde kunne forekomme redundans i tabeller, der overholdt tredje normalform. Selvom det m˚ aske ikke var hyppigt, s˚ a m˚ atte det dog for databasernes konsistens undg˚ as. Codd (1974) fremkom derfor i samarbejde med Raymond Boyce med en løsning p˚ a dette problem. Denne løsning var tænkt som en forbedret definition p˚ a 3NF, men det viste sig snart, at nogle relationer opfyldte 3NF, men ikke denne nyformulerede udgave af den. Den nye formulering fik derfor sit eget navn Boyce/Codd normalformen, BCNF. Vi ser s˚ aledes at relationer p˚ a BCNF en ægte delmængde af relationer p˚ a 3NF, RBCN F ⊂ R3N F . Codds og Boyces oprindelig definition af BCNF lyder s˚ aledes, idet man jo mente at være i færd med at reformulere 3NF: En relation er p˚ a tredje normalform, hvis det for enhver mængde C af attributter i R gælder, at hvis en attribut, der ikke er medlem af C, er funktionelt afhængig af C, s˚ a er alle attributter i R funktionelt afhængige af C. Definitionens C skal fortolkes som en supernøgle. Med lidt sproglig velvilje, kan man heri ogs˚ a a se den tidligere givne definition af 3NF, se 5.5.1, der jo siger at ingen ikke-nøgle-attribut m˚ være transitivt afhængig af en kandidatnøgle, som jo er en minimal supernøgle. Med andre ord fordrer 3NF direkte afhængigheder, hvilket ovenst˚ aende formulering ogs˚ a gør. Som det ogs˚ a ses, er det ikke muligt ud fra definitionen af fastsl˚ a om denne nye formulering er en skærpelse i forhold til 3NF. Definitionen nævner ikke som en forudsætning, at relationen skal opfylde 3NF, hvilket er ganske naturligt, men man kan sige, at den s˚ a m˚ aske burde have nævnt 2NF som et krav; men det gør den heller ikke. Det er s˚ aledes praksis, der har vist os, som nævnt, at relationer der opfylder denne definition er en ægte delmængde af relationer p˚ a 3NF. Da vi jo allerede har set at R3N F ⊂ R2N F og praksis viser at RBCN F ⊂ R3N F , er der monotont stigende krav fra den unormaliserede relation op til og med BCNF. Hierarkiet bevares. En m˚ aske mere mundret definition af BCNF er En relation er p˚ a Boyce/Codd normalformen, hvis alle dens determinantfelter er kandidatnøgler. Der findes alternative formuleringer af henholdsvis 3NF og BCNF, der synes at klarlægge gennem definitionerne alene, at BCNF er stærkere end 3NF. Da disse formuleringer imidlertid blandt andet bygger p˚ a nøgleattributters funktionelle afhængighed af nøgler, skal de udelades her, idet de i denne fremstilling givne definitioner alle bygger p˚ a ikke-nøgle-attributters afhængigheder. Der kan henvises til Zaniolo (1982).

5.6.2

Et illustrativt eksempel

Problematiske relationer, som overholder 3NF, men ikke BCNF, har det til fælles, at de har sammensatte og overlappende kandidatnøgler. Lad os i figur 5.2 se p˚ a et konkret eksempel, der dokumenterer situationen. Figuren indeholder en ER-model af en undervisningssituation. For overskuelighedens skyld er der kun tegnet nøgleattributter ind i diagrammet. Som vi senere i kapitel 6 skal se, vil ER-relationen Underviser blive til en relation i vores database. Denne relation vil efter ©nml

71


Kapitel 5: Normalisering

Figur 5.2: ER-model af undervisningssituation. regler, som vi skal se i det p˚ agældende kapitel f˚ a en primærnøgle best˚ aende af Fagnr og KlasseBetegnelse og i øvrigt indeholde LaererId som ikke-nøgle-attribut. S˚ aledes Underviser: [Fagnr, KlasseBetegnelse, LaererId]

Situationen kan ogs˚ a beskrives i en forekomsttabel som i tabel 5.6. KlasseBetegnelse

LaererId

Fagnr

05M

bki

3528

04R

brar

3520

04A

chrb

3524

05N

chrb

3524

04A

mban

3528

04A

nml

3523

05N

nml

3523

Tabel 5.6: Tupler i en relation der er p˚ a 3NF, men ikke p˚ a BCNF. Underviser har følgende funktionelle afhængigheder {F agnr, KlasseBetegnelse} → LaererId, og LaererId → F agnr da {F agnr, KlasseBetegnelse} er kandidatnøgle i Underviser, mens LaererId ikke er det, er relationen p˚ a 3NF, men ikke p˚ a BCNF. At relationen er p˚ a 3NF skyldes at {F agnr, KlasseBetegnelse} → LaererId, dvs. at den opfylder 2NF, og at LaererId som eneste ikke-nøgle-attribut selvfølgeligt ikke er transitivt afhængig af kandidatnøglen. At U nderviser ikke er p˚ a BCNF skyldes den sidstnævnte af de to funktionelle afhængigheder, og at LaererId ikke er en kandidatnøgle. 5.6.2.1

Paco’s princip anvendt p˚ a den problematiske relation

Jævnfør de normale procedure bør relationen deles. Der kan tænkes tre mulige delinger: 1. R11: [KlasseBetegnelse, LaererId] og R12: [Fagnr, KlasseBetegnelse] eller 72

©nml


5.6: Boyce-Codd Normalformen

2. R21: [Fagnr, LaererId] og R22: [Fagnr, KlasseBetegnelse] eller 3. R31: [Fagnr, LaererId] og R32: [KlasseBetegnelse, LaererId] Det kan konstateres at uanset hvilken deling der laves i det konkrete tilfælde, vil vi miste den funktionelle afhængighed {F agnr, KlasseBetegnelse} → LaererId. I denne situation skal vi foretrække den 3. mulighed idet den, ved nærmere analyse, viser sig ikke at generere falske tupler, n˚ ar vi laver en natural join p˚ a de delte relationer. Falske tupler er s˚ adanne, som ikke forekom i den relation, der for˚ arsagede delingen, fordi den ikke var p˚ a BCNF. Forekomster ved deling efter eksempel 1. R11

R12

R ← R11 ∗ R12 KlasseBetegnelse

LaererId

Fagnr

05M

bki

3528

04R

brar

3520

04A

chrb

3523

KlasseBetegnelse

LaererId

Fagnr

Klassebetegnelse

04A

chrb

3524

04R

brar

3520

04R

04A

chrb

3528

04A

nml

3523

04A

05N

chrb

3523

04A

chrb

3524

04A

05N

chrb

3524

04A

mban

3528

04A

04A

mban

3523

05N

nml

3523

05N

04A

mban

3524

05M

bki

3528

05M

04A

mban

3528

05N

chrb

3524

05N

04A

nml

3523

04A

nml

3524

04A

nml

3528

05N

nml

3523

05N

nml

3524

Forekomster ved deling efter eksempel 2 R21

R22

R ← R21 ∗ R22 KlasseBetegnelse

LaererId

Fagnr

bki

3528

Fagnr

KlasseBetegnelse

04A

Fagnr

LaererId

3520

04R

05M

bki

3528

3520

brar

3523

04A

04R

brar

3520

3523

nml

3524

04A

04A

chrb

3524

3524

chrb

3528

04A

05N

chrb

3524

3528

mban

3523

05N

04A

mban

3528

3528

bki

3528

05M

05M

mban

3528

3524

05N

04A

nml

3523

05N

nml

3523

Tabel 5.7: Falske tupler De falske tupler ses tydeligt i tabel 5.7, hvor b˚ ade eksempel 1 og 2, svarende til de to delingsmuligheder i teksten ovenfor, giver tupler, der ikke forekom i populationen fra tabel 5.6. Ser vi p˚ a tabel 5.8, der afspejler mulighed 3 fra teksten herover, finder vi som antydet den mulighed, der ikke giver falske tupler. Vi erindrer os fra afsnit 5.3.4, at der ikke m˚ atte g˚ a information tabt ved deling i forbindelse med normalisering. Vi har her set et eksempel p˚ a det modsatte, at en genforening af de delte relationer med operationen natural join, i uheldigste ©nml

73


Kapitel 5: Normalisering

fald kan fremvise tupler, der ikke ville have eksisteret uden en deling. Disse falske tupler bør undg˚ as, hvorfor vi m˚ a vælge den deling, der ikke frembringer dette logiske problem. Forekomster ved deling efter eksempel 3. R31

R32

R ← R31 ∗ R32

KlasseBetegnelse

LaererId

KlasseBetegnelse

Fagnr

LaererId

LaererId

Fagnr

04R

brar

3520

brar

04A

nml

05M

bki

3528

04R

brar

3520

3523

nml

04A

3524

chrb

04A

chrb

04A

chrb

3524

mban

05N

chrb

3524

3528

mban

3528

bki

05N

nml

04A

mban

3528

05M

bki

04A

nml

3523

05N

chrb

05N

nml

3523

Tabel 5.8: Det bedste valg ved deling af relationen, der ikke var p˚ a BCNF.

5.7 5.7.1

Øvelser til kapitel 5 bla bla

Du skal

5.7.2

Øvelse n

P˚ a baggrund af

74

©nml


Kapitel 6

Fra ER til RM 6.1

Transformation af ER-model1

N˚ ar der i et systemudviklingsprojekt er skabt en ER-model, skal denne p˚ a et tidspunkt implementeres elektronisk som en database p˚ a det niveau i ANSI/SPARC-modellen vi kalder det logiske niveau. Vi skal i gang med at transformere den udarbejdede ER-model til en database i overensstemmelse med den relationelle model for derefter at kunne realisere den p˚ a en computer. Metoden hertil kaldes mapping 2 . P˚ a dansk kunne man med Rønnow and Jacobsen (1989) kalde denne transformation for en reduktion, idet ikke alle tegnede objekter fra ER-diagrammet overlever transformationen. Nogle objekter er ikke nødvendige af ganske logiske ˚ arsager. Disse reduceres bort fra modellen idet deres informationsværdi varetages af andre objekter. Der er ingen grund til at have objekter med blot for at have dem. Forudsætningen er selvfølgelig, at informationsindholdet fra de bortreducerede elementer bevares, og at databasen bliver enklere derved. I det følgende skal gennemg˚ as en metode, der skridt for skridt metodisk foretager denne transformation fra ER-model til relationel model. Elmasri and Navathe (2003) kalder metoden en algoritme3 .

6.1.1

Første skridt

Almindelige (stærke) entiteter For alle ikke-svage entiteter oprettes en relation. Der oprettes i denne relation attributter svarende til entitetens attributter. Det bør overvejes om der bør defineres domæner i forvejen, svarende til attributternes datatyper. Domæner kan i givet fald p˚ alægges regler, begræn-

Figur 6.1: Input til skridt nr. 1, entiteterne E1 og E2 sninger, der indsnævrer værdimængden i forhold til det som den rene datatype medfører. 1

Lad os med uformel nydansk sprogbrug kalde denne transformation for ER2RM, fra Entity-Relationship til Relationel Model. 2 Fra engelsk map, der som verbum betyder at tegne et kort. 3 En algoritme er en samling af instruktioner, der trin for trin beskriver, hvad der skal gøres for at løse en opgave.

75


Kapitel 6: Fra ER til RM

Indeholder entiteten sammensatte attributter, oprettes kun de atomare komponenter heraf som attributter i relationen. Der vælges blandt entitetens kandidatnøgler en som primær nøgle. Alternativnøglerne erklæres i relationen som unikke. Figur ?? giver følgende relationsskemaer fra algoritmens første skridt: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an]4

Det vil i virkelighedens verden være form˚ alstjentligt, at skrive relationsskemaerne direkte i form af create table-deklarationer i SQL, men da vi endnu ikke har diskuteret SQL, bruger vi her denne pseudoform.

6.1.2

Andet skridt

Svage entiteter For alle svage entiteter i ER-modellen oprettes en tilsvarende relation. Der oprettes attributter svarende til entitetens attributter p˚ a samme m˚ ade som beskrevet under første skridt. Relationen tildeles som primærnøgle samme attribut, som er udnævnt som primærnøgle i den relation, som denne er svag overfor. Primærnøglen udvides eventuelt med yderligere at-

Figur 6.2: Input til algoritmens andet skridt tributter, afhængigt af behov, der kan opst˚ a hvis den svage entitet har kardinaliteten N. Den del af primærnøglen der svarer til den stærke entitets primærnøgle erklæres ogs˚ a som fremmednøgle, der udpeger primærnøglen fra den stærke entitet som reference. Herved varetages rollen som identificerende relation, og samhørigheden mellem den stærke entitet og den svage sikres. Figur 6.2 giver følgende relationsskemaer fra algoritmens første (E1) og andet (WE) skridt: E1: [ck,a1,a2,...,an] og WE: [ck,lnr,a1,a2,...,an]

Her er WE.ck overført fra E1, og WE.lnr er tilføjet som et løbenummer fordi WE har kardinaliteten N.

6.1.3

Tredje skridt

ER-relationer Vi har nu transformeret alle entiteter fra ER-modellen til den relationelle models relationer. I det følgende skal vi derfor se p˚ a ER-relationernes skæbne. Skridt 3, 4, 5 og 7 i denne metodologi behandler ER-relationerne afhængigt af kardinaliteten af de p˚ agældende ERrelationer. Det er indledningsvist værd at bemærke, at ingen af de i det følgende beskrevne situationer indeholder relationer med total deltagelse til alle indg˚ aende entiteter, jævnfør afsnit 3.2.8. De constraints, som ER2RM indebærer vil af ethvert RDBMS skulle h˚ andhæves i isolation p˚ a den aktuelle databasetransaktion. Det betyder, at algoritmen resulterer i definitionen 4

Figurens og tekstens notation her og i resten af beskrivelsen af transformationsalgoritmen vil være, at attributten ck betyder en kandidatnøgle. Den er understreget hvis den er primærnøgle. Attributterne er a1, a2, op til an. Fx. vil notationen E2.a2 betyde anden attribut fra entiteten E2.

76

©nml


6.1: Transformation af ER-model

af en database, hvis regler nødvendigvis skal h˚ andhæves af et RDBMS, hver gang dette konfronteres med en SQL Data deklaration. I de tilfælde, hvor designeren har modelleret total deltagelse til alle indg˚ aende entiteter, m˚ a vi s˚ aledes vælge side med hensyn til implementering af deltagelsestypen. Valget er simpelt og overvejelserne henvises til det konkrete afsnit. Introduktion til heuristisk design - Bjørns metode Suzanne W. Dietrich fremhæver i Dietrich (2001), at der altid er et heuristic design og at der, med en enkelt undtagelsessituation, findes et alternativt design at vælge. Dietrichs heuristic design kan s˚ aledes altid bruges. Det udgør en tilbagefaldsregel, som man, uden at g˚ a p˚ a kompromis med logikken, altid kan bruge. Det hun kalder heuristic design best˚ ar i, at der dannes en relation af ER-relationen. Denne relation skal, selvfølgelig, indeholde de attributter, der m˚ atte være modelleret p˚ a den. Hertil kommer en nøgle best˚ aende af kombinationen af de involverede entiteters nøgler, der udover tilsammen at udgøre primærnøglen, hver især defineres som fremmednøgle med reference til den entitet, hvorfra de kom. P˚ a baggrund af en særligt vellykket undervisningssituation vil vi herefter give dette design tilnavnet Bjørns metode. I en række tilfælde viser det sig dog, at et alternativt design kan opn˚ a samme logiske resultat uden oprettelse af en relation svarende til ER-relationen. I den situation vil man derfor kunne “spare” programmering af funktionalitet til oprettelse, vedligeholdelse og sletning af forekomster i en s˚ adan relation uden forringelse af databasens design og anvendelsesmuligheder. Binære 1:1 relationer Der er tre forskellige mulige m˚ ader, hvorp˚ a binære 1:1-relationer kan afbildes i den relationelle model: 6.1.3.1

Fremmednøglemetoden

Elmasri and Navathe (2003) kalder denne første m˚ ade for fremmednøgle-metoden og anbefaler den som hovedregel. Der er dog en forudsætning, der skal være opfyldt for at den er nyttig. Metoden best˚ ar i, at der ikke oprettes en ny relation til afbildning af ER-relationen, men i stedet at tilføje primærnøglen fra den relation, der afbilder den ene entitet som ny attribut i den anden indg˚ aende entitets afbildende relation. Den nye attribut erklæres som fremmednøgle, der refererer sin kildes primærnøgle. Metodens forudsætning er, at den relation, der f˚ ar tildelt fremmednøgleattributten, har total deltagelse. Er dette ikke tilfældet vil metoden kunne medføre at fremmednøglefeltet kan st˚ a udefineret (null ) hen. Derfor er denne forfatter ikke enig i at denne metoden bør være hovedreglen. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an]

Nærværende processkridt ændrer nu relationen med total deltagelse, E2, s˚ a den f˚ ar nyt udseende: E2: [ck,a1,a2,...,an,fk], hvor fk erklæres som fremmednøgle, der skal referere E1.ck. Jævnfør i øvrigt figur 6.3a. 6.1.3.2

Sammenlægning

Den anden m˚ ade best˚ ar i sammenlægning af de to entiteter til en relation. Denne m˚ ade kan ikke anbefales, idet der formentlig er en b˚ ade fornuftig og logisk grund til at der er modelleret ©nml

77


Kapitel 6: Fra ER til RM

a)

b)

Figur 6.3: Input til a) algoritmens tredje skridts fremmednøglemetode, og b) til Bjørns metode to forekomster i samme entitetsklasse i stedet for en. Ud fra en logisk betragtning er m˚ aden kun anvendelig ved total deltagelse. 6.1.3.3

Bjørns metode, oprettelse af en opslagstabel

Har 1:1-relationen partiel deltagelse til begge sider, figur 6.3b, skal der oprettes en relation til afbildning af ER-relationen. Har ER-relationen ikke selv attributter skal primærnøglerne fra de deltagende entiteter indsættes som attributter og en af dem udnævnes til primærnøgle. Har relationen selv attributter skal disse selvfølgelig ogs˚ a indg˚ a i relationen. De to nye attributter erklæres hver for sig som fremmednøgle, refererende hver sin primærnøgle fra de to deltagende entiteters afbildning. Denne nye relation kaldes af og til for en opslagstabel, idet den jo indeholder alle de realiserede kombinationer mellem de indg˚ aende entiteter. Er man i tvivl om det hensigtsmæssige i at kun en af de nye attributter udnævnes til primærnøgle, kan det anbefales at skitsere en tabel over forekomster, og deri afprøve forskellige muligheder. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an]

Nærværende processkridt opretter nu relationen R med følgende udseende: R: [pk1,pk2], hvor pk1 og pk2 tilsammen er primærnøgle. Attributten pk1 erklæres som fremmednøgle, der skal referere E1.ck, og pk2 erklæres som fremmednøgle, der skal referere E2.ck. 6.1.3.4

Total deltagelse til begge sider

Hvis 1:1-relationen har total deltagelse for begge involverede entiteter, har vi et logisk problem. Entitetsforekomsterne p˚ a de to sider vil forudsætte hinanden, en s˚ akaldt Catch 225 situation. Hvis vi i misforst˚ aet iver for at sikre høj integritet opretter en fremmednøgle i den modsatte entitet, vil RDBMSet sikre, at vi aldrig f˚ ar oprettet nogen forekomst i de to relationer, der skal afbilde entiteterne. Den praktiske løsning er et valg. Enten vælges, med anbefaling herfra, fremmednøglemetoden, hvorved man giver afkald p˚ a RDBMSets h˚ andhævelse af den ene tvungne deltagelse, 5

Catch 22 er en (særdeles underholdende) roman af Joseph Heller.

78

©nml


6.1: Transformation af ER-model

eller man vælger Bjørns metode, hvorved man giver afkald p˚ a at begge entiteters tvungne deltagelse skal styres af RDBMSet. Det fravalg man derved er p˚ atvunget afhjælpes ved en mindre ekstra egenprogrammering omkring oprettelse og sletning af forekomster i relationerne svarende til entitetsklasserne.

6.1.4

Fjerde skridt

Binære 1:N relationer For 1:N-relationer har vi to muligheder:

a)

b)

Figur 6.4: Algoritmens fjerde skridt. a) total deltagelse. b) partiel deltagelse.

6.1.4.1

Total deltagelse - brug af det alternative design

Hvis der er total deltagelse p˚ a N-siden, oprettes ingen ny relation, men vi finder derimod relationen, der afbilder N-siden og heri indføjes som ny attribut nøglefeltet fra 1-siden. Dette nye felt erklæres som fremmednøgle i N-relationen med reference til 1-sidens nøglefelt. Der kan naturligvis her være tale om, at nøglefeltet er sammensat. Logikken er her, at da hver forekomst p˚ a N-siden refererer netop en forekomst p˚ a 1-siden, er relationens form˚ al opfyldt. Der opst˚ ar ikke null s, n˚ ar der er fuld deltagelse. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an] se ogs˚ a figur 6.4a. Nærværende processkridt ændrer nu relationen med total deltagelse, E2, s˚ a den f˚ ar nyt udseende: E2: [ck,a1,a2,...,an,fk], hvor fk erklæres som fremmednøgle, der skal referere E1.ck. Denne metode ligner til forveksling den første mulighed fra beskrivelsen af binære 1:1ER-relationer, se afsnit 6.1.3.1, hvor der dog var teoretisk valgfrihed mellem de to entiteter med hensyn til placeringen af fremmednøglen. Valgfriheden var p˚ a bekostning af nulls hvis ikke entiteten med fuld deltagelse valgtes. I nærværende situation er der ingen valgfrihed idet, der er tale om en 1:N-ER-relation. 6.1.4.2

Partiel deltagelse - Bjørns metode, oprettelse af en relation

Er der partiel deltagelse p˚ a N-siden oprettes en relation til afbildning af ER-relationen. Denne nye relation f˚ ar alene nøglefelterne fra de deltagende attributter som nye attributter. N-sidens ©nml

79


Kapitel 6: Fra ER til RM

bidrag erklæres som primærnøgle og samtidig erklæres denne attribut som fremmednøgle med reference til sin oprindelse. 1-sidens nøglefelt erklæres som fremmednøgle med reference til 1-sidens primærnøgle. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an]

Nærværende processkridt opretter nu relationen R med følgende udseende: R: [fk1,pk2], hvor pk2 er primærnøgle. Attributten fk1 erklæres som fremmednøgle, der skal referere E1.ck, og pk2 erklæres som fremmednøgle, der skal referere E2.ck. 6.1.4.3

Total deltagelse p˚ a 1-siden

Den opmærksomme læser vil allerede have bemærket, at total deltagelse p˚ a 1-siden ikke er behandlet. P˚ a grund af de logiske problemer, der er redegjort for i afsnit 3.2.8 og 6.1.3.4 m˚ a vi vælge. Det naturlige valg er at lade som om 1-siden har partiel deltagelse. Det medfører, hvis N-siden har total deltagelse handler vi som beskrevet i afsnit 6.1.4.1, og hvis N-siden har a vi jf afsnit partiel deltagelse handler vi som beskrevet i afsnit 6.1.4.2. I begge situationer m˚ 6.1.3.4 med en mindre egenprogrammering afhjælpe RDBMSets dilemma. Læseren vil kunne forvisse sig om, at ethvert andet valg ville medføre mulighed for nulls i databasen, og derved være et d˚ arligt valg.

6.1.5

Femte skridt

Binære N:M relationer

Figur 6.5: Binær N:M-relation

Uanset deltagelsestype skal enhver N:Mrelation oprettes som relation efter Bjørns metode. Denne f˚ ar som attributter attributterne som vi eventuelt havde tildelt ERrelationen. Hertil kommer, som nye felter i relationen, nøglefelterne fra de deltagende relationer fra ER-modellen. Disse erklæres sammen som nøglefelter i den nye relation. Hver for sig erklæres de som fremmednøgler med passende referencer. Der opst˚ ar ingen nulls i databasen p˚ a den baggrund, idet forekomster naturligvis kun oprettes, n˚ ar situationen kræver det. Ved partiel deltagelse er dette af og til. Ved total deltagelse sker det hver gang, der oprettes en forekomst i den relation, der afspejler en

deltagende entitet med fuld deltagelse. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an] og E2: [ck,a1,a2,...,an]

Nærværende processkridt opretter nu relationen R med følgende udseende: R: [pk1,pk2,a1,a2,...,an], hvor pk1 og pk2 tilsammen er primærnøgle. Attributten pk1 erklæres som fremmednøgle, der skal referere E1.ck, og pk2 erklæres som fremmednøgle, der skal referere E2.ck. 80

©nml


6.1: Transformation af ER-model

6.1.6

Sjette skridt

Flerværdiattributter Det er denne forfatters opfattelse, at flerværdiede attributter p˚ a dette tidspunkt ikke længere eksisterer i ER-modellen. En gennemgang af ER-modellen vil have afsløret dem og burde allerede p˚ a daværende tidspunkt have for˚ arsaget en revision af modellen. Se afsnittene 3.7 og3.12. Støder vi imidlertid alligevel p˚ a en flerværdiet attribut, skal afbildningen i den relationelle model afspejle den strategi, der i 3.12 blev beskrevet. Vi opretter derfor en ny relation svarende til den svage entitet, der skal indeholde attributten. Udover den famøse flerværdiattribut, skal den nye relation indeholde en fremmednøgle, der refererer den relation, som oprindeligt indholdt flerværdiattributten. De to attributter tilsammen deklareres som primærnøgle i den ny relation. Dette sidste sikrer integriteten da kardinaliteten er 1:N. Lad os antage at entiteten E1 har en flerværdiet attribut. Vi kalder den fvan. E1: [ck,a1,a2,...,an,fvan]

Nærværende processkridt opretter nu relationen WE med følgende udseende: WE: [ck,fvan], med primærnøgle best˚ aende af ck og fvan. ck erklæres ogs˚ a som fremmednøgle, der skal referere E1.ck.

6.1.7

Syvende skridt

Relationer af n’te grad (n-ære relationer) P˚ a samme m˚ ade som ved binære N:M-relationer, resulterer forekomster af n-ære ER-relationer altid, uanset kardinalitet, oprettelse af en ny relation i databasen det vil sige anvendelse af Bjørns metode.

Figur 6.6: N-ær relation som input tilalgoritmens syvende skridt. Har ER-relationen attributter, vil disse naturligvis indg˚ a som attributter i den nye relation. Nøglefelterne fra de relaterede entiteter, der tidligere er blevet relationer, oprettes som attributter i relationen. Disse attributter erklæres alle, hver for sig, som fremmednøgler, refererende deres respektive ophav. Som primærnøgle erklæres samlet de attributter, der er nøgleattributter i de relationer der hidrører fra entiteter, hvis deltagelse i den n-ære ER-relation har en kardinalitet højere end 1. Fra algoritmens første skridt, afsnit 6.1.1, har vi allerede etableret os med relationerne til afbildning af entiteterne: ©nml

81


Kapitel 6: Fra ER til RM E1: [ck,a1,a2,...,an], E2: [ck,a1,a2,...,an] og En: [ck,a1,a2,...,an]

Nærværende processkridt opretter nu relationen R med følgende mulige udseende: R: [pk1,pk2,fk], hvor pk1 og pk2 tilsammen er primærnøgle. Attributten pk1 erklæres som fremmednøgle, der skal referere E1.ck, og pk2 erklæres som fremmednøgle, der skal referere E2.ck. Attributten fk erklæres som fremmednøgle, der skal referere En.ck. N˚ ar dette blot er et muligt resultat, i øvrigt svarende til figur ??, er det selvfølgelig fordi en anden kardinalitet af den n-ære ER-relation vil have fordelt deltagelsen i primærnøglen i R anderledes.

6.1.8

Ottende skridt

Specialiseringer/generaliseringer

Figur 6.7: Specialisering/generalisering til input i transformationsalgoritmen. I et specialiserings-/generaliseringshierarki, eksempelvis som vist i figur 6.7, kan man vælge at se superklassen og dens tilhørende subklasser som almindelige entiteter i ERmodellen og afbilde dem i overensstemmelse hermed. Vi kan samtidig vælge at opfatte hver subklasse som en entitet forbundet til superklassen i en 1:1-relation. Forekomster i subklasserne ikke kan forekomme uden at have en tilhørende forekomst af superklassen. Der gælder den særlige regel for disse forhold i ER-modellen, at subklasserne identificeres p˚ a samme m˚ ade som deres superklasse. En forekomst i en subklasse har samme primærnøgle som den forekomst i superklassen, som den tilhører. Med disse betragtninger in mente, er afbildningen i den relationelle model ganske enkel. En superklasse afbildes som en relation med de attributter, som den har fra ER-modellen. Der vælges en primærnøgle blandt kandidatnøglerne. Subklasserne afbildes hver for sig som relationer i databasen med deres egne respektive attributter. Som primærnøgle for hver subklasse vælges at tilføje primærnøglen fra den tilhørende superklasse. Denne fremgangsm˚ ade respekterer ER-modellens nuancer og bringer ikke nulls ind i databasen. Vi etablerer alts˚ a i første omgang relationerne til afbildning af entiteterne: SUP1: [ck,a1,a2,...,an], SUB1: [a1,a2,...,an] og SUB2: [a1,a2,...,an]

82

©nml


6.1: Transformation af ER-model

Derefter justeres SUB1 og SUB2 ved tilføjelse af primærnøgler, hvortil l˚ anes primærnøglen fra superentiteten SUP1 ck. De f˚ ar derved følgende endelige udseende: SUB1: [pk,a1,a2,...,an] og SUB2: [pk,a1,a2,...,an],

hvor SUB1.pk og SUB2.pk er primærnøgler. Attributten SUB1.pk erklæres som fremmednøgle, der skal referere SUP1.ck, og SUB2.pk erklæres som fremmednøgle, der ogs˚ a skal referere SUP1.ck. Alternativer? Nogle af de kendte kilder, fx. Conolly (2005) og Elmasri and Navathe (2003), skitserer en række valmuligheder ved afbildning af specialiseringer fra ER-modellen til den relationelle model. I alle tilfælde bortset fra ovenst˚ aende valgmulighed vil der enten opst˚ a nulls i de resulterende relationer, eller der vil g˚ a nuancer tabt i form af sammenlægning af subklasser eller sammenlægning af super- og subklasser. Der henvises i øvrigt til de nævnte kilder. Med al respekt for de lærde vil vi derfor her anbefale den skitserede fremgangsm˚ ade, og se bort fra andre. Det vil være mærkeligt at skitsere en nuanceret model overfor en rekvirent, for derefter at fjerne nuancer i implementeringen, n˚ ar der ikke er grund hertil. Det er denne forfatters overbevisning, at vi ogs˚ a hermed p˚ a bedste m˚ ade i databasen bevarer fleksibilitet i forhold til eventuelle fremtidige udvidelser af systemerne.

6.1.9

Niende skridt

Aggregeringer

Figur 6.8: Aggregering. Betragt aggregeringer p˚ a samme m˚ ade som vi betragter parenteser i matematiske udtryk. Parentesernes indhold behandles først, og først derefter det samlede udtryk. Aggregeringernes indhold behandles først i overensstemmelse med reglerne fra nærværende algoritmes første otte skridt. En del af resultatet heraf vil ofte være en relation, der repræsenterer aggregeringen. Denne relation kan være opst˚ aet ud fra en ER-entitet, men vil oftest være en afbildning af en ER-relation. N˚ ar resten af ER-modellen gennemarbejdes i overensstemmelse med algoritmen, vil den relation der repræsenterer aggregeringen skulle forbindes med resten af modellen, som var den en entitet. Vi etablerer alts˚ a i første omgang relationerne til afbildning af entiteterne: E1: [ck,a1,a2,...,an],

©nml

83


Kapitel 6: Fra ER til RM

og relationen hvor fk1 og fk2 tilsammen er primærnøgle, der referer de respektive entiteters primærnøgler, jf. tidligere beskrivelse. Vi g˚ ar nu ud fra at E3 er etableret som relation i overensstemmelse med algoritmens første skridt: E2: [ck,a1,a2,...,an] R1: [fk1,fk2],

E3: [ck,a1,a2,...,an].

Den egentlige erklæring af aggregeringen som s˚ adan f˚ as ved sammenbinding af E3 og R1, der repræsenterer aggregeringen. Denne sammenbinding, R2, f˚ ar følgende udseende: R2: [fk1,fk2,fk3].

Heri er fk1, fk2 og fk3 tilsammen primærnøgle, hvis kardinaliteten er som vist p˚ a figur ??. der gælder samme regel som vi tidligere har set ved etablering af opslagstabeller. Primærnøglen best˚ ar af de overførte nøgler fra bidrag med kardinalitet N eller M. Er kardinaliteten 1, behøver feltet ikke deltage i primærnøglen, men skal dog være i relationen. Samtidig skal felterne i R2 hver for sig erklæres som fremmednøgler. R2.fk1 refererer R1.fk1, R2.fk2 refererer R1.fk2 mens R2.fk3 refererer E3.ck.

6.2 6.2.1

Øvelser til kapitel 6 Øvelse

Se p˚ a øvelse 3.4.2.3. Der skal nu etableres en relationsdatabase af ER-modellen fra den p˚ agældende øvelse. Gør rede for begrundelser for databasens udseende i form af argumentation for forekomst eller mangel p˚ a samme af ER-modellens objekter i relationsdatabasen.

6.2.2

Øvelse

Se p˚ a figur 6.9. P˚ a baggrund af kapitlets algoritme implementeres nu ER-modellens eksempel a) som en database. Lav en tabel over nogle tupler, som de kunne se ud. Brug eventuelt tabel 5.6 som inspiration, hvis fantasien ikke rækker.

Figur 6.9: To ER-modeller med samme entiteter og samme attributter.

6.2.3

Øvelse

a baggrund af kapitlets gennemgang implementeres nu ER-modellens Se nu igen p˚ a figur 6.9. P˚ eksempel b) som en database. Lav en tabel over nogle tupler, som de kunne se ud. Brug eventuelt tabel 5.6 som inspiration, hvis fantasien ikke rækker. 84

©nml


6.2: Øvelser til kapitel 6

6.2.4

Øvelse

Sammenlign resultatet fra øvelse 6.2.3 med det du opn˚ aede i øvelse 6.2.2. Hvad anser du for det bedste design? Hvorfor?

6.2.5

Øvelse

I kapitlets metodes syvende trin s˚ a vi, at p˚ a baggrund af n-ære ER-relationer, skulle der altid etableres en relation. Ternære relationer kan teoretisk have følgende mulige kardinaliteter, N:M:L, N:M:1, N:1:1 og 1:1:1. Det hævdedes at primærnøglen i den nye relation skulle omfatte de fremmednøglefelter, der refererer deltagelse p˚ a baggrund af en kardinalitet p˚ a mere end 1. P˚ a den m˚ ade blev der ikke taget stilling til nøglen i en relation, hvis baggrund er en ER-relation, hvor alle kardinaliteter var 1, alts˚ a fx. en ternær 1:1:1-relation. Ræsonner over hvilke(n) attribut(ter), som du mener bør deltage i primærnøglen og hvorfor.

6.2.6

Øvelse

Se p˚ a følgende diagram i figur 6.10:

Figur 6.10: Model til transformation. Den viste model transformeres til den relationelle model ved hjælp af kapitlets algoritme. Hvis der ikke skrives create table-deklarationer kan der evt. vises tabelskitser i formatet fag[udd,navn,nr] og ved siden af skrives en liste med attributternes type, og andre karakteristika. Det væsentlige er logik og nøgleovervejelser.

©nml

85


Kapitel 6: Fra ER til RM

86

Šnml


Kapitel 7

Databasesystemer - DBMSer Vi er nu n˚ aet til det punkt, hvor det ikke længere kan udskydes, at anvende al denne teori p˚ a virkeligt eksisterende software. Derfor kommer her et kort kapitel om et følsomt emne. Hvilken RDBMS skal man vælge? Emnet er følsomt fordi der i dette, ligesom i valg af operativsystem, og i valg af browser, og i valg af .... er “religiøse” undertoner, dvs. begrundelser, som ikke altid er fuldt ud rationelle. Diskussionen her har som m˚ al at være fordomsfri. Graden af m˚ alopfyldelse m˚ a læseren herefter vurdere. Et databasesystem kan formentlig ikke vælges uden hensyn til platform, idet det næppe skal eksistere alene, men sammen med anden software, der bruger databasesystemet. Denne anden software kan være kommerciel software, hvormed i denne sammenhæng menes købt software udviklet af andre end den brugende organisation. I et s˚ adant tilfælde er databasesystemet enten bundlet (en del af) eller købt særskilt ved siden af. Valgfriheden hos køberen med hensyn til databasesystem er oftest ikke til stede. Det betyder, at man enten hermed f˚ ar et nyt totalsystem, der passer til den operativsystem-platform, som man i forvejen har, eller at man etablerer sig med en platform, til netop et s˚ adant system. Valget af system kan en organisation lade være afhængigt af et evt. ønske om selv at lave yderligere, selvstændig softwareudvikling, der udnytter den p˚ agældende DBMS. Alternativt kan der være tale om software af egen udvikling, hvorved vi f˚ ar mulighed for selv at vælge databasesystem, og ogs˚ a hvilken platform, som det skal afvikles p˚ a.

7.1

Client/server

Inden vi g˚ ar videre i diskussionen kan det være nyttigt at f˚ a et overblik over databasesystemets placering i it-arkitekturen i organisationen. Langt de fleste, hvis ikke alle databasesystemer i vore dage er client/server-systemer i sig selv. De vil s˚ a oven i købet ofte være en del af et omgivende miljø, der i sig selv ogs˚ a er et client/server-system. Lad os først kaste et blik p˚ a det generelle client/server koncept i figur 7.1. Figuren viser øverst en model af den generelle client/server-arkitektur, som et givent system kan tilpasse sig p˚ a en af to m˚ ader. Det kan enten være et 2-tier, eller et 3-tier system. 2-tier-systemet er karakteriseret ved, at logik- og data-management-services smelter sammen i et niveau, mens det i 3-tier udgaven fuldt ud følger afbildningen. Den nederste del af figur 7.1 viser, hvordan en moderne, dynamisk web-applikation i realiteten er en 3-tier client/server-applikation. Lynene i client/server-model antyder, at et s˚ adant miljø er netværksbaseret. Softwaren er skrevet s˚ a de enkelte dele kommunikerer med hinanden ved hjælp af netværksprotokoller. Denne teknik hindrer ikke, at et s˚ adant system kan realiseres med alle komponenter p˚ a en enkelt computer. S˚ adan vil man m˚ aske ofte gøre det i en udviklingssituation, hvorimod n˚ ar systemet implementeres, s˚ a vil dets komponenter blive fordelt p˚ a flere computere. 87


Kapitel 7: Databasesystemer - DBMSer

Klient Display Lokal logik [Tier 1]

Server Logik/ applikation [Tier 2]

Server Data Management [Tier 3]

Generel client/server struktur-model

Klient Web-browser

Server Web-server

Server Databaseserver

Client/server struktur-model for dynamisk web Figur 7.1: Skematisk fremstilling af client/server-arkitektur.

7.2

Databasesystemet

Da vi indtil videre i denne gennemgang kun er interesserede i databasesystemet for sig, kan vi fokusere p˚ a denne komponent fra figur 7.1. Herved kommer vi frem til afbildningen vist i figur 7.2, der er meget abstrakt i forhold til den totale virkelighed. Vi ser i figuren blot serveren og klient-programmet, som en bruger skal anvende med henblik p˚ a de SQL-aktiviteter, der vil blive beskrevet i kapitel 8. I realiteten er der en hel række moduler, s˚ asom backup og restore-programmer, moduler til fortolkning af SQL, brugeradministration, indeholdt i figurens server-kasse. En konkret computer, der afvikler databasesystemet som en service, kan oftest sagtens betjene flere klienter samtidig. Det betyder at der ikke er nogen principiel hindring for at flere brugere samtidigt manipulerer en enkelt database.

7.3 “And the nominees are ...” I en tid hvor web-applikationer myldrer frem, og hvor der i kølvandet heraf er stor opmærksomhed p˚ a open source-bevægelsen er det naturligt at nævne nogle DBMSer fra denne gruppe sammen med de mere traditionelt nævnte fra de veletablerede kommercielle softwarehuse. Sidstnævnte er ikke open source, og dertil kommer at de kan være særdeles kostbare, dog afhængigt af hvilken platform de skal købes til. Fra den kommercielle softwareindustri kan nævnes: ˆ DB2 fra IBM ˆ Microsoft SQL Server ˆ Oracle ˆ Sybase Adaptive Server eller SQL Anywhere

88

©nml


7.3: “And the nominees are ...”

Server Data Management [Tier 3] Data management niveauet i client/server

Server Databaseserver

Klient til SQL

Implementering af DBMS

Figur 7.2: Et DBMS set udefra og indefra. Alle de nævnte er kendte og anerkendte produkter, der er tilgængelige til mainframes, miniog mikrocomputere (pc’er). Microsofts SQL Server og Sybase’s Adaptive Server var i øvrigt en fællesudvikling helt frem til 19941 . De kendte, anerkendte og udbredte open source databaser, der trænger sig p˚ a er: ˆ Firebird ˆ MySQL ˆ PostgreSQL

De tre nævnte er tilgængelig til b˚ ade Windows- og UNIX/Linux-platforme, og i ydedygtighed indenfor deres funktionalitet, st˚ ar de ikke væsentligt tilbage for de kommercielle produkter. Firebird er en open source efterfølger til InterBase, en kendt Borland database, som en kortere periode var tilgængelig som open source, men siden blev trukket tilbage igen. Firebird var i V1.0 funktionelt identisk med InterBase V6.0, og de lignede hinanden s˚ a meget, at de begge indtil videre fra brugerside kunne betjenes af et og samme klientprogram. PostgreSQL er et system, der har sin rod i et akademisk miljø p˚ a University of California at Berkeley. Læs her hvad Bruce Momjian skriver2 : PostgreSQL is the most advanced open-source database server. It is Object-Relational (ORDBMS), and is supported by a team of Internet developers. PostgreSQL’s ancestor was Ingres, developed at the University of California at Berkeley(19771985). The Ingres code was taken and enhanced by Relational Technologies/Ingres Corporation, which produced one of the first commercially successful relational database servers. (Ingres Corp. was later purchased by Computer Associates.) B˚ ade Firebird og PostgreSQL er avancerede databasesystemer, der p˚ a teoretisk baggrund med mindst liges˚ a god ret som de ovenfor nævnte kommercielle produkter kan kalde sig relationelle databasesystemer. PostgreSQL vinder frem i udbredelse fordi den i dag kommer bundlet med Linux operativsystemet. Firebird er endnu relativt ny, version 1.0 er fra 2002. Firebird har p˚ a 1 2

http://www.pearsonptg.com/samplechapter/067232007X.pdf http://www.ca.postgresql.org/docs/devhistory.html

©nml

89


Kapitel 7: Databasesystemer - DBMSer

de f˚ a˚ ar efter i følge nogle statistikker vundet en udbredelse, der gør den en stærk konkurrent i udbredelse til MySQL. MySQL er formentligt stadig den mest udbredte af open source databaserne. Den har et ry for særlig hurtighed i forespørgsels-/informationssystemer. Udbredelsen skyldes at den har været med i open source-bevægelsen næsten fra starten. Imidlertid har MySQL i skrivende stund nogle væsentlige skavanker i forhold til den relationelle model og ogs˚ a til SQL-standarderne, der i denne forfatters øjne gør den alvorligt handicappet. Det drejer sig om manglende understøttelse af views, triggers, stored procedures og indlejrede queries. Hertil kommer, at den helt fundamentale referentielle integritet er ny, og implementeret p˚ a ustandardiseret vis. Der er endvidere udest˚ aender omkring væsentlige sikkerhedsmekanismer som transaktioner og rollback. Det skal retfærdigvis siges, at disse mangler kan imødeg˚ as af applikationsudviklerne ved ekstra programmeringsarbejde. Herved flyttes dog en del af ansvaret for den konkrete MySQLdatabases integritet væk fra selve databasesystemet og det kan næppe siges at være betryggende.

7.4 “Vinderen er” P˚ a baggrund af de teoretiske overvejelser og praktiske, hensyntagen til tilgængeligheden fra alle platforme, samt en særdeles ukompliceret installation p˚ a disse platforme, er der til denne bogs eksempelmateriale og gennemgang af praktiske problemstillinger valgt Firebird3 .

7.5

Øvelser til kapitel 7

7.5.1

Installation af RDBMS

Her er der ikke meget ny teori at øve, men der kan derimod være mening i at opfordre læseren til, hvis det ikke er sket for længe siden, at beslutte sig for et RDBMS og f˚ a det installeret p˚ a en nærtst˚ aende computer. Fra dette sted i fremstillingen vil der være data at manipulere.

3

Firebird har et web-site: http://www.firebirdsql.org/ Herfra er der links til downloads.

90

©nml


Kapitel 8

Structured Query Language Programmeringssproget SQL er det lingua franca, som i dag bruges i alle databasesystemer. SQL er en implementering af den relationelle calculus. I teoretisk forstand er SQL omdiskuteret, og den betragtes af en række eksperter med skepsis, idet det fraviger den relationelle model p˚ a væsentlige punkter. Vi er imidlertid i denne sammenhæng nødt til at gennemg˚ a den, idet der ikke ikke findes reelle alternativer. SQL er standardiseret af ISO (International Organization for Standardization). Den aktuelle standard har betegnelsen ISO/IEC 9075-n:2003, hvor n angiver et del-nummer, hvoraf der findes et antal, der hver koncentrerer sig om et emne1 . Den nuværende standard, er den fjerde i rækken. I forhold til SQL-92 udvidede SQL-99 begreberne omkring beskrivelsen af opfyldelse af standardens elementer. I SQL-92 defineredes tre niveauer for opfyldelse: Entry level, Intermediate og Full level. Entry level, som var relativt enkel at opfylde er i overensstemmelse med den amerikanske standardiseringsmyndighed ANSI’s anbefalinger. Softwareleverandørerne, der skrev de egentlige DBMSer, kunne s˚ a karakterisere deres produkt i forhold til disse niveauer. Prædikat Entry Level (Transitional) Intermediate Full

Bemærkning Svarer til ANSI-standarden Svarer til NIST-standarden, ikke en del af ISO’s SQL92

Tabel 8.1: SQL92’s niveauer. I SQL-99 betyder prædikatet Core SQL-99 at al funktionalitet fra den gamle Entry Level er implementret plus nogle helt nye ting. P˚ a den m˚ ade er der givet softwareleverandørerne en m˚ ade hvorp˚ a de ralativt hurtigt kan n˚ a fra Entry Level i SQL-92 til Core SQL-99. Udover Core SQL-99 er der defineret ni (9) tillægspakker med yderligere funktionalitet. Enhanced SQL-99 betyder s˚ aledes nu, at man er p˚ a Core SQL-99 og har implementeret mindst en yderligere af de 9 tillægspakker. SQL er tænkt med nogle ideelle standardegenskaber, der her nævnes, men senere vil blive yderligere behandlet: 1. SQL skal ligne naturligt sprog (engelsk) s˚ a meget, at det skulle kunne bruges af s˚ akaldt almindelige mennesker, uden nogen særlig programmeringsbaggrund. 2. SQL skal være et deklarativt, ikke-proceduralt sprog. 3. SQL skal være et sprog, der betjener databaseadministratoren og den almindelige bruger. 1

Find http://www.iso.ch og søg p˚ a “sql”

91


Kapitel 8: Structured Query Language

Identifikation PKG001

Navn Enhanced datetime facilities

PKG002

Enhanced integrity management

PKG003

OLAP capabilities

PKG004

SQL Persistent Stored Modules (PSM)

PKG005

SQL Call Level Interface (CLI)

PKG006

Basic object support

PKG007 PKG008

Enhanced object support Active database features

Bemærkninger Udvidelser vedr. dato, tid og intervaller. Udvidelser vedr. regler (constraints), referentiel integritet og indlejrede forespørgsler. Instrukser til brug i forbindelse med Data Varehuse (Statistik databaser). Faciliteter til programmering af moduler, der afvikles af DBMSet. Grænseflade til kald af SQLoperationer fra programmer. Basisfunktioner til objektorientering. Udvidelser til objektorientering. Support af triggere. Databasen overtager funktionalitet fra applikationerne.

PKG009

SQL Multimedia (MM) support

Faciliteter til h˚ andtering af streaming af mm-data og generel h˚ andtering af store og komplekse audio- og videodata.

Tabel 8.2: SQL99-standardens tillægspakker.

92

©nml


8.1: SQLs Systematik

4. SQL skal have sprogkomponenter til h˚ andtering af: ˆ forespørgsler ˆ indsætte, ajourføre og ændre data i databasens objekter ˆ oprette, ajourføre og slette databaseobjekter ˆ h˚ andtere brugere og sikkerhed omkring databasens objekter

5. En SQL forespørgsel skal hente data ud af relationer og aflevere resultater som relationer. Det vil fremg˚ a, at ikke alle idealer er realiserede.

8.1

SQLs Systematik

Vi har tidligere set, at en datamodel som en integreret bestanddel har operationer. I den relationelle model kan disse operationer udtrykkes p˚ a to væsensforskellige m˚ ader. Den matematisklogiske relationelle algebra udgør et antal operationer, der ligesom de fleste programmeringssprog er imperativt, dvs. fortæller DBMSet, hvad det skal gøre for at levere et givet resultat. Denne type sprog kaldes ogs˚ a procedurale sprog, idet de beskriver en procedure for løsningen af en forespørgsel/opgave. Overfor den relationelle algebra st˚ ar den relationelle calculus, der er implementeret i praksis som SQL, Structured Query Language. Mange anser det for en umulighed at undervise i relationel calculus uden at have beredt grunden med relationel algebra. Der kan være gode argumenter for denne holdning, der har sin baggrund i den matematiske logik og mængdelæren. Samtidig m˚ a det dog siges, at da der ikke findes egentlige DBMS-implementeringer af den relationelle algebra, er det vanskeligt at gøre praksisnært. Denne bog tager derfor den holdning, at læseren med passende pædagogisk hjælp fra eksempler, der kan udføres i praksis, vil kunne overvinde den forhindring. Den relationelle calculus er ogs˚ a vanskeligt tilgængelig, men SQL-implementationen anses dog for at være mere brugervenlig end begge formelle sprog, Elmasri and Navathe (2003). Hvis læseren alligevel er nysgerrig overfor den anden tilgang, findes der en fremragende kort og klar fremstilling fra Dietrich (2001). SQL adskiller sig ogs˚ a fra den relationelle algebra derved, at det er et deklarativt sprog. Det betyder, at en SQL-sætning ikke fortæller DBMSet, hvordan det skal bære sig ad med at løse en forespørgselsopgave. Derimod fortælles hvilket resultat brugeren ønsker. Hvordan dette resultat tilvejebringes er DBMSets hovedpine. Deklarative sprog kaldes ogs˚ a ikke-procedurale sprog. Her skal indskydes en kort sproglig pointe. Den engelsksprogede litteratur kalder SQLsprogets sætninger for statements. Dansksproget litteratur kalder oftest disse statements for kommandoer. Dette ord leder tanken hen p˚ a imperativer, som ville være naturlige i procedurale sprog, hvor vi bestemmer, hvordan computeren skal udføre en given opgave. Normale sprog best˚ ar jo af sætninger, der best˚ ar af ord, s˚ a sætninger ville være mere neutralt eller m˚ aske bedre, men i denne fremstilling er valgt ordet deklaration som en ikke alt for søgt oversættelse af statement, idet vi herved konstant betoner SQLs natur som deklarativt sprog. Det er bevist, at enhver forespørgsel specificeret i relationel algebra ogs˚ a kan udtrykkes i relationel calculus, og omvendt. Dette betyder at de to sprogs udtryksevne er identiske. Dette faktum har givet anledning til, at man definerer et sprog som relationelt fuldstændigt (relationally complete), hvis det kan udtrykke enhver forespørgsel, som kan udtrykkes med relationel calculus. P˚ a denne m˚ ade har vi et mindste m˚ al for ethvert nyt forespørgselssprog. SQL er et standardiseret forespørgselssprog, der er implementeret i alle DBMSer, der kalder sig relationelle. Implementationerne er dog forskellige i større eller mindre grad, men ©nml

93


Kapitel 8: Structured Query Language

der skal i denne fremstilling søges anvendt relativt konservativ SQL, dvs. SQL s˚ a tæt p˚ a standarden som praktisk muligt. Hvor der afviges, vil det blive nævnt, hvori afvigelsen best˚ ar. Resultaterne af forespørgsler i den relationelle model leveres til brugeren i form af relationer. Lidt firkantet kan man sige, at en SELECT p˚ a en tabel, ALTID resulterer i en tabel. Her er imidlertid en alvorlig skavank i forhold til den relationelle model, og som Date (2005) dokumenterer en skavank, der kan medføre meningsforstyrrende problemer. SQL returnerer altid tabeller som svar p˚ a SELECT-deklarationer, men disse tabeller er bestemt ikke altid relationer. Det betyder for eksempel, at dubletter kan forekomme i rigt m˚ al, hvis man ikke gør noget aktivt for at forhindre det. Udover SQLs anvendelse til forespørgsler og manipulation af databasens data, kan sproget h˚ andtere databasens egne objekter, dvs. skabe, vedligehold og slette fx relationer. Hertil kommer oprettelse, vedligeholdelse og sletning af brugere, der har rettigheder i forhold til ovennævnte objekter.

8.1.1

SQL-92 struktur

N˚ ar man betragtede SQL faldt det i tre dele ;-) Sprogets deklarationer kan grupperes efter form˚ al i klasser, der karakteriserer anvendelsen. Man opfattede groft sagt den gamle standard, SQL-92, som inddelt i tre klasser. Se tabel 8.3. Klasse

Bemærkninger

Deklarationer

DDL

Akronym for Data Definition Language. Deklara-

CREATE, ALTER, DROP

tionerne i denne gruppe bruges til oprettelse, vedligeholdelse og sletning af databasens strukturelle objekter, ikke til brugerens data. DCL

Data Control Language. Bruges til tildeling og

GRANT, REVOKE

fratagelse af rettigheder til databasens strukturelle objekter. DML

Data Manipulation Language. Disse deklarationer

INSERT, UPDATE, DELETE, SE-

bruges til skrivning, vedligeholdelse, sletning og læs-

LECT

ning af data i databasen, ligeledes her oftest i brugerens data.

Tabel 8.3: SQL-92 klassifikation af deklarationer.

8.1.2

SQL-2003 struktur

Heroverfor st˚ ar de nyere standarder fra 1999, henholdsvis 2003. ISO/IEC 9075:1999 er den officielle betegnelse for et værk i 10 dele, nummereret fra 1-5 og 9-14 ;-) De mellemliggende manglende numre er korrektur og tilføjelse til del 5. SQL-99 klassificerer alle SQLs deklarationer, hvor den gamle standard efterlod en række ”forældreløse deklarationer udenfor klasserne. Inddelingen er finere og anderledes navngivet, jf. tabellen herunder: Siden er der kommet en endnu nyere udgave af SQL-standarden, ISO/IEC 9075: 2003. Den adskiller sig ikke strukturelt fra 1999-standarden, men indeholder en lang række rettelser og noget nyt. Det nye i 2003-standarden er ikke væsentligt for denne fremstilling. Figur 8.4 viser klassifikationen i SQL99, der tager h˚ and om sine deklarationer. Den forrige standard havde sin gruppering, men et anseligt antal deklarationer fandt ikke en plads i den klassifikation. 94

©nml


8.2: Øvelser til kapitel 8 Klasse

Bemærkning

Vigtige deklarationer

SQL Connect

Etabler, henholdsvis nedbryd forbindelse fra klient

CONNECT, DISCONNECT

til DBMS-server. SQL Control

Styring

af

afviklingen

af

en

gruppe

SQL-

CALL, RETURN

deklarationer, typisk en s˚ akaldt stored procedure. SQL Data

H˚ andtering af data. Indsættelse, ajourføring, slet-

INSERT, UPDATE, DELETE,

ning og læsning af (oftest) brugerdata. Svarer til

SELECT

SQL92 DML. SQL Diagnostic

Diagnostisk information og h˚ andtering af fejlmed-

GET DIAGNOSTICS

delelser. SQL Schema

Deklarationerne i denne gruppe bruges til oprettelse,

CREATE, ALTER, DROP

vedligeholdelse og sletning af databasens struk-

GRANT, REVOKE

turelle objekter, fx relationer. Ikke til slutbrugerens data. SQL Session

Sessionsstyring, der bl. a. bruges til at etablere

SET

konsistenspunkter i forbindelse med sikring mod eventuelle nedbrud. SQL Transaction

Grupperer et antal INSERT, UPDATE og/eller

COMMIT, ROLLBACK

DELETE i transaktioner, der under et kan ”ugøres”, hvis der opst˚ ar fejlsituationer.

Tabel 8.4: Nuværende klassifikation af SQL-deklarationer

8.2 8.2.1

©nml

Øvelser til kapitel 8 bla bla

95


Kapitel 8: Structured Query Language

96

Šnml


Kapitel 9

SQL Tutorial - SQL Skema Dette og det følgende kapitel er en tutorial i SQL. Det intenderer ikke at være en komplet, systematisk tutorial for derved at kunne st˚ a selvstændigt som materiale i et SQL-kursus. Derimod er hensigten af bibringe læseren en eksemplificeret gennemgang af væsentlige og dagligdags anvendelige dele af SQL som programmeringssprog og værktøj. En traditionel og velstruktureret gennemgang af SQL ville m˚ aske vælge at starte med at etablere relationer førend det gennemg˚ as hvordan de ændres og eller slettes, og først derefter befolke relationerne med data. Efter at databasen s˚ aledes er befolket kunne man sætte sig ind i læsninger, opdateringer og sletninger af data fra databasens relationer. Et alternativ kunne, m˚ aske ikke særligt pædagogisk, som en del online dokumentation gør det, være at vælge at gennemg˚ a SQL som man læser et leksikon, alfabetisk sorteret. P˚ a baggrund af egen undervisningserfaring med særdeles nyttig feedback fra studerende er her valgt en tredie m˚ ade. Studerende har forskellige læringsstile, og mange har derfor ønsket s˚ a tidligt som muligt at kunne anvende den lærte teori i praksis. Derfor skal her introduceres en eksempeldatabase, der kun meget kort og summarisk illustreres med sin etablerende SQL. N˚ ar dette er gjort vil gennemgangen starte med læsninger i databasen, for derefter at se p˚ a indsættelse, opdatering og sletning af data. Dette omr˚ ade kaldes af standarden for SQL Data. Der er s˚ aledes valgt en meget brugsorienteret systematik, som derefter vil dreje sig mod etableringen af databasens objekter, relationerne med videre. Det vi kalder SQL Schema deklarationerne. Den opmærksomme læser vil se, at eksempeldatabasens opbygning lider af nogle logiske mangler, som vil blive kommenteret og repareret under diskussionen i denne tutorial.

9.1

Eksempeldatabasen

Førend vi starter p˚ a en mere systematisk gennemgang af SQL, er det p˚ a sin plads at vise det databasefragment, som de første eksempler bygger op. Se figur 9.1. Det er i kapitel 6 gennemg˚ aet, hvordan man p˚ a baggrund af en ER-model skaber den relationelle database. Til dette databasefragment knytter sig følgende relationelle tabelskemaer: BOG(bog_id, bog_titel, isbn, udgivet_aar, udlaanes_dage, status_pris, emne_kode, emne_nr) EMNE(emne_kode, emne_nr, emne_navn, udlaanes_dage)

Tabel 9.1: Eksempeldatabasens relationer. De to viste tabelskemaer beskriver de relationer, der indeholder de eksempeldata, der vil indg˚ a i den efterfølgende SQL-tutorial. Relationerne bog og emne er fra en simuleret bib97


Kapitel 9: SQL Tutorial - SQL Skema

Figur 9.1: Et fragment af en ER-model af en biblioteksdatabase til SQL-eksemplerne. lioteksdatabase, og udgør absolut kun et segment af en s˚ adan. De viste relationer indeholder som nævnt nogle ”pædagogiske” svagheder, der vil blive afhjulpet gradvist undervejs. Hvis læseren af pædagogiske, eller andre grunde skulle ønske at starte denne SQL tutorial med SQL Data, kan man med fordel gennemføre aktiviteten vist herunder i afsnit 9.2.1 for derefter at udføre aktiviteterne fra bilag C, og s˚ a læse videre i kapitel 10. Herved f˚ ar man etableret en aktiv udgave af eksempeldatabasen til eksperimenter. Resten af indeværende kapitel kan s˚ a læses p˚ a et senere tidspunkt.

9.2

SQL Schema - indledning

SQL Schema deklarationerne (DDL) er beregnet til at oprette, vedligeholdelse og sletning af databasens strukturelle objekter, hvoraf de vigtigste vel er typer og relationer. I tillæg til den strukturelle opbygning varetager SQL Schema deklarationer ogs˚ a implementering af datamodellens regler (constraints) for domæner, b˚ ade gennem datatyper og yderligere begrænsninger til disse. Hertil kommer sikring af databasens objekter i forhold til brugere og brugergrupper.

9.2.1

Skab en database

Der er forskel p˚ a hvordan forskellige databasesystemer skaber en database. Nogle systemer har et dedikeret program til netop dette, mens andre gør det ved hjælp af en enkelt standardiseret SQL-instruks1 . CREATE DATABASE ’sti/til/database/databasenavn’;

Tabel 9.2: Lad os begynde med begyndelsen. Bruges en grafiske klient er der ofte menuvalg til oprettelsen af en database, s˚ a det ikke i den situation skal gøres med en SQL-instruks. N˚ ar databasen er oprettet er det tid at koncentrere sig om to af de helt centrale objekter i en relationel database, relationer og domæner.

9.2.2

Datatyper

SQL Schema deklarationerne skal oprette databasens strukturelle elementer. N˚ ar deklarationerne til etablering af relationer skal anvendes, forudsættes at de definerede attributter erklæres med angivelse af datatype for hver enkelt attribut. Det er derfor nyttigt at se p˚ a datatyper inden vi g˚ ar i gang med SQL Schema. Lad os med Kline and Kline (2001) se en skematiseret opstilling af SQL99s datatyper. 9.2.2.1

Implementation af datatyper

Det skal betones, at det m˚ a anses for en selvfølgelighed, at DBMSerne, der implementerer disse ting, varierer, ikke blot fra standarden p˚ a varierende punkter, men ogs˚ a fra hinanden. Det er derfor vigtigt, at man støtter sig til sin konkrete DBMS dokumentation. 1

Produktdokumentation til Firebird er bl. a. “InterBase 6 - Data Definition Guide.”

98

©nml


9.2: SQL Schema - indledning

Kategori Binære

Datatyper binary large object (blob)

Bitstrenge

bit, bit varying

Boolske

boolean

Tegn

char, character varying (varchar) national character nchar (nchar) national character varying (nvarchar) character large object (clob) national character large object (nclob) smallint integer, int bigint numeric(p,s) decimal, dec (p,s)

Numeriske

float(p) real double precision

Tidsmæssige

date time time with zone timestamp timestamp with zone interval

Beskrivelse Til opbevaring af binære eller hexadecimale strenge (oftest lange), fx billeder, lyde, ... Binære eller hexadecimale data. bit har fast længde, mens bit varying har variabel længde. Sandhedsværdier, hvoraf der (besynderligt nok) findes tre: TRUE, FALSE og UNKNOWN Kan indeholde enhver tænkelig tegnfølge fra det relevante tegnsæt. Datatyperne med betegnelsen varying er af variabel længde, mens de øvrige har fast længde. Fastlængdefelter udfylder de ikke-benyttede tegnpositioner, mens de variable kun fylder det anvendte antal tegn.

De 5 førstnævnte numeriske datatyper opbevarer nøjagtige værdier, og det gælder, at det konkrete DBMS fastsætter præcisionen P, højeste antal cifre s˚ aledes at Psmallint 5 Pint 5 Pbigint . Typerne numeric og decimals præcision er ligeledes bestem af implementeringen, dvs DBMSet. Standarden siger om begge, at de har implementeringsvalgt præcision og scale, antal decimaler. Forskellen er at ved brug af numeric er præcisionen p, mens den ved brug af decimal er mindst p. Float tager en tilnærmet værdi med et givent maksimalt antal cifre (p). Real og double tager tilnærmede værdier med mindst givent maksimalt antal cifre. Double skal efter standarden have større præcision end real.. Date og time er der ingen kommentarer til. With time zone indebærer et suffix til værdien med difference i forhold til GMT (= UCT). Timestamp er en tidsangivelse baseret p˚ a værtsmaskinens tid p˚ a opbevaringstidspunktet. Interval angiver tidsforskelle.

Tabel 9.3: SQL-03 Datatyper.

©nml

99


Kapitel 9: SQL Tutorial - SQL Skema

9.2.3

Nøgler

Saml op p˚ a nøglebegreber og forklar behov og SQLs mangler

9.3

Relationer

Lad os atter engang kort rekapitulere, 4, Chens matematiske definition af en relation R p˚ a domænerne X1 , X2 , ..., Xn : R = {(x1 , x2 , ..., xn )|x1 ∈ X1 , x2 ∈ X2 , ..., xn ∈ Xn } En attribut tilhørende et domæne, der i den relationelle sprogbrug definerer værdimængden for en relations attributter, defineres matematisk s˚ aledes, idet vi kan tage et helt konkret eksempel:

xi = {(udgivet aar)|udgivet aar ∈ aarstal} Eller p˚ a almindeligt dansk: Vi definerer en attribut udgivet aar med navnet udgivet aar for hvilken det gælder, at den tilhører domænet aarstal. N˚ ar vi nu ved hvordan en relation er defineret, er vi klar til at formulere den overfor DBMSet ved hjælp af SQL.

9.3.1

CREATE TABLE

Lad os som første eksempel se p˚ a den SQL-kode, der opretter de to eksempelrelationer. Disse kodeeksempler findes ogs˚ a i bilag C sammen med testdata til relationerne. For en ordens skyld skal der gøres opmærksom p˚ a, at relationen bog overtræder en række gængse krav til god kvalitet, som læseren straks vil kunne forvisse sig om. Det er gjort s˚ adan for at kunne

Figur 9.2: Bog-emne i ER-modellen fremhæve nogle aspekter ved SQL i den efterfølgende SQL Data tutorial, og udgør p˚ a ingen m˚ ade et eksempel til efterfølgelse. I afsnit 9.3.2 er en alternativ og bedre, omend heller ikke perfekt, udgave skitseret. Oprettelsen sker ved hjælp af CREATE TABLE deklarationen. Først bog: 100

©nml


9.3: Relationer create table bog ( bog_id

integer not null primary key,

bog_titel

varchar(40),

isbn

char(13),

udgivet_aar

integer,

indgaaet_dato

date default ’now’,

udlaanes_dage

int,

status_pris

numeric(6,2),

emne_kode emne_nr

char(2), int

);

Tabel 9.4: Create table - oprettelse af relationen bog. Derefter emne-tabellen:

create table emne ( emne_kode char(2) not null, emne_nr int not null, emne_navn varchar(50) not null, udlaanes_dage int not null default 30, primary key(emne_kode, emne_nr) );

Tabel 9.5: Create table - oprettelse af relationen emne.

Det fremg˚ ar, at den principielle opbygning af deklarationen er create table <tablenavn> (...);,

hvor navnet er valgfrit indenfor visse grænser, og at der i parentes anføres et antal attributter efter behov, samt at hver attribut tilknyttes en datatype og eventuelt yderligere regler. I definitionen af bog kan læses, at bog_id er et heltal (integer), at vi ikke vil acceptere, at det ikke tildeles en værdi (not null) og at det udnævnes til primærnøgle (primary key). Herefter nogle attributter, der kun tilknyttes datatyper. Længere ned ses indgaaet_dato, hvor det bestemmes, at der, hvis en værdi ikke oplyses p˚ a insert-tidspunktet, skal indsættes værtsmaskinens aktuelle dato som standardværdi (default). Emne-relationen adskiller sig fra bog især ved den m˚ ade, hvorp˚ a primærnøglen er defineret. Man behøver ikke deklarere nøgler p˚ a samme m˚ ade som under bog. Det kan altid gøres, som ved emne, i en selvstændig linje til sidst. Hvis nøglen best˚ ar af mere end en attribut skal det gøres med angivelsen primary key(att1[,att2[,..,attn]]), hvor parentesen alts˚ a indeholder en kommasepareret liste med mindst et element. Ved udnævnelse af en attribut til primærnøgle eller del af en s˚ adan, skal attributten i forvejen være forsynet med en not null-regel.

9.3.2

Yderligere regler

Til illustration af yderligere begrænsninger p˚ a domæner omkring enkelte attributter, samt h˚ andteringen af kandidatnøgler og fremmednøgler kan vi forestille os en alternativ definition af relationen bog: ©nml

101


Kapitel 9: SQL Tutorial - SQL Skema create table bog ( bog_id integer not null check (bog_id > 0), bog_titel varchar(40) not null, isbn char(13) not null, udgivet_aar integer not null check (udgivet_aar between 1930 and 2050), indgaaet_dato date default ’now’ not null , udlaanes_dage int, status_pris numeric(6,2) default 0.00 not null, emne_kode char(2) not null, emne_nr int not null, primary key(bog_id), unique(isbn), foreign key (emne_kode, emne_nr) references emne(emne_kode, emne_nr) );

Tabel 9.6: Alternativ definition af bog.

9.3.2.1

Check

Reglen check siger, at DBMSet skal h˚ andhæve en regel. En check, som i linje 3 eller 7, knytter sig til en enkelt attribut. Den begrænser attributtens domæne udover det, der implicit følger af datatypen. Vi ser i de to tilfælde felter, definerede som heltal, f˚ a begrænset deres mulige værdier til en delmængde af heltal, i øvrigt p˚ a to forskellige m˚ ader.

9.3.2.2

Unique

Ved udnævnelsen af en attribut til primærnøgle sikrer vi entydighed p˚ a den attribut. Hvis primærnøglen er udvalgt blandt to eller flere kandidatnøgler, hvorved de øvrige bliver til alternativnøgler, bør vi sikre integriteten omkring alternativnøglerne ved at erklære dem unique, linje 15. Herved vil DBMSet kontrollere, ligesom ved primærnøglen, at der ikke findes to forekomster af rækker med samme værdi for den p˚ agældende attribut. I den konkrete situation kunne vi have valgt bogens isbn som primærnøgle. Kandidaterne var bog_id og isbn. Vi valgte bog_id, hvorved isbn blev “reduceret” til alternativnøgle.

9.3.2.3

Fremmednøgler

Databasens referentielle integritet sikres ved hjælp af fremmednøgler. Begrebet referentiel integritet dækker jo over, at vi ikke fra en relation skal kunne angive værdier som knytter relationen til en eller flere andre relationer, uden at sikre at de relevante forekomster af disse referencer, som naturligvis skal være til primærnøgler, rent faktisk eksisterer i databasen. Ved definition af en attribut som fremmednøgle skal den refererede relation allerede være oprettet i databasen, s˚ a der opst˚ ar her et krav om en orden i relationernes oprettelsesrækkefølge. Vi skal dog se senere, at dette krav om orden kan fraviges, hvis man vælger altid at oprette fremmednøglereferencer ved hjælp af alter table-deklarationen. I det givne eksempel var kravet dog stadig at emne allerede var oprettet. Den anføres herunder ogs˚ a i en alternativ formulering.

9.3.2.4

En alternativ deklaration af emne

Lad os ogs˚ a se p˚ a en alternativ deklaration til tabellen emne: 102

©nml


9.3: Relationer create table emne ( emne_kode char(2) not null check (emne_kode in (’NF’,’SK’,’CS’,’IT’)), emne_nr int not null check (emne_nr between 0 and 999), emne_navn varchar(50) not null, udlaanes_dage int not null default 30 check (udlaanes_dage between 0 and 45), primary key(emne_kode, emne_nr) );

Tabel 9.7: Alternativ definition af emne.

Hvorfor den alternative deklaration? I relationen bog valgtes ikke at lave check p˚ a attributterne emne_kode og emne_nr, da disse jo refererer til primærnøglefelterne i emne. Fremmednøgle referencen fra bog til emne vil s˚ aledes medføre, at RDBMSet vil have kontrolleret validiteten i emne førend vi fra bog kan referere til den.

9.3.3

ALTER TABLE

Med ALTER TABLE giver SQL et begrænset udbud af ændringsmuligheder for en tabel, der allerede er oprettet og eventuelt befolket med data. I en udviklingssituation, hvor databasen enten endnu ikke er befolket, eller blot befolket med testdata, vil det oftest være mere alsidigt anvendeligt at slette tabeldefinitionen med DROP TABLE, for derefter at genoprette den med en ændret CREATE TABLE. En alter table tillader oprettelse, ændring og sletning af attributter i en relation, samt oprettelse eller sletning af integritetsregler for relationen. Der er dog visse indskrænkninger i mulighederne. Kort sagt kan en relation ikke ændres, hvis ændringen medfører, at relationen eller dens attributter derved kommer i modstrid med gældende integritetsregler. Hvis eksisterende data i relationen ved en sletning af en attribut kommer i modstrid med gældende primary key, unique eller foreign key-regler, kan attributten ikke slettes. Er en attribut refereret i en check-regel, kan den ikke slettes. I visse tilfælde kan ændringer først foretages, hvis integritetsregler som de m˚ atte stride imod, fjernes. Omvendt kan tilføjes integritetsregler, der ikke strider mod en attributs værdi i nogen forekomst i relationen. Der kan s˚ aledes ikke tilføjes en not null-regel, hvis der allerede i databasen er forekomster, hvor den p˚ agældende attribut er null. Er der ikke nulls i en attribut, er der derimod ikke nogen hindring for at p˚ alægge en not null-regel ved hjælp af alter table. Konkrete DBMSer har ogs˚ a her forskelle til SQL-standarden, b˚ ade syntaktisk og med hensyn til funktionalitet. Da r˚ aderummet for ændringer samtidig er begrænset, er det (ogs˚ a her) særdeles anbefalelsesværdigt, at bruge DBMSets dokumentation, n˚ ar der ændres i databasestrukturen. Især bør man kontrollere om DBMSet truer med datatab ved brug af alter table. Lad os først se p˚ a bogs definition i DBMSets terminologi, fremkaldt af den i Firebird proprietære deklaration show tables <relationsnavn>: ©nml

103


Kapitel 9: SQL Tutorial - SQL Skema show tables bog; BOG_ID

INTEGER Not Null

BOG_TITEL

VARCHAR(40) Not Null

ISBN

CHAR(13) Not Null

UDGIVET_AAR

INTEGER Not Null

INDGAAET_DATO

DATE Not Null default ’now’

UDLAANES_DAGE

INTEGER Nullable

STATUS_PRIS

NUMERIC(6, 2) Not Null default 0.00

EMNE_KODE

CHAR(2) Not Null

EMNE_NR

INTEGER Not Null

CONSTRAINT INTEG_21: Foreign key (EMNE_KODE, EMNE_NR) References EMNE (EMNE_KODE, EMNE_NR) CONSTRAINT INTEG_19: Primary key (BOG_ID) CONSTRAINT INTEG_20: Unique key (ISBN) CONSTRAINT INTEG_10: check (bog_id > 0) CONSTRAINT INTEG_14: check (udgivet_aar between 1930 and 2050)

Tabel 9.8: Firebirds visning af en relationsdefinition for bog. Bemærk parentetisk, at DBMSet navngiver alle regler (constraints), hvis vi ikke selv gør det. Vi kunne indsætte et ”glemt” felt i relationen ved hjælp af

alter table bog add indkoebt_indbundet char(1) default ’n’ not null check(indkoebt_indbundet in(’j’, ’n’, ’J’, ’N’));

Tabel 9.9: Eksempel p˚ a alter table med udvidelse med en ny attribut. Eksempel-DBMSet tillader faktisk at nye attributter indsættes et bestemt sted i sekvensen af attributter, men da dette faktisk er meningsløst i forhold til den relationelle model ifølge hvilken, der ikke er nogen rækkefølge, er det undladt i eksemplet. Det valgte felt er endvidere en oplagt kandidat til datatypen boolean, men netop den er ikke implementeret i DBMSet p˚ a trods af, at den er en del af standarden. Lad os nu for eksemplets skyld antage, at vi ønsker at harmonisere bog_titel og emne_navn (jf. tidl. visning), til at tilhøre samme domæne. Vi skulle nu enten omdefinere bog_titel fra højst at være 40 tegn til nu 50 tegns maksimallængde, eller vi skulle indskrænke bog_emne til højst 40 tegns længde. Sidstnævnte g˚ ar ikke an i vores eksempel-DBMS, idet der jo kunne være oprettet forekomster allerede, hvor de 40 tegn er overskredet. Førstnævnte er tilladt:

alter table bog alter bog_titel type varchar(50);

Tabel 9.10: Eksempel p˚ a alter table med ændring af en attributs karakteristika. Eller lad os sige, at tabellens regel om at udgivet aar skulle begrænses til at ligge mellem 1930 og 2050 var fejlagtig, og at vi ønskede at slette reglen: 104

©nml


9.4: Domæner alter table bog drop constraint integ_14;

Tabel 9.11: Alter table bruges til at slette en regel for en enkelt attribut. Det er indlysende, at ønsker vi at slette en af de automatisk navngivne regler, m˚ a vi bruges RDBMSets faciliteter til først at finde navnet p˚ a reglen.

9.3.4

DROP TABLE

DROP TABLE sletter en defineret relation samt alle andre strukturelle objekter, der knytter sig til den. Det kan være indekser, diverse regler, triggere og tilladelser, der m˚ atte være GRANTet til relationen. Data, der befolker tabellen vil ogs˚ a blive slettet! Deklarationerne drop table bog; drop table emne;

Tabel 9.12: Sletning af relationsdefinitioner. ville i givet fald slette bogdatabasens to tabeller. En simpel syntaks m˚ a man sige. Standardsyntaksen har ogs˚ a en mulighed for at checke om der er referencer i de relationer, der skal slettes og i givet fald specificere, at disse skal enten bevares eller slettes sammen med relationen.

9.4

Domæner

Domains som semantiske datatyper jf Date p 238

9.4.1

CREATE DOMAIN

Konstateres det under design af databasen, at relationer har identiske domæner, enten i samme relation eller p˚ a tværs af relationerne, kan det være særdeles nyttigt og arbejdsbesparende at definere s˚ adanne domæner med en CREATE DOMAIN-definition, for derved efterfølgende at kunne referere til domænet i create table-deklarationer, hvor et domæne refereres som en datatype. Der kan være gode argumenter for at definere domæner dækkende alle de attributter, der kan blive brug for i en database. Derved vil alle attributdefinitioner i CREATE TABLE skulle referere egne domæner og alts˚ a kun indirekte datatyperne. Lad os se et konkret eksempel:

create domain middel_langt_tekstfelt varchar(50) not null;

Tabel 9.13: Domænedefinition. Denne deklaration kunne straks implementeres i de to eksisterende relationer med følgende to deklarationer: alter table bog alter bog_titel type middel_langt_tekstfelt; alter table emne alter emne_navn type middel_langt_tekstfelt;

Tabel 9.14: Implementering af den nye domænedefinition. ©nml

105


Kapitel 9: SQL Tutorial - SQL Skema

Et andet eksempel, denne gang med en check-klausul tilføjet. Check virker i domæner p˚ a samme m˚ ade som anvendt i forbindelse med attributter i henholdsvis CREATE og ALTER TABLE. Bemærk at i check for domæner er der ikke noget attributnavn, s˚ aledes om vi s˚ a det ved check i create table-deklarationen. Dette skyldes, at domænet kan knyttes til arbitrært mange forskellige attributter. I stedet for attributnavn bruges nøgleordet value. create domain my_boolean char(1) default ’F’ not null check(value in (’F’, ’T’)); alter table bog drop constraint integ_23 ; alter table bog alter indkoebt_indbundet type my_boolean;

Tabel 9.15: Udskiftning af en tidligere regel med en ny, implementeret gennem et domæne. Eksemplet viser i tillæg til etablering af domænet, hvordan det kunne implementeres i begge relationer. Til domæner findes ogs˚ a b˚ ade ALTER DOMAIN og DROP DOMAIN, ligesom der gør til alle andre SQL SCHEMA-deklarationer. Læseren opfordres til at sætte sig ind i disses virkem˚ ade ved hjælp af det konkrete DBMS dokumentation.

9.5

En praktisk digression

Som afslutning p˚ a denne ekstraordinært korte tutorial i SQL Schema deklarationer skal medtages en, der har stor praktisk betydning. Det drejer sig om create generator.

9.5.1

CREATE GENERATOR

En generator genererer en værdi, som ved hjælp af en standardfunktion kan bringes til at automatisere indsættelse af værdier i fx nøglefelter, hvor man ønsker løbenumre som nøgler. create generator genial; set generator genial to 10001; insert into bog values( gen_id(genial, 1), ’Grammer Guide’, ’0-7475-13856’, 1993, ’28-sept-2004’, null, 128.00, ’NF’, 0, ’T’);

Tabel 9.16: Etablering, initialisering og anvendelse af en generator. Det skal bemærkes, at SQL-standarden, fra SQL-99, beskriver generatorer, og foreskriver deklarationen CREATE SEQUENCE til oprettelse. Den viste er s˚ aledes Firebirds version af en generator. Man kan ikke forvente at andre DBMSer implementerer dem p˚ a samme m˚ ade. Første linje er SQL Schema deklarationen til oprettelse af generatoren. En generator er her et heltal, der ved oprettelse initialiseres til værdien 0. Næste linje er en SQL Data deklaration til at give generatoren en startværdi, hvis man ikke er tilfreds med standardværdien. Den tredie deklaration er en SQL Data insert-deklaration, der, som det vises, benytter gen_id(genial,1) til indsættelse af værdi i den attribut, der skal have en automatisk genereret værdi. Funktionen gen_id har som argumenter navnet p˚ a den relevante generator og det tal som generatoren skal inkrementeres med. En anden proprietær ting ved Firebirds generator er det, at de ikke slettes med DROP, som man skulle forvente, men derimod med: DELETE FROM RDB$GENERATOR WHERE RDB$GENERATOR_NAME =

106

genial;

©nml


9.6: SQL Schema - sikkerhed

hvor RDB$GENERATOR er navnet p˚ a den systemtabel, der beskriver generatorer.

9.6

SQL Schema - sikkerhed

GRANTs og REVOKE - brugere

9.6.1

GRANT

GRANT er SQL Schema deklarationen til tildeling af rettigheder til databasens objekter. Rettigheder tildeles brugere eller grupper af brugere. GRANT ALL on BOG to nml; GRANT SELECT on bog to nobody;

9.6.2

REVOKE

REVOKE er SQL Schema deklarationen til fratagelse af rettigheder til databasens objekter. REVOKE DELETE on BOG from nml;

9.7 9.7.1

Øvelser til kapitel 9 Øvelse

Find øvelse 6.2.1. Den refererer til øvelse 3.4.2.3. P˚ a baggrund af resultaterne herfra implementeres nu den udarbejdede database i dit yndlings-RDBMS.

©nml

107


Kapitel 9: SQL Tutorial - SQL Skema

108

Šnml


Kapitel 10

SQL Tutorial - SQL Data SQL Data omfatter den gruppe SQL-deklarationer, der bruges til manipulation af databasens data. Det er s˚ aledes ved hjælp af disse at brugeren varetager den daglige vedligeholdelse af egne data. Gruppen best˚ ar blot af, INSERT, UPDATE, DELETE og SELECT, som vil blive eksemplificeret herunder. De eksempler der findes herunder er alle baserede p˚ a relationernes indhold som resultatet af de insert deklarationer, der er vist sammen med create table-deklarationerne i app. C.

10.1

SELECT

SELECT deklarationen er den helt centrale deklaration i SQL. SELECT bruges i alle forespørgsler fra en database. Idet vi husker, at det fundamentale objekt i databasen er en relation, kan vi udtrykke det s˚ adan, at SELECT udvælger nogle data fra en relation fra databasen. SELECT resulterer som bekendt i en (temporær) tabel, der præsenteres for brugeren.

10.1.1 10.1.1.1

SELECT-eksempler SELECT situation 1

Det første eksempel p˚ a select er det simplest mulige, læs alle kolonner fra bog. Man kan m˚ aske foretrække at indtaste deklarationer s˚ a der formatteres med linjerne for overskuelighedens skyld. S˚ a følgende varianter er semantisk identiske:

select * from emne; select * from emne;

Tabel 10.1: To varianter af select all Deklarationen select efterfølges af et s˚ akaldt wild card, her en * (asterisk), der udtales all, det engelske ord for alle. Betydningen er alle attributter. Da vi ikke her har gjort noget for at begrænse det, vil alle tabellens rækker blive læst og vist. Resultatet ses herunder: 109


Kapitel 10: SQL Tutorial - SQL Data EMNE_KODE EMNE_NR EMNE_NAVN UDLAANES_DAGE ========= ============ ================================================== ============= IT 202 Indføring i PHP 30 IT 167 Databaseteknik 30 IT 272 Kunstig intelligens 30 SK 1 Agent- og spionromaner 45 IT 200 Programmering med scriptsprog 30 SK 0 Diverse fiction 30 IT 100 Grundlæggende informationsvidenskab 30 IT 201 Indføring i JavaScript 30 NF 30 Ordbøger og leksika 0 NF 0 Diverse non-fiction 30 IT 168 Datamodellering 30 SK 60 Lyrik 45 IT 203 Objektorientering i PHP 0

Tabel 10.2: Resultat af en select * from emne; Det er værd at hæfte sig ved rækkefølgen i ovenst˚ aende udskrift. Den relationelle teori indebærer, at elementerne i en relation ikke har nogen rækkefølge. Følgeligt kommer de udskrevne elementer i en tilsyneladende tilfældig rækkefølge. Hvis vi ønsker, at se dem i en speciel orden, m˚ a vi fortælle dette i deklarationen.

Advarsel Der kan være grund til at advare mod ovenst˚ aende ellers tilsyneladende praktiske skrivem˚ ade for en select-deklaration. Det er et grundlæggende princip at tilstræbe datauafhængighed. Laves der ændringer i relationer i databasen, tilstræber vi, at der kun skal ændres i de programmer, der netop bruger de ændrede elementer i databasen, og ikke i alle programmer. Har man anvendt deklarationen select * for at f˚ a alle attributter fra en eller flere relationer ud som output, og derefter formateret en tabellarisk visning af de resulterende data, kan man senere støde ind i problemer. Lad os antage, at der ved en alter table er tilføjet en eller flere attributter til en relation. En programmeret tabellarisk visning af en s˚ adan relation, vil derfor kunne blive forkert eller vildledende p˚ a grund af denne alter table. Datauafhængigheden er s˚ aledes kompromitteret. Der er derfor grund til forsigtighed med anvendelsen af select *. I stedet bør man overveje generelt altid at bruge select med attributnavne, jf. afsnit 10.1.1.2.

10.1.1.2

SELECT situation 2

Det følgende eksempel gør dette ved hjælp af en order by <attributnavn>. Eksemplet viser samtidigt hvordan man udtrækker specificerede attributter fra relationen. Man nævner attributnavne i en kommasepareret liste.

select bog_id, bog_titel, isbn from bog order by bog_id;

Tabel 10.3: Select med attributnavne og sortering af output. Resultatet ses her i tabel 10.4: 110

©nml


10.1: SELECT BOG_ID ============ 1 10 11 12 13 14 15 21 22 23 10114 10115 10225 19875 19899 100001 100002

BOG_TITEL ======================================== IT kommunikation The Code Book Teach Yourself JavaScript 1.3 in 24 Hrs Learning Python, 2nd ed. Fundamentals of Database Systems An Introduction to Database Systems IT kommunikation DanskOrdbogen The New Penguin English Dictionary The New Penguin Thesaurus The Concepts of Programming Languages The Database relational Model The cathedral and the Bazaar The Practice of Programming Tcl and the Tk Toolkit The Web Wizards Guide to XHTML Kunsten at skrive speciale

100012 SQL in a Nutshell

ISBN ============= 87-7281-104-8 1-85702-879-1 0-672-31407-X 0-596-00281-5 0-201-54263-3 0-201-38590-2 87-7281-104-8 87-7783-926-9 0-14-029310-8 0-14-029311-6 0-201-38596-1 0-201-61294-1 0-596-00108-8 0-201-61586-X 0-201-63337-X 0-321-17868-8 87-500-3477-4 1-56592-744-3

Tabel 10.4: Output fra SQL-deklarationen i tabel 10.3. 10.1.1.3

SELECT situation 3

Endnu et eksempel med order by, der denne gang er i faldende orden, descending. Bemærk her yderligere to ting, nemlig hvordan udskriften af bogens titel ikke længere har attributnavnet som kolonneoverskrift, og at der kan sorteres p˚ a en attribut, der ikke indg˚ ar i udtrækket. select bog_titel “TITEL”, isbn from bog order by emne_nr desc;

Tabel 10.5: Select med ændring af kolonneoverskrift og sortering i faldende orden.

Det er ikke givet, at relationernes attributnavne er egnede som kolonneoverskrifter i præsentation af output. Derfor giver SQL programmøren en mulighed for at angive en alternativ kolonneoverskrift. I eksemplet i tabel 10.5 ser vi konstruktionen ... bog_titel “TITEL”, som fortæller, at select-deklarationen skal vælge attributten bog-titel, men i outputtet give kolonnen overskriften TITEL. Bemærk at der ikke er noget komma mellem attributnavnet og den alternative overskrift. Best˚ ar den alternative overskrift af mere end et enkelt ord, skal den st˚ a i anførselstegn. Ellers kan disse udelades. 10.1.1.4

SELECT situation 4

Vi har nu set en række eksempler p˚ a selects, hvoraf ingen gør sig nogen anstrengelse for at reducere antallet af rækker i udtrækket. Det er derfor naturlig nu at interessere sig for denne problemtik, der løses ved hjælp af en where-parameter p˚ a deklarationen. Se nu p˚ a den efterfølgende liste af eksempler p˚ a select ... from ... where ... De udmærker sig ved at indeholder hver sin variant af brug af where. select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where emne_nr between 100 and 200;

Tabel 10.6: Hent udvalgte attributter fra udvalgte tupler, der opfylder en given betingelse. ©nml

111


Kapitel 10: SQL Tutorial - SQL Data

Select-betingelsen sørger for, at kun en delmængde af relationens tupler vises. Denne variant af en select svarer til algebraens select efterfulgt af en projektion p˚ a de ønskede attributter.

select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where udgivet_aar in (2000,2001,2002) order by bog_titel;

Tabel 10.7: Hent udvalgte kolonner fra udvalgte tupler, hvori en attribut er lig med en af et udvalg, Sorter visning. select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where udgivet_aar not in (2000,2001,2002);

Tabel 10.8: Hent udvalgte attributter fra tupler der ikke opfylder en given betingelse.

select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where udgivet_aar = 1999;

Tabel 10.9: Hent udvalgte attributter fra tupler, hvori en attribut har en given værdi.

select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where bog_titel like ’Programming’;

Tabel 10.10: Hent udvalgte attributter fra tupler, der i en given attribut matcher en given værdi. select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where bog_titel like ’%the%’;

Tabel 10.11: Hent udvalgte attributter fra tupler, hvori en attribut matcher en variabel værdi givet med Wild Card notation. Tegnet ’%’ er et wild-card, erstatningstegn for n forekomster af et hvilket som helst tegn. n ≥ 0.

select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where bog_titel like ’_T%’;

Tabel 10.12: Hent udvalgte attributter fra tupler, hvori en attribut matcher en variabel værdi givet med Wild Card notation. Her skal det bemærkes, at begge mulige wild-card-tegn er brugt. Tegnet ’ ’ (underscore) er erstatningstegn for præcist et tegn. Procenttegnet er forklaret ovenfor. 112

©nml


10.1: SELECT select bog_id, isbn, emne_nr, emne_kode, udlaanes_dage from bog where udlaanes_dage is null;

Tabel 10.13: Hent udvalgte attributter fra tupler, hvori en given attribut er null. Et upædagogisk eksempel. Dette smertefulde eksempel p˚ akalder sig m˚ aske ekstra opmærksomhed p˚ a grund af den manglende pædagogik. SQL har dog klarsyn til, selvom den anerkender null, at behandle den anderledes end andet attributindhold. Bemærk s˚ aledes, at betingelsen er ’... where udl˚ anes dage is null’. Der anvendes alts˚ a ikke lighedstegn. Outputtet ses her i tabel 10.14: BOG_ID ISBN

EMNE_NR EMNE_KODE UDLAANES_DAGE

============ ============= ============ ========= ============= 5003 0-1400-4064-1

0 NF

<null>

Tabel 10.14: Output fra SQL-deklarationen i tabel 10.13 Med henblik p˚ a dette eksempel har det været nødvendigt allerede p˚ a dette tidspunkt, at indsætte en ny tupel i databasen udover de i appendiks C viste. Den konkrete insertdeklaration er vist og forklaret i tabel 10.38. select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where emne_kode = ’IT’ and emne_nr between 100 and 200 order by emne_nr;

Tabel 10.15: Hent et udvalg af attributter fra tupler, der opfylder en sammensat betingelse med and. select bog_id, bog_titel, isbn, emne_nr, emne_kode from bog where bog_id > 100000 or udgivet_aar = 2000);

Tabel 10.16: Hent et udvalg af attributter fra tupler, der opfylder en sammensat betingelse med or. 10.1.1.5

SELECT situation 5

Man har af og til brug for at liste attributter, hvoraf man ved at en given værdi forekommer i et antal rækker. For at undg˚ a at se en given attribut i langsom gentagelse har vi en distinct, som vi kan modificere vores select med. Se først den traditionelle: select emne_kode from bog;

Tabel 10.17: Almindeligt brugt select. Vi ser i ovenst˚ aende output et tydeligt eksempel p˚ a, at SQL ikke respekterer den relationelle model. Outputtet er ikke en relation. Herunder select med distinct, der, som det ses, kan være særdeles nødvendig. man kan have den fordom at SQL, som operationer til den relationelle model, selv burde sørge for at output er i form af relationer, med andre ord at en standard select burde være implementeret som en select distinct. ©nml

113


Kapitel 10: SQL Tutorial - SQL Data select distinct emne_kode from bog;

Tabel 10.18: Select distinct S˚ adan er det imidlertid ikke. 10.1.1.6

SELECT situation 6

Her følger et eksempel p˚ a konketenering, dvs sammenstikning af attributter, der ellers ville komme hver for sig. Konkateneringstegnet er to lodrette streger. Der kan eventuelt, som i eksemplet, indsættes tekst ved at angive en tekststreng i apostroffer. select bog_id, bog_titel, isbn, emne_nr || ’ - ’ || emne_kode EMNE from bog where emne_nr < 200 order by emne_nr;

Tabel 10.19: Select med manipulation af attributternes overskrifter. 10.1.1.7

SELECT situation 7

I forbindelse med udtræk fra databasen kan der foretages beregninger p˚ a de udtrukne data, og beregningsresultaterne kan vises sammen med databasens data. select bog_titel, isbn, status_pris "Pris excl. moms", status_pris * 1.25 "Pris incl. moms" from bog where emne_kode = ’IT’ order by emne_nr;

Tabel 10.20: Hent nogle attributter, beregn andre, fra udvalgte tupler. 10.1.1.8

SELECT situation 8

Man har ofte brug for nogle beregningsresultater, der forudsætter, at alle, eller i det mindste en del, af rækkerne fra en relation er læst. Til løsning af dette form˚ al har SQL nogle s˚ akaldte gruppefunktioner. Kig engang p˚ a følgende liste. select count(*) from bog; select avg(status_pris) from bog; select max(status_pris) from bog; select min(status_pris) from bog; select sum(status_pris) from bog;

Tabel 10.21: SQLs indbyggede gruppefunktioner. 114

©nml


10.1: SELECT

Man kan med et blik p˚ a listen spørge sig, hvorfor de kaldes gruppefunktioner, men listen tager det simple først, nemlig at se hele populationen af rækker som en enkelt gruppe. Hvis vi tager tabel 10.21s første eksempel og tilføjer en group by ..., se tabel 10.22, ser vi b˚ ade begrundelsen for navnet, og vi opn˚ ar, at resultatet i stedet for en enkelt optælling af antal rækker, bliver en optælling af antal rækker per group by-attribut. Det er værd at bemærke, at group by underforst˚ ar en order by, som vi s˚ a ikke har behov for at skrive, hvis der ikke skal afviges fra standardrækkefølgen.

select emne_kode, count(*) from bog group by emne_kode;

Tabel 10.22: Kombinations-select med gruppefunktion og gruppering. Der er rige muligheder for at kombinere gruppefunktionerne, hvis man ønsker rapporter af statistisk karakter. select emne_kode, count(*) Antal, sum(status_pris) "Samlet værdi", max(status_pris) Dyreste, min(status_pris) Billigste from bog group by emne_kode;

Tabel 10.23: Demonstration af flere af SQLs gruppefunktioner i samlet udtræk.

10.1.2

JOIN - SELECT fra mere end en tabel

Vi har ofte brug for at kombinere informationer fra flere af databasens relationer. Det betyder, at vi skal læse fra flere relationer ad gangen. Denne form for udtræk kaldes en join, man taler p˚ a nydansk ogs˚ a om at ”joine” relationer. Det er en færd, hvorp˚ a man st˚ ar sig ved at holde stramt p˚ a logikken. 10.1.2.1

Equijoin - SELECT situation 9

Lad os først, tabel 10.24, se en ukritisk formuleret select, hvis form˚ al er at udtrække bøger og samtidig f˚ a listet, hvilket emne de tilhører: select bog_id, bog_titel, isbn, bog.emne_nr, bog.emne_kode, emne_navn from bog, emne where bog_id > 10 and bog_id < 15;

Tabel 10.24: Uheldigt formuleret select fra flere tabeller. S˚ a galt kan det g˚ a, n˚ ar man ikke udtrykker sig korrekt. Men hvad g˚ ar egentlig galt her. Udtrækket er for s˚ a vidt legalt, og er et udtryk for det, der i fagterminologien kaldes det kartesiske produkt (opkaldt efter den franske filosof og matematiker Rene Descartes). Et kartesisk produkt kombinerer alle forekomster i den ene mængde med alle forekomster i den anden mængde. Det er imidlertid ikke det, vi her er interesserede i. Vi ville gerne se, for hver bog, hvilken emnekategori netop den bog tilhører. Vi omformulerer nu det første forsøg s˚ a det giver det ønskede resultat, tabel ©nml

115


Kapitel 10: SQL Tutorial - SQL Data select bog_id, isbn, bog.emne_nr, bog.emne_kode, emne_navn from bog, emne where bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode order by bog.emne_kode, bog.emne_nr, bog_titel;

Tabel 10.25: Join af flere tabeller med sortering af output. Vel vidende at en join giver et kartesisk produkt, best˚ ar kunsten nu i, ved hjælp af where, som vi jo tidligere har set p˚ a, at begrænse antal af tupler i outputrelation. Det sker ved at deklarere, at vi kun vil se forekomster fra bog matchet med forekomster fra emne, hvor præcist emne kode og emne nr er ens i de to relationer. Dette er udtrykt i eksemplets sqlkodelinjer 3 og 4. Denne type join kaldes en equijoin, idet den søger sammenfaldende (equi = lig med) værdier. Resultatet fra select-deklarationen i tabel 10.25 ses i tabel 10.26. BOG_ID ISBN

EMNE_NR EMNE_KODE EMNE_NAVN

============ ============= ============ ========= ================================================== 1 87-7281-104-8

100 IT

Grundlæggende informationsvidenskab

15 87-7281-104-8

100 IT

Grundlæggende informationsvidenskab

10225 0-596-00108-8

100 IT

Grundlæggende informationsvidenskab

13 0-201-54263-3

167 IT

Databaseteknik

100012 1-56592-744-3

167 IT

Databaseteknik

10115 0-201-61294-1

167 IT

Databaseteknik

12 0-596-00281-5

200 IT

Programmering med scriptsprog

10114 0-201-38596-1

200 IT

Programmering med scriptsprog

11 0-672-31407-X

201 IT

Indføring i JavaScript

100002 87-500-3477-4

0 NF

Diverse non-fiction

10 1-85702-879-1

0 NF

Diverse non-fiction

21 87-7783-926-9

30 NF

Ordbøger og leksika

22 0-14-029310-8

30 NF

Ordbøger og leksika

23 0-14-029311-6

30 NF

Ordbøger og leksika

a output fra join Tabel 10.26: Eksempel p˚ SQL har faktisk en særlig join-operator, der af mange findes mere logisk, tættere p˚ a naturligt sprog, og m˚ aske derfor bør foretrækkes. Eksemplet i tabel 10.27 er resultatmæssigt identisk med det fra tabel 10.25. Læseren opfordres til at afprøve de to joins og sammenligne resultaterne.

select bog_id, isbn, emne.emne_nr, emne.emne_kode, emne_navn from bog join emne on bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode order by bog.emne_kode, bog.emne_nr, bog_titel;

Tabel 10.27: Join med join-operator Med henblik p˚ a at f˚ a alle detaljer med ses den centrale del af deklarationen her fremhævet: select ... from bog join emne on bog.emne_nr = emne.emne_nr

116

©nml


10.1: SELECT

10.1.2.2

Outer join - SELECT situation 10

De formuleringer af join, som vi hidtil har set p˚ a udtrækker kun forekomster, hvis værdier i de relevante relationer/attributter er ens. Disse joins kaldes ogs˚ a inner joins. Man kan dog sagtens have databasesituationer, hvor nogen, men ikke alle, forekomster har en ”partner” i en anden relation. Konkret har vi i eksempeldatabasen bøger, hvis emneinformation ikke eksisterer i emnerelationen, og modsvarende har vi emner, der er ”tomme”, dvs. hvortil vi i øjeblikket ikke har nogle bøger. Ud fra en logisk betragtning burde man nok ikke kunne oprette bøger indenfor emner, der ikke eksisterer i emnerelationen, men som databasen i øjeblikket er defineret, kan det lade sig gøre. Databasen afspejles af ER-diagrammet i figur 10.1.

Figur 10.1: Eksempeldatabasefragmentet. Pt. uden referentiel integritet. Man kan ikke p˚ a samme m˚ ade sige, at alle emner skal have indhold, dvs. bøger. I en opbygnings/planlægningssituation er det naturligt, at man skal oprette emner i databasen for først derefter at oprette bøger hørende til disse emner. Den opmærksomme læser vil afgjort opdage, at figurens ER-model burde have haft total deltagelse for bog-entiteten. S˚ a ville dette problem ikke være opst˚ aet. P˚ a denne baggrund kan man have et behov for at kunne orientere sig om, hvilke bøger, der p˚ a et givet tidspunkt ikke matches af et emne fra emnerelationen, og modsat, at f˚ a at vide til hvilke emner, der ikke findes bøger. Løsningen p˚ a dette problem er selects formuleret som outer joins. Der findes tre typer, left outer join, right outer join og full outer join. Hvad er nu venstre og højre? Som en huskehjælp kan man m˚ aske bruge følgende Venn-diagram, der ikke er en afbildning af de to relationer, idet der jo ikke er overlap mellem relationerne. Diagrammet afbilder alene emneinformationen fra de to relationer som mængder. Fællesmængden, mærket join, viser grafisk resultatet af en inner join p˚ a emneinformationer, jf. tabel 10.27. Lægger vi hertil indholdet af den venstre ellipse f˚ ar vi resultatet af en left outer join. Modsvarende er fællesmængden plus indholdet af højre ellipse resultatet af en right outer join. Foreningsmængden af de to ellipser er nu selvfølgelig resultatet af en full outer join. Venn diagram over emneinformationer i databasen

Figur 10.2: Venn-diagram over databasefragmentets emner. Her vises nu i tabel 10.28en left [outer] join, hvor den venstre relation fra figur 10.2 er den, der i eksemplet nævnes først, alts˚ a bog:

Det er en pointe her, at join-attributterne udskrives fra den relation, der nævnes i joindeklaration, her den venstre, alts˚ a som bog.emne nr og bog.emne kode. I modsat fald ville ©nml

117


Kapitel 10: SQL Tutorial - SQL Data select bog_id, isbn, bog.emne_nr, bog.emne_kode, emne_navn from bog left join emne on bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode order by bog.emne_kode, bog.emne_nr, bog_titel;

Tabel 10.28: Left outer join med sortering. emne nr og emne kode i output-relationen st˚ a tomme, og den kunne s˚ a ikke anvendes som input til en opdatering. Bøgerne uden emne kan være fejlregistrerede eller emnerelationen kan være mangelfuld. En right outer join ser ud som i tabel 10.29: select bog_id, isbn, emne.emne_nr, emne.emne_kode, emne_navn from bog right outer join emne on bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode order by emne.emne_kode, emne.emne_nr, bog_titel;

Tabel 10.29: Right outer join. For fuldstændighedens skyld vises ogs˚ a en full outer join, tabel 10.30. select bog_id, isbn, emne.emne_nr, emne.emne_kode, emne_navn from bog full outer join emne on bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode order by emne.emne_kode, emne.emne_nr, bog_titel;

Tabel 10.30: Full outer join. Grunden til de enkelte tomme emne-felter i outputtet er, at det er højre relations felter der vises, og de mangler jo her, hvor bøgerne refererer ikke-eksisterende emner. Det kunne afhjælpes ved at udtrække b˚ ade bogens og emnets emne-felter. Output ses her i tabel 10.31: BOG_ID ISBN

EMNE_NR EMNE_KODE EMNE_NAVN

============ ============= ============ ========= ================================================== <null>

60 SK

Lyrik

14 0-201-38590-2

<null>

<null> <null>

<null>

19899 0-201-63337-X

<null> <null>

<null>

19875 0-201-61586-X

<null> <null>

<null>

100001 0-321-17868-8

<null> <null>

<null>

Tabel 10.31: Output fra en full outer join, jf. tabel 10.30.

10.1.3 10.1.3.1

Indlejret SELECT SELECT situation 11

Nogle forespørgsler p˚ a databasen kan kun besvares, hvis man, mens man læser, samtidigt kender andre data fra databasen i forvejen. S˚ adanne forespørgsler kan klares af indlejrede 118

©nml


10.2: INSERT

select-deklarationer, hvori where-delen indeholder en hel select-konstruktion. Et eksempel vil klargøre, se tabel 10.32. select bog_titel, isbn, status_pris from bog where status_pris >= (select avg(status_pris) from bog);

Tabel 10.32: Select med indlejret select.

Man kunne m˚ aske ogs˚ a forestille sig at se den dyreste bog i hver emne kode? Find svaret i tabel 10.33. select bog_titel, isbn, status_pris, emne_kode from bog where status_pris IN (select max(status_pris) from bog group by emne_kode);

Tabel 10.33: Select med anden indlejring udløst af anden type betingelse.

Eller m˚ aske skulle vi se bøger, hvor de tilhørende emneinformationer mangler i emnerelationen. Dette er en indlejret select, der har samme informationsværdi, som udtrækket vi brugte til demonstration af left [outer] join i tabel 10.28. Samtidig er denne select et eksempel p˚ a en korreleret indlejret select. Disse selects er karakteriserede ved, at den indlejrede selects where refererer en attribut fra den ydre select. I tabel 10.34 er attributten bog.emne_nr, der bruges i den indlejrede select, et resultat fra den ydre select. select bog_titel, isbn, emne_kode, emne_nr from bog where not exists (select * from emne where emne.emne_kode = bog.emne_kode and emne.emne_nr = bog.emne_nr);

Tabel 10.34: Korreleret indlejret select.

Her er et sidste eksempel, tabel 10.35, der skal udtrække bøger, hvis priser er større end alle bøger i ”NF”, Non Fiction emnet.

Nøgleordet all har et par alternativer, any og some. 10.1.3.2

SELECT - The End

Dette var en lang gennemgang af en variation af select-deklarationer. Gennemgangen er ikke udtømmende. I en konkret problemstilling bør altid refereres til DBMSets dokumentation af sin SQL-implementering, der oftest ogs˚ a har en række konkrete eksempler, og endvidere til anden teoretisk litteratur, hvis form˚ al netop er en udtømmende gennemgang af SQL. Jf. referencelisten. ©nml

119


Kapitel 10: SQL Tutorial - SQL Data

select bog_titel, isbn, status_pris from bog where status_pris > all (select status_pris from bog where emne_kode = ’NF’);

Tabel 10.35: Indlejret select p˚ a samme relation som i den ydre select.

insert into emne values(’IT’,202,’Indføring i PHP’,30); insert into emne values(’IT’,167,’Databaseteknik’,30); insert into emne values(’IT’,272,’Kunstig intelligens’,30); insert into emne values(’SK’,001,’Agent- og spionromaner’,45); insert into emne values(’IT’,200,’Programmering med scriptsprog’,30); insert into emne values(’SK’,000,’Diverse fiction’, 30); insert into emne values(’IT’,100,’Grundlæggende informationsvidenskab’,30); insert into emne values(’IT’,201,’Indføring i JavaScript’,30); insert into emne values(’NF’,030,’Ordbøger og leksika’, 0); insert into emne values(’NF’,000,’Diverse non-fiction’, 30); insert into emne values(’IT’,168,’Datamodellering’,30); insert into emne values(’SK’,060,’Lyrik’, 45); insert into bog values(15,’IT kommunikation’,’87-7281-104-8’,2002, ’25-nov-2001’,30,238.40,’IT’,100); insert into bog values(100012,’SQL in a Nutshell’,’1-56592-744-3’,2001, ’13-apr-2001’,30,238.40,’IT’,167); insert into bog values(1,’IT kommunikation’,’87-7281-104-8’,2002, ’25-nov-2001’,30,238.40,’IT’,100); insert into bog values(21,’DanskOrdbogen’,’87-7783-926-9’,1999, ’01-jan-2000’,30,400.00,’NF’,30); insert into bog values(10,’The Code Book’,’1-85702-879-1’,1999, ’20-dec-2000’,30,378.40,’NF’,0);

Tabel 10.36: Insert-deklarationer til eksempeldatabasens to relationer.

120

©nml


10.2: INSERT

10.2

INSERT

Efter den omfattende eksempelsamling fra den formentlig mest anvendte deklaration select, skal vi nu se de deklarationer, der har befolket eksempeldatabasen, og diskutere hvad vi kan lære af disse. I tabel 10.36 ses det, at insert into efterfølges af relationens navn, og herefter følger values( ... ); Prikkerne udgøres af de konkrete værdier, som ønskes anbragt i databaserelationen, adskilt af kommaer. Der er et par ting at bemærke. For det første kræver den viste syntaks for deklarationen, at værdierne anføres i den rækkefølge, der svarer til attributternes relative placering i relationen, dvs. værdien af første felt først, værdien af andet felt næst, etc. Denne rækkefølge kan ses i den oprindelige create table-sætning, eller den kan ses med hjælp fra en ustandardiseret, DBMS-proprietær SQL-deklaration, i Firebird <show tables relationsnavn>. Man bør ogs˚ a være opmærksom p˚ a, at syntaksen kræver, at der anføres værdier til alle attributter, ogs˚ a s˚ adanne som ikke er begrænsede af en not null-regel. Det andet man bemærker er, at nogle af felterne er i apostroffer, andre ikke. Generelt er det s˚ adan at tekst-felter skal anføres i apostroffer, mens numeriske felter blot skrives som de er. Hvis de numeriske værdier er kommatal, anvendes punktum (.), som decimalpunkt. Datofelter er, uanset intern datarepræsentation, at opfatte som tekstfelter. Det er vel ogs˚ a en bemærkning værd, at indtastningssyntaksen er fleksibel p˚ a den m˚ ade, at en SQL-deklaration afsluttes med et semikolon, ogs˚ a selvom dette kommer p˚ a en senere linie. Fortolkningen af sætningen starter simpelthen ikke før afslutningstegnet for deklarationen forekommer. Sammenligner man tabel 3 og tabel 4 herover, ses denne fleksibilitet afbildet.

10.2.1

INSERT - alternativ syntaks

I en række tilfælde er man som bruger interesseret at f˚ a oprettet forekomster i databasen uden at man p˚ a oprettelsestidspunktet nødvendigvis kender alle værdier for relationens attributter for den p˚ agældende række. Deklarationen insert har en alternativ syntaks, der tilgodeser dette behov. insert into bog (bog_id, bog_titel, isbn, emne_kode, emne_nr) values(5001,’C Pocket Reference’,’0-596-00436-2’,’IT’,210); insert into bog (bog_id, bog_titel, isbn, emne_kode, emne_nr) values(5002,’XML Pocket Reference’,’1-56592-709-5’,’IT’,191);

Tabel 10.37: Insert i den detaljerede alternative formulering.

Vi ser i syntaksen i tabel 10.37, at insert into bog(...) nævner en liste af attributter, ikke alle mulige, og at values(...) derefter tilføjer værdier for præcist de nævnte attributter. Forudsætningen er, at de udeladte attributter ikke har en not null-regel tilknyttet. De ikke nævnte attributter tilknyttes null i stedet for en værdi, med mindre de har f˚ aet tilknyttet en regel om indsættelse af en standardværdi, i hvilket tilfælde de naturligvis f˚ ar tildelt standardværdien i stedet. Endelig er der en mulighed for, at man bevidst ønsker, at et felt tildeles null i stedet for en værdi. Ser vi p˚ a relationen bog, er attributten udlaanes dage tænkt som en mulighed for at angive individuelle maksimale udl˚ ansperioder for enkelte titler. Værdien nul, 0, ikke at forveksle med null, bruges til at angive, at en titel slet ikke l˚ anes ud. Med andre ord en værdi for denne attribut st˚ ar over en tilsvarende værdi fra det emne som titlen hører til. Kun ved manglen p˚ a værdi for bog.udlaanes_dage i en konkret titel vil emne.udlaanes_dage finde anvendelse. Vi skal derfor i tabel 10.38 se den deraf følgende syntaks for insert. ©nml

121


Kapitel 10: SQL Tutorial - SQL Data insert into bog (bog_id, bog_titel, isbn, emne_kode, emne_nr, udlaanes_dage) values(5003, ’The Magic of Lewis Carroll’, ’0-1400-4064-1’, ’NF’, 0, null);

Tabel 10.38: Eksempel p˚ a insert med manglende værdi. Til afrunding er her ogs˚ a antydet, at ved brug af den alternative syntaks for insert med attributliste, er rækkefølgen af attributter i listen arbitrær i forhold til relationens definition. Værdierne i values-parentesen skal blot matche attribut-listen. Det bør noteres, at de seneste to eksempler, tabel 10.37 og 10.38 helt upædagogisk bruger nulls. Det betyder p˚ a ingen m˚ ade at forfatteren anbefaler brug af nulls, men er alene et tilstræbt neutralt forsøg p˚ a at vise SQLs muligheder p˚ a omr˚ adet. Det m˚ a stadig anses for at være et udtryk for særdeles tvivlsom kvalitet at anvende nulls i sine databaser.

10.2.2

INSERT med brug af generator

For en ordens skyld skal p˚ a dette naturlige sted gentages fra afsnit 9.5.1 insert into bog values( gen_id(genial, 1), ’Grammer Guide’, ’0-7475-13856’, 1993, ’28-sept-2004’, null, 128.00, ’NF’, 0, ’T’);

Tabel 10.39: Etablering, initialisering og anvendelse af en generator. Deklarationen er en SQL Data insert-deklaration, der, som det vises, benytter gen_id(genial,1) til indsættelse af værdi i den attribut, der skal have en automatisk genereret værdi. Funktionen gen_id har som argumenter navnet p˚ a den relevante generator og det tal som generatoren skal inkrementeres med. gen_id er en standardfunktion i Firebird.

10.3

UPDATE

Forudsætningen for at kunne ajourføre data i databasen er naturligvis, at der er data at ajourføre. Disse data er kommet ind i databasen ved hjælp af insert. Ajourføringsdeklarationen, p˚ a nudansk ofte kaldet opdateringsdeklarationen, er update tabelnavn set feltnavn=værdi[, feltnavn=værdi];

Lad os se et eksempel: update bog set udlaanes_dage = null;

Tabel 10.40: Update aggressivt.

Dette er et fuldstændigt nyttigt og godt eksempel, det gør (nogenlunde), hvad det skal, men er samtidigt et eksempel p˚ a en ganske farlig variant af update. Resultatet af ovennævnte er ikke, at en enkelt tupel i vores relation ændres, men at alle tupler ændres til ikke at have nogen værdi i attributten udlaanes dage. Farligt men nyttigt i enkelte tilfælde. Hvis vi i stedet, og det er m˚ aske en mere normal situation, ønsker at ajourføre en enkelt forekomst i relationen, kunne det gøres p˚ a følgende m˚ ade: 122

©nml


10.4: DELETE update bog set udlaanes_dage = 0 where bog_id = 22;

Tabel 10.41: Update af en enkelt attribut i en enkelt tupel. Forskellen mellem tabel 10.40 og tabel 10.41 er selvfølgelig, at i tabel 10.41 er vores update suppleret med en where-betingelse, der i det konkrete tilfælde siger, at godt nok skal bog opdateres, men det gælder kun forekomster, hvor betingelsen bog_id = 22 er opfyldt. Hvis betingelsen medfører, at kun en enkelt forekomst opfylder den, ja s˚ a opdateres kun denne ene forekomst. Lad os slutte med endnu et eksempel: update bog set udlaanes_dage = 0, indgaaet_dato = ’01-jul-2000’ where bog_id > 20 and bog_id < 24;

Tabel 10.42: Update med sammensat selektionskriterium. Her ajourføres to attributter med to attributnavn=værdi adskilt af komma, endvidere er der vist en sammensat betingelse idet bog_id b˚ ade skal være større end 20, og, samtidigt, mindre end 24.

10.4

DELETE

Ligesom det var tilfældet med update, har delete en farlig variant, og en, om ikke ufarlig, s˚ a dog mildere variant. Den farlige variant, der sletter alle tupler i en relation, ser s˚ aledes ud: delete from bog;

eller blot: delete bog;

Tabel 10.43: Delete i altfortærende udgave.

Ud over at det oftest ikke er en af disse varianter vi har brug for, skal det ogs˚ a bemærkes, at denne deklaration er en SQL Data deklaration, ikke en SQL Schema deklaration, hvilket indebærer at relationens definition ikke berøres. Tabellen vil fortsat være der efter en delete, men den vil unægteligt være tom! Deklarationen delete har en parallel deklaration i truncate, der dog kun findes i den farlige variant. truncate har oven i købet ikke nogen fortrydelsesmulighed. Den mildere udgave I sin milde form vil delete kun slette udvalgte tupler fra relationen. Dette opn˚ as ved at kombinere den med en where, ligesom vi gjorde for update. Eksempelvis vil delete from bog where bog_id = 22;

Tabel 10.44: Delete i den milde form.

kun slette en enkelt forekomst, nemlig den, hvor primærnøglen bog_id har værdien 22. Ligesom for b˚ ade select og update kan betingelsesdelen gøres mere eller mindre nuanceret for at p˚ avirke færre eller flere forekomster. ©nml

123


Kapitel 10: SQL Tutorial - SQL Data

10.5

Øvelser til kapitel 10

10.5.1

Øvelse

124

©nml


Kapitel 11

SQL Tutorial VIEWS, Virtuelle relationer Efter gennemførelsen af en tutorial i SQL Data er vi nu i stand til at returnere til SQL Schema for at komplettere med et væsentligt element, skabelsen af views, s˚ akaldt virtuelle tabeller. Databasens brugere har individuelt eller grupperet ofte brug for at se en delmængde af databasens indhold. Det hævdes endda, at den delmængde ern bestemt gruppe har brug for er relativt konstant over tid. Et view er resultatet af en metode til præsentation til vise en gruppe den delmængde af data, som vedkommende ofte har brug for. Skabelsen af disse indebærer en indlejret select og demonstreres derfor først nu. I tabel 11.1 vises et simpelt eksempel anvendt p˚ a bog og emnetabellerne. create view bogemne (bog_id, bog_titel, isbn, udgivet_aar, emne_kode, emne_nr, emne_navn) as select bog_id, bog_titel, isbn, udgivet_aar, bog.emne_nr, bog.emne_kode, emne_navn from bog, emne where bog.emne_nr = emne.emne_nr and bog.emne_kode = emne.emne_kode

Tabel 11.1: Den virtuelle relation bogemne Skabelse af et view kan ske med stort set alle varianter af select, dog i almindelighed ikke indeholdende en order by, hvilket ogs˚ a ville være i modstrid med den relationelle datamodels udsagn om, at man ikke kan p˚ avirke rækkefølgen af tuplerne i en relation. Et view af nogle bestemte dele af en database medfører ikke, at disse data herefter vil blive opbevaret i kopi. Et view skal alts˚ a opfattes som en reference til de basistabeller, der gennem en select-deklaration leverer data til viewet. Det betyder at værdien af et view set som en relationsvariabel, ændrer sig, n˚ ar basistabellernes værdi ændres. Under specielle omstændigheder kan basistabellerne i et view opdateres gennem viewet. SQL99 understøtter tanken herom forudsat, jf. Kline and Kline (2001): ˆ Select sætningen til definition af viewet kun bruger en tabel ˆ Select sætningen ikke indeholder having eller group by ˆ At viewet ikke er lavet med brug af union, minus eller intersect operatorerne ˆ Select sætningen til definition ikke anvendte pseudokolonner ˆ Select sætningen til definition ikke indeholdt en distinct

125


Kapitel 11: SQL Tutorial VIEWS, Virtuelle relationer

ˆ Select sætningen til definition ikke indeholdt gruppefunktioner

I alle øvrige tilfælde er et view read only. create view bogtest (id, isbn, emnekode) as select bog_id,isbn,emne_kode from bog; update bogtest set emnekode=’NF’ where id=15; select emne_kode,bog_id from bog; EMNE_KODE BOG_ID ========= ============ NF 15 IT 100012 IT 1 ...

Tabel 11.2: View baseret p˚ a en enkelt tabel. øverst definition, dernæst et eksempel p˚ a opdatering dokumenteret med en select p˚ a basistabellen. Et view er tilgængeligt med ovennævnte undtagelser for de gængse SQL Data deklarationer. Det m˚ a dog antages at den hyppigste anvendelse vil være select-deklarationer i overensstemmelse med begrundelsen for overhovedet at lave views. Antager vi, at SQL er anvendt som forespørgselssprog for den almindelige bruger, er skabelsen af views en effektive m˚ ade, hvorp˚ a følsomme kolonner i tabeller kan afskærmes fra nogle grupper af brugere. Der skabes ganske enkelt views, hvori disse kolonner ikke indg˚ ar. P˚ a tilsvarende vis kan brug af views siges at medvirke til sikring af databasens datauafhængigheden, idet der ved ændringer i databasens struktur kan skabes views, der skjuler ændringerne for brugerne, der vil opleve at databasen er strukturelt uændret. I realiteten er SQL i direkle interaktiv form ikke særligt anvendt af almindelige brugere. Den ambition med sproget blev aldrig opfyldt. Det m˚ a derfor antages, at den gængse adgang til databasen sker gennem SQLs anvendelse via et højniveau-programmeringssprog. P˚ a den baggrund har views formentlig ikke længere i s˚ a stort omfang opgaven at sikre konfidentialitet og datauafhængighed.

11.1

Øvelser til kapitel 11

11.1.1

Øvelse

Ovennævnte

11.1.2

126

Øvelse

©nml


Kapitel 12

SQL Tutorial - Sikkerhed Taler vi sikkerhed i et it-miljø er der en række typer af sikkerhed at forholde sig til. Vi vil her kun forholde os til aspekter af logisk sikkerhed. Vores stræben er, som allerede kendt fra kapitel et, at databasen skal være et sandfærdigt udsagn om den virkelighed, som den skal afbilde. Vi skal se p˚ a de mekanismer et RDBMS skal stille til r˚ adighed med henblik p˚ a at databaser som et effektivt arbejdsredskab skal kunne bruges af flere, mange, brugere ad gangen. Vi skal ogs˚ a se p˚ a, hvordan vi sikrer at det netop er de rigtige brugere der har adgang til h˚ andtering af givne databaseobjekter.

12.1

Transaktioner i Databasesystemet

12.1.1

Samtidighed og Flerbrugeri

Skabes forbindelse til en database gennem login i klient-programmet eller gennem connect fra et program i et højniveausprog skabes en transaktion som en isoleret proces, et fællesskab mellem netop denne bruger og databasen. Gør en anden bruger det samme, f˚ ar denne bruger sin egen transaktion stillet til r˚ adighed. Disse transaktioner lever lykkeligt uvidende om hinanden, side om side. En bruger kan være en person, der m˚ a identificere sig gennem et login til et klientprogram, eller en bruger kan være et program, der identificerer sig som en bruger gennem en connect til databasen.

12.1.2

Commit og rollback

12.2

Sikkerhed gennem SQL

12.2.1

Grant og revoke

Kast nu igen et blik p˚ a tabel 13.3. Med dette (komplette) indhold i relationen bog, logger vi nu ind i klientprogrammet, som en anden, upriviligeret bruger: isql iau3_bog0.gdb -u gemen -p gemen Database: iau3_bog0.gdb, User: gemen SQL>

Tabel 12.1: Login til klient-program som bruger gemen Med denne identitet vil vi nu orientere os i relationen bog: Med andre ord intet resultat. 127


Kapitel 12: SQL Tutorial - Sikkerhed SQL> select bog_id, isbn, emne_kode from bog; Statement failed, SQLCODE = -551 no permission for read/select access to TABLE BOG SQL>

Tabel 12.2: gemen forsøger at læse fra en relation Situationen er den, at ejeren af databasen ikke har givet brugeren gemen rettigheder til noget objekt i denne database. Ejeren eller Databaseadministratoren kan med andre ord selektivt tildele og fratage rettigheder til databaseobjekter. M˚ alet for tildeling er brugere, eventuelt grupperet i roller. Lad os se p˚ a tildelingen, der sker gennem SQL-deklarationen grant. Det ses at ejeren af databasen f˚ ar adgang uden login. isql iau3_bog0.gdb Database: iau3_bog0.gdb SQL> grant select on bog to gemen; SQL> quit;

Tabel 12.3: Tildeling af rettigheder foretages med grant af ejeren af databasen Rettigheden select p˚ a relationen bog gives til brugeren gemen. Vi skal derefter se p˚ a effekten af denne handling. Det ses, at gennem den tildelte rettighed f˚ ar gemen nu lov til at se indholdet af bog gennem en select. Fremturer hun nu, og forsøger at foretage en ændring af en af de famøse nulls, afvises handlingen med en besked om manglende rettigheder. Der findes følgende rettigheder, som grant kan tildele: delete, insert, select, update og references. Ønskes alle rettigheder til bog tildelt en bloc kan det gøre med grant all on bog to gemen

Nøgleordet all eller identisk hermed all privileges repræsenterer s˚ aledes de nævnte fire rettigheder. En oversigt over alle rettigheder tildelt i en database gives s˚ aledes, se tabel 12.5 Modsat grant fratages rettigheder til objekter ved hjælp af deklarationen revoke, se tabel 12.6.

12.3

Sikkerhedskopiering

Backup og restore udføres med RDBMS utilities. Aktiviteterne gælder b˚ ade databasens metadata og dens data.

128

©nml


12.3: Sikkerhedskopiering SQL>isql iau3_bog0.gdb -u gemen -p gemen Database: iau3_bog0.gdb, User: gemen SQL> select bog_id, isbn, emne_kode from bog; BOG_ID ISBN EMNE_KODE ============ ============= ========= 15 100012 1 10115 13 12 23 10114 19899 21 22 100001 100002 14 10225 19875 10 11 3338 42 43

87-7281-104-8 1-56592-744-3 87-7281-104-8 0-201-61294-1 0-201-54263-3 0-596-00281-5 0-14-029311-6 0-201-38596-1 0-201-63337-X 87-7783-926-9 0-14-029310-8 0-321-17868-8 87-500-3477-4 0-201-38590-2 0-596-00108-8 0-201-61586-X 1-85702-879-1 0-672-31407-X 123-123-1234 1234-5678-1-2 1234-5678-1-3

IT IT IT IT IT IT NF IT IT NF NF IT NF IT IT IT NF IT IT <null> <null>

SQL> update bog CON> set emne_kode = ’IT’ CON> where bog_id = 42; Statement failed, SQLCODE = -551 no permission for update/write access to TABLE BOG SQL>

a bog Tabel 12.4: gemen kan nu udføre select, men ikke update p˚ SQL> show grants; /* Grant permissions for this database */ GRANT SELECT ON BOG TO USER GEMEN GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON BOG TO USER NOBODY GRANT SELECT ON EMNE TO USER NOBODY GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON FAG TO USER NOBODY SQL>

Tabel 12.5: Vis alle databasens rettigheder ©nml

129


Kapitel 12: SQL Tutorial - Sikkerhed

SQL> revoke delete, insert, update on fag from nobody; SQL> show grants fag; GRANT SELECT, REFERENCES ON FAG TO USER NOBODY SQL>

Tabel 12.6: Fratagelse og display af rettigheder

130

Šnml


Kapitel 13

Den Relationelle Model og SQL Et kritisk tilbageblik Bogen har allerede i de tidlige kapitler om den semantiske datamodellering fremhævet det uacceptable i forekomsten af redundans og nulls. Samtidig er det en direkte konsekvens af normaliseringsteorien, at man ikke kan p˚ aber˚ abe sig kvalitetsdesign, eller “design” overhovedet, hvis databasens tabeller ikke er relationer. Databasen vill i den situation ikke være en relationel database. Nu er det s˚ adan, at SQL-standarden, der er opst˚ aet i og omkring den relationelle model, ikke eksplicit kræver, at en tabel skal have en primærnøgle eller attributter med en UNIQUE regel tilknyttet. Det er syntaktisk muligt at udelade begge disse integritetsregler fra en tabel. Man kan skærpe sprogbrugen og kalde det t˚ abeligt at lave tabeller uden erklærede kandidatnøgler, men al erfaring viser, at det forekommer ude i virkeligheden.

Nøgleløs er hovedløs Lad os først kaste et blik p˚ a disse nøgleløse tabeller. En tabel uden nøgle er en tabel, der tillader forekomst af dubletter. Ved en særligt venlig tilladelse fra O’Reilly, er det her muligt at bruge en række eksempler fra Date (2005), der dokumenterer det hovedløse ved nøgleløshed. Date gør i sin bog den forudsætning, at læseren er bekendt med, at RDBMSens SQLfortolker er i stand til, og har lov til at foretaget en fortolkning, læs omformulering, af brugerens SQL-deklaration under betingelse af, at omformuleringen giver samme resultater som den oprindelige deklaration. Omformuleringen sker i et forsøg p˚ a at opn˚ a bedre ydelseskarakteristika i besvarelsen. Til form˚ alet er konstrueret en lille, ikke-relationel database, se tabel 13.1.

P:

PNO

PNAME

P1

Screw

P1

Screw

P1

Screw

P2

Screw

SP:

SNO

PNO

S1

P1

S1

P1

S1

P2

Tabel 13.1: Ikke-relationel database. Begge tabeller indeholder dubletter. Form˚ alet med at tillade dubletter er uklart. Vi m˚ a g˚ a ud fra, at der har været et form˚ al, idet man formentlig ellers ville have modelleret databasen anderledes. Chris Date har formuleret 12 forskellige SQL-deklarationer1 til besvarelse af: “Vi ønsker 1

Code taken from Database in Depth. Copyright © 2005 O’Reilly Media, Inc. All rights reserved. Used with permission.

131


Kapitel 13: Den Relationelle Model og SQL - Et kritisk tilbageblik

at se reservedelsnumrene (PNO) som enten er skruer (Screws) eller som leveres af leverandør (SNO) S1, eller som opfylder begge disse betingelser. Dates deklarationer er kørt gennem de tre mest udbredte Open Source Software RDBMSer s˚ avel som Microsofts SQL Server. Tabel 13.2: SELECTs i relationer med tilladte dubletter Chris Dates SQL

Firebird V2.0.3

PostgreSQL V8.0.15

MySQL V5.0.54

MS SQL Server

1

select p.pno from p where p.pname = ’Screw’ or p.pno in (select sp.pno from sp where sp.sno = ’s1’ );

PNO === p1 p1 p1 p2

pno ----p1 p1 p1 p2

|pno +- | p1 | p1 | p1 | p2

| + | | | |

pno ---p1 p1 p1 p2

2

select sp.pno from sp where sp.sno = ’s1’ or sp.pno in (select p.pno from p where p.pname = ’Screw’); select p.pno from p, sp where (sp.sno = ’s1’ and sp.pno = p.pno ) or p.pname = ’Screw’;

PNO === p1 p1 p2

pno --p1 p1 p2

|pno +- | p1 | p1 | p2

| + | | |

pno ---p1 p1 p2

PNO ====== p1 p1 p1 p1 p1 p1 p1 p1 p1 p2 p2 p2 PNO === p1 p1 p2 p1 p1 p2 p1 p1 p2 p1 p1 p2

pno ----p1 p1 p1 p2 p1 p1 p1 p2 p1 p1 p1 p2 pno ----p1 p1 p1 p1 p1 p1 p1 p1 p2 p2 p2 p2

|pno | +- - + | p1 | | p1 | | p1 | | p1 | | p1 | | p1 | | p1 | | p1 | | p1 | | p2 | | p2 | | p2 | |pno | +-- -+ | p1 | | p1 | | p2 | | p1 | | p1 | | p2 | | p1 | | p1 | | p2 | | p1 | | p1 | | p2 |

pno ---p1 p1 p1 p2 p1 p1 p1 p2 p1 p1 p1 p2 pno ---p1 p1 p1 p1 p1 p1 p1 p1 p2 p2 p2 p2

3

4

132

select sp.pno from p, sp where ( sp.sno = ’s1’ and sp.pno = p.pno ) or p.pname = ’Screw’;

©nml


Tabel 13.2: SELECTs i relationer med tilladte dubletter

5

6

7

8

9

10

©nml

Chris Dates SQL

Firebird V2.0.3

PostgreSQL V8.0.15

MySQL V5.0.54

MS SQL Server

select p.pno from p where p.pname = ’Screw’ union all select sp.pno from sp where sp.sno = ’s1’;

PNO ====== p1 p1 p1 p2 p1 p1 p2 PNO ====== p1 p2 p1 p1 p2 PNO ====== p1 p1 p1 p2 p1 p2 PNO ====== p1 p2

pno ----p1 p1 p1 p2 p1 p1 p2 pno ----p1 p2 p1 p1 p2 pno ----p1 p1 p1 p2 p1 p2 pno ----p1 p2

pno +- | p1 | p1 | p1 | p2 | p1 | p1 | p2 |pno +- | p1 | p2 | p1 | p1 | p2 |pno +- | p1 | p1 | p1 | p2 | p1 | p2 |pno +- | p1 | p2

+ | | | | | | | | + | | | | | | + | | | | | | | + | |

pno ---p1 p1 p1 p2

PNO ====== p1 p2

pno ----p1 p2

|pno +- | p1 | p2

| + | |

pno ---p1 p2

PNO ====== p1 p2

pno ----p2 p1

|pno +- | p1 | p2

| + | |

pno ---p1 p2

select distinct p.pno from p where p.pname = ’Screw’ union all select sp.pno from sp where sp.sno = ’s1’; select p.pno from p where p.pname = ’Screw’ union all select distinct sp.pno from sp where sp.pno = ’s1’; select distinct p.pno from p where p.pname = ’Screw’ or p.pno in ( select sp.pno from sp where sp.sno = ’s1’ ); select distinct sp.pno from sp where sp.sno = ’s1’ or sp.pno in ( select p.pno from p where p.pname = ’Screw’ ); select p.pno from p group by p.pno, p.pname having p.pname = ’Screw’ or p.pno in ( select sp.pno from sp where sp.sno = ’s1’ );

pno ---p1 p2

pno ---p1 p1 p1 p2

pno ---p1 p2

133


Kapitel 13: Den Relationelle Model og SQL - Et kritisk tilbageblik

Tabel 13.2: SELECTs i relationer med tilladte dubletter

11

12

Chris Dates SQL

Firebird V2.0.3

PostgreSQL V8.0.15

select p.pno from p, sp group by p.pno, p.pname, sp.sno, sp.pno having ( sp.sno = ’s1’ and sp.pno = p.pno ) or p.pname = ’Screw’; select p.pno from p where p.pname = ’Screw’ union select sp.pno from sp where sp.sno = ’s1’;

PNO ====== p1 p1 p2 p2

pno ----p1 p2 p1 p2

PNO ====== p1 p2

pno ----p1 p2

MySQL V5.0.54 MySQL: syntaksfejl

MS SQL Server

|pno +- | p1 | p2

pno ---p1 p2

| + | |

pno ---p1 p1 p2 p2

En analyse af resultaterne viser, hvad der p˚ a nuværende tidspunkt næppe er overraskende, at der er forskel p˚ a resultaterne af tolv uskyldige formuleringer af en forespørgsel overgivet til en RDBMS. Afhængigt af formulering kan optimeringen falde forskelligt ud og dermed give forskelligt resultat. Hvad, der derimod m˚ aske er overraskende, er at samme SQL-deklaration kan give et antal forskellige resultater afhængigt af valgt implementering. Med andre ord, RDBMSfabrikanterne fortolker heller ikke standarden ens. Den kloge bruger har kun en konklusion p˚ a den baggrund. Hvis hun bruger tabeller, der tillader dubletter, kan hun ikke stole p˚ a forespørgslerne til sin egen database. S˚ a derfor definerer hun ikke tabeller uden nøgler.

Nulls eller ingenting Efter belysningen af det letsindige i brugen af tabeller uden nøgler, skal vi et øjeblik vende tilbage til nulls i databasen. Som for de nøgleløse er der aspekter ved accept af nulls, der gør SQL utroværdig. Se nu p˚ a tabel 13.3. I dennes første SQL-deklaration vises bøgerne fra eksempeldatabasens bog-relation. Bemærk dog, at der for eksemplet skyld er tilføjet to rækker med bog_id 42, henholdsvis 43, og at begge disse har null i emnekode. Tæller vi alle rækkerne i relationen f˚ ar vi, som vist, antallet 21. Skulle vi nu f˚ a den kætterske ide, at vi gerne ville se en optælling, men denne gang fordelt p˚ a emne-koder, er dette med vores nys tilegnede viden om select-deklarationer en simpel sag. Se tabellens tredje deklaration. Til vores bestyrtelse er der nu kun 19 (nitten) emne koder. Eksemplets sidste deklaration bekræfter, at tæller vi alle rækkerne via attributten emne kode er der kun nitten. Hvad skal vi nu stole p˚ a? Er der 19 bøger eller er der 21 bøger? I det konkrete tilfælde er det m˚ aske overkommeligt at foretage en mauel(?) eftertælling, men i en realistisk situation, hvor der kunne være titusindevis eller flere bøger, ville dette være uoverkommeligt. Er resultaterne fra nogle SQL-forespørgsler utroværdige, s˚ a er alle resultater utroværdige! Hvordan skulle den kloge bruger kunne skelne mellem troværdige eller utroværdige resultater? 134

©nml


SQL> select bog_id, isbn, emne_kode CON> from bog; BOG_ID ISBN EMNE_KODE ============ ============= ========= 15 87-7281-104-8 IT 100012 1-56592-744-3 IT 1 87-7281-104-8 IT 10115 0-201-61294-1 IT 13 0-201-54263-3 IT 12 0-596-00281-5 IT 23 0-14-029311-6 NF 10114 0-201-38596-1 IT 19899 0-201-63337-X IT 21 87-7783-926-9 NF 22 0-14-029310-8 NF 100001 0-321-17868-8 IT 100002 87-500-3477-4 NF 14 0-201-38590-2 IT 10225 0-596-00108-8 IT 19875 0-201-61586-X IT 10 1-85702-879-1 NF 11 0-672-31407-X IT 3338 123-123-1234 IT 42 1234-5678-1-2 <null> 43 1234-5678-1-3 <null> SQL> select count(*) from bog; COUNT ============ 21 SQL> select emne_kode,count(emne_kode) from bog group by emne_kode; EMNE_KODE COUNT ========= ============ IT 14 NF 5 <null> 0 SQL> select count(emne_kode) from bog; COUNT ============ 19

Tabel 13.3: Tør du købe en brugt bil af din SQL?

©nml

135


Kapitel 13: Den Relationelle Model og SQL - Et kritisk tilbageblik

Det kan hun ikke, og definerer derfor ikke tabeller, der tillader nulls.

136

Šnml


Kapitel 14

Videreg˚ aende Programmering i Databasesystemet Med henblik p˚ a opn˚ aelse af en mere naturlig fordeling af arbejdsopgaver mellem den brugerskrevne applikation og RDBMSen er der funktionalitet, der p˚ a grund af sin konkret tætte tilknytning til databasens relationer, mest praktisk kunne udføres af RDBMSen. Der er opgaver af automatiseringskarakter. Opgaver der udløses ved indtræden af forskellige begivenheder omkring relationerne. Der er ligeledes opgaver, der er af individuel karakter for en konkret database eller dele deraf. Nogle af disse lidt løst beskrevne opgaver har oven i købet ofte en karakter, der vanskeligt lader sig løse med almindelig SQL p˚ a grund af sprogets deklarative karakter. SQL standarden kræver to typer af procedurer til løsning af den type opgaver. Trigger og procedure er de officielle begreber. RDBMSer der implementerer disse implementerer som oftest et særligt programmeringssprog til løsning af opgaven. Dette programmeringssprog vil oftest være en blanding af SQL og traditionel højniveau-programmeringssprog-logik, der tillader en mere individuel behandling af tupler end SQL normalt er i stand til.

14.1

Stored Procedures

En procedure er et brugerskrevet stykke kode, der implementerer en given algoritme, som brugeren af databasen finder nyttig med henblik p˚ a genbrug. Der findes to typer af procedurer. Den ene kaldes direkte i en applikation, udfører en opgave og returnerer. Svarende til en procedure i traditionel programmering. Den anden form bruges ved at man lader den indg˚ a i en select-deklaration p˚ a relationens/viewets plads. Denne form returnerer en værdi, en relationsvariabel p˚ a samme m˚ ade som select-deklarationen. Dette svarer til den traditionelle programmeringsterminologis funktion.

14.2

Triggers

En trigger er en specialiseret procedure. Den er ogs˚ a i traditionel programmeringsterminologi en procedure. Den er associeret til en relation eller et view, udføres ved en given hændelse i forbindelse med p˚ agældende relation eller view. Det kan forsvares, at kalde triggeren for en event-handler s˚ aledes som dette begreb anvendes i forbindelse med fx programmering af grafiske brugergrænseflader eller i web-programmering. De hændelser, der kan affyre triggeren er udelukkende insert, update eller delete af tupler i den relation, som triggeren er tilknyttet. En trigger kan ikke kaldes som en procedure, men kun udløses af de nævnte hændelser.

137


Kapitel 14: VideregË&#x161; aende Programmering i Databasesystemet

138

Šnml


Kapitel 15

Case til illustration af en udviklingsmetode I dette kapitel vil en konkret opgave blive gennemg˚ aet med henblik p˚ a at vise en udviklingsmetode. Opgaven er ikke omfattende, idet det ikke er hensigten at belyse alle mulige kombinationer i ER-modeller, men primært det principielle i metoden.

15.1

Datamodellering

15.1.1

Analyse

Lad os forudsætte at vi i skriftlig form har modtaget en overordnet beskrivelse af en problemstilling, som en del af en organisation ønsker udviklet som system med henblik p˚ a at opn˚ a et beskrevet form˚ al. Analysen, der skal starte processen omkring systemudviklingen, skal klarlægge detaljer om, hvad der egentlig er bedt om. Da vi jo her har brugt ER-modelleringen til semantisk datamodellering er det naturligt at se problembeskrivelsen gennem ER-modellens optik. Til alt held er modellen p˚ a dette punkt ret generel, s˚ a dette valg afskærer os ikke fra erkendelse. Allerede Chen (1980), beskriver noget om søgning efter relevante navneord og udsagnsord, idet han havde opdaget at navneord tenderer mod at være enten entiteter eller attributter, hvorimod ER-relationer ofte vil være udsagnsord, ord forbundet med en handling. P˚ a denne baggrund skal problembeskrivelsen afsøges for ord og begreber, der kan kategoriseres som entiteter, relationer og attributter. Er der tydelige referencer til allerede eksisterende dataobjekter, vil denne kategorisering skulle relatere disse til de nye objekter. Det kan være nyttigt at beskrive denne analyse i form af en kravspecifikation og diskutere denne med opdragsgiveren for at sikre semantikken allerede p˚ a dette tidlige stade. Et eksempel p˚ a en opgave beskrivelse kunne være følgende, der er modtaget fra virksomhedens ansvarlige for sikkerhed og sikkerhedsprocedurer: Vi har i de senere ˚ ar udvidet vore it-systemer med en række intranet-applikationer med adgang for medarbejdere fra virksomheden. I forbindelse med en fusion kan vi ikke længere garantere, at kun de hidtidige brugere har adgang til de p˚ agældende applikationer. Da to intranet bliver bundet sammen via internettet, aner vi en fare for fremmedes forsøg p˚ a, og mulighed for indtrængen i vore systemer. Der ønskes derfor et system til sikring af autoriseret adgang til virksomhedens web-applikationer gennem autentifikation. Systemet skal tilrettelægges s˚ aledes, at det er administrativt overkommeligt at h˚ andtere for den nuværende sikkerhedsadministration, der skal tildele og ajourføre de rettigheder som medarbejdere og afdelinger har. 139


Kapitel 15: Case til illustration af en udviklingsmetode

Der skal kunne skabes overblik over rettigheder ved udskrifter over personers rettigheder, s˚ avel som udskrifter over rettigheder til programmer. Vi stiller os gerne til r˚ adighed for yderlige diskussion og information.... En liste over de interessante navneord kunne være: It-systemer, intranet-applikationer, medarbejdere, virksomheden, brugere, fremmede, rettigheder, sikkerhedsadministration, afdelinger, overblik, programmer. Udsagnsordene: Autentificere, tildele, ajourføre, udskrive, har ( rettigheder). Listen over navneord viser sig ved analysen at have b˚ ade grupperinger af beslægtede begreber og m˚ aske ogs˚ a synonymer. S˚ aledes kan man vel sige at it-systemer har intranetapplikationer, der igen har programmer, hvis ikke programmer er programmer. Virksomheden har afdelinger, der har har medarbejdere. Disse medarbejdere er brugere. Fremmede er m˚ aske brugere uden rettigheder, eller er m˚ aske slet ikke interessante. It-systemer, intranet-applikationer og programmer er vel alle kandidater til at være entiteter i det ønskede system. Det samme er virksomheden, afdelingerne og medarbejderne. Sidstnævnte vil vi vælge at opfatte som kandidater til at være brugere. Rettigheder kunne være entiteter, men de kunne ogs˚ a være egenskaber, attributter ved brugere eller ved programmer. Udsagnsordene falder i mindst to grupper. Autentificere, tildele, ajourføre og udskrive beskriver de handlinger systemet skal kunne udføre for brugere og systemets objekter. Vil vælger at kaldet dette for systemets transaktioner. Disse er udtryk for de krav der stilles til systemets ydelse. Det lille ord har, beskriver her at brugere og afdelinger har rettigheder, nemlig til programmer. Man kunne her tilføje, at der indirekte ogs˚ a st˚ ar tilbyder, idet programmer jo tilbyder rettigheder. I forklaringen til listen over grupperede navneord fremkommer yderligere et par gange ordet har. Det beskriver blandt andet sammenhængen mellem afdelinger og medarbejdere. M˚ aske skulle vi allerede nu vælge, at anvende begrebet bruger for medarbejdere, der skal kunne bruge virksomhedens programmer. Læseren vil se, at der selv med en kortfattet problembeskrivelse kan fabuleres meget over semantikken. Da opdragsgiveren tilbyder at informere yderligere kunne det m˚ aske være form˚ alstjenligt at udarbejde et foreløbigt ER-diagram, der afbilder nogle af de ideer, der fremst˚ ar fra analysen.

15.1.2 15.1.2.1

ER-modellering ER-diagrammet

Følger vi den centrale besked fra opgaveformuleringen, nemlig at nogle brugere skal tilbydes ret til at udføre visse programmer, kunne dette illustreres som i figur 15.1. Figur 15.1 viser, at der ogs˚ a er leget med en forestilling om, hvilke attributter, der kunne være nødvendige. Entiteterne program og bruger er selvforklarende. ER-relationen tilbyder_ret_til vil komme til at indeholde en forekomst for hver tilladt brugerret til et program. Figuren giver ogs˚ a grundlag for at regne lidt p˚ a den administrative byrde. Lad os forestille os ialt 50 programmer og 10 brugere. Da vi jo ved, at en N:M-relation giver anledning til en relation i databasen kan vi ogs˚ a beregne at hvis alle 10 brugere har ret til alle 50 programmer vil vi f˚ a 500 forekomster i relationen tilbyder_ret_til. Maksimalt 560 forekomster i dette hjørne af virksomhedens database. Dialogen med opdragsgiveren bekræfter, at analysens grundsubstans er rigtig, men som forventet mangler der en række nuancer. Det p˚ apeges, at flere programmer med samme navn kan eksistere forskellige steder, forskellige filkataloger, i operativsystemets filsystem. Det betyder at programnavnet ikke er tilstrækkeligt som unik nøgle for et program. Der udvides med en stibetegnelse. 140

©nml


15.1: Datamodellering

Figur 15.1: Første udkast til ER-model for autentifikationssystemet. Grupperingsmuligheden er ikke tegnet ind i første udkast, da der manglede detaljeret information. Nu viser det sig, at en bruger har rettigheden til et givet program i kraft af medlemskab af en gruppe. I sjældne tilfælde skal en bruger have direkte ret. Det er i s˚ a fald oftest den sikkerhedsansvarlige, der er tale om. Disse forhold ligner til forveksling rettighedsmekanismen, som er kendt fra UNIX filsystem, hvor hvert program har tre rettighedshavere, der hver for sig kan tildeles rettigheder. En ejer har sit sæt rettigheder overfor programmet. En gruppe med et variabelt antal medlemmer har sine rettigheder, og slutteligt har alle andre et tredje sæt rettigheder eller, ofte, mangel p˚ a samme. P˚ a denne m˚ ade er programmet tilført attributter, der med sine værdier fortæller om henholdsvis identitet og rettigheder for ejer, uid og urwx, og gruppe, gid og grwx. Endvidere om rettigheder for andre, orwx. Slutteligt ønsker man ogs˚ a at kunne p˚ atvinge brugerne periodiske password-skift p˚ a en m˚ ade, s˚ a et password ikke kan genbruges førend det har en vis alder i form af et antal generationer. Til det form˚ al er oprettet en svag entitet tilknyttet brugeren. Heri opbevares brugte passwords. Ser vi p˚ a tallene for at sammenligne med den første ide, kan vi holde fast i de 50 programmer og de 10 brugere. Lad os antage, lidt urealistisk, at vi har de 10 brugere grupperet i hver sin gruppe, 10 grupper. Det medfører at databasen f˚ ar 50 programmer, 10 grupper, maksimalt 100 “berig”-er og 10 brugere, i alt 170 rækkeforekomster. Samtidig er modellen mere nuanceret end den første ide, idet de 10 brugere gennem gruppejerskab kan have rettigheder til de samme 50 programmer som i første ide, og det for en lavere databasemæssig omkostning. Betydelig færre forekomster giver betydeligt mindre administration af adgangssikkerheden. Sikkerhedschefen kan lide denne løsning. Selv om sikkerhed er s˚ a vigtig, at det er en selvstændig opgave, m˚ a opgaven gerne kunne løses omkostningsbevidst. Den reviderede model findes i figur 15.2. 15.1.2.2

Kardinaliteter og deltagelsestyper

Kardinaliteter Ser vi p˚ a kardinaliteten for diagrammets relationer ser vi først, at en gruppe kan have rettigheder til et antal (N) programmer. Et program har kun mulighed for tildeling af grupperettigheder til en (1) gruppe. Relationen ret_for_grp er s˚ aledes en 1:N-relation. En bruger kan have direkte rettighed til et antal (N) programmer, mens programmets kun tildeler direkte ret til en enkelt (1) bruger. kardinaliteten for ret-for-bruger er ogs˚ a 1:N. Til gengæld kan en bruger være medlem af et antal (N) grupper. Grupperne kan ogs˚ a hver have et antal (M) medlemmer. Kardinaliteten for berig er s˚ aledes N:M. Herved sikres brugerne ogs˚ a ret©nml

141


Kapitel 15: Case til illustration af en udviklingsmetode

Figur 15.2: Andet udkast til ER-model for autentifikationssystemet. tigheder i forhold til programmerne som de ikke er direkte rettighedshavere til. Rettighederne g˚ ar gennem medlemsskab af grupper via berig. Relationen havde er en 1:N-relation idet den sikrer associationen mellem en bruger og hans tidligere passwords. Form˚ alet er at bevare information om et antal generationer af passwords for den enkelte bruger, s˚ a sikkerheden ikke kompromitteres ved “evigt liv” for et enkelt password eller ved for hurtig genbrug af bestemte passwords. Den enkelte organisation m˚ a beslutte sig for et antal (N) som for den skal være det optimale. Dette antal er ikke en del af datamodellen, men skal sikres gennem en forretningsregel i et applikationsprogram. Deltagelsestyper Programmer er tvungne deltagere i relationerne ret-for-grp og ret-for_bruger, jf dobbeltstregerne i diagrammet. Det betyder blandt andet, at førend det første program kan oprettes i systemet, skal der allerede eksistere relevante brugere og grupper. En gruppe kan eksistere uden (endnu) at have medlemmer. Brugere behøver ikke nødvendigvis at være medlemmer af grupper. De brugte passwords skal selvføgelig deltage i en havde-relation, mens brugerne endnu ikke nødvendigvis har brugte passwords. En anden forretningsregel i organisationen skal fastlægge et tidsinterval, hvorefter et password forældes og skal fornys.

15.1.3

Logisk transaktionsafprøvning

Kontroller logisk, at alle transaktioner, jf afsnit 15.1.1 understøttes. Iterativ proces med ERmodellering 142

©nml


15.1: Datamodellering

15.1.4

Analyse af fleksibilitet og fremtidige informationskrav

Overvej tænkelige fremtidige informationskrav. Du kan aggregere fra detaljer du har, men du kan oftest ikke detaljere de aggregater du har. Juster eventuelt datamodellen.

15.1.5

Transformation fra ER til RM

Vi er nu n˚ aet til det centrale skridt at transformere ER-diagrammet til den relationelle model. Her opst˚ ar databasens tabeller i praksis. Vi skal gennemløbe det som vi i kapitel 6 beskrev i ni trin. I den konkrete situation er der dog ikke brug for alle trin, som vi skal se. Som et udtryk for det, der p˚ a nudansk kaldes best practice starter vi med et indledende skridt, der ikke er strengt nødvendigt, men som kan vise sig b˚ ade praktisk og arbejdsbesparende i de følgende skridt. Nulte skridt, hvis læseren vil tilgive betegnelsen, best˚ ar i at skabe en data dictionary for projektet. I praksis vil dette sige, at vi analyserer alle entiteters og relationers attributter, og definerer dem i databasesystemet som domæner, se i øvrigt afsnit 9.4. Disse domæner vil derefter blive anvendt i skabelsen af relationerne i databasen. Fordelen er at vi sikrer ensartede definitioner for ensartede datatyper p˚ a tværs af relationer i den kommende database. I udviklingsfasen giver det ogs˚ a en central mulighed for korrektur, da domænerne defineres et sted, og kan anvendes mange steder. Dette projekts data dictionary ser s˚ aledes ud: CREATE CREATE CREATE CREATE CREATE CREATE

DOMAIN EMAILADR AS VARCHAR(64); DOMAIN KOMMENTARER AS VARCHAR(256); DOMAIN NAVNEFELT AS VARCHAR(40); DOMAIN PASSWD AS VARCHAR(40); DOMAIN PROGRAMNAVNE AS VARCHAR(32); DOMAIN RWX AS INTEGER check (value between 0 and 7); CREATE DOMAIN STINAVNE AS VARCHAR(48); CREATE DOMAIN TEGNID AS VARCHAR(16); CREATE DOMAIN TIDSSTEMPEL AS TIMESTAMP;

Betydningen heraf vil kunne ses i det følgende. Første skridt er at transformere alle normale entiteter fra diagrammet til tabeldefinitioner. Med andre ord skal der nu skrives create table-deklarationer til entiteterne bruger, gruppe, og program. CREATE TABLE BRUGER ( UID TEGNID NOT NULL, UPWORD PASSWD NOT NULL, UPWDATO TIDSSTEMPEL NOT NULL, UFORNAVN NAVNEFELT NOT NULL, UEFTERNAVN NAVNEFELT NOT NULL, UEMAIL EMAILADR NOT NULL, PRIMARY KEY (UID) ); CREATE TABLE GRUPPE ( GID TEGNID NOT NULL, GNAVN NAVNEFELT NOT NULL, PRIMARY KEY (GID) ); CREATE TABLE PROGRAM ( PATH STINAVNE NOT NULL, PID PROGRAMNAVNE NOT NULL, UID TEGNID NOT NULL, URWX RWX NOT NULL, GID TEGNID NOT NULL, GRWX RWX NOT NULL, ORWX RWX NOT NULL,

©nml

143


Kapitel 15: Case til illustration af en udviklingsmetode BESKRIVELSE KOMMENTARER NOT NULL, PRIMARY KEY (PATH, PID), FOREIGN KEY (UID) REFERENCES BRUGER (UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID) ); GRANT GRANT GRANT GRANT GRANT

DELETE, DELETE, DELETE, DELETE, DELETE,

INSERT, INSERT, INSERT, INSERT, INSERT,

SELECT, SELECT, SELECT, SELECT, SELECT,

UPDATE, UPDATE, UPDATE, UPDATE, UPDATE,

REFERENCES REFERENCES REFERENCES REFERENCES REFERENCES

ON ON ON ON ON

BERIG TO NOBODY; BRUGER TO NOBODY; GRUPPE TO NOBODY; PROGRAM TO NOBODY; GLPWORD TO NOBODY;

Andet skridt er oprettelse af tabeller for de svage entiteter, hvoraf vi konkret kun har en. Da kardinaliteten for den p˚ agældendes deltagelse i relationen havde er N, skal vi sikre, at der udover nøglefeltet uid, der som nøgle og fremmednøgle knytter den til en bestemt bruger, ogs˚ a er logisk mulighed for et antal forekomster tilhørende samme bruger. Det kunne gøres ved at indføre et ekstra nøglefelt, et løbenr, men her vælges at lade upwdato, datoen for ikrafttrædelse af de nye nøglefelt, udføre denne rolle. Herved kan der kun opbevares et password per dag. Det skønnes tilstrækkeligt. En forretningsregel i praksis hyppigt være, at der m˚ a ikke skiftes password p˚ a den dag, hvor det forrige er oprettet. Resultatet af andet skridt er nu: CREATE TABLE BRUGT_PWD ( UID TEGNID NOT NULL, UPWDATO TIDSSTEMPEL NOT NULL, UPWORD PASSWD NOT NULL, PRIMARY KEY (UID,UPWDATOTID), FOREIGN KEY (UID) REFERENCES BRUGER (UID) );

Tredje skridt bortfalder i denne situation, da vores model ikke indeholder 1:1-relationer. Fjerde skridt er de binære 1-N-relationer. Projektet har tre binære 1:N-relationer. Da ingen af de tre har partiel deltagelse til begge associerede entiteter, vil der ikke være behov for oprettelse af opslagstabeller. Vi husker, at n˚ ar der er tvungen deltagelse, sikres referencen ved at entiteten p˚ a N-siden med en fremmednøgle udpeger præcist den associerede forekomst p˚ a 1-siden. Der oprettes dermed ingen relationer i dette skridt i det konkrete tilfælde. Femte skridt handler om mange-til-mange-relationerne, N:M. Af disse har vi kun en enkelt. Den associerer gruppe med bruger, og i overensstemmelse med logikken udredt i afsnit 6.1.5 kommer den til at se s˚ aledes ud: CREATE TABLE BERIG ( GID TEGNID NOT NULL, UID TEGNID NOT NULL, PRIMARY KEY (GID, UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID), FOREIGN KEY (UID) REFERENCES BRUGER (UID) );

Idet den ikke har egne attributter f˚ ar den kun attributterne fra de associerede entiteter og de udgør tilsammen primærnnøglen, mens de hver for sig agerer fremmednøgle til de respektive entiteters afbildning som relationer. Sjette skridt ville være h˚ andtering af flerværdiede attributter. Der ingen af disse i projektet. Syvende skridt er eventuelt etablering af relationer svarende til de n-re ER-relationer. Ottende skridt omhandler etablering af relationer til afspejling af specialiseringer/generaliseringer. S˚ adanne indeholder projektet heller ikke. Niende skridt behandler aggregeringer. Proejktet indeholder heller ikke aggregeringer. Det er ikke usædvanligt at sm˚ a projekter, s˚ aledes som det ses her, ikke har aktiviteter svarende til alle de tænkelige skridt som teorien indeholder. 144

©nml


15.1: Datamodellering

15.1.6

Normalisering

I kapitel 5 om normalisering som kvalitetskontrol af databasen er det hævdet, at I praksis kan vi nøjes med at analysere de genererede forslag til relationer i forhold til Boyce-Codd normalformen. Dette st˚ ar stadig til troende, men vi vil imidlertid her af pædagogiske grunde ogs˚ a analysere efter 1-3NF. At vore relationsforslag alle er tildelt primærnøgler tager vi som en forudsætning. Første normalform siger, at en relations attributter skal være udelelige, atomare. Vi har i relationen bruger allerede inddelt navnet i fornavn og efternavn. Da vi ikke har noget form˚ al med en underopdeling i dag,m˚ aned og ˚ ar af tidsstemplet for ikrafttrædelse af det seneste password, er der ikke i bruger behov for ændringer. Relationen opfylder 1NF. Datoovervejelserne gælder p˚ a samme m˚ ade relationen brugt_pwd. I gruppe har vi et gruppenavn. Da der ikke er tale om et personnavn med fornavn og efternavn, men blot en gruppebetegnelse, er der heller ikke her ændringer. Anden normalform stilles som yderligere krav at relationernes attributter skal være fuldt funktionelt afhængige af enhver kandidatnøgle. Fuld funktionel afhængighed adskilte sig jo fra almindelig funktionel afhængighed derved, at afhængigheden skulle være af hele kandidatnøglen og ikke blot af en del af denne. Da kun relationerne program og berig har sammensatte nøgler er der i denne sammenhæng kun grund til at se p˚ a dem. Relationen berig har imidlertid ingen ikke-nøgle-attributter, og er s˚ aledes alligevel uproblematisk i denne sammenhæng. Relationen program kunne opfattes som problematisk. Da programnavne ikke er entydige, men kan dække overforskellige programmer af samme navn, blot placeret i forskellige directories, er vi nødsaget til at se path og pid som en samlet nøgle. Vi konstaterer, at der ikke er afhængigheder af nogle af disse komponenter hver for sig. Ved analysen i forhold til anden normalform optræder begrebet enhver kandidatnøgle. Lad os derfor undersøge relationerne for forekomst af kandiatnøgler udover dem, somallerede er udpeget som primærnøgler. Vi konstaterer, at relationen bruger, der i det konkrete tilfælde aldrig skal bruges som et fælles login-id, da vi har et gruppebegreb, har attributten uemail som en kandidatnøgle. Relationen gruppe har attributten gnavn, der formentlig ogs˚ a kunne have være nøgle. I overensstemmelse med de regler vi fastlagde i kapitel 6, jf. blandt andet afsnit 6.1.1, skal vi definere alternativnøglerne som unikke. Lad os derfor ændre de p˚ agældende to relationer, s˚ a de efter ændring tager sig s˚ aledes ud: CREATE TABLE BRUGER ( UID TEGNID NOT NULL, UPWORD PASSWD NOT NULL, UPWDATO TIDSSTEMPEL NOT NULL, UFORNAVN NAVNEFELT NOT NULL, UEFTERNAVN NAVNEFELT NOT NULL, UEMAIL EMAILADR NOT NULL, PRIMARY KEY (UID), UNIQUE (UEMAIL) ); CREATE TABLE GRUPPE ( GID TEGNID NOT NULL, GNAVN NAVNEFELT NOT NULL, PRIMARY KEY (GID), UNIQUE (GNAVN) );

Tredje normalform stiller som krav, udover opfyldelse af 2NF, at en relation ikke indeholder transitive afhængigheder. I relationen bruger kunne man fristes til at overveje om uemail skulle være afhængig af kombinationen ufornavn og uefternavn. Da fornavn og efternavn imidlertid ikke er egnede som samlet nøgle, idet en given organisation sagtens kan have flere ©nml

145


Kapitel 15: Case til illustration af en udviklingsmetode

medarbejdere med samme navn, er de netop af den grund repræsenterede af uid som nøgle. Vi konstaterer derfor ingen transitiv afhængighed her. Man kunne p˚ a sammem˚ ade overveje om urwx i relationen program var afhængig af uid, og om grwx var det af gid. Imidlertid er brugerrettigheder, omend afhængige af brugeren, variable i forhold til programmet. Brugeren har formentlig andre rettigheder til andre programmer. Det samme gælder gruppen. Igen konstaterer vi ingen transitive afhængigheder. Boyce-Codd normalformen, BCNF, er, som vi husker, i sin definition uafhængig af 1-3NF. Den kræver, at alle determinantfelter er kandidatnøgler i den relation, hvori de forekommer. Analyserede vi relationerne i forhold til BCNF uden i forvejen at have være gennem de overvejelser, der er gjort herover, ville vi i analysen konstatere forekomsten af uemail og gnavn som determinantfelter i henholdsvis bruger og gruppe. Overvejelsen netop beskrevet under 3NF omkring uemails mulige afhængighed af navnet ville ogs˚ a forekomme. Det samme gælder overvejelserene om uid og urwx henholdsvis gid og grwx i relationen program. Da vi har stillet opfyldelse af BCNF som et gængstkvalitetskrav til databasen, afslutter vi normaliseringsovervejelserne her. Vi har set justeringer i definitionerne af enkelte relationer, men der er ikke forekommet delinger, som ville medføre at vores ER-diagram skulle ajourføres.

15.2

Udvikling

15.2.1

Relationer implementeres

Database oprettes. Skriv og udfør create table sætninger

15.2.2

Testdata

Der udarbejdes foreløbige testdata. Disse indsættes i databasen.

15.2.3

Transaktionsafprøvning, igen

Der udarbejdes en række sql-deklarationer, der dokumenterer at transaktionskravene, der allerede er logisk afprøvede, se afsnit 15.1.3, ogs˚ a kan udføres p˚ a de foreløbige testdata. Opst˚ ar der problemer overvejes først testdata for validitet, dernæst sql-sætningerne. Er der stadig problemer kan der itereres helt tilbage til 15.1.2.

15.2.4

Strukturmodel

Der udarbejdes et strukturdiagram, der viser hvilke funktioner systemet best˚ ar af og hvordan der navigeres mellem dem. Diagrammet skal dokumentere at der er funktioner til oprettelse/ajourføring/sletning af alle relationer samt til transaktioner nævnt i kravspecifikationen. Fastlæg en navnesystematik for funktionerne. Funktionerne beskrives i hver sit dokument.

15.2.5

Programmering af funktioner

De i afsnit 15.2.4 nævnte funktioner programmeres og testes individuelt.

15.3

Test

15.3.1

Testdata

Udarbejd endelig testdata, der skal kunne dokumentere hele systemets funktionalitet. 146

©nml


15.4: Implementering

15.3.2

Testen

Opret ny udgave af databasen Brug de nyudviklede funktioner til oprettelse af testdata i databasen. Alle funktioner til opret/ajourfør/slet skal afprøves. Alle transaktioner testes og output analyseres.

15.3.3

Dokumentation

Testresultater dokumenteres elektronisk og dokumentationen bruges i en iterativ proces hvor vi vender tilbage til det i afsnit 15.2.5 beskrevne. N˚ ar testresultaterne bedømmes til tilfredsstillende udarbejdes en liste over udviklingsønsker til næste version, hvorefter vi g˚ ar til implementering.

15.4

Implementering

15.4.1

Forberedelse

Produktionsdatabase klargøres. Der beskrives en procedure for oprettelse af alle grunddata i produktionsdatabasen.

15.4.2

Ibrugtagning

Grunddata oprettes i overensstemmelse med planen og systemet tages i brug.

©nml

147


Kapitel 15: Case til illustration af en udviklingsmetode

148

Šnml


Kapitel 16

Distribuerede Databaser Response vedr besvarelser p˚ a uge 3’s opgave 0. Arkitektur og central forskelle p˚ a homogene og heterogene systemer C&B beskriver den helt centrale pointe i det distribueret DBMS best˚ aende af netværk, computere og databaser som værende hvorvidt databaserne er bestyrede af samme DBMS eller flere forskellige DBMSer. De homogene er de førstnævnte. 1. Distribueret processing implicerer central database. Dette har en række praktiske fordele især af systemadministrativ art. Der er ogs˚ a nogle sikkerhedsmæssige omkring adgang, backup mv. Set fra brugersiden er vil der i et transaprent system ikke være forskel med mindre netværket er utilgængeligt. Med vore dages netkvalitet og kapacitet er der ingen p˚ atrængende ulemper. Om transmissionstider og -forsinkelser er værre ved denne løsning end ved distribueret database er vel tvivlsomt, idet der ogs˚ a her kan være transmissionsforsinkelser. Distribueret database giver nogle fordele af systemadministrativ art, idet denne arkitektur er mere robust for netværksnedbrud. N˚ ar man laver statistik p˚ a netværksnedbrud, er der vist ikke væsentlige fordele i distribueringen af den grund. Ulemperne er ret signifikante her og best˚ ar i systemadministrative, der kræves nemlig lokal databaseadministrativ ekspertise p˚ a hver lokation. Der er højere kompleksitet omkring alle aggregeringer af data til central brug. Teknologien er endvidere indtil videre ikke s˚ a gammel og m˚ a forventes derfor at være mindre robust. Parallelle DBMSer dublerer en eller flere af de ressourcer, der kan udgøre flaskehalse i systemer med meget høje krav til ekspedition af antal transaktioner. Fordelen er selvfølgelig, at det kan gøres. Fejler de delte ressourcer vil vi have samme ulemper som i et centralt system. Alle p˚ avirkes.

149


Kapitel 16: Distribuerede Databaser

150

Šnml


Kapitel 17

Objektorienterede Databasesystemer 17.1

Fysisk repræsentation af data

N˚ ar gængse kilder skal diskutere fordele og ulemper ved den relationelle, nævnes det især at den aom en væsenltlig ulempe har d˚ arlig repræsentation af den virkelige verdens data. Det som C&B (og andre) kalder d˚ arlig repræsentation af data i den relationelle model efter normalisering er netop det, som anses for den relationelle models væsentligste styrke. Datas integritet, og dermed datas mulighed for at udgøre et konsistent øjebliksbillede af den del af virkelighedens som modellen skal repræsentere, er afhængig af, at der ikke forekommer redundans og/eller nulls. P˚ astanden om at datas fysiske repræsentation afspejler den normaliserede struktur i den logiske model er i øvrigt ikke et udsagn om den relationelle model, men om dens implementering. Det kan derfor højst være en ulempe ved konkret RDBMS. Den relationelle model som s˚ adan beskæftiger sig ikke med datas fysiske opbevaring, helt i overensstemmelse med Tsichritzis and Lochovsky (1982)’s definition af en datamodel, som best˚ aende af M = Gs + Gc + O hvor Gs er generatorer, der beskriver struktur, og Gc er generatorer, der beskriver regler (constraints), mens O er operatorerne, SQL mv. Jf. ogs˚ a kapitel 2.1.4. Heri er intet om opbevaring

17.2

Semantisk overload

Muligheden for ensartede operationer i den relationelle model bygger helt fundamentalt p˚ a repræsentationen af data gennem relationer. Relationen er et matematisk begreb, der er helt neutralt overfor enkeltdatas anvendelse. I den relationelle model anses dette for en styrke, idet det som nævnt er fundamentalt ved at muliggøre definitionen af den relationelle algebra, og i øvrigt ogs˚ a den relationelle calculus. Datauafhængighed er ligeledes en helt fundamental ting i den relationelle model. Data i den relationelle model opbevares uafhængigt af deres anvendelse, men ikke uafhængigt af deres fortolkning. Fortolkningen danner jo netop grundlag for normaliseringen. Mange ˚ ars forsøg med semantiske modeller af data er jo ikke forgæves af den grund. Det m˚ a anses for nyttigt, at der findes ordentlige semantiske modeller for data. Herfra skal især fremhæves Entity-Relationship-modellen. Den, ER-modellen, danner semantisk model udgangspunkt for specifikation og design af arkitektur og applikationer. Den er lidet abstrakt og skal med henblik p˚ a implementering transformeres til den logiske, relationelle model. Det 151


Kapitel 17: Objektorienterede Databasesystemer

betyder at vores data transformeres til den logiske implementeringsmodel. Databasen er logisk, ikke semantisk. Den logiske database implementeres s˚ a gennem et RDBMS. De fleste RDBMSer anses for mere eller mindre heldige implementeringer af den relationelle model. Man kan afslutningsvist sige, at netop datauafhængigheden, som den relationelle models fortalere anser for fundamental, er i modstrid med en grundtanke i den objektorienterede filosofi, hvor data jo knyttes tæt til deres anvendelse. I en form for billedsprog kunne man sige at den relationelle model repræsenterer data i hvile, opbevarede data, multipelt anvendelige. Det objektorienterede synspunkt beskæftiger sig med data i flugt, deres skæbne under behandling. Ingen vil vel heller p˚ ast˚ a, at et fly p˚ a jorden har samme egenskaber som et fly i luften. For at blive i det sprog m˚ a vi s˚ a at sige bekymre os om starter og landinger. 3. Ringe understøttelse af integritets- og forretningsregler C&B har ret n˚ ar de skriver. at mange kommercielle systemer har en mangelfuld implementering af entitets- og referentiel integritet samt af domæner. Med fare for gentagelse, m˚ a det atter fremhæves, som C&B gør, at det er et implementeringsproblem. SQL-standarden er yderst mangelful i forhold til den relationelle teori, idet den fx ikke kræver entitetsintegritet, tilstedeværelse af en primærnøgle uden mulighed for nulls. Selv udbredte RDBMSer har ingen eller mangelfuld mulighed for specifikation af referentiel integritet og/eller domæner. 4. Homogene datastrukturer Ligesom objekter af samme klasse har en ensartet opbygning, har relationer ensartede tupler. C&B beskriver styklisteproblematikken som problematisk i den relationelle model. Javel, men det er den ogs˚ a i den gamle hierarkiske model. problemerne kan dog løses. I den relationelle model løses de dog anderledes end i andre modeller. BLOBs, Binary Large Objects fremhæves som problematiske i RDBMSer. Det er rigtigt at de h˚ andteres forskelligt, hvilket dog ikke kan tilskrives modellen men RDBMSerne. 5. Begrænsede operationer Det er ganske rigtigt at der er et endeligt funktionsomfang i SQLs begrænsede antal operationer. SQL-standarden forudsætter dog, s˚ a vidt jeg husker, mulighed for programmering af triggers og stored procedures, hvormed der kan programmeres ønskede udvidelser. Implementeringen af disse muligheder er uensartet, og mangler i flere RDBMSer. 6. Rekursive forespørgsler Det er korrekt, at det med SQL er svært at programmere rekursive forespørgsler. Brugen af triggers og stored procedures vil sikkert være en hjælp. 7. Programmeringsdisharmoni Et forsøg p˚ a en fortolkning af impedance mismatch, som jo direkte oversat betyder noget i retning af uensartet besvær med prorammeringen. ˚ Arsagen er kolissionen mellem det deklarative og det procedurale programmeringsparadigme. Førstnævnte repræsenteret af SQL og sidstnævnte af de fleste andre programmeringssprog. SQL arbejder med hele relationer (et antal tupler/rækker) ad gangen, hvorimod de procedurale sprog arbejder med en række ad gangen. Der findes dog moderne programmeringssprog, fx PHP der mest benyttes i web-applikationer, som stiller funktionalitet til r˚ adighed til problemfri løsning af dette problem. Der kan s˚ aledes let argumenteres for, at denne s˚ akaldte ulempe med samme ret kan anses for at være en ulempe ved diverse programmeringssprog. 8. Transaktioner Transaktionsproblemer afhænger meget af implementering i en konkret RDBMS, som C&B ogs˚ a skriver. Emnet behandles ikke i den relationelle model som s˚ adan. 9. Skemaændringers besværlighed C&B skriver, at der typisk er problemer med skemaændringer. I praksis m˚ a disse problemer ofte snarere tilskrives ubehjælpsom programmering end SQLs uegnethed. Den relationelle model kan ikke bebrejdes. Der er ganske rigtigt et begrænset udbud af muligheder med ALTER TABLE i forhold til 152

©nml


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


Kapitel 17: Objektorienterede Databasesystemer

Figur 17.1: UML eller ER

154

Šnml


Kapitel 18

Databasen p˚ a World Wide Web Ref: Data Mining for Web Intelligence, Computer, November 2002. Interessant artikel om at finde relevant information p˚ a web ved søgninger. Databaser har jo en tvetydig rolle i skabelsen af den dynamiske web. De skjuler web’ens information for søgemaskinerne. En web-side, der vises frem er tilgængelig for tilskueren, men samtidig er den flygtig. Den samme web-side kan m˚ aske aldrig vises igen idet den kan være dannet dynamsik (PHP, ASP e.l.) p˚ a nogle forudsætninger, der ikke vil genopst˚ a. Den bagved liggende information kan dog stadig eksistere tilgængeligt for web, men m˚ aske ikke i en indexerbar html/pdf-form. En tutorial med et konkret oplæg fx Bibliotek Forudsætninger Apache, PHP og en browser relater til C/S

18.1

Datamodellen

18.2

Web-grænsefladen

Forklar et HTML-dokument Især formularen

18.3

PHP-programmet

Vis det og kommenter det kodeeksempler p˚ a select, insert, update og delete

155


Kapitel 18: Databasen p˚ a World Wide Web

156

©nml


Kapitel 19

Datavarehuse 19.1

Definitioner

Den normale database i en organisation indg˚ ar normalt som en hjørnesten i virksomhedens samlede administrative system. Et s˚ adant system kaldes af og til for et OLTP-system. OLTP betyder On Line Transaction Processing. Vi kalder det ofte for det operationelle system, som bruges i den daglige drift. Som vi har set gennem eksemplerne bruges et s˚ adant system til at registre ordrer, behandling af ordrerne, fakturering, personaleadministration s˚ asom lønninger, etc. etc. Databasen eller databaserne er med altovervejende sandsynlighed administrerede af et RDBMS, der kan udføre et astronomisk antal transaktioner per tidsenhed vedrørende organisationens aktiviteter. Formanden p˚ a gulvet i en fabriksafdeling ønsker svar p˚ a, hvor mange kg han har tilbage af komponent z som skal blandes med komponent y for at kunne producere den ønskede mængde x af halvfabrikata q som skal indg˚ a i produktionen af en ordre. I virksomhedens anden ende bekymrer salgschefen, marketingfolkene, m˚ aske endda bestyrelsen, sig om formuleringen af en salgsstrategi for segmentet suburbia 1 . De har brug for at kende tal for det ˚ arlige salg af det aktuelle produkt, fordelt p˚ a m˚ aneder og i øvrigt sæsonjusteret. Tallene skal dække de seneste fem ˚ ar med henblik p˚ a at kunne lave en prognose for de næste tre. De sidstnævnte har med andre ord et meget større perspektiv. De sidstnævnte har brug for aggregeringer af data snarere end detaljer. Begge perspektiver er nødvendige og relevante. I datavarehusterminologi taler man om datas finkornethed2 . Detaljerigdommen i en virksomheds data skal være høj, idet man ellers ikke kunne h˚ andtere formandens behov. Salgsstrategiens behov opn˚ as derefter ved aggregering. Det kan ikke lade sig gøre at findele data til en detaljeringsgrad højere end den, hvori data opbevares, mens aggregeringer af detaljer kan udføres til et hvilket som helst ønsket niveau. SHU (1998) citerer Disney-selskabet Buena Vista:“Et datavarehus er en database til beslutningsstøttesystemer. Dens data kommer fra virksomhedens operationelle system og modificeres og kombineres med henblik p˚ a brugernes analyse.” Med andre ord henter vi data ud af virksomhedens operationelle system og dets database(r), sætter dem ind i varehuset og bruger dem til analysearbejde. I lyset af ovenst˚ aende citat og rationalet bag det, kommer vi til modstykket til den operationelle OLTP database, det analytiske OLAP datavarehus. OLAP er akronym for On Line Analytical Processing og er i praksis forretningsprocesserne bag et andet IT buzzword fra en af datavarehusomr˚ adet store aktører, SAS Institute, der kalder det Business Intelligence. For at bringe det ned p˚ a jorden kan vi sige, at et datavarehus er en slags database. I indledningen til en afhandling om disse ting skriver den relationelle models fader Codd 1 2

Typisk markedssegment. Granularity, p˚ a engelsk.

157


Kapitel 19: Datavarehuse

(1993): “This paper defines a category of database processing: Online Analytical Processing [OLAP]. This paper defines the OLAP category, describes an enabling architecture ...” I den nævnte afhandling beskriver forfatterne tolv regler til karakterisering af OLAPprodukter. Reglerne citeres bredt i fagkredse fx. b˚ ade hos SHU (1998) og Agosta (1999), der kan være særdeles nyttige kilder. Det er klart, at reglerne er møntet p˚ a OLAP i den forstand, at de opstiller nogle kriterier, som et ordentligt OLAP-produkt bør lve op til. De kan dog, med nogle f˚ a undtagelser ogs˚ a anvendes som kriterier i forbindelse med valg af et traditionelt OLTP-system. Nogle af reglerne beskæftiger sig med den begrebsmæssige datamodel, andre med den logiske implementeringsmodel, og alle g˚ ar de p˚ a analytikerens interesser. De tolv punkter er: 1. Et multidimensionalt begrebsmæssigt syn p˚ a data 2. Transparens 3. Tilgængelighed 4. Fornuftig performance for udtræk af data 5. Client/Server-arkitektur 6. Generiske dimensioner 7. Dynamisk h˚ andtering af tyndt befolkede tabeller 8. Understøttelse af flere brugere 9. Uhindret adgang til operationer p˚ a tværs af dimensioner 10. Intuitiv datah˚ andtering 11. Fleksibel formatering af udtræk 12. Ingen begrænsninger i dimensioner og aggregeringsmuligheder

19.2

Datamodellering

19.2.1

Den relationelle model

I lyset af et datavarehus behov er der aspekter af den relationelle model, der er, om ikke tvivlsomme, s˚ a diskutable. I forrige afsnit er firkornetheden, granulariteten af organisationens data omtalt i forbindelse med afvejning af OLTP-systemets behov for atomare data op mod OLAP-systemets ønske om en vis aggregering. Dette er en potentiel konfikt i forhold til den relationelle models normaliseringskrav. Adskillige kilder fremhæver ogs˚ a, at den relationelle model, som ofte visualiseres gennem et ER-diagram, er alt for kompleks for den almindelige bruger. Herimod kan argumenteres, at den almindelige bruger m˚ aske sjældent er interesseret i helheden, men blot i en del af den. Helheden er ofte kompleks. Selvom man i et systemudviklingsprojekt kan præsentere en del af en konkret datamodel for brugerne, og derved f˚ a dem til at forst˚ a den “bid for bid”, har man stadig analytikerens behov for at se modellen i sin helhed for at kunne bruge den. Tager vi eksempelvis punkterne 1, 6, 9 og 12 og ser dem underordnet punkt 10, kan vi forst˚ a behovet for en forenkling. SHU (1998) ser et praktisk problem som kan være en potentiel forhindring p˚ a vejen mod en datavarehus-applikation. Der skal tid til at hente data ud af OLTP-systemet og indsætte dem i datavarehuset til OLAP-brug. Virksomheder af en vis størrelse og alder kan have s˚ a store datamængder, at det ikke umiddelbart kan gøres i løbet af en nat, og dermed have mulighed 158

©nml


19.2: Datamodellering

for at ske relativt usynligt for brugerne. Behovet er klart at perioden, hvor datavarehuset ikke er konsistent, skal være b˚ ade kort og hensigtsmæssigt placeret i forhold til brugernes aktivitet. Med disse problemstillinger i tankerne skal vi nu se p˚ a, hvordan den relationelle model eventuelt skal vrides for at kunne bruges.

19.2.2

Den dimensionale model - relational OLAP

Det er m˚ aske her p˚ a sin plads at fremhæve, at den dimensionale model, som skal beskrives, ikke beskrives “forfra” med definitioner af strukturelle elementer, regler og operationer, s˚ aledes som det i kapitel 4 var tilfældet med den relationelle model. I stedet beskrives modellen relativt løst, og egentlig mest som en variation over den relationelle model. Den relationelle models grundbegreber tuplen og relationen best˚ ar, ligesom dens integritetsregler. Ligeledes tilføres der ikke nye operationer. Der er intet i den relationelle algebra eller calculus, der ikke kan benyttes igen. Om man i dette lys kan tale om den dimensionale model som en egentlig datamodel er vel tvivlsomt. Vi vil dog bruge sprogbrugen, omend vi alts˚ a snarere beskriver en anvendelsesvariant af den relationelle datamodel. Dimensioner som begreb er nævnt flere gange i Codds tolv punkter. Vi tale ofte indenfor bogholderi og regnskabsvæsen om en kontoplan i et antal dimensioner. Eksempler p˚ a dimensioner herfra er sted, form˚ al, projekt, art etc.3 Betydningen heraf er ikke kompliceret. Det er attributter i tabeller som repræsenterer hver sin dimension. Den konkrete modellering vil understøtte muligheden for at lave forespørgsler, data mining, hvor dimensionerne anvendes til analytiske form˚ al. Den dimensionale model beskrives ofte som en terning, en kubus, hvilket nok mest er fordi terningens tre dimensioner er det højeste vi kan n˚ a p˚ a en tegning. Virkeligheden kræver ofte flere end tre dimensioner, man taler s˚ aledes om en hyperkubus4 . Det er klart at man i den relationelle model kan lave forespørgsler p˚ a værdier fra alle attributter i de involverede tabeller. Det skal derfor præciseres, at en dimension kan defineres som en attribut, hvorom man p˚ a forh˚ and ved, at den skal bruges til analyseform˚ al, og at man tilgodeser dette ved at etablere en tabel til registrering af mulige værdier for netop denne attribut. I vores modellering af data har vi ikke hidtil beskæftiget os eksplicit med de s˚ akaldt temporale aspekter. Databasens tilstand ændres, n˚ ar en relation ændrer værdi. Hvis der ikke i modellen er afsat attributter til at fastholde tidsmæssige data om hvorn˚ ar disse ændringer sker, bliver de ikke registreret. Databasen har blot f˚ aet en ny tilstand. Dette tillader intet historisk perspektiv, idet databsen er det til enhver tid gældende øjebliksbillede af dens data. Den dimensionale model arbejder med at inddrage tiden som en eksplicit dimension. I SHU (1998) siges det, at den relationelle model kan siges at være internt konsistent med en organisations aktiviteter, mens den dimensionale model siges at være globalt konsistent p˚ a grund af dens registrering af tid omkring ændringer. Det at tid gøres til en eksplicit dimension forhindrer ikke, at vi kan etablere et hvilket som helst antal øvrige dimensioner. Det kan siges, at studenter registreret p˚ a kurser kan repræsenteres i en 2-dimensional matriks. P˚ a samme m˚ ade kan vi sige, at hvis en række viser navne p˚ a et email-posthus, og kolonnerne afspejler aldersfordelingen p˚ a de deri beroende mails, s˚ a er dette ligeledes et eksempel p˚ a en 2-dimensional matriks. Se for eksempel illustrationen af et ark i et regneark i tabel 19.1. Regnearkets enkelte celle indeholder en værdi, og regnearkets samlede mængde af værdier p˚ a et givet tidspunkt er regnearkets værdi. Lad os nu forestille os, at vi anbragte et antal udgaver af dette regneark, men optalt p˚ a forskellige tidspunkter, den ene oven p˚ a 5 den anden. Regnearket ville blive en kubus , hvor tiden ville være den nye tredje dimension. 3

Se fx. under konto(regnskab) i http://da.wikipedia.org Hyper cube 5 Engelssproget litteratur bruger begrebet cube, der jo betyder terning. Denne terminologi er tilsyneladende allerede ved at vinde indpas p˚ a dansk. Der er dog intet krav om at kassen har lige store sideflader. 4

©nml

159


Kapitel 19: Datavarehuse

Enhver kan forestille sig en kubus, en terning, men hvordan ser det ud med flere dimensioner end tre? Der er dog ikke noget logisk i vejen for, at indføre flere dimensioner end de tre. Kubussen ville blive til en hyperkubus. Datamodelleringsmæssigt har vi et værktøj, hvormed vi kan beskrive modeller i n dimensioner. Posthus CMS CONS CSV ...

<30 min nn nn .. ..

30 min-60 min nn nn .. ..

60 - 90 min nn nn .. ..

... nn nn .. ..

Tabel 19.1: Tabel til illustration af en todimensional matriks, et regneark.

19.2.2.1

Star Schema - Stjerneskemaet

Stjerneskemaet er det grafiske udtryk for en n-dimensional model. Stjerneskemaet indeholder to forskellige tabeltyper, dimensionstabeller og s˚ akaldte faktatabeller. De indeholder begge data. Vi ser i figur 19.1 et eksempel p˚ a et stjerneskema. Det er citeret fra Larsen (1999). Det ses ret tydeligt at st˚ a i gæld til ER-modellen, se afsnit 3.2, i sit grafiske udtryk. Latens_i_posthus dimension Posthus dimension +posthus_id +beliggenhed

+tid_id +i_posthus_id +fra_posthus_id +til_posthus_id +alder_id +antal

Alder dimension +alder_id +aldersinterval

Tid dimension +tid_id +ugedag +år +helligdag_jn

Figur 19.1: Eksempel p˚ a et stjerneskema. Figur 19.1 viser et eksempel p˚ a, hvordan relationen mellem faktatabellen og posthusdimensionen modelleres. Den indeholder ligeledes relationer fra fakta til henholdsvis tidsdimensionen og dimensionen for email-alder. De tre relationer mellem fakta og posthuse er helt normale i ER-modellen, og bør s˚ aledes ikke være nogen stor overraskelse i den dimensionale model. Det kan være nyttigt for parallellitetens skyld lige at kaste et blik p˚ a figur 19.2 for at se, hvordan det ville have være tegnet i ER-diagrammet. Ikke den store forskel. Selv om vi i dette værk har tegnet relationer som figurer, er der adskillige varianter af ERmodelleringsgrafiske værktøjer, der tillader, at relationer blot udtrykkes som linjer mellem relaterede objekter. En væsentlig forskel mellem den dimensionale model er det, at mens den Relationelle model og s˚ aledes ogs˚ a ER-modellen er skarpe i kravet om normalisering p˚ a grund af ønsket om at undg˚ a overflødige data, s˚ a er dette krav opblødt meget i den dimensionale model, hvor man oven i købet taler om denormalisering. Elmasri and Navathe (2000) definerer denormalisering s˚ aledes: “Den proces hvorved et join af relationer p˚ a en højere normalform opbevares som basistabeller p˚ a en lavere normalform.” Ordet join bruges her i sin betydning fra den relationelle algebra og SQL. I daglig tale betyder denormalisering at vi ser gennem fingre med en vis redundans. Det kan retfærdiggøres 160

©nml


19.2: Datamodellering

Figur 19.2: En ER-grafisk udgave af relationen mellem faktatabellen og posthus-dimensionen fra figur 19.1. af, at vi har at gøre med historiske data, der ikke længere skal vedligeholdes. I datavarehuset vedligeholdes data ikke. Der tilføres hele tiden nye. Vi kommer s˚ aledes ikke af den grund i den opdateringsanomali, der i den relationelle grund er en hoved˚ arsag til, at vil vil undg˚ a redundans. Der argumenteres ogs˚ a for at tillade en vis redundans i den dimensonale model derved, at vi over tid kommer op p˚ a s˚ a store datamængder, at der vil være m˚ albare performancefordele herved. Vi kan sige, at vi flytter den relationelle verdens byrde af sikring af datas konsistens gennem RDBMSens h˚ andhævelse af rigoristiske regler. I den dimensionale verden er denne opgave overladt til et program udenfor datavarehuset, nemlig det system, der lægger data ind i varehuset. Løses opgaven her, kommer der ikke senere opdateringer, der kan ændre p˚ a datas konsistens. 19.2.2.2

The Snowflake Schema - Snefnugskemaet

En variant af stjerneskemaet til af en dimensional model er snowflake skemaet, snefnugskemaet. Det er karakteriseret ved i forhold til normalisering at være en mellemvej mellem stjernen som udtryk for den dimensioanle model og den relationelle, normaliserede model.

Figur 19.3: Eksempel p˚ a snefnugskema. Diagrammet i figur 19.3 er et snefnugskema. Sammenligner vi med stjerneskemaet fra figur 19.1 er der tilføjet de objekter, der vises med gr˚ a baggrund. Dette afspejler, hvad vi ©nml

161


Kapitel 19: Datavarehuse

kunne en renormalisering af modellen repræsenteret i stjerneskemaet. Ved et forsøg p˚ a at forudsige hvor store datamængder, der vil opst˚ a i varehuset, kan man vælge at opbevare dele af fakta atomart, og s˚ aledes gøre det muligt at normalisere til et højere niveau. Den potentielle mængde af data i varehuset er naturligvis det kartesiske produkt af antallet af forekomster i dimensionstabellerne i varehuset. Det er derfor klart, at potentielt vokser datamængden ekstremt, hvis alle celler, hvor dimensionerne krydser hinanden, er befolkede med værdier. Begrebet sparsity, egentlig knaphed, men her vel tyndt befolket, bruges til at beskrive, at dette ikke nødvendigvis er tilfældet, hvorfor en af den dimensionale models praktiske følger er, at RDBMSen, hvis man vælger s˚ adan en, der bestyrer varehuset, skal være god til at h˚ andtere sparsity, hvilket vil sige, at den skal kunne h˚ andtere ikke at afsætte tom plads, hvor der ingen data er. Samtidig skal produktet være godt til at h˚ andtere indeksering af store datamængder. Disse opgaver er højaktuelle her, hvor de i den relationelle models implementering er af mindre betydning.

19.2.3

Den Multidimensionale Model - Multidimensional OLAP

Der er ingen begrebsmæssig sondring mellem den dimensionale model beskrevet i forrige afsnit og multidimensionale OLAP, der kort skal beskrives her. Læseren vil bemærke at den dimensionale model ogs˚ a kaldtes relationel OLAP, alts˚ a antydede at den kunne h˚ andteres af et RDBMS. N˚ ar vi derfor kort skal se p˚ a multidimensional OLAP, MDOLAP, er det fordi, der er ved at opst˚ a implementeringer, software, der er specialiseret p˚ a dette omr˚ ade. S˚ adan software kalder vi MDDBMS6 . Der findes ingen standardisering endnu p˚ a omr˚ adet. Som proprietære systemer indeholder MDDBMSerne ogs˚ a b˚ ade proprietære forespørgselsmetoder og rapporteringsværktøjer. Præsentationslaget er dog i nogle produkter en grænseflade for aflevering af data til regneark, som ogs˚ a i relationel OLAP er brugt som analytikernes værktøj til videre forarbejdning og præsentation af analyseresultater. Der findes alts˚ a produkter allerede, ligesom der i den nyeste SQL-standard er visse OLAPudvidelser til sproget. En forlægger7 har sagt, at før en SQL-programmør kunne begynde at arbejde med OLTPsystemer skulle de aflære traditionel procedural programmering for at komme frem til SQLs deklarative, mængdeorienterede programmering. OLAP skulle være næste skridt i denne udvikling. Datavarehuse og OLAP ser aggregerede data i et tidsperspektiv. Det er endnu engang nødvendigt at aflære for at lære noget nyt. Et sikkert salgsorienteret udsagn, med med det gran af sandhed, der korresponderer med, at vi endnu ikke ved om OLAP-leverandørerne og især MDOLAP-leverandørerne vælger vælger SQL-udvidelserne eller fortsætter med de proprietære querymekanismer i endnu en periode.

19.3

Et datavarehuseksempel

bla bla

6 7

MultiDimensional Database Management System. http://www.powells.com om Celko (2006).

162

©nml


Kapitel 20

XML og Databaser Semistrukturerede data

163


Kapitel 20: XML og Databaser

164

Šnml


Kapitel 21

Afrunding Fremtid

165


Kapitel 21: Afrunding

166

Šnml


Bilag A

Dummy appendiks bla bla

167


Appendiks A: Dummy appendiks

168

Šnml


Bilag B

UML bla bla

169


Appendiks B: UML

170

Šnml


Bilag C

Eksempeldatabasen til kapitel 9 og 10 Dette appendiks indeholder fire blokke af SQL-kode. Disse fire blokke af SQL-kode, to CREATE TABLE deklarationer og to grupper af INSERT deklarationer kan en bruger indtaste direkte i sit eget databasesystem, udføre, hvorefter man skulle være i stand til at deltage i den efterfølgende tutorial i SQL Data, kapitel 10, hvis man skulle ønske at gennemføre denne del før SQL Skema i kapitel 9. Forklaringen p˚ a de fire kodeblokke findes i det relevante tutorialkapitel. Først etableres bog-tabellen ved udførelse af: create table bog ( bog_id

integer not null primary key,

bog_titel

varchar(40),

isbn

char(13),

udgivet_aar

integer,

indgaaet_dato

date default ’now’,

udlaanes_dage

int,

status_pris

numeric(6,2),

emne_kode emne_nr

char(2), int

);

Derefter emne-tabellen: create table emne ( emne_kode char(2) not null, emne_nr int not null, emne_navn varchar(50) not null, udlaanes_dage int not null default 30, primary key(emne_kode, emne_nr) );

I relationen bog er der en forbindelse til relationen emne, idet alle bøger burde tilhøre et registreret emne. Denne referentielle integritetsregel er et eksempel p˚ a de nævnte pædagogiske svagheder, idet reglen ikke er integreret i databasen endnu. Et kort blik p˚ a eksemplets data til de respektive relationer. Først befolkes bog-tabellen ved udførelse af følgende: insert into bog values(15,’IT kommunikation’,’87-7281-104-8’,2002, ’25-nov-2001’,30,238.40,’IT’,100);

171


Appendiks C: Eksempeldatabasen til kapitel 9 og 10 insert into bog values(100012,’SQL in a Nutshell’,’1-56592-744-3’,2001, ’13-apr-2001’,30,238.40,’IT’,167); insert into bog values(1,’IT kommunikation’,’87-7281-104-8’,2002, ’25-nov-2001’,30,238.40,’IT’,100); insert into bog values(10115,’The Database relational Model’,’0-201-61294-1’,2001, ’25-nov-2000’,30,238.40,’IT’,167); insert into bog values(13,’Fundamentals of Database Systems’,’0-201-54263-3’,2000, ’2-jan-2000’,30,450.00,’IT’,167); insert into bog values(12,’Learning Python, 2nd ed.’,’0-596-00281-5’,2003, ’09-dec-2003’,30,438.40,’IT’,200); insert into bog values(23,’The New Penguin Thesaurus’,’0-14-029311-6’,2002, ’17-aug-2001’,30,438.40,’NF’,30); insert into bog values(10114,’The Concepts of Programming Languages’,’0-201-38596-1’,1999, may-2000’,30,548.00,’IT’,200);

’2-

insert into bog values(19899,’Tcl and the Tk Toolkit’,’0-201-63337-X’,1994, ’25-nov-1994’,30,438.00,’IT’,210); insert into bog values(21,’DanskOrdbogen’,’87-7783-926-9’,1999, ’01-jan-2000’,30,400.00,’NF’,30); insert into bog values(22,’The New Penguin English Dictionary’,’0-14-029310-8’,2000, aug-2001’,0,538.40,’NF’,30);

’17-

insert into bog values(100001,’The Web Wizards Guide to XHTML’,’0-321-17868-8’,2005, ’25-aug-2004’,30,198.40,’IT’,190); insert into bog values(100002,’Kunsten at skrive speciale’,’87-500-3477-4’,1997, ’25-nov-2002’,30,238.40,’NF’,0); insert into bog values(14,’An Introduction to Database Systems’,’0-201-38590-2’,2000, feb-2001’,30,419.67,’IT’,67);

’2-

insert into bog values(10225,’The cathedral and the Bazaar’,’0-596-00108-8’,2001, ’25-nov-2001’,30,198.40,’IT’,100); insert into bog values(19875,’The Practice of Programming’,’0-201-61586-X’,1999, ’12-may-2000’,30,378.40,’IT’,21); insert into bog values(10,’The Code Book’,’1-85702-879-1’,1999, ’20-dec-2000’,30,378.40,’NF’,0); insert into bog values(11,’Teach Yourself JavaScript 1.3 in 24 Hrs’,’0-672-31407X’,2002, ’29-nov-2002’,30,250.00,’IT’,201);

Til sidst udføres indsættelse af data for emnerne gennem udførelse af: insert insert insert insert

172

into into into into

emne emne emne emne

values(’IT’,202,’Indføring i PHP’,30); values(’IT’,167,’Databaseteknik’,30); values(’IT’,272,’Kunstig intelligens’,30); values(’SK’,001,’Agent- og spionromaner’,45);

©nml


insert insert insert insert insert insert insert insert

©nml

into into into into into into into into

emne emne emne emne emne emne emne emne

values(’IT’,200,’Programmering med scriptsprog’,30); values(’SK’,000,’Diverse fiction’, 30); values(’IT’,100,’Grundlæggende informationsvidenskab’,30); values(’IT’,201,’Indføring i JavaScript’,30); values(’NF’,030,’Ordbøger og leksika’, 0); values(’NF’,000,’Diverse non-fiction’, 30); values(’IT’,168,’Datamodellering’,30); values(’SK’,060,’Lyrik’, 45);

173


Appendiks C: Eksempeldatabasen til kapitel 9 og 10

174

Šnml


Bilag D

Binary Large Objects from outer space Rolle, domænebeskrivelse Ustandardiseret

D.1

Binary Large Objects

Vis og diskuter eksempel p˚ a indsættelse i relation, og p˚ a ekstrakt til fx afspilning af lyd eller visning af billede Undersøg muligheden for brug af BLOB gennemren SQL, og hvis det g˚ ar beskrives det i SQL tutorial Brug Firebird eksempler MySQL eksemplerne kan vises i et appendiks

175


Appendiks D: Binary Large Objects from outer space

176

Šnml


Bilag E

MySQL-variant af BLOB-hË&#x161; andtering Skal disse eksempler medtages eller hur?

177


Appendiks E: MySQL-variant af BLOB-h˚ andtering

178

©nml


Bilag F

M˚ alinger og myter om RDBMSer Nogle simple eksperimenter afslører store tidsforskelle mellem de tre kendte OSS RDBMSer Firebird, MySQL og PostgreSQL med hensyn til performance. I et eksepriment, der egentlig var udløst af en provokation, nemlig forfatterens ønske om at tilbagevise p˚ astanden om, at brug af fremmednøgler ved normalisering til 3NF har signifikant betydning for RDBMSernes performance, afsløredes m˚ alelige forskelle mellem systemerne mere end mellem brug af fremmednøgler og afst˚ aelse fra brug af fremmednøgler. Lad mig beskrive afprøvningssituationen. Da standardeksemeplet p˚ a redundans oftest er beboere i postdistrikter, hvor postdistriktnavnet opbevares sammen med beboeren, valgtes med udgangspunkt i en dansk postnummertabel p˚ a 1225 postnumre at generere et sæt tabeller per RDBMS. create table runorm ( pa int not null primary key, fb varchar(13) not null, pn int not null, pd varchar(20) not null ); create table rnormb ( pn int not null primary key, pd varchar(20) not null ); create table rnorma ( pa int not null primary key, fb varchar(13) not null, pn int not null, foreign key(pn) references rnormb(pn) );

Tabel F.1: SQL Schema-deklarationer til Firebird og PostgreSQL I tabel F.1 ses SQL-Schema-deklarationerne brugt til at oprette tre tabeller en database i hver af RDBMSerne Firebird og PostgreSQL. I tabel F.2 ses de tilsvarende deklarationer til MySQL. Forskellen er nødvendiggjort af, at MySQL bruger en ustandardiseret syntaks for create table, n˚ ar den skal respektere referentiel integritet, brug af fremmednøgler. Der oprettedes alts˚ a en database i hvert af RDBMSerne. I hver af de tre databaser udførtes de viste relevante create table-deklarationer. Tabel runorm er en tabel med en nøgleattribut pa, der bruges som kundenummer, en attribut fb, der er et kundenavn, et postnummer pn samt et postdistriktnavn, pd. Alts˚ a ganske unormaliseret idet postdistriktet jo forekommer 179


Appendiks F: M˚ alinger og myter om RDBMSer create table runorm ( pa int not null primary key, fb varchar(13) not null, pn int not null, pd varchar(20) not null ) engine=innodb; create table rnormb ( pn int not null primary key, pd varchar(20) not null ) engine=innodb; create table rnorma ( pa int not null primary key, fb varchar(13) not null, pn int not null, foreign key(pn) references rnormb(pn) ) engine=innodb;

Tabel F.2: SQL Schema-deklarationer til MySQL redundant, da det gentages i hver kundeforekomst. Den modsvarende normaliserede situation afspejles af tabellerne rnorma og rnormb. Kundetabellen rnorma indeholder nøgleattributten pa, navneattributten fb og postnummeret pn, der er erklæret som fremmednøgle med reference til postdistriktabellen rnormbs postnummer, pn. Tabellen rnormb indeholder udover nøgleattributten, postnummeret pn, attributten pd, navnet p˚ a postdistriktet. Dette navn forekommer derfor kun en gang for hvert postdistrikt, alts˚ a normaliseret i overensstemmelse med 3NF. Derefter genereredes 1000 kunder i hvert postdistrikt. Herved fremkommer tabellerne runorm og rnorma med hver 1.225.000 tupler, da postnummertabellen indeholdt 1225 tupler. Lad os blot for eksemplets skyld se nogle f˚ a forekomster fra hver af de tre tabeller, se tabel F.3. ˜db/normunorm n˚ ar python benchmark program er klar laves count fra det program

180

©nml


pa

|

fb

|

pn

---------+---------------+------

pn

0 | Niels_0

| 1050

1 | Niels_1

| 1050

2 | Niels_2

| 1050

3 | Niels_3

| 1050

4 | Niels_4

| 1050

5 | Niels_5

| 1050

6 | Niels_6

| 1050

7 | Niels_7

| 1050

|

tabel rnorma a)

pd

------+----------------------

tabel rnormb b)

8420 | Knebel 8444 | Balle 8450 | Hammel 8462 | Harlev J 8464 | Galten 8471 | Sabro 8472 | Sporup 8500 | Grenaa 8520 | Lystrup pa

|

fb

|

pn

|

pd

---------+---------------+------+---------------------0 | Niels_0

| 1050 | København K

1 | Niels_1

| 1050 | København K

2 | Niels_2

| 1050 | København K

3 | Niels_3

| 1050 | København K

4 | Niels_4

| 1050 | København K

5 | Niels_5

| 1050 | København K

6 | Niels_6

| 1050 | København K

7 | Niels_7

| 1050 | København K

tabel runorm c)

normunormtest=> select count(rnorma.pn) from rnorma; count --------1225000 (1 row) normunormtest=> select count(rnormb.pn) from rnormb; count ------1225 (1 row) normunormtest=> select count(runorm.pd) from runorm; count --------1225000 (1 row)

Tabel a), © nml F.3: Indholdseksempler samt optælling af antal forekomster fra tabellerne rnorma 181 rnormb b) og runorm c).


Appendiks F: M˚ alinger og myter om RDBMSer

182

©nml


Litteratur Adams, D.: 1979, The Hitchhikers Guide to the Galaxy, Pan Books, UK. Agosta, L.: 1999, The Essential Guide to Data Warehousing, Prentice Hall, New Jersey. Celko, J.: 2006, Analytics & OLAP in SQL, Morgan Kaufmann, Elsevier, San Francisco, CA. Chen, P.: 1976, The Entity-Relationship Model - Toward a Unified View of Data, ACM Transactions of Database Systems 1(1), 9–36. Chen, P.: 1980, Entity Relationship Diagrams and English Language Structures, in P. Chen (ed.), Entity-Relationship Approach to Systems Analysis and Design, North Holland, Amsterdam, New York, Oxford, pp. 13–14. Codd, E.: 1970, A Relational Model of Data for Large Shared Data Banks, Communications of the ACM 13(6), 377–387. Codd, E.: 1971, Further Normalization of the Database Relational Model, IBM Research Report RJ909 . Codd, E.: 1974, Recent Investigations into Relational Database Systems, IBM Research Report RJ1385 . Codd, E.F.; Codd S.B.; Salley, C.: 1993, Providing OLAP to User-Analysts: An IT Mandate, E.F. Codd Associates and Hyperion Solutions Corporation. White Paper. Available at www.hyperion.com/whitepapers.cfm. Conolly, T. B. C.: 2005, Database Systems - A Practical Approach to Design, Implementation, and Management, 4 edn, Addison Wesley, Pearson Education Ltd., UK. Date, C.: 2000a, The Database Relational Model, Addison Wesley Longman, USA. Date, C.: 2000b, An Introduction to Database Systems, 7 edn, Addison Wesley, Reading, MA, USA. Date, C.: 2005, Database in Depth, O’Reilly & Associates, Inc., Sebastopol, CA, USA. Dietrich, S. W.: 2001, Understanding Relational Database Query Languages, Pearson Education, Prentice Hall, Upper Saddle River, NJ. Elmasri, R. and Navathe, S.: 2000, Fundamentals of Database Systems, 3 edn, Addison-Wesley, World Student Series, Reading, MA, USA. Elmasri, R. and Navathe, S.: 2003, Fundamentals of Database Systems, 4 edn, Addison-Wesley, World Student Series, Reading, MA, USA. Elsom-Cook, M.: 2001, Principles of Interactive Multimedia, McGraw-Hill International, London. 183


LITTERATUR Feil, Todd and Krone, J.: 2003, Essential Discrete Mathematics for Computer Science, Pearson Education, Inc., Upper Saddle River, NJ, USA. Kline, K. and Kline, D.: 2001, SQL in a Nutshell, O’Reilly, Sevastopol, CA, USA. Langefors, B.: 1977, Informations Systems Theory, Inf. Syst. 2, 207–219. Larsen, N.: 1999, Data Warehousing. Assignment Report filed for NIE module: Data Warehousing. Nørretranders, T.: 1991, Mærk Verden. En beretning om bevidsthed, Gyldendal, København, DK. Rønnow, T. and Jacobsen, C.: 1989, Design af Begrebsmæssige Datamodeller, Informatics, Viby J., Denmark. (Design of Conceptual Data Models). SHU: 1998, Data Warehousing, Graduate School of Computing and Management Sciences. Course material. Sheffield Hallam University. Tsichritzis, D. and Lochovsky, F.: 1982, Data Models, Prentice-Hall, Inc., New York. Zaniolo, C.: 1982, A new normal form for the design of relational database schemata, ACM Transactions on Database Systems 7(3), 489–499.

184

©nml

mller  

bog om lidt af hvert

Read more
Read more
Similar to
Popular now
Just for you