Is dit database-ontwerp goed?

[Hatsekie_D]

Ik heb het volgende database-ontwerp gemaakt:

KLIK

Is dit een beetje een goed ontwerp waar ik echt mee verder kan?

Zoals te zien is gaat het om een winkelautomatisering.

[ReallyStupidGuy]

Dat is een behoorlijk uitgebreide database die je daar hebt :-)

Ik heb eigenlijk alleen naar de rechterbovenkant gekeken en mij viel vooral op dat je in de tabel personeel orders laat terugkomen.. Eigenlijk moet je aan een order gewoon een personeelsnummer hangen.

En ik ben nu voor mn stage bezig met CRM, dus meer klantgegevens, veel meer :-) !!

[Hatsekie_D]

ReallyStupidGuy schreef op 23 september 2003 @ 12:59:
Dat is een behoorlijk uitgebreide database die je daar hebt :-)

Ik heb eigenlijk alleen naar de rechterbovenkant gekeken en mij viel vooral op dat je in de tabel personeel orders laat terugkomen.. Eigenlijk moet je aan een order gewoon een personeelsnummer hangen.

En ik ben nu voor mn stage bezig met CRM, dus meer klantgegevens, veel meer :-) !!

orders is een boolean, die aangeeft of het personeelslid gerechtigd is orders aan te nemen en te verwerken
Dit geldt voor alles vanaf password in de tabel personeel.

P.s. dat was linksboven

[ Voor 3% gewijzigd door Hatsekie_D op 23-09-2003 13:10 ]

[Vlugge Japie]

Moet orders_facturen niet verplicht zijn, aangezien offerte_facturen en computer_facturen dat ook zijn?
(ik kan het mis hebben hoor, ik ben nog tamelijk een noob op het gebied van databases...).

[houthakker]

tot welke normaliseervorm ben je gegaan? alle veel-op-veel relaties eruit (heb geen tijd om hem goed na te kijken). Waarin heb je eigelijk het ontwerp gemaakt, volgens mij niet in dezign.

[Hatsekie_D]

Vlugge Japie schreef op 23 September 2003 @ 13:49:
Moet orders_facturen niet verplicht zijn, aangezien offerte_facturen en computer_facturen dat ook zijn?
(ik kan het mis hebben hoor, ik ben nog tamelijk een noob op het gebied van databases...).

Die stippellijn en doorgetrokken lijn heeft niets te maken met 'verplicht zijn' volgens mij, maar inderdaad: die moeten wel gelijk aan elkaar zijn. Ik ga even kijken hoe dat dan zit.

tot welke normaliseervorm ben je gegaan? alle veel-op-veel relaties eruit (heb geen tijd om hem goed na te kijken). Waarin heb je eigelijk het ontwerp gemaakt, volgens mij niet in dezign.

Ik heb nog niet echt uitgebreid genormaliseerd, ik heb het gewoon ingevuld zoals het mij goed leek. Veel-op-veel relaties zitten er niet in bij mijn weten
Het ontwerp is wél in Dezign gemaakt...

[ Voor 5% gewijzigd door Hatsekie_D op 23-09-2003 14:03 ]

[Hatsekie_D]

Ik heb nu wat aangepast in de relaties e.d., ik kan zo niet precies meer zeggen wat, maar niet echt rigoreuze wijzigingen.

Het nieuwe schema:
KLIK

Als ik nu dit schema exporteer naar een SQL bestand en dit laat uitvoeren op de database, krijg ik de volgende foutmelding:

ERROR: UNIQUE constraint matching given keys for referenced table "orders" not found

Dit begrijp ik dus niet helemaal, de combinatie van 3 sleutels is toch wel uniek bij mijn weten.

Iemand hier een oplossing voor?

[TheGhostInc]

Even zomaar een opmerking tussendoor:

Ik zie 3 tabellen met eigenlijk maar 1 ding erin,
computer, offerte en order facturen.

Hoewel dit misschien helemaal volgens het boekje is, en ik geen zin heb om dat na te zoeken... bedenk even het volgende:
Als het een daadwerkelijk systeem moet worden waarbij snelheid een issue kan worden, dan wordt je database niet blij van dat soort grapjes.

Het is namelijk weer een tabel extra die geladen moet worden, waarbij vaak blijkt dat je meteen daarna toch de rest van de gegevens nodig hebt, voorbeeld:

