Au fil des ans, en tant que modélisateur de données et architecte de base de données, j'ai remarqué qu'il y a quelques règles à suivre lors de la modélisation et du développement des données. Ici, je décris quelques conseils dans l'espoir qu'ils pourraient vous aider. J'ai répertorié les conseils dans l'ordre dans lequel ils se produisent au cours du cycle de vie du projet plutôt que de les classer par importance ou par degré de fréquence.
1. Planifiez à l'avance
Ne pas planifier, c'est planifier l'échec.
Alan Lakein
Un problème que j'ai vu est lorsque la modélisation des données se produit en même temps que le développement de logiciels. C'est comme construire les fondations avant de terminer les plans. Dans le passé, la planification semblait une étape évidente avant de commencer le développement. Les équipes de développement ne créeraient pas de bases de données sans planification, tout comme les architectes ne construiraient pas de bâtiments sans plans.
Dans le développement d'applications, il est essentiel de comprendre la nature des données.
La planification est souvent ignorée afin que les développeurs puissent simplement "commencer à coder". Le projet démarre et lorsque des problèmes surviennent, il n'y a pas de relâchement dans le calendrier pour les résoudre. Les développeurs prennent des raccourcis avec l'intention de les corriger plus tard, mais cela se produit rarement, voire jamais.
Une planification minutieuse permet de s'assurer que vous vous retrouvez avec une base de données appropriée qui n'est pas piratée ensemble. Si vous ne consacrez pas le temps et les efforts nécessaires au traitement des données requises par les processus, vous le paierez plus tard avec une base de données qui doit être retravaillée, remplacée ou supprimée.
Même si la planification n'est pas toujours effectuée, de nombreux modélisateurs de données suivent toujours ces directives. Cela ne veut pas dire que nous pouvons prédire chaque besoin de conception à l'avance, mais la plupart des modélisateurs pensent que cela vaut la peine de comprendre les données et leur utilisation. Vous ne voudriez pas une conception pour le traitement des transactions lorsque le besoin est la création de rapports analytiques.
Les temps ont changé; Les méthodologies agiles sont plus répandues, les équipes de bases de données doivent donc repenser leur approche de la modélisation des données. Dans Agile, le modèle de domaine des cas d'utilisation est utilisé à la place des diagrammes de relation d'entité. Cependant, le besoin de planification n'a pas diminué. Nous devons comprendre les données et ce qu'elles sont censées faire. En général, les premiers Sprints doivent se concentrer sur la conception des données.
Ce n'est donc pas Agile qui est le problème des modélisateurs de bases de données, mais plutôt des individus qui ne saisissent pas la nature des données. Certains voient le développement de bases de données comme le même que le développement d'applications. La modélisation de base de données et le développement de logiciels sont différents et nécessitent une attention appropriée.
La base de données est au cœur de la plupart des applications logicielles. Vous devez prendre le temps d'analyser les exigences et la manière dont le modèle de données y répondra. Cela diminue le risque que le développement perde son cap et sa direction.
Les développeurs doivent comprendre l'importance des données et leur contribution au processus de développement. Nous vivons à l'ère de l'information. Les applications affichent et manipulent des données. Ce sont les informations contenues dans les données qui donnent du sens à l'application.
Il n'est pas possible de prévoir toutes les exigences ni tous les problèmes, mais il est important de se préparer aux problèmes par une planification minutieuse.
2. Documentez votre modèle
Lors de la réalisation d'un modèle de données, tout semble évident. Vous nommez les objets de manière à ce que leur objectif soit évident et que tout le monde comprenne le sens rien qu'en lisant le nom. C'est peut-être vrai, mais ce n'est pas aussi évident qu'on pourrait le penser. Lorsque vous choisissez des noms pour les tables et les colonnes, indiquez clairement quelle sera l'utilisation de chaque objet. Au fil du temps, la signification des objets ne sera pas claire sans documentation.
L'utilisation d'une convention de nommage est une étape vers une documentation efficace. Lorsque vous devrez apporter des modifications à l'avenir, vous apprécierez toute documentation existante. Un document court et simple qui décrit les décisions que vous avez prises et décrit la conception aidera à expliquer le choix de conception à ce moment-là.
Vous voulez suffisamment de documentation pour que la base de données puisse être gérée par un nouvel administrateur et qu'il puisse comprendre le sens sans avoir à revenir vers vous pour des explications. Si le modèle de données et l'environnement ne sont pas documentés, il est difficile de le maintenir ou de le modifier à mesure que les exigences changent.
Dans une certaine mesure, la documentation a peu à voir avec la modélisation des données. La documentation consiste à communiquer la conception et à la rendre compréhensible à l'avenir.
La documentation est souvent une réflexion après coup. Lorsque les horaires sont courts, la documentation est ignorée. Or, il s'agit d'une dette technique au coût élevé. Prendre des raccourcis pendant le cycle de développement entraînera des coûts à l'avenir pour les modifications de la base de données, l'identification des problèmes, le suivi des bogues et la compréhension du modèle de données et de la nature des données.
Par exemple, les modèles de données ont souvent un champ "ID" comme clé primaire pour une table ou une partie du nom d'une clé. Il peut s'agir d'une clé primaire telle que TransactionID sur la Transaction table. Si certaines tables utilisent "Number" dans le nom d'une clé, il est bon de documenter pourquoi. Peut-être ReferenceNumber est utilisé comme nom de la clé primaire sur le Message car c'est ainsi que la référence est appelée dans le domaine métier. Par exemple, dans les services financiers, les messages financiers incluent généralement un numéro de référence.
Documentez la définition des tables, des colonnes et des relations afin que les programmeurs puissent accéder aux informations. La documentation doit décrire les attentes de la structure de la base de données.
Dans l'outil Vertabelo, je peux immédiatement inclure des commentaires sur n'importe quel élément :tables, colonnes, références, clés alternatives, ce qui signifie que la documentation est stockée immédiatement avec mon modèle plutôt que dans un document supplémentaire à conserver séparément.
Une documentation médiocre ou absente est souvent due à une réflexion à courte vue, mais n'ignorez pas son importance. C'est encore un problème à résoudre.
3. Suivre les conventions
Les conventions de nommage peuvent ne pas sembler importantes lors de la conception. En réalité, les noms permettent de comprendre un modèle. Ils sont une introduction et doivent être logiques.
Une dénomination incohérente ne sert à rien. Cela ne fait que frustrer les développeurs qui doivent accéder aux données, les administrateurs de la base de données et les modélisateurs qui doivent apporter des modifications à l'avenir.
Lorsque "ID" est utilisé pour certaines clés artificielles mais que certaines tables utilisent une convention de dénomination différente (telle que Number), les développeurs, les analystes et les administrateurs de base de données peuvent perdre du temps à comprendre les exceptions. Des conventions de dénomination faibles entraînent également des erreurs de développement car la dénomination n'est pas cohérente.
Parallèlement à la documentation, l'utilisation d'une convention de dénomination permet à quelqu'un de comprendre le modèle à l'avenir. Ne basculez pas au hasard entre l'utilisation de "ID" (comme CustomerID ) et "Numéro" (AccountNumber ) comme clés pour les tables. Ne faites des exceptions aux conventions que lorsqu'elles sont justifiées. Documentez quelle est l'exception et pourquoi la convention n'est pas respectée.
La même chose s'applique aux noms cryptiques comme "XRT1" - est-ce les tables de référence étendues ? Votre supposition est aussi bonne que la mienne. J'espère que le concepteur savait pourquoi il a choisi un nom aussi énigmatique, mais je doute que la prochaine personne à accéder à la base de données puisse en deviner la raison.
Les conventions de nommage sont une question de choix personnel. Assurez-vous que les décisions sont cohérentes et documentées.
Si j'ai réussi à vous convaincre d'appliquer la convention de nommage dans la conception de votre base de données, n'hésitez pas à lire mon prochain article entièrement consacré à ce sujet.
4. Réfléchissez bien aux clés
Les clés suscitent souvent la controverse :clés primaires, clés étrangères et clés artificielles. Les tables ont besoin d'une clé primaire qui identifie chaque ligne. L'art consiste à décider quelles colonnes doivent faire partie de la clé primaire et quelles valeurs inclure.
Pour une bonne normalisation, chaque table a besoin d'une clé d'identification. L'unicité doit être garantie. Pourtant, les clés naturelles et les clés primaires ne doivent pas nécessairement être identiques. En fait, ils peuvent ne pas l'être, tant que la table a une clé naturelle.
Certains modélisateurs de données préfèrent une clé artificielle pour l'unicité. Pourtant, certains modélisateurs préfèrent une clé naturelle pour garantir l'intégrité des données.
Alors, devrions-nous utiliser une clé naturelle comme clé primaire ? Un défi se pose si la clé naturelle doit être changée. Si la clé naturelle se compose de plusieurs colonnes, vous devrez peut-être apporter des modifications à de nombreux endroits. Un autre défi consiste à utiliser une clé artificielle comme seule clé pour une table.
Par exemple, vous pouvez avoir une table stockant des informations sur les produits. La table peut être définie avec une clé artificielle telle qu'une séquence, un code pour le nom alphabétique court du produit et la définition du produit. Si l'unicité n'est assurée que par la clé artificielle, il peut y avoir deux lignes avec le même code produit. S'agit-il du même produit qui est entré deux fois ? Peut-être qu'une clé avec le code produit est plus appropriée.
5. Utilisez les vérifications d'intégrité avec précaution
Pour garantir l'intégrité des données, nous avons besoin de clés étrangères et de contraintes. Veillez à ne pas abuser ou sous-utiliser ces vérifications d'intégrité.
Les tables de domaine sont efficaces pour faire respecter l'intégrité. Les tables de domaine fonctionnent bien lorsqu'il y a de nombreuses valeurs à vérifier ou que les valeurs à vérifier changent fréquemment.
Un problème peut être que les développeurs décident que l'application vérifiera l'intégrité. Le problème ici est qu'une base de données centrale peut être accessible par de nombreuses applications. De plus, vous souhaitez généralement protéger les données là où elles se trouvent :dans la base de données.
Si les valeurs possibles sont limitées ou comprises dans une plage, une contrainte de vérification peut être préférable. Disons que les messages sont définis comme entrants ou sortants, auquel cas il n'est pas nécessaire d'avoir une clé étrangère. Mais, pour quelque chose comme des devises valides, bien que celles-ci puissent sembler statiques, elles changent en fait de temps en temps. Les pays rejoignent une union monétaire et les devises changent.
Les applications doivent également effectuer des vérifications d'intégrité, mais ne comptez pas uniquement sur l'application pour la vérification d'intégrité. La définition de règles d'intégrité sur la base de données garantit que ces règles ne seront jamais violées. De cette manière, les données satisfont à tout moment aux règles d'intégrité définies.
6. N'oubliez pas les index dans votre conception
Certaines conceptions d'indexation sont utiles pendant la modélisation de la base de données, même si les index peuvent changer pendant le déploiement et l'utilisation réels. Bien sûr, il est possible d'avoir trop d'index, tout comme il est possible d'en avoir trop peu.
L'indexation est un processus continu. Lors de la conception, vous démarrez le processus sur votre modèle. Le travail de conception porte sur les clés primaires et les contraintes.
Les index sont importants lors de l'examen des requêtes sur les données. Lors de la modélisation, vous devez tenir compte de la manière dont les données seront interrogées. Attention à ne pas sur-indexer. L'indexation s'articule autour de l'optimisation des requêtes.
7. Évitez les tables de recherche courantes
J'ai souvent vu une table de recherche commune pour les paires d'attributs. La définition d'une seule table de domaine générique est perçue comme simplifiant la conception. Ce style de table de domaine fait une définition abstraite pour contenir du texte. J'ai entendu dire qu'il s'agissait d'une table de "valeurs autorisées" ou de "valeurs valides", mais le terme table "MUCK" a été inventé pour cet anti-modèle en 2006 :clé de code massivement unifiée.
Les tables MUCK contiennent des données non liées.
Par exemple, vous pourriez avoir une table qui définit le domaine, l'entrée et une description. En repensant à l'exemple de message ci-dessus, deux entrées pourraient être :
| Domaine | Entrée | Description |
|---|---|---|
| 1 | Je | Message entrant reçu par la banque |
| 1 | O | Message sortant envoyé par la banque |
Ajoutez maintenant des entrées pour un autre domaine :
| Domaine | Entrée | Description |
|---|---|---|
| 2 | COUVERTURE | Couvrir le paiement |
| 2 | SÉRIE | Paiement en série |
| 2 | SSI | Instructions de règlement standard |
C'est juste un gâchis. Que signifie le tableau ?
Juste pour le plaisir, j'ai modélisé un exemple simple d'une table MUCK (ou OTLT, "One True Lookup Table" si vous êtes un fan de Tolkien) et j'ai inclus quelques commentaires. Veuillez noter qu'il s'agit d'un anti-modèle et que je ne vous recommande pas de l'utiliser dans votre modèle de données.
Avec les tables MUCK, les contraintes ne peuvent pas être définies. Les MUCK peuvent devenir plusieurs lignes sans aucune signification. Lorsque vous devez interroger une autre table pour comprendre la signification d'un champ, ce n'est pas l'idéal.
Ces tableaux « à tout va » rendent les contrôles d'intégrité complexes voire impossibles. L'une des raisons pour lesquelles ces tables peuvent être créées est que plusieurs tables de la base de données ont une définition similaire. Les contrôles d'intégrité des données deviennent alors impossibles. De plus, leur taille peut devenir assez grande.
La normalisation devrait s'éloigner des tables MUCK. Une seule table doit représenter un seul domaine ; plutôt qu'une seule table (MUCK) représentant tous les domaines. Sans tables MUCK, nous pouvons mettre en place des contraintes de clé étrangère.
Utilisez des tables distinctes pour les objets de domaine plutôt que de les entasser dans une seule table. Cela permet des types de colonnes, des contraintes et des relations appropriés. Un tableau "Valeurs autorisées" n'est que de la merde et n'a pas sa place dans un modèle de données.
8. Définir une stratégie d'archivage
Trop souvent, j'ai vu des bases de données créées sans une stratégie appropriée de conservation et d'archivage des données. Combien de temps les données seront-elles conservées en ligne disponibles dans les tables de base de données actives ? La plupart des systèmes sont conçus pour conserver les données dans la base de données « pour toujours ». Pour la plupart des systèmes, il ne s'agit pas d'une stratégie raisonnable de conservation des données à long terme. À un moment donné, les données actives doivent être archivées.
Une approche que je préconise consiste à inclure la conservation des données dans le cadre de vos considérations de conception. Aurez-vous des tables actives et historiques pour que les insertions de nouvelles lignes dans les tables actives restent rapides, tout en optimisant les recherches sur les données historiques ?
Cela évite d'avoir à reconcevoir l'archivage dans votre base de données en plus de la conception d'origine.
9. Testez tôt, testez souvent
Pour paraphraser Al Capone (ou John Van Buren, fils du 8e président américain), « testez tôt, testez souvent ». De cette manière, vous suivez la voie de l'Intégration Continue. Tester à un stade précoce du développement permet d'économiser du temps et de l'argent.
Les tests sont toujours un défi dans le plan de développement. Il y a souvent une phase de test à la fin d'un Sprint Agile et des tests système à la fin du développement. Les tests sont généralement la première chose à presser lorsque le temps presse.
En testant la base de données, l'objectif doit être de simuler un environnement de production :"Une journée dans la vie de la base de données". A quels volumes peut-on s'attendre ? Quelles sont les interactions utilisateur probables ? Les cas limites sont-ils traités ?
Ainsi, le plan de test et les tests appropriés doivent faire partie intégrante de la modélisation des données et du développement de la base de données.
Conclusion
Ce sont les principaux problèmes que j'ai rencontrés lorsque j'ai travaillé avec des modélisateurs de données et examiné des modèles de données. En prêtant attention à ces conseils, votre base de données sera mieux conçue et plus robuste. Pourtant, le retour sur investissement de certains de ces investissements n'est pas toujours évident ou visible. Planifiez, documentez, utilisez des normes, créez des clés, assurez l'intégrité, effectuez l'indexation, évitez le MUCK, développez des stratégies et TESTEZ !
Aucune de ces activités ne prendra énormément de temps, mais aura un impact énorme sur la qualité de votre modèle de données.
Que pensez-vous de ces conseils ?
