Проект база данни за фризьорски салон

Актуализирано:22 януари 2018 г. от Richard Holowczak

Следните материали документират дизайна и разработването на приложение за база данни за поддръжка на малък фризьорски салон. Проектът започва с описание на бизнеса и продължава през концептуално (E-R) моделиране, логическо (релационно) моделиране, физическо моделиране и накрая внедряване на приложение за база данни. Бележки (Коментар) са предоставени в края на всеки раздел, за да обяснят някои специфични характеристики на стъпките, които се извършват.

Съдържание

И. Бизнес сценарий
II. ER модел, използващ UML нотация
III. Превръщане в релационен модел
IV. Нормализиране
V. Създаване на схема на база данни с SQL
VI. Приложение за база данни
VII. Заключения

.

И. Бизнес сценарий

Нашата компания притежава и управлява фризьорски салон и салон за нокти в центъра на Манхатън от 7 години. Използваме електронни таблици и хартиен дневник, за да следим клиенти, срещи и плащания. Бихме искали да заменим този ръчен метод за проследяване на бизнеса с база данни.

В нашия бизнес клиентите си уговарят срещи с любимия си фризьор (хора, които подстригват и оформят косата на клиентите) или друг служител и могат да се отдадат на редица Услуги като основно подстригване/оформяне на косата, боядисване на косата, акценти, къдрене, лице, маникюр, педикюр и др. Трябва да следим материалите (шампоан, цвят на косата) и времето, което ще отнеме за извършване на всяка услуга. Въпреки че всяка услуга има стандартна цена, промоции и други фактори могат да повлияят на действителната цена, предоставена на Клиента за дадена услуга.

Също така трябва да следим нашите служители, включително техния домашен адрес, информация за контакт и ставка на заплащане. Трябва да следим информацията за контакт на всеки клиент, както и техния пол. За срещи трябва да знаем датата и часа на срещата и за кой клиент е срещата.

Коментар

Въз основа на горното описание изградете модел на връзката на обекта, използвайки UML нотация, която ще обхване всички нужди на бизнеса от данни.

II. ER модел, използващ UML нотация

Въз основа на горното описание, ние разработваме следния модел на взаимоотношения на обекти, използвайки UML нотация.

Коментар

Какво харесваме в този модел:

• Всички линии на връзката са в хоризонтално или вертикално положение. Не се пресичат линии.
• Имената на атрибути се изписват без интервали в имената. Не се използват съкращения.
• Всяка връзка има две много фрази, от които можем да направим изречения за връзки (вижте следващия раздел).
• Диаграмата също има „легенда“ в горния десен ъгъл, за да можем да разберем какво представлява диаграмата и кой последен е променил диаграмата.

Изречения за връзка

Единклиент може да бъде извършване на един или повече срещи

Една Среща трябва да е резервация за един и само един Клиент

ЕдинСалонСервис може да бъде услуга, предоставена като една или повече ServiceRendered

Една предоставена услуга трябва да е изобразяване на един и само един SalonService

ЕдинСлужител може да бъде изобразяване една или повече ServiceRendered

Една предоставена услуга трябва да е изобразено от един и само единСлужител
 

Една Среща може да бъде резервация за предоставяне на една или повече ServiceRendered

Една предоставена услуга трябва да е конкретна услуга, предоставена по време на една и само една Среща

Коментар

Изреченията за връзка трябва да имат смисъл. В този пример глаголните фрази са подчертани. Имената на обектите са с удебелен шрифт. Минималната мощност (може да бъде за 0 и трябва да бъде за 1) са изписани в курсив. Максималната кардиналност се записва като „едно или повече“ за * и „един и само един“ за 1.

След като ER моделът е финализиран, преминаваме към следващата стъпка – да преобразуваме концептуалния модел на ER в логически релационен модел.

III. Преобразуване в релационен модел

Следващата стъпка е да преобразувате диаграмата на връзката на обекта в релационен модел. По време на тази стъпка идентификаторите в обектите стават ключове в отношенията. Връзките „едно към много“ водят до копиране на външен ключ от страната „Едно“ към „много“ на връзката.

