Frisörsalongens databasprojekt

Uppdaterad:22 januari 2018 av Richard Holowczak

Följande material dokumenterar design och utveckling av en databasapplikation för att stödja en liten frisörsalong. Projektet inleds med en beskrivning av verksamheten och fortsätter genom konceptuell (E-R) modellering, logisk (Relationell) modellering, Fysisk modellering och slutligen implementering av en databasapplikation. Anteckningar (kommentarer) finns i slutet av varje avsnitt för att förklara några specifika egenskaper hos de steg som utförs.

Innehållsförteckning

Jag. Affärsscenario
II. ER-modell med UML-notation
III. Konvertering till relationsmodell
IV. Normalisering
V. Skapa databasschemat med SQL
VI. Databasapplikation
VII. Slutsatser

.

Jag. Affärsscenario

Vårt företag har ägt och drivit en hår- och nagelsalong i centrala Manhattan i 7 år. Vi har använt kalkylblad och en pappersloggbok för att hålla reda på kunder, möten och betalningar. Vi skulle vilja ersätta denna manuella metod för att spåra verksamheten med en databas.

I vår verksamhet bokar kunder tider med sin favoritfrisör (folk som klipper och stylar kunders hår) eller annan anställd och kan njuta av ett antal tjänster som grundläggande hårklippning/styling, hårfärg, highlights, permanent, ansiktsbehandling, manikyr, pedikyr etc. Vi behöver ha koll på material (schampo, hårfärg) och tiden det tar att genomföra varje tjänst. Även om varje tjänst har ett standardpris, kan kampanjer och andra faktorer påverka det faktiska priset som förlängs till kunden för den givna tjänsten.

Vi måste också hålla reda på våra anställda inklusive deras hemadress, kontaktinformation och lönenivå. Vi måste hålla reda på varje kunds kontaktinformation samt deras kön. För möten behöver vi veta datum och tid för mötet och vilken kund mötet gäller.

Kommentar

Baserat på ovanstående beskrivning, konstruera en Entity Relationship-modell med UML-notation som kommer att fånga alla företagets databehov.

II. ER-modell med UML-notation

Baserat på ovanstående beskrivning utvecklar vi följande Entity Relationship-modell med UML-notation.

Kommentar

Vad vi gillar med den här modellen:

• Alla relationslinjer går i horisontell eller vertikal position. Inga linjer korsas.
• Attributnamn stavas utan mellanslag i namnen. Inga förkortningar används.
• Varje relation har två väldigt fraser som vi kan göra relationsmeningar av (se nästa avsnitt).
• Diagrammet har också en "legend" i det övre högra hörnet så att vi kan se vad diagrammet representerar och vem som senast ändrade diagrammet.

Relationsmeningar

En Kund kan vara göra ett eller flera möten

Ett möte måste vara en reservation för en och endast en Kund

En SalonService kan vara en tjänst som tillhandahålls som en eller flera ServiceRendered

En ServiceRendered måste vara en återgivning av en och endast en SalonService

En anställd kan vara rendering en eller flera ServiceRendered

En ServiceRendered måste vara återges av en och endast en anställd
 

Ett möte kan vara en reservation för att tillhandahålla en eller flera ServiceRendered

En ServiceRendered måste vara en specifik tjänst som utförs under ett och endast ett möte

Kommentar

Relationsmeningarna borde vara vettiga. I det här exemplet är verbfraserna understrukna. Enhetsnamnen är i fetstil. Minsta kardinalitet (kan vara för 0 och måste vara för 1) är skrivna i kursiv stil. Den maximala kardinaliteten skrivs som "en eller flera" för * och "en och bara en" för 1.

När ER-modellen är klar, går vi vidare till nästa steg – att konvertera den konceptuella ER-modellen till en logisk relationsmodell.

III. Konvertering till relationsmodell

Nästa steg är att konvertera Entity Relationship-diagrammet till en relationsmodell. Under detta steg blir identifierare i enheterna nycklar i relationerna. En-till-många-relationer resulterar i att en främmande nyckel kopieras från en-till-många-sidan av relationen.

Kund ( Kund-ID (nyckel), Förnamn, Efternamn, Telefonnummer, Gata, Stad, Stat, Postnummer )

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

