Rel. Database - Multiple foreign keys

[Verwijderd]

Probleemomschrijving
Een tabel child met een foreign key parentID naar de primary key in 1 van de volgende tabellen:
• ParentA
• ParentB
• ParentC
Zoals bekend, kan een foreign key niet naar meerdere tabellen wijzen.

Oplossing van mij
Ik heb daarom een koppeltabel gemaakt, kopTabel, met 1 veld:

• PK koppelingID

De foreign key parentID in child wijst naar deze PK en een veld childID in parentA, parentB en parentC wijst ook naar deze PK.

Er is dus een 1 op 1 op 1 relatie.

Is dit de juiste manier? Aangezien de parents niets met elkaar te maken hebben, is 'omhoog' brengen van gegevens niet mogelijk (zoals gevonden op google).

[NMe]

Databaseontwerp is òòk software engineering.

Programming>>Software Engineering & Architecture

[mulder]

Waarom dan in child niet gewoon ParentA_ID, ParentB_ID en ParentC_ID?

[Verwijderd]

Don Facundo schreef op maandag 20 maart 2006 @ 11:20:
Waarom dan in child niet gewoon ParentA_ID, ParentB_ID en ParentC_ID?

Tsjah, dat kan wel, maar is niet echt genormaliseerd Er is namelijk maar eenparent, dus parentA, parentB OF parentC. Met jouw oplossing zou je dan 2x null krijgen...

offtopic:
@NME: Tsjah, die nieuwe structuur ook

[Pannenkoekkie]

Veelal is de neiging om koppeltabellen te gebruiken een direct gevolg van het niet goed normaliseren van je gegevens... Ik kan helaas niet meer dan dit zeggen omdat ik weinig data heb

[Verwijderd]

Tsjah, het is nogal lastig uit te leggen wat die childs en parents precies zijn...

Elke parent is iets heel anders. Je zou het zo kunnen zien: child = een deur, parentA=een auto, parentB=een huis. Zoiets...

Heeft IMO niets met normaliseren te maken, ik moet een bepaalde tabel koppelen aan 1 van drie tabellen Jij hebt wel gelijk dat een koppeltabel meestal nodig is bij slecht genormaliseerde databases, maar aangezien de 3 parents niets met elkaar te maken hebben, kan dat niet.

[mulder]

Ik snap die koppeltabel eigenlijk ook niet, 1 veld? Hoe kun je nou zien welk type je parent is?

[Verwijderd]

Don Facundo schreef op maandag 20 maart 2006 @ 11:36:
Ik snap die koppeltabel eigenlijk ook niet, 1 veld? Hoe kun je nou zien welk type je parent is?

Ja, dat is ook het lastige

Ik probeerde net een query te maken, maar dat wil inderdaad niet ... In de koppeltabel zou ik voor elke parenttabel een FK kunnen maken, maar dat is weer niet netjes.

Ik kom er gewoon even niet meer uit

[P_de_B]

Ik snap het ook niet precies, maar moet je de relatie niet andersom maken? Je Parent tabel heeft een FK relatie naar je child tabel

[Varienaja]

Dit is hoe ik dat doe:

code:

Tabel AbstractObject
ID (PK)
Naam
Blabla

Tabel Deur
ID (PK + FK naar AbstractObject)
Breedte
Hoogte

Tabel Auto
ID (PK + FK naar AbstractObject)
Merk
AantalDeuren

Tabel Childding
ID (PK)
ObjectID (FK naar AbstractObject)
...

[JKVA]

Kun je niet 1 foreign key maken die naar de paren verwijst en dat eventueel samen met een indicatieveldje?

Iets van een varchar ofzo waar je dan AUTO, HUIS, etc in zet.

[Verwijderd]

P_de_B schreef op maandag 20 maart 2006 @ 11:40:
Ik snap het ook niet precies, maar moet je de relatie niet andersom maken? Je Parent tabel heeft een FK relatie naar je child tabel

Een parent kan meerdere childs hebben

JKVA schreef op maandag 20 maart 2006 @ 11:41:
Kun je niet 1 foreign key maken die naar de paren verwijst en dat eventueel samen met een indicatieveldje?

Iets van een varchar ofzo waar je dan AUTO, HUIS, etc in zet.

Heb ik ook al aangedacht, maar een FK moet toch naar een tabel wijzen? Hoe had je dit in gedachten? Volgens mij kan dit niet werken...

Varienaja schreef op maandag 20 maart 2006 @ 11:40:
Dit is hoe ik dat doe:

code:

Tabel AbstractObject
ID (PK)
Naam
Blabla

Tabel Deur
ID (PK + FK naar AbstractObject)
Breedte
Hoogte

Tabel Auto
ID (PK + FK naar AbstractObject)
Merk
AantalDeuren

Tabel Childding
ID (PK)
ObjectID (FK naar AbstractObject)
...

Dit moet ik denk ik nog een paar keer overlezen

[ Voor 68% gewijzigd door Verwijderd op 20-03-2006 11:50 ]

[mulder]

Varienaja schreef op maandag 20 maart 2006 @ 11:40:
Dit is hoe ik dat doe:

code:

Tabel AbstractObject
ID (PK)
Naam
Blabla

Tabel Deur
ID (PK + FK naar AbstractObject)
Breedte
Hoogte

Tabel Auto
ID (PK + FK naar AbstractObject)
Merk
AantalDeuren

