{"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 nella progettazione DWH","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Lo sviluppo di un data warehouse \u00e8 un compito lungo e serio. <\/p>\n<p>Molto nella vita del progetto dipende da quanto bene \u00e8 stata pensata la modelizzazione degli oggetti e la struttura del database fin dall'inizio.<\/p>\n<p>Un approccio consolidato \u00e8 rappresentato dalle varie combinazioni dello schema a 'stelle' con la terza forma normale. Di solito, seguendo il principio: dati sorgente \u2014 3NF, data mart \u2014 stelle. Questo approccio, collaudato nel tempo e supportato da un gran numero di ricerche, \u00e8 il primo (e a volte l'unico) pensiero che viene in mente a un esperto di DWH quando si considera come dovrebbe apparire un data warehouse analitico.<\/p>\n<p>D'altra parte, le esigenze dell'azienda in generale e del cliente in particolare tendono a cambiare rapidamente, cos\u00ec come i dati possono crescere sia 'in profondit\u00e0' che 'in larghezza'. E qui si manifesta il principale svantaggio della stella \u2014 la sua limitata <b>flessibilit\u00e0<\/b>.<\/p>\n<p>E se improvvisamente nella vostra vita tranquilla e confortevole di sviluppatore di DWH:<\/p>\n<ul>\n<li>si presenta la necessit\u00e0 di 'fare rapidamente qualcosa, poi vedremo';<\/li>\n<li>compare un progetto in rapida crescita, con l'integrazione di nuove fonti e la modifica del modello di business almeno una volta a settimana;<\/li>\n<li>si presenta un cliente che non ha idea di come deve apparire il sistema e quali funzioni deve svolgere alla fine, ma \u00e8 aperto agli esperimenti e all'affinamento graduale del risultato desiderato avvicinandosi progressivamente ad esso;<\/li>\n<li>un manager di progetto fa capolino con la lieta notizia: 'E ora abbiamo Agile!'.<\/li>\n<\/ul>\n<p>\nOppure, se siete semplicemente curiosi di scoprire come si possono costruire i data warehouse \u2014 benvenuti qui sotto!<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella 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>\nPer prima cosa, definiamo quali caratteristiche deve avere un sistema per poter essere definito 'flessibile'. <\/p>\n<p>\u00c8 importante sottolineare che le propriet\u00e0 descritte devono riferirsi precisamente a <b>sistema<\/b>, e non a <b>il processo <\/b>di sviluppo. Pertanto, se desideravate leggere di 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\/\">articoli di revisione<\/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\/\">problemi<\/a><\/noindex>).<\/p>\n<p>Ci\u00f2 non significa che il processo di sviluppo e la struttura del data warehouse siano completamente slegati. In generale, sviluppare un repository di architettura flessibile seguendo il metodo Agile dovrebbe essere significativamente pi\u00f9 facile. Tuttavia, nella pratica, si incontrano pi\u00f9 spesso varianti in cui si utilizza il metodo Agile per un DWH classico secondo Kimball e Data Vault usando il waterfall, piuttosto che felici coincidenze di flessibilit\u00e0 in entrambe le sue forme nello stesso progetto.<\/p>\n<p>Quindi, quali devono essere le capacit\u00e0 di un data warehouse flessibile? Qui possiamo evidenziare tre punti:<\/p>\n<ol>\n<li><b>Consegna anticipata e rapidi sviluppi<\/b> \u2014 ci\u00f2 significa che, in ideale, il primo risultato commerciale (ad esempio, i primi report funzionanti) dovrebbe essere ottenuto il prima possibile, prima che l'intero sistema sia progettato e implementato completamente. Ogni successivo sviluppo dovrebbe richiedere il minor tempo possibile.<\/li>\n<li><b>Sviluppo iterativo<\/b> \u2014 ci\u00f2 significa che ogni sviluppo successivo in ideale non dovrebbe influenzare le funzionalit\u00e0 gi\u00e0 attive. Questo elemento diventa spesso il maggiore incubo nei progetti di grandi dimensioni: prima o poi, singoli oggetti iniziano ad accumulare cos\u00ec tante relazioni che diventa pi\u00f9 semplice replicare completamente la logica in una copia accanto, piuttosto che aggiungere un campo a una tabella esistente. E se ti sorprende che l'analisi dell'impatto dello sviluppo sugli oggetti esistenti possa richiedere pi\u00f9 tempo dello sviluppo stesso, probabilmente non hai ancora lavorato con grandi DWH nel settore bancario o delle telecomunicazioni.<\/li>\n<li><b>Costante adattamento ai requisiti aziendali in evoluzione<\/b> \u2014 la struttura oggettuale generale deve essere progettata non solo tenendo conto di possibili ampliamenti, ma calcolando che il nuovo indirizzo di ampliamento potrebbe non esserti nemmeno venuto in mente durante la fase di progettazione.<\/li>\n<\/ol>\n<p>\nE s\u00ec, corrispondere a tutti questi requisiti in un unico sistema \u00e8 possibile (naturalmente, in determinati casi e con alcune riserve).<\/p>\n<p>Di seguito esaminer\u00f2 due delle metodologie di progettazione flessibile pi\u00f9 popolari per i DWH \u2014 <b>Anchor model<\/b> e <b>Data Vault<\/b>. Tra parentesi rimangono ottimi approcci, come ad esempio EAV, 6NF (nella sua forma pura) e tutto ci\u00f2 che riguarda le soluzioni NoSQL - non perch\u00e9 siano inferiori, e nemmeno perch\u00e9 in questo caso l'articolo rischierebbe di acquisire il volume di una tesi media. Semplicemente, tutto ci\u00f2 appartiene a soluzioni di un altro tipo - o a metodi che potete applicare in casi specifici, indipendentemente dall'architettura generale del vostro progetto (come EAV), oppure a paradigmi completamente diversi di archiviazione delle informazioni (come, ad esempio, i database a grafo e altre varianti NoSQL).<\/p>\n<h3>Problemi del metodo \u201cclassico\u201d e le loro soluzioni nelle metodologie agili<\/h3>\n<p>\n<i>Per \u201capproccio classico\u201d intendo la vecchia cara stella (indipendentemente dall'implementazione specifica dei livelli sottostanti, perdonatemi adepti di Kimball, Inmon e CDM).<br \/>\n<\/i><\/p>\n<h4>1. Rigidit\u00e0 della cardinalit\u00e0 dei legami<\/h4>\n<p>\nAlla base di questo modello c'\u00e8 una chiara suddivisione dei dati in <b>dimensioni (Dimensione)<\/b> e <b>fatti (Fatto)<\/b>. E questo, accidenti, ha senso - poich\u00e9 l'analisi dei dati, nella stragrande maggioranza dei casi, si riduce proprio all'analisi di specifici indicatori numerici (fatti) in specifici contesti (dimensioni).<\/p>\n<p>In questo caso, i legami tra gli oggetti sono stabiliti sotto forma di relazioni tra tabelle tramite chiavi esterne. Questo appare del tutto naturale, ma porta immediatamente al primo limite di flessibilit\u00e0 - <b>rigida definizione della cardinalit\u00e0 dei legami<\/b>.<\/p>\n<p>Ci\u00f2 significa che nella fase di progettazione delle tabelle dovete definire con precisione per ogni coppia di oggetti correlati se possono avere una relazione di molti a molti, oppure solo 1 a molti, e \u201cin quale direzione\u201d. Questo influisce direttamente su quale tabella avr\u00e0 la chiave primaria e quale avr\u00e0 la chiave esterna. La modifica di questa relazione in seguito all'ottenimento di nuove esigenze porter\u00e0 con alta probabilit\u00e0 a un ripensamento del database.<\/p>\n<p>Ad esempio, progettando l'oggetto \u201cscontrino fiscale\u201d, basandovi sulle solenni promesse del reparto vendite, avete previsto la possibilit\u00e0 che <b>una promozione possa agire su pi\u00f9 voci di scontrino<\/b> (ma non viceversa):<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nE dopo un po', i colleghi hanno introdotto una nuova strategia di marketing, in cui pi\u00f9 promozioni possono agire contemporaneamente su <b>la stessa voce<\/b>. E ora dovete rielaborare le tabelle, estraendo il legame in un oggetto separato. <\/p>\n<p>(Tutti gli oggetti derivati in cui avviene il join di un controllo promozionale ora necessitano di modifiche).<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Collegamenti in Data Vault e Anchor Model<\/b><\/p>\n<p>Evitare tale situazione si \u00e8 rivelato piuttosto semplice: non bisogna fidarsi del reparto vendite. Baste <b>memorizzare tutti i collegamenti in tabelle separate<\/b> e gestirli 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 completamente supportato <b>da Lars R\u00f6nnb\u00e4ck<\/b> in <b>Anchor Model<\/b>.<\/p>\n<p>Alla fine otteniamo la prima caratteristica distintiva delle metodologie flessibili:<\/p>\n<blockquote><p>I collegamenti tra gli oggetti non sono memorizzati negli attributi delle entit\u00e0 genitore, ma rappresentano un tipo di oggetto separato.<\/p><\/blockquote>\n<p>In <b>Data Vault<\/b> Tali tabelle di associazione sono chiamate <b>Link<\/b>, e in <b>Anchor Model<\/b> \u2014 <b>Tie<\/b>. A prima vista sembrano molto simili, anche se le loro differenze non si esauriscono nel nome (di cui si discuter\u00e0 pi\u00f9 avanti). In entrambe le architetture, le tabelle di associazione possono collegare <b>un numero qualsiasi di entit\u00e0<\/b> (non necessariamente 2).<\/p>\n<p>Questa apparente ridondanza offre una notevole flessibilit\u00e0 nelle modifiche. Questa struttura diventa tollerante non solo ai cambiamenti nelle cardinalit\u00e0 delle relazioni esistenti, ma anche all'aggiunta di nuove: se ora a una voce di controllo viene aggiunto anche un riferimento al cassiere che l'ha registrata, la creazione di tale collegamento diventa semplicemente un'estensione delle tabelle esistenti senza influenzare alcun oggetto o processo gi\u00e0 esistente.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella 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, in primo luogo <b>per dimensioni di tipo SCD2<\/b> (slowly changing dimensions di secondo tipo), anche se non solo per esse.<\/p>\n<p>In un classico data warehouse, una dimensione di solito \u00e8 rappresentata da una tabella che contiene una chiave surrogata (come PK) oltre a un insieme di chiavi aziendali e attributi in colonne separate. <\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe la dimensione supporta la versione, al set standard di campi vengono aggiunti i limiti di tempo di validit\u00e0 della versione, e per ogni riga nella fonte ci sono pi\u00f9 versioni nel magazzino (una per ogni modifica degli attributi di versione).<\/p>\n<p>Se la misura contiene almeno un attributo versionato soggetto a frequenti modifiche, il numero di versioni di tale misura sar\u00e0 considerevole (anche se gli altri attributi non sono versionati o non cambiano mai) e, se ci sono pi\u00f9 di tali attributi, il numero di versioni pu\u00f2 crescere in modo esponenziale in base al loro numero. Tale misura pu\u00f2 occupare una notevole quantit\u00e0 di spazio su disco, anche se la maggior parte dei dati memorizzati in essa cos'\u00e8 semplicemente duplicati dei valori degli attributi immutabili di altre righe.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInoltre, molto spesso viene applicata anche la <b>denormalizzazione<\/b> \u2014 parte degli attributi viene intenzionalmente memorizzata come valore, piuttosto che come riferimento a una tabella di consultazione o un'altra misura. Questo approccio accelera l'accesso ai dati, riducendo il numero di join quando si accede alla misura.<\/p>\n<p>Di norma, ci\u00f2 porta al fatto che <b>la stessa informazione \u00e8 memorizzata contemporaneamente in pi\u00f9 luoghi<\/b>. Ad esempio, le informazioni sulla regione di residenza e sull'appartenenza alla categoria del cliente possono essere memorizzate contemporaneamente nelle misure \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 misure normali (non versionate), ma nelle versionate pu\u00f2 avere un'altra portata: l'emergere di una nuova versione dell'oggetto (specialmente retroattivamente) non porta solo all'aggiornamento di tutte le tabelle correlate, ma a un'emergenza a cascata di nuove versioni degli oggetti correlati \u2014 quando la Tabella 1 \u00e8 utilizzata per costruire la Tabella 2, e la Tabella 2 per costruire la Tabella 3, e cos\u00ec via. Anche se nessun attributo della Tabella 1 partecipa alla costruzione della Tabella 3 (e partecipano altri attributi della Tabella 2, ottenuti da altre fonti), l'aggiornamento versionato di questa struttura porter\u00e0 almeno a costi aggiuntivi, e al massimo \u2014 a versioni superflue nella Tabella 3, che qui \u00e8 completamente \u201cestranea\u201d e cos\u00ec via a catena.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella 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 dello sviluppo<\/h4>\n<p>\nIn questo caso, ogni nuova vetrina costruita sulla base di un'altra aumenta il numero di luoghi in cui i dati possono \u201cdispersarsi\u201d quando vengono apportate modifiche all'ETL. Questo, a sua volta, porta a un aumento della complessit\u00e0 (e della durata) di ogni successivo sviluppo.<\/p>\n<p>Se quanto descritto sopra riguarda sistemi con processi ETL raramente aggiornati, si pu\u00f2 vivere in tale paradigma: \u00e8 sufficiente prestare attenzione affinch\u00e9 i nuovi aggiornamenti siano correttamente integrati in tutti gli oggetti correlati. Se tuttavia gli aggiornamenti avvengono frequentemente, la probabilit\u00e0 di \u201ctrascurare\u201d casualmente alcune relazioni aumenta notevolmente.<\/p>\n<p>Se si considera inoltre che un ETL \u201cversionato\u201d \u00e8 sostanzialmente pi\u00f9 complesso di un ETL \u201cnon versionato\u201d, diventa abbastanza difficile evitare errori durante frequenti aggiornamenti di tutto questo sistema.<\/p>\n<h3>Archiviazione di oggetti e attributi in Data Vault e Anchor Model<\/h3>\n<p>\nL'approccio proposto dagli autori di 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, conservare le chiavi separatamente dagli attributi.<\/p><\/blockquote>\n<p> A questo proposito, non bisogna confondere <b>non versionato<\/b> l'attributo con <b>immutabile<\/b>: il primo non conserva la storia della sua modifica, ma pu\u00f2 cambiare (ad esempio, a seguito di correzioni di errori di input o ricezione di nuovi dati), il secondo \u2014 non cambia mai.<\/p>\n<p>Le opinioni su cosa possa essere considerato immutabile nel Data Vault e nel Modello Anchor sono divergenti.<\/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 del prodotto nel sistema sorgente, ecc.) e surrogate. A questo punto, gli altri attributi possono essere suddivisi in gruppi per fonte e\/o frequenza di cambiamenti e <b>per ciascun gruppo mantenere una tabella separata<\/b> con un insieme indipendente di versioni.<\/p>\n<p>Nel paradigma del <b>Modello Anchor<\/b> si considera immutabile <b>solo la chiave surrogata<\/b> dell'entit\u00e0. Tutto il resto (compresi i chiavi naturali) \u00e8 semplicemente un caso particolare dei suoi attributi. In questo modo <b>tutti gli attributi sono per default indipendenti tra loro<\/b>, pertanto per ogni attributo deve essere creata una <b>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>Data di aggiunta della registrazione<\/li>\n<\/ul>\n<p>\nLe registrazioni negli Hub <b>non vengono mai modificate e non hanno versioni.<\/b>. Esternamente, gli hub assomigliano molto alle tabelle di tipo ID-map, usate in alcuni sistemi per la generazione di surrogate, ma come surrogate nel Data Vault si consiglia di utilizzare non una sequenza intera, ma un hash dell'insieme di chiavi aziendali. Questo approccio semplifica il caricamento delle relazioni e degli attributi dalle fonti (non \u00e8 necessario effettuare join sull'hub per ottenere il surrogate, \u00e8 sufficiente calcolare l'hash dalla chiave naturale), ma pu\u00f2 creare altri problemi (relativi, 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 diversi satelliti che memorizzano set di attributi differenti.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa distribuzione degli attributi nei satelliti avviene secondo il principio <b>di modifica congiunta<\/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 attributi versionati a cambiamento raro (ad esempio, il cognome e il numero di passaporto), in un terzo attributi soggetti a frequenti modifiche (ad esempio, indirizzo di consegna, categoria, data dell'ultimo ordine, ecc.). La versionabilit\u00e0 \u00e8 gestita a livello di singoli satelliti, e non dell'entit\u00e0 nel complesso, quindi \u00e8 opportuno distribuire gli attributi in modo da minimizzare l'intersezione delle versioni all'interno di un singolo satellite (ci\u00f2 riduce il numero totale di versioni memorizzate). <\/p>\n<p>Inoltre, per ottimizzare il processo di caricamento dei dati, in satelliti separati vengono spesso spostati attributi provenienti da diverse fonti.<\/p>\n<p>I satelliti sono collegati all'HUB tramite <b>chiavi esterne<\/b> (il che corrisponde a una cardinalit\u00e0 1-a-molti). Ci\u00f2 significa che molteplici valori di attributi (ad esempio, diversi numeri di telefono di contatto per un singolo cliente) sono supportati da questa architettura \u201cper impostazione predefinita\u201d.<\/p>\n<p>In <b>Modello Ancorato (Anchor Model)<\/b> le tabelle che memorizzano le chiavi sono chiamate <b>Anchor (Ancoraggi)<\/b>. E memorizzano: <\/p>\n<ul>\n<li><b>Solo chiavi surrogate<\/b><\/li>\n<li>Riferimento alla fonte<\/li>\n<li>Data di aggiunta della registrazione<\/li>\n<\/ul>\n<p>\nLe chiavi naturali, dal punto di vista del Modello Ancorato, sono considerate <b>attributi normali<\/b>. Questa opzione pu\u00f2 sembrare pi\u00f9 complessa da comprendere, ma consente una maggiore libert\u00e0 nell'identificazione dell'oggetto.<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAd esempio, se i dati su una stessa entit\u00e0 possono provenire da sistemi diversi, ognuno dei quali utilizza la propria chiave naturale. Nel Data Vault questo pu\u00f2 portare a strutture piuttosto ingombranti formate da pi\u00f9 hub (uno per sorgente + una versione master consolidante), mentre nel modello Ancorato la chiave naturale di ciascuna sorgente viene inserita nel proprio attributo e pu\u00f2 essere utilizzata al momento del caricamento indipendentemente dagli altri. <\/p>\n<p>Ma qui si nasconde un aspetto insidioso: se in un'entit\u00e0 vengono combinati attributi di sistemi diversi, probabilmente esistono alcune <b>regole di \u201cfusione\u201d<\/b>, secondo le quali il sistema deve comprendere che le registrazioni provenienti da diverse fonti corrispondono a un'istanza unica dell'entit\u00e0. <\/p>\n<p>In <b>Data Vault<\/b> Queste regole probabilmente determineranno la formazione <b>di un \u201chub surrogato\u201d per l'entit\u00e0 master<\/b> e non influiranno sugli Hub, che conservano le chiavi naturali delle sorgenti e i loro attributi originali. Se in qualche momento le regole di fusione cambiano (o viene ricevuto un aggiornamento degli attributi su cui essa si basa), baster\u00e0 riformare gli hub surrogati.<\/p>\n<p>In <b>Nel modello Ancorato<\/b> tale entit\u00e0 sar\u00e0 probabilmente conservata in <b>un'unica ancora<\/b>. Questo significa che tutti gli attributi, indipendentemente dalla fonte da cui provengono, saranno legati a un unico surrogato. Separare registrazioni erroneamente unite e monitorare l'attualit\u00e0 della fusione in un tale sistema pu\u00f2 risultare notevolmente pi\u00f9 difficile, specialmente se le regole sono piuttosto complesse e cambiano frequentemente, e lo stesso attributo pu\u00f2 essere ottenuto da fonti diverse (anche se \u00e8 certamente possibile, poich\u00e9 ogni versione dell'attributo conserva un riferimento alla propria fonte).<\/p>\n<p>In ogni caso, se nel vostro sistema \u00e8 prevista l'implementazione della funzionalit\u00e0 di <b>deduplicazione, fusione di registrazioni e altri elementi MDM<\/b>, \u00e8 consigliabile prestare particolare attenzione agli aspetti di conservazione delle chiavi naturali nelle metodologie flessibili. \u00c8 probabile che la struttura pi\u00f9 complessa del Data Vault si riveli improvvisamente pi\u00f9 sicura dal punto di vista degli errori di fusione.<\/p>\n<p><b>Il modello Ancorato<\/b> prevede anche un ulteriore tipo di oggetto, chiamato <b>Nodo (Knot)<\/b> , che \u00e8 essenzialmente un <b>tipo degenerato di ancora<\/b>, che pu\u00f2 contenere solo un attributo. I nodi sono previsti per la memorizzazione di dizionari piatti (come sesso, stato civile, categoria di servizio clienti, ecc.). A differenza dell'Ancora, il Nodo <b>non ha tabelle di attributi collegate<\/b>, e il suo unico attributo (nome) \u00e8 sempre memorizzato in una tabella con la chiave. I nodi si collegano agli Ancoraggi tramite tabelle di collegamento (Tie) allo stesso modo in cui gli ancoraggi si collegano tra loro.<\/p>\n<p>Non c'\u00e8 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 ad Ancoraggio in Russia, ritiene (non senza fondamento) che per nessun dizionario si possa affermare con certezza che esso <b>sempre<\/b> sar\u00e0 statico e unilivello, quindi per tutti gli oggetti \u00e8 meglio utilizzare subito un Ancoraggio completo.<\/p>\n<p>Un'altra importante differenza tra Data Vault e il modello ad Ancoraggio risiede nella presenza di <b>attributi nelle relazioni<\/b>:<\/p>\n<p>In <b>Data Vault<\/b> Le relazioni sono oggetti completi, proprio come gli Hub, e possono avere <b>attributi propri<\/b>. In <b>Nel modello Ancorato<\/b> Le relazioni sono utilizzate solo per collegare gli Ancoraggi e <b>non possono avere attributi propri<\/b>. Questa differenza porta a approcci sostanzialmente diversi nella modellazione <b>dei fatti<\/b>, di cui si parler\u00e0 successivamente.<\/p>\n<h3>Memorizzazione dei fatti<\/h3>\n<p>\nFino a questo punto abbiamo parlato principalmente della modellazione delle misure. Per quanto riguarda i fatti, la situazione \u00e8 leggermente meno chiara.<\/p>\n<p>In <b>Data Vault<\/b> oggetto tipico per la memorizzazione dei fatti \u2014<b> Collegamento (Link)<\/b>, nei Satelliti dei quali vengono memorizzati i dati reali.<\/p>\n<p>Questo approccio sembra intuitivamente comprensibile. Fornisce un accesso semplice ai dati analizzati e in generale assomiglia a una tradizionale tabella dei fatti (solo che i dati non sono memorizzati nella tabella stessa, ma in una \"vicina\"). Ma ci sono anche insidie: una delle modifiche standard al modello \u2014 l'estensione della chiave del fatto \u2014 comporta la necessit\u00e0 <b>di aggiungere una nuova chiave esterna nel Link<\/b>. E questo, a sua volta, \"rompe\" la modularit\u00e0 e potenzialmente richiede modifiche ad altri oggetti.<\/p>\n<p>In <b>Nel modello Ancorato<\/b> Il Collegamento non pu\u00f2 avere attributi propri, quindi questo approccio non funzioner\u00e0: tutti gli attributi e i dati devono essere legati a un'unica Ancora concreta. La conclusione \u00e8 semplice \u2014 <b>per ogni fatto \u00e8 necessaria anche la propria Ancora.<\/b>. Per una parte di ci\u00f2 che siamo abituati a considerare come fatti, questo pu\u00f2 sembrare naturale: ad esempio, il fatto di un acquisto si riduce bene a un oggetto \"ordine\" o \"scontrino\", la visita di un sito web a una sessione, e cos\u00ec via. Ma ci sono anche fatti per i quali non \u00e8 cos\u00ec semplice trovare un \"oggetto-portante\" naturale, come ad esempio le rimanenze di merci nei magazzini all'inizio di ogni giorno. <\/p>\n<p>Di conseguenza, non ci sono problemi di modularit\u00e0 nell'espandere la chiave del fatto nel modello Anchor (\u00e8 sufficiente aggiungere una nuova Relazione all'Anchor corrispondente), ma la progettazione del modello per rappresentare i fatti \u00e8 meno chiara, possono apparire \"Anchor\" \"artificiali\" che rappresentano il modello aziendale in modo poco evidente.<\/p>\n<h3>Come si raggiunge la flessibilit\u00e0<\/h3>\n<p>\nLa struttura risultante in entrambi i casi contiene <b>notevolmente pi\u00f9 tabelle<\/b>, rispetto a una misura tradizionale. Ma pu\u00f2 occupare <b>notevolmente meno spazio su disco<\/b> con lo stesso insieme di attributi di versione, esattamente come la misura tradizionale. Non c'\u00e8 magia qui, ovviamente \u2014 \u00e8 tutta questione di normalizzazione. Distribuendo gli attributi tra i Satelliti (in Data Vault) o tabelle separate (Anchor Model), riduciamo (o escludiamo completamente) <b>la duplicazione dei valori di alcuni attributi quando si modificano altri<\/b>.<\/p>\n<p>Per <b>Data Vault<\/b> il guadagno dipender\u00e0 dalla distribuzione degli attributi tra i Satelliti, e per <b>Nel modello Ancorato<\/b> \u2014 \u00e8 praticamente direttamente proporzionale al numero medio di versioni per oggetto di misura.<\/p>\n<p>Tuttavia, il guadagno in termini di spazio occupato \u00e8 un vantaggio importante, ma non il principale, del deposito separato degli attributi. Insieme al deposito separato delle relazioni, questo approccio rende il deposito <b>una costruzione modulare<\/b>. Questo significa che l'aggiunta di attributi separati o addirittura di nuove aree tematiche in un modello simile sembra una <b>sovrastruttura<\/b> sul set esistente di oggetti senza modificarli. Ed \u00e8 proprio questo che rende flessibili le metodologie descritte.<\/p>\n<p>Ricorda anche il passaggio dalla produzione unitario a quella di massa \u2014 se nell'approccio tradizionale ogni tabella del modello \u00e8 unica e richiede attenzione separata, nelle metodologie flessibili esse diventano un insieme di \"componenti\" standard. Da un lato, il numero di tabelle aumenta, i processi di caricamento e recupero dei dati devono sembrare pi\u00f9 complessi. D'altra parte, diventano <b>standardizzati<\/b>. E ci\u00f2 significa che possono essere <b>automatizzati e gestiti dai metadati<\/b>. La domanda \u201ccome procederemo con la pianificazione?\u201d, la cui risposta poteva occupare una parte significativa del lavoro di progettazione delle modifiche, ora semplicemente non si pone (cos\u00ec come la domanda sull'impatto del cambiamento del modello sui processi esistenti). <\/p>\n<p>Questo non significa che gli analisti non siano affatto necessari in un sistema del genere: qualcuno deve comunque lavorare su un insieme di oggetti con attributi e capire da dove e come caricarli. Ma il volume di lavoro, cos\u00ec come la probabilit\u00e0 e il costo di errore, diminuiscono significativamente. Sia nella fase di analisi che nello sviluppo dell'ETL, che in buona parte pu\u00f2 essere ridotto all'editing dei metadati. <\/p>\n<h3>Lato oscuro<\/h3>\n<p>\nTutto quanto detto sopra rende entrambi gli approcci davvero flessibili, tecnologici e adatti per modifiche iterative. Naturalmente, c'\u00e8 anche un 'barile di pece' di cui, credo, avete gi\u00e0 un'idea.<\/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>costi aggiuntivi<\/b> per i join durante le selezioni. Per ottenere semplicemente tutti gli attributi di misurazione, in un classico magazzino \u00e8 sufficiente un'unica selezione, mentre un'architettura flessibile richiede una serie di join. E se per i report tutti questi join possono essere scritti in anticipo, gli analisti che sono abituati a scrivere SQL a mano soffriranno di pi\u00f9.<\/p>\n<p>Ci sono alcuni fattori che semplificano questa situazione:<\/p>\n<p><b>Quando si lavora con grandi misure, quasi mai vengono utilizzati simultaneamente tutti i suoi attributi.<\/b> Questo significa che i join potrebbero essere meno di quanto sembri a prima vista. Nel Data Vault, si pu\u00f2 anche tenere conto della frequenza prevista di utilizzo congiunto nella distribuzione degli attributi tra i satelliti. I Hub o Ancore sono necessari principalmente per la generazione e il mapping dei surrogati nella fase di caricamento e sono raramente utilizzati nelle query (soprattutto per quanto riguarda le Ancore).<\/p>\n<p><b>Tutti i join \u2014 per chiave.<\/b> Inoltre, un metodo di archiviazione dei dati pi\u00f9 \"compresso\" riduce i costi indiretti per la scansione delle tabelle dove necessario (ad esempio durante il filtraggio per valore dell'attributo). Questo pu\u00f2 portare a risultati pi\u00f9 rapidi da un database normalizzato con molti join, rispetto alla scansione di una singola misura pesante con molte versioni per riga.<\/p>\n<p>Ad esempio, qui 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 Anchora con un campionamento da una singola tabella.<\/p>\n<p><b>Molto dipende dal motore.<\/b> Molte piattaforme moderne hanno meccanismi interni per ottimizzare i join. Ad esempio, MS SQL e Oracle possono \"saltare\" i join su tabelle se i loro dati non vengono utilizzati altrove, tranne che per altri join, e non influiscono sul risultato finale (eliminazione delle tabelle\/join), mentre MPP Vertica, secondo <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">le esperienze dei colleghi di Avito<\/a><\/noindex>, si \u00e8 dimostrato un ottimo motore per il modello Anchora con 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 i join, al momento sembra non essere una buona idea.<\/p>\n<p>Inoltre, per entrambe le architetture esistono <b>tecniche speciali<\/b>, che facilitano l'accesso ai dati (sia dal punto di vista delle prestazioni delle query che per gli utenti finali). Ad esempio, <b>le tabelle Point-In-Time<\/b> in Data Vault o <b>funzioni tabulari speciali<\/b> nel modello Anchora.<\/p>\n<h2>Totale<\/h2>\n<p>\nIl punto principale delle architetture flessibili considerate \u00e8 la modularit\u00e0 della loro \"struttura\". <\/p>\n<p>Questa caratteristica consente:<\/p>\n<ul>\n<li>Dopo un certo inizio di preparazione, legato al dispiegamento dei metadati e alla scrittura degli algoritmi ETL di base, <b>di fornire rapidamente al cliente il primo risultato<\/b> sotto forma di un paio di report contenenti dati di appena alcuni oggetti sorgente. Non \u00e8 necessario pensare completamente (anche a livello alto) a tutto il modello di oggetti per questo.<\/li>\n<li>Il modello di dati pu\u00f2 iniziare a funzionare (e portare benefici) con solo 2-3 oggetti, e poi <b>espandersi gradualmente<\/b> (riguardo al modello Anchora, Nikolay <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">ha applicato <\/a><\/noindex>un bel confronto con il micelio).<\/li>\n<li>La maggior parte delle modifiche, inclusa l'espansione dell'area tematica e l'aggiunta di nuove sorgenti <b>non influisce sulla funzionalit\u00e0 esistente e non comporta il rischio di rompere qualcosa che gi\u00e0 funziona.<\/b>.<\/li>\n<li>Grazie alla decomposizione in elementi standard, i processi ETL in tali sistemi appaiono omogenei, la loro scrittura si presta all'algoritmizzazione e, infine, <b>all'automazione<\/b>.<\/li>\n<\/ul>\n<p>\nIl prezzo di questa flessibilit\u00e0 \u00e8 <b>prestazioni<\/b>. Questo non significa che raggiungere prestazioni accettabili in tali modelli sia impossibile. Nella maggior parte dei casi, \u00e8 probabile che vi serva semplicemente pi\u00f9 impegno 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 nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMaggiore informazione 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>Modello Anchor<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella progettazione DWH\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMaggiore informazione su Anchor Model:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Sito dei creatori di Anchor Model<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Articolo sull'esperienza di implementazione di Anchor Model in Avito<\/a><\/noindex><\/p>\n<p>Tabella riassuntiva con caratteristiche comuni e differenze tra i metodi esaminati:<\/p>\n<p><img decoding=\"async\" alt=\"Panoramica delle metodologie flessibili nella 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 5.0.1.1 - 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.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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 flessibili di progettazione DWH | ProHoster","description":"Lo sviluppo di un data warehouse \u00e8 un compito lungo e serio.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}