Ciao! Mi chiamo Andrey Semenov, sono un analista senior di Sportmaster. In questo post voglio sollevare la questione della denormalizzazione dei database del sistema ERP. Considereremo le condizioni generali, nonché un esempio specifico: diciamo che sarebbe una meravigliosa taverna monopolistica per pirati e marinai. In cui pirati e marinai devono essere serviti diversamente, perché le idee di bellezza e i modelli di consumo di questi bravi signori sono significativamente diverse.
Come rendere tutti felici? Come evitare di impazzire progettando e mantenendo un sistema del genere? Cosa fare se alla taverna cominciano a venire non solo i soliti pirati e marinai?
Tutto è sotto taglio. Ma andiamo con ordine.
1. Limitazioni e presupposti
Tutto quanto sopra si applica solo ai database relazionali. Non vengono prese in considerazione le conseguenze della denormalizzazione sotto forma di modifiche, cancellazioni e anomalie di inserimento, che sono ampiamente trattate, anche su Internet. Al di fuori dell'ambito di questa pubblicazione ci sono casi in cui la denormalizzazione è un luogo comune, con esempi classici: serie e numero di passaporto, data e ora, ecc.
Il post utilizza definizioni intuitive e praticamente applicabili di forme normali, senza riferimento a termini matematici. Nella forma in cui possono essere applicati all'esame di processi aziendali reali (BP) e alla progettazione di software industriale.
Si sostiene che la progettazione di data warehouse, strumenti di reporting e accordi di integrazione (che utilizzano rappresentazioni tabulari delle informazioni) differisce dalla progettazione dei database dei sistemi ERP in quanto la facilità di consumo e l'uso della denormalizzazione consapevole per ottenerla possono avere la precedenza sull'integrità dati di protezione. Condivido questa opinione e quanto descritto di seguito si applica esclusivamente ai modelli di dati anagrafici e dati transazionali dei sistemi ERP.
Viene fornita una spiegazione delle forme normali utilizzando un esempio comprensibile a livello quotidiano per la maggior parte dei lettori. Tuttavia, come illustrazione visiva, nei paragrafi 4-5 è stato deliberatamente utilizzato un compito deliberatamente “immaginario”. Se non lo fai e prendi qualche esempio da un libro di testo, ad esempio lo stesso modello di archiviazione degli ordini del punto 2, potresti trovarti in una situazione in cui l'attenzione del lettore verrà spostata dalla scomposizione proposta del processo a un modello, all’esperienza personale e alla percezione di come devono essere costruiti processi e modelli per l’archiviazione dei dati nei SI. In altre parole, prendiamo due analisti informatici qualificati, uno fornisce servizi ai logisti che trasportano passeggeri, l'altro ai logisti che trasportano macchine per la produzione di microchip. Chiedere loro, senza discutere in anticipo le BP automatizzate, di creare un modello di dati per archiviare informazioni su un viaggio ferroviario.
Esiste una probabilità diversa da zero che nei modelli proposti troverete non solo un insieme di attributi notevolmente diversi, ma anche insiemi di entità divergenti, perché ogni analista farà affidamento sui processi e sui compiti a lui familiari. E in una situazione del genere è impossibile dire quale modello sia “corretto”, perché non esiste un criterio di valutazione.
2. Forme normali
Prima forma normale del database richiede atomicità di tutti gli attributi.
In particolare, se l'oggetto A ha attributi non chiave a e b, tali che c=f(a,b) e nella tabella che descrive l'oggetto A si memorizza il valore dell'attributo c, allora nel database viene violata la prima forma normale . Ad esempio, se la specifica dell'ordine indica una quantità, le cui unità di misura dipendono dal tipo di prodotto: in un caso possono essere pezzi, in un altro litri, in un terzo confezioni composte da pezzi (nel modello sopra Good_count_WR) , l'atomicità degli attributi viene violata nel database. In questo caso, per dire quale dovrebbe essere il cluster di tabelle della specifica dell'ordine, è necessaria una descrizione mirata del processo di lavoro nell'IS e poiché i processi possono essere diversi, possono esserci molte versioni “corrette”.
Seconda forma normale del database richiede il rispetto del primo modulo e di una propria tabella per ciascuna entità relativa al processo lavorativo nel SI. Se in una tabella ci sono dipendenze c=f1(a) e d=f2(b) e non c'è dipendenza c=f3(b), allora nella tabella è violata la seconda forma normale. Nell'esempio precedente non esiste alcuna dipendenza tra ordine e indirizzo nella tabella Ordini. Cambia il nome della via o della città e non avrai alcun effetto sugli attributi essenziali dell'ordine.
Terzo database in forma normale richiede il rispetto della seconda forma normale e l'assenza di dipendenze funzionali tra attributi di entità diverse. Questa regola può essere formulata come segue: “tutto ciò che può essere calcolato deve essere calcolato”. In altre parole, se ci sono due oggetti A e B. Nella tabella che memorizza gli attributi dell'oggetto A, l'attributo C è manifesto e l'oggetto B ha l'attributo b, in modo tale che esiste c=f4(b), allora la terza forma normale è violato. Nell'esempio seguente, l'attributo Quantità di pezzi (Total_count_WR) nel record dell'ordine afferma chiaramente di violare la terza forma normale
3. Il mio approccio all'applicazione della normalizzazione
1. Solo un processo aziendale automatizzato di destinazione può fornire all'analista criteri per identificare entità e attributi durante la creazione di un modello di archiviazione dei dati. La creazione di un modello di processo è un prerequisito per la creazione di un modello dati normale.
2. Il raggiungimento della terza forma normale in senso stretto potrebbe non essere pratico nella pratica effettiva della creazione di sistemi ERP se vengono soddisfatte alcune o tutte le seguenti condizioni:
- i processi automatizzati sono raramente soggetti a modifiche,
- le scadenze per la ricerca e lo sviluppo sono strette,
- i requisiti per l'integrità dei dati sono relativamente bassi (eventuali errori nel software industriale non portano alla perdita di denaro o di clienti da parte del cliente del software)
- eccetera
Nelle condizioni descritte, i costi per identificare e descrivere il ciclo di vita di alcuni oggetti e i loro attributi potrebbero non essere giustificati dal punto di vista dell’efficienza economica.
3. Eventuali conseguenze della denormalizzazione del modello dati in un IS già creato possono essere mitigate da uno studio preliminare approfondito del codice e da test.
4. La denormalizzazione è un modo per trasferire i costi del lavoro dalla fase di ricerca delle fonti di dati e di progettazione di un processo aziendale alla fase di sviluppo, dal periodo di implementazione al periodo di sviluppo del sistema.
5. È consigliabile tendere alla terza forma normale di banca dati se:
- La direzione del cambiamento nei processi aziendali automatizzati è difficile da prevedere
- Esiste una debole divisione del lavoro all'interno del team di implementazione e/o sviluppo
- I sistemi inclusi nel circuito di integrazione si sviluppano secondo i propri piani
- L'incoerenza dei dati può comportare la perdita di clienti o denaro da parte di un'azienda
6. La progettazione di un modello di dati dovrebbe essere effettuata da un analista solo in connessione con i modelli del processo aziendale target e del processo nell'IS. Se uno sviluppatore sta progettando un modello di dati, dovrà immergersi nell'argomento a tal punto da comprendere, in particolare, la differenza tra i valori degli attributi, una condizione necessaria per isolare gli attributi atomici. Assumendo così funzioni insolite.
4 Problema illustrativo
Supponiamo che tu abbia una piccola taverna robotica nel porto. Il tuo segmento di mercato: marinai e pirati che entrano in porto e hanno bisogno di una pausa. Ai marinai vendi tè con timo, ai pirati rum e pettini d'osso per pettinare la barba. Il servizio nella taverna stessa è fornito da una hostess robot e da un barista robot. Grazie alla vostra alta qualità e ai prezzi bassi, avete scacciato i vostri concorrenti, tanto che tutti quelli che scendono dalla nave vengono nella vostra taverna, che è l'unica del porto.
Il complesso dei sistemi informativi della taverna è costituito dai seguenti software:
- Un sistema di allarme precoce su un cliente che riconosce la sua categoria in base alle caratteristiche caratteristiche
- Sistema di controllo per hostess robot e baristi robot
- Sistema di gestione del magazzino e delle consegne al punto vendita
- Sistema di gestione dei rapporti con i fornitori (SURP)
processo:
Il sistema di allarme rapido riconosce le persone che lasciano la nave. Se una persona è ben rasata, viene identificata come un marinaio; se si scopre che una persona ha la barba, viene identificata come un pirata.
Entrando nella taverna, l'ospite sente il saluto della padrona di casa robot conforme alla sua categoria, ad esempio: "Ho-ho-ho, caro pirata, vai al tavolo No..."
L'ospite si reca al tavolo indicato, dove il barista robot ha già preparato per lui la merce secondo la categoria. Il robot barista trasmette al sistema di magazzino l'informazione che la porzione successiva di consegna dovrà essere incrementata; il magazzino IS, in base ai saldi rimanenti in magazzino, genera una richiesta di acquisto nel sistema gestionale.
Mentre il sistema di allarme rapido potrebbe essere stato sviluppato dal tuo IT interno, il programma di gestione del robot da barra potrebbe essere stato creato da un appaltatore esterno appositamente per la tua azienda. E i sistemi di gestione dei magazzini e dei rapporti con i fornitori sono soluzioni confezionate su misura dal mercato.
5. Esempi di denormalizzazione e suo impatto sullo sviluppo del software
Nel progettare un processo aziendale, gli esperti in materia intervistati hanno affermato all'unanimità che in tutto il mondo i pirati bevono rum e si pettinano la barba con pettini d'osso, e i marinai bevono tè con timo e sono sempre ben rasati.
Appare un elenco di tipologie di clienti con due valori: 1 - pirati, 2 - marinai, comuni per tutto il circuito informativo dell'azienda.
Il sistema di notifica del cliente memorizza immediatamente il risultato dell'elaborazione dell'immagine come identificatore (ID) del cliente riconosciuto e la sua tipologia: marinaio o pirata.
ID oggetto riconosciuto
Categoria cliente
100500
pirata
100501
pirata
100502
Marinaio
Notiamolo ancora una volta
1. I nostri marinai sono in realtà persone rasate
2. I nostri pirati sono in realtà persone barbute
Quali problemi in questo caso devono essere eliminati affinché la nostra struttura miri alla terza forma normale:
- violazione dell'atomicità dell'attributo - Categoria cliente
- mescolando il fatto analizzato e la conclusione in un'unica tabella
- relazione funzionale fissa tra attributi di entità diverse.
In forma normalizzata, otterremmo due tabelle:
- risultato del riconoscimento sotto forma di un insieme di caratteristiche stabilite,
ID oggetto riconosciuto
Peli del viso
100500
Sì
100501
Sì
100502
No
- il risultato della determinazione della tipologia del cliente come applicazione della logica incorporata nell'IS per interpretare le caratteristiche stabilite
ID oggetto riconosciuto
Identificativo
Categoria cliente
100500
100001
pirata
100501
100002
pirata
100502
100003
Marinaio
In che modo un'organizzazione normalizzata di archiviazione dei dati può facilitare lo sviluppo di un complesso IP? Diciamo che improvvisamente ottieni nuovi clienti. Che siano i pirati giapponesi, che magari non hanno la barba, ma camminano con un pappagallo sulla spalla, e i pirati ambientalisti, li potete facilmente riconoscere dal profilo blu di Greta sulla parte sinistra del petto.
I pirati ambientali, naturalmente, non possono usare pettini d'osso e richiedono un analogo realizzato con plastica marina riciclata.
È necessario rielaborare gli algoritmi del programma in base ai nuovi input. Se le regole di normalizzazione fossero seguite, in alcuni sistemi bisognerebbe solo integrare gli input per alcuni rami del processo e creare nuovi rami solo per quei casi e in quegli IS in cui i peli del viso sono importanti. Ma poiché le regole non sono state seguite, dovrai analizzare l'intero codice, lungo l'intero circuito, dove vengono utilizzati i valori della directory del tipo client e stabilire chiaramente che in un caso l'algoritmo dovrebbe tenere conto del professionista attività del cliente e nelle altre caratteristiche fisiche.
In una forma tale стремится per normalizzare, otterremmo due tabelle con dati operativi e due directory:
- risultato del riconoscimento sotto forma di un insieme di caratteristiche stabilite,
ID oggetto riconosciuto
Greta sul petto a sinistra
Uccello sulla spalla
Peli del viso
100510
1
1
1
100511
0
0
1
100512
1
0
- il risultato della determinazione del tipo di client (lascia che sia una vista personalizzata in cui vengono visualizzate le descrizioni delle directory)
La denormalizzazione rilevata significa che i sistemi non possono essere modificati per soddisfare nuove condizioni? Ovviamente no. Se immaginiamo che tutti i sistemi informativi siano stati creati da un team con turnover pari a zero, che gli sviluppi siano ben documentati e che le informazioni vengano trasferite all'interno del team senza perdite, allora le modifiche richieste possono essere apportate con uno sforzo trascurabile. Ma se torniamo alle condizioni originarie del problema, 1,5 tastiere verranno cancellate solo per stampare i protocolli delle discussioni congiunte e altre 0,5 per l'elaborazione delle procedure di appalto.
Nell'esempio sopra, tutte e tre le forme normali sono violate, proviamo a violarle separatamente.
Violazione della prima forma normale:
Supponiamo che le merci vengano consegnate al tuo magazzino dai magazzini dei fornitori tramite ritiro utilizzando una gazzella da 1.5 tonnellate che appartiene alla tua taverna. La dimensione dei tuoi ordini è così piccola rispetto al fatturato dei fornitori che vengono sempre completati individualmente senza attendere la produzione. Hai bisogno di tabelle separate con un processo aziendale di questo tipo: veicoli, tipologie di veicoli, è necessario separare piano e fatto negli ordini ai fornitori partiti?
Immagina quante connessioni “extra” i tuoi programmatori dovranno scrivere se utilizzi il modello seguente per sviluppare un programma.
Diciamo che abbiamo deciso che la struttura proposta è inutilmente complessa; nel nostro caso, separare il piano e il fatto nel record dell'ordine è un'informazione ridondante e la specifica dell'ordine generata viene riscritta in base ai risultati dell'accettazione della merce arrivata, rari errori -la classificazione e l'arrivo della merce di qualità inadeguata vengono regolati al di fuori dell'IS.
E poi un giorno vedi come l'intera sala della taverna è piena di pirati indignati e trasandati. Quello che è successo?
Si scopre che man mano che la tua attività cresceva, aumentavano anche i tuoi consumi. Un tempo la direzione decideva che se una gazzella fosse stata sovraccarica di volume e/o peso, cosa estremamente rara, il fornitore avrebbe dato priorità al carico a favore delle bevande.
La merce non consegnata finiva nell'ordine successivo e partiva su un nuovo volo; la presenza di un saldo minimo nel magazzino presso l'osteria permetteva di non accorgersi delle casse mancanti.
L'ultimo concorrente ha chiuso al porto, e il caso di sovraccarico della gazzella forato, aggirato dalla prioritizzazione basata sul presupposto della sufficienza del saldo minimo e del sottocarico periodico del veicolo, è diventato pratica comune. Il sistema creato funzionerà idealmente in conformità con gli algoritmi in esso incorporati e sarà privato di qualsiasi opportunità di tenere traccia del mancato adempimento sistematico degli ordini pianificati. Solo una reputazione danneggiata e clienti insoddisfatti saranno in grado di rilevare il problema.
Un lettore attento potrebbe aver notato che la quantità ordinata nella specifica dell'ordine (T_ORDER_SPEC) nella sezione 2 e nella sezione 5 può o meno soddisfare il requisito della prima forma normale. Tutto dipende dal fatto se, dato l'assortimento di merci selezionato, unità di misura essenzialmente diverse possano rientrare nello stesso campo.
Violazione della seconda forma normale:
Man mano che le tue esigenze crescono, acquisti un paio di veicoli in più di dimensioni diverse. In questo contesto, la creazione di un elenco dei veicoli è stata considerata ridondante; di conseguenza, tutti gli algoritmi di elaborazione dei dati al servizio delle esigenze di consegna e magazzino percepiscono il movimento della merce dal fornitore al magazzino come il volo di un aereo esclusivamente da 1,5 tonnellate. gazzella. Quindi, insieme all'acquisto di nuovi veicoli, creerai comunque un elenco di veicoli, ma una volta finalizzato, dovrai analizzare tutto il codice che fa riferimento alla circolazione delle merci per scoprire se in ogni specifico luogo sono impliciti riferimenti alle caratteristiche del veicolo stesso da cui è iniziata l'attività.
Violazione della terza forma normale:
Ad un certo punto inizi a creare un programma fedeltà, appare il record di un cliente abituale. Perché, ad esempio, dedicare tempo alla creazione di visualizzazioni materiali che memorizzano dati aggregati sulle vendite a un singolo cliente da utilizzare nel reporting e trasferire a sistemi analitici, se all'inizio di un programma fedeltà tutto ciò che interessa al cliente può essere inserito nel record del cliente ? E, in effetti, a prima vista, non ha senso. Ma ogni volta che la tua azienda collega, ad esempio, nuovi canali di vendita, dovrebbe esserci qualcuno tra i tuoi analisti che ricorderà che esiste un tale attributo di aggregazione.
Quando si progetta ogni nuovo processo, ad esempio le vendite su Internet, le vendite tramite distributori collegati ad un sistema di fidelizzazione comune, qualcuno deve tenere presente che tutti i nuovi processi devono garantire l'integrità dei dati a livello di codice. Per un database industriale con migliaia di tabelle, sembra un compito impossibile.
Uno sviluppatore esperto, ovviamente, sa come risolvere tutti i problemi sopra menzionati, ma, secondo me, il compito di un analista esperto non è portarli alla luce.
Vorrei esprimere la mia gratitudine allo sviluppatore principale Evgeniy Yarukhin per il suo prezioso feedback durante la preparazione della pubblicazione.
Letteratura
Connolly Thomas, Begg Caroline. Banca dati. Progettazione, realizzazione e supporto. Teoria e pratica
Fonte: habr.com