Database ontwerp

[erwink]

Hallo,

Ik ben met een delphi project bezig waar ik een database moet ontwerpen.

Ik ga gebruik maken van een access database.

Ik wil 1 database maken met alle producten(waarschijnlijk gaat dit niet lukken)
Ik heb een aantal producten van de merken a, b, c, d, e

Elk merk heeft verschillende waardes, cv's genoemd.

De eerste 10 cv's zijn bij alle merken hetzelfde.

De overige zijn verschillend. BV merk b heeft totaal 250 CV's en merk a 75.

Daarnaast is het zo dat met a op cv 11 de waarde heeft deur open/dicht en bij merk b zit daar licht aan of uit.

Tevens is het zo dat er niet alleen de waarde 0 of 1 mogelijk is maar bv ook tussen de waarde 0 tot 255. Enkele cv's kunnen ook een subwaarde hebben. bv CV 12.1 en cv 12.2.

Het komt te hangen aan een delphi programma die tabbladen heeft. bv staandaard gegevens dit zijn dan bv de waarden van licht aan uit, deur open dicht maar deze komen dus niet in de eertse 10cv's.

Elk merk heeft deze op een andere cv lokatie staan.

Heeft iemand een iedee hoe ik dit het beste kan gaan opzetten.

[Boudewijn]

wat heb je zelf al uitgekiend?
ik vind dit beetje script-request achtig aandoen, verbeter me aub als ik het fout doe

[Boss]

Ja, eerst eens goed nadenken over een objecten model. De keuze van je database (Access) en programmeertaal (Delphi) zijn hier totaal ondergeschikt aan.

Ik denk zo even snel aan:
- Een tabel merken
- Een tabel producten
- Een tabel met CV's bij de producten

Op die manier kan je bij ieder product net zo veel CV's toevoegen als je wil (whatever een CV ook mag zijn, blijkt niet echt uit je beschrijving. Maar het is vast iets belangrijks!)

Je opmerking dat het waarschijnlijk in 1 database niet gaat lukken lijkt me ook overbodig. Ik denk dat je denk dat het in 1 tabel niet gaat lukken, maar een database kan natuurlijk meerdere tabellen bevatten.

offtopic:
[quote]Boudewijn schreef op maandag 13 februari 2006 @ 17:09:
wat heb je zelf al uitgekiend?
ik vind dit beetje script-request achtig aandoen, verbeter me aub als ik het fout doe
[/quote]
Daar heb je dan toch de schop-een-modje knop voor ipv een overbodige bijdrage?

[ Voor 21% gewijzigd door Boss op 13-02-2006 17:13 ]

[NMe]

Wat verwacht je nu van dit topic? Dat mensen hun verzonnen model zo voor je uit gaan schrijven zodat jij het uit kan werken? Je zal gewoon een overzicht moeten opstellen van alle eisen die er aan je database en/of applicatie hangen. Vervolgens zul je op basis daarvan enkele tabellen moeten verzinnen, die je vervolgens gaat normaliseren. Wat ben je daarbij voor problemen tegengekomen? Waar zit volgens jou een probleem? Wat is je precies niet duidelijk? Het is hier uitdrukkelijk niet de bedoeling om gewoon een vraag te dumpen en dan maar te wachten op een antwoord. We willen ook wat moeite van jouw kant zien.

Kort samengevat: wat zijn je eigen gedachten over dit probleem?

[erwink]

Sluit dit topic maar.

Jammer dat een beginneling die nog nooit een db gemaakt heeft of genormaliseerd heeft geen vraag kan stellen.

Een reactie zoals boss, daar zou ik mee verder kunnen gaan stoeien.

Ik heb er zelf ook heel wat tijd in zitten om een idee te krijgen maar heb dit helaas niet kunnen bedenken. en dus ook niet uit te schrijven.

In 1 database is het iig niet voor elkaar te krijgen en om voor elk merk een tabel te maken lijkt mij ook niet handig.

Ik had gehoopt enkele tips te krijgen, ipv dat ik gelijk een script vraag of compleet voorgekaud db.

[Thefirstikke]

Als je nou zelf al wat had bedacht, ok. Maar dit is toch echt een standaard google vraag. Er staan zo ontzettend veel tutorials op het net, dat je makkelijk zelf al de nodige kennis op had kunnen doen.

[Arnout]

Maak gewoon een uitwerking en plaats die hier. Dat komt al een stuk beter over dan de stoffige topicstart zoals die nu is. Dus gewoon even schetsen hoe jij je model in gedachten had, en niet alleen maar vragen hoe het zou moeten. We willen best helpen maar dan moet je zelf ook genoeg moeite ervoor willen doen.

