Toon posts:

Graag commentaar op database ontwerp

Pagina: 1
Acties:

  • Reveller
  • Registratie: augustus 2002
  • Laatst online: 07-05-2020
Voor mijn opleiding (financieel!) moeten we de haalbaarheid bepalen van de introductie van een nieuw systeem in de energiemarkt. Een hele korte uitleg:
  • consumenten die een windturbine of zonnepanelen hebben, krijgen een kastje in hun meterkast
  • dit kastje meet energie gebruik en productie van deze zgn. "prosumer". Op de server wordt deze info opgeslagen
  • als productie > consumptie, wordt het overschot verkocht; andersom wordt energie bijgekocht (realtime)
  • de prosumer kan een aantal preferences/parameters instellen, o.a. van wat voor soort energiebronnen hij wel / niet energie geleverd wil krijgen (iemand die "groen" denkt wil bv. geen energie van kerncentrale kopen, dus users_sources). Op basis van deze parameters wordt een prosumer (in het schema "user") dus gekoppeld aan een aantal potentiele brokers (users_brokers)
  • energiebrokers bieden elk een eigen mix aan van verschillende energy_sources (wind, water, kolen, etc)
  • als er energie gekocht is van / verkocht is aan een broker, wordt de contractinfo opgeslagen
Gek genoeg moet er ook een database diagram bij de opdracht worden ingeleverd :? Dus als non-techneut maar eens ingelezen, Visio uit de kast getrokken en mijn best gedaan. Ik wil jullie vragen er eens naar te kijken en evt. commentaar te leveren, zodat ik weet of ik er verder mee kan gaan of mezelf eerst nog meer moet gaan inlezen :)

Database ontwerp voor IBA Opdracht 2

P.S. Ik zou graag mbv de pijlen laten zien of er een 1-op-1 of 1-op-meer relatie is tussen tabellen, maar standaard maakt Visio (versie 2002) van elke relatie een pijl :(

[Voor 6% gewijzigd door Reveller op 30-09-2010 13:58]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."


  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 21-09 16:53
Een 1-1 relatie kun je modelleren door de PK van tabel X ook de FK te laten zijn die wijst naar de PK van tabel Y. Moet je wel PK's definieren. ;)

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • Reveller
  • Registratie: augustus 2002
  • Laatst online: 07-05-2020
Grijze Vos schreef op donderdag 30 september 2010 @ 14:16:
Een 1-1 relatie kun je modelleren door de PK van tabel X ook de FK te laten zijn die wijst naar de PK van tabel Y. Moet je wel PK's definieren. ;)
Thanks! Ik heb met die tip het volgende gedaan. Moet wel zeggen dat ik wat in de war raak. Je zou het volgende moeten kunnen aflezen uit het diagram:
  • het systeem kent 2 soorten users: prosumers en administrators, elk met een eigen tabel voor details
  • elke prosumer kan een aantal instellingen (parameters) zetten (bv. wel/geen notifications). Een van de instellingen laat toe dat de prosumer definieert van welke energiebronnen hij energie geleverd zou willen krijgen (bv wind, zon maar geen steenkool)
  • deze mogelijke energiebronnen staan in energy_sources
  • iedere energie broker levert een bepaalde mix van energiebronnen (bv broker 1 levert wind en water, broker 2 alleen kernenergie); deze matching staat in brokers_sources
  • dagelijks worden er contracten gesloten tussen prosumers en brokers
  • let op: brokers zijn geen actieve gebruikers in het systeem - zij behoeven geen inlogcombinatie
  • prosumers hebben een kastje in de meterkast dat energie gebruik / productie meet. Voor elke minuut van elke dag worden deze gegevens opgeslagen in usage_production


Graag jullie reaktie :) Welke fouten zie je? Wat is onlogisch?
* Wat een gedenk ineens voor een niet-techneut ;) *

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."


  • Xiphalon
  • Registratie: juni 2001
  • Laatst online: 12:39
Je hebt wel heel veel tabellen met als PK user_id.

  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 13:46

Janoz

Moderator Devschuur®

!litemod

Een 1 op 1 relatie 'bestaat niet'. Dat zijn namelijk geen 2 tabellen, maar is 1 tabel.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • dusty
  • Registratie: mei 2000
  • Laatst online: 20-09 06:45

dusty

Global Moderator

Y! Celebrate Life!

Ik zie mogelijkheden om een contract te hebben met een userid waarvan de userid nog niet bestaat.
Elke user kan slechts een parameter record hebben.

