💊 🧑🏾 🌉 Dénormalisation des systèmes de bases de données ERP et son impact sur le développement de logiciels: ouvrir une taverne sur Tortuga 🌀 👩‍❤️‍💋‍👨 🛤️

salut! Je m'appelle Andrey Semenov, je suis analyste senior chez Sportmaster. Dans cet article, je veux soulever la question de la dénormalisation des systèmes de bases de données ERP. Nous considérerons les conditions générales, ainsi qu'un exemple spécifique - disons que ce sera une merveilleuse taverne monopolistique pour les pirates et les marins. Dans lequel les pirates et les marins doivent être servis de différentes manières, car les idées sur les beaux modèles de consommation de ces bons maîtres sont sensiblement différentes.

Comment rendre tout le monde heureux? Comment ne pas devenir fou en concevant et en maintenant un tel système? Que faire si non seulement des pirates et des marins familiers commencent à venir à la taverne? Tout est sous la coupe. Mais allons-y dans l'ordre.

1. Limitations et hypothèses

Tout ce qui précède ne s'applique qu'aux bases de données relationnelles. Bien éclairés, y compris sur Internet, les effets de la dénormalisation sous forme d'anomalies de modification, de suppression et d'insertion ne sont pas pris en compte. Au-delà de la portée de la publication, il reste des cas où la dénormalisation est monnaie courante, avec des exemples classiques: numéro de série et de passeport, date et heure, etc.

La publication utilise des définitions intuitives et pratiquement applicables des formes normales, sans référence à des termes mathématiques. Sous la forme dans laquelle ils peuvent être appliqués à l'examen de processus commerciaux réels (BP) et à la conception de logiciels industriels.

Il existe une opinion selon laquelle la conception des entrepôts de données, des outils de reporting et des accords d'intégration (qui utilisent une présentation tabulaire des informations) diffère de la conception des systèmes de base de données ERP en ce que la facilité de consommation et l'application de dénormalisation consciente pour y parvenir peuvent avoir la priorité sur la protection de l'intégrité Les données. Je partage cette opinion, et la description ci-dessous s'applique exclusivement aux modèles de données de base et aux données transactionnelles des systèmes ERP.

L'explication des formes normales est donnée par un exemple compréhensible au niveau du ménage pour la plupart des lecteurs. Cependant, à titre d'illustration, aux paragraphes 4 à 5, la tâche «inventée» soulignée a été délibérément utilisée. Si vous ne faites pas cela et prenez un exemple de manuel, par exemple, le même modèle de stockage des commandes de la clause 2, vous pouvez vous retrouver dans une situation où l'attention du lecteur sera déplacée de la décomposition proposée du processus dans un modèle, vers une expérience personnelle et une perception de la façon dont des processus et des modèles de stockage de données sur IP devraient être construits. En d'autres termes, prenez deux analystes informatiques qualifiés, laissez l'un fournir des services aux logisticiens transportant des passagers et l'autre aux logisticiens transportant des machines pour la production de micropuces. Demandez-leur, sans discuter de la BP pré-automatisée, de créer un modèle de données pour stocker des informations sur le vol ferroviaire.

Il y a une probabilité non nulle que dans les modèles proposés, vous trouverez non seulement un ensemble d'attributs sensiblement différent, mais également des ensembles d'entités différents, car chaque analyste s'appuiera sur ses processus et tâches habituels. Et dire dans une telle situation quel modèle est «correct» est impossible, car il n'y a pas de critère d'évaluation.

2. Formes normales

La première forme normale de la base de données nécessite l'atomicité de tous les attributs.
En particulier, si l'objet A a des attributs non clés a et b, tels que c = f (a, b) et dans le tableau décrivant l'objet A, vous stockez la valeur de l'attribut c, le premier formulaire normal est violé dans la base de données. Par exemple, si la spécification de commande spécifie une quantité dont les unités de mesure dépendent du type de produit: dans un cas, il peut s'agir de pièces, dans les autres litres, dans le troisième emballage composé de pièces (dans le modèle ci-dessus Good_count_WR), alors l'atomicité des attributs est violée dans la base de données. Dans ce cas, pour dire à quoi devrait ressembler la douille des tables pour la spécification de la commande, vous avez besoin d'une description ciblée du processus de travail dans l'IP, et puisque les processus peuvent être différents, il peut y avoir de nombreuses versions «correctes».

