normaliseren

[Davo]

Hallo,
Ik ben mij aan het verdiepen in normaliseren en heb het onder staande overzicht genormaliseerd.

---------------------------------------------------------------------------------
Cursusrooster januari t/m augustus 2005
---------------------------------------------------------------------------------
Fast Build, Quick Applications productcode FaBu € 1600,-

Datum--------------Duur-----------Locatie
07-01-05------------5--------------NOVI training centrum
07-01-05------------5--------------SQL Solutions opleidingen

-----------------------------------------------------------------------------------
System Development with SolBase productcode SyDs € 3250,-
Datum---------Duur----------Locatie
… etc ….
-----------------------------------------------------------------------------------


En nu kom ik hier op uit en heb het gevoel dat dat niet goed is.
Kan iemand hier miss naar kijken en als het niet goed is zeggen waar ik de fout in ga.

0NV
© Cursusrooster januari t/m augustus, (RG Fast Build Quik Applications productcode Fabu, (RG Datum, Duur, locatie))
( sleutel Fast Build Quik Applications productcode Fabu)

1NV

Tabel1

Fast Build Quik Applications productcode Fabu (ook de sleutel)

Tabel 2

Datum, Duur, locatie (sleutel Datum en Locatie)

2NV=1NV
3NV=1NV

M.v.g Davo

[Avalaxy]

Stap 1: Maak er eens een fatsoenlijk ERD van

http://wb.mysql.com/

[Davo]

Thx voor de reply.
Maar doe je dat niet als je hebt genormaliseerd.
Zo niet moet ik eerst maar eens op google kijken om wat van ERD te leren


M.v.g Davo

[Avalaxy]

Normaliseren is niet echt een losse stap in het designproces. Je maakt gewoon een ontwerp (ERD in dit geval), net zoals je bij software een UML zou maken. Dit doe je meteen de eerste keer goed (dus in BCNF normaalvorm), je gaat niet eerst een flinke tabel maken en deze later in losse tabellen opsplitsen

Sowieso is MySQL workbench hier een hele fijne tool voor omdat je heel overzichtelijk ziet wat je doet, hij automatisch de juiste foreign keys aanmaakt bij het leggen van een relation en omdat je de tabellen kunt forward engineeren naar MySQL CREATE statements.

De manier waarop je het nu doet (alles opschrijven? ) is iig zeker niet aan te raden en in dit geval ook zeer onoverzichtelijk.

[ik222]

Om inhoudelijk op de case hierboven in te gaan. Volgens mij heb je een entiteit "Curus" met al zijn atributen. Daarnaast een entiteit "Locatie". Die twee hebben een veel op veel relatie dus krijg je sowieso een koppeltabel met datum en tijdsduur. Tenminste als ik puur naar de informatie in je case kijk, want mij lijkt dat persoonlijk geen heel goede oplossing in principe. Ik zou tijdsduur namelijk eerder bij cursus zetten en dan bijvoorbeeld een starttijd opnemen in de koppeltabel.

Want wat doe je anders als dezelfde cursus twee keer op een dag op dezelfde locatie wilt geven?

Maar wat Avalaxy zegt in natuurlijk sowieso waar

[ Voor 4% gewijzigd door ik222 op 13-01-2011 19:15 ]

[Davo]

Thx voor de reply's.

Dan moet ik mij maar gaan verdiepen in ERD en BCNF.
Schrijf het zo op om dat ik zo uit een boek van een maat heb die had nog een databaseontwikkeling boek liggen en daar heb ik dat in gelezen, vandaar dat ik het zo neer zet.

Maar dan ga ik maar naar google nogmaals dank voor u tijd.

M.v.g Davo

Edit na nog wat gelezen te hebben op het internet kom ik tot ( Ga uiteraard nog verdiepen in BCFN en ERD)

Maar volgens mij moet dit aardig kloppen.

0NV
(C Cursusrooster januari t/m augustus ( RG Cursus (RG Datum, Duur, Locatie)))

1NV

Tabel 1 Cursus
Cursus

Tabel 2 Locatie
Cursus, Locatie, Datum, Duur

2NV
Tabel 1 Cursus
Cursus

Tabel 2 Locatie
Cursus, Locatie

Tabel 3 Duur
Cursus, Datum, Duur

3NV
Tabel 1 Cursus
Cursus

Tabel 2 Locatie
Cursus, Locatie

Tabel 3 Duur
Cursus, Duur

Tabel 4 Datum
Datum

[ Voor 45% gewijzigd door Davo op 13-01-2011 21:23 ]

[Avalaxy]

Davo schreef op donderdag 13 januari 2011 @ 21:01:
Dan moet ik mij maar gaan verdiepen in ERD en BCNF.

