[Robert]

Om vi säger att du har en tabell med Universitet (där datat mer eller mindre aldrig updateras pga att det inte byggs så många ny univ.)

Du har också lagt in data om programmen i din Programtabell.

Du kan ju börja med att knyta ihop vilka program som hör till vilka universitet genom att i din kopplingstabellen (mellan univ och prog) koppla universitetsid till programid.

Du gör sedan likadant med kurser; knyter dessa kurser till de olika programmen, och sedan likadant med böckerna, knyter dess böckernas id till kursernas id.

Men du får ju tänka på följande; om det finns lokala avvikelser mellan de olika universitetens program så bör de lagras dubbelt i databasen (de kanske har olika kurslitteratur knutet till sig och då måste programmen ligga som en dublett. Likaså gäller givetvis kurserna.

[eg0master]

Originally posted by Robert@Mar 31 2005, 10:35
Men du får ju tänka på följande; om det finns lokala avvikelser mellan de olika universitetens program så bör de lagras dubbelt i databasen (de kanske har olika kurslitteratur knutet till sig och då måste programmen ligga som en dublett. Likaså gäller givetvis kurserna.

just därför är ju en enda kopplingstabell utmärkt...

men för att återgå till problemet...
Exakt hur lägger du in data och exakt hur hämtar du data när du äsger "att inget finns där"?

[Robert]

Ursprungligen postat av eg0master

just därför är ju en enda kopplingstabell utmärkt...

men för att återgå till problemet...
Exakt hur lägger du in data och exakt hur hämtar du data när du äsger "att inget finns där"?

"en enda kopplingstabell"? Uh?

Det blir antagligen mycket redundans då kopplingar måste dubbleras för varje universitet som kommer in etc etc. Det bästa är att göra en "riktigt" databasmodell, och i detta fallet betyder det att böckerna bara ska kopplas till kurserna.

Ett universitet kan inte ha en bok.
Ett program kan inte ha en bok.
En kurs kan ha flera böcker.

[eg0master]

Nu går vi off-topic men;
Samma kurs kan ha olika böcker beroende på olika universitet.
Således måste man välja på att antingen ha redundans i "kurs" dvs två instanser av samma kurs beroende på universitet, eller så löser man det med en kopplingstabell som talar om vilken bok som hör till vilken kurs på vilket universitet.

Om man har den typen av beroenden är till och med databasen normaliserad. Det finns inget som säger att man inte får koppla flera olika tabeller i en gemensam tabell. Allt hänger ju på hur relationerna i data ser ut.
bara för att samma kurs råkar ha samma bok på två olika universitet innebär inte det att data är redundant eftersom det är olika universitet.

Du refererar till att man skall göra en "riktig" databasmodell. "Riktig" betyder i alla praktiska fall att DB-modellen måste vara anpassad för de relationer man kan identifiera, inte anpassad för en fantasivärld.
Det är naturligt att knyta bok till kurs och kurs till universitet. men om man gör det finns bara en lösning när samma kurs har olika böcker på olika universitet och det är att göra två olika kurser, men med samma namn. Om det nu är så att detta är vanligt (vilket det sannolikt är) blir det lättare och mer i linje med de verkliga relationerna att lägga allt i en enda kopplingstabell.
Med lite våld kan man kanske kalla det redundans, men det är inte intressant egenligen för det man vill ha är en DB-modell som liknar verkligheten för att på så sätt göra jobbet att lägga in och hämta data enklare. Samtidigt ger den förenklade (med en gnutta redundans) sannolikt snabbare svar än en mer puristisk design.

[Robert]

Kopplingar ska göras på 1 ställe så de kan pekas om utan att behöva updatera på flera ställen. Om nu en kurs skulle byta universitet (vilket iofs är fantasi i detta fall men som exempel så behöver man updatera xxx antal kopplingar istället för att bara peka om kursen.

Japp, två kurser som har olika innehåll är INTE likdana bara för att vi människor väljer att identifiera en kurs vid dess namn (som må vara samma). Det är därför inte redundans att lagra en (till synes) identiskt kurs flera gånger.

Min personliga åsikt är inte att din modell är mer "i linje med de verkliga relationerna". De flesta strukturer beskrivs både lättas och bäst i en trädstruktur, inte en "stjärnstruktur" där 1 objekt har förgreningar åt alla håll även om de övriga objekten (tabellerna) har inbördes kopplingar.

Måhända att i detta fall endast böckerna är en avgränsad sak som ska behandlas och då duger kanske din struktur, men om man någon gång i en oöverskådlig (oplanerad snarare) framtid behöver göre en förändring så är det dumt att ha målat in sig i ett hörn. Tänk att senare behöva lägga till en tabell som kanske beskríver författare. Då måste man i ditt fall lägga till en kolumn och updatera alla rader i denna (på bredden) växande kopplingstabell. Samma bok, med samma författare, behöver alltså updateras på xxx antal ställen.

[Steiner83]

Jag är oerhört tacksam för Era svar. Det är en stor tröst, tro mig!

Iaf. Så här har jag lagt upp mina tabeller. Funderade om det var något i radernas beskrivning som är felaktig och som därför skapar "tom" data i min tabell.
Är aningen förvirrad då det är så pass många olika variabler som skall in. Kommentera gärna! Åter igen är jag väldigt tacksam!


create table tbluni
( uniID CHAR(4) NOT NULL PRIMARY KEY,
uni CHAR(50) NOT NULL);


create table tblprogram
( programID CHAR(5) NOT NULL PRIMARY KEY,
uniID CHAR(4) NOT NULL,
program CHAR(30) NOT NULL
);


create table tblterm
( termID CHAR(7) NOT NULL PRIMARY KEY,
programID CHAR(5) NOT NULL,
term INT NOT NULL
);


create table tblcourse
( kursID CHAR(6) NOT NULL PRIMARY KEY,
termID CHAR(7) NOT NULL,
course CHAR(100) NOT NULL,
credits CHAR(2) NOT NULL
);


create table tblbooks
( bokID INT NULL AUTO_INCREMENT PRIMARY KEY,
uniID CHAR(4),
programID CHAR(5) NOT NULL,
termID CHAR(7) NOT NULL,
kursID INT NOT NULL,
title VARCHAR(200) NOT NULL,
author1 VARCHAR(50) NULL,
author2 VARCHAR(50) NULL,
author3 VARCHAR(50) NULL,
author4 VARCHAR(50) NULL,
year CHAR(4) NULL,
edition CHAR(3) NULL,
isbn CHAR(13) NULL,
publisher CHAR(60) NULL,
status VARCHAR(5) NULL
);

[eg0master]

Originally posted by Robert@Mar 31 2005, 14:13
[...]
Måhända att i detta fall endast böckerna är en avgränsad sak som ska behandlas och då duger kanske din struktur, men om man någon gång i en oöverskådlig (oplanerad snarare) framtid behöver göre en förändring så är det dumt att ha målat in sig i ett hörn. Tänk att senare behöva lägga till en tabell som kanske beskríver författare. Då måste man i ditt fall lägga till en kolumn och updatera alla rader i denna (på bredden) växande kopplingstabell. Samma bok, med samma författare, behöver alltså updateras på xxx antal ställen.
[...]

Egentligen är vi i stora drag överrens som jag tolkar det.

Dock är det naivt av dig (och ett hån mot mitt intelekt ) att tro att bara för att jag i detta fall finner en enda kopplingstabell lämplig så skulle det betyda att när jag vill lägga till författare så måste jag göra det med en kolumn till i den gigantiska tabellen.

Jag är ute efter att använda de relationer som är verkliga och en bok har en eller flera författare och tvärt om. Därför är det oavsett den ursprungliga stora kopplingstabellen lämpligt med en separat kopplingstabell för bok/författare.

En lösning utesluter inte en annan...

Steiner: Exakt hur lägger du in data. Och exakt hur ser du att dina tabeller är tomma?

[Steiner83]

Glömde säga att jag tittar efter sparad data genom att gå in i PHPADMIN. Använder jag enbart SQL satser i PHPADMIN sparas data utan problem...för att titta på datan väljer jag bara vilken databas sedan vilken tabel och "VISA", tabellen kommer då fram och den data jag satt in finns där.
Försöker jag köra via formulär så är tabellen delvis NULL och de rader som inte är NULL är helt tomma.

[Steiner83]

Har viss data sparad, ca 100 rader, och försökte åtminstone få in den i databasen.
Det skall tydligen gå om man konverterar excellfilen till CSV och lägger in den via PHPADMIN. Visst skapas det rader men det är all NULL precis som tidigare....

[Steiner83]

Försöker lägga in kolumner rad efter rad. Den första fungerar, dvs uniID men inte programID då uppstår NULL-felet.... Har tagit bort svenska tecken och vad som än så länge enbart finns i kolumen är "lak" (utan " förstås).