En nog een stuk of 6 andere fouten die je ook zelf kunt ontdekken zodra je correct normaliseert.

Curlio.com Music News For You!
"Je moet haar alleen aan de ketting leggen" - MueR


  • Reveller
  • Registratie: augustus 2002
  • Laatst online: 07-05-2020
dusty schreef op donderdag 30 september 2010 @ 18:16:
Ik zie mogelijkheden om een contract te hebben met een userid waarvan de userid nog niet bestaat.
Vanwege die PK zeker?
Elke user kan slechts een parameter record hebben.
Dat is toch ook de bedoeling? Elke user kan slechts 1x een voorkeur opgeven voor wel/geen notifications, wel/niet eigen energy eerst gebruiken, etc...?
En nog een stuk of 6 andere fouten die je ook zelf kunt ontdekken zodra je correct normaliseert.
Dat wordt dan zoeken :)

[Voor 31% gewijzigd door Reveller op 30-09-2010 18:40]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."


  • MBV
  • Registratie: februari 2002
  • Laatst online: 22-09 17:00
Als je de parameters toch maar 1x kan hebben, waarom dan niet in de users-tabel?


Misschien handig om even uit te leggen wat normaliseren is:
Wikipedia: Boyce-Codd normal form

[Voor 22% gewijzigd door MBV op 30-09-2010 19:00]


  • Reveller
  • Registratie: augustus 2002
  • Laatst online: 07-05-2020
OK, dus een PK is de unieke identifier van een tabel, gebruikt als index. Een FK verbindt een tabel met een andere tabel. De parameters zijn toegevoegd aan de users tabel. Ik weet nog niet zeker of ik een aparte prosumer en administrators tabel moet laten. Ik denk het wel, omdat ik van beide groepen andere zaken ga opslaan (ik hoef bv. niet de bankaccount van een administrator te hebben in deze case). Klopt het nu wat beter?



Edit: is het trouwens niet gebruikelijk om "user_id" in de prosumer tabel te hernoemen naar "prosumer_id" en naar "admin_id" in de administrator tabel?

[Voor 13% gewijzigd door Reveller op 30-09-2010 21:46]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."


  • dusty
  • Registratie: mei 2000
  • Laatst online: 20-09 06:45

dusty

Global Moderator

Y! Celebrate Life!

Reveller schreef op donderdag 30 september 2010 @ 18:39:
[...]
Dat is toch ook de bedoeling? Elke user kan slechts 1x een voorkeur opgeven voor wel/geen notifications, wel/niet eigen energy eerst gebruiken, etc...?
[...]
Dus jij gaat extra kolommen aanmaken voor elke voorkeur, kolom 1 voor notifications, kolom 2 voor eigen energy, etc?
Indien ja: dan heb je niet genormaliseerd.
Indien nee: is je database model dus niet goed.
Tip: zet je users-tabel als "hoofd-tabel" neer, in het midden van je schema. Als er een user is dan heeft hij een userID. Bestaat die userID niet, dan kan er geen record met die UserID in een van je andere tabellen zijn, dus link elke tabel met UserID naar je "hoofd-tabel" en kijk eens hoe ver je komt met je schema met dat in je hoofd.

Curlio.com Music News For You!
"Je moet haar alleen aan de ketting leggen" - MueR


  • wizzkizz
  • Registratie: april 2003
  • Laatst online: 19-04 19:32

wizzkizz

smile...tomorrow will be worse

dusty schreef op vrijdag 01 oktober 2010 @ 01:18:
Dus jij gaat extra kolommen aanmaken voor elke voorkeur, kolom 1 voor notifications, kolom 2 voor eigen energy, etc?
Indien ja: dan heb je niet genormaliseerd.
Indien nee: is je database model dus niet goed.
Die aanpak lijkt me prima verdedigbaar hoor. Je kunt die voorkeuren zien als attributen van het object prosumer. Wat wil je anders?

Een 1:1 relatie met een notifications-tabel? Dan kun je het beter in de prosumer tabel laten.
een 1:n relatie met een voorkeuren tabel en vervolgens daar de velden naam en waarde hebben? Kan, maar aangezien er tussen elke voorkeur en de prosumer een 1:1 relatie bestaat, zou ik het gewoon in de prosumer tabel laten. Bovendien loop je dan aanvullend tegen het probleem aan: welk type veld moet dan die waarde hebben? Een varchar, int, datum of nog iets anders? Of voor elk datatype een kolom en de niet-benodigde kolommen NULL-en?

