Hjälp kring Datamodellering och konceptuella databaser

Disclaimer: Jag är inte Databasadministratör, utan har läst en kurs i Databaser i ett distansprogram inom Webbutveckling. Jag antar också att vi pratar om relationsdatabaser här såsom MySQL/MariaDB? Det är vad jag ger input om.

1. För att minimera risken för "motsägelser" i din databas (t.ex. upprepade värden, null-värden, otillåtna raderingar, etc.) så vill du att varje Tabell (Entitet) bara ska beskriva en sak och att varje kolumn i en given Entitet (Tabell) ska innehålla atomiska värden (t.ex. två kolumner/attribut med "Förnamn" + "Efternamn" och inte en kolumn/ett attribut, "Fullständigt namn"). Du vill växa på höjden (fler nya rader i en Tabell eller fler nya Tabeller) och inte på bredden (fler kolumner i samma tabell/entitet).

Ett simpelt exempel är telefonnummer för personer. Klassiska felet är att ha kolumnen/attributet "Telefonnummer" i Tabellen "Person" och sedan flera telefonnummer för varje person i form av flera värden (ej atomiska) i samma fält då: "07612345679,07012345679" eller kanske ännu värre: du kör en till kolumn/ett till attribut: "Telefonnummer 2" efter "Telefonnummer 1". Massor av null-värden blir det då för varje ny Person då. "Det går men det är fel!" som min gamla databaslärare skulle ha sagt!

"Mer korrekt" (minimera motsägelser) vore att du har Tabellerna/Entiteterna "Person" och "Telefonnummer" där varje rad i Telefonnumret ska peka på en rad (alltså agera som FK) i Tabellen "Person". Då kan du lägga till flera telefonnummer för varje person och du kan då se hur du växer på höjden (främst i tabellen "Telefonnummer") istället för bredden. En annan sak du löser också då är att när du tar bort ett Telefonnummer så försvinner inte alla telefonnummer för den personen samtidigt som du kan välja när du designar om du vill ha det som så att alla telefonnummer för en person ska försvinna om personen ur tabellen "Person" försvinner.

2. Många-till-Många eller "N:M" tolkar jag som ett sätt att koppla samman två Tabeller/Entiteter när det i sammanhanget behövs. Exempelvis kanske du har som så att Flera personer ska kunna Äga en och samma bil. Då har du en Tabell med "Bilägare" (och dessa ska _inte_ beskriva vilka bilar de har utan bara att de är bilägare!) och så har du en Tabell med "Bilar" (och dessa ska _inte_ beskriva vilka ägare de har utan bara vilka slags bilar de är). Vill du ta det ett steg till här så kan du under "Bilar" peka på en rad i en Tabell vid namn "Biltyp" som i sin tur innehåller egenskaper för olika biltyper. Men börja simpelt först.

