Ontwerp database

[dave.vanderveke]

Een tijdje geleden was ik op dit forum met een boel vragen over een database... Toen zeiden ze me dat het ontwerp van de database niet zo goed was.... Ik heb dus besloten van volledig opnieuw te beginnen...

 

Maar ik zit dus nog met een deel vragen... Vandaar deze post...

 

Ik zal even uitleggen welke functie de database moet hebben...

Ik heb ook al een klein bestand gemaakt... waar ik hoop vanaf het begin dus de relaties tegoei te leggen en niet met overbodige tabellen zit..

 

De db is voor de opvolging en verkoop van projecten...

1) elk project heeft 1 opdrachtgever.

2) elk project heeft meerdere leveranciers.

3) elke leverancier kan meerdere dingen doen (type: dus voor project 1 doet hij het ontwerp en voor project 2 doet hij de afwerking ofzo)

4) elk project bestaat uit meerdere units

5) elke unit is van een type (4 types)

5b) de units moeten per project en per type in een portaal komen

6) 1 klant per overeenkomst

7) elke overeenkomst kan verschillende units van 1 project hebben

1 klant kan meerdere overeenkomsten hebben (dus 2 overeenkomsten van project 1, of 1 van project 1 en 1 van project 2)

9) in eerste instantie is een overeenkomst mondeling, daarna komt de schriftelijke overeenkomst, daarna een definitieve koop en daarna misschien een annulatie.... deze gegevens moeten wel bijgehouden worden dus ik kan niet het type wijzigen denk ik want anders blijven deze gegevens niet ... daarom denk ik dat ik dus voor een koop 3 overeenkomsten zal moeten maken (eventueel via een copy om overbodig werk te vermijden) of bij een annulatie moet ik nog wel weten welke units in optie waren en welke data enzo...

10) na annulatie moeten de units wel genoteerd blijven bij deze annulatieovereenkomst maar ze moeten wel terug vrij gezet worden zodat ze in een nadere overeenkomst kunne komen...

10b) nu is er wel het probleem dat bij een optie (1ste soort overeenkomst) unit A en unit B kunnen staan, maar bij de verkoopsovereenkomst het gaat over unti A en C... later moet ik dus wel kunne nakijken welke units d eklant eerst wilde... hier moet dus wel even nagedacht worden over de juiste werking.. als je vragen hebt mail me maar of zet maar in de post dan..

11) als een unit in een overeenkomst zit... dan mag ze niet meer inboekbaar zijn voor een andere overeenkomst

12) een overeenkomst bevat untis van 1 enkel project..

13) elk project en elke overeenkomst kan meerdere ToDo's hebben

14) elke todo is voor een specifieke werknemer

 

Zo hierop komt het neer... kan iemand me adviseren of raad geven ivm de te leggen relaties?

db.fp7

[dave.vanderveke]

hujm weinig reacties...

 

even kort zeggen, het is niet de bedoeling dat jullie hier deze database ontwerpen voor me... het is eerder de bedoeling van sommige relaties even uit te leggen hoe ik ze het beste maak.... en dat ik zelf dit alles uitprobeer....

 

thx

[AvD]

hujm weinig reacties...

Dat zou normaal een belletje moeten doen rinkelen: meestal is iedereen hier erg behulpzaam, sommigen zelfs (terecht) trots op het verspreiden van hun kennis en kunde. Toch krijg je geen reactie...

het is niet de bedoeling dat jullie hier deze database ontwerpen voor me... het is eerder de bedoeling van sommige relaties even uit te leggen(...)

Je schijnt niet te beseffen dat je hoofdprobleem schuilt in het gebruik van het woordje "even". Wat jij hier vraagt komt in grote lijnen overeen met een consultancy-opdracht van vele uren. Dat betekent dat je ook weinig of geen kijk hebt op de complexiteit van een databankstructuur. Je zal het dus over een andere boeg moeten gooien, tenzij je hier toch nog een of andere goedhartige ziel vindt die én veel kennis én veel vrije tijd heeft...

Het spijt me, maar na je vele vragen in dezelfde richting, vrees ik dat dit toch "even" moest gezegd worden.

[rmw]

Ik sluit me aan bij de vorige spreker.

 

Tip:

Probeer veel directere probleemstellingen te posten.

Nu moet iemand eerst je probleem bestuderen voordat een antwoord kan worden gegeven en die tijd moet men wel willen investeren.

Dat was voor mij in elk geval de reden om niet te antwoorden.

 

rmw

[JeanWM]

Indien je ons een voor tenminste 75 % uitgewerkt ER diagram kunt tonen, heb ik een paar goede zielen die zich er even willen over buigen...

 

Zonder dat...aansluiting bij de vorige posters....

[medic112]

Je spreekt hier wel over types maar ik zie nergens geen beschrijving van te types (value list)

Ik denk dat je beter eens een database doorstuurt waar je voorbeelden hebt ingevoerd, zo is het eigenlijk een beetje moeilijk om het juist uit te pluizen. Vergt te veel tijd die zeer kostbaar is.

 

 

voor de rest is het hier moeilijk om dit volledig uit te pluizen, mij lijkt het best dat je eens op je gemak alles bekijkt en probleem per probleem op te lossen inplaats van alles tegelijkertijd.