Ciao! Mi chiamo Andrey Semenov, sono un analista senior di Sportmaster. In questo post, voglio sollevare la questione della denormalizzazione delle basi di dati nei sistemi ERP. Esamineremo le condizioni generali e un esempio specifico - diciamo che sarà una meravigliosa taverna monopolista per pirati e marinai. In questa, i pirati e i marinai devono essere serviti in modo diverso, poiché le loro concezioni del bello e i modelli dei consumatori differiscono notevolmente.
Come fare affinché tutti siano soddisfatti? Come non impazzire progettando e mantenendo un tale sistema? Cosa fare se nella taverna iniziano a venire non solo i soliti pirati e marinai?
Tutto sotto l'etichetta. Ma procediamo con ordine.
1. Limitazioni e ipotesi
Tutto quanto esposto si riferisce solo a basi di dati relazionali. Le conseguenze della denormalizzazione, ben documentate anche su Internet, in termini di anomalie di modifica, cancellazione e inserimento non verranno considerate. Sono esclusi i casi in cui la denormalizzazione è pratica comune, con esempi classici: numero di serie e numero di passaporto, data e ora, ecc.
Il post utilizza definizioni intuitive e pratiche delle normali forme, senza riferimenti a termini matematici. Così come possono essere applicate all'analisi dei processi aziendali reali e alla progettazione di software industriale.
Esiste l'opinione che la progettazione di archivi dati, strumenti per la creazione di report e accordi di integrazione (che utilizzano una rappresentazione tabellare delle informazioni), si differenzia dalla progettazione di database di sistemi ERP, in quanto la facilità di utilizzo 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 riferisce esclusivamente ai modelli di master data e dati transazionali dei sistemi ERP.
La spiegazione delle forme normali è fornita con un esempio comprensibile per la maggior parte dei lettori. Tuttavia, come illustrazione visiva, nei punti 4-5 è stata utilizzata deliberatamente una «situazione inventata». Se non si fa ciò e si prende un esempio comunemente usato, come il modello di archiviazione degli ordini nel punto 2, si rischia di spostare l'attenzione del lettore dall'analisi del processo proposto al proprio bagaglio personale e alle percezioni su come dovrebbero essere costruiti i processi e i modelli di archiviazione dei dati nei sistemi informatici. In altre parole, prendete due analisti IT qualificati; uno lavora con i servizi per i logisti che trasportano passeggeri, l'altro con i logisti 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 informazioni su un viaggio ferroviario.
C'è una probabilità non nulla che nei modelli proposti si trovino non solo un insieme di attributi notevolmente diverso, ma anche insiemi di entità non corrispondenti, poiché ogni analista si baserà sui processi e sulle attività a lui familiari. E in una situazione del genere, dire quale modello sia "giusto" è impossibile, poiché non esiste un criterio di valutazione.
2. Forme normali
La prima forma normale del DB richiede l'atomicità di tutti gli attributi.
In particolare, se un 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 DB è violata la prima forma normale. Ad esempio, se nella specifica 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 confezioni composte da pezzi (nel modello sopra Good_count_WR), allora nel DB è violata l'atomicità degli attributi. In questo caso, per dire quale dovrebbe essere la struttura della tabella nella specifica dell'ordine, è necessaria una descrizione mirata del processo di lavoro nel sistema informativo, e poiché i processi possono essere diversi, possono esistere anche molte versioni "giuste".
Secondo normale forma del DB richiede il rispetto della prima forma e una propria tabella per ogni entità relativa al processo di lavoro nel sistema informatico. Se in una tabella esistono dipendenze con=f1(a) e d=f2(b) e non esiste dipendenza con=f3(b), allora la tabella viola la seconda normale forma. Nell'esempio sopra, nella tabella 'Ordine' non esiste dipendenza tra l'ordine e l'indirizzo. Cambia il nome della strada o della città, e non influenzerai alcun attributo sostanziale dell'ordine.
Terza normale forma del DB richiede il rispetto della seconda normale forma e l'assenza di dipendenze funzionali tra attributi di entità diverse. Questa regola può essere formulata così: '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, è presente l'attributo C, e per l'oggetto B c'è un attributo b, tale che esiste c=f4(b), allora la terza normale forma è violata. Nell'esempio sottostante, l'attributo 'Numero di pezzi' (Total_count_WR) nella registrazione dell'ordine sembra chiaramente violare la terza normale forma.
3. Il mio approccio all'applicazione della normalizzazione
1. Solo i processi aziendali automatizzabili e mirati possono fornire analisi con criteri per identificare entità e attributi durante la creazione di un modello di archiviazione dati. La creazione di un modello di processo è una condizione necessaria per la realizzazione di un modello dati normale.
2. Raggiungere la terza forma normale in senso stretto può non essere praticabile nella realtà della creazione di sistemi ERP quando si soddisfano parte o tutte le seguenti condizioni:
- i processi automatizzabili subiscono raramente cambiamenti,
- i tempi per la ricerca e lo sviluppo sono ristretti,
- i requisiti di integrità dei dati sono relativamente bassi (errori potenziali nel software industriale non comportano la perdita di denaro o clienti per il committente del software)
- e così via.
In tali circostanze, i costi per l'identificazione e la descrizione del ciclo di vita di alcuni oggetti e dei loro attributi possono non essere giustificati in termini di efficienza economica.
3. Qualsiasi conseguenza della denormalizzazione del modello dati in un sistema informativo già creato può essere mitigata attraverso un'attenta analisi preliminare del codice e test.
4. La denormalizzazione è un modo per trasferire il lavoro richiesto dalla fase di ricerca delle fonti dati e progettazione del processo aziendale alla fase di sviluppo, spostando il periodo di implementazione al periodo di evoluzione del sistema.
5. È utile mirare alla terza forma normale del DB se:
- È difficile prevedere l'andamento dei processi aziendali automatizzati
- All'interno del team di implementazione e/o sviluppo esiste una chiara divisione del lavoro
- I sistemi che fanno parte del contesto di integrazione si sviluppano secondo propri piani
- Incoerenze nei dati possono portare a una perdita di clienti o di denaro per l'azienda
6. La progettazione del modello dati deve essere effettuata dall'analista esclusivamente in relazione ai modelli del processo aziendale target e al processo nel sistema informativo. Se la progettazione del modello dati è eseguita dallo sviluppatore, questi dovrà immergersi nel dominio del soggetto fino al punto da comprendere, tra l'altro, la differenza tra i valori degli attributi - condizione necessaria per l'estrazione degli attributi atomici. In questo modo assumerebbe funzioni non a lui proprie.
4 Esempio di compito
Immagina di avere una piccola taverna automatizzata nel porto. Il tuo segmento di mercato: marinai e pirati che approdano e hanno bisogno di riposo. Ai marinai vendi tè al timo, mentre ai pirati proponi rum e pettini di osso per pettinare le barbe. Il servizio nella taverna è gestito da un robot hostess e da un robot barista. Grazie all'alta qualità e ai prezzi competitivi, hai sopraffatto i tuoi concorrenti, così ogni persona che scende dalla nave si dirige verso la tua taverna, l'unica nel porto.
Il complesso di sistemi informativi della taverna è composto dal seguente software:
- Sistema di allerta precoce per il cliente, che riconosce la sua categoria in base a caratteristiche distintive
- Sistema di gestione dei robot hostess e dei robot baristi
- Sistema di gestione del magazzino e delle consegne al punto vendita
- Sistema di gestione delle relazioni con i fornitori (SRF)
Processo:
Il sistema di allerta precoce riconosce le persone che scendono dalla nave. Se una persona è ben rasata, la identifica come marinaio; se ha una barba, viene identificata come pirata.
Entrando nella taverna, l'ospite sente il saluto del robot hostess in base alla propria categoria, ad esempio: «Ho-ho-ho, caro pirata, segua il tavolo n°…»
L'ospite si dirige verso il tavolo indicato, dove il robot barista ha già preparato i prodotti in base alla categoria. Il robot barista comunica al sistema di magazzino che la prossima consegna deve essere incrementata, e il sistema informatico di magazzino genera una richiesta di acquisto basata sulle giacenze in magazzino.
Lasciate che il sistema di allerta precoce sia stato sviluppato dal vostro IT interno, mentre il programma di gestione dei robot da bar è stato creato da un fornitore esterno specificamente per il vostro business. I sistemi per la gestione del magazzino e delle relazioni con i fornitori sono soluzioni box personalizzate del mercato.
5. Esempi di denormalizzazione e il suo impatto sullo sviluppo software
Nella 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è al 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 notifica del 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
Ribadiamo che
1. I nostri marinai sono in realtà persone rasate
2. I nostri pirati sono in realtà persone con la barba
Quali problemi devono essere risolti affinché la nostra struttura tenda alla terza forma normale:
- violazione dell'atomicità dell'attributo - Categoria del cliente
- mescolanza del fatto analizzato e della conclusione in un'unica tabella
- dipendenza funzionale fissa 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
Pelo sul viso
100500
Sì
100501
Sì
100502
No
- risultato della definizione del tipo di cliente come applicazione della logica incorporata nel sistema 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
Come può un'organizzazione di archiviazione dei dati normalizzata facilitare lo sviluppo di un sistema informativo complesso? Immagina che all'improvviso ti arrivino nuovi clienti. Facciamo che siano dei pirati giapponesi che, pur non avendo barba, portano un pappagallo sulla spalla, e pirati ecologisti, che potrai riconoscere dal profilo blu di Greta sulla loro sinistra.
I pirati ecologisti, naturalmente, non possono utilizzare pettini di osso e richiedono un'alternativa realizzata in plastica marina riciclata.
È necessario riprocessare gli algoritmi delle applicazioni in base alle nuove esigenze. Se le regole di normalizzazione fossero state seguite, avresti dovuto solo integrare alcune nuove entrate in parte dei sistemi e creare nuovi rami solo in quei casi e nei sistemi informativi dove è rilevante la peluria facciale. Tuttavia, poiché le regole non sono state rispettate, dovrai analizzare l'intero codice in tutto il contesto in cui vengono utilizzati i valori del registro dei tipi di clienti e accertarti che in un caso l'algoritmo debba considerare l'attività professionale del cliente, mentre nell'altro le caratteristiche fisiche.
In un formato che si propone di normalizzato, avremmo ottenuto due tabelle con dati operativi e due elenchi:
- risultato del riconoscimento sotto forma di un insieme di caratteristiche stabilite,
ID dell'oggetto riconosciuto
Greta sul petto sinistro
Uccello sulla spalla
Pelo sul viso
100510
1
1
1
100511
0
0
1
100512
1
0
- risultato della determinazione del tipo di cliente (che sia una visualizzazione personalizzata, in cui vengano mostrati i descrittori degli elenchi)
Significa l'eventuale denormalizzazione che i sistemi non possano essere adattati a nuove condizioni? Certamente no. Se immaginiamo che tutti i sistemi informativi siano stati creati da un unico team con zero turnover, lo sviluppo sia ben documentato e le informazioni all'interno del team vengano trasferite senza perdite, le modifiche necessarie possono essere realizzate con sforzi trascurabili. Ma se torniamo alle condizioni iniziali del compito, solo per stampare i verbali delle discussioni congiunte si userebbero 1,5 tastiere e altri 0,5 per la documentazione delle procedure di acquisto.
Nell'esempio sopra, 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 con un furgone da 1,5 tonnellate di proprietà della tua taverna. Le dimensioni dei tuoi ordini sono talmente ridotte rispetto ai volumi dei fornitori, che vengono sempre eseguiti uno a uno senza attesa per la produzione. Serve un registro separato per veicoli, tipi di veicoli e per distinguere tra piano e fattibilità nei tuoi ordini inviati ai fornitori?
Immagina quanti «collegamenti inutili» dovranno scrivere i tuoi programmatori se si utilizza il modello sottostante per lo sviluppo del programma.
Supponiamo che abbiamo deciso che la struttura proposta è eccessivamente complessa; nel nostro caso è superfluo distinguere tra piano e realizzazione nel registro dell'ordine. Le specifiche dell'ordine vengono aggiornate in base ai risultati dell’accettazione delle merci ricevute, mentre le rare discrepanze e le merci di qualità non conforme vengono gestite al di fuori del sistema informatico.
E un giorno vedi l'intera sala della taverna riempita di pirati arrabbiati e trasandati. Cosa è successo?
Si è scoperto che con la crescita della tua azienda cresceva anche il consumo. Un tempo si era presa la decisione gestionale che, se il furgone risultava sovraccarico in termini di volume e/o peso, cosa piuttosto rara, il fornitore dava priorità al caricamento delle bevande.
I prodotti non consegnati venivano inseriti nel successivo ordine e partivano con un nuovo viaggio, e la presenza di una scorta minima in magazzino presso la taverna permetteva di non notare i casi di sottofornitura.
Nel porto ha chiuso l'ultimo concorrente, e il caso di sovraccarico del furgone, ignorato a causa della priorità data a presupposti sulla sufficienza della scorta minima e sul carico parziale del veicolo, è diventato una pratica comune. Il sistema creato funzionerà perfettamente in conformità agli algoritmi in esso integrati e non offrirà alcuna possibilità di tracciare il mancato rispetto sistematico degli ordini pianificati. Solo una cattiva reputazione e clienti insoddisfatti potranno individuare il problema.
È probabile che il lettore attento abbia notato che la quantità ordinata nella specifica dell'ordine (T_ORDER_SPEC) nelle sezioni 2 e 5 può corrispondere o meno al requisito della prima forma normale. Tutto dipende dal fatto che, con l'assortimento di prodotti scelto, possano finire nello stesso campo diverse unità di misura sostanzialmente distinte.
Violazione della seconda forma normale:
Con l'aumento delle vostre esigenze, acquistate un paio di veicoli di dimensioni diverse. Nel contesto esposto sopra, è stato ritenuto eccessivo creare un archivio dei veicoli, di conseguenza tutti gli algoritmi di gestione dei dati che servono le esigenze di consegna e magazzino considerano il trasporto delle merci dal fornitore al magazzino come un viaggio esclusivo di un furgone da 1,5 tonnellate. Pertanto, anche con l'acquisto di nuovi veicoli, si crea comunque un archivio dei veicoli, ma nella fase di modifica sarà necessario analizzare tutto il codice che si riferisce al trasporto delle merci per capire se in ogni singolo punto ci si riferisce alle caratteristiche del veicolo da cui è iniziata l'attività.
Violazione della terza forma normale:
A un certo punto, inizi a creare un programma di fidelizzazione e viene registrato un cliente abituale. Perché, ad esempio, perdere tempo a creare rappresentazioni materiali che memorizzano dati aggregati sulle vendite per un singolo cliente da utilizzare nei report e trasmettere nei sistemi analitici, se all'inizio del programma di fidelizzazione tutto ciò che interessa il cliente può essere memorizzato direttamente nel profilo del cliente stesso? E, in effetti, a prima vista, non ha senso. Ma ogni volta che la tua azienda attiverà, ad esempio, nuovi canali di vendita, tra i tuoi analisti dovrebbe esserci qualcuno che ricorda l'esistenza di questo attributo aggregato.
Progettando ogni nuovo processo, poniamo, le vendite online, le vendite attraverso distributori collegati al sistema di fidelizzazione comune, qualcuno deve tenere a mente che tutti i nuovi processi devono garantire l'integrità dei dati a livello di codice. Per un DB industriale con migliaia di tabelle, questo sembra un compito praticamente irrealizzabile.
Un sviluppatore esperto sa certamente come mitigare tutti i problemi sopra menzionati, ma, a mio avviso, il compito di un analista esperto è prevenirli.
Vorrei esprimere la mia gratitudine per il prezioso feedback fornito al principale sviluppatore Evgeny Yarukhin durante la preparazione della pubblicazione.
Letteratura
Connolly Thomas, Begg Caroline. Database. Progettazione, implementazione e manutenzione. Teoria e pratica
Fonte: habr.com