Anställd ( Anställds-ID (nyckel), Förnamn, Efternamn, Gata, Stad, Stat, Postnummer, Lönekostnad )

Avbokning ( AppointmentID (nyckel), AppointmentDate, ApotinmentTime, CustomerID (fk) )

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

Detta är den "initiala uppsättningen av relationer."

Kommentar

• Lägg märke till att ServiceRendered Entiteten från ER-modellen är ID-beroende vilket innebär att den behöver ett attribut utöver LineItemNumber för att bilda en sammansatt nyckel.
• Nycklar visas med (nyckel)beteckningen och främmande nycklar visas med (fk)beteckningen.

Nästa steg är att normalisera den initiala uppsättningen av relationer.

IV. Normalisering

Nästa steg är att normalisera relationerna.

Stegen att följa för varje relation är:

1. Skriv ut relationen inklusive alla attributnamn. Ange nycklar och främmande nycklar.
2. Ange några exempeldata för relationen.
3. Ange nyckeln för relationen och skriv ner alla funktionella beroenden .
4. Gå igenom definitionerna för varje normal form som börjar med 1NF och går upp till BCNF (eller 3NF beroende på dina projektkrav).
5. Om en relation uppfyller definitionen av en normalform, gå upp till nästa högre normalform.
6. Om en relation inte uppfyller definitionen av en normal form (t.ex. den innehåller ett partiell nyckelberoende eller det innehåller ett transitivt beroende), dela upp relationen i två nya relationer.
   Börja normaliseringsprocessen från början med var och en av dessa två nya relationer.

Kundrelation

Kund ( kund-ID (nyckel) , förnamn, efternamn, kundtelefon, gata, stad, stat, postnummer, kön )

Exempeldata

Nyckel:Kund-ID

FD1:Kund-ID -> Förnamn, Efternamn, Telefonnummer, Gata, Stad, Stat, Postnummer, Kön

FD2:Postnummer -> Stad, delstat

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Transitivt beroende existerar:Kund-ID -> Postnummer och postnummer -> Stad, delstat

Lösning:Dela upp kundrelationen i två nya relationer som heter CustomerData och ZipCodes:

Kunddata (kund-ID (nyckel), förnamn, efternamn, kundtelefon, gata, postnummer (fk), kön )

Nyckel:Kund-ID

FD1:Kund-ID -> Förnamn, Efternamn, Telefonnummer, Gata, Postnummer (fk), Kön

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

Postnummer( postnummer (nyckel), stad, delstat)

Nyckel:Postnummer

FD1:Postnummer -> Stad, delstat

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

SalonService Relation

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

Exempeldata:

Nyckel:ServiceID

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

1NF:ServiceMaterials kan behandlas som ett attribut med flera värden. I det här fallet finns inte SalonService i 1NF.

Lösning:Dela upp ServiceMaterials i en separat relation.

För det här exemplet kommer vi dock att behålla ServiceMaterials som ett attribut för SalonService-relationen.

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

Anställda relationer

Anställd( anställd-ID (nyckel), förnamn, efternamn, gata, stad, stat, postnummer, lönesats )

Nyckel:EmployeeID

FD1:EmployeeID -> Förnamn, Efternamn, Gata, Stad, Stat, Postnummer, PayRate

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Transitivt beroende existerar:Anställds-ID -> Postnummer och postnummer -> Stad, delstat

Lösning:Dela upp kundrelationen i två nya relationer som heter EmployeeData och ZipCodes:

EmployeeData(EmployeeID (nyckel), FirstName, AfterName, Street, Postnummer (fk), PayRate )

Nyckel:EmployeeID

FD1:EmployeeID -> Förnamn, Efternamn, Gata, Postnummer (fk), PayRate

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

Obs:Vi har redan en postnummerrelation från när kundrelationen delades upp. Så vi återanvänder postnummerrelationen. Det finns inget behov av att skapa en andra postnummerrelation.

Utnämningsrelation

Avbokning ( Utnämnings-ID (nyckel), Utnämningsdatum, Tid för möte, Kund-ID (fk) )

Exempeldata:

Nyckel:Utnämnings-ID

FD1:AppointmentID -> AppointmentDate, ApotinmentTime, CustomerID (fk)

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

ServiceRendered Relation

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

