Vad är ett relationsschema? Hur skapar man en effektiv databas?

Det finns ingen databasstruktur som alltid är effektivare än någon annan. Detta beror på att typen och mängden data som lagras ändrar databasens optimala struktur.

Det finns dock en stor skillnad mellan att bygga en databas som är optimerad för prestanda och en som är optimerad för datavolym.

Med hjälp av relationsschema i MySQL kan du skapa en databas som är optimerad för datavolym. Detta är idealiskt i situationer där kostnaden för lagring, bearbetning och minne är oöverkomligt dyr.

Men även om detta inte längre är fallet för standardelektronik finns det fortfarande många situationer där programmerare och utvecklare vill använda relationsschema. Även om lagring, processorkraft och minne är billiga för användare av konventionella datorer är dessa saker massivt dyra i kvantdatorernas värld.

Också ett relationellt schema är viktigt i MySQL-databaser som förlitar sig på relationer för att generera mening. Anställda och akademiska register, till exempel, kan lätt betraktas som nätverk av relationer som beskrivs bättre med hjälp av ett relationsschema än till exempel nyckelvärdes- eller grafdatabaser.

Relationsschemat är det primära elementet i en relationsdatabas. Dessa databaser hanteras med hjälp av ett språk och en struktur som överensstämmer med första ordningens logik. Detta gör det möjligt att hantera databaser baserat på entitetsrelationer, vilket gör dem lätta att organisera efter volym.

Relationellt schema hänvisar till metadata som beskriver datastrukturen inom en viss domän. Det är en databasens ritning som beskriver hur dess struktur organiserar data i tabeller.

Om din databas till exempel innehåller uppgifter om anställda för ett stort företag kan du ha entitetsrelationer som beskriver varje anställd som en stark enhet på följande sätt:

  • Anställdas namn
  • ID-nummer
  • Adress
  • Anställdas färdigheter
  • Anställdas anställningsdatum
  • Anställningsår

I det här exemplet skulle du ha två attribut för relationsschemadata. Först har du attributet Employee, som är tabellens primärnyckel (eftersom allt är relaterat till den anställde) och attributet Address, som är ett sammansatt attribut som består av olika element.

Adressattributet skulle bestå av följande värden:

  • City
  • Street
  • Address number
  • Zip code

Med detta i åtanke är du redo att mappa ett entitetsrelationsdiagram till ett relationsschema. Det skulle vilja se ut så här:

  • Anställd (namn, ID-nummer, adressnummer, gata, stad, postnummer, anställningsdatum)
  • Anställd kompetens (ID-nummer, kompetens)

Du bör lägga märke till att antal tjänsteår inte ingår i den här listan. Det beror på att det är ett härlett attribut som kan beräknas genom att subtrahera anställningsdatumet från det aktuella datumet. Anledningen till att Employee Skillset har ett eget schema är att det är ett attribut med flera värden.

För relationsscheman blir varje enhetstyp en egen tabell och varje attribut med ett värde är en kolumn i den tabellen. Avledda attribut kan säkert ignoreras, medan flervärdesattribut blir separata tabeller.

Metoden för att konvertera svaga entitetstyper till relationsschemat liknar den process som beskrivs ovan, förutom att de svaga entitetstyperna blir egna tabeller och att den starka entitetens primärnyckel agerar som en utländsk nyckel i tabellen.

Detta innebär att för den starka entiteten Anställd skulle du skapa en sammansatt primärnyckel som består av den utländsk nyckeln Beroende och nyckeln för den svaga entiteten i sig själv. Då skulle schemat se ut så här:

  • Employee (Name, ID Number, Address Number, Street, City, Zip Code, Hiring Date)
  • Dependent (Employee, Dependent ID, Name, Address)

Korrelationen här är mellan ID Number i tabellen Employee och Employee-elementet i tabellen Dependent.

Med det här arbetet gjort är du redo att börja konvertera relationer. För att göra det måste man förstå kardinaliteten och graden av varje relation.

  • Det finns tre möjliga kardinaliteter – 1:1, 1:M, 1:N
  • Det finns tre möjliga grader – unär, binär och ternär.

Om vi tar exemplet ovan vidare skulle Anställd kunna kombineras med en ny tabell Avdelning för att bilda en binär 1:1-relation. Om den anställde leder en viss avdelning kan han eller hon beskrivas som en partiell deltagare, medan avdelningen skulle beskrivas som en total deltagare.

Relationsschemat skulle se ut så här:

  • Anställd (namn, ID-nummer, adressnummer, gata, stad, postnummer, anställningsdatum)
  • Avdelning (chefens ID-nummer, avdelningens ID, namn, adress)

I det här fallet blir den partiella deltagarens primära nyckel den totala deltagarens utländska nyckel. Chefens ID-nummer korrelerar med den lämpliga anställdas ID-nummer.