Ik zou voor elk attribuut van de prosumer ook een aparte kolom aanmaken, net zoals je dat voor naam en adres doet bijvoorbeeld.

Edit:
@Reveller
Denk er nog even over na hoe je die rechten wilt hebben. Een aparte tabel met daarin de rechten en vervolgens een koppeltabel naar de administrator-tabel, is het meest gebruikelijke.

Je zou, als je heel enthousiast bent, dit ook nog kunnen uitbreiden met een rollen-tabel, met koppeltabellen naar de rechten en de administrators. Je kunt dan administrators indelen in één of meerdere rollen (bijv. contractbeheerder, debiteurbeheerder etc.) en aan de hand van hun rol hebben ze dan bepaalde rechten.

[Voor 18% gewijzigd door wizzkizz op 03-10-2010 13:31]

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.


  • sopsop
  • Registratie: januari 2002
  • Laatst online: 22-09 13:48

sopsop

[v] [;,,;] [v]

Een aantal zaken vallen me op:
De tabel administrators zou ik opsplitsen:
code:
1
2
3
4
5
6
7
8
TABLE Roles
PK - RoleId
   - RoleDescription

TABLE UsersRolesCR:
PK - UsersRolesId
FK - UserId
FK - RoleId


Voor bijvoorbeeld Usage production zou ik de PK UsageProductionId maken en User_Id een FK. Daarnaast kun je de tabel user & prosumer prima samenvoegen mits iedere user ook altijd een prosumer is.

Iedere tabel moet een voor die tabel unieke PK hebben. Dat houdt in dat je de velden moet gebruiken die nooit kunnen veranderen en nooit dubbel kunnen voorkomen. Indien je die garantie niet kunt geven (ik noem bijvoorbeeld een combinatie voorletters + achternaam, die kan zowel dubbel voorkomen als wijzigen) moet je zelf een uniek veld toevoegen.

Tabel users: sla geen passwoord op, maar een hash van een password. Zorg er in ieder geval voor dat het wachtwoord er niet in plain text instaat.

[Voor 34% gewijzigd door sopsop op 03-10-2010 14:03]


  • dusty
  • Registratie: mei 2000
  • Laatst online: 20-09 06:45

dusty

Global Moderator

Y! Celebrate Life!

wizzkizz schreef op zondag 03 oktober 2010 @ 13:21:
[...]
Die aanpak lijkt me prima verdedigbaar hoor. Je kunt die voorkeuren zien als attributen van het object prosumer. Wat wil je anders?
[...]
Ik zou voor elk attribuut van de prosumer ook een aparte kolom aanmaken, net zoals je dat voor naam en adres doet bijvoorbeeld.
[...]
Denk er nog even over na hoe je die rechten wilt hebben. Een aparte tabel met daarin de rechten en vervolgens een koppeltabel naar de administrator-tabel, is het meest gebruikelijke.
[...]
En je kunt rechten ook zien als attributen van het object prosumer/user. En bij de een normaliseer je wel, en bij het andere doe je het juist niet?

Curlio.com Music News For You!
"Je moet haar alleen aan de ketting leggen" - MueR


  • wizzkizz
  • Registratie: april 2003
  • Laatst online: 19-04 19:32

wizzkizz

smile...tomorrow will be worse

dusty schreef op zondag 03 oktober 2010 @ 20:33:
En je kunt rechten ook zien als attributen van het object prosumer/user. En bij de een normaliseer je wel, en bij het andere doe je het juist niet?
Dat kan misschien, maar ik zie rechten als aparte entiteit met een n:m relatie met de entiteit administrator.
De reden hiervoor is dat je rechten niet alleen kunt koppelen aan gebruikers, maar ook aan gebruikersrollen bijvoorbeeld. Of ga jij dan voor elk recht in beide tabellen een extra kolom aanmaken?

De entiteit recht heeft bijvoorbeeld een naam, een omschrijving, een veld dat aangeeft of het recht toegekend of afgewezen is of overerft etc. Daarmee is het principieel anders dan een attribuut "eigen stroom eerst", dat altijd een 1:1 relatie heeft met een prosumer.

En je gaat verder ook niet in op de praktische kant van een extra Voorkeuren-entiteit voor het ontwerp.

Wat mij betreft moet je, ook bij normaliseren, zowel de regels volgens als je GBV (gezonde boerenverstand) gebruiken. Doe je dit niet, dat leidt dit tot een onnodige complexiteit of over-genormaliseerde database. En daar wint niemand wat mee.

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.


  • jbdeiman
  • Registratie: september 2008
  • Laatst online: 06:24
