[Alg] Datamodel discussie*

[WheeleE]

In het kader van leren en proberen applicaties te maken ben ik op zoek naar een voorbeeld datamodel voor een sportcompetitie.
Ik ben zelf al tot Teams en Wedstrijden gekomen, maar ik wil er ook een stukje in hebben dat het mogelijk maakt om snel en makkelijk tussentijdse overzichten van de stand te maken. Periodiek dus de wedstrijden aflopen die nog niet verwerkt zijn en adhv de uitslagen e.e.a. bijwerken.

Wie kan mij verder helpen of heeft een tip waar ik voorbeelden hier van kan vinden?

Merci bij voorbaat!

Toevoeging: Dit is niet bedoeld als scriptrequest. Ik wil graag ideen opdoen over hoe dit het beste aangepakt kan worden. Zie ook mijn volgende post met eigen ideeen.

[ Voor 14% gewijzigd door WheeleE op 06-02-2003 11:31 . Reden: werd aangezien voor scriptrequest ]

[whoami]

WheeleE schreef op 06 februari 2003 @ 11:14:
In het kader van leren en proberen applicaties te maken ben ik op zoek naar een voorbeeld datamodel voor een sportcompetitie.

Noujah, op zoek zijn naar een voorbeeld model valt eigenlijk onder script request, en deze laten we hier niet toe.

Ik ben zelf al tot Teams en Wedstrijden gekomen, maar ik wil er ook een stukje in hebben dat het mogelijk maakt om snel en makkelijk tussentijdse overzichten van de stand te maken. Periodiek dus de wedstrijden aflopen die nog niet verwerkt zijn en adhv de uitslagen e.e.a. bijwerken.


Wie kan mij verder helpen of heeft een tip waar ik voorbeelden hier van kan vinden?

Merci bij voorbaat!

Zoek gewoon eens eea op over data modelling, normalisatie enzo. Noteer de gegevens die je nodig hebt, pas de regels erop toe, etc.... zo leer je het best van al bij.

[D2k]

heropend, de starter wilde nog wel het eea toevoegen

[Alarmnummer]

Ik ga je geen voorbeeld geven van hoe je een domein model hiervoor kan maken, maar ik kan je wel een uitstekend boek aanraden over hoe je dit zou kunnen aanpakken:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition).

[WheeleE]

Ik heb nu een basic model met een tabel Wedstrijd(W) en een tabel Team(T). W verwijst 2 keer naat T, nl team 1 en team 2. Verder bevat T een ID, Tijd en score 1 & 2.
Tot zover lukt het wel, maar het verwerken van uitslagen en het maken van overzichten gaat zo best wel veel tijd kosten. Alle wedstrijdrecords moet worden afgelopen om de uitslagen en teams te gaan verwerken tot een tussenstand/standentabel.

Ik had bedacht dat er na elke invoerronde van standen (na een speeldag bijvoorbeeld) een batchverwerking wordt gestart om een tabel Stand(S) te vullen.bij te werken. De wedstrijden die nog niet zijn verwerkt worden nagelopen en adhv de stand worden in de tabel S de kolommen (behorende bij Team_id) #gespeeld. #gewonnen/verloren/gelijk, wedstrijdpunten en doelsaldo opgehoogt/bijgewerkt. Uit die tabel kunnen dan gemakkelijker gegevens voor een overzicht worden geplukt.

De vraagt die bij mij nu rijst is, hoe gaat dat nu met het bewaren van de historie. Men wil ook wel eens standen bekijken van vorige seizoenen. Daar ben ik nog niet over uit, hoe dat moet gaan gebeuren.

[ Voor 2% gewijzigd door WheeleE op 06-02-2003 11:49 . Reden: woordje vergeten ]

[whoami]

Alarmnummer: ik denk dat de topicstarter nog bezig is met het opstellen van z'n database.

[Alarmnummer]

whoami schreef op 06 februari 2003 @ 11:42:
Alarmnummer: ik denk dat de topicstarter nog bezig is met het opstellen van z'n database.

Dat kan je aan de hand van een domein model ook uitstekend doen hoor Het is veel handiger om in termen te denken van domein modellen dan in relationeel database model. En tenslotte komt een ER diagram behoorlijk overeen met domein model. Je hebt in beide entiteiten, relaties, cardinaliteiten van relaties ed.

[OZ-Gump]

Volgens mij is het nooit verstandig om berekende waardes in een tabel op te slaan, omdat je dan inderdaad met een historie zit. Ik denk dat je zou moeten werken aan een query die de stand genereert, waarin je de begin en einddatum variabel maakt. Op die manier is de huidige stand met een simpele query op te roepen, maar ook de stand van 1 december afgelopen jaar. Het wordt natuurlijk geen simpele query, maar met een beetje werk en hulp van wat andere (sub)queries moet je daar toch wel uit kunnen komen.

[whoami]

Alarmnummer schreef op 06 February 2003 @ 11:51:
[...]


Dat kan je aan de hand van een domein model ook uitstekend doen hoor Het is veel handiger om in termen te denken van domein modellen dan in relationeel database model. En tenslotte komt een ER diagram behoorlijk overeen met domein model. Je hebt in beide entiteiten, relaties, cardinaliteiten van relaties ed.

Hmmm, daar ga ik niet geheel mee akkoord.
Ik ga altijd eerst een ERD maken, en daarop baseer ik dan m'n object-model. Trouwens, een domain model hoeft niet 1 op 1 overeen te komen met je ERD.

[WheeleE]

