Embed Size (px)
Citation preview
La modélisation conceptuelle est une approche alternative à la théorie de la
normalisation pour concevoir une base de données. Moins formelle et plus intuitive que
la théorie de la normalisation, elle lui est préférable dès qu’on doit structurer un
ensemble de données un peu complexe (à chacun de juger quand un ensemble de
données atteint ce seuil), tandis que la théorie de la normalisation, plus rigoureuse, offre
des moyens d’analyse très fins pour régler des problèmes sur des sous-ensembles précis
des données.
1
Sur ce schéma, on montre où se situe la modélisation conceptuelle de données. Entre le
monde réel qu’elle doit permettre de représenter de manière assez intuitive et les modèles
logiques des SGBD sous-jacents.
Au bénéfice des modèles conceptuels, on peut dire qu’il est souvent plus simple (plus
intuitif) de passer par une modélisation conceptuelle entre le monde réel et la
modélisation logique (dans notre cas, la modélisation relationnelle). L’étape
intermédiaire de transformation d’un modèle conceptuel vers un modèle logique
s’appelle la dérivation.
La limite des modèles conceptuels est liée à ce qui fait leur force : si l’expert qui
modélise les données n’a pas la bonne intuition, alors le modèle ne met pas de garde-fous
pour aider l’utilisateur dans sa démarche, contrairement à des formalismes logiques plus
formels, tels que le modèle relationnel qui s’accompagne d’un formalisme de
modélisation très rigoureux (appelé « théorie de la normalisation »).
Les séquences dédiées à la théorie de la normalisation illustrent ainsi la complémentarité
que l’on peut trouver entre modélisation conceptuelle (utile quand les données sont
complexes) et la modélisation relationnelle (permettant, sur un ensemble de données
restreint, d’avoir une démarche rigoureuse).
2
3
Attention !
Les notations UML présentées dans ce document sont présentées dans l’optique
d’effectuer un modèle conceptuel de données. Afin d’effectuer un diagramme de
classe, les mêmes éléments de notation sont utilisés mais les usages peuvent
parfois sensiblement différer.
4
5
6
Dans le premier exemple le nom de l’association « Emprunte > » permet de
faciliter la lecture. Le symbôle > nous indique le sens de lecture « Un étudiant
emprunte un livre » et non pas « Un livre emprunte un étudiant ». C’est une
annotation qui n’a aucun impact sur le schéma.
Dans le deuxième exemple, la notation utilisant la flèche au niveau de
l’association est utilisée dans un diagramme de classe pour donner une
information sur la navigabilité de l’association. Dans le cas cela signifie qu’à partir
de la classe Etudiant on pourra accéder à la classe Livre (mais l’inverse est
faux). CETTE NOTATION N’EST JAMAIS UTILISEE DANS LE CADRE DE LA
MODELISATION CONCEPTUELLE DE DONNEES.
7
Pour déterminer les cardinalités dans cet exemple nous devons nous poser les
questions suivantes dans le contexte où nous désirons stocker uniquement les
emprunts en cours :
- Combien de livres peuvent être empruntés par un étudiant donné ?
Un étudiant peut emprunter zéro ou plusieurs (0..*) livres.
- Par combien d’étudiants un livre peut-il être emprunté ?
Un livre peut être emprunté par zéro ou un (0..1) étudiant.
8
Lorsque une classe a une cardinalité minimale de 1 on dit que sa participation est
totale. Si sa cardinalité minimale est 0 se participation n’est donc pas totale.
9
Remarque : dans la notation UML il n’est pas prévue de souligner les identifiants
d’une classe. C’est un abus de notation que nous nous autorisons ici, pour
simplifier la lecture du schéma conceptuel de données.
10
11
12
Afin de déterminer les cardinalités on « fixe » 2 attributs pour en déduire le 3ème :
- Pour un enseignant donné et un étudiant donné dans combien de salle peut-il
avoir cours ?
- Pour un enseignant donné et une salle donné, combien d’étudiants peut-il y
avoir ?
- Pour une salle donné et un étudiant donné, combien peut-il y avoir de
professeurs ?
Dans l’exemple ci-dessus nous comprenons donc, que pour une salle donnée, et
un étudiant donné il y a au maximum un seul enseignant possible.
13
14
15
L’identifiant de la classe devient la clef primaire lors de la dérivation. Si la classe
ne possède pas d’identifiant naturel, on crée une clef primaire artificielle.
16
Ici c’est la classe Bibliothèque qui a une participation totale car chaque
bibliothèque a toujours un et un seul documentaliste qui lui est rattaché.
La classe Documentaliste n’a pas une participation totale car tous les
documentalistes ne sont pas responsables d’une bibliothèque.
Il existe deux variantes à la règle :
1) Lorsque les 2 classes ont une participation totale (cardinalités 1..1 et 1..1), il
est alors possible de les fusionner en une même relation.
2) Lorsque les 2 classes n’ont pas une participation totale (cardinalités 0..1 et
0..1) et qu’il y a un risque important d’avoir de nombreuses valeurs nulles, il
est alors possible de créer une 3ème relation (selon les mêmes modalités que
la règle n°4). Cette relation est souvent appelée « lookup table ».
17
Ici la classe Livre est rattachée à, au plus, un étudiant. Ainsi, en dérivant, on
référence un unique étudiant dans la relation LIVRE.
18
19
On obtient la le schéma logique suivant :
ETUDIANT(numero, nom, prenom)
SALLE (numero, nom)
ENSEIGNANT (numero, nom, prenom)
COURS (n°étudiant, n°salle, n°professeur, titre_cours) où
n°etudiant référence Etudiant(numero), n°professeur
référence Professeur(numero) et n°salle référence
Salle(numero)
20
Numero manager référence numero dans PERSONNE
Distinguer la manière dont l’association est nommée et le nom de l’attribut dans
la relation.
21
22
23
24
25
26
Ce schéma permet de nous assurer qu’un étudiant peut emprunter plusieurs
livres alors qu’un livre n’est emprunté que par un seul étudiant. Quand on
dit “un livre n’est emprunté que par un seul étudiant” c’est sans
considération de temps, et uniquement pour l’information actuellement
stockée dans la base de données.
La solution proposée ne permet donc pas de gérer l’historique des emprunts.
27
Cette fois ci, le schéma permet de nous assurer qu’un étudiant peut emprunter plusieurslivres et qu’un livre peut être emprunté par un ou plusieurs étudiants.
TOUTEFOIS, il ne faut pas se tromper sur l’interprétation de la phrase “un livre peut êtreemprunté par un ou plusieurs étudiants”. Il n’existe qu’une seule association entre Etudiant et Livre, il ne peut donc y avoir qu’un seul lien à la fois entre un étudiant donné et un livre donné. Un livre peut donc être emprunté par un ouplusieurs étudiants, mais forcément un étudiant différent à chaque fois.
Pour vous convaincre, dérivons le schéma conceptuel en un schéma logique. On obtient, en appliquant la règle n°4 :
ETUDIANT (numero, nom, prenom)
LIVRE (isbn, titre, auteur)
EMPRUNT(numero, isbn) où numero référence ETUDIANT(numero) et isbn référenceLIVRE(isbn)
La clef primaire étant {numero,isbn} vous voyez qu’il est impossible qu’un mêmeétudiant puisse emprunter plusieurs fois le même livre.
On a donc, avec ce schéma conceptuel, la liste de tous les étudiants avec les livresqu’ils ont empruntés, mais l’information sera écrasée s’ils ont empruntéplusieurs fois le même et il nous est impossible de savoir quand l’emprunt a eulieu car nous n’avons pas de notion de date.
28
Ce schéma nous permet de gérer un peu mieux l’historique car nous pouvons
désormais distinguer les emprunts en cours des emprunts terminés.
TOUTEFOIS, nous avons toujours le même problème : un étudiant ne peut pas
emprunter plusieurs fois le même livre.
Pour vous convaincre, dérivons le schéma conceptuel en un schéma logique. On
obtient, en appliquant la règle n°4 :
ETUDIANT (numero, nom, prenom)
LIVRE (isbn, titre, auteur)
EMPRUNT(numero, isbn, date_emprunt) où numero référence
ETUDIANT(numero) et isbn référence LIVRE(isbn)
Remarquez que la date_emprunt ne fait pas partie de la clef primaire !
Le schéma conceptuel proposé ne permet donc, toujours pas, de gérer
correctement l’historique des emprunts.
29
Comment sommes nous parvenus à fixer les cardinalités ?
- Pour un étudiant donné et un livre donné, à combien de dates a-t-il pu l’emprunter ?
0 ou plusieurs (0..*)
- Pour un étudiant donné à une date donnée, combien de livres a-t-il pu emprunter ?
0 ou plusieurs (0..*)
- A une date donnée et pour un livre donné, par combien d’étudiants le livre a-t-il pu être emprunté ?
0 ou plusieurs (0..*) ! Attention ici on parle d’un livre et non pas d’un exemplaire physique du livre (voirtransparent suivant)
Cette fois-ci nous gérons de manière convenable l’historique des emprunts.
En dérivant le schéma conceptuel au moyen de la règle n°5, on obtient le schéma logique suivant :
ETUDIANT (numero, nom, prenom)
LIVRE (isbn, titre, auteur)
DATE(date)
EMPRUNT(numero, isbn, date_emprunt) où numero référence ETUDIANT(numero), isbn référenceLIVRE(isbn) et date_emprunt référence DATE(date)
Toutefois, la gestion des dates est déjà gérée dans les SGBD traditionnels, il est donc inutile de créer unenouvelle relation DATE. Nous obtenons donc :
ETUDIANT (numero, nom, prenom)
LIVRE (isbn, titre, auteur)
EMPRUNT(numero, isbn, date_emprunt) où numero référence ETUDIANT(numero) et isbn référenceLIVRE(isbn)
30
Essayez ensuite d’obtenir le schéma logique correspondant à ce modèle
conceptuel
31
