Mapning fra Klassediagram til Relationel database!

Du skal naturligvis sørge for at have kardinaltet med på dit klassediagram - så giver det sig selv! :-)

sorry lidt for hurtig dér

Men stadig væk, så er det jo sådan - i mange tilfælde kan du løse det ved at lave en type tabel. Feks biltyper, der hører til biler.

Aggragering er jo i princippet det samme som en normal relation, bare med noget ekstra afhængighed. Dette vil man normalt mappe, som man gør med normale relationer, dog kan det være en fordel, hvis det er en stærk aggratering, at bruge den funktionalitet nogle databaser har med at man kan gøre tubler afhængige af hinanden, så hvis den ene slettes, slettes den anden også.
Generalisering laver jeg normalt ved at have samme primærenøgle i alle tabeller, og så igen bruge den funktionalitet hvor tubler er afhængige af hinanden.

ok.. hvis man fks har en superklasse der hedder
bil
og en generalisering der er toyota og porche
vil jeg så ikke være nød til at lave en tabel der hedder bil med biltype som primær (fks)
og så have den som fremmed nøgle i toyota og porche sådanne så tabellen \"bil\" har de generelle attributter for subklasserne? og subklasserne så har de attributter som er individuelle for hver bil?

og med aggregering: den tror jeg bare man mapper som en normal relation med primær nøgle som fremmed nøgle i subklasserne ligesom en generalisering men at superklassen kun har sine egne attributer og at subklasserne ikke arver nogle attributter fra superklasser

Hvis vi har klasen bil og så subklasserne toyota og porche, så ville jeg give bil-klassen en primærnøgle der fx hedder bilId og denne tabel skulle så også indeholde de atributter der er fælles for alle subklasser (altså de atributter der er defineret i klassen). Jeg vil så lave en tabel for hver subklasse og begge disse subklasser har så også bilId, men denne er både primærnøgle og fremmednøgle med relation til bil-klassen.

Aggragering: Selvfølgelig skal superklassen ikke har nogle atributter fra subklasserne det er jo seperate klasser.

Normalt vil det være sådan at du har en tabel for hver klasse (dog har du selvfølgelig en ekstra hvis der er mange til mange relationer), men en klasse vil i de fleste tilfælde have sin egen klasse om det så er en klasse der arver fra en anden eller hvad det er.

ok.. et sidste spørgsmål.. grunden til at du siger du vil lave en porche tabel og tage bil tabellens primær nøgle og lave den til fremmed nøgle i porche tabellen og så en primær nøgle i porche tabellen er det så du slipper for at lave en ny primær nøgle i porche tabellen? eller ligger der noget dybere i det? :)

og hvis jeg har en 1:1 relation hvordan mapper man den? (ja jeg er MEGET ny til mapning :))
jeg mener hvis du har en mand.. og en kone.. så kan manden jo have en kone.. og konen kan have en mand.. hvordan sætter man så en primær nøgle og en fremmed nøgle?

Der er jo ikke nogen grund til at Porche-tabellen har sin egne primærnøgle da der aldrig vil kunne eksistere en tubel i den uden der findes en tilhørende tubel i bil-tabellen. Og da det er arv kan en tubel i bil-tabellen kun have én tubel i enten den ene eller den anden sub-tabel.

1:1: I dette tilfælde vil konen så have mandens primærnøgle som fremmednøgle og omvendt.
-Lige i dette tilfælde giver det stor mening at både manden kender konen og omvendt, men ofte skal man overveje om det er nødvendigt at de kender hinanden begge vej. Fx bør en bil kende sine sidespejle, men det er jo ikke nødvendigt for sidespaejlene at kende bilen.

du skal nok ikke bruge kone mand men Far søn så passer det på dine klasser ( arv og tilhørsforhold )

/Martin