Modélisation logique des données

Modélisation
de logiciels de gestion
160. Modélisation logique des données (MLD)
Aspects macroscopiques
Table des matières
1
2
3
4
5
6
7
Préambule........................................................................................................................... 2
Concepts de base ................................................................................................................ 3
2.1
Le modèle relationnel initial ...................................................................................... 3
2.2
Le modèle logique de données relationnel................................................................. 4
Table................................................................................................................................... 5
3.1
Schéma d’une table .................................................................................................... 6
3.2
Extension d’une table ................................................................................................. 6
3.3
Espace de nommage ................................................................................................... 6
Clés..................................................................................................................................... 7
4.1
Clé primaire................................................................................................................ 7
4.2
Clé secondaire ............................................................................................................ 8
4.3
Clé secondaire unique et non nulle ............................................................................ 9
4.4
Clé étrangère ............................................................................................................ 10
Relation entre tables ......................................................................................................... 11
Degré d’une relation......................................................................................................... 12
Contraintes d’intégrité...................................................................................................... 13
7.1
Contrainte d’unicité de valeur (UNIQUE) ............................................................... 13
7.2
Contrainte de valeur non nulle (NOT NULL).......................................................... 13
7.3
Contrainte de clé primaire (PRIMARY KEY) ......................................................... 14
7.4
Contrainte d’intégrité référentielle stricte (FOREIGN KEY, REFERENCE) ......... 15
1/15
1 Préambule
Nous avons déjà expliqué la démarche de réalisation de modèles conceptuels de données dans
le chapitre « Modélisation conceptuelle des données – Aspects macroscopiques », dans ce
chapitre nous présenterons les éléments techniques essentiels de construction des modèles
logiques de données et de leur représentation graphique.
Nous exposerons la modélisation logique des données selon le concept de modèle relationnel
dans une vision macroscopique ; c’est-à-dire que nous tenterons de mettre en évidence les
éléments essentiels que nous retrouvons pratiquement dans la plupart des différentes
implantations de modélisation logique des données.
La modélisation s’appuyant sur un langage et une représentation graphique, nous avons
choisi de nous appuyer sur UML et le modèle de classes pour réaliser ce chapitre, tout
comme nous l’avons fait pour le modèle conceptuel.
Deux raisons nous ont guidé dans ce choix :
• UML est relativement commun à la communauté informatique ;
• Le formalisme d’UML est très riche.
Toutefois le formalisme des méthodes mettant en évidence la modélisation des données peut
être plus approprié que UML; à titre d’exemple, nous pouvons citer la méthode CDM
d’Oracle et l’AGL Designer. Nous présenterons certains de ces formalismes plus loin dans le
cours.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
2/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
2
Concepts de base
2.1 Le modèle relationnel initial
Le concept de modèle relationnel a été présenté par E. F. Codd en 1970 et fait l’objet, encore
actuellement, de nombreux travaux de recherche.
[MERISE-3] En première approximation une relation peut être définie comme un tableau de
données. Chacun de ces tableaux aura un nom et sera caractérisé par des attributs.
Le méta modèle s’inspire de la notion mathématique de relation, il est basé sur deux aspects
fondamentaux:
• Aspect statique - Une démarche de conception permettant de définir une collection de
relations nommée : Modèle logique de données relationnel.
• Aspect dynamique - Une algèbre permettant de manipuler des tables ou relations.
Dans la suite du chapitre nous ne traiterons que de l’aspect statique.
L’algèbre relationnelle, partie dynamique, est traitée dans la partie de modélisation des
traitements.
Remarque importante :
Historiquement, le terme « relationnel » s’appliquait à la notion de structure tabulaire ; il
mettait en évidence les relations existantes entre les colonnes ou attributs d’une table.
Afin d’éviter toute confusion d’interprétation, dans la suite de ce cours, le terme de table sera
utilisé en lieu et place de relation et le terme relation sera réservé aux « liens » entre tables.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
3/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
2.2 Le modèle logique de données relationnel
Le méta modèle générique du modèle relationnel est constitué de 2 classes d’objets :
• les tables qui permettent de définir la structure de mémorisation des occurrences
d’entités du modèle conceptuel ;
• les dépendances fonctionnelles entre tables sous forme de couples formés de clés
primaires et clés étrangères qui permettent de mémoriser les occurrences
d’associations entre entités.
Les dépendances fonctionnelles entre tables sont représentées graphiquement sous forme de
« relations » entre tables.
Pour le cas de la crèche, la structure de la table Enfants correspond à l’entité Enfant. La
colonne Edu_Numero est une clé étrangère; associée à la clé primaire Numero de la table
Educatrices, cette dépendance fonctionnelle ou relation réalise l’association En Charge.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
4/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
3 Table
Une table est l’équivalent d’un tableau de valeurs ; lors de la transformation
d’un modèle conceptuel en modèle logique, elle est issue d’une entité ou d’une
entité associative.
Le tableau ci-après fixe le vocabulaire utilisé dans le cadre du modèle relationnel.
Vocabulaire
tabulaire
Vocabulaire
relationnel
Remarques
Colonne
Attribut
Propriété dans le cadre de la modélisation
conceptuelle des données (MCD / E-A)
Un attribut prend ses valeurs dans un domaine
par exemple:
• domaine des entiers {... -2; -1; 0; 1; 2 ...}
• domaine des continents {Europe; Asie ...}
Ligne
Tuple ou n-uplet
Occurrence d’entité ou d’association dans le
cadre des MCD / E-A.
Equivalent d’un enregistrement dans le cadre
d’une gestion de fichiers structurés.
Nombres de colonnes
Degré
Nombre de lignes
Cardinalité
Dans la suite du cours, nous privilégierons les termes de colonne et d’enregistrement.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
5/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
3.1 Schéma d’une table
Le schéma d’une table permet de définir la structure d’une table. Il est
constitué du nom de la table suivi de la liste de ses colonnes (attributs) avec
leurs domaines de valeurs.
Toute table du modèle logique de données doit impérativement être dotée d’une clé primaire.
Tout comme pour le modèle conceptuel, la ou les colonnes constitutives de la clé primaire
sont enrichies du stéréotype « PK ».
Remarques:
Nous conservons le stéréotype « UID » défini en modélisation conceptuelle pour montrer la
ou les colonnes constitutives d’un identifiant naturel.
3.2 Extension d’une table
L’extension ou instanciation d’une table est l’ensemble des enregistrements
(lignes ou tuples) définis par les valeurs prises par les différentes colonnes du
schéma de la table concernée.
Pour la suite du cours, nous nous intéresserons au seul schéma ; l’instanciation est l’affaire de
la modélisation des traitements.
3.3 Espace de nommage
Comme nous l’avons déjà expliqué dans le chapitre de modélisation conceptuelle, une table
est un espace de nommage et les colonnes ne doivent pas être préfixés ou postfixés de tout ou
partie du nom de la table.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
6/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
4 Clés
Les clés sont des colonnes de tables qui permettent d’accéder aux enregistrements avec
rapidité et précision. Par rapport au concept initial de relation, les clés permettent de lier les
tables entre elles avec rigueur ; elles offrent un mécanisme performant de réalisation des
associations du modèle conceptuel de données.
4.1 Clé primaire
La clé primaire d’une table permet au SGBD1 d’accéder à un enregistrement
sans ambiguïté, elle est formée d’une une plusieurs colonnes.
Remarque:
Dans le cas de gestion de personnes, la valeur de clé primaire peut être utile
aussi aux utilisateurs pour accéder à un enregistrement précis.
Rappel du chapitre de modélisation conceptuelle des données :
Nous préconisons, pour faciliter la maintenance, de nommer uniformément la colonne
artificielle de clé primaire NUMERO.
Nous montrons le ou les attributs qui forment la clé primaire en les enrichissant du stéréotype
« PK ».
Pour remplir totalement son rôle, la clé primaire doit être:
• univaluée - à un enregistrement ne correspond qu’une seule valeur de clé primaire;
• discriminante - à une valeur de clé primaire donnée correspond un seul et unique
enregistrement;
• minimale - si la clé primaire est composée de plus d’une colonne, la perte d’une colonne
doit faire perdre le caractère discriminant de la clé primaire.
• stable - la valeur initiale de la clé primaire doit être conservée durant toute la vie de
l’enregistrement.
Pour un SII, la clé primaire est une valeur numérique entière; la valeur de clé primaire est
créée par un séquencement automatique. La valeur de la clé primaire n’a et ne doit avoir
aucune signification pour en garantir la stabilité.
1
SGBD : système de gestion de base de données – logiciel spécifiquement dédié à la gestion de données.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
7/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
4.2 Clé secondaire
La ou les clés secondaires d’une table permettent aux utilisateurs d’accéder à
un ou éventuellement plusieurs enregistrements à partir de la connaissance des
valeurs d’une ou plusieurs colonnes.
Le concept de clé secondaire était essentiel avant l’arrivée des SGBD-R2, actuellement, ce
concept de clé secondaire tend à être occulté. Une clé secondaire est réalisée par un index.
Avant les SGBD-R, la création et la maintenance d’un index était une tâche fastidieuse qui
devait impérativement être planifiée ; la planification se basait sur le recensement des clés
secondaires à mettre en oeuvre. Avec les SGBD-R, la création et la maintenance d’un index se
fait par une simple déclaration ; les index et implicitement les clés secondaires sont souvent
créés pour améliorer les performances d’un SII en cours d’exploitation.
Une clé secondaire peut :
• être nulle ; c’est-à-dire qu’elle peut ne pas être renseignée pour un ou plusieurs
enregistrements ;
• être non discriminante ; c’est-à-dire qu’elle peut identique pour plusieurs
enregistrements.
Pour notre crèche, le nom des éducatrices peut être une clé secondaire pertinent, le prénom
aussi ; toutefois, nous pourrions avoir deux éducatrices de même nom ou prénom voire une
éducatrice dont le prénom n’est pas enregistré.
Remarque :
Nous ne mettons pas en évidence les clés secondaires qui sont optionnelles ou non
discriminantes.
2
SGBD-R : système de gestion de base de données réalisé sur les concepts du modèle relationnel de Codd.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
8/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
4.3 Clé secondaire unique et non nulle
La ou les clés secondaires uniques et non nulles d’une table permettent aux
utilisateurs d’accéder à un enregistrement à partir de la connaissance des
valeurs d’une ou plusieurs colonnes.
Remarque:
Pour la gestion de personnes, il peut être impossible de créer une clé secondaire
unique et non nulle ; dans ce cas, la valeur de clé primaire est utilisée par les
utilisateurs pour accéder à un enregistrement précis.
Toute table doit être dotée d’au moins une clé secondaire unique et non nulle ; la
connaissance de la valeur de cette clé secondaire unique et non nulle permet aux utilisateur
d’accéder à un enregistrement précis sans ambiguïté.
La clé secondaire unique et non nulle correspond au concept d’identifiant naturel présenté en
modélisation conceptuelle des données ; nous enrichissons les clés secondaires uniques et non
nulles du stéréotype « UID » pour bien montrer la similarité entre les deux niveaux de
modélisation.
Rappel du chapitre de modélisation conceptuelle des données :
Pour remplir totalement son rôle sans ambiguïté, l’identifiant doit être:
• univalué - à une occurrence d’entité ne correspond qu’une seule valeur d’identifiant;
• discriminant - à un identifiant donné correspond une seule et unique occurrence d’entité;
• minimal - si l’identifiant est composé de plus d’une propriété, la perte d’un composant
doit faire perdre le caractère discriminant de l’identifiant.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
9/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
4.4 Clé étrangère
Une clé étrangère correspond à la clé primaire d’une table servant de
référence. Le couple {clé primaire de la table source de la référence, clé
étrangère de la table cible de la référence} matérialise une dépendance
fonctionnelle entre deux tables.
Nous préconisons, pour faciliter la maintenance, de nommer les clés étrangères NUMERO et
de les préfixer du nom court de la table de référence ; plus précisément, le préfixe sera
constitué du rôle et du nom court de la table. Nous aborderons plus tard la notion de rôle.
Le nom court de la table est un nom abrégé de la table, quelques lettres. Ce nom court doit
être discriminant et facilement mémorisable. Le nom court est utilisé pour nommer les
contraintes de tables dont justement les contraintes de clés étrangères.
La clé étrangère de l’éducatrice en charge de l’enfant devient :
EDU_NUMERO
EDU est l’abréviation de la table Educatrices
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
10/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
5 Relation entre tables
Une relation entre tables représente une dépendance fonctionnelle entre deux tables.
Une relation est réalisée par un couple {clé primaire de la table de référence, clé
étrangère de la table cible de la référence}.
Remarque:
Une relation peut s’établir aussi au sein d’une seule table ; nous parlons, alors, de
relation réflexive.
Une relation est représentée dans le modèle logique de donnée par une association UML entre
les deux tables (classes stéréotypées « Table » dans la terminologie UML).
La table Educatrices est la source de la dépendance fonctionnelle ou de la relation, la table
Enfants est la cible de la dépendance fonctionnelle ou de la relation.
Nous utilisons aussi le vocabulaire « Parent / Enfant » pour décrire le rôle de chacune des
deux tables.
La table Educatrices est le parent de la relation, la table Enfants est l’enfant de la relation.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
11/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
6 Degré d’une relation
Le degré d’une relation exprime la cardinalité maximale des enregistrements
participant à la relation.
Le degré s’exprime par deux nombres sous la forme a:b.
• a représente le nombre maximum d’enregistrements de la table source de la relation
ayant une valeur de clé primaire correspondant à une valeur de clé étrangère de la
table cible.
Ce nombre vaut toujours 1; en effet, une clé étrangère ne doit pouvoir être asssociée
qu’à un et un seul enregistrement parent.
• b représente le nombre maximum d’enregistrements de la table cible de la relation
ayant une valeur de clé étrangère correspondant à une valeur de clé primaire de la
table source; ce nombre s’exprime par 1 ou n.
1 signifie qu’un enregistrement parent ne peut avoir qu’un seul enfant.
n signifie qu’un enregistrement parent peut avoir plusieurs enfants.
Le degré d’une relation ne peut s’exprimer avec UML qu’au travers des cardinalités de
l’association entre les deux classes.
Dans l’exemple ci-dessus, la table Enfants est enfant de la relation et ne peut avoir qu’un
seul parent (nombre a) ; la valeur 1 se lit sur l’extrémité Educatrices.
La table Educatrices est parent de la relation et peut avoir plusieurs enfants ; la valeur n
(UML représente le n par le symbole *) se lit sur l’extrémité Enfant.
La relation En charge est de degré 1:n.
Remarque :
Les valeurs minimales des cardinalités ne sont pas prises en compte par le concept de degré
de relation.
[Plus de détails sur les cardinalités dans le chapitre de modélisation conceptuelle des données]
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
12/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
7 Contraintes d’intégrité
Une contrainte d’intégrité est une assertion qui doit être vérifiée par les
valeurs de colonnes de tables.
[MERISE-3] Le modèle conceptuel de données ne peut suffire à donner une image complète
de la réalité. En effet, c’est une vision synthétique qui se veut également la plus simple
possible d’un point de vue représentation. C’est pourquoi associé à ce modèle conceptuel on
définit un système d’intégrité constitué d’un ensemble de prédicats relatifs aux entités
conceptuelles de façon à fournir une image cohérente de la réalité.
Les contraintes ci-après sont présentées selon la syntaxe de la norme SQL3.
7.1 Contrainte d’unicité de valeur (UNIQUE)
Une contrainte d’unicité de valeur assure l’unicité de valeurs d’une ou de
plusieurs colonnes pour chacun des enregistrements d’une table.
La contrainte d’unicité est réalisée par un index ; chaque entrée de l’index est défini comme
unique.
La clé secondaire unique et non nulle (l’identifiant naturel de la modélisation conceptuelle)
est réalisée pour sa première partie par une contrainte d’unicité.
7.2 Contrainte de valeur non nulle (NOT NULL)
Une contrainte de valeur non nulle assure la présence obligatoire de valeurs
d’une ou de plusieurs colonnes pour chacun des enregistrements d’une table.
La clé secondaire unique et non nulle (l’identifiant naturel de la modélisation conceptuelle)
est réalisée pour sa deuxième partie par une contrainte de valeur non nulle.
3
SQL - Strutured Query Language / Langage d’interrogation structuré
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
13/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
7.3 Contrainte de clé primaire (PRIMARY KEY)
Une contrainte de clé primaire assure la présence obligatoire de valeurs
discriminantes et stables d’une ou de plusieurs colonnes pour chacun des
enregistrements d’une table.
Une contrainte de clé primaire est construite théoriquement à partir des contraintes de base
suivantes:
• Contrainte d’unicité de valeur (UNIQUE)
• Contrainte de valeur non nulle (NOT NULL)
• Contrainte d’interdiction de changement de valeur (ou un automatisme de mise à jour en
cascade en cas de changement mais, en violation des règles de Codd).
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
14/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch
7.4 Contrainte d’intégrité référentielle stricte (FOREIGN KEY,
REFERENCE)
Une contrainte d’intégrité référentielle stricte assure la cohérence de la
dépendance fonctionnelle entre la clé primaire de la table source et la clé
étrangère de la table cible.
Source
Cible
•
•
Un enregistrement enfant ne doit pas pouvoir référer un enregistrement
parent inexistant.
La suppression d’un enregistrement parent ne doit pas laisser
d’enregistrements enfants orphelins.
Lors de la manipulation de données, une contrainte d’intégrité référentielle stricte implique
que le SGBD effectue les contrôles de cohérence suivants :
•
En cas d’ajout ou de modification d’enregistrement de la table cible ou enfant, la
valeur de la clé étrangère doit exister comme valeur de clé primaire de la table source
ou parent.
Dans l’exemple ci-dessus, nous ne devrions pas pouvoir créer un enregistrement de la
table Enfants en mettant comme valeur de clé étrangère 102 car il n’existe pas
d’éducatrice dotée de cette valeur de clé primaire.
•
En cas de suppression d’enregistrement de la table source ou parent, la valeur de la clé
primaire ne doit être référencée dans aucune clé étrangère de la table cible ou enfant.
Dans l’exemple ci-dessus, nous ne devrions pas pouvoir supprimer l’enregistrement
AO Orange Aurélie de la table Educatrices car elle est référencée par l’enfant
Nathan.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
160. Modélisation logique des données
15/15
4.10.2005/ P-A. Sunier
http://lgl.isnetne.ch