Modéliser une BDD grâce à UML

Présentation de UML

Signifiant Unified Modeling Language, ce qui se traduit par Langage de Modélisation Unifié, UML est en langage ayant pour but de représenter sous forme d’une modélisation graphique la conception d’un logiciel, le fonctionnement d’un système ou tout processus, d’une façon normée.

Norme UML

Conventions de nommage

Élément	Singulier / pluriel	Accents	Casse	Exemple
Classe	Singulier	Non	PascalCase	MethodePaiement
Attribut	Singulier	Non	camelCase	montantLimite

Représentation des classes et de leurs associations

Les classes

• Une classe est représentée par un rectangle contenant le nom de l’objet.
• Il peut n’y avoir que le nom, ou bien le nom et, séparé par un trait, la liste des propriétés.
• Il existe les classes d’associations, issues d’une association many-to-many (voir ci-dessous).

Association de classes

• Une association entre deux classes est représentée par un trait reliant le rectangle de chacune des deux classe. Un titre, généralement un verbe, peut être apposé sur ce trait.
• Un libellé peut être également être apposé de chaque côté du trait afin d’indiquer le rôle d’une classe envers l’autre. Par exemple, entre une classe Livre et une classe Personne, on pourrait avoir lisible et lire : un livre est lisible par une personne, une personne est lecteur d’un livre.

Multiplicités sur les associations de classes

Elles permettent de définir les limites basses et hautes d’une association entre deux classes. Par exemple, un livre a minimum 1 auteur, mais peut en avoir plusieurs. Livre peut avoir un nombre infini de lecteurs, mais peut n’en avoir aucun.

On distingue 3 grandes catégories d’associations :

• Association one-to-one. C’est lorsque la limite haute est 1 de chaque côté. Par exemple, un n° d’abonné n’appartient qu’à une personne et une personne n’a aucun ou 1 n° d’abonné.
  • 0..1 : Aucune ou une seule association.
  • 1..1 : Une et une seule association. Souvent simplifié en 1.
• Association one-to-many ou many-to-one. C’est lorsque la limite haute est 1 d’un côté et plus de 1 de l’autre côté.
  • 0..* : Aucune ou une infinité d’associations.
  • 1..* : Une ou une infinité d’associations.
• Association many-to-many. C’est lorsque la limite haute est plus de 1 de chaque côté.
  • x..x : X associations forcément, ni plus ni moins.
  • y..z : Au moins Y associations et maximum Z.
• Cas particulier : 0..0 : Aucune association. Souvent simplifié en 0.

Les formes normales

Les formes normales (abrégées FN en français, NF en anglais) sont des règles ayant pour but d’assurer la cohérence de structuration des données, de limiter (si ce n’est d’empêcher totalement) la duplication de données, de garantir une évolutivité simple de la structure des données.

• 1NF : Chaque attribut doit être atomique, c’est-à-dire ne contenir qu’une seule valeur. On s’interdit donc de stocker par exemple le nom et le prénom dans un même attribut.
• 2NF : Si la clé primaire est un agrégat de plusieurs attributs, aucun autre attribut que ceux composants la clé ne doit dépendre d’un seul attribut composant la clé. Par exemple, une entité représentant le contenu de livraisons avec des identifiants de livraisons et de produits et pour chaque produit la quantité, il ne doit pas y avoir la date de livraison. Elle n’a pas sa place dans cette association, mais dans la classe livraison directement.
• 3NF : Dans une classe, un attribut ne composant pas la clé primaire ne doit pas dépendre d’un autre attribut ne composant pas non plus la clé primaire. Par exemple, une classe représentant des produits avec un identifiant, un nom, une taille, une couleur… ne doit pas avoir un attribut indiquant si le produit est plutôt clair ou foncé. Cette information devrait être dans une entité Couleur définissant la couleur, l’aspect clair/foncé, autres… et cette classe serait associée au produit.

Afin d’éviter la duplication de données, on appliquera également un découpage visant à regrouper entre eux des attributs représentant un élément identifiant de manière isolé. Par exemple, une adresse postale. On évitera de stocker la rue + le code postal + la ville + le pays directement dans une entité Client, car la gestion d’adresses postales est factorisable entre plusieurs entités. On préférera disposer d’une table d’adresse postales, liées à de multiples entités, avec une gestion factorisée, des normes et un formalisme cohérents. Cela limitera également le nombre d’attributs dans chaque classe et évitera de les dupliquer.