Vous êtes sur la page 1sur 28

Modèle Logique de Données

Règles de transformations vues à travers un exemple

Objectif
Pendant le cours d’analyse, nous avons vu comment
construire le modèle conceptuel des données d’un système
d’informations d’une entreprise
Nous devons valider ce MCD de façon à ce que toutes les
tâches automatisées soient réalisables

2/28
Règles de transformations vues à travers un exemple

L’objectif ici est de transformer ce MCD en quelque chose


de facilement intégrable au SGBD choisi pour réaliser
l’application.
Cette traduction doit permettre de conserver l’ensemble des
informations contenues dans le MCD (c.à.d. l’ensemble des
occurrences des entités et des associations du MCD) en
tenant compte des contraintes imposées sur les informations
(identifiants, cardinalités, CIF).

3/28
Règles de transformations vues à travers un exemple

Plusieurs types de formalisme sont possibles.


CODASYL pour les SGBD hiérarchiques ou réseaux.
Relationnel pour les SGBD relationnels.
Fichiers pour les langages de programmation généraux.
Le modèle relationnel, basé sur la théorie des ensembles, est le
plus répandu actuellement.

4/28
Règles de transformations vues à travers un exemple

L’objectif de ce chapitre est de décrire les étapes de


transformations nécessaires pour passer d’un MCD à un
ensemble de tables.
Une table est l’objet de base des SGBD relationnels, c’est
l’endroit où seront stockées les informations sous forme de
n-uplets

5/28
Règles de transformations vues à travers un exemple

Une table a un nom et un ensemble de définition composé


d’attributs
Exemple : la table ELEVE définie sur l’ensemble d’attributs
Num, Nom, Prénom Les éléments de cette table seront des
triplets composés d’un entier et de deux chaines de caractères.
(1234, Ikar, Léo) est une instance de la table ELEVE.
Chaque n-uplet correspondra à une occurrence d’une entité ou
d’une association du MCD.

Num Nom Prénom


1234 Ikar Léo
1235 Martin Julie
1236 Dupont Christophe

6/28
Règles de transformations vues à travers un exemple

On considère le MCD suivant relatif à la gestion d’un stock

RG1 : Nous voulons pouvoir retrouver le fournisseur d’un


produit vendu à un client.
RG2 : Un produit est fourni par un et un seul fournisseur à
une date donnée.
RG3 : Un produit a 3 types de conditionnement possibles :
Unité de 1 à 9, Demi-gros de 10 à 99 et Gros au delà de 100

7/28
Règles de transformations vues à travers un exemple

8/28
Règles de transformations vues à travers un exemple

Faire une table par entité

9/28
Règles de transformations vues à travers un exemple

Pour les CIF de dimension 2, mettre l’identifiant de l’objet


appartenant dans la table de l’objet appartenu

10/28
Règles de transformations vues à travers un exemple

Pour les autres associations, créer une table par association avec
comme attributs, les identifiants des entités associées par
l’association et les propriétés éventuelles portées par l’association

11/28
Règles de transformations vues à travers un exemple

Pour les autres associations, créer une table par association avec
comme attributs, les identifiants des entités associées par
l’association et les propriétés éventuelles portées par l’association

12/28
Règles de transformations vues à travers un exemple

Pour les autres associations, créer une table par association avec
comme attributs, les identifiants des entités associées par
l’association et les propriétés éventuelles portées par l’association

13/28
Règles de transformations vues à travers un exemple

Supprimer les tables qui ne comportent que des informations que l’on peut retrouver
dans d’autres tables. Cas type la table : DATE.

Pour la table FOURNISSEUR, les cardinalités 0-n nous indiquent que des fournisseurs peuvent ne jamais avoir

fourni d’article, il faut absolument conserver cette table pour conserver ces fournisseurs. 14/28
Règles de transformations vues à travers un exemple

Supprimer les tables qui ne comportent que des informations que l’on peut retrouver
dans d’autres tables. Cas type la table : DATE.

Les cardinalités nous indiquent qu’il ne peut y avoir que 3 conditionnements par produit et donc 3 prix. En ajoutant

les trois prix possibles dans la table PRODUIT, on peut supprimer la table FIXER PRIX. 15/28
Règles de transformations vues à travers un exemple

Chercher à diminuer le nombre de tables

Les cardinalités nous indiquent qu’il ne peut y avoir que 3 conditionnements par produit et donc 3 prix. En ajoutant

