Representation av SQL-data
Uppgift:
A natural way to represent a list of bands is to list every band with all the artists belonging to it, so that
every band name is mentioned only once. For example, consider the following lists with band members
and the years they joined the band (the lists are not complete):
• The Beatles: John Lennon 1960, Paul McCartney 1960, Ringo Starr 1962, George Harrison 1960
• Metallica: James Hetfield 1981, Lars Ulrich 1981, Kirk Hammett 1983, Dave Mustaine 1982, Cli↵
Burton 1982
Is this possible in the relational data model, such as SQL? If yes, show the table. If no, explain why.
Notice: We expect the solution to use just band names, artist names, and years as attributes - no other
attributes such as ID numbers.
Jag är med på att atomära värden bryter mot första normalformen, men jag förstår inte varför det skulle vara ett problem att varje rad har samma längd?
Svaret till uppgiften:
A table listing all members of a band on a row would violate the first normal form: that all posts in a tuple have atomic
values. Or the even more fundamental principle that all tuples have the same length.
Försök att skriva kolumnnamn på din tabell. Tex:
Bandnamn | bandmedlem 1 | bandmedlem 2 | bandmedlem3
Då ser du att det blir ett problem eftersom alla band inte har lika många medlemmar.
Det finns såklart många sätt att komma runt detta men de är egentligen inte så bra (man kan tex lista alla medlemmar i ett fält vilket skulle göra det svårare att använda datat).
Eller ha tomma fält ... men hur många skall man då ha?
En tupel som sådan (om ordet ens egentligen finns på svenska) har väl inte nödvändigtvis samma storlek som en annan tupel, och i många datorsammanhang kan man ha vilka tupler man vill var som helst. I andra sammanhang (t.ex. mycket strängt typade språk som Haskell) måste man bestämma sig för en viss längd om en variabel ska ha en tupeltyp. Sådana språk där man kan hantera alla slags objekt helt fritt var inte så vanliga när man utformade relationsdatabaser och deras olika normalformer, så det betraktades nog som sunt, och gör väl det fortfarande, att en tupel i ett visst sammanhang måste ha ett bestämt antal element.
Men jag vet inte om "tupel" egentligen förekommer alls i databas-terminologi (som ni hör har jag tangerat ämnet men inte djupdykt). Hur används det tidigare i boken?
joculator skrev:Försök att skriva kolumnnamn på din tabell. Tex:
Bandnamn | bandmedlem 1 | bandmedlem 2 | bandmedlem3
Då ser du att det blir ett problem eftersom alla band inte har lika många medlemmar.Det finns såklart många sätt att komma runt detta men de är egentligen inte så bra (man kan tex lista alla medlemmar i ett fält vilket skulle göra det svårare att använda datat).
Eller ha tomma fält ... men hur många skall man då ha?
Jag missförstod svaret till uppgiften ser jag nu då jag tolkade det som att det inte är tillåtet att ha rader av samma längd. Tomma fält är väl något man skall undvika. Jag gissar att man skulle kunna lösa problemet genom två tabeller där en tabell innehåller information om bandet (idnummer, bandnamn, genre, skivbolag, ...) och en annan tabell som innehåller data för varje medlem (personnummer, namn, år, ...) ?
Laguna skrev:En tupel som sådan (om ordet ens egentligen finns på svenska) har väl inte nödvändigtvis samma storlek som en annan tupel, och i många datorsammanhang kan man ha vilka tupler man vill var som helst. I andra sammanhang (t.ex. mycket strängt typade språk som Haskell) måste man bestämma sig för en viss längd om en variabel ska ha en tupeltyp. Sådana språk där man kan hantera alla slags objekt helt fritt var inte så vanliga när man utformade relationsdatabaser och deras olika normalformer, så det betraktades nog som sunt, och gör väl det fortfarande, att en tupel i ett visst sammanhang måste ha ett bestämt antal element.
Men jag vet inte om "tupel" egentligen förekommer alls i databas-terminologi (som ni hör har jag tangerat ämnet men inte djupdykt). Hur används det tidigare i boken?
Vissa rader i en tabell kan ju innehålla nullvärden, och om rad 1 inte har några nullvärden, men rad 2 har ett nullvärde så antar jag att rad 1 och 2 har olika längd? Det vi har fått lära oss i skolan är att man skall undvika nullvärden om det går
Jag har sett att tuple används i flera böcker om databaser. Här följer en tabell över termerna:
TB16 skrev:joculator skrev:Försök att skriva kolumnnamn på din tabell. Tex:
Bandnamn | bandmedlem 1 | bandmedlem 2 | bandmedlem3
Då ser du att det blir ett problem eftersom alla band inte har lika många medlemmar.Det finns såklart många sätt att komma runt detta men de är egentligen inte så bra (man kan tex lista alla medlemmar i ett fält vilket skulle göra det svårare att använda datat).
Eller ha tomma fält ... men hur många skall man då ha?
Jag missförstod svaret till uppgiften ser jag nu då jag tolkade det som att det inte är tillåtet att ha rader av samma längd. Tomma fält är väl något man skall undvika. Jag gissar att man skulle kunna lösa problemet genom två tabeller där en tabell innehåller information om bandet (idnummer, bandnamn, genre, skivbolag, ...) och en annan tabell som innehåller data för varje medlem (personnummer, namn, år, ...) ?
Ja, man löser normalt detta genom att ha en tabell med alla band (med ett id för varje band) och sedan en annan tabell med alla medlemmar (med en kolumn med band-id). Men frågan var väl om det går att lösa med EN tabell och dessutom skulle man inte använda ID ...
Om man använder 2 tabeller får man sedan hantera att vissa medlemmar kan vara med i flera band (dvs det kan bli flera rader för en viss person). Detta hanteras när man ställer frågor mot databasen.
-----------------------
We expect the solution to use just band names, artist names, and years as attributes
Ja, det går i EN tabell men den blir ju inte 'relational data modell'
Om man inte får lägga till ett ID på band kan man inte hantera att flera band kan ha samma namn.
joculator skrev:Ja, man löser normalt detta genom att ha en tabell med alla band (med ett id för varje band) och sedan en annan tabell med alla medlemmar (med en kolumn med band-id). Men frågan var väl om det går att lösa med EN tabell och dessutom skulle man inte använda ID ...
Om man använder 2 tabeller får man sedan hantera att vissa medlemmar kan vara med i flera band (dvs det kan bli flera rader för en viss person). Detta hanteras när man ställer frågor mot databasen.
-----------------------
We expect the solution to use just band names, artist names, and years as attributes
Ja, det går i EN tabell men den blir ju inte 'relational data modell'
Om man inte får lägga till ett ID på band kan man inte hantera att flera band kan ha samma namn.
Men oavsett om vi hade fått använda ett ID så hade det väl inte räckt för att klassas som en 'relational data model' eftersom alla band kan ha olika antal medlemmar? En databas måste väl i alla fall bestå av minst två tabeller för att få räknas som en relationsdatabas?
Ja, för att räknas som en 'relational data model' måste man ha fler än en tabell.
Id hade används för att skapa relationen mellan tabellerna. Det blir mindre bra om man tex använder bandnamnet som nyckel.