La deuxième forme normale de la base de donnéesexige le respect du premier formulaire et de son propre tableau pour chaque entité liée au processus de travail en PI. Si dans un tableau il y a des dépendances c = f1 (a) et d = f2 (b) et qu'il n'y a pas de dépendance c = f3 (b), alors la deuxième forme normale est violée dans le tableau. Dans l'exemple ci-dessus, dans le tableau «Commande», il n'y a pas de relation entre la commande et l'adresse. Changez le nom de la rue ou de la ville et vous n'aurez aucune influence sur les attributs essentiels de la commande.

La troisième forme normale de la base de donnéesnécessite le respect de la deuxième forme normale et l'absence de dépendances fonctionnelles entre les attributs des différentes entités. Cette règle peut être formulée comme suit: "tout ce qui peut être calculé doit être calculé". En d'autres termes, s'il y a deux objets A et B.Dans la table qui stocke les attributs de l'objet A, l'attribut C est affiché, l'objet B a l'attribut b, de sorte que c = f4 (b) existe, alors la troisième forme normale est violée. Dans l'exemple ci-dessous, l'attribut «Nombre de pièces» (Total_count_WR) dans l'enregistrement de commande prétend clairement violer le troisième formulaire normal

3. Mon approche de l'application de la normalisation

1. Seul le processus métier automatisé cible peut fournir à l'analyse des critères d'identification des entités et des attributs lors de la création d'un modèle de stockage de données. La création d'un modèle de processus est une condition préalable à la création d'un modèle de données normal.

2. La réalisation de la troisième forme normale au sens strict peut ne pas être pratique dans la pratique actuelle de création de systèmes ERP lorsque tout ou partie des conditions suivantes sont remplies:

les processus automatisés sont rarement sujets à changement,
les délais de recherche et 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 n'entraînent pas de perte d'argent ou de clients par le client du logiciel)
etc.

Dans les conditions décrites, les coûts d'identification, une 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. Toutes les conséquences de la dénormalisation du modèle de données dans l'IP déjà créé peuvent être arrêtées par une étude préliminaire approfondie du code et des tests.

4. La dénormalisation est un moyen de transférer les coûts de main-d'œuvre du stade de la recherche de sources de données et de la conception d'un processus métier au stade de développement, de la période de mise en œuvre à la période de développement du système.

5. Il est conseillé de rechercher la troisième forme normale de la base de données si:

L'orientation du changement dans les processus commerciaux automatisés est difficile à prévoir
Il existe une division perméable du travail au sein de l'équipe de mise en œuvre et / ou de développement
Les systèmes inclus dans le circuit d'intégration évoluent selon leurs propres plans.
L'incohérence des données peut entraîner la perte de clients ou d'argent par l'entreprise

6. La conception du modèle de données ne doit être effectuée par l'analyste qu'en relation avec les modèles du processus métier cible et du processus IP. Si un développeur est engagé dans la conception d'un modèle de données, il devra plonger dans le domaine à un point tel qu'il devra notamment comprendre la différence entre les valeurs d'attribut - une condition nécessaire pour distinguer les attributs atomiques. Ainsi, prendre des fonctions inhabituelles.

4 Tâche d'illustration

Disons que vous avez une petite taverne robotique dans le port. Votre segment de marché: les marins et les pirates qui font escale au port et ont besoin de repos. Pour les marins, vous vendez du thé au thym, et pour les pirates, des peignes à rhum et à os pour peigner votre barbe. Le service dans la taverne elle-même est assuré par un robot hôtesse et un robot barman. En raison de la haute qualité et des prix bas, vous avez évincé tous vos concurrents, de sorte que tous ceux qui quittent le navire viennent dans votre taverne, qui est la seule du port.

Le complexe des systèmes d'information des tavernes comprend les logiciels suivants:

Système d'alerte précoce du client qui reconnaît sa catégorie par des caractéristiques
Système de gestion pour robots hôtesse et robots barman
Système de gestion d'entrepôt et de point de livraison
Système de gestion des relations avec les fournisseurs (SMSS)

Processus:

Le système d'alerte précoce détecte les personnes quittant le navire. Si une personne est rasée de près, elle le définit comme un marin, si une barbe est trouvée chez une personne, alors il est défini comme un pirate.

En entrant dans la taverne, l'invité entend un message d'accueil du robot hôtesse selon sa catégorie, par exemple: "Ho-ho-ho, cher pirate, allez à la table n ° ..." L'

invité va à la table indiquée, où le robot-barman s'est déjà préparé pour lui des marchandises selon la catégorie. Le robot barman transmet au système d'entrepôt des informations selon lesquelles la prochaine partie de la livraison devrait être augmentée, l'entrepôt SI, sur la base du stockage restant, forme une demande d'achat dans le système de contrôle.