BCNF (Boyce-Codd Normal Form) is eigenlijk een soort variant van de derde normaalvorm (net iets hoger, ook wel 3.5NV genoemd). In principe is dat ook een beetje de standaard op het gebied van normaliseren, dus als je je nu al verdiept hebt in de derde normaalvorm is het niet zoveel werk

[Maethor2]

Volgens mij ga je hierboven compleet de mist in je eerste, tweede en derde normaalvorm. Kan je je primary en foreign keys misschien aanduiden. Je eerste poging bovenaan leek me vele malen correcter dan dit. Alleen dat cursusrooster hoeft er niet voor volgens mij.

Je bent denk ik ook de prijs vergeten?

[Davo]

Dank voor de reacties.

Ben inderdaad de prijs vergeten.
Maar zal het zondag overnieuw proberen dan met de prijs er bij uiteraard.
En zal ook nog meer gaan lezen van BCNF.


m.v.g Davo

[ Voor 12% gewijzigd door Davo op 15-01-2011 00:03 ]

[Maethor2]

Een keer je databasemodel in derde normaalvorm staat heb je zo goed als geen werk meer om hem BCNF te maken. Misschien kan je je daarop concentreren.

[Davo]

Hallo,
Ben met een ander overzicht bezig gegaan.
En heb deze nu als 0NV nog zonder sleutel want daar heb ik een vraag over.
Ben nu met dit overzicht bezig http://img689.imageshack.us/i/0806wb.jpg/ en heb deze 0nv,

0NV
(C Datum overzicht (RG Locatie Code (RG Artikel Code, Artikel Beschrijving, Artikel Aantal (P Totale Vooraad))))

Ten eerste kloppen deze gegevens. En dan de vraag om dat je constante niet mee neemt naar de eerste normaal vorm. Wordt dan mijn sleutel in de 0NV Locatie Code of neem ik gewoon Datum Overzicht als sleutel.


Zal dit overzicht tot BCNF normaal vorm gaan doen.


M.v.g Davo

[Avalaxy]

Ik snap niet echt waarom je nou nogsteeds met 0NV aankomt? Ik kan iig niet echt wijs worden uit je letterbrij.

Dingen eerst in 0NV zetten, daarna in 1NV, daarna in 2NV, daarna in 3NV en daarna pas in BCNF is natuurlijk absoluut niet de manier waarop je zoiets aanpakt. Je gaat ook niet eerst je code volledig tikken in wordpad om daarna stukje op te delen in functies en daarna functies op te delen in classes, dat is iets wat je meteen de eerste keer doet.

[Glewellyn]

Avalaxy schreef op maandag 17 januari 2011 @ 18:19:
Ik snap niet echt waarom je nou nogsteeds met 0NV aankomt? Ik kan iig niet echt wijs worden uit je letterbrij.

Dingen eerst in 0NV zetten, daarna in 1NV, daarna in 2NV, daarna in 3NV en daarna pas in BCNF is natuurlijk absoluut niet de manier waarop je zoiets aanpakt. Je gaat ook niet eerst je code volledig tikken in wordpad om daarna stukje op te delen in functies en daarna functies op te delen in classes, dat is iets wat je meteen de eerste keer doet.

Iemand met wat meer ervaring kan inderdaad meteen tot de 3e of soms zelfs 4e normaalvorm normaliseren. Maar als je nog nooit eerder hebt genormaliseerd is het juist een hele goede oefening om het stap voor stap te doen, dan begrijp je ook beter waarom bepaalde gegevens in bepaalde tabellen terecht komt.

[Davo]

Deze manier van opschrijven komt uit een MBO boek. (C= constante( RG= repeterende groep (RG dubbel repeterende roep ( P= proces gegevens en dan om af te sluiten ))))

Er staat in dat boek ook geen andere manier dan eerst naar de 0nv dan naar de 1nv dan 2nv en dan 3nv.

Maar als dit de totaal verkeerde manier is, hoe kan ik het dan het best aanpakken.


M.v.g Davo

[Maethor2]

Een relatie is in BCNF als hij minimaal in 1NF staat en elke determinant in de relatie een kandidaatsleutel is van de relatie. Determinant betekent dat als Y functioneel afhankelijk is van X dan is X de determinant van deze functionele afhankelijkheid.

Praktisch kan je dus zowel vanuit 1NF, 2NF en 3NF vertrekken en deze onmiddellijk BCNF maken. Je kijkt gewoon naar de functionele afhankelijkheden in je relaties.
Tijdens het inoefenen is het makkelijk om de stappen te doorlopen. Het werk om van 3NF naar BCNF te gaan is vervolgens minimaal.