Академический Документы
Профессиональный Документы
Культура Документы
COM
INFORMATIQUE
PROF.CORINE CAUVET
1/ Sujet du module
A. Définition
B. Historique
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 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
COURSDECO.BLOGSPOT.COM
2/ Objectif du cours
3/ Contenu du cours
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
AVION
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.
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.
AVION COMMANDANT
Numav Numcom
Typeav Nomcom
… …
VOL
VOL-REALISE
Villedep
Numvol, datevol
Numvol
…
jvol
Numav
Numvol
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é, …).
5ième solution :
PERSONNE (nopers, adrpers, nompers)
ACHAT (noimmat, nopers, date-achat, prix-achat)
VOITURE1 (noimmat, type, couleur)
VOITURE2 (type, marque, puissance)
Ceci est une bonne base de données.
1/ Introduction
La normalisation est basée sur ce principe de décomposition (on casse en plusieurs tables).
Relation unique
(Mauvaise qualité)
2/ La Normalisation
a. Définition
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.
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.
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.
COURSDECO.BLOGSPOT.COM
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
Noimmat . Couleur
Type .
Marque Puissance
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)
COURSDECO.BLOGSPOT.COM
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é.
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.
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.
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).
COURSDECO.BLOGSPOT.COM
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).
3/ Méthode de Normalisation
I. Principe de la Démarche
Structure Base de
Normalisé Requêtes,
Données interrogation
de la base
de données de la base de
données
Le travail de Conception :
Les besoins dont on a besoin sont flous, incomplets, ambigus Structure de Base de données
complet, structuré et formel.
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.
B. Exemple
C. Quelques principes
Abonnés Livre
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.
b. Exemple
c. Convention graphique
Abonnés
…
…
…
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
Règle 3 : Règle d’identification : Tout objet de gestion doit posséder au moins un identifiant
(clé primaire).
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
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
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
COURSDECO.BLOGSPOT.COM
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.
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
Cf objet de gestion
Voir illustration 3
Voir illustration 4
Cas particulier n° 1 : Les associations peuvent être définies entre plus de deux objets de
gestion (dimension > 2).
Voir Illustration 5
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
Voir illustration 11
Voir illustration 12
E. Notions complémentaires
A. Construction du MCD
B. Validation du MCD
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.
Voir illustration 16
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.
Voir illustration 17
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
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 illustration 2
(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).
Donc elle est (0,1) d’un coté et (0,n) ou (1,n) ou encore (0,1) de l’autre coté.
La solution S1 peut comporter des valeurs nulles (champs non renseignés) au niveau du
champ noproj dans EMPLOYE.
Voir illustration 7
Voir illustration 8
Voir illustration 9
Voir illustration 10
Voir illustration 11
Voir illustration 12
• 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
COURSDECO.BLOGSPOT.COM