Projecten Applicatie Ontwikkeling
Standaarden Normaliseren ROC Flevoland
Werner Pauchli
Versie 1.0 Almere, 15 januari 2004
Inhoudsopgave
Inhoudsopgave Inhoudsopgave
3
1.
Documentbeheer
4
2.
Inleiding
5
3.
Standaarden
6
3.1 3.2
3.3 3.4 4.
Algemeen:.............................................................................................................................. 6 Notatiewijze ........................................................................................................................... 7 De nulde normaalvorm: ......................................................................................................... 7 De eerste normaalvorm ......................................................................................................... 7 De tweede normaalvorm: ...................................................................................................... 7 De derde normaalvorm:......................................................................................................... 7 Entiteit Relatie Diagram (ERD).............................................................................................. 8 Datadictionary (Entiteitbeschrijvingen) .................................................................................. 8
Bijlage: Factuur Garage Toonders
Versie 1.0 15 januari 2004
9
blad 3 van 9
1 • Documentbeheer
1.
Documentbeheer STATUS
Versie 1.0
Datum 15-01-2004
Auteur/bewerker Beschrijving Werner Pauchli Eerste versie Tabel 1 : Status van het document
ROCF
DISTRIBUTIELIJST Ter accordering Ontwikkelteam Applicatie ontwikkeling
Ter review Docenten Applicatie Ontwikkeling
Ter informatie Afdeling ICT ROC Flevoland Cursisten Applicatie Ontwikkeling
Tabel 2 : Document accordatie-, review- en informatielijst
HISTORIE Versie 1.0
Actie datum 15-01-2004
Beschrijving Eerste versie
Tabel 3 : Document historie.
Versie 1.0 15 januari 2004
blad 4 van 9
2 • Inleiding
2.
Inleiding Dit document is een beschrijving van de standaarden van producten van de informatieanalyse normaliseren zoals die worden gebruikt tijdens de projecten van applicatieontwikkeling. Aan bod komen: • • •
Normaliseren Entiteit Relatie Diagram (ERD) Datadictionary
Versie 1.0 15 januari 2004
blad 5 van 9
3 • Standaarden
3.
Standaarden Voor de uitwerking van het normaliseren houden we ons aan bepaalde standaarden. Deze zijn uitgewerkt aan de hand van het overzicht “Garage Toonders”.
3.1
Algemeen: • Dubbele streep onder een sleutel • Enkele streep onder een vreemde sleutel • Bij elke normaalvorm wordt het gehele product van normaliseren genoteerd. Dus ook de entiteiten die NIET veranderen worden meegenomen naar de volgende normaalvorm. • Bij de laatste normaalvorm (dus als er niet meer verder genormaliseerd kan worden) dienen de entiteiten van een functioneel juiste naam te worden voorzien. Deze naam dient een zelfstandig naamwoord in enkelvoud te zijn. • Er dient te worden genormaliseerd t/m de derde normaalvorm. Indien de derde normaalvorm gelijk is aan de tweede normaalvorm dient dit expliciet vermeld te worden. • De relaties tussen de verschillende entiteiten kan schematisch worden weergegeven door of een ERD of een strokendiagram te tekenen. In het voorbeeld wordt gebruik gemaakt van een ERD. In het ERD dient te worden aangegeven welke attributen de relatie realiseren. Ook de cardinaliteit en de optionaliteit van de relatie dienen te worden aangegeven. • Als laatste dient een datadictionary in tabel vorm te worden opgegeven. Per entiteit 1 tabel. In de tabel wordt de naam van het attribuut, het datatype en een veld voor opmerkingen weergegeven.
Versie 1.0 15 januari 2004
blad 6 van 9
3 • Standaarden
3.2
Notatiewijze
De nulde normaalvorm: RepNummer, Datum, Klantnummer, Naam, Woonplaats, Merk, Bouwjaar, Kenteken, KMStand [Onderdeelnummer, Omschrijving, Bedrag]
De eerste normaalvorm RepNummer, Datum, Klantnummer, Naam, Woonplaats, Merk, Bouwjaar, Kenteken, KMStand RepNummer, Onderdeelnummer, Omschrijving, Bedrag
De tweede normaalvorm: RepNummer, Datum, Klantnummer, Naam, Woonplaats, Merk, Bouwjaar, Kenteken, KMStand RepNummer, Onderdeelnummer Onderdeelnummer, Omschrijving, Bedrag
De derde normaalvorm: Factuur:
RepNummer, Datum, Klantnummer, Kenteken, KMStand
Auto:
Kenteken, Merk, Bouwjaar, Klantnummer
Klant
Klantnummer, Naam, Woonplaats
Reparatie:
RepNummer, Onderdeelnummer
Onderdeel:
Onderdeelnummer, Omschrijving, Bedrag
Versie 1.0 15 januari 2004
blad 7 van 9
3 • Standaarden
3.3
Entiteit Relatie Diagram (ERD)
Klantnr
Klant
Factuur
Klantnr
RepNummer
Reparatie
Auto
Klantnr Klant
OnderdeelNummer
Onderdeel
3.4
Datadictionary (Entiteitbeschrijvingen)
Entiteitnaam Definitie Attribuutnaam Kenteken Merk Bouwjaar Klantnummer Relaties R1 R2
AUTO Een AUTO is het voertuig dat ter reparatie/onderhoud aan de garage is aangeboden Datatype Toelichting Tekst (20) Kenteken van de auto Sleutel Tekst (20) Merk van de auto Datum Maand en jaar waarin de auto gebouw is Numeriek, R1, R2 Eigenaar van de auto Toelichting Een AUTO is altijd eigendom van 1 KLANT. 1 KLANT kan 0, 1 of meer AUTO’s bezitten. Een AUTO kan 1 of meer malen gefactureerd worden. Een FACTUUR heeft altijd betrekking op 1 AUTO
.
Versie 1.0 15 januari 2004
blad 8 van 9
4 • Bijlage: Factuur Garage Toonders
4.
Bijlage: Factuur Garage Toonders
Garage Toonders _____________________________________________________________ Factuur Reparatie / vervanging _____________________________________________________________ Reparatienummer: Datum:
1276352 20-05-03
Klant:
458977 H. de Vries Utrecht
Merk: Volkswagen Golf Bouwjaar: 1997 Kenteken: KL-98-KL Km. Stand: 150000 ____________________________________________________________ Onderdeel Omschrijving Bedrag ___________________________________________________________ 9876 Uitlaat 218 9055 Remblokken 222 Totaal:
440
Opmerkingen: • • •
De historie van de kilometerstand dient te worden vastgelegd. Alleen indien een auto voor reparatie komt wordt de kmstand vastgelegd. Een klant kan meerdere auto’s bezitten.
Versie 1.0 15 januari 2004
blad 9 van 9
