{"id":92015,"date":"2020-08-21T19:42:13","date_gmt":"2020-08-21T17:42:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh"},"modified":"2020-08-21T19:42:13","modified_gmt":"2020-08-21T17:42:13","slug":"obzor-gibkih-metodologij-proektirovaniya-dwh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"Panoramica delle metodologie flessibili per la progettazione DWH","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Lo sviluppo di un data warehouse \u00e8 un'impresa lunga e seria. <\/p>\n<p>Molto nella vita di un progetto dipende da quanto bene \u00e8 pensato il modello degli oggetti e la struttura del database sin dall'inizio.<\/p>\n<p>Il metodo comunemente adottato rimane un mix di schemi a \"stella\" con la terza forma normale. In genere, secondo il principio: dati sorgente \u2014 3NF, data mart \u2014 stella. Questo approccio, ampiamente testato nel tempo e supportato da numerosi studi, \u00e8 il primo (e a volte l'unico) pensiero di un esperto DWH quando si tratta di concepire come dovrebbe apparire un data warehouse analitico.<\/p>\n<p>D'altra parte, le esigenze del business generalmente e quelle dei clienti in particolare tendono a cambiare rapidamente, e i dati non smettono di crescere sia \u201cin profondit\u00e0\u201d che \u201cin ampiezza\u201d. Qui emerge il principale svantaggio dello schema a stella: la sua limitatezza. <b>flessibilit\u00e0<\/b>.<\/p>\n<p>E se nella vostra vita tranquilla e serena di sviluppatore DWH si presenta all'improvviso:<\/p>\n<ul>\n<li>la necessit\u00e0 di \"fare qualcosa in fretta, poi vedremo\";<\/li>\n<li>un progetto in rapida espansione, con l'integrazione di nuove fonti e la modifica del modello di business almeno una volta alla settimana;<\/li>\n<li>\u00e8 comparso un cliente che non ha idea di come dovrebbe apparire il sistema e quali funzioni dovrebbe svolgere alla fine, ma \u00e8 disposto a sperimentare e a chiarire progressivamente il risultato desiderato avvicinandosi ad esso con gradualit\u00e0;<\/li>\n<li>\u00e8 stato da noi un manager di progetto con una lieta notizia: \u201cE ora abbiamo l'agile!\u201d.<\/li>\n<\/ul>\n<p>\nOppure se siete semplicemente curiosi di scoprire altri modi di costruire archivi \u2014 benvenuti sotto il cat!<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/59cd70ca3af4841d0c5c9bfbbd7636a3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Cosa significa 'flessibilit\u00e0'<\/h3>\n<p>\nIniziamo definendo quali caratteristiche deve avere un sistema per potersi definire 'flessibile'. <\/p>\n<p>Vale la pena sottolineare che le propriet\u00e0 descritte devono riferirsi specificamente a <b>un sistema<\/b>, e non a <b>un processo <\/b>la sua sviluppo. Pertanto, se volevate leggere su Agile come metodologia di sviluppo, \u00e8 meglio consultare altri articoli. Ad esempio, qui su Habr ci sono molti materiali interessanti (come <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">rassegnati<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">pratici<\/a><\/noindex>, sia <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problematici<\/a><\/noindex>).<\/p>\n<p>Questo non significa che il processo di sviluppo e la struttura del Data Warehouse non siano affatto correlati. In generale, sviluppare un repository di architettura flessibile seguendo il modello Agile dovrebbe essere sostanzialmente pi\u00f9 facile. Tuttavia, nella pratica, si incontrano pi\u00f9 frequentemente casi di sviluppo di un DWH tradizionale basato su Agile secondo Kimball e DataVault \u2014 secondo il waterfall, piuttosto che fortunate coincidenze di flessibilit\u00e0 in entrambe le sue forme in un unico progetto.<\/p>\n<p>Quindi, quali sono le caratteristiche che un repository flessibile dovrebbe possedere? Possiamo evidenziare tre punti:<\/p>\n<ol>\n<li><b>Consegna precoce e rapida modifica<\/b> \u2014 questo significa che idealmente il primo risultato di business (ad esempio, i primi report funzionanti) dovrebbe essere ottenuto il prima possibile, cio\u00e8 ancora prima che il sistema sia completamente progettato e implementato. Inoltre, ogni successiva modifica dovrebbe richiedere il minor tempo possibile.<\/li>\n<li><b>Modifica iterativa<\/b> \u2014 significa che ogni successivo sviluppo non dovrebbe idealmente influenzare le funzionalit\u00e0 gi\u00e0 funzionanti. Questo aspetto si trasforma spesso nel maggior incubo nei grandi progetti: prima o poi, singoli elementi iniziano ad avere cos\u00ec tante interconnessioni che diventa pi\u00f9 semplice replicare completamente la logica accanto, piuttosto che aggiungere un campo nella tabella esistente. E se vi sorprende che l'analisi dell'impatto di un'evoluzione su oggetti esistenti possa richiedere pi\u00f9 tempo dello sviluppo stesso, \u00e8 probabile che non abbiate ancora lavorato con grandi HD in ambito bancario o telecomunicazioni.<\/li>\n<li><b>Adattamento costante ai requisiti aziendali in evoluzione<\/b> \u2014 la struttura generale degli oggetti deve essere progettata non solo tenendo conto di un possibile ampliamento, ma anche prevedendo che la direzione di questo prossimo ampliamento non poteva nemmeno venirvi in mente nella fase di progettazione.<\/li>\n<\/ol>\n<p>\nE s\u00ec, soddisfare tutti questi requisiti all'interno di un unico sistema \u00e8 possibile (ovviamente, in determinati casi e con alcune riserve).<\/p>\n<p>Di seguito esplorer\u00f2 due delle metodologie di progettazione agili pi\u00f9 popolari per HD \u2014 <b>Modulo Anchor<\/b> e <b>Data Vault<\/b>. Rimangono fuori tecniche affascinanti come EAV, 6NF (nella sua forma pura) e tutto ci\u00f2 che riguarda le soluzioni NoSQL - non perch\u00e9 siano in qualche modo inferiori, n\u00e9 perch\u00e9 in questo caso l'articolo rischierebbe di diventare lungo come una tesi di laurea media. Semplicemente, tutto ci\u00f2 appartiene a soluzioni di un'altra categoria - o a tecniche che possono essere applicate in casi specifici, indipendentemente dall'architettura generale del vostro progetto (come EAV), o a paradigmi di archiviazione delle informazioni globalmente diversi (come ad esempio i database a grafo e altre opzioni NoSQL).<\/p>\n<h3>Problemi del approccio \u201cclassico\u201d e le loro soluzioni nelle metodologie agili<\/h3>\n<p>\n<i>Con approccio \u201cclassico\u201d intendo la vecchia cara stella (indipendentemente dalla specifica implementazione dei livelli sottostanti, che i seguaci di Kimball, Inmon e CDM mi perdonino).<br \/>\n<\/i><\/p>\n<h4>1. Cardinalit\u00e0 rigida delle relazioni<\/h4>\n<p>\nAlla base di questo modello c'\u00e8 una chiara separazione dei dati in <b>dimensioni (Dimension)<\/b> e <b>fatti (Fact)<\/b>. E questo, diamine, ha senso \u2014 poich\u00e9 l'analisi dei dati si riduce nella stragrande maggioranza dei casi all'analisi di specifici indicatori numerici (fatti) in determinati contesti (dimensioni).<\/p>\n<p>In questo caso, le relazioni tra gli oggetti sono stabilite sotto forma di legami tra le tabelle tramite chiavi esterne. Questo appare del tutto naturale, ma porta immediatamente al primo vincolo di flessibilit\u00e0 \u2014 <b>una rigorosa definizione della cardinalit\u00e0 delle relazioni<\/b>.<\/p>\n<p>Ci\u00f2 significa che nella fase di progettazione delle tabelle devi determinare con precisione se ogni coppia di oggetti correlati possa essere considerata come molti-a-molti, oppure solo 1-a-molti, e 'in quale direzione'. Questo influir\u00e0 direttamente su quale tabella conterr\u00e0 la chiave primaria e quale la chiave esterna. Una modifica di questa relazione in seguito a nuovi requisiti con alta probabilit\u00e0 porter\u00e0 a una revisione del database.<\/p>\n<p>Ad esempio, progettando l'oggetto 'scontrino', ti sei basato sulle assicuratissime affermazioni del reparto vendite per prevedere la possibilit\u00e0 di un'azione <b>di una promozione su pi\u00f9 posizioni dello scontrino<\/b> (ma non viceversa):<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDopo un po', i colleghi hanno introdotto una nuova strategia di marketing, in cui possono concorrere <b>pi\u00f9 promozioni contemporaneamente<\/b>. Ora \u00e8 necessario rielaborare le tabelle, evidenziando il legame in un oggetto separato. <\/p>\n<p>(Tutti gli oggetti derivati in cui avviene il check di join sulle promozioni necessitano ora di una revisione).<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Relazioni nel Data Vault e Modello Anchor<\/b><\/p>\n<p>Evitare tale situazione \u00e8 risultato piuttosto semplice: non bisogna fidarsi del reparto vendite, \u00e8 sufficiente <b>memorizzare tutte le relazioni inizialmente in tabelle separate<\/b> e gestirle come molti-a-molti. <\/p>\n<p>Questo approccio \u00e8 stato proposto <b>da Dan Linstedt<\/b> come parte della paradigmi <b>Data Vault<\/b> ed \u00e8 stato completamente supportato <b>da Lars R\u00f6nnb\u00e4ck<\/b> in <b>del Modello Anchor<\/b>.<\/p>\n<p>Di conseguenza, otteniamo la prima caratteristica distintiva delle metodologie agili:<\/p>\n<blockquote><p>Le relazioni tra gli oggetti non sono memorizzate negli attributi delle entit\u00e0 genitrici, ma rappresentano un tipo separato di oggetti.<\/p><\/blockquote>\n<p>In <b>Data Vault<\/b> Tali tabelle di legame sono chiamate <b>Link<\/b>, e nella <b>Modello Anchor<\/b> \u2014 <b>Tie<\/b>. A prima vista sembrano molto simili, ma le loro differenze non si esauriscono nel nome (di cui si parler\u00e0 pi\u00f9 avanti). In entrambe le architetture, le tabelle di collegamento possono connettere <b>un numero qualsiasi di entit\u00e0<\/b> (non necessariamente 2).<\/p>\n<p>Questa apparente ridondanza offre una notevole flessibilit\u00e0 nelle modifiche. Tale struttura diventa tollerante non solo ai cambiamenti delle cardinalit\u00e0 delle relazioni esistenti, ma anche all'aggiunta di nuove: se ora un articolo di scontrino avr\u00e0 un link al cassiere che lo ha registrato, l'emergere di tale collegamento diventer\u00e0 solo un'estensione delle tabelle esistenti senza influire su oggetti e processi attualmente esistenti.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Duplicazione dei dati<\/h4>\n<p>\nIl secondo problema affrontato dalle architetture flessibili \u00e8 meno ovvio e caratteristico, principalmente <b>delle misure di tipo SCD2<\/b> (dimensioni lentamente mutevoli di secondo tipo), anche se non solo di esse.<\/p>\n<p>In un classico data warehouse, una dimensione \u00e8 solitamente rappresentata da una tabella che contiene una chiave surrogata (come PK) e anche un insieme di chiavi aziendali e attributi in colonne separate. <\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe la misura supporta la versioning, al set standard di campi vengono aggiunti i confini temporali della versione, e in una riga della fonte appaiono pi\u00f9 versioni nel repository (una per ogni modifica degli attributi di versioning).<\/p>\n<p>Se la misura contiene almeno un attributo di versioning frequentemente modificato, il numero di versioni di tale misura sar\u00e0 notevole (anche se gli altri attributi non sono versionati, o non vengono mai modificati), e se ci sono pi\u00f9 di tali attributi, il numero di versioni pu\u00f2 crescere in progressione geometrica in base al loro numero. Tale misura pu\u00f2 occupare una quantit\u00e0 sostanziale di spazio su disco, anche se la maggior parte dei dati memorizzati consiste semplicemente in duplicati dei valori degli attributi immutabili di altre righe.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA tale proposito, si applica molto frequentemente anche <b>denormalizzazione<\/b> \u2014 parte degli attributi viene intenzionalmente memorizzata come valore, non come riferimento a un dizionario o ad un'altra misura. Questo approccio accelera l'accesso ai dati, riducendo il numero di join quando si accede alla misura.<\/p>\n<p>In genere, ci\u00f2 porta a <b>la stessa informazione \u00e8 memorizzata contemporaneamente in pi\u00f9 posti<\/b>. Ad esempio, le informazioni sulla regione di residenza e sulla categoria del cliente possono essere memorizzate simultaneamente nelle misurazioni \u201cCliente\u201d e nei fatti \u201cAcquisto\u201d, \u201cConsegna\u201d e \u201cRichieste al call center\u201d, cos\u00ec come nella tabella di collegamento \u201cCliente \u2014 Manager del cliente\u201d.<\/p>\n<p>In generale, quanto descritto sopra si applica anche alle misurazioni normali (non versionate), ma nelle versionate pu\u00f2 avere un'altra portata: l'emergere di una nuova versione dell'oggetto (soprattutto retroattivamente) non porta semplicemente all'aggiornamento di tutte le tabelle correlate, ma a un'emergenza a cascata di nuove versioni di oggetti correlati \u2014 quando la Tabella 1 \u00e8 utilizzata nella costruzione della Tabella 2, e la Tabella 2 \u00e8 utilizzata nella costruzione della Tabella 3, ecc. Anche se nessun attributo della Tabella 1 partecipa alla costruzione della Tabella 3 (ma partecipano altri attributi della Tabella 2, ottenuti da altre fonti), l'aggiornamento versionato di questa struttura comporter\u00e0 almeno costi aggiuntivi, e al massimo versioni inutili nella Tabella 3, che qui \u00e8 del tutto \u201cnon pertinente\u201d e cos\u00ec via nella catena.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Complessit\u00e0 non lineare nell'implementazione<\/h4>\n<p>\nOgni nuova vetrina, costruita sulla base di un'altra, aumenta il numero di punti in cui i dati possono 'divergere' quando si apportano modifiche all'ETL. Questo, a sua volta, porta a un aumento della complessit\u00e0 (e della durata) di ogni successiva modifica.<\/p>\n<p>Se quanto descritto sopra riguarda sistemi con processi ETL raramente modificati, vivere in tale paradigma \u00e8 possibile: basta prestare attenzione affinch\u00e9 le nuove modifiche vengano applicate correttamente a tutti gli oggetti collegati. Tuttavia, se le modifiche avvengono frequentemente, la probabilit\u00e0 di 'perdere' accidentalmente alcune connessioni aumenta significativamente.<\/p>\n<p>Se poi si considera che l'ETL 'versionato' \u00e8 sostanzialmente pi\u00f9 complesso rispetto a quello 'non versionato', evitare errori durante le modifiche frequenti diventa piuttosto difficile.<\/p>\n<h3>Archiviazione degli oggetti e attributi nel Data Vault e Anchor Model<\/h3>\n<p>\nL'approccio proposto dagli autori delle architetture flessibili pu\u00f2 essere formulato come segue:<\/p>\n<blockquote><p>\u00c8 necessario separare ci\u00f2 che cambia da ci\u00f2 che rimane invariato. Vale a dire, archiviare le chiavi separatamente dagli attributi.<\/p><\/blockquote>\n<p> Tuttavia, non bisogna confondere <b>non versionato<\/b> attributo con <b>immutabile<\/b>: il primo non conserva la cronologia delle sue modifiche, ma pu\u00f2 cambiare (ad esempio, in caso di correzione di un errore di input o ricezione di nuovi dati) il secondo - non cambia mai.<\/p>\n<p>Le opinioni su cosa si possa considerare immutabile nel Data Vault e nel modello Anchor divergono.<\/p>\n<p>Dal punto di vista architettonico <b>Data Vault<\/b>, si pu\u00f2 considerare immutabile <b>l'intero insieme di chiavi<\/b> \u2014 naturali (Codice Fiscale dell'organizzazione, codice prodotto nel sistema sorgente, ecc.) e surrogate. In questo caso, gli altri attributi possono essere divisi in gruppi in base alla fonte e\/o alla frequenza delle modifiche e <b>per ogni gruppo mantenere una tabella separata<\/b> con un insieme di versioni indipendente.<\/p>\n<p>Nella parbidigma <b>Anchor Model<\/b> si considera immutabile <b>solo la chiave surrogata<\/b> dell'entit\u00e0. Tutto il resto (inclusi i tasti naturali) \u00e8 semplicemente un caso particolare dei suoi attributi. In questo senso <b>tutti gli attributi per impostazione predefinita sono indipendenti l'uno dall'altro<\/b>, pertanto per ogni attributo deve essere creata <b>una tabella separata<\/b>.<\/p>\n<p>In <b>Data Vault<\/b> le tabelle contenenti le chiavi delle entit\u00e0 sono chiamate <b>Hub<\/b>. Gli Hub contengono sempre un insieme fisso di campi:<\/p>\n<ul>\n<li>Chiavi naturali dell'entit\u00e0<\/li>\n<li>Chiave surrogata<\/li>\n<li>Riferimento alla fonte<\/li>\n<li>Tempo di aggiunta della registrazione<\/li>\n<\/ul>\n<p>\nLe registrazioni negli Hub <b>non cambiano mai e non hanno versioni<\/b>. Esternamente, gli hub assomigliano molto a tabelle di tipo ID-map, utilizzate in alcuni sistemi per generare surrogate, tuttavia, per le surrogate nel Data Vault si raccomanda di utilizzare non una sequenza intera, ma un hash basato su un insieme di chiavi di business. Questo approccio semplifica il caricamento delle relazioni e degli attributi dalle fonti (non \u00e8 necessario unire gli hub per ottenere la surrogata, basta calcolare l'hash della chiave naturale), ma pu\u00f2 causare altri problemi (legati, ad esempio, a collisioni, maiuscole e caratteri non stampabili nelle chiavi stringa, ecc.), quindi non \u00e8 universalmente accettato.<\/p>\n<p>Tutti gli altri attributi delle entit\u00e0 sono memorizzati in tabelle speciali, chiamate <b>Satellite (Satellit)<\/b>. Un hub pu\u00f2 avere pi\u00f9 satelliti che memorizzano diversi insiemi di attributi.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa distribuzione degli attributi tra i satelliti avviene secondo il principio di <b>cambiamento congiunto<\/b> \u2014 in un satellite possono essere memorizzati attributi non versionati (ad esempio, la data di nascita e il codice fiscale per le persone fisiche), in un altro quelli versionati che cambiano raramente (come il cognome e il numero del passaporto), in un terzo quelli che cambiano frequentemente (per esempio, l'indirizzo di spedizione, la categoria, la data dell'ultimo ordine, ecc.). La versioning \u00e8 gestita a livello di singoli satelliti e non dell'entit\u00e0 nel suo complesso, pertanto \u00e8 opportuno distribuire gli attributi in modo tale che l'intersezione delle versioni all'interno di uno stesso satellite sia minima (riducendo il numero totale delle versioni memorizzate). <\/p>\n<p>Inoltre, per ottimizzare il processo di caricamento dei dati, gli attributi provenienti da diverse fonti vengono spesso estratti in satelliti separati.<\/p>\n<p>I satelliti sono collegati al Hub tramite <b>chiave esterna<\/b> (che corrisponde a una cardinalit\u00e0 1-a-molti). Questo significa che valori multipli di un attributo (ad esempio, diversi numeri di telefono di un singolo cliente) sono supportati da questa architettura 'per impostazione predefinita'.<\/p>\n<p>In <b>Modello Anchor<\/b> le tabelle che memorizzano le chiavi sono chiamate <b>Ancora<\/b>. E memorizzano: <\/p>\n<ul>\n<li><b>Solo chiavi surrogate<\/b><\/li>\n<li>Riferimento alla fonte<\/li>\n<li>Tempo di aggiunta della registrazione<\/li>\n<\/ul>\n<p>\nLe chiavi naturali, secondo il Modello Anchor, sono considerate <b>attributi comuni<\/b>. Questa opzione pu\u00f2 sembrare pi\u00f9 complessa da comprendere, ma offre sicuramente maggiore libert\u00e0 per l'identificazione dell'oggetto.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAd esempio, se i dati relativi alla stessa entit\u00e0 possono provenire da sistemi diversi, ognuno dei quali utilizza la propria chiave naturale. Nel Data Vault ci\u00f2 pu\u00f2 portare a costruzioni piuttosto ingombranti che comprendono pi\u00f9 hub (uno per fonte + una versione master unificata), mentre nel modello Anchor la chiave naturale di ciascuna fonte entra nel proprio attributo e pu\u00f2 essere utilizzata al caricamento indipendentemente da tutti gli altri. <\/p>\n<p>Ma qui si nasconde un punto insidioso: se in un'unica entit\u00e0 si uniscono attributi provenienti da sistemi diversi, \u00e8 probabile che esistano alcune <b>regole di 'fusion\u00e8<\/b>, secondo cui il sistema deve comprendere che i record provenienti da fonti diverse corrispondono a un'unica istanza dell'entit\u00e0. <\/p>\n<p>In <b>Data Vault<\/b> Queste regole probabilmente determineranno la formazione di <b>un 'hub surrogato' dell'entit\u00e0 master<\/b> e non influenzare i Hub, che memorizzano le chiavi naturali delle fonti e i loro attributi originali. Se in qualche momento le regole di fusione cambiano (o arriva un aggiornamento degli attributi secondo cui avviene), sar\u00e0 sufficiente riformare i hub surrogati.<\/p>\n<p>In <b>Modello ancorato<\/b> tale entit\u00e0 sar\u00e0 probabilmente memorizzata in <b>un unico ancoraggio<\/b>. Questo significa che tutti gli attributi, indipendentemente dalla fonte di provenienza, saranno legati allo stesso surrogato. Separare le registrazioni erroneamente fuse e monitorare l'attualit\u00e0 della fusione in un sistema del genere potrebbe risultare notevolmente pi\u00f9 difficile, soprattutto se le regole sono abbastanza complesse e cambiano frequentemente, e lo stesso attributo potrebbe provenire da diverse fonti (anche se \u00e8 possibile, poich\u00e9 ogni versione dell'attributo mantiene un riferimento alla propria sorgente).<\/p>\n<p>In ogni caso, se nella vostra sistema \u00e8 prevista l'implementazione di funzionalit\u00e0 <b>di deduplicazione, fusione di registri e altri elementi MDM<\/b>, \u00e8 particolarmente importante fare attenzione agli aspetti di conservazione delle chiavi naturali nelle metodologie agili. \u00c8 probabile che una struttura pi\u00f9 complessa come il Data Vault si dimostri improvvisamente pi\u00f9 sicura in termini di errori di fusione.<\/p>\n<p><b>Modello ancorato<\/b> prevede anche un tipo aggiuntivo di oggetto chiamato <b>Nodo (Knot)<\/b> fondamentalmente \u00e8 un tipo speciale <b>di ancoraggio degenerato<\/b>, che pu\u00f2 contenere solo un attributo. I nodi sono pensati per l'archiviazione di dizionari piatti (ad esempio sesso, stato civile, categoria di assistenza ai clienti, ecc.). A differenza dell'ancora, il nodo <b>non ha tabelle di attributi correlate<\/b>, e il suo unico attributo (nome) \u00e8 sempre conservato nella stessa tabella con la chiave. I nodi sono collegati agli ancoraggi tramite tabelle di relazione (Tie) proprio come gli ancoraggi tra di loro.<\/p>\n<p>Non esiste un'opinione univoca sull'uso dei nodi. Ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolai Golov<\/a><\/noindex>, che promuove attivamente l'uso del modello ancorato in Russia, ritiene (non senza fondamento) che non si possa affermare con certezza per nessun dizionario che esso <b>sempre<\/b> sar\u00e0 statico e unidimensionale, quindi per tutti gli oggetti \u00e8 meglio utilizzare subito un Anchor completo.<\/p>\n<p>Un'altra importante differenza tra Data Vault e il modello Anchor \u00e8 la presenza di <b>attributi nelle relazioni.<\/b>:<\/p>\n<p>In <b>Data Vault<\/b> Le relazioni sono oggetti a pieno titolo, proprio come gli Hub, e possono avere <b>i propri attributi.<\/b>. In <b>Modello ancorato<\/b> Le relazioni vengono utilizzate solo per collegare gli Anchors e <b>non possono avere i propri attributi.<\/b>Questa differenza produce approcci sostanzialmente diversi alla modellazione <b>dei fatti,<\/b>di cui si parler\u00e0 in seguito.<\/p>\n<h3>Memorizzazione dei fatti.<\/h3>\n<p>\nFino ad ora abbiamo parlato principalmente della modellazione delle misure. I fatti presentano una situazione leggermente meno chiara.<\/p>\n<p>In <b>Data Vault<\/b> un oggetto tipico per la memorizzazione dei fatti \u2014<b> la Relazione (Link),<\/b>nelle cui Satelliti si accumulano indicatori misurabili.<\/p>\n<p>Questo approccio sembra intuitivo. Fornisce un accesso semplice agli indicatori analizzati ed \u00e8 generalmente simile a una tradizionale tabella dei fatti (solo che gli indicatori non sono memorizzati nella tabella stessa, ma in \"una tabella vicina\"). Tuttavia, ci sono anche delle insidie: una delle modifiche tipiche del modello \u2014 l'espansione della chiave di fatto \u2014 comporta la necessit\u00e0 <b>di aggiungere una nuova chiave esterna nel Link.<\/b>. Questo, a sua volta, \u201ccomplica\u201d la modularit\u00e0 e potrebbe richiedere modifiche ad altri oggetti.<\/p>\n<p>In <b>Modello ancorato<\/b> Una relazione non pu\u00f2 avere attributi propri, quindi questo approccio non funzioner\u00e0 \u2014 tutti gli attributi e gli indicatori devono essere collegati a un singolo ancoraggio specifico. La conclusione \u00e8 semplice \u2014 <b>ogni fatto ha bisogno del suo ancoraggio<\/b>. Per alcune cose che consideriamo fatti, pu\u00f2 sembrare naturale \u2014 ad esempio, il fatto di acquistare si traduce perfettamente in un oggetto \u201cordine\u201d o \u201cricevuta\u201d, la visita a un sito \u2014 in una sessione e cos\u00ec via. Ma ci sono anche fatti per i quali non \u00e8 cos\u00ec semplice trovare un \u201coggetto portante\u201d naturale \u2014 ad esempio, le giacenze di merce nei magazzini all'inizio di ogni giorno. <\/p>\n<p>Pertanto, non ci sono problemi di modularit\u00e0 nell'espandere la chiave del fatto nel modello Ancoraggio (\u00e8 sufficiente aggiungere una nuova Relazione all'ancoraggio corrispondente), ma la progettazione del modello per visualizzare i fatti \u00e8 meno univoca, possono apparire \u201cancoraggi\u201d \u201cartificiali\u201d che non rappresentano chiaramente il modello aziendale.<\/p>\n<h3>Come si raggiunge la flessibilit\u00e0<\/h3>\n<p>\nLa struttura risultante in entrambi i casi contiene <b>significativamente pi\u00f9 tabelle<\/b>, rispetto a una misurazione tradizionale. Ma pu\u00f2 occupare <b>notevolmente meno spazio su disco<\/b> con lo stesso insieme di attributi di versione della misurazione tradizionale. Non c'\u00e8 niente di magico, naturalmente \u2014 si tratta di normalizzazione. Distribuendo gli attributi tra i Satelliti (in Data Vault) o in tabelle separate (Anchor Model), riduciamo (o eliminiamo del tutto) <b>la duplicazione dei valori di alcuni attributi quando altri cambiano<\/b>.<\/p>\n<p>Per <b>Data Vault<\/b> il guadagno dipender\u00e0 dalla distribuzione degli attributi tra i Satelliti, e per <b>Modello ancorato<\/b> \u00e8 praticamente direttamente proporzionale al numero medio di versioni per oggetto di misurazione.<\/p>\n<p>Tuttavia, il risparmio di spazio \u2014 \u00e8 un vantaggio importante, ma non il principale vantaggio della memorizzazione separata degli attributi. Insieme alla memorizzazione separata delle relazioni, questo approccio rende il magazzino <b>una costruzione modulare<\/b>. Ci\u00f2 significa che l'aggiunta sia di singoli attributi che di intere nuove aree tematiche in tale modello appare come <b>un'estensione<\/b> sul set esistente di oggetti senza modificarli. Ed \u00e8 proprio questo che rende le metodologie descritte flessibili.<\/p>\n<p>Questo ricorda anche il passaggio dalla produzione artigianale a quella di massa: se nell'approccio tradizionale ogni tabella modello \u00e8 unica e richiede attenzione separata, nelle metodologie agili si tratta gi\u00e0 di un insieme di \u201ccomponenti\u201d standardizzati. Da un lato, ci sono pi\u00f9 tabelle, i processi di caricamento e di estrazione dei dati devono apparire pi\u00f9 complessi. Dall'altro lato, esse diventano <b>standardizzate<\/b>. Questo significa che possono essere <b>automatizzate e gestite tramite metadati<\/b>. La domanda \u201ccome organizzeremo tutto?\u201d, la cui risposta richiedeva una parte consistente del lavoro di progettazione delle modifiche, ora non si pone pi\u00f9 (come non si pone la questione dell'impatto delle modifiche del modello sui processi esistenti). <\/p>\n<p>Ci\u00f2 non significa che gli analisti in un sistema di questo tipo non siano affatto necessari: qualcuno deve comunque elaborare un insieme di oggetti con attributi e capire da dove e come caricare tutto questo. Tuttavia, il volume di lavoro, cos\u00ec come la probabilit\u00e0 e il costo di un errore, si riducono notevolmente. Sia nella fase di analisi che nello sviluppo di ETL, che in gran parte pu\u00f2 essere ridotto all'editing di metadati. <\/p>\n<h3>Il lato oscuro<\/h3>\n<p>\nTutto quanto sopra rende entrambi gli approcci davvero flessibili, tecnologici e adatti a sviluppi iterativi. Naturalmente, c'\u00e8 anche un \u201cbarile di mele marce\u201d, di cui penso vi siate gi\u00e0 accorti.<\/p>\n<p>La decomposizione dei dati, che sta alla base della modularit\u00e0 delle architetture flessibili, porta a un aumento del numero di tabelle e, di conseguenza, <b>di costi indiretti<\/b> per i join durante le query. Per ottenere semplicemente tutti gli attributi della dimensione, in un magazzino classico \u00e8 sufficiente un solo select, mentre un'architettura flessibile richieder\u00e0 una serie di join. E se per i report questi join possono essere scritti in anticipo, gli analisti, abituati a scrivere SQL manualmente, subiranno un doppio svantaggio.<\/p>\n<p>Ci sono diversi fatti che rendono questa situazione pi\u00f9 gestibile:<\/p>\n<p><b>Quando si lavora con dimensioni grandi, raramente vengono utilizzati tutti i suoi attributi contemporaneamente.<\/b> Questo significa che i join possono essere inferiori a quanto sembri a prima vista nel modello. In Data Vault si pu\u00f2 anche considerare la frequenza prevista di utilizzo nella distribuzione degli attributi tra i satelliti. I hub o ancore sono necessari principalmente per la generazione e il mapping dei surrogate durante il caricamento e sono raramente utilizzati nelle query (soprattutto per quanto riguarda le ancore).<\/p>\n<p><b>Tutti i join sono basati su chiave.<\/b> Inoltre, un modo di archiviazione pi\u00f9 \"compresso\" riduce le spese generali per la scansione delle tabelle dove necessario (ad esempio, durante il filtraggio per valore dell'attributo). Ci\u00f2 pu\u00f2 portare a una selezione da un database normalizzato con molti join che risulta persino pi\u00f9 veloce della scansione di una sola dimensione pesante con molte versioni per riga.<\/p>\n<p>Ad esempio, in <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">questo <\/a><\/noindex> questo articolo c'\u00e8 un dettagliato test comparativo delle prestazioni del modello ad ancore con una selezione da una singola tabella.<\/p>\n<p><b>Molto dipende dal motore.<\/b> Molte moderne piattaforme dispongono di meccanismi interni per ottimizzare le join. Ad esempio, MS SQL e Oracle possono 'saltare' le join su tabelle se i loro dati non vengono utilizzati da nessun'altra parte, eccetto in altre join e non influiscono sul risultato finale (eliminazione delle tabelle\/join), mentre MPP Vertica ha <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">dimostrato, secondo le esperienze dei colleghi di Avito<\/a><\/noindex>, di essere un eccellente motore per il Modello Anchora, tenendo conto di una certa ottimizzazione manuale del piano di query. D'altra parte, memorizzare il Modello Anchora, ad esempio, su Click House, che ha un supporto limitato per le join, sembra attualmente non essere una buona idea.<\/p>\n<p>Inoltre, per entrambe le architetture esistono <b>tecniche speciali<\/b>, che semplificano l'accesso ai dati (sia dal punto di vista delle prestazioni delle query, sia per gli utenti finali). Ad esempio, <b>le tabelle Point-In-Time<\/b> nel Data Vault o <b>funzioni di tabella speciali<\/b> nel Modello Anchora.<\/p>\n<h2>Totale<\/h2>\n<p>\nLa sostanza principale delle architetture flessibili discusse \u00e8 la modularit\u00e0 della loro 'costruzione'. <\/p>\n<p>Questa propriet\u00e0 consente di:<\/p>\n<ul>\n<li>Dopo una certa preparazione iniziale, legata al dispiegamento dei metadati e alla scrittura di algoritmi ETL di base, <b>fornire rapidamente al cliente il primo risultato<\/b> come una coppia di rapporti che contengono dati di solo alcuni oggetti sorgenti. Non \u00e8 necessario pianificare completamente (anche a livello alto) l'intero modello di oggetti per questo.<\/li>\n<li>Il modello di dati pu\u00f2 iniziare a funzionare (e portare vantaggi) con soli 2-3 oggetti, per poi <b>espandersi gradualmente<\/b> (relativamente al Modello Anchor Nikolaj <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">ha applicato <\/a><\/noindex>una bella analogia con il micelio).<\/li>\n<li>La maggior parte delle modifiche, incluso l'ampliamento dell'area tematica e l'aggiunta di nuove sorgenti <b>non influisce sulle funzionalit\u00e0 esistenti e non comporta il rischio di rompere qualcosa gi\u00e0 funzionante.<\/b>.<\/li>\n<li>Grazie alla decomposizione in elementi standard, i processi ETL in tali sistemi appaiono omogenei, la loro scrittura pu\u00f2 essere algoritmizzata e, infine, <b>automatizzata.<\/b>.<\/li>\n<\/ul>\n<p>\nIl prezzo di tale flessibilit\u00e0 \u00e8 <b>prestazioni<\/b>. Ci\u00f2 non significa che ottenere prestazioni accettabili su tali modelli sia impossibile. Nella maggior parte dei casi, potrebbero semplicemente essere necessari pi\u00f9 sforzi e attenzione ai dettagli per raggiungere le metriche desiderate.<\/p>\n<h2>Applicazioni<\/h2>\n<p><\/p>\n<h4>Tipi di entit\u00e0 <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUlteriori informazioni su Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Sito di Dan Linstedt<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.dwh-club.com\/ru\/dwh-bi-articles\/vse-o-data-vault.html\">Tutto su Data Vault in russo<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/348188\/\">Su Data Vault su Habr<\/a><\/noindex><\/p>\n<h4>Tipi di entit\u00e0 <b>Anchor Model<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUlteriori informazioni sul Modello Anchor:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Sito dei creatori del Modello Anchor<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Articolo sull'esperienza di implementazione del Modello Anchor in Avito<\/a><\/noindex><\/p>\n<p>Tabella riassuntiva con somiglianze e differenze dei metodi esaminati:<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili per la progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/glowbyte\/blog\/515940\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92016,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92015","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Panoramica delle metodologie agili di progettazione DWH | ProHoster","description":"Lo sviluppo di un deposito \u00e8 un compito lungo e serio. Molto nella vita di un progetto dipende da quanto bene \u00e8 pensato il modello degli oggetti e la struttura del database all'inizio. L'approccio pi\u00f9 comune \u00e8 stato e rimane una combinazione di varianti dello schema 'stella' con la terza forma normale. Di solito, secondo il principio: dati di origine \u2014 3NF, vetrine \u2014 stella. Questo approccio, collaudato nel tempo e supportato","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster","og:description":"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-21T17:42:13+00:00","article:modified_time":"2020-08-21T17:42:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92015","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:16:44","updated":"2022-09-27 14:57:59"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}