[SQL] Vraag over een cardinality constraint

[Captain N]

Ik ben al een hele tijd aan het zoeken naar het antwoord op een simpele vraag (denk ik ) .. ik heb een ER diagram gemaakt, waarin een stukje zit dat er als volgt uit ziet:

een entiteit Recencist, met de attributen recensistnr (PK), naam, en adres.
een tweede entiteit genaamd Website met de attributen home_url (PK), en naam.

Tussen deze zit een relatie genaamd Werkt_voor. Iedere Recencist werkt precies voor 1 Website, en iedere Website heeft minstends 1 Recensist. Ik heb hier de volgende SQL bij gemaakt:

code:

CREATE TABLE Recencist  ( recencistnr   INTEGER,
              naam      CHAR(30),
              adres     CHAR(70),
              home_url  CHAR(50) NOT NULL,
              PRIMARY KEY (recencistnr),
              FOREIGN KEY (websitenr)   REFERENCES Website )

CREATE TABLE Website    ( home_url  CHAR(50),
              naam      CHAR(30),
              PRIMARY KEY (home_url) )

Dit zou volgens mij goed werken als een Website 0 tot n Recencisten zou hebben, maar dus niet wanneer het minstends 1 website moet hebben. Mijn vraag is nu hoe ik dit wel kan oplossen. Een aparte tabel maken voor de relatie? Of is het ook mogelijk op deze manier met wat aanpassingen? Kan deze specifieke situatie nergens vinden in mijn boek, en ook na een lange zoektocht op internet nog geen resultaat. Alvast bedankt.

[ Voor 5% gewijzigd door Captain N op 03-06-2003 18:20 ]

[ACM]

Ten eerste heb je enige duplicatie in je data door een primary key die a) niet betekenisloos en b) aan verandering onderhevig is.

Je kan voor je website beter een aparte id bijhouden.

Voor de n-m relaties ben je doorgaans gedwongen een aparte tabel bij te houden, als dan n gelijk is aan 1-n en/of m ook wordt het lastiger, want je kan wel vrij simpel bijhouden dat er 0-n koppelingen zijn, maar niet dat er meer zijn.

Hoe dat specifieke 1...n - 1...m op te lossen zou ik zo gauw ook niet weten

[Captain N]

ACM schreef op 03 June 2003 @ 18:23:
Ten eerste heb je enige duplicatie in je data door een primary key die a) niet betekenisloos en b) aan verandering onderhevig is.

Je kan voor je website beter een aparte id bijhouden.

Ow.. hehe.. dat heb ik net weggehaald Maar je hebt wel gelijk idd, dus verander het weer ff terug

Voor de n-m relaties ben je doorgaans gedwongen een aparte tabel bij te houden, als dan n gelijk is aan 1-n en/of m ook wordt het lastiger, want je kan wel vrij simpel bijhouden dat er 0-n koppelingen zijn, maar niet dat er meer zijn.

Uhm.. mja, dat wil ik juist weten idd

edit:

code:

CREATE TABLE Recencist  ( recencistnr   INTEGER,
              naam      CHAR(30),
              adres     CHAR(70),
              websitenr INTEGER NOT NULL,
              PRIMARY KEY (recencistnr),
              FOREIGN KEY (websitenr)   REFERENCES Website )

CREATE TABLE Website    ( websitenr INTEGER,
              home_url  CHAR(50),
              naam      CHAR(30),
              PRIMARY KEY (websitenr) )

Even die verandering die ACM zegt doorgevoerd in m'n code

[ Voor 25% gewijzigd door Captain N op 03-06-2003 18:33 ]

[robjanssen]

Waarom zet je niet alles in 1 tabel dan.
Als ieder Recensist voor 1 website werkt en bij ieder website hoort 1 recensist
Dat kan dan toch mooi in 1 tabel?

Want in de situatie die je nu hebt kan het nog steeds zo zijn dat je een website hebt, zonder recensist.

[ACM]

ik gok dat ie per website meerdere recensisten wil en per recensist minstens één website wil?

[Captain N]

Nee.. per website 1 of meer recencisten, en per recensist 1 website. Dat is juist het probleem... 1-1 of m:n of 1:m is niet zo'n probleem... maar 1:m waarbij m>=1 is.. uhm.. geen idee hoe dat dan gaat??

Want in de situatie die je nu hebt kan het nog steeds zo zijn dat je een website hebt, zonder recensist.

Jups, dat moet ik dus nog oplossen.. de andere constraints kloppen al wel (volgens mij).

[ Voor 40% gewijzigd door Captain N op 03-06-2003 19:03 ]

[ACM]

Humm, begreep ik je nog verkeerd ook. Maar ik denk dat dat niet echt kan, simpelweg omdat je dan met een kip-ei principe komt te zitten. Om een recensist aan te maken moet er een website zijn en om een website aan te maken moet er een recensist zijn.

