Bonjour! Je m'appelle Andrey Semenov, je suis analyste principal chez Sportmaster. Dans cet article, je souhaite aborder la question de la dénormalisation des bases de données du système ERP. Nous examinerons les conditions générales, ainsi qu'un exemple spécifique - disons que ce serait une merveilleuse taverne monopolistique pour les pirates et les marins. Dans lequel les pirates et les marins doivent être servis différemment, car les idées sur la beauté et les modes de consommation de ces bons messieurs sont très différentes.
Comment rendre tout le monde heureux ? Comment éviter de devenir fou en concevant et en entretenant un tel système ? Que faire si non seulement les pirates et les marins habituels commencent à venir à la taverne ?
Tout est sous la coupe. Mais allons-y dans l'ordre.
1. Limites et hypothèses
Tout ce qui précède s'applique uniquement aux bases de données relationnelles. Les conséquences de la dénormalisation sous forme d'anomalies de modification, de suppression et d'insertion, bien couvertes, y compris sur Internet, ne sont pas prises en compte. En dehors du cadre de cette publication, il existe des cas où la dénormalisation est un lieu courant, avec des exemples classiques : série et numéro de passeport, date et heure, etc.
L'article utilise des définitions intuitives et pratiquement applicables des formes normales, sans référence à des termes mathématiques. Sous la forme sous laquelle ils peuvent être appliqués à l’examen de processus métiers réels (BP) et à la conception de logiciels industriels.
Il est avancé que la conception des entrepôts de données, des outils de reporting et des accords d'intégration (qui utilisent des représentations tabulaires de l'information) diffère de la conception des bases de données du système ERP dans la mesure où la facilité de consommation et le recours à une dénormalisation consciente pour y parvenir peuvent avoir préséance sur l'intégrité. données de protection. Je partage cet avis et ce qui est décrit ci-dessous s'applique uniquement aux modèles de données de base et de données transactionnelles des systèmes ERP.
Une explication des formes normales est donnée à l'aide d'un exemple compréhensible au niveau quotidien pour la plupart des lecteurs. Cependant, à titre d'illustration visuelle, aux paragraphes 4 et 5, une tâche délibérément « fictive » a été délibérément utilisée. Si vous ne le faites pas et prenez un exemple de manuel, par exemple le même modèle de stockage de commandes du point 2, vous pourriez vous retrouver dans une situation où l'attention du lecteur sera déplacée de la décomposition proposée du processus vers un modèle, à l'expérience personnelle et à la perception de la manière dont les processus et les modèles de stockage des données dans le SI doivent être construits. En d’autres termes, prenons deux analystes informatiques qualifiés, l’un fournissant des services aux logisticiens transportant des passagers, l’autre aux logisticiens transportant des machines pour la production de puces électroniques. Demandez-leur, sans discuter au préalable des BP automatisés, de créer un modèle de données pour stocker les informations sur un voyage en train.
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 divergents, car chaque analyste s'appuiera sur des processus et des 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
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 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 base de données. . Par exemple, si le cahier des charges indique 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 un autre de litres, dans un troisième de colis constitués 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 quel doit être le cluster de tableaux de la spécification de commande, vous avez besoin d'une description ciblée du processus de travail dans le SI, et comme les processus peuvent être différents, il peut y avoir de nombreuses versions « correctes ».
Deuxième forme normale de la base de données exige le respect du premier formulaire et de son propre tableau pour chaque entité liée au processus de travail dans le SI. Si dans une table 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 la table. Dans l'exemple ci-dessus, il n'y a aucune dépendance entre la commande et l'adresse dans la table Commande. Changez le nom de la rue ou de la ville et vous n'aurez aucun effet sur les attributs essentiels de la commande.
Troisième base de données de forme normale né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 ainsi : « 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 stockant les attributs de l'objet A, l'attribut C est manifesté et l'objet B a l'attribut b, tel que c=f4(b) existe, alors la troisième forme normale est violée. Dans l'exemple ci-dessous, l'attribut Quantité de pièces (Total_count_WR) sur l'enregistrement de la commande prétend clairement violer la troisième forme normale.
3. Mon approche de l'application de la normalisation
1. Seul un processus métier automatisé cible peut fournir à l'analyste 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. Atteindre la troisième forme normale au sens strict peut ne pas être pratique dans la pratique réelle de création de systèmes ERP si 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 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. Les éventuelles conséquences d'une dénormalisation du modèle de données dans un SI déjà créé peuvent être atténué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 recherche des sources de données et de 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 privilégier la troisième forme normale d'une base de données si :
- La direction du changement dans les processus métier automatisés est difficile à prévoir
- Il existe une faible division 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 se développent selon leurs propres plans
- L'incohérence des données peut entraîner une perte de clients ou d'argent pour une entreprise
6. La conception d'un modèle de données doit être réalisée par un analyste uniquement en relation avec les modèles du processus métier cible et le processus du SI. Si un développeur conçoit un modèle de données, il devra s'immerger dans le domaine à tel point qu'il comprend notamment la différence entre les valeurs d'attribut - une condition nécessaire pour isoler les attributs atomiques. Ainsi, assumant des fonctions inhabituelles.
4 Problème à titre d'illustration
Disons que vous avez une petite taverne robotique dans le port. Votre segment de marché : les marins et pirates qui débarquent au port et ont besoin d'une pause. Vous vendez du thé au thym aux marins, et du rhum et des peignes en os pour peigner la barbe aux pirates. Le service dans la taverne elle-même est assuré par une hôtesse robot et un robot barman. Grâce à votre qualité élevée et à vos prix bas, vous avez chassé vos concurrents, de sorte que tous ceux qui descendent du navire viennent dans votre taverne, qui est la seule du port.
Le complexe de systèmes d'information de la taverne se compose des logiciels suivants :
- Un système d'alerte précoce concernant un client qui reconnaît sa catégorie en fonction de ses caractéristiques
- Système de contrôle pour robots hôtesses et robots barmans
- Système de gestion d'entrepôt et de livraison au point de vente
- Système de gestion de la relation fournisseur (SURP)
Processus:
Le système d'alerte précoce reconnaît les personnes qui quittent le navire. Si une personne est rasée de près, elle l'identifie comme un marin ; si une personne porte la barbe, elle est alors identifiée comme un pirate.
En entrant dans la taverne, le client entend un message de bienvenue de la part de l'hôtesse robot en fonction de sa catégorie, par exemple : "Ho-ho-ho, cher pirate, va à la table No..."
L'invité se rend à la table indiquée, où le robot barman lui a déjà préparé des marchandises conformément à la catégorie. Le robot barman transmet au système d'entrepôt l'information selon laquelle la prochaine partie de la livraison doit être augmentée ; le SI de l'entrepôt, en fonction des soldes restants en stock, génère une demande d'achat dans le système de gestion.
Bien que le système d'alerte précoce ait pu être développé par votre service informatique interne, le programme de gestion des robots de bar peut avoir été créé par un sous-traitant externe spécifiquement pour votre entreprise. Et les systèmes de gestion des entrepôts et des relations avec les fournisseurs sont des solutions packagées 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 interrogés ont déclaré à l'unanimité que partout dans le monde, les pirates boivent du rhum et se peignent la barbe avec des peignes en os, et que les marins boivent du thé au thym et sont toujours rasés de près.
Un répertoire de types de clients apparaît avec deux valeurs : 1 - pirates, 2 - marins, communs à tout le circuit d'information de l'entreprise.
Le système de notification client stocke immédiatement le résultat du traitement d'image comme l'identifiant (ID) du client reconnu et son type : marin ou pirate.
ID d'objet reconnu
Catégorie de client
100500
Pirate
100501
Pirate
100502
Моряк
Notons encore une fois que
1. Nos marins sont en réalité des gens rasés
2. Nos pirates sont en réalité des barbus
Quels problèmes dans ce cas doivent être éliminés pour que notre structure s'efforce d'atteindre la troisième forme normale :
- violation d'atomicité d'attribut - Catégorie de client
- mélanger le fait analysé et la conclusion dans un seul tableau
- relation fonctionnelle fixe entre les attributs de différentes entités.
Sous forme normalisée, nous obtiendrions deux tableaux :
- résultat de la reconnaissance sous la forme d'un ensemble de caractéristiques établies,
ID d'objet reconnu
Poils
100500
Oui
100501
Oui
100502
Aucun
- le résultat de la détermination du type de client comme application de la logique embarquée dans le SI pour interpréter les caractéristiques établies
ID d'objet reconnu
Identifiant
Catégorie de client
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Моряк
Comment une organisation normalisée de stockage de données peut-elle faciliter le développement d’un complexe IP ? Disons que vous obtenez soudainement de nouveaux clients. Que ce soit des pirates japonais qui n'ont peut-être pas de barbe, mais qui marchent avec un perroquet sur l'épaule, et des pirates écologistes, vous pouvez facilement les reconnaître grâce au profil bleu de Greta sur la poitrine gauche.
Les pirates environnementaux ne peuvent naturellement pas utiliser de peignes en os et exigent un analogue fabriqué à partir de plastique marin recyclé.
Vous devez retravailler les algorithmes du programme en fonction des nouvelles entrées. Si les règles de normalisation étaient suivies, vous n'auriez qu'à compléter les entrées de certaines branches de processus dans certains systèmes et à créer de nouvelles branches uniquement pour les cas et dans les SI où la pilosité faciale est importante. Mais, comme les règles n'ont pas été respectées, vous devrez analyser l'intégralité du code, tout au long du circuit, où sont utilisées les valeurs du répertoire de type client et établir clairement que dans un cas l'algorithme doit prendre en compte le professionnel activité du client, et dans les autres caractéristiques physiques.
Sous une forme qui cherche Pour normaliser, nous obtiendrions deux tables avec des données opérationnelles et deux répertoires :
- résultat de la reconnaissance sous la forme d'un ensemble de caractéristiques établies,
ID d'objet reconnu
Greta sur la poitrine gauche
Oiseau sur l'épaule
Poils
100510
1
1
1
100511
0
0
1
100512
1
0
- le résultat de la détermination du type de client (que ce soit une vue personnalisée dans laquelle les descriptions des répertoires sont affichées)
La dénormalisation détectée signifie-t-elle que les systèmes ne peuvent pas être modifiés pour répondre à de 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 roulement de personnel nul, que les développements sont bien documentés et que les informations sont transférées au sein de l'équipe sans perte, alors les changements requis peuvent être apportés avec un effort négligeable. Mais si l'on revient aux conditions initiales du problème, 1,5 clavier sera effacé uniquement pour l'impression des protocoles de discussions communes et 0,5 autre pour le traitement des procédures de passation des marchés.
Dans l'exemple ci-dessus, les trois formes normales sont violées, essayons de les violer séparément.
Violation de la première forme normale :
Disons que les marchandises sont livrées à votre entrepôt depuis les entrepôts des fournisseurs par ramassage à l'aide d'une gazelle de 1.5 tonne appartenant à votre taverne. La taille de vos commandes est si petite par rapport au chiffre d’affaires des fournisseurs qu’elles sont toujours exécutées en tête-à-tête sans attendre la production. Avec un tel processus métier, avez-vous besoin de tableaux séparés : véhicules, types de véhicules, est-il nécessaire de séparer plan et 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.
Disons que nous avons décidé que la structure proposée est inutilement complexe ; dans notre cas, séparer le plan et le fait dans l'enregistrement de la commande est une information redondante, et la spécification de commande générée est réécrite sur la base des résultats de l'acceptation des marchandises arrivées, une erreur rare -le classement et l'arrivée des marchandises de qualité insuffisante sont réglés en dehors du SI.
Et puis un jour, vous voyez comment toute la salle de la taverne est remplie de pirates indignés et négligés. Ce qui s'est passé?
Il s’avère qu’à mesure que votre entreprise se développe, votre consommation évolue également. Il était une fois une décision de la direction selon laquelle si une gazelle était surchargée en volume et/ou en poids, ce qui était extrêmement rare, le fournisseur donnerait la priorité au chargement en faveur des boissons.
Les marchandises non livrées se retrouvaient dans la commande suivante et partaient sur un nouveau vol ; la présence d'un solde minimum dans l'entrepôt de la taverne permettait de ne pas constater les caisses manquantes.
Le dernier concurrent a fermé ses portes au port, et le cas de surcharge de gazelle, contourné par une priorisation basée sur l'hypothèse de la suffisance du solde minimum et d'une 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 intégrés et sera privé de toute possibilité de suivre l'échec systématique de l'exécution des commandes planifiées. Seuls une réputation entachée et des clients insatisfaits pourront détecter le problème.
Un lecteur attentif aura peut-être remarqué que la quantité commandée dans la spécification de commande (T_ORDER_SPEC) dans les sections 2 et 5 peut ou non répondre à l'exigence de première forme normale. Tout dépend si, compte tenu de l'assortiment de produits sélectionné, des unités de mesure essentiellement différentes peuvent tomber dans le même domaine.
Violation de la deuxième forme normale :
Au fur et à mesure que vos besoins augmentent, vous achetez quelques véhicules supplémentaires 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 ; en conséquence, tous les algorithmes informatiques répondant aux besoins de livraison et d'entrepôt perçoivent le mouvement des marchandises du fournisseur à l'entrepôt comme le vol d'un avion exclusivement de 1,5 tonne. gazelle. Ainsi, parallèlement à l'achat de véhicules neufs, vous créez toujours un répertoire de véhicules, mais lors de sa finalisation, vous devrez analyser tout le code qui fait référence au mouvement des marchandises pour savoir si à chaque endroit spécifique des références aux caractéristiques sont implicites. du véhicule même à partir duquel les affaires ont commencé.
Violation de la troisième forme normale :
À un moment donné, vous commencez à créer un programme de fidélité, un enregistrement d'un client régulier apparaît. Pourquoi, par exemple, passer du temps à créer des vues matérielles qui stockent des données agrégées sur les ventes à un client individuel pour les utiliser dans les rapports et les transférer vers des systèmes analytiques, si au début d'un programme de fidélité, tout ce qui intéresse le client peut être placé dans le dossier du client. ? Et effectivement, à première vue, cela ne sert à rien. Mais chaque fois que votre entreprise connecte, par exemple, de nouveaux canaux de vente, il devrait y avoir quelqu'un parmi vos analystes qui se souviendra de l'existence d'un tel attribut d'agrégation.
Lors de la conception de chaque nouveau processus, par exemple les ventes sur Internet, les ventes via des distributeurs connectés à un système de fidélisation commun, il faut 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 comportant un millier de tables, cela semble une tâche impossible.
Un développeur expérimenté, bien sûr, sait comment résoudre tous les problèmes mentionnés ci-dessus, mais, à mon avis, la tâche d'un analyste expérimenté n'est pas de les mettre en lumière.
Je voudrais exprimer ma gratitude au principal développeur Evgeniy Yarukhin pour ses précieux commentaires lors de la préparation de la publication.
littérature
Connolly Thomas, mendiant Caroline. Base de données. Conception, mise en œuvre et support. Théorie et pratique
Source: habr.com