Chapitre 1:
MODELISATION DES BASES DE DONNEES
3ème Année Ingénieur
Semestre: S5
Ecole Supérieure
Département en Informatique
d’Informatique
Plan
• I. Concepts de base de la modélisation
Conception de bases de données
Cycle de vie
Le Modèle Conceptuel EA
Le Modèle EAE
• II. Modélisation des Contraintes d’Intégrité
Définition et Formalisation
CI sur les Attributs
CI d'intégrité sur les cardinalités
CI d'intégrité sur les généralisations/spécialisations
I. Concepts de base de la modélisation (UML et Entité
Association)
La conception de base de données
Phase nécessaire à la création de la base de données.
Consensus sur le découpage du processus de construction de la base au
vu des objectifs.
Problème :Beaucoup de bases ont été développées sans méthode.
Conséquences
Sous estimation du temps ou des ressources nécessaires
pour le projet
Développement de Bases de données inadéquates et
inefficaces.
Documentation limitée.
Maintenance difficile.
Méthodologie : Cycle de vie de Bases de données
Un processus complexe qui implique des décisions à différents niveaux.
(Après avoir décomposé le problème en sous-problèmes à résoudre
indépendamment en utilisant des méthodes et des techniques spécifiques) :
Niveau (ou Schéma )conceptuel : description de haut niveau de la
structure de la base de données : décrit le contenu en information et non
les structures de stockage
Niveau (ou Schéma )logique : description de la structure de la base de
données qui puisse être comprise par le SGBD (Système de Gestion de Bases
de Données) : dépend du modèle logique choisi (relationnel, objet ou XML)
Niveau (ou Schéma )physique : description de l'implantation de la Base
de Données en mémoire secondaire (structure de stockage et méthodes
d'accès) => dépend du SGBD cible (Oracle, DB2, …)
Méthodologie : Motivations
Beaucoup des problèmes de BD sont dus à une mauvaise compréhension des
données à un niveau abstrait ou conceptuel
Collaboration avec les utilisateurs :
Description des besoins (sémantique des données).
la collaboration avec l’utilisateur converge plus vers un schéma
conceptuel
Le modèle EA est indépendant du SGBD:
le schéma conceptuel "survit" à un changement de SGBD.
Fédération des bases de données (ou intégration ) se fait par le
biais de leurs schémas conceptuels.
Modèle Conceptuel (EA , UML)
Concepts de base
Les plus connus :
Modèle entité-relation (E-R)
Diagramme de classe UML
Tous se basent sur les mêmes concepts et mécanismes d'abstraction.
Modèle de données VS Schéma
Langue pour décrire la réalité description d'une réalité selon un modèle
Modèle Langue
Schéma texte
Qualité d’un schéma Qualité d’un texte
Le Modèle Entité/ Association
Concepts de Base
• Type d ’Entité (Entity Set)
• Type d ’Association (Relationship Set)
• Attribut (Attribute)
• Clé (Key)
DEFINITION D'UNE ENTITE
Un objet pouvant être identifié distinctement.
Un objet représentant des unités que l'on peut distinguer.
Entités manipulables ou physiques : une table, un avion, un livre,
Entités non manipulables ou conceptuelles : un compte client, un service
dans une entreprise, …
On se limite aux entités utiles pour la modélisation, c'est-à-dire celles
qui vérifient les deux conditions suivantes :
-On en connaît plusieurs unités.
-On souhaite que la base de données contienne des informations sur
ces unités.
Entité et Entité type
Niveau générique (ou Entité Type) :
C’est un élément type de l'ensemble d'entités considéré
Exemple : Employé
Niveau Instance ou Occurence:
C’est un élément particulier de l'ensemble d'entités
Exemple : L’employé Kaddour
Voir Cours ISI : Notion d’information
PROPRIETES - ATTRIBUTS – VALEURS
Pour définir une entité, on établit la liste de ses caractéristiques ou
propriétés ou attributs
Exemple: le produit P1 est le produit de code M2244.
Sa désignation est « boite à vitesse" et son prix unitaire est de 25000 DA.
On appelle l'ensemble de valeurs un groupe de valeurs de même type.
Exemple : l'ensemble des valeurs de codes produit
Un attribut est une relation (au sens mathématique) entre un ensemble
d'entités et un ensemble de valeurs.
Plus précisément, un attribut est une fonction d'un ensemble d'entités vers
un ensemble de valeurs.
Exemple: N°Produit est une fonction de l'ensemble de produits dans
l'ensemble des valeurs de codes produits.
EXEMPLE Entité Employé Si la fonction attribut est injective, on parle
Propriétés Code d'attribut-clé ou d'identifiant.
Employé Une valeur de l'attribut-clé permet d'identifier
Nom une seule occurrence de de l'ensemble
Prénom d'entités.
Adresse Exemple : code employé
DEFINITION D'UNE RELATION (OU ASSOCIATION)
Une relation (au sens sémantique) indique un lien entre deux ou
plusieurs entités.
Par exemple, entre les entités Etudiant et Enseignant, il existe une
relation COURS définissant le cours dispensé à l'étudiant par l’enseignant.
Association et Association Type:
Niveau Type ou générique : la relation COURS entre l'entité Etudiant
et Enseignant.
Niveau Instance : le cours de Web Sémantique dispensé par le
professeur Bensaber à l'étudiant Sofiane.
DIAGRAMME ENTITE-RELATION
Entités et Associations sont généralement représentées
graphiquement avec le formalisme suivant :
Ou
Association
Entité
Exemple
Enseignant Cours Etudiant
LES ASSOCIATIONS PEUVENT AVOIR DES ATTRIBUTS PROPRES
Dépôt Stock Produit
Stock: Quantité
PU
Stock d’alerte
Association Binaire : relation entre deux Entité : Exemple ci-dessus
Association Ternaire : relation entre trois Entité :
Etudiant Enseigne Module
C-
C- Professeur desig Coef
Nom Adr Mod
Inscr
Matric
ule
Nom Adr
Association récursive
Personne Mariage
Le "Rôle" d'une entité dans l’association est la fonction réalisée par l'entité
dans cette dernière.
Ainsi dans l'exemple ci-dessous, "Mari" et "Femme" sont les rôles joués par
les éléments de l'ensemble d'entités personne.
Il peut exister plusieurs relations entre deux mêmes entités :
Exemple :
TYPES DE RELATIONS
On peut définir plus précisément une association en caractérisant le
nombre maximum d'occurrences d'une entité reliées à une occurrence de
l'autre entité.
Ainsi, on distingue trois types d'associations binaires :
LES ENTITES REGULIERES (ou FORTES)
Ce sont des ensembles d'entités dont l'identification des éléments se
réalise sans avoir recours aux relations existant entre les entités
Ainsi dans l'exemple ci-dessous, si on peut identifier les éléments de
l’ensembles d'entités Pièce sans avoir nécessairement à utiliser les
attributs de Fournisseur, Pièce est une entité régulière.
LES ENTITES FAIBLES
Ce sont des ensembles d'entités dont l'identification des éléments se
fait grâce aux ensembles de relations.
Dans un tel cas, l'existence des entités d'arrivée dépend de l'existence
des entités de départ.
Comment modéliser ?
Comment procéder ?
1- Faire la liste des entités
2- Four chaque entité :
faire la liste des propriétés
définir les propriétés identifiantes
3- Faire la liste des associations entre les entités
4- Pour chaque relation :
faire la liste des propriétés propres
vérifier la dimension (binaire, ternaire, etc…)
définir le type (1-1, 1-N ou M-N)
5- Vérifier le schéma obtenu notamment :
supprimer les transitivités
s'assurer que le schéma est connexe
s'assurer qu'il répond aux demandes
6- Valider avec les utilisateurs
QUELQUES CONSEILS DE MODELISATION
« Ne pas surestimer la dimension d'une relation »
Exemple : Relation Fournisseur - Pièce - Projet
Ternaire uniquement si une pièce peut être commandée chez différents
fournisseurs ou si le prix pratiqué n'est pas le même selon le projet
SINON
"Ne pas attribuer à une association les attributs des entités participantes"
Exemple
Le prix de la pièce est une caractéristique de la relation s'il dépend du
fournisseur.
Sinon c'est une caractéristique de la pièce
"Ne pas exprimer les relations redondantes, c'est-à-dire déductibles par
transitivité «
Exemple
Si un employé ne peut travailler que dans un projet administré par son
département,
Et si l’association « rattaché à » n’a pas d’attributs propres
Et si les associations ont le même cycle de vie
alors l’association "rattaché à" est redondante, sinon elle ne l'est pas.
« Confondre le concept de donnée et celui de traitement »
1. La modélisation conceptuelle de données exclut la représentation des
traitements sur ces données
2. Pourtant elle nécessite la connaissance de ces traitements :
-> Facturation n’est ni une entité ni une relation, mais un traitement
des données sur les commandes
« Introduire des attributs calculés »
1. Principe : chaque information doit être stockée une fois sous sa forme
élémentaire
2. Règle valable au niveau conceptuel, parfois remise en cause au niveau
physique
Exemples de Schéma Conceptuel
Gestion de Stock
Exercices d’Application
Exercice 1 : Elaborer un schéma conceptuel E/A relatif à une société d'assurance automobile
dont les clients sont propriétaires d’une ou plusieurs voitures chacun. A Chaque voiture est
associés 0 à N accidents enregistrés. Chaque police d'assurance couvre une ou plusieurs
voitures, et a un ou plusieurs paiements de primes qui lui sont associés. Chaque paiement est
pour une période de temps, et a une date d'échéance associée, et la date à laquelle le
paiement a été reçu.
Exercice 2 : Considérons une base de données utilisée pour enregistrer les notes que les
étudiants obtiennent dans différents examens des différents modules offerts (Section).
Etablir un diagramme E-R modélisant les examens comme des entités, et utilise une relation
ternaire.
Construire un schéma alternatif E-R qui utilise uniquement une relation binaire entre l'étudiant
et la section. mais vous pouvez représenter les notes qu'un étudiant obtient dans les différents
examens.