Een aantal zaken:
- Inderdaad (je noemde het al ergens) een PK die overal user_id is, dus eigenlijk allemaal 1 op 1 relaties.
- Bijvoorbeeld bij users/ administrators, je kan beter een kolom rights in de users tabel zetten
- de procumers zijn denk ik de consumenten? Er zit eigenlijk maar 1 prosumer aan een user, maar voor een administrator zijn die gegevens niet beschikbaar. Ik zou prosumer_id als PK doen, (bij prosumers) en in users een FK naar prosumer. => Je koppelt zo de gebruiker aan zijn useraccount.
- Bij de usage_production tabel heb je een 1 op N relatie. Dus PK user_id kan niet. Je houdt die kolom wel, maar de PK wordt usage_production_id (of iets in die trent)
- Bij de tabellen waar je nu geen PK hebt, zijn beide kolommen eigenlijk de PK (gezamelijk) echter heb je ook de user_id, die een FK is, en de source_id ook. Hiervoor is het het eenvoudigst om de combo van beide kolommen een "unique" mee te geven en een aparte (auto_increment) kolom te gebruiken voor de PK. Dit geldt overigens voor meerdere tabellen.

  • dusty
  • Registratie: mei 2000
  • Laatst online: 20-09 06:45

dusty

Global Moderator

Y! Celebrate Life!

wizzkizz schreef op dinsdag 05 oktober 2010 @ 12:17:
[...]
Dat kan misschien, maar ik zie rechten als aparte entiteit met een n:m relatie met de entiteit administrator.
De reden hiervoor is dat je rechten niet alleen kunt koppelen aan gebruikers, maar ook aan gebruikersrollen bijvoorbeeld. Of ga jij dan voor elk recht in beide tabellen een extra kolom aanmaken?
[...]
En je kan ook voorkeuren hebben die alleen geldig is voor iemand met een bepaald recht.

Niet normaliseren, betekent dat je repeterende kolommen hebt. (Immers kan je ze Voorkeur1, Voorkeur2, Voorkeur3 noemen.) en iedereen met GBV kan aanvoelen dat daar iets fout zit. Bij hoeveel voorkeuren ga je zeggen dat het misschien anders moet? 10? 20? 50? 200? of ga jij echt een tabel maken met over 100 kolommen?
En je gaat verder ook niet in op de praktische kant van een extra Voorkeuren-entiteit voor het ontwerp.
[...]
Voordeel van het normaliseren van voorkeuren is uiteraard dat je later makkelijk extra voorkeuren kunt toevoegen zonder dat je aan je database moet gaan sleutelen.

Curlio.com Music News For You!
"Je moet haar alleen aan de ketting leggen" - MueR


  • wizzkizz
  • Registratie: april 2003
  • Laatst online: 19-04 19:32

wizzkizz

smile...tomorrow will be worse

dusty schreef op dinsdag 05 oktober 2010 @ 14:59:
Niet normaliseren, betekent dat je repeterende kolommen hebt. (Immers kan je ze Voorkeur1, Voorkeur2, Voorkeur3 noemen.) en iedereen met GBV kan aanvoelen dat daar iets fout zit. Bij hoeveel voorkeuren ga je zeggen dat het misschien anders moet? 10? 20? 50? 200? of ga jij echt een tabel maken met over 100 kolommen?
Ik ga hier niet lang over door zeuren, maar vind je dat niet een beetje een flauw argument? Dan kun je alles wel zo gaan behandelen, en naam, achternaam en tussenvoegsel attribuut1, attribuut2 en attribuut3 noemen.

Ik zei dus ook niet dat het de enige manier is, maar wel dat het prima verdedigbaar is. Als je normaliseer volgens de letter der "wet" is het misschien niet juist, maar imho kan je het zo prima toepassen.

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.


  • sopsop
  • Registratie: januari 2002
  • Laatst online: 22-09 13:48

sopsop

[v] [;,,;] [v]

Daar heb je de verschillende normaalvormen voor. Als je niet verder dan de derde normaalvorm normaliseert blijf je gewoon in het common sense gebied (de normalisatie stappen blijven logisch).

  • SvMp
  • Registratie: september 2000
  • Niet online
Janoz schreef op donderdag 30 september 2010 @ 16:52:
Een 1 op 1 relatie 'bestaat niet'. Dat zijn namelijk geen 2 tabellen, maar is 1 tabel.
Kun je dat toelichten?