Stel je hebt een offerte, en je wil de factuur hebben, moet je eerst het nr. opvragen en daarna pas de factuur. Terwijl het logisch is dat als je vanuit offerte naar een factuur wil, dat je dan de factuur wil hebben.

Dit zijn overigens overwegingen die je in real-life moet testen, als je voor school een opdracht moet doen.... forget what I said.

[Hatsekie_D]

TheGhostInc schreef op 24 September 2003 @ 14:56:
Even zomaar een opmerking tussendoor:

Ik zie 3 tabellen met eigenlijk maar 1 ding erin,
computer, offerte en order facturen.

Hoewel dit misschien helemaal volgens het boekje is, en ik geen zin heb om dat na te zoeken... bedenk even het volgende:
Als het een daadwerkelijk systeem moet worden waarbij snelheid een issue kan worden, dan wordt je database niet blij van dat soort grapjes.

Het is namelijk weer een tabel extra die geladen moet worden, waarbij vaak blijkt dat je meteen daarna toch de rest van de gegevens nodig hebt, voorbeeld:

Stel je hebt een offerte, en je wil de factuur hebben, moet je eerst het nr. opvragen en daarna pas de factuur. Terwijl het logisch is dat als je vanuit offerte naar een factuur wil, dat je dan de factuur wil hebben.

Dit zijn overigens overwegingen die je in real-life moet testen, als je voor school een opdracht moet doen.... forget what I said.

Het is voor een bedrijf dus snelheid is op zich best van belang, maar ik heb hiervoor gekozen omdat niet elke computer, order en offerte een bijbehorende factuur heeft.
Als ik dit niet zo zou doen zou je veel NULL waarden krijgen, wat mij ook afgeleerd is

[bille]

een kort blik levert mij de volgende vraag op omtrent facturen, offerten en klanten.

Een factuur kan alleen bestaan als er een offerte bestaat. Een offerte wordt uitgebracht naar een klant. Zodoende hoeft in de tabel Factuur geen Klantnr opgenomen te worden, want die kan je opvragen via de Offerte.

Tevens snap ik de ogenschijnlijke N-op-N relatie tussen facturen en offerten niet helemaal Kan 1 offerte meerdere facturen hebben? Ja lijkt me. Kan 1 factuur bij meerdere offerten staan? Nee lijkt me. Toch bestaat er een tabel Offerte_facturen waarin je meerdere facturen met meerdere offerten kan combineren. Wat je liever hebt waarschijnlijk is het Offertenr als FK in de tabel Facturen. Zodat iedere Factuur maximaal 1 Offerte kent en 1 Offerte meerdere Facturen.

Nog een ding: Je neemt zowel in de tabel Artikelen als de tabel Offerte_regel het leveranciersnr op. Dit is niet nodig, je kan de leverancier van een artikel opvragen via de Artikelen tabel. Ook de verkoopprijs van een Artikel is redundant opgenomen in zowel Offerte_regel als in Artikel.

[edit]
ook vraag ik me af wat het verschil is tussen een offerte en een order.. aan de hand van welke van de twee wordt de factuur opgesteld?

maar ik heb hiervoor gekozen omdat niet elke computer, order en offerte een bijbehorende factuur heeft. Als ik dit niet zo zou doen zou je veel NULL waarden krijgen, wat mij ook afgeleerd is

door wie is je dat afgeleerd? waar zit je in godesnaam op school?

Waar jij als informaticus voor verantwoordelijk wordt gehouden:
Kan je straks nog opvragen welke computer verkocht is aan welke klant of als een klant met een factuur komt welke computer dat is geweest? Met de offerte erbij e.d.? DAT is belangrijk..

[ Voor 26% gewijzigd door bille op 24-09-2003 15:59 . Reden: bleh ]

[Hatsekie_D]

bille schreef op 24 september 2003 @ 15:48:
een kort blik levert mij de volgende vraag op omtrent facturen, offerten en klanten.

Een factuur kan alleen bestaan als er een offerte bestaat. Een offerte wordt uitgebracht naar een klant. Zodoende hoeft in de tabel Factuur geen Klantnr opgenomen te worden, want die kan je opvragen via de Offerte.

