Graag commentaar op database ontwerp

[Reveller]

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



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 ]

[Reveller]

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 *

[Reveller]

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 ]