Det är lättare än du tror. Vi tar ett förspänt exempel med följande två tabeller; tblkund, tblorder.
Kan tex en kund göra flera beställningar?
Kan en och samma order göras av flera kunder?
Om man utgår ifrån att svaret på fråga ett är JA. Då kan ju flera rader i tblorder kopplas till samma kundnr. Vi har alltså många till en. Svaret på fråga två är sannolik ja, men i praktiken är det liten chans att flera kunder gör exakt samma beställning. Resultatet blir att du inte behöver göra en många till många relation här. Du kan nöja dig med att låta en kund göra hur många beställningar som helst, så länge den betalar alltså.
Ett rättighetssystem, där användare och saker de skall kunna komma åt finns, kan modelleras på följande vis: UserTable[1]-----[N]UserEntityAccess[M]-----[1]Entity.
D.v.s. i UserEntityAccess sparar du information om vilka användare som får komma åt vilka entities. I den tabellen kan samma användarid finnas flera gånger och samma entitetsid finnas flera gånger (dock endast på samma rad en gång!). I detta scenario finns det en många-till-många-relation mellan användare och entiteter.
Du har redan en många-till-många-relation mellan ordrar och produkter. Resultatet av den relationen är tabellen tblOrderrader. (Man kan ifrågasätta huruvida Antal skall vara med som ett fält i den tabellen, men det är en helt annan femma.)
Tycker att du börjar få en bra ordning på dina exempel.
Du bör kanske gå ett steg längre dock i normalisewringen.
Jag tycker att det var ett bra exempel du hade även där.
Men det finns en fjärde grad.
Fundera på vad som händer om kunden byter adress eller telefon! Hur kan du säkerställa historiska data.
Och en Produkt har olika pris vid olika tidpunkter. Där bör man se upp!
Så normalisera lite till och var inte rädd för TS.
Jag har tolkat det som att kundnr i tblkund är en primärnyckel och att kundnr i tblOrder är en sekundärnyckel. Trodde att sekundärnyckel är samma sak som en främmande nyckel!?
Vad är isåfall en sekundärnyckel i min tabellstruktur?
Sekundär nyckel är (nödvändigtvis) inte samma sak som en främmande nyckel. I detta fall är inte kundnr sekundär nyckel i tblOrder.
En sekundär nyckel är samma sak som en alternativ nyckel, vilket innebär att den kan användas som primärnyckel.
Av de fält som syns i din modell finns troligtvis inga sekundära nycklar. Ett exempel: Säg att du har en tabell med användare kallad Users som ser ut enligt följande:
id (autoinc) | personnr (string) | namn (string)
Då är både id och personnr alternativa nycklar i Users. Men det är bara en av dem du väljer som primärnyckel; den andra blir då sekundär nyckel.
Hur skulle jag isåfall få till en sekundärnyckel i min tabellstruktur?
Om jag skulle (Av nån anledning) sätta primärnyckel på både kundnr i tblkund och kundnr i tblOrder. (En till en). Skulle kundnr tblOrder fortfarande vara en främmande nyckel?
Okej, jag förstår vad de säger i länken du postade, men just begreppen primära/sekundära tabeller vet jag inte varifrån de fått. Men det är väl en bisak i sammanhanget.
Sekundärnycklar är ingenting man skapar för skapandes skull; snarare är det så att de uppstår naturligt (se mitt exempel med id och personnr ovan). Med andra ord bör du inte lägga någon större vikt vid det.
Det finns ingen som helst anledning att sätta kundnr som primärnyckel i tblOrder, eftersom ett kundnr inte unikt identifierar en order (en kund kan ju ha flera ordrar). Mer sannolikt bör primärnyckeln i tblOrder vara ett ordernummer.
Ett fält F kan vara både primärnyckel och främmande nyckel. Vanligt är då att F är en del av en sammansatt nyckel i den tabell där den är primärnyckel.
Så länge kundnr är primärnyckel i tblKund så kommer alla förekomster av kundnr i de andra tabellerna att vara främmande nycklar till tblKund.kundnr (såvida de definieras till att vara främmande nycklar).
Just därföt lät man ofta dessa fält ligga efter varandra i vissa Db verktyg
Exempelvis KundNr 6 Tkn samt OrderNr 6 tkn Då kunde man kontatinera (slå ihop) KundOrderNR 12 tkn vid vissa typer av transaktioner.
Sånt behövs ju inte idag med dagens datakraft.
141 ms totalt · 3 externa anrop · v20260731065814-full.55e59744