les trois prix possibles dans la table PRODUIT, on peut supprimer la table FIXER PRIX 16/28
Règles de transformations vues à travers un exemple

Regarder si les identifiants recopiés ne sont pas trop  gros 

Ici on va ajouter un identifiant au client Numéro client et remplacer Nom client et Prénom client par Numéro

client dans la table FACTURE


17/28
Règles de transformations vues à travers un exemple

Au final on obtient une un MLD avec 6 tables.

18/28
Règles de transformations vues à travers un exemple

Les cardinalités ont déjà été prises en compte dans la traduction du MCD en MLD.
Les identifiants permettront de définir les clés des tables. On peut retrouver plusieurs
fois le même attribut dans différentes tables du MLD, cela donnera naissance au clés
étrangères

19/28
Règles de transformations vues à travers un exemple

On va maintenant compléter les MLD pour le transformer en un MPD modèle


physique des données.
Pour cela on va ajouter à chaque attribut sa structure (DDD).
Si la même donnée apparaı̂t à différents endroit, elle doit avoir la même structure

20/28
Règles de transformations vues à travers un exemple

On va maintenant compléter les MLD pour le transformer en un MPD modèle


physique des données.
Pour cela on va ajouter à chaque attribut sa structure (DDD).
Si la même donnée apparaı̂t à différents endroit, elle doit avoir la même structure

21/28
Règles de transformations vues à travers un exemple

On va maintenant repérer les identifiants (entité et association)

22/28
Règles de transformations vues à travers un exemple

Diminuer les identifiants pour les associations comportant des cif


de dimension 3 ou plus

23/28
Règles de transformations vues à travers un exemple

Repérer les clés étrangères (identifiant d’une table utilisé comme


attribut d’une autre table

24/28
Règles de transformations vues à travers un exemple

Créer un script SQL de création de la base de données.


CREATE TABLE NOMDETABLE (Attribut type, ...., constraintes)

create table client( create table produit(


numcl varchar2(5), reference varchar2(5),
nomcl varchar2(15), designation varchar2(15),
prenomcl varchar2(15), prixUnit number(4,2),
adressecl varchar2(30), prixDemiGros number(4,2),
primary key (numcl)); prixGros number(4,2),
constraint pkProd primary key(reference));
create table facture(
numfact varchar2(15), create table composer(
datefact date, numfact varchar2(15),
montant_total number(8,2), reference varchar2(5),
numcl varchar2(5), quantite number(4),
primary key (numfact), constraint pkComp primary key (numfact, reference),
foreign key (numcl) references constraint fkCompFact foreign key (numfact) references
client(numcl)); facture(numfact),
constraint fkCompProd foreign key (reference) references
create table fournisseur( produit(reference));
nomfournisseur varchar2(15),
primary key(nomfournisseur)); create table fournir(
reference varchar2(5),
nomfournisseur varchar2(15),
DateAchat date,
constraint pkFournir primary key(reference, nomfournisseur),
constraint fkFournirProd foreign key (reference) references
produit(reference),
constraint fkFournirFourn foreign key (nomfournisseur) references
fournisseur(nomfournisseur)); 25/28
Règles de transformations vues à travers un exemple

Supprimer les tables avant de les créer

Drop table fournir ;


Drop table composer ;
Drop table produit ;
Drop table fournisseur ;
Drop table facture ;
Drop table client ;

create table client(


numcl varchar2(5),
nomcl varchar2(15),
prenomcl varchar2(15),
adressecl varchar2(30),
primary key (numcl));

...
26/28
Règles de transformations vues à travers un exemple

Insertion de valeurs dans les tables.

insert into client values(’123C’, ’Dupont’, ’Leo’, ’Olivet’);


insert into facture values(’45ERT32864F’, to_Date(’14/10/2014’, ’DD/MM/YYYY’),
124.5, ’123C’);
insert into produit values(’ch987’, ’Chaise’, 62, 56, 52.55);
insert into fournisseur values(’Meuble bio’);
insert into composer values(’45ERT32864F’,’ch987’, 10);
insert into fournir values(’ch987’,’Meuble bio’,
to_Date(’13/10/2014’, ’DD/MM/YYYY’));

27/28
Règles de transformations vues à travers un exemple

Conclusion

A partir d’un MCD, nous pouvons obtenir un script de


création de la base de données de façon automatique.
Quelques adaptations peuvent être faites.
Plus votre travail de réflexion sur le MCD sera poussé, plus
votre base de données sera solide

28/28