[Jaspertje]

Wat dus zou kunnen helpen is (een deel van) je datamodel hier neer te zetten, zodat we daar op en aanmerkingen over kunnen geven, dan maakt het al meteen een heel andere indruk. Het is hier niet de bedoeling om je weg te jagen, maar je vraag komt heel simplitisch over thats all

[Varienaja]

ernieek schreef op maandag 13 februari 2006 @ 19:23:
Sluit dit topic maar.

Aggos.. kan je niet tegen een beetje feedback?!

Jammer dat een beginneling die nog nooit een db gemaakt heeft of genormaliseerd heeft geen vraag kan stellen.

Ik begrijp niet waar je dat vandaan haalt. Echter, het is wel zo dat het hier geen school is. Van beginsel af aan dingen uitleggen doen we hier niet. Als je databases wilt leren maken moet je gewoon boeken kopen, cursussen doen, tutorials doornemen, etc. Als tijdens die activiteiten vragen hebt kan je hier prima terecht.

Ik heb er zelf ook heel wat tijd in zitten om een idee te krijgen maar heb dit helaas niet kunnen bedenken. en dus ook niet uit te schrijven.

Aan denken heb je niet zoveel, als je dingen moet leren. Doen, doen, doen en nog eens doen. Daar leer je pas van!

In 1 database is het iig niet voor elkaar te krijgen en om voor elk merk een tabel te maken lijkt mij ook niet handig.

Ik had gehoopt enkele tips te krijgen, ipv dat ik gelijk een script vraag of compleet voorgekaud db.

Alvast 1 tip (die overigens al gegeven is): het kan prima in 1 database, maar het kan zeker niet in 1 tabel. Het lijkt mij persoonlijk overigens wel zeer handig om gegevens die niet bij elkaar horen in aparte tabellen op te nemen.

Ik ontwikkel meestal obejct-georienteerd. Het datamodel maak ik pas als ik mn objectenmodel af heb. Daarbj houd ik overigens altijd rekening dat het gemakkelijk in een Hibernate-mapping te zetten moet zijn.

[dusty]

ernieek schreef op maandag 13 februari 2006 @ 17:07:
[..]
Heeft iemand een iedee hoe ik dit het beste kan gaan opzetten.

Schrijf elke voorwaarde in een regel op.

Bepaal welke data je in je database wilt hebben aan de hand van die voorwaarden.

Stel je tabellen op en ga normaliseren.

