Virksomheder er på vej fra store sprogmodeller, der svarer på spørgsmål, til AI-agenter, der kan udføre opgaver på egen hånd. Det gør teknologien mere nyttig – og langt mere risikabel.
Nej det er under design processen, hvis at man f.eks. har en tabel som hedder person med PersonID som PK og en tabel som hedder f.eks CvSturktur også med en Fremmednøgle af PersonID som PK, og så fra den har man endnu en tabel som hedder f.eks. CvLinier med En fremmednøgle af fremmednøglen PersonID.
Den sidste PersonID vil så være transitivt afhængig af den første PersonID igennem PersonID i tabellen CvSturktur, og det er ulovligt database mæssigt.
Men jeg kan ikke huske hvad man skal gøre i sådan situation, og det er mit spm.
Entiteten \'CvStruktur\' kan formentlig ikke eksisterer uden entiteten \'Person\'. D.v.s. det er en svag entitet. For hver svag entitet oprettes en relation, hvortil alle simple attributer knyttes (hvilket også inkluderer attributterne som indgår i en sammensat attribut - \"composite attribut\"). Multivaluede attributter medtages ikke. Nøglen fra \"ejer\" entitet tilføjes relationen. Primærnøgle er sammensat dels af nøglen som medtages fra \"ejer\" entiteten, dels af den svage entitets nøgle. Og det samme gør sig vel også gældende for entiteten \'CvLinier\' ?
Simple attributter = almindelige attributer (Fornavn, Efternavn, Adresse, Postnr., By o.s.v.). Jeg mener at dine entiteter \'CvLinier\' og \'CvStruktur\' ikke kan eksisterer uden entiteten \'Person\' (Der er ingen mening i at have et CV uden en person, men man kan vel godt have en person uden CV [indtil han / hun får det lavet] :). Derfor er \'CvLinier\' og \'CvStruktur\' afhængige af \'Person\' og derfor svage entiteter. Du får så én ny tabel (relation) der indeholder alle attributer fra de tre entiteter og en sammensat PK der består af alle entiteternes PK. Jow\' dit scenarie er ikke helt \'efter bogen\' :)
Kender du til EER-diagrammer og Mapningsprocedure ?
Næ, det tror jeg såmen ikke. Det afhænger nok meget af om man er til tekstuelle fremlægninger (Normalisering) eller til mere grafiske former (EER-diagrammer).
Min \'HD\' står af når jeg når 4. normalform ... derfor bruger jeg EER-diagrammer og Mapning ...
\'Biblen\' til \'EER-diagrammer\' og \'Mapning\' er nok \"Fundamentals of Database Systems - ISBN: 0-201-54263-3\" (ca. 500,- kr.), men mon ikke der findes meget på nettet om det også ...
Vil du have min danske oversættelse af \'Mapningstrinene\' ... måske de kan inspirerer dig undervejs i \'Normaliseringen\' ... ?
Mapning fra ER-diagram til den relationelle model.
1. For hver regulær entitet i ER-skemaet oprettes en relation, hvortil alle simple attributter knyttes (hvilket også inkluderer attributterne som indgår i en sammensat attribut - \"composite attribut\"). Multivalued attributter (flerværdi attributter) medtages ikke. Primærnøgle vælges - evt. som sammensat nøgle.
2. For hver svag entitet i ER-skemaet oprettes en relation, hvortil alle simple attributer knyttes (hvilket også inkluderer attributterne som indgår i en sammensat attribut - \"composite attribut\"). Multivaluede attributter medtages ikke. Nøglen fra \"ejer\" entitet tilføjes relationen. Primærnøgle er sammensat dels af nøglen som medtages fra \"ejer\" entiteten, dels af den svage entitets nøgle.
3. Ved binære forhold af typen 1:1 - binær 1:1 relation i ER-skemaet medtages primærnøglen fra den ene relation i den anden relation, som en fremmednøgle. Hvis begge entiteters deltagelse er total, så kan de samles i een relation. Hvis den ene entitets deltagelse er total, så indsættes fremmednøglen i dennes relation.
4. Ved binære forhold af typen 1:M i ER-skemaet medtages primærnøglen fra den \'1\' sidede relation i den \'M\' sidede relation som fremmednøgle.
5. Ved binære forhold af typen N:M i ER-skemaet skal der skabes en ny relation mellem de deltagende entiteter. Til den nye relation knyttes \'forholdets\' simple attributter - hvilket også inkluderer attributterne som indgår i sammensatte nøgler - samt de primære nøgler fra de deltagende entiteter. primærnøglen bliver i relationen dannet af de deltagende entiteters primære nøgler - relationen vil således få en sammensat primærnøgle.
6. For hver \'multivalued\' attribut skal der oprettes en relation. Hvis \'multivalued\' attribut er en sammensat attribut så medtages de enkelte attributter i relationen. Primærnøglen dannes af nøglen i den relation som attributten relaterer sig til samt af den bestemmende attribut i relationen.
7. Fravigelser fra binære forhold. Forhold af n\'te grad behandles på lige fod med binære M:N forhold.
8A. Der oprettes en separat relation for superklassen samt for hver af subklasserne. Superklassens primære nøgle medtages i samtlige subklasser. de enkelte subklassers primære nøgle er sammensat af superklassens nøgle samt af subklassens \'egen\' nøgle.
8B. Der oprettes kun subklasser. Disse indeholder også superklassens specifikke attributter - det forudsætter dog total specialisering samt at subklasserne er disjunkte.
8C. Der oprettes en superklasse indeholdende alle subklassernes specifikke attributter. I superklassen indsættes et typefelt til identifikation af \'den aktive subklasse\' - det forudsættes, at der er tale om disjunkte - adskilte - subklasser, for ellers kan de ikke identificeres via et typefelt.
8D. Der oprettes en superklasse indeholdende alle subklassernes specifikke attributter. I superklassen indsættes typefeltet til identifikation af den \'aktive\' subklasse - det forudsættes at der her er tale om \'overlappende\' klasser.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
