🤔 Dans une DB, clés étrangères ou pas ou mixte?

4310 · March 8, 2023, 8:50am

Je sais que cela peut sembler unorthodox mais voilà;
dans une DB, afin de faciliter le développement et la modularité, je suis tenté de ne pas mettre de réelles clés étrangères partout tout en gardant une schéma « fictif » des relations entre les tables, cela permettrait entre autres une certaine liberté et rapidité de développement, exemple; remplir les tables dans l’ordre que l’on souhaite sans se soucier des contraintes.

Mon contexte est le suivant; je suis en train de créer une base de données pour une application qui sera relativement centrale dans le SI et devra être connectée à d’autres bases de données, qui peuvent, eux avoir certains manques d’intégrité, parfois des données venant de fichier excel.
Cette base de données devra alimenter un entrepôt de données.
Les Dev du Back auront le loisir de gérer les règles et l’ordre de remplissage des données et donc de créer eux-mêmes les contraintes, donc il y aura un semblant d’intégrité assurée par eux.
Pour le moment nous avons choisi un certain type de base de données, mais il est possible que nous allions sur un autre type dans un moyen terme.

Pour le moment je pense faire une sorte de mixte et détecter seulement quelques tables nécessitant des clés étrangères avec réelles contraintes, exemple, une table liées avec une autre table comportant une longue liste d’élément, cela permettrait de supprimer en cascade l’ensemble des enfants, autre exemple; lorsqu’un élément ne peut pas exister sans un autre élément, genre un toit et une maison, il ne peut y avoir de toit sans maison, mais une maison peut avoir plusieurs toits…
Pour les autres tables, il y aurait des clés étrangère mais pas contraignantes dans la base, seule la colonne FK existerait, et je laisserais la responsabilité au back d’assurer le minimum d’intégrité.

Existe-il des systèmes de correction et vérification d’intégrité ?
Si je poste cela, c’est que je n’arrive pas vraiment à trancher, merci d’avance pour vos conseilles.

voici un article sur Dataedo qui parle des 9 raisons de ne pas mettre de FK:

2435 · March 13, 2023, 5:01pm

Bonjour Malek,

Merci pour votre message très intéressante. Si je comprends votre intention est de faciliter le développement et la modularité de votre base de données. En essayant de résumer votre objectif : vous envisagez de ne pas mettre de clés étrangères partout, mais de garder un schéma « fictif » des relations entre les tables afin de permettre plus de liberté. vous prévoyez de laisser aux développeurs la gestion des règles et de l’ordre de remplissage des données afin qu’ils créent eux-mêmes les contraintes pour assurer une certaine intégrité. Certaines tables auront des clés étrangères avec des contraintes réelles, tandis que d’autres n’auront que des clés étrangères non contraignantes. Et vous vous demandez s’il existe des systèmes de correction et de vérification d’intégrité pour aider à gérer cela?

La réponse n’est bien évidemment pas aussi simple que cela et va dépendre du cas d’usage que vous souhaitez mettre en place dans votre entreprise. Souhaitez-vous realiser des analyses sur le schéma créé ou juste historiser l’information ?

Dans le premier cas, j’aimerais souligner l’importance des contraintes de clés étrangères pour maintenir l’intégrité des données dans votre système d’information. Sans ces contraintes, il sera difficile d’être sûr que les données contenues dans votre base de données sont correctes et cohérentes. Je vous recommande donc de bien réfléchir avant de supprimer les contraintes de clés étrangères dans votre base de données.
Dans le deuxième cas, vous pouvez tenter une approche assez peu connu du public qui se nomme l’approche data vault. L’approche Data Vault 2.0 est une méthodologie de modélisation de données pour les entrepôts de données qui se concentre sur la capacité d’évolution, la flexibilité et la scalabilité. Cette approche divise les données en trois types de tables : les tables d’entités, les tables de liaisons et les tables de satellites. Les tables d’entités représentent les éléments de base de l’entreprise, comme les clients, les produits et les employés, tandis que les tables de liaison connectent ces entités les unes aux autres. Les tables de satellites contiennent des informations supplémentaires à propos des entités et des liens, tels que les dates de validité, les descriptions et les codes.

Le modèle Data Vault 2.0 est centré sur l’historique des données, la traçabilité, la gouvernance des données et la maîtrise des changements. Il encourage également l’utilisation de l’automatisation, de la répétabilité et de l’extensibilité pour faciliter la gestion des changements et la maintenance de l’entrepôt de données. L’un des aspects clés de l’approche Data Vault 2.0 est la séparation des responsabilités entre la modélisation des données et l’implémentation technique, ce qui permet une évolutivité et une flexibilité accrues en cas de changements dans l’environnement des données.

Quelques liens (non exhaustif) pour creuser:

En espérant avoir répondu à votre question,