Клиент ( ИД на клиента (ключ), Име, Фамилия, Телефонен номер, Улица, Град, Щат, Пощенски код )

СалонСервиз ( ServiceID (ключ), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Служител ( EmployeeID (ключ), име, фамилия, улица, град, щат, пощенски код, ставка на заплащане )

Среща ( AppointmentID (ключ), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Предадена услуга ( AppointmentID (fk)(key), LineItemNumber(key), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Това е „първоначалният набор от отношения.“

Коментар

• Забележете, че ServiceRendered Обектът от модела на ER е зависим от ID, което означава, че се нуждае от атрибут в допълнение към LineItemNumber, за да образува съставен ключ.
• Ключовете се показват с обозначението (ключ), а външните ключове – с обозначението (fk).

Следващата стъпка е да се нормализира първоначалният набор от отношения.

IV. Нормализиране

Следващата стъпка е нормализиране на отношенията.

Стъпките, които трябва да следвате за всяка връзка, са:

1. Напишете връзката, включително всички имена на атрибути. Посочете ключовете и външните ключове.
2. Предоставете примерни данни за връзката.
3. Посочете Ключа за релацията и запишете всички Функционални зависимости .
4. Прегледайте дефинициите на всяка нормална форма, започвайки с 1NF и стигайки до BCNF (или 3NF в зависимост от изискванията на вашия проект).
5. Ако една връзка отговаря на определението за нормална форма, преминете към следващата по-висока нормална форма.
6. Ако релация не отговаря на дефиницията за нормална форма (напр. съдържа зависимост от частичен ключ или съдържа преходна зависимост), разделете релацията на две нови релации.
   Започнете процеса на нормализиране от самото начало с всяка от тези две нови отношения.

Връзка с клиенти

Клиент (Идентификатор на клиента (ключ) , Име, Фамилия, CustPhone, улица, град, щат, пощенски код, пол)

Примерни данни

Ключ:CustomerID

FD1:CustomerID -> име, фамилия, телефонен номер, улица, град, щат, пощенски код, пол

FD2:Пощенски код -> Град, щат

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Съществува преходна зависимост:CustomerID -> ZipCode и ZipCode -> City, State

Решение:Разделете връзката с клиента на две нови връзки, наречени CustomerData и ZipCodes:

CustomerData (CustomerID (ключ), Firstname, LastName, CustPhone, Street, ZipCode (fk), Gender )

Ключ:CustomerID

FD1:CustomerID -> име, фамилия, телефонен номер, улица, пощенски код (fk), пол

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Пощенски кодове (ZipCode (ключ), град, щат)

Ключ:ZipCode

FD1:Пощенски код -> Град, щат

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Връзка SalonService

SalonService ( ServiceID (ключ), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials)

Примерни данни:

Ключ:ServiceID

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

1NF:ServiceMaterials може да се третира като атрибут с много стойности. В този случай SalonService не е в 1NF.

Решение:Разделете ServiceMaterials в отделна връзка.

За този пример обаче ще запазим ServiceMaterials като атрибут на релацията SalonService.

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Връзка със служителите

Служител( EmployeeID (ключ), име, фамилия, улица, град, щат, пощенски код, ставка на заплащане )

Ключ:EmployeeID

FD1:EmployeeID -> Име, фамилия, улица, град, щат, пощенски код, ставка на заплащане

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Съществува преходна зависимост:EmployeeID -> ZipCode и ZipCode -> City, State

Решение:Разделете връзката с клиента на две нови отношения, наречени EmployeeData и ZipCodes:

EmployeeData(EmployeeID (ключ), Име, Фамилия, Улица, Пощенски код (fk), PayRate )

Ключ:EmployeeID

FD1:EmployeeID -> Име, фамилия, улица, пощенски код (fk), PayRate

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Забележка:Вече имаме връзка пощенски кодове от момента, когато връзката с клиента е била разделена. Така че ние използваме повторно тази връзка ZipCodes. Няма нужда да създавате втора връзка ZipCodes.

Връзка за среща

Среща (AppointmentID (ключ), AppointmentDate, AppotinmentTime, CustomerID (fk))

Примерни данни:

Ключ:AppointmentID

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

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Връзка, предоставена на услуга

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

Примерни данни:

Ключ:AppointmentID, LineItemNumber

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

1NF:Отговаря на определението за релация

2NF:Няма частични ключови зависимости

3NF:Няма преходни зависимости

BCNF:Всички детерминанти са кандидат ключове

Окончателен набор от отношения

Клиент ( ИД на клиента (ключ) , Име, Фамилия, Телефонен номер, Улица, Пощенски код (fk), Пол )

Пощенски кодове ( Пощенски код (ключ), град, щат.

СалонСервиз ( ServiceID (ключ), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Служител ( EmployeeID (ключ), Име, Фамилия, Улица, Пощенски код (fk), PayRate )

Среща ( AppointmentID (ключ), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Предадена услуга ( AppointmentID (fk)(key), LineItemNumber(key), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Коментар

• Обърнете внимание, че е необходима само една връзка ZipCodes. Споделя се както с клиентите, така и със служителите.
• Както беше отбелязано по-рано, атрибутът ServiceMaterials не е нормализиран в този пример. Може би това може да бъде направено в бъдещо назначение или подобрение на модела.

Сега, когато отношенията са нормализирани, схемата може да бъде създадена в система за управление на база данни, използвайки език за структурирани заявки (SQL).

V. Създаване на схема на база данни със структуриран език за заявки

Създайте таблица в базата данни за всяка от релациите в крайния набор от релации.

Следният SQL код създава шестте таблици и добавя ограничението PRIMARY KEY към всяка от тях:

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 35), Фамилия VARCHAR(35), Телефонен номер VARCHAR(15), Улица VARCHAR(35), Пощенски код VARCHAR(12), Пол VARCHAR(2), ОГРАНИЧЕНИЕ pk_customer ПРАВИЛЕН КЛЮЧ (CustomerID))СЪЗДАВАНЕ НА ТАБЛИЦА Среща(VARCHAR10) NOT NULL, AppointmentDateTime DATE, CustomerID VARCHAR(10) NOT NULL, CONSTRAINT pk_appointment PRIMARY KEY (AppointmentID))СЪЗДАВАТЕ ТАБЛИЦА SalonService( ServiceID VARCHAR(10) NOT NULL, ServiceName VARCHARration(35. ), ОГРАНИЧЕНИЕ pk_salonservice PRIMARY KEY (ServiceID))CREATE TABLE Employee ( EmployeeID VARCHAR(10) NOT N ULL, Име VARCHAR(35), Фамилия VARCHAR(25), Улица VARCHAR(45), Пощенски код VARCHAR(12), Номер на заплащане, ОГРАНИЧЕНИЕ pk_employee ПЪРВИЧЕН КЛЮЧ (ИД на служител)) СЪЗДАВАНЕ НА ТАБЛИЦА Предоставена услуга ( AppointmentID(AppointmentID10m VARCHAR)UNLLnem VARCHAR INTEGER NOT NULL, ServiceID VARCHAR(10) NOT NULL, ServiceExtendedPrice NUMBER, EmployeeID VARCHAR(10) NOT NULL, CONSTRAINT pk_ServiceRendered ПЪРВИЧЕН КЛЮЧ (AppointmentID, LineItemNumber))

Добавяне на външни ключове

Следните SQL кодове добавят ограничения за ВЪНШЕН КЛЮЧ за свързване на таблиците заедно:

 Променлива таблица Клиент Добавяне на ограничение FK_CUSTOMER_ZIPCODES Външен ключ (Zipcode) Референции Zipcodes (ZipCode) ALTER TABLE Служител Добавяне на ограничение FK_EMPLOYEE_ZIPCODES Външен ключ (ZipCode) Препратки Zipcodes (Zipcode) Променлива таблица Назначаване Добавяне )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) 
 

 Коментар към SQL:
 
 
Повечето СУБД ще съхраняват ДАТАТА и ЧАСА в една и съща колона. Така AppointmentDate и AppointmentTime бяха комбинирани в една колона в базата данни с име AppointmentDateTime
 
Ключовете и чуждите ключове трябва да имат едно и също име и тип данни. Например, Key CustomerID е VARCHAR(10) в таблицата Customer и също VARCHAR(10) в таблицата Appointment.
 
На ограниченията се дават смислени имена, като pk_customer за първичен ключ и fk_customer_zipcodes за външен ключ.
 
Колони като телефонен номер и пощенски код трябва да използват тип данни VARCHAR. Ако се използва тип данни NUMBER или INTEGER, тогава водещите нули ще липсват.
 
 
 

 След създаване на таблиците и добавяне на ограничения на външния ключ, схемата на базата данни вече изглежда по следния начин:
 
 

 
 
 
Изглед на връзката
 

 Използвайки изгледа за връзки под Инструменти за база данни, можем да видим връзките (външни ключове) между таблиците:
 

 
 

 
 
 
Добавяне на данни към таблиците с помощта на SQL INSERT оператори
 
ВМЕСЕТЕ В СТОЙНОСТИТЕ на пощенски кодове ('07026', 'Garfield', 'NJ');ВМЕСЕТЕ В СТОЙНОСТИТЕ на пощенски кодове ('07621', 'Bergenfield', 'NJ');ВМЕСЕТЕ В СТОЙНОСТИТЕ на пощенски кодове ('07010', 'Cli Park', 'NJ');ВМЕСЕТЕ В СТОЙНОСТИТЕ на пощенски кодове ('07631', 'Englewood', 'NJ');ВЪВЕТЕ В СТОЙНОСТИТЕ на пощенски кодове ('07665', 'Teaneck', 'NJ');ВМЕСЕТЕ В СТОЙНОСТИТЕ на клиента (' C101“, „Elia“, „Fawcett“, „201-222-2222“, „8989 Smith Rd“, „07026“, „F“); , '201-222-3333', '65 Hope Rd', '07026', 'M');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА ('C103', 'Frederic', 'Fawcett', '201-222-2222', ' 8989 Smith Rd', '07026', 'M'); ВЪВЕДЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА ('C104', 'Goldie', 'Montand', '201-222-4321', '5235 Ironwood Ln', '07026',' F');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F'); ВЪВЕДЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА ('C107', 'Faye', 'Glenn' , '201-333-4242', '1 522 Main St', '07010', 'F'); ВЪВЕДЕТЕ В СТОЙНОСТИТЕ НА КЛИЕНТА ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', ' F');ВМЕСЕТЕ В СТОЙНОСТИТЕ SalonService ('SV101', 'Мъжка прическа', 20, 22, 'Няма');ВМЕСЕТЕ В СТОЙНОСТИТЕ SalonService ('SV102', 'Женско подстригване', 30, 32 , 'Няма');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА SalonService ('SV103', 'Детско подстригване', 20, 15, 'Няма');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА SalonService ('SV104', 'Женски цвят за коса', 60, 76 , 'Цвят, реагент, ръкавици, четка за реагент, фолио');ВЪВЕТЕ ВЪВ СТОЙНОСТИТЕ НА SalonService ('SV105', 'Женска прическа', 45, 56, 'Шампоан, балсам');ВМЕСЕТЕ В СТОЙНОСТИТЕ НА SalonService (' SV106“, „Мъжка прическа“, 45, 46, „Шампоан, балсам“); ВЪВЕДЕТЕ В ЦЕННОСТИТЕ на служителите („E300“, „Joy“, „Aveda“, „46 Easton Ave.“, „07026“) , 18); ВЪВЕДЕТЕ В ЦЕННОСТИТЕ на служителите („E400“, „Джералдо“, „Джералдо“, „Фортис“ 12 бул. ап. 2A', '07026', 22);ВМЕСЕТЕ В СТОЙНОСТИТЕ на служителите ('E500', 'Koy', 'Petruzzio', '70 Wilard St. ', '07026', 20);ВМЕСЕТЕ В СТОЙНОСТИТЕ на служителите ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18); ВЪВЕДЕТЕ В ЦЕННОСТИТЕ на служителите ('E700', 'Pat', 'Reese', '2 Lincoln Place', '07010', 23);ВМЕСЕТЕ В СТОЙНОСТИТЕ на служителите ('E800', 'Winter', 'Tanner', '215 Elm Ave', '07665', 23);ВЪВЕТЕ В СТОЙНОСТИТЕ НА СЛУЖИТЕЛИТЕ ('A400', '10/22/2017 11:00):00 AM', 'C101');ВМЕСЕТЕ В СТОЙНОСТИТЕ на срещата ('A401', '11/06/2017 12:45:00 PM', 'C102');ВМЕСЕТЕ В СТОЙНОСТИТЕ на срещата ('A402', '12/07 /2017 14:00:00 PM', 'C106');ВМЕСЕТЕ В СТОЙНОСТИТЕ на срещата ('A403', '12/18/2017 15:30:00 PM', 'C106');ВМЕСЕТЕ В СТОЙНОСТИТЕ на срещата ('A404 ', '12/21/2017 11:30:00 AM', 'C108');ВМЕСЕТЕ В СТОЙНОСТИТЕ за среща ('A405', '12/31/2017 10:00:00 AM', 'C107'); INTO VALUES ('A406', '01/11/2018 15:15:00 PM', 'C103'); INSERT INTO VALUES ('A407', '01/12/2018 02:30:00 PM', 'C104');ВМЕСЕТЕ В СТОЙНОСТИТЕ за среща ('A408', '0 22.01.2018 г. 16:00:00 ч.“, „C105“);ВМЪКВАНЕ ВЪВ СЛЕДНИ СТОЙНОСТИ („A400“, 1, „SV104“, 75, „E400“); , 'SV102', 25, 'E400');ВМЪКВАНЕ ВЪВ СЛЕДНИ СТОИНИ ('A401', 1, 'SV101', 22, 'E500');ВМЪКВАНЕ ВЪВ СЛЕДНИ СТОЙНОСТИ ('A402', 1, 'SV754', СТОЙНОСТИ , 'E600');INSERT INTO ServiceRendered STOS ('A402', 2, 'SV102', 30, 'E800');INSERT INTO ServiceRendered STOS ('A403', 1, 'SV105', 50, 'E300'); INSERT INTO ServiceRendered STOS ('A404', 1, 'SV105', 55, 'E300');INSERT INTO ServiceRendered STOS ('A405', 1, 'SV102', 30, 'E700');INSERT INTO ServiceRendered STOS ('A405', 1, 'SV102', 30, 'E700'); A405', 2, 'SV104', 70, 'E700'); ВЪВЕДЕТЕ ВЪВ услуги, предоставени СТОЙНОСТИ ('A405', 3, 'SV105', 50, 'E700');
 