Tabel Childding
ID (PK)
ObjectID (FK naar AbstractObject)
...

Juist, en dan AbstractObject de ID laten genereren en die aan de (overervende) tabellen meegeven zodat die dezelfde ID hebben. Maar dan zul je ook nog het (object)type moeten opslaan in AbstractObject?

[Verwijderd]

Don Facundo schreef op maandag 20 maart 2006 @ 11:53:
[...]


Juist, en dan AbstractObject de ID laten genereren en die aan de (overervende) tabellen meegeven zodat die dezelfde ID hebben. Maar dan zul je ook nog het (object)type moeten opslaan in AbstractObject?

Sorry, maar ik heb dit 10x doorgelezen, maar snap het echt niet... De parents en childs zijn allemaal verschillende tabellen zonder enige overeenkomst...

[Dido]

Een koppeltabel lijkt me op zich niet verkeerd, maar met 1 veld is het onzinnig.

Het lijkt me trouwens dat je drie koppeltabellen wilt hebben, of in het huis/auto voorbeeld 2.

code:

HUIS ---< HUISDEUR >---|
                       |--- DEUR
AUTO ---< AUTODEUR >---|

Met in HUISDEUR: HUIS_ID en DEUR_ID
Met in AUTODEUR: AUTO_ID en DEUR_ID

Lijkt me ook logisch, aangezien een deur dan wel een deur is, maar een huisdeur en een autodeur zijn verschillende entiteiten, lijkt me.

[ Voor 17% gewijzigd door Dido op 20-03-2006 12:01 ]

[Verwijderd]

Dido schreef op maandag 20 maart 2006 @ 12:00:
Een koppeltabel lijkt me op zich niet verkeerd, maar met 1 veld is het onzinnig.

Het lijkt me trouwens dat je drie koppeltabellen wilt hebben, of in het huis/auto voorbeeld 2.

code:

HUIS ---< HUISDEUR >---|
                       |--- DEUR
AUTO ---< AUTODEUR >---|

Met in HUISDEUR: HUIS_ID en DEUR_ID
Met in AUTODEUR: AUTO_ID en DEUR_ID

Lijkt me ook logisch, aangezien een deur dan wel een deur is, maar een huisdeur en een autodeur zijn verschillende entiteiten, lijkt me.

Dat 1 veld onzinnig is, had ik al bedacht ja....

Dit lijkt meer ergens op Ik moet vanuit de parent al zijn childs kunnen opzoeken.

Ff denken... in SQL:

SQL:

SELECT deur_id FROM huisdeur WHERE huis_id = x

_{x = dan een bepaalde waarde}

Dat is vrij simpel ja

Is 3 koppeltabellen de netste oplossing? Ik wil niet dat ik lui overkom, maar database design is echt niet mijn ding

offtopic:
TIP: ga nooit afstuderen

[kenneth]

Verwijderd schreef op maandag 20 maart 2006 @ 11:56:
[...]

Sorry, maar ik heb dit 10x doorgelezen, maar snap het echt niet... De parents en childs zijn allemaal verschillende tabellen zonder enige overeenkomst...

Je zegt dan in AbstractObject of het een Deur of een Auto is. Een zgn discriminator.

[Varienaja]

Don Facundo schreef op maandag 20 maart 2006 @ 11:53:
Juist, en dan AbstractObject de ID laten genereren en die aan de (overervende) tabellen meegeven zodat die dezelfde ID hebben. Maar dan zul je ook nog het (object)type moeten opslaan in AbstractObject?

Het objecttype hoef je niet per se op te slaan. Een AbstractObject met id 1 is een Deur als er een deur is met id 1, of een Auto als er een Auto is met id 1. Het mag niet voorkomen dat zowel een Deur als een Auto hetzelfde id hebben, en dat kan je inderdaad proberen te voorkomen door het id uit een sequence te laten komen.

Ik werk veel met Hibernate, en dan heet deze constructie een joined-subclass. Je kunt een joined-subclass wel op meer dan 1 manier in een database opslaan, maar de oplossing die ik gaf vind ik de meest elegante constructie.

[mulder]

Een AbstractObject met id 1 is een Deur als er een deur is met id 1, of een Auto als er een Auto is met id 1.

Maar dit gaat toch duurder worden bij elke type die je toevoegt?

[Varienaja]

Don Facundo schreef op maandag 20 maart 2006 @ 12:44:
Maar dit gaat toch duurder worden bij elke type die je toevoegt?

Inderdaad. Maar als je ervoor zorgt dat je alleen queries doet op Deuren of op Auto's, dan valt het reuze mee. Er blijft dan slechts een join van over. Als je objecten van ieder type wilt be-querien dan wordt het wel snel duurder ja.

Je kunt er dan voor kiezen om een tabel als dit te nemen:

code:

ID (PK)
Type (1 = deur, 2 = auto, 3 = gebouw, 4 = trein, 5 =...)
Aantaldeuren
Merk
Breedte
Hoogte
AantalWagonnetjes

Velden die niet van belang zijn voor je type laat je null. Dan heb je minder tot geen last van het duurder worden van queries, maar dan ga je weer enorm veel (disk)geheugen misbruiken.

Objectgeorienteerde zaken als overerving zijn bere-slecht in een relationele DB te vatten. Echt netjes wordt het nooit.