Het Kapsalon Database Project

Bijgewerkt:22 januari 2018 door Richard Holowczak

De volgende materialen documenteren het ontwerp en de ontwikkeling van een databasetoepassing ter ondersteuning van een kleine kapsalon. Het project begint met een beschrijving van het bedrijf en verloopt via conceptuele (E-R) modellering, logische (relationele) modellering, fysieke modellering en tenslotte implementatie van een databasetoepassing. Aan het einde van elke sectie worden opmerkingen (commentaar) gegeven om enkele specifieke kenmerken van de uitgevoerde stappen uit te leggen.

Inhoudsopgave

Ik. Bedrijfsscenario
II. ER-model met UML-notatie
III. Conversie naar relationeel model
IV. Normalisatie
V. Het databaseschema maken met SQL
VI. Databasetoepassing
VII. Conclusies

.

Ik. Bedrijfsscenario

Ons bedrijf heeft 7 jaar lang een haar- en nagelsalon in Midtown Manhattan gehad en geëxploiteerd. We gebruiken spreadsheets en een papieren logboek om klanten, afspraken en betalingen bij te houden. We willen deze handmatige methode om het bedrijf te volgen vervangen door een database.

In ons bedrijf maken klanten afspraken met hun favoriete kapper (mensen die het haar van klanten knippen en stylen) of een andere medewerker en kunnen ze genieten van een aantal diensten, zoals basiskapsel/styling, haarkleur, highlights, permanenten, gezichtsbehandelingen, manicure, pedicure, enz. We moeten de materialen (shampoo, haarkleur) bijhouden en de tijd die nodig is om elke service te voltooien. Hoewel elke service een standaardprijs heeft, kunnen promoties en andere factoren van invloed zijn op de werkelijke prijs die voor de gegeven service aan de klant wordt verstrekt.

We moeten ook onze werknemers bijhouden, inclusief hun thuisadres, contactgegevens en salaris. We moeten de contactgegevens van elke klant bijhouden, evenals hun geslacht. Voor afspraken moeten we de datum en tijd van de afspraak weten en voor welke klant de afspraak is.

Commentaar

Stel op basis van de bovenstaande beschrijving een Entity Relationship-model op met UML-notatie dat alle gegevensbehoeften van het bedrijf omvat.

II. ER-model met UML-notatie

Op basis van de bovenstaande beschrijving ontwikkelen we het volgende Entity Relationship-model met behulp van UML-notatie.

Commentaar

Wat we leuk vinden aan dit model:

• Alle relatielijnen gaan in een horizontale of verticale positie. Er worden geen lijnen overschreden.
• Attribuutnamen worden gespeld zonder spaties in de namen. Er worden geen afkortingen gebruikt.
• Elke relatie heeft twee zinnen waaruit we relatiezinnen kunnen maken (zie volgende sectie).
• Het diagram heeft ook een 'legenda' in de rechterbovenhoek, zodat we kunnen zien wat het diagram voorstelt en wie het diagram voor het laatst heeft gewijzigd.

Relatie Zinnen

Eén klant mogelijk het maken van een of meer Afspraken

Eén Afspraak moet zijn een reservering voor één en slechts één Klant

Eén SalonService mogelijk een service geleverd als een of meer ServiceRendered

Eén ServiceRendered moet zijn een weergave van één en slechts één SalonService

Eén Medewerker mogelijk weergave een of meer ServiceRendered

Eén ServiceRendered moet zijn weergegeven door één en slechts één Medewerker
 

Eén Afspraak mogelijk een reservering om een ​​of meer ServiceRendered . te leveren

Eén ServiceRendered moet zijn een specifieke dienst verleend tijdens één en slechts één Afspraak

Commentaar

De relatiezinnen moeten logisch zijn. In dit voorbeeld zijn de werkwoordzinnen onderstreept. De namen van de entiteiten zijn vetgedrukt. De minimale kardinaliteit (mag zijn voor 0 en moet . zijn voor 1) zijn cursief geschreven. De maximale kardinaliteit wordt geschreven als "een of meer" voor * en "één en slechts één" voor 1.

Nu het ER-model is voltooid, gaan we verder met de volgende stap:het conceptuele ER-model omzetten in een logisch relationeel model.

III. Conversie naar relationeel model

De volgende stap is het omzetten van het entiteitsrelatiediagram naar een relationeel model. Tijdens deze stap worden Identifiers in de Entiteiten Sleutels in de Relaties. Een-op-veel-relaties resulteren in het kopiëren van een externe sleutel van de ene kant naar de veelkant van de relatie.

Klant ( Klant-ID (sleutel), Voornaam, Achternaam, Telefoonnummer, Straat, Stad, Provincie, Postcode )

SalonService ( ServiceID (sleutel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Medewerker ( Werknemer-ID (sleutel), Voornaam, Achternaam, Straat, Plaats, Staat, Postcode, Betaaltarief )

Afspraak ( AfspraakID (sleutel), Afspraakdatum, Afspraaktijd, KlantID (fk) )

Service weergegeven ( AppointmentID (fk)(key), LineItemNumber(key), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Dit is de "initiële reeks relaties".

Commentaar

• Merk op dat de ServiceRendered entiteit uit het ER-model is ID-afhankelijk, wat betekent dat het een attribuut nodig heeft naast LineItemNumber om een ​​samengestelde sleutel te vormen.
• Sleutels worden weergegeven met de (sleutel) aanduiding en buitenlandse sleutels worden weergegeven met de (fk) aanduiding.

De volgende stap is het normaliseren van de initiële set relaties.

IV. Normalisatie

De volgende stap is om de relaties te normaliseren.

De te volgen stappen voor elke relatie zijn:

1. Schrijf de relatie op inclusief alle attribuutnamen. Geef sleutels en externe sleutels aan.
2. Geef enkele voorbeeldgegevens voor de relatie.
3. Geef de Sleutel . op voor de relatie en noteer alle Functionele Afhankelijkheden .
4. Ga door de definities van elke normale vorm, beginnend met 1NF en gaand naar BCNF (of 3NF, afhankelijk van uw projectvereisten).
5. Als een relatie voldoet aan de definitie van een normaalvorm, ga dan naar de volgende hogere normaalvorm.
6. Als een relatie niet voldoet aan de definitie van een normaalvorm (deze bevat bijvoorbeeld een afhankelijkheid van een gedeeltelijke sleutel of een transitieve afhankelijkheid), splits de relatie dan op in twee nieuwe relaties.
   Begin met het normalisatieproces vanaf het begin met elk van deze twee nieuwe relaties.

Klantrelatie

Klant ( CustomerID (key) , FirstName, LastName, CustPhone, Street, City, State, PostCode, Geslacht )

Voorbeeldgegevens

Sleutel:Klant-ID

FD1:Klant-ID -> Voornaam, Achternaam, Telefoonnummer, Straat, Plaats, Staat, Postcode, Geslacht

FD2:Postcode -> Plaats, Provincie

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Transitieve afhankelijkheid bestaat:Klant-ID -> Postcode en Postcode -> Stad, staat

Oplossing:Splits de klantrelatie op in twee nieuwe relaties genaamd CustomerData en ZipCodes:

CustomerData (CustomerID (sleutel), FirstName, LastName, CustPhone, Street, ZipCode (fk), Geslacht )

Sleutel:Klant-ID

FD1:Klant-ID -> Voornaam, Achternaam, Telefoonnummer, Straat, Postcode (fk), Geslacht

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

Postcodes( Postcode (sleutel), Stad, Provincie)

Sleutel:Postcode

FD1:Postcode -> Plaats, Provincie

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

SalonServicerelatie

SalonService ( ServiceID (sleutel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Voorbeeldgegevens:

Sleutel:Service-ID

FD1:ServiceID -> Servicenaam, Serviceduur, Serviceprijs, Servicematerialen

1NF:ServiceMaterials kunnen worden behandeld als een kenmerk met meerdere waarden. In dit geval zit SalonService niet in 1NF.

Oplossing:Splits ServiceMaterials op in een aparte relatie.

Voor dit voorbeeld houden we ServiceMaterials echter als een attribuut van de SalonService-relatie.

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

Werknemersrelatie

Werknemer( Werknemer-ID (sleutel), Voornaam, Achternaam, Straat, Stad, Provincie, Postcode, Betaaltarief )

Sleutel:Medewerker-ID

FD1:Werknemer-ID -> Voornaam, Achternaam, Straat, Plaats, Staat, Postcode, Betaaltarief

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Transitieve afhankelijkheid bestaat:EmployeeID -> ZipCode en ZipCode -> City, State

Oplossing:Splits de klantrelatie in twee nieuwe relaties genaamd EmployeeData en ZipCodes:

EmployeeData(EmployeeID (sleutel), FirstName, LastName, Street, ZipCode (fk), PayRate )

Sleutel:Medewerker-ID

FD1:Werknemer-ID -> Voornaam, Achternaam, Straat, Postcode (fk), Betaaltarief

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

Let op:We hebben al een postcode relatie van toen de klantrelatie werd opgesplitst. Dus we hergebruiken die ZipCodes-relatie. Het is niet nodig om een ​​tweede postcode-relatie aan te maken.

Afspraakrelatie

Appointment ( AppointmentID (key), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Voorbeeldgegevens:

Sleutel:Afspraak-ID

FD1:Afspraak-ID -> Afspraakdatum, Afspraaktijd, Klant-ID (fk)

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

Door service weergegeven relatie

ServiceRendered ( AppointmentID (fk)(key), LineItemNumber(key), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk) )

Voorbeeldgegevens:

Sleutel:Afspraak-ID, LineItemNumber

FD1:AppointmentID, LineItemNumber -> ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk)

1NF:Voldoet aan de definitie van een relatie

2NF:Geen gedeeltelijke sleutelafhankelijkheden

3NF:Geen transitieve afhankelijkheden

BCNF:alle determinanten zijn kandidaatsleutels

Definitieve reeks relaties

Klant ( KlantID (sleutel) , Voornaam, Achternaam, Telefoonnummer, Straat, Postcode (fk), Geslacht )

Postcodes ( Postcode (sleutel), plaats, staat)

SalonService ( ServiceID (sleutel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Medewerker ( WerknemerID (sleutel), Voornaam, Achternaam, Straat, Postcode (fk), Betaaltarief )

Afspraak ( AfspraakID (sleutel), Afspraakdatum, Afspraaktijd, KlantID (fk) )

Service weergegeven ( AppointmentID (fk)(key), LineItemNumber(key), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Commentaar

• Houd er rekening mee dat er slechts één postcode-relatie vereist is. Het wordt gedeeld met zowel klant- als werknemersrelaties.
• Zoals eerder opgemerkt, is het kenmerk ServiceMaterials in dit voorbeeld niet genormaliseerd. Misschien kan het in een toekomstige opdracht of verbetering van het model worden gedaan.

Nu de relaties zijn genormaliseerd, kan het schema worden gemaakt in een databasebeheersysteem met behulp van gestructureerde querytaal (SQL).

V. Het databaseschema maken met gestructureerde querytaal

Maak een tabel in de database voor elk van de relaties in de laatste set relaties.

De volgende SQL-code maakt de zes tabellen en voegt aan elke tabel de PRIMARY KEY-beperking toe:

CREATE TABLE ZipCodes( postcode VARCHAR(12) NOT NULL, plaats VARCHAR(36), state VARCHAR(4), CONSTRAINT pk_zipcodes PRIMARY KEY (zipcode))CREATE TABLE Customer( CustomerID VARCHAR(10) NOT NULL, FirstName VARCHAR( 35), Achternaam VARCHAR(35), Telefoonnummer VARCHAR(15), Straat VARCHAR(35), Postcode VARCHAR(12), Geslacht VARCHAR(2), CONSTRAINT pk_customer PRIMAIRE SLEUTEL (Klant-ID)) TABEL MAKEN Afspraak ( Afspraak-ID VARCHAR (10) NOT NULL, AppointmentDateTime DATE, CustomerID VARCHAR(10) NOT NULL, CONSTRAINT pk_appointment PRIMARY KEY (AppointmentID))CREATE TABEL SalonService( ServiceID VARCHAR(10) NOT NULL, ServiceName VARCHAR(35), ServiceDuration INTEGER, ServicePrice NUMBER, ServiceMaterials VAR ), CONSTRAINT pk_salonservice PRIMAIRE SLEUTEL (Service-ID))CREATE TABEL Medewerker ( Werknemer-ID VARCHAR (10) NIET N ULL, Voornaam VARCHAR(35), Achternaam VARCHAR(25), Straat VARCHAR(45), Postcode VARCHAR(12), PayRate NUMBER, CONSTRAINT pk_employee PRIMARY KEY (EmployeeID))CREATE TABLE Service Rendered ( Afspraak-ID VARCHAR (10) NOT NULL, LineItemNumber INTEGER NOT NULL, ServiceID VARCHAR (10) NOT NULL, ServiceExtendedPrice NUMBER, EmployeeID VARCHAR (10) NOT NULL, CONSTRAINT pk_ServiceRendered PRIMARY KEY (AppointmentID, LineItemNumber))

Externe sleutels toevoegen

De volgende SQL-codes voegen FOREIGN KEY-beperkingen toe om de tabellen aan elkaar te koppelen:

ALTER TABLE Klant ADD CONSTRAINT fk_customer_zipcodes FOREIGN KEY (ZipCode) REFERENCES ZipCodes (ZipCode)ALTER TABLE Employee ADD CONSTRAINT fk_employee_zipcodes FOREIGN KEY (ZipCode) REFERENCES Aangepast (ZipCode) REFERENCES ZipCodesALTERDDABLECodeIDS ) ALTER TABEL ServiceRendered /pre> 
 

 Commentaar op SQL:
 
 
De meeste DBMS zullen de DATUM en TIJD in dezelfde kolom opslaan. Dus AppointmentDate en AppointmentTime werden gecombineerd in één kolom in de database met de naam AppointmentDateTime
 
Sleutels en buitenlandse sleutels moeten exact dezelfde naam en hetzelfde gegevenstype hebben. De Key CustomerID is bijvoorbeeld VARCHAR (10) in de tabel Klant en ook VARCHAR (10) in de tabel Afspraak.
 
Beperkingen krijgen betekenisvolle namen zoals pk_customer voor een primaire sleutel en fk_customer_zipcodes voor een externe sleutel.
 
Kolommen zoals telefoonnummer en postcode moeten het gegevenstype VARCHAR gebruiken. Als een gegevenstype NUMBER of INTEGER wordt gebruikt, ontbreken de voorloopnullen.
 
 
 

 Na het maken van de tabellen en het toevoegen van de externe-sleutelbeperkingen, ziet het databaseschema er nu als volgt uit:
 
 

 
 
 
Relatieweergave
 

 Met behulp van de Relatieweergave onder Databasehulpmiddelen kunnen we de relaties (buitenlandse sleutels) tussen de tabellen zien:
 

 
 

 
 
 
Gegevens aan tabellen toevoegen met SQL INSERT-statements
 
INSERT INTO ZipCodes VALUES ('07026', 'Garfield', 'NJ');INSERT INTO ZipCodes VALUES ('07621', 'Bergenfield', 'NJ');INSERT INTO ZipCodes VALUES ('07010', 'Cliffside Park', 'NJ');INSERT INTO ZipCodes VALUES ('07631', 'Englewood', 'NJ');INSERT INTO ZipCodes VALUES ('07665', 'Teaneck', 'NJ');INSERT INTO Customer VALUES (' C101', 'Elia', 'Fawcett', '201-222-2222', '8989 Smith Rd', '07026', 'F'); INSERT INTO Customer VALUES ('C102', 'Ishwarya', 'Roberts' , '201-222-3333', '65 Hope Rd', '07026', 'M'); INSERT INTO Customer VALUES ('C103', 'Frederic', 'Fawcett', '201-222-2222', ' 8989 Smith Rd', '07026', 'M'); INSERT INTO Customer VALUES ('C104', 'Goldie', 'Montand', '201-222-4321', '5235 Ironwood Ln', '07026', ' F');VOEG IN IN Klantwaarden ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M');VOEG IN IN Klantwaarden (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F'); INSERT IN TO Customer VALUES ('C107', 'Faye', 'Glenn' , '201-333-4242', '1 522 Main St', '07010', 'F'); INSERT INTO Customer VALUES ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', ' F');VOEG IN IN SalonService WAARDEN ('SV101', 'Herenkapsel', 20, 22, 'Geen');VOEG IN IN SalonService WAARDEN ('SV102', 'Dameskapsel', 30, 32 , 'Geen');INVOER IN SalonService WAARDEN ('SV103', 'Kinderkapsel', 20, 15, 'Geen');VOEG IN IN SalonService WAARDEN ('SV104', 'Haarkleur voor vrouwen', 60, 76 , 'Kleur, reagens, handschoenen, reagensborstel, folie');VOEG DE WAARDEN VAN SalonService IN ('SV105', 'Dameskapsel', 45, 56, 'Shampoo, Conditioner'); VOEG DE WAARDEN VAN SalonService IN (' SV106', 'Herenkapsel', 45, 46, 'Shampoo, Conditioner'); INSERT INTO Employee VALUES ('E300', 'Joy', 'Aveda', '46 Easton Ave.', '07026' , 18); INSERT INTO Employee VALUES ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. geschikt. 2A', '07026', 22);INSERT INTO Employee VALUES ('E500', 'Koy', 'Petruzzio', '70 Wilard St. ', '07026', 20);INSERT INTO Employee VALUES ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18); INSERT INTO Employee VALUES ('E700', 'Pat', 'Reese', '2 Lincoln Place', '07010', 23);INSERT INTO Employee VALUES ('E800', 'Winter', 'Tanner', '215 Elm Ave', '07665', 23);INSERT INTO Appointment VALUES ('A400', '22-10-2017 11:00:00 AM', 'C101');INVOER IN AFSPRAAKWAARDEN ('A401', '11/06/2017 12:45:00 PM', 'C102');INVOER IN AFSPRAAKWAARDEN ('A402', '12/07 /2017 14:00:00 PM', 'C106');INSERT INTO Afspraak VALUES ('A403', '18/12/2017 15:30:00 PM', 'C106');INSERT INTO Afspraak VALUES ('A404 ', '21/12/2017 11:30:00 AM', 'C108');INSERT INTO Afspraak WAARDEN ('A405', '31/12/2017 10:00:00 AM', 'C107');INSERT IN AFSPRAAKWAARDEN ('A406', '01/11/2018 03:15:00 PM', 'C103');INSERT INTO Afspraak VALUES ('A407', '01/12/2018 14:30:00 PM', 'C104');INVOER IN AFSPRAAKWAARDEN ('A408', '0 2/2/2018 16:00:00 PM', 'C105');INSERT INTO ServiceRendered VALUES ('A400', 1, 'SV104', 75, 'E400');INSERT INTO ServiceRendered VALUES ('A400', 2 , 'SV102', 25, 'E400');VOEG IN IN door service weergegeven waarden ('A401', 1, 'SV101', 22, 'E500');VOEG IN IN door service weergegeven waarden ('A402', 1, 'SV104', 75 , 'E600');INSERT INTO door service weergegeven waarden ('A402', 2, 'SV102', 30, 'E800');INSERT INTO door service weergegeven waarden ('A403', 1, 'SV105', 50, 'E300'); INSERT INTO ServiceRendered VALUES ('A404', 1, 'SV105', 55, 'E300');INSERT INTO ServiceRendered VALUES ('A405', 1, 'SV102', 30, 'E700');INSERT INTO ServiceRendered VALUES (' A405', 2, 'SV104', 70, 'E700'); INSERT INTO door service weergegeven WAARDEN ('A405', 3, 'SV105', 50, 'E700');
 
Commentaar op gegevensvoorbeelden
 
 
We voegen net genoeg gegevens toe om de relaties tussen de tabellen te kunnen testen en om de applicatieontwikkelaars iets te geven om mee te werken.
 
Let op de volgorde waarin gegevens worden toegevoegd. Alle postcodes moeten bijvoorbeeld eerst worden ingevoerd, voordat ofwel de klant ofwel de werknemer (die beide postcode als externe sleutel gebruiken) kan worden ingevoerd.
 
Gebruik bij het toevoegen van VARCHAR-gegevens met ingesloten aanhalingstekens twee aanhalingstekens. bijv. 'Dameskapsel'
 
Op dit punt is het databaseschema klaar voor de applicatieontwikkelaars om aan de slag te gaan met het ontwerpen van formulieren, rapporten en query's.
 
 

 Nu het databaseschema is gemaakt en is gevuld met enkele voorbeeldgegevens, kan de databasetoepassing worden ontwikkeld.
 

 
 
VI. Databasetoepassing
 

 De databasetoepassing bestaat uit een set formulieren, rapporten en query's die aan elkaar zijn gekoppeld op een navigatieformulier.
 

 Het navigatieformulier is het eerste formulier dat verschijnt wanneer de database wordt geopend.
 
 
Navigatieformulier
 

 
 

 Verschillende formulieren voor gegevensinvoer en rapporten kunnen worden weergegeven door op de selectie aan de linkerkant te klikken.
 
 
Invoerformulier klantgegevens
 

 
 

 Het formulier Customer Data Entry wordt gebruikt om bestaande klanten op te zoeken en nieuwe klantinformatie in te voeren. De velden Stad en Staat worden automatisch ingevuld door een postcode te selecteren uit de combobox. Het formulier heeft verschillende aangepaste VBA-codes om de voor- en achternaam om te zetten in de juiste hoofdletters en om een ​​nieuwe, unieke klant-ID te genereren wanneer een leeg klant-ID-veld verschijnt na het maken van een nieuw record.
 
 

 
 
 
Invoerformulier voor salondiensten
 

 
 

 Het formulier voor het invoeren van salonservicegegevens wordt gebruikt om nieuwe salonservices op te vragen, bij te werken en toe te voegen.
 
 
Invoerformulier afspraakgegevens
 

 
 

 Het Afspraken Invoerformulier wordt gebruikt om een ​​nieuwe afspraak voor een klant te maken. Net als bij het klantformulier kan een nieuwe afspraak-ID worden gemaakt door in een leeg afspraak-ID-veld te klikken nadat een nieuwe record is gemaakt. De klant kan worden geselecteerd uit het keuzevak Klant-ID, zoals hieronder weergegeven:
 

 
 

 Als dit een nieuwe klant is die een afspraak maakt, kan de gebruiker op de knop Nieuwe klant klikken om het formulier Klantgegevensinvoer te openen. Nadat de informatie van de nieuwe klant is opgeslagen, kan de gebruiker terugkeren naar het formulier Afspraakgegevensinvoer en de afspraak maken.
 
 
Afspraak- en dienstenformulier
 

 
 

 Het doel van dit formulier is om verschillende diensten in te voeren die bij een afspraak horen. Dit formulier kan ook worden gebruikt om een ​​factuur voor de klant te genereren. De Dienst en de Werknemer kunnen worden geselecteerd uit hun respectievelijke keuzelijsten, zoals hieronder weergegeven:
 

 
 

 
Totalenrapport klantafspraken
 

 
 

 Dit rapport geeft een overzicht van het aantal afspraken en het totale bedrag dat door elke klant is uitgegeven.
 
 

 Gebaseerd op zoekopdracht:
 
SELECT Customer.CustomerID, FirstName, LastName, SUM(q.TotalSpent) AS TotalSpent, COUNT(q.AppointmentID) AS NumberOfAppointmentsFROM Customer, Appointment, Query_Total_Spent_Each_Appointment AS qWHERE Customer.CustomerID =Appointment.CustomerID AND AppointmentID =. Afspraak-IDGROEP OP Klant.Klant-ID, Voornaam, AchternaamORDER OP Achternaam, Voornaam;
 
 

 En Query Total_Spent_Each_Appointment
 
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;
 
 
Services en kortingenrapport
 

 
 

 Dit rapport toont elk van de services met totalen van de reguliere serviceprijs, de uitgebreide prijs en een indicatie van het kortingsbedrag dat is toegepast op de in het verleden verleende services.
 
 

 Gebaseerd op zoekopdracht:
 
SELECT SalonService.ServiceID, ServiceName, SUM(ServicePrice) AS TotalServicePrice, SUM(ServiceExtendedPrice) AS TotalExtPrice, FORMAT(1.0 - (SUM(ServiceExtendedPrice) / SUM(ServicePrice)), "0.00%") AS DiscountFROM SalonService, ServiceRenderedWHERE SalonService.ServiceID =ServiceRendered.ServiceIDGROUP DOOR SalonService.ServiceID, ServiceNameORDER DOOR SalonService.ServiceID, ServiceName;
 
 
Rapport klantadressen
 

 
 

 Dit rapport toont de volledige namen en adressen van elke klant.
 

 
 
VII. Conclusies
 

 Het ontwikkelen van een databasetoepassing volgt een levenscyclus van systeemontwikkeling die begint met conceptuele modellering en wordt doorlopen via een gestructureerde reeks stappen die logische modellering, normalisatie, fysieke implementatie en toepassingsontwikkeling omvatten. Het voorbeeld van het kapsalonproject illustreert elk van deze belangrijke stappen. Sommige details zijn echter niet volledig gedocumenteerd. Er kan bijvoorbeeld wat extra werk nodig zijn om de relatie tussen Salonservices te normaliseren om rekening te houden met verschillende materialen die voor elke service worden gebruikt. Aanvullende details van de toepassingsimplementatie, zoals andere VBA-codes en meer gedetailleerde beschrijvingen van het gebruik van elk formulier en rapport, kunnen ook worden toegevoegd.