Apprendre les BDD relationnelles : Modèle Logique de Données (MLD)

Un modèle détaillé

Une fois notre MCD défini, le MLD va nous permettre de valider sa conformité.

Bien que lui aussi indépendant de toute implémentation physique ou logicielle, le MLD consiste à détailler l’implémentation pour un type de base de données spécifique.

Il ne s’agit pas encore de concevoir la base de données mais de l’implémenter selon un modèle spécifique ; relationnel en ce qui nous concerne. Nous y détaillerons ainsi entre autres nos clés primaires et étrangères.

Le MLD peut s’écrire sous forme textuelle ou via un diagramme ressemblant au MCD. Nous aborderons ici l’écriture textuelle, bien plus synthétique.

Règles de traduction d’un MCD en MLD

Détaillons les étapes permettant de traduire un MCD en MLD pour une base de données relationnelle. Considérons le MCD du chapitre précédent :

Traduction des termes

Un MLD se veut détailler l’implémentation de la base de données pour un modèle spécifique. Notre point de vue change naturellement et il nous faut dans un premier temps adapter notre champ lexical.

Entités -> tables

On réécrit sur chaque ligne nos entités en tant que tables à l’exception des entités relationnelles (Publie, Possède…).

On notera généralement le nom de la table en minuscules (lowercase), au pluriel et sans caractères spéciaux.

Une bonne pratique consiste d’ailleurs à en profiter pour traduire ses entités en anglais, rendant le MLD plus unniversel.

avatars
users
comments
articles
categories

Exemple : Catégorie du MCD, devient categories dans un MLD.

Propriétés -> attributs

On spécifie pour chaque table ses attributs entre parenthèses. Il est désormais temps d’adopter une casse pour nos attributs. On utilise généralement la 🐍 snake_case.

En anglais, pour conserver la même convention de nommage.

avatars(id, path, is_valid)
users(id, email, password, registered_at, role)
comments(id, content, published_at)
articles(id, title, description, content, published_at)
categories(id, name)

Identifiants -> clés primaires

L’identifiant est désormais appelé « clé primaire ». Il doit être le premier attribut listé et être souligné.

avatars(i̲d̲, path, is_valid)
users(i̲d̲, email, password, registered_at, role)
comments(i̲d̲, content, published_at)
articles(i̲d̲, title, description, content, published_at)
categories(i̲d̲, name)

Traduction des relations

Du côté de nos relations, il est temps d’implémenter les notions de clés étrangères et de tables de liaison.

1:1 : création d’une clé étrangère

L’entité relationnelle disparaît pour laisser place à une clé étrangère qui sera soumise à une contrainte d’unicité. La table propriétaire de la clé étrangère est :

• La table de notre choix si la relation est de même cardinalité des deux côtés (0,1 et 0,1 ou 1,1 et 1,1)
• La table pouvant avoir une multiplicité nulle si la relation est facultative (0,1 et 1,1 et inversement)

avatars(i̲d̲, path, is_valid, #user_id)
users(i̲d̲, email, password, registered_at, role)
comments(i̲d̲, content, published_at)
articles(i̲d̲, title, description, content, published_at)
categories(i̲d̲, name)

Dans cet exemple :

#user_id dans avatars

• « Un Utilisateur Upload au moins 0 et au plus 1 Avatar »
• « Un Avatar Est uploadé par au moins 1 et au plus 1 Utilisateur »

avatars est donc le côté potentiellement nul de la relation, c’est lui qui contient la clé étrangère #user_id

1:n : création d’une clé étrangère

L’entité relationnelle disparaît pour laisser place à une clé étrangère dans la table se trouvant du côté n de la relation.

Une clé étrangère est généralement désignée par le nom de la table qu’elle référence (au singulier - car elle référence un enregistrement précis de cette table), suivi de _id. On la préfixera d’un # (« hashtag »). Exemple : #user_id

avatars(i̲d̲, path, is_valid, #user_id)
users(i̲d̲, email, password, registered_at, role)
comments(i̲d̲, content, published_at, #user_id, #article_id)
articles(i̲d̲, title, description, content, published_at, #user_id)
categories(i̲d̲, name)

Dans cet exemple :

#user_id dans comments

• « Un Utilisateur Publie au moins 0 et au plus n Commentaire »
• « Un Commentaire Est publié par au moins 1 et au plus 1 Utilisateur » comments est donc le côté n, c’est lui qui contient la clé étrangère #user_id

#article_id dans comments

• « Un Article Possède au moins 0 et au plus n Commentaire »
• « Un Commentaire Est possédé par au moins 1 et au plus 1 Article » comments est donc le côté n, c’est lui qui contient la clé étrangère #article_id

#user_id dans articles

• « Un Utilisateur Publie au moins 0 et au plus n Article »
• « Un Article Est publié par au moins 1 et au plus 1 Utilisateur » articles est donc le côté n, c’est lui qui contient la clé étrangère #user_id

n:n : création d’une table de liaison

L’entité relationnelle disparaît pour laisser place à une table dite « de liaison » contenant des clés étrangères vers les tables liées. Le couple formé par les clés étrangères constitue la clé primaire de cette table.

avatars(i̲d̲, path, is_valid, #user_id)
users(i̲d̲, email, password, registered_at, role)
comments(i̲d̲, content, published_at, #user_id, #article_id)
articles(i̲d̲, title, description, content, published_at, #user_id)
categories(i̲d̲, name)
articles_get_categories(#̲a̲r̲t̲i̲c̲l̲e̲_̲i̲d̲, #̲c̲a̲t̲e̲g̲o̲r̲y̲_̲i̲d̲)

Table de liaison articles_get_categories entre articles et categories

• « Un Article Possède au moins 0 et au plus n Catégories »
• « Une Catégorie Est possédée par au moins 0 et au plus n Article » categories et articles sont tous deux du côté n, on ajoute alors une table de liaison articles_get_categories dans laquelle on forme des couples de clés étrangères #article_id et #category_id.