[db-ontwerp / MySQL] N op N relaties

[drm]

Voor de db-ontwerpers onder ons:

Ik heb 2 tabellen, en tussen die tabellen bestaat een N op N relatie:

code:

tabel Bedrijf
+-----------+-------------+----------+
| bedrijfID | bedrijfNaam | etcetera |
+-----------+-------------+----------+
bedrijfID: Primary Key

tabel Soort
+---------+-----------+
| soortID | soortNaam |
+---------+-----------+
soortID: Primary Key

Nu kan een bedrijf zowel een verhuur- als een verkoopbedrijf zijn. Maar er zijn natuurlijk meerdere bedrijven die er zo over denken N:N relatie dus.

Nu kun je de koppeling leggen door op de volgende manier te werk te gaan:

code:

tabel koppBedrijfSoort(ofzo)
+-----------+---------+
| bedrijfID | soortID |
+-----------+---------+
| 0    | 0   |
| 0    | 1   |
| 1    | 4   |
| 1    | 5   |
+-----------+---------+
etcetera

en ik doop hem koppelingstabel.

Is dit nou de oplossing of zijn er betere manieren om zo'n relatie vast te leggen? Je vraagt je vast af waarom ik dit vraag, maar ik ben eerlijk gezegd op zoek naar goeie tips. (wordt een behoorlijk databaseje namelijk, en dan kan ik hem maar beter goed opgezet hebben )

En nog tips over consequente naamgevingen in zulke koppelingstabellen?

For what it's worth, ik gebruik MySQL

[Arnim]

Ik doe het ook altijd op deze manier. Dan weet je in ieder geval dat je alles kunt opslaan wat je wil.

Zet nog wel een extra ID-veld in je koppeltabel.

[JapJap]

Dit is inderdaad de standaardmanier om een N op N relatie te maken. Een extra ID in de koppeltabel is trouwens niet nodig .

[drm]

Op woensdag 12 september 2001 11:37 schreef JapJap het volgende:
Dit is inderdaad de standaardmanier om een N op N relatie te maken. Een extra ID in de koppeltabel is trouwens niet nodig .

extra ID zou ik wel doen (is toch altijd handig voor onderhoud), maar idd niet nodig.

Ok, thanks.

Hoe doen jullie dat met naamgeving?

[Verwijderd]

Op woensdag 12 september 2001 10:38 schreef drm het volgende:
Voor de db-ontwerpers onder ons:

Ik ben wel geen db-ontwerper, maar voor zover ik weet is de door jou aangegeven methode de algemeen gebruikte methode. DIe bovendien aardig efficient is. Voor de naamgeving van de tabellen cq. kolommen ben je natuurlijk helemaal vrij om te kiezen wat je wil, een aantal tips:
1. Kies namen die geen zgn. "reserved words" zijn in (my)SQL
2. Kies namen die duidelijk zijn (op zijn minst voor jezelf)
3. Wees consequent in je naamgeving.

[Arnim]

Ik zou mijn tabllen als volgt noemen:
tCompany
tType
tCompanyType

Ik gebruik altijd de Engelse benamingen voor entiteiten en attributen. Code is immers ook in het Engels.
Verder zet ik voor tabelnamen de letter t (van table ). Voor koppeltabellen plak ik altijd de twee namen achter elkaar. Is gewoon iets wat ik me aangewend heb.

[drm]

mentat:
Ik ben wel geen db-ontwerper, maar voor zover ik weet is de door jou aangegeven methode de algemeen gebruikte methode.

Leek mij ook het meest logisch, maar ik wist niet of er ondertussen al nieuwe technieken voor bedacht waren. Who knows

DIe bovendien aardig efficient is. Voor de naamgeving van de tabellen cq. kolommen ben je natuurlijk helemaal vrij om te kiezen wat je wil, een aantal tips:
1. Kies namen die geen zgn. "reserved words" zijn in (my)SQL
2. Kies namen die duidelijk zijn (op zijn minst voor jezelf)
3. Wees consequent in je naamgeving.

3 open deuren.
thnx neway

Arnim:[/b]
Ik zou mijn tabllen als volgt noemen:
tCompany
tType
tCompanyType

Ik gebruik altijd de Engelse benamingen voor entiteiten en attributen. Code is immers ook in het Engels.

Mwahhh. De output naar de user weer in het nederlands. Wel een overweging waar, iig.

Verder zet ik voor tabelnamen de letter t (van table ).

Lijkt mij weer een beetje overdone, magoed

Voor koppeltabellen plak ik altijd de twee namen achter elkaar. Is gewoon iets wat ik me aangewend heb.

Dat dacht ik zelf ook al, ja. Maar dan zit ik met het volgende:
er komen in diezelfde database ook Typen te staan van Objecten. Ook daar bestaat weer een N:N relatie.
Nu moet er dus onderscheid gemaakt worden tussen object type en companytype:
tObjectType
tObject
tType
tCompany
tCompanyType
tType <--- tja, beeeeetje ambigu is dat wel

hoe zou je dat oplossen?

[dusty]

