[DB] ontwerp db model voor voetbalpool systeem

[Verwijderd]

Ik ben begonnen met het bouwen van een systeem waarmee een voetbal poule georganiseerd kan worden. Ik heb nu de volgende tabellen (in deze post heb ik alles even zo simpel mogelijk gehouden):
- Team
- Player
- Match
- TeamInMatch

De eerste drie tabellen spreken voor zich. Ik heb bewust gekozen voor een extra koppeltabel TeamInMatch in plaats van twee kolommen in de tabel Match. Dit lijkt mij netter en praktischer bij het ophalen van daaraan gerelateerde gegevens.

Nu wil ik ook kunnen registreren welke spelers er mee hebben gedaan in een wedstrijd. Ik wil namelijk als onderdeel van het spel maken dat de gebruikers kunnen voorspellen wie de topscoorder wordt of wie de meeste kaarten haalt.

Ik zou dan een tabel PlayerInMatch willen introduceren welke een relatie heeft met de tabel TeamInMatch en de tabel Player. Maar dit is volgens mij niet helemaal een nette oplosssing. Ik heb in Word even een lelijke weergave gemaat om dit duidelijk te maken

Iets zegt mij dat met het gebruik van deze relaties er redundantie ontstaat doordat PlayerInMatch zoewel een relatie heeft met TeamInMatch als met Player.

Zie iemand mij kunnen vertellen wat ik nu fout doe en waarom dit fout is en hoe ik het kan verhelpen?

[Voutloos]

Aan een match doen toch altijd exact 2 teams mee? Waarom dan niet gewoon een thuis en uit team id kolom in match?

Iets zegt mij dat met het gebruik van deze relaties er redundantie ontstaat doordat PlayerInMatch zowel een relatie heeft met TeamInMatch als met Player.

Adhv van de player id kan je het team al weten, maar nog niet de wedstrijd.

PlayerInMatch (oid) kan vooral handig zijn als je db zolang gebruikt dat er spelers van team wisselen. Als het echter puur om een EK/WK poule gaat en enkel de topscorer stats over het totale kampioenschap boeien, kan je db een stuk eenvoudiger.

offtopic:
@hieronder: je kan ook knippen in quotes.

[ Voor 4% gewijzigd door Voutloos op 08-04-2008 08:10 ]

[Webgnome]

Verwijderd schreef op maandag 07 april 2008 @ 23:10:
Ik ben begonnen met het bouwen van een systeem waarmee een voetbal poule georganiseerd kan worden. Ik heb nu de volgende tabellen (in deze post heb ik alles even zo simpel mogelijk gehouden):
- Team
- Player
- Match
- TeamInMatch

De eerste drie tabellen spreken voor zich. Ik heb bewust gekozen voor een extra koppeltabel TeamInMatch in plaats van twee kolommen in de tabel Match. Dit lijkt mij netter en praktischer bij het ophalen van daaraan gerelateerde gegevens.

Nu wil ik ook kunnen registreren welke spelers er mee hebben gedaan in een wedstrijd. Ik wil namelijk als onderdeel van het spel maken dat de gebruikers kunnen voorspellen wie de topscoorder wordt of wie de meeste kaarten haalt.

Ik zou dan een tabel PlayerInMatch willen introduceren welke een relatie heeft met de tabel TeamInMatch en de tabel Player. Maar dit is volgens mij niet helemaal een nette oplosssing. Ik heb in Word even een lelijke weergave gemaat om dit duidelijk te maken

Iets zegt mij dat met het gebruik van deze relaties er redundantie ontstaat doordat PlayerInMatch zoewel een relatie heeft met TeamInMatch als met Player.

Zie iemand mij kunnen vertellen wat ik nu fout doe en waarom dit fout is en hoe ik het kan verhelpen?

[afbeelding]

Zoals ook al is aangegeven. TeamInMatch is overbodig aangezien er per match maar 2 teams kunnen zijn (of bestaat er ook zoiets als voetbal met 3 teams ) en je kunt die gegevens dus netjes in de match tabel zetten.

[Verwijderd]

Voutloos schreef op dinsdag 08 april 2008 @ 07:59:
Aan een match doen toch altijd exact 2 teams mee? Waarom dan niet gewoon een thuis en uit team id kolom in match?


[...]
Adhv van de player id kan je het team al weten, maar nog niet de wedstrijd.

