C08-Modelisation Conceptuelle Et Logique Des BD

Part 4
CONCEPTION DE BASES DE
DONNÉES RELATIONNELLES
Les niveaux de conception d’une BD
 On a coutume de distinguer trois niveaux de représentation ou

d’abstraction pour les bases de données et les systèmes
d’information de manière plus générale :
 le niveau externe (utilisateur)
 le niveau conceptuel (concepteur, administrateur)
 le niveau interne (stockage)
 Les trois niveaux et les modèles qui en découlent offrent un

cadre rigoureux de description des données pour les
concepteurs d’une BD
Prof. Asmaa El Hannani ISIC-S2 437
1
Les niveaux de conception d’une BD
Vues des utilisateurs
Niveau
externe
 Indépendant du Description graphique des données et leurs liens
modèle de
Niveau données effectue
conceptuel  Indépendant du
Médecin Visite
SGBD
 Dépendant du Description de la structure de la BD
modèle de
Niveau interne
Modèle données Relationnel Objet XML

logique  Indépendant du
SGBD
 Dépendant du
modèle de  Organisation physique des données
Modèle données  Structures de stockage des données
Physique  Dépendant du  Structures accélératrices (index)
SGBD
Niveau conceptuel
2
La modélisation conceptuelle
 Le schéma conceptuel exprime une vue abstraite de la base de

données.
 Cette vue est représentée de manière graphique – on parle de

diagramme, de schéma et de modèle.
 Représentation à laide de la trilogie de base

 objets
 liens
 propriétés
Avantages de la modélisation conceptuelle
 L’attention est portée sur les applications

 Indépendante des technologies
 Portabilité
 Longévité
 Orientée utilisateur
 Compréhensibilité
 Support du dialogue concepteurs / utilisateurs
 Permet la collaboration et la validation par les utilisateurs
 Spécifications formelles, non ambigües
 Facilite les échanges d’informations entre SGBD différents
3
Elaboration du schéma conceptuel
 Analyse du monde réel

 Identification des phénomènes à représenter dans la BD
 Représentation à laide des concepts du modèle
 contenu
 structure
 règles
 dynamique
 Représentation en général
 Partielle
 Subjective
Différents types de modèles conceptuels
 Dans le cadre de ce cours nous allons se concentré sur les

modèles pour les donnée en utilisant:
 Méthode objet (type UML - Unified Modelling Language)
 Déjà vu !
 Méthode systémique (type MERISE)
 Nous réaliserons un face à face entre le modèle conceptuel
des données de Merise et le diagramme de classes UML.
4
Merise
 La méthode Merise est une évolution ou plus précisément une

standardisation du modèle entité-association.
 Merise est une méthode d'analyse, de conception et de
réalisation de systèmes d'informations.
 Cette méthode préconise plusieurs étapes pour passer d'un
système d'informations manuel à un système d'informations
automatisé.
Merise
 Dans la méthode Merise, le modèle conceptuel correspond au

modèle entité-association celui-ci s'appelle le Modèle
Conceptuel de Données : MCD.
 La méthode Merise propose d'autres modèles tels que :
 Les Modèles de Traitement (MOT, MCT) qui permettent de
modéliser les événements, les opérations et les processus.
 Les Modèles de Communication (MCC) qui permettent de
modéliser les interactions.
 Ces aspects de la méthode ne seront pas développés ici car ils

sont plus orientés application que base de données.
5
UML
 Parmi tous les diagrammes proposés par la méthode UML,

seul le diagramme de classes permet de modéliser les bases de
données.
 Les autres diagrammes ne seront donc pas mentionnés dans