Laissez votre service informatique interne développer un système d'alerte précoce, un entrepreneur externe spécialement conçu pour votre entreprise pour créer un programme de gestion de robot de bar. Et les systèmes de gestion d'entrepôt et de relations avec les fournisseurs sont des solutions en boîte personnalisées du marché.

5. Exemples de dénormalisation et son impact sur le développement de logiciels

Lors de la conception d'un processus commercial, les experts en la matière ont déclaré à l'unanimité que les pirates du monde entier boivent du rhum et se peignent la barbe avec des crêtes d'os, et les marins boivent du thé au thym et sont toujours rasés en douceur.

Un répertoire des types de clients apparaît à partir de deux valeurs: 1 - pirates, 2 - marins, commun à l'ensemble du circuit d'information de l'entreprise.

Le système de notification client enregistre immédiatement le résultat du traitement d'image comme identifiant (ID) du client reconnu et son type: marin ou pirate.

ID d'objet reconnu	Catégorie de client
100500	Pirate
100501	Pirate
100502	Marin

Encore une fois, nous notons que

1. Nos marins sont en fait des gens rasés
2. Nos pirates sont en fait des gens barbus

Quels problèmes dans ce cas doivent être résolus pour que notre structure s'efforce de prendre une troisième forme normale:

attribut violation atomique - Catégorie de client
mélange du fait analysé et conclusion dans un tableau
relation fonctionnelle fixe entre les attributs de différentes entités.

Sous forme normalisée, nous obtiendrions deux tableaux:

la reconnaissance se traduit par un ensemble de caractéristiques établies,

ID d'objet reconnu	Poils
100500	Oui
100501	Oui
100502	Non

le résultat de la détermination du type de client comme application de la logique intégrée au SI pour l'interprétation des signes établis

ID d'objet reconnu	ID d'identification	Catégorie de client
100500	100001	Pirate
100501	100002	Pirate
100502	100003	Marin

Comment une organisation de stockage normalisée peut-elle faciliter le développement d'un complexe IP? Disons que vous avez soudainement de nouveaux clients. Qu'il s'agisse de pirates japonais qui n'ont peut-être pas de barbe, mais ils marchent avec un perroquet sur les épaules, et des pirates environnementaux, vous pouvez facilement les reconnaître par le profil bleu de Greta sur leur poitrine gauche.

Les pirates de l'environnement, bien sûr, ne peuvent pas utiliser de crêtes osseuses et nécessitent un analogue du plastique marin recyclé.

Vous devez retravailler les algorithmes des programmes conformément à la nouvelle introduction. Si les règles de normalisation étaient respectées, vous n'auriez qu'à ajouter des entrées pour certaines branches de processus et créer de nouvelles branches uniquement pour les cas et dans les adresses IP où la racine des cheveux sur le visage est importante. Mais, comme les règles n'ont pas été respectées, vous devrez analyser tout le code, dans tout le circuit, où les valeurs du répertoire des types de clients sont utilisées et établir sans ambiguïté que dans un cas, l'algorithme devrait prendre en compte les activités professionnelles du client, et dans les autres caractéristiques physiques.

Dans une vue qui tend à se normaliser, nous obtiendrions deux tables avec des données opérationnelles et deux répertoires:

la reconnaissance se traduit par un ensemble de caractéristiques établies,


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

La dénormalisation détectée signifie-t-elle que les systèmes ne peuvent pas être modifiés dans de nouvelles conditions? Bien sûr que non. Si vous imaginez que toutes les adresses IP ont été créées par une seule équipe avec un roulement de personnel nul, que le développement est bien documenté et que les informations dans l'équipe sont transmises sans perte, alors les changements requis peuvent être des produits avec un effort négligeable. Mais si nous revenons aux conditions initiales de la tâche, seuls 1,5 claviers et 0,5 de plus pour l'enregistrement des procédures de passation de marchés ne seront effacés que pour l'impression des protocoles de discussions conjointes.

Dans l'exemple ci-dessus, les trois formes normales sont violées, essayons de les violer individuellement.

Violation de la première forme normale:

Supposons que les marchandises soient livrées à votre entrepôt à partir des entrepôts des fournisseurs à vos frais en utilisant une gazelle de 1,5 tonne appartenant à votre taverne. La taille de vos commandes est si faible par rapport au chiffre d'affaires des fournisseurs qu'elles sont toujours réalisées en tête à tête sans attente de production. Avez-vous besoin de tableaux séparés pour une telle alimentation: véhicules, types de véhicules, avez-vous besoin de séparer le plan et le fait dans vos commandes aux fournisseurs partis?