Denk je dat je klaar bent met normaliseren kan je altijd terecht of je database correct is genormaliseerd. ( laat je ook meteen zien welke stappen je allemaal ondernomen hebt, en kunnen mensen je vertellen als je ergens een fout hebt gemaakt en wat je dus anders moet doen.

Modbreak:

offtopic na dit bericht geeft kans op een waarschuwing

[ Voor 6% gewijzigd door dusty op 13-02-2006 19:36 ]

[The Wrecker]

Het is ook niet de bedoelign om voor elk merk een tabel aan te maken. Maar een tabel met merken erin.

Daarnaast met die cv's kan je niet aangeven dat het ene cv een deur heeft en de andere niet? lijkt me gewoon een boolean waarde. Of misschien kan je dat zelfs met een integer oplossen (binaire waarde 110011 ) en dat vergelijken. Gaat misschien wat sneller.

[erwink]

Oke, Ik ga vanavond eens kijken hoe ik mijn opzet die ik in gedachten had kan visualiseren

en ja ik kan wel tegen kritiek alleen lijkt het wel of verschillende forums en niet alleen tweakers maar vele anderen de mensen het altijd beter weten door je naar google te sturen, of denken dat iedereen alles kan.

Ik bedoel ik wil graag leren maar het betekend niet dat ik voor 1 database verschillende cursusen en boeken hoef te gaan aanschaffen. en nee ik heb het dan niet over de simpele goedkope boeken maar die dikke pillen en dure cursusen.


maar zoals gezegt, ik zal het in een schema zetten en dan hoor ik daar graag reacties op positief en negatief.

[Thefirstikke]

Met google zijn genoeg simpele gratis tutorals te vinden waarmee je een heel eind opweg komt hoor.

Om je een voorzetje te geven:
http://www.geekgirls.com/databases_from_scratch_1.htm

Eerste hit in google, vertelt je genoeg om de basis te begrijpen. En gratis ook nog

[ Voor 3% gewijzigd door Thefirstikke op 13-02-2006 22:19 ]

[Verwijderd]

hier mijn suggesties:

tabel product
tabel product beschrijving
tabel CV
tabel CV beschrijving
tabel Merk
tabel Merk beschrijving

is in principe een aanvulling wat Boss al heeft gepost.

de extra tabellen zijn toegevoegd om dupplicatie te voorkomen. Waarschijnlijk moeten er meer tabellen bij komen maar dat kan komt niet echt duidelijk naar voren uit jouw verhaal

[NMe]

Aparte tabellen voor beschrijvingen die 1 op 1 gekoppeld zijn aan records in de "gewone" tabellen? Lijkt me niet echt zinvol. Alleen als een beschrijving meestal niet nodig is mag dit volgens de normalisatieregels.

[Verwijderd]

-NMe- schreef op dinsdag 14 februari 2006 @ 07:17:
Aparte tabellen voor beschrijvingen die 1 op 1 gekoppeld zijn aan records in de "gewone" tabellen? Lijkt me niet echt zinvol. Alleen als een beschrijving meestal niet nodig is mag dit volgens de normalisatieregels.

Want? Het is een van de drie manieren om overerving te implementeren in een relationeel model. Los van performance is het een keurig design.

Of boss dat ook bedoelde, dat is me niet helemaal duidelijk.

[ Voor 10% gewijzigd door Verwijderd op 14-02-2006 07:41 ]

[Boss]

Verwijderd schreef op dinsdag 14 februari 2006 @ 07:39:
[...]
Of boss dat ook bedoelde, dat is me niet helemaal duidelijk.

Nou, in mijn database modellen gebruik ik inderdaad meestal maar 1 tabel voor bijvoorbeeld Merk. Ik zie er ook niet echt voordeel in om een tabel Merk en MerkOmschrijving te maken en daar een 1-op-1 relatie tussen te leggen.

Wat zou daar dan het voordeel van zijn?

[Verwijderd]

Ik bedoelde eigelijk de gebruiker 'b'. Anyways, je kunt een op een relaties gebruiken om overerving in een database te realiseren. Door simpelweg attributen van het afgeleide type op te nemen in een apparte tabel met een relatie naar de parent tabel.

Performance wise niet zo leuk, maar je db ziet er wel clean uit.

[NMe]

Anders dan een performance-issue kan ik me niet voorstellen dat een 1:1-relatie op een dergelijke manier handig is. Wat wel zou kunnen is een aparte tabel waar je alle beschrijvingen in duwt voor alle soorten tabellen, maar dat is helemaal smerig en daarbij verlies je je performancewinst helemaal door een complexere join-operatie. Wanneer het ene record uit de ene tabel altijd gelinkt is aan één record uit de andere tabel, dan is één van beide tabellen overbodig IMO.

[RobLemmens]

Boss schreef op dinsdag 14 februari 2006 @ 08:49:
[...]

Nou, in mijn database modellen gebruik ik inderdaad meestal maar 1 tabel voor bijvoorbeeld Merk. Ik zie er ook niet echt voordeel in om een tabel Merk en MerkOmschrijving te maken en daar een 1-op-1 relatie tussen te leggen.

Wat zou daar dan het voordeel van zijn?

Het enige wat ik me kan bedenken is een omschrijving in meerdere talen.

[Pete]

RobLemmens schreef op dinsdag 14 februari 2006 @ 13:39:
[...]


Het enige wat ik me kan bedenken is een omschrijving in meerdere talen.

maar dan is het geen 1:1 relatie meer

[ElCondor]

ernieek schreef op maandag 13 februari 2006 @ 21:41:
Oke, Ik ga vanavond eens kijken hoe ik mijn opzet die ik in gedachten had kan visualiseren

en ja ik kan wel tegen kritiek alleen lijkt het wel of verschillende forums en niet alleen tweakers maar vele anderen de mensen het altijd beter weten door je naar google te sturen, of denken dat iedereen alles kan.

Ik bedoel ik wil graag leren maar het betekend niet dat ik voor 1 database verschillende cursusen en boeken hoef te gaan aanschaffen. en nee ik heb het dan niet over de simpele goedkope boeken maar die dikke pillen en dure cursusen.


maar zoals gezegt, ik zal het in een schema zetten en dan hoor ik daar graag reacties op positief en negatief.

* ElCondor aait over bolletje.
We zien een schema graag tegemoet.
Hoe 'dom' een schema ook is, het helpt ons ALTIJD een wat beter beeld te krijgen met wat je precies zoekt, en, zoals door anderen wordt aangegeven, het getuigd van inzet.
Natuurlijk heb je al boeken en tutorials bekeken op het internet, maar dat kunnen wij niet ruiken. Zet dat er duidelijk bij, en geef bijvoorbeeld aan WAT je precies hebt bekeken.
We kunnen je dan altijd nog aan de hand van die tutorials in de juiste richting sturen.
Zit niet bij de pakken neer, wees geen huilie maar maak iets moois van je schema. Je zult er altijd iets van kunnen gebruiken. Voor de meeste mensen is het, het makkelijkst om iets te visualiseren.
Ik begin zelf ook een beetje te klooien met Db's en dat vergt veel tekeken, hertekenen en nog eens tekenen. Zo leer je dat. Daar heb je geen cursus voor nodig, alleen logisch denken.

Zet op een rij wat je in je database wilt registreren. Wat is het allerbelangrijkste.
Verzin vervolgens welke eigenschappen dit item heeft, en of die eigenschappen weer subeigenschappen hebben. Als dat zo is, dan loont het vaak de moeite om voor een specifiek eigenschap een eigen tabel te maken, met de daar aan te koppelen sub-eigenschappen daarin. Zoe hoe je nooit een sub-eigenschap te herdefiniëren.

Succes ermee, ik zal dit met interesse volgen.

[Janoz]

Verwijderd schreef op dinsdag 14 februari 2006 @ 07:39:
[...]

Want? Het is een van de drie manieren om overerving te implementeren in een relationeel model. Los van performance is het een keurig design.

Puur miereneukerig gezien spreek je bij zo'n ORM toepassing niet over 1 op 1, maar 1 op [0,1] of 1:N met N<=1.

[Verwijderd]

Janoz schreef op dinsdag 14 februari 2006 @ 15:57:
Puur miereneukerig gezien spreek je bij zo'n ORM toepassing niet over 1 op 1, maar 1 op [0,1] of 1:N met N<=1.

I know. Het ging mij meer om wat 'b' bedoelde. Ik gok dus op het eerder beschreven design om overerving te ondersteunen.

[ Voor 25% gewijzigd door Verwijderd op 14-02-2006 16:27 ]

[Verwijderd]

Ik heb inprincipe alleen de normalisatie regel toegepast. Uiteraard zijn de tabellen voor beschrijving niet nodig. Deze kunnen in principe toegevoegd worden in andere tabellen. Maar als je dit doet krijg je dupplicatie (wat tegen de normalisatie regel ingaat). Vandaar dus. Dus mocht je een beschrijving van bijvoorbeeld een merk willen veranderen dan moet je dat ook in de andere records van je database wijzigen. Als je die beschrijving in een apparte tabel plaatst hoef je de wijziging alleen maar op een plaatst te wijzigen. Uiteraard zal het de performance niet goed doen maar ja dit kan denk ik deels opgelost worden door gebruik te maken van stored procedures. Daarnaast is de keuze om de beschrijvingen in apparte tabellen op te nemen beter als er regelmatig nieuwe producten bijkomen en of verdwijnen.

[NMe]

Een beschrijving die inhoudelijk slechts afhankelijk is van één record, en waarbij de relatie 1 op 1 is opsplitsen naar een aparte tabel is niet volgens de normalisatieregels. Je bent op dat moment aan het denormaliseren, wat af en toe handig kan zijn en je performance ten goede kan komen, maar in dit geval is dat niet zo.

[Verwijderd]

-NMe- schreef op dinsdag 14 februari 2006 @ 22:21:
Een beschrijving die inhoudelijk slechts afhankelijk is van één record, en waarbij de relatie 1 op 1 is opsplitsen naar een aparte tabel is niet volgens de normalisatieregels. Je bent op dat moment aan het denormaliseren, wat af en toe handig kan zijn en je performance ten goede kan komen, maar in dit geval is dat niet zo.

hmm ik kan het mis hebben hoor maar volgens mij is het toepassen van het hele normalisatie gebeuren om oa dupplicatie te verwijderen (valt onder de tweede normalisatie vorm). Als je een beschrijving van bijvoorbeeld merk in de merk tabel laat zitten krijg je heel veel dupplicatie. bijvoorbeeld:

merk (met MerkID 1) heeft een beschrijving "bla"
merk (met MerkID 2) heeft een beschrijving "bla2"
merk (met MerkID 3) heeft een beschrijving "bla"

MerkID 1 en MerkID 2 hebben dus dezelfde beschrijving. Door de tweede normalizatie toe te passen (dus beschrijving in een apparte tabel opnemen) voorkom je dupplicatie.