cette partie du cours.
Terminologie
6
Entité, Classe
Merise UML
Entité Classe
Identifiant Attribut 1
Attribut 2 Attribut 2
.... ....
Attribut n Attribut n
methodes
L'association
Merise UML
Entite_1 Entite_2 Classe_1 Classe_2
Lie Lie
7
Cardinalités, Multiplicités
Merise UML
Cardinalités Lecture Multiplicités Lecture
0,1 Lien vers 0 ou 1 0..1 Lien vers 0 ou 1
1,1 Lien vers 1 1 Lien vers 1
0,n Lien vers 0 ou N * Lien vers 0 ou plusieurs
1,n Lien vers 1 ou N 1..* Lien vers 1 ou plusieurs
Les associations un à un
Merise UML
Cardinalités Multiplicités
0,1 0,1 0 .. 1 0 .. 1
0,1 1,1 0 .. 1 1
1,1 1,1 1 1
8
Les associations un à plusieurs
Merise UML
0,1 0,N 0 .. 1 *
0,1 1,N 0 .. 1 1 .. *
1,1 0,N 1 *
1,1 1,N 1 1 .. *
Associations plusieurs à plusieurs
Merise UML
0,N 0,N * *
0,N 1,N * 1 .. *
1,N 0,N 1 .. * *
1,N 1,N 1 .. * 1 .. *
9
Exemple d'association
Merise UML
Une personne peut exercer une profession
Personne Profession Personne Profession

0,1 Exerce 0,N 0..1
*
Exerce
Une profession peut être exercée par plusieurs personnes
 Les cardinalités d’une association binaire dans le modèle de Merise

sont inversées par rapport au modèle UML au niveau de l’axe de
représentation de l’association.
Association avec attributs
Merise UML
Entite_1 Entite_2 Classe_1 Classe_2

Lie
Lie
Attribut_1
Classe_Asso
Attribut_1
Classe-association
10
L'association ternaire
Merise UML
Min,Max Lie Min,Max

Entite_1 Entite_2 Classe_3
Attributs
Min,Max Min..Max
Entite_3
Min..Max Min..Max
Classe_1 Classe_2
Class_Asso
Attributs
L'association réflexive
Merise UML
[rôle 1] rôle 1
Entite_1 Classe_1
Lie
[rôle 2] rôle 2
11
L'association réflexive
Merise
UML
Les contraintes
 Afin de prendre en compte plus de règles, la norme Merise

intègre les notions de contraintes.
 Les contraintes associent des entités ou des relations afin de
préciser des règles supplémentaires.
 En contrepartie, UML permet de définir tout type de contrainte

en langage naturel (graphiquement, il s’agira d’un texte
encadré d’accolades s’appliquant au niveau d’un attribut, d’un
rôle, ou entre associations nommées).
12
Les contraintes
Merise
Entite_2 Assoc_1 Entite_1
Assoc_2
UML
Classe_2 Classe_1
Assoc_1
{Contrainte}
Assoc_2
Les contraintes
 Les contraintes les plus courantes sont :

 L'exclusivité : peut être l'un ou l'autre
 La totalité : doit être l'un, l'autre ou les deux
 La partition : doit être l'un ou l'autre
 L'inclusion : ce qui est dans l'un est dans l'autre
 La simultanéité : doit être dans l'un et dans l'autre
 L'unicité : ce qui est dans l'un ne peut être qu'une fois dans l'autre
13
Les contraintes
 Dans Merise les contraintes sont modélisés par des codes :

 L'exclusivité : X
 La totalité : T
 La partition : XT (parfois P)
 L'inclusion : I
 Simultanéité : S
 L'unicité : U
Les contraintes
Exemple de contrainte d'exclusivité :
Personne Possede Adresse
Loue
 Ici, on modélise le fait qu'une personne ne peut pas posséder et

louer une même adresse.
14
Les contraintes
Exemple de contrainte de totalité :
Loue
 Ici, on modélise le fait qu'une personne est forcément

propriétaire, locataire ou les deux.
Les contraintes
Exemple de contrainte de partition :
XT
Loue
 Ici, on modélise le fait qu'une personne est forcément

propriétaire ou locataire mais pas les deux.
15
Les contraintes
Exemple de contrainte d'inclusion :
Etudiant Souhaite Stage
Effectue
 Ici, on modélise le fait que le stage qu'un étudiant effectuera

est un des stage qu'il a souhaité.
Les contraintes
Exemple de contrainte de simultanéité :
Etudiant Effectue Stage
Inscrit ENSAJ
 Ici, on modélise le fait que le stage est obligatoire pour tous les
