Hvad er et relationelt skema? Hvordan skaber man en effektiv database?
Der findes ikke en enkelt databasestruktur, der altid er mere effektiv end nogen anden. Det skyldes, at typen og mængden af lagrede data ændrer databasens optimale struktur.
Der er imidlertid en stor forskel mellem at opbygge en database, der er optimeret til ydeevne, og en, der er optimeret til datamængde.
Ved hjælp af relationelle skemaer i MySQL kan du oprette en database, der er optimeret til datamængde. Dette er ideelt i situationer, hvor omkostningerne til lagring, behandling og hukommelse er uoverkommeligt dyre.
Mens dette ikke længere er tilfældet for standardelektronik, er der stadig masser af situationer, hvor programmører og udviklere vil ønske at bruge relationelt skema. Selv om lagring, processorkraft og hukommelse er billige for brugere af konventionelle computere, er disse ting massivt dyre i kvantecomputerverdenen.
Også er et relationelt skema vigtigt i MySQL-databaser, der er afhængige af relationer for at generere mening. Medarbejder- og akademiske optegnelser kan f.eks. let tænkes som netværk af relationer, der bedre kan beskrives ved hjælp af et relationelt skema end f.eks. nøgle-værdi- eller grafdatabaser.
Det relationelle skema er det primære element i den relationelle database. Disse databaser forvaltes ved hjælp af et sprog og en struktur, der er i overensstemmelse med førsteordslogik. Dette giver mulighed for databasestyring baseret på entitetsrelationer, hvilket gør dem nemme at organisere efter volumen.
Det relationelle skema henviser til de metadata, der beskriver strukturen af data inden for et bestemt domæne. Det er en databases blueprint, der skitserer den måde, hvorpå dens struktur organiserer data i tabeller.
For eksempel, hvis din database indeholder medarbejderposter for en stor virksomhed, kan du have entitetsrelationer, der beskriver hver enkelt medarbejder som en stærk enhed på følgende måde:
- Medarbejderens navn
- ID-nummer
- Adresse
- Medarbejderens færdigheder
- Anbudsdato
- Tjenesteår
I dette eksempel ville du have to attributter for relationelle skemadata. For det første ville du have attributten Employee, som er tabellens primærnøgle (da alt er relateret til medarbejderen) og en Address-attribut, som er en sammensat attribut, der består af forskellige elementer.
Attributten Adresse ville bestå af følgende værdier:
- By
- Street
- Addresse nummer
- Zip kode
Med denne viden er du klar til at mappe et entitetsrelationsdiagram til relationelt skema. Det skulle gerne se sådan ud:
- Medarbejder (Navn, ID-nummer, Adressenummer, Gade, By, Postnummer, Ansættelsesdato)
- Medarbejderens færdighedssæt (ID-nummer, Færdighedssæt)
Du bør bemærke, at antal tjenesteår er udelukket fra denne liste. Det skyldes, at det er en afledt attribut, der kan beregnes ved at trække ansættelsesdatoen fra den aktuelle dato. Grunden til, at Employee Skillset har sit eget skema, er, at det er en attribut med flere værdier.
For relationelle skemaer bliver hver enhedstype sin egen tabel, og hver enkeltværdiattribut er en kolonne i denne tabel. Afledte attributter kan roligt ignoreres, mens attributter med flere værdier bliver til separate tabeller.
Metoden til at konvertere svage enhedstyper til relationsskemaet svarer til den ovenfor beskrevne proces, bortset fra at svage enhedstyper bliver til deres egne tabeller, og at den stærke enheds primære nøgle fungerer som en fremmed nøgle i tabellen.
Det betyder, at du for den stærke enhed Medarbejder ville oprette en sammensat primær nøgle bestående af den fremmede nøgle Afhængig og nøglen for selve den svage enhed. Det ville få skemaet til at se således ud:
- Medarbejder (Navn, ID-nummer, Adressenummer, Gade, By, Postnummer, Ansættelsesdato)
- Afhængig (Medarbejder, Afhængigt ID, Navn, Adresse)
Korrelationen her er mellem ID-nummeret i tabellen Medarbejder og elementet Medarbejder i tabellen Afhængig.
Med dette arbejde gjort, er du klar til at begynde at konvertere relationer. Det kræver, at du forstår kardinaliteten og graden af hver relation.
- Der er tre mulige kardinaliteter – 1:1, 1:M, 1:N
- Der er tre mulige grader – unær, binær og ternær.
Tager vi ovenstående eksempel videre, kan Medarbejder kombineres med en ny afdelingstabel for at danne en binær 1:1-relation. Hvis medarbejderen leder en bestemt afdeling, kan han eller hun beskrives som en delvis deltager, mens afdelingen vil blive beskrevet som en samlet deltager.
Det relationelle skema ville se således ud:
- Medarbejder (Navn, ID-nummer, Adressenummer, Gade, By, Postnummer, Ansættelsesdato)
- Afdeling (Leder-ID-nummer, Afdelings-ID, Navn, Adresse)
I dette tilfælde bliver den delvise deltagers primærnøgle til den samlede deltagers fremmednøgle. Lederens ID-nummer korrelerer med den pågældende medarbejders ID-nummer.
Dette viser en vigtig del af oprettelsen af det relationelle skema. Den primære nøgle for en af deltagerne i en binær 1:1-relation kan blive en fremmed nøgle i den anden. En anden måde at beskrive ovenstående relation på ville være at bruge Manages som fremmednøgle under Employee, der korrelerer med primærnøglen Department ID under Department.
Et eksempel på en binær 1:N-relation ville være den mellem en Lærer, der underviser et fag. I et bestemt klasseværelse kan lærere undervise mere end ét fag til en række forskellige elever, men alle fag deler alligevel den samme relation med læreren.
I den binære 1:1-relation ovenfor havde hver afdeling en unik leder. Med denne binære 1:N-relation kan et variabelt antal elever dele den samme lærer. Den primære nøgle for Lærer ville være Lærer-ID, som ville korrelere med den fremmede nøgle for Fag under Lærer.
For at beskrive et binært M:N-forhold skal du forestille dig en studerende, der tilmelder sig et kursus. Opret en ny tabel, der beskriver Elev, og en anden, der beskriver Kursus. Begge disse tabeller er relateret gennem tilmeldingen, og begge tabeller har fremmednøgler.
- Den fremmednøgle for Student er Student ID.
- Den fremmednøgle for Kursus er Kursus ID.
Den nye tabels primærnøgle er kombinationen af hver af de enkelte enheders fremmednøgler. Du ville beskrive det som (Student ID, Course ID). Dette er et unikt binært M:N-relationsskema, der knytter individuelle studerende til kurser.
Dette fungerer, fordi ID’er i sagens natur er oprettet med henblik på at være fremmednøgler i relationelle databaser.
Du kan bruge et relationsskema til at beskrive selvrefererende relationer. To medarbejdere, der er gift med hinanden, kan f.eks. have den fremmede nøgle Ægtefælle. For begge disse medarbejderes fremmednøgler vil referencen være til den anden medarbejders Employee ID, som er primærnøglen i hver medarbejders respektive tabel.
Dette fungerer også i relationsskemaer med en kardinalitet på 1:N. Selve primærnøglefeltet ville i dette tilfælde blive den fremmede nøgle for den samme tabel. Dette er det samme som et unært 1:1 skema.
For eksempel kan en medarbejder, der er leder for en underordnet, have manager som sin fremmednøgle. I dette tilfælde ville medarbejder-id’et være primærnøglen i samme tabel.
Selvhenvisning til et M:N-forhold kræver to tabeller. Det ene skal repræsentere den pågældende enhed, og det andet skal repræsentere M:N-forholdet.
Forestil dig en medarbejder, som er ansvarlig for at garantere kvaliteten af et bestemt produkt eller en bestemt tjenesteydelse. Denne relation ville skulle indeholde både Garant og Modtager som fremmednøgler, der kombineres for at korrelere med medarbejder-id’et i tabellen Medarbejder. Både Garant og Begunstiget ville fungere som primær- og fremmednøgler i den nyligt oprettede tabel i relationsskemaet.
Mens binære og unære relationer er enkle at beskrive ved hjælp af et relationsskema med et eller to tabeller. Ternære tabeller kræver en tredje, ny tabel.
Den primære nøgle i denne nye tabel består af hver deltagende enheds fremmednøgle, lagt sammen. Det betyder, at den nye tabel skal indeholde tre fremmednøgler, som den skal korrelere med.
For eksempel består forholdet mellem en læge og hendes patient faktisk af tre entiteter: Lægen, patienten og medicinen. For at beskrive dette forhold korrekt som et relationsskema skal du tildele fremmednøgler til hver af disse entiteter og korrelere dem til en ny tabel med titlen Recept.
Dette er en simpel måde at visualisere den måde, som en ternær tabel fungerer på. Primærnøglen for den nyoprettede tabel Prescription er (Læge-ID, Patient-ID, Lægemiddel-ID). Ethvert skema, der ikke indeholder disse tre vigtige data, mangler en vigtig del af puslespillet.
Denne fremgangsmåde ville gøre det muligt for en databaseadministrator at oprette et organiseret arkiv af recepter, der redegør for specifikke lægemiddeltyper, der umiddelbart er korreleret med navnene på de patienter, der bruger dem, og tilbyder navnene på de læger, der har ordineret dem.
For fuldstændighedens skyld kan du tilføje udløbsdatoen til tabellen Medicin, så disse data er tilgængelige i hovedmatrixen. Du kan tilføje Næste aftale eller Genopfyldningsdato til tabellen Recept. Du vil logisk set ønske at tilføje fødselsdato, adresse og andre vigtige relationelle data til tabellen Patient.
Alle disse værktøjer kombineres for at gøre det muligt at oprette relationsorienterede databaser i MySQL. Du kan øve dig i at lave dine egne MySQL-databaser online med en hvilken som helst browser ved hjælp af SQLDBM.