Er bestaat ook nog zoiets als losse verkoop, zonder offerte dus.

Tevens snap ik de ogenschijnlijke N-op-N relatie tussen facturen en offerten niet helemaal Kan 1 offerte meerdere facturen hebben? Ja lijkt me.
Kan 1 factuur bij meerdere offerten staan? Nee lijkt me.
Toch bestaat er een tabel Offerte_facturen waarin je meerdere facturen met meerdere offerten kan combineren. Wat je liever hebt waarschijnlijk is het Offertenr als FK in de tabel Facturen. Zodat iedere Factuur maximaal 1 Offerte kent en 1 Offerte meerdere Facturen.

Zie mijn vorige reply: Niet elke offerte heeft een factuur en niet elke factuur heeft een offerte. Vandaar die losse tabel.
Ik heb het nu zo gemaakt dat één factuur uit meerdere offertes kan bestaan, maar dat hoeft niet per sé. Er kunnen niet meerdere facturen gemaakt worden van één offerte.

Nog een ding: Je neemt zowel in de tabel Artikelen als de tabel Offerte_regel het leveranciersnr op. Dit is niet nodig, je kan de leverancier van een artikel opvragen via de Artikelen tabel.

Een artikel kan van verschillende leveranciers komen, vandaar de combinatiesleutel. Klopt wel volgens mij dus

Ook de verkoopprijs van een Artikel is redundant opgenomen in zowel Offerte_regel als in Artikel.

Nee, als een verkoopprijs verandert nadat de offerte (of factuur, daarvoor geldt hetzelfde) is opgesteld, moet de bij opmaak geldende prijs bewaard blijven.

Sorry als het antwoord soms misschien wat hard overkomt, ik waardeer uw reactie zeer

[Freakertje]

Een kleine tip: Misschien is het handig als je de datadictionary hier ook neer zet, dan kan iedereen zien wat je precies met de kolommen bedoeld

[Verwijderd]

offtopic:
Waar heb je dit schema mee gemaakt? Niet visio toch?

[Verwijderd]

Verwijderd schreef op 24 September 2003 @ 19:23:

offtopic:
Waar heb je dit schema mee gemaakt? Niet visio toch?

Volgens mij schreef hij hier boven dat het met DeZign gemaakt is.

[Verwijderd]

Verwijderd schreef op 24 september 2003 @ 19:23:

offtopic:
Laat maar. Moet leren lezen

[ATS]

@HPE Als het topic even doorleest, dan zie het het vanzelf...

[Crazy D]

Hatsekie_D schreef op 24 september 2003 @ 15:59:
Een artikel kan van verschillende leveranciers komen, vandaar de combinatiesleutel. Klopt wel volgens mij dus

Is het van belang om in de offerte te weten van welke leverancier het produkt komt? Het lijkt met dat als je bv een MerkX laptop hebt, die door bedrijf X en bedrijf Y geleverd kunnen worden, het niet voor de offerte van belang is bij welke leverancier het produkt vandaan komt. Voor de offerte (en de order, en de faktuur), is het alleen van belang dat je weet dat het een MerkX laptop is, die jullie voor bedrag X verkopen. Hoe jullie aan die laptop komen, boeit niet echt voor de verkoop. Dat zul je waarschijnlijk bepalen aan de hand van welke leverancier het artikel op voorraad heeft, en/of de korting die je kunt bedingen. In dat geval zou ik geen leverancier opnemen in de offerte, maar een koppeltabel gebruiken tussen artikelen en leveranciers ("artikelen per leverancier").
Als je naderhand wat gegevens wilt hebben over hoeveel winst je precies hebt gemaakt op een produkt, koppel je je bestellingen (jullie bestellingen bij de leveranciers dus) aan een offerte/order/faktuur, zodat je aan de hand daarvan kunt nagaan bij wie jullie voor klant Pietje zijn laptop hebben gekocht.

Het is in dat opzicht ook niet zo heel logisch om in een artikelen tabel een samengestelde sleutel op Artikelnummer en Leverancier te hebben. Het artikelnummer wordt niet anders wanneer de leverancier verandert (en zo wel, heb je alsnog een uniek artikelnummer....).

[bille]

Sorry als het antwoord soms misschien wat hard overkomt, ik waardeer uw reactie zeer