PlayerInMatch (oid) kan vooral handig zijn als je db zolang gebruikt dat er spelers van team wisselen. Als het echter puur om een EK/WK poule gaat en enkel de topscorer stats over het totale kampioenschap boeien, kan je db een stuk eenvoudiger.

In eerste instantie had ik ook gewoon de twee teams in dezelfde tabel waarbij voor het thuis spelende team en voor het andere team een kolom is gereserveerd. Wanneer ik nu gegevens als de spelers die een doelpunt hebben gemaakt of een kaart hebben gehaald dan zal ik dat moeten vastleggen per wedstrijd. Dit betekent dus ook dubbele referentiele constraints naar de tabel match omdat er twee kolommen bestaan. Querien is ook een stuk eenvoudiger. Misschien dat het nu wat duidelijker is.

Uiteindelijk wil ik allerlei verschillende manieren om punten te kunnen halen implementeren zoals welke speler het meest is opgesteld daarom de PlayerInMatch tabel. Het db model moet een EK overleven en dus ook voor andere competies bruikbaar zijn.

Ik begriojp dat ik aan de hand van de Player het Team weet maar niet de wedstrijd maar er staat me iets bij dat je moet voorkomen in je model dat er soort van cirel ontstaat (zie afbeelding: je kunt van Player naar Team, van Team naar TeamInMatch en van TeamInMatch naar PlayerInMatch en weer terug. Dit is toch redundant of doe ik verkeerde aanname en is het helemaal niet fout?

[Webgnome]

Verwijderd schreef op dinsdag 08 april 2008 @ 09:51:
[...]


In eerste instantie had ik ook gewoon de twee teams in dezelfde tabel waarbij voor het thuis spelende team en voor het andere team een kolom is gereserveerd. Wanneer ik nu gegevens als de spelers die een doelpunt hebben gemaakt of een kaart hebben gehaald dan zal ik dat moeten vastleggen per wedstrijd. Dit betekent dus ook dubbele referentiele constraints naar de tabel match omdat er twee kolommen bestaan. Querien is ook een stuk eenvoudiger. Misschien dat het nu wat duidelijker is.

Uiteindelijk wil ik allerlei verschillende manieren om punten te kunnen halen implementeren zoals welke speler het meest is opgesteld daarom de PlayerInMatch tabel. Het db model moet een EK overleven en dus ook voor andere competies bruikbaar zijn.

Ik begriojp dat ik aan de hand van de Player het Team weet maar niet de wedstrijd maar er staat me iets bij dat je moet voorkomen in je model dat er soort van cirel ontstaat (zie afbeelding: je kunt van Player naar Team, van Team naar TeamInMatch en van TeamInMatch naar PlayerInMatch en weer terug. Dit is toch redundant of doe ik verkeerde aanname en is het helemaal niet fout?

De playermatch tabel is dan ook niks mis mee naar mijn mening. Ik denk dat je hem beter kunt hernoemen naar wat de lading dekt . als je er alleen maar een playerid en een wedstrijd id in gaat zetten dan kun je een aparte tabel maken waarin je de overtredingen bij gaat houden.

[mithras]

Op zich is dit systeem toch niet heel erg moeilijk? Je maakt een tabel voor elke entity: player, team, poule, match. Je kan er ook nog een overtreding of doelpunt tabel bijstoppen.
Verder heb je een koppeltabel nodig voor elke many:many relatie in je model. Als je uit je relaties bent, heb je dit db systeem zo opgezet

[Verwijderd]

Verwijderd schreef op dinsdag 08 april 2008 @ 09:51:
[...]

Ik begriojp dat ik aan de hand van de Player het Team weet maar niet de wedstrijd maar er staat me iets bij dat je moet voorkomen in je model dat er soort van cirel ontstaat (zie afbeelding: je kunt van Player naar Team, van Team naar TeamInMatch en van TeamInMatch naar PlayerInMatch en weer terug. Dit is toch redundant of doe ik verkeerde aanname en is het helemaal niet fout?

Het gaat me dus hier om waar ik even hulp bij nodig heb..

[Verwijderd]

Ik waardeer de krtieke op de rest van het ontwerp maar ben nog steeds zoekende naar een antwoord op mijn eigenlijk vraag

[Voutloos]

Het is niet volledig redundant, want PlayerInMatch bedoel je toch als historisch gegeven? Als een player later van team moet kunnen wisselen heb je geen cirkel.

Indien PlayerInMatch geen historisch gegeven is, heb je die hele tabel niet nodig.

[Verwijderd]

Een team wordt in het veld gestuurd met 11 spelers maar op de bank zitten ook spelers die mee willen doen. De selectie van spelers is dus groter dan 11. Ik wil uiteindelijk meer manieren introduceren waarop deelnemers punten kunnen halen. Bijvoorbeeld ook voor of een speler van een team is opgesteld / ingevallen voor een wedstrijd. Deze tabel is dus niet bedoeld voor historie tabel voor spelers die van team wisselen/transferen. Is het wat duidelijker zo?

[Voutloos]

Dat was mij ook al duidelijk. Met player in match log je dus gewoon player, team, match, begintijd, eindtijd, aantal geel, aantal rood, aantal meters, aantal keer bal hooggehouden, aantal keer geroggeld, etc...
Dergelijke rows pas je na de wedstrijd nooit meer aan, dus historisch gegeven. Dit terwijl de andere relatie tussen player en team aangepast wordt bij een transfer oid.

Dit wil je blijkbaar horen, dus maak het maar zo. Ik zou echter overwegen om 'gebeurtenissen' te loggen, bijv. match, player, time, event_type(goal,geel,rood,roggel) of iets in die zin te doen ipv een enkele tabel met alle spelers en alle mogelijke attributen per match.

[Verwijderd]

Voutloos schreef op donderdag 10 april 2008 @ 15:45:
Dat was mij ook al duidelijk. Met player in match log je dus gewoon player, team, match, begintijd, eindtijd, aantal geel, aantal rood, aantal meters, aantal keer bal hooggehouden, aantal keer geroggeld, etc...
Dergelijke rows pas je na de wedstrijd nooit meer aan, dus historisch gegeven. Dit terwijl de andere relatie tussen player en team aangepast wordt bij een transfer oid.

Dit wil je blijkbaar horen, dus maak het maar zo. Ik zou echter overwegen om 'gebeurtenissen' te loggen, bijv. match, player, time, event_type(goal,geel,rood,roggel) of iets in die zin te doen ipv een enkele tabel met alle spelers en alle mogelijke attributen per match.

Ik wil niet perse iets horen hoor Overigens was ik niet van plan om gebeurtenissen vast te leggen in de PlayerInMatch tabel maar dit inderdaad te doen in andere tabel(len). PlyaerInMatch dient dus als koppeltabel tussen player en match om zo per wedstrijd/speler alle gebeurtenissen vast te leggen.

Maar een 'circle'' is dus niet altijd erg wanneer je 'historische' gegevens vast legt?

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 16:29:
[...]


Ik wil niet perse iets horen hoor Overigens was ik niet van plan om gebeurtenissen vast te leggen in de PlayerInMatch tabel maar dit inderdaad te doen in andere tabel(len). PlyaerInMatch dient dus als koppeltabel tussen player en match om zo per wedstrijd/speler alle gebeurtenissen vast te leggen.

Maar een 'circle'' is dus niet altijd erg wanneer je 'historische' gegevens vast legt?

kick

[bigbeng]

Het is geen circulaire referentie, omdat een relatie ook een richting heeft. Als je deze richtingen in de vorm van pijlen neerzet zul je zien dat het geen circel is.

Het heeft dus ook helemaal niks met goed of slecht te maken. Je modelleert de werkelijkheid, een speler speelt in een wedstrijd voor een team, dat is de relatie die je probeert te maken. Dat een speler in een team zit is ook een relatie die je wilt hebben (kan ik me zo voorstellen). Die zul je dan apart moeten vastleggen.

De TeamInMatch blijft voor mij een vraagteken. Je hebt een koppeltabel gemaakt voor iets wat functioneel vastligt, namelijk 2 teams in een wedstrijd. Nu is uit of thuis spelen vaak ook een eigenschap van een team in een wedstrijd, hoe ga je dit aangeven? En waarom denk je dat het ophalen van gerelateerde gegevens makkelijker danwel praktischer wordt met deze oplossing?

[Verwijderd]

bigbeng schreef op donderdag 17 april 2008 @ 17:35:
Het is geen circulaire referentie, omdat een relatie ook een richting heeft. Als je deze richtingen in de vorm van pijlen neerzet zul je zien dat het geen circel is.

Het heeft dus ook helemaal niks met goed of slecht te maken. Je modelleert de werkelijkheid, een speler speelt in een wedstrijd voor een team, dat is de relatie die je probeert te maken. Dat een speler in een team zit is ook een relatie die je wilt hebben (kan ik me zo voorstellen). Die zul je dan apart moeten vastleggen.

Ik wist niet dat de richting van relaties een circel 'opheft'. Ik kan weer met een gerust hart verder

bigbeng schreef op donderdag 17 april 2008 @ 17:35:
De TeamInMatch blijft voor mij een vraagteken. Je hebt een koppeltabel gemaakt voor iets wat functioneel vastligt, namelijk 2 teams in een wedstrijd. Nu is uit of thuis spelen vaak ook een eigenschap van een team in een wedstrijd, hoe ga je dit aangeven? En waarom denk je dat het ophalen van gerelateerde gegevens makkelijker danwel praktischer wordt met deze oplossing?

Ik maakte een denkfout waardoor ik dacht dat dit nodig was voor andere oplossingen maar ik heb het licht gezien dus ik maak nu gewoon een tabel Match met daarin o.a. de twee kolommen TeamHome en TeamAway.

Ik zal de voortgang hier posten.

[Voutloos]

Dat richting argument raakt echt kant nog wal. Juist als je op meerdere manieren data kan afleiden (links- of rechtsom) heb je misschien wel ergens redundantie. En soms wil je ook gewoon weten welke spelers in een team zitten ipv andersom.

Relaties moeten gewoon logisch zijn. Als je je entiteiten en relaties netjes uit tekent komt het allemaal wel goed. Als je een extra relatie van A naar C legt puur zodat je 'lekker niet met B hoeft te joinen' voel je hopelijk zelf aan dat redundant is.

[Verwijderd]

Voutloos schreef op vrijdag 18 april 2008 @ 08:25:
Dat richting argument raakt echt kant nog wal. Juist als je op meerdere manieren data kan afleiden (links- of rechtsom) heb je misschien wel ergens redundantie. En soms wil je ook gewoon weten welke spelers in een team zitten ipv andersom.

Tuurlijk wil ik weten welke spelers in een team zitten maar dat is in bovenstaande toch mogelijk. Kun je misschien aangeven wat er nu niet klopt in mijn gedachte? Ik wil juist voorkomen dat ik rechts- en links om data kan ophalen maar ik zou niet weten hoe ik dit moet voorkomen in mijn situatie.

Voutloos schreef op vrijdag 18 april 2008 @ 08:25:
Relaties moeten gewoon logisch zijn. Als je je entiteiten en relaties netjes uit tekent komt het allemaal wel goed. Als je een extra relatie van A naar C legt puur zodat je 'lekker niet met B hoeft te joinen' voel je hopelijk zelf aan dat redundant is.

Ik ben het daar mee eens. Ik zal niet zomaar extra relaties maken omdat het makkelijker is. Dit zal ik alleen doen wanneer blijk dat na normalisatie extra relaties nodig t.b.v. performance verbetering.

[bigbeng]

Voutloos schreef op vrijdag 18 april 2008 @ 08:25:
Dat richting argument raakt echt kant nog wal. Juist als je op meerdere manieren data kan afleiden (links- of rechtsom) heb je misschien wel ergens redundantie. En soms wil je ook gewoon weten welke spelers in een team zitten ipv andersom.

Relaties moeten gewoon logisch zijn. Als je je entiteiten en relaties netjes uit tekent komt het allemaal wel goed. Als je een extra relatie van A naar C legt puur zodat je 'lekker niet met B hoeft te joinen' voel je hopelijk zelf aan dat redundant is.

Dude, ik refereerde aan de cirkel. Circulaire referentie dus. Redundantie heb ik het niet eens over. En vervolgens heb ik het over logische relaties en dat herhaal jij nog eens.

[Verwijderd]

Over circular referencing nog even. In dit topic wordt in post vier ook gezegd dat dit niet altijd een probleem hoeft te zijn wanneer de richting van de relaties onder de loep worden genomen. Klinkt dan toch wel aannemelijk. Ook zou ik in mijn model geen andere oplossing kunnen bedenken.

[Verwijderd]

Modbreak:

Spammen wordt niet gewaardeerd.

[ Voor 100% gewijzigd door NMe op 10-06-2010 17:36 ]

[tweakict]

spam?

Modbreak:

Jouw post is dan ook. Alleen posten als je iets toe kan voegen s.v.p.

[ Voor 89% gewijzigd door NMe op 10-06-2010 17:37 ]