Creazione di un data warehouse aziendale unificato. Crea un modello di data warehouse basato su un modello di dati aziendale. Modelli di dati di settore

Zaitsev SL, Ph.D.

Gruppi ripetuti

I gruppi ripetuti sono attributi per i quali una singola istanza di entità può avere più di un valore. Ad esempio, una persona può avere più di un'abilità. Se, in termini di requisiti aziendali, abbiamo bisogno di conoscere il livello di abilità per tutti, e ogni persona può avere solo due abilità, possiamo creare l'entità mostrata in Fig. 1.6. Ecco l'entità UNA PERSONA con due attributi per memorizzare abilità e livelli di abilità per ciascuno.

Riso. 1.6. Questo esempio usa i gruppi ripetuti.

Il problema con i gruppi ripetuti è che non possiamo sapere esattamente quante abilità potrebbe avere una persona. Nella vita reale, alcune persone hanno un'abilità, altre ne hanno diverse e altre ancora non ne hanno. La Figura 1.7 mostra il modello ridotto alla prima forma normale. Notare l'aggiunta ID abilità , che li definisce in modo univoco ABILITÀ.

Riso. 1.7. Modello ridotto alla prima forma normale.

Un fatto in un posto

Se lo stesso attributo è presente in più di un'entità e non è una chiave esterna, tale attributo è considerato ridondante. Il modello logico non deve contenere dati ridondanti.

La ridondanza richiede spazio aggiuntivo, ma mentre l'efficienza della memoria è importante, il vero problema risiede altrove. La sincronizzazione garantita dei dati ridondanti comporta un sovraccarico e corri sempre il rischio di valori in conflitto.

Nell'esempio precedente ABILITÀ dipende da ID persona e da ID abilità. Ciò significa che non avrai ABILITÀ finché non appare UNA PERSONA, avendo questa abilità. Inoltre, rende più difficile cambiare il nome dell'abilità. Devi trovare ogni voce Nome abilità e cambiarla per ogni persona che possiede quella abilità.

La Figura 1.8 mostra il modello in seconda forma normale. Si noti che l'entità è stata aggiunta ABILITÀ e attributo TITOLO competenza trasferita a questa entità. Il livello di abilità è rimasto, rispettivamente, all'incrocio PERSONE e COMPETENZE.

Riso. 1.8. Nella seconda forma normale, il gruppo ripetuto viene spostato in un'altra entità. Ciò offre la flessibilità di aggiungere tutte le competenze necessarie e di modificare il nome o la descrizione della specialità in un'unica posizione.

Ogni attributo dipende da una chiave

Ogni attributo di un'entità deve dipendere dalla chiave primaria di tale entità. Nell'esempio precedente Nome della scuola e Area geografica presente nella tabella UNA PERSONA ma non descrivere una persona. Per ottenere la terza forma normale, devi spostare gli attributi nell'entità, dove dipenderanno dalla chiave. Figura 1.9. mostra il modello in terza forma normale.

Riso. 1.9. In terza forma normale Nome della scuola e Regione geografica spostato nell'entità, dove i loro valori dipendono dalla chiave.

Molte-a-molte relazioni

Relazione molti a molti rispecchiare la realtà dell'ambiente. Si noti che nella Figura 1.9 esiste una relazione molti-a-molti tra PERSONA e SCUOLA. Il rapporto riflette accuratamente il fatto che UNA PERSONA può studiare in molti SCUOLE e dentro SCUOLA può imparare molto PERSONA. Per ottenere la quarta forma normale, viene creata un'entità associativa che elimina la relazione monogie-a-molti generando una voce separata per ogni combinazione unica di scuola e persona. La Figura 1.10 mostra il modello nella quarta forma normale.

Riso. 1.10. Nella quarta forma normale, la relazione monogie-to-molti tra PERSONA e SCUOLA risolto introducendo un'entità associativa, in cui viene assegnata una voce separata per ogni combinazione univoca SCUOLE e PERSONE.

Definizioni formali di forme normali

Le seguenti definizioni di forme normali possono sembrare intimidatorie. Considerali semplicemente come formule per raggiungere la normalizzazione. Le forme normali si basano sull'algebra relazionale e possono essere interpretate come trasformazioni matematiche. Sebbene questo libro non copra una discussione dettagliata delle forme normali, i modellisti sono incoraggiati ad approfondire l'argomento.

In una data relazione R, l'attributo Y dipende funzionalmente dall'attributo X. Simbolicamente, RX -> RY (letto come "RX definisce funzionalmente RY") se e solo se ogni valore X in R è associato esattamente a un valore Y in R ( in qualunque momento). Gli attributi X e Y possono essere composti (Data KJ Introduzione ai sistemi di database. 6a edizione. Ed. Williams: 1999, 848 pp.).

Una relazione R è in prima forma normale (1NF) se e solo se tutti i suoi domini contengono solo valori atomici (Data, ibid.).

Una relazione R è in seconda forma normale (2NF) se e solo se è in 1NF e ogni attributo non chiave è completamente dipendente dalla chiave primaria (Data, ibid.).

Una relazione R è in terza forma normale (3NF) se e solo se è in 2NF e ogni attributo non chiave non è transitivamente dipendente dalla chiave primaria (Data, ibid.).

La relazione R è in forma normale di Boyce-Codd (BCNF) se e solo se ogni determinante è un candidato per l'uso come chiave.

NOTA Di seguito è riportata una breve spiegazione di alcune delle abbreviazioni utilizzate nelle definizioni di Date.

MVD (dipendenza multivalore) - dipendenza multivalore. Utilizzato solo per entità con tre o più attributi. In una dipendenza multivalore, il valore di un attributo dipende solo da una parte della chiave primaria.

FD (dipendenza funzionale) - dipendenza funzionale. In una dipendenza funzionale, il valore di un attributo dipende dal valore di un altro attributo che non fa parte della chiave primaria.

JD (unisci la dipendenza) - unisciti alla dipendenza. In una dipendenza di join, la chiave primaria dell'entità padre è riconducibile almeno al terzo livello di discendenti pur mantenendo la possibilità di essere utilizzata nell'unione della chiave originale.

Una relazione è in quarta forma normale (4NF) se e solo se c'è un MVD in R, come A®®B. In questo caso, tutti gli attributi di R dipendono funzionalmente da A. In altre parole, in R esistono solo dipendenze (FD o MVD) della forma K®X (cioè la dipendenza funzionale dell'attributo X dal candidato all'uso come chiave K). Di conseguenza, R soddisfa i requisiti di 4NF se è conforme a BCNF e tutti gli MVD sono in effetti FD (Data, ibid.).

Per la quinta forma normale, la relazione R soddisfa la relazione di unione (JD)*(X, Y, …, Z) se e solo se R è equivalente alle sue proiezioni su X, Y,..., Z, dove X, Y,..., Z sottoinsiemi dell'insieme di attributi R.

Esistono molte altre forme normali per tipi di dati complessi e situazioni specifiche che esulano dall'ambito della nostra discussione. Ogni appassionato di sviluppo di modelli vorrebbe esplorare altre forme normali.

Moduli commerciali normali

Nel suo libro Clive Finklestein (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) ha adottato un approccio diverso alla normalizzazione. Definisce le normali forme commerciali in termini di riduzioni di tali forme. Molti modellisti trovano questo approccio più intuitivo e pragmatico.

First Business Normal Form (1BNF) associa i gruppi ripetuti a un'altra entità. Questa entità ottiene il proprio nome e gli attributi della chiave primaria (composita) dall'entità originale e dal suo gruppo ripetuto.

Second Business Normal Form (2BNF) mappa gli attributi che dipendono in parte da una chiave primaria a un'altra entità. La chiave primaria (composita) di questa entità è la chiave primaria dell'entità in cui risiedeva originariamente, insieme a chiavi aggiuntive da cui l'attributo dipende interamente.

La terza forma normale aziendale (3BNF) sposta gli attributi che non dipendono dalla chiave primaria a un'altra entità, dove dipendono completamente dalla chiave primaria di questa entità.

Fourth Business Normal Form (4BNF) mappa gli attributi che dipendono dal valore della chiave primaria o sono facoltativi per un'entità secondaria, dove dipendono interamente dal valore della chiave primaria, o dove devono (obbligatori) essere presenti in tale entità .

Fifth Business Normal Form (5BNF) appare come un'entità strutturale se esiste una dipendenza ricorsiva o di altro tipo tra le istanze di un'entità secondaria o se esiste una dipendenza ricorsiva tra le istanze della sua entità primaria.

Modello di dati logici completato

Il modello logico completato deve soddisfare i requisiti della terza forma normale aziendale e includere tutte le entità, gli attributi e le relazioni necessarie per supportare i requisiti dei dati e le regole aziendali associate ai dati.

Tutte le entità devono avere nomi che descrivono il contenuto e una descrizione o definizione chiara, concisa e completa. In una delle seguenti pubblicazioni verrà presa in considerazione una prima serie di raccomandazioni per la corretta formazione dei nomi e delle descrizioni delle entità.

Le relazioni dovrebbero includere una costruzione verbale che descriva la relazione tra le entità, insieme a caratteristiche come la pluralità, il bisogno di esistenza o la possibilità di non esistenza della relazione.

NOTA Pluralità relazioni descrive il numero massimo di istanze di entità secondarie che possono essere associate a un'istanza dell'entità originale.Il bisogno di esistere opossibilità di assenza La relazione viene utilizzata per definire il numero minimo di istanze di un'entità secondaria che può essere associata a un'istanza dell'entità originale.

Modello di dati fisici

Dopo aver creato un modello logico completo e adeguato, sei pronto per prendere una decisione sulla scelta della piattaforma di implementazione. La scelta della piattaforma dipende dai requisiti per l'utilizzo dei dati e dai principi strategici dell'architettura dell'organizzazione. La selezione della piattaforma è una questione complessa che va oltre lo scopo di questo libro.

In ERwin, il modello fisico è una rappresentazione grafica del database effettivo. Il database fisico sarà composto da tabelle, colonne e relazioni. Il modello fisico dipende dalla piattaforma scelta per l'implementazione e dai requisiti di utilizzo dei dati. Il modello fisico per IMS sarà molto diverso dallo stesso modello per Sybase. Il modello fisico per i report OLAP avrà un aspetto diverso rispetto al modello per OLTP (Online Transaction Processing).

Il modellatore di dati e l'amministratore del database (DBA) utilizzano il modello logico, i requisiti di utilizzo ei principi strategici dell'architettura aziendale per sviluppare il modello fisico dei dati. Puoi denormalizzare il modello fisico per migliorare le prestazioni e creare viste per supportare i requisiti di utilizzo. Le sezioni seguenti descrivono in dettaglio il processo di denormalizzazione e la creazione di viste.

Questa sezione fornisce una panoramica del processo di creazione di un modello fisico, raccolta dei requisiti per l'utilizzo dei dati, definizione dei componenti di un modello fisico e reverse engineering. Questi problemi saranno trattati in modo più dettagliato nelle pubblicazioni future.

Raccolta dei requisiti di utilizzo dei dati

In genere, raccogli i requisiti di utilizzo dei dati all'inizio durante i colloqui e le sessioni di lavoro. Allo stesso tempo, i requisiti dovrebbero definire l'utilizzo dei dati da parte dell'utente nel modo più completo possibile. L'atteggiamento superficiale e le lacune nel modello fisico possono portare a costi non pianificati e ritardare il progetto. I requisiti di utilizzo includono:

Requisiti di accesso e prestazioni

Caratteristiche volumetriche (stima della quantità di dati da memorizzare), che consentono all'amministratore di rappresentare il volume fisico del database

Una stima del numero di utenti che hanno bisogno di accedere ai dati contemporaneamente, che ti aiuta a progettare il tuo database per un livello di prestazioni accettabile

Riepilogo, riepilogo e altri dati calcolati o derivati che possono essere considerati candidati per l'archiviazione in strutture di dati durevoli

Requisiti per la generazione di report e query standard per aiutare l'amministratore del database a creare indici

Viste (permanenti o virtuali) che aiuteranno l'utente nell'esecuzione di operazioni di unione o filtraggio dei dati.

Oltre al presidente, al segretario e agli utenti, la sessione dei requisiti di utilizzo deve includere il modellatore, l'amministratore del database e l'architetto del database. Dovrebbero essere discussi i requisiti dell'utente per i dati storici. La durata dell'archiviazione dei dati ha un impatto significativo sulle dimensioni del database. Spesso i dati meno recenti vengono archiviati in forma aggregata e i dati atomici vengono archiviati o eliminati.

Gli utenti devono portare con sé alla sessione query e report di esempio. I report devono essere rigorosamente definiti e devono includere i valori atomici utilizzati per eventuali campi di riepilogo e riepilogo.

Componenti del modello fisico dei dati

I componenti del modello di dati fisici sono tabelle, colonne e relazioni. È probabile che le entità nel modello logico diventino tabelle nel modello fisico. Gli attributi booleani diventeranno colonne. Le relazioni logiche diventeranno vincoli all'integrità delle relazioni. Alcune relazioni logiche non possono essere implementate in un database fisico.

ingegneria inversa

Quando il modello logico non è disponibile, diventa necessario ricreare il modello dal database esistente. In ERwin, questo processo è chiamato reverse engineering. L'ingegneria inversa può essere eseguita in diversi modi. Il modellatore può esplorare le strutture di dati nel database e ricreare le tabelle in un ambiente di modellazione visiva. È possibile importare un linguaggio di definizione dei dati (DDL) in uno strumento che supporta il reverse engineering (ad es. Erwin). Strumenti avanzati come ERwin includono funzioni che forniscono la comunicazione ODBC con un database esistente per creare un modello leggendo direttamente le strutture dei dati. Il reverse engineering utilizzando ERwin sarà discusso in dettaglio in una futura pubblicazione.

Uso dei confini funzionali aziendali

Quando si crea un modello logico, è importante che il modellatore si assicuri che il nuovo modello corrisponda al modello aziendale. Utilizzare i confini funzionali aziendali significa modellare i dati nei termini utilizzati all'interno di un'azienda. Il modo in cui i dati vengono utilizzati in un'azienda sta cambiando più velocemente dei dati stessi. In ogni modello logico, i dati devono essere rappresentati in modo olistico, indipendentemente dal dominio aziendale che supporta. Entità, attributi e relazioni dovrebbero definire le regole aziendali a livello aziendale.

NOTA Alcuni dei miei colleghi si riferiscono a questi confini funzionali aziendali come modelli del mondo reale. La modellazione del mondo reale incoraggia il modellatore a visualizzare le informazioni in termini di relazioni e relazioni della vita reale.

L'uso dei confini funzionali aziendali per un modello di dati adeguatamente costruito fornisce un quadro per supportare le esigenze informative di qualsiasi numero di processi e applicazioni, consentendo a un'azienda di sfruttare in modo più efficace uno dei suoi asset più preziosi, le informazioni.

Che cos'è un modello di dati aziendale?

Modello di dati aziendali (EDM) contiene entità, attributi e relazioni che rappresentano le esigenze informative di una società. L'EDM è solitamente suddiviso in aree tematiche, che rappresentano gruppi di entità legate al supporto di specifiche esigenze aziendali. Alcune aree tematiche possono coprire specifiche funzioni aziendali come la gestione dei contratti, altre possono raggruppare entità che descrivono prodotti o servizi.

Ciascun modello logico deve corrispondere a un dominio del modello dati aziendale esistente. Se il modello logico non soddisfa questo requisito, ad esso deve essere aggiunto un modello che definisca l'area disciplinare. Questo confronto garantisce che il modello aziendale sia migliorato o adattato e che tutti gli sforzi di modellazione logica siano coordinati all'interno dell'azienda.

EDM include anche entità specifiche che definiscono l'ambito dei valori per gli attributi chiave. Queste entità non hanno genitori e sono definite indipendenti. Le entità indipendenti sono spesso utilizzate per mantenere l'integrità delle relazioni. Queste entità sono identificate da diversi nomi, come tabelle di codici, tabelle di collegamento, tabelle di tipi o tabelle di classificazione. Useremo il termine "oggetto aziendale". Un oggetto aziendale aziendale è un'entità che contiene un insieme di valori di attributo indipendenti da qualsiasi altra entità. Gli oggetti aziendali aziendali all'interno di una società dovrebbero essere utilizzati in modo coerente.

Creazione di un modello di dati aziendali mediante ridimensionamento

Ci sono organizzazioni in cui il modello aziendale dall'inizio alla fine è stato costruito come risultato di un unico sforzo concertato. D'altra parte, la maggior parte delle organizzazioni costruisce modelli aziendali abbastanza completi costruendo.

Crescere significa costruire qualcosa, strato dopo strato, proprio come un'ostrica fa crescere una perla. Ciascun modello di dati creato fornisce input per la formazione dell'EDM. La creazione di un EDM in questo modo richiede ulteriori fasi di modellazione per aggiungere nuove strutture di dati e domini o estendere le strutture di dati esistenti. Ciò consente di creare un modello di dati aziendale costruendo, aggiungendo in modo iterativo livelli di dettaglio e raffinamento.

Il concetto di metodologia di modellazione

Esistono diverse metodologie per la modellazione visiva dei dati. ERwin ne supporta due:

IDEF1X (Definizione dell'integrazione per la modellazione delle informazioni - descrizione integrata dei modelli informativi).

IE (Ingegneria dell'Informazione - Ingegneria dell'Informazione).

IDEF1X è una buona metodologia e la sua notazione è ampiamente utilizzata

Descrizione integrata dei modelli informativi

IDEF1X è una metodologia di modellazione dei dati altamente strutturata che estende la metodologia IDEF1 adottata come standard FIPS (Federal Information Processing Standards). IDEF1X utilizza un insieme altamente strutturato di tipi di costrutti di modellazione e si traduce in un modello di dati che richiede una comprensione della natura fisica dei dati prima che tali informazioni possano essere rese disponibili.

La struttura rigida di IDEF1X costringe il modellatore ad assegnare caratteristiche ad entità che potrebbero non corrispondere alle realtà del mondo che le circonda. Ad esempio, IDEF1X richiede che tutti i sottotipi di entità siano esclusivi. Ciò porta al fatto che una persona non può essere sia un cliente che un dipendente. Mentre la pratica reale ci dice il contrario.

Ingegneria dell'informazione

Clive Finklestein viene spesso definito il padre dell'ingegneria dell'informazione, sebbene James Martin condividesse con lui concetti simili (Martin, James. Gestione dell'ambiente del database. Upper Saddle River, New Jersey: Prentice Hall, 1983.). L'ingegneria dell'informazione utilizza un approccio orientato al business per gestire le informazioni e utilizza una notazione diversa per rappresentare le regole aziendali. IE funge da estensione e sviluppo della notazione e dei concetti di base della metodologia ER proposta da Peter Chen.

IE fornisce l'infrastruttura per supportare i requisiti di informazione integrando la pianificazione strategica aziendale con i sistemi informativi in fase di sviluppo. Tale integrazione consente di collegare maggiormente la gestione delle risorse informative con le prospettive strategiche di lungo periodo dell'impresa. Questo approccio orientato al business porta molti modellatori a scegliere IE rispetto ad altre metodologie che si concentrano principalmente sulla risoluzione dei problemi di sviluppo immediati.

IE fornisce un flusso di lavoro che porta un'azienda a identificare tutte le sue informazioni necessarie per raccogliere e gestire i dati e identificare le relazioni tra gli oggetti informativi. Di conseguenza, i requisiti informativi sono articolati sulla base di direttive gestionali e possono essere tradotti direttamente in un sistema informativo gestionale a supporto delle esigenze informative strategiche.

Conclusione

Comprendere come utilizzare uno strumento di modellazione dei dati come ERwin è solo una parte del problema. Inoltre, è necessario comprendere quando vengono eseguite le attività di modellazione dei dati e come vengono raccolti i requisiti di informazione e le regole aziendali per essere rappresentati nel modello di dati. La conduzione di sessioni di lavoro fornisce le condizioni più favorevoli per la raccolta di informazioni richieste in un ambiente che include esperti in materia, utenti e specialisti di tecnologia dell'informazione.

Costruire un buon modello di dati richiede l'analisi e la ricerca dei requisiti informativi e delle regole aziendali raccolte durante sessioni di lavoro e colloqui. Il modello di dati risultante dovrebbe essere confrontato con il modello aziendale, se possibile, per garantire che non sia in conflitto con i modelli a oggetti esistenti e includa tutti gli oggetti richiesti.

Il modello di dati è costituito da modelli logici e fisici che rappresentano i requisiti di informazione e le regole aziendali. Il modello logico deve essere ridotto alla terza forma normale. La terza forma normale limita, aggiunge, aggiorna e rimuove le anomalie della struttura dei dati per supportare il principio "un fatto, un luogo". I requisiti di informazione raccolti e le regole aziendali dovrebbero essere analizzati e ricercati. Devono essere confrontati con il modello aziendale per garantire che non siano in conflitto con i modelli a oggetti esistenti e che includano tutti gli oggetti richiesti.

In ERwin, il modello di dati include sia modelli logici che fisici. ERwin implementa l'approccio ER e consente di creare oggetti modello logici e fisici per rappresentare i requisiti di informazione e le regole di business. Gli oggetti del modello logico includono entità, attributi e relazioni. Gli oggetti del modello fisico includono tabelle, colonne e vincoli di integrità delle relazioni.

In una delle seguenti pubblicazioni, verranno presi in considerazione i problemi di identificazione delle entità, determinazione dei tipi di entità, scelta dei nomi e delle descrizioni delle entità, nonché alcuni trucchi per evitare gli errori di modellazione più comuni associati all'uso delle entità.

Le entità devono avere un set completo di attributi, in modo che ogni fatto su ciascuna entità possa essere rappresentato dai suoi attributi. Ciascun attributo deve avere un nome che ne rifletta i valori, un tipo di dati booleano e una descrizione o definizione chiara, breve e completa. In una delle seguenti pubblicazioni, considereremo la serie iniziale di raccomandazioni per la corretta formazione di nomi e descrizioni di attributi. Le relazioni dovrebbero includere una costruzione verbale che descriva la relazione tra le entità, insieme a caratteristiche come la pluralità, il bisogno di esistenza o la possibilità di non esistenza della relazione.

NOTA Pluralità relazioni descrive il numero massimo di istanze di entità secondarie che possono essere associate a un'istanza dell'entità originale.La necessità dell'esistenza o la possibilità dell'assenza La relazione viene utilizzata per determinare il numero minimo di istanze di un'entità secondaria che può essere associata a un'istanza dell'originale

Per vendere, devi capire cosa stai vendendo.

Definiamo terminologia e concetti. ( Data Warehouse) non è un sistema di indicatori chiave di prestazione (KPI, KPI), non è un database di grandi dimensioni, non è un strumento OLAP, questo non è un sistema intelligente che permette di estrarre nuovi dati e ottenere dipendenze statistiche, questo non è un sistema di un singolo dato di riferimento - questo non è un data warehouse, se ne parliamo nel contesto di un singolo articolo.

Data Warehouse aziendale – si tratta di un array di dati appositamente organizzato di un'impresa (organizzazione), elaborato e archiviato in un unico complesso hardware e software, che fornisce un rapido accesso a informazioni operative e storiche, analisi dei dati multidimensionali (KPI per varie misurazioni), ottenendo previsioni e statistiche in nel contesto di un'informazione di riferimento regolamentare (NSI) concordata.

Potenziali clienti per un data warehouse aziendale e cosa ottengono?

Come identificare potenziali clienti aziendali che necessitano di un data warehouse?

Innanzitutto, molte informazioni dovrebbero emergere nelle attività quotidiane dell'azienda. Può trattarsi di telefonate, transazioni finanziarie, reclami/recensioni dei clienti, richieste di spedizione dei clienti, informazioni da satelliti spia, ecc. In linea di principio, qualsiasi cosa, la cosa principale è che ci sono molti dati.
Un potenziale cliente dovrebbe avere il desiderio di vedere e analizzare queste informazioni. Allo stesso tempo, il periodo di analisi dovrebbe essere piuttosto ampio, da un giorno o anche un'ora, a un'analisi di diversi anni.
Il client deve disporre di un'infrastruttura normalmente funzionante (non devono esserci server collegati tramite doppino intrecciato o porta USB). Se il cliente non ha l'infrastruttura, deve venderla.

Quali vantaggi ottiene il cliente dall'implementazione di un data warehouse aziendale?

Viene visualizzato un sistema unificato di archiviazione delle informazioni per i dati aziendali, in cui viene utilizzata un'unica informazione di riferimento.
C'è l'opportunità di condurre un'analisi completa del business. Ad esempio: quali clienti sono i più redditizi e redditizi; quale servizio, quali clienti sono più richiesti, che tipo di reclami sono più frequenti e in quali regioni, ecc.
Diventa possibile condurre un'analisi utilizzando i dati storici. Spesso i sistemi operativi (automatizzazione dei processi aziendali quotidiani) non lo consentono, semplicemente non dispongono di spazio sufficiente per archiviare la cronologia e il potere di condurre analisi.
Diventa possibile collegare e analizzare informazioni precedentemente memorizzate in diversi sistemi informativi. Ad esempio, i dati sul traffico di varie filiali vengono archiviati in sistemi di fatturazione di diversi sviluppatori. Dopo l'implementazione del data warehouse, diventa possibile analizzarli insieme, in un unico report.
Diventa possibile analizzare e incrociare diversi tipi di dati. Ad esempio, denaro e traffico, numero del personale e numero di rifiuti o reclami, ecc.
Esiste una base per un migliore calcolo del costo dei servizi: sulla base delle informazioni provenienti dal data warehouse aziendale, è possibile ottenere dati più adeguati per le basi di distribuzione naturale.

Che cos'è un data warehouse aziendale

Quali componenti costruisce un data warehouse aziendale dal punto di vista tecnico?

Componenti data warehouse aziendale imprese

Il cliente ha sempre sistemi operativi - Origine dei dati per data warehouse aziendale. Questi sono, ad esempio, contabilità, fatturazione, banche, ecc. sistemi.
Usando Applicazione ETL(software che consente di estrarre, trasformare e caricare dati), i dati provenienti dai sistemi di origine entrano nel database del data warehouse. È possibile utilizzare come strumento ETL: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Ci sono anche prodotti di altri fornitori, ma quasi non sono rappresentati sul mercato russo.
Si Banca dati lo storage aziendale non è astratto nella sua struttura (un insieme di tabelle, campi in esse e relazioni tra tabelle), ma è creato sulla base di modelli di dati. La stragrande maggioranza dei database utilizza Oracle o Teradata.
Modello di datiè una descrizione di tutte le entità, oggetti database di un data warehouse aziendale e include: modello di dati concettuale, modello di dati logico e fisico modello di database . A livello di modello concettuale, vengono definite le entità e le relazioni tra di esse. A livello del modello logico, le entità sono suddivise in aree di business, viene loro fornita una descrizione dettagliata e completa e vengono prescritte le relazioni. Quando si sviluppa un modello di database fisico, viene determinata l'intera struttura del database, dalle tabelle e dai campi in essi contenuti, alle partizioni e agli indici. Modelli di datiIBM, SAP e Oracle forniscono oggi il mercato, ma acquistare un modello di dati non significa creare automaticamente il giusto negozio aziendale.Modello di dati Questo non è un prodotto in scatola. Deve essere modificato per soddisfare le esigenze di un particolare cliente.
Inoltre, già utilizzando i dati del data warehouse aziendale, le aree di analisi, reporting e data mart. Successivamente, gli utenti possono creare autonomamente la reportistica necessaria e condurre analisi multivariate. Business Objects, Oracle Discoverer, IBM AlphaBlocks e altri prodotti vengono utilizzati principalmente come strumenti di analisi.

Che aspetto hanno i componenti di un data warehouse aziendale (modello di dati, processi ETL, data mart)

Diamo esempi illustrativi del modello dati, dell'implementazione del processo ETL, della forma di supporto per un unico dato di riferimento, dei data mart.

Modello logicodati.
Definisce le entità, i loro attributi e le relazioni tra di loro.

processo ETLeliminazione dei duplicati nei dati di origine

Modulo di inserimento dati per la formazione di un unico elenco

data martsotto forma di relazione tabellare

data martcon grafica e colore
emettere dati in base a una data condizione

data martcon programma

Software e hardware correlati

Innanzitutto, oltre ai servizi stessi per lo sviluppo di un data warehouse aziendale, vengono vendute anche licenze sia per software server (OS, database, server applicativo, ecc.) che per siti client (protezione antivirus e strumenti di sicurezza) .

È possibile che i server esistenti del client non siano progettati per la distribuzione del data warehouse. È necessario presentare i requisiti per loro e vendere hardware a un potenziale cliente.

Oltre ai server stessi, sono necessari disk array per archiviare una quantità significativa di informazioni.

Con l'intenzione di costruire un data warehouse aziendale, un potenziale cliente non sempre capisce come fornirà la ridondanza. Spesso i sistemi di backup esistenti del client non sono in grado di collegare simultaneamente al backup volumi di dati compresi tra 20 e 30 TB.

Di norma, gli specialisti e gli utenti del cliente richiedono corsi di formazione.

Kovtun MV Agosto 2010

Inviare il tuo buon lavoro nella knowledge base è semplice. Usa il modulo sottostante

Gli studenti, i dottorandi, i giovani scienziati che utilizzano la base di conoscenze nei loro studi e nel loro lavoro ti saranno molto grati.

postato su http://www.allbest.ru/

1. Modello di dati relazionali

1.1 Modello di dati relazionali. Definizioni di base
1.2 Operazioni sulle relazioni

2. Sistemi informativi aziendali
Bibliografia

1. Modello di dati relazionali

1.1 Modello di dati relazionali. Definizioni di base

Nelle discipline matematiche, il concetto di "tavola" corrisponde al concetto di "relazione" (relazione). La tabella riflette un oggetto del mondo reale, un'entità, e ciascuna delle sue righe riflette un'istanza specifica dell'entità. Ogni colonna ha un nome univoco per la tabella. Le stringhe non hanno nomi, il loro ordine non è definito e il loro numero non è logicamente limitato. Uno dei principali vantaggi del modello di dati relazionali è l'omogeneità (ogni riga di una tabella ha un formato). L'utente stesso decide se le entità corrispondenti hanno omogeneità. Questo risolve il problema dell'idoneità del modello.

Concetti basilari:

* Una relazione è una tabella bidimensionale contenente alcuni dati.

* Entità: un oggetto di qualsiasi natura, i cui dati sono archiviati nel database. Attributi - proprietà che caratterizzano l'entità (colonne).

* Grado di relazione - il numero di colonne.

* Schema di relazione: un elenco di nomi di attributi, ad esempio DIPENDENTE (n., nome completo, anno di nascita, posizione, dipartimento).

* Dominio: un insieme di valori di attributo di relazione (tipo di dati).

* Tupla - riga della tabella.

* Cardinalità (potenza) - il numero di righe nella tabella.

* La chiave primaria è un attributo che identifica in modo univoco le righe in una relazione. Una chiave primaria con più attributi è chiamata chiave composita. La chiave primaria non può essere completamente o parzialmente vuota (avere un valore nullo). Le chiavi che possono essere utilizzate come chiavi primarie sono chiamate chiavi candidate o alternative.

* Una chiave esterna è uno o più attributi di una tabella che possono fungere da chiave primaria di un'altra tabella. È un riferimento alla chiave primaria di un'altra tabella.

La normalizzazione è un processo volto a ridurre la ridondanza delle informazioni in un database. Oltre ai dati stessi, nel database possono essere normalizzati anche vari nomi, nomi di oggetti ed espressioni.

Un database non normalizzato contiene informazioni in una o più tabelle diverse; ciò crea l'impressione che l'inclusione dei dati in una tabella particolare non sia dovuta a ragioni apparenti. Questo stato di cose può avere un impatto negativo sulla sicurezza dei dati, sulla gestione dello spazio su disco, sulla velocità delle query, sull'efficienza dell'aggiornamento del database e, cosa forse più importante, sull'integrità delle informazioni archiviate. Il database prima della normalizzazione è una struttura che non è stata ancora suddivisa logicamente in tabelle più piccole e gestibili.

La forma normale è una sorta di indicatore del livello, o profondità, della normalizzazione del database. Il livello di normalizzazione di un database corrisponde alla forma normale in cui si trova.

1.2 Operazioni sulle relazioni

Per convertire una tabella nella prima forma normale (1NF), devono essere osservate due regole:

1. Atomicità o indivisibilità. Ogni colonna deve contenere un valore indivisibile.

2. La tabella non deve contenere colonne o gruppi di dati ripetuti.

Ad esempio, se una tabella contiene l'indirizzo completo di una persona (via, città, codice postale) in un campo, non rispetterà le regole di 1NF, poiché conterrà valori diversi in una colonna, che sarà una violazione della regola dell'atomicità. Oppure, se il database contiene dati sui film e ha le colonne attore1, attore2, attore3, non soddisferà le regole, poiché ci sarà la ripetizione dei dati.

La normalizzazione dovrebbe iniziare controllando la struttura del database per la compatibilità con 1NF. Tutte le colonne che non sono atomiche devono essere scomposte nelle loro colonne costituenti. Se la tabella ha colonne duplicate, devono allocare una tabella separata.

Per convertire una tabella nella prima forma normale:

* Trova tutti i campi che contengono più informazioni.

* I dati che possono essere suddivisi in parti componenti devono essere inseriti in campi separati.

* Sposta i dati duplicati in una tabella separata.

* Verifica se tutte le tabelle soddisfano le condizioni del primo modulo normale.

Per convertire le tabelle nella seconda forma normale (2NF), le tabelle risultanti devono essere già in 1NF. La normalizzazione deve essere eseguita in ordine.

Ora, nella seconda forma normale, la condizione deve essere soddisfatta: qualsiasi colonna che non sia una chiave (comprese quelle esterne) deve dipendere dalla chiave primaria. Tipicamente, queste colonne, che hanno valori che non dipendono dalla chiave, sono facili da identificare. Se i dati contenuti in una colonna non sono correlati alla chiave che descrive la riga, devono essere separati in una tabella separata. La chiave primaria deve essere restituita alla vecchia tabella.

Per convertire la base nella seconda forma normale:

* Identifica tutte le colonne che non dipendono direttamente dalla chiave primaria di questa tabella.

* Crea i campi necessari nelle tabelle utenti e forum, seleziona da campi esistenti o crea chiavi primarie da quelle nuove.

* Ogni tabella necessita della propria chiave primaria

* Crea chiavi esterne e denota le loro relazioni tra le tabelle. L'ultimo passaggio della normalizzazione a 2NF sarà l'assegnazione di chiavi esterne per l'associazione con le tabelle associate. La chiave primaria di una tabella deve essere una chiave esterna in un'altra.

Suggerimenti:

Un altro modo per creare uno schema 2NF è esaminare le relazioni tra le tabelle. L'opzione ideale è creare tutte le relazioni uno-a-molti. Le relazioni molti-a-molti devono essere ristrutturate.

Una tabella correttamente normalizzata non avrà mai righe duplicate (due o più righe i cui valori non sono chiavi e contengono gli stessi dati).

Un database sarà nella terza forma normale se viene eseguito il cast nella seconda forma normale e ogni colonna non chiave è indipendente l'una dall'altra. Se il processo di normalizzazione viene seguito correttamente fino a questo punto, potrebbero non esserci problemi con la riduzione a 3NF. Dovresti essere consapevole del fatto che 3NF viene violato se una modifica in un valore in una colonna richiede una modifica in un'altra colonna.

Per convertire la base nella terza forma normale:

* Determina in quali campi di quali tabelle esiste un'interdipendenza, ad es. campi che dipendono più l'uno dall'altro che dalla serie nel suo insieme.

* Crea tabelle pertinenti. Se è presente una colonna problematica nel passaggio 1, creare tabelle separate per essa.

* Creare o allocare chiavi primarie. Ogni tabella deve avere una chiave primaria.

* Crea le chiavi esterne necessarie che formano una qualsiasi delle relazioni.

Nella quarta forma normale, un'ulteriore regola consiste nell'escludere le dipendenze multivalore. In altre parole, tutte le righe della tabella devono essere indipendenti l'una dall'altra. La presenza di qualche riga X non dovrebbe significare che anche la riga Y sia da qualche parte in questa tabella.

2. Sistemi informativi aziendali

sistema di dati del modello relazionale

Un sistema (dal greco systema - un tutto, una connessione fatta di parti) è un insieme di elementi che interagiscono tra loro, formando una certa integrità, unità. Ecco alcuni concetti che vengono spesso utilizzati per caratterizzare un sistema.

1. Elemento del sistema: una parte del sistema che ha uno scopo funzionale specifico. Gli elementi complessi dei sistemi, a loro volta costituiti da elementi interconnessi più semplici, sono spesso chiamati sottosistemi.

2. Organizzazione del sistema - ordine interno, coerenza nell'interazione degli elementi del sistema, che si manifesta, in particolare, nel limitare la diversità degli stati degli elementi all'interno del sistema.

3. La struttura del sistema: la composizione, l'ordine e i principi di interazione degli elementi del sistema, che determinano le proprietà di base del sistema. Se i singoli elementi del sistema sono separati da livelli diversi e i collegamenti interni tra gli elementi sono organizzati solo dai livelli superiori a quelli inferiori e viceversa, allora si parla di una struttura gerarchica del sistema. Strutture puramente gerarchiche sono praticamente rare, quindi, ampliando un po' questo concetto, una struttura gerarchica è generalmente intesa come tali strutture in cui, tra le altre connessioni, le connessioni gerarchiche sono di fondamentale importanza.

4. Architettura del sistema: un insieme di proprietà di sistema essenziali per l'utente.

5. L'integrità del sistema - l'irriducibilità fondamentale delle proprietà del sistema alla somma delle proprietà dei suoi singoli elementi (l'emergere delle proprietà) e, allo stesso tempo, la dipendenza delle proprietà di ciascun elemento dal suo posto e funzione all'interno del sistema.

Un sistema informativo è un insieme interconnesso di mezzi, metodi e personale utilizzato per archiviare, elaborare e rilasciare informazioni al fine di raggiungere l'obiettivo"

La legge federale "Sull'informazione, l'informatizzazione e la protezione delle informazioni" fornisce la seguente definizione:

"Il sistema informativo è un insieme ordinato dal punto di vista organizzativo di documenti (array di documenti) e tecnologie informatiche, compreso l'utilizzo di tecnologie informatiche e strumenti di comunicazione che implementano processi informativi"

Classificazione in scala

Per scala, i sistemi informativi sono suddivisi nei seguenti gruppi:

* separare;

* gruppo;

* aziendale.

Un sistema informativo aziendale è un sistema scalabile progettato per l'automazione complessa di tutti i tipi di attività economiche di grandi e medie imprese, comprese le società costituite da un gruppo di società che richiedono una gestione unificata.

Un sistema informativo aziendale può essere considerato un sistema che automatizza oltre l'80% delle divisioni aziendali.

Di recente, in molte pubblicazioni dedicate all'uso delle tecnologie informatiche nella gestione degli oggetti economici, viene spesso utilizzato il termine "sistemi informativi aziendali", che si riferisce ai veri e propri sistemi informatici automatizzati degli oggetti economici.

Un sistema informativo automatizzato (AIS) è una combinazione di vari tipi di supporto, nonché di specialisti progettati per automatizzare l'elaborazione delle informazioni contabili e analitiche. I tipi di supporto in termini di composizione sono, di regola, omogenei per i diversi sistemi, il che consente di attuare il principio di compatibilità dei sistemi nel corso del loro funzionamento. Nel processo di studio dell'AIS come sistema complesso, è necessario individuare singole parti ed elementi e considerare le caratteristiche del loro utilizzo nelle fasi di creazione e funzionamento.

I sistemi informativi aziendali sono un'evoluzione dei sistemi per gruppi di lavoro, sono focalizzati su grandi aziende e possono supportare nodi o reti geograficamente dispersi. Fondamentalmente, hanno una struttura gerarchica a più livelli. Tali sistemi sono caratterizzati da un'architettura client-server con specializzazione dei server o da un'architettura multilivello. Durante lo sviluppo di tali sistemi, è possibile utilizzare gli stessi server di database utilizzati per lo sviluppo di sistemi informativi di gruppo. Tuttavia, nei sistemi informativi di grandi dimensioni, i server più utilizzati sono Oracle, DB2 e Microsoft SQL Server.

Per i sistemi di gruppo e aziendali, i requisiti per l'affidabilità del funzionamento e la sicurezza dei dati sono notevolmente aumentati. Queste proprietà sono fornite mantenendo l'integrità di dati, collegamenti e transazioni nei server di database.

Classificazione per ambito

Secondo l'ambito dei sistemi informativi sono generalmente divisi in quattro gruppi:

* sistemi di elaborazione delle transazioni;

* sistemi decisionali;

* sistemi informativi e di riferimento;

* sistemi informativi d'ufficio.

Bibliografia

1. Agltsov, VP Banca dati. In 2 volumi V. 2. Banche dati distribuite e remote: Libro di testo / V.P. Agltsov. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Banche dati: libro di testo / O.L. Golitsyna, NV Maksimov, I.I. Popov. - M.: Forum, 2012.

3. Karpova, IP Banche dati: libro di testo / I.P. Karpov. - San Pietroburgo: Pietro, 2013.

4. Kirillov, V.V. Introduzione ai database relazionali Introduzione ai database relazionali / V.V. Kirillov, G.Yu. Gromov. - San Pietroburgo: BHV-Pietroburgo, 2012.

5. Pirogov, V.Yu. Sistemi informativi e banche dati: organizzazione e design: Libro di testo / V.Yu. Pirogov. - San Pietroburgo: BHV-Pietroburgo, 2009.

6. G.N. Fedorov. Sistemi di informazione. - M.: Accademia, 2013.

7. A.E. Satunina, LA Sysoev. Project management del sistema informativo aziendale dell'impresa. - M.: Finanza e statistica, Infra-M, 2009.

Ospitato su Allbest.ru

...

Documenti simili

Essenza e caratteristiche dei tipi di modelli di dati: gerarchici, di rete e relazionali. Concetti di base del modello dei dati relazionali. Attributi, schema di relazione del database. Condizioni di integrità dei dati. Relazioni tra tabelle. Idee generali sul modello dati.

tesina, aggiunta il 29/01/2011

Sistemi informativi aziendali e database, loro utilizzo per il miglioramento e il debug del business. Classificazione dei sistemi informativi aziendali. Sistemi informativi della classe OLTP. Elaborazione analitica operativa.

tesina, aggiunta il 19/01/2011

Database con file bidimensionali e sistemi di gestione di database relazionali (DBMS). Creazione di un database ed elaborazione di query tramite un DBMS. Tipi di base di database. Concetti di base dei database relazionali. Proprietà fondamentali delle relazioni.

abstract, aggiunto il 20/12/2010

Il concetto di un sistema di database. Modello relazionale e sue caratteristiche. L'integrità nel modello relazionale. Algebra relazionale. Problemi di progettazione del database. normali forme di relazione. Progettazione di un database utilizzando il metodo entità-relazione. diagrammi ER. Linguaggio SQL.

corso di lezioni, aggiunto il 03.10.2008

Una struttura logica specifica di dati archiviata in un database. Modelli di dati di base. Elementi del modello dei dati relazionali. Un esempio di utilizzo di chiavi esterne. I principali requisiti per le relazioni del modello di dati relazionali.

presentazione, aggiunta il 14/10/2013

I database e il loro utilizzo nell'informatica. Caratteristiche e unità strutturale di base del modello dati di rete. Modello gerarchico, oggetti di dominio. Modello relazionale, sua visibilità, presentazione dei dati in forma tabellare.

abstract, aggiunto il 19/12/2011

Tipi e funzioni del sistema di gestione dei database Microsoft Access. Modello gerarchico, di rete, relazionale di descrizione del database. Concetti di base di una tabella di database. Funzionalità di creazione di oggetti di database, moduli di base. Accesso a Internet in Access.

lavoro di controllo, aggiunto il 01/08/2011

Moderni sistemi di gestione di database (DBMS). Analisi del modello dati gerarchico. Modello di dati relazionali. Modello di dati post-relazionale come modello relazionale esteso che rimuove la restrizione dell'indivisibilità dei dati memorizzati nei record di tabella.

lavoro scientifico, aggiunto il 06/08/2010

Modelli di dati nella gestione dei database. Modelli di dati concettuali. Il ruolo delle banche dati nei sistemi informativi. Modello di dati relazionali. Definizione dell'area disciplinare. Realizzazione di un modello di database per il sistema informativo "Pets".

tesina, aggiunta il 19/04/2011

Un modello informativo in Access come sostituto semplificato di un oggetto o sistema reale. Strutture di base che definiscono l'organizzazione dei dati e le relazioni tra di essi; tipo relazionale di organizzazione dei dati. Un esempio di database in materia fiscale.

Zaitsev SL, Ph.D.

Gruppi ripetuti

Riso. 1.6. Questo esempio usa i gruppi ripetuti.

Riso. 1.7. Modello ridotto alla prima forma normale.

Un fatto in un posto

Se lo stesso attributo è presente in più di un'entità e non è una chiave esterna, tale attributo è considerato ridondante. Il modello logico non deve contenere dati ridondanti.

Ogni attributo dipende da una chiave

Riso. 1.9. In terza forma normale Nome della scuola e Regione geografica spostato nell'entità, dove i loro valori dipendono dalla chiave.

Molte-a-molte relazioni

Definizioni formali di forme normali

Una relazione R è in prima forma normale (1NF) se e solo se tutti i suoi domini contengono solo valori atomici (Data, ibid.).

Una relazione R è in seconda forma normale (2NF) se e solo se è in 1NF e ogni attributo non chiave è completamente dipendente dalla chiave primaria (Data, ibid.).

Una relazione R è in terza forma normale (3NF) se e solo se è in 2NF e ogni attributo non chiave non è transitivamente dipendente dalla chiave primaria (Data, ibid.).

La relazione R è in forma normale di Boyce-Codd (BCNF) se e solo se ogni determinante è un candidato per l'uso come chiave.

NOTA Di seguito è riportata una breve spiegazione di alcune delle abbreviazioni utilizzate nelle definizioni di Date.

FD (dipendenza funzionale) - dipendenza funzionale. In una dipendenza funzionale, il valore di un attributo dipende dal valore di un altro attributo che non fa parte della chiave primaria.

Moduli commerciali normali

La terza forma normale aziendale (3BNF) sposta gli attributi che non dipendono dalla chiave primaria a un'altra entità, dove dipendono completamente dalla chiave primaria di questa entità.

Modello di dati logici completato

Modello di dati fisici

Raccolta dei requisiti di utilizzo dei dati

Requisiti di accesso e prestazioni

Caratteristiche volumetriche (stima della quantità di dati da memorizzare), che consentono all'amministratore di rappresentare il volume fisico del database

Una stima del numero di utenti che hanno bisogno di accedere ai dati contemporaneamente, che ti aiuta a progettare il tuo database per un livello di prestazioni accettabile

Riepilogo, riepilogo e altri dati calcolati o derivati che possono essere considerati candidati per l'archiviazione in strutture di dati durevoli

Requisiti per la generazione di report e query standard per aiutare l'amministratore del database a creare indici

Viste (permanenti o virtuali) che aiuteranno l'utente nell'esecuzione di operazioni di unione o filtraggio dei dati.

Componenti del modello fisico dei dati

ingegneria inversa

Uso dei confini funzionali aziendali

Che cos'è un modello di dati aziendale?

Creazione di un modello di dati aziendali mediante ridimensionamento

Il concetto di metodologia di modellazione

Esistono diverse metodologie per la modellazione visiva dei dati. ERwin ne supporta due:

IDEF1X (Definizione dell'integrazione per la modellazione delle informazioni - descrizione integrata dei modelli informativi).

IE (Ingegneria dell'Informazione - Ingegneria dell'Informazione).

IDEF1X è una buona metodologia e la sua notazione è ampiamente utilizzata

Descrizione integrata dei modelli informativi

Ingegneria dell'informazione

Conclusione

Sempre più spesso, i professionisti IT stanno rivolgendo la loro attenzione a soluzioni di gestione dei dati basate su modelli di dati standard del settore e modelli di decisioni aziendali. Modelli di dati fisici complessi pronti per il caricamento e report di business intelligence per aree di attività specifiche consentono di unificare la componente informativa dell'azienda e accelerare notevolmente i processi aziendali. I modelli di soluzione consentono ai fornitori di servizi di sfruttare la potenza delle informazioni non standard nascoste nei sistemi esistenti, riducendo così tempi, costi e rischi del progetto. Ad esempio, i progetti reali mostrano che il modello di dati e i modelli di decisione aziendale possono ridurre lo sforzo di sviluppo del 50%.

Un modello logico di settore è una vista specifica del dominio, integrata e strutturata in modo logico di tutte le informazioni che devono trovarsi in un data warehouse aziendale per rispondere a domande di business sia strategiche che tattiche. Lo scopo principale dei modelli è facilitare l'orientamento nello spazio dei dati e aiutare a evidenziare i dettagli importanti per lo sviluppo del business. Nell'ambiente aziendale odierno, è assolutamente essenziale avere una chiara comprensione delle relazioni tra le varie componenti e una buona comprensione del quadro generale dell'organizzazione. L'identificazione di tutti i dettagli e delle relazioni tramite modelli consente di utilizzare nel modo più efficiente tempo e strumenti per organizzare il lavoro dell'azienda.

I modelli di dati sono modelli astratti che descrivono come i dati vengono rappresentati e accessibili. I modelli di dati definiscono gli elementi di dati e le relazioni tra di loro in una determinata area. Un modello di dati è uno strumento di navigazione sia per le aziende che per i professionisti IT che utilizza un insieme specifico di simboli e parole per spiegare accuratamente una classe specifica di informazioni reali. Ciò migliora la comunicazione all'interno dell'organizzazione e crea così un ambiente applicativo più flessibile e stabile.

Un esempio di GIS per le autorità e modello di autogoverno locale.

Oggi è strategicamente importante per i fornitori di software e servizi essere in grado di rispondere rapidamente ai cambiamenti del settore associati alle innovazioni tecnologiche, alla rimozione delle restrizioni governative e alla complessità delle catene di approvvigionamento. Insieme ai cambiamenti nel modello di business, cresce la complessità e il costo delle tecnologie informatiche necessarie a supportare le attività dell'azienda. La gestione dei dati è particolarmente difficile in un ambiente in cui i sistemi informativi aziendali ei loro requisiti funzionali e aziendali sono in continua evoluzione.

Per aiutare a facilitare e ottimizzare questo processo, nel tradurre l'approccio IT al livello moderno, sono richiesti modelli di dati di settore.

Modelli di dati di settore dell'aziendaEsri

I modelli di dati per la piattaforma Esri ArcGIS sono modelli di lavoro da utilizzare nei progetti GIS e per la creazione di strutture di dati per varie aree applicative. La creazione di un modello di dati implica la creazione di un progetto concettuale, una struttura logica e una struttura fisica che possono quindi essere utilizzate per creare un geodatabase personale o aziendale. ArcGIS fornisce strumenti per la creazione e la gestione di uno schema di database e i modelli di modelli di dati vengono utilizzati per avviare rapidamente un progetto GIS in una varietà di applicazioni e settori. Esri, insieme alla comunità degli utenti, ha dedicato molto tempo allo sviluppo di una serie di modelli che possono aiutarti a iniziare rapidamente a progettare un geodatabase aziendale. Questi progetti sono descritti e documentati su support.esri.com/datamodels . Di seguito, nell'ordine in cui appaiono su questo sito, ci sono le traduzioni semantiche dei nomi dei modelli di settore di Esri:

Registro degli indirizzi
agricoltura
Meteorologia
Dati spaziali di base
Biodiversità
Spazio interno degli edifici
Contabilità del gas serra
Mantenimento dei confini amministrativi
Stabilimento militare. Servizio di intelligence
Energia (incluso il nuovo protocollo ArcGIS MultiSpeak)
Edifici ecologici
Ministero per le situazioni di emergenza. Protezione antincendio
Catasto forestale
Silvicoltura
Geologia
GIS a livello nazionale (e-gov)
Acque sotterranee e reflue
assistenza sanitaria
Archeologia e protezione dei siti commemorativi
sicurezza nazionale
Idrologia
Organizzazione idrografica internazionale (IHO). Formato S-57 per ENC
Irrigazione
Catasto
governo municipale
Navigazione marittima
Catasto dello Stato
Strutture petrolifere e del gas
Condutture
Negozi raster
Batimetria, topografia dei fondali
Telecomunicazioni
Trasporto
Impianti idraulici, fognari, servizi

Questi modelli contengono tutte le caratteristiche necessarie dello standard del settore, vale a dire:

sono liberamente disponibili;
non sono legati alla tecnologia del produttore "selezionato";
creato come risultato della realizzazione di progetti reali;
realizzato con la partecipazione di esperti del settore;
progettato per fornire interazione informativa tra vari prodotti e tecnologie;
non contraddire altri standard e documenti normativi;
utilizzato in progetti implementati in tutto il mondo;
sono progettati per funzionare con le informazioni durante tutto il ciclo di vita del sistema in fase di creazione e non con il progetto stesso;
espandibile alle esigenze del cliente senza perdere la compatibilità con altri progetti e/o modelli;
accompagnato da materiali ed esempi aggiuntivi;
utilizzato nelle linee guida e nei materiali tecnici di varie aziende industriali;
una grande comunità di partecipanti, mentre l'accesso alla comunità è aperto a tutti;
un gran numero di riferimenti a modelli di dati nelle pubblicazioni degli ultimi anni.

Esri fa parte di un gruppo di esperti di organismi indipendenti che raccomandano l'uso di vari modelli di settore, come PODS (Pipeline Open Data Standards - uno standard aperto per l'industria petrolifera e del gas; attualmente esiste un'implementazione di PODS come Esri PODS Esri Spatial 5.1.1 geodatabase) o un geodatabase (GDB) di ArcGIS for Aviation che tenga conto delle raccomandazioni ICAO e FAA, nonché dello standard di scambio dei dati di navigazione AIXM 5.0. Inoltre, sono disponibili modelli consigliati che aderiscono rigorosamente agli standard di settore esistenti, come S-57 e ArcGIS for Maritime (caratteristiche marine e costiere), nonché modelli creati dal lavoro di Esri Professional Services e sono standard "de facto" nelle aree di pertinenza. Ad esempio, i GIS per la nazione e il governo locale hanno influenzato gli standard NSDI e INSPIRE, mentre Hydro e Groundwater sono ampiamente utilizzati nel pacchetto professionale ArcHydro disponibile gratuitamente e nei prodotti commerciali di aziende terze. Va notato che Esri supporta anche standard "de facto" come NHDI. Tutti i modelli di dati proposti sono documentati e pronti per l'uso nei processi IT aziendali. I materiali di accompagnamento per i modelli includono:

diagrammi UML di relazioni tra entità;
strutture dati, domini, directory;
modelli di geodatabase già pronti in formato ArcGIS GDB;
dati di esempio e applicazioni di esempio;
esempi di script di caricamento dati, esempi di utilità di analisi;
libri di riferimento sulla struttura dei dati proposta.

Esri riassume la sua esperienza nella costruzione di modelli di settore sotto forma di libri e localizza i materiali pubblicati. Esri CIS ha localizzato e pubblicato i seguenti libri:

Architettura geospaziale orientata ai servizi (SOA);
Progettazione di geodatabase per il trasporto;
Sistemi di geoinformazione aziendale;
GIS: nuova energia delle imprese elettriche e del gas;
Petrolio e gas su una mappa digitale;
Modellare il nostro mondo. Guida alla progettazione del geodatabase Esri;
Pensando al GIS. Progettazione GIS: una guida per i manager;
Sistemi informativi geografici. Nozioni di base;
GIS per la gestione amministrativa ed economica;
WebGIS. Principi e applicazione;
Strategie di progettazione dei sistemi, 26a edizione;
68 numeri della rivista ArcReview con pubblicazioni di aziende e utenti di sistemi GIS;
... e tante altre note e pubblicazioni tematiche.

Ad esempio, il libro Modellare il nostro mondo..."(traduzione) è una guida completa e una guida di riferimento alla modellazione dei dati GIS in generale e al modello dei dati del geodatabase in particolare. Il libro mostra come prendere le giuste decisioni sulla modellazione dei dati, decisioni che sono coinvolte in ogni aspetto di un progetto GIS: dai dati di progettazione del database e dalla raccolta dei dati all'analisi e visualizzazione spaziale Descrive in dettaglio come progettare un database geografico appropriato per il progetto, impostare funzionalità di database senza programmazione, gestire il flusso di lavoro in progetti complessi, modellare una varietà di strutture di rete come fiume, trasporti o reti elettriche, integrare i dati delle immagini satellitari nell'analisi geografica e nella mappatura e creare modelli di dati 3D GIS. Progettazione di geodatabase per il trasporto" contiene approcci metodologici che sono stati testati su un gran numero di progetti e sono pienamente conformi ai requisiti legislativi dell'Europa e degli Stati Uniti, nonché agli standard internazionali. E nel libro " GIS: la nuova energia delle imprese elettriche e del gas Utilizzando esempi del mondo reale, mostra i vantaggi che un GIS aziendale può apportare a un fornitore di energia, inclusi aspetti come il servizio clienti, il funzionamento della rete e altri processi aziendali.

Alcuni dei libri, tradotti e originali, pubblicati in russo da Esri CIS e DATA+. Coprono sia le questioni concettuali relative alla tecnologia GIS che molti aspetti applicati alla modellazione e all'implementazione di GIS di varie scale e scopi.

Prenderemo in considerazione l'uso di modelli di settore utilizzando come esempio il modello di dati BISDM (Building Interior Space Data Model) versione 3.0. BISDM è uno sviluppo di un modello BIM più generale (Building Information Model, Building Information Model) ed è destinato all'uso nella progettazione, costruzione, esercizio e smantellamento di edifici e strutture. Utilizzato nei software GIS, consente di scambiare efficacemente geodati con altre piattaforme e interagire con esse. Si riferisce al gruppo di attività generale FM (gestione dell'infrastruttura organizzativa). Elenchiamo i principali vantaggi del modello BISDM, il cui utilizzo consente:

organizzare lo scambio di informazioni in un ambiente eterogeneo secondo regole uniformi;
ottenere una incarnazione "fisica" del concetto BIM e delle regole consigliate per la gestione di un progetto di costruzione;
mantenere un unico repository utilizzando gli strumenti GIS durante l'intero ciclo di vita dell'edificio (dalla progettazione alla dismissione);
coordinare il lavoro di vari specialisti nel progetto;
visualizzare il programma pianificato e le fasi di costruzione per tutti i partecipanti;
fornire una stima preliminare del costo e dei tempi di realizzazione (dati 4D e 5D);
controllare lo stato di avanzamento del progetto;
garantire il funzionamento di qualità dell'edificio, compresa la manutenzione e le riparazioni;
entrare a far parte del sistema di asset management, comprese le funzioni di analisi dell'efficienza dell'uso degli spazi (affitto, depositi, gestione del personale);
calcolare e gestire l'efficienza energetica dell'edificio;
simulare il movimento dei flussi umani.

BISDM definisce le regole per lavorare con i dati spaziali a livello di locali interni in un edificio, compresi lo scopo e i tipi di utilizzo, le comunicazioni posate, le apparecchiature installate, la contabilità per riparazioni e manutenzione, la registrazione degli incidenti, i rapporti con altri beni aziendali. Il modello aiuta a creare un repository unificato di dati geografici e non geografici. L'esperienza delle principali aziende mondiali è stata utilizzata per isolare entità e modellare a livello GDB (geodatabase) le relazioni spaziali e logiche di tutti gli elementi fisici che costituiscono sia l'edificio stesso che il suo interno. Seguire i principi del BISDM consente di semplificare notevolmente i compiti di integrazione con altri sistemi. Nella prima fase, questa è solitamente l'integrazione con CAD. Quindi, durante il funzionamento dell'edificio, viene utilizzato lo scambio di dati con i sistemi ERP ed EAM (SAP, TRIRIGA, Maximo, ecc.).

Visualizzazione di elementi strutturali BISDM mediante ArcGIS.

Nel caso di utilizzo di BISDM, il cliente/proprietario della struttura riceve uno scambio di informazioni end-to-end dall'idea di creare una struttura allo sviluppo di un progetto completo, controllo di costruzione con ottenimento fino a - informazioni sulla data entro il momento della messa in funzione dell'impianto, controllo dei parametri durante il funzionamento e anche durante la ricostruzione o la disattivazione dell'impianto. Seguendo il paradigma BISDM, il GIS e il GDB creato con il suo aiuto diventano un repository di dati comune per i sistemi correlati. Spesso nel GDB ci sono dati creati e gestiti da sistemi di terze parti. Questo deve essere preso in considerazione durante la progettazione dell'architettura del sistema in fase di creazione.

Ad un certo punto, la "massa critica" di informazioni accumulata consente di passare a un nuovo livello qualitativo. Ad esempio, al termine della fase di progettazione di un nuovo edificio, è possibile visualizzare in automatico modelli di rilievo 3D in GIS, compilare un elenco delle apparecchiature da installare, calcolare i chilometri di reti ingegneristiche da posare, eseguire alcune verifiche , e anche fornire una stima finanziaria preliminare del costo del progetto.

Ancora una volta, utilizzando BISDM e ArcGIS insieme, diventa possibile costruire automaticamente modelli 3D dai dati accumulati, poiché il GDB contiene una descrizione completa dell'oggetto, comprese le coordinate z, l'appartenenza a un piano, i tipi di connessioni degli elementi, le apparecchiature modalità di installazione, materiale, percorsi disponibili movimenti del personale, scopo funzionale di ogni elemento, ecc. eccetera. Va notato che dopo l'importazione iniziale di tutti i materiali di progettazione nel BISDM GDB, è necessario un contenuto aggiuntivo per:

posizionamento di modelli 3D di oggetti e attrezzature in luoghi designati;
raccogliere informazioni sul costo dei materiali e sulla procedura per la loro posa e installazione;
controllo della pervietà in base alle dimensioni dell'apparecchiatura non standard installata.

Attraverso l'uso di ArcGIS, l'importazione di ulteriori oggetti 3D e libri di riferimento da fonti esterne è semplificata. Il modulo ArcGIS Data Interoperability consente di creare procedure per importare tali dati e posizionarli correttamente all'interno del modello. Sono supportati tutti i formati utilizzati nel settore, inclusi IFC, AutoCAD Revit, Benlye Microstation.

Modelli di dati di settore di IBM

IBM fornisce una serie di strumenti e modelli di gestione dello storage per una varietà di settori:

IBM Banking and Financial Markets Data Warehouse (finanza)
IBM Banking Data Warehouse
Processo bancario IBM e modelli di servizio
Modello di dati del piano sanitario IBM (salute)
IBM Insurance Information Warehouse (assicurazione)
Processo assicurativo IBM e modelli di servizio
IBM Retail Data Warehouse (vendita al dettaglio)
IBM Telecommunications Data Warehouse (telecomunicazioni)
Pacchetto magazzino InfoSphere:
- per Customer Insight (per comprendere i clienti)
- per Market e Campaign Insight (per comprendere l'azienda e il mercato)
- per Supply Chain Insight (per la comprensione dei fornitori).

Ad esempio, modello IBMbancarioeFinanziariomercatiDatiMagazzino progettato per affrontare le sfide specifiche del settore bancario in termini di dati, e IBMbancarioprocessieServizioModelli- in termini di processi e SOA (architettura orientata ai servizi). Modelli presentati per l'industria delle telecomunicazioni IBMInformazioneStruttura(SEW) e IBMTelecomunicazioniDatiMagazzino (TDW). Aiutano ad accelerare notevolmente il processo di creazione di sistemi analitici, nonché a ridurre i rischi associati allo sviluppo di applicazioni di business intelligence, alla gestione dei dati aziendali e all'organizzazione dei data warehouse, tenendo conto delle specificità del settore delle telecomunicazioni. Le capacità di IBM TDW coprono l'intero spettro del mercato delle telecomunicazioni: dai provider Internet e dagli operatori di reti via cavo che offrono servizi di telefonia cablata e wireless, trasmissione dati e contenuti multimediali, alle multinazionali che forniscono servizi telefonici, satellitari, a lunga distanza e di comunicazione internazionale, nonché come organizzazioni reti globali. Oggi, TDW è utilizzato da grandi e piccoli fornitori di servizi cablati e wireless in tutto il mondo.

Lo strumento chiamato Pacchetto InfoSphere Warehouse per informazioni dettagliate sui clientiè un contenuto aziendale strutturato e facilmente implementabile per un numero crescente di progetti e settori aziendali, tra cui banche, assicurazioni, finanza, programmi di assicurazione sanitaria, telecomunicazioni, vendita al dettaglio e distribuzione. Per utenti aziendali Pacchetto InfoSphere Warehouse per informazioni sul mercato e sulla campagna ti aiuta a massimizzare l'efficacia delle informazioni di mercato e delle campagne di marketing attraverso uno sviluppo passo dopo passo e un processo specifico per l'azienda. attraverso Pacchetto InfoSphere Warehouse per informazioni sulla catena di approvvigionamento le organizzazioni hanno la capacità di ottenere informazioni aggiornate sulle operazioni della catena di approvvigionamento.

La posizione di Esri all'interno dell'architettura della soluzione IBM.

Di particolare rilievo è l'approccio di IBM ai servizi di pubblica utilità e alle società di servizi pubblici. Per soddisfare le crescenti richieste dei consumatori, le società di servizi pubblici necessitano di un'architettura più flessibile di quella che usano oggi, nonché di un modello a oggetti standard del settore che faciliti il libero scambio di informazioni. Ciò migliorerà le capacità di comunicazione delle società energetiche consentendo comunicazioni più convenienti e darà ai nuovi sistemi una migliore visibilità su tutte le risorse necessarie, indipendentemente da dove si trovano all'interno dell'organizzazione. Alla base di questo approccio c'è la SOA (Service Oriented Architecture), un modello a componenti che stabilisce una corrispondenza tra le funzioni dei dipartimenti ei servizi di varie applicazioni che possono essere riutilizzati. I "servizi" di questi componenti comunicano attraverso interfacce senza hard binding, nascondendo all'utente l'intera complessità dei sistemi dietro di loro. In questa modalità, le aziende possono aggiungere facilmente nuove applicazioni indipendentemente dal fornitore del software, dal sistema operativo, dal linguaggio di programmazione o da altre caratteristiche interne del software. Il concetto è implementato sulla base di SOA SICURO ( Solution Architecture for Energy, consente al settore dei servizi pubblici di ottenere una visione olistica basata su standard della propria infrastruttura.

Esri ArcGIS® è una piattaforma software riconosciuta a livello mondiale per i sistemi informativi geografici (GIS), che fornisce la creazione e la gestione di risorse digitali di energia elettrica, trasmissione del gas, distribuzione e reti di telecomunicazioni. ArcGIS consente di effettuare l'inventario più completo dei componenti della rete di distribuzione elettrica, tenendo conto della loro posizione spaziale. ArcGIS estende notevolmente l'architettura IBM SAFE fornendo gli strumenti, le applicazioni, i flussi di lavoro, l'analisi e le informazioni e le capacità di integrazione necessarie per gestire la smart grid. ArcGIS all'interno di IBM SAFE consente di ottenere informazioni da varie fonti su oggetti infrastrutturali, risorse, clienti e dipendenti con dati accurati sulla loro posizione, nonché creare, archiviare ed elaborare informazioni georeferenziate sulle risorse aziendali (pilastri, condutture, cavi, trasformatori, canaline portacavi, ecc.). ArcGIS all'interno di un'infrastruttura SAFE consente di connettere dinamicamente le applicazioni aziendali chiave combinando i dati provenienti da GIS, SCADA e sistemi di assistenza clienti con informazioni esterne come traffico, condizioni meteorologiche o immagini satellitari. Le utility utilizzano queste informazioni combinate per una varietà di scopi, da C.O.R. (quadro d'insieme dell'ambiente operativo) a sopralluoghi, manutenzione, analisi e pianificazione della rete.

I componenti informativi di un'azienda di alimentazione possono essere modellati utilizzando diversi livelli, che vanno dal livello più basso, fisico, al livello più alto e più complesso della logica dei processi aziendali. Questi livelli possono essere integrati per soddisfare i requisiti tipici del settore, come la registrazione automatizzata delle misurazioni e il controllo di supervisione e acquisizione dati (SCADA). Costruendo l'architettura SAFE, le società di servizi pubblici stanno facendo progressi significativi nel promuovere un modello a oggetti aperto a livello di settore chiamato Common Information Model (CIM) for Energy and Utilities. Questo modello fornisce la base necessaria per spostare molte aziende verso un'architettura orientata ai servizi, poiché incoraggia l'uso di standard aperti per la strutturazione di dati e oggetti. Facendo in modo che tutti i sistemi utilizzino gli stessi oggetti, la confusione e l'inelasticità associate a diverse implementazioni degli stessi oggetti saranno ridotte al minimo. Pertanto, la definizione dell'oggetto "cliente" e di altri importanti oggetti aziendali saranno unificati in tutti i sistemi dell'azienda fornitrice di energia. Con CIM, i fornitori di servizi e i consumatori di servizi possono ora condividere una struttura di dati comune, semplificando l'esternalizzazione di componenti aziendali costosi poiché CIM stabilisce una base comune su cui costruire la condivisione delle informazioni.

Conclusione

I modelli di dati di settore completi forniscono alle aziende una visione unica e integrata delle informazioni aziendali. Molte aziende hanno difficoltà a integrare i propri dati, sebbene questo sia un prerequisito per la maggior parte dei progetti a livello aziendale. Secondo uno studio del Data Warehousing Institute (TDWI), oltre il 69% delle organizzazioni intervistate ha riscontrato che l'integrazione rappresenta un ostacolo significativo all'adozione di nuove applicazioni. Al contrario, l'implementazione dell'integrazione dei dati porta all'azienda un reddito tangibile e una maggiore efficienza.

Un modello ben costruito definisce in modo univoco il significato dei dati, che in questo caso sono dati strutturati (al contrario di dati non strutturati come un'immagine, un file binario o un testo, dove il valore può essere ambiguo). I modelli di settore più efficaci sono offerti da fornitori professionali, tra cui Esri e IBM. Gli alti rendimenti derivanti dall'utilizzo dei loro modelli sono ottenuti grazie al loro livello significativo di dettaglio e accuratezza. Di solito contengono molti attributi di dati. Inoltre, gli esperti di Esri e IBM non solo hanno una vasta esperienza di modellazione, ma sono anche esperti nella creazione di modelli per un particolare settore.

Architettura del database

Lo schema CMD è una descrizione della struttura del modello dati dal punto di vista dell'amministratore.

Uno schema AMD è una descrizione di un modello interno o fisico. Memorizza una descrizione della posizione fisica dei dati sul supporto. Lo schema memorizza indicazioni dirette sulla posizione dei dati in memoria (volumi, dischi).

Lo schema CMD descrive la struttura di dati, record e campi.

Tutti i DBMS supportano tre tipi principali di modelli di dati:

1. Modello gerarchico. Presuppone una voce di root. I rami provengono dalle radici.

Non tutti gli oggetti sono convenientemente descritti in questo modo. Non ci sono connessioni nella gerarchia ed è caratteristica una grande ridondanza delle informazioni.

2. Modello di rete. Consente di visualizzare correttamente tutte le complessità delle relazioni.

Il modello è conveniente per rappresentare collegamenti con dati provenienti dall'ambiente esterno, ma meno conveniente per descrivere nel database, il che comporta un lavoro aggiuntivo per l'utente per studiare la navigazione attraverso i collegamenti.

3. Modello relazionale. Si basa sul termine matematico Relazione - una relazione, ma semplicemente - una tabella. Ad esempio, un rettangolare bidimensionale.

La struttura dei dati relazionali è stata sviluppata alla fine degli anni '60 da un certo numero di ricercatori, di cui il contributo più significativo è stato dato dal dipendente IBM Edgar Codd. Con l'approccio relazionale, i dati sono presentati sotto forma di tabelle bidimensionali, le più naturali per una persona. Allo stesso tempo, per l'elaborazione dei dati, Codd ha suggerito di utilizzare l'apparato della teoria degli insiemi: unione, intersezione, differenza, prodotto cartesiano.

Tipo di dati- questo concetto ha lo stesso significato dei linguaggi di programmazione (ovvero, il tipo di dati definisce la rappresentazione interna nella memoria del computer e il modo in cui viene archiviata l'istanza di dati, nonché l'insieme di valori che l'istanza di dati può assumere e l'insieme delle operazioni sui dati validi). Tutti i database moderni esistenti supportano tipi speciali di dati progettati per memorizzare dati di tipo intero, virgola mobile frazionaria, caratteri e stringhe, date di calendario. Molti server di database implementano altri tipi, ad esempio Interbase dispone di un tipo di dati speciale per l'archiviazione di grandi array di informazioni binarie (BLOB).

Dominioè un potenziale insieme di valori di un tipo di dati semplice, è simile a un sottotipo di dati in alcuni linguaggi di programmazione. Un dominio è definito da due elementi: un tipo di dati e un'espressione booleana che viene applicata ai dati. Se questa espressione restituisce true, l'istanza di dati appartiene al dominio.

Atteggiamentoè una tabella bidimensionale di tipo speciale, composta da un'intestazione e un corpo.

intestazioneè un insieme fisso di attributi, ognuno dei quali è definito su alcuni domini, e c'è una corrispondenza uno a uno tra attributi e domini di definizione.

Ogni attributo è definito sul proprio dominio. Il dominio è un tipo di dati intero e la condizione booleana è n>0. L'intestazione è senza tempo, a differenza del corpo di relazione. Corpo di relazione- è una collezione tuple, ognuno dei quali è una coppia attributo-valore.

Dal potere della relazioneè il numero delle sue tuple, e grado di atteggiamentoè il numero di attributi.

Il grado di un rapporto è un valore costante per un dato rapporto, mentre la potenza di un rapporto varia nel tempo. La potenza del rapporto è anche chiamata numero cardinale.

I concetti di cui sopra sono teorici e vengono utilizzati nello sviluppo di strumenti linguistici e sistemi software per DBMS relazionali. Nel lavoro quotidiano vengono invece utilizzati i loro equivalenti informali:

atteggiamento - tavolo;

attributo - colonna o campo;

tupla - record o riga.

Pertanto, il grado della relazione è il numero di colonne nella tabella e il numero cardinale è il numero di righe.

Poiché una relazione è un insieme, e nella teoria classica degli insiemi, per definizione, un insieme non può contenere elementi corrispondenti, una relazione non può avere due tuple identiche. Pertanto, per una data relazione, esiste sempre un insieme di attributi che identificano in modo univoco una tupla. Questo insieme di attributi viene chiamato chiave.

La chiave deve soddisfare i seguenti requisiti:

deve essere unico;

· deve essere minimo, ovvero la rimozione di qualsiasi attributo dalla chiave comporta una violazione dell'unicità.

Di norma, il numero di attributi in una chiave è inferiore al grado della relazione, tuttavia, in casi estremi, la chiave può contenere tutti gli attributi, poiché la combinazione di tutti gli attributi soddisfa la condizione di unicità. In genere, una relazione ha più chiavi. Di tutte le chiavi della relazione (dette anche "chiavi possibili"), una viene scelta come chiave primaria. Quando si sceglie chiave primaria la preferenza viene solitamente data alla chiave con il minor numero di attributi. È inoltre inappropriato utilizzare chiavi con valori di stringa lunghi.

In pratica, come chiave primaria viene spesso utilizzato uno speciale attributo numerico: uno zero autoincrementante, il cui valore può essere generato da un trigger (un trigger è una procedura speciale che viene chiamata quando vengono apportate modifiche al database) oppure con mezzi speciali definiti nel meccanismo DBMS.

I concetti descritti in questo capitolo non sono specifici di una particolare implementazione di database, ma sono comuni a tutti loro. Pertanto, questi concetti sono alla base di un certo modello generale, chiamato modello dei dati relazionali.

Il fondatore dell'approccio relazionale, Date, ha stabilito che il modello relazionale si compone di tre parti:

strutturale;

· manipolativo;

olistico.

Le relazioni sono fissate nella parte strutturale del modello come unica struttura dati utilizzata nel modello relazionale.

Nella parte relativa alla manipolazione, vengono fissati due meccanismi di base per la manipolazione dei database relazionali: l'algebra relazionale e il calcolo relazionale.

Per parte integrante si intende un certo meccanismo atto a garantire la non distruttibilità dei dati. La parte relativa all'integrità include due requisiti di integrità di base per i database relazionali: integrità dell'entità e integrità referenziale.

Requisiti integrità dell'entitàè che ogni tupla di qualsiasi relazione deve essere distinta da qualsiasi altra tupla di questa relazione, cioè, in altre parole, ogni relazione deve avere una chiave primaria. Questo requisito deve essere soddisfatto se sono soddisfatte le proprietà di base della relazione.

Nel linguaggio di manipolazione dei dati, così come nel linguaggio di interrogazione, viene eseguito un apparato matematico chiamato algebra delle relazioni, per il quale sono definite le seguenti azioni:

1. Operazioni standard: - intersezione, - unione, \ - differenza, X - prodotto cartesiano.

2. Specifico: proiezione, limitazione, connessione, divisione.

un. Un'associazione.

SD SHM EI HP

R 1 (codice pezzo, codice materiale, unità di misura, tasso di consumo)

R 2 (SHD, SHM, EI, HP)

Necessità di trovare

Dovrebbe unire gli insiemi R 1 e R 2 . In questa operazione si conserva il grado e la cardinalità dell'insieme risultante

B. intersezione.

Evidenzia le linee corrispondenti.

C. Differenza.

Escludere da R 1 tuple che corrispondono a R 2 .

D. Prodotto cartesiano.

Qui è dove vengono concatenate le tuple.

Ogni riga di un insieme è concatenata con ogni riga dell'altro.

Dati due insiemi:

Il prodotto cartesiano ha la seguente forma:

In questo caso, il grado S è, a, cioè ottieni 12 righe e 5 colonne.

Il database aziendale è il collegamento centrale del sistema informativo aziendale e consente di creare un unico spazio informativo aziendale. Banche dati aziendali

Condividi il lavoro sui social network

Se questo lavoro non ti soddisfa, c'è un elenco di lavori simili in fondo alla pagina. Puoi anche usare il pulsante di ricerca

TEMA V BANCHE DATI AZIENDALI

V .uno. Organizzazione dei dati nei sistemi aziendali. Banche dati aziendali.

V .2. DBMS e soluzioni strutturali nei sistemi aziendali.

V.3. Tecnologie Internet/Intranet e soluzioni di accesso ai database aziendali.

V .uno. L'ORGANIZZAZIONE DEI DATI NEI SISTEMI AZIENDALI. BANCHE DATI AZIENDALI

Base aziendale i dati sono il collegamento centrale del sistema informativo aziendale e consentono di creare un unico spazio informativo dell'azienda. Banche dati aziendali (Figura 1.1).

Esistono varie definizioni di database.

Sotto la banca dati (DB) comprendere un insieme di informazioni logicamente correlate in modo tale da costituire un unico insieme di dati archiviati nei dispositivi di archiviazione di un computer. Questo insieme funge da dati iniziali dei compiti risolti nel processo di funzionamento di sistemi di controllo automatizzati, sistemi di elaborazione dati, sistemi informatici e informatici.

È possibile formulare brevemente il termine database come una raccolta di dati logicamente correlati destinati alla condivisione.

Sotto banca dati si riferisce a una raccolta di dati archiviati insieme con una ridondanza minima tale da poter essere utilizzati in modo ottimale per una o più applicazioni.

Scopo della creazione di database come forma di archiviazione dei dati costruire un sistema di dati che non dipenda dagli algoritmi adottati (software), dai mezzi tecnici utilizzati, dalla collocazione fisica dei dati nel computer. Il database presuppone un uso multiuso (più utenti, molte forme di documenti e query di un utente).

Requisiti di base del database:

Completezza della presentazione dei dati. I dati nel database dovrebbero rappresentare adeguatamente tutte le informazioni sull'oggetto e dovrebbero essere sufficienti per ODS.
Integrità del database. I dati devono essere conservati durante il trattamento delle loro ODS e in tutte le situazioni che si presentano nel corso del lavoro.
Flessibilità della struttura dei dati. Il database dovrebbe consentire di modificare le strutture dei dati senza violarne l'integrità e la completezza quando cambiano le condizioni esterne.
Realizzabilità. Ciò significa che deve esserci una rappresentazione oggettiva dei vari oggetti, delle loro proprietà e relazioni.
Disponibilità. È necessario prevedere una differenziazione dell'accesso ai dati.
ridondanza. Il database dovrebbe avere una ridondanza minima nella rappresentazione dei dati su qualsiasi oggetto.

La conoscenza è compresa un insieme di fatti, schemi e regole euristiche con cui è possibile risolvere il problema.

Base di conoscenza (KB)  raccolta delle banche dati e delle regole utilizzate, ricevute dai decisori. La base di conoscenza è un elemento dei sistemi esperti.

dovrebbe essere distinto diverse modalità di presentazione dei dati.

Dati fisici - Si tratta di dati archiviati nella memoria del computer.

Rappresentazione logica dei dati corrisponde alla rappresentazione dei dati fisici da parte dell'utente. La differenza tra una rappresentazione fisica dei dati e una corrispondente logica è che quest'ultima riflette alcune importanti relazioni tra i dati fisici.

Sotto database aziendale comprendere un database che combina in una forma o nell'altra tutti i dati e le conoscenze necessarie su un'organizzazione automatizzata. Nei sistemi informativi aziendali, un concetto comebanche dati integrate, in cui si attua il principio dell'ingresso unico e dell'uso multiplo delle informazioni.

Riso. 1.1. La struttura dell'interazione dei dipartimenti con le risorse informative della società.

I database aziendali lo sono concentrato (centralizzato) e distribuito.

Database concentrato (centralizzato). è un database i cui dati sono archiviati fisicamente nei dispositivi di archiviazione di un computer. Sulla fig. 1.2 mostra un diagramma di un'applicazione server per l'accesso a database in varie piattaforme.

Fig.1.2. Schema di un eterogeneo banca dati centralizzata

La centralizzazione dell'elaborazione delle informazioni ha consentito di eliminare le carenze dei file system tradizionali come l'incoerenza, l'incoerenza e la ridondanza dei dati. Tuttavia, con la crescita dei database, e soprattutto se utilizzati in organizzazioni geograficamente disperse, sorgono problemi. Ad esempio, per database concentrati situati in un nodo di rete di telecomunicazioni, attraverso i quali vari dipartimenti di un'organizzazione accedono ai dati, con un aumento del volume di informazioni e del numero di transazioni, sorgono le seguenti difficoltà:

Ampio flusso di scambio dati;
Elevato traffico di rete;
Bassa affidabilità;
Prestazioni complessive basse.

Sebbene sia più facile garantire la sicurezza, l'integrità e la coerenza delle informazioni durante gli aggiornamenti in un database concentrato, questi problemi creano alcune difficoltà. Il decentramento dei dati si propone come una possibile soluzione a questi problemi. Il decentramento realizza:

Maggior grado di simultaneità di elaborazione grazie alla condivisione del carico;
Migliorare l'uso dei dati sul campo durante l'esecuzione di query remote (remote);
minori costi;
Database locali facili da gestire.

I costi di creazione di una rete con workstation (piccoli computer) ai suoi nodi sono molto inferiori ai costi di creazione di un sistema simile utilizzando un mainframe. La Figura 1.3 mostra un diagramma logico di un database distribuito.

Fig.1.3. Database aziendale distribuito.

Diamo la seguente definizione di database distribuito.

Database distribuito - si tratta di una raccolta di informazioni, file (relazioni) conservati in diversi nodi della rete informatica e logicamente collegati in modo da costituire un unico insieme di dati (il collegamento può essere funzionale o tramite copie dello stesso file). Pertanto, è un insieme di database logicamente interconnessi, ma fisicamente situati su più macchine che fanno parte della stessa rete di computer.

I requisiti più importanti per le caratteristiche di un database distribuito sono i seguenti:

scalabilità;
Compatibilità;
Supporto per vari modelli di dati;
portabilità;
Trasparenza della posizione;
Autonomia dei nodi di database distribuiti (Autonomia del sito);
Elaborazione delle richieste distribuite;
Esecuzione di transazioni distribuite.
Supporto per un sistema di sicurezza omogeneo.

La trasparenza della posizione consente agli utenti di lavorare con i database senza sapere nulla della loro posizione. L'autonomia dei nodi di database distribuiti significa che ogni database può essere mantenuto indipendentemente dagli altri. Una query distribuita è una query (istruzione SQL) durante la quale avviene l'accesso a oggetti (tabelle o viste) di database diversi. Quando si eseguono transazioni distribuite, viene esercitato il controllo della concorrenza su tutti i database coinvolti. Oracle7 utilizza la tecnologia di trasferimento delle informazioni in due fasi per eseguire transazioni distribuite.

Non è necessario che i database che compongono un database distribuito siano omogenei (ovvero eseguiti dallo stesso DBMS) o eseguiti sullo stesso ambiente del sistema operativo e/o sullo stesso tipo di computer. Ad esempio, un database potrebbe essere un database Oracle su un computer SUN che esegue SUN OS (UNIX), un secondo database potrebbe essere eseguito da un DBMS DB2 su un mainframe IBM 3090 che esegue un sistema operativo MVS e un terzo database potrebbe essere eseguito da un DBMS SQL/DS anche su mainframe IBM, ma con sistema operativo VM. Una sola condizione è obbligatoria: tutte le macchine con database devono essere accessibili tramite la rete di cui fanno parte.

Il compito principale di un database distribuito – distribuzione dei dati sulla rete e accesso ad essa. Ci sono i seguenti modi per risolvere questo problema:

Ciascun nodo archivia e utilizza il proprio set di dati disponibile per le query remote. Questa distribuzione è divisa.
Alcuni dati utilizzati di frequente nei siti remoti potrebbero essere duplicati. Tale distribuzione è chiamata parzialmente duplicata.
Tutti i dati vengono duplicati in ogni nodo. Tale distribuzione è chiamata completamente ridondante.
Alcuni file possono essere divisi orizzontalmente (è selezionato un sottoinsieme di record) o verticalmente (è selezionato un sottoinsieme di campi di attributo), mentre i sottoinsiemi divisi sono archiviati in nodi diversi insieme a dati non suddivisi. Tale distribuzione è chiamata divisa (frammentata).

Quando si crea un database distribuito a livello concettuale, è necessario risolvere le seguenti attività:

È necessario disporre di un unico schema concettuale per l'intera rete. Ciò fornirà all'utente una trasparenza logica dei dati, in conseguenza della quale sarà in grado di formulare una richiesta all'intero database, trovandosi su un terminale separato (funziona, per così dire, con un database centralizzato).
È necessario uno schema per individuare i dati sulla rete. Ciò garantirà trasparenza nel posizionamento dei dati in modo che l'utente non debba specificare dove inoltrare la richiesta per ottenere i dati richiesti.
È necessario risolvere il problema dell'eterogeneità dei database distribuiti. I database distribuiti possono essere omogenei o eterogenei in termini di hardware e software. Il problema dell'eterogeneità è relativamente facile da risolvere se il database distribuito è eterogeneo in termini di hardware, ma omogeneo in termini di software (lo stesso DBMS nei nodi). Se vengono utilizzati DBMS diversi nei nodi di un sistema distribuito, sono necessari mezzi per convertire strutture dati e linguaggi. Ciò dovrebbe fornire trasparenza della trasformazione nei nodi del database distribuito.
È necessario risolvere il problema della gestione dei dizionari. Per fornire ogni tipo di trasparenza in un database distribuito, sono necessari programmi che gestiscono numerosi dizionari e libri di consultazione.
È necessario definire i metodi per eseguire le query in un database distribuito. I metodi per eseguire le query in un database distribuito differiscono dai metodi simili nei database centralizzati, poiché le singole parti delle query devono essere eseguite nella posizione dei dati corrispondenti e trasferire i risultati parziali ad altri nodi; allo stesso tempo dovrebbe essere assicurato il coordinamento di tutti i processi.
È necessario risolvere il problema dell'esecuzione parallela delle query. In un database distribuito è necessario un meccanismo complesso per la gestione dell'elaborazione simultanea, che, in particolare, deve garantire la sincronizzazione quando le informazioni vengono aggiornate, garantendo la coerenza dei dati.
La necessità di una metodologia sviluppata per la distribuzione e il posizionamento dei dati, inclusa la suddivisione, è uno dei requisiti principali per un database distribuito.

Una delle nuove aree in via di sviluppo attivo dell'architettura dei sistemi informatici, che è un potente strumento per l'elaborazione di informazioni non numeriche, è macchine di database. Le macchine di database vengono utilizzate per risolvere compiti non numerici, come archiviare, cercare e trasformare documenti e fatti, lavorare con oggetti. Seguendo la definizione dei dati come informazioni digitali e grafiche sugli oggetti del mondo circostante, diversi contenuti sono incorporati nel concetto di dati nell'elaborazione numerica e non numerica. L'elaborazione numerica utilizza oggetti come variabili, vettori, matrici, array multidimensionali, costanti e così via, mentre l'elaborazione non numerica utilizza oggetti come file, record, campi, gerarchie, reti, relazioni e così via. l'elaborazione numerica riguarda direttamente le informazioni sugli oggetti (ad esempio, un determinato dipendente o gruppo di dipendenti) e non il file del dipendente stesso. Non indicizza il file del dipendente per selezionare una determinata persona; qui più interessati al contenuto del record desiderato. Enormi volumi di informazioni sono generalmente soggetti a elaborazioni non numeriche. In varie applicazioni, tali operazioni possono essere eseguite su questi dati, ad esempio:

aumentare lo stipendio di tutti i dipendenti dell'azienda;
calcolare gli interessi bancari sui conti di tutti i clienti;
apportare modifiche all'elenco di tutte le merci in magazzino;
trovare l'abstract richiesto da tutti i testi conservati in biblioteca o nel sistema di reperimento delle informazioni bibliografiche;
trovare la descrizione del contratto desiderato in un file contenente gli atti legali;
visualizzare tutti i file contenenti le descrizioni dei brevetti e trovare un brevetto (se presente) simile a quello riproposto.

Per implementare il motore di database, parallelo e associativo architetture in alternativa al monoprocessorevon Neumannstruttura, che consente di lavorare con grandi quantità di informazioni in tempo reale.

I motori di database stanno acquisendo importanza in connessione con l'esplorazione e l'applicazione di concetti di intelligenza artificiale come la rappresentazione della conoscenza, i sistemi esperti, l'inferenza, il riconoscimento di schemi, ecc.

Archivi di informazioni. Oggi molti riconoscono che la maggior parte delle aziende gestisce già diversi database e, per lavorare con successo con le informazioni, non sono necessari solo diversi tipi di database, ma diverse generazioni di DBMS. Secondo le statistiche, ogni organizzazione utilizza in media 2,5 diversi DBMS. È diventata evidente la necessità di "isolare" il business delle aziende, o meglio, le persone coinvolte in questo business, dalle caratteristiche tecnologiche delle banche dati, per fornire agli utenti una visione unica delle informazioni aziendali, indipendentemente da dove siano fisicamente archiviate . Ciò ha stimolato l'emergere della tecnologia di immagazzinamento delle informazioni ( Data Warehouse, DW).

L'obiettivo principale di DW è creazione di un'unica rappresentazione logica dei dati contenuti in diverse tipologie di database, ovvero un unico modello di dati aziendali.

Un nuovo ciclo di sviluppo di DW è diventato possibile grazie al miglioramento della tecnologia dell'informazione in generale, in particolare all'emergere di nuovi tipi di database basati sull'elaborazione di query parallele, che a loro volta si basavano sui progressi nel campo dei computer paralleli. Sono stati creati costruttori di querycon un'interfaccia grafica intuitiva che ha semplificato la creazione di complesse query di database. Software varimiddlewarecomunicazione fornitatra diversi tipi di database, e alla fine è diminuito drasticamente di prezzodispositivi di memorizzazione delle informazioni.

Una banca dati può essere presente nella struttura di una società.

Banca dati - componente funzionale e organizzativa nei sistemi di controllo automatizzati e nei sistemi informatici e informatici, che fornisce supporto informativo centralizzato per un gruppo di utenti o un insieme di compiti risolti nel sistema.

Banca dati è considerato un sistema informativo e di riferimento, il cui scopo principale è:

nell'accumulo e nel mantenimento in condizioni di lavoro di un insieme di informazioni costituenti la base informativa dell'intero sistema automatizzato o di un determinato insieme di compiti in esso risolti;
nel rilascio dei dati richiesti dall'incarico o dall'utente;
nel fornire accesso collettivo alle informazioni archiviate;
nel garantire la necessaria gestione dell'utilizzo delle informazioni contenute nell'infobase.

Pertanto, una moderna banca dati è un complesso software e hardware complesso, che include strumenti tecnici, di sistema e di rete, database e DBMS, sistemi di recupero delle informazioni per vari scopi.

V .2. DBMS E SOLUZIONI STRUTTURALI NEI SISTEMI AZIENDALI

Database e sistemi di gestione della conoscenza

Una componente importante dei moderni sistemi informativi sono i sistemi di gestione di database (DBMS).

DBMS - un insieme di strumenti software e linguistici progettati per creare, mantenere e utilizzare database.

Il sistema di gestione dei database fornisce ai sistemi di elaborazione dati l'accesso ai database. Come già notato, un ruolo importante del DBMS viene acquisito nella realizzazione dei sistemi informativi aziendali e un ruolo particolarmente importante nella realizzazione di sistemi informativi che utilizzano risorse informative distribuite basate sulle moderne tecnologie informatiche di rete.

La caratteristica principale dei moderni DBMS è che i moderni DBMS supportano tecnologie come:

tecnologia client/server.
Supporto per le lingue del database. Questolinguaggio di definizione dello schema DB (SDL - Linguaggio di definizione degli schemi),linguaggio di manipolazione dei dati (DML - Data Manipulation Language), linguaggi integrati SQL (Structured Queue Language), QDB (Query - Per - Esempio) e QMF (Query Management Facility ) è uno strumento periferico avanzato per la specifica di query e la generazione di report DB 2 ecc.;
Gestione diretta dei dati nella memoria esterna.
Gestione del buffer di memoria.
Gestione delle transazioni. Tecnologia OLTP (Elaborazione delle transazioni in linea), OLAP - tecnologia (Elaborazione di analisi in linea) per DW.
Garantire la protezione e l'integrità dei dati. L'uso del sistema è consentito solo agli utenti che hanno il diritto di accedere ai dati. Quando gli utenti eseguono operazioni sui dati, viene mantenuta la coerenza dei dati archiviati (integrità). Questo è importante nei sistemi informativi multiutente aziendali.
Giornalismo.

I DBMS moderni devono soddisfare i requisiti del database sopra elencati. Inoltre, devono rispettare i seguenti principi:

Indipendenza dei dati.
Versatilità. Il DBMS deve disporre di un potente supporto per il modello di dati concettuali per visualizzare viste logiche personalizzate.
Compatibilità. Il DBMS deve rimanere operativo con lo sviluppo di software e hardware.
Ridondanza dei dati. A differenza dei file system, un database deve essere un unico insieme di dati integrati.
Protezione dati. Il DBMS deve fornire protezione contro l'accesso non autorizzato.
Integrità dei dati. Il DBMS deve impedire agli utenti di manomettere il database.
Gestione del lavoro simultaneo. Il DBMS deve proteggere il database dalle incongruenze nella modalità di accesso condiviso. Per garantire uno stato coerente del database, tutte le richieste degli utenti (transazioni) devono essere eseguite in un determinato ordine.
Il DBMS deve essere universale. Dovrebbe supportare diversi modelli di dati su un'unica base logica e fisica.
Il DBMS dovrebbe supportare database sia centralizzati che distribuiti e diventare così un collegamento importante nelle reti di computer.

Considerando un DBMS come una classe di prodotti software focalizzati sulla manutenzione di database in sistemi automatizzati, possiamo distinguere due delle caratteristiche più significative che determinano i tipi di DBMS. Secondo loro, il DBMS può essere considerato da due punti di vista:

le loro capacità in relazione ai database distribuiti (aziendali);
la loro relazione con il tipo di modello di dati implementato nel DBMS.

In relazione ai database aziendali (distribuiti), si possono convenzionalmente distinguere le seguenti tipologie di DBMS:

DBMS "desktop". Questi prodotti si concentrano principalmente sul lavoro con i dati personali (dati desktop). Hanno set di comandi per la condivisione di database comuni, ma sono di piccole dimensioni (tipo piccolo ufficio). Innanzitutto è un DBMS come Access, dBASE, Paradox, ExPro. Perché Access, dBASE, Paradox, ExPro hanno scarso accesso ai dati aziendali. Il fatto è che non esiste un modo semplice per superare la barriera tra dati personali e dati aziendali. E il punto non è nemmeno che il meccanismo di un DBMS di dati personali (o di un piccolo ufficio) sia focalizzato sull'accesso ai dati attraverso molti gateway, prodotti gateway, ecc. Il problema è che questi meccanismi in genere implicano trasferimenti di file completi e la mancanza di un ampio supporto per gli indici, con conseguenti code al server che sono praticamente un arresto nei sistemi di grandi dimensioni.
DBMS multiutente specializzato ad alte prestazioni. Tali DBMS sono caratterizzati dalla presenza di un kernel di sistema multiutente, un linguaggio di manipolazione dei dati e le seguenti funzioni tipiche dei DBMS multiutente sviluppati:
organizzare un buffer pool;
la presenza di un sistema per l'elaborazione delle code di transazione;
la presenza di meccanismi per il blocco dei dati multiutente;
registrazione delle transazioni;
disponibilità di meccanismi di controllo degli accessi.

Si tratta di DBMS come Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium e altri che forniscono un ampio servizio per l'elaborazione di database aziendali.

Quando si lavora con i database, viene utilizzato il meccanismo delle transazioni.

transazione è un'unità logica di lavoro.

transazione è una sequenza di istruzioni di manipolazione dei dati che viene eseguitacome una(tutto o niente) e database di traduzioneda uno stato integrale ad un altro stato integrale.

Una transazione ha quattro proprietà importanti, note come proprietà ASID:

(A) Atomicità . La transazione viene eseguita come operazione atomica: viene eseguita l'intera transazione oppure non viene eseguita l'intera transazione.
(C) Coerenza. Una transazione sposta un database da uno stato coerente (coerente) a un altro stato coerente (coerente). All'interno di una transazione, la coerenza del database può essere interrotta.
(I) Isolamento . Le transazioni di utenti diversi non devono interferire tra loro (ad esempio, come se fossero eseguite rigorosamente a loro volta).
(D) Durabilità. Se la transazione viene completata, i risultati del suo lavoro dovrebbero essere salvati nel database, anche se il sistema si arresta in modo anomalo al momento successivo.

La transazione di solito inizia automaticamente dal momento in cui l'utente si unisce al DBMS e continua fino a quando si verifica uno dei seguenti eventi:

È stato emesso un comando COMMIT WORK (per eseguire una transazione).
Comando ROLLBACK WORK emesso.
L'utente si è disconnesso dal DBMS.
C'è stato un guasto del sistema.

Per l'utente, indossa di solito carattere atomico. Si tratta infatti di un complesso meccanismo di interazione tra l'utente (applicazione) e il database. Il software dei sistemi aziendali utilizza un motore di elaborazione delle transazioni in tempo reale (Sistemi di elaborazione delle transazioni online, OLTP), in particolare programmi di contabilità, software per la ricezione e l'elaborazione delle domande dei clienti, applicazioni finanziarie, producono molte informazioni. Questi sistemi sono progettati (e opportunamente ottimizzati) per l'elaborazione di grandi quantità di dati, transazioni complesse e operazioni di lettura/scrittura intensive.

Sfortunatamente, le informazioni inserite nei database dei sistemi OLTP non sono molto adatte all'uso da parte degli utenti ordinari (a causa dell'alto grado di normalizzazione delle tabelle, dei formati specifici di presentazione dei dati e di altri fattori). Pertanto, i dati provenienti da diverse pipeline di informazioni vengono inviati (nel senso di essere copiati) a magazzino di stoccaggio, smistamento e successiva consegna al consumatore. Nella tecnologia dell'informazione, il ruolo dei magazzini è giocato daarchivi di informazioni.

Fornitura di informazioni all'utente finale - sono coinvolti sistemi di elaborazione dei dati analitici in tempo reale (Elaborazione analitica in linea, OLAP), che forniscono un accesso estremamente facile ai dati attraverso utili strumenti per la generazione di query e l'analisi dei risultati. Nei sistemi OLAP, il valore di un prodotto informativo viene accresciuto attraverso l'uso di vari metodi di analisi ed elaborazione statistica. Inoltre, questi sistemi sono ottimizzati in termini di velocità di estrazione dei dati, raccolta di informazioni generalizzate e sono focalizzati sull'utente ordinario (hanno un'interfaccia intuitiva). Se Sistema OLTP fornisce risposte a semplici domande come "qual è stato il livello di vendita del prodotto N nella regione M a gennaio 199x?", quindi Sistemi OLAP sono pronti per le richieste degli utenti più complesse, ad esempio: "Fare un'analisi delle vendite del prodotto N per tutte le regioni secondo il piano per il secondo trimestre rispetto ai due anni precedenti".

Architettura client/server

Nei sistemi moderni elaborazione delle informazioni distribuitela tecnologia è al centro della scena client/server. Nel sistema architetture client-serverl'elaborazione dei dati è suddivisa tra un computer client e un computer server, la cui comunicazione avviene su una rete. Questa separazione dei processi di elaborazione dei dati si basa sul raggruppamento di funzioni. In genere, un computer server di database è dedicato all'esecuzione di operazioni di database, mentre un computer client esegue programmi applicativi. La Figura 2.1 mostra un semplice sistema di architettura client-server che include un computer che funge da server e un altro computer che funge da client. Ogni macchina svolge funzioni diverse e dispone delle proprie risorse.

		Banca dati
Computer server
Rete
PC compatibile IBM	PC compatibile IBM	PC compatibile IBM
		Applicazioni

Riso. 2.1. Sistema di architettura client-server

La funzione principale del computer client è eseguire l'applicazione (interfaccia utente e logica di presentazione) e comunicare con il server quando richiesto dall'applicazione.

server - Questo è un oggetto (computer) che fornisce servizi ad altri oggetti su loro richiesta.

Come suggerisce il termine, la funzione principale del computer server è quella di soddisfare le esigenze del cliente. Il termine "Server" è usato per riferirsi a due diversi gruppi di funzioni: un file server e un database server (di seguito, questi termini significano, a seconda del contesto, o il software che implementa questi gruppi di funzioni, oppure i computer con questo software ). I file server non sono progettati per eseguire operazioni di database, la loro funzione principale è condividere file tra più utenti, ad es. fornendo l'accesso simultaneo di molti utenti ai file su un computer: un file server. Un esempio di file server è il sistema operativo NetWare di Novell. Il server di database può essere installato ed eseguito su un computer file server. Oracle DBMS sotto forma di NLM (Network Loadable Module) viene eseguito in un ambiente NetWare su un file server.

Il server di rete locale deve disporre di risorse che corrispondano al suo scopo funzionale e alle esigenze della rete. Si noti che a causa dell'orientamento verso l'approccio dei sistemi aperti, è più corretto parlare di server logici (ovvero un insieme di risorse e strumenti software che forniscono servizi su queste risorse), che non si trovano necessariamente su computer diversi. Una caratteristica di un server logico in un sistema aperto è che se, per ragioni di efficienza, è opportuno spostare il server su un computer separato, questo può essere fatto senza bisogno di alcuna modifica, sia di se stesso che dell'applicazione programmi che lo utilizzano.

Uno dei requisiti importanti del server è che il sistema operativo in cui è ospitato il server di database deve essere multitasking (e preferibilmente, ma non necessariamente, multiutente). Ad esempio, il DBMS Oracle installato su un personal computer con un sistema operativo MS-DOS (o PC-DOS) che non soddisfa i requisiti per il multitasking non può essere utilizzato come server di database. E lo stesso DBMS Oracle installato su un computer con un sistema operativo OS / 2 multitasking (sebbene non multiutente) può essere un server di database. Molte varietà di UNIX, MVS, VM e alcuni altri sistemi operativi sono sia multitasking che multiutente.

Calcolo distribuito

Il termine "informatica distribuita" è spesso usato per riferirsi a due concetti diversi, seppur complementari:

Banca dati distribuita;
Elaborazione dati distribuiti.

L'applicazione di questi concetti consente di organizzare l'accesso alle informazioni memorizzate su più macchine per gli utenti finali con vari mezzi.

Esistono molti tipi di server:

Server di database;
server di stampa;
Server di accesso remoto;
Fax server;
Server web, ecc.

Al centro della tecnologia Client/Server Esistono tecnologie di base come:

Tecnologie dei sistemi operativi, concetto di interazione di sistemi aperti, creazione di ambienti orientati agli oggetti per il funzionamento dei programmi;
Tecnologie delle telecomunicazioni;
Tecnologie di rete;
Tecnologie di interfaccia utente grafica ( GUI);
Eccetera.

Vantaggi della tecnologia client-server:

La tecnologia client/server consente il calcolo su ambienti informatici eterogenei. Indipendenza dalla piattaforma: accesso ad ambienti di rete eterogenei, che includono diversi tipi di computer con diversi sistemi operativi.
Indipendenza dalle fonti dei dati: accesso alle informazioni da banche dati eterogenee. Esempi di tali sistemi sono DB2, SQL/DS, Oracle, Sybase.
Bilanciamento del carico tra client e server.
Esecuzione di calcoli dove avviene in modo più efficiente;
Fornisce capacità di ridimensionamento efficiente;
Calcolo multipiattaforma. L'elaborazione multipiattaforma è definita semplicemente come l'implementazione di tecnologie in ambienti informatici eterogenei. Le seguenti opzioni dovrebbero essere fornite qui:
L'applicazione deve essere eseguita su più piattaforme;
Su tutte le piattaforme dovrebbe avere la stessa interfaccia e logica di lavoro;
L'applicazione deve integrarsi con l'ambiente operativo nativo;
Dovrebbe comportarsi allo stesso modo su tutte le piattaforme;
Dovrebbe avere un supporto semplice e coerente.

 Calcolo distribuito. Il calcolo distribuito implica la distribuzione del lavoro tra diversi computer (sebbene il calcolo distribuito sia un concetto più ampio).

 Ridimensionamento. Il downscaling è il trasferimento di applicazioni mainframe su piattaforme di computer di piccole dimensioni.

Riduci i costi dell'infrastruttura e dell'hardware. Conveniente: la disponibilità di hardware di elaborazione a basso costo e la crescente prevalenza di reti locali rendono la tecnologia client-server più conveniente rispetto ad altre tecnologie di elaborazione dati. L'attrezzatura può essere aggiornata secondo necessità.

 Ridurre il tempo complessivo di esecuzione dell'applicazione;

 Utilizzo ridotto della memoria del client;

 Riduzione del traffico di rete.

Capacità di lavorare con la multimedialità: ad oggi sono stati creati molti programmi per lavorare con la multimedialità per PC. Non esistono programmi di questo tipo per la configurazione dell'host terminale o sono molto costosi.
La possibilità di utilizzare più risorse di elaborazione per le operazioni di database: poiché le applicazioni vengono eseguite sui computer client, sul computer server vengono liberate risorse aggiuntive (rispetto alla configurazione terminal-host) per le operazioni di database, come CPU e risorse operative.
Aumento della produttività dei programmatori: la produttività dei programmatori viene aumentata utilizzando strumenti come SQL*Forms e CASE per sviluppare applicazioni più velocemente dei linguaggi di programmazione come C, PL1 o COBOL.
Aumento della produttività degli utenti finali: al giorno d'oggi, molti utenti finali hanno adottato sistemi come Lotus, Paradox, Word Perfect, Harvard Graphics, ecc.

L'interfaccia di back-end è definita e fissata. Pertanto, è possibile creare nuove parti client di un sistema esistente (un esempio di interoperabilità a livello di sistema).

Riso. 2.2. Un'illustrazione dell'accesso client a una condivisione server.

Come implementare la tecnologia client-server

Di seguito viene discussa l'installazione di un sistema basato su tecnologia client-server e in grado di elaborare dati distribuiti. Sono necessari i seguenti hardware e software per computer:

computer server di database;
computer client;
rete di comunicazione;
software di rete;
software applicativo.

Linguaggio SQL . Linguaggio di query di alto livello - SQL (linguaggio di query strutturato ) viene utilizzato per implementare query su database, come NMD, NDL e PJD, ed è stato adottato come standard. Lingua SQL è stato originariamente adottato come linguaggio dati dei prodotti software dell'azienda IBM e YMD di un DBMS relazionale SISTEMA R di IBM . Una caratteristica importante della lingua SQL è che lo stesso linguaggio è rappresentato attraverso due diverse interfacce, ovvero: tramite un'interfaccia interattiva e tramite un'interfaccia di programmazione applicativa (dynamic SQL). SQL dinamico è costituito da molte funzionalità linguistiche integrate SQL , fornito specificamente per la costruzione di applicazioni interattive, dove un'applicazione interattiva è un programma scritto per supportare l'accesso al database da parte dell'utente finale in esecuzione sul terminale interattivo. Lingua SQL fornisce le funzioni di definizione, manipolazione e gestione dei dati del database ed è trasparente per l'utente dal punto di vista del DBMS implementato.

Riso. 2.3. Schema per l'esecuzione delle richieste degli utenti su database distribuiti.

La struttura interna delle banche dati è determinata dai modelli di dati utilizzati. Il modello concettuale ha più capacità di astrazione e una semantica più ricca rispetto ai modelli esterni. I modelli esterni sono spesso chiamati modelli sintattici o operativi, riferendosi alla natura sintattica della gestione e dell'applicazione come mezzo di interazione dell'utente con il database. Nella modellazione dell'informazione, ci sono vari livelli di astrazione, dal livello del modello concettuale al livello del modello fisico dei dati, che influenzano l'architettura del DBMS.

Il modello dati è composto da tre componenti:

Una struttura di dati da rappresentare dal punto di vista dell'utente sul database.
Operazioni valide da eseguire sulla struttura dati. È necessario essere in grado di lavorare con questa struttura utilizzando varie operazioni DDL e NML. Una struttura ricca non ha valore se non puoi manipolarne il contenuto.
Vincoli per il controllo dell'integrità. Il modello di dati deve essere dotato di mezzi per preservarne l'integrità e proteggerlo. A titolo di esempio, consideriamo i seguenti due vincoli:
Ogni sottoalbero deve avere un nodo di origine. I database gerarchici non possono archiviare nodi figlio senza un nodo padre.
In relazione a un database relazionale, non possono esserci tuple identiche. Per un file, questo requisito richiede che tutti i record siano univoci.

Una delle caratteristiche più importanti del DBMS è la capacità di collegare oggetti.

Esistono i seguenti tipi di collegamenti tra gli oggetti:

Uno a uno (1:1). Un oggetto di un set può essere associato a un oggetto di un altro set.
Uno a molti (1:M). Un oggetto di un insieme può essere correlato a molti oggetti di un altro insieme.
Molti a molti (M:N). Un oggetto di un insieme può essere associato a molti oggetti di un altro insieme, ma allo stesso tempo un oggetto di un altro insieme può essere associato a molti oggetti del primo insieme.
ramificato . Un oggetto di un insieme può essere associato a oggetti di più insiemi.
Ricorsivo . Un oggetto di un dato insieme può essere associato a un oggetto dello stesso insieme.

Esistono i seguenti modelli di dati principali:

Modello di dati relazionali.
Modello di dati gerarchico.
Modello di dati di rete incompleto.
Modello dati CODASYL.
Modello di dati di rete esteso.

V.3. TECNOLOGIE INTERNET / INTRANET E SOLUZIONI DI ACCESSO AL DATABASE AZIENDALE

Il problema principale dei sistemi basati sull'architettura "client-server" è che, secondo il concetto di sistemi aperti, devono essere mobili nella più ampia classe possibile di soluzioni hardware e software di sistemi aperti. Anche se ci limitiamo alle reti locali basate su UNIX, reti diverse utilizzano apparecchiature e protocolli di comunicazione diversi. Il tentativo di creare sistemi che supportino tutti i possibili protocolli porta al loro sovraccarico di dettagli di rete a scapito della funzionalità.

Un aspetto ancora più complesso di questo problema è legato alla possibilità di utilizzare diverse rappresentazioni di dati in diversi nodi di una rete locale eterogenea. Computer diversi possono avere indirizzi, rappresentazioni di numeri, codifica dei caratteri diversi, ecc. Ciò è particolarmente importante per i server di alto livello: telecomunicazioni, informatica, database.

Una soluzione comune al problema della mobilità dei sistemi basati sull'architettura "client-server" è quella di affidarsi a pacchetti software che implementano protocolli di chiamata di procedura remota (RPC - Remote Procedure Call). Utilizzando questi strumenti, chiamare un servizio sull'host remoto appare come una normale chiamata di procedura. Gli strumenti RPC, che, ovviamente, contengono tutte le informazioni sulle specifiche delle apparecchiature di rete locali e sui protocolli di rete, traducono la chiamata in una sequenza di interazioni di rete. Pertanto, le specifiche dell'ambiente di rete e dei protocolli sono nascoste al programmatore dell'applicazione.

Quando viene chiamata una procedura remota, i programmi RPC convertono i formati di dati del client in formati intermedi indipendenti dalla macchina e quindi convertono in formati di dati del server. Quando si passano i parametri di risposta, vengono eseguite trasformazioni simili.

Altri lavori correlati che potrebbero interessarti.vshm>
6914.		Concetto di database	11,56 KB
	Il database è un insieme di materiali indipendenti presentati in una forma oggettiva di articoli di calcolo di atti normativi di decisioni giudiziarie e altri materiali simili sistematizzati in modo tale che questi materiali possano essere trovati ed elaborati utilizzando un computer elettronico Codice civile della Federazione Russa Arte. Un database organizzato secondo determinate regole e mantenuto nella memoria del computer, un insieme di dati che caratterizza lo stato attuale di alcuni ...
8064.		Banche dati distribuite	43,66 KB
	Database distribuiti Un database RDB distribuito è un insieme di dati condivisi logicamente interconnessi che sono fisicamente distribuiti su diversi nodi di una rete di computer. L'accesso ai dati non dovrebbe dipendere dalla presenza o dall'assenza di repliche di dati. Il sistema dovrebbe determinare automaticamente i metodi per eseguire un join di dati, un collegamento di rete in grado di gestire la quantità di informazioni trasferite e un nodo con potenza di elaborazione sufficiente per unire le tabelle. L'RDBMS deve essere in grado di...
20319.		BANCHE DATI E LORO PROTEZIONE	102,86 KB
	I database online online sono apparsi a metà degli anni '60. Le operazioni sulle banche dati operative sono state elaborate in modo interattivo tramite terminali. La semplice organizzazione di record sequenziale dell'indice si è rapidamente evoluta in un modello di record orientato ai set più potente. Charles Bachmann ha ricevuto il Premio Turing per aver guidato il lavoro del Data Base Task Group (DBTG), che ha sviluppato un linguaggio standard per la descrizione e la manipolazione dei dati.
5031.		Libreria di sviluppo database	11,72 MB
	Tecnologia di progettazione di database. Definizione delle relazioni tra entità e creazione di un modello dati. Le idee principali della moderna tecnologia dell'informazione si basano sul concetto che i dati dovrebbero essere organizzati in database per riflettere adeguatamente il mondo reale in evoluzione e soddisfare le esigenze di informazione degli utenti. Questi database sono creati e gestiti sotto il controllo di speciali sistemi software chiamati sistemi di gestione di database DBMS.
13815.		MODELLO DI DATABASE GERARCHICO	81,62 KB
	Le idee principali della moderna tecnologia dell'informazione si basano sul concetto di database, secondo il quale la base dell'informatica sono i dati organizzati in database che riflettono adeguatamente lo stato di una particolare area disciplinare e forniscono all'utente informazioni rilevanti in tale area disciplinare. Si precisa che i dati sono...
14095.		Sviluppo database di biblioteche	11,72 MB
	L'aumento del volume e della complessità strutturale dei dati archiviati, l'allargamento della cerchia degli utenti dei sistemi informativi hanno portato all'uso diffuso dei DBMS relazionali (tabulari) più convenienti e di relativamente facile comprensione.
5061.		Creazione di una banca dati del policlinico	2,4 MB
	Lo sviluppo della tecnologia informatica e della tecnologia dell'informazione ha fornito opportunità per la creazione e l'uso diffuso di sistemi informatici automatizzati (AIS) per vari scopi. Si stanno sviluppando e implementando sistemi informativi per la gestione delle strutture economiche e tecniche
13542.		Banche dati di informazioni geologiche	20,73 KB
	Di recente, l'introduzione delle tecnologie informatiche e, in particolare, delle banche dati, nell'ambito scientifico è avvenuta a ritmi sostenuti. Questo processo non aggira nemmeno la geologia, poiché è nelle scienze naturali che è necessario archiviare ed elaborare grandi quantità di informazioni.
9100.		Banca dati. Concetti basilari	26,28 KB
	Un database è una raccolta di informazioni su oggetti specifici del mondo reale in qualsiasi area disciplinare, economia, management, chimica, ecc. Lo scopo di un sistema informativo non è solo archiviare dati su oggetti, ma anche manipolare questi dati, prendendo tenere conto delle relazioni tra gli oggetti. Ogni oggetto è caratterizzato da un insieme di proprietà dei dati, che nel database vengono chiamate attributi.
5240.		Creazione della banca dati "Presidenza dell'Università"	1,57 MB
	Un database (DB) è una raccolta di dati interconnessi archiviati insieme su un supporto di archiviazione esterno di un computer con un'organizzazione e una ridondanza minima tale da consentirne l'utilizzo in modo ottimale per una o più applicazioni.

Modelli di dati di settore

Lo scopo principale dei modelli è facilitare l'orientamento nello spazio dei dati e aiutare a evidenziare i dettagli importanti per lo sviluppo del business. Nell'ambiente aziendale odierno, è assolutamente essenziale avere una chiara comprensione delle relazioni tra le varie componenti e una buona comprensione del quadro generale dell'organizzazione. L'identificazione di tutti i dettagli e delle relazioni tramite modelli consente di utilizzare nel modo più efficiente tempo e strumenti per organizzare il lavoro dell'azienda.

Il modello di dati definisce in modo univoco il significato dei dati, che in questo caso sono dati strutturati (al contrario di dati non strutturati come un'immagine, un file binario o un testo, in cui il valore può essere ambiguo).

Di norma si distinguono modelli di livello superiore (e più generali nei contenuti) e di livello inferiore (rispettivamente più dettagliati). Il livello superiore di modellazione è il cosiddetto modelli di dati concettuali(modelli di dati concettuali), che forniscono il quadro più generale del funzionamento di un'impresa o di un'organizzazione. Il modello concettuale comprende i concetti principali o le aree tematiche critiche per il funzionamento dell'organizzazione; di solito il loro numero non supera 12-15. Tale modello descrive classi di entità importanti per l'organizzazione (oggetti aziendali), le loro caratteristiche (attributi) e le associazioni tra coppie di queste classi (es. relazioni). Poiché la terminologia nella modellazione aziendale non è stata ancora completamente risolta, in varie fonti in lingua inglese, i modelli di dati concettuali possono anche essere chiamati modello di area tematica (che può essere tradotto come modelli di area tematica) o modello di dati aziendali soggetto (modelli di dati aziendali soggetti ).

Il livello gerarchico successivo è modelli di dati logici(modelli di dati logici). Possono anche essere indicati come modelli di dati aziendali o modelli di business. Questi modelli contengono strutture di dati, i relativi attributi e regole di business e rappresentano le informazioni utilizzate da un'impresa dal punto di vista aziendale. In un tale modello, i dati sono organizzati sotto forma di entità e relazioni tra di loro. Il modello logico rappresenta i dati in un modo facilmente comprensibile per gli utenti aziendali. In un modello logico, è possibile allocare un dizionario di dati, un elenco di tutte le entità con le loro esatte definizioni, che consente a diverse categorie di utenti di avere una comprensione comune di tutti i flussi di input e di output delle informazioni del modello. Il livello successivo di modellazione è già l'implementazione fisica del modello logico utilizzando strumenti software e piattaforme tecniche specifici.

Il modello logico contiene la decisione aziendale dettagliata, che di solito assume la forma di un modello normalizzato. La normalizzazione è il processo che garantisce che ogni elemento di dati nel modello abbia un solo valore e dipenda completamente e in modo univoco dalla chiave primaria. Gli elementi di dati sono organizzati in gruppi in base alla loro identificazione univoca. Le regole aziendali che controllano i dati devono essere integralmente inserite nel modello normalizzato con una verifica preliminare della loro validità e correttezza. Ad esempio, un elemento di dati come il nome del cliente verrebbe probabilmente suddiviso in nome e cognome e raggruppato con altri elementi di dati pertinenti in un'entità cliente con una chiave primaria di ID cliente.

Il modello di dati logici è indipendente dalle tecnologie applicative come database, networking o strumenti di reporting e dalla loro implementazione fisica. Un'organizzazione può avere un solo modello di dati aziendale. I modelli logici in genere includono migliaia di entità, relazioni e attributi. Ad esempio, un modello di dati per un istituto finanziario o una società di telecomunicazioni può contenere circa 3.000 concetti di settore.

È importante distinguere tra modello di dati logico e semantico. Il modello di dati logici rappresenta la soluzione di business aziendale, mentre il modello di dati semantici rappresenta la soluzione di business applicata. Lo stesso modello di dati logici aziendali può essere implementato utilizzando diversi modelli semantici, ad es. i modelli semantici possono essere considerati come il livello successivo di modellazione che si avvicina ai modelli fisici. Inoltre, ciascuno di questi modelli rappresenterà una "fetta" separata del modello di dati aziendali in conformità con i requisiti delle varie applicazioni. Ad esempio, in un modello di dati logici aziendali, l'entità Cliente sarà completamente normalizzata e in un modello semantico per un data mart, può essere rappresentata come una struttura multidimensionale.

Un'azienda può avere due modi per creare un modello di dati logico aziendale: costruirlo da soli o utilizzare un modello già pronto modello di settore(modello di dati logici di settore). In questo caso, le differenze in termini riflettono solo approcci diversi alla costruzione dello stesso modello logico. Nel caso in cui un'azienda sviluppi e implementi autonomamente il proprio modello di dati logici, tale modello, di norma, viene semplicemente chiamato modello logico aziendale. Se l'organizzazione decide di utilizzare il prodotto finito di un fornitore professionale, possiamo parlare di un modello di dati logico del settore. Quest'ultimo è un modello di dati logici già pronto che riflette il funzionamento di un particolare settore con un alto grado di accuratezza. Un modello logico di settore è una visualizzazione integrata e specifica del dominio di tutte le informazioni che devono trovarsi in un data warehouse aziendale per rispondere a domande di business sia strategiche che tattiche. Come qualsiasi altro modello di dati logici, il modello di settore non dipende dalle soluzioni applicative. Inoltre, non include dati derivati o altri calcoli per un recupero più rapido dei dati. Di norma, la maggior parte delle strutture logiche di un tale modello trova una buona incarnazione nella sua effettiva implementazione fisica. Tali modelli vengono sviluppati da molti fornitori per un'ampia varietà di aree: finanza, produzione, turismo, assistenza sanitaria, assicurazioni, ecc.

Un modello dati logico di settore contiene informazioni comuni a un settore e pertanto non può essere una soluzione completa per un'azienda. La maggior parte delle aziende deve aumentare il modello in media del 25% aggiungendo elementi di dati e ampliando le definizioni. I modelli finiti contengono solo gli elementi di dati chiave e il resto degli elementi deve essere aggiunto agli oggetti business appropriati durante l'installazione del modello nell'azienda.

I modelli di dati logici di settore contengono un numero significativo di astrazioni. L'astrazione si riferisce all'unione di concetti simili sotto nomi comuni come Evento o Partecipante. Ciò aggiunge flessibilità ai modelli di settore e li rende più unificati. Pertanto, il concetto di Evento è applicabile a tutti i settori.

L'esperto di Business Intelligence Steve Hoberman delinea cinque fattori da considerare quando si decide se acquistare un modello di dati di settore. Il primo è il tempo e le risorse necessarie per costruire il modello. Se un'organizzazione ha bisogno di ottenere risultati rapidamente, il modello di settore darà un vantaggio. L'utilizzo di un modello di settore potrebbe non fornire immediatamente un'immagine dell'intera organizzazione, ma può far risparmiare una notevole quantità di tempo. Invece della modellazione vera e propria, sarà dedicato del tempo a collegare le strutture esistenti al modello di settore, nonché a discutere il modo migliore per personalizzarlo in base alle esigenze dell'organizzazione (ad esempio, quali definizioni dovrebbero essere modificate e quali elementi di dati dovrebbero essere aggiunti).

Il secondo fattore è il tempo e il denaro necessari per mantenere in funzione il modello. Se un modello di dati aziendali non fa parte di una metodologia che lo mantiene accurato e aggiornato, il modello diventerà obsoleto molto rapidamente. Il modello dei dati di settore può prevenire questo rischio poiché è mantenuto aggiornato da risorse esterne. Naturalmente, i cambiamenti che si verificano all'interno dell'organizzazione devono riflettersi nel modello dall'azienda stessa, ma i cambiamenti del settore saranno riprodotti nel modello dal suo fornitore.

Il terzo fattore è l'esperienza nella valutazione e nella modellazione del rischio. La creazione di un modello di dati aziendale richiede risorse qualificate da parte del personale aziendale e IT. Di norma, i manager conoscono bene il lavoro dell'organizzazione nel suo insieme o le attività di un particolare dipartimento. Pochi di loro hanno una conoscenza ampia (a livello aziendale) e profonda (a livello di unità) della propria attività. La maggior parte dei manager di solito conosce bene solo un'area. Pertanto, per ottenere un quadro a livello aziendale, sono necessarie risorse aziendali significative. Ciò aumenta anche i requisiti per il personale IT. Più risorse aziendali sono necessarie per creare e testare un modello, più esperti devono essere gli analisti. Non solo devono sapere come ottenere informazioni dal personale aziendale, ma anche essere in grado di trovare un terreno comune in aree controverse ed essere in grado di presentare tutte queste informazioni in modo integrato. Colui che crea il modello (in molti casi si tratta dello stesso analista) deve avere buone capacità di modellazione. La creazione di modelli di logica aziendale richiede la modellazione "per il futuro" e la capacità di convertire affari complessi in letteralmente "quadrati e linee".

D'altra parte, il modello di settore consente di utilizzare l'esperienza di specialisti di terze parti. I modelli logici specifici del settore utilizzano metodologie di modellazione collaudate e team di professionisti esperti per evitare problemi comuni e costosi che possono sorgere durante lo sviluppo di modelli di dati aziendali all'interno di un'organizzazione.

Il quarto fattore è l'infrastruttura applicativa esistente e le relazioni con i fornitori. Se un'organizzazione utilizza già molti strumenti dello stesso fornitore e ha stabilito relazioni con loro, ha senso ordinare anche il modello di settore da loro. Tale modello potrà funzionare liberamente con altri prodotti dello stesso fornitore.

Il quinto fattore è lo scambio di informazioni all'interno del settore. Se un'azienda ha bisogno di condividere i dati con altre organizzazioni che operano nello stesso campo, un modello di settore può essere molto utile in questa situazione. Le organizzazioni all'interno dello stesso settore utilizzano componenti strutturali e terminologia simili. Al giorno d'oggi, nella maggior parte dei settori, le aziende sono costrette a condividere i dati per gestire con successo la propria attività.

I modelli di settore offerti dai fornitori professionali sono i più efficaci. L'elevata efficienza del loro utilizzo è ottenuta grazie a un livello significativo di dettaglio e precisione di questi modelli. Di solito contengono molti attributi di dati. Inoltre, i creatori di questi modelli non solo hanno una vasta esperienza di modellazione, ma sono anche esperti nella costruzione di modelli per un particolare settore.

I modelli di dati di settore forniscono alle aziende una visione unica e integrata delle informazioni aziendali. Molte aziende hanno difficoltà a integrare i propri dati, sebbene questo sia un prerequisito per la maggior parte dei progetti a livello aziendale. Secondo uno studio del Data Warehousing Institute (TDWI), oltre il 69% delle organizzazioni intervistate ha riscontrato che l'integrazione rappresenta un ostacolo significativo all'adozione di nuove applicazioni. Al contrario, l'implementazione dell'integrazione dei dati porta un reddito significativo all'azienda.

Il modello di dati del settore, oltre a collegarsi ai sistemi esistenti, offre grandi vantaggi per progetti a livello aziendale come la pianificazione delle risorse aziendali (ERP), la gestione dei dati master, la business intelligence, il miglioramento della qualità dei dati e lo sviluppo dei dipendenti.

Pertanto, i modelli di dati logici del settore sono uno strumento efficace per integrare i dati e ottenere un quadro olistico dell'azienda. L'utilizzo di modelli logici sembra essere un passo necessario verso la creazione di data warehouse aziendali.

Pubblicazioni

Steve Hoberman. Sfruttare il modello di dati logico di settore come modello di dati aziendale
Claudia Imhoff. Monitoraggio rapido dei progetti di data warehousing e business intelligence tramite la modellazione intelligente dei dati

Questo articolo si concentrerà sull'architettura dei data warehouse. A cosa essere guidato durante la costruzione, quali approcci funzionano e perché.

"La fiaba è una bugia - ma c'è un accenno in essa ..."

Il nonno ha piantato ... deposito. E il magazzino divenne sempre più grande. Solo che non sapevo davvero come funzionasse. E il nonno ha iniziato una revisione. Il nonno ha chiamato la nonna, la nipote, il gatto e il topo per un consiglio di famiglia. E dice il seguente argomento: “Il nostro spazio di archiviazione è cresciuto. I dati di tutti i sistemi si affollano, le tabelle sono visibili e invisibili. Gli utenti preparano i loro rapporti. Sembra che tutto vada bene: vivere e vivere. Sì, solo una tristezza: nessuno sa come funziona. Richiede dischi apparentemente invisibili: non ne avrai mai abbastanza! E poi ci sono utenti che si rivolgono a me con diversi reclami: o il report si blocca o i dati sono obsoleti. E a volte è un vero disastro: arriviamo con rapporti allo zar-padre, ma i numeri non sono d'accordo tra loro. L'ora non è nemmeno - il re si arrabbierà - quindi non demolire la testa - né per me, né per te. Così ho deciso di radunarvi e consultarmi: cosa faremo?

Gettò gli occhi sull'assemblea e chiese:
- Ecco a te, nonna, sai com'è organizzato il nostro deposito?
- No, nonno, non lo so. E come dovrei saperlo? Laggiù, che ragazzi coraggiosi lo stanno proteggendo! Alcuni baffi! Non fare un passo avanti. Sono andato a trovarli in qualche modo, torte al forno. E mangiarono delle torte, si asciugarono i baffi e dissero: “Perché sei venuta, nonna? Qual è il tuo spazio di archiviazione? Dicci di che tipo di rapporto hai bisogno - lo faremo per te! Soprattutto, porti le torte più spesso! Dolorosamente, hanno un sapore delizioso.
- E tu, mia adorata nipote, sai come è organizzato il nostro deposito?
- No, nonno, non lo so. Mi ha dato un po' di accesso ad esso. Mi sono connesso, guardo - e ci sono dei tavoli - apparentemente invisibili. E diversi schemi sono nascosti. Gli occhi si spalancano.... All'inizio ero confuso. E poi ho guardato da vicino: alcuni sono vuoti, altri sono pieni, ma solo la metà. Inoltre, i dati sembrano essere ripetuti. Non c'è da stupirsi che non sia possibile fare scorta di dischi con tale ridondanza!
- Bene, tu, gatto, cosa puoi dire del nostro deposito? C'è qualcosa di buono in esso?
- Sì, come non dire, nonno - dirò. Su richiesta di mia nipote, ho provato a realizzare un pilota pilota in uno schema separato: una piccola vetrina. Per capire che tipo di commercio è vantaggioso per il nostro stato - quali prodotti sono buoni per i mercanti, rendono omaggio - il tesoro viene rifornito. E quali sono cattivi. E ho iniziato a raccogliere dati da questo repository. Fatti raccolti. E iniziò a provare a confrontarli con i prodotti. E cosa, nonno, ho visto - i prodotti sembrano essere gli stessi, ma guardi i segni - sono diversi! Ho quindi iniziato a pettinarli con il pettine di mia nipote. Ha graffiato, graffiato - e ha portato a una certa uniformità, accarezzando l'occhio. Ma presto mi sono rallegrato - il giorno dopo ho lanciato i miei script per aggiornare i meravigliosi dati nella finestra - e tutto è andato via per me! "Come mai?" - Penso, - la nipote si arrabbierà - oggi sarebbe necessario mostrare il nostro pilota al ministro. Come possiamo farlo - con tali dati?
- Sì, storie tristi, gatto, dici tu. Ebbene tu, topolino, non hai davvero provato a scoprire il caveau? Sei una ragazza vivace, agile e socievole! Cosa ci dirai?
- Sì, come, nonno, non provarci - certo, sono un topo tranquillo, ma agile. In qualche modo la nipote del gatto ha chiesto al modello di dati del nostro archivio statale di ottenerlo. E il gatto, ovviamente, è venuto da me - su di te, dice il topo, tutta speranza! Ebbene, che buona azione non possono fare le brave persone (ei gatti)? Sono andato al castello, dove il capo del repository nasconde il modello di dati in una cassaforte. E nascosto. Ho aspettato che tirasse fuori quel modello dalla cassaforte. Non appena è uscito per un caffè, sono saltato sul tavolo. Guardo il modello - non riesco a capire niente! Come mai? Non riconosco il nostro caveau! Abbiamo innumerevoli migliaia di tabelle, dati - flussi instancabili! E qui - tutto è armonioso e bello ... Guardò questo modello - e lo ripose nella cassaforte.
- Sì, cose molto strane, ci hai detto, topo.
Il nonno ci ha pensato bene.
Cosa dobbiamo fare, amici miei? Dopotutto, non vivrai a lungo con un simile repository ... Gli utenti perderanno presto completamente la pazienza.

Qualunque cosa decida nostro nonno della fiaba - di costruire un nuovo magazzino o provare a rianimare quello esistente - dobbiamo trarre conclusioni prima di “rimboccarci le maniche” di nuovo.
Mettiamo da parte gli aspetti organizzativi - come il pericolo di concentrare le competenze in un gruppo ristretto e chiuso, la mancanza di processi di controllo e di garantire la trasparenza dell'architettura dei sistemi utilizzati nell'impresa, ecc.
Oggi vorrei concentrarmi sulla costruzione dell'architettura di un particolare sistema (o gruppo di sistemi): i data warehouse. Cosa dovrebbe essere tenuto a fuoco in primo luogo quando un'organizzazione inizia a costruire un sistema così complesso e costoso come lo storage.

Debriefing

Nessuno di noi, lavorando alla creazione e allo sviluppo di un sistema, non vuole che sia una “casa temporanea”, o una soluzione che “svanirà” in un anno o due, perché. non sarà in grado di soddisfare i requisiti e le aspettative dei Clienti e delle Imprese. Non importa quanto sia forte oggi il passaggio verso "metodologie flessibili", è molto più piacevole per una persona sentirsi un "maestro" che fa violini che un artigiano che intaglia i bastoncini per tamburi usa e getta.
La nostra intenzione sembra naturale: realizzare sistemi solidi e di alta qualità, che non ci richiedano regolarmente "vigilanze notturne con un file", di cui non ci vergogneremo davanti agli utenti finali, e che non sembreranno una "scatola nera" per tutti i follower "non iniziati".

Innanzitutto, elenchiamo i problemi tipici che incontriamo regolarmente quando lavoriamo con gli archivi. Scriviamo solo quello che abbiamo - finora senza cercare di razionalizzare e formalizzare.

In linea di principio, abbiamo una buona conservazione: se non la tocchi, tutto funziona. È vero, non appena è necessario un cambiamento, iniziano i "crolli locali".
I dati vengono caricati quotidianamente, secondo le normative, all'interno di un unico grande processo, entro 8 ore. E ci si addice. Ma se si verifica un guasto all'improvviso, ciò richiede un intervento manuale. E poi tutto può funzionare in modo imprevedibile per molto tempo, perché. è necessaria la partecipazione umana nel processo.
Rilascio progressivo: aspettati problemi.
Una fonte non è stata in grado di fornire i dati in tempo: tutti i processi sono in attesa.
L'integrità dei dati è controllata dal database, quindi i nostri processi si bloccano quando vengono interrotti.
Abbiamo uno spazio di archiviazione molto grande: 2000 tabelle in uno schema comune. E 3000 in più in molti altri schemi. Abbiamo già poca idea di come siano disposti e per quale motivo siano apparsi. Pertanto, può essere difficile per noi riutilizzare qualcosa. E molti problemi devono essere risolti di nuovo. Perché è più facile e veloce (che capire "nel codice di qualcun altro"). Di conseguenza, abbiamo discrepanze e funzionalità duplicate.
Ci aspettiamo che la fonte fornisca dati di qualità. Ma si scopre che non è così. Di conseguenza, dedichiamo molto tempo alla riconciliazione dei nostri rapporti finali. E hanno avuto molto successo. Abbiamo anche un processo semplificato. È vero, ci vuole tempo. Ma gli utenti sono abituati a...
L'utente non si fida sempre dei nostri rapporti e richiede una giustificazione per una cifra particolare. In alcuni casi ha ragione e in altri ha torto. Ma è molto difficile per noi sostanziarli, perché non forniamo mezzi di "analisi end-to-end" (o derivazione dei dati).
Potremmo coinvolgere altri sviluppatori. Ma abbiamo un problema: come li trasformiamo in lavoro? Qual è il modo più efficiente per parallelizzare il lavoro?
Come sviluppare il sistema gradualmente, senza entrare nello sviluppo del “nucleo del sistema” per un anno intero?
Il data warehouse è associato al modello aziendale. Ma sappiamo per certo (l'abbiamo visto nella banca XYZ) che è possibile costruire un modello a tempo indeterminato (nella banca XYZ siamo andati in giro e abbiamo discusso di entità aziendali per sei mesi, senza alcun movimento). Perché è lei? O forse è meglio senza di lei, se ci sono così tanti problemi con lei? Forse generarlo in qualche modo?
Abbiamo deciso di guidare il modello. Ma come sviluppare sistematicamente il modello dei dati di magazzino? Abbiamo bisogno di "regole del gioco" e quali possono essere? Cosa ci darà? E se commettiamo un errore con il modello?
Dobbiamo salvare i dati, o la cronologia delle loro modifiche, se "l'azienda non ne ha bisogno"? Non vorrei "immagazzinare spazzatura" e complicare l'uso di questi dati per compiti reali. Il caveau dovrebbe conservare la cronologia? Com'è? Come funziona l'archiviazione nel tempo?
È necessario cercare di unificare i dati nello storage se disponiamo di un sistema di gestione NSI? Se è presente l'MDM, significa che ora l'intero problema dei dati anagrafici è risolto?
Ci si aspetta che sostituiremo presto i sistemi contabili chiave. Il datastore dovrebbe essere pronto per una modifica dell'origine? Come raggiungere questo obiettivo?
Abbiamo bisogno di metadati? Cosa dobbiamo intendere con questo? Dove si possono usare esattamente? Come può essere implementato? Devono essere tenuti "in un unico posto"?
I nostri clienti sono estremamente instabili nelle loro esigenze e desideri - qualcosa è in continua evoluzione. In generale, la nostra attività è molto dinamica. Mentre stiamo facendo qualcosa, diventa già superfluo. Come possiamo assicurarci di produrre risultati il più rapidamente possibile, come le torte calde?
Gli utenti richiedono velocità. Ma non possiamo eseguire spesso i nostri processi di avvio principali, perché questo carica i sistemi di origine (ha un effetto negativo sulle prestazioni) - quindi, riattacchiamo flussi di dati aggiuntivi - che prenderanno in modo appropriato - ciò di cui abbiamo bisogno. È vero, risulta un sacco di flussi. E poi elimineremo alcuni dei dati. Inoltre, ci sarà un problema di convergenza. Ma non c'è altro modo...

Sono già successe molte cose. Ma questo non è un elenco completo: è facile integrarlo e svilupparlo. Non lo nasconderemo sul tavolo, ma lo appenderemo in un luogo ben visibile, mantenendo questi problemi al centro della nostra attenzione nel processo di lavoro.
Il nostro compito è quello di sviluppare una soluzione completa di conseguenza.

antifragilità

Guardando la nostra lista, si può trarre una conclusione. Non è difficile creare una sorta di "database per i rapporti", inserire dati lì o persino creare una sorta di processo di aggiornamento dei dati di routine. Il sistema inizia a vivere in qualche modo, gli utenti appaiono e con loro gli obblighi e gli SLA, sorgono nuovi requisiti, vengono collegate fonti aggiuntive, le metodologie cambiano: tutto ciò deve essere preso in considerazione nel processo di sviluppo.

Dopo un po' di tempo, l'immagine è la seguente:
"Ecco il caveau. E funziona se non lo tocchi. I problemi sorgono quando dobbiamo cambiare qualcosa”.

Ci arriva un cambiamento, di cui non siamo in grado di valutare e comprendere l'impatto (perché inizialmente non abbiamo inserito tali strumenti nel sistema) - e per non correre rischi, non tocchiamo ciò che è, ma ne facciamo uno in più estensione laterale, e ancora, e ancora, trasformando la nostra decisione in slum, o come si dice in America Latina, "favelas", dove anche la polizia ha paura di andare.
C'è una sensazione di perdita di controllo sul proprio sistema, il caos. Sono necessarie sempre più mani per mantenere i processi esistenti e risolvere i problemi. Ed è sempre più difficile apportare modifiche. In altre parole, il sistema diventa instabile alle sollecitazioni, non adattabile ai cambiamenti. E poi c'è una forte dipendenza dai personaggi che "conoscono il fairway", dal momento che nessuno ha una "carta".

Questa proprietà di un oggetto è di crollare sotto l'influenza del caos, eventi casuali e sconvolgimenti - chiama Nassim Nicholas Taleb fragilità . Introduce anche il concetto opposto: antifragilità – quando l'oggetto non viene distrutto da stress e incidenti, ma ne trae un beneficio diretto. ("Antifragilità. Come trarre vantaggio dal caos")
Altrimenti può essere chiamato adattabilità o resistenza al cambiamento .

Cosa significa questo in questo contesto? Quali sono le "fonti del caos" per i sistemi IT? E cosa significa "capitalizzare il caos" in termini di architettura IT?
Il primo pensiero che viene in mente sono i cambiamenti che vengono dall'esterno. Qual è il mondo esterno per il sistema? Per la conservazione in particolare. Naturalmente, prima di tutto - modifiche dalle origini dati per il magazzino:

cambiare i formati dei dati in entrata;
sostituzione di alcuni sistemi di origine dati con altri;
modificare le regole/piattaforme per l'integrazione del sistema;
modificare l'interpretazione dei dati (vengono salvati i formati, cambia la logica di lavorare con i dati);
modifica del modello dati, se l'integrazione viene eseguita a livello di dati (analisi dei file di registro delle transazioni del database);
crescita dei volumi di dati - mentre c'erano pochi dati nel sistema di origine e il carico era piccolo - potevi prenderli in qualsiasi momento, con una richiesta arbitrariamente pesante, i dati e il carico sono cresciuti - ora ci sono rigide restrizioni;
eccetera.

Gli stessi sistemi di origine, la composizione dell'informazione e la sua struttura, il tipo di interazione di integrazione, nonché la logica stessa del lavoro con i dati possono cambiare. Ogni sistema implementa il proprio modello di dati e approcci per lavorare con essi che soddisfano gli obiettivi e gli obiettivi del sistema. E non importa quanto si sforzano di unificare i modelli di settore e le pratiche di riferimento, inevitabilmente emergeranno comunque delle sfumature. (E inoltre, lo stesso processo di unificazione industriale, per vari motivi, non sta andando molto avanti.)
La cultura del lavoro con i dati aziendali - la presenza e il controllo dell'architettura dell'informazione, un modello semantico unico, i sistemi di gestione dei dati anagrafici (MDM) facilitano in qualche modo il compito di consolidamento dei dati nel magazzino, ma non ne escludono la necessità.

Non meno importanti modifiche vengono avviate dai consumatori di archiviazione (modifiche ai requisiti):

in precedenza c'erano dati sufficienti per creare un report - ora era necessario collegare campi aggiuntivi o una nuova origine dati;
i metodi di elaborazione dei dati precedentemente implementati sono obsoleti: gli algoritmi e tutto ciò che influisce devono essere rielaborati;
In precedenza, tutti erano soddisfatti del valore corrente dell'attributo del dizionario sul pannello delle informazioni - ora è richiesto il valore rilevante al momento del verificarsi del fatto/evento analizzato;
c'era un requisito per la profondità della storia dell'archiviazione dei dati, che prima non c'era: per archiviare i dati non per 2 anni, ma per 10 anni;
Prima bastava avere i dati a “fine giornata/periodo” - ora serve lo stato dei dati “intraday”, ovvero al momento di un determinato evento (ad esempio, prendere una decisione su una richiesta di prestito - per Basilea II);
prima eravamo soddisfatti di riportare i dati di ieri (T-1) o successivi, ora abbiamo bisogno di T0;
eccetera.

Sia le interazioni di integrazione con i sistemi di origine che i requisiti dei consumatori del data warehouse sono fattori esterni per il data warehouse: un sistema di origine ne sostituisce un altro, i volumi di dati crescono, i formati dei dati in entrata cambiano, i requisiti degli utenti cambiano, ecc. E tutte queste sono tipiche modifiche esterne per le quali il nostro sistema - il nostro repository - deve essere pronto. Con la giusta architettura, non dovrebbero uccidere il sistema.

Ma non è tutto.
Parlando di variabilità, ricordiamo innanzitutto fattori esterni. In fondo dentro di noi possiamo controllare tutto, ci sembra, no? Sì e no. Sì, la maggior parte dei fattori che sono al di fuori della zona di influenza sono esterni. Ma c'è anche “entropia interna”. Ed è proprio per la sua presenza che a volte occorre tornare “al punto 0”. Ricomincia il gioco.
Nella vita, spesso si tende a ricominciare da zero. Perché tendiamo a farlo? Ed è così male?
Applicato all'IT. Per il sistema stesso - questo può essere molto positivo - la capacità di riconsiderare le decisioni individuali. Soprattutto quando possiamo farlo localmente. Il refactoring è il processo di svelamento del "web" che periodicamente si pone nel processo di sviluppo del sistema. Tornare "all'inizio" può essere utile. Ma ha un prezzo.
Con una corretta gestione dell'architettura, questo prezzo viene ridotto e il processo di sviluppo del sistema stesso diventa più controllabile e trasparente. Un semplice esempio: se si rispetta il principio della modularità, è possibile riscrivere un modulo separato senza intaccare le interfacce esterne. E questo non può essere fatto con una struttura monolitica.

L'antifragilità di un sistema è determinata dalla sua architettura. Ed è questa proprietà che lo rende adattivo.
Quando si parla di architettura adattiva- intendiamo dire che il sistema è in grado di adattarsi ai cambiamenti, e per niente cambiamo costantemente l'architettura stessa. Al contrario, più l'architettura è stabile e stabile, minori sono i requisiti che ne comportano la revisione, più il sistema è adattabile.

Le soluzioni che richiedono una revisione dell'intera architettura avranno un prezzo molto più alto. E per la loro adozione, devi avere ottime ragioni. Ad esempio, un tale motivo potrebbe essere un requisito che non può essere implementato all'interno dell'architettura attuale. Poi dicono - c'era un requisito che riguarda l'architettura.
Quindi, dobbiamo anche conoscere i nostri “limiti di antifragilità”. L'architettura non si sviluppa "nel vuoto", ma si basa sui requisiti e sulle aspettative attuali. E se la situazione cambia radicalmente - dobbiamo capire che siamo andati oltre l'architettura attuale - e dobbiamo rivederla, sviluppare una soluzione diversa - e riflettere sui percorsi di transizione.
Ad esempio, abbiamo ipotizzato che a fine giornata avremo sempre bisogno di dati in magazzino, raccoglieremo dati quotidianamente utilizzando interfacce di sistema standard (attraverso un insieme di viste). Poi, dal dipartimento di risk management, sono emerse richieste relative alla necessità di ricevere i dati non a fine giornata, ma al momento della decisione sull'erogazione del credito. Non c'è bisogno di provare a "allungare il non allungato" - devi solo riconoscere questo fatto - prima è, meglio è. E inizia a lavorare su un approccio che ci permetta di risolvere il problema.
C'è una linea molto sottile qui - se consideriamo solo i "requisiti del momento" e non guardiamo qualche passo avanti (e diversi anni avanti), allora aumentiamo il rischio di incontrare troppo tardi un requisito che influisca sull'architettura - e il il costo del nostro cambiamento sarà molto alto. Guardare un po' avanti - entro i confini del nostro orizzonte - non ha mai fatto del male a nessuno.

L'esempio di un sistema tratto dalla "fiaba di archiviazione" è solo un esempio di un sistema molto traballante costruito su approcci progettuali fragili. E se ciò accade, la distruzione avviene piuttosto rapidamente, per questa particolare classe di sistemi.
Perché posso dirlo? Il tema della conservazione non è nuovo. Gli approcci e le pratiche ingegneristiche che sono state sviluppate durante questo periodo sono state mirate proprio a questo: mantenere la fattibilità del sistema.
Per fare un semplice esempio, uno dei motivi più comuni per cui i progetti di storage di takeoff falliscono è provare a creare storage su sistemi di origine in fase di sviluppo senza abbinare le interfacce di integrazione, cercando di estrarre i dati direttamente dalle tabelle. Di conseguenza, sono entrati in fase di sviluppo - durante questo periodo il database di origine è cambiato - e i flussi di download nello spazio di archiviazione sono diventati inutilizzabili. È troppo tardi per rifare qualcosa. E se non ti sei assicurato creando diversi strati di tavoli all'interno del magazzino, puoi buttare via tutto e ricominciare da capo. Questo è solo un esempio, e uno dei più semplici.

Il criterio di Taleb per fragile e antifragile è semplice. Il giudice capo è il tempo. Se il sistema resiste alla prova del tempo e mostra la sua "sopravvivenza" e "indistruttibilità", ha la proprietà di antifragilità.
Se, durante la progettazione di un sistema, prendiamo in considerazione l'antifragilità come requisito, questo ci incoraggerà a utilizzare tali approcci per costruire la sua architettura che renderanno il sistema più adattabile sia al "caos dall'esterno" che al "caos dall'interno ”. E alla fine il sistema avrà una vita più lunga.
Nessuno di noi vuole fare dei "temporanei". E non illuderti che non ci sia altro modo ora. Guardare qualche passo avanti è normale per una persona in qualsiasi momento, soprattutto in tempi di crisi.

Che cos'è un data warehouse e perché lo costruiamo

L'articolo sull'architettura di archiviazione presuppone che il lettore non solo sappia di cosa si tratta, ma abbia anche una certa esperienza con tali sistemi. Tuttavia, ho ritenuto necessario farlo: tornare alle origini, all'inizio del percorso, perché. è lì che si trova il “fulcro” dello sviluppo.

In che modo le persone sono giunte alla conclusione che i data warehouse sono necessari? E in che modo sono diversi da un semplice "database molto grande"?
Molto tempo fa, quando esistevano semplicemente "sistemi di elaborazione dati aziendali" nel mondo, non esisteva alcuna divisione dei sistemi IT in classi come sistemi oltp front-end, dss back-office, sistemi di elaborazione dati di testo, data warehouse, ecc. .
Questo è stato il momento in cui il primo DBMS relazionale Ingres è stato creato da Michael Stonebreaker.
E questo è stato il momento in cui l'era dei personal computer è esplosa nell'industria dei computer come un vortice e ha trasformato per sempre tutte le idee della comunità IT di quel tempo.

Quindi è stato facile trovare applicazioni aziendali scritte sulla base di DBMS di classe desktop, come Clipper, dBase e FoxPro. E il mercato delle applicazioni client-server e dei DBMS stava solo guadagnando slancio. Uno dopo l'altro, sono comparsi server di database che avrebbero occupato a lungo la loro nicchia nello spazio IT: Oracle, DB2, ecc.
E fu diffuso il termine "applicazione di database". Cosa includeva un'applicazione del genere? Semplificato: alcuni moduli di input attraverso i quali gli utenti potevano inserire contemporaneamente informazioni, alcuni calcoli che venivano lanciati "su un pulsante" o "su una pianificazione", nonché alcuni report che potevano essere visualizzati sullo schermo o salvati come file e inviati per sigillare .
"Niente di speciale: solo una semplice applicazione, solo un database", ha osservato uno dei miei primi mentori. "Non è niente di speciale?" - Ho pensato allora.

Se guardi da vicino, ci sono ancora funzionalità. Man mano che gli utenti crescono, il volume delle informazioni in entrata aumenta, man mano che aumenta il carico sul sistema, i suoi sviluppatori-progettisti, per mantenere le prestazioni a un livello accettabile, fanno alcuni "trucchi". Il primo in assoluto è la divisione di un "sistema di elaborazione dei dati aziendali" monolitico in un'applicazione di contabilità che supporta il lavoro degli utenti in modalità online e un'applicazione separata per l'elaborazione e il reporting dei dati batch. Ciascuna di queste applicazioni ha il proprio database ed è persino ospitata su un'istanza separata del server di database, con impostazioni diverse per diversi tipi di carico di lavoro: OLTP e DSS. E i flussi di dati sono costruiti tra di loro.

È tutto? Sembrerebbe che il problema sia risolto. Cosa succede dopo?
E poi le aziende crescono, i loro bisogni informativi si moltiplicano. Cresce anche il numero delle interazioni con il mondo esterno. Di conseguenza, non esiste una grande applicazione che automatizza completamente tutti i processi, ma diverse applicazioni di produttori diversi. Il numero di sistemi che generano informazioni - sistemi di origine dati nell'azienda è in aumento. E prima o poi ci sarà la necessità di vedere e confrontare le informazioni ricevute da diversi sistemi. Ecco come appare in azienda il Data Warehousing, una nuova classe di sistemi.
La definizione generalmente accettata di questa classe di sistemi è la seguente.

Data Warehouse (o Data Warehouse)- un database informativo specifico del dominio, appositamente progettato e destinato alla preparazione di report e analisi aziendali al fine di supportare il processo decisionale in un'organizzazione

In questo modo, consolidamento dati provenienti da sistemi diversi, la capacità di guardarli in un certo modo "singolo" (unificato) è una delle proprietà chiave dei sistemi di classe di archiviazione dati. Questo è il motivo per cui lo storage è nato durante l'evoluzione dei sistemi IT.

Caratteristiche principali dei data warehouse

Diamo un'occhiata più in dettaglio. Quali sono le caratteristiche principali di questi sistemi? Cosa rende i data warehouse diversi dagli altri sistemi IT aziendali?

Innanzitutto, si tratta di grandi volumi. Molto grande. VLDB - è così che i fornitori leader chiamano tali sistemi quando danno i loro consigli sull'uso dei loro prodotti. Da tutti i sistemi dell'azienda, i dati confluiscono in questo grande database e lì vengono archiviati "per sempre e immutabile", come si dice nei libri di testo (in pratica la vita risulta essere più complicata).

In secondo luogo, si tratta di dati storici − "Memoria aziendale" - i cosiddetti data warehouse. In termini di lavoro con il tempo di archiviazione, tutto è piuttosto interessante. Nei sistemi contabili, i dati sono rilevanti al momento. Quindi l'utente esegue alcune operazioni e i dati vengono aggiornati. Allo stesso tempo, la cronologia delle modifiche potrebbe non essere preservata: dipende dalla pratica contabile. Prendi, ad esempio, il saldo di un conto bancario. Potremmo essere interessati al saldo attuale a "adesso", a fine giornata o al momento di qualche evento (ad esempio, al momento del calcolo del punteggio). Se i primi due vengono risolti in modo abbastanza semplice, molto probabilmente il secondo richiederà sforzi speciali. Quando si lavora con il repository, l'utente può accedere ai periodi passati, confrontarli con quello corrente e così via. Sono queste capacità legate al tempo che distinguono in modo significativo i data warehouse dai sistemi contabili - ottenendo lo stato dei dati in vari punti dell'asse temporale - fino a una certa profondità nel passato.

Terzo, questo consolidamento e unificazione dei dati . Per rendere possibile la loro analisi congiunta, è necessario portarli in una forma comune - modello di dati unificato , confrontare i fatti con libri di consultazione unificati. Ci possono essere diversi aspetti e difficoltà qui. In primis - concettuale – nello stesso termine, persone diverse di reparti diversi possono capire cose diverse. E viceversa - chiamare diversamente qualcosa che è essenzialmente la stessa cosa. Come garantire una "visione unica" e allo stesso tempo preservare le specificità della visione di un particolare gruppo di utenti?

In quarto luogo, è lavorare con qualità dei dati . Durante il caricamento dei dati nella memoria, vengono puliti, vengono eseguite trasformazioni e trasformazioni generali. Le trasformazioni generali devono essere eseguite in un unico posto e quindi utilizzate per creare vari report. Ciò eviterà le discrepanze che causano tanta irritazione agli utenti business, in particolare al management, che sono portati al tavolo da numeri di reparti diversi che non sono d'accordo tra loro. La scarsa qualità dei dati dà origine a errori e discrepanze nei rapporti, la cui conseguenza è una diminuzione del livello fiducia degli utenti all'intero sistema, all'intero servizio analitico nel suo insieme.

concetto architettonico

Tutti coloro che hanno incontrato il repository, molto probabilmente hanno osservato una sorta di "struttura a strati" - perché. è questo paradigma architettonico che ha messo radici per i sistemi di questa classe. E non per caso. I livelli di archiviazione possono essere percepiti come componenti separati del sistema - con i propri compiti, area di responsabilità, "regole del gioco".
L'architettura a strati è un mezzo per affrontare la complessità del sistema: ogni livello successivo è astratto dalle complessità dell'implementazione interna del precedente. Questo approccio consente di identificare compiti dello stesso tipo e risolverli in modo uniforme, senza reinventare ogni volta la “bicicletta” da zero.
Nella figura è mostrato un diagramma architettonico concettuale schematico. Questo è un diagramma semplificato che riflette solo l'idea chiave - il concetto, ma senza i "dettagli anatomici" che emergeranno con uno studio più approfondito dei dettagli.

Come mostrato nel diagramma, selezionare concettualmente i seguenti livelli. Tre livelli principali che contengono l'area di memorizzazione dei dati (indicata da un rettangolo pieno) e il software di caricamento dei dati (indicato condizionatamente da frecce dello stesso colore). Oltre a un livello ausiliario - di servizio, che però svolge un ruolo di collegamento molto importante - la gestione del caricamento dei dati e il controllo della qualità.

Livello dati primario - livello dati primario (o messa in scena , o strato operativo ) - è progettato per essere caricato dai sistemi di origine e salvare le informazioni primarie, senza trasformazioni - nella sua qualità originale e con il supporto per una cronologia completa delle modifiche.
Il compito di questo livello– per astrarre livelli di archiviazione successivi dal dispositivo fisico delle origini dati, metodi di raccolta dati e metodi per evidenziare il delta delle modifiche.

Core Data Layer - core di archiviazione - la componente centrale del sistema, che distingue lo storage da una semplice “piattaforma di integrazione batch”, o “big data dump”, poiché il suo ruolo principale è consolidamento dei dati da fonti diverse, riduzione a strutture uniformi, chiavi. È durante il caricamento nel kernel che viene eseguito il lavoro principale con la qualità dei dati e le trasformazioni generali, che possono essere piuttosto complesse.
Il compito di questo livello- astrarre i propri consumatori dalle peculiarità della struttura logica delle fonti di dati e dalla necessità di confrontare i dati provenienti da sistemi diversi, garantire l'integrità e la qualità dei dati.

Data Mart Layer - vetrine analitiche - un componente la cui funzione principale è convertire i dati in strutture convenienti per l'analisi (se la BI lavora con le vetrine, allora questo è solitamente un modello dimensionale), o secondo i requisiti del sistema di consumo.
Di norma, i data mart prelevano i dati dal core - come fonte affidabile e verificata - cioè utilizzare il servizio di questo componente per portare i dati in un unico modulo. Chiameremo tali finestre regolare . In alcuni casi, le vetrine possono prelevare i dati direttamente dallo staging, operando con i dati primari (nelle chiavi di origine). Questo approccio, di norma, viene utilizzato per attività locali in cui non è richiesto il consolidamento dei dati da sistemi diversi e in cui è necessaria più efficienza della qualità dei dati. Tali display sono chiamati operativo . Alcuni indicatori analitici possono avere metodi di calcolo molto complessi. Pertanto, per tali calcoli e trasformazioni non banali, cd vetrine secondarie .
Attività del livello Storefront– preparazione dei dati secondo le esigenze di un determinato consumatore – una piattaforma BI, un gruppo di utenti o un sistema esterno.

I livelli sopra descritti sono costituiti da un'area di archiviazione dati permanente, nonché da un modulo software per il caricamento e la trasformazione dei dati. Questa divisione in strati e regioni è logica. L'implementazione fisica di questi componenti può essere diversa: puoi persino utilizzare piattaforme diverse per archiviare o trasformare i dati su livelli diversi, se questo è più efficiente.
Le aree di archiviazione contengono tecniche (tabelle buffer) che vengono utilizzate nel processo di trasformazione dei dati e tabelle di destinazione, a cui accede il componente consumer. È buona norma "coprire" le tabelle di destinazione con le viste. Ciò facilita la successiva manutenzione e sviluppo del sistema. I dati nelle tabelle target di tutti e tre i livelli sono contrassegnati da appositi campi tecnici (meta-attributi), che servono a garantire i processi di caricamento dei dati, nonché a consentire l'audit informativo dei flussi di dati nello storage.

Si distingue anche un componente speciale (o un insieme di componenti), che fornisce funzioni di servizio per tutti i livelli. Uno dei suoi compiti chiave - la funzione di controllo - è quello di fornire "regole uniche del gioco" per l'intero sistema nel suo insieme, lasciando il diritto di utilizzare diverse opzioni per implementare ciascuno dei livelli sopra descritti - incl. utilizzare diverse tecnologie per il caricamento e l'elaborazione dei dati, diverse piattaforme di archiviazione, ecc. Chiamiamolo livello di servizio (Livello di servizio) . Non contiene dati aziendali, ma ha le proprie strutture di archiviazione: contiene un'area di metadati, nonché un'area per lavorare con la qualità dei dati (ed eventualmente altre strutture, a seconda delle funzioni assegnate).

Una divisione così chiara del sistema in componenti separati aumenta notevolmente la controllabilità dello sviluppo del sistema:

si riduce la complessità del compito assegnato allo sviluppatore della funzionalità di un particolare componente (non deve risolvere contemporaneamente problemi di integrazione con sistemi esterni, pensare alle procedure di pulizia dei dati e pensare alla presentazione ottimale dei dati per consumatori) - il compito è più facile da scomporre, valutare ed eseguire una piccola consegna;
puoi coinvolgere vari artisti (e anche squadre o appaltatori) nel lavoro - perché questo approccio consente di parallelizzare efficacemente le attività, riducendo la reciproca influenza reciproca;
la presenza di staging persistente permette di collegare velocemente le sorgenti dati senza progettare l'intero core o showcase per l'intera area tematica, per poi costruire gradualmente il resto dei layer in base alle priorità (inoltre i dati saranno già nel repository - disponibile agli analisti di sistema, che faciliteranno notevolmente i compiti di successivo sviluppo del repository);
la presenza del core consente di nascondere alle vetrine e all'utente finale tutto il lavoro con la qualità dei dati (oltre a possibili mancati ed errori) e, soprattutto, utilizzando questo componente come un'unica fonte di dati per le vetrine, è possibile evitare problemi con convergenza dei dati grazie all'implementazione di algoritmi comuni in un unico luogo;
l'evidenziazione delle vetrine consente di prendere in considerazione le differenze e le specificità di comprensione dei dati che gli utenti dei diversi reparti possono avere e la loro progettazione per i requisiti di BI consente non solo di emettere dati aggregati, ma anche di garantire l'affidabilità dei dati fornendo opportunità di approfondimento agli indicatori primari;
la presenza del livello di servizio consente di eseguire analisi dei dati end-to-end (data lineage), utilizzare strumenti di audit dei dati unificati, approcci comuni per evidenziare il delta delle modifiche, lavorare con la qualità dei dati, la gestione del carico, il monitoraggio degli errori e gli strumenti diagnostici e accelera la risoluzione dei problemi.

Questo approccio alla decomposizione rende anche il sistema più resistente al cambiamento (rispetto a una "struttura monolitica") - ne garantisce l'antifragilità:

le modifiche dai sistemi di origine vengono elaborate sullo staging: nel kernel, vengono modificati solo i thread interessati da queste tabelle di staging, l'effetto sulle vetrine è minimo o assente;
le modifiche ai requisiti dei clienti vengono elaborate principalmente nelle vetrine (a meno che non richiedano informazioni aggiuntive che non siano già nel magazzino).

Successivamente, esamineremo ciascuno dei componenti di cui sopra e li esamineremo un po' più in dettaglio.

Nucleo del sistema

Iniziamo "dal centro": il nucleo del sistema o lo strato intermedio. Non etichettato come Core Layer. Il core svolge il ruolo di consolidamento dei dati - riduzione a singole strutture, directory, chiavi. Qui viene svolto il lavoro principale con la qualità dei dati: pulizia, trasformazione, unificazione.

La presenza di questo componente consente di riutilizzare flussi di dati che trasformano i dati primari ricevuti dai sistemi sorgente in un unico formato, seguendo regole e algoritmi comuni, anziché ripetere l'implementazione delle stesse funzionalità separatamente per ogni vetrina applicativa, che, oltre a un uso inefficiente delle risorse, può portare anche a discrepanze nei dati.
Lo storage core è implementato in un modello dati, nel caso generale, diverso sia dai modelli dei sistemi sorgente che dai formati e dalle strutture dei consumatori.

Modello del motore di archiviazione e modello dei dati aziendali

Il compito principale del livello di archiviazione intermedio è la stabilità. Ecco perché l'obiettivo principale qui è sul modello di dati. Viene comunemente chiamato "modello di dati aziendali". Intorno ad esso si è purtroppo sviluppato un certo alone di miti e assurdità, che a volte portano all'abbandono del tutto, ma invano, della sua costruzione.

Mito 1. Un modello di dati aziendali è un modello enorme composto da migliaia di entità (tabelle).
In realtà. In qualsiasi area disciplinare, in qualsiasi ambito aziendale, nei dati di qualsiasi azienda, anche la più complessa, ci sono poche entità di base: 20-30.

Mito 2. Non è necessario sviluppare alcun "modello proprio" - acquistiamo un modello di riferimento del settore - e fare tutto in base ad esso. Spendiamo soldi, ma otteniamo un risultato garantito.
In realtà. I modelli di riferimento possono essere davvero molto utili, perché. contengono esperienza nel settore nella modellazione di quest'area. Da loro puoi trarre idee, approcci, pratiche di denominazione. Verificare la "profondità di copertura" dell'area, per non farsi sfuggire qualcosa di importante. Ma è improbabile che saremo in grado di utilizzare un modello del genere "out of the box", così com'è. Questo è lo stesso mito dell'acquisto, ad esempio, di un sistema ERP (o CRM) e della sua implementazione senza alcuna “torsione per se stessi”. Il valore di tali modelli nasce nel loro adattamento alle realtà di questo particolare business, di questa particolare azienda.

Mito 3. Lo sviluppo del modello di storage core può richiedere molti mesi, durante i quali il progetto verrà effettivamente bloccato. Inoltre, richiede una quantità folle di incontri e la partecipazione di molte persone.
In realtà. Il modello del repository può essere sviluppato in modo iterativo, pezzo per pezzo, insieme al repository. Per le aree scoperte vengono posizionati "punti di estensione" o "tronchetti" - ad es. vengono applicate alcune "costruzioni universali". Allo stesso tempo, devi sapere quando fermarti per non ottenere una cosa super-universale di 4 tabelle, in cui è difficile sia "mettere dati" che (ancora più difficile) ottenerli. E che è estremamente non ottimale in termini di prestazioni.

Ci vorrà del tempo per sviluppare il modello. Ma questo non è il tempo speso per "disegnare entità": questo è il tempo necessario per analizzare l'area tematica, capire come sono strutturati i dati. Questo è il motivo per cui gli analisti sono coinvolti molto da vicino in questo processo, così come sono coinvolti vari esperti di business. E questo viene fatto in modo selettivo. E non organizzando incontri con un numero folle di persone, inviando enormi questionari, ecc.
L'analisi del business e del sistema di qualità è la chiave per costruire un modello di storage core. Devi capire molte cose: dove (in quali sistemi) i dati vengono generati, come sono organizzati, in quali processi aziendali circolano, ecc. L'analisi qualitativa non ha mai danneggiato alcun sistema. Piuttosto, al contrario, i problemi sorgono da "punti vuoti" nella nostra comprensione.

Lo sviluppo di un modello di dati non è un processo per inventare e inventare qualcosa di nuovo. In effetti, il modello dati in azienda esiste già. E il processo della sua progettazione è più simile a "scavi". Il modello viene delicatamente e accuratamente riportato alla luce dal "terreno" dei dati aziendali e vestito in una forma strutturata.

Mito 4. Nella nostra azienda, l'attività è così dinamica e tutto sta cambiando così rapidamente che è inutile per noi creare un modello: diventerà obsoleto prima di mettere in funzione questa parte del sistema.
In realtà. Ricordiamo che il fattore chiave nel core è la stabilità. E soprattutto la topologia del modello. Come mai? Perché è questa componente che è centrale e riguarda tutto il resto. La stabilità è anche un requisito per il modello del kernel. Se il modello diventa obsoleto troppo rapidamente, è stato progettato in modo errato. Per il suo sviluppo sono stati scelti approcci e “regole del gioco” sbagliati. È anche una questione di analisi qualitativa. Le entità chiave del modello aziendale cambiano molto raramente.
Ma se ci viene in mente di fare per un'azienda che vende, diciamo, dolciumi, invece della directory "Prodotti", fare "Dolci", "Torte" e "Torte". Quindi, quando la pizza appare nell'elenco delle merci, sì, dovrai inserire molti nuovi tavoli. Ed è solo una questione di approccio.

Mito 5. La creazione di un modello aziendale è un'attività molto seria, complessa e responsabile. Ed è spaventoso commettere un errore.
In realtà. Il modello principale, sebbene dovrebbe essere stabile, non è ancora "fuso in metallo". Come qualsiasi altra decisione progettuale, la sua struttura può essere rivista e modificata. Basta non dimenticare questa sua qualità. Ma questo non significa affatto che "non puoi respirare" su di esso. E questo non significa che le soluzioni temporanee e gli "stub" che dovrebbero essere pianificati per l'elaborazione siano inaccettabili.

Mito 6. Se disponiamo di una fonte di dati, ad esempio un sistema NSI (o un sistema di gestione dei dati anagrafici - MDM), allora dovrebbe corrispondere in modo positivo al modello aziendale (soprattutto se è stato progettato di recente e non ha avuto il tempo di acquisire “effetti collaterali”, “tradizioni” e costruzioni temporanee). Si scopre che per questo caso - non abbiamo bisogno di un modello di kernel?
In realtà. Sì, in questo caso, la costruzione del modello di storage core è notevolmente facilitata, perché seguiamo un modello concettuale ready-made di alto livello. Ma non è affatto escluso. Come mai? Perché quando si costruisce un modello di un determinato sistema, si applicano determinate regole: quali tipi di tabelle utilizzare (per ciascuna entità), come eseguire la versione dei dati, con quale granularità conservare la cronologia, quali meta-attributi (campi tecnici da utilizzare), ecc. .

Inoltre, non importa quanto sia meraviglioso e completo il sistema NSI e MDM di cui disponiamo, di norma, ci saranno sfumature associate all'esistenza di directory locali "più o meno le stesse" in altri sistemi contabili. E questo problema, che ci piaccia o no, dovrà essere risolto nell'archivio, perché qui vengono raccolti report e analisi.

Livello dati primario (o staging storicizzabile o livello operativo)

Su di esso è designato come livello dati primario. Il ruolo di questa componente: integrazione con i sistemi sorgente, caricamento e memorizzazione dei dati primari, nonché pulizia preliminare dei dati - verifica del rispetto delle regole di controllo logico-formato, fissate nel "contratto di interfaccia di interazione" con la sorgente.
Inoltre, questo componente risolve un compito molto importante per l'archiviazione - evidenziando il "true change delta" - indipendentemente dal fatto che la fonte consenta o meno di tenere traccia delle modifiche nei dati e come (con quale criterio possono essere "catturate") . Non appena i dati sono entrati in staging, il problema della selezione delta è già chiaro per tutti gli altri livelli, grazie alla marcatura con meta-attributi.

I dati in questo livello sono archiviati in strutture il più vicino possibile al sistema di origine, al fine di mantenere i dati primari il più vicino possibile alla loro forma originale. Un altro nome per questo componente è "livello operativo".
Perché non usare semplicemente il termine consolidato "messa in scena"? Il fatto è che prima, prima dell '"era dei big data e dei VLDB", lo spazio su disco era molto costoso e spesso i dati primari, se archiviati, erano solo per un periodo di tempo limitato. E spesso viene chiamato il nome "messa in scena". pulibile respingente.
Ora, la tecnologia ha fatto un passo avanti e possiamo permetterci non solo di archiviare tutti i dati primari, ma anche di storicizzarli con il grado di granularità che è solo possibile. Ciò non significa che non dobbiamo controllare la crescita dei dati e non elimina la necessità di gestire il ciclo di vita delle informazioni ottimizzando il costo di archiviazione dei dati, a seconda della "temperatura" di utilizzo - cioè spostando i "dati freddi", che sono meno richiesti, su supporti e piattaforme di archiviazione più economici.

Cosa ci dà la presenza della "messa in scena storica":

la possibilità di sbagliare (nelle strutture, negli algoritmi di trasformazione, nella granularità della conservazione dello storico) - avendo dati primari completamente storicizzabili nella zona di disponibilità dello storage, possiamo sempre ricaricare le nostre tabelle;
un'opportunità per pensare: possiamo prenderci il nostro tempo con lo sviluppo di un grande frammento del core in questa iterazione dello sviluppo del repository, perché nella nostra messa in scena, comunque, lo saranno, e con un orizzonte temporale uniforme (ci sarà un “punto di partenza della storia”);
la possibilità di analisi - salveremo anche quei dati che non sono più nella fonte - potrebbero essere sovrascritti lì, andare in archivio, ecc. – con noi rimangono disponibili per l'analisi;
la possibilità di un audit delle informazioni - grazie alle informazioni primarie più dettagliate, saremo quindi in grado di capire come ha funzionato il download per noi, che alla fine abbiamo ottenuto tali numeri (per questo, devi anche avere la marcatura con meta-attributi e i metadati corrispondenti su cui funziona il download - questo viene deciso a livello di servizio).

Quali difficoltà possono sorgere nella costruzione della "messa in scena storica":

sarebbe conveniente stabilire i requisiti per l'integrità transazionale di questo livello, ma la pratica dimostra che ciò è difficile da raggiungere (questo significa che in quest'area non garantiamo l'integrità referenziale delle tabelle padre e figlio) - l'allineamento dell'integrità si verifica nelle successive strati;
questo layer contiene volumi molto grandi (il più grande in storage - nonostante tutta la ridondanza delle strutture analitiche) - e bisogna essere in grado di gestire tali volumi - sia in termini di caricamento che in termini di interrogazioni (altrimenti si può seriamente degradare il prestazioni dell'intero storage).

Cos'altro si può dire di questo livello.
In primo luogo, se ci allontaniamo dal paradigma dei “processi di carico end-to-end”, allora la regola “la carovana si muove alla velocità dell'ultimo cammello” non funziona più per noi, o meglio, abbandoniamo il principio della “carovana” e passare al principio del "trasportatore": abbiamo preso i dati dalla fonte - inseriti nel tuo livello - pronti per prendere la porzione successiva. Significa che
1) non aspettiamo che l'elaborazione avvenga su altri livelli;
2) non dipendiamo dalla tempistica di fornitura dei dati da parte di altri sistemi.
In poche parole, pianifichiamo un processo di caricamento che prende i dati da un'origine attraverso un metodo di connessione specifico ad essa, controlla, estrae il delta e inserisce i dati nelle tabelle di destinazione di staging. E questo è tutto.

In secondo luogo, questi processi, a quanto pare, sono organizzati in modo molto semplice - si potrebbe dire banalmente, dal punto di vista logico. E questo significa che possono essere molto ben ottimizzati e parametrizzati, riducendo il carico sul nostro sistema e velocizzando il processo di connessione delle sorgenti (tempi di sviluppo).
Affinché ciò avvenga, è necessario conoscere molto bene le caratteristiche tecnologiche della piattaforma su cui funziona questo componente e quindi è possibile creare uno strumento molto efficace.

Strato di vetrine analitiche

Il livello Storefront (livello Data mart) è responsabile della preparazione e della fornitura dei dati agli utenti finali - persone o sistemi. A questo livello, vengono prese in considerazione il più possibile le esigenze del consumatore, sia logiche (concettuali) che fisiche. Il servizio dovrebbe fornire esattamente ciò che è necessario, né più né meno.

Se il consumatore è un sistema esterno, di norma determina le strutture dati di cui ha bisogno e le regole per la raccolta delle informazioni. Un buon approccio è quello in cui il consumatore è responsabile della corretta raccolta dei dati. Il data warehouse preparato, costituiva la vetrina, prevedeva la possibilità di raccolta dati incrementale (contrassegnamento con meta-attributi per la successiva selezione delle modifiche delta), e quindi il sistema del consumatore gestisce ed è responsabile di come utilizza questa vetrina. Ma ci sono delle particolarità: quando il sistema non ha un componente attivo per la raccolta dei dati, o è necessario un componente esterno che svolga una funzione integrativa, oppure lo storage fungerà da “piattaforma di integrazione” e garantirà il corretto caricamento incrementale dei dati più lontano – al di fuori del deposito. Qui emergono molte sfumature e le regole di interazione dell'interfaccia dovrebbero essere pensate e comprese da entrambe le parti (tuttavia, come sempre, quando si tratta di integrazione). Di norma, a tali vetrine viene applicata la pulizia/archiviazione di routine dei dati (raramente è necessario che questi "dati di transito" siano conservati per lungo tempo).

Di massima importanza in termini di compiti analitici sono le vetrine "per le persone" - più precisamente, per gli strumenti di BI con cui lavorano.
Tuttavia, esiste una categoria di "utenti particolarmente avanzati" - analisti, data scientist - che non necessitano né di strumenti di BI né di processi di routine per il riempimento di sistemi specializzati esterni. Hanno bisogno di una sorta di "vetrina comune" e "la propria sandbox", dove possono creare tabelle e trasformazioni a loro discrezione. In questo caso, la responsabilità del repository è garantire che questi data mart comuni siano popolati in conformità con le normative.
Separatamente, possiamo individuare tali consumatori come strumenti di data mining: analisi approfondita dei dati. Questi strumenti hanno i propri requisiti di preparazione dei dati e sono utilizzati anche dai data scientist. Per il repository, il compito si riduce, ancora una volta, a supportare il servizio per il download di alcune vetrine di un formato concordato.

Tuttavia, torniamo alle vetrine analitiche. Sono loro che interessano dal punto di vista dei progettisti di archiviazione in questo livello di dati.
A mio parere, il miglior approccio collaudato alla progettazione di data mart, per i quali quasi tutte le piattaforme BI sono ora "affilate", è l'approccio di Ralph Kimball. È conosciuto con il nome modellazione dimensionale – modellazione multidimensionale. Ci sono moltissime pubblicazioni su questo argomento. Ad esempio, le regole di base possono essere trovate nella pubblicazione. E, naturalmente, puoi consigliare dai guru della modellazione multivariata. Un'altra risorsa utile è Suggerimenti di Kimball.
L'approccio multidimensionale alla creazione di vetrine è stato descritto ed elaborato così bene - sia dagli evangelisti del metodo che dai principali fornitori di software - che non ha senso soffermarsi qui in dettaglio: la fonte originale è sempre preferibile.

Vorrei fare solo un'enfasi. "Reporting e analisi" è diverso. Esistono "rapporti pesanti": rapporti preordinati generati sotto forma di file e consegnati agli utenti tramite i canali di consegna forniti. E ci sono pannelli informativi - dashboard BI. Fondamentalmente, sono applicazioni web. E i requisiti di tempo di risposta di queste applicazioni sono gli stessi di qualsiasi altra applicazione web. Ciò significa che il normale tempo di aggiornamento per il pannello BI è di secondi, non di minuti. È importante tenerlo a mente quando si progetta una soluzione. Come raggiungere questo obiettivo? Metodo di ottimizzazione standard: esaminiamo da cosa è composto il tempo di risposta e cosa possiamo influenzare. Su cosa dedichi più tempo? Per la lettura fisica (disco) del database, per il trasferimento di dati in rete. Come ridurre la quantità di dati letti e trasmessi per richiesta? La risposta è ovvia e semplice: è necessario aggregare i dati o applicare un filtro su tabelle dei fatti di grandi dimensioni che partecipano alla query ed escludere l'unione di tabelle di grandi dimensioni (i riferimenti alle tabelle dei fatti dovrebbero passare solo attraverso le dimensioni).

A cosa serve la BI? Com'è conveniente? Perché il modello multivariato è efficace?
La BI consente all'utente di eseguire le cosiddette "interrogazioni ad hoc". Cosa significa? Ciò significa che non conosciamo esattamente la richiesta in anticipo, ma sappiamo quali indicatori in quali sezioni l'utente può richiedere. L'utente genera tale query selezionando i filtri BI appropriati. E il compito dello sviluppatore BI e del progettista della vetrina è garantire una tale logica operativa dell'applicazione in modo che i dati vengano filtrati o aggregati, evitando una situazione in cui vengono richiesti troppi dati e l'applicazione "si blocca". Solitamente si parte con cifre aggregate, per poi approfondire dati più dettagliati, ma lungo il percorso si impostano i filtri necessari.

Non è sempre sufficiente costruire semplicemente la "stella giusta" e ottenere una struttura conveniente per la BI. A volte è necessario applicare la denormalizzazione da qualche parte (guardando indietro a come influirà sul carico) e da qualche parte per creare vetrine e aggregati secondari. Da qualche parte per aggiungere indici o proiezioni (a seconda del DBMS).

Pertanto, attraverso "prove ed errori", è possibile ottenere una struttura ottimale per la BI, che terrà conto delle caratteristiche sia del DBMS che della piattaforma BI, nonché dei requisiti dell'utente per la presentazione dei dati.
Se prendiamo i dati dal "core", tale elaborazione delle vetrine sarà di natura locale, senza in alcun modo influire sulla complessa elaborazione dei dati primari ricevuti direttamente dai sistemi di origine: "spostiamo" i dati solo in un formato conveniente per BI. E possiamo permetterci di farlo molte volte, in modi diversi, secondo esigenze diverse. È molto più facile e veloce farlo sulla base dei dati del kernel piuttosto che assemblare dal "primario" (la cui struttura e le cui regole, come sappiamo, possono anche "fluttuare").

livello di servizio

Il livello di servizio ( - Livello di servizio) è responsabile dell'implementazione di funzioni comuni (di servizio) che possono essere utilizzate per elaborare i dati in vari livelli di archiviazione: gestione del carico, gestione della qualità dei dati, diagnosi dei problemi e strumenti di monitoraggio, ecc.
La presenza di questo livello garantisce trasparenza e flussi di dati strutturati nello storage.

Questo livello include due aree di archiviazione dei dati:

area dei metadati - utilizzata per il meccanismo di controllo del caricamento dei dati;
area della qualità dei dati - per implementare controlli di qualità dei dati off-line (ovvero quelli che non sono integrati direttamente nei processi ETL).

È possibile creare il processo di gestione del carico in diversi modi. Uno dei possibili approcci è questo: dividiamo l'intero set di tabelle di archiviazione in moduli. Solo le tabelle di un livello possono essere incluse in un modulo. Le tabelle incluse in ciascun modulo vengono caricate come parte di un processo separato. Chiamiamolo processo di controllo . L'avvio del processo di controllo è programmato. Il processo di controllo orchestra le chiamate ai processi atomici, ognuno dei quali carica una tabella di destinazione e contiene anche alcuni passaggi comuni.
Ovviamente, è sufficiente suddividere semplicemente le tabelle di staging in moduli - in base ai sistemi sorgente, o meglio ai loro punti di connessione. Ma per il kernel, questo è già più difficile da fare, perché. lì dobbiamo garantire l'integrità dei dati, il che significa che dobbiamo tenere conto delle dipendenze. Quelli. ci saranno conflitti che devono essere risolti. E ci sono diversi modi per risolverli.

Un punto importante nella gestione del carico è lo sviluppo di un approccio unificato alla gestione degli errori. Gli errori sono classificati in base al livello di criticità. Quando si verifica un errore critico, il processo dovrebbe interrompersi e il prima possibile, perché. il suo verificarsi indica un problema significativo che può portare al danneggiamento dei dati nell'archiviazione. Pertanto, la gestione del carico non riguarda solo l'avvio dei processi, ma anche l'arresto degli stessi, oltre a prevenire l'avvio prematuro (per errore).

Viene creata una speciale struttura di metadati per il funzionamento del livello di servizio. Quest'area memorizzerà informazioni sui processi di caricamento, set di dati caricati, checkpoint utilizzati per mantenere l'incremento (quale processo ha letto fino a quel punto) e altre informazioni di servizio necessarie per il funzionamento del sistema.
È importante notare che tutte le tabelle di destinazione in tutti i livelli sono contrassegnate da un insieme speciale di metacampi, uno dei quali è l'ID del processo che ha aggiornato questa stringa. Per le tabelle all'interno di un repository, questo contrassegno di processo consente un modo unificato per estrarre successivamente le modifiche delta. Quando si caricano i dati nel livello dati primario, la situazione è più complicata: l'algoritmo per l'estrazione del delta per diversi oggetti caricati può essere diverso. D'altra parte, la logica dell'elaborazione delle modifiche accettate e del loro rolling sulle tabelle di destinazione per il core e le vetrine è molto più complicata che per lo staging, dove tutto è abbastanza banale: è facile parametrizzare e pensare a passaggi tipici riutilizzabili (procedure ).

Non ho impostato qui il compito di coprire completamente questo argomento - l'organizzazione del caricamento - metto solo accenti a cui vale la pena prestare attenzione.
L'approccio di cui sopra è solo una delle opzioni. È abbastanza adattabile. E il suo "prototipo concettuale" era il trasportatore Toyota e il sistema "just-in-time". Quelli. ci stiamo allontanando dal paradigma diffuso del “caricamento notturno dei dati” esclusivamente, e stiamo caricando in piccole porzioni durante il giorno, poiché i dati sono pronti in varie fonti: quello che è arrivato è quello che è stato caricato. Allo stesso tempo, abbiamo molti processi paralleli in esecuzione. E la "coda calda" di nuovi dati "lampeggia" costantemente e dopo un po' si uniforma. Dobbiamo tenere conto di questa caratteristica. E, all'occorrenza, a formare “fette” vetrine personalizzate, dove tutto è già integro. Quelli. è impossibile raggiungere contemporaneamente efficienza e coerenza (integrità). Abbiamo bisogno di un equilibrio: da qualche parte una cosa è importante, da qualche altra parte.

È estremamente importante fornire mezzi di registrazione e monitoraggio. Una buona pratica consiste nell'utilizzare eventi tipizzati, in cui è possibile impostare parametri diversi e configurare un sistema di notifica, ovvero un abbonamento a determinati eventi. Perché è molto importante che quando è richiesto l'intervento dell'amministratore di sistema, ne venga a conoscenza il prima possibile e riceva tutte le informazioni diagnostiche necessarie. I registri possono essere utilizzati anche per l'analisi dei problemi post factum, nonché per indagare su incidenti di malfunzionamento del sistema, incl. qualità dei dati.

Progettazione e manutenzione di modelli di dati di magazzino

Perché è importante prestare attenzione alla progettazione di modelli di dati quando si sviluppa un sistema in cui è coinvolto un database (e soprattutto in un magazzino)? Perché non inserire semplicemente una serie di tabelle, ovunque, anche in un editor di testo? Perché abbiamo bisogno di queste immagini?
Stranamente, anche gli sviluppatori esperti sollevano tali domande.
In realtà, sì, nulla ti impedisce di disegnare le tabelle e iniziare a usarle. Se ... se allo stesso tempo nella testa (!) Lo sviluppatore ha un quadro generale armonioso della struttura che sta scolpendo. E se ci sono più sviluppatori? Ma cosa succede se qualcun altro utilizzerà queste tabelle? Ma cosa succede se il tempo passa: una persona lascia quest'area e poi torna ad essa?

È possibile capirlo senza un modello? Fondamentalmente, puoi. E per capirlo, e "stimare le immagini su un pezzo di carta" e "spazzare - sistemare" i dati. Ma è molto più semplice, più chiaro e più veloce utilizzare un artefatto già pronto: un modello di dati. E anche per capire la "logica della sua struttura" - cioè Sarebbe bello avere regole comuni del gioco.

E la cosa più importante non è nemmeno quella. Soprattutto, quando si progetta un modello, siamo costretti (semplicemente senza opzioni!) a studiare l'area tematica in modo più approfondito e approfondito, le caratteristiche della struttura dei dati e il loro utilizzo in vari casi aziendali. E quelle domande che facilmente “rifiuteremmo” in quanto complesse, “offuscate” lanciando i nostri segni, senza cercare di design modello - saremo costretti a impostare e decidere ora, in fase di analisi e progettazione, e non più tardi - quando costruiremo report e pensiamo a “come ridurre l'incompatibile” e “reinventare la ruota” ogni volta.

Questo approccio è una di quelle pratiche ingegneristiche che consentono di creare sistemi antifragili. Dal momento che sono comprensibili, trasparenti, facili da sviluppare e i loro “confini di fragilità” sono immediatamente visibili, è possibile valutare con maggiore precisione la “portata del disastro” quando emergono nuove esigenze e il tempo necessario per una riprogettazione (se necessaria).
Pertanto, il modello dei dati è uno dei principali artefatti che devono essere mantenuti durante lo sviluppo del sistema. In senso positivo, dovrebbe essere "sul tavolo" per ogni analista, sviluppatore, ecc. – tutti coloro che sono coinvolti in progetti di sviluppo del sistema.

La progettazione di modelli di dati è un argomento separato e molto ampio. Esistono due approcci principali alla progettazione dello storage.
L'approccio è buono per il kernel "relazione-entità" - quando si costruisce un modello normalizzato (3NF) sulla base dello studio dell'area disciplinare, più precisamente dell'area prescelta. Qui viene riprodotto lo stesso "modello aziendale" di cui si è parlato sopra.

Quando si progettano vetrine analitiche adatte modello multidimensionale . Questo approccio si presta bene alla comprensione degli utenti aziendali. questo è un modello semplice e conveniente per la percezione umana: le persone operano con concetti comprensibili e familiari delle metriche (indicatori) e delle sezioni in base alle quali vengono analizzate. E questo ci consente di costruire in modo semplice e chiaro il processo di raccolta dei requisiti: disegniamo una serie di "matrici di tagli e indicatori", comunicando con i rappresentanti di vari dipartimenti. E poi lo portiamo in una struttura - il "modello di analisi": formiamo il "bus di misurazione" e determiniamo i fatti che sono definiti su di esso. Lungo la strada, stiamo lavorando su gerarchie e regole di aggregazione.

Inoltre, è molto facile passare al modello fisico, aggiungendo elementi di ottimizzazione tenendo conto delle caratteristiche del DBMS. Ad esempio, per Oracle sarebbe il partizionamento, un insieme di indici e così via. Per Vertica verranno utilizzate altre tecniche: ordinamento, segmentazione, sezionamento.
Potrebbe essere necessaria anche una denormalizzazione speciale - quando introduciamo deliberatamente la ridondanza nei dati, grazie alla quale miglioriamo le prestazioni delle query, ma allo stesso tempo complichiamo l'aggiornamento dei dati (perché la ridondanza dovrà essere presa in considerazione e supportata durante il processo di caricamento dei dati). Forse, per migliorare le prestazioni, dovremo anche creare tabelle aggregate aggiuntive o utilizzare funzionalità DBMS aggiuntive come proiezioni in Vertica.

Quindi, quando modelliamo i dati di magazzino, risolviamo effettivamente diversi problemi:

il compito è costruire un modello concettuale (logico) del nucleo - analisi di sistema e business - studio dell'area disciplinare, approfondendo i dettagli e tenendo conto delle sfumature dei "dati in tempo reale" e del loro utilizzo nel business;
il compito di costruire un modello di analisi - e quindi un modello concettuale (logico) di vetrine;
il compito di costruire modelli fisici è la gestione della ridondanza dei dati, l'ottimizzazione tenendo conto delle caratteristiche del DBMS per le query e il caricamento dei dati.

Quando sviluppiamo modelli concettuali, potremmo non tenere conto delle caratteristiche di un particolare DBMS per il quale stiamo progettando una struttura di database. Inoltre, possiamo utilizzare un modello concettuale per crearne diversi fisici, per diversi DBMS.

Riassumiamo.

Un modello di dati non è un insieme di "belle immagini" e il processo di progettazione non è il processo di disegnarle. Il modello riflette la nostra comprensione dell'area tematica. E il processo della sua compilazione è il processo del suo studio e della sua ricerca. È qui che si perde tempo. E per niente “disegnare e colorare”.
Un modello di dati è un artefatto di progettazione, un modo per condividere le informazioni in modo strutturato tra i membri del team. Per fare ciò, deve essere comprensibile a tutti (questo è fornito dalla notazione e dalla spiegazione) e accessibile (pubblicato).
Il modello dati non viene creato una volta e congelato, ma viene creato e sviluppato nel processo di sviluppo del sistema. Noi stessi stabiliamo le regole per il suo sviluppo. E possiamo cambiarli se vediamo come renderli migliori, più semplici, più efficienti.
Il modello dati (fisico) consente di consolidare e utilizzare un insieme di best practices finalizzate all'ottimizzazione - ad es. utilizzare le tecniche che hanno già funzionato per questo DBMS.

Caratteristiche dei progetti di data warehouse

Soffermiamoci sulle caratteristiche dei progetti all'interno dei quali l'azienda costruisce e sviluppa data warehouse. E guardiamoli dal punto di vista dell'influenza dell'aspetto architettonico. Perché è importante costruire un'architettura per tali progetti, e fin dall'inizio. Ed è la presenza di un'architettura ben congegnata che offre flessibilità al progetto di data warehouse, consente di distribuire efficacemente il lavoro tra gli esecutori e rende anche più facile prevedere il risultato e rendere il processo più prevedibile.

Data Warehouse è un software personalizzato

Un data warehouse è sempre uno "sviluppo personalizzato", non una soluzione in scatola. Sì, esistono applicazioni BI specifiche del settore che includono un modello dati di riferimento, processi ETL preconfigurati da origini comuni (ad esempio sistemi ERP), un set di dashboard e report BI tipici. Ma in pratica, lo storage viene raramente implementato, come una "scatola". Lavoro con lo storage da circa 10 anni e non ho mai visto una storia del genere. Ci sono sempre sfumature associate alle caratteristiche uniche dell'azienda, sia nel panorama aziendale che IT. Pertanto, è alquanto avventato sperare che il "fornitore" che fornisce la soluzione fornisca l'architettura. L'architettura di tali sistemi spesso matura all'interno dell'organizzazione stessa. Oppure è formato da specialisti della società appaltatrice, che è l'appaltatore principale del progetto.

Il data warehouse è un progetto di integrazione

Il data warehouse carica ed elabora le informazioni da molti sistemi di origine. E per mantenere "relazioni amichevoli" con loro, devi essere estremamente attento con loro. Tra l'altro è necessario ridurre al minimo il carico sui sistemi sorgente, tenere conto delle finestre “disponibilità e inaccessibilità”, selezionare le interfacce di interazione tenendo conto della loro architettura, ecc. Quindi lo storage sarà in grado di raccogliere i dati il prima possibile e con la frequenza richiesta. In caso contrario, verrai "trasferito" su un circuito di backup, che non viene aggiornato con la frequenza più operativa.
Inoltre, va tenuto conto del "fattore umano". L'integrazione non è solo l'interazione delle macchine. È anche comunicazione tra le persone.

Data Warehouse è un progetto di squadra

In una grande azienda, un tale sistema può raramente essere eseguito da un solo team. Di norma, qui lavorano più squadre, ognuna delle quali risolve un problema specifico.

L'architettura dovrebbe fornire la possibilità di organizzare il proprio lavoro parallelo, mantenendone l'integrità ed evitando la duplicazione delle stesse funzionalità in luoghi diversi, da parte di persone diverse. Oltre a costi di manodopera non necessari, tale duplicazione può portare a discrepanze nei dati in un secondo momento.

Inoltre, quando così tante persone e team, spesso dispersi, sono coinvolti nel processo di sviluppo del sistema, sorge inevitabilmente la domanda: come costruire comunicazioni e interazione informativa tra di loro. Più approcci e pratiche standard e comprensibili vengono utilizzati, più facile, conveniente ed efficiente sarà impostare tale lavoro. E includendo vale la pena pensare alla composizione degli "artefatti di lavoro", tra i quali per i data warehouse n. 1 ci sono i modelli di dati (si veda la sezione precedente).

Il data warehouse ha una durata maggiore rispetto ad altri sistemi

Consentitemi di chiarire: l'affermazione è vera per un archivio "live", funzionante, integrato con fonti chiave, in possesso di dati storici e che fornisce informazioni e servizi analitici a molte divisioni dell'azienda.

Che motivi ho per crederlo?
In primo luogo, la costruzione di uno storage è un processo molto dispendioso in termini di risorse: oltre ai costi effettivi delle apparecchiature, alle licenze per il software tecnologico necessario e allo sviluppo, sono coinvolti anche quasi tutti i sistemi e le divisioni dell'azienda. Ripetere l'intero processo da zero è un'impresa molto audace.

In secondo luogo, se lo storage ha l'architettura giusta, può facilmente sopravvivere sia al cambiamento dei sistemi di origine, all'emergere di nuovi requisiti da parte degli utenti finali, sia alla crescita dei volumi di dati.
Se l'architettura è corretta, i flussi informativi sono trasparenti, allora un tale sistema può essere sviluppato per lungo tempo senza il rischio di trovarsi in una situazione di stupore quando si apportano modifiche per difficoltà di valutazione dell'impatto.

Sviluppo iterativo graduale

L'ultima cosa che il cliente vorrebbe, essendo coinvolto nella storia con lo storage, è di congelare i suoi requisiti per un anno o due, fino a quando non viene progettato il modello di dati aziendale completo, tutte le fonti sono completamente collegate, ecc.

Il data warehouse agli occhi dei Clienti sembra spesso un mostro assoluto: i compiti, gli obiettivi e l'orizzonte di sviluppo del sistema sono così voluminosi. E spesso il Cliente ha paura che “a spese del suo budget” il reparto IT risolva alcuni “propri compiti”. E ancora, ci troviamo di fronte al problema dell'interazione tra le persone e della capacità di affermare con calma la propria posizione e di negoziare.

Approcci architetturali competenti consentono di sviluppare il sistema in modo iterativo, aumentando gradualmente le funzionalità, senza andare in “sviluppo” per diversi anni prima di iniziare a dare risultati.

Anche se va notato che "i miracoli non accadono" - e anche l'"inizio" richiede tempo. Per gli archivi, può essere piuttosto grande - poiché si tratta di grandi quantità di dati, si tratta di dati storici - per vecchi periodi in cui le regole per l'elaborazione delle informazioni potrebbero differire da quelle attuali. Pertanto, è necessario tempo sufficiente per lo sviluppo analitico, l'interazione con i sistemi sorgente e una serie di "prove ed errori", compresi i test di carico su dati reali.

Data Warehouse - "storia multiprogetto"

È difficile individuare un singolo cliente aziendale per un data warehouse. E si ritiene (non a caso) che il fattore chiave per il successo del progetto di stoccaggio sia il supporto del management dell'azienda, direttamente in prima persona.
Raramente un repository viene creato e sviluppato all'interno di un singolo progetto. Di norma, ci sono varie esigenze di consolidamento e analisi dei dati, dietro di esse ci sono diversi Clienti e gruppi di utenti. Pertanto, il repository viene spesso sviluppato nell'ambito di diversi progetti paralleli.

Equilibrio tra innovazione e soluzioni collaudate

Nonostante il fatto che il tema dell'archiviazione sia molto "antico" (se una parola del genere è applicabile a un settore così giovane come l'IT) e piuttosto conservatore. Tuttavia, i progressi non si fermano e le limitazioni che esistevano in precedenza a causa di dischi costosi e lenti, memoria costosa, ecc. - sono ora rimossi. E allo stesso tempo, è tempo di riconsiderare alcuni approcci architettonici. Ciò vale, inoltre, sia per le piattaforme tecnologiche sia per l'architettura dei sistemi applicati che su di esse si basano.

È importante trovare un equilibrio qui - e mantenere un approccio abbastanza "verde" sia alle risorse che alle informazioni archiviate. Altrimenti, puoi trasformare molto rapidamente il repository in un "discarica di rifiuti" semi-strutturato, che, se può essere risolto, richiederà un notevole sforzo.
Sì, abbiamo più opportunità, ma questo non significa che dobbiamo smentire tutte le pratiche che sono state sviluppate e sperimentate dal tempo, che sono chiare come e perché utilizzare, e "abbandonarsi a tutto seri" guidati solo dal nebbioso fantasma di “innovazione”.
Mantenere un equilibrio significa utilizzare nuovi metodi e approcci in cui si aprono nuove opportunità, ma allo stesso tempo utilizzare vecchi collaudati per risolvere problemi urgenti che nessuno ha cancellato.
Cosa possiamo fare come sviluppatori e progettisti di soluzioni applicate? Innanzitutto conoscere e comprendere i cambiamenti tecnologici delle piattaforme su cui lavoriamo, le loro capacità, caratteristiche e limiti di applicazione.

Diamo un'occhiata al DBMS, come la piattaforma tecnologica più critica e importante per lo storage.
Di recente, c'è stata una chiara deriva dei database relazionali, originariamente creati come "universali", verso la specializzazione. Per molto tempo, i principali fornitori hanno rilasciato varie opzioni, per applicazioni di classi diverse (OLTP, DSS e DWH). Inoltre, ci sono ulteriori opportunità per lavorare con testo, dati geografici, ecc.

Ma la questione non si limitava a questo: cominciarono ad apparire prodotti inizialmente incentrati su una certa classe di compiti, ad es. DBMS specializzato. Possono o meno utilizzare il modello relazionale. L'importante è che siano inizialmente "affilati" non solo per l'archiviazione e l'elaborazione di "informazioni commerciali" in generale, ma per determinati compiti.

A quanto pare, centralizzazione e specializzazione sono due tendenze complementari che periodicamente si sostituiscono, garantendo sviluppo ed equilibrio. Così come lo sviluppo graduale (graduale) evolutivo e i cambiamenti cardinali. Quindi, negli anni '90, Michael Stonebreaker è stato uno degli autori del Manifesto dei database di terza generazione, che esprimeva chiaramente l'idea che il mondo non avesse bisogno di un'altra rivoluzione nel mondo dei database. Tuttavia, 10 anni dopo, pubblica opere in cui annuncia i presupposti per l'inizio di una nuova era nel mondo dei DBMS, proprio in base alla loro specializzazione.
Si concentra sul fatto che i DBMS universali diffusi sono costruiti su un'architettura "taglia unica" che non tiene conto dei cambiamenti nelle piattaforme hardware o della divisione delle applicazioni in classi per le quali è possibile trovare una soluzione migliore di l'attuazione di requisiti universali.
E inizia a sviluppare una serie di progetti secondo questa idea. Uno di questi è C-Store, un DBMS colonnare progettato nell'architettura Shared Nothing (SN), originariamente creato appositamente per i sistemi di classe di archiviazione dati. Questo prodotto è stato ulteriormente commercializzato come HP Vertical.

Sembra che ora il tema dello sviluppo dei data warehouse sia scivolato in un nuovo ciclo di sviluppo. Stanno emergendo nuove tecnologie, approcci e strumenti. Il loro studio, test e ragionevole applicazione ci consentono di creare soluzioni davvero interessanti e utili. E portali all'attuazione, godendoti il fatto che i tuoi sviluppi siano utilizzati nel lavoro reale e portino benefici.

Epilogo

Nella preparazione di questo articolo ho cercato di concentrarmi principalmente su architetti, analisti e sviluppatori che lavorano direttamente con i data warehouse. Ma si è scoperto che inevitabilmente "ho preso l'argomento un po 'più ampio" - e altre categorie di lettori sono cadute nel campo visivo. Alcuni punti sembreranno controversi, altri non chiari, altri ovvi. Le persone sono diverse, con esperienze, background e posizioni diverse.
Ad esempio, le domande tipiche dei manager sono "quando attirare gli architetti?", "Quando dovrei fare architettura?", "Architettura, non sarà troppo costosa?" suona piuttosto strano per noi (sviluppatori, designer), perché per noi l'architettura del sistema appare con la sua nascita - non importa se ce ne rendiamo conto o meno. E anche se non c'è un ruolo formale di un architetto nel progetto, un normale committente “accende sempre il suo architetto interno”.

Nel grande schema delle cose, non importa chi sia l'architetto, ciò che conta è che qualcuno faccia queste domande ed esplori le risposte. Se l'architetto è chiaramente individuato, significa solo che è il primo responsabile del sistema e del suo sviluppo.
Perché il tema dell'“antifragilità” mi è sembrato rilevante in relazione a questo argomento?

"L'unicità dell'antifragilità è che ci permette di lavorare con l'ignoto, di fare qualcosa in condizioni in cui non capiamo esattamente cosa stiamo facendo e di avere successo"/Nassim N.Taleb/

Pertanto, la crisi e un alto grado di incertezza non sono una scusa per la mancanza di architettura, ma fattori che ne rafforzano la necessità.