Hvad er et en-til-mange forhold i en database? En forklaring med eksempler

En-til-mange-relationer er en af ​​de mest almindelige databaserelationer. Hvis du vil lære, hvornår og hvordan du bruger en-til-mange-forhold, så er denne artikel et godt udgangspunkt.

Du vil helt sikkert bruge en-til-mange-relationer til at gemme information i enhver relationel database, uanset om du designer software på virksomhedsniveau eller blot opretter en simpel database for at holde styr på din onkels frimærkesamling.

En kort introduktion til den relationelle model

Relationelle databaser er en kernekomponent i enhver moderne transaktionsapplikation. Den relationelle model er sammensat af tabeller (data organiseret i rækker og kolonner), der har mindst én unik nøgle, der identificerer hver række. Hver tabel repræsenterer en enhed. Dette er vist i følgende eksempel, en meget simpel version af en tabel, der repræsenterer kundeordrer:

Ovenstående diagram, som jeg oprettede online ved hjælp af Vertabelo, har en enkelt tabel. Hver række i tabellen repræsenterer én ordre og hver kolonne (også kendt som en attribut ) repræsenterer hver enkelt information indeholdt i en ordre.

For dem, der endnu ikke er bekendt med Vertabelo-designværktøjet, artiklen Hvad er symbolerne brugt i ER-diagrammer? forklarer de anvendte symboler og konventioner. Du vil måske også lære mere om relationelle modeller og databaser ved at bruge vores databasemodelleringskursus.

Hvad er relationer, og hvorfor har vi brug for dem?

Hvis vi ser nærmere på tabellen brugt i det foregående eksempel, vil vi se, at den ikke rigtig repræsenterer en komplet rækkefølge. Den har ikke alle de oplysninger, du forventer, at den har. Du vil bemærke, at den ikke indeholder nogen data relateret til kunden, der har foretaget ordren, og den har heller ikke noget om de bestilte produkter eller tjenester.

Hvad skal vi gøre for at færdiggøre dette design for at gemme ordredata? Skal vi tilføje kunde- og produktoplysninger til ordren bord? Det ville kræve tilføjelse af nye kolonner (attributter) for kundenavne, skatte-id'er, adresser osv. som vist nedenfor:

Hvis vi gør det, vil vi snart løbe ind i problemer. De fleste kunder afgiver mere end én ordre, så dette system gemmer kundeoplysninger mange gange, én gang for hver ordre fra hver kunde. Det virker ikke som et smart træk.

Desuden, hvad sker der, når en kunde ændrer sit telefonnummer? Hvis nogen har brug for at ringe til kunden, kan de finde det gamle nummer på tidligere ordrer – medmindre nogen opdaterer hundredvis (eller endda tusindvis) af eksisterende ordrer med de nye oplysninger. Og det samme ville gælde for enhver anden ændring.

En relationel model kræver, at vi definerer hver enhed som en separat tabel og etablerer relationer mellem dem. At gemme alle oplysningerne i en enkelt tabel virker bare ikke.

Der er flere typer relationer mellem tabeller, men nok den mest almindelige er en-til-mange relationen, som ofte skrives som 1:N. Denne form for relation betyder, at en række i en tabel (normalt kaldet den overordnede tabel) kan have en relation med mange rækker i en anden tabel (normalt kaldet undertabel). Nogle almindelige eksempler på en-til-mange-forhold er:

• En bilproducent laver mange forskellige modeller, men en bestemt bilmodel er kun bygget af en enkelt bilproducent.
• En kunde kan foretage flere køb, men hvert køb foretages af en enkelt kunde.
• Én virksomhed kan have mange telefonnumre, men et telefonnummer tilhører én virksomhed.

Der er også andre typer relationer mellem tabeller; Hvis du vil vide mere om dem, kan du se denne artikel om mange-til-mange-forhold.

Går vi tilbage til vores første ordreeksempel, Kunden tabellen ville være den overordnede tabel og Orden bord barnet; en kunde kan have mange ordrer, mens en ordre kan tilhøre en enkelt kunde.

Bemærk venligst, at en-til-mange-definitionen tillader, at en række i den overordnede tabel kan knyttes til mange rækker på hver underordnet tabel, men det kræver det ikke. Faktisk tillader designet en kunde at have nul ordrer (dvs. en ny kunde, der endnu ikke har foretaget sit første køb), én ordre (en relativt ny kunde, der har foretaget et enkelt køb) eller mange ordrer (en hyppig kunde).

Vis en-til-mange-relationer i et ER-diagram

Lad os tage et kig på et mere komplet eksempel på et simpelt kundebestillingssystem, der bruger et ER-diagram (eller entitetsforhold). (Hvis du vil lære mere om disse diagrammer, er Vertabelo Features:Logical Diagrams et godt udgangspunkt.) Her er modellen:

Dette er et mere realistisk design. Du vil bemærke, at der er nye entiteter (tabeller) i diagrammet, som nu indeholder tabellerne Kunde , Bestil , Ordredetaljer og Produkt . Det vigtigste, du dog bemærker, er, at der nu er relationer mellem bordene .

