Le projet de base de données des salons de coiffure

Mis à jour :22 janvier 2018 par Richard Holowczak

Les documents suivants documentent la conception et le développement d'une application de base de données pour prendre en charge un petit salon de coiffure. Le projet commence par une description de l'entreprise et se poursuit par la modélisation conceptuelle (E-R), la modélisation logique (relationnelle), la modélisation physique et enfin la mise en œuvre d'une application de base de données. Des notes (commentaires) sont fournies à la fin de chaque section pour expliquer certaines caractéristiques spécifiques des étapes en cours.

Table des matières

Je. Scénario commercial
II. Modèle ER utilisant la notation UML
III. Conversion au modèle relationnel
IV. Normalisation
V. Création du schéma de base de données avec SQL
VI. Application de base de données
VII. Conclusion

.

Je. Scénario d'entreprise

Notre société possède et exploite un salon de coiffure et de manucure dans le centre de Manhattan depuis 7 ans. Nous utilisons des feuilles de calcul et un journal de bord papier pour suivre les clients, les rendez-vous et les paiements. Nous aimerions remplacer cette méthode manuelle de suivi de l'entreprise par une base de données.

Dans notre entreprise, les clients prennent rendez-vous avec leur coiffeur préféré (personnes qui coupent et coiffent les cheveux des clients) ou un autre employé et peuvent se livrer à un certain nombre de services tels que la coupe/coiffage de base, la couleur des cheveux, les mèches, la permanente, le soin du visage, manucure, pédicure, etc. Nous devons garder une trace des matériaux (shampooing, couleur des cheveux) et du temps qu'il faudra pour terminer chaque service. Bien que chaque service ait un prix standard, les promotions et d'autres facteurs peuvent affecter le prix réel proposé au client pour le service donné.

Nous devons également garder une trace de nos employés, y compris leur adresse personnelle, leurs coordonnées et leur taux de rémunération. Nous devons garder une trace des coordonnées de chaque client ainsi que de son sexe. Pour les rendez-vous, nous devons connaître la date et l'heure du rendez-vous et le client auquel le rendez-vous est destiné.

Commentaire

Sur la base de la description ci-dessus, construisez un modèle de relation d'entité à l'aide de la notation UML qui capturera tous les besoins de données de l'entreprise.

II. Modèle ER utilisant la notation UML

Sur la base de la description ci-dessus, nous développons le modèle de relation d'entité suivant en utilisant la notation UML.

Commentaire

Ce que nous aimons dans ce modèle :

• Toutes les lignes de relation vont dans une position horizontale ou verticale. Aucune ligne n'est franchie.
• Les noms d'attributs sont épelés sans espaces dans les noms. Aucune abréviation n'est utilisée.
• Chaque relation a deux expressions à partir desquelles nous pouvons créer des phrases de relation (voir la section suivante).
• Le diagramme a également une "légende" dans le coin supérieur droit afin que nous puissions dire ce que le diagramme représente et qui a modifié le diagramme en dernier.

Phrases relationnelles

Un client peut-être prendre un ou plusieurs rendez-vous

Un rendez-vous doit être une réservation pour un et un seul Client

Un SalonService peut-être un service rendu sous la forme d'un ou plusieurs ServiceRendered

Un ServiceRendu doit être un rendu d'un et un seul SalonService

Un Employé peut-être rendu un ou plusieurs ServiceRendered

Un ServiceRendu doit être rendu par un et un seul Employé
 

Un rendez-vous peut-être une réservation pour fournir un ou plusieurs ServiceRendered

Un ServiceRendu doit être un service spécifique rendu lors d'un et un seul Rendez-vous

Commentaire

Les phrases de relation doivent avoir un sens. Dans cet exemple, les phrases verbales sont soulignées. Les noms des entités sont en caractères gras. La cardinalité minimale (peut être pour 0 et doit être pour 1) sont écrits en italique. La cardinalité maximale s'écrit "un ou plusieurs" pour * et "un et un seul" pour 1.

Une fois le modèle ER finalisé, nous passons à l'étape suivante :convertir le modèle ER conceptuel en un modèle relationnel logique.

III. Conversion en modèle relationnel

L'étape suivante consiste à convertir le diagramme Entity Relationship en un modèle relationnel. Au cours de cette étape, les identifiants dans les entités deviennent des clés dans les relations. Les relations un-à-plusieurs entraînent la copie d'une clé étrangère du côté un vers le côté plusieurs de la relation.

Client ( CustomerID (clé), FirstName, LastName, PhoneNumber, Street, City, State, ZipCode )

SalonService ( ServiceID (clé), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Employé ( EmployeeID (clé), FirstName, LastName, Street, City, State, ZipCode, PayRate )

Rendez-vous ( AppointmentID (clé), AppointmentDate, AppointmentTime, CustomerID (fk) )

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

Il s'agit de "l'ensemble initial de relations".

Commentaire

• Remarquez que le ServiceRendered L'entité du modèle ER est dépendante de l'ID, ce qui signifie qu'elle a besoin d'un attribut en plus de LineItemNumber pour former une clé composite.
• Les clés sont affichées avec la désignation (clé) et les clés étrangères sont affichées avec la désignation (fk).

L'étape suivante consiste à normaliser l'ensemble initial de relations.

IV. Normalisation

L'étape suivante consiste à normaliser les relations.

Les étapes à suivre pour chaque relation sont :

1. Écrivez la relation, y compris tous les noms d'attributs. Indiquez les clés et les clés étrangères.
2. Fournissez des exemples de données pour la relation.
3. Indiquez la clé pour la relation et notez toutes les dépendances fonctionnelles .
4. Parcourez les définitions de chaque forme normale en commençant par 1NF et en remontant jusqu'à BCNF (ou 3NF selon les exigences de votre projet).
5. Si une relation correspond à la définition d'une forme normale, passer à la forme normale supérieure suivante.
6. Si une relation ne répond pas à la définition d'une forme normale (par exemple, si elle contient une dépendance de clé partielle ou si elle contient une dépendance transitive), divisez la relation en deux nouvelles relations.
   Commencez le processus de normalisation depuis le début avec chacune de ces deux nouvelles relations.

Relation Client

Client (ID client (clé), Prénom, Nom, Téléphone du client, Rue, Ville, État, Code postal, Sexe)

Exemple de données

Clé :CustomerID

FD1 :ID client -> Prénom, Nom, Numéro de téléphone, Rue, Ville, État, Code postal, Sexe

FD2 :Code postal -> Ville, État

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :une dépendance transitive existe :CustomerID -> ZipCode et ZipCode -> City, State

Solution :divisez la relation client en deux nouvelles relations nommées CustomerData et ZipCodes :

CustomerData (CustomerID (clé), FirstName, LastName, CustPhone, Street, ZipCode (fk), Gender )

Clé :CustomerID

FD1 :ID client -> Prénom, Nom, Numéro de téléphone, Rue, Code postal (fk), Sexe

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Codes postaux (code postal (clé), ville, état)

Clé :code postal

FD1 :Code postal -> Ville, État

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Relation SalonService

SalonService ( ServiceID (clé), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Exemple de données :

Clé :ServiceID

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

1NF :ServiceMaterials peut être traité comme un attribut à valeurs multiples. Dans ce cas SalonService n'est pas en 1NF.

Solution :divisez ServiceMaterials en une relation distincte.

Pour cet exemple, nous conserverons cependant ServiceMaterials comme attribut de la relation SalonService.

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Relation Employé

Employee( EmployeeID (key), FirstName, LastName, Street, City, State, ZipCode, PayRate )

Clé :ID de l'employé

FD1 :EmployeeID -> FirstName, LastName, Street, City, State, ZipCode, PayRate

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :une dépendance transitive existe :EmployeeID -> ZipCode et ZipCode -> City, State

Solution :divisez la relation client en deux nouvelles relations nommées EmployeeData et ZipCodes :

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

Clé :ID de l'employé

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

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Remarque :Nous avons déjà une relation Codes postaux à partir du moment où la relation Client a été scindée. Nous réutilisons donc cette relation ZipCodes. Il n'est pas nécessaire de créer une deuxième relation ZipCodes.

Relation de rendez-vous

Rendez-vous ( AppointmentID (clé), AppointmentDate, AppointmentTime, CustomerID (fk) )

Exemple de données :

Clé :ID de rendez-vous

FD1 :ID de rendez-vous -> Date de rendez-vous, heure de rendez-vous, ID client (fk)

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Relation rendue par le service

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

Exemple de données :

Clé :AppointmentID, LineItemNumber

FD1 :ID de rendez-vous, numéro d'élément de ligne > ID de service (fk), prix étendu du service, ID d'employé (fk)

1NF :Répond à la définition d'une relation

2NF :Pas de dépendances de clé partielles

3NF :pas de dépendances transitives

BCNF :Tous les déterminants sont des clés candidates

Ensemble final de relations

Client ( CustomerID (clé) , FirstName, LastName, PhoneNumber, Street, ZipCode (fk), Gender )

Codes postaux (Code postal (clé), Ville, État)

SalonService ( ServiceID (clé), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Employé ( EmployeeID (clé), FirstName, LastName, Street, ZipCode (fk), PayRate )

Rendez-vous ( AppointmentID (clé), AppointmentDate, AppointmentTime, CustomerID (fk) )

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

Commentaire

• Notez qu'une seule relation ZipCodes est requise. Il est partagé avec les relations clients et employés.
• Comme indiqué précédemment, l'attribut ServiceMaterials n'a pas été normalisé dans cet exemple. Peut-être que cela peut être fait dans une future affectation ou amélioration du modèle.

Maintenant que les relations sont normalisées, le schéma peut être créé dans un système de gestion de base de données à l'aide d'un langage de requête structuré (SQL).

V. Création du schéma de base de données avec le langage de requête structuré

Créez une table dans la base de données pour chacune des relations dans l'ensemble final de relations.

Le code SQL suivant crée les six tables et ajoute la contrainte PRIMARY KEY à chacune :

CREATE TABLE ZipCodes( code postal VARCHAR(12) NOT NULL, ville VARCHAR(36), état VARCHAR(4), CONSTRAINT pk_zipcodes PRIMARY KEY (code postal))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, CONTRAINTE pk_appointment PRIMARY KEY (AppointmentID))CREATE TABLE SalonService( ServiceID VARCHAR(10) NOT NULL, ServiceName VARCHAR(35), ServiceDuration INTEGER, ServicePrice NUMBER, ServiceMaterials VARCHAR(255) ), CONTRAINTE pk_salonservice PRIMARY KEY (ServiceID))CREATE TABLE Employee ( 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, CONTRAINTE pk_ServiceRendered PRIMARY KEY (AppointmentID, LineItemNumber))

Ajout de clés étrangères

Les codes SQL suivants ajoutent des contraintes FOREIGN KEY pour lier les tables entre elles :

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 /pré> 
 

 Commentaire sur SQL :
 
 
La plupart des SGBD stockent la DATE et l'HEURE dans la même colonne. Ainsi, AppointmentDate et AppointmentTime ont été combinés en une seule colonne dans la base de données nommée AppointmentDateTime
 
Les clés et les clés étrangères doivent avoir exactement le même nom et le même type de données. Par exemple, le Key CustomerID est VARCHAR(10) dans la table Customer et également VARCHAR(10) dans la table Appointment.
 
Les contraintes reçoivent des noms significatifs tels que pk_customer pour une clé primaire et fk_customer_zipcodes pour une clé étrangère.
 
Les colonnes telles que le numéro de téléphone et le code postal doivent utiliser le type de données VARCHAR. Si un type de données NUMBER ou INTEGER est utilisé, les zéros non significatifs seront manquants.
 
 
 

 Après avoir créé les tables et ajouté les contraintes de clé étrangère, le schéma de la base de données ressemble maintenant à ceci :
 
 

 
 
 
Vue relationnelle
 

 À l'aide de la vue des relations sous Outils de base de données, nous pouvons voir les relations (clés étrangères) entre les tables :
 

 
 

 
 
 
Ajout de données aux tables à l'aide d'instructions 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 IN TO Customer VALUES ('C102', 'Ishwarya', 'Roberts' , '201-222-3333', '65 Hope Rd', '07026', 'M'); 8989 Smith Rd', '07026', 'M') F' );INSÉRER DANS LES VALEURS DU CLIENT ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M');INSÉRER DANS LES VALEURS DU CLIENT (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F');INSERT IN TO Customer VALUES ('C107', 'Faye', 'Glenn' , '201-333-4242', '1 522 Main St', '07010', 'F' ); F' );INSERT INTO SalonService VALUES ("SV101", "Coupe de cheveux pour hommes", 20, 22, "Aucun");INSERT INTO SalonService VALUES ("SV102", "Coupe de cheveux pour femmes", 30, 32 , 'Aucun');INSERT INTO SalonService VALUES ('SV103', 'Child Haircut', 20, 15, 'Aucun');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, 'Shampooing, Conditioner'); , 18 ); INSÉRER DANS LES VALEURS DES EMPLOYÉS ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. Apte. 2A', '07026', 22);INSÉRER DANS LES VALEURS DES EMPLOYÉS ('E500', 'Koy', 'Petruzzio', '70 Wilard St. ', '07026', 20);INSÉRER DANS LES VALEURS DES EMPLOYÉS ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18);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' ); /2017 02:00:00 PM', 'C106');INSERT INTO Appointment VALUES ('A403', '12/18/2017 03:30:00 PM', 'C106');INSERT INTO Appointment VALUES ('A404 ', '21/12/2017 11:30:00', 'C108');INSERT INTO Appointment VALUES ('A405', '12/31/2017 10:00:00 AM', 'C107');INSERT DANS LES VALEURS de rendez-vous ('A406', '11/01/2018 15:15:00', 'C103'); 'C104');INSÉRER DANS LES VALEURS DE RENDEZ-VOUS ('A408', '0 22/01/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 ('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');
 
Commentaire sur les échantillons de données
 
 
Nous ajoutons juste assez de données pour pouvoir tester les relations entre les tables et donner aux développeurs d'applications une base de travail.
 
Faites attention à l'ordre dans lequel les données sont ajoutées. Par exemple, tous les codes postaux doivent être insérés en premier, avant que le client ou l'employé (qui utilisent tous deux le code postal comme clé étrangère) puisse être inséré.
 
Lorsque vous ajoutez des données VARCHAR avec des guillemets intégrés, utilisez deux guillemets ensemble. par exemple, "Style de coiffure pour femmes"
 
À ce stade, le schéma de la base de données est prêt pour que les développeurs d'applications se mettent au travail pour concevoir des formulaires, des rapports et des requêtes.
 
 

 Maintenant que le schéma de la base de données a été créé et est rempli avec des exemples de données, l'application de base de données peut être développée.
 

 
 
VI. Application de base de données
 

 L'application de base de données se compose d'un ensemble de formulaires, de rapports et de requêtes qui sont liés ensemble sur un formulaire de navigation.
 

 Le formulaire de navigation est le premier formulaire qui apparaît lorsque la base de données est ouverte.
 
 
Formulaire de navigation
 

 
 

 Différents formulaires de saisie de données et rapports peuvent être affichés en cliquant sur la sélection à gauche.
 
 
Formulaire de saisie des données client
 

 
 

 Le formulaire de saisie des données client est utilisé pour rechercher des clients existants et saisir de nouvelles informations sur les clients. Les champs Ville et État sont automatiquement remplis en sélectionnant un formulaire de code postal dans la zone de liste déroulante. Le formulaire comporte plusieurs codes VBA personnalisés pour convertir le prénom et le nom en cas correct et pour générer un nouvel identifiant client unique lorsqu'un champ CustomerID vide apparaît. après avoir créé un nouvel enregistrement.
 
 

 
 
 
Formulaire de saisie des données des services de salon
 

 
 

 Le formulaire de saisie de données de service de salon est utilisé pour interroger, mettre à jour et ajouter de nouveaux services de salon.
 
 
Formulaire de saisie des données de rendez-vous
 

 
 

 Le formulaire de saisie de données de rendez-vous est utilisé pour créer un nouveau rendez-vous pour un client. Comme pour le formulaire Client, un nouvel ID de rendez-vous peut être créé en cliquant dans un champ vide d'ID de rendez-vous après la création d'un nouvel enregistrement. Le client peut être sélectionné dans la zone de liste déroulante ID client comme indiqué ci-dessous :
 

 
 

 S'il s'agit d'un nouveau client prenant rendez-vous, l'utilisateur peut cliquer sur le bouton Nouveau client pour afficher le formulaire de saisie des données client. Une fois les informations du nouveau client enregistrées, l'utilisateur peut revenir au formulaire de saisie des données de rendez-vous et prendre le rendez-vous.
 
 
Formulaire de rendez-vous et de services
 

 
 

 Ce formulaire a pour but de saisir les différentes prestations associées à un rendez-vous. Ce formulaire peut également être utilisé pour générer une facture pour le client. Le service et l'employé peuvent être sélectionnés dans leurs listes déroulantes respectives, comme indiqué ci-dessous :
 

 
 

 
Rapport sur les totaux des rendez-vous clients
 

 
 

 Ce rapport fournit un résumé du nombre de rendez-vous et du montant total dépensé par chaque client.
 
 

 Basé sur la requête :
 
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. AppointmentIDGROUP BY Customer.CustomerID, FirstName, LastNameORDER BY LastName, FirstName;
 
 

 Et requête Total_Spent_Each_Appointment
 
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Appointment, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID ;
 
 
Rapport sur les services et les remises
 

 
 

 Ce rapport montre chacun des services avec les totaux du prix du service régulier, le prix étendu et une indication du montant de la remise appliquée aux services rendus dans le passé.
 
 

 Basé sur la requête :
 
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 ;
 
 
Rapport sur les adresses des clients
 

 
 

 Ce rapport affiche les noms et adresses complets de chaque client.
 

 
 
VII. Conclusion
 

 Le développement d'une application de base de données suit un cycle de vie de développement de système qui commence par la modélisation conceptuelle et passe par un ensemble structuré d'étapes comprenant la modélisation logique, la normalisation, la mise en œuvre physique et le développement d'applications. L'exemple du projet Hair Salon illustre chacune de ces grandes étapes. Cependant, certains détails n'ont pas été entièrement documentés. Par exemple, des travaux supplémentaires peuvent être nécessaires pour normaliser la relation Salon Services afin de tenir compte des différents matériaux utilisés pour chaque service. Des détails supplémentaires sur la mise en œuvre de l'application, tels que d'autres codes VBA et des descriptions plus détaillées de l'utilisation de chaque formulaire et rapport, peuvent également être ajoutés.