Visual Paradigm Réaliser un modèle logique de données (MLD)

27.02.2013
p.a. sunier
Visual Paradigm
Réaliser un modèle logique de données (MLD)
Sommaire
1
Propos liminaires ............................................................................................................................. 2
2
Organisation du projet ..................................................................................................................... 2
3
Création des tables........................................................................................................................... 3
4
Création de relations ........................................................................................................................ 4
5
6
4.1
Bases........................................................................................................................................ 4
4.2
Relations identifiantes ............................................................................................................. 5
4.3
Table associative ..................................................................................................................... 6
Notation ........................................................................................................................................... 7
5.1
Notation au niveau des colonnes ............................................................................................. 7
5.2
Notation au niveau des relations.............................................................................................. 8
Webographie ................................................................................................................................... 9
1 Propos liminaires
Dans le cadre de la démarche méthodologique [2] que nous appliquons, inspirée du Processus unifié
(UP), nous ne concevons pas de modèle logique de données (MLD). Le MLD est créé
automatiquement à partir de la transformation du modèle conceptuel de données(MCD), seul un
enrichissement est, éventuellement, réalisé.
Toutefois, il arrive que les concepteurs de logiciels de gestion fassent l'impasse sur le MCD et
démarrent l'analyse des données à partir du niveau logique1. Ce document est réalisé dans cette
optique.
2 Organisation du projet
Il vous faut commencer par créer un projet pour chaque modèle que vous devez réaliser, que le modèle
soit issu d’un exercice dans un cadre scolaire ou issu d’un besoin de décrire les données d’un système
d’information ou d’un logiciel particulier. [Plus de détails au chapitre : Les bases – Notion de
référentiel]
La modélisation des données et la création des
différents diagrammes de visualisation s’effectue au
sein du répertoire Database Modeling de votre projet.
Le sous-répertoire Entity Relationship Diagramm
contiendra les diagrammes logiques (tables…) ; pour
rappel, les objets de modélisation eux-mêmes sont
hors du périmètre des diagrammes et existent pour
eux-mêmes au sein du référentiel.
Contrairement à ce que la traduction littérale de
Entity Relationship Diagram laisse à penser ces diagrammes ne sont pas des représentations des
modèles Entités-Associations (MCD) mais, bien des modèles logiques de données sous forme de
tables de bases de données relationnelles avec des contraintes de clés étrangères et autres.
1
Nous déconseillons vivement de commencer l'analyse des données avec un modèle logique; le modèle
conceptuel permet de se concentrer sur les concepts en faisant abstraction des solutions de mise en œuvre qui
peuvent influencer le travail de conception.
Page 2
3 Création de tables
Après avoir créé une table, vous pourrez lui attribuer ses colonnes et définir les caractéristiques de
celles-ci.
Page 3
4 Création de relations
4.1 Bases
Vous créez une relation en tirant une "association" Relationship entre deux tables.
Par défaut, la colonne de clé étrangère sera nommée en concaténant le nom de la table parent et sa
colonne de clé primaire.
Vous pouvez renommer la colonne de clé étrangère à votre convenance.
Page 4
Une relation obligatoire se traduit par une colonne de clé étrangère obligatoire; ci-après, nous avons
rendu la relation entre Educatrices et Enfants optionnelle; la colonne de clé étrangère peut être nulle.
L'optionalité de la relation s'observe aussi par le symbole O du côté Educatrices en lieu et place du
symbole │.
4.2 Relations identifiantes
Une relation peut être qualifiée d'identifiante; une relation identifiante est dessinée en trait plein et la
colonne de clé étrangère devient partie de la clé primaire.
Page 5
4.3 Table associative
Une table associative est identifiée par deux relations identifiantes ou plus; une table associative
permet de réaliser une relation de degré n:n.
Page 6
5 Notation
Le modèle relationnel ne respecte pas le symbolisme UML, il est propre à Visual Paradigm mais,
néanmoins, inspiré d'éléments provenant de la modélisation conceptuel des données de l'approche
fonctionnelle des années 1970 et des us et coutumes de la modélisation des bases de données
relationnelles.
5.1 Notation au niveau des colonnes

La clé primaire est représentée par le symbole d'une clé

La clé étrangère est représentée par le symbole d'une flèche
.
.
Si la relation est identifiante, la clé étrangère devient partie de la clé primaire; la clé étrangère
est alors représentée par le symbole combiné de flèche et de clé

Une colonne non obligatoire est représentée par le symbole
.
(sans ce symbole les colonnes
sont dotées de la contrainte Not Null).

Une contrainte de colonne unique est représentée par le symbole

Les types de données des colonnes proviennent du choix de la base de données relationnelle
cible de la génération du code SQL-DDL.
Page 7
(Unique).
5.2 Notation au niveau des relations
Les cardinalités des relations sont représentées selon le symbolisme de Bachman. La cardinalité d'un
tuple de table se lit à l'opposé de la relation comme en UML.
La figure ci-après, reprise de la documentation Visual Paradigm, en donne d'une part la signification
et d'autre part l'équivalence qui peut être faite avec UML
Comme nous l'avons indiqué précédemment, les relations identifiantes sont dessinées en traits pleins
alors que les relations non identifiantes sont en traits tillés.
Page 8
6 Webographie
[1]
Cours de modélisation de systèmes d'information informatisés (SII) de gestion
http://lgl.isnetne.ch/modelisation-2005/index.htm
[2]
Les bases de modélisation du système d'information de l'entreprise
Eléments théoriques du cas pratique ArcPizzas.
http://lgl.isnetne.ch/BachelorII/Modelisation/BasesSI/BasesModelisationSI.pdf
Page 9