I en databasemodel er relationer repræsenteret af linjer, der forbinder to enheder. Karakteristikaene for disse relationer er repræsenteret af forskellige forbindelser:

• Når der er en enkelt lodret linje, har den enhed, der er nærmest den forbindelse, kun én række påvirket af relationen. Det er 'en' i en-til-mange.
• Når der er en multi-line connector, der ligner en kragefod, har den nærmeste enhed flere rækker påvirket af relationen; det er de 'mange'.

Når man ser på billedet og kender notationen, er det nemt at forstå, at diagrammet definerer, at hver Ordre kan have mange Ordredetaljer og at hver Ordredetalje tilhører en enkelt Ordre .

Implementering af et en-til-mange-forhold mellem tabeller

For at definere en en-til-mange-relation mellem to tabeller, skal den underordnede tabel referere til en række i den overordnede tabel. De nødvendige trin for at definere det er:

1. Tilføj en kolonne til den underordnede tabel, der gemmer værdien af ​​den primære identifikator. (Faktisk tillader de fleste databasemotorer, at det er en hvilken som helst unik nøgle fra den overordnede tabel, ikke kun den primære nøgle.) Kolonnen kan defineres som obligatorisk afhængigt af dine forretningsbehov; alligevel laves der normalt udenlandske nøglekolonner

Bemærk: Det er en god praksis at beholde navnet på de refererende kolonner det samme som i den refererede (overordnede) tabel. Dette gør det endnu nemmere at forstå forholdet.

2. Tilføj en fremmednøgle begrænsning på børnebordet. Dette indikerer, at hver værdi, der er gemt i denne nye kolonne, refererer til en række i den overordnede tabel.

Udenlandske nøglebegrænsninger er en funktion, der er tilgængelig i relationsdatabasen, som håndhæver det:

1. Når du tilføjer en række til den underordnede tabel, skal værdien af ​​referencekolonnen matche én (og kun én) værdi i den overordnede tabel. (Derfor skal der refereres til en kolonne eller et sæt kolonner, der udgør en primær nøgle eller unik nøgle).
2. Hvis nogen forsøger at slette en række fra den overordnede tabel eller forsøger at ændre værdierne af den unikke/primære nøgle, der bruges som reference og der er en undertabel, der refererer til den række, vil handlingen mislykkes.

Disse to funktioner sikrer, at databasen bevarer sin integritet. Der er ingen chance for at oprette ordrer, der refererer til en ikke-eksisterende kunde, eller for at slette en kunde, der allerede har ordrer.

Oprettelse af en fremmednøgle

Fremmednøglesyntaks afhænger normalt af måldatabasemotoren. Når du har defineret din logiske model, kan du bruge funktionen "Generer fysisk model..." på Vertabelo logiske diagrammer til at transformere din (databaseagnostiske) model til en fysisk model, der matcher din databaseudbyder. Vertabelo vil også generere det nødvendige SQL-script, der giver dig mulighed for at oprette tabellerne og relationerne i din måldatabase.

Nogle praktiske eksempler på 1:N-relationer

Lad os nu gennemgå nogle eksempler på en-til-mange-forhold i den virkelige verden.

En-til-mange-forhold ved hjælp af primære nøgler

Dette er sandsynligvis det mest almindelige scenario, når man definerer et en-til-mange forhold. Den underordnede tabel bruger den primære nøgleværdi for den overordnede tabel til at etablere relationen.

Dette eksempel beskriver en grundlæggende online streamingtjeneste. Lad os gennemgå, hvad der er gemt i hver af tabellerne, og hvordan de relaterer til de andre tabeller i vores model:

1. Hver ServiceType definerer, hvordan en konto 'opfører sig' (f.eks. hvor mange brugere der kan oprette forbindelse til systemet på samme tid, hvis kontoen har Full HD aktiveret osv.). Det har én relation til andre enheder:
   • Et en-til-mange-forhold med Konto , hvilket betyder, at hver tjenestetype kan have mange konti af den type.
2. Hver konto gemmer oplysninger om én kunde. Den har to direkte relationer til andre enheder:
   • Hver konto tilhører en enkelt ServiceType , som forklaret ovenfor.
   • Denne tabel har et en-til-mange forhold til Profilen tabel, hvilket betyder, at mere end én bruger kan oprette forbindelse til vores system ved hjælp af den samme konto.
3. Hver profil repræsenterer en bruger i vores system. Den har to relationer til andre entiteter:
   • Hver profil tilhører en enkelt konto . Dette giver alle familiemedlemmer (eller måske en gruppe venner) mulighed for at dele den samme konto, mens hver enkelt har deres egne personlige egenskaber (f.eks. et profilnavn).
   • Hver profil har en unik Avatar .
4. Hver Avatar er et billede, der giver os mulighed for hurtigt at identificere hver enkelt kontobruger. Det har én relation til en anden enhed:
   • Et en-til-mange-forhold med Profil , hvilket betyder, at en enkelt avatar kan tildeles profiler på forskellige konti.