Projekt databáze kadeřnictví

Aktualizováno:22. ledna 2018 Richard Holowczak

Následující materiály dokumentují návrh a vývoj databázové aplikace pro podporu malého kadeřnictví. Projekt začíná popisem podnikání a pokračuje přes koncepční (E-R) modelování, logické (relační) modelování, Fyzické modelování a nakonec implementaci databázové aplikace. Poznámky (komentář) jsou uvedeny na konci každé části, aby vysvětlily některé specifické vlastnosti prováděných kroků.

Obsah

I. Podnikatelský scénář
II. Model ER využívající notaci UML
III. Převod na relační model
IV. Normalizace
V. Vytvoření schématu databáze pomocí SQL
VI. Databázová aplikace
VII. Závěry

.

I. Podnikatelský scénář

Naše společnost vlastní a provozuje kadeřnický a nehtový salon v centru Manhattanu již 7 let. Ke sledování zákazníků, schůzek a plateb používáme tabulky a papírový deník. Rádi bychom tuto manuální metodu sledování firmy nahradili databází.

V našem podnikání si zákazníci sjednávají schůzky se svým oblíbeným kadeřníkem (lidé, kteří stříhají a upravují vlasy zákazníků) nebo jiným zaměstnancem a mohou si dopřát řadu služeb, jako je základní střih/styling, barva vlasů, melír, trvalá, obličej, manikúru, pedikúru atd. Musíme mít přehled o materiálech (šampon, barva na vlasy) a době, kterou zabere dokončení každé služby. I když má každá služba standardní cenu, propagační akce a další faktory mohou ovlivnit skutečnou cenu poskytnutou zákazníkovi za danou službu.

Potřebujeme také sledovat naše zaměstnance, včetně jejich domácí adresy, kontaktních informací a mzdové sazby. Musíme sledovat kontaktní údaje každého zákazníka a také jeho pohlaví. U schůzek potřebujeme znát datum a čas schůzky a pro kterého zákazníka je schůzka určena.

Komentář

Na základě výše uvedeného popisu vytvořte model vztahu entit pomocí notace UML, který bude zachycovat všechny potřeby podnikových dat.

II. Model ER pomocí notace UML

Na základě výše uvedeného popisu vyvíjíme následující model vztahu entit pomocí notace UML.

Komentář

Co se nám na tomto modelu líbí:

• Všechny čáry vztahu jsou ve vodorovné nebo svislé poloze. Nejsou překročeny žádné čáry.
• Názvy atributů jsou hláskovány bez mezer v názvech. Nejsou použity žádné zkratky.
• Každý vztah má dvě velmi fráze, ze kterých můžeme vytvořit vztahové věty (viz další část).
• Diagram má také „legendu“ v pravém horním rohu, takže můžeme říci, co diagram představuje a kdo jej naposledy upravil.

Věty o vztahu

Jeden zákazník může být provedení jedné nebo více Schůzek

Jedna Schůzka musí být rezervace pro jednoho a pouze jednoho zákazníka

Jeden SalonService může být služba poskytovaná jako jedna nebo více ServiceRendered

Jedna ServiceRendered musí být vykreslení jednoho a pouze jednoho SalonService

Jeden zaměstnanec může být vykreslování jeden nebo více ServiceRendered

Jedna ServiceRendered musí být vykreslený jedním a pouze jedním zaměstnancem

Jedna Schůzka může být rezervaci poskytující jednu nebo více ServiceRendered

Jedna ServiceRendered musí být konkrétní služba poskytnutá během jedné a pouze jedné Schůzky

Komentář

Vztahové věty by měly dávat smysl. V tomto příkladu jsou slovesné fráze podtržené. Názvy entit jsou vytištěny tučně. Minimální mohutnost (může být pro 0 a musí být pro 1) jsou psány kurzívou. Maximální mohutnost je zapsána jako „jeden nebo více“ pro * a „jeden a pouze jeden“ pro 1.

Po dokončení ER modelu přejdeme k dalšímu kroku – převedení konceptuálního ER modelu na logický relační model.

III. Převod na relační model

Dalším krokem je převod diagramu vztahů entit na relační model. Během tohoto kroku se identifikátory v entitách stanou klíči ve vztazích. Vztahy typu One-to-Many vedou ke zkopírování cizího klíče z jedné strany vztahu na stranu Mnoho.

