Database Relationer

Fra Holstebro HTX Wiki
Spring til navigation Spring til søgning

For at få det ønskede indhold i en database, så er det nødvendigt at designe den rigtigt.

Det handler både om at få det rigtige indhold gemt i databasen, men det handler måske endnu mere om at få databasen struktureret rigtigt, så man ikke skal gemme noget flere gang, hvilket ellers er en klassisk design-fejl i en database.

For at sikre sig at databasen er opbygget korrekt, når normaliserer man en database. Det sikrer at indholdet er gemt rigtigt i databasen.

Relation

En relation er det der knytter to tabeller sammen, altså at noget i en post i en tabel henviser til en post i en anden tabel, så man angiver at dette indhold hører sammen med.

Et eksempel på en relation er at en faktura har netop EN kunde, så man i den enkelte faktura kan henvise til en bestemt kunde i kundetabellen. Omvendt så kan en kunde godt have mange fakturaer. Lige netop dette eksempel viser, at man kan have alle kundeoplysninger liggende i en tabel, og så henvise fra en faktura med blot et kundenummer. Det betyder at man ikke behøver at indtaste alle kundeoplysninger hver gang man opretter en ny faktura til den samme kunde, man skal blot taste kundenummeret.

Relationstyper

Der findes tre måder tabeller kan bindes sammen på med relationer: 1-mange, mange-mange og 1-1 [1].

En 1-mange (læses en til mange) relation er den mest brugte relation i databaser, og det er netop at en post i en tabel kan henvise til en anden post i tabellen. Det at det er en en til mange relation betyder at posten i den ene tabel KAN henvise til mange forskellige poster i en bestemt anden tabel - den henviser kun til en bestemt, men andre poster i tabellen vil så sikkert henvise til andre poster i den samme tabel.

I eksemplet med fakturaer og kunder er det sådan at hver kunder kan have mange fakturaer, men den enkelte faktura har kun tilknyttet EN kunde. Der kan jo også være mange kunder med hver deres faktura.

En mange-mange (læses mange til mange) relation betyder at en post i en tabel kan have mange henvisninger til mange andre poster i en anden tabel.

I eksemplet med fakturaen, så bliver en henvisning til en vare til en mange-mange relation. Det er fordi der på den enkelte faktura kan være mange forskellige varer, og det er samtidigt mange forskellige varer der henvises til. Samtidigt er det sådan at varer kan indgå i mange forskellige fakturaer.

Det kan altså ikke lade sig gøre at henvise hverken fra den ene eller den anden tabel, uden at man skal lægge mange ens attributter ind i tabellen, og det er en dårlig praksis, da man så vil begrænse sig til det antal man bestemmer sig for, og man vil have tomme henvisninger hvis ikke alle er brugt.

En mange-mange relation kan dog stadig fint optræde i et E-R diagram, det gør bare at man skal håndtere det lidt specielt når man opretter tabellerne.

Det man gør er, at man laver en mellem-tabel, hvor hver post henviser både til den ene og den anden tabel.

I eksemplet med varer på en faktura, så vil man få lige netop det antal poster i denne mellem-tabel, som der er varer på fakturaen (man kunne kalde det en vare-henvisnings-tabel). Hvis der kun er de to henvisninger, så vil 3 af en bestemt vare kræve 3 poster i henvisningstabellen. For at gøre det smartere, så kan man lægge antallet ind i henvisningstabellen, og der kunne måske også tilføjes en rabat-sats (fx mængderabat).

Den sidste type relation, en 1-1 (læses en til en) er en sjældent brugt relation, da den forudsætter at der kun henvises til en post EN gang. Et eksempel kan være en sælger-tabel der knyttes sammen med en salgsrute-tabel, hvor det er en bestemt sælger der har en bestemt rute.

Relationen vil således kunne placeres i begge tabeller, så sælger-tabellen henviser til ruten, men det kan lige så godt være at ruten henviser til sælgeren, og man kan faktisk have begge henvisninger.

Et andet klassisk eksempel på en 1-1 relation er en "gift med" relation, i en person-tabel, hvor det (ifølge dansk lov) er sådan at man kun kan være gift med EN person. Her vil man i person-tabellen kunne henvise til en anden post i samme person-tabel. Det vil så typisk være sådan at den anden person henviser tilbage til den første, da de jo er gift med hinanden.

Der er normalt ikke noget i database-automatikken der forhindrer at der ikke går rod i 1-1 relationer. Det vil betyde at man selv skal sikre (med kode skrevet til databasen), at man ikke laver rod i systemet, og at man overholder loven - at en person ikke er gift med flere personer, at de personer der er gift også er gift med hinanden, og endelig at en person ikke kan være gift med sig selv.

Nøgler

For at en database skal fungere godt med relationer, så skal hver tabel have en Primær nøgle, så det er denne nøgle der henvises til fra andre tabeller [2].

Når der henvises til en post i en anden tabel, så gør man det med en Fremmed nøgle, så hvis der på en faktura er en bestemt kunde, så henviser man til denne kundes kundenummer, og i fakturatabellen er det så en fremmed nøgle, mens kundens kundenummer er primær nøglen i kundetabellen.

Referencer

  1. systimes Informatik B til EUX omkring relationer
  2. Systime informatik B til EUX gennemgår primær og fremmed nøgler
Database
Database E-R diagram - henvendelse fra en Form - Database med onecompiler - Normalisering - Relationer - Tabel struktur diagram - Database Visning