étudiants puisque toute occurrence dans ‘Inscrit' doit exister
dans 'Effectue'.
16
Les contraintes
Exemple de contrainte d'unicité :
Utilisateur 0,N Appartient 0,N Groupe
 Ici, on modélise le fait qu'un utilisateur ne peut pas appartenir

plusieurs fois au même groupe.
 Cette contrainte n'a d'intérêt que dans une relation plusieurs à
plusieurs.
L'héritage
 L'héritage existe en Merise comme en UML.

 Le concept est le même qu'en langage objet.
 On modélise l'héritage en Merise par un triangle contenant les
contraintes, en UML par une flèche de l'héritier vers le parent.
17
L'héritage
Merise UML
Super_Entite Super_Classe
Sous_Entite1 Sous_Entite2 Sous_Classe1 Sous_Classe2
L'héritage
Il existe différents cas d'héritage en fonction des instances des classes :
A A A
A
A/B A/B
B B B
B
Cas 1 Cas 2 Cas 3 Cas 4

Chacun de ces cas d’héritage peut être modélisé à l’aide de contraintes :
Couverture Non-couverture
Disjonction Cas 1 Cas 2

Merise : Partition (XT) Merise : Exclusivité (X)
UML : {complete, disjoint} UML : {incomplete, disjoint} (par défaut)
Non-disjonction Cas 3 Cas 4
Merise : Totalité (T) Merise : Pas de contrainte
UML : {complete, overlapping} UML : {incomplete, overlapping}
18
L'héritage : exemple
 Une population de postes de travail peut être composée :
 de postes clients ou serveurs exclusivement (cas 1) ;
 de postes clients, de postes serveurs et de postes isolés qui ne sont ni
clients ni serveurs (cas 2) ;
 de postes clients, de postes serveurs et de postes qui sont à la fois clients
et serveurs, mais pas de postes isolés (cas 3) ;
 de postes clients, de postes serveurs, de postes qui sont à la fois clients
et serveurs et de postes isolés (cas 4).
Postes Postes Postes Postes
Clients Clients Clients

Clients
C/S C/S
Serveur Serveurs Serveurs
Serveurs
Cas 1 Cas 2 Cas 3 Cas 4

L'héritage : exemple « cas 1 »
Merise UML UML

Poste Poste
nserie nserie
typeposte typeposte
XT
{Complete, disjoint}
Client Serveur Client Serveur

adr_IP nomserv adr_IP nomserv
masque disque masque disque
19
L'héritage
 L'absence de contraintes sur un graphe d'héritage n'a pas la

même signification en Merise et UML :
 Pour Merise c'est le cas 4 : non-couverture, non-disjonction
 Pour UML c'est le cas 2 : non-couverture, disjonction
UML ou Merise ?
 La notation UML est bien adaptée à la modélisation d’une

base de données pour les raisons suivantes :
 Les bases de données sont majoritairement relationnelles, mais
certaines migreront vers l’objet ;
 Les concepts fondamentaux de Merise peuvent être représentés
dans le diagramme de classes d’UML qui offre en plus la
possibilité de définir des stéréotypes et des contraintes
personnalisées ;
 la majorité des contraintes sur les associations n-aires sont
implicites si on utilise les classes-associations;
 les concepteurs travaillent dans un même environnement (comme
Eclipse), avec la possibilité d’interfacer plus facilement les
langages évolués C++ ou Java.
20
Conception du modèle pour une BD
 Il n'existe pas de modèle de données idéal.

 Le modèle doit correspondre à un besoin précis.
 Il est indispensable que chaque décision, chaque façon de faire soit
réfléchie.
 En cas de multiples possibilités, il faut s'assurer que le
fonctionnement mis en place répondra au besoin.
 Il peut être tentant de créer un modèle le plus généraliste possible.
Mais attention :
 Ce type de modèles mèneront à des bases de données trop
complexes.
 Les performances seront alors moindre et les fonctionnalités mise
en place pas forcément utilisées.
Interprétation (1/3)
 Une base données doit permettre de stocker toutes les