Exempeldata:

Nyckel:AppointmentID, LineItemNumber

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

1NF:Uppfyller definitionen av en relation

2NF:Inga partiella nyckelberoenden

3NF:Inga transitiva beroenden

BCNF:Alla determinanter är kandidatnycklar

Slutliga relationer

Kund ( Kund-ID (nyckel) , Förnamn, Efternamn, Telefonnummer, Gata, Postnummer (fk), Kön )

Postnummer ( Postnummer (nyckel), stad, delstat)

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

Anställd ( Anställds-ID (nyckel), Förnamn, Efternamn, Gata, Postnummer (fk), Lönpris )

Avbokning ( AppointmentID (nyckel), AppointmentDate, ApotinmentTime, CustomerID (fk) )

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

Kommentar

• Observera att endast en postnummerrelation krävs. Den delas med både kund- och anställdrelationer.
• Som nämnts tidigare har attributet ServiceMaterials inte normaliserats i det här exemplet. Kanske kan det göras i ett framtida uppdrag eller förbättring av modellen.

Nu när relationerna är normaliserade kan schemat skapas i ett databashanteringssystem som använder strukturerat frågespråk (SQL).

V. Skapa databasschemat med Structured Query Language

Skapa en tabell i databasen för var och en av relationerna i den slutliga uppsättningen av relationer.

Följande SQL-kod skapar de sex tabellerna och lägger till PRIMARY KEY-begränsningen till var och en:

CREATE TABLE ZipCodes
(
    zipcode    VARCHAR(12) NOT NULL,
    city       VARCHAR(36),
    state      VARCHAR(4),
    CONSTRAINT pk_zipcodes
          PRIMARY KEY (zipcode)
)


CREATE TABLE Customer
(
    CustomerID   VARCHAR(10) NOT NULL,
    FirstName    VARCHAR(35),
    LastName     VARCHAR(35),
    PhoneNumber  VARCHAR(15),
    Street       VARCHAR(35),
    ZipCode      VARCHAR(12),
    Gender       VARCHAR(2),
    CONSTRAINT pk_customer
          PRIMARY KEY (CustomerID)
)

CREATE TABLE Appointment
(
    AppointmentID       VARCHAR(10) NOT NULL,
    AppointmentDateTime DATE,
    CustomerID          VARCHAR(10) NOT NULL,
    CONSTRAINT pk_appointment
          PRIMARY KEY (AppointmentID)
)

CREATE TABLE SalonService
(
    ServiceID         VARCHAR(10) NOT NULL, 
    ServiceName       VARCHAR(35),
    ServiceDuration   INTEGER, 
    ServicePrice      NUMBER, 
    ServiceMaterials  VARCHAR(255),
    CONSTRAINT pk_salonservice
        PRIMARY KEY (ServiceID)
)

CREATE TABLE Employee 
(
    EmployeeID     VARCHAR(10) NOT NULL,
    FirstName      VARCHAR(35), 
    LastName       VARCHAR(25), 
    Street         VARCHAR(45), 
    ZipCode        VARCHAR(12), 
    PayRate        NUMBER,
     CONSTRAINT pk_employee
       PRIMARY KEY (EmployeeID)
)

CREATE TABLE ServiceRendered 
( 
    AppointmentID         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)
)

Lägga till främmande nycklar

Följande SQL-koder lägger till FOREIGN KEY-begränsningar för att länka samman tabellerna:

ALTER TABLE Customer
   ADD CONSTRAINT fk_customer_zipcodes
     FOREIGN KEY (ZipCode) 
        REFERENCES ZipCodes (ZipCode)

ALTER TABLE Employee
   ADD CONSTRAINT fk_employee_zipcodes
     FOREIGN KEY (ZipCode) 
        REFERENCES ZipCodes (ZipCode)

ALTER TABLE Appointment
   ADD CONSTRAINT fk_customer_appointment
     FOREIGN KEY (CustomerID) 
        REFERENCES Customer (CustomerID)

ALTER TABLE ServiceRendered
   ADD CONSTRAINT fk_ServiceRendered_Service
     FOREIGN KEY (ServiceID) 
        REFERENCES SalonService (ServiceID)

