Tabel met meerdere Foreign Keys

[Jaspertje]

Tweakers,

Ik heb een hele nieuwe startpost geschreven met het probleem zelf, want mijn voorbeeld was niet goed. Excuus. (Daarin is ook het voorbeeld veranderd, hiercvoor ging het over auto's motoren en motorinhouden )

Ik heb het volgende probleem:
Zowel een lening als een verzekering kunnen een of meerdere gekoppelde portfolio's hebben maar een portfolio kan niet bij zowel een lening als een verzekering horen. Lening en verzekering hebben niets met elkaar te maken maar in het objectenmodel is de portfolio hetzelfde.

In de database kan dit op meerdere manieren opgelost worden en ik zoek eigelijk de beste.
1. In de portfolio tabel referentie's leggen naar beide tabellen en dmv een FK en een trigger om te controleren of een portfolio al niet bij een ander object (lening of verzekering) hoort.


Het nadeel hiervan is wel als er nog een derde object komt wat ook aan portfolio gekoppeld moet worden, de tabel en de trigger uitgebreid moeten worden.

2. Tussen beide tabellen een losse koppeltabel zetten met daarin een 1-1 relatie tussen de portfolio en de gekoppelde portfolio. Daardoor kan een portfolio niet aan meerdere leningen/verzekeringen gekoppeld worden. Dan zullen er alsnog triggers geschreven moeten worden die controleren of de portfolio niet al voor het andere object gebruikt wordt.
Het voordeel is dat een nieuwe koppelingen een extra tabel oplevert waardoor de rest niet aanpast. Het nadeel is dat er dan waarschijnlijk meerdere triggers geupdate moeten worden


3. Twee lossen portfolio tabellen maken. 1 voor leningen en 1 voor verzekeringen. Dit gaat alleen een huge beheersprobleem opleveren als er een update plaatsvindt op de tabel

Ik hoop dat ik nu wel duidelijk ben. Excuus nogmaals

NB. Gebruik SQL 2000

[ Voor 85% gewijzigd door Jaspertje op 20-07-2007 10:07 ]

[P_de_B]

Zou je niet overwegen een tabel 'Voertuig' te maken, met daarbij (eventueel) een tabel Voertuigtype?

[Creepy]

Een andere optie zou zijn om van motor en auto 1 tabel "voertuig" o.i.d. te maken met een type aanduiding. Kan je ook vrij eenvoudig andere type's (boot, brommer, broodrooster etc.) toevoegen.

Edit: snelle P_de_B

Meteen even een move naar SEA. In DTE heeft het niet veel te zoeken

[ Voor 19% gewijzigd door Creepy op 19-07-2007 12:53 ]

[Tukk]

Verwacht je dat er velschillende eigenschappen nog kunnen komen voor een auto, boot of motor?
Ander zet je de data in 1 tabel, met een extra kolom of het een auto, motor of boot betreft.

Als er dan alsnog eigenschappen voor een bepaald soort rij/vaartuig komt kun je een tabel aanmaken met de kolommen RIJTUIGID, EIGENSCHAPNAAM, WAARDE. Ben je geheel vrij voor mogelijk aanpassingen.

@Eens met de blauwe en rode hierboven.

[ Voor 5% gewijzigd door Tukk op 19-07-2007 12:55 ]

[EfBe]

Ik vraag me bij het schema meteen af: wat is de reden dat motorinhoud een entity is? Volgens mij is dat nl. een attribute van 'motor' (niet die dingen met 2 wielen, maar die dingen die voorin in je panda liggen )

[Jaspertje]

Excuus dat ik niet helemaal duidelijk ben. Ik gebruik dit als (blijkt nu, verschikkelijk slecht) voorbeeld. Normaal zou ik dit idd ook anders modeleren. Dit is dan ook puur het voorbeeld. Theoretisch zou er ook een heel ander ding aan motorinhoud gekoppeld kunnen worden.

In werkelijkheid gaat het over portfolio's (beleggingen) die aan verzekeringen gekoppeld kunnen worden, maar ook aan bankaire producten. Waarbij motor en auto dus compleet niets met elkaar te maken zouden hebben. (Ik heb dus toch een slecht voorbeeld gekozen)

EfBe schreef op donderdag 19 juli 2007 @ 12:57:
Ik vraag me bij het schema meteen af: wat is de reden dat motorinhoud een entity is? Volgens mij is dat nl. een attribute van 'motor' (niet die dingen met 2 wielen, maar die dingen die voorin in je panda liggen )

In het 'objectenmodel' is motorinhoud ook een entiteit, vandaar dat ie los is.

[ Voor 27% gewijzigd door Jaspertje op 19-07-2007 18:43 ]

[EfBe]

Jaspertje schreef op donderdag 19 juli 2007 @ 18:42:
Excuus dat ik niet helemaal duidelijk ben. Ik gebruik dit als (blijkt nu, verschikkelijk slecht) voorbeeld. Normaal zou ik dit idd ook anders modeleren. Dit is dan ook puur het voorbeeld. Theoretisch zou er ook een heel ander ding aan motorinhoud gekoppeld kunnen worden.

In werkelijkheid gaat het over portfolio's (beleggingen) die aan verzekeringen gekoppeld kunnen worden, maar ook aan bankaire producten. Waarbij motor en auto dus compleet niets met elkaar te maken zouden hebben. (Ik heb dus toch een slecht voorbeeld gekozen)

ALTIJD echte omschrijvinge/code gebruiken ipv faked voorbeelden, want dat gaat altijd mis.

[...]
In het 'objectenmodel' is motorinhoud ook een entiteit, vandaar dat ie los is.

Dan nog is het een attribute en geen entiteit. Motorinhoud is een value, geen entiteit met een uniek identificerend attribute, want het heeft maar 1 attribute, nl. zichzelf.

Zolang je motorinhoud handhaaft als een entiteit blijft je model fout en gammel.

[Jaspertje]

Ik heb de topicstart herschreven. Het echte probleem staat nu beschreven ipv een slecht voorbeeld.

[ikke007]

In Postgres kun je dit oplossen met een 'Check' (weet niet of dat SQL standaard is en of dat door andere databases wordt ondersteund). Dit is een redelijk simpele constraint welke checkt of een expressie een boolean true oplevert en anders een error raised

http://www.postgresql.org...tive/ddl-constraints.html

voorbeeld

SQL:

CREATE TABLE portfolio (
    portfolioid SERIAL,
    leningid integer CHECK (leningid IS NULL OR verzekeringid IS NULL),
    verzerkeringid integer CHECK (leningid IS NULL OR verzekeringid IS NULL),
    rekeningnummer varchar(15)
);

NB: je startpost is duidelijk maar het is wel raar als de eerste reactie's over voertuigen en auto's gaan en dat niet in je startpost terug komt

[ Voor 11% gewijzigd door ikke007 op 20-07-2007 09:42 ]

[Verwijderd]

Zou je niet een tabel ProductPortfolio (verzekering/lening) kunnen introduceren als koppeltabel met drie velden.

1. ProductId (verzekering/lening id en later evt. andere producten)
2. PortfolioId
3. Id

In je tabel verzekeringen en portfolio maak je ook een extra veld ProductId (oid) en die heeft dan een 1 op 1 relatie met het Id in de Product-tabel.

Op deze manier koppel je in deze tabel je verzekering of lening aan een of meerdere portfolio's en mag elk portfolio dus maar 1 keer voorkomen in deze tabel, dan heb je geen triggers nodig voor controles.

Misschien zie ik wat over het hoofd, maar volgens mij moet het zo kunnen.

Dit komt een beetje overeen met het voertuig-verhaal in je vorige startpost

[ Voor 19% gewijzigd door Verwijderd op 20-07-2007 11:13 ]

[Dido]

Optie 1, met een extra veldje in "Portfolio", om aan te geven waar het aan gelinkt is?

Waar je dan verzekering/lening ID in 1 veldje kwijt kunt ipv in twee, met een FK over Extra veldje+ID?

[ Voor 38% gewijzigd door Dido op 20-07-2007 11:03 ]

[Jaspertje]

Dido schreef op vrijdag 20 juli 2007 @ 11:01:
Optie 1, met een extra veldje in "Portfolio", om aan te geven waar het aan gelinkt is?

Waar je dan verzekering/lening ID in 1 veldje kwijt kunt ipv in twee, met een FK over Extra veldje+ID?

Dus dan in Portfolio een 'type' lening of verzekering meegeven

[Dido]

Jaspertje schreef op vrijdag 20 juli 2007 @ 13:48:
Dus dan in Portfolio een 'type' lening of verzekering meegeven

Precies

Voordeel is dat als je later meerdere mogelijkheden krijgt, je je Portfolio-tabel niet hoeft aan te passen.

[Jaspertje]

Dido schreef op vrijdag 20 juli 2007 @ 14:38:
[...]

Precies

Voordeel is dat als je later meerdere mogelijkheden krijgt, je je Portfolio-tabel niet hoeft aan te passen.

Dit is een goede oplossing ben ik inmiddels achter... maaar........ hoe kan ik er nu voor zorgen dat mijn database relationeel blijft. Ik kan nu geen cascading deletes meer gebruiken, en triggers/code moet ik ook aanpassen als ik een nieuwe type wil gebruiken. Dan gaat deze oplossing weer werk kosten