AU : 2023-2024

Rapport du projet : Base de Donnée

Réalisé par :
Omar Ben Hammouda
Wahib Bouzabia
 Filière : 2eme année
Génie Télécommunication embarqué

Groupe : GTE 2.1.1

Enseignant : Pr. Mohamed Nazih Omri

 Sommaire
Introduction générale………………………………………………………5
Chapitre 1 : Cahier des charges……………………………………………6
Chapitre 2 : Diagramme Entité-Association……………………………….7
1. Introduction
2. Définition diagramme entité-association
3. Éléments et fonctionnalités d'un diagramme entité-association
4. Diagramme Entité-Association
5. Conclusion
Chapitre 3 : Modèle relationnel……………………………………………10
1. Introduction
2. Définition du modèle relationnel
3. Modèle relationnel
4. Conclusion
Chapitre 4 : Normalisation………………………………………………12
1. Introduction
2. Définition
3. Normalisation
4. Conclusion
Chapitre 5 : Implémentation des tables et requêtes SQL…………………20
1. Introduction
2. Schémas des tables et relations
3. Requête SQL
4. Conclusion
 Introduction générale
Une base de données désigne un ensemble d'informations stockées dans un dispositif
informatique. Les technologies actuelles offrent la possibilité d'organiser et de structurer ces
bases de données de manière à manipuler facilement leur contenu tout en permettant un
stockage efficace de vastes quantités d'informations. Ceci facilite le traitement, le filtrage et le
tri des données selon les besoins.

Les données sont organisées en tables, dont la création, la mise à jour et l'exploitation sont
gérées par un Système de Gestion de Bases de Données Relationnelles (SGBDR), défini par
son schéma (structure) et son contenu (valeurs). Chaque table est constituée de lignes,
appelées enregistrements, et de colonnes, appelées champs.

Les bases de données sont largement utilisées dans divers secteurs, telles que les réservations
aériennes, la gestion de la production, les dossiers médicaux hospitaliers et les
enregistrements légaux des compagnies d'assurances. Les bases de données les plus vastes
sont généralement déployées par des entités gouvernementales, des grandes entreprises ou des
universités.

Dans ce contexte, notre projet a consisté à concevoir une base de données pour la gestion d'un
aéroport. Ce rapport présente en détail notre base de données, divisé en cinq chapitres :

Le premier chapitre expose le cahier des charges élaboré pour notre base de données.

Le deuxième chapitre se consacre à la modélisation du diagramme entité-association,

illustrant les relations entre les objets au sein du système.

Le troisième chapitre présente le modèle relationnel, basé sur l'organisation des données en
tables.

Le quatrième chapitre détaille le graphe minimum de notre base de données et les différentes
formes normales de chaque relation.

Le cinquième chapitre est consacré à l'implémentation de notre base de données dans un

système SGBDR.
 Chapitre 1 : Cahier des charges

Dans le cadre de la gestion d'un aéroport, il est nécessaire de stocker dans une base de
données les informations relatives aux éléments suivants :

Chaque avion géré est identifié par un numéro d'immatriculation et peut appartenir à une
société ou à un particulier. Dans les deux cas, les informations essentielles comprennent le
nom, l'adresse, le numéro de téléphone du propriétaire, ainsi que la date d'acquisition de
l'avion.

Chaque avion est classifié par un type spécifique, défini par son nom, le nom du constructeur,
la puissance du moteur et le nombre de places disponibles.

La maintenance des avions est assurée par les mécaniciens de l'aéroport. Par mesure de
sécurité, les interventions sont toujours réalisées en duo, l'un effectuant les réparations et
l'autre vérifiant. Un même mécanicien peut, selon les circonstances, être responsable de la
réparation ou de la vérification. Les détails conservés pour chaque intervention incluent
l'objet, la date et la durée.

Les informations relatives aux mécaniciens englobent leur nom, adresse, numéro de
téléphone, ainsi que les types d'avions sur lesquels ils sont autorisés à intervenir.

Une liste de pilotes enregistrés auprès de l'aéroport est également maintenue. Pour chaque
pilote, les données comprennent son nom, adresse, numéro de téléphone, numéro de brevet de
pilote, et les types d'avions qu'il est autorisé à piloter, avec le nombre total de vols effectués
pour chacun de ces types.
 Chapitre 2 : Diagramme Entité-Association

1. Introduction
Dans ce chapitre, on va présenter le diagramme entité-association qui modélise la gestion
d’un aéroport.

2. Définition diagramme entité-association

Un diagramme entité-association se présente comme un modèle conceptuel destiné à illustrer

les relations entre les intervenants au sein d'un système. Souvent employés pour concevoir ou
résoudre des problèmes dans le contexte de bases de données relationnelles, ces diagrammes
sont efficaces pour définir la logique et les règles métier à appliquer dans un modèle de
données logiques, ou encore pour déterminer les technologies spécifiques à utiliser dans un
modèle de données physiques.

3. Éléments et fonctionnalités d'un diagramme entité-association

Les diagrammes entité-association se structurent autour d'entités, de relations et d'attributs,

englobant également la cardinalité qui quantifie les relations. Au stade conceptuel, les entités,
symbolisées par des rectangles, représentent des objets, tandis que les associations, figurées
par des ellipses ou des losanges, dépeignent les liens entre eux.

 Les concepts de base :

 Objet ⬄Entité
 Lien ⬄Association
 Propriété⬄Attribut
Entités et types d’entités :

Entité : C’est un élément définissable qui représente un objet du monde réel ayant une
existence propre.

type d’entité (TE) : C’est une représentation d’un ensemble d’entités perçues comme
similaires et ayant les mêmes caractéristiques.

Associations et types d’associations :

Association : Correspond à la façon dont des entités agissent l'une sur l'autre ou sont
associées l'une avec l'autre.
Type d’association (TA) : représentation d’un ensemble d’associations ayant la même
sémantique et décrites par les mêmes caractéristiques.

Les entités intervenantes dans notre projet sont :

-Avion

-Propriétaire

-Mécanicien

-Type d’avion

-Pilote

Attribut : Propriété ou caractéristique d'une entité. Un attribut est généralement représenté

sous la forme d'un ovale ou d'un cercle.

Cardinalité : définit les attributs numériques d'une relation entre deux entités ou ensembles
d'entités.

4. Diagramme Entité-Association
La figure ci-dessous correspond au diagramme entité-association qui modélise la gestion
d’un aéroport.

Figure1 : Diagramme Entité-Association

 5. Conclusion
Dans ce chapitre on a pu déterminer le diagramme entité-association de notre base de
données.
 Chapitre 3 : Modèle Relationnel
1. Introduction
Dans ce chapitre, on va présenter le modèle relationnel à partir du diagramme entité-
association.

2. Définition du modèle relationnel

Le modèle relationnel, formulé par E.F. Codd en 1970, constitue une méthode d'organisation
des données sous forme de tables, connues sous le nom de relations, lesquelles sont
interconnectées. Son succès auprès des chercheurs, des concepteurs et des utilisateurs découle
de la puissance et de la simplicité de ses concepts.

Les objectifs du modèle relationnel incluent :

- Proposer des schémas de données conviviaux,
- Améliorer l'indépendance logique et physique,
- Mettre à la disposition des utilisateurs des langages de haut niveau accessibles même aux
non-informaticiens,
- Optimiser les accès à la base de données,
- Améliorer l'intégrité et la confidentialité,
- Fournir une approche méthodologique dans la construction des schémas.

Une base de données qui adopte le modèle relationnel est qualifiée de base de données
relationnelle. Ces bases de données peuvent utiliser le langage SQL pour les opérations et les
requêtes.

3. Modèle relationnel
Avion(Immatriculation, date achat , #CIN , #nomT)

CIN référence Propriétaire

NomT référence Type

Propriétaire(CIN, nom,@tel,catégorie)

Mécanicien(CIN , nom , @ , tel)

Intervention(#ImmA,CINM,objet,date,durée)

ImmA référence Avion

CINM référence mécanicien

Type(nom,constructeur,puissance,nb places)

Habilité1(#nomT ,CINM)

CINM reference M

nomT reference T

Pilote(CIN,Nom,Adresse,#tel)

Habilité2(#CINP , NomT,nb-vols)

CIN reference Pilote

NomT refernce Type

4. Conclusion
Dans ce chapitre on a arboré le modèle relationnel de notre base de données.
 Chapitre 4 : Normalisation

1. Introduction
Dans ce chapitre, on va présenter le graphe minimum de notre base de données et les
différentes formes normales.

2. Définition
La normalisation constitue le processus d'organisation des données au sein d'une base de
données. Ce procédé englobe la création de tables et l'établissement de relations entre celles-
ci, conformément à des règles élaborées pour protéger les données et accroître la flexibilité de
la base de données. Cela s'opère en éliminant la redondance et les dépendances incohérentes,
sources d'anomalies sémantiques. Ces anomalies compliquent la manipulation automatisée
des données et la gestion des bases de données.

Dans ce contexte, nous allons présenter les normes et les règles relatives aux différentes
formes normales des bases de données.

3. Normalisation
On va présenter pour chaque relation :

- les redondances éventuelles dans sa population.

- le graphe minimum de dépendances.
- l’(les) identifiant(s).
- la forme normale.
- la décomposition optimale.

Ensemble des dépendances fonctionnelles (DF)

Num_immatri🡪 Date d’achat, IdProp, nomTyp

IdProp 🡪nomPL, adresse, type, numéro de téléphone

NomTyp🡪 nom du construction, puissance de moteur, nombre de places

IdPL🡪 nomPL, adresse, numéro de téléphone, numéro du brevet

IdMec🡪 nom_Mec, adresse, numéro de téléphone

(nomTyp+IdPL)🡪nombre total d’heures de vol

(num_immatri+IdMec)🡪objet, date, durée

(num_immatri+IdMec)🡪objet, date, durée

Relation Avion :

Num_immatri 🡪 Date d’achat, IdProp, nomTyp

-Pas de redondances

 Graphe minimum :

num_immatri

IdProp Date d’achat NomTyp

Identifiant : num_immatri

 Forme normale :
-Identifiant : Num_immatri

-Avion est en 1FN car les attributs sont simples et monovalués.

-Avion est en 2FN car tous les attributs décrivent la relation.

-Avion est en 3FN car la profondeur est 1.

-Avion est en FNBC car toute source complète de DF est un identifiant entier.

-Avion est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Avion n’est pas décomposable.

Relation Propriétaire :

IdProp 🡪 nomProp, adresse, type, numéro de téléphone

-Pas de redondances

 Graphe minimum :

IdProp

nomProp
adresse type numéro de téléphone
Identifiant : IdProp

 Forme normale :
-Propriétaire est en 1FN car les attributs sont simples et monovalués.
-Propriétaire est en 2FN car tous les attributs décrivent la relation.

-Propriétaire est en 3FN car la profondeur est 1.

-Propriétaire est en FNBC car toute source complète de DF est un identifiant entier.

-Propriétaire est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Propriétaire n’est pas décomposable.

Relation Type d’Avion :

NomTyp🡪 nom du construction, puissance de moteur, nombre de places

-Pas de redondances

 Graphe minimum :

nomTyp

Nom du Puissance Nombres de

constructeur de moteur places

Identifiant : nomTyp

 Forme normale :
-Type d’avion est en 1FN car les attributs sont simples et monovalués.

-Type d’avion est en 2FN car tous les attributs décrivent la relation.

-Type d’avion est en 3FN car la profondeur est 1.

-Type d’avion est en FNBC car toute source complète de DF est un identifiant entier.

-Type d’avion est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Type d’avion n’est pas décomposable.

Relation Pilote :

IdPL🡪 nomPL, adresse, numéro de téléphone, numéro du brevet

-Pas de redondances
  Graphe minimum :

IdPL

nomPL
adresse numéro du numéro de téléphone
brevet
Identifiant : IdPL

 Forme normale :
-Pilote est en 1FN car les attributs sont simples et monovalués.

-Pilote est en 2FN car tous les attributs décrivent la relation.

-Pilote est en 3FN car la profondeur est 1.

-Pilote est en FNBC car toute source complète de DF est un identifiant entier.

-Pilote est en 4FN car elle ne contient de dépendance multivaluée(DM).

-Pilote n’est pas décomposable.

Relation Mécanicien :

IdMec🡪 nom_Mec, adresse, numéro de téléphone

-Pas de redondances

 Graphe minimum :

IdMec

adresse numéro de téléphone

nom_Mec
Identifiant : IdMec

 Forme normale :
-Mécanicien est en 1FN car les attributs sont simples et monovalués.
-Mécanicien est en 2FN car tous les attributs décrivent la relation.

-Mécanicien est en 3FN car la profondeur est 1.

-Mécanicien est en FNBC car toute source complète de DF est un identifiant entier.

-Mécanicien est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Mécanicien n’est pas décomposable.

Relation Habilitation :

nomTyp IdMec

-Pas de redondances

 Graphe minimum :

nomTyp IdMec

Identifiant : nomTyp

Nom_Mec

 Forme normale :
-Habilitation est en 1FN car les attributs sont simples et monovalués.

-Habilitation est en 2FN car tous les attributs décrivent la relation.

-Habilitation est en 3FN car la profondeur est 0.

-Habilitation est en FNBC car toute source complète de DF est un identifiant entier.

-Habilitation est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Habilitation n’est pas décomposable.

Relation Habilité :

(nomTyp, IdPL) 🡪 nombre total d’heures de vol

-Pas de redondances

 Graphe minimum :

nomTyp IdPL

Nombre total de vol

 Identifiant : (nomTyp, IdPL)

 Forme normale :
-Habilité est en 1FN car les attributs sont simples et monovalués.

-Habilité est en 2FN car tous les attributs décrivent la relation.

-Habilité est en 3FN car la profondeur est 1.

-Habilité est en FNBC car toute source complète de DF est un identifiant entier.

-Habilité est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Habilité n’est pas décomposable.

Relation Intervention_réparation :

(num_immatri, IdMec)🡪objet, date, durée

-Pas de redondances

 Graphe minimum :

Num_immatri IdMec

Nombre total de vol

Identifiant : (num_immatri, IdMec)

 Forme normale :
-Intervention_réparation est en 1FN car les attributs sont simples et monovalués

-Intervention_réparation est en 2FN car tous les attributs décrivent la relation

-Intervention_réparation est en 3FN car la profondeur est 1

-Intervention_réparation est en FNBC car toute source complète de DF est un identifiant

entier.

-Intervention_réparation est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Intervention_réparation n’est pas décomposable.

relation Intervention_vérification :

(num_immatri, IdMec, date)🡪objet, durée

-Pas de redondances
  Graphe minimum :

Num_immatri Date IdMec

objet durée

Identifiant : (num_immatri, IdMec,date)

 Forme normale :
-Intervention_vérification est en 1FN car les attributs sont simples et monovalués

-Intervention_vérification est en 2FN car tous les attributs décrivent la relation

-Intervention_vérification est en 3FN car la profondeur est 1

-Intervention_vérification est en FNBC car toute source complète de DF est un identifiant

entier.

-Intervention_vérification est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Intervention_vérification n’est pas décomposable.

relation Intervention_réparation :

(num_immatri, IdMec, date)🡪objet, durée

-Pas de redondances

 Graphe minimum :

Num_immatri Date IdMec

objet durée
Identifiant : (num_immatri, IdMec,date)

 Forme normale :
-Intervention_réparation est en 1FN car les attributs sont simples et monovalués

-Intervention_réparation est en 2FN car tous les attributs décrivent la relation

-Intervention_réparation est en 3FN car la profondeur est 1

-Intervention_réparation est en FNBC car toute source complète de DF est un identifiant

entier.

-Intervention_réparation est en 4FN car elle ne contient de dépendance multivaluée (DM).

-Intervention_réparation n’est pas décomposable.

4. Conclusion
Dans ce chapitre on a présenté les formes normales de chaque relation ainsi les graphes
minimums de dépendances.
 Chapitre 5 : Implémentation et requêtes SQL

1. Introduction :
Dans ce chapitre, on va présenter les tables de la BDD aéroport

2. Tables d’entités et relations :

Ci-dessous les tables implémentées dans la base de phpmyAdmin :

3. Requête SQL :
4. Conclusion :
Dans ce chapitre , on a présenté les tables et les relations et associations entre eux ainsi
que les requêtes proposées par l’énoncé. Ces requêtes plus généralisées seront par suite
codées et affichées dans une interface web.