Avatar billede foxmulder58 Praktikant
14. januar 2006 - 23:43 Der er 14 kommentarer og
3 løsninger

hjælp til relationer mellem tabeller

Hej eksperter,


Jeg vil gerne have hjælp til at forklare hvordan relationerne her hører sammen, samt hvorfor relationskopiering af felter er foretaget på denne måde:



http://www.netau.hotserv.dk/relationer/

NB! samt finde stærke/svage entiteter.


Håber en gider hjælpe mig!



Mvh
Mads
Avatar billede krellex Nybegynder
15. januar 2006 - 01:46 #1
Kan prøve..
Er dog lidt rusten.. :-)

1: relation genre -- film genre
Her kan beskrivelsen godt være en attribut således undgår du den sidste tabel.
I film_genre skal du således gøre genrenavn unique da den jo er primær attribut, den skal styre tabellen.

2: relation film_skuespiller -- skuespiller
er der man film_skuespiller til en skuespiller hvilket jo giver mening d en skuespiller spiller med i flere film.

Håber det kan hjælpe lidt.
Avatar billede sjap Praktikant
15. januar 2006 - 10:35 #2
Nu er databaseteori ikke min stærke side, men her er et forslag vedr. entiteter:

Stærke: Genre, Film og Skuespiller
(stærke entiteter har ingen fremmednøgler)

Svage: Film_Genre og Film_Skuespillere
Avatar billede terry Ekspert
15. januar 2006 - 10:39 #3
there are two many-to-many realtionships and in a many-to-many its is always necessary to have three tables. In this case Film is used in both.

A film can have more than one "genre" and a "genre" would be used in more than one film.

There will also very likely be more than one "skuespiller" in the film, and a "skuespiller" will act in more than one film.

So the tables film_genre and film_skuespiller make it possible to have more than just one "genre" or "skuespiller" in a film.

In the Film table there is a field instruktør. I would concider putting this in a seperate table becuase an "instruktør" will very likley instruct many films. And I would also think it possible that a film can have more than one instructor which would then give you another many-to-many relationship
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 11:28 #4
Terry >> there aren`t any many-to-many relationships in this database.

But i can see your argument in moving "skuespiller" in a seperate table.
Avatar billede terry Ekspert
15. januar 2006 - 12:28 #5
!
The diagram you gave a link to has two many-to-many relationships.
Avatar billede ffsoft Praktikant
15. januar 2006 - 12:46 #6
Det er en ekstrem dårlig måde relationerne er skruet sammen på, der kan f. eks. kun være een film der hedder "High noon", fordi nøglefelter skal være unikke. Det kunne måske bedre lade sig gøre at der f. eks. kun er en skuespiller der hedder "Brad Pitt".
Alle tabeller skal forsynes med en primærnøgle, som så fremmednøglerne kan linke til.

tblFilm
FilmID
Filmnavn
Handling
PremiereInfo
Aarstal
Produktionsland
GenreID

tblGenre
GenreID
GenreNavn
Beskrivelse

tblSkuespiller
SkuespillerID
SkuespillerNavn
FoedselsDato
FoedeSted
Biografi

tblFilm_Skuespiller
FilmID
SkuespillerID

I mellem Film og Genre er der en 1-til-mange relation. En film tilhører
en og kun en Genre. Den samme Genre kan godt forekomme i flere film

En Film kan godt have en eller flere Skuespillere og en Skuespiller
kan godt forekomme i en eller flere film. Der er en mange-til-mange
relation.

Jeg kan se du bruger Access, så du kan bruge autonummerering til alle
primærnøglerne.

- Læs mere om databaser her -
            www.ffsoft.dk
Avatar billede terry Ekspert
15. januar 2006 - 12:53 #7
Kan en film ikke have mere end en genre?
Romantisk komedie for eksempel.
Avatar billede terry Ekspert
15. januar 2006 - 12:54 #8
Have both thes in the same field doesnt make it as flexibale when searching on "genre"
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 12:57 #9
jo en film kan have mere end én genre databasen er som et led i én opgave der skulle håndtere 5 specifikke forespørgsler.

Jeg sidder nemlig lige nu og undrer mig over hvorfor jeg har lavet den relationskopiering!


Men jeg skal nok give point.
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 13:03 #10
Kan i huske hvorfor man gør følgende:

Kopieren primærnøglen "titel" over i en ny tabel og laver ek ekstre felt (fremmmednøgle).

Jeg mener, det som jeg har gjort fra "titel" ud til "film_genre" og "film_skuespiller"


Se linket til relationen hvis i er i tvivl om hvad jeg mener.


mvh
Mads
Avatar billede terry Ekspert
15. januar 2006 - 13:04 #11
I also agree with ffsoft in that the table film should have have another field as the primary key, because more than one film can have the same name "King Kong" for example.
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 13:06 #12
terry >> ja det er rigtigt (i agree).
Avatar billede terry Ekspert
15. januar 2006 - 13:08 #13
15/01-2006 13:03:29
teh reason for this is to give you a many-to-many relationship so that a film can have more than one "Genre". But add a new field (FilmID) in film and us this as the primary key. Then change the foreign key (titel) in film_genre to FilmID
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 13:11 #14
I have to defend this database and its relations so can`t change the tables, but i will take your advice in consideration.
Avatar billede foxmulder58 Praktikant
15. januar 2006 - 13:28 #15
Hvordan synes i point skal fordeles?


mvh
Mads
Avatar billede terry Ekspert
15. januar 2006 - 14:01 #16
You could split them evenly between us all, or depending on where you feeling you got most help. In the end its up to you :o)
Avatar billede terry Ekspert
15. januar 2006 - 17:55 #17
thanks Mads, hope the others are happy with the points
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Dyk ned i databasernes verden på et af vores praksisnære Access-kurser

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester