Modéliser une base de données

Une base de données rassemble des données organisées pour des usages définis. Un système de gestion de base de données, ou SGBD, est le logiciel qui permet notamment leur stockage, leur interrogation et l’application de contraintes. Le modèle relationnel décrit les données sous forme de relations, représentées en pratique par des tables. Une relation possède des attributs, représentés par les colonnes, et des lignes qui décrivent ses occurrences.

Le mot relation a ici un sens précis : il désigne une structure de données comme CLIENT. Le lien métier entre un client et une commande est une association. Confondre les deux empêche de comprendre le modèle. Une entité est un objet du domaine étudié, par exemple un client, un produit ou une commande. Le passage aux relations traduit les règles de gestion ; il ne suffit pas de dessiner un tableau pour que ce tableau représente correctement l’activité.

Un attribut décrit une propriété : nom, date de commande, montant. Son domaine indique les valeurs autorisées. Un montant peut être un nombre décimal non négatif ; un état peut appartenir à une liste de valeurs prévues. Le type informatique et la règle métier se complètent. Un nombre entier peut être techniquement valide mais impossible dans le contexte : une quantité négative ne convient pas à une ligne de vente ordinaire.

Une clé est un ensemble minimal d’attributs permettant de distinguer chaque ligne. La clé primaire est celle choisie comme identifiant principal de la relation ; elle doit être unique et renseignée. Une clé peut comporter plusieurs attributs. La stabilité et la simplicité de l’identifiant facilitent les usages. Un numéro de client est généralement plus adapté qu’une combinaison de données personnelles susceptibles de changer.

Une clé étrangère est un attribut ou un ensemble d’attributs qui référence une clé admissible d’une relation. Dans notre modèle, id_client de COMMANDE référence la clé primaire de CLIENT. Le même client peut apparaître dans plusieurs commandes ; la valeur étrangère n’est donc pas nécessairement unique. Une référence obligatoire doit être renseignée et correspondre à un client existant. Une référence facultative exige une règle explicite sur l’absence de valeur.

La cardinalité exprime combien d’occurrences peuvent être associées selon les règles métier. Dans le cas choisi, un client peut n’avoir encore aucune commande ou en avoir plusieurs ; chaque commande appartient à un seul client. Cette règle explique la présence de la clé étrangère dans COMMANDE. Elle ne se déduit pas seulement des données observées un jour : voir un client avec une commande ne prouve pas qu’il ne pourra jamais en avoir deux.

Une dépendance fonctionnelle signifie qu’une valeur d’un attribut, ou d’un groupe d’attributs, détermine une seule valeur d’un autre attribut selon les règles du modèle. Ici, id_client détermine le nom et la ville du client dans l’état courant. On l’écrit id_client → nom, ville. Cette dépendance n’affirme pas qu’une personne ne déménage jamais : elle décrit l’information conservée à un moment donné.

Si le nom et la ville du client sont répétés dans chaque commande, une correction doit être faite à plusieurs endroits. Certaines lignes peuvent rester anciennes : c’est une anomalie de mise à jour. Séparer CLIENT et COMMANDE permet de garder l’information courante du client dans une relation adaptée. Cependant, l’adresse historique de livraison d’une commande peut être une donnée distincte à conserver. Il faut discuter le sens avant de supprimer une répétition utile à l’historique.

Une association plusieurs-à-plusieurs demande généralement une relation supplémentaire. Une commande contient plusieurs produits ; un produit peut figurer dans plusieurs commandes. LIGNE_COMMANDE relie les deux et porte la quantité. Dans l’hypothèse où un produit figure au plus une fois par commande, le couple id_commande et id_produit est une clé composée. La quantité dépend du couple : elle n’est ni la quantité totale du produit en stock, ni une propriété du client.

Adapter un modèle commence par une nouvelle règle. Si un produit peut apparaître plusieurs fois dans une même commande avec des conditions différentes, le couple précédent ne suffit plus. On peut introduire un numéro de ligne dans la commande. Le choix dépend du besoin, pas d’une recette universelle. La modélisation demande de tester plusieurs cas, y compris les absences, les répétitions autorisées et les changements d’état.

L’intégrité d’entité protège l’identification des lignes ; l’intégrité référentielle protège la cohérence des références ; les contraintes de domaine portent sur les valeurs admissibles. Des règles métier supplémentaires peuvent limiter des situations particulières. Le SGBD peut faire respecter des contraintes déclarées et activées. Il ne sait pas, à lui seul, qu’une adresse saisie est celle du bon client ou qu’une quantité respecte une décision commerciale absente du modèle.

NULL peut représenter une information absente ou inconnue dans une table SQL. Ce n’est pas le nombre zéro ni une chaîne vide. Son usage doit être prévu et interprété avec soin. Une clé primaire ne doit pas être manquante. Pour une référence facultative, l’absence peut être autorisée, mais elle ne doit pas masquer une erreur de saisie. Le modèle, les contraintes techniques et les contrôles humains participent ensemble à la qualité des données.

Pour poursuivre : https://www.allostmg.fr/exercices.