Коментар на образци от данни
 
 
Добавяме достатъчно данни, за да можем да тестваме връзките между таблиците и да дадем на разработчиците на приложения нещо, с което да работят.
 
Внимавайте в реда, в който се добавят данните. Например, първо трябва да се вмъкнат всички пощенски кодове, преди да могат да се вмъкнат клиент или служител (които и двамата използват пощенски код като външен ключ).
 
Когато добавяте VARCHAR данни с вградени кавички, използвайте две кавички заедно. напр. „Женска прическа“
 
В този момент схемата на базата данни е готова, за да могат разработчиците на приложения да се заемат с проектирането на формуляри, отчети и заявки.
 
 

 Сега, след като схемата на базата данни е създадена и е попълнена с някои примерни данни, приложението за база данни може да бъде разработено.
 

 
 
VI. Приложение за база данни
 

 Приложението за база данни се състои от набор от формуляри, отчети и заявки, които са свързани заедно във формуляр за навигация.
 

 Формулярът за навигация е първият формуляр, който се появява при отваряне на базата данни.
 
 
Формуляр за навигация
 

 
 

 Различни формуляри и отчети за въвеждане на данни могат да се покажат, като щракнете върху селекцията от лявата страна.
 
 
Формуляр за въвеждане на данни за клиента
 

 
 

 Формулярът за въвеждане на данни за клиенти се използва за търсене на съществуващи клиенти и за въвеждане на информация за нови клиенти. Полетата за град и щат се попълват автоматично чрез избиране на пощенски код от Combo Box. Формулярът има няколко персонализирани VBA кода за преобразуване на собствените и фамилните имена в правилен регистър и за генериране на нов, уникален идентификационен номер на клиента, когато се появи празно поле CustomerID след създаване на нов запис.
 
 

 
 
 
Формуляр за въвеждане на данни за Salon Services
 

 
 

 Формулярът за въвеждане на данни за Salon Service се използва за запитване, актуализиране и добавяне на нови услуги в салона.
 
 
Формуляр за въвеждане на данни за среща
 

 
 

 Формулярът за въвеждане на данни за срещи се използва за създаване на нова среща за клиент. Както при формуляра за клиент, нов идентификатор на среща може да бъде създаден, като щракнете върху празно поле за идентификатор на среща, след като бъде създаден нов запис. Клиентът може да бъде избран от комбинираното поле на ИД на клиента, както е показано по-долу:
 

 
 

 Ако това е нов клиент, който прави среща, потребителят може да щракне върху бутона Нов клиент, за да изведе формуляра за въвеждане на данни за клиента. След като информацията за новия клиент бъде запазена, потребителят може да се върне към формуляра за въвеждане на данни за среща и да си уговори среща.
 
 
Формуляр за среща и услуги
 

 
 

 Целта на този формуляр е да въведе различни услуги, свързани със среща. Този формуляр може да се използва и за генериране на сметка за клиента. Услугата и Служителят могат да бъдат избрани от съответните им комбинирани полета, както е показано по-долу:
 

 
 

 
Общ отчет за срещите на клиенти
 

 
 

 Този отчет предоставя обобщение на броя на срещите и общата сума, изразходвана от всеки клиент.
 
 

 Въз основа на заявка:
 
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.CuopointID. AppointmentIDGROUP BY Customer.CustomerID, First Name, LastNameORDER BY LastName, First Name;
 
 

 И заявете Total_Spent_Each_Appointment
 
ИЗБЕРЕТЕ Appointment.AppointmentID, SUM(ServiceExtendedPrice) КАТО TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;
> 
 
Отчет за услуги и отстъпки
 

 
 

 Този отчет показва всяка от услугите с обща стойност на редовната цена на услугата, разширената цена и индикация за размера на отстъпката, приложена към услугите, предоставени в миналото.
 
 

 Въз основа на заявка:
 
ИЗБЕРЕТЕ SalonService.ServiceID, ServiceName, SUM(ServicePrice) КАТО TotalServicePrice, SUM(ServiceExtendedPrice) КАТО TotalExtPrice, FORMAT(1.0 - (SUM(ServiceExtendedPrice) / SUM(ServicePrice)), "0,00% отстъпка на услугата, "0.00% отстъпка на услугата,") SalonService.ServiceID =ServiceRendered.ServiceIDGROUP BY SalonService.ServiceID, ServiceNameORDER BY SalonService.ServiceID, ServiceName;
 
 
Отчет за адресите на клиенти
 

 
 

 Този отчет показва пълните имена и адреси на всеки клиент.
 

 
 
VII. Заключения
 

 Разработването на приложение за база данни следва жизнения цикъл на разработка на системата, който започва с концептуално моделиране и преминава през структуриран набор от стъпки, които включват логическо моделиране, нормализиране, физическа реализация и разработка на приложения. Примерът с проекта за фризьорски салон илюстрира всяка една от тези основни стъпки. Някои подробности обаче не са напълно документирани. Например, може да се наложи известна допълнителна работа, за да се нормализира отношението на услугите на салона за отчитане на различни материали, използвани за всяка услуга. Могат да бъдат добавени и допълнителни подробности за внедряването на приложението, като други VBA кодове и по-подробни описания на използването на всеки формуляр и отчет.