Embedded Files
Le livre est organisé en 5 parties :
1. Introduction
L'introduction fixe le vocabulaire et présente les traits généraux de la démarche de modélisation.
2. Bases du modèle relationnel
Cette deuxième partie est le cœur du livre. Elle présente de manière détaillée les bases du modèle relationnel.
3. Normalisation
Cette partie présente le processus de normalisation qui permet au modélisateur de s’assurer que la structure de données du modèle relationnel est correctement élaborée.
4. Transformation du MCD en utilisant les contraintes structurelles du MLD-R
Cette quatrième partie relève de l’ingénierie. Elle présente les règles usuelles de transformation d’un modèle conceptuel de données (MCD) en un modèle logique de données relationnel (MLD-R).
5. Transformation du MCD en utilisant les contraintes déclaratives du MLD-R
Cette dernière partie relève, comme la précédente, de l’ingénierie. Elle présente des règles de transformation d’un modèle conceptuel de données (MCD) en un modèle logique de données relationnel (MLD-R).
En utilisant des contraintes déclaratives plutôt que des contraintes structurelles, le MLD-R est susceptible de supporter plus facilement des changements de règles de gestion.
Introduction
Introduction
Le lecteur voudra bien se référer à l'introduction du livre "Modèle conceptuel de données" qui est identique hormis l'introduction au modèle logique de données relationnel que nous résumons ci-après :
Modèle logique de données relationnel (MLD-R)
Un MLD-R est conçu à partir des éléments suivants :
- Les tables qui représentent des conteneurs de données.
- Les clés primaires qui permettent d’identifier sans ambiguïté toute ligne de table.
- Les clés étrangères qui réalisent les relations entre tables.
- Les colonnes de tables qui représentent des conteneurs de données élémentaires
Bases du modèle relationnel
Bases du modèle relationnel
Table
- Type de données
Clé
- Clé primaire
- Clé étrangère
- Clé secondaire
Contrainte
- Valeur non nulle
- Unicité
- Clé primaire
- Clé étrangère
Relation (clé étrangère)
- Multiplicité / Cardinalité
- Degré de relation
- Relation réflexive
- Relation identifiante
Formes de table
- Table indépendante
- Table dépendante
- Table associative
Traçabilité
- Colonnes d'audit
Une table est une représentation mathématique d'un ensemble ou d'une entité du modèle conceptuel où :
- Les colonnes représentent les attributs des éléments de l'ensemble ou de l'entité.
- Les lignes ou tuples représentent les éléments de l'ensemble ou les occurrences de l'entité
Les colonnes, tout comme les attributs des entités du modèle conceptuel, sont caractérisées par un type de données. Un type de données définit, plus ou moins universellement, une nature de données.
Pour ce cours, nous nous appuierons sur la typologie proposée par l'ANSI pour le langage SQL...
Toute table du modèle relationnel est dotée d'une seule et unique clé primaire ; une clé primaire est un identifiant technique qui permet de distinguer sans équivoque chaque ligne de la table. La clé primaire est constituée d'une ou plusieurs colonnes ; cette ou ces colonnes constitutives de la clé primaire sont marquées du stéréotype «PK»...
Une clé étrangère est formée d'une ou de plusieurs colonnes qui réfèrent un tuple ou une ligne dans une autre table ou au sein de la même table. Une table peut avoir plusieurs clés étrangères. La référence doit se faire sur la clé primaire de la table référée (parent). Il y aura dans la table référençant (enfant ou source de dépendance) autant de colonnes qu'il y en a dans la clé primaire de la table référée (parent ou cible de dépendance). La valeur de chaque colonne de clé étrangère doit correspondre à une valeur de colonne de clé primaire correspondante dans la table référée...
La clé secondaire est un concept quelque peu désuet. Historiquement, elle servait à spécifier la création d'index d'accès à un ou des enregistrements. Actuellement, la création d'index, au niveau des bases de données relationnelles, est tellement aisée que l'utilisation de la notion de clé secondaire tend à disparaître et n'est, en principe, plus modélisée au niveau logique. Une clé secondaire est formée d'une ou de plusieurs colonnes. Une clé secondaire n'est pas obligatoirement discriminante ; plusieurs tuples peuvent avoir une même clé secondaire. Un attribut de clé secondaire peut être nul...
Une contrainte est une condition que doit satisfaire tout ou partie d'une table. Chaque contrainte doit être nommée ; son nom sera unique et associé à un message d'erreur. En cas de violation, le message d'erreur devrait être affiché par l'interface utilisateur en lieu et place du nom de la contrainte...
La contrainte s'applique à une colonne. Par défaut, La valeur d'une colonne non renseignée est nulle et reconnue comme telle avec le mot-clé NULL.
La contrainte NOT NULL interdit l'enregistrement d'une valeur nulle...
La contrainte d'unicité s'applique à une ou plusieurs colonnes. La contrainte d'unicité, UNIQUE, interdit la saisie de valeurs redondantes pour une colonne ou plusieurs colonnes formant un tout...
La contrainte de clé primaire s'applique à une ou plusieurs colonnes ; la plupart des systèmes de gestion de bases de données relationnelles, abrégés SGBD-R, offrent une solution de gestion automatisée des clés primaires et de leur obligation de valeur non nulle, d'unicité et de stabilité.
La contrainte de clé primaire, PRIMARY KEY, inclut :
- la contrainte de valeur non nulle, NOT NULL, pour chacune des colonnes constitutives ;
- la contrainte d'unicité, UNIQUE. De plus, elle assume que les valeurs de chacune des colonnes constitutives ne soient jamais modifiées, ce que nous nommons la stabilité.
La stabilité de la clé primaire est indispensable à garantir la pérennité des relations entre tables. En effet, la cible d’une relation ne saurait être modifiée au risque d’avoir une source invalide...
La contrainte de clé étrangère, FOREIGN KEY, assume l'intégrité du référencement de la ou des colonnes de clés étrangères lors de manipulations de données :
- En cas d'ajout ou de modification au sein de la table référençant, le SGBD-R vérifie que le tuple ou la ligne référencée existe dans la table de référence.
- En cas de suppression ou de modification au sein de toute table, le SGBD-R vérifie qu'il n'y aura pas de tuple ou de ligne sans référence (orpheline) dans une table la référençant.
La cardinalité ou multiplicité dans la terminologie UML est un couple de nombres qui exprime la participation des tuples ou lignes d’une table à une relation avec une autre table....
Une cardinalité minimale de 0 est très souvent indispensable pour pouvoir créer un tuple sans être obligé de faire un lien avec un autre tuple...
Les valeurs de 1 sur les cardinalités sont contraignantes :
- La valeur de 1 pour la cardinalité minimale est une contrainte implicite stipulant qu'une lien doit exister.
- La valeur de 1 pour la cardinalité maximale est une contrainte implicite stipulant qu'un seul lien est possible.
Une relation est dite de degré 1:1 lorsque les cardinalités maximales des deux extrémités sont de 1.
Une relation est dite de degré 1:n lorsqu'un enregistrement de la table référencée (parent) peut avoir plusieurs enregistrements le référençant au sein de la table enfant.
Il ne peut pas y avoir de relation de degré n:n dans le modèle logique relationnel car les colonnes de clé étrangère ne peuvent contenir que des données atomiques référant un et un seul tuple de la table parent ou cible de la relation...
Une relation peut se faire au sein d’une même table. Nous parlons de relation réflexive...
La ou les colonnes constitutives d'une relation (contrainte de clé étrangère) peuvent constituer tout ou partie d'une contrainte de clé primaire ; une telle relation est qualifiée d'identifiante...
Nous qualifions d'indépendante une table dont la clé primaire est constituée de colonnes qui lui sont propres et ne proviennent pas d'une contrainte de clé étrangère...
Nous qualifions de dépendante une table dont la clé primaire est formée, en totalité ou partiellement, de la ou des colonnes constitutives d'une relation identifiante...
Une table associative est une table dont la clé primaire est formée des colonnes provenant de deux relations identifiantes ou plus. La clé primaire d'une table associative est formée des colonnes constitutives des clés étrangères des relations identifiantes...
Les éléments de traçabilité, et tout spécialement les tables de journalisation, ont pour seul et unique but d’améliorer la sûreté des logiciels de gestion en fournissant un mécanisme d’assurance en cas d’erreur des utilisateurs et/ou des développeurs...
- Les colonnes d'audit sont des données techniques que l'on rajoute à la structure de la table pour fournir quelques informations de traçabilité minimales. Couramment, il s'agit de 4 colonnes :CTRLAJUSER qui enregistre l'utilisateur qui a ajouté le tuple ;
- CTRLAJDATE qui enregistre les date et heure d'ajout du tuple ;
- CTRLMOUSER qui enregistre l'utilisateur qui a effectué la dernière modification du tuple ;
- CTRLMODATE qui enregistre les date et heure de la dernière modification du tuple.
- Journalisation
Nous pouvons assurer la traçabilité des manipulations de données en recourant à des éléments temporels ou autres. Il est alors possible de se déplacer dans le temps comme pour une vidéo que l’on avance ou recule. Toutefois, le traitement de ces éléments de traçabilité est fastidieux sans parler de la difficulté à les identifier.
En lieu et place, en parallèle ou en complément à la modélisation d'éléments de traçabilité, il est possible de tracer toutes les opérations de manipulation de données dans des tables de journalisation. Pour chaque table, nous créons une table de journalisation. Chaque manipulation qui est faite dans la table à journaliser fait l'objet d'un nouvel enregistrement dans la table de journalisation. Pour reprendre notre métaphore, cela consisterait à faire une photo lors de chaque changement et le journal serait un album de photos...
Normalisation
Normalisation
Transformation du MCD en un MLD-R en utilisant les contraintes structurelles du MLD-R
Transformation du MCD en un MLD-R en utilisant les contraintes structurelles du MLD-R
Concept
3 règles de bases
- 1ère règle
- 2ème règle
- 3ème règle
Règles de structures particulières
- Entité associative
- Entité dépendante
- Généralisation - spécialisation
Processus de transformation itératif
La transformation usuelle d'un modèle conceptuel de données en un modèle logique relationnel avec contraintes structurelles obéit à 3 règles de base :
- Toute entité devient une table.
- Toute association de degré 1:1 ou 1:n devient une contrainte de clé étrangère.
- Toute association de degré n:n devient une table associative.
A ces 3 règles de base, il y a lieu d'ajouter les règles de transformation de structures particulières, à savoir :
- Les entités dépendantes.
- Les entités associatives.
- Les entités dépendantes n:n.
- Les pseudos entités associatives.
- Les structures de généralisation et spécialisation.
De plus, la transformation devra se faire selon un processus itératif respectant les dépendances existantes entre entités...
Toute entité indépendante devient une table.Usuellement, le nom de la table est repris du nom de l'entité en le mettant au pluriel. Les attributs de l’entité deviennent des colonnes de la table...
Toute association binaire de degré 1:1 ou 1:n devient une contrainte de clé étrangère...
Toute association binaire de degré n:n devient une table associative...
En appliquant la 3ème règle de base (une association de degré n:n est transformée en une table associative), l'entité associative est partiellement transformée, il ne reste plus qu'à transformer les attributs de l'entité associative en colonnes de la table associative...
Une entité dépendante est transformée en une table et l'association identifiante est transformée en une relation identifiante...
Les entités généralisées et spécialisées sont transformées en tables. Les entités spécialisées deviennent des tables dépendantes sans identifiant propre.Les relations de spécialisation, est une sorte de , sont transformées en relations identifiantes entre tables...
En présence d'associations identifiantes, d'entité associatives ou encore d'entités spécialisées, la transformation doit se faire de manière itérative. En effet, les tables cibles de relations identifiantes doivent exister pour pouvoir créer les colonnes de clé étrangère dans les tables sources ; la ou les colonnes de clé étrangère doivent être conformes à la contrainte de clé primaire de la table cible à laquelle ou auxquelles elles se réfèrent.
Les associations identifiantes, les entités associatives ou encore les associations de spécialisations peuvent s'imbriquer et ainsi une table cible de relation identifiante peut être elle-même source d'une relation identifiante. Dès lors nous proposons le modèle de processus suivant pour effectuer une transformation garantissant un traitement correct de dépendances imbriquées :
- Une initialisation qui consiste à créer les tables initiales ou racines du ou des graphes de dépendance à partir des entités indépendantes.
- Un traitement itératif des dépendances.
- Une finalisation consistant à créer les contraintes de clés étrangères pour les associations qui ne sont ni identifiantes, ni de degré n:n.
Transformation du MCD en un MLD-R en utilisant les contraintes déclaratives du MLD-R
Transformation du MCD en un MLD-R en utilisant les contraintes déclaratives du MLD-R
Concept
La transformation se fait usuellement en mettant à profit les relations identifiantes du modèle logique relationnel. Toutefois, l’utilisation de relations identifiantes pose des contraintes structurelles qui peuvent s’avérer bloquantes dans la perspective de l’évolution future de notre modèle logique relationnel.
Pour donner aux modèles logiques relationnels un plus grand degré de liberté d’évolution, il est possible de renoncer aux relations identifiantes et de les remplacer par des relations non identifiantes. Pour ne pas perdre de sémantique, cela implique de mettre les contraintes déclaratives suivantes :
- Le stéréotype «M» ou le stéréotype «NID-x» pour indiquer l’obligation de valeur de chaque colonne de clé étrangère des relations non identifiantes de remplacement.
- Le stéréotype «NID-x» ou l’opération UML unique() pour indiquer l’unicité de la relation non identifiante, seule ou en conjonction avec d’autres éléments.
Les 2 premières règles de base de la transformation avec contraintes structurelles s’appliquent à l’identique à la transformation avec contraintes déclaratives :
- Toute entité indépendante devient une table.
- Toute association de degré 1:1 ou 1:n devient une contrainte de clé étrangère.
La 3ème règle est modifiée comme suit :
- Toute association de degré n:n devient une table indépendante dotée d’une contrainte d’unicité simulant le produit cartésien...
Google Sites
Report abuse