*snik snik* * bille gaat in een hoekje zitten huilen hehe.. neej hoor.. zo denk jij nog es na waarom je bepaalde dingen gedaan hebt en of ze wel correct zijn.

Overgens geeft dit wel aan dat het klaarblijkelijk moeilijk is een model te beoordelen zonder de achterliggende gedachtengang te kennen. Misschien iets wat je kan onthouden als je dit model wilt presenteren aan een leraar / manager.. zorg dat je goede ontwerpdocumentatie hebt.. anders kunnen mensen er weinig mee

[edit]
overgens kan ik nog wel iets leuks bedenken met: artikel, leverancier, inkoopprijs en verkoopprijs.
Zou er namelijk niet eigelijk een N-op-N relatie moeten zijn tussen leverancier en artikel? Of wil je meerdere keren dezelfde artikelnaam gaan opnemen met verschillende leveranciers? Inkoopprijs is gekoppeld aan artikel-leverancier combinatie, maar verkoopprijs niet.. dus eigelijk zou ik verwachten een tabel met allemaal artikelen.. een tabel met allemaal leveranciers.. en een tussentabel waarin je de leverancier koppelt aan een artikel en je de bijbehorende inkoopprijs vermeldt. In de tabel Artikel zet je vervolgens de verkoopprijs...

Misschien theoretisch geneuzel.. dit zal ook werken, maar feitelijk zit er nog wel het één en andere redundant

[ Voor 40% gewijzigd door bille op 25-09-2003 18:13 ]

[marenk_vos]

Hoef je in deze database geen inkoop korting bij leverancier op te nemen, lijkt me dat dit toch wel van in de meeste REAL-LIFE situaties van toepassing is.

En minimale verkoopprijs (een soort van inkoopprijs-inkoopkorting + overheadkosten) meestal handig voor verkopers om te kijken hoeveel speling ze hebben bij verkoop van producten.

Hoe ga je om met de order-tabel, het aantal wat is dat voor aantal? Het aantal dat in order staat vanuit de levering richting de klant of het aantal dat het bedrijf op order heeft voor zijn eigen voorraad?

Heb je ook nog een bestelling tabel nodig, voor inkopers om bestellingen samen te stellen?

[Verwijderd]

Ik snap de entiteit computer niet helemaal in dit ERD...

Aangezien computers niet op offertes en orders staan ga ik ervan uit dat je de entiteit computers alleen gebruikt tijdens reparaties. Wat ik alleen niet snap is waarom je de complete inhoud van een computer gaat administreren en niet alleen de gerepareerde onderdelen.
Handiger lijkt mij om bij de reparatie gewoon het klantnr optenemen. Uiteraard moeten de kosten voor een reparatie wel gefactureerd worden dus die relatie moet je nog wel leggen.

Factuur_regel:
Voeg een factuurregelnr toe en maak van artikelnr en leveranciernr FK om te voorkomen dat je verplicht bent om alleen bestaande artikelen van bekende leveranciers aan te slaan op een factuur. Door ook nog een opmerkingen veld toe te voegen geef je je eindgebruikers enorm veel vrijheid. "10 euro extra korting ivm te late levering" kan dan ook gewoon op de factuur komen te staan.

Datzelfde geintje kan je ook toepassen bij offerte_regel en reparatie_regel zodat de gebruikers meer informatie kunnen verschaffen omtrent gedane offertes en reparaties

[Stewie!]

je fout:

er bestaan geen factuuradressen/afleveradressen/telefoon werk in je systeem. Effe toevoegen aan klanten!

[voodoo202]

Ik zou het personeels bestand uitbreiden, met extra adressen, en evt. telefoonnummers.
Want het factuur adres wijkt meestal wel af van het bezorgadres. En mensen hebben meestal meerdere telefoonnummers, die kun je dan mooi opslaan in een aparte tabel gekoppeld aan de persoon.

[Hatsekie_D]

In elk geval weer bedankt voor de vele reacties, ik zal even weer aan het puzzelen gaan in mijn ontwerp.
Zodra ik weer een versie klaar heb zal ik 'm wel weer posten.

[Xymox]

Eh, hoort dit topic niet in Devschuur thuis ?

[Hatsekie_D]