Zákazník ( ID zákazníka (klíč), jméno, příjmení, telefonní číslo, ulice, město, stát, PSČ )

SalonService ( ServiceID (klíč), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Zaměstnanec ( ID zaměstnance (klíč), jméno, příjmení, ulice, město, stát, PSČ, mzda )

Schůzka ( AppointmentID (klíč), AppointmentDate, AppointinmentTime, CustomerID (fk) )

ServiceRendered ( ID schůzky (fk) (klíč), Číslo položky (klíč), ID služby (fk), ServiceExtendedPrice, ID zaměstnance (fk))

Toto je „počáteční soubor vztahů.“

Komentář

• Všimněte si, že ServiceRendered entita z modelu ER je závislá na ID, což znamená, že k vytvoření složeného klíče potřebuje kromě LineItemNumber také atribut.
• Klíče se zobrazují s označením (klíč) a cizí klíče s označením (fk).

Dalším krokem je normalizace počáteční sady vztahů.

IV. Normalizace

Dalším krokem je normalizace vztahů.

Kroky, které je třeba provést pro každý vztah, jsou:

1. Napište vztah včetně všech názvů atributů. Uveďte klíče a cizí klíče.
2. Poskytněte některá vzorová data pro vztah.
3. Uveďte Klíč pro vztah a zapište si všechny Funkční závislosti .
4. Projděte si definice každé normální formy počínaje 1NF až po BCNF (nebo 3NF v závislosti na požadavcích vašeho projektu).
5. Pokud vztah splňuje definici normální formy, přejděte na další vyšší normální formu.
6. Pokud vztah nesplňuje definici normální formy (např. obsahuje závislost částečného klíče nebo obsahuje tranzitivní závislost), rozdělte vztah na dva nové vztahy.
   Začněte proces normalizace od začátku s každým z těchto dvou nových vztahů.

Vztah se zákazníky

Zákazník ( ID zákazníka (klíč) , jméno, příjmení, vlastní telefon, ulice, město, stát, PSČ, pohlaví)

Ukázková data

Klíč:CustomerID

FD1:CustomerID -> Jméno, Příjmení, Telefonní číslo, Ulice, Město, Stát, PSČ, Pohlaví

FD2:PSČ -> Město, stát

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Existuje přechodná závislost:CustomerID -> PSČ a PSČ -> Město, stát

Řešení:Rozdělte vztah se zákazníkem na dva nové vztahy s názvem CustomerData a PSČ:

Zákaznická data (CustomerID (klíč), Jméno, Příjmení, Vlastní telefon, Ulice, PSČ (fk), Pohlaví)

Klíč:CustomerID

FD1:CustomerID -> Jméno, Příjmení, Telefonní číslo, Ulice, PSČ (fk), Pohlaví

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

PSČ ( PSČ (klíč), město, stát)

Klíč:PSČ

FD1:PSČ -> Město, stát

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

SalonService Relation

SalonService ( ServiceID (klíč), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Ukázková data:

Klíč:ServiceID

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

1NF:ServiceMaterials lze považovat za atribut s více hodnotami. V tomto případě SalonService není v 1NF.

Řešení:Rozdělte ServiceMaterials do samostatného vztahu.

Pro tento příklad však ponecháme ServiceMaterials jako atribut vztahu SalonService.

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

Zaměstnanecký vztah

Zaměstnanec (ID zaměstnance (klíč), jméno, příjmení, ulice, město, stát, PSČ, mzda )

Klíč:EmployeeID

FD1:EmployeeID -> First Name, Last Name, Street, City, State, PSČ, Pay Rate

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Existuje tranzitivní závislost:EmployeeID -> ZipCode a ZipCode -> City, State

Řešení:Rozdělte vztahy se zákazníky do dvou nových vztahů s názvem EmployeeData a ZipCodes:

Údaje o zaměstnanci (ID zaměstnance (klíč), jméno, příjmení, ulice, PSČ (fk), mzdová sazba)

Klíč:EmployeeID

FD1:EmployeeID -> First Name, Last Name, Street, PSČ (fk), PayRate

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

Poznámka:Již máme vztah PSČ z doby, kdy byl vztah se zákazníkem rozdělen. Takže znovu použijeme vztah PSČ. Není potřeba vytvářet druhý vztah PSČ.

Vztah ke schůzce

Schůzka ( AppointmentID (klíč), AppointmentDate, AppointmentTime, CustomerID (fk) )

Ukázková data:

Klíč:AppointmentID

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

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

SlužbaRendered Relation

ServiceRendered ( AppointmentID (fk) (klíč), LineItemNumber (klíč), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk) )

Ukázková data:

Klíč:AppointmentID, LineItemNumber

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

1NF:Splňuje definici vztahu

2NF:Žádné dílčí klíčové závislosti

3NF:Žádné tranzitivní závislosti

BCNF:Všechny determinanty jsou kandidátskými klíči

Konečná sada vztahů

Zákazník ( ID zákazníka (klíč) , jméno, příjmení, telefonní číslo, ulice, PSČ (fk), pohlaví )

PSČ ( PSČ (klíč), město, stát)

SalonService ( ServiceID (klíč), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Zaměstnanec ( ID zaměstnance (klíč), jméno, příjmení, ulice, PSČ (fk), mzda )

Schůzka ( AppointmentID (klíč), AppointmentDate, AppointinmentTime, CustomerID (fk) )

ServiceRendered ( ID schůzky (fk) (klíč), Číslo položky (klíč), ID služby (fk), ServiceExtendedPrice, ID zaměstnance (fk))

Komentář

• Upozorňujeme, že je vyžadován pouze jeden vztah PSČ. Je sdílen jak se zákazníky, tak se zaměstnanci.
• Jak bylo uvedeno dříve, atribut ServiceMaterials nebyl v tomto příkladu normalizován. Možná to lze provést v budoucím úkolu nebo vylepšení modelu.

Nyní, když jsou vztahy normalizovány, lze schéma vytvořit v systému správy databází pomocí strukturovaného dotazovacího jazyka (SQL).

V. Vytvoření schématu databáze pomocí strukturovaného dotazovacího jazyka

Vytvořte v databázi tabulku pro každý vztah v konečné sadě vztahů.

Následující kód SQL vytvoří šest tabulek a ke každé přidá omezení PRIMARY KEY:

CREATE TABLE PSČ( PSČ VARCHAR(12) NOT NULL, město VARCHAR(36), stát VARCHAR(4), CONSTRAINT pk_zipcodes PRIMÁRNÍ KLÍČ (PSČ))CREATE TABLE Customer( CustomerID VARCHAR(10) NOT NULL, FirstName VARCHAR 35), Příjmení VARCHAR(35), Telefonní číslo VARCHAR(15), Ulice VARCHAR(35), PSČ VARCHAR(12), Pohlaví VARCHAR(2), OMEZENÍ pk_customer PRIMÁRNÍ KLÍČ (ID zákazníka))VYTVOŘIT TABULKU Schůzka (VARCHARCHAR10) 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 ServicePrice25GER, ServiceDuration Service INTEGER ), CONSTRAINT pk_salonservice PRIMÁRNÍ KLÍČ (ID služby))VYTVOŘIT TABULKU Zaměstnanec (ID zaměstnance VARCHAR(10) NE N ULL, Jméno VARCHAR(35), Příjmení VARCHAR(25), Ulice VARCHAR(45), PSČ VARCHAR(12), ČÍSLO Mzdové sazby, OMEZENÍ Pk_employee PRIMÁRNÍ KLÍČ (ID zaměstnance))VYTVOŘIT TABULKU NOT ServiceRendered (ItCHARNember 10 Řádek) INTEGER NOT NULL, ServiceID VARCHAR(10) NOT NULL, ServiceExtendedPrice NUMBER, EmployeeID VARCHAR(10) NOT NULL, CONSTRAINT pk_ServiceRendered PRIMARY KEY (AppointmentID, LineItemNumber))

Přidání cizích klíčů

Následující kódy SQL přidávají omezení FOREIGN KEY k propojení tabulek:

 Změna tabulky Zákazník Přidání Omezení fk_customer_zipcodes cizí klíč (ZIPCode) Reference ZipCodes (ZIPCode) Alter Tabulka Zaměstnanec Přidat omezení fk_employee_zipCodes cizí klíč (ZipCode) Reference ZipCodes (Zipcode) Alter Talking Choption (CustoiRID CUNSIONS CUNSIONS) )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) 
 

 Komentář k SQL:
 
 
Většina DBMS uloží DATUM a ČAS do stejného sloupce. Takže AppointmentDate a AppointmentTime byly sloučeny do jednoho sloupce v databázi s názvem AppointmentDateTime
 
Klíče a cizí klíče by měly mít stejný přesný název a datový typ. Například klíč CustomerID je VARCHAR(10) v tabulce Customer a také VARCHAR(10) v tabulce Appointment.
 
Omezení dostávají smysluplné názvy, jako je pk_customer pro primární klíč a fk_customer_zipcodes pro cizí klíč.
 
Sloupce jako Telefonní číslo a PSČ by měly používat datový typ VARCHAR. Pokud je použit datový typ NUMBER nebo INTEGER, budou úvodní nuly chybět.
 
 
 

 Po vytvoření tabulek a přidání omezení cizího klíče nyní schéma databáze vypadá takto:
 
 

 
 
 
Zobrazení vztahu
 

 Pomocí pohledu Relationship View pod Databázovými nástroji můžeme vidět vztahy (cizí klíče) mezi tabulkami:
 

 
 

 
 
 
Přidávání dat do tabulek pomocí příkazů SQL INSERT
 
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');VLOŽTE DO HODNOT zákazníka ('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', '1 522 Main St', '07010', 'F');INSERT INTO Customer VALUES ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', ' F');VLOŽTE DO HODNOT SalonService ('SV101', 'Pánské střihy', 20, 22, 'Žádné');VLOŽTE DO HODNOT SalonService ('SV102', 'Dámský střih', 30, 32 , 'None');INSERT INTO SalonService VALUES ('SV103', 'Dětský účes', 20, 15, 'None');VLOŽTE DO HODNOT SalonService ('SV104', 'Barva vlasů pro ženy', 60, 76 , 'Barva, činidlo, rukavice, štětec na činidla, fólie');VLOŽTE DO HODNOT SalonService ('SV105', 'Účes pro ženy', 45, 56, 'Šampón, kondicionér');VLOŽTE DO HODNOT SalonService (' SV106', 'Pánský účes', 45, 46, 'Šampón, kondicionér');VLOŽTE DO HODNOT zaměstnanců ('E300', 'Joy', 'Aveda', '46 Easton Ave.', '07026' , 18);VLOŽTE DO HODNOT zaměstnanců ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. Apt. 2A', '07026', 22);VLOŽTE DO HODNOT zaměstnanců ('E500', 'Koy', 'Petruzzio', '70 Wilard St. ', '07026', 20);VLOŽTE DO HODNOT zaměstnanců ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18);INSERT INTO Employee VALUES ('E700', 'Pat', 'Reese', '2 Lincoln Place', '07010', 23);VLOŽTE DO HODNOT zaměstnance ('E800', 'Winter', 'Tanner', '215 Elm Ave', '07665', 23);VLOŽTE DO HODNOT Schůzky ('A400', '22. 10. 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 14:00:00 PM', 'C106');INSERT INTO Appointment VALUES ('A403', '18/12/2017 15:30:00 PM', 'C106');INSERT INTO Appointment VALUES ('A404' ', '21/12/2017 11:30:00 AM', 'C108');VLOŽIT DO HODNOT Schůzky ('A405', '31. 12. 2017 10:00:00 AM', 'C107');INSERT INTO HODNOTY Schůzky ('A406', '01/11/2018 15:15:00 PM', 'C103');INSERT INTO Appointment VALUES ('A407', '01/12/2018 14:30:00', 'C104');VLOŽIT DO HODNOT Schůzky ('A408', '0 22. 1. 2018 16: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, 'SV75104', , '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'); A405', 2, 'SV104', 70, 'E700');INSERT INTO ServiceRendered VALUES ('A405', 3, 'SV105', 50, 'E700');
 
Komentář k ukázkám dat
 
 
Přidáváme jen tolik dat, abychom mohli otestovat vztahy mezi tabulkami a dát vývojářům aplikací něco, s čím mohou pracovat.
 
Dávejte pozor na pořadí, ve kterém jsou data přidávána. Například všechna PSČ je třeba vložit jako první, než bude možné vložit zákazníka nebo zaměstnance (kteří oba používají PSČ jako cizí klíč).
 
Při přidávání dat VARCHAR s vloženými uvozovkami použijte dvě uvozovky společně. např. ‚Dámský účes‘
 
V tuto chvíli je schéma databáze připraveno pro vývojáře aplikací, aby mohli pracovat na navrhování formulářů, sestav a dotazů.
 
 

 Nyní, když je schéma databáze vytvořeno a je naplněno některými ukázkovými daty, lze vyvinout databázovou aplikaci.
 

 
 
