Ciao! Mi chiamo Andrei Semenov, sono analista senior in Sportmaster. In questo post voglio sollevare la questione della denormalizzazione dei database dei sistemi ERP. Esamineremo le condizioni generali, oltre a un esempio concreto: diciamo che sarà una fantastica taverna monopolista per pirati e marinai. In cui i pirati e i marinai devono essere serviti in modo differente, poiché le loro idee sul bello e i pattern di consumo differiscono notevolmente.
Come fare affinché tutti siano soddisfatti? Come non impazzire progettando e mantenendo un sistema del genere? Cosa fare se in taverna iniziano a arrivare non solo i pirati e i marinai abituali?
Tutto è sotto il tag. Ma procediamo con ordine.
1. Limitazioni e assunzioni
Tutto quanto esposto si riferisce solo ai database relazionali. Non si considerano le conseguenze della denormalizzazione, ben documentate anche su Internet, sotto forma di anomalie di modifica, eliminazione e inserimento. Rimangono esclusi i casi in cui la denormalizzazione è una prassi comune, con esempi classici: numero e serie del passaporto, data e ora, ecc.
Nel post vengono utilizzate definizioni di forme normali intuitive e di facile applicazione, senza riferimenti a termini matematici. Nella forma in cui possono essere applicate all'analisi dei processi aziendali reali e alla progettazione di software industriale.
Esiste l'opinione che la progettazione di data warehouse, strumenti per la creazione di report e accordi di integrazione (in cui si utilizza la rappresentazione tabellare delle informazioni) differisca dalla progettazione dei database dei sistemi ERP in quanto la comodità d'uso e l'applicazione della denormalizzazione consapevole possono avere la priorità sulla protezione dell'integrità dei dati. Condivido questa opinione, e quanto descritto di seguito si applica esclusivamente ai modelli di master data e dati transazionali dei sistemi ERP.
La spiegazione delle forme normali è presentata attraverso un esempio comprensibile a livello pratico per la maggior parte dei lettori. Tuttavia, come illustrazione visiva, nei punti 4-5 è stata consapevolmente utilizzata un'attività fortemente "inventata". Se non si fa questo e si prende un esempio classico, come il modello di gestione degli ordini del punto 2, si può rischiare che l'attenzione del lettore venga distolta dalla proposta di decomposizione del processo in un modello, alla propria esperienza personale e alla percezione di come debbano essere costruiti i processi e i modelli di gestione dei dati nei sistemi informativi. In altre parole, prendete due analisti IT qualificati, uno che fornisce servizi a logistici che trasportano passeggeri e l'altro a logistici che trasportano macchinari per la produzione di microchip. Chiedete loro, senza discutere in anticipo i processi aziendali automatizzabili, di creare un modello di dati per memorizzare le informazioni su una corsa ferroviaria.
Esiste una probabilità non trascurabile che nei modelli proposti troviate non solo un insieme di attributi visibilmente diverso, ma anche insiemi di entità non corrispondenti, perché ogni analista si baserà sui processi e le attività a lui familiari. E dire in una tale situazione quale modello sia "corretto" è impossibile, perché non esiste un criterio di valutazione.
2. Forme Normali
La prima forma normale del database richiede l'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 è violata la prima forma normale. Ad esempio, se nelle specifiche dell'ordine viene indicata 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 imballaggi composti da pezzi (nel modello sopra Good_count_WR), allora nel database è violata l'atomicità degli attributi. In questo caso, per dire come dovrebbe essere la struttura delle tabelle nelle specifiche dell'ordine, è necessaria una descrizione chiara del processo di lavoro nei sistemi informativi, e poiché i processi possono variare, ci possono essere molte "versioni corrette".
La seconda forma normale del database richiede il rispetto della prima forma e una propria tabella per ogni entità relativa al processo di lavoro nel sistema informativo. Se in una tabella ci sono dipendenze con=f1(a) e d=f2(b) e non c'è una dipendenza con=f3(b), allora la tabella viola la seconda forma normale. Nell'esempio sopra nella tabella "Ordine" non c'è una dipendenza tra l'ordine e l'indirizzo. Cambia il nome della strada o della città, e non avrai alcun impatto sugli attributi significativi dell'ordine.
Terza forma normale del DB richiede il rispetto della seconda forma normale e l'assenza di dipendenze funzionali tra gli attributi di entità diverse. Questa regola può essere formulata così: «tutto ciò che può essere calcolato, deve essere calcolato». In altre parole, se esistono due oggetti A e B. Nella tabella che memorizza gli attributi dell'oggetto A, è presente l'attributo C, e nell'oggetto B esiste un attributo b, tale che c=f4(b), allora la terza forma normale è violata. Nell'esempio di seguito, l'attributo «Numero di pezzi» (Total_count_WR) nel record dell'ordine pretende chiaramente di violare la terza forma normale.
3. Il mio approccio all'applicazione della normalizzazione
1. Solo un processo aziendale automatizzabile può fornire all'analista i criteri per identificare entità e attributi nella creazione di un modello di archiviazione dei dati. La creazione del modello di processo è un prerequisito fondamentale per creare un modello di dati normale.
2. Raggiungere la terza forma normale in senso stretto può non essere conveniente nella pratica reale della creazione di sistemi ERP, se si verificano alcune o tutte le seguenti condizioni:
- i processi automatizzabili sono raramente soggetti a cambiamenti,
- i tempi per la ricerca e lo sviluppo sono ristretti,
- i requisiti di integrità dei dati sono relativamente bassi (potenziali errori nel software commerciale non portano a perdite di denaro o clienti per il cliente del software)
- e così via.
Negli scenari descritti, i costi per identificare e descrivere il ciclo di vita di alcuni oggetti e dei loro attributi potrebbero non essere giustificati in termini di efficienza economica.
3. Qualsiasi conseguenza della denormalizzazione del modello di dati in un sistema informativo già creato può essere attenuata attraverso una scrupolosa analisi preventiva del codice e test.
4. La denormalizzazione è un modo per trasferire gli sforzi di lavoro dalla fase di ricerca delle fonti di dati e progettazione del processo aziendale alla fase di sviluppo, dal periodo di implementazione a quello di evoluzione del sistema.
5. È opportuno aspirare alla terza forma normale del database se:
- La direzione dei processi aziendali automatizzati è difficile da prevedere
- All'interno del team di implementazione e/o sviluppo c'è una divisione del lavoro poco permeabile
- I sistemi che fanno parte del contesto di integrazione si sviluppano secondo piani propri
- La disomogeneità dei dati può portare alla perdita di clienti o di denaro per l'azienda
6. La progettazione del modello dati dovrebbe essere effettuata dall'analista solo in relazione ai modelli del processo aziendale target e del processo nel sistema informatico. Se il progettista del modello dati è uno sviluppatore, dovrà immergersi nel dominio tematico a tal punto da comprendere, in particolare, la differenza tra i valori degli attributi — condizione necessaria per l'estrazione degli attributi atomici. Così assumendo su di sé funzioni non proprie.
4 Compito per illustrazione
Supponiamo che tu abbia una piccola taverna robotizzata nel porto. Il tuo segmento di mercato: marinai e pirati che entrano in porto e hanno bisogno di riposo. Ai marinai vendi tè con timo, mentre ai pirati rom e pettini di ossa per pettinare la barba. Il servizio nella taverna è offerto da un robot hostess e un robot barista. Grazie all'alta qualità e ai prezzi bassi, hai soppiantato tutti i concorrenti, così ogni persona che scende dalla nave viene nella tua taverna, che è l'unica nel porto.
Il complesso dei sistemi informativi della taverna è composto dai seguenti software:
- Sistema di allerta precoce per il cliente, che riconosce la sua categoria in base a segni caratteristici
- Sistema di gestione per i robot hostess e i robot baristi
- Sistema di gestione del magazzino e di consegna al punto vendita
- Sistema di gestione delle relazioni con i fornitori (CRM)
Processo:
Il sistema di allerta precoce riconosce le persone che scendono dalla nave. Se la persona è rasa, la identifica come marinaio, se ha la barba, la identifica come pirata.
Entrando nella taverna, l'ospite sente dal robot hostess un saluto in base alla sua categoria, ad esempio: «Ho-ho-ho, stimato pirata, venga al tavolo n°…»
L'ospite si avvicina al tavolo indicato, dove il robot-barista ha già preparato per lui i prodotti in base alla categoria. Il robot-barista invia informazioni al sistema di magazzino riguardo al fatto che la prossima consegna deve essere aumentata, e il sistema informativo del magazzino, basandosi sulle scorte a disposizione, genera una richiesta di acquisto nel SUOP.
Lascia che il sistema di allerta precoce sia stato sviluppato dal tuo IT interno, mentre il programma di gestione dei robot da bar è stato creato da un appaltatore esterno specificamente per il tuo business. I sistemi per la gestione del magazzino e le relazioni con i fornitori sono soluzioni boxe personalizzate provenienti dal mercato.
5. Esempi di denormalizzazione e il suo impatto sull'evoluzione del software
Durante la progettazione del processo aziendale, gli esperti del settore intervistati hanno affermato all'unisono che in tutto il mondo i pirati bevono rum e si pettinano la barba con pettini di osso, mentre i marinai bevono tè con timo e sono sempre ben rasati.
Appare un elenco dei tipi di clienti con due valori: 1- pirati, 2 - marinai, comune a tutto il contesto informativo dell'azienda.
Il sistema di allerta sul cliente salva immediatamente il risultato dell'elaborazione dell'immagine come identificatore (ID) del cliente riconosciuto e il suo tipo: marinaio o pirata.
ID dell'oggetto riconosciuto
Categoria del cliente
100500
Pirata
100501
Pirata
100502
Marinaio
Ripetiamo ancora che
1. I nostri marinai sono in realtà uomini rasati
2. I nostri pirati sono in realtà uomini barbuti
Quali problemi devono essere risolti in questo caso affinché la nostra struttura ambisca alla terza forma normale:
- violazione dell'atomicità dell'attributo - Categoria del cliente
- mescolanza del fatto analizzato e della conclusione nella stessa tabella
- dipendenza funzionale registrata tra gli attributi di entità diverse.
In forma normalizzata avremmo ottenuto due tabelle:
- risultato del riconoscimento sotto forma di un insieme di caratteristiche stabilite,
ID dell'oggetto riconosciuto
Peluria sul viso
100500
Sì
100501
Sì
100502
No
- risultato della determinazione del tipo di cliente come applicazione della logica incorporata nel sistema informativo per l'interpretazione delle caratteristiche stabilite
ID dell'oggetto riconosciuto
ID di identificazione
Categoria del cliente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Marinaio
In che modo un'organizzazione di archiviazione dati normalizzata può facilitare lo sviluppo di un complesso sistema informatico? Supponiamo che, all'improvviso, vi siano nuovi clienti. Che siano pirati giapponesi senza barba, ma con un pappagallo sulla spalla, o pirati ecologici, li riconoscerete facilmente per il profilo blu di Greta sul petto sinistro.
I pirati ecologici, naturalmente, non possono usare pettini di ossa e richiedono un'alternativa realizzata con plastica marittima riciclata.
È necessario riprogettare gli algoritmi delle applicazioni in base ai nuovi input. Se le regole di normalizzazione fossero state seguite, sarebbe bastato integrare solo alcune ingressi per alcuni rami dei processi e creare nuovi rami solo per quei casi e per quei sistemi informatici dove le caratteristiche dei capelli sul viso hanno rilevanza. Ma poiché le regole non sono state seguite, sarà necessario analizzare tutto il codice, in tutto il contorno, dove vengono utilizzati i valori del repertorio dei tipi di clienti e stabilire chiaramente che in un caso l'algoritmo deve tenere conto dell'attività professionale del cliente, mentre nell'altro delle caratteristiche fisiche.
Nella forma in cui tende alla normalizzazione, avremmo due tabelle con dati operativi e due repertori:
- risultato del riconoscimento sotto forma di un insieme di caratteristiche stabilite,
ID dell'oggetto riconosciuto
Greta sul petto sinistro
Uccello sulla spalla
Peluria sul viso
100510
1
1
1
100511
0
0
1
100512
1
0
- risultato della determinazione del tipo di cliente (che sia una vista utente, in cui sono presentate descrizioni dai repertori)
La denormalizzazione rilevata implica che i sistemi non potranno essere adattati alle nuove condizioni? Certo che no. Se immaginiamo che tutti i sistemi informatici siano stati creati da un unico team con un turnover nullo, i progetti siano ben documentati e le informazioni all'interno del team vengano trasferite senza perdite, le modifiche necessarie possono essere eseguite con sforzi trascurabili. Ma se torniamo alle condizioni iniziali del compito, solo per stampare i verbali delle discussioni comuni si consumeranno 1,5 tastiere e altre 0,5 per l'organizzazione delle procedure di acquisto.
Nell'esempio sopra citato, tutte e tre le forme normali sono violate, proviamo a violarle singolarmente.
Violazione della prima forma normale:
Supponiamo che le merci nel tuo magazzino vengano consegnate dai magazzini dei fornitori tramite il ritiro utilizzando un furgone da 1,5 tonnellate che appartiene alla tua taverna. Le dimensioni dei tuoi ordini sono così piccole rispetto ai volumi dei fornitori, che vengono sempre eseguiti uno a uno senza aspettare la produzione. Sono necessarie tabelle separate per veicoli, tipi di veicoli? È necessario separare il piano e il fatto nei tuoi ordini inviati ai fornitori?
Immagina solo quanti "collegamenti superflui" i tuoi programmatori dovranno scrivere se si utilizza il modello qui sotto per sviluppare il programma.
Supponiamo di aver deciso che la struttura proposta è eccessivamente complessa; nel nostro caso, separare il piano e il fatto nella registrazione dell'ordine è un'informazione superflua e la specifica dell'ordine redatta viene sovrascritta in base ai risultati dell'accettazione della merce in arrivo, casi rari di errore e arrivo di merce di qualità inadeguata vengono risolti al di fuori del sistema informativo.
E un giorno vedi che l'intera sala della taverna è piena di pirati arrabbiati e incolti. Cosa è successo?
Si è scoperto che insieme alla crescita della tua attività cresceva anche il consumo. In passato era stata presa una decisione manageriale che, se il furgone si trovava sovraccarico in base al volume e/o al peso - cosa che accadeva molto raramente - il fornitore dava priorità al carico di bevande.
I beni non consegnati venivano inclusi nel successivo ordine e partivano in un nuovo viaggio; la presenza di una scorta minima nel magazzino della taverna permetteva di non notare i casi di mancanza.
Nel porto ha chiuso l'ultimo concorrente e il caso di sovraccarico del furgone, trascurato per via della priorità basata sull'assunzione di una scorta minima e sul carico parziale periodico del veicolo, è diventato una pratica comune. Il sistema creato funzionerà perfettamente secondo gli algoritmi incorporati e sarà privo di ogni possibilità di monitorare il mancato rispetto sistematico degli ordini pianificati. Solo una reputazione danneggiata e clienti insoddisfatti potranno scoprire il problema.
Il lettore attento avrà sicuramente notato che la quantità ordinata nella specifica d'ordine (T_ORDER_SPEC) nella sezione 2 e nella sezione 5 potrebbe corrispondere o meno ai requisiti della prima forma normale. Tutto dipende dal fatto che, con l'assortimento di beni scelto, diverse unità di misura sostanziali possano rientrare nello stesso campo.
Violazione della seconda forma normale:
Con l'aumento delle vostre esigenze, acquistate altri veicoli di diverse dimensioni. Nel contesto esposto sopra, la creazione di un database dei veicoli è stata considerata ridondante, di conseguenza tutti gli algoritmi di gestione dei dati, a supporto delle esigenze di consegna e magazzino, interpretano il movimento del carico dal fornitore al magazzino come un viaggio esclusivamente di un gazelle da 1,5 tonnellate. Quindi, insieme all'acquisto di nuovi veicoli, create comunque un database dei veicoli, ma durante la modifica dovrete analizzare tutto il codice che fa riferimento al movimento del carico per determinare se in ogni specifico punto ci si riferisca alle caratteristiche del particolare veicolo da cui ha avuto inizio l'attività.
Violazione della terza forma normale:
A un certo punto iniziate a creare un programma di fidelizzazione, compare la registrazione di un cliente abituale. Perché, ad esempio, perdere tempo a creare rappresentazioni materiali che memorizzano dati aggregati delle vendite per un singolo cliente da utilizzare nei report e da trasferire nei sistemi analitici, se all'inizio del programma di fidelizzazione tutto ciò che interessa il cliente può essere inserito direttamente nella registrazione del cliente stesso? E, effettivamente, a prima vista non ha senso. Ma ogni volta che la vostra attività collegherà, ad esempio, nuovi canali di vendita, tra i vostri analisti ci deve essere qualcuno che ricordi che esiste un attributo aggregato.
Progettando ogni nuovo processo, supponiamo le vendite su Internet, vendite attraverso distributori collegati al sistema di fidelizzazione, qualcuno deve tenere a mente che tutti i nuovi processi devono garantire, a livello di codice, l'integrità dei dati. Per un database industriale con mille tabelle, questo sembra un compito poco praticabile.
Un sviluppatore esperto sa naturalmente come mitigare tutti i problemi sopra menzionati, ma, secondo me, il compito di un analista esperto è evitare di arrivarci.
Desidero esprimere gratitudine per il feedback prezioso nella preparazione della pubblicazione al lead developer Evgeny Yarukhin.
Letteratura
Connolly Thomas, Begg Caroline. Database. Progettazione, implementazione e supporto. Teoria e pratica.
Fonte: habr.com
