SQL database design vraag i.v.m. validatie

Pagina: 1
Acties:

Onderwerpen

Vraag


Acties:
  • 0 Henk 'm!

  • LoveCode
  • Registratie: Januari 2017
  • Laatst online: 16-11-2017
ERD edit:
Afbeeldingslocatie: https://postimg.org/image/5ul6o8fen/


Vraag i.v.m. een ERD ontwerp t.b.v. een studie de vraag met de deadline van 23-1-2017 om 12:00 uur ben ik opzoek naar validatie t.a.v. het database ontwerp en correcte implementatie hiervan in SQL Server / Acces.

Ik vraag me af of de entiteiten en relatie zoals beschreven / afgebeeld zin niet gewijzigd moet worden om te voldoen aan de onderstaande Business Requirements\.

Qua validatie van de data zie ik twee opties:
Optie 1. een Alternative Key toevoegen aan de entiteit verzekering- die gekoppeld is aan verhuren fietsen. Zorgt voor vraag of dit ervoor zorgt dat de ERD voldoet aan de Business Requirements/
Optie 2, Het verwijderen van de one-to-one relatie tussen verhuur-klanttabel en deze creëren tussen de verhuur_has_fiets tabel?


Business Requirements:
1. Alleen de fietsen zijn verzekerd
2. Geboekte fietsen zijn omwisselbaar, alleen als er voorraad is.
3. email moet uniek zijn
4. Het personeel voert meerdere rollen uit.
5. Accessoires zoals helmen ectr. zijn alleen te boeken mits er minimaal 1 fiets gehuurd is.
6. Het geslacht moet ‘M’ (man) of ‘V’ (vrouw) bevatten.
7. De einddatum moet op of na de verhuurdatum liggen.
8. De schade_betaaldatum komt na de schadedatum
9 Zeven relevante constrains:
9.1. insert rules:
- email moet unique zijn
- verhuurdatum is de huidige datum of na de verhuurdatum liggen.
9.2. Update constrains:
- aanmelding kan niet als het emailadress null is.
- Het Klant_ID is niet te veranderen.
- bij niet bestaande ID's wordt er een error weergegeven.
9.3. Delete Rules:
- records worden per record verwijderd niet in bulk.
- In een aparte tabel wordt er een log bijgehouden wanneer CRUD acties per user heeft plaatsgevonden

ERD Edit:
Afbeeldingslocatie: https://s27.postimg.org/5ul6o8fen/ER_Diagram_22_1_2017.jpg

[ Voor 10% gewijzigd door LoveCode op 22-01-2017 22:00 ]

Alle reacties


Acties:
  • 0 Henk 'm!

  • EvilWhiteDragon
  • Registratie: Februari 2003
  • Laatst online: 11-09 12:12
Ik weet niet goed wat nu je vraag is, maar een fiets is altijd verzekerd; dan kan je de verzekering dus aan de fiets hangen. Daarmee zijn je accessoires en/of verhuuractie ook direct onverzekerd ;) Dan zit je nog wel met de vraag of er 1 polisnummer per fiets is, of dat meerdere fietsen een polis hebben (en kan een polis/fietscombinatie wijzigen?)

LinkedIn
BlackIntel


Acties:
  • 0 Henk 'm!

Verwijderd

LoveCode schreef op zondag 22 januari 2017 @ 00:18:
6. Het geslacht moet ‘M’ (man) of ‘V’ (vrouw) bevatten.
Dit heeft niets met de vraag te maken, maar wel met je ontwerp:

Het geslacht moet m of v bevatten, het mag dus niet iets anders zijn ook niet NULL.
Waarom is het veld geslacht dan een NULL veld? En kijk ook eens naar die varchar(50), want die klopt ook niet voor geslacht.

Vanwaar je keuze om van alle kolommen die geen relatie aangeven of key zijn NULL velden te maken?
En waarom bijna alles varchar(50)?

[ Voor 11% gewijzigd door Verwijderd op 22-01-2017 02:59 . Reden: Toevoegingen ]


Acties:
  • 0 Henk 'm!

  • LoveCode
  • Registratie: Januari 2017
  • Laatst online: 16-11-2017
EvilWhiteDragon: Goed opgemerkt. Je vraag of er 1 polisnummer per fiets is, of dat meerdere fietsen een polis hebben (en kan een polis/fietscombinatie wijzigen?) is i.v.m. de uitwerking om dit te aan te passen.
Welke wijzigingen moet ik in het ERD doorvoeren zodat zowel:
- groepsboekingen xxx fietsen op basis van 1 polisnr en 1 rekening,
- xx fietsen met ieder een uniekpolisnr / rekening correct in database verwerkt worden)?

NR: Bedankt voor de tip.