[ER/SQL] Probleem met omzetten ER diagram -> relaties

[Verwijderd]

Hoi!

Ik heb een probleempje met het omzetten van een ER schema naar entiteiten (voor in de database). Stel je hebt volgend ER schema:



Volgens mij boek (*) is dit niets bijzonders, en moet ik het als volgt doen:
    1. turn each entity set into a relation with the same set of attributes
    2. replace a relationship by a relation whose attributes are the keys of the connected entity sets

Oké, dat geeft dus volgende relaties:

A(age (PK), dad)
B(geg (PK), agb)
C(xyz (PK), abc) (ben xyz vergeten te onderstrepen!)
Relatie1(age, xyz)
Relatie2(geg, xyz)

Maar zelf, zonder de regel uit mijn boek, zou ik het zo gedaan hebben:

A(age (PK), dad)
B(geg (PK), agb)
C(xyz (PK), abc)
Relatie(key, xyz, type), waarbij key de primary key is uit de relaties A of B en type een enum is, met waarden: 'A', 'B'

Nu weet ik niet tussen welk van de 2 oplossingen ik moet kiezen. De entities A en B hebben dus totaal niets met elkaar te maken. Het probleem is dat ik in mijn model 6 entities heb die niets met elkaar te maken, en dezelfde entity C die in relatie staat met al die 6 entities. Bij de eerste oplossing krijg je dan 6+6+1 verschillende tabellen, terwijl je bij de tweede oplossing 6+1+1 tabellen krijgt. Heeft iemand ervaring met deze situatie? Zelf lijkt mij de eerste oplossing efficiënter (je moet niet steeds het veld 'type' vastleggen in de WHERE clause van je queries), maar minder zuinig met geheugen en oplossing 2 geeft ook een beter overzicht van je database model, omdat je daar maar 1 tabel hebt, die in principe al 'identieke' relaties omvat.

Realistisch voorbeeld: stel bijvoorbeeld op tweakers.net: A = nieuwspost, B = user profile en C = comment. Nieuwsposten en user profiles hebben dus niets met elkaar te maken, en je kan zowel een comment posten op een nieuwspost, als op een user profile.

(*) boek: database systems - the complete book van Hector Garcia-Molina, Jeffrey D. Ullman en Jennifer Widom

[ Voor 26% gewijzigd door Verwijderd op 25-08-2003 17:20 ]

[EfBe]

Relaties zijn zaken die je in Data Definition Language vastlegt, dus met lege tabellen zijn de relaties toch gedefinieerd.

ER model heeft als leuke eigenschap dat je het 1:1 kunt afbeelden op tables, dus je 1e voorbeeld is dan ook de juiste.

Doordat je dat doet is er een m:n relatie ontstaan tussen A en B over C (leuke bijkomstigheid). Het is wel zo dat uit je plaatje niet blijkt of xyz, geg en age hetzelfde voorstellen. dat moet nu eenmaal wil je een relatie kunnen leggen tussen 2 attributes.

[Verwijderd]

EfBe schreef op 25 August 2003 @ 17:34:
Relaties zijn zaken die je in Data Definition Language vastlegt, dus met lege tabellen zijn de relaties toch gedefinieerd.

Hiermee snap ik niet goed wat je wil zeggen? Heb ik ergens lege tabellen?

ER model heeft als leuke eigenschap dat je het 1:1 kunt afbeelden op tables, dus je 1e voorbeeld is dan ook de juiste.

Ja, dat je rechtstreeks van ER -> tables kan, is een leuke eigenschap, maar het is niet altijd de beste oplossing. En ik vraag me af of in deze situatie er betere oplossingen zijn: misschien die ene die ik gegeven heb, misschien andere?

Doordat je dat doet is er een m:n relatie ontstaan tussen A en B over C (leuke bijkomstigheid).

Die is er toch altijd al geweest? Dus ook in het gewone ER schema?

Het is wel zo dat uit je plaatje niet blijkt of xyz, geg en age hetzelfde voorstellen. dat moet nu eenmaal wil je een relatie kunnen leggen tussen 2 attributes.

Dat snap ik niet! Waarom moeten die hetzelfde voorstellen? Uit het tweakers.net voorbeeld is dan 'age' = 'news_id', 'geg' = 'user_id' en xyz = 'comment_id'. Wat bedoel jij met 'ze moeten hetzelfde zijn'? En een relatie leg je toch nooit tussen attributen?

Bedankt voor je hulp!

EDIT: Ik heb even het tweakers.net voorbeeld uitgewerkt. Dit is misschien veel duidelijker

[ Voor 18% gewijzigd door Verwijderd op 25-08-2003 18:25 ]

[EfBe]

En een relatie leg je toch nooit tussen attributen?

Hmm, where to start? Ik wil niet het boek wat je aan het lezen bent hier neerpoten, maar relaties zijn JUIST tussen attributen gelegd, of combinaties van attributen. Omdat die attributen een 1:1 relatie hebben met een entity zijn de entities behorend bij die attributen weer gerelateerd volgens de relatie tussen de attributen die een relatie hebben.