informations nécessaires à son utilisation.
 Toute la complexité réside dans l'organisation de ces attributs.
 Toute redondance est interdite.
 Il faut essayer de créer un modèle à la fois évolutif mais aussi
suffisant pour le besoin.
21
 Un choix difficile est notamment le fait d'utiliser un attribut

dans l'entité ou de créer une association.
Exemple :
Personne
Personne Adresse
ID ou
ID 0,1 Réside 0,N ID
Nom
Nom Rue
Prenom
Prenom CP
Adresse
Ville
CP
Ville
 Le choix des cardinalités est également primordial.
Exemple :
Personne Adresse
ID 0,1 Réside 0,N ID
Nom date_debut Voie
ou
Prenom date_fin CP
Ville
Personne Adresse
ID 1,N Réside 0,N ID
Nom type Voie
Prenom date_debut CP
date_fin Ville
22
Niveau logique
Passage au niveau logique
 Le niveau logique (relationnel) est Intermédiaire entre le

modèle conceptuel et le modèle physique des données.
 Il donne la représentation des tables telles qu'elles seront dans
la base de données.
 Le niveau logique n'est pas impacté par le système de bases de
données utilisé.
 Nous présenterons les structures ainsi :
Table[cle_primaire,champ_1, …, champ_N, cle_etrangere#]
23
Clé primaire et clé étrangère: Rappel
 Une clé primaire est une contrainte d'unicité qui permet
d'identifier de manière unique un enregistrement dans une table. Une
clé primaire peut être composée d'un ou de plusieurs attributs de la
table.
 Une clé étrangère identifie une colonne ou un ensemble de colonnes

d'une table comme référençant une colonne ou un ensemble de
colonnes d'une autre table (la table référencée)
 Les colonnes de la table référencée doivent faire partie d'une contrainte
de clé primaire ou d'une contrainte d'unicité
 L'ensemble constitué d'une clé primaire et d'une clé étrangère sert à

établir des relations entre tables.
Passage au niveau logique
 Nous donnons ci-après quatre règles (de R1 à R4) pour

traduire un schéma conceptuel Merise ou UML en un schéma
logique (relationnel) équivalent.
 Il existe d’autres solutions de transformation, mais ces règles

sont les plus simples et les plus opérationnelles.
24
Règle 1 (Transformation d’entités/classes)
 Chaque entité devient une relation. L’identifiant de l’entité

devient clé primaire pour la relation.
 Chaque classe du diagramme UML devient une relation. Il faut
choisir un attribut de la classe pouvant jouer le rôle
d’identifiant.
 Si aucun attribut ne convient en tant qu’identifiant, il faut en
ajouter un de telle sorte que la relation dispose d’une clé
primaire (les outils proposent l’ajout de tels attributs).
Règle 1 (Transformation d’entités/classes)
Merise UML
Avion[immat, typeav]
R1
Compagnie[ncomp, nomcomp]
25
Règle 2 (Associations un-à-plusieurs)
 Il faut ajouter un attribut de type clé étrangère dans la relation

fils de l’association:
 la relation dérivée de l’entité ayant la « multiplicité plusieurs »
dans le modèle UML .
ou
 la relation dérivée de l’entité ayant la « cardinalité un » dans le
modèle Merise.
 L’attribut porte le nom de la clé primaire de la relation père de

l’association.
Règle 2 (Associations un-à-plusieurs)
Avion[immat, typeav, ncomp#]

R1 et R2
26
Règle 3
(Associations plusieurs-à-plusieurs et n-aires)
 L’association ou classe-association devient une relation dont la
clé primaire est composée par la concaténation des identifiants
des entités (classes) connectés à l’association.
 Ces attributs devient alors des clés étrangères.
 Les attributs de la classe-association doivent être ajoutés à la

nouvelle relation. Ces attributs ne sont ni clé primaire, ni clé
étrangère.
Règle 3
(Associations plusieurs-à-plusieurs)
R1 et R3
Avion[immat, typeav]
Affreter[immat#,ncomp#, dateaff]
27
Règle 4 (Associations un-à-un)
 Il faut ajouter un attribut clé étrangère dans la relation dérivée de

l’entité ayant la multiplicité minimale égale à zéro pour UML (ou
cardinalité minimale égale à 1 pour Merise).
 La clé étrangère est la clé primaire de la relation dérivée de l’autre

entité (classe) connectée à l’association.
 Si les deux cardinalités (multiplicités) minimales sont à zéro, le

choix est donné entre les deux relations dérivées de la règle R1.
 Si les deux cardinalités minimales sont à un, il est sans doute

préférable de fusionner les deux entités (classes) en une seule.
Règle 4 (Associations un-à-un)
Stage[nstage, entreprise]
R1 et R4
Etudiant[netu, nometu, nstage#]
28
Exercice
Donnez les modèle logique des schémas suivants:
Personne Adresse
A. Reside
ID 0,1 0,N ID
Nom Rue
Prenom CP
Ville
B. Personne Adresse
ID 0,N Réside 0,N ID
Nom Rue
Prenom Date_emmen CP
Ville
Associations réflexives
 Un-à-plusieurs
29
Associations réflexives
 Plusieurs-à-plusieurs
Héritage
 Il existe trois méthodes de décomposition pour traduire une

association d'héritage :
 La décomposition par distinction (une table par entité ou classe)
 La décomposition descendante (une table par sous-entité ou sous-

classe)
 La décomposition ascendante (une table par sur-entité ou sur-

classe)
30
La décomposition par distinction
 Il faut transformer chaque sous-classe en une relation.
 La clé primaire de la classe mère devient à la fois clé primaire et clé
étrangère des sous-classes.
La décomposition descendante
 Il faut alors faire migrer tous les attributs de la classe mère

dans les relations issues des sous-classes.
31
La décomposition ascendante
 Il faut supprimer les relations issues des sous-classes et faire migrer

les attributs dans la relation issue de la classe mère.
Exercice
Donnez le modèle logique du schéma suivant:
Poste
nserie
typeposte
{Complete, disjoint}
Client Serveur
adr_IP nomserv
masque disque
32
Agrégation
 Alors que l’agrégation de UML se traduit au niveau logique

comme une simple association, il n’en est pas de même pour la
composition.
On suppose que l’attribut a identifie la classe composante et que l’attribut c

identifie la classe composite
Contraintes
 Certaines contraintes peuvent se traduire au niveau logique,

d'autres au niveau physique.
 Il existe plusieurs façons de prendre en comptes les
contraintes, cela dépend de la contrainte et du type
d'association.
 Certaines contraintes nécessitent l'utilisation de triggers, nous
considérerons que nous ne les prenons en compte dans ce
cours.
33
Contraintes
Exemple de prise en compte :
Contrainte Logique Physique

Fusion des tables avec
Exclusivité (X) Le champ indicateur NULL
champ indicateur
Totalité (T) Le champ indicateur NOT NULL
champ indicateur
Partition (XT) Le champ booléen NOT NULL
champ booléen
Inclusion (I) Les champs inclus sont NULL
champs NULL
Simultanéité (S) Fusion des 2 tables Les champs sont NOT NULL
Unicité (U) Indexe unique
Contraintes
Exemple avec la contrainte d'exclusivité :

Loue
Personne [idp, nom, prenom, date_naiss]

Adresse [ida, voie, cp, ville]
Dispose [idp#, ida#, ind_loue]
Le champ ‘ind_loue' pourra prendre les valeurs :
'L' : locataire, 'P' : propriétaire, NULL : pas précisé
34
Niveau Physique
Niveau physique
 Le Modèle Physique de Données est la représentation exacte

de la base de données.
 Il est liée au système utilisé.
 Il peut être obtenu automatiquement par des outils mais il
correspond rarement au besoin.
 Il peut permettre de créer automatiquement la base de données
par des outils en générant le code SQL correspondant.
 Par exemple en utilisant phpMyAdmin
35
Passage au niveau physique
 Les tables sont les éléments du MPD.

 Comme pour le modèle logique
 Une table doit contenir une clé primaire permettant d'identifier de
façon unique l'occurrence de la table.
 Une table peut contenir une ou des clé étrangère permettant de la

lier à une autre table.
 En plus les attributs sont typés.

 Les types de données peuvent varier selon les système de base
de données.
Passage au niveau physique
 Nous présenterons les structures soit par:
Table [cle_primaire: type,champ1:type, … champN:type, cle_etrangere#:type]
Ou
Table
Cle_primaire type
champ1 type
champN type
Cle_etranger# type
36
Passage au modèle physique (exemple1)
Passage au modèle physique (exemple2)
37

C08-Modelisation Conceptuelle Et Logique Des BD

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

C08-Modelisation Conceptuelle Et Logique Des BD

Загружено:

Авторское право:

Доступные форматы

Part 4

Les niveaux de conception d’une BD

 On a coutume de distinguer trois niveaux de représentation ou

 Les trois niveaux et les modèles qui en découlent offrent un

Prof. Asmaa El Hannani ISIC-S2 437

Modèle données Relationnel Objet XML

Prof. Asmaa El Hannani ISIC-S2 438

 Le schéma conceptuel exprime une vue abstraite de la base de

 Cette vue est représentée de manière graphique – on parle de

 Représentation à laide de la trilogie de base

Prof. Asmaa El Hannani ISIC-S2 440

Avantages de la modélisation conceptuelle

 L’attention est portée sur les applications

Prof. Asmaa El Hannani ISIC-S2 441

 Analyse du monde réel

Prof. Asmaa El Hannani ISIC-S2 442

Différents types de modèles conceptuels

 Dans le cadre de ce cours nous allons se concentré sur les

Prof. Asmaa El Hannani ISIC-S2 443

 La méthode Merise est une évolution ou plus précisément une

Prof. Asmaa El Hannani ISIC-S2 444

 Dans la méthode Merise, le modèle conceptuel correspond au

 Ces aspects de la méthode ne seront pas développés ici car ils

Prof. Asmaa El Hannani ISIC-S2 445

 Parmi tous les diagrammes proposés par la méthode UML,

Prof. Asmaa El Hannani ISIC-S2 446

Prof. Asmaa El Hannani ISIC-S2 447

Prof. Asmaa El Hannani ISIC-S2 448

Entite_1 Entite_2 Classe_1 Classe_2

Prof. Asmaa El Hannani ISIC-S2 449

Cardinalités Lecture Multiplicités Lecture

0,1 Lien vers 0 ou 1 0..1 Lien vers 0 ou 1

1,1 Lien vers 1 1 Lien vers 1

0,n Lien vers 0 ou N * Lien vers 0 ou plusieurs

1,n Lien vers 1 ou N 1..* Lien vers 1 ou plusieurs

Prof. Asmaa El Hannani ISIC-S2 450

Prof. Asmaa El Hannani ISIC-S2 451

Prof. Asmaa El Hannani ISIC-S2 452

Associations plusieurs à plusieurs

Prof. Asmaa El Hannani ISIC-S2 453

Personne Profession Personne Profession

Une profession peut être exercée par plusieurs personnes

 Les cardinalités d’une association binaire dans le modèle de Merise

Association avec attributs

Entite_1 Entite_2 Classe_1 Classe_2

Prof. Asmaa El Hannani ISIC-S2 455

Min,Max Lie Min,Max

Prof. Asmaa El Hannani ISIC-S2 456

Prof. Asmaa El Hannani ISIC-S2 457

Prof. Asmaa El Hannani ISIC-S2 458

 Afin de prendre en compte plus de règles, la norme Merise

 En contrepartie, UML permet de définir tout type de contrainte

Prof. Asmaa El Hannani ISIC-S2 459

Prof. Asmaa El Hannani ISIC-S2 460

 Les contraintes les plus courantes sont :

Prof. Asmaa El Hannani ISIC-S2 461

 Dans Merise les contraintes sont modélisés par des codes :

Prof. Asmaa El Hannani ISIC-S2 462

Exemple de contrainte d'exclusivité :

Personne Possede Adresse

 Ici, on modélise le fait qu'une personne ne peut pas posséder et

Prof. Asmaa El Hannani ISIC-S2 463

Exemple de contrainte de totalité :

Personne Possede Adresse