voodoo202 schreef op 26 September 2003 @ 01:05:
Ik zou het personeels bestand uitbreiden, met extra adressen, en evt. telefoonnummers.
Want het factuur adres wijkt meestal wel af van het bezorgadres. En mensen hebben meestal meerdere telefoonnummers, die kun je dan mooi opslaan in een aparte tabel gekoppeld aan de persoon.

Ook @ DaMorpheus:
Ik heb het met de opdrachtgever er over gehad, hij vond dat er voldoende informatie over de klanten kan worden opgeslagen, dus ben ik het daar uiteraard wel mee eens

Weer het een en ander aangepast:
KLIK

[Verwijderd]

Hieronder een alternatief ontwerp, met slechts de kern van je project.

Lijkt me sowieso wel verstandig om eerst met je opdrachtgever duidelijk te bepalen wat hij allemaal in het systeem wil (functioneel ontwerp) voordat je met de rest begint

Relaties tussen je facturen en je reparaties/offertes kan je er nog bij leggen.




Tips:
Een history van je voorraad kan erg handig zijn
Self-referencing-relation op Artikelgroep

[Hatsekie_D]

Verwijderd schreef op 26 September 2003 @ 23:27:
Lijkt me sowieso wel verstandig om eerst met je opdrachtgever duidelijk te bepalen wat hij allemaal in het systeem wil (functioneel ontwerp) voordat je met de rest begint

Ja, vooral als de opdrachtgever (=stagebegeleider) steeds nieuwe dingen bedenkt en van mening verandert
Ik heb wel een Requirements en Specifications-document maar dat moet dus telkens aangepast worden...

[afbeelding]

Heel erg bedankt voor deze moeite, ik zal er zeker eens naar kijken (maar volgens mij is dit grotendeels hetzelfde als wat ik heb, maar dan wat overzichtelijker weergegeven

Tips:
Een history van je voorraad kan erg handig zijn
Self-referencing-relation op Artikelgroep

Say what?

Waar kan dat precies handig voor zijn?

Ik zie net dat ik Voorraad er nog helemaal niet in heb zitten, dit doe ik gewoon als veld bij artikelen. Lijkt me het makkelijkst.

[Verwijderd]

Ja, vooral als de opdrachtgever (=stagebegeleider) steeds nieuwe dingen bedenkt en van mening verandert

Opdrachtgevers hebben het recht om van mening te veranderen, maar jij hebt een deadline te halen... en die twee gaan niet altijd hand-in-hand. Vaak is werken met deel-opleveringen een goed alternatief.

Waar kan dat precies handig voor zijn?

Het doel van een systeem is vaak niet alleen registratie van gegevens, maar ook het opvragen daarvan. Ik kan me voorstellen dat je opdrachtgever het historisch verloop van z'n voorraad wil kunnen zien.

maar volgens mij is dit grotendeels hetzelfde als wat ik heb

Het schema was om te verduidelijken, dat je project volgens mij prima zonder de entiteit "computer" kan, en dat je het in het begin simpel moet houden.

Say what?

hehe srry, ik bedoel dus een Parent-Child structuur in je ArtikelGroep tabel, zodat je een oneindig aantal niveaus sub-artikelgroepen per hoofd-artikelgroep kunt creeeren.

BTW, voor welke opleiding is het ?

BTW2, ik moet me er ook niet zoveel mee bemoeien Schema's maken is geen wiskunde, er zijn meerdere wegen die naar Utrecht leiden

[Hatsekie_D]

Verwijderd schreef op 01 October 2003 @ 23:28:
Het doel van een systeem is vaak niet alleen registratie van gegevens, maar ook het opvragen daarvan. Ik kan me voorstellen dat je opdrachtgever het historisch verloop van z'n voorraad wil kunnen zien.

Ik zal eens vragen of dit de bedoeling is

hehe srry, ik bedoel dus een Parent-Child structuur in je ArtikelGroep tabel, zodat je een oneindig aantal niveaus sub-artikelgroepen per hoofd-artikelgroep kunt creeeren.

BTW, voor welke opleiding is het ?

Ik doe HIO... maar dit soort dingen moet ik blijkbaar nog wel even aan werken

BTW2, ik moet me er ook niet zoveel mee bemoeien Schema's maken is geen wiskunde, er zijn meerdere wegen die naar Utrecht leiden

Deze 'bemoeienissen' stel ik wel op prijs hoor