ALTER TABLE ServiceRendered
   ADD CONSTRAINT fk_ServiceRendered_Employee
     FOREIGN KEY (EmployeeID) 
        REFERENCES Employee (EmployeeID)

ALTER TABLE ServiceRendered
   ADD CONSTRAINT fk_ServiceRendered_Appointment
     FOREIGN KEY (AppointmentID) 
        REFERENCES Appointment (AppointmentID)

Kommentar till SQL:

• De flesta DBMS lagrar DATUM och TID i samma kolumn. Så AppointmentDate och AppointmentTime kombinerades till en kolumn i databasen med namnet AppointmentDateTime
• Nycklar och främmande nycklar bör ha exakt samma namn och datatyp. Till exempel är Key CustomerID VARCHAR(10) i Kundtabellen och även VARCHAR(10) i Mötestabellen.
• Begränsningar ges meningsfulla namn som pk_customer för en primärnyckel och fk_customer_zipcodes för en främmande nyckel.
• Kolumner som telefonnummer och postnummer ska använda datatypen VARCHAR. Om en datatyp NUMBER eller INTEGER används, kommer de inledande nollorna att saknas.

Efter att ha skapat tabellerna och lagt till begränsningarna för främmande nyckel ser databasschemat nu ut så här:

Relationsvy

Med hjälp av relationsvyn under Databasverktyg kan vi se relationerna (främmande nycklar) mellan tabellerna:

Lägga till data i tabellerna med SQL INSERT-satser

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');
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');
INSERT INTO Customer VALUES ('C107', 'Faye', 'Glenn', '201-333-4242', '1522 Main St', '07010', 'F');
INSERT INTO Customer VALUES ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', 'F');

