Modéliser les données avec MySQL Workbench

Puisqu'on s'intéresse à la modélisation des données, il n'est pas inutile de rappeler quelques concepts du niveau sémantique, à savoir les différents types d'entités (entités-types).

Je fais ici référence à RM/T (Relational Model / Tasmania) de Ted Codd, qui développa ses idées sur la modélisation sémantique à partir du Modèle Relationnel de Données (cf. son article de 1979, Extending the Database Relational Model to Capture More Meaning). Le tenant de Merise ou d'UML saura faire le rapprochement entre les entités-types de Codd et les types d'entités ou classes qui lui sont familiers.

Codd classe les entités-types (types d'entités) de cette façon :

— L'entité-type forte, qu'il nomme Kernel,

— L'entité-type faible (Characteristic),

— L'entité-type associative (Associative).

Par ailleurs, chacune de ces entités-types peut jouer le rôle de surtype (supertype) ou de sous-type (subtype) par rapport à une entité-type de même nature : une entité-type forte peut être sous-type d'une autre entité-type forte, une entité-type faible peut être sous-type d'une autre entité-type faible et une entité-type associative peut être sous-type d'une autre entité-type associative. Signalons que MySQL Workbench ne propose pas formellement les concepts de surtype et de sous-type, mais on sait s'en arranger et ce sujet est abordé au paragraphe 6.

Une entité (instance, occurrence) de ce type est autonome, insensible aux stimuli qui pourraient provoquer son altération, émis par des entités qui entretiennent des relations avec elle, en conséquence de quoi ces stimuli feraient l'objet d'un refus énergique de la part de cette entité s'ils conduisaient à sa destruction. Imaginons que l'entreprise Dubicobit vende des savonnettes et que chacun de ses clients réside dans une commune. Le concepteur aura rédigé une règle de gestion des données ressemblant à ceci :

D'où la représentation simple mais parlante, bien connue des habitués du forum Schéma chez DVP :


        [CLIENT]--1,1----(RÉSIDER)----0,N--[COMMUNE]


Ou dans le forum UML :

                                    Résider
        [CLIENT]--0..N------------------1--[COMMUNE]


Si on supprime le client Raoul qui réside dans la commune de Morzy-les-Joyeuses, celle-ci n'en est pas avertie et reste donc parfaitement insensible à la disparition de ce malheureux Raoul.

Si c'est une commune qu'on cherche à supprimer, par exemple Yadupour, et si aucun client n'y réside, pas de problème. En revanche, si au moins un client y réside, changement de chanson, l'opération doit échouer : les clients résidant dans cette commune sont sensibles au stimulus qui leur parvient et sont en droit de juger l'action parfaitement déplacée, ils réagissent donc vigoureusement et négativement, forçant le système à leur donner raison.¹

______________________________________________

¹ Les habitués de SQL auront reconnu la mise en œuvre pour cela de l'option RESTRICT (ou NO ACTION) utilisée dans le contexte de l'intégrité référentielle :

    CREATE TABLE CLIENT ... 
        FOREIGN KEY (CommuneId) REFERENCES COMMUNE ON DELETE RESTRICT ...

Une entité de ce type n'est jamais qu'une propriété multivaluée d'une entité plus forte qu'elle. Exemple, les lignes de facture constituent une propriété multivaluée d'une facture et, au nom de la normalisation (telle qu'énoncée par Codd dans son article fondateur de 1970, A Relational Model of Data for Large Shared Data Banks), ce genre de propriété fait l'objet d'une entité-type LIGNE_FACTURE, mais il n'en demeure pas moins que si l'on supprime une facture, ses lignes ne peuvent que disparaître avec elle, car n'ayant pas d'existence propre.


Représentation à la façon de Merise :


        [FACTURE]--1,N----(COMPOSER)----(1,1)--[LIGNE_FACTURE]


La cardinalité 1,1 côté LIGNE_FACTURE figure entre parenthèses : par convention, LIGNE_FACTURE est à considérer comme entité-type faible relativement à l'entité-type FACTURE. Ce procédé est emprunté à PowerAMC.

Avec WinDesign, la notation équivalente est la suivante :


        [FACTURE]--1,N----(COMPOSER)----1,1(R)--[LIGNE_FACTURE]


Dans le cas d'un diagramme de classes :


         [FACTURE] --1..N---------------1--[LIGNE_FACTURE]


Une entité-type faible peut être considérée comme forte par rapport à une autre entité-type. Par exemple, si chaque ligne de facture est composée d'engagements sur ligne de facture, on aura la représentation suivante (Power AMC) :


         [FACTURE]--1,N----(COMPOSER)----(1,1)--[LIGNE_FACTURE]--1,N----(GROUPER)----(1,1)--[ENGAGEMENT]

Comme son qualificatif l'indique, ce type d'entité permet d'associer deux entités-types selon une relation de plusieurs à plusieurs : au niveau logique (tabulaire, disons SQL), une entité-type associative donne lieu à une table. Par exemple, une ligne de facture peut être perçue comme associant une facture à un article. Dans le style merisien :


        [FACTURE]--1,N----(LIGNE_FACTURE)----0,N--[ARTICLE]


Au sens de Codd, LIGNE_FACTURE est une entité-type associative, tandis que FACTURE et ARTICLE peuvent être des entités-types fortes, faibles, associatives : pas de restriction (contrairement à ce qui se passe avec Merise qui traditionnellement n'admet pas les associations d'associations).