Das Friseursalon-Datenbankprojekt

Aktualisiert:22. Januar 2018 von Richard Holowczak

Die folgenden Materialien dokumentieren das Design und die Entwicklung einer Datenbankanwendung zur Unterstützung eines kleinen Friseursalons. Das Projekt beginnt mit einer Beschreibung des Geschäfts und setzt sich fort durch konzeptionelle (E-R) Modellierung, logische (relationale) Modellierung, physikalische Modellierung und schließlich Implementierung einer Datenbankanwendung. Anmerkungen (Kommentare) werden am Ende jedes Abschnitts bereitgestellt, um einige Besonderheiten der auszuführenden Schritte zu erläutern.

Inhaltsverzeichnis

Ich. Geschäftsszenario
II. ER-Modell mit UML-Notation
III. Umstellung auf relationales Modell
IV. Normalisierung
V. Erstellen des Datenbankschemas mit SQL
VI. Datenbankanwendung
VII. Schlussfolgerungen

.

Ich. Geschäftsszenario

Unser Unternehmen besitzt und betreibt seit 7 Jahren einen Friseur- und Nagelsalon in Midtown Manhattan. Wir haben Tabellenkalkulationen und ein Logbuch aus Papier verwendet, um Kunden, Termine und Zahlungen im Auge zu behalten. Wir möchten diese manuelle Methode der Geschäftsverfolgung durch eine Datenbank ersetzen.

In unserem Geschäft vereinbaren Kunden Termine mit ihrem Lieblingsfriseur (Leute, die Kundenhaare schneiden und stylen) oder anderen Mitarbeitern und können sich einer Reihe von Dienstleistungen wie grundlegendem Haarschnitt/Styling, Haarfarbe, Highlights, Dauerwelle, Gesichtsbehandlung, Maniküre, Pediküre usw. Wir müssen die Materialien (Shampoo, Haarfarbe) und die Zeit, die für die Durchführung jeder Dienstleistung benötigt wird, im Auge behalten. Während jeder Service einen Standardpreis hat, können Werbeaktionen und andere Faktoren den tatsächlichen Preis beeinflussen, der dem Kunden für den jeweiligen Service gewährt wird.

Wir müssen auch unsere Mitarbeiter im Auge behalten, einschließlich ihrer Privatadresse, Kontaktinformationen und Gehaltssätze. Wir müssen die Kontaktinformationen jedes Kunden sowie sein Geschlecht im Auge behalten. Für Termine müssen wir das Datum und die Uhrzeit des Termins sowie den Kunden kennen, für den der Termin bestimmt ist.

Kommentar

Erstellen Sie basierend auf der obigen Beschreibung ein Entity-Relationship-Modell unter Verwendung der UML-Notation, das alle Datenanforderungen des Unternehmens erfasst.

II. ER-Modell mit UML-Notation

Basierend auf der obigen Beschreibung entwickeln wir das folgende Entity-Relationship-Modell unter Verwendung der UML-Notation.

Kommentar

Was uns an diesem Modell gefällt:

• Alle Beziehungslinien gehen in eine horizontale oder vertikale Position. Es werden keine Grenzen überschritten.
• Attributnamen werden ohne Leerzeichen in den Namen geschrieben. Es werden keine Abkürzungen verwendet.
• Jede Beziehung hat genau zwei Ausdrücke, aus denen wir Beziehungssätze bilden können (siehe nächster Abschnitt).
• Das Diagramm hat auch eine „Legende“ in der oberen rechten Ecke, damit wir erkennen können, was das Diagramm darstellt und wer das Diagramm zuletzt geändert hat.

Beziehungssätze

Ein Kunde kann sein einen oder mehrere Termine vereinbaren

Ein Termin muss sein eine Reservierung für einen und nur einen Kunden

Ein SalonService kann sein ein Dienst, der als ein oder mehrere ServiceRendered erbracht wird

Ein ServiceRendered muss sein eine Wiedergabe von einem und nur einem SalonService

Ein Mitarbeiter kann sein Rendern ein oder mehrere ServiceRendered

Ein ServiceRendered muss sein erbracht von einem und nur einem Mitarbeiter
 

Ein Termin kann sein eine Reservierung, um einen oder mehrere ServiceRendered bereitzustellen

Ein ServiceRendered muss sein eine bestimmte Dienstleistung, die während eines und nur eines Termins erbracht wird

Kommentar

Die Beziehungssätze sollten Sinn machen. In diesem Beispiel sind die Verbphrasen unterstrichen. Die Namen der Entitäten sind fett gedruckt. Die minimale Kardinalität (kann sein für 0 und muss sein zu 1) sind kursiv geschrieben. Die maximale Kardinalität wird als „one or more“ für * und „one and only one“ für 1 geschrieben.

Nachdem das ER-Modell fertiggestellt ist, fahren wir mit dem nächsten Schritt fort – der Umwandlung des konzeptionellen ER-Modells in ein logisches relationales Modell.

III. Konvertierung in relationales Modell

Der nächste Schritt besteht darin, das Entity-Relationship-Diagramm in ein relationales Modell umzuwandeln. Während dieses Schritts werden Identifikatoren in den Entitäten zu Schlüsseln in den Relationen. Eins-zu-Viele-Beziehungen führen dazu, dass ein Fremdschlüssel von der Eins-Seite auf die Viele-Seite der Beziehung kopiert wird.

Kunde ( Kunden-ID (Schlüssel), Vorname, Nachname, Telefonnummer, Straße, Stadt, Bundesland, Postleitzahl )

SalonService ( ServiceID (Schlüssel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Mitarbeiter ( EmployeeID (key), FirstName, LastName, Street, City, State, Postleitzahl, PayRate )

Termin ( Termin-ID (Schlüssel), Termindatum, Terminzeit, Kunden-ID (fk) )

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

Dies ist der „Anfangssatz von Beziehungen.“

Kommentar

• Beachten Sie, dass der ServiceRendered Entität aus dem ER-Modell ist ID-abhängig, was bedeutet, dass sie zusätzlich zu LineItemNumber ein Attribut benötigt, um einen zusammengesetzten Schlüssel zu bilden.
• Schlüssel werden mit der Bezeichnung (key) und Fremdschlüssel mit der Bezeichnung (fk) dargestellt.

Der nächste Schritt besteht darin, den anfänglichen Satz von Beziehungen zu normalisieren.

IV. Normalisierung

Der nächste Schritt ist die Normalisierung der Beziehungen.

Die für jede Beziehung zu befolgenden Schritte sind:

1. Schreiben Sie die Relation inklusive aller Attributnamen aus. Schlüssel und Fremdschlüssel angeben.
2. Geben Sie einige Beispieldaten für die Beziehung an.
3. Geben Sie den Schlüssel an für die Beziehung und notieren Sie alle Funktionalen Abhängigkeiten .
4. Gehen Sie die Definitionen jeder Normalform durch, beginnend mit 1NF und aufsteigend bis BCNF (oder 3NF, abhängig von Ihren Projektanforderungen).
5. Wenn eine Relation die Definition einer Normalform erfüllt, gehe zur nächsthöheren Normalform auf.
6. Wenn eine Relation die Definition einer Normalform nicht erfüllt (z. B. eine partielle Schlüsselabhängigkeit oder eine transitive Abhängigkeit enthält), teilen Sie die Relation in zwei neue Relationen auf.
   Beginnen Sie mit dem Normalisierungsprozess von Anfang an mit jeder dieser beiden neuen Beziehungen.

Kundenbeziehung

Kunde ( Kunden-ID (Schlüssel) , Vorname, Nachname, Telefon des Kunden, Straße, Stadt, Bundesland, Postleitzahl, Geschlecht )

Beispieldaten

Schlüssel:Kunden-ID

FD1:Kunden-ID -> Vorname, Nachname, Telefonnummer, Straße, Stadt, Bundesland, Postleitzahl, Geschlecht

FD2:Postleitzahl -> Stadt, Bundesland

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Transitive Abhängigkeit existiert:CustomerID -> Postleitzahl und Postleitzahl -> Stadt, Bundesland

Lösung:Teilen Sie die Kundenbeziehung in zwei neue Beziehungen mit den Namen CustomerData und ZipCodes auf:

Kundendaten (Kundennummer (Schlüssel), Vorname, Nachname, Telefon des Kunden, Straße, Postleitzahl (fk), Geschlecht )

Schlüssel:Kunden-ID

FD1:KundenID -> Vorname, Nachname, Telefonnummer, Straße, Postleitzahl (fk), Geschlecht

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

Postleitzahlen (Postleitzahl (Schlüssel), Stadt, Bundesland)

Schlüssel:Postleitzahl

FD1:Postleitzahl -> Stadt, Bundesland

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

SalonService-Beziehung

SalonService ( ServiceID (Schlüssel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Beispieldaten:

Schlüssel:ServiceID

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

1NF:ServiceMaterials kann als mehrwertiges Attribut behandelt werden. In diesem Fall ist SalonService nicht in 1NF.

Lösung:ServiceMaterials in eine separate Relation ausgliedern.

Für dieses Beispiel behalten wir jedoch ServiceMaterials als Attribut der Beziehung SalonService bei.

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

Mitarbeiterbeziehung

Mitarbeiter (Mitarbeiter-ID (Schlüssel), Vorname, Nachname, Straße, Stadt, Bundesland, Postleitzahl, Lohnsatz)

Schlüssel:MitarbeiterID

FD1:MitarbeiterID -> Vorname, Nachname, Straße, Ort, Bundesland, Postleitzahl, Lohnsatz

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Transitive Abhängigkeit vorhanden:EmployeeID -> Postleitzahl und Postleitzahl -> Stadt, Bundesland

Lösung:Teilen Sie die Kundenbeziehung in zwei neue Beziehungen mit den Namen EmployeeData und ZipCodes auf:

EmployeeData(EmployeeID (key), FirstName, LastName, Street, Postleitzahl (fk), PayRate )

Schlüssel:MitarbeiterID

FD1:MitarbeiterID -> Vorname, Nachname, Straße, Postleitzahl (fk), Lohnsatz

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

Hinweis:Wir haben bereits eine ZipCodes-Beziehung aus der Zeit, als die Kundenbeziehung aufgeteilt wurde. Also verwenden wir diese ZipCodes-Beziehung wieder. Es ist nicht erforderlich, eine zweite ZipCodes-Beziehung zu erstellen.

Terminbeziehung

Termin ( AppointmentID (Schlüssel), AppointmentDate, AppotinmentTime, CustomerID (fk) )

Beispieldaten:

Schlüssel:TerminID

FD1:TerminID -> TerminDatum, TerminUhrzeit, KundenID (fk)

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

ServiceRendered-Beziehung

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

Beispieldaten:

Schlüssel:AppointmentID, LineItemNumber

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

1NF:Erfüllt die Definition einer Relation

2NF:Keine partiellen Schlüsselabhängigkeiten

3NF:Keine transitiven Abhängigkeiten

BCNF:Alle Determinanten sind Kandidatenschlüssel

Endgültiger Satz von Beziehungen

Kunde ( Kundennummer (Schlüssel) , Vorname, Nachname, Telefonnummer, Straße, Postleitzahl (fk), Geschlecht )

Postleitzahlen ( Postleitzahl (Schlüssel), Stadt, Bundesland)

SalonService ( ServiceID (Schlüssel), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Mitarbeiter ( EmployeeID (key), FirstName, LastName, Street, Postleitzahl (fk), PayRate )

Termin ( Termin-ID (Schlüssel), Termindatum, Terminzeit, Kunden-ID (fk) )

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

Kommentar

• Beachten Sie, dass nur eine ZipCodes-Beziehung erforderlich ist. Es wird sowohl mit Kunden- als auch mit Mitarbeiterbeziehungen geteilt.
• Wie bereits erwähnt, wurde das ServiceMaterials-Attribut in diesem Beispiel nicht normalisiert. Vielleicht kann dies in einer zukünftigen Aufgabe oder Erweiterung des Modells erfolgen.

Nachdem die Beziehungen nun normalisiert sind, kann das Schema in einem Datenbankverwaltungssystem unter Verwendung einer strukturierten Abfragesprache (SQL) erstellt werden.

V. Erstellen des Datenbankschemas mit der strukturierten Abfragesprache

Erstellen Sie eine Tabelle in der Datenbank für jede der Beziehungen im endgültigen Satz von Beziehungen.

Der folgende SQL-Code erstellt die sechs Tabellen und fügt jeder die PRIMARY KEY-Einschränkung hinzu:

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), Nachname VARCHAR(35), Telefonnummer VARCHAR(15), Straße VARCHAR(35), Postleitzahl VARCHAR(12), Geschlecht 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 N ULL, FirstName VARCHAR(35), LastName VARCHAR(25), Street VARCHAR(45), Postleitzahl 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))

Fremdschlüssel hinzufügen

Die folgenden SQL-Codes fügen FOREIGN KEY-Einschränkungen hinzu, um die Tabellen miteinander zu verknüpfen:

ALTER TABLE Kunde ADD CONSTRAINT fk_customer_zipcodes FOREIGN KEY (Postleitzahl) REFERENCES Postleitzahlen (Postleitzahl)ALTER TABLE Mitarbeiter ADD CONSTRAINT fk_employee_zipcodes FOREIGN KEY (Postleitzahl) REFERENCES Postleitzahlen (Postleitzahl)ALTER TABLE Termin ADD CONSTRAINT fk_customer_appointment FOREIGN KEY (CustomerID) REFERENCES Kunde (Kunden-ID) REFERENCES )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 Mitarbeiter (EmployeeID)ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Appointment REFERENCES /pre> 
 

 Kommentar zu SQL:
 
 
Die meisten DBMS speichern DATUM und ZEIT in derselben Spalte. Daher wurden AppointmentDate und AppointmentTime in einer Spalte mit dem Namen AppointmentDateTime
 in der Datenbank zusammengefasst 
Schlüssel und Fremdschlüssel sollten genau denselben Namen und denselben Datentyp haben. Beispielsweise ist der Schlüssel CustomerID VARCHAR(10) in der Customer-Tabelle und auch VARCHAR(10) in der Appointment-Tabelle.
 
Einschränkungen erhalten aussagekräftige Namen wie pk_customer für einen Primärschlüssel und fk_customer_zipcodes für einen Fremdschlüssel.
 
Spalten wie Telefonnummer und Postleitzahl sollten den Datentyp VARCHAR verwenden. Wenn ein NUMBER- oder INTEGER-Datentyp verwendet wird, dann fehlen die führenden Nullen.
 
 
 

 Nach dem Erstellen der Tabellen und dem Hinzufügen der Fremdschlüsseleinschränkungen sieht das Datenbankschema nun wie folgt aus:
 
 

 
 
 
Beziehungsansicht
 

 Mit der Beziehungsansicht unter Datenbank-Tools können wir die Beziehungen (Fremdschlüssel) zwischen den Tabellen sehen:
 

 
 

 
 
 
Hinzufügen von Daten zu den Tabellen mit SQL INSERT-Anweisungen
 
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', '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', 'Herrenhaarschnitt', 20, 22, 'None');INSERT INTO SalonService VALUES ('SV102', 'Damenhaarschnitt', 30, 32 , 'None');INSERT INTO SalonService VALUES ('SV103', 'Child Haircut', 20, 15, 'None');INSERT INTO SalonService VALUES ('SV104', 'Women''s Hair Color', 60, 76 , 'Farbe, Reagenz, Handschuhe, Reagenzpinsel, Folie');INSERT INTO SalonService VALUES('SV105', 'Women''s Hair Style', 45, 56, 'Shampoo, Conditioner');INSERT INTO SalonService VALUES (' SV106', 'Männerfrisur', 45, 46, 'Shampoo, Spülung'); IN MitarbeiterWERTE EINFÜGEN ('E300', 'Joy', 'Aveda', '46 Easton Ave.', '07026') , 18);INSERT INTO Employee VALUES ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. Geeignet. 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 14:00:00', 'C106');INSERT INTO Appointment VALUES ('A403', '12/18/2017 15:30:00 PM', 'C106');INSERT INTO Appointment VALUES ('A404 ', '21.12.2017 11:30:00', 'C108');INSERT INTO Appointment VALUES ('A405', '31.12.2017 10:00:00', 'C107');INSERT INTO Appointment VALUES ('A406', '01/11/2018 15:15:00 PM', 'C103');INSERT INTO Appointment VALUES ('A407', '01/12/2018 14:30:00 PM', 'C104');INSERT INTO Appointment VALUES ('A408', '0 22.01.2018 16:00:00', '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 zu Datenbeispielen
 
 
Wir fügen gerade genug Daten hinzu, um die Beziehungen zwischen den Tabellen testen zu können und den Anwendungsentwicklern etwas zu geben, mit dem sie arbeiten können.
 
Achten Sie auf die Reihenfolge, in der Daten hinzugefügt werden. Beispielsweise müssen zuerst alle Postleitzahlen eingefügt werden, bevor entweder Kunde oder Mitarbeiter (die beide Postleitzahlen als Fremdschlüssel verwenden) eingefügt werden können.
 
Wenn Sie VARCHAR-Daten mit eingebetteten Anführungszeichen hinzufügen, verwenden Sie zwei Anführungszeichen zusammen. B. „Frauenfrisur“
 
An diesem Punkt ist das Datenbankschema bereit für die Anwendungsentwickler, damit sie mit der Gestaltung von Formularen, Berichten und Abfragen beginnen können.
 
 

 Nachdem das Datenbankschema erstellt und mit einigen Beispieldaten gefüllt wurde, kann die Datenbankanwendung entwickelt werden.
 

 
 
VI. Datenbankanwendung
 

 Die Datenbankanwendung besteht aus einer Reihe von Formularen, Berichten und Abfragen, die in einem Navigationsformular miteinander verknüpft sind.
 

 Das Navigationsformular ist das erste Formular, das erscheint, wenn die Datenbank geöffnet wird.
 
 
Navigationsformular
 

 
 

 Durch Klicken auf die Auswahl auf der linken Seite können verschiedene Datenerfassungsformulare und Berichte angezeigt werden.
 
 
Kundendaten-Eingabeformular
 

 
 

 Das Kundendateneingabeformular wird verwendet, um bestehende Kunden zu suchen und neue Kundeninformationen einzugeben. Die Felder „Stadt“ und „Bundesstaat“ werden automatisch ausgefüllt, indem eine Postleitzahl aus dem Kombinationsfeld ausgewählt wird. Das Formular verfügt über mehrere benutzerdefinierte VBA-Codes, um den Vor- und Nachnamen in die richtige Groß- und Kleinschreibung umzuwandeln und eine neue, eindeutige Kunden-ID zu generieren, wenn ein leeres Kunden-ID-Feld angezeigt wird nach dem Erstellen eines neuen Datensatzes.
 
 

 
 
 
Dateneingabeformular für Salondienste
 

 
 

 Das Salonservice-Dateneingabeformular wird verwendet, um neue Salonservices abzufragen, zu aktualisieren und hinzuzufügen.
 
 
Termindaten-Eingabeformular
 

 
 

 Das Formular Dateneingabe für Termine wird verwendet, um einen neuen Termin für einen Kunden zu erstellen. Wie beim Kundenformular kann eine neue Termin-ID erstellt werden, indem in ein leeres Termin-ID-Feld geklickt wird, nachdem ein neuer Datensatz erstellt wurde. Der Kunde kann wie unten gezeigt aus dem Kombinationsfeld Kunden-ID ausgewählt werden:
 

 
 

 Wenn es sich um einen neuen Kunden handelt, der einen Termin vereinbart, kann der Benutzer auf die Schaltfläche „Neuer Kunde“ klicken, um das Kundendateneingabeformular aufzurufen. Nachdem die Informationen des neuen Kunden gespeichert wurden, kann der Benutzer zum Formular zur Termindateneingabe zurückkehren und den Termin vereinbaren.
 
 
Termin- und Dienstleistungsformular
 

 
 

 Der Zweck dieses Formulars besteht darin, verschiedene mit einem Termin verbundene Dienstleistungen einzugeben. Dieses Formular könnte auch verwendet werden, um eine Rechnung für den Kunden zu erstellen. Der Dienst und der Mitarbeiter können wie unten gezeigt aus ihren jeweiligen Kombinationsfeldern ausgewählt werden:
 

 
 

 
Bericht über die Gesamtzahl der Kundentermine
 

 
 

 Dieser Bericht enthält eine Zusammenfassung der Anzahl der Termine und des Gesamtbetrags, die von jedem Kunden ausgegeben wurden.
 
 

 Basierend auf der Abfrage:
 
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.CustomerID =Appointment.CustomerID AND Appointment.AppointmentID =q. TerminIDGROUP BY Kunde.KundenID, Vorname, NachnameORDER BY Nachname, Vorname;
 
 

 Und fragen Sie Total_Spent_Each_Appointment
 ab 
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;
 
 
Dienstleistungs- und Rabattbericht
 

 
 

 Dieser Bericht zeigt jede der Dienstleistungen mit Summen des regulären Servicepreises, des erweiterten Preises und einer Angabe des Rabattbetrags, der auf die in der Vergangenheit erbrachten Dienstleistungen angewendet wurde.
 
 

 Basierend auf der Abfrage:
 
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;
 
 
Kundenadressenbericht
 

 
 

 Dieser Bericht zeigt die vollständigen Namen und Adressen jedes Kunden.
 

 
 
VII. Schlussfolgerungen
 

 Die Entwicklung einer Datenbankanwendung folgt einem Systementwicklungslebenszyklus, der mit der konzeptionellen Modellierung beginnt und eine strukturierte Reihe von Schritten durchläuft, die logische Modellierung, Normalisierung, physische Implementierung und Anwendungsentwicklung umfassen. Das Projektbeispiel „Friseursalon“ veranschaulicht jeden dieser Hauptschritte. Einige Details sind jedoch nicht vollständig dokumentiert. Zum Beispiel kann einige zusätzliche Arbeit erforderlich sein, um die Salondienstleistungsbeziehung zu normalisieren, um unterschiedliche Materialien zu berücksichtigen, die für jede Dienstleistung verwendet werden. Zusätzliche Anwendungsimplementierungsdetails wie andere VBA-Codes und detailliertere Beschreibungen der Verwendung jedes Formulars und Berichts könnten ebenfalls hinzugefügt werden.