INSERT INTO SalonService VALUES ('SV101', 'Men''s Haircut', 20, 22, 'None');
INSERT INTO SalonService VALUES ('SV102', 'Women''s Haircut', 30, 32, 'None');
INSERT INTO SalonService VALUES ('SV103', 'Child Haircut', 20, 15, 'None');
INSERT INTO SalonService VALUES ('SV104', 'Women''s Hair Color', 60, 76, 'Color, Reagent, Gloves, Reagent Brush, Foil');
INSERT INTO SalonService VALUES ('SV105', 'Women''s Hair Style', 45, 56, 'Shampoo, Conditioner');
INSERT INTO SalonService VALUES ('SV106', 'Men''s Hair Style', 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. 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 Appointment VALUES ('A400', '10/22/2017 11:00:00 AM', 'C101');
INSERT INTO Appointment VALUES ('A401', '11/06/2017 12:45:00 PM', 'C102');
INSERT INTO Appointment VALUES ('A402', '12/07/2017 02:00:00 PM', 'C106');
INSERT INTO Appointment VALUES ('A403', '12/18/2017 03:30:00 PM', 'C106');
INSERT INTO Appointment VALUES ('A404', '12/21/2017 11:30:00 AM', 'C108');
INSERT INTO Appointment VALUES ('A405', '12/31/2017 10:00:00 AM', 'C107');
INSERT INTO Appointment VALUES ('A406', '01/11/2018 03:15:00 PM', 'C103');
INSERT INTO Appointment VALUES ('A407', '01/12/2018 02:30:00 PM', 'C104');
INSERT INTO Appointment VALUES ('A408', '01/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 om dataprover

• Vi lägger till precis tillräckligt med data för att kunna testa relationerna mellan tabellerna och för att ge applikationsutvecklarna något att arbeta med.
• Var försiktig med i vilken ordning data läggs till. Till exempel måste alla postkoder infogas först, innan antingen kund eller anställd (som båda använder postnummer som främmande nyckel) kan infogas.
• När du lägger till VARCHAR-data med inbäddade citattecken, använd två citattecken tillsammans. t.ex. "Kvinnors hårstil"
• Vid denna tidpunkt är databasschemat redo för applikationsutvecklarna att börja arbeta med att utforma formulär, rapporter och frågor.

Nu när databasschemat har skapats och är fyllt med några exempeldata, kan databasapplikationen utvecklas.

VI. Databasapplikation

Databasapplikationen består av en uppsättning formulär, rapporter och frågor som är länkade tillsammans på ett navigeringsformulär.

Navigationsformuläret är det första formuläret som visas när databasen öppnas.

Navigeringsformulär

Olika datainmatningsformulär och rapporter kan visas genom att klicka på valet till vänster.

Formulär för kunddatainmatning

Formuläret Kunddatainmatning används för att söka upp befintliga kunder och för att mata in ny kundinformation. Fälten Stad och delstat fylls i automatiskt genom att välja postkod från kombinationsrutan. Formuläret har flera anpassade VBA-koder för att konvertera för- och efternamn till versaler och för att generera ett nytt, unikt kund-ID när ett tomt kund-ID-fält visas efter att ha skapat en ny post.

Datainmatningsformulär för Salong Services

Salong Service Data Entry-formuläret används för att fråga, uppdatera och lägga till nya salongstjänster.

Inmatningsformulär för mötesdata

Formuläret Mötesdatainmatning används för att skapa ett nytt möte för en kund. Precis som med kundformuläret kan ett nytt mötes-ID skapas genom att klicka i ett tomt mötes-ID-fält efter att en ny post har skapats. Kunden kan väljas från kombinationsrutan Kund-ID enligt nedan:

Om det här är en ny kund som bokar ett möte kan användaren klicka på knappen Ny kund för att få upp formuläret för inmatning av kunddata. När den nya kundens information har sparats kan användaren gå tillbaka till formuläret för inmatningsdata och boka tid.

formulär för möten och tjänster

Syftet med detta formulär är att ange olika tjänster kopplade till ett möte. Detta formulär kan också användas för att generera en faktura till kunden. Tjänsten och den anställde kan väljas från sina respektive kombinationsrutor enligt nedan:

Rapport för totala kundmöten

Den här rapporten ger en sammanfattning av antalet möten och det totala belopp som spenderats av varje kund.

Baserat på fråga:

SELECT   Customer.CustomerID, FirstName, LastName, 
         SUM(q.TotalSpent) AS TotalSpent, 
         COUNT(q.AppointmentID) AS NumberOfAppointments
FROM     Customer, Appointment, Query_Total_Spent_Each_Appointment AS q
WHERE    Customer.CustomerID = Appointment.CustomerID
          AND  Appointment.AppointmentID = q.AppointmentID
GROUP BY Customer.CustomerID, FirstName, LastName
ORDER BY LastName, FirstName;

Och fråga Total_Spent_Each_Appointment

SELECT   Appointment.AppointmentID, 
         SUM(ServiceExtendedPrice) AS TotalSpent
FROM     Appointment, ServiceRendered
WHERE    Appointment.AppointmentID = ServiceRendered.AppointmentID
GROUP BY Appointment.AppointmentID
ORDER BY Appointment.AppointmentID;

Tjänster och rabatter rapport

Den här rapporten visar var och en av tjänsterna med summan av det ordinarie servicepriset, det utökade priset och en indikation på rabattbeloppet för de tjänster som utförts tidigare.

Baserat på fråga:

SELECT SalonService.ServiceID, ServiceName, 
       SUM(ServicePrice) AS TotalServicePrice, 
       SUM(ServiceExtendedPrice) AS TotalExtPrice, 
       FORMAT(1.0 - (SUM(ServiceExtendedPrice) / SUM(ServicePrice)), "0.00%") 
                   AS Discount
FROM SalonService, ServiceRendered
WHERE SalonService.ServiceID = ServiceRendered.ServiceID
GROUP BY SalonService.ServiceID, ServiceName
ORDER BY SalonService.ServiceID, ServiceName;

Kundadressrapport

Denna rapport visar fullständiga namn och adresser för varje kund.

VII. Slutsatser

Att utveckla en databasapplikation följer en systemutvecklingslivscykel som börjar med konceptuell modellering och flyttas genom en strukturerad uppsättning steg som inkluderar logisk modellering, normalisering, fysisk implementering och applikationsutveckling. Hårsalongsprojektets exempel illustrerar vart och ett av dessa viktiga steg. Vissa detaljer har dock inte dokumenterats helt. Till exempel kan det krävas ytterligare arbete för att normalisera Salong Services-relationen för att ta hänsyn till olika material som används för varje tjänst. Ytterligare applikationsimplementeringsdetaljer som andra VBA-koder och mer detaljerade beskrivningar av användningen av varje formulär och rapport kan också läggas till.