Introduction à la modélisation 2

Nous avons déjà vu les points suivants :

• La réalité de l'organisation et la
• La démarche de modélisation et la représentation d'une BDD
• Les définitions de Valeur, Donnée et Concept et de dépendance fonctionnelle

La schématisation des données se fera dans des sous-parties suivantes et la modélisation des traitments dans un autre chapitre.

Sommaire sommaire :

• Représentation des modèles : schématisation normalisée et (autres) définitions fondamentales

En fait, il n'y a plus vraiment de guerre, le modèle UML (Universal Modelling Language) a supplanté le modèle Franco Français Merise.
Mais Merise fait de la résistance car de nombreuses entreprises l'utilisent encore … le poids de l'histoire!
Par ailleurs, ce modèle fait toujours référence pour la construction des bases de données classiques orientées SQL. Ce sont ces bases que nous allons voir.

Le modèle UML n'est pas en reste et permet aussi de faire des modèles de bases de données mais encore bien plus avec un symbolisme assez facile à comprendre même si déroutant quand on vient de Merise.

Ici, je vais présenter Merise. Cependant, il faut absolument aussi maîtriser UML. Donc …

Niveaux de modélisation

Ce qui rassemble les modèles, c'est la multitude de schémas et diagrammes et le nombre de niveaux de modélisation plus ou moins utilisés.
Il ressort cependant trois niveaux principaux dont voici les mots-clés :

• le niveau conceptuel, le plus élevé qui permet de comprendre comment les classes et entités sont liées et dépendent les unes des autres, comment les entités sont construites et associées entre elles.
• le niveau logique : qui montre l'organisation des objets et les messages (informations) qu'ils échangent, les relations entre les propriétés (attribut ou champs), assez proche des tables mais encore abstrait
• le niveau physique : les données et leur structuration, les tables, les enregistrements ou lignes, les clés primaire ou étrangères, les champs ou colonnes, les valeurs, les requêtes SQL

En pratique :

• Au niveau physique, nous aurons les tables.
  Une table contient des champs avec des données élémentaires et se présente un peu comme un tableau de tableur.
  Pour modéliser, on retient la liste des noms des colonnes. (easy!)
• Au niveau conceptuel, nous aurons, pour :
  • Merise : une entité ou une association contenant des attributs pour chaque table et des liens porteurs de cardinalités.
    Entité : titre et liste des propriétés de l'entité, champ(s) ayant le rôle de clé primaire.
  • UML : Une classe ou pseudo classe pour chaque table et des liens valués.
    Classe : nom, liste des attributs (nom, type, éventuellement leur accessibilité (privé, public, ..)) et une liste d'opérations que l'on peut effectuer sur les objets de la classe (case vide en bas de l'entité).

Quelques ressources :

• Merise : La méthode MERISE (Principes) (PDF)
• UML : UML en français (WWW)

Gescom gère des clients dont on connaît le nom, l'adresse et la ville et auxquels elle a attribué un identifiant unique pour distinguer les homonymes.
Gescom gère les commandes des clients à l'aide des tables suivantes (extrait)

Niveau physique : tables (extrait) et SQL

Le niveau physique dépend du système utilisé. Il permet aussi de connaître le type de stockage (ici un SGBDr comme MariaDB ou Mysql).

Les clients

La valeur de l'identifiant idClient est unique pour chaque client. C'est la clé primaire.

Les commandes des clients

La colonne idClient contient des valeurs qui doivent exister dans la colonne idClient de la table des clients.
C'est grâce à cette relation de dépendance qu'on peut retrouver le client de chaque commande.

Les articles

Chaque article possède un code unique (codeArticle). C'est l'identifiant pour chaque article.

Les articles contenus dans les commandes (association contenir)

• Le couple (numéro,codeArticle) doit être unique pour chaque ligne car il représente l'identifiant de chaque ligne.
• Chaque champ du couple référence une valeur dans le champ correspondant des tables commande et article.

Requêtes de création des tables précédentes

La base de données est créé par des requêtes qui reprennent les tables et leurs champs.

CREATE TABLE Client( idClient INT NOT NULL, nom VARCHAR (50), adresse TEXT, cp VARCHAR (10), ville VARCHAR (50), pays INT NOT NULL,
   PRIMARY KEY (idClient)
);
 
CREATE TABLE Commande( numero INT NOT NULL, dateCde DATE NOT NULL, idClient INT NOT NULL,
   PRIMARY KEY (numero),
   FOREIGN KEY (idClient) REFERENCES Client(idClient)
);
 
CREATE TABLE Article( codeArticle VARCHAR (20) NOT NULL, description VARCHAR (50), prixUnHT DECIMAL (15,5), poids DECIMAL (9,2), type INT NOT NULL,
   PRIMARY KEY (codeArticle)
);
 
CREATE TABLE contenir( numero INT NOT NULL, codeArticle VARCHAR (20) NOT NULL, qté DECIMAL (9,2),
   PRIMARY KEY (numero, codeArticle),
   FOREIGN KEY (numero) REFERENCES Commande(numero),
   FOREIGN KEY (codeArticle) REFERENCES Article(codeArticle)
);

Les requêtes d'insertions des données ne sont pas écrites ici.

Niveau logique : on dessine les tables et les liens de clés étrangères (SLD)

Schéma relationnel des tables et requêtes sql précédentes

Le schéma relationnel reprend les tables et indique les clés primaires identifiant chaque ligne et les relation de dépendance des valeurs des clés étrangères.
Il fait partie du modèle logique des données (MLD)

client(idClient, nom, adresse, cp, ville, pays)  
	clé primaire : idClient
 
commande(numero, dateCde, idClient, statut)  
	clé primaire : numero  
	clé étrangère : l'attribut idClient est en dépendance de référence avec l'attribut idClient de la relation client.
 
article(codeArticle, description, prixUnHT, poids, type)  
	clé primaire : codeArticle
 
contenir(numero, codeArticle, qté)  
	clé primaire : numero, idClient  ; le couple est la clé primaire
	clé étrangère : numero référence numero dans commande.
	clé étrangère : codeArticle référence codeArticle dans article.

Le schéma relationnel précédent est transformé en schéma logique de données. les relations deviennent des rectangles

Autres notions du modèle de données : forme normale, Boyce-Codd, algèbre relationnelle, privilèges CIMS.
A mettre en parallèle avec le modele organisationnel des traitements (MOT ou MOTa) et le diagramme événements/résultats décrivant les traitement et leur enchaînement ou les cas d'utilisation UML.

Niveau conceptuel : les relations deviennent des entités ou associations (SCD)

On dessine les entités à partir des relations dont la clé primaire n'est pas aussi une clé étrangère.
La clé primaire de la relation contenir ne contient pas de champ propre (qui n'est pas clé étrangère). Elle devient donc une association dans le SCD/MCD.

Les cardinalités représentent le nombre d'associations que peut avoir chaque ligne d'une entité avec une ou plusieurs autres lignes d'autres entités à travers une association.
Elles sont écrite sur les liens entre entités et asso.

Exemple : une commande n'a qu'un et un seul client (card = 1,1) ; un client peut avoir zéro à plusieurs commandes (card = 0,n).

Selon l'objet (entité ou association) à chaque bout des flèches du MLD, le lien portera une cardinalité différente.

Les cardinalités qui commencent par (1,...) équivalent à : "au moins un à ...."
Les cardinalités qui commencent par (0,...) équivalent à : "un ou aucun à ...."

Voici donc la fin d'un petit aperçu de la modélisation.
Pour aller plus loin, il faudrait revoir la théorie et passer du texte à la base de données.