Waarom kan een website zonder recensisten niet bestaan?

[Captain N]

Omdat het hier gaat om websites die recensies op hun website hebben staan. Die moet toch iemand maken? En dat wat jij zegt klopt inderdaad. Dit heeft mijn docent ook een keer verteld, en ook een oplossing voor gegeven, die me op het moment niet meer helemaal duidelijk is.. volgens mij iets als tijdelijk even die constraints uitschakelen, een recencist en website aanmaken, en dan die constraint weer aanzetten. Maar nu ik er zo over nadenk... dan zou je dat iedere keer als je een nieuwe website wil toevoegen dus moeten doen. Maar het moet toch wel op een of andere manier mogelijk zijn? Want heb bijvoorbeeld ook nog de volgende relatie: 2 entiteiten: games en systeem... een spel is ontwikkeld voor precies 1 systeem, en voor ieder systeem is er minstens 1 spel... Het lijkt me niet echt iets dat nooit voorkomt? Hoe wordt dit normaalgesproken opgelost dan? Ik ben nu wat aan het bestuderen over assertions, maar kom daar nog niet helemaal uit...

[ACM]

Volgens mij komen deze relatietypes het meest voor:
1-n waarbij n 0 mag zijn
n-1 " "
n-m waarbij zowel n als m 0 mogen zijn.

Dus er is niet perse een recensist bij een website (hoewel je die gelijk erna aan zult maken), of er is niet perse een website bij een recensist.

Of recensisten kunnen bij meerdere websites werken, maar het is niet gegarandeerd _dat_ een recensist bij een website werkt of een website recensisten heeft.

Ook je games-systeem relatie, het lijkt me prima mogelijk dat er systemen zijn waar geen games voor bestaan. In de echte wereld heb je allerlei embeded systemen waar echt geen games voor bestaan hoor

[Captain N]

Mja, maar het gaat in dit geval om Nintendo-systemen Heeft niet zoveel zin om zo'n systeem te maken, en er geen spellen voor uit te brengen

[ACM]

klopt, maar omdat je dat weet heeft het wellicht ook weinig zin moeilijk te doen om dat te garanderen vanuit je database model.

[Captain N]

Mja.. daar heb je een puntje Maar als ik nu bijvoorbeeld een nieuwe website toe voeg, en ook een recensist toevoeg... wat als ik die weghaal? Ik kan niet in de DDL van de Recencist tabel ON DELETE CASCADE toevoegen, want als ik 2 recencisten toevoeg, en er daarna 1 weghaal zou 'ie dan toch ook de entry in de Website tabel weghalen? Of heb ik dit nou verkeerd?

[ACM]

Euh..

de recensist heeft een foreign key naar de website dan, toch?

Als je dan de website verwijderd, worden ook alle recensisten die ernaar verwijzen meeverwijderd (als je de actie CASCADE kiest tenminste). Als je echter een recensist verwijderd wordt niet je website verwijderd hoor

[Captain N]

Ooow.. ok Dan had ik dat even verkeerd begrepen Mja, ben nog nieuw met dit Thanks voor de hulp, ik denk dat ik er dan nu wel uit ben

[Captain N]

Toch nog een vraagje... hoe los je dat sowieso op? Als een entiteit een relatie heeft met minstends 1 andere entiteit?? Dus bijvoorbeeld een m:n relatie waarbij m>=1? Misschien een stomme vraag, maar ik kom er echt even niet uit

Want als je een foreign key in de tabel zet van de m entiteit dan krijg je dubbele entries (waar dan alleen de foreign key anders is), en als je de PK van de m entiteit PK maakt in een tabel die de relatie definieert dan hoeft dat ook niet te betekenen dat alle websites erin voorkomen

[ Voor 40% gewijzigd door Captain N op 03-06-2003 20:14 ]

[Annie]

[rml]ACM in "[ SQL] Vraag over een cardinality constra"[/rml]

koppeltabel dus

[Captain N]

Mja, dat had ik al begrepen.. maar hij zegt ook dat ie even niet weet hoe je dus een 1-n: m relatie daarin verwerkt

[jochemd]

ACM schreef op 03 June 2003 @ 19:05:
Humm, begreep ik je nog verkeerd ook. Maar ik denk dat dat niet echt kan, simpelweg omdat je dan met een kip-ei principe komt te zitten. Om een recensist aan te maken moet er een website zijn en om een website aan te maken moet er een recensist zijn.

Dan moet je de constraint uitstellen
DEFERRED constraints worden pas gecontroleerd op het moment dat de transactie gecommit wordt, niet op het moment dat individuele statements uit de tranactie draaien. Als je dus zowel de website als de recensist in 1 transactie aanmaakt kan het wel.

[Captain N]

Oja.. dat was het! Thanks Ik ga me dan even verdiepen in hoe je DEFERRED gebruikt