OZ-Gump schreef op 06 februari 2003 @ 11:51:
Volgens mij is het nooit verstandig om berekende waardes in een tabel op te slaan, omdat je dan inderdaad met een historie zit. Ik denk dat je zou moeten werken aan een query die de stand genereert, waarin je de begin en einddatum variabel maakt. Op die manier is de huidige stand met een simpele query op te roepen, maar ook de stand van 1 december afgelopen jaar. Het wordt natuurlijk geen simpele query, maar met een beetje werk en hulp van wat andere (sub)queries moet je daar toch wel uit kunnen komen.

Dat was ook mijn eerste gedachte, maar dat moeten elke keer alle records in de wedstrijdentabel worden nagelopen. Dat kost, zeker bij een flinke tabel, nogal wat tijd en geeft ook veel belasting op de database. Dat wil ik voorkomen door een soort van tussenstation te maken (de tabel Stand).

[whoami]

WheeleE schreef op 06 February 2003 @ 11:56:
[...]


Dat was ook mijn eerste gedachte, maar dat moeten elke keer alle records in de wedstrijdentabel worden nagelopen. Dat kost, zeker bij een flinke tabel, nogal wat tijd en geeft ook veel belasting op de database. Dat wil ik voorkomen door een soort van tussenstation te maken (de tabel Stand).

Berekende data sla je echt best niet op. Veel te veel werk om altijd alles up to date houden enzo.
Dat je elke keer alle records moet aflopen is niet waar, mits je goed gebruik maakt van indexen. Pas als je geen indexen gebruikt, en het DBMS een 'table scan' moet uitvoeren, dan zal het traag gaan.

[The Eagle]

Alarmnummer schreef op 06 February 2003 @ 11:35:
Ik ga je geen voorbeeld geven van hoe je een domein model hiervoor kan maken, maar ik kan je wel een uitstekend boek aanraden over hoe je dit zou kunnen aanpakken:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition).

Brrrrr...UML

[WheeleE]

whoami schreef op 06 februari 2003 @ 11:58:

[...]


Berekende data sla je echt best niet op. Veel te veel werk om altijd alles up to date houden enzo.

Dat zou periodiek gebeuren. Dmv een stored procedure oid word elke 2 weken ofzo alle niet-verwerkte wedstrijden afgewerkt.

Dat je elke keer alle records moet aflopen is niet waar, mits je goed gebruik maakt van indexen. Pas als je geen indexen gebruikt, en het DBMS een 'table scan' moet uitvoeren, dan zal het traag gaan.

Daar zeg je wat. Aan indexen ha ik nog niet gedacht op die manier.

[Alarmnummer]

whoami schreef op 06 February 2003 @ 11:54:
Hmmm, daar ga ik niet geheel mee akkoord.
Ik ga altijd eerst een ERD maken, en daarop baseer ik dan m'n object-model.

objectmodel!=domein model:)

Trouwens, een domain model hoeft niet 1 op 1 overeen te komen met je ERD.

Kun je een voorbeeld geven?

[whoami]

Alarmnummer schreef op 06 February 2003 @ 12:05:
[...]

objectmodel!=domein model:)

Euh, jah. Nouja, je snapt wel wat ik bedoel.

Kun je een voorbeeld geven?

Stel, je hebt 2 tabellen in uw ERD: Klant en Orders.
Dan ga je daarom toch niet in uw domainmodel die informatie op dezelfde manier gaan opslaan zoals je doet in je databank? Normaal gezien zal je dan een class 'Klant' hebben die als member bv. een ArrayList bevat waar de Orders voor die klant in opgeslagen zitten, terwijl, in je databank je met een foreign key 'klantid' in de Order-tabel zult werken.
Zie ook in dat boek 'Patterns of Enterprise Application Architecture' van Fowler de puntjes over inheritance in uw domain-model enz....

[Alarmnummer]

Bij een ERD ga je je ook niet druk lopen maken over foreign keys ed. Je geeft alleen aan wat entiteiten zijn, waarmee je een entiteit kan identificeren (primaire sleutel), wat de relaties zijn tussen de entiteiten, de cardinaliteiten zijn van die relaties en de attributen. Dit is precies wat je ook met een domain model doet.

[edit]
je mag wel je zeggen hoor ipv u. (rare belgen ook )

[ Voor 14% gewijzigd door Alarmnummer op 06-02-2003 13:46 ]

[whoami]

Alarmnummer schreef op 06 February 2003 @ 13:44:
Bij een ERD ga je je ook niet druk lopen maken over foreign keys ed. Je geeft alleen aan wat entiteiten zijn, waarmee je een entiteit kan identificeren (primaire sleutel), wat de relaties zijn tussen de entiteiten, de cardinaliteiten zijn van die relaties en de attributen. Dit is precies wat je ook met een domain model doet.

[edit]
je mag wel je zeggen hoor ipv u. (rare belgen ook )

Mwah. Bij een domain-model ga je het toch ook al over de Business Logica hebben, terwijl je met een ERD enkel gaat gaan kijken hoe je de data op gaat slaan.
In uw domain-model kan je te maken hebben met strategies ed, en die ga je niet representeren in uw ERD.

_{nu doe ik het weer......}

[Alarmnummer]

whoami schreef op 06 February 2003 @ 13:47:

[...]


Mwah. Bij een domain-model ga je het toch ook al over de Business Logica hebben,

Ik het over domain model van UP. Dit is een diagram notatie waarmee je eenvoudig domein modellen op kan stellen.