Hej.
Jag ska skapa en personaldatabas där man ska kunna slå upp vem som gör vad, var.
Principen är inte svår och kan nog liknas vid tex en säljorgnaisation.
Tanken är att man ska kunna så upp en ärendetyp, välja ett område och se vem som arbetar med det.

Relationer:
Grundprincip
En person kan arbeta med flera olika ärendetyper i olika områden.

Nedbrutet
I ett område kan det arbeta flera olika personer. 1:N
I ett område förekommer flera typer av ärenden. 1:N

En person kan arbeta med flera olika ärenden. 1:N
En person kan arbeta i flera olika områden. 1:N

En ärendetyp kan handläggas av olika personer (beroende på område) 1:N (Är det tankefel här?)
En ärendetyp kan förekomma i flera olika områden

Problem
Mitt problem är att jag fastnar på hur jag ska bygga relationerna. Jag har aldrig lyckats lära mig N:N.
Jag vet att man ska göra det via en kopplingstabell men får helt enkelt inte till det.

Jag har utgått från tre grundtabeller
Personer (PersonID som räknare och Primärnyckel) med Namn, Avdelning, telefonnummer etc.
Område (OmrådesID som räknare och Primärnyckel) med områdesnamn
Ärende (ÄrendeID som räknare och Primärnyckel) med typ av ärende/ansvar

Jag har försökt att skapa två mellanliggande tabbeller, kopplingstabeller mellan Person-Område resp Område-Ärende. Kopplingstabelelrna består av respektive huvudtabells primärnyckel, men här med datatypen tal, långt heltal. relationerna har jag satt som 1:N relation mellan Huvudtabellen(1) och kopplingstabellen (N).

OCH, det funkar inte.

Hjälp önskas. Jag vet inte, men tror att jag gör ett trivialfel någonstans på vägen, men så tusan om jag ser det.

När jag väl fått ordnign på själva databasen och dess relationer tänker jag bygga formulär etc i VB.Net

Jag tar gärna emot tips om bra webbplatser som beskriver problemet med N:Nrelationer. Har sökt men hittar inget riktigt bra.
/Lasse

N:N förhållande:
1. En person kan arbeta i fler områden och flera personer kan arbeta i ett område

CREATE TABLE PersonerOmråde (
    PersonID  int,
    OmrådesID  int,    
    PRIMARY KEY (PersonID, OmrådesID),
    FOREIGN KEY (PersonID) REFERENCES  Personer (PersonID),
    FOREIGN KEY (OmrådesID) REFERENCES  Område  (OmrådesID)
)

CREATE TABLE OmrådeÄrendeTyper  (
    OmrådesID  int,    
    ÄrendeTypID int,
    PRIMARY KEY (OmrådesID, ÄrendeTypID),
    FOREIGN KEY (OmrådesID) REFERENCES  Område  (OmrådesID),
    FOREIGN KEY (ÄrendeTypID) REFERENCES  ÄrendeTyper (ÄrendeTypID)
)

Frågor:
1. Kan flera personer arbeta mett ett ärende?
2. Kan ett ärende ha flera typer?
3. Kan en ärende typ bara tillhöra ett område?

Svar:
1. Ja flera personer kan arbeta med samma typ av ärende. (Både Pia, Ida och Daniel arbetar med avfallsfrågor)
2. Osäker på om jag förstår dig där. Inom ärendetypen "avfall" kan man tänka sig olika undertyper, (Avfall - Industri, avfall - hushåll, avfall - båthamnar)
3. Nej ärendetypen förekommer i flera områden. (eg en person ansvarar för avfallsfrågorna i en del av staden)

Ok, du har beskrivit sqlkod för att genererar kopplingen via en mellantabell. Så långt ok.
Jag antar att jag helt enkelt kan lägga den som kod i VBformuläret då eller?

Men när du skriver:

CREATE TABLE PersonerOmråde (
PersonID int,
OmrådesID int,
PRIMARY KEY (PersonID, OmrådesID),

...Är jag inte med. Är både PersonID OCH OmrådesID primärnycklar i tabellen personOmråde?
Kan man ha fler primärnycklar i en tabell? Eller är det bara beskrivnignar av PK i resp huvudtabell?

Det finns bara en primärnyckel och den primärnyckeln består av flera fält. Din exempeldata gör det lite klarare.

Jag tro det krävs en hel del kopplingstabeller till för att lagra allt du vill.

JAg antar att man skall ange vilka personenr som jobbar i et område och med vilka typer av ärenden. Det är en trevägs N:M relation.

osv...

..osv? :-)

Efter samtal med en vänlig och förstående lillebror har jag löst min gordiska knut.
Tack för hjälpen, jag kom på rätt väg.