Naar mijn idee bestaat het wel.

Bijvoorbeeld: Je hebt een database met plaatsen. Soms heb je alleen elementaire gegevens, soms aanvullingen, ongeveer fifty-fifty. Dat kun je in één tabel zetten, maar dan heb je in veel gevallen wel veel lege velden, die ook enige overhead gegeven (length-values van varchars bijv).

Je kunt ook een tabel maken met primaire gegevens tabel plaats(ID [primary key], plaatsnaam, aantal inwoners) en een tabel met aanvullingen, tabel plaats_extra (ID [foreign key en primary key tegelijk], stadsrechten, oppervlakte, infotext). In zo'n geval heb je toch twee tabellen met een 1-op-1 relatie?

  • EnigmA-X
  • Registratie: februari 2002
  • Laatst online: 22-09 23:28
Normaliseren doe je met twee redenen:
  1. Voorkomen dat je data dubbel/redundant opslaat
  2. Logisch opslaan van gegevens
In jouw voorbeeld sla je data niet twee keer op (uitgezonderd van de key), maar is de logica het probleem. Je gaat uitzonderingen toepassen op je database, zonder dat het direct te maken heeft met de data. Mijn vraag zou dan ook zijn waarom je andere data uit je 'hoofdtabel' niet ook op zou slaan in een losse tabel. Het kan namelijk zijn dat je het aantal inwoners niet kent, ga je er dan ook een uitzondering van maken?

Anders gezegd, als je uitzonderingen gaat maken, moet je daar echt een heel goede reden voor hebben en in een professionele omgeving betekent dat je dit ook supergoed zou moeten gaan documenteren. Daarnaast wijk je af van de standaarden (BCNF) en zou je dat ook moeten gaan documenteren.

In dat geval kan je imho beter kiezen voor een beetje extra storage gebruik en een sterk logisch database model, waar jij en je collega's na een poosje ook nog makkelijk aan kunnen prutsen.

Daarom dus :)

  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 13:46

Janoz

Moderator Devschuur®

!litemod

SvMp schreef op woensdag 06 oktober 2010 @ 16:32:
[...]


Kun je dat toelichten?

Naar mijn idee bestaat het wel.

Bijvoorbeeld: Je hebt een database met plaatsen. Soms heb je alleen elementaire gegevens, soms aanvullingen, ongeveer fifty-fifty. Dat kun je in één tabel zetten, maar dan heb je in veel gevallen wel veel lege velden, die ook enige overhead gegeven (length-values van varchars bijv).

Je kunt ook een tabel maken met primaire gegevens tabel plaats(ID [primary key], plaatsnaam, aantal inwoners) en een tabel met aanvullingen, tabel plaats_extra (ID [foreign key en primary key tegelijk], stadsrechten, oppervlakte, infotext). In zo'n geval heb je toch twee tabellen met een 1-op-1 relatie?
Wat voor enorme overhead bezwaren gaat het überhaupt opleveren wanneer je die bit, de double en het text veld in de plaats tabel op gaat nemen? (Bedenk daarbij dat in veel database oplossingen de velden met type text sowieso al los opgeslagen worden) Dat er mogelijk veel velden in een tabel komen die allemaal null kunnen zijn vind ik persoonlijk een enorm non issue en neigt heel erg naar premature optimalisatie.

Er bestaat wel een 1-op-0..1 relatie. Die is vergelijkbaar met de 1:N relatie maar dan met een maximale waarde voor N.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • SvMp
  • Registratie: september 2000
  • Niet online
Het idee voor een aparte tabel voor gegevens die vaak ontbreken, heb ik van deze website vandaan: http://20bits.com/article...l-queries-that-dont-suck/
Er worden 10 tips gegeven om MySQL queries te optimaliseren. Tip nummer 4 heeft betrekking op het splitsen van tabellen. Als ik bovenstaande reacties goed begrijp, is dit een zinloze poging tot optimalisatie.

  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 13:46

Janoz

Moderator Devschuur®

!litemod

Je breekt normaal database gebruik ten behoeve van optimalisatie (Je kun nooit met slechts een atomaire operatie je database in een consistente staat houden. Je zult de inserts altijd in een transactie moeten doen). Doe dat pas wanneer je daadwerkelijk een efficientie probleem ontdekt en ook daadwerkelijk hebt kunnen meten dat een gepartitioneerde tabel dat op gaat lossen. Je doet het dus zeker niet vooraf al.

[Voor 22% gewijzigd door Janoz op 07-10-2010 14:15]

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee