Informatique L3

COURSDECO.BLOGSPOT.
COM
INFORMATIQUE
PROF.CORINE CAUVET
La conception de bases de données
CHAPITRE INTRODUCTIF : INTRODUCTION AUX MODULES
1/ Sujet du module
A. Définition
On va s’intéresser à la notion de bases de données.

Une base de donné comporte trois définitions correspondant à trois points de vues :
- Elles sont au cœur des applications informatiques. Elles sont utilisées comme
technique de mémorisation et de gestion des données de l’entreprise.
- Une base de données est une image de l’organisation qu’elle sert. Elle est au service
d’une organisation. On trouve l’ensemble des informations sur son organisation
(passé, présente, …).
- C’est un noyau stratégique dans l’architecture du système informatique de
l’organisation.
B. Historique
Schématiquement, l’histoire des systèmes informatiques dans les organisations comportent

trois grandes générations :
- avant les bases de données (avant les années 70) : architecture des systèmes
informatiques : c’est une succession de programme, une chaine de traitement. Les
données sont mémorisées dans des fichiers. Mais cela donne de la redondance de
données, car elle est présente dans plusieurs fichiers qui entrainent de la redondance.
Les accès aux données sont difficiles pour les utilisateurs.
Saisie
Contrôle
Fichier 1 Fichier 2
Traitement
Edition Document
COURSDECO.BLOGSPOT.COM
- Arrivée des bases de données (année 80, 90, 2000) : c’est l’intégration de toutes les
données présentes dans les fichiers précédant. Il y a un accès s’simplifier à la base de
données pour les utilisateurs.
Traitement 1
Document 1 Base de données

Gestionnaire
utilisateur (requête
avec langage
d’interrogation)
Traitement 2
Document 2
- Après les bases de données (après 2000) : un réseau permet que plusieurs bases de
données puissent communiquer.
Ce système informatique est réparti ou distribué, il est hétérogène (plusieurs système
de base de données différentes) car le matériel et les logiciels sont différents. Ce
système est aussi ouvert vers l’extérieur grâce aux internautes.
C. Problématique du module
Organisation
Quelles informations ?
Conception
de la base
de données
Structure
de la base
de données
Réalisation
de la base Base de
de données données
On utilise le terme de maitrise d’ouvrage et de maitrise d’œuvre.

La structure de base de données est une partie du cahier des charges qui répond à l’expression
d’une partie des besoins.
2/ Objectif du cours
- Apprendre à concevoir une base de données selon une démarche méthodologique.

- Apprendre à formaliser ses besoins en information au sein d’une organisation.
3/ Contenu du cours
Chapitre 1 : Rappels des principales notions en bases de données
Chapitre 2 : Normalisation d’une base de données
Chapitre 3 : Démarche méthodologique pour concevoir une base de données.
Chapitre 4 : Etape conceptuelle
Chapitre 5 : Etape Logique

CHAPITRE 1 : RAPPELS DES PRINCIPALES NOTIONS DE BASES DE DONNÉES
1/ Base de données, table, champ, clé primaire et liens entre tables
A. Base de données
C’est une collection de données organisées en tables. La base de données compagnie aérienne
contient par exemple la table avion, la table vol, …
B. Notion de table
Une table contient un ensemble d’objet de même nature.

Elle a une structure et un contenu.
Considérons la table AVION :
AVION
Noavion Typeavion Nbhvol

1 Airbus 380 1030
2 Boeing 747 130
La structure est un ensemble de champ ou d’attribut.

Le contenu est un ensemble de n-upllet ou d’enregistrement.
Notation : la table AVION sera noté par : AVION (Noavion, Typeavion, Nbhvol).
Un champ a toujours un format ou un type.
C. Notion de Clef Primaire
Une table a obligatoirement une clef primaire. C’est un champ particulier qui ne peut pas
avoir de double et doit être forcément renseigner (pas de valeur nulle).
Notation : on souligne la clef primaire.
Une clef primaire peut être composée de plusieurs champs.
Exemple : VOL-CATALOGUE (numvol, villedep, villear, hdep, har, jvol)

VOL-REALISE (numvol, datevol, hdep, har,…)
D. Lien entre table
Certains champs sont communs à plusieurs tables.
Exemple : COMMANDANT (numcom, nomcom, adrcom, telcom)

AVION (numav, typeav, nbhav)
VOL-CATALOGUE (numvol, villedep, villear, hdep, har, jvol)
VOL-REALISE (numvol, datevol, hdep, har,…, numav, numcom)
Numav et numcom sont des clef étrangères.
Une clef étrangères signifie que les valeurs du champ doit être compris dans la table ou ce
champ est clef primaire. Les valeurs du champ de la clef étrangère dans la table doivent
exister dans une autre table.
Notation : la plus usuelle est le dièse.
Cas particuliers de clefs étrangères :

- DEPARTEMENT (nodep, budgetdep, nodir)
EMPLOYE (noemp, nomemp, salaire, nodep)
Les deux champs nodir et noemp n’ont pas forcément le même nom.
Nodir est une clef étrangère.ses valeurs doivent exister dans la table EMPLOYE.
- EMPLOYE (noemp, nomemp, salaire, noresp)
Noresp est une clef étrangère, ses valeurs doivent existé comme valeur du champ
noemp.
E. Représentation Graphique d’une Base de données
AVION COMMANDANT
Numav Numcom
Typeav Nomcom
… …
VOL
VOL-REALISE
Villedep
Numvol, datevol
Numvol
…
jvol
Numav
Numvol
Les clefs étrangères sont représentées par des flèches.
2/ Bonnes et mauvaises bases de données
Considérons l’application suivante : On étudie un bureau d’immatriculation de voiture qui

gère des achats de voitures par des personnes.
 1ère solution : on réalise une base de données constituée d’une seule table dans lequel on
met toutes les informations.
ACHATS (nopers, nompers, adrpers, noimmat, type, puissance, marque, couleur, date-achat,
prix-achat).
Commentaire : Cette base de données est de mauvaise qualité car :
- Il y a redondance des informations (pour une personne qui achète 20 voitures, on
répète 20 fois son nom et son adresse).
- Cette table peut contenir des valeurs nulles (trou, champ non renseigné, …).
 2ième solution : On réalise une base de données avec deux tables.

PERSONNE (nopers, adrpers, nompers)

VOITURE (noimmat, type, couleur, marque, puissance)
Commentaires : On a perdu des informations (date-achat, prix-achat), en effet on a perdu les
informations sur les achats des voitures par les personnes.
 3ième solution : On réalise une base de données avec trois tables.

VOITURE (noimmat, type, couleur, marque, puissance)
ACHAT (noimmat, nopers, date-achat, prix-achat)
Commentaire : Cette base de données n’est toujours pas de bonne qualité, elle souffre d’un
problème de redondance (en effet, si le bureau d’immatriculation gère 25 R5 TS, on répète 25
fois 5CV et Renault).
 4ième solution : On réalise une base de données avec 4 tables.

VOITURE1 (noimmat, type, puissance)
VOITURE2 (type, marque, couleur)
Commentaires : Cette structure est de mauvaise qualité car on a perdu la couleur des voitures.
 5ième solution :
VOITURE1 (noimmat, type, couleur)
VOITURE2 (type, marque, puissance)
Ceci est une bonne base de données.
Conclusion : il est nécessaire de disposer d’une démarche méthodologique pour concevoir

une base de données de qualité. On ne peut pas utiliser notre instinct.
CHAPITRE 2 : NORMALISATION DE BASES DE DONNÉES

Normaliser consiste à rendre une base de données de bonne qualité.
1/ Introduction
A. Démarche d’élaboration d’une structure de base de données
Structure Brute (de mauvaise

Construction
qualité
Normalisation Structure de qualité (sans

redondance et sans perte
d’information)
Optimisation On obtient une structure

optimisée (dont ayant de
meilleure temps de réponse
pour les requêtes des
utilisateurs)
B. L’approche par décomposition
La normalisation est basée sur ce principe de décomposition (on casse en plusieurs tables).
Relation unique
(Mauvaise qualité)
Relation 1 Relation 2 Relation 3 Relation 4
Deux difficultés dans l’approche de cette manœuvre :

- Comment décomposer ? Pour traiter ce problème, on va utiliser la notion de
dépendance fonctionnelle.
- Jusqu’ou décomposer ? Pour traiter ce problème, on va utiliser la notion de forme
normale au nombre de trois. Il en existe trois, dont la meilleure est la troisième.
2/ La Normalisation
A. Notion de dépendance Fonctionnelle (DF)

a. Définition
Soit une relation R (A1, A2, …, An).

On dit qu’il existe une dépendance fonctionnelle de X vers Y (on note X  Y) si et seulement
si à toute valeur de X correspond une et une seule valeur de Y. X et Y sont des sous-
ensembles de l’ensemble des attributs (A1, A2, …, An).
La notion de dépendance fonctionnelle est définie entre des champs, et non entre des tables.
En revanche, on peut dire que le champ X est en relation fonctionnelle avec Y.
Exemples : on s’intéresse qu’à des voitures qui sont d’une seule couleur.
Noimmat  type
Noimmat  couleur
Noss  nom
Noimmat, type couleur
Contre exemples :
Couleur  noimmat (faux)
Nom  noss (faux)
La notion de dépendance fonctionnelle est sémantique, car aucun outil ne peut nous aider à
trouver cela, elle ne peut être trouvé par hasard, et seulement par nous même.
b. Notion de dépendance fonctionnelle élémentaire
La dépendance fonctionnelle X  Y est élémentaire si et seulement si il n’existe pas de X’

inclus dans X tel que X’  Y.
Exemple :
Noimmat  type
Noemp, datesal  salaire : on souhaite avoir dans la base de données l’historique des salaires
des employés.
Contre exemples :
Noimmat, type  couleur : Le type ne sert à rien, car si on l’enlève, la dépendance
fonctionnelle est conservée, donc cette dépendance fonctionnelle n’est pas élémentaire.
c. Notion de dépendance fonctionnelle directe
La dépendance fonctionnelle X  Z est directe si et seulement si il n’existe pas d’attribut Y

tel que X  Y et Y  Z.
Exemples :
Noimmat  type
Type  puissance
Contre exemples :
Noimmat  puissance mais on peut avoir : noimmat  type  puissance. Cette dépendance
est non directe, car on peut passer par un autre attribut. Elle est donc redondante.
d. Graphe des dépendances fonctionnelles
Les nœuds de ce graphe sont des champs de la table, représenté par un point.
Entre les nœuds, les arcs sont les dépendances fonctionnelles.
Exemple :
Type . Puissance
Marque
Noimmat . couleur
Cas particulier : comment représenter par un graphe cette représentation suivante ?

Noemp  (deux flèches relier par un point)  salaire
Datsal 
Noemp  (deux flèches avec une barre)  salaire

Datsal 
Noimmat . Couleur
Type .
Marque Puissance
Voir feuille sur les graphes.
B. Les Formes Normales
Cette notion de forme normale s’applique à des tables, et non à des champs. Elles permettent
de caractériser la qualité d’une table.
Il existe trois formes normales :
- première forme normale (1FN)
- deuxième forme normale (2FN)

- troisième forme normale (3FN)
La troisième forme normale correspond à la meilleure qualité.
a. Première Forme Normale
Définition : Une relation R est en première forme normale (1FN) si sa clef primaire est en
dépendance fonctionnelle avec tous les autres attributs de cette table.
R (K, att1, att2, …, attn). Cette table ne peut avoir de trou. A toute valeur de K correspond
une et une seule valeur d’att1, les champs sont forcément renseigner (pas de valeur nulle).
Une telle table est une table qui n’a pas de valeur nulle.
Cette table n’a pas de champ de multi-valué.
Contre exemple : on imagine les tables suivantes :

PERSONNE (noss, nom, prénoms)
A un numéro de sécurité sociale correspond plusieurs prénoms. Elle n’est donc pas en
première forme normale car il n’y a pas de dépendance fonctionnelle entre noss et prénoms.
Exemple : on imagine la table suivante :

EMPLOYE (noemp, datechgsala, nomemp, salaire). C’est une table qu’il mémorise
l’historique des salaires de l’employé.
Cette table est en première forme normale mais pourtant elle n’est pas satisfaisante, car on
répète le même nom d’employé chaque fois que cet employé change de salaire.
b. Deuxième Forme Normale
Définition : Une relation R est en deuxième forme normale (2FN) si sa clef est en dépendance
fonctionnelle élémentaire avec tous ses autres attributs.
R (K1, att1, att2, …, attn). Il faut que sa clef primaire soit en dépendance fonctionnelle
élémentaire, c'est-à-dire qu’on ne peut enlever aucun attribut.
Contre exemple : EMPLOYE (noemp, datechgsala, nomemp, salaire). Il y a une dépendance

fonctionnelle entre sa clef primaire est le nom de l’employé qui n’est pas élémentaire.
Pour la mettre en deuxième forme normale, on fait le graphe des dépendances fonctionnelles
pour les attributs de cette table.
Voir graphe 2 sur feuille
Les deux tables construites sont en deuxième formes normales.
Exemple : VOITURE (noimmat, type, marque, puissance, couleur). Cette table est en
deuxième forme normale, mais elle n’est pas satisfaisante, car elle contient de la redondance
entre type, marque et puissance (si on gère 25 voiture de type R5TS, on répète 25 fois Renault
et 5 CHV). On ne peut pas s’arrêter sur la deuxième forme normale.
c. Troisième Forme Normale
Définition : Une relation R est dite en troisième forme normale (3FN) si sa clef primaire est
en dépendance fonctionnelle élémentaire directe avec ses autres attributs.
R (K3, att1, …, attn).
Contre exemple : VOITURE (noimmat, type, marque, puissance, couleur). Cette table n’est
pas en troisième forme normale car la dépendance fonctionnelle noimmat  puissance n’est
pas directe, car il existe un autre chemin pour aller à la puissance en passant par le type
(noimmat  type  puissance).
La dépendance fonctionnelle noimmat  marque n’est pas directe, car on peut passer par type
(noimmat  type  marque).
Construisons le graphe des dépendances fonctionnelles pour les attributs de la table

VOITURE.
Voir graphe 3 de la feuille
Il en résulte deux tables :

VOITURE (noimmat, type, couleur)
MODELEVOITURE (type, marque, puissance)
Ces deux tables sont en troisième forme normale, car elle résultat de dépendance
fonctionnelle élémentaire et directe.
3/ Méthode de Normalisation
A. Comment construire une base de données de qualité ?
 Il faut construire le graphe des dépendances fonctionnelles élémentaires et directes.

 Partitionner le graphe obtenu en groupes. On prend un nœud source de dépendance
fonctionnelle, et mettre dans ce groupe tous les attributs qui correspondent à ce nœud source.
 Produire pour chaque groupe obtenu à l’issu de l’étape 2, une relation.
R1 (A1, A2, A7, A5)
R2 (A2, A6)
R3 (A5, A8)
R4 (A5, A3, A4)
Ces 4 tables sont en troisième forme normale.
CHAPITRE 3 : DÉMARCHE GÉNÉRALE DE CONCEPTION D’UNE BASE DE DONNÉES
I. Principe de la Démarche
Conception Réalisation Exploitation
Structure Base de
Normalisé Requêtes,
Données interrogation
de la base
de données de la base de
données
Nous, on s’intéresse à la Conception.
Le travail de Conception :
Les besoins dont on a besoin sont flous, incomplets, ambigus  Structure de Base de données
complet, structuré et formel.
II. Les Etapes de la conception et ses résultats
La démarche de conception proposée comporte trois étapes :
Quelles Etape Modèle conceptuel

informations ? conceptuelle de données (MCD)
Comment Modèle logique de

Etape logique
représenter ces données (MLD)
informations dans (Cf représentation
des relations ? graphique d’une
base de données)
Comment Modèle physique de

Etape physique
implémenter données (MPD)
ces tables (cf représentation
avec un GBD graphique d’une
particulier ? base de données
dans accès
III. Les outils de la conception

La démarche proposée permet un découpage du travail de conception :

- séparer les différentes problématiques de la conception
- le niveau conceptuel constitue une expression des besoins en informations
- le niveau conceptuel constitue une base de dialogue entre utilisateurs et informaticiens
- le niveau conceptuel constitue une référence durable (invariante) des besoins au regard
de la technique
CHAPITRE 4 : L’ETAPE CONCEPTUELLE
I. Introduction
A. La Problématique
Il s’agit d’exprimer l’ensemble des informations que l’on veut prendre en compte dans la
future Base de Données.
Cette étape est basée sur le formalisme de description. Ce formalisme est associé à une
représentation graphique.
Le résultat de cette étape est un MCD (modèle conceptuel de données), qui doit être cohérent,
complet, fidèle et normalisé.
Ce résultat est indépendant de toutes considérations techniques ou organisationnelles.
Exemple : Besoin d’une bibliothèque : De quelles informations ai-je besoin ?
B. Exemple
Les livres avec leur référence, leur titre, leur auteur, …

Les abonnés avec leur nom, leur prénom, leur adresse, …
Les emprunts de livre des abonnés, …
Livre, abonnés  Objet de gestion (référence, titre, nom, prénom, …)

 Propriétés ou caractéristiques
Emprunts  Association d’objet de gestion
C. Quelques principes
Dans un MCD, on représente des types (population en classe d’objet).

Exemple : La classe des livres, les abonnées, …
Les principales notions utilisées sont :

- la notion d’objet de gestion
- la notion de propriété ou caractéristique
- la notion d’association entre objets de gestion
- la notion de contrainte
On utilise un formalisme graphique :
Abonnés Livre
Nom Emprunte Référence

Prénom nom auteur
Adresse titre
II. Les concepts et les règles d’utilisations

A. Le concept d’objet de gestion
a. Définition
C’est une représentation d’un ensemble d’objets, de même nature, abstraits ou concret et
présentant un intérêt.
Terminologie : entité-type ou type entité.
b. Exemple
L’objet de gestion : abonné

L’objet de gestion : compte bancaire
c. Convention graphique
Abonnés
…
…
…
d. Règles d’utilisation de ce concept
Règle 1 : Règle de pertinence : Seuls les objets ayant un intérêt doivent être représentés dans
le MCD.
Voir illustration 1
Règle 2 : Règle de caractérisation : Tout objet de gestion doit être décrit par des propriétés.
Abonnées
Nom
Prénom
Adresse
Les propriétés prennent des valeurs.

Ils existent trois types de propriétés :
- propriétés signalétiques : il s’agit de propriété qui caractérise de manière intrinsèque
les objets : nom, coordonnées, …
- les variables d’états : il s’agit de propriété qui expriment de manière synthétique la
situation des objets au cours de leur évolution (exemple : une formation, ouvert,
fermé)
- les variables d’analyses : il s’agit de propriétés que l’on veut suivre (exemple : l’objet
de gestion formation pourrait être décrit avec la propriété nombre d’inscrit)
Règle 3 : Règle d’identification : Tout objet de gestion doit posséder au moins un identifiant
(clé primaire).
Rappel sur la notion d’identifiant : c’est une propriété qui vérifie :

- l’unicité
- la minimalité
- la stabilité
- qui est renseigné
Un objet de gestion peut avoir plusieurs identifiants.
Règle 4 : Règle de la non répétitivité : Chaque propriété d’un objet de gestion ne peut avoir
qu’une seule valeur.
Exemple :
Abonné
Noabo
Nomabo
Emprunt
Il ne peut y avoir l’attribut emprunt car il y a plusieurs emprunts.
Règle 5 : Règle d’homogénéité : Chaque propriété d’un objet de gestion doit être renseignée
pour tous les objets de la population renseignée.
Contre exemple :
Véhicule-assuré
Noimma
Puissance
Poids
Les caravanes n’ont pas de puissance.
Exemple :
Voiture
Caravane
Noimma
Noimma
Puissance
Poids
Poids
Moteur
B. Le concept d’association
Les objets de gestions ne sont pas indépendant les uns des autres
a. Définition
C’est une représentation d’un ensemble d’association de même nature en deux (ou plusieurs)
objet de gestion ayant un intérêt.
Terminologie : association type, relation type
b. Convention graphique
Voir illustration 2
On appelle Dimension d’une association type le nombre d’objet de gestion participant à cette
association.
c. Règles d’utilisations
Règle 1 : Règle de caractérisation : Les associations types peuvent avoir des propriétés.
Voir illustration 3
Règle 2 : La Règle de non répétitivité et la règle d’homogénéité s’appliquent sur les

associations.
Cf objet de gestion
Règle 3 : Règle d’identification : Une association a pour identifiant la composition des

identifiants des objets de gestions qu’elle relie.
Exemple : Entre Abonné et Livre, il y a l’association : emprunte.
Voir illustration 3
L’identifiant de l’association « emprunte » est le n° d’abonné et la référence.

Il y a problème si l’abonné emprunte plusieurs fois le même livre.
Attention : Si on conserve la bibliographie, cette solution est fausse car l’identifiant de

l’association est faux ici.
La solution correcte est :
Voir illustration 4
d. Ces particuliers d’associations
Cas particulier n° 1 : Les associations peuvent être définies entre plus de deux objets de
gestion (dimension > 2).
Voir Illustration 5
Remarque : C’est une association ternaire.

On suppose la règle de gestion suivante : Tous les cours relatifs à une même matière et
assurés par un même enseignant sont donnés dans une même salle.
Remarque : Les associations ternaires ne peuvent pas être remplacées par deux associations
binaires car il y a perte d’information.
Cas particulier n° 2 : Entre deux objets de gestions, il peut exister plusieurs associations
différentes.
Voir illustration 6
Cas particulier n° 3 : Un même objet de gestion peut apparaître plusieurs fois dans une
association.
Voir illustration 7
C. La notion de spécialisation
Voir illustration 8
Attention : Ne marche pas pour, par exemple, la voiture jaune et rouge que s’il y a un type de
propriétés différentes.
Remarque : Le nombre de niveau peut être quelconque : on pourrait spécialiser les clients
réguliers.
Remarque : Le nombre d’objet de gestion spécialisé est quelconque (exemple de 4 sous
classes).
Remarque : On peut spécialiser un même objet de gestion sur plusieurs critères.
Voir illustration 9
D. Les contraintes
Il s’agit d’apporter des précisions au MCD : Il existe plusieurs types de contraintes.
a. Les cardinalités d’une association
Considérons l’association suivante : Voir illustration 10

Remarque : Une cardinalité est composé de deux éléments :
- le cardinalité minimale
- la cardinalité maximale
Remarque : Notation : card min, card max
Remarque : Soit a,b : en pratique, le a prend les valeurs 0 ou 1 et le b prend les valeurs 1 ou n.
Voir illustration 11
Pour la cardinalité maximale de commande : selon si la commande et mono produit ou multi

produit.
Pour la cardinalité 1,1 de produit : contexte de fabrication à la commande.
Rôle des cardinalités :

- les cardinalités permettent de préciser la définition des objets de gestions
- les cardinalités utilisées pour transformer le MCD en une structure de BDD.
b. Les contraintes sur spécialisation
E. Notions complémentaires
 Identifiant relatif : Voir illustration 13
NB : S’il y a un identifiant relatif, alors la cardinalité est de (1,1).
 Représentation du temps dans un MCD :

- Propriétés à valeurs calendaires : Voir illustration 14
- Séries chronologiques :
Exemple : représenter le chiffre d’affaire des clients mois par mois ou la température
quotidienne d’une ville ou la vente mensuelle d’un produit.
Voir Illustration 15
- Représentation d’un historique de propriété : exemple de l’historique salaire des
employés
III. La démarche de construction du MCD
Elle comporte les étapes suivantes
A. Construction du MCD
Il s’agit de trouver les objets de gestions ou associations et d’indiquer les contraintes.
B. Validation du MCD
Il s’agit d’appliquer les règles d’utilisation des concepts.
C. Spécification du MCD
Il s’agit de compléter la représentation graphique par une description textuelle définissant les
objets de gestions, les associations et les propriétés.
D. Quantification du MCD
Il s’agit de préciser la taille des propriétés, le nombre d’objet représenté par un objet de
gestion et la cardinalité n lorsqu’elle est connue.
Illustration du Chapitre 4 : Enoncé
(1) étatdem peut prendre les valeurs :

- acceptée
- en attente
- refusée
Nouvelle hypothèse : On suppose que les saisons varient en fonction des stations. Que fait t’il
modifier ?
Ici les saisons sont les mêmes pour toutes les stations.
Hypothèse : On suppose que le demandeur n’est pas le client.
MCD : modèle conceptuel de données

A retenir : objet de gestion : CLIENT
Propriété : numcli, nomcli, …
Association : Pour
CHAPITRE 5 : L’ÉTAPE LOGIQUE
I. Introduction
A. Problématique
Il s’agit de construire une structure de BDD (appelée MLD : modèle logique de données).
Cette structure de BDD décrit l’organisation des données en table.
Cette structure s’obtient en transformant le MCD.
Il ne s’agit pas d’enrichir le contenu informationnel du MCD.
Cette étape utilise le MCD.
B. Introduction
Voir Illustration 1
C. L’approche
MCD
Objet de gestion
Propriété, association
Structure déspécialisée
Cardinalités
MLD
Table
Attributs, champs
Clés primaires
Clés étrangères
On applique un ensemble de règle de transformation.
II. Les règles de transformation du MCD en une base de données
Les règles doivent être appliquées selon l’ordre de la présentation
A. Règle de Transformation des objets de gestions
Tout objet de gestion est transformé en une table. Les propriétés de l’objet de gestion
deviennent les attributs de la table.
L’identifiant de l’objet de gestion devient la clef primaire de la table nouvellement créée.
Voir exemple d’illustration 1
Cas particulier : L’identifiant de l’objet de gestion est un identifiant relatif.
Voir illustration 2
B. Règles de transformation des associations

a. Cas des associations binaires et (1,1) d’un coté
(1,1) = l’association va avoir une cardinalité (1,1) d’un coté et (0,n) de l’autre., ou (1,1) ; (1,n)
ou encore (1,1) ; (0,n).
Considérons le MCD suivant : Voir illustration 3
Cas particulier : Considérons le fragment de MCD suivant : voir illustration 4
b. Cas des associations binaires et (0,1) d’un coté
Donc elle est (0,1) d’un coté et (0,n) ou (1,n) ou encore (0,1) de l’autre coté.
Considérons le MCD suivant : Voir illustration 5
La solution S1 peut comporter des valeurs nulles (champs non renseignés) au niveau du
champ noproj dans EMPLOYE.
Voir aussi l’illustration 6
c. Règle de transformation des associations binaires et (n,n) (ou n des deux

côtés)
C’est les cas suivant :

- (1,n) ; (1,n)
- (0,n) ; (0,n)
- (1,n) ; (0,n)
Voir illustration 7
On doit créer une nouvelle table.

C. Règle de transformation des associations ternaires (ou plus)
Voir illustration 8
Cas particulier d’association : Association Réflexive
Voir illustration 9
On applique la règle 1 et la règle 3 vu au dessus.
On applique la règle 1 et la règle 4.
D. Règle de transformation de la structure de spécialisation (règle 6)
III. La Démarche de Construction du MLD

Voir illustration du Chapitre 5 (Enoncé)

BONUS. FICHE DE RÉVISION
• Une TABLE - contient un ensemble d’objet de même nature

• La structure est un ensemble de champ ou d’attribut.
• Clef primaire - Une table a obligatoirement une clef primaire. C’est un champ
particulier qui ne peut pas avoir de double et doit être forcément renseigner (pas de
valeur nulle).peut être composé de plusieurs champs.
• Une clef étrangères signifie que les valeurs du champ doit être compris dans la table
ou ce champ est clef primaire.
• Normaliser une BD = consiste à rendre une base de données de bonne qualité
La notion de dépendance fonctionnelle est définie entre des champs, et non entre des tables.
En revanche, on peut dire que le champ X est en relation fonctionnelle avec Y. ex. Noimmat 
couleur vsex. Couleur noimmat
• La dépendance fonctionnelle X  Y est élémentaire si et seulement si il n’existe
pas de X’ inclus dans X tel que X’  Y. ex (Noemp, datesal  salaire pour
historique de salaire)
• La dépendance fonctionnelle X  Z est directe si et seulement si il n’existe pas
d’attribut Y tel que X  Y et Y  Z. ex (Numat  nomat) vsex. (numens
 numat ; numat  nomat)
• Les formes normales
Cette notion de forme normale s’applique à des tables, et non à des champs. Elles permettent
de caractériser la qualité d’une table.
Il existe trois formes normales :
- première forme normale (1FN)
- deuxième forme normale (2FN)
- troisième forme normale (3FN)
La troisième forme normale correspond à la meilleure qualité.
• 1FN = si sa clef primaire est en dépendance fonctionnelle avec
tous les autres attributs de cette table. EMPLOYE (noemp, datechgsala, nomemp, salaire).
• (2FN) si sa clef est en DF élémentaire avec tous ses autres
attributs.
Histosala( numemp, datechangesala,sala) Employe( numemp, nomemp)
• 3FN= DF élémentaire et direct avec ….
Voitre(noimat, type, couleur) Modèle (type, puissance, marque)
• Conception ( MCD)– Réalisation (MLD) – Exploitation d’une
BD (MphysiqueD)
• MCD
o Objet de gestion - une représentation d’un ensemble
d’objets, de même nature, abstraits ou concret et présentant un intérêt. (Terminologie :
entité-type)
o Règle d’identification : Une association a pour
identifiant la composition des identifiants des objets de gestions qu’elle relie. ex : Entre
Abonné et Livre, il y a l’association : emprunte.
o Règle de non répétitivité – chaque propriété d’un objet
de gestion ne peut avoir qu’une seule valeur.
o Rôle des cardinalités :
- les cardinalités permettent de préciser la définition des objets de gestions
- les cardinalités utilisées pour transformer le MCD en une structure de BDD.
Construire un MCD :
1) Trouver les objets de gestion
• MLD - décrit l’organisation des données en table. On utilise le MCD

R1. tous objets de gestion –» tables
R2. binaire (1,1) de côté de 1,1 –» ajouter clé primaire comme une clé étranger.
R3. (0,1) –» ajouter de l’autre côté
R4. (n,n) (ou n des deux côtés) –» créer une table (cléprim1, cléprim2, attribut)
R5. Ternaire –» créer une table (cléprim1, cléprim2, cléprim3, attribut)
Association père-fils : 1 fils peut avoir qu’un père, un père peut avoir plusieurs fils.
Association réflexive : Association entre une entité et elle-même
T (TOTALITÉ) : les éléments appartient au moins à une entité spécialisée.
Un salarié peut être à la fois commercial et technicien dans une entreprise (non disjonction). Il est
au moins l’un ou l’autre
X (EXCLUSION) : les éléments d’une entité spécialisée n’appartient qu’à elle et à aucune
autre.
Ex. Un bien locatif est soit un garage, soit un appartement (il n’est pas les deux), mais il peut
exister d’autres types de biens locatifs.
XT (+): un élément appartient à la une où à l’autre, jamais aux deux simultanément. Ex. Un
propriétaire est soit une PP, soit une SCI (il n’est pas les deux).
BONUS : Il existe aussi des contraintes d’égalité, d’unicité

Informatique L3

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Informatique L3

Hochgeladen von

Copyright:

Verfügbare Formate

COURSDECO.BLOGSPOT.

La conception de bases de données

CHAPITRE INTRODUCTIF : INTRODUCTION AUX MODULES

On va s’intéresser à la notion de bases de données.

Schématiquement, l’histoire des systèmes informatiques dans les organisations comportent

Document 1 Base de données

On utilise le terme de maitrise d’ouvrage et de maitrise d’œuvre.

- Apprendre à concevoir une base de données selon une démarche méthodologique.

Chapitre 1 : Rappels des principales notions en bases de données

Chapitre 2 : Normalisation d’une base de données

Chapitre 3 : Démarche méthodologique pour concevoir une base de données.

Chapitre 4 : Etape conceptuelle

Chapitre 5 : Etape Logique

CHAPITRE 1 : RAPPELS DES PRINCIPALES NOTIONS DE BASES DE DONNÉES

1/ Base de données, table, champ, clé primaire et liens entre tables

Une table contient un ensemble d’objet de même nature.

Noavion Typeavion Nbhvol

La structure est un ensemble de champ ou d’attribut.

C. Notion de Clef Primaire

Exemple : VOL-CATALOGUE (numvol, villedep, villear, hdep, har, jvol)

D. Lien entre table

Certains champs sont communs à plusieurs tables.

Exemple : COMMANDANT (numcom, nomcom, adrcom, telcom)

Cas particuliers de clefs étrangères :

E. Représentation Graphique d’une Base de données

Les clefs étrangères sont représentées par des flèches.

2/ Bonnes et mauvaises bases de données

Considérons l’application suivante : On étudie un bureau d’immatriculation de voiture qui

 2ième solution : On réalise une base de données avec deux tables.

PERSONNE (nopers, adrpers, nompers)

 3ième solution : On réalise une base de données avec trois tables.

 4ième solution : On réalise une base de données avec 4 tables.

Conclusion : il est nécessaire de disposer d’une démarche méthodologique pour concevoir

CHAPITRE 2 : NORMALISATION DE BASES DE DONNÉES

Normaliser consiste à rendre une base de données de bonne qualité.

A. Démarche d’élaboration d’une structure de base de données

Structure Brute (de mauvaise

Normalisation Structure de qualité (sans

Optimisation On obtient une structure

B. L’approche par décomposition

Relation 1 Relation 2 Relation 3 Relation 4

Deux difficultés dans l’approche de cette manœuvre :

A. Notion de dépendance Fonctionnelle (DF)

Soit une relation R (A1, A2, …, An).

b. Notion de dépendance fonctionnelle élémentaire

La dépendance fonctionnelle X  Y est élémentaire si et seulement si il n’existe pas de X’

c. Notion de dépendance fonctionnelle directe

La dépendance fonctionnelle X  Z est directe si et seulement si il n’existe pas d’attribut Y

d. Graphe des dépendances fonctionnelles

Cas particulier : comment représenter par un graphe cette représentation suivante ?

Noemp  (deux flèches avec une barre)  salaire

Voir feuille sur les graphes.

B. Les Formes Normales

- deuxième forme normale (2FN)

a. Première Forme Normale

Contre exemple : on imagine les tables suivantes :

Exemple : on imagine la table suivante :

b. Deuxième Forme Normale

Contre exemple : EMPLOYE (noemp, datechgsala, nomemp, salaire). Il y a une dépendance

Voir graphe 2 sur feuille

Les deux tables construites sont en deuxième formes normales.

c. Troisième Forme Normale

Construisons le graphe des dépendances fonctionnelles pour les attributs de la table

Voir graphe 3 de la feuille