Detta visar en viktig del av skapandet av relationsschemat. Primärnyckeln för endera deltagaren i en binär 1:1-relation kan bli en främmande nyckel i den andra. Ett annat sätt att beskriva relationen ovan skulle vara att använda Manages som främmande nyckel under Employee, som korrelerar med primärnyckeln Department ID under Department.

Ett exempel på en binär 1:N-relation skulle vara den mellan en lärare som undervisar ett ämne. I ett visst klassrum kan lärare undervisa mer än ett ämne till olika elever, men alla ämnen har samma relation till läraren.

I den binära 1:1-relationen ovan hade varje avdelning en unik chef. Med denna binära 1:N-relation kan ett variabelt antal elever dela samma lärare. Primärnyckeln för lärare skulle vara lärar-id, vilket skulle korrelera med den främmande nyckeln för ämne, under lärare.

För att beskriva en binär M:N-relation, föreställ dig en student som anmäler sig till en kurs. Skapa en ny tabell som beskriver Student och en annan som beskriver Kurs. Båda dessa tabeller är relaterade genom att de registrerar sig och båda har främmande nycklar.

  • Den främmande nyckeln för Student är Student-ID.
  • Den främmande nyckeln för Kurs är Kurs-ID.

Primärnyckeln i den nya tabellen är kombinationen av varje enhets främmande nycklar. Du kan beskriva den som (Student-ID, Kurs-ID). Detta är ett unikt binärt M:N-relationsschema som länkar enskilda studenter till kurser.

Detta fungerar eftersom ID:n till sin natur skapas för att vara främmande nycklar i relationsdatabaser.

Du kan använda ett relationsschema för att beskriva självrefererande relationer. Till exempel kan två anställda som är gifta med varandra ha den främmande nyckeln Spouse. För båda dessa anställdas utländska nycklar kommer referensen att vara till den andra anställdas Employee ID, som är primärnyckeln i varje anställds respektive tabell.

Detta fungerar även i relationsscheman med en kardinalitet på 1:N. Själva primärnyckelfältet skulle i det här fallet bli den främmande nyckeln för samma tabell. Detta är samma sak som ett unärt 1:1 schema.

En anställd som är chef för en underordnad kan till exempel ha chef som sin främmande nyckel. I det här fallet skulle anställdas ID vara primärnyckeln i samma tabell.

För att självreferera ett M:N-förhållande krävs två tabeller. Den ena måste representera enheten i fråga och den andra måste representera M:N-relationen.

Föreställ dig en anställd som är ansvarig för att garantera kvaliteten på en viss produkt eller tjänst. Det här förhållandet skulle behöva inkludera både Garant och Förmånstagare som främmande nycklar som kombineras för att korrelera med anställnings-ID i tabellen Anställd. Både Garant och Förmånstagare skulle fungera som primära och utländska nycklar i den nyskapade tabellen i relationsschemat.

Samtidigt som binära och unära relationer är enkla att beskriva med hjälp av relationsschemat med en eller två tabeller. Ternära tabeller kräver en tredje, ny tabell.

Primärnyckeln i denna nya tabell består av varje deltagande enhets utländska nyckel, adderad tillsammans. Detta innebär att den nya tabellen måste innehålla tre främmande nycklar att korrelera med.

Till exempel består relationen mellan en läkare och hennes patient egentligen av tre enheter: Läkaren, patienten och medicinen. För att beskriva detta förhållande korrekt som ett relationsschema måste du tilldela främmande nycklar till var och en av dessa enheter och korrelera dem till en ny tabell med titeln Prescription.

Detta är ett enkelt sätt att visualisera hur en ternär tabell fungerar. Primärnyckeln i den nyligen skapade tabellen Prescription är (Läkar-ID, Patient-ID, Läkemedels-ID). Varje schema som inte innehåller dessa tre viktiga uppgifter saknar en viktig del av pusslet.

Detta tillvägagångssätt skulle göra det möjligt för en databashanterare att skapa ett organiserat arkiv av recept som redovisar specifika läkemedelstyper, omedelbart korrelerade med namnen på de patienter som använder dem och erbjuder namnen på de läkare som skrivit ut dem.

För fullständighetens skull kan man lägga till utgångsdatumet i tabellen Medicin så att dessa uppgifter finns tillgängliga i huvudmatrisen. Du kan lägga till nästa möte eller datum för påfyllning i tabellen Recept. Du skulle logiskt sett vilja lägga till födelsedatum, adress och andra viktiga relationsdata till tabellen Patient.

Alla dessa verktyg kombineras för att göra det möjligt att skapa relationsorienterade databaser i MySQL. Du kan öva på att skapa egna MySQL-databaser online med vilken webbläsare som helst med SQLDBM.

Lämna ett svar

Din e-postadress kommer inte publiceras.