Als twee attributen een relatie hebben, dan moeten ze hetzelfde voorstellen. Een veld UserID kan niet een relatie hebben met een veld PostingID in een andere tabel. Wil je een relatie leggen tussen twee attributes (en daarmee dus tussen twee entities/tables) dan zullen ze beide hetzelfde moeten voorstellen, bv userid. De een is dan de primary key van een tabel en de andere is een normaal veld of onderdeel van of compleet de primary key van een andere tabel.

In je plaatje hierboven kan user alleen een relatie met comment hebben als comment ook een veld userid bevat. Die heeft ie niet, dus bestaat relatie2 niet. Comment heeft echter wel een userid nodig, want het is gepost door een user. door die userid als non-primary key veld bij comment op te slaan kun je een relatie leggen tussen comment en user over comment.userid (FK field) - user.userid (PK field).

Dit is hopelijk aan bod gekomen in je boek, anders zou ik een ander boek kopen.

[Creepy]

Je zgt in je voorbeeld dat je een comment kan posten op een nieuws item, als op een userprofile. Maar is dit wel zo? Is het niet zo dat een user een comment maakt op een nieuwsitem? Als dit zo is zijn er dus echt twee relaties en zul je de PK van User en de PK van nieuws moeten opnemen in de comment tabel om zo de juiste relaties te kunnen leggen (dus echt 2 relaties)

Als het een comment is over een nieuws item of over een user dan kan het id in comment nooit het id uit user of uit nieuws bevatten aangezien deze niet uniek is. De combinatie van id en type (zoals jij in je relatie aangeeft) is dan uniek en is dan ook de PK.

Edit: efbe is me te snel af

[ Voor 3% gewijzigd door Creepy op 25-08-2003 18:38 ]

[Verwijderd]

Ja, natuurlijk, als je het zo bekijkt heb je altijd relaties tussen attributen, akkoord

In feite zeg jij gewoon meer wat ik zeg:

Jij zegt: "je hebt relaties tussen 'tabellen', en die relaties worden bepaald/vastgelegd door de overeenkomstige attributen (primary en foreign keys)"
Ik zeg: "je hebt relaties tussen 'tabellen'"

Het is ook daarom dat je de Relatie2 moet vertalen in een aparte tabel (mede ook de m:n eigenschap ervan), om (zoals jij zegt) 'de overeenkomstige attributen te hebben'. Zowel Relatie2 als Comment hebben een attribuut 'commentid' en zowel Relatie2 als User hebben een attribuut 'userid'.

Comment heeft echter wel een userid nodig, want het is gepost door een user.

Dat is volgens mij fout? De relatie geldt omdat je nu eenmaal een comment kan geven op een user-profile, niet omwille het feit dat een comment door een user gepost kan worden. De relatie wordt onderhouden door het ruitje 'Relatie2', en niet door het (eventuele) veld 'userid' in 'Comment'. Die 'userid' wordt in 'Relatie2' automatisch verondersteld! Vandaar dat je bij de vertaling van een relatie (de ruit) naar een tabel, de keys moet meenemen, samen met de eventuele eigen attributen die op de relatie gelden (die er in dit geval niet zijn).

Of volg ik je nog altijd niet?

[Verwijderd]

Ik zie het probleem al

Een comment OP een user profile wordt gepost DOOR een user. In principe heb je dus 2 relaties tussen User en Comment, namelijk:

- een relatie die aanduidt wie de comment post (dit bedoel ik niet!)
- een relatie die aanduidt op welke user (profile) de comment gepost is (dit bedoel ik!)

EDIT: Ik zal het anders helemaal uitwerken (dus ook de relatie 'comment geschreven door' en 'nieuws geschreven door'), dan is het misschien duidelijker, en dan kan ik dan de vraag beter opnieuw stellen.

[ Voor 151% gewijzigd door Verwijderd op 25-08-2003 19:23 ]

[EfBe]

Een comment OP een user profile wordt gepost DOOR een user. In principe heb je dus 2 relaties tussen User en Comment, namelijk:

- een relatie die aanduidt wie de comment post (dit bedoel ik niet!)
- een relatie die aanduidt op welke user (profile) de comment gepost is (dit bedoel ik!)

krek

En geen van die relaties is terug te vinden in je plaatje.

[Creepy]

Een comment OP een user word ook DOOR een user gedaan

Ikzelf zou de comment op een nieuws artikel in een andere tabel doen dan de comments opeen user acount. Ze kunnen inderdaad wel samen, maar dan zul je een type veld moeten opnemen in de comments tabel

[ Voor 65% gewijzigd door Creepy op 25-08-2003 19:06 ]

[Verwijderd]

OK, we beginnen opnieuw



Bij het vertalen volgens de 'standaardregels' (zie eerste post), krijg ik het volgende:

· nieuws (id, titel, userid)
· user(id, voornaam)
· commentOpNieuws(id, tekst, nieuwsid, useridAuteur)
· commentOpUser(id, tekst, userid, useridAuteur)

Dit lijkt mij juist? (de 1:m relaties heb ik al samengevoegd met de tabellen waarnaar ze wijzen)

Nu is mijn vraag: wat als je commentaar kan geven op heel veel dingen? (nieuws, users, artikelen, ...). In mijn opzet is er een vergelijkbare situatie, waar op 6 verschillende zaken commentaar kan gegeven worden. Dan krijg je ook 6 'commentaar tabellen':

· commentOpNieuws(id, tekst, nieuwsid, useridAuteur)
· commentOpUser(id, tekst, userid, useridAuteur)
· commentOpBla1(id, tekst, blaid, useridAuteur)
· commentOpBla2(id, tekst, bla2id, useridAuteur)
· commentOpBla3(id, tekst, bla3id, useridAuteur)
· commentOpBla4(id, tekst, bla4id, useridAuteur)

Eigenlijk zijn al die tabellen allemaal hetzelfde, behalve is de foreign key steeds verschillend. Nu dacht ik, als een alternatieve oplossing de volgende tabel te maken, ipv. de 6 bovenstaande tabel:

· comment(id, tekst, foreignid, useridAuteur, type), met typ een enum ('NIEUWS', 'USER', 'BLA1', 'BLA2', 'BLA3', 'BLA4')

Beide oplossingen zijn evenwaardig (je kan er evenveel mee). Maar nu vroeg ik mij af wat de beste oplossing is? Of is het gewoon een keuze maken, gebaseerd op wat je met je data (in dit geval de comments) wilt doen.

Ik hoop dat ik het nu wel verstaanbaar gemaakt heb (vorige ER schemas waren idd. onvolledig)

Creepy schreef op 25 August 2003 @ 19:05:
Een comment OP een user word ook DOOR een user gedaan

Ikzelf zou de comment op een nieuws artikel in een andere tabel doen dan de comments opeen user acount. Ze kunnen inderdaad wel samen, maar dan zul je een type veld moeten opnemen in de comments tabel

Ah, je snapte het al, doh!

Maar waarom zou jij 2 (en dus ook 6?) aparte tabellen maken, en niet 1 tabel met de enum veld?

[ Voor 23% gewijzigd door Verwijderd op 25-08-2003 19:44 ]

[EfBe]

ik zie maar 4 tabellen: news, user, comment opnews en commentopuser

[Creepy]

Verwijderd schreef op 25 August 2003 @ 19:23:
[...]
Ah, je snapte het al, doh!

Maar waarom zou jij 2 (en dus ook 6?) aparte tabellen maken, en niet 1 tabel met de enum veld?

Omdat het mij lijkt dat comments bij het nieuws veel vaker opgevraagd zullen worden, en er ook veel meer zullen zijn en je dus niet met een extra type veld hoeft te selecteren, en dus ook geen secundaire index hoeft te maken op id en type, maar gewoon de PK op id kunt gebruiken. Maar dat is mijn voorkeur dus

Als je nog meer andere soorten comments hebt dan zou ik ook voor 1 tabel gaan met een type veld erin om vervuiling van allemaal min of meer dezelfde tabellen te voorkomen.

[Verwijderd]

EfBe schreef op 25 augustus 2003 @ 20:15:
ik zie maar 4 tabellen: news, user, comment opnews en commentopuser

Op de ER tekening staan er maar 2, maar ik heb er 6. De tekening diende alleen om de situatie te schetsen.

Creepy schreef op 25 August 2003 @ 20:20:
[...]



[...]

Omdat het mij lijkt dat comments bij het nieuws veel vaker opgevraagd zullen worden, en er ook veel meer zullen zijn en je dus niet met een extra type veld hoeft te selecteren, en dus ook geen secundaire index hoeft te maken op id en type, maar gewoon de PK op id kunt gebruiken. Maar dat is mijn voorkeur dus

Als je nog meer andere soorten comments hebt dan zou ik ook voor 1 tabel gaan met een type veld erin om vervuiling van allemaal min of meer dezelfde tabellen te voorkomen.

Er is dus geen beste oplossing zo te zien Over die indices heb je gelijk, met 1 tabel heb je een dubbele index nodig + het opvragen duurt langer (ondanks de index).

Ik zie nog een ander probleem: stel dat de primary key van nieuws (nieuws_id) van het type smallint is, en de primary key van user (user_id) van het type bigint is, welk type kies je dan voor 'foreignid' in de comment-tabel? Ook al kies je bigint, op een gegeven moment (in theorie dan) ga je nog plaats hebben voor extra users, maar heb je misschien geen plaats meer voor een comment op die user te plaatsen, omdat je voorbij de grenzen van de bigint van foreignid in de comment-tabel zit (er zijn waarden verspild aan comments op nieuws, artikelen, ...).

[ Voor 74% gewijzigd door Verwijderd op 25-08-2003 23:03 ]