Frisørsalonens databaseprojekt

Opdateret:22. januar 2018 af Richard Holowczak

Følgende materialer dokumenterer designet og udviklingen af ​​en databaseapplikation til støtte for en lille frisørsalon. Projektet starter med en beskrivelse af virksomheden og fortsætter gennem konceptuel (E-R) modellering, logisk (Relationel) modellering, Fysisk modellering og til sidst implementering af en databaseapplikation. Noter (kommentarer) findes i slutningen af ​​hvert afsnit for at forklare nogle specifikke træk ved de trin, der udføres.

Indholdsfortegnelse

Jeg. Forretningsscenarie
II. ER-model med UML-notation
III. Konvertering til Relationsmodel
IV. Normalisering
V. Oprettelse af databaseskemaet med SQL
VI. Databaseapplikation
VII. Konklusioner

.

Jeg. Forretningsscenarie

Vores firma har ejet og drevet en frisør- og neglesalon i Midtown Manhattan i 7 år. Vi har brugt regneark og en papirlogbog til at holde styr på kunder, aftaler og betalinger. Vi vil gerne erstatte denne manuelle metode til at spore virksomheden med en database.

I vores forretning laver kunder aftaler med deres yndlingsfrisør (folk, der klipper og styler kunders hår) eller en anden medarbejder og kan forkæle sig med en række tjenester såsom grundlæggende klipning/styling, hårfarve, highlights, permanent, ansigtsbehandling, manicure, pedicure osv. Vi skal holde styr på materialer (shampoo, hårfarve) og den tid det vil tage at gennemføre hver enkelt service. Mens hver tjeneste har en standardpris, kan kampagner og andre faktorer påvirke den faktiske pris, der gives til kunden for den givne tjeneste.

Vi skal også holde styr på vores medarbejdere, herunder deres hjemmeadresse, kontaktoplysninger og løn. Vi skal holde styr på hver kundes kontaktoplysninger samt deres køn. Til aftaler skal vi kende datoen og tidspunktet for aftalen, og hvilken kunde aftalen er til.

Kommentar

Baseret på ovenstående beskrivelse, konstruer en enhedsrelationsmodel ved hjælp af UML-notation, der vil fange alle virksomhedens databehov.

II. ER-model ved hjælp af UML-notation

Baseret på ovenstående beskrivelse udvikler vi følgende Entity Relationship-model ved hjælp af UML-notation.

Kommentar

Hvad vi kan lide ved denne model:

• Alle relationslinjer går i vandret eller lodret position. Ingen linjer krydses.
• Attributnavne staves uden mellemrum i navnene. Der bruges ingen forkortelser.
• Hvert forhold har to meget sætninger, som vi kan lave forholdssætninger ud fra (se næste afsnit).
• Diagrammet har også en "legende" i øverste højre hjørne, så vi kan se, hvad diagrammet repræsenterer, og hvem der sidst har ændret diagrammet.

Relationssætninger

Én kunde kan være lave en eller flere aftaler

Én aftale skal være en reservation for én og kun én kunde

Én SalonService kan være en tjeneste gengivet som en eller flere ServiceRendered

Én ServiceRendered skal være en gengivelse af én og kun én SalonService

Én medarbejder kan være gengivelse en eller flere ServiceRendered

Én ServiceRendered skal være gengivet af én og kun én medarbejder
 

Én aftale kan være en reservation for at levere en eller flere ServiceRendered

Én ServiceRendered skal være en specifik service ydet under én og kun én aftale

Kommentar

Relationssætningerne skal give mening. I dette eksempel er verbumssætningerne understreget. Enhedsnavnene er med fed skrift. Minimumskardinalitet (kan være for 0 og skal være for 1) er skrevet med kursiv. Den maksimale kardinalitet skrives som "en eller flere" for * og "en og kun én" for 1.

Med ER-modellen færdiggjort, går vi videre til næste trin – at konvertere den konceptuelle ER-model til en logisk Relationel model.

III. Konvertering til Relationsmodel

Det næste trin er at konvertere Entity Relationship-diagrammet til en Relationel Model. Under dette trin bliver identifikatorer i enhederne nøgler i relationerne. En-til-mange-relationer resulterer i, at en fremmednøgle bliver kopieret fra den ene side til den mange-side af forholdet.

Kunde ( Kunde-ID (nøgle), Fornavn, Efternavn, Telefonnummer, Gade, By, Stat, Postnummer )

