Dette spørgsmål viser, at du ikke fuldt ud forstår entitetsforhold (ingen uhøflighed tilsigtet). Hvoraf der er fire (teknisk kun 3) typer nedenfor:
One to One One to Many Many to One Many to Many
En til en (1:1): I dette tilfælde er en tabel blevet delt op i to dele med det formål at overholde normaliseringen, eller mere normalt det åbne lukkede princip.
Normalisering overholdelse:Du har muligvis en forretningsregel om, at hver kunde kun har én konto. Teknisk set kunne du i dette tilfælde sige, at kunde og konto alle kunne være i samme tabel, men dette bryder normaliseringsreglerne, så du deler dem op og laver en 1:1.
Åben-luk-princippet overholdelse:En kundetabel, kan have id, for- og efternavne og adresse. Senere beslutter nogen at tilføje en fødselsdato og med den muligheden for at beregne alder sammen med en masse andre meget nødvendige felter. Dette er et alt for forenklet eksempel på en til en, men du får hovedanvendelsen for det er at udvide din database uden at bryde eksisterende kode. Meget kode skrevet (desværre) er tæt koblet til databasen, så ændringer i strukturen af en tabel vil bryde koden. Tilføjelse af en 1:1 som denne vil udvide tabellen til at opfylde nye krav uden at ændre den oprindelige, og derved tillade gammel kode at fortsætte med at fungere normalt og ny kode for at gøre brug af de nye db funktioner.
Ulempen ved normalisering og udvidelse af tabeller ved at bruge 1:1 relationer på denne måde er ydeevne. Ofte på meget brugte systemer er det første mål for at øge databasens ydeevne at denormalisere og kombinere sådanne tabeller til en enkelt tabel og optimere indekserne og dermed fjerne behovet for at bruge joins og læse fra flere tabeller. Normalisering / De-Normalisering er hverken en god eller dårlig ting, da det afhænger af systemets behov. De fleste systemer starter normalt normaliseret med at skifte tilbage, når det er nødvendigt, men denne ændring skal gøres meget omhyggeligt som nævnt, hvis kode er tæt koblet til DB-strukturen, vil det næsten helt sikkert få systemet til at fejle. dvs. Når du kombinerer 2 tabeller, ophører den ene med at eksistere, al koden, der inkluderer den nu ikke-eksisterende tabel, fejler, indtil den er ændret (i db-termer, forestil dig at forbinde relationer til en af tabellerne i 1:1, når du fjerner disse tabeller , dette bryder relationerne, og derfor skal strukturen ændres meget for at kompensere. Desværre er sådanne dårlige designs meget nemmere at få øje på i DB-verdenen end i softwareverdenen i de fleste tilfælde, og du plejer ikke at bemærke, at noget gik galt i kode, indtil det hele falder fra hinanden), medmindre systemet er korrekt designet med adskillelse af bekymringer i tankerne.
Det er det tætteste du kan komme på arv i objektorienteret programmering. Men det er ikke helt det samme.
En til mange (1:M) / Mange til en (M:1): Disse to forhold (derfor bliver 4 til 3) er de mest populære forholdstyper. De er begge den samme type forhold, det eneste, der ændrer sig, er dit synspunkt. Et eksempel En kunde har mange telefonnumre, eller alternativt kan mange telefonnumre tilhøre en kunde.
I objektorienteret programmering vil dette blive betragtet som komposition. Det er ikke arv, men du siger, at en genstand er sammensat af mange dele. Dette er normalt repræsenteret med arrays / lister / samlinger osv. inde i klasser i modsætning til en arvestruktur.
Mange til Mange (M:M): Denne type forhold til den nuværende teknologi er umulig. Af denne grund er vi nødt til at opdele det i to en til mange relationer med en "associations"-tabel, der slutter sig til dem. Den mange side af de to en til mange relationer er altid på associerings-/linktabellen.
For dit eksempel er den person, der sagde, at du har brug for mange til mange, korrekt. Fordi et to til mange reelt er et mange (det betyder mere end et) til mange forhold. Dette er den eneste måde, du kan få dit system til at fungere på. Medmindre du har til hensigt at undersøge feltet relationel beregning at finde en ny type forhold, der ville tillade dette.
Også for sådanne relationer (m2m) har du to valgmuligheder, enten opret en sammensat nøgle i linkertabellen, så kombinationen af felter bliver en unik post (hvis du er interesseret i db-optimering er dette det langsommere valg, men tager mindre plads). Alternativt opretter du et tredje felt med en automatisk genereret id-kolonne og gør den til den primære nøgle (til db-optimering er dette det hurtigere valg, men det tager mere plads).
I dit eksempel specifikt ovenfor...
Dette ville være et mange-til-mange-forhold med telefonnummertabellen som linker-tabellen mellem virksomheder og brugere. Som forklaret, for at sikre, at intet telefonnummer gentages, skal du blot indstille det som primærnøgle eller bruge en anden primærnøgle og indstille telefonnummerfeltet til unikt.
For den slags spørgsmål er det virkelig ned til, hvordan du formulerer dem. Hvad der får dig til at blive forvirret over dette, og hvordan du overvinder denne forvirring for at se løsningen er enkel. Omformuler problemet som følger. Start med at spørge om det er en til en, hvis svaret er nej, så gå videre. Næste spørg er det en til mange, hvis svaret ikke er gå videre. Den eneste anden mulighed, der er tilbage, er mange til mange. Vær dog forsigtig, sørg for at du har overvejet de første 2 spørgsmål omhyggeligt, før du går videre. Mange uerfarne databasefolk komplicerer ofte problemer ved at definere en til mange som mange til mange. Endnu en gang er den mest populære type forhold langt fra én til mange (jeg vil sige 90 %) med mange til mange og én til én, der deler de resterende 10 % 7/3 hhv. Men disse tal er bare mit personlige perspektiv, så du skal ikke citere dem som industristandardstatistikker. Min pointe er at gøre ekstra ekstra sikker på, at det bestemt ikke er en til mange, før jeg vælger mange til mange. Det er den ekstra indsats værd.
Så nu for at finde linkertabellen mellem de to, beslutte hvilke to der er dine hovedtabeller, og hvilke felter der skal deles mellem dem. I dette tilfælde skal både firma- og brugertabeller dele telefonen. Derfor skal du lave en ny telefontabel som linker.
Advarselsalarmen om misforståelse bør vises, så snart du beslutter, at ingen af de 3 virker for dig. Dette burde være nok til at fortælle dig, at du simpelthen ikke formulerer forholdsspørgsmålet korrekt. Du vil blive bedre til det, som tiden går, men det er en essentiel færdighed og bør virkelig mestres så hurtigt som muligt for din egen fornuft.
Selvfølgelig kan du også gå til en objektorienteret database, som vil tillade en række andre relationer kaldet "hierarkiske" relationer. Det er fantastisk, hvis du også overvejer at blive programmør. Men jeg vil ikke anbefale dette, da det vil gøre dit hoved ondt, når du begynder at finde måder at kombinere de forskellige typer forhold. Især i betragtning af at der ikke er meget behov for, da næsten alle databaser i verden kun består af de 3 typer relationer, medmindre de er noget super duper specielt.
Håber dette var et fornuftigt svar. Tak, fordi du tog dig tid til at læse den.