Op woensdag 12 september 2001 10:38 schreef drm het volgende:
Nu kan een bedrijf zowel een verhuur- als een verkoopbedrijf zijn. Maar er zijn natuurlijk meerdere bedrijven die er zo over denken N:N relatie dus.

Dus NIET N:N relatie.. aangezien een bedrijf MEER soorten kan zijn. het is een N:M relatie. (een bedrijf kan meerdere soorten zijn.. en er kunnen ook meerdere bedrijven onder een soort.

daarvanaf gezien is het inderdaad een standaard manier. iets wat je normaal al leert bij database design iets met parts, suppliers tabelletjes wat in 80% van de leerboeken wordt gebruikt. (DATE!)

Het wordt pas leuk als je alle andere informatie aan je database gaat toevoegen.

[Killemov]

Als het alleen gaat over de eigenschappen van een bedrijf dat en/of verkoopt en/of verhuurt, dan is dit nogal overkill en zou ik twee booleans opnemen bij elk bedrijf. (nl. 'verkoopt' en 'verhuurt') Als er nu echt behoorlijk wat soorten zijn, dan moet je natuurlijk wel aan de N:M relaties. Ik zou zelf de grens leggen op meer dan 4 van dit soort vlaggen, voordat ik toch aan een andere tabel zou denken.

Soms kun je ook te ver gaan met normaliseren ...

[drm]

Op woensdag 12 september 2001 12:38 schreef dusty het volgende:

[..]

Dus NIET N:N relatie.. aangezien een bedrijf MEER soorten kan zijn. het is een N:M relatie. (een bedrijf kan meerdere soorten zijn.. en er kunnen ook meerdere bedrijven onder een soort.

daarvanaf gezien is het inderdaad een standaard manier. iets wat je normaal al leert bij database design iets met parts, suppliers tabelletjes wat in 80% van de leerboeken wordt gebruikt. (DATE!)

Het wordt pas leuk als je alle andere informatie aan je database gaat toevoegen.

pfff. Excuse me for not being educated
gaat het.

[drm]

Op woensdag 12 september 2001 12:50 schreef Killemov het volgende:
Als het alleen gaat over de eigenschappen van een bedrijf dat en/of verkoopt en/of verhuurt, dan is dit nogal overkill en zou ik twee booleans opnemen bij elk bedrijf. (nl. 'verkoopt' en 'verhuurt') Als er nu echt behoorlijk wat soorten zijn, dan moet je natuurlijk wel aan de N:M relaties. Ik zou zelf de grens leggen op meer dan 4 van dit soort vlaggen, voordat ik toch aan een andere tabel zou denken.

Soms kun je ook te ver gaan met normaliseren ...

Je moet denken aan ca. 16 soorten bedrijven

[Janoz]

Zet daarnaast een key op beide velden (Voor efficientie) en maak beiden velden samen de primary key (<-Ja MyPhpAdmin gebruikers.. Je kunt ook van meerdere velden samen een primaire sleutel maken)

ID is absoluut overbodig. Alle rijen zijn uniek identificeerbaar (tenzij je een koppeling perongeluk dubbel erin gezet hebt, maar als beide velden samen de primaire sleutel is, is dat niet mogelijk)

[Arnim]

Zoals ik al zei: naamgeving in het Engels en tabelnamen beginnen met een t is een keuze die ik een tijd geleden gemaakt heb. Ik ben er inmiddels aan gewend geraakt. Verder kort ik namelijk ook attributen af op dezelfde manier, zodat ik weet wanneer een attribuut bv. een integer of een char is.
Wellicht ten overvloede: zorg er in elk geval voor dat je een standaard notatie ontwikkelt. Dat voorkomt fouten.

Met twee tabellen die je type wil noemen heb je inderdaad een probleem. Dan moet je inderdaad slimmer worden...

[Flauwe modus]
tCompany // Gegevens over bedrijf
tCompanyType // Gegevens over mogelijke typen bedrijven
tCompanyTypeCompany // koppeltabel

tObject // Gegevens over object
tObjectType // Gegevens over mogelijke typen objecten
tObjectTypeObject // koppeltabel
[/Flauwe modus]

Oftewel om het duidelijk te houden moet je twee namen verzinnen voor de verschillende entiteiten met typen.

[drm]

Arnim:
Zoals ik al zei: naamgeving in het Engels en tabelnamen beginnen met een t is een keuze die ik een tijd geleden gemaakt heb. Ik ben er inmiddels aan gewend geraakt. Verder ...

Dat was al wel duidelijk, hoor

... kort ik namelijk ook attributen af op dezelfde manier, zodat ik weet wanneer een attribuut bv. een integer of een char is.
Wellicht ten overvloede: zorg er in elk geval voor dat je een standaard notatie ontwikkelt. Dat voorkomt fouten.

jup. ten overvloede

Met twee tabellen die je type wil noemen heb je inderdaad een probleem. Dan moet je inderdaad slimmer worden...

[Flauwe modus]
tCompany // Gegevens over bedrijf
tCompanyType // Gegevens over mogelijke typen bedrijven
tCompanyTypeCompany // koppeltabel

tObject // Gegevens over object
tObjectType // Gegevens over mogelijke typen objecten
tObjectTypeObject // koppeltabel
[/Flauwe modus]

Oftewel om het duidelijk te houden moet je twee namen verzinnen voor de verschillende entiteiten met typen.

dit vind ik dus echt schrale boel:
tCompanyTypeCompany

Ik had zelf iets in gedachten van:

Object
Type
ObjectType_k
ofzo, dan kan je aan de _k altijd zien dat het een koppeltabel is.

Op woensdag 12 september 2001 13:34 schreef Janoz het volgende:
Zet daarnaast een key op beide velden (Voor efficientie) en maak beiden velden samen de primary key (<-Ja MyPhpAdmin gebruikers.. Je kunt ook van meerdere velden samen een primaire sleutel maken)

ID is absoluut overbodig. Alle rijen zijn uniek identificeerbaar (tenzij je een koppeling perongeluk dubbel erin gezet hebt, maar als beide velden samen de primaire sleutel is, is dat niet mogelijk)

Dat is nou een goeie tip. Dat wist ik dus niet.

[Arnim]

Ik had zelf iets in gedachten van:

Object
Type
ObjectType_k
ofzo, dan kan je aan de _k altijd zien dat het een koppeltabel is.

Dan heb je toch nog steeds twee tabellen met de naam Type?

Tenzij je data over twee entiteiten in één tabel wil zetten, zal je voor de tweede entiteit toch een nieuwe naam moeten verzinnen.

[drm]

ik zal even volledig zijn:

ObjectType
Object
ObjectType_k

CompanyType
Company
CompanyType_k

dat bedoelde ik eigenlijk.

mwja als ik het zo zie ben ik er ook niet dol van...
iemand anders nog goeie ideeen?

[Scare360]

N op N MAG NOOIT VOORKOMEN... een koppelentiteit ertussen en probleem opgelost... = trouwens de basis van datamoddeling...zo'n beetje het eerste wat je leert...


Als je eerst een bachman schema maakt heb je die problemen meteen overzichtelijk weergegeven

[drm]

Op woensdag 12 september 2001 14:47 schreef paulgielens het volgende:
N op N MAG NOOIT VOORKOMEN... een koppelentiteit ertussen en probleem opgelost... = trouwens de basis van datamoddeling...zo'n beetje het eerste wat je leert...

Beetje lullig als je het jezelf aanleert

[Scare360]

[dusty]

Op woensdag 12 september 2001 14:47 schreef paulgielens het volgende:
N op N MAG NOOIT VOORKOMEN...[....]

Zeg nooit nooit. Voordat je het weet zegt een Dusty dat er uitzonderingen zijn waarbij het wel slim is om N op N te hebben.

[drm]

Op woensdag 12 september 2001 14:58 schreef paulgielens het volgende:

tja zo kom je wel aan je HK-posts

chill man, ik bedoelde het niet lomp.

[Scare360]

Oke sorry nooit bedoeld om te flamen ofzo... N op N relaties daar krijgen wij ICT'ers het erg benauwd van... een N op N relatie wordt weggewerkt door een koppel entiteit. Een Bachman diagram... is niets meer of minder dan een schematische weergeving van het datamodel. Zoek eens in google ofzo... is misschien wel interessant voor je om hier wat meer informatie over te hebben...voordat je stevig met databases aan ge gang gaat... Het is allemaal geen pittige stof...dus als je een paar uurtjes uit trekt... heb je erg veel kennis opgedaan mbt datamoddeling en is dit probleem een peuleschil geworden.

Succes

[drm]

Hmm, zal er eens naar kijken. Heb 2 jr. HIO gedaan maar op een of andere manier konden de lessen informatiesystemen en databases ed. niet zo boeien. Had ik nou maar beter opgelet :-)

nehow, ik heb er nog een boek over liggen. Staat eea in over OO, Semantische Objecten, Bachmann, DFD's etc. Beetje droge stof, maar ik zal eens kijken.

thnx for the tip

[Pelle]

Op woensdag 12 september 2001 22:59 schreef drm het volgende:
Hmm, zal er eens naar kijken. Heb 2 jr. HIO gedaan maar op een of andere manier konden de lessen informatiesystemen en databases ed. niet zo boeien. Had ik nou maar beter opgelet :-)

nehow, ik heb er nog een boek over liggen. Staat eea in over OO, Semantische Objecten, Bachmann, DFD's etc. Beetje droge stof, maar ik zal eens kijken.

* Pelle heeft anders nog wel een hele stapel boeken liggen voor drm over (met name) ERD's en normalisatie van databases

Best droge stof, maar ook best interessant. Kom anders ook gewoon deeltijd doen joh, is gezellig

[Pelle]

Op woensdag 12 september 2001 12:38 schreef dusty het volgende:
Het wordt pas leuk als je alle andere informatie aan je database gaat toevoegen.

Hoe bedoel je? Toevoegen is nooit zo'n probleem lijkt me; editen kan lastiger worden omdat elke mutatie op een combinatie van bedrijfsnaam-soortnaam automagisch minimaal een delete en een insert met zich meebrengt (en geen update) in die tussentabel, en als het tegen zit zijn dat er dus veel meer.