Projekt bazy danych salonu fryzjerskiego

Zaktualizowano:22 stycznia 2018 r. przez Richarda Holowczaka

Poniższe materiały dokumentują projektowanie i tworzenie aplikacji bazodanowej do obsługi małego salonu fryzjerskiego. Projekt rozpoczyna się od opisu biznesu i przechodzi przez modelowanie koncepcyjne (E-R), modelowanie logiczne (relacyjne), modelowanie fizyczne i finalnie wdrożenie aplikacji bazodanowej. Uwagi (komentarz) znajdują się na końcu każdej sekcji, aby wyjaśnić niektóre specyficzne cechy wykonywanych kroków.

Spis treści

I. Scenariusz biznesowy
II. Model ER przy użyciu notacji UML
III. Konwersja do modelu relacyjnego
IV. Normalizacja
V. Tworzenie schematu bazy danych za pomocą SQL
VI. Aplikacja bazy danych
VII. Wnioski

.

I. Scenariusz biznesowy

Nasza firma jest właścicielem i operatorem salonu fryzjerskiego i paznokci na Manhattanie od 7 lat. Korzystaliśmy z arkuszy kalkulacyjnych i papierowego dziennika, aby śledzić klientów, spotkania i płatności. Chcielibyśmy zastąpić tę ręczną metodę śledzenia firmy bazą danych.

W naszej działalności Klienci umawiają się na wizytę ze swoim ulubionym fryzjerem (osobami, które strzygą i stylizują włosy klientów) lub innym pracownikiem i mogą skorzystać z szeregu Usług, takich jak podstawowe strzyżenie/stylizacja włosów, koloryzacja, pasemka, trwała ondulacja, pielęgnacja twarzy, manicure, pedicure itp. Musimy na bieżąco śledzić materiały (szampon, kolor włosów) oraz czas potrzebny na wykonanie każdej usługi. Chociaż każda usługa ma standardową cenę, promocje i inne czynniki mogą wpływać na rzeczywistą cenę rozszerzoną na Klienta za daną usługę.

Musimy również śledzić naszych Pracowników, w tym ich adres domowy, dane kontaktowe i stawkę wynagrodzenia. Musimy śledzić dane kontaktowe każdego Klienta, a także jego płeć. W przypadku spotkań musimy znać datę i godzinę spotkania oraz klienta, dla którego spotkanie jest przeznaczone.

Komentarz

W oparciu o powyższy opis, skonstruuj model relacji między jednostkami przy użyciu notacji UML, który uchwyci wszystkie potrzeby biznesowe dotyczące danych.

II. Model ER przy użyciu notacji UML

Na podstawie powyższego opisu opracowujemy następujący model relacji encji przy użyciu notacji UML.

Komentarz

Co nam się podoba w tym modelu:

• Wszystkie linie relacji przebiegają w pozycji poziomej lub pionowej. Żadne linie nie są skrzyżowane.
• Nazwy atrybutów są pisane bez spacji w nazwach. Żadne skróty nie są używane.
• Każdy związek ma dwie frazy, z których możemy utworzyć zdania dotyczące związku (patrz następna sekcja).
• Diagram ma również „legendę” w prawym górnym rogu, dzięki czemu możemy powiedzieć, co przedstawia diagram i kto ostatnio go zmodyfikował.

Zdania dotyczące relacji

Jeden Klient może być umawianie co najmniej jednego spotkania

Jedno spotkanie musi być rezerwacja dla jednego i tylko jednego Klienta

Jedna Usługa salonu może być usługa świadczona jako jeden lub więcej ServiceRendered

Jedna Usługa świadczona musi być renderowanie jednej i tylko jednej SalonService

Jeden pracownik może być renderowanie jeden lub więcej Usługi świadczone

Jedna Usługa świadczona musi być renderowane przez jednego i tylko jednego pracownika
 

Jedno spotkanie może być rezerwacja zapewniająca co najmniej jedną usługę ServiceRendered

Jedna Usługa świadczona musi być konkretna usługa świadczona podczas jednego i tylko jednego Spotkania

Komentarz

Zdania dotyczące relacji powinny mieć sens. W tym przykładzie frazy czasownikowe są podkreślone. Nazwy podmiotów są pogrubione. Minimalna kardynalność (może być dla 0 i musi być dla 1) są pisane kursywą. Maksymalna kardynalność jest zapisana jako „jeden lub więcej” dla * i „jeden i tylko jeden” dla 1.

Po sfinalizowaniu modelu ER przechodzimy do następnego kroku – przekształcenia koncepcyjnego modelu ER w logiczny model relacyjny.

III. Konwersja do modelu relacyjnego

Następnym krokiem jest przekonwertowanie diagramu relacji encji na model relacyjny. Na tym etapie Identyfikatory w encjach stają się kluczami w relacjach. Relacje jeden-do-wielu powodują skopiowanie klucza obcego z jednej strony na wiele relacji.

Klient ( ID klienta (klucz), imię, nazwisko, numer telefonu, ulica, miasto, województwo, kod pocztowy )

Usługi salonu ( ServiceID (klucz), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Pracownik (Identyfikator pracownika (klucz), imię, nazwisko, ulica, miasto, województwo, kod pocztowy, stawka wynagrodzenia )

Spotkanie ( AppointmentID (klucz), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Usługa świadczona ( AppointmentID (fk) (klucz), LineItemNumber (klucz), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

To jest „początkowy zestaw relacji”.

Komentarz

• Zauważ, że Usługa świadczona jednostka z modelu ER jest zależna od ID, co oznacza, że ​​potrzebuje atrybutu oprócz LineItemNumber, aby utworzyć klucz złożony.
• Klucze są wyświetlane z oznaczeniem (klucz), a klucze obce z oznaczeniem (fk).

Następnym krokiem jest normalizacja początkowego zestawu relacji.

IV. Normalizacja

Następnym krokiem jest normalizacja relacji.

Kroki, które należy wykonać dla każdej relacji, to:

1. Napisz relację zawierającą wszystkie nazwy atrybutów. Wskaż klucze i klucze obce.
2. Podaj przykładowe dane dla relacji.
3. Podaj Klucz dla relacji i zapisz wszystkie zależności funkcjonalne .
4. Przejrzyj definicje każdej normalnej formy, zaczynając od 1NF i przechodząc do BCNF (lub 3NF w zależności od wymagań projektu).
5. Jeśli relacja spełnia definicję formy normalnej, przejdź do następnej wyższej formy normalnej.
6. Jeśli relacja nie spełnia definicji formy normalnej (np. zawiera zależność z kluczem częściowym lub zawiera zależność przechodnią), wówczas podziel relację na dwie nowe relacje.
   Rozpocznij proces normalizacji od początku z każdą z tych dwóch nowych relacji.

Relacja z klientem

Klient ( ID klienta (klucz) , Imię, Nazwisko, Telefon klienta, Ulica, Miasto, Stan, Kod pocztowy, Płeć )

Przykładowe dane

Klucz:ID klienta

FD1:ID klienta -> imię, nazwisko, numer telefonu, ulica, miasto, województwo, kod pocztowy, płeć

FD2:Kod pocztowy -> Miasto, województwo

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:istnieje zależność przechodnia:ID klienta -> Kod pocztowy i Kod pocztowy -> Miasto, stan

Rozwiązanie:Podziel relację z klientem na dwie nowe relacje o nazwach CustomerData i ZipCodes:

CustomerData (CustomerID (klucz), FirstName, LastName, CustPhone, Street, ZipCode (fk), Płeć)

Klucz:ID klienta

FD1:ID klienta -> imię, nazwisko, numer telefonu, ulica, kod pocztowy (fk), płeć

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przejściowych

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Kody pocztowe (Kod pocztowy (klucz), Miasto, Stan)

Klucz:kod pocztowy

FD1:Kod pocztowy -> Miasto, województwo

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przejściowych

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Relacja z usługą salonu

SalonService ( ServiceID (klucz), ServiceName, Service Duration, ServicePrice, ServiceMaterials )

Przykładowe dane:

Klucz:ServiceID

FD1:ServiceID -> ServiceName, Service Duration, ServicePrice, ServiceMaterials

1NF:ServiceMaterials mogą być traktowane jako atrybut wielowartościowy. W takim przypadku SalonService nie jest w 1NF.

Rozwiązanie:Podziel ServiceMaterials na osobną relację.

Jednak w tym przykładzie zachowamy ServiceMaterials jako atrybut relacji SalonService.

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przejściowych

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Relacje z pracownikami

Pracownik(Identyfikator pracownika (klucz), Imię, Nazwisko, Ulica, Miasto, Stan, Kod pocztowy, Stawka wynagrodzenia )

Klucz:Identyfikator pracownika

FD1:EmployeeID -> Imię, Nazwisko, Ulica, Miasto, Województwo, Kod pocztowy, Stawka płacy

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:istnieje zależność przechodnia:IDPracownika -> Kod pocztowy i Kod pocztowy -> Miasto, stan

Rozwiązanie:Podziel relację z klientem na dwie nowe relacje o nazwach EmployeeData i ZipCodes:

DanePracownika(Identyfikator Pracownika (klucz), Imię, Nazwisko, Ulica, Kod Pocztowy (fk), Stawka Płac )

Klucz:Identyfikator pracownika

FD1:EmployeeID -> FirstName, LastName, Street, ZipCode (fk), PayRate

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przechodnich

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Uwaga:Mamy już relację z kodami pocztowymi od momentu podziału relacji Klient. Więc ponownie używamy tej relacji z kodami pocztowymi. Nie ma potrzeby tworzenia drugiej relacji z kodami pocztowymi.

Stosunek do spotkania

Spotkanie ( AppointmentID (klucz), AppointmentDate, ApotinmentTime, CustomerID (fk) )

Przykładowe dane:

Klucz:Identyfikator spotkania

FD1:AppointmentID -> Appointment Date, AppotinmentTime, CustomerID (fk)

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przejściowych

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Relacja świadczona przez usługę

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

Przykładowe dane:

Klucz:identyfikator spotkania, numer pozycji

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

1NF:Spełnia definicję relacji

2NF:Brak częściowych zależności kluczy

3NF:Brak zależności przejściowych

BCNF:Wszystkie wyznaczniki są kluczami kandydackimi

Ostateczny zestaw relacji

Klient ( ID klienta (klucz) , imię, nazwisko, numer telefonu, ulica, kod pocztowy (fk), płeć )

Kody pocztowe ( Kod pocztowy (klucz), miasto, województwo)

Usługi salonu ( ServiceID (klucz), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Pracownik (Identyfikator pracownika (klucz), imię, nazwisko, ulica, kod pocztowy (fk), stawka wynagrodzenia )

Spotkanie ( AppointmentID (klucz), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Usługa świadczona ( AppointmentID (fk) (klucz), LineItemNumber (klucz), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Komentarz

• Pamiętaj, że wymagana jest tylko jedna relacja z kodami pocztowymi. Jest udostępniany zarówno relacjom z klientami, jak i pracownikami.
• Jak wspomniano wcześniej, atrybut ServiceMaterials nie został znormalizowany w tym przykładzie. Być może można to zrobić w przyszłym przypisaniu lub ulepszeniu modelu.

Teraz, gdy relacje są znormalizowane, schemat można utworzyć w systemie zarządzania bazą danych przy użyciu strukturalnego języka zapytań (SQL).

V. Tworzenie schematu bazy danych za pomocą strukturalnego języka zapytań

Utwórz tabelę w bazie danych dla każdej relacji w końcowym zestawie relacji.

Poniższy kod SQL tworzy sześć tabel i dodaje do każdej z nich ograniczenie PRIMARY KEY:

CREATE TABLE Kody pocztowe( kod pocztowy VARCHAR(12) NOT NULL, miasto VARCHAR(36), stan VARCHAR(4), OGRANICZENIE pk_zipcodes PRIMARY KEY (kod pocztowy))CREATE TABLE Klient( CustomerID VARCHAR(10) NOT NULL, FirstName VARCHAR( 35), Nazwisko VARCHAR(35), Numer telefonu VARCHAR(15), Ulica VARCHAR(35), Kod pocztowy VARCHAR(12), Płeć VARCHAR(2), OGRANICZENIE pk_customer PRIMARY KEY (IDKlienta))CREATE TABLE Spotkanie(Identyfikator spotkania 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) ), OGRANICZENIE pk_salonservice KLUCZ PODSTAWOWY (ServiceID)) UTWÓRZ TABELĘ Pracownik ( EmployeeID VARCHAR(10) NOT N ULL, 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))

Dodawanie kluczy obcych

Poniższe kody SQL dodają ograniczenia FOREIGN KEY, aby połączyć ze sobą tabele:

 ALTER TABELA Klient DODAJ OGRANICZENIE fk_customer_zipcodes KLUCZ OBCY (Kod pocztowy) REFERENCJE Kody pocztowe (Kod pocztowy) TABELA ALTER Pracownik DODAJ OGRANICZENIE fk_employee_zipcodes KLUCZ OBCY (Kod pocztowy) REFERENCJE Kody pocztowe (Identyfikator pocztowy) REFERENCJA KLIENTA_KLIENTA_DODATKOWE OGRANICZENIE CONSTRATOM ) Alter Table ServiceRended Dodaj ograniczenie FK_SERVICERENDED_SERVICE KLUCZ ZAGRANICZNY (SERVICE) Referencje Salonservice (ServiceId) Tabela ServiceRendered Dodaj ograniczenie FK_SERVICEREDED_EMPLEYE COUNTHOPOREE KLUCZ (Społeczeństwo) Klucz zagraniczny (Spotkanie) /pre> 
 

 Komentarz do SQL:
 
 
Większość DBMS przechowuje DATE i TIME w tej samej kolumnie. Tak więc AppointmentDate i AppointmentTime zostały połączone w jedną kolumnę w bazie danych o nazwie AppointmentDateTime
 
Klucze i klucze obce powinny mieć taką samą dokładną nazwę i typ danych. Na przykład klucz CustomerID to VARCHAR(10) w tabeli Customer, a także VARCHAR(10) w tabeli Spotkanie.
 
Ograniczeniom nadawane są znaczące nazwy, takie jak pk_customer dla klucza podstawowego i fk_customer_zipcodes dla klucza obcego.
 
Kolumny, takie jak Numer telefonu i Kod pocztowy, powinny używać danych typu VARCHAR. Jeśli używany jest typ danych NUMBER lub INTEGER, nie będzie zer wiodących.
 
 
 

 Po utworzeniu tabel i dodaniu ograniczeń kluczy obcych schemat bazy danych wygląda teraz następująco:
 
 

 
 
 
Widok relacji
 

 Korzystając z widoku relacji w obszarze Narzędzia bazy danych, możemy zobaczyć relacje (klucze obce) między tabelami:
 

 
 

 
 
 
Dodawanie danych do tabel za pomocą instrukcji SQL INSERT
 
WSTAW WARTOŚCI kodów pocztowych ('07026', 'Garfield', 'NJ');WSTAW WARTOŚCI kodów pocztowych ('07621', 'Bergenfield', 'NJ');WSTAW WARTOŚCI kodów pocztowych ('07010', 'Cliffside Park', 'NJ');WSTAW WARTOŚCI kodów pocztowych ('07631', 'Englewood', 'NJ');WSTAW WARTOŚCI kodów pocztowych ('07665', 'Teaneck', 'NJ');WSTAW WARTOŚCI KLIENTÓW (' C101', 'Elia', 'Fawcett', '201-222-2222', '8989 Smith Rd', '07026', 'F');WSTAW W WARTOŚCI KLIENTA ('C102', 'Ishwarya', 'Roberts' , '201-222-3333', '65 Hope Rd', '07026', 'M');WSTAW W WARTOŚCI KLIENTA ('C103', 'Frederic', 'Fawcett', '201-222-2222', ' 8989 Smith Rd', '07026', 'M');WSTAW W WARTOŚCI KLIENTA ('C104', 'Goldie', 'Montand', '201-222-4321', '5235 Ironwood Ln', '07026', ' F');WSTAW W WARTOŚCI KLIENTA ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M');WSTAW W WARTOŚCI KLIENTA (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F');WSTAW W WARTOŚCI KLIENTA ('C107', 'Faye', 'Glenn' , '201-333-4242', '1 522 Main St ', '07010', 'F');WSTAW W WARTOŚCI KLIENTA ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', ' F');WSTAW WARTOŚCI SalonService ('SV101', 'Fryzura męska', 20, 22, 'Brak');WSTAW WARTOŚCI SalonService ('SV102', 'Strzyżenie damskie', 30, 32 , 'Brak');WSTAW WARTOŚCI SalonService ('SV103', 'Strzyżenie dziecięce', 20, 15, 'Brak');WSTAW WARTOŚCI SalonService ('SV104', 'Kolor włosów dla kobiet', 60, 76 , „Kolor, odczynnik, rękawiczki, pędzel do odczynników, folia”); WSTAW DO WARTOŚCI SalonService („SV105”, „Fryzura damska”, 45, 56, „Szampon, odżywka”); WSTAW DO WARTOŚCI SalonService (” SV106”, „Fryzura męska”, 45, 46, „Szampon, odżywka”); WSTAWIĆ WARTOŚCI PRACOWNIKA („E300”, „Radość”, „Aveda”, „46 Easton Ave.”, „07026” , 18);WSTAWIĆ WARTOŚCI PRACOWNIKA („E400”, „Geraldo”, „Geraldo”, „12 Fortis Blvd. Trafny. 2A', '07026', 22);WSTAW W WARTOŚCI PRACOWNIKA ('E500', 'Koy', 'Petruzzio', '70 Wilard St.', '07026', 20);WSTAW W WARTOŚCI PRACOWNIKA ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18);WSTAW W WARTOŚCI PRACOWNIKA ('E700', 'Pat', 'Reese', '2 Lincoln Place', '07010', 23);WSTAW W WARTOŚCI pracownika ('E800', 'Zima', 'Opalacz', '215 Elm Ave', '07665', 23);WSTAW W WARTOŚCI Mianowania ('A400', '22.10.2017 11:00:00 AM', 'C101');WPISAĆ WARTOŚCI TERMINU ('A401', '11/06/2017 12:45:00 PM', 'C102');WPISAĆ WARTOŚCI TERMINU ('A402', '12/07') /2017 14:00:00', 'C106');WSTAWIĆ W WARTOŚCI SPOTKANIA ('A403', '18.12.2017 15:30:00', 'C106');WSTAWIĆ W WARTOŚCI SPOTKANIA ('A404 ', '21.12.2017 11:30:00', 'C108');WSTAWIĆ WARTOŚCI TERMINU ('A405', '31.12.2017 10:00:00', 'C107');WSTAWIĆ W WARTOŚCIACH Mianowania ('A406', '01/11/2018 15:15:00', 'C103');WSTAWIĆ WARTOŚCI MIANOWANIA ('A407', '01/12/2018 14:30:00', 'C104');WSTAWIĆ WARTOŚCI TERMINU ('A408', '0 1/22/2018 16:00:00', 'C105');WSTAW DO SERWISU Wyrenderowane WARTOŚCI ('A400', 1, 'SV104', 75, 'E400');WSTAW DO SERWISU Wyrenderowane WARTOŚCI ('A400', 2 , 'SV102', 25, 'E400');WSTAW DO SERWISOWE WARTOŚCI ('A401', 1, 'SV101', 22, 'E500');WSTAW DO SERWISOWE WARTOŚCI ('A402', 1, 'SV104', 75 , 'E600');WSTAW DO WARTOŚCI świadczonych przez usługę ('A402', 2, 'SV102', 30, 'E800');WSTAW DO WARTOŚCI świadczonych przez usługę ('A403', 1, 'SV105', 50, 'E300'); WSTAW DO Serwisu WARTOŚCI wyrenderowane ('A404', 1, 'SV105', 55, 'E300');WSTAW DO Serwisu wyrenderowane WARTOŚCI ('A405', 1, 'SV102', 30, 'E700'); A405', 2, 'SV104', 70, 'E700');WSTAW DO WARTOŚCI świadczonych przez usługę ('A405', 3, 'SV105', 50, 'E700');
 
Komentarz do próbek danych
 
 
Dodajemy tylko tyle danych, aby móc przetestować relacje między tabelami i dać programistom aplikacji coś do pracy.
 
Uważaj na kolejność dodawania danych. Na przykład wszystkie kody pocztowe należy wstawić najpierw, zanim będzie można wstawić klienta lub pracownika (które używają kodu pocztowego jako klucza obcego).
 
Dodając dane VARCHAR z osadzonymi cudzysłowami, użyj dwóch cudzysłowów razem. np. „Fryzura damska”
 
W tym momencie schemat bazy danych jest gotowy dla twórców aplikacji, aby mogli przystąpić do projektowania formularzy, raportów i zapytań.
 
 

 Teraz, gdy schemat bazy danych został utworzony i jest wypełniony niektórymi przykładowymi danymi, można opracować aplikację bazy danych.
 

 
 
VI. Aplikacja bazy danych
 

 Aplikacja bazy danych składa się z zestawu formularzy, raportów i zapytań, które są połączone ze sobą w formularzu nawigacji.
 

 Formularz nawigacji to pierwszy formularz, który pojawia się po otwarciu bazy danych.
 
 
Formularz nawigacji
 

 
 

 Różne formularze wprowadzania danych i raporty można wyświetlić, klikając wybór po lewej stronie.
 
 
Formularz wprowadzania danych klienta
 

 
 

 Formularz wprowadzania danych klienta służy do wyszukiwania istniejących klientów i wprowadzania nowych informacji o kliencie. Pola Miasto i Stan są automatycznie wypełniane przez wybranie kodu pocztowego z pola kombi. Formularz zawiera kilka niestandardowych kodów VBA do konwersji imienia i nazwiska na poprawną wielkość liter oraz do wygenerowania nowego, unikalnego identyfikatora klienta, gdy pojawi się puste pole Identyfikator klienta po utworzeniu nowego rekordu.
 
 

 
 
 
Formularz wprowadzania danych usług salonu
 

 
 

 Formularz wprowadzania danych usług salonu służy do sprawdzania, aktualizacji i dodawania nowych usług salonu.
 
 
Formularz wprowadzania danych spotkania
 

 
 

 Formularz Wprowadzanie danych o spotkaniach służy do tworzenia nowego spotkania dla klienta. Podobnie jak w przypadku formularza klienta, nowy identyfikator spotkania można utworzyć, klikając puste pole identyfikatora spotkania po utworzeniu nowego rekordu. Klienta można wybrać z pola kombi ID klienta, jak pokazano poniżej:
 

 
 

 Jeśli jest to nowy Klient umawiający się na wizytę, użytkownik może kliknąć przycisk Nowy Klient, aby wyświetlić formularz Wprowadzania Danych Klienta. Po zapisaniu informacji o nowym kliencie użytkownik może wrócić do formularza Wprowadzanie danych o wizycie i umówić się na wizytę.
 
 
Formularz spotkań i usług
 

 
 

 Celem tego formularza jest wprowadzenie różnych usług związanych z wizytą. Formularz ten może być również wykorzystany do wygenerowania rachunku dla klienta. Usługę i Pracownika można wybrać z odpowiednich pól kombi, jak pokazano poniżej:
 

 
 

 
Raport podsumowujący spotkania klientów
 

 
 

 Ten raport zawiera podsumowanie liczby spotkań i całkowitej kwoty wydanej przez każdego klienta.
 
 

 Na podstawie zapytania:
 
SELECT Klient.Identyfikator klienta, Imię, Nazwisko, SUM(q.Całkowite wydatki) AS Łączne wydatki, COUNT(q.Identyfikator spotkania) AS Liczba spotkańFROM Klient, Termin, Zapytanie_Całkowite_wydane_Każde_spotkanie AS Identyfikator spotkaniaGROUP BY Klient.IDKlienta, Imię, NazwiskoORDER BY Nazwisko, Imię;
 
 

 I zapytaj Total_Spent_Each_Appointment
 
SELECT Spotkanie.Identyfikator spotkania, SUM(Cena rozszerzona usługi) AS TotalSpentFROM Spotkanie, UsługaRenderedWHERE Spotkanie.Identyfikator spotkania =Usługarenderowana.Identyfikator spotkaniaGROUP BY Spotkanie.Identyfikator spotkaniaORDER BY Spotkanie.Identyfikator spotkania;
 
 
Raport usług i rabatów
 

 
 

 Ten raport pokazuje każdą usługę wraz z sumą ceny zwykłej usługi, ceny rozszerzonej i wskazaniem kwoty rabatu zastosowanego do usług świadczonych w przeszłości.
 
 

 Na podstawie zapytania:
 
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 BY SalonService.ServiceID, ServiceNameORDER BY SalonService.ServiceID, ServiceName;
 
 
Raport adresów klientów
 

 
 

 Ten raport pokazuje pełne nazwy i adresy każdego Klienta.
 

 
 
VII. Wnioski
 

 Tworzenie aplikacji bazodanowej odbywa się zgodnie z cyklem rozwoju systemu, który rozpoczyna się od modelowania koncepcyjnego i przechodzi przez uporządkowany zestaw kroków, które obejmują modelowanie logiczne, normalizację, implementację fizyczną i rozwój aplikacji. Przykład projektu Salon fryzjerski ilustruje każdy z tych głównych etapów. Jednak niektóre szczegóły nie zostały w pełni udokumentowane. Na przykład, może być wymagana dodatkowa praca w celu normalizacji relacji Usług Salonu w celu uwzględnienia różnych materiałów wykorzystywanych do każdej usługi. Można również dodać dodatkowe szczegóły implementacji aplikacji, takie jak inne kody VBA i bardziej szczegółowe opisy użycia każdego formularza i raportu.