VI. Databázová aplikace
 

 Databázová aplikace se skládá ze sady formulářů, sestav a dotazů, které jsou vzájemně propojeny v navigačním formuláři.
 

 Navigační formulář je první formulář, který se objeví při otevření databáze.
 
 
Navigační formulář
 

 
 

 Různé formuláře pro zadávání dat a sestavy lze zobrazit kliknutím na výběr na levé straně.
 
 
Formulář pro zadání údajů o zákaznících
 

 
 

 Formulář pro zadání údajů o zákaznících se používá k vyhledání stávajících zákazníků a k zadání informací o nových zákaznících. Pole Město a Stát se automaticky vyplní výběrem PSČ z Combo Boxu. Formulář má několik vlastních kódů VBA pro převod křestních jmen a příjmení na správná velká a malá písmena a pro vygenerování nového, jedinečného ID zákazníka, když se objeví prázdné pole CustomerID. po vytvoření nového záznamu.
 
 

 
 
 
Formulář pro zadání dat služeb salonu
 

 
 

 Formulář pro zadání dat služeb salonu se používá k dotazování, aktualizaci a přidávání nových služeb salonu.
 
 
Formulář pro zadání údajů o schůzce
 

 
 

 Formulář pro zadání dat schůzek se používá k vytvoření nové schůzky pro zákazníka. Stejně jako u formuláře Zákazník lze nové ID schůzky vytvořit kliknutím do prázdného pole ID schůzky po vytvoření nového záznamu. Zákazníka lze vybrat z rozbalovacího pole Číslo zákazníka, jak je znázorněno níže:
 

 
 

 Pokud se jedná o nového zákazníka, který si sjednává schůzku, může uživatel kliknout na tlačítko Nový zákazník a vyvolat formulář pro zadání zákaznických dat. Po uložení informací o novém zákazníkovi se uživatel může vrátit do formuláře pro zadání údajů o schůzce a domluvit si schůzku.
 
 
Formulář pro schůzky a služby
 

 
 

 Účelem tohoto formuláře je zadat různé služby spojené se schůzkou. Tento formulář lze také použít ke generování vyúčtování pro zákazníka. Službu a zaměstnance lze vybrat z jejich příslušných rozbalovacích polí, jak je uvedeno níže:
 

 
 

 
Přehled celkových schůzek zákazníků
 

 
 

 Tento přehled poskytuje souhrn počtu schůzek a celkové částky utracené každým zákazníkem.
 
 

 Na základě dotazu:
 
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.CustomerCpoint AND AppointID Appointment. AppointmentIDGROUP BY Customer.CustomerID, FirstName, LastNameORDER BY LastName, FirstName;
 
 

 A dotaz Total_Spent_Každá_schůzka
 
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;
 
 
Přehled služeb a slev
 

 
 

 Tento přehled zobrazuje každou ze služeb s celkovými cenami běžné služby, prodlouženou cenou a údajem o výši slevy uplatněné na služby poskytnuté v minulosti.
 
 

 Na základě dotazu:
 
SELECT SalonService.ServiceID, ServiceName, SUM(ServicePrice) AS TotalServicePrice, SUM(ServiceExtendedPrice) AS TotalExtPrice, FORMAT(1.0 - (SUM(ServiceExtendedPrice)/SUM(ServicePrice)), "0.00%") JAKO Sleva ZE SalonService, ServiceRenderedWHERE SalonService.ServiceID =ServiceRendered.ServiceIDGROUP BY SalonService.ServiceID, ServiceNameORDER BY SalonService.ServiceID, ServiceName;
 
 
Přehled adres zákazníků
 

 
 

 Tento přehled zobrazuje úplná jména a adresy každého zákazníka.
 

 
 
VII. Závěry
 

 Vývoj databázové aplikace se řídí životním cyklem vývoje systému, který začíná koncepčním modelováním a prochází strukturovanou sadou kroků, které zahrnují logické modelování, normalizaci, fyzickou implementaci a vývoj aplikací. Příklad projektu Kadeřnictví ilustruje každý z těchto hlavních kroků. Některé detaily však nebyly plně zdokumentovány. Například může být zapotřebí nějaká další práce k normalizaci vztahu služeb salonu, aby bylo možné zohlednit různé materiály používané pro každou službu. Mohou být také přidány další podrobnosti implementace aplikace, jako jsou další kódy VBA a podrobnější popisy použití každého formuláře a sestavy.