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 4.1 Bases... 4 4.2 Relations identifiantes... 5 4.3 Table associative... 6 5 Notation... 7 5.1 Notation au niveau des colonnes... 7 5.2 Notation au niveau des relations... 8 6 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 logique 1. 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 (Unique). 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
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