Bonjour ! Je m'appelle Andreï Semyonov, je suis analyste senior chez Sportmaster. Dans ce post, je souhaite aborder la question de la dénormalisation des bases de données des systèmes ERP. Nous examinerons les conditions générales, ainsi qu'un exemple concret : disons qu'il s'agira d'une magnifique taverne-monopoliste pour les pirates et les marins. Dans celle-ci, pirates et marins doivent être servis différemment, car leurs conceptions du beau et leurs comportements de consommation diffèrent considérablement.
Comment s'assurer que tout le monde soit satisfait ? Comment ne pas devenir fou en concevant et en maintenant un tel système ? Que faire si la taverne commence à accueillir non seulement les pirates et marins habituels ?
Tout est sous le chapô. Mais procédons dans l'ordre.
1. Restrictions et hypothèses
Tout ce qui est exposé ne concerne que les bases de données relationnelles. Les conséquences bien documentées, y compris sur Internet, de la dénormalisation en termes d'anomalies de modification, de suppression et d'insertion ne sont pas abordées. Les cas où la dénormalisation est une pratique courante, avec des exemples classiques : numéro de série et numéro de passeport, date et heure, etc. sont exclus de cette publication.
Dans le post, des définitions intuitivement compréhensibles et pratiquement applicables des formes normales sont utilisées, sans référence aux termes mathématiques. Dans la manière dont elles peuvent être appliquées à l'analyse des processus métier réels et à la conception de logiciels industriels.
Il existe un avis selon lequel la conception d'entrepôts de données, d'outils de rapport et d'accords d'intégration (qui utilisent une représentation tabulaire de l'information) diffère de la conception des bases de données des systèmes ERP en ce sens que la facilité de consommation et l'utilisation d'une dénormalisation consciente pour y parvenir peuvent avoir la priorité sur la protection de l'intégrité des données. Je partage cet avis, et ce qui est décrit ci-dessous ne concerne que les modèles de données maîtresses et de données transactionnelles des systèmes ERP.
L'explication des formes normales est fournie à travers un exemple compréhensible au niveau domestique pour la plupart des lecteurs. Cependant, par souci de clarté, les points 4 et 5 utilisent délibérément un problème « fictif ». Si cela n'est pas fait et qu'un exemple traditionnel est pris, comme le modèle de stockage de commande mentionné au point 2, on peut se retrouver dans une situation où l'attention du lecteur est détournée du processus proposé vers son expérience personnelle et sa perception de la manière dont les processus et modèles de stockage de données en SI doivent être construits. En d'autres termes, prenez deux analystes informatiques qualifiés, demandez à l'un de fournir un service aux logisticiens qui transportent des passagers, et à l'autre de faire de même pour les logisticiens qui transportent des machines pour la production de microprocesseurs. Demandez-leur, sans discuter des processus automatisables, de créer un modèle de données pour stocker des informations sur un voyage ferroviaire.
Il existe une probabilité non nulle que dans les modèles proposés, vous trouviez non seulement un ensemble d'attributs sensiblement différent, mais également des ensembles d'entités qui ne coïncident pas, car chaque analyste s'appuiera sur les processus et les tâches qui lui sont familiers. Et dans une telle situation, il est impossible de dire quel modèle est « correct », car il n'y a pas de critère d'évaluation.
2. Formes normales
La première forme normale d'une BD exige l'atomicité de tous les attributs.
En particulier, si un objet A possède des attributs non clés a et b, tels que c=f(a,b) et que dans la table décrivant l'objet A vous stockez la valeur de l'attribut c, alors la première forme normale est violée dans la BD. Par exemple, si dans la spécification de commande la quantité est exprimée en unités qui dépendent du type de produit : dans un cas ce peut être des unités, dans un autre des litres, et dans un troisième des emballages composés d'unités (dans le modèle ci-dessus Good_count_WR), alors la BD viole l'atomicité des attributs. Dans ce cas, pour déterminer quel devrait être l'ensemble de tables pour la spécification de commande, il faut une description cible du processus de travail dans le SI, et comme les processus peuvent varier, il peut donc y avoir de nombreuses versions « correctes ».
La deuxième forme normale d'une BD requiert le respect de la première forme et d'une table propre pour chaque entité liée au processus de travail dans le système d'information. Si une table contient des dépendances c=f1(a) et d=f2(b) et qu'il n'existe pas de dépendance c=f3(b), alors la deuxième forme normale est violée dans la table. Dans l'exemple ci-dessus, la table «Commande» ne présente pas de dépendance entre la commande et l'adresse. Modifiez le nom de la rue ou de la ville, et vous n'obtiendrez aucun impact sur les attributs essentiels de la commande.
Troisième forme normale de la base de données requiert le respect de la deuxième forme normale et l'absence de dépendances fonctionnelles entre les attributs de différentes entités. Cette règle peut être formulée ainsi : «tout ce qui peut être calculé doit être calculé». En d'autres termes, s'il existe deux objets A et B. Dans la table contenant les attributs de l'objet A, l'attribut C est présent, et l'objet B possède un attribut b tel que c=f4(b), alors la troisième forme normale est violée. Dans l'exemple ci-dessous, l'attribut «Quantité d'articles» (Total_count_WR) dans l'enregistrement de la commande revendique clairement la violation de la troisième forme normale.
3. Mon approche de l'application de la normalisation
1. Seul le processus commercial cible et automatisable peut fournir à l'analyste des critères pour identifier les entités et les attributs lors de la création du modèle de stockage des données. La création du modèle de processus est une condition sine qua non pour établir un modèle de données normal.
2. Atteindre la troisième forme normale au sens strict peut ne pas être judicieux dans la pratique réelle de la création de systèmes ERP lorsque certaines ou toutes les conditions suivantes sont remplies :
- les processus automatisables sont rarement sujets à des changements,
- les délais pour la recherche et le développement sont serrés,
- les exigences en matière d'intégrité des données sont relativement faibles (les erreurs potentielles dans les logiciels industriels ne entraînent pas de pertes d'argent ou de clients pour le client du logiciel)
- etc.
Dans les conditions décrites, les coûts d'identification et de description du cycle de vie de certains objets et de leurs attributs peuvent ne pas être justifiés du point de vue de l'efficacité économique.
3. Toute conséquence de la dénormalisation du modèle de données dans un système d'information déjà créé peut être atténuée par une recherche minutieuse du code et des tests.
4. La dénormalisation est une méthode qui permet de transférer les efforts de la phase d'exploration des sources de données et de conception du processus métier vers la phase de développement, du temps d'implémentation vers la période d'évolution du système.
5. Il est judicieux de viser la troisième forme normale pour une base de données si :
- La direction de l'évolution des processus métiers automatisés est difficile à prévoir.
- Au sein de l'équipe d'implémentation et/ou d'évolution, il existe une séparation des tâches peu perméable.
- Les systèmes inclus dans le périmètre d'intégration se développent selon leurs propres plans.
- Un manque de cohérence des données peut conduire à une perte de clients ou d'argent pour l'entreprise.
6. La conception du modèle de données ne doit être réalisée par l'analyste qu'en relation avec les modèles du processus métier cible et du processus dans le SI. Si la conception du modèle de données est confiée à un développeur, celui-ci devra plonger dans le domaine spécifique à tel point qu'il comprendra notamment la différence entre les valeurs des attributs - condition nécessaire pour identifier des attributs atomiques. Ainsi, il s'attribue des fonctions qui ne lui sont pas propres.
4 Tâche d'illustration
Supposons que vous ayez une petite taverne robotisée dans le port. Votre segment de marché : des marins et des pirates qui arrivent au port et ont besoin de repos. Vous vendez aux marins du thé au thym, et aux pirates du rhum et des peignes en os pour se coiffer la barbe. Le service dans la taverne est assuré par un robot hôtesse et un robot barman. Grâce à la haute qualité et aux prix bas, vous avez écarté tous les concurrents, de sorte que chaque personne descendant du navire vient dans votre taverne, qui est la seule du port.
Le complexe des systèmes d'information de la taverne se compose des logiciels suivants :
- Système d'alerte précoce sur les clients, reconnaissant leur catégorie par des signes caractéristiques.
- Système de gestion des robots hôtesses et des robots barmen.
- Système de gestion des stocks et de livraison au point de vente.
- Système de gestion des relations avec les fournisseurs (SGRPS).
Processus :
Le système d'alerte précoce reconnaît les personnes descendant du navire. Si une personne est bien rasée, elle est identifiée comme marin ; si une personne a une barbe, elle est identifiée comme pirate.
En entrant dans la taverne, le client entend de la part du robot hôtesse un accueil en fonction de sa catégorie, par exemple : « Ho-ho-ho, cher pirate, veuillez vous diriger vers la table n°… »
Le client se dirige vers le comptoir spécifié, où le robot-barman a déjà préparé des articles en fonction de la catégorie. Le robot-barman transmet des informations au système d'entrepôt, indiquant que la prochaine livraison doit être augmentée, et le système d'information de l'entrepôt, en fonction des stocks disponibles, génère une demande d'achat dans le système de gestion de l'approvisionnement.
Peu importe si votre système d'alerte précoce a été développé par votre département informatique interne, le programme de gestion des robots-barmans a été créé par un prestataire extérieur spécifiquement pour votre entreprise. Les systèmes de gestion d'entrepôt et de relations avec les fournisseurs sont des solutions personnalisées provenant du marché.
5. Exemples de dénormalisation et son impact sur le développement logiciel
Lors de la conception du processus métier, les experts du domaine ont tous affirmé qu'à travers le monde, les pirates boivent du rhum et se peignent la barbe avec des peignes en os, tandis que les marins boivent du thé au thym et sont toujours rasés de près.
Un annuaire des types de clients apparaît avec deux valeurs : 1 - pirates, 2 - marins, commun à l'ensemble du cadre d'information de l'entreprise.
Le système d'alerte concernant le client sauvegarde immédiatement le résultat du traitement de l'image comme identifiant (ID) du client reconnu et son type : marin ou pirate.
ID de l'objet reconnu
Catégorie de client
100500
Pirate
100501
Pirate
100502
Marin
Encore une fois, soulignons que
1. Nos marins sont en réalité des personnes rasées
2. Nos pirates sont en réalité des personnes barbus
Quels problèmes doivent être résolus pour que notre structure tende vers la troisième forme normale :
- violation de l'atome d'attribut - Catégorie de client
- mélange du fait analysé et de la conclusion dans une seule table
- dépendance fonctionnelle fixée entre les attributs de différentes entités.
Dans une forme normalisée, nous obtiendrions deux tables :
- résultat de la reconnaissance sous forme d'ensemble de caractéristiques établies,
ID de l'objet reconnu
Poils sur le visage
100500
Oui
100501
Oui
100502
Non
- résultat de la détermination du type de client comme application de la logique inscrite dans le système d'information pour interpréter les caractéristiques établies
ID de l'objet reconnu
ID d'identification
Catégorie de client
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Marin
Comment une organisation normalisée de stockage des données peut-elle faciliter le développement d'un système d'information ? Supposons que de nouveaux clients apparaissent soudainement. Ce seraient des pirates japonais qui pourraient ne pas avoir de barbe, mais qui ont un perroquet sur l'épaule, et des pirates écologistes, que vous reconnaîtrez facilement grâce au profil bleu de Greta sur leur poitrine gauche.
Les pirates écologistes, bien sûr, ne peuvent pas utiliser de peignes en os et exigent un équivalent en plastique marin recyclé.
Vous devez retravailler les algorithmes des programmes en fonction des nouvelles données. Si les règles de normalisation avaient été respectées, vous auriez seulement eu à compléter certaines entrées dans quelques systèmes pour certaines branches de processus et à créer de nouvelles branches uniquement pour les cas et dans les systèmes où la pilosité faciale est importante. Mais, comme les règles n'ont pas été respectées, vous devrez analyser tout le code, dans tout le contour où des valeurs de répertoire de types de clients sont utilisées et établir clairement que dans un cas, l'algorithme doit prendre en compte l'activité professionnelle du client, et dans l'autre, les caractéristiques physiques.
Sous la forme qui vise à la normalisation, nous obtiendrions deux tableaux avec des données opérationnelles et deux répertoires :
- résultat de la reconnaissance sous forme d'ensemble de caractéristiques établies,
ID de l'objet reconnu
Greta sur la poitrine gauche
Un oiseau sur l'épaule
Poils sur le visage
100510
1
1
1
100511
0
0
1
100512
1
0
- le résultat de la détermination du type de client (supposons qu'il s'agisse d'une vue utilisateur, dans laquelle des descriptions des répertoires sont affichées)
La dénormalisation détectée signifie-t-elle que les systèmes ne pourront pas être adaptés aux nouvelles conditions ? Bien sûr que non. Si nous imaginons que tous les systèmes d'information ont été créés par une seule équipe avec un taux de turnover nul, que le développement est bien documenté et que l'information dans l'équipe est transmise sans pertes, les changements requis peuvent être effectués avec des efforts négligeables. Mais si nous revenons aux conditions initiales de la tâche, rien que pour imprimer les procès-verbaux des discussions communes, 1,5 claviers seront usés et encore 0,5 pour la rédaction des procédures d'achat.
Dans l'exemple donné ci-dessus, toutes les trois formes normales sont violées, essayons maintenant de les violer individuellement.
Violation de la première forme normale :
Supposons que les marchandises soient livrées à votre entrepôt depuis les dépôts des fournisseurs par un utilitaire de 1,5 tonne appartenant à votre taverne. La taille de vos commandes est si petite par rapport au volume des fournisseurs qu'elles sont toujours exécutées à la lettre sans attente de fabrication. Avez-vous besoin de tableaux distincts pour cela : véhicules, types de véhicules, devez-vous séparer prévisions et réalités dans vos commandes envoyées aux fournisseurs ?
Imaginez combien de connexions « superflues » vos programmeurs devront écrire si l'on utilise le modèle ci-dessous pour développer le programme.
Supposons que nous ayons décidé que la structure proposée est trop compliquée, pour notre cas, séparer prévisions et réalités dans l'enregistrement des commandes est une information superflue, et la spécification de commande créée est écrasée en fonction des résultats de la réception des marchandises arrivées, les rares erreurs de tri et la réception de marchandises de mauvaise qualité sont réglées en dehors du système d'information.
Et un jour, vous voyez que toute la salle de la taverne est remplie de pirates indignes et mal coiffés. Que s'est-il passé ?
Il s'est avéré qu'avec la croissance de votre entreprise, la consommation a également augmenté. Autrefois, une décision de gestion a été prise pour que si l'utilitaire était surchargé en volume et/ou en poids, ce qui arrivait très rarement, le fournisseur donnait la priorité à la charge au profit des boissons.
Les marchandises non livrées figuraient dans la commande suivante et partaient lors d'un nouveau voyage, la présence d'un stock minimum dans l'entrepôt de la taverne permettait de ne pas remarquer les cas de non-conformité.
Le dernier concurrent a fermé dans le port, et le cas de surcharge de l'utilitaire, contourné par la priorisation basée sur l'hypothèse d'une suffisance du stock minimum et la sous-charge périodique du véhicule, est devenu une pratique courante. Le système créé fonctionnera parfaitement en fonction des algorithmes qui y sont intégrés et sera dépourvu de toute possibilité de suivre les manquements systématiques aux commandes planifiées. Seule une réputation ternie et des clients mécontents pourront détecter le problème.
Un lecteur attentif a sûrement remarqué que la quantité commandée dans la spécification de la commande (T_ORDER_SPEC) dans la section 2 et dans la section 5 peut répondre ou non à l'exigence de la première forme normale. Tout dépend de la possibilité que différentes unités de mesure soient incluses dans le même champ pour la gamme de produits choisie.
Violation de la deuxième forme normale :
Avec l'augmentation de vos besoins, vous acquérez quelques véhicules de transport de tailles différentes. Dans le contexte décrit ci-dessus, la création d'un répertoire des véhicules a été jugée redondante, par conséquent, tous les algorithmes traitant des données pour les besoins de livraison et d'entrepôt considèrent le déplacement des marchandises du fournisseur vers l'entrepôt comme un trajet exclusivement d'un véhicule léger de 1,5 tonne. Ainsi, avec l'achat de nouveaux véhicules, vous créez tout de même un répertoire des véhicules, mais lors des ajustements, vous devrez analyser tout le code référant au déplacement des marchandises pour déterminer si, à chaque endroit spécifique, il y a des références aux caractéristiques du véhicule qui a initié l'entreprise.
Violation de la troisième forme normale :
À un moment donné, vous commencez à créer un programme de fidélité et une fiche client fidèle apparaît. Pourquoi, par exemple, prendre le temps de créer des représentations matérielles contenant des données agrégées sur les ventes d'un client spécifique pour les rapports et l'intégration dans des systèmes analytiques, si au début du programme de fidélité, tout ce qui intéresse le client peut être indiqué sur la fiche du client lui-même ? Et, en effet, cela peut sembler ne pas avoir de sens au premier abord. Mais chaque fois que votre entreprise connecte, par exemple, de nouveaux canaux de vente, il doit y avoir parmi vos analystes quelqu'un qui se souvienne de l'existence de cet attribut d'agrégation.
En concevant chaque nouveau processus, par exemple, les ventes en ligne, les ventes via des distributeurs connectés au système de fidélité global, quelqu'un doit garder à l'esprit que tous les nouveaux processus doivent assurer la cohérence des données au niveau du code. Pour une base de données industrielle avec des milliers de tables, cela semble être une tâche peu réalisable.
Un développeur expérimenté sait bien sûr comment résoudre tous les problèmes mentionnés ci-dessus, mais à mon avis, la tâche d'un analyste chevronné est de ne pas les laisser se produire.
Je tiens à exprimer ma gratitude pour les précieux retours lors de la préparation de la publication au développeur principal Evgeny Yarukhin.
Littérature
Connolly Thomas, Begg Caroline. Bases de données. Conception, réalisation et maintenance. Théorie et pratique.
Source : habr.com
