Hittills

• En rad är ett objekt
• En tabell är en array av objekt
  • ... men hur får vi mer än det?
• Svar: förhållanden mellan tabeller

Nycklar (keys)

• Värde som unikt identifierar en rad i en tabell
  • Oftast en enda kolumn: personnummer, serienummer, ...
  • Kan bestå av flera kolumner: gatunamn + gatunummer, ...
  • Ofta en "artificiell" kolumn med heltal: 1, 2, 3, 4, ...
• Nycklar definieras på en kolumn
  • Alla värden i kolumnen måste vara unika
• En tabell kan ha flera nycklar
  • I de flesta fall fokuserar vi på en enda: ett automatiskt ökande heltal ("identity specification")

Vad vi vill åstadkomma

• Ett album har diverse egenskaper av inbyggda datatyper
  • Exempelvis: namn som nvarchar och lanseringsdatum som date
• Ett album har också ett godtyckligt antal låtar
  • "One-to-many"
• Varje låt har i sin tur diverse egenskaper av inbyggda datatyper
  • Exempelvis: namn som nvarchar och längd som smallint

Vad vi skulle göra i C#

1. class Album {
2. public string Name;
3. public DateTime Date;
4. public Song[] Songs;
5. }
7. class Song {
8. public string Name;
9. public int Length;
10. }

Vad vi kan försöka i SQL

Problem

• Vi har ett fördefinierat högsta antal låtar
• Vi kan behöva ändra databasstrukturen bara för att lägga till nya rader
• Vi får svårt att skriva kommandon (i synnerhet i nästa kurs)

Lösning

• Två tabeller!
  • En tabell med album
  • En tabell med låtar
  • Ett förhållande mellan dem

Två tabeller

Förhållande

• Varje rad har utöver sina vanliga egenskaper också en "pekare" till ett album
  • Foreign key ("främmande nyckel")
• Hur kan vi peka på ett specifikt album?
  • Namn... kanske

One-to-many-förhållande med namn

Problem med namn

• Flera album kan ha samma namn
• Om vi ändrar namnet på ett album så behöver vi ändra många rader
• Bättre: ID
  • Unikt värde per rad: nyckel (key)
  • Vanligtvis också primary key ("primärnyckel")

One-to-many-förhållande med ID

Utökning: samma låt på olika album

• Varje album kan ha flera låtar (som förut)
• Varje låt kan ha flera album (exempelvis samlingsalbum)
• "Many-to-many"

Vad vi skulle göra i C#

1. class Album {
2. public string Name;
3. public DateTime Date;
4. public Song[] Songs;
5. }
7. class Song {
8. public string Name;
9. public int Length;
10. public Album[] Albums;
11. }

Problem med many-to-many

• Vår albumkolumn i låttabellen kan bara innehålla ett värde
• Vi behöver... en till tabell!
  • Join-tabell
  • Junction table i boken

Join-tabell

• Den nya tabellen har två kolumner:
  • En foreign key till den ena tabellens ID
  • En foreign key till den andra tabellens ID
• Varje rad i join-tabellen sammankopplar en rad i den ena tabellen med en rad i den andra tabellen

Many-to-many-förhållande

Extra värden på join-tabellen

• Ibland behöver vi "metadata" om förhållandet
  • Inte bara att raderna är sammankopplade utan också hur
  • Exempel:
    • Spårnummer för en låt (då databasen inte har någon inbyggd ordning)
    • Antal för en produkt i en beställning
    • Yrkesroll för person i filmproduktion
• Join-tabellen kan ha ytterligare kolumner med denna data

Exempel på extra värden i join-tabellen

Alternativt perspektiv

• Har vi ett many-to-many-förhållande mellan Movie och Person?
• ... eller ett one-to-many-förhållande mellan Movie och MoviePerson samt ett one-to-many-förhållande mellan MoviePerson och Person?
• I det senare fallet: MoviePerson är nu en "egen" tabell
  • Bättre namn: CastMember
• Främst en teoretisk diskussion
  • Principerna för ID:n och foreign keys är samma oavsett
• Viktig observation: en tabell kan ingå i flera förhållanden

Förhållanden istället för null

• Null ska användas för okända värden, inte icke-existerande värden
  • I praktiken inte alltid så
• Korrekt metod, enligt SQL-teori:
  • Ta bort null-kolumnen
  • Skapa en ny tabell med en rad för varje icke-null-värde i den tidigare kolumnen

Exempel på null istället för förhållande

Exempel på förhållande istället för null

Sammanfattning

• Om varje rad består av enbart inbyggda datatyper
  • Inget förhållande krävs
• Om varje rad i sin tur kan "innehålla" flera andra rader
  • One-to-many
  • Båda tabellerna behöver ID-värden genom primary keys
  • Tabellen vars rader ska förekomma flera gånger behöver en foreign key
• Om raderna "på andra sidan" också kan innehålla flera andra rader
  • Many-to-many
  • Båda tabellerna behöver ID-värden genom primary keys
  • En ny tabell som sammankopplar de två tabellerna behövs
  • Den nya tabellen behöver foreign keys till båda de andra tabellerna