Till sist så har du då en N:M-tabell mellan "Bilägare" och "Bilar" som i sin tur då kopplar samman "Bilägare 1 Äger Bil 1", och "Bilägare 2 Äger Oxå Bil 1" och "Bilägare 1 Äger Bil 2" och så vidare. N:M-tabellen kopplar alltså samman FK (två rader från två olika andra tabeller) och dessa två FK blir en sammansatt primärnyckel (eng. "Composite Primary Key" Composite PK"). Varför blir den sammansatt PK? Jo, för med PK så skapar du unikhet i en rad för du vill inte upprepa data i onödan. I din N:M-Tabell så vill du inte råka skriva att "Bilägare 1 Äger Bil 2" två gånger utan det ska bara gå en gång.

3. PK är ju till för att peka på en unik rad i en tabell och då vill du även tänka vad som är unikt beroende på övriga tabeller. Om vi tänker tabellen "Bilägare". Kan det vara samma "Bilägare" två gånger i den tabellen "Bilägare"? Nej, det vore som om det fanns två av samma person vilket ej är realistiskt i sammanhanget. Däremot kan som sagt var samma "Bilägare" förekomma två eller fler gånger i N:M-tabellen eftersom den beskriver "Vilka Bilägare Som Äger Vilka Bilar" och samma Bilägare kan äga fler än en bil kom vi fram till i exemplet ovan (om det nu är tänkt så för användningsområdet - tänk en tabell som beskriver vilken enstaka uthyrd bil som är aktivt uthyrd till en person, då kan bilen inte vara aktivt uthyrd till flera personer samtidigt, handlar om användningsområde eller "Verksamhetsbeskrivning").

4. Med handen på hjärtat så tycker jag att kurslitteraturen jag hade för Databaskursen jag läste var lite dåligt upplagd (alternativt jag som var för korkad för att förstå det). Även om den gick igenom grunderna i databastänket för relationsdatabaser och databaser rent allmänt talat så tycker jag att den hade varit bättre om den kunde visa SQL-kod och Tabeller samtidigt som den visade själva modelleringen med alla dessa figurer, pilar, kardinaliteter. Med andra ord kan du testa den när du vill och då kanske du upptäcker snabbare varför det rekommenderas att göras som det rekommenderas med modelleringen när du väl får se i skarpt implementeringsläge av modellen (inskriven & exekverad SQL-kod). Men det är min personliga åsikt och inget mer. För mig "kopplade" det mer när jag väl började prova att mata in "CREATE TABLE TabellNamn"-koderna och sedan lite testdata "INSERT INTO TabellNamn".

Vad du troligen kommer att få huvudvärk över är "normalformer" och "normalisering" vilket helt enkelt handlar om att eliminera "motsägelser" i databaser så att du inte stoppar in data i onödan, inte kan radera data för att för mycket hänger ihop, eller att data inte uppdateras på korrekt sätt för få FKs används. Samtidigt så har jag varit inne nyligen och kikat i WordPress-databaer och MyBB-databaser och där finns det tonvis med kolumner här och var i diverse tabeller vilket inte tycks följa databastänket riktigt fullt ut. Bland olika MyBB-versioner tillkom även olika kolumner i vissa tabeller (växa på bredden - ajjabajja!) vilket orsakade lite kaos här och var i SQL-frågor om de inte också uppdaterades i samma veva.

Förhoppningsvis gav detta något eller så svamlade jag bara!

Mvh,
WKL.

Jag kompletterar det Webbkodslärlingen säger ovan, som jag tycker är bra, med följande.

I praktiken ska man aldrig någonsin ha något annat än tekniska nycklar som primary key i sina tabeller. Undantaget är just tabeller som hanterar M:N-relationer, vars PK är sammansatt av två foreign keys, vilka i sin tur då är tekniska nycklar i respektive tabell de pekar på.

En teknisk nyckel är automatgenererad på något sätt och helst slumpmässig (alltså inte ett löpnummer utan till exempel en GUID/UUID) eftersom någon klantig webbutvecklare förr eller senare kommer fucka säkerheten och låta vem som helst hämta vad som helst man vet Id:t på.

Det klassiska misstaget är till exempel att välja personnummer som primary key i sin persontabell eller registreringsnummer som PK i sin biltabell. Det blir inte jättekul när det ändras och det finns foreign keys i andra tabeller som har det värdet. I stället ser man till att ha constraints som gör att personnummer respektive registreringsnummer unika i respektive tabell och att dessa tabeller har PKs som aldrig behöver ändras eftersom de inte betyder något.

WKL har rätt i att man gör databasen först och sedan genererar man ut entitetsdiagrammet eller vad nu läraren eller enterprise-arkitekten vill ha, med lämpligt verktyg. I praktiken skriver man förstås klasserna i koden först och genererar databasen med något ORM-verktyg.

Faller kanske utanför dina frågor men jag rekommenderar boken Databasteknik av Thomas Padron-McCarthy och Tore Risch. Den är lättläst och ger en bra överblick på grunderna med övningar. Författaren har även en sammanfattning online som jag tror boken delvis är baserad på men jag hade rekommenderat att du beställer den fullständiga boken genom ditt lokala bibliotek.

https://www.databasteknik.se/webbkursen/index.html