Design af database

"så opretter den en kopi af Node tabellen, der hedder Node_1. Er det godt?"

Er det ikke fordi du allerede har en relation?

Højst sandsynligt. Og det er nok også problemstillingen, som mit spørgsmål udspringer af. Hvis man kun kan have 1 foreign key relation i en tabel, hvad gør man så, når man har brug for 2 :-)

Du kan kun have een nøgle i din tabel. Hvis flere felter skal indgå i PK:

Så holder du SHIFT-tasten nede og markerer de felter, der skal indgå i din sammensatte nøgle og trykker på ikonet med en nøgle.

Mugs: Jeg er ikke helt med. Det eneste sted man kan trykke på en nøgle er i Table Design View. Hvorfor skal jeg slå 2 felter sammen til at udgøre en fællles primary key. Jeg kan ikke se hvordan det kan løse min problemstilling.

Jeg har en tabel, hvor 2 Foreign Keys skal relatere til den samme primary key i en anden tabel og vil gerne blive klogere på hvordan man kan designe/håndtere den situation.

Problemstillingen må være velkendt i andre sammenhænge. Et musik nummer med 3 composer felter. En person med 2 telefonnumre/adresser. Osv.

"Hvorfor skal jeg slå 2 felter sammen til at udgøre en fællles primary key."
Det er heller ikke sikkert, at det er nødvendig at have en sammensat nøgle, men det var den måde jeg forstod dit problem!

"hvor 2 Foreign Keys skal relatere til den samme primary key i en anden tabel "
Så vil Acess oprette en ny ralation og dermed oprette tabellen Node_1 i relationsvinduet fodi du i forvejen har en relation til PK i fremmedtabellen.

Hvis du i begge tabeller har et unikt indeks i tabeller fælles for begge poster, kan du evt. prøve med en DLookUp i en forespørgsel. Funktionen henter data fra en anden IKKE RELATERET tabel hvos der er en fælles identifikation for posterne.

I eksemplet med composer: Hvis det er tilfældet, at den samme composer har 3 kompositioner, og disse er samlet i een post sådan:

ID    FELT      KOMP1      KOMP2      KOMP3
  1    Composer  aa        bb        cc

Vil jeg sige, at din db er forkert struktueret. Jeg ville bruge een post til hver KOMP, og så relaterer til ID feltet med en een til mange relation.

Dit eksempel med en composer, der kun laver 3 numre er jo (næsten) essensen af mit spørgsmål(selvom jeg nok ville vende den om og sige, at et musiknummer kun kan have 3 composere :-) )

Lad os for at blive i musik verdenen sige, at du lavede en tabel over alle kunstnere i verden. Dit job var nu, at lave en tabel med alle musik numre i verden.

Men du er nødt til at tage hensn til følgende:
- Et musik nummer bliver fremført af en kunstner
- sangteksterne bliver skrevet af en kunstner
- musikken komponeres af en kunstner

Der er altså forskellige former for kunstnere, men en kunstner som eks. Kim Larsen kan sagtens tilhøre alle 3 underkategorier.

Da du gerne vil kunne finde alle musik numre fremført/skrevet eller komponeret af en bestemt kunstner, så er det vigtigt at kunne skilne mellem typerne af kunstner. Kim Larsen kan godt have lavet lyrics til at nummer fremført at Lone Kellerman. Men både Lone Kellerman og Kim Larsen er kunstnere.

I min modellering skal jeg repræsentere noget der minder om et 1-til-2 relationship. Det ligger helt fast, at et link består af 1 fra- og 1 til-node, men det kan ikke repræsenteres ved et 1-to-many relationship, da det er vigtig, hvilken af de to nodes der er fra-node og hvilken, der er to-node.

Det er derfor oplagt at designe Link-tabellen som en tabel med 2 FK til Node. En anden tilgang ville være at oprette to ens tabeller, der hedder FromNode og ToNode, der begge indeholder alle Nodes. Så vil man kunne lave sine relationships mellem Link og de to Node tabeller. Men det kræver at man gemmer alle Node data dobbelt!!!!

Jeg efterlyser simpelthen en bedre tilgang til designet.

Når du bliver ved med at tale om noder, går jeg ud fra, at du virkelig har check på emnet! For det er ikke et område jeg har gjort særlig meget i.

Du skal ikke tænke så meget på kunstnere, men på den enkelte persons rolle i forhold til en komposition. Jeg ville oprette 3 tabeller, der hver for sig er et register over:

- Komponist
- Tekstforfatter
- Arrangør

Herefter en 4. tabel, der ved hjælp af kombinationsbokse henter relevante data fra de 3 registrer. Bemærk, at f.eks. Kim Larsen kan jo sagtens kan optræde i alle 3 tabeller. Rent teknisk i db, er han således 3 forskellige personer.
Denne 4. tabel skal så have een til mange relationer til de øvrige 3 tabeller.

Hehe. Noder? Som i musik og noder? Jeg aner intet om noder!

I min verden er en Node det engelske ord for knudepunkt - altså et sted hvor 1 eller flere veje mødes og udgør en form for kryds eller drejemulighed. Jeg skal arbejde med biltrafik, digitale kort og ruteplanlægning. Hvis du skal kunne finde vej fra A til B, så skal du følge en rute gennem mange vejstykker - dem kalder jeg Links. Det går ikke at lade en bil køre i den forkerte side af en vej eller imod en ensretning og derfor er der forskel på et link, der går fra knudepunkt A->B og B->A.

Anyways. Det virker bare så ulogisk at duplikere sine data til flere tabeller med forskellige tabelnavne.

Ligesom der er mange kunstnere i verden, så er der også ret mange vejkryds i et digitalt kort over eksempelvis København. At oprette 2 tabeller, der bortset fra navnet er fuldstændig ens, lyder ikke som en optimal løsning.

Jeg har naturligvis mulighed for at joine node og link sammen i en query, men jeg havde bare håbet, at der var en god måde at opretholde relationer samtidig med, så datavalideringen i Access sikrede, at jeg ikke havde korrupt data.

Med din formulering kan en node have 2 roller i forhold til et Link. Den kan være enten fra-til node, Origin-destination, Start-end. Kært barn har mange navne.

Vedr. noder, læs artiklerne om TreView kontrollen:

http://www.eksperten.dk/artikler/Databaser/Access/

Jeg kom ikke rigtig videre med Treeview artiklerne. Udover at Treeview benytter navnet Node i sin abstraktioner, så har jeg ikke opnået designmæssige aha-oplevelser, der kan overføres til designet af min Digitale Kort Database.

Jeg må klare mig med joins. Har ikke lyst til at duplikere Nodes tabellen og hvis man ikke kan designe sig til at basic data kan ligge i 1 tabel og derefter antage forskellige roller i relationer, så må det jo være en begrænsning ved SQL.

Jeg siger tak for indsatsen Mugs. Smid et svar så får du point.

Tak.