Imaginez simplement combien de connexions «supplémentaires» vos programmeurs devront écrire si vous utilisez le modèle ci-dessous pour développer un programme.

Supposons que nous ayons décidé que la structure proposée est inutilement compliquée, dans notre cas, la séparation du plan et le fait dans le dossier de commande sont des informations redondantes, et la spécification de la commande générée est écrasée par les résultats de l'acceptation des marchandises arrivées, un rare tri et l'arrivée de marchandises de qualité inadéquate sont réglés en dehors de la PI.
Et puis un jour, vous voyez comment toute la salle de la taverne est remplie de pirates indignés et négligés. Qu'est-il arrivé?

Il s'est avéré qu'avec la croissance de votre entreprise, la consommation a également augmenté. Une décision de gestion a été prise une fois que si une gazelle était surchargée en volume et / ou en poids, ce qui était extrêmement rare, le fournisseur privilégiait le chargement en faveur des boissons.

Les marchandises non livrées tombaient dans la commande suivante et partaient sur un nouveau vol, la présence d'un solde irréductible dans l'entrepôt de la taverne permettait de ne pas remarquer les cas perforés.

Le dernier concurrent a fermé au port, et le cas de surcharge de gazelle perforée, contourné par une hiérarchisation basée sur l'hypothèse de la suffisance de l'équilibre minimum et de la sous-charge périodique du véhicule, est devenu une pratique courante. Le système créé fonctionnera idéalement conformément aux algorithmes qui y sont définis et sera privé de toute possibilité de suivre la non-exécution systématique des ordres planifiés. Seule une réputation endommagée et des clients insatisfaits pourront détecter le problème.

Un lecteur attentif doit avoir remarqué que la quantité commandée dans le cahier des charges (T_ORDER_SPEC) des sections 2 et 5 peut ou non satisfaire à l'exigence du premier formulaire normal. Tout dépend si, pour un assortiment sélectionné de marchandises, des unités de mesure essentiellement différentes peuvent tomber dans le même domaine.

Violation de la deuxième forme normale:

À mesure que vos besoins augmentent, vous obtenez quelques véhicules de plus de différentes tailles. Dans le contexte ci-dessus, la création d'un répertoire de véhicules a été considérée comme redondante, par conséquent, tous les algorithmes de manipulation de données qui répondent aux besoins de livraison et d'entrepôt perçoivent le mouvement des marchandises du fournisseur vers l'entrepôt comme un vol de gazelle exclusivement de 1,5 tonne. Ainsi, avec l'achat de nouveaux véhicules, vous créez toujours un répertoire de véhicules, mais lors de la finalisation, vous devrez analyser l'intégralité du code qui se réfère au mouvement de la cargaison pour savoir si des références aux caractéristiques de la voiture à partir de laquelle entreprise a commencé.

Violation de la troisième forme normale:

À un moment donné, vous commencez à créer un programme de fidélité, un dossier client régulier apparaît. Pourquoi, par exemple, passer du temps à créer des représentations matérielles qui stockent des données de ventes agrégées pour un client individuel pour les utiliser dans les rapports et les transférer vers des systèmes analytiques, si au début du programme de fidélité tout ce qui intéresse le client peut être placé dans ses propres enregistrements? Et, en effet, cela n'a aucun sens à première vue. Mais chaque fois que votre entreprise se connecte, par exemple, de nouveaux canaux de vente, il devrait y avoir quelqu'un parmi vos analystes qui se souvient qu'il existe un tel attribut d'agrégation.

Lors de la conception de chaque nouveau processus, par exemple, la vente sur Internet, la vente via des distributeurs connectés à un système de fidélisation commun, il convient de garder à l'esprit que tous les nouveaux processus doivent garantir l'intégrité des données au niveau du code. Pour une base de données industrielle avec mille tables, cela semble une tâche impossible.

Un développeur expérimenté, bien sûr, sait comment arrêter tous les problèmes mentionnés ci-dessus, mais, à mon avis, la tâche d'un analyste expérimenté n'est pas de les porter à leur attention.

Je tiens à exprimer ma gratitude pour les précieux commentaires lors de la préparation de la publication au développeur principal Evgeny Yarukhin.

Littérature

https://habr.com/en/post/254773/
Connolly Thomas, Begg Carolyn. Base de données. Conception, mise en œuvre et maintenance. Théorie et pratique