SalonService ( ServiceID (nøgle), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Medarbejder (medarbejder-id (nøgle), fornavn, efternavn, gade, by, stat, postnummer, lønsats )

Aftale ( Aftale-ID (nøgle), Aftaledato, Aftaletidspunkt, kunde-id (fk) )

ServiceRendered ( Aftale-ID (fk)(nøgle), LineItemNumber(nøgle), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Dette er det "indledende sæt af relationer."

Kommentar

• Bemærk, at ServiceRendered enhed fra ER-modellen er ID-afhængig, hvilket betyder, at den har brug for en attribut ud over LineItemNumber for at danne en sammensat nøgle.
• Nøgler vises med (nøgle)betegnelsen, og fremmednøgler vises med (fk)betegnelsen.

Det næste trin er at normalisere det indledende sæt af relationer.

IV. Normalisering

Det næste trin er at normalisere relationerne.

Trinene, der skal følges for hver relation, er:

1. Skriv relationen ud, inklusive alle attributnavne. Angiv nøgler og fremmednøgler.
2. Angiv nogle eksempeldata for relationen.
3. Angiv Nøglen for relationen og skriv alle Funktionelle afhængigheder ned .
4. Gennemgå definitionerne af hver normal form begyndende med 1NF og gå op til BCNF (eller 3NF afhængigt af dine projektkrav).
5. Hvis en relation opfylder definitionen af ​​en normalform, skal du flytte op til den næste højere normalform.
6. Hvis en relation ikke opfylder definitionen af ​​en normal form (f.eks. indeholder den en delvis nøgleafhængighed eller den indeholder en transitiv afhængighed), så opdel relationen i to nye relationer.
   Start normaliseringsprocessen fra begyndelsen med hver af disse to nye relationer.

Kunderelation

Kunde (kunde-id (nøgle) , fornavn, efternavn, kundetelefon, gade, by, stat, postnummer, køn )

Eksempeldata

Nøgle:Kunde-id

FD1:Kunde-id -> Fornavn, Efternavn, Telefonnummer, Gade, By, Stat, Postnummer, Køn

FD2:Postnummer -> By, stat

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Transitiv afhængighed eksisterer:Kunde-ID -> Postnummer og postnummer -> By, stat

Løsning:Opdel kunderelation i to nye relationer kaldet CustomerData og ZIPCodes:

Kundedata (kunde-id (nøgle), fornavn, efternavn, kundetelefon, gade, postnummer (fk), køn )

Nøgle:Kunde-id

FD1:Kunde-ID -> Fornavn, Efternavn, Telefonnummer, Gade, Postnummer (fk), Køn

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

Postkoder( Postnummer (nøgle), by, stat)

Nøgle:Postnummer

FD1:Postnummer -> By, stat

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

SalonService Relation

SalonService ( ServiceID (nøgle), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Eksempeldata:

Nøgle:ServiceID

FD1:ServiceID -> ServiceName, ServiceDuration, ServicePrice, ServiceMaterials

1NF:ServiceMaterials kan behandles som en attribut med flere værdier. I dette tilfælde er SalonService ikke i 1NF.

Løsning:Opdel ServiceMaterials i en separat relation.

I dette eksempel vil vi dog beholde ServiceMaterials som en attribut for SalonService-relationen.

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

Medarbejderforhold

Medarbejder (medarbejder-id (nøgle), fornavn, efternavn, gade, by, stat, postnummer, lønsats )

Nøgle:Medarbejder-ID

FD1:Medarbejder-ID -> Fornavn, Efternavn, Gade, By, Stat, Postnummer, Lønningssats

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Transitiv afhængighed eksisterer:Medarbejder-ID -> Postnummer og postnummer -> By, stat

Løsning:Opdel kunderelation i to nye relationer ved navn EmployeeData og ZIPCodes:

Medarbejderdata(medarbejder-id (nøgle), fornavn, efternavn, gade, postnummer (fk), lønsats )

Nøgle:Medarbejder-ID

FD1:EmployeeID -> Fornavn, Efternavn, Gade, Postnummer (fk), PayRate

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

Bemærk:Vi har allerede en postnummer-relation fra da Kunderelationen blev opdelt. Så vi genbruger denne postcode-relation. Der er ingen grund til at oprette en anden postcode-relation.

Aftaleforhold

Aftale ( Aftale-ID (nøgle), Aftaledato, Aftaletidspunkt, kunde-id (fk) )

Eksempeldata:

Nøgle:Aftale-ID

FD1:Aftale-ID -> Aftaledato, Aftaletidspunkt, kunde-id (fk)

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

ServiceRendered Relation

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

Eksempeldata:

Nøgle:AppointmentID, LineItemNumber

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

1NF:Opfylder definitionen af ​​en relation

2NF:Ingen delvise nøgleafhængigheder

3NF:Ingen transitive afhængigheder

BCNF:Alle determinanter er kandidatnøgler

Sidste sæt af relationer

Kunde ( Kunde-ID (nøgle) , Fornavn, Efternavn, Telefonnummer, Gade, Postnummer (fk), Køn )

Postkoder ( Postnummer (nøgle), by, stat)

SalonService ( ServiceID (nøgle), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Medarbejder (medarbejder-id (nøgle), fornavn, efternavn, gade, postnummer (fk), lønsats )

Aftale ( Aftale-ID (nøgle), Aftaledato, Aftaletidspunkt, kunde-id (fk) )

ServiceRendered ( Aftale-ID (fk)(nøgle), LineItemNumber(nøgle), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Kommentar

• Bemærk, at der kun kræves én postkoderelation. Den deles med både kunde- og medarbejderrelationer.
• Som tidligere nævnt er attributten ServiceMaterials ikke blevet normaliseret i dette eksempel. Måske kan det gøres i en fremtidig opgave eller forbedring af modellen.

Nu hvor relationerne er normaliserede, kan skemaet oprettes i et databasestyringssystem ved hjælp af struktureret forespørgselssprog (SQL).

V. Oprettelse af databaseskemaet med Structured Query Language

Opret en tabel i databasen for hver af relationerne i det endelige sæt af relationer.

Følgende SQL-kode opretter de seks tabeller og tilføjer PRIMARY KEY-begrænsningen til hver enkelt:

OPRET TABEL Postkoder( postnummer VARCHAR(12) IKKE NULL, by VARCHAR(36), stat VARCHAR(4), BEGRÆNSNING pk_zipcodes PRIMÆR NØGLE (postnummer))OPRET TABEL Kunde( Kunde-ID VARCHAR(10) IKKE NULL, Fornavn VARCHAR( 35), Efternavn VARCHAR(35), Telefonnummer VARCHAR(15), Gade VARCHAR(35), Postnummer VARCHAR(12), Køn VARCHAR(2), BEGRÆNSNING pk_customer PRIMÆR NØGLE (Kunde-ID))OPRET TABEL Aftale( Aftale-ID VARCHAR) NOT NULL, AppointmentDateTime DATE, CustomerID VARCHAR(10) NOT NULL, CONSTRAINT pk_appointment PRIMÆR NØGLE (Aftale-ID))CREATE TABLE SalonService( ServiceID VARCHAR(10) NOT NULL, ServiceName VARCHAR(35), ServiceDuration INTEGER, ServiceMaterial 5, ServiceMaterial(5) ), BEGRÆNSNING pk_salonservice PRIMÆR NØGLE (ServiceID))OPRET TABEL Medarbejder (medarbejder-ID VARCHAR(10) IKKE N ULL, Fornavn VARCHAR(35), Efternavn VARCHAR(25), Gade VARCHAR(45), Postnummer VARCHAR(12), PayRate NUMBER, CONSTRAINT pk_employee PRIMARY KEY (EmployeeID))CREATE TABLE ServiceRendered ( AppointmentID VARCHARNumber) HELTAL IKKE NULL, ServiceID VARCHAR(10) NOT NULL, ServiceExtendedPrice NUMBER, EmployeeID VARCHAR(10) NOT NULL, CONSTRAINT pk_ServiceRendered PRIMARY KEY (Aftale-ID, LineItemNumber))

Tilføjelse af fremmednøgler

Følgende SQL-koder tilføjer FOREIGN KEY-begrænsninger for at linke tabellerne sammen:

 alter tabel Kunde Tilføj begrænsning fk_customer_zipcodes Foreign Key (ZipCode) Referencer Zipcodes (ZipCode) Alter Table Medarbejder Tilføj begrænsning FK_Employee_zipcodes Foreign Key (Zipcode) Referencer Zipcodes (ZipCode) Alter Table Tab ) ALTER TABLE SERVICESerendered Tilføj begrænsning FK_SERVICERENDERED_SERVICE UDENLANDSKE KEY (SERVICEID) REFERENCER SALONSERVICE (SERVICEID) ALTER TABEL SERVICERENDERED ADD BEGRÆNSNING FK_SERVICERENDENDERED_MOLLEME UDENLANDSKE KEY (EMMEDELSE) REFERENCES ANVENDELSE (ANVENDELSE) ALTER TABEL SERVICEERENDERED ADD BEGRÆNSNING /pre> 
 

 Kommentar til SQL:
 
 
De fleste DBMS gemmer DATO og TID i samme kolonne. Så AppointmentDate og AppointmentTime blev kombineret i én kolonne i databasen med navnet AppointmentDateTime
 
Nøgler og fremmednøgler skal have samme nøjagtige navn og datatype. For eksempel er Key CustomerID VARCHAR(10) i kundetabellen og også VARCHAR(10) i aftaletabellen.
 
Begrænsninger gives meningsfulde navne såsom pk_customer for en primær nøgle og fk_customer_zipcodes for en fremmed nøgle.
 
Kolonner såsom telefonnummer og postnummer skal bruge VARCHAR-datatypen. Hvis der bruges en TAL- eller HELTAL-datatype, vil de foranstillede nuller mangle.
 
 
 

 Efter at have oprettet tabellerne og tilføjet fremmednøgle-begrænsningerne, ser databaseskemaet nu ud som følgende:
 
 

 
 
 
Relationsvisning
 

 Ved at bruge Relationsvisningen under Databaseværktøjer kan vi se relationerne (fremmednøgler) mellem tabellerne:
 

 
 

 
 
 
Tilføjelse af data til tabellerne ved hjælp af SQL INSERT-sætninger
 
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'); INDSÆT I KUNDEVÆRDIER ('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');INSERT INTO Customer VALUES ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M');INSERT INTO Customer VALUES (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F'); INDSÆT I KUNDEVÆRDIER ('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');INSERT INTO SalonService VALUES ('SV101', 'Herreklippning', 20, 22, 'Ingen');INSERT INTO SalonService VALUES ('SV102', 'Dameklipning', 30, 32 , 'Ingen');INSERT INTO SalonService VALUES ('SV103', 'Child Haircut', 20, 15, 'Ingen');INSERT INTO SalonService VALUES ('SV104', 'Women's Hair Color', 60, 76 , 'Farve, Reagens, Handsker, Reagensbørste, Folie'); INDSÆT I SalonService-VÆRDIER ('SV105', 'Dame's Hair Style', 45, 56, 'Shampoo, Conditioner'); INDSÆT I SalonService-VÆRDIER (' SV106', 'Mænds frisure', 45, 46, 'Shampoo, balsam'); INDSÆT I Medarbejder-VÆRDIER ('E300', 'Joy', 'Aveda', '46 Easton Ave.', '07026' , 18);INDSÆT I Medarbejder-VÆRDIER ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. Apt. 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 Aftaleværdier ('A400', '10/22/2017 11:00:00 AM', 'C101'); INDSÆT I aftaleværdier ('A401', '11/06/2017 12:45:00 PM', 'C102'); INDSÆT I aftaleværdier ('A402', '12/07 /2017 02:00:00 PM', 'C106');INDSÆT I aftaleværdier ('A403', '12/18/2017 03:30:00 PM', 'C106');INDSÆT I aftaleværdier ('A404 ', '12/21/2017 11:30:00 AM', 'C108');INSERT INTO Aftaleværdier ('A405', '12/31/2017 10:00:00 AM', 'C107'); INTO aftaleværdier ('A406', '01/11/2018 03:15:00 PM', 'C103');INDSÆT I aftaleværdier ('A407', '01/12/2018 02:30:00 PM', 'C104'); INDSÆT I aftaleværdier ('A408', '0 1/22/2018 04:00:00 PM', 'C105');INSERT INTO ServiceRendered VALUES ('A400', 1, 'SV104', 75, 'E400');INSERT INTO ServiceRendered VALUES ('A400', 2 , 'SV102', 25, 'E400');INSERT INTO ServiceRendered VALUES ('A401', 1, 'SV101', 22, 'E500');INSERT INTO ServiceRendered VALUES ('A402', 1, 'SV104', 75 , 'E600');INSERT INTO ServiceRendered VALUES ('A402', 2, 'SV102', 30, 'E800');INSERT INTO ServiceRendered VALUES ('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 ServiceRendered VALUES ('A405', 3, 'SV105', 50, 'E700');
 
Kommentar til dataeksempler
 
 
Vi tilføjer lige nok data til at kunne teste relationerne mellem tabellerne og give applikationsudviklerne noget at arbejde med.
 
Vær forsigtig med den rækkefølge, data tilføjes i. For eksempel skal alle postkoder indsættes først, før enten kunde eller medarbejder (som begge bruger postnummer som fremmednøgle) kan indsættes.
 
Når du tilføjer VARCHAR-data med indlejrede anførselstegn, skal du bruge to anførselstegn sammen. f.eks. 'Kvindefrisure'
 
På dette tidspunkt er databaseskemaet klar til, at applikationsudviklerne kan gå i gang med at designe formularer, rapporter og forespørgsler.
 
 

 Nu hvor databaseskemaet er blevet oprettet og er udfyldt med nogle eksempeldata, kan databaseapplikationen udvikles.
 

 
 
VI. Databaseapplikation
 

 Databaseapplikationen består af et sæt formularer, rapporter og forespørgsler, der er knyttet sammen på en navigationsformular.
 

 Navigationsformularen er den første formular, der vises, når databasen åbnes.
 
 
Navigationsformular
 

 
 

 Forskellige dataindtastningsformularer og rapporter kan vises ved at klikke på valget i venstre side.
 
 
Formular til indtastning af kundedata
 

 
 

 Kundedataindtastningsformularen bruges til at slå eksisterende kunder op og til at indtaste nye kundeoplysninger. By- og Statsfelterne udfyldes automatisk ved at vælge en postkode fra kombinationsboksen. Formularen har flere tilpassede VBA-koder til at konvertere for- og efternavne til store bogstaver og til at generere et nyt, unikt kunde-id, når et tomt kunde-id-felt vises efter oprettelse af en ny post.
 
 

 
 
 
Salon Services Dataindtastningsformular
 

 
 

 Indtastningsformularen til salonservicedata bruges til at forespørge, opdatere og tilføje nye salontjenester.
 
 
Formular til indtastning af aftaledata
 

 
 

 Formularen Dataindtastning af aftaler bruges til at oprette en ny aftale for en kunde. Som med kundeformularen kan et nyt aftale-id oprettes ved at klikke i et tomt aftale-id-felt, efter at en ny post er oprettet. Kunden kan vælges fra kombinationsboksen Kunde-id som vist nedenfor:
 

 
 

 Hvis dette er en ny kunde, der laver en aftale, kan brugeren klikke på knappen Ny kunde for at få vist formularen til indtastning af kundedata. Når den nye kundes oplysninger er gemt, kan brugeren vende tilbage til formularen til indtastning af aftaledata og lave aftalen.
 
 
Formular til aftale og tjenester
 

 
 

 Formålet med denne formular er at indtaste forskellige ydelser i forbindelse med en aftale. Denne formular kan også bruges til at generere en regning til kunden. Tjenesten og medarbejderen kan vælges fra deres respektive kombinationsbokse som vist nedenfor:
 

 
 

 
Rapport for samlede kundeaftaler
 

 
 

 Denne rapport giver en oversigt over antallet af aftaler og det samlede beløb brugt af hver kunde.
 
 

 Baseret på forespørgsel:
 
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.Customer.CustomerID =Appointment.qpointA. AppointmentIDGROUP BY Customer.CustomerID, FirstName, LastNameORDER BY LastName, FirstName;
 
 

 Og forespørg om Total_Spent_Each_Appointment
 
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;
 
 
Rapport om tjenester og rabatter
 

 
 

 Denne rapport viser hver af tjenesterne med totaler af den almindelige servicepris, den udvidede pris og en indikation af rabatbeløbet, der blev anvendt på de tjenester, der blev leveret tidligere.
 
 

 Baseret på forespørgsel:
 
SELECT SalonService.ServiceID, ServiceName, SUM(ServicePrice) AS TotalServicePrice, SUM(ServiceExtendedPrice) AS TotalExtendedPrice, FORMAT(1,0 - (SUM(ServiceExtendedPrice) /SUM(ServicePrice)), "0,00%") AS DiscountFROM SalonService, ServiceRendedWHERE SalonService.ServiceID =ServiceRendered.ServiceIDGROUP BY SalonService.ServiceID, ServiceNameORDER BY SalonService.ServiceID, ServiceName;
 
 
Kundeadresserapport
 

 
 

 Denne rapport viser de komplette navne og adresser på hver kunde.
 

 
 
VII. Konklusioner
 

 Udvikling af en databaseapplikation følger en systemudviklingslivscyklus, der begynder med konceptuel modellering og bevæges gennem et struktureret sæt trin, der inkluderer logisk modellering, normalisering, fysisk implementering og applikationsudvikling. Hårsalon-projekteksemplet illustrerer hvert af disse store trin. Nogle detaljer er dog ikke fuldt dokumenteret. For eksempel kan der kræves noget ekstra arbejde for at normalisere Salonservicerelationen for at tage højde for forskellige materialer, der bruges til hver service. Yderligere applikationsimplementeringsdetaljer såsom andre VBA-koder og mere detaljerede beskrivelser af brugen af ​​hver formular og rapport kan også tilføjes.