談談資料倉儲架構的發展和分類
在此不做評述，僅供參考！
以下內容均引自於ttnn網站，詳細連結如下：
1
發件人： Jerome - 檢視個人資料
日期： 2006年12月10日(星期日) 下午4時36分
電子郵件： "Jerome"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
最近大家對資料倉儲架構的討論又多了起來，我在這裡對一些架構進行一下簡單的整理。目的是給大家樹立一個靶子，大家可以在這篇文章後盡情的批判和補充。
我把我聽說過的架構都歸整在一起，分了六類，其中和很多說明是我個人的理解，不見得正確，大家多多指導。
1．獨立的資料集市架構（Independent data mart architecture）
獨立的資料集市架構有時也稱為獨立的資料倉儲架構，應該是出現最早的架構方式，也是很常見的方式。特別是對於中小企業、中小開發公司，出於成本和見效快的考慮都會採用這種架構方式。大家對這種架構方式一定也很熟。
這種架構方式的缺點也很明顯，不是企業內一致的資料，產生資訊孤島。當然我企業就是很小，就一個系統，不用整合，一個資料集市足以的情況下采用這種方式也沒什麼。先期小投資，讓企業看看效果，以後發展大了再考慮重新建立資料倉儲。
2．聯邦式資料倉儲架構（Federated data warehouse
architecture）
這種架構方式我之前寫過一點簡單介紹，當然，我對這種方式也不熟，介紹的也是亂七八糟。我想它的出現應該是由於，企業發展的初期建立了幾個獨立的資料集市架構，後來發現這樣不行，資料沒整合，要解決資訊孤島得想辦法。推倒重建當然好，不過投入太大，以前的資料集市還想用，怎麼辦。於是，想出另一種辦法，在各個獨立的資料集市間建立一些對照表，在不推倒它們的基礎上能進行一下資料交換。後來，慢慢發現，早想好整合策略，直接這樣建資料倉儲也可以，於是，地域聯邦、功能聯邦的概念也就都提出來了。
聯邦架構的缺點也很明顯，除非建立之初就採用類似匯流排架構的方法實現資料一致，否則很容易出現資料不一致，導致整合的不徹底。如果之初就考慮好的話，和匯流排架構的差別就不大了。當然，對於臨時解決企業原有獨立資料集市的資料交換問題，聯邦架構還是有一定作用的。
3．集中式架構（Centralized architecture）
集中式架構方式的出現，標識著資料倉儲架構已經進入比較成熟的時期。他的架構方式是建立物理的EDW，即中心資料倉儲，資料都集中的EDW中，應用和分析程式都在EDW中進行訪問，資料是全企業內一致的。隨著ROLAP的發展，在這種集中式架構中建立ROLAP開始比較流行，常見的MicroStrategy公司的解決方案就是在EDW中建立ROLAP。ROLAP單獨建表儲存後設資料，只儲存維度模型的關係，不儲存維度模型的資料，由MicroStrategy的應用去解析，加上應用伺服器作為快取，速度還可以。
這種方式也有一些缺點，如擴充套件能力差，對EDW所在的RDBMS要求太高，隨著資料量和分析的逐步增長，就不得不再把資料進行分離。如果在EDW的基礎上進行資料分離，為不同的應用單獨建立資料集市或者挖掘倉庫，集中式結構也就演變成Hub
and Spoke架構方式。
4．集線器和車輪輻條架構（Hub and spoke architecture）
其實我更想直接稱之為企業資訊工廠架構（Corporate
information factory
architecture），集線器和車輪輻條架構聽起來比較彆扭，叫起來也不響亮。而企業資訊工廠應該是這種架構方式的最出色的代表。從名稱我們也能大概猜個差不多，中心資料倉儲EDW從各個源系統收集資料，將資料提供給各個資料集市和挖掘倉庫，功能和集線器很相似，所以稱為Hub。如果大家把圖畫出來，可能會更形象一些，EDW和各個源資料庫及資料集市、挖掘倉庫之間都連一條線，看起來就向一個車輪，這些連線就像車輪輻條，所以稱為Spoke。而這種採用中心資料倉儲EDW整合資料，再分散到各個資料集市使用資料的方式就形象的稱為Hub
and spoke architecture。
這種架構方式當然也有缺點，雖然是在整合的中心資料倉儲EDW上建立資料集市，但是這些資料集市之間還是不能進行資料交換的，大家建立的方法和ETL程式都會不同，各個資料集市之間的資料不見得的是一致的。而且這種架構方式開始變得複雜。
5．匯流排架構（Bus architecture）
匯流排架構和Hub and spoke
architecture的最大區別，應該是維度建模的原子層和一致性維度的建立。正因為預先建立的匯流排架構和一致性維度，所以這種架構可以保證在逐步建立資料集市的過程中還能保證企業資料的一致性。匯流排架構是資料倉儲架構方式從複雜走向簡單的一步，將維度建模的資料倉儲原子層和資料集市合而為一，一層就把資料倉儲建立好的，還能支援各種資料集市分析應用。
當然匯流排架構也有缺點，中心資料倉儲以維度模型儲存，對於特殊的非維度型分析應用會有侷限性，支援的不好。
6．複合式架構（Composite architecture）
複合式架構是我自己起的一個名字，當然它可能有自己的名字但是我不知道，歡迎大家指導。這種架構方式是綜合考慮Hub
and spoke architecture和Bus
architecture兩種架構方式，或者說綜合兩種方式得出的一種架構方式。這個，innovate511可能更有發言權，CDW架構應該就是這種架構方式的代表。
複合式架構的缺點也是很明顯，架構過於複雜，（比CIF還要複雜），企業內資料量大的話，每一次搬動都會非常麻煩。
呵呵，簡單的整理的各種架構，也大略談了一些缺點，至於那種架構好，那種不好，我不想和大家爭論，我想它們都有自己的適用範圍吧。歡迎大家對我文章中的錯誤和描述不清的地方進行指導。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
2
發件人： 土包子 - 檢視個人資料
日期： 2006年12月10日(星期日) 下午7時09分
電子郵件： "土包子"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 刪除 | 報告濫用行為 | 查詢此作者的帖子
這樣的結構描述未免太虛了一點。
最好有個圖例之類的，一堆的英文名詞看得不知所以然了，呵呵
歡迎訪問： http://PercyWang.itpub.net
回覆 回覆，幷包含引用 »
3
發件人： innovate511 - 檢視個人資料
日期： 2006年12月11日(星期一) 上午12時50分
電子郵件： "innovate511"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
覺得還是和具體情況有關吧。
有多大規模的專案、企業期望（包括期望的生命週期）、企業投資等都有關係。當然，正如前面分析到的，目前已上專案中，各種架構都嘗試過了，優缺點都很明顯。
不過複合式架構的缺點，我覺得並非搬動麻煩，而是整體要求很高，無論是EDW資料整合，還是類似HUB的CDW建設，再到資料集市，介面很多，對設計要求高，而對開發和測試的要求也很高，任何一步沒走好，都可能導致專案瀕臨失敗。這也是90年代很多想模仿CDW思想的專案失敗的重要原因。但是效果也是很明顯的，即使數萬計的終端使用者，各個部門世界各地的分公司的四大BI需求全部能滿足，由於所有複雜資料轉換問題都在後臺已經完成了，BI工具可以更穩定更快速地實現BI。同時由於非常靈活，也能滿足更多資料來源和業務的加入，實現系統長期使用，避免重複投資帶來的資金投入過大、穩定性降低、一致性在重複上專案後不能保證、前期專案維護問題太多導致終端使用者不滿等缺點。
至於資料搬動問題，我覺得不是大問題，因為沒一步也可以看成一個獨立的整體，只要按照流程移植，是不存在風險的，包括利用Kimball的思想進行DMR（Data
Mart
Restructure），資料集市也可以不斷擴大或者拆分來滿足更復雜BI整體需求，在這些靈活度方面我還是很有信心的。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
4
發件人： Qing - 檢視個人資料
日期： 2006年12月11日(星期一) 下午1時55分
電子郵件： Qing
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這兩天關於資料倉儲架構的討論甚歡，看了jerome、innovate的介紹，有些東西清晰了不少。Jerome提出六種架構，Innovate提出架構面臨的四種需求，以及四級架構抽象級別。下面我就充當主持人的角色，再歸納一下這個六、四、四，各位還請繼續探討。
六種架構（Jerome提出）：
1、獨立資料集市：如果你對構建一個大型資料倉儲沒把握，可以從獨立的資料集市入手；
2、聯邦式：如果你已經有若干資料集市，但又不想建立一個物理集中的資料倉儲，可以考慮聯邦式的；
3、集中式：針對不同資料來源，建立物理集中的資料倉儲，任何分析都從中取數；
4、CIF式：如果你有決心要構建一個大大的資料倉儲，充分規劃好這個資訊工廠。建立物理集中資料倉儲，並且為專門應用建立資料集市；
5、匯流排式：如果你想快一點看到效果，又不想向獨立資料集市那樣，可能浪費投資，採用匯流排架構；統一規劃，儘快實施。
6、複合式：綜合CIF，偏向資料的用CIF，偏向應用的用匯流排架構。
我想，對於電信行業的經營分析系統來說，大部分是比較符合"集中式"的，因為它從不同資料來源物理集中了資料，並且沒有單獨構建資料集市，大多隻是在資料倉儲架構裡面劃出一層DM層出來（不知道算不算）。當然，也有可能是使用匯流排架構的，畢竟這個見效快一點，在目前這個階段，"快"還是一個優先考慮的因素。
架構四種需求（Innovate提出）：
1、對資料的整合需求；
2、對業務的分解需求；
3、對資料的效率需求；
4、對需求變化的需求；
Innovate對這四種需求並沒有多說，為什麼分成這4種，是否還有別的類別？看起來業務的分解和需求變化都是指業務需求（可能只是前者是現有業務的功能分解，後者是業務需求的變化吧）。如果要對需求進行分類，還得看看都是什麼角色提出這些需求的。處理資料的人，希望架構能夠方便自己，使用資料的，希望能夠快速、安全地訪問......我想這就是需求分類的依據。
架構的四層抽象級別（Innovate提出）：
1、整體IT架構；諸如硬體、網路體系，或SOA等等；
2、資料倉儲架構；諸如前面介紹的匯流排式、CIF架構等；
3、功能架構；如何支撐ETL、OLAP、報表展現、Portal等等功能；
4、應用架構；如何支撐具體的業務，例如對客戶通話行為的分析，這是電信行業相關的。
將架構分成不同的抽象級別，這是顯而易見的。例如SOA肯定是比J2EE更加抽象的，J2EE也許不適合資料倉儲系統的架構，但SOA卻能適合。到了第三層架構，至少都是能夠適合不同行業的資料倉儲專案的，但到了第四層，便只是服務於專門的行業了。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
5
發件人： yushano@gmail.com - 檢視個人資料
日期： 2006年12月12日(星期二) 下午3時24分
電子郵件： "yush...@gmail.com"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
在市區的電子政務中，要對市級的各個部門進行資料整合。因為這些部門多數都是自上而下的系統，是由國家中央、省到地方市區的。比如公安、稅務、人民銀行都是自成體系的業務系統。再如國家統計局各個專業指標（人口，工業，農業等等）的資訊系統也都是自成體系的，從中央推向地方區鎮，而要想得到市區一級的綜合統計指標（人均純收入，GDP，社會消費零售額等），就必須對各個專業指標進行整合，它們都是異構的資料庫和資料標準（叫資料集市？），而整合形成的資料平臺叫資料倉儲？是形成一箇中介軟體式統一規劃的資料標準還是做介面表呢？如果要想橫向協同利用各個局的資料，比如市區政府想利用這些資料，應該採取上述的哪種方案呢？我想雖然我們應用目標的出發點不一樣，但是碰到的資料整合問題應該是相通的吧。
回覆 回覆，幷包含引用 » 為此帖評分：
6
發件人： goldenfish - 檢視個人資料
日期： 2006年12月13日(星期三) 上午10時16分
電子郵件： "goldenfish"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這種情況下資料整合的挑戰首先來源於管理模式。市區政府想要利用這些資料，但這些資料的所有權並不直接屬於市區政府。以前遇到的情況是，市長辦公會請各部門一把手去，專門討論如何給資料的問題。每個部門都說自己的明細資料機密性很高，搞不好就引起社會問題，不願意給，能不能只給報表？如果給的話，能不能給去年的資料？或者給的話，只給一次？要想動態實時的拿到這些資料，更是不可能的任務。大的國企也有這個問題，法人層級太多，總部想要下面的資料也是被推三阻四，軟磨硬泡的不給。
其次，市區一級的綜合統計指標體系如何建立。從一個市區的角度自定義一套綜合統計指標體系，有點勉為其難。與國家統計局的統計口徑是否保持一致？如果全然一致，為什麼不從本市的統計局直接取？當然，統計局可能走的是一套自己的統計方法、例如抽樣；自己的頻度，例如一季一次；可能只向上級統計機構負責，而不向平級下級負責等等，以至於統計局的資料很難直接使用。統計指標體系的建立要把各主要業務部門的核心指標匯聚到一起，剔除重疊和不一致，有些需對跨部門的資料進行合併。這個指標體系的建立也是很大的挑戰。
最後才是技術架構如何建立的問題。沒有通用的或絕對正確的技術架構。它是解決具體問題的，隨著實際狀況的不同而調整。由於上述管理的和安全的原因，從源系統直接取數恐怕是很難實現的，退而求其次，只能要介面表或介面檔案。如果不能從源系統的資料直接匯出，可能還要定義介面格式，由開發系統的廠商提供。介面表（或介面檔案）放置到從介面緩衝區轉移到一個集中的場地（伺服器）進行資料整合。統一規劃的資料標準很難約束到每個部門的業務系統，畢竟都是垂直條線下來的；現實一點，只能約束介面標準。在設計中還要考慮資料如何儲存（資料結構）、取數的頻度、資料保留多久、整合後資料是否有需要回流到源系統等問題。此外，還要考慮有部分資料很難取到原始明細，要有人工補錄的手段。
"yush...@gmail.com 寫道：
"
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
> 在市區的電子政務中，要對市級的各個部門進行資料整合。因為這些部門多數都是自上而下的系統，是由國家中央、省到地方市區的。比如公安、稅務、人民銀行都是自成體系的業務系統。再如國家統計局各個專業指標（人口，工業，農業等等）的資訊系統也都是自成體系的，從中央推向地方區鎮，而要想得到市區一級的綜合統計指標（人均純收入，GDP，社會消費零售額等），就必須對各個專業指標進行整合，它們都是異構的資料庫和資料標準（叫資料集市？），而整合形成的資料平臺叫資料倉儲？是形成一箇中介軟體式統一規劃的資料標準還是做介面表呢？如果要想橫向協同利用各個局的資料，比如市區政府想利用這些資料，應該採取上述的哪種方案呢？我想雖然我們應用目標的出發點不一樣，但是碰到的資料整合問題應該是相通的吧。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
7
發件人： Qing - 檢視個人資料
日期： 2006年12月13日(星期三) 下午1時04分
電子郵件： Qing
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
看到這個問題，頭腦中首先碰出來的一個想法是——"可以用聯邦式資料倉儲的架構"。因為對於已經自成體系的系統，將資料整合到一個物理資料倉儲是否現實？後來看到goldenfish的回覆，提到首要的挑戰在於"管理模式"。應該就是這個道理吧。管理的整合比資料整合要難，何不避難從簡？
當然，由於對電子政務中的系統不甚瞭解，不管此處說得是否合理，能夠對思路有所開拓就足夠了。
為什麼當初的第一反映是"聯邦式資料倉儲"呢，如此問自己？也許正是餘山老師提到了自成體系的系統，這些系統由不同開發商完成，也沒有什麼統一的標準，系統的設計思想、編碼肯定是千奇百怪，而且涉及到安全性的問題。所以我想，可能用一種虛擬的資料倉儲更加合適，即實際的資料都還是位於各自的系統當中，而所謂資料整合，是建立一個可以容納所有這些系統（現實一點，可能是這些系統的交集部分）的框架，框架裡面放置的是類似"資料指標"那樣的東西，這是虛擬的，當你需要查詢什麼資料的時候，其實這個框架是將查詢定位給具體的系統了。比如要查詢某個人的信貸、犯罪、稅務情況，好似從一個統一的平臺輸入了ID號，返回以上若干資訊，但資料都還是存放在金融、公安和稅務的系統裡面的。
由此深入思考，我認為與其說這個案例是"資料的整合"，不如說是"應用的整合"。所以，根本也用不上上面提到的資料倉儲架構，也不是什麼"聯邦式架構"，可能應該在面向服務架構（SOA）中尋找答案。
建立一個資料倉儲，不如建立一些標準，可以將每個獨立系統想象成為一個服務提供者，它可以提供什麼服務，是經過註冊的。比如金融系統可以根據一個個人ID給出此人的帳戶、貸款、信用等資訊，可以根據一個公司的程式碼，給出公司的資訊，或者可以提供年度的統計指標等等。當然，這些資訊的提取應該是基於金融系統內部的資料倉儲的，總不能從業務系統去取。此處關鍵的就是如何定義這些"服務提供者"提供的服務，也就是標準。輸入什麼、輸出什麼、甚至是輸入輸出的規格標準化（例如身份ID的要求，輸出資料中，性別的編碼規則）、許可權控制、如何註冊這些服務等等。
有這樣的標準，具體的實現交給獨立系統的實現廠商。而至於基於這些服務能夠作甚麼用途，那得具體看應用而定。
On 12/12/06, yush...@gmail.com wrote:
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
> ....
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
8
發件人： goldenfish3 - 檢視個人資料
日期： 2006年12月13日(星期三) 下午2時06分
電子郵件： goldenfish3
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
資料整合和應用整合有些區別。通常，應用整合指EAI，現在已經轉向以SOA的理念實現EAI。資料整合通常指透過資料整合層或資料整合平臺、EDW等進行的資料整合（Integration）/整合（Consolidation）/融合（Mediation）。廣義的應用整合包含業務應用間的資料整合，即A的資料送往B，例如保險營業系統中的保單收費送往財務系統入帳。但應用整合更多是指A系統要求B完成一個操作，B完成後返回一個確認，以及這樣的多步操作形成一個流程，流程整合是應用整合（整合）的高階應用。資料整合往往是為分析目的完成的。不同系統的資料送往一個整合平臺，進行資料清洗和整合，為了實現分析應用。兩者結合起來，可以稱之為企業整合（EI）。
如上所述，兩者是有交叉的。特別是SOA與主資料管理相結合之後，主資料整合透過SOA實現，主資料為業務系統形成統一的檢視（在電信裡已經有SID的應用）。這種理念的出現體現了SOA對傳統業務系統架構的衝擊，也是應用整合的一個發展方向。但主資料管理並不能替代資料整合，不能替代資料的清洗整合。兩者服務於不同的目的，有不同（儘管可能有所重疊）的範圍。倒是EII的出現對傳統的資料整合架構有所衝擊。EII體現了一種實時資料整合的理念，來自不同源系統的資料不集中儲存，而是使用的時候邊傳輸邊整合。但顯然，目前EII的實現不能隔離對業務系統資料庫的訪問壓力，對於大量資料很難有效處理。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
9
發件人： yushano@gmail.com - 檢視個人資料
日期： 2006年12月13日(星期三) 下午2時13分
電子郵件： "yush...@gmail.com"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
感謝諸位賜教。如上所言，管理的整合很難。但正是管理的界限形成了資料統一規劃的界限，異構系統就是這樣形成的。對於一個企業來說，消除部門的異構資料還可以透過統一規劃的方法來達到共享，而對於像市級的各個專業局就是難以實現了。
就我目前調研的情況看，在市區一級的ＯＡ系統，聯合審批（所謂陽光政務），還有財政局因為要對其它部門實現統一國庫支付（兩千以上的採購），這些系統的橫向協同比較緊密，好像可以進行統一的資料規劃整合。
劉慶最後的應用整合提法令我很開竅，打個比喻，是否如同XML網路消除異構的方法，不是在文字的儲存編碼上去統一整合，而是在顯示介面的語言上統一整合？這樣就能與作業系統，資料庫，字元資料的儲存標準都無關？從而達到統一。
回覆 回覆，幷包含引用 » 為此帖評分：
10
發件人： goldenfish3 - 檢視個人資料
日期： 2006年12月19日(星期二) 下午2時39分
電子郵件： goldenfish3
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這種情況下資料整合的挑戰首先來源於管理模式。市區政府想要利用這些資料，但這些資料的所有權並不直接屬於市區政府。以前遇到的情況是，市長辦公會請各部門一把手去，專門討論如何給資料的問題。每個部門都說自己的明細資料機密性很高，搞不好就引起社會問題，不願意給，能不能只給報表？如果給的話，能不能給去年的資料？或者給的話，只給一次？要想動態實時的拿到這些資料，更是不可能的任務。大的國企也有這個問題，法人層級太多，總部想要下面的資料也是被推三阻四，軟磨硬泡的不給。
其次，市區一級的綜合統計指標體系如何建立。從一個市區的角度自定義一套綜合統計指標體系，有點勉為其難。與國家統計局的統計口徑是否保持一致？如果全然一致，為什麼不從本市的統計局直接取？當然，統計局可能走的是一套自己的統計方法、例如抽樣；自己的頻度，例如一季一次；可能只向上級統計機構負責，而不向平級下級負責等等，以至於統計局的資料很難直接使用。統計指標體系的建立要把各主要業務部門的核心指標匯聚到一起，剔除重疊和不一致，有些需對跨部門的資料進行合併。這個指標體系的建立也是很大的挑戰。
最後才是技術架構如何建立的問題。沒有通用的或絕對正確的技術架構。它是解決具體問題的，隨著實際狀況的不同而調整。由於上述管理的和安全的原因，從源系統直接取數恐怕是很難實現的，退而求其次，只能要介面表或介面檔案。如果不能從源系統的資料直接匯出，可能還要定義介面格式，由開發系統的廠商提供。介面表（或介面檔案）放置到從介面緩衝區轉移到一個集中的場地（伺服器）進行資料整合。統一規劃的資料標準很難約束到每個部門的業務系統，畢竟都是垂直條線下來的；現實一點，只能約束介面標準。在設計中還要考慮資料如何儲存（資料結構）、取數的頻度、資料保留多久、整合後資料是否有需要回流到源系統等問題。此外，還要考慮有部分資料很難取到原始明細，要有人工補錄的手段。
以下內容均引自於ttnn網站，詳細連結如下：
1
發件人： Jerome - 檢視個人資料
日期： 2006年12月10日(星期日) 下午4時36分
電子郵件： "Jerome"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
最近大家對資料倉儲架構的討論又多了起來，我在這裡對一些架構進行一下簡單的整理。目的是給大家樹立一個靶子，大家可以在這篇文章後盡情的批判和補充。
我把我聽說過的架構都歸整在一起，分了六類，其中和很多說明是我個人的理解，不見得正確，大家多多指導。
1．獨立的資料集市架構（Independent data mart architecture）
獨立的資料集市架構有時也稱為獨立的資料倉儲架構，應該是出現最早的架構方式，也是很常見的方式。特別是對於中小企業、中小開發公司，出於成本和見效快的考慮都會採用這種架構方式。大家對這種架構方式一定也很熟。
這種架構方式的缺點也很明顯，不是企業內一致的資料，產生資訊孤島。當然我企業就是很小，就一個系統，不用整合，一個資料集市足以的情況下采用這種方式也沒什麼。先期小投資，讓企業看看效果，以後發展大了再考慮重新建立資料倉儲。
2．聯邦式資料倉儲架構（Federated data warehouse
architecture）
這種架構方式我之前寫過一點簡單介紹，當然，我對這種方式也不熟，介紹的也是亂七八糟。我想它的出現應該是由於，企業發展的初期建立了幾個獨立的資料集市架構，後來發現這樣不行，資料沒整合，要解決資訊孤島得想辦法。推倒重建當然好，不過投入太大，以前的資料集市還想用，怎麼辦。於是，想出另一種辦法，在各個獨立的資料集市間建立一些對照表，在不推倒它們的基礎上能進行一下資料交換。後來，慢慢發現，早想好整合策略，直接這樣建資料倉儲也可以，於是，地域聯邦、功能聯邦的概念也就都提出來了。
聯邦架構的缺點也很明顯，除非建立之初就採用類似匯流排架構的方法實現資料一致，否則很容易出現資料不一致，導致整合的不徹底。如果之初就考慮好的話，和匯流排架構的差別就不大了。當然，對於臨時解決企業原有獨立資料集市的資料交換問題，聯邦架構還是有一定作用的。
3．集中式架構（Centralized architecture）
集中式架構方式的出現，標識著資料倉儲架構已經進入比較成熟的時期。他的架構方式是建立物理的EDW，即中心資料倉儲，資料都集中的EDW中，應用和分析程式都在EDW中進行訪問，資料是全企業內一致的。隨著ROLAP的發展，在這種集中式架構中建立ROLAP開始比較流行，常見的MicroStrategy公司的解決方案就是在EDW中建立ROLAP。ROLAP單獨建表儲存後設資料，只儲存維度模型的關係，不儲存維度模型的資料，由MicroStrategy的應用去解析，加上應用伺服器作為快取，速度還可以。
這種方式也有一些缺點，如擴充套件能力差，對EDW所在的RDBMS要求太高，隨著資料量和分析的逐步增長，就不得不再把資料進行分離。如果在EDW的基礎上進行資料分離，為不同的應用單獨建立資料集市或者挖掘倉庫，集中式結構也就演變成Hub
and Spoke架構方式。
4．集線器和車輪輻條架構（Hub and spoke architecture）
其實我更想直接稱之為企業資訊工廠架構（Corporate
information factory
architecture），集線器和車輪輻條架構聽起來比較彆扭，叫起來也不響亮。而企業資訊工廠應該是這種架構方式的最出色的代表。從名稱我們也能大概猜個差不多，中心資料倉儲EDW從各個源系統收集資料，將資料提供給各個資料集市和挖掘倉庫，功能和集線器很相似，所以稱為Hub。如果大家把圖畫出來，可能會更形象一些，EDW和各個源資料庫及資料集市、挖掘倉庫之間都連一條線，看起來就向一個車輪，這些連線就像車輪輻條，所以稱為Spoke。而這種採用中心資料倉儲EDW整合資料，再分散到各個資料集市使用資料的方式就形象的稱為Hub
and spoke architecture。
這種架構方式當然也有缺點，雖然是在整合的中心資料倉儲EDW上建立資料集市，但是這些資料集市之間還是不能進行資料交換的，大家建立的方法和ETL程式都會不同，各個資料集市之間的資料不見得的是一致的。而且這種架構方式開始變得複雜。
5．匯流排架構（Bus architecture）
匯流排架構和Hub and spoke
architecture的最大區別，應該是維度建模的原子層和一致性維度的建立。正因為預先建立的匯流排架構和一致性維度，所以這種架構可以保證在逐步建立資料集市的過程中還能保證企業資料的一致性。匯流排架構是資料倉儲架構方式從複雜走向簡單的一步，將維度建模的資料倉儲原子層和資料集市合而為一，一層就把資料倉儲建立好的，還能支援各種資料集市分析應用。
當然匯流排架構也有缺點，中心資料倉儲以維度模型儲存，對於特殊的非維度型分析應用會有侷限性，支援的不好。
6．複合式架構（Composite architecture）
複合式架構是我自己起的一個名字，當然它可能有自己的名字但是我不知道，歡迎大家指導。這種架構方式是綜合考慮Hub
and spoke architecture和Bus
architecture兩種架構方式，或者說綜合兩種方式得出的一種架構方式。這個，innovate511可能更有發言權，CDW架構應該就是這種架構方式的代表。
複合式架構的缺點也是很明顯，架構過於複雜，（比CIF還要複雜），企業內資料量大的話，每一次搬動都會非常麻煩。
呵呵，簡單的整理的各種架構，也大略談了一些缺點，至於那種架構好，那種不好，我不想和大家爭論，我想它們都有自己的適用範圍吧。歡迎大家對我文章中的錯誤和描述不清的地方進行指導。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
2
發件人： 土包子 - 檢視個人資料
日期： 2006年12月10日(星期日) 下午7時09分
電子郵件： "土包子"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 刪除 | 報告濫用行為 | 查詢此作者的帖子
這樣的結構描述未免太虛了一點。
最好有個圖例之類的，一堆的英文名詞看得不知所以然了，呵呵
歡迎訪問： http://PercyWang.itpub.net
回覆 回覆，幷包含引用 »
3
發件人： innovate511 - 檢視個人資料
日期： 2006年12月11日(星期一) 上午12時50分
電子郵件： "innovate511"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
覺得還是和具體情況有關吧。
有多大規模的專案、企業期望（包括期望的生命週期）、企業投資等都有關係。當然，正如前面分析到的，目前已上專案中，各種架構都嘗試過了，優缺點都很明顯。
不過複合式架構的缺點，我覺得並非搬動麻煩，而是整體要求很高，無論是EDW資料整合，還是類似HUB的CDW建設，再到資料集市，介面很多，對設計要求高，而對開發和測試的要求也很高，任何一步沒走好，都可能導致專案瀕臨失敗。這也是90年代很多想模仿CDW思想的專案失敗的重要原因。但是效果也是很明顯的，即使數萬計的終端使用者，各個部門世界各地的分公司的四大BI需求全部能滿足，由於所有複雜資料轉換問題都在後臺已經完成了，BI工具可以更穩定更快速地實現BI。同時由於非常靈活，也能滿足更多資料來源和業務的加入，實現系統長期使用，避免重複投資帶來的資金投入過大、穩定性降低、一致性在重複上專案後不能保證、前期專案維護問題太多導致終端使用者不滿等缺點。
至於資料搬動問題，我覺得不是大問題，因為沒一步也可以看成一個獨立的整體，只要按照流程移植，是不存在風險的，包括利用Kimball的思想進行DMR（Data
Mart
Restructure），資料集市也可以不斷擴大或者拆分來滿足更復雜BI整體需求，在這些靈活度方面我還是很有信心的。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
4
發件人： Qing - 檢視個人資料
日期： 2006年12月11日(星期一) 下午1時55分
電子郵件： Qing
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這兩天關於資料倉儲架構的討論甚歡，看了jerome、innovate的介紹，有些東西清晰了不少。Jerome提出六種架構，Innovate提出架構面臨的四種需求，以及四級架構抽象級別。下面我就充當主持人的角色，再歸納一下這個六、四、四，各位還請繼續探討。
六種架構（Jerome提出）：
1、獨立資料集市：如果你對構建一個大型資料倉儲沒把握，可以從獨立的資料集市入手；
2、聯邦式：如果你已經有若干資料集市，但又不想建立一個物理集中的資料倉儲，可以考慮聯邦式的；
3、集中式：針對不同資料來源，建立物理集中的資料倉儲，任何分析都從中取數；
4、CIF式：如果你有決心要構建一個大大的資料倉儲，充分規劃好這個資訊工廠。建立物理集中資料倉儲，並且為專門應用建立資料集市；
5、匯流排式：如果你想快一點看到效果，又不想向獨立資料集市那樣，可能浪費投資，採用匯流排架構；統一規劃，儘快實施。
6、複合式：綜合CIF，偏向資料的用CIF，偏向應用的用匯流排架構。
我想，對於電信行業的經營分析系統來說，大部分是比較符合"集中式"的，因為它從不同資料來源物理集中了資料，並且沒有單獨構建資料集市，大多隻是在資料倉儲架構裡面劃出一層DM層出來（不知道算不算）。當然，也有可能是使用匯流排架構的，畢竟這個見效快一點，在目前這個階段，"快"還是一個優先考慮的因素。
架構四種需求（Innovate提出）：
1、對資料的整合需求；
2、對業務的分解需求；
3、對資料的效率需求；
4、對需求變化的需求；
Innovate對這四種需求並沒有多說，為什麼分成這4種，是否還有別的類別？看起來業務的分解和需求變化都是指業務需求（可能只是前者是現有業務的功能分解，後者是業務需求的變化吧）。如果要對需求進行分類，還得看看都是什麼角色提出這些需求的。處理資料的人，希望架構能夠方便自己，使用資料的，希望能夠快速、安全地訪問......我想這就是需求分類的依據。
架構的四層抽象級別（Innovate提出）：
1、整體IT架構；諸如硬體、網路體系，或SOA等等；
2、資料倉儲架構；諸如前面介紹的匯流排式、CIF架構等；
3、功能架構；如何支撐ETL、OLAP、報表展現、Portal等等功能；
4、應用架構；如何支撐具體的業務，例如對客戶通話行為的分析，這是電信行業相關的。
將架構分成不同的抽象級別，這是顯而易見的。例如SOA肯定是比J2EE更加抽象的，J2EE也許不適合資料倉儲系統的架構，但SOA卻能適合。到了第三層架構，至少都是能夠適合不同行業的資料倉儲專案的，但到了第四層，便只是服務於專門的行業了。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
5
發件人： yushano@gmail.com - 檢視個人資料
日期： 2006年12月12日(星期二) 下午3時24分
電子郵件： "yush...@gmail.com"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
在市區的電子政務中，要對市級的各個部門進行資料整合。因為這些部門多數都是自上而下的系統，是由國家中央、省到地方市區的。比如公安、稅務、人民銀行都是自成體系的業務系統。再如國家統計局各個專業指標（人口，工業，農業等等）的資訊系統也都是自成體系的，從中央推向地方區鎮，而要想得到市區一級的綜合統計指標（人均純收入，GDP，社會消費零售額等），就必須對各個專業指標進行整合，它們都是異構的資料庫和資料標準（叫資料集市？），而整合形成的資料平臺叫資料倉儲？是形成一箇中介軟體式統一規劃的資料標準還是做介面表呢？如果要想橫向協同利用各個局的資料，比如市區政府想利用這些資料，應該採取上述的哪種方案呢？我想雖然我們應用目標的出發點不一樣，但是碰到的資料整合問題應該是相通的吧。
回覆 回覆，幷包含引用 » 為此帖評分：
6
發件人： goldenfish - 檢視個人資料
日期： 2006年12月13日(星期三) 上午10時16分
電子郵件： "goldenfish"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這種情況下資料整合的挑戰首先來源於管理模式。市區政府想要利用這些資料，但這些資料的所有權並不直接屬於市區政府。以前遇到的情況是，市長辦公會請各部門一把手去，專門討論如何給資料的問題。每個部門都說自己的明細資料機密性很高，搞不好就引起社會問題，不願意給，能不能只給報表？如果給的話，能不能給去年的資料？或者給的話，只給一次？要想動態實時的拿到這些資料，更是不可能的任務。大的國企也有這個問題，法人層級太多，總部想要下面的資料也是被推三阻四，軟磨硬泡的不給。
其次，市區一級的綜合統計指標體系如何建立。從一個市區的角度自定義一套綜合統計指標體系，有點勉為其難。與國家統計局的統計口徑是否保持一致？如果全然一致，為什麼不從本市的統計局直接取？當然，統計局可能走的是一套自己的統計方法、例如抽樣；自己的頻度，例如一季一次；可能只向上級統計機構負責，而不向平級下級負責等等，以至於統計局的資料很難直接使用。統計指標體系的建立要把各主要業務部門的核心指標匯聚到一起，剔除重疊和不一致，有些需對跨部門的資料進行合併。這個指標體系的建立也是很大的挑戰。
最後才是技術架構如何建立的問題。沒有通用的或絕對正確的技術架構。它是解決具體問題的，隨著實際狀況的不同而調整。由於上述管理的和安全的原因，從源系統直接取數恐怕是很難實現的，退而求其次，只能要介面表或介面檔案。如果不能從源系統的資料直接匯出，可能還要定義介面格式，由開發系統的廠商提供。介面表（或介面檔案）放置到從介面緩衝區轉移到一個集中的場地（伺服器）進行資料整合。統一規劃的資料標準很難約束到每個部門的業務系統，畢竟都是垂直條線下來的；現實一點，只能約束介面標準。在設計中還要考慮資料如何儲存（資料結構）、取數的頻度、資料保留多久、整合後資料是否有需要回流到源系統等問題。此外，還要考慮有部分資料很難取到原始明細，要有人工補錄的手段。
"yush...@gmail.com 寫道：
"
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
> 在市區的電子政務中，要對市級的各個部門進行資料整合。因為這些部門多數都是自上而下的系統，是由國家中央、省到地方市區的。比如公安、稅務、人民銀行都是自成體系的業務系統。再如國家統計局各個專業指標（人口，工業，農業等等）的資訊系統也都是自成體系的，從中央推向地方區鎮，而要想得到市區一級的綜合統計指標（人均純收入，GDP，社會消費零售額等），就必須對各個專業指標進行整合，它們都是異構的資料庫和資料標準（叫資料集市？），而整合形成的資料平臺叫資料倉儲？是形成一箇中介軟體式統一規劃的資料標準還是做介面表呢？如果要想橫向協同利用各個局的資料，比如市區政府想利用這些資料，應該採取上述的哪種方案呢？我想雖然我們應用目標的出發點不一樣，但是碰到的資料整合問題應該是相通的吧。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
7
發件人： Qing - 檢視個人資料
日期： 2006年12月13日(星期三) 下午1時04分
電子郵件： Qing
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
看到這個問題，頭腦中首先碰出來的一個想法是——"可以用聯邦式資料倉儲的架構"。因為對於已經自成體系的系統，將資料整合到一個物理資料倉儲是否現實？後來看到goldenfish的回覆，提到首要的挑戰在於"管理模式"。應該就是這個道理吧。管理的整合比資料整合要難，何不避難從簡？
當然，由於對電子政務中的系統不甚瞭解，不管此處說得是否合理，能夠對思路有所開拓就足夠了。
為什麼當初的第一反映是"聯邦式資料倉儲"呢，如此問自己？也許正是餘山老師提到了自成體系的系統，這些系統由不同開發商完成，也沒有什麼統一的標準，系統的設計思想、編碼肯定是千奇百怪，而且涉及到安全性的問題。所以我想，可能用一種虛擬的資料倉儲更加合適，即實際的資料都還是位於各自的系統當中，而所謂資料整合，是建立一個可以容納所有這些系統（現實一點，可能是這些系統的交集部分）的框架，框架裡面放置的是類似"資料指標"那樣的東西，這是虛擬的，當你需要查詢什麼資料的時候，其實這個框架是將查詢定位給具體的系統了。比如要查詢某個人的信貸、犯罪、稅務情況，好似從一個統一的平臺輸入了ID號，返回以上若干資訊，但資料都還是存放在金融、公安和稅務的系統裡面的。
由此深入思考，我認為與其說這個案例是"資料的整合"，不如說是"應用的整合"。所以，根本也用不上上面提到的資料倉儲架構，也不是什麼"聯邦式架構"，可能應該在面向服務架構（SOA）中尋找答案。
建立一個資料倉儲，不如建立一些標準，可以將每個獨立系統想象成為一個服務提供者，它可以提供什麼服務，是經過註冊的。比如金融系統可以根據一個個人ID給出此人的帳戶、貸款、信用等資訊，可以根據一個公司的程式碼，給出公司的資訊，或者可以提供年度的統計指標等等。當然，這些資訊的提取應該是基於金融系統內部的資料倉儲的，總不能從業務系統去取。此處關鍵的就是如何定義這些"服務提供者"提供的服務，也就是標準。輸入什麼、輸出什麼、甚至是輸入輸出的規格標準化（例如身份ID的要求，輸出資料中，性別的編碼規則）、許可權控制、如何註冊這些服務等等。
有這樣的標準，具體的實現交給獨立系統的實現廠商。而至於基於這些服務能夠作甚麼用途，那得具體看應用而定。
On 12/12/06, yush...@gmail.com
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?
> ....
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
8
發件人： goldenfish3 - 檢視個人資料
日期： 2006年12月13日(星期三) 下午2時06分
電子郵件： goldenfish3
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
資料整合和應用整合有些區別。通常，應用整合指EAI，現在已經轉向以SOA的理念實現EAI。資料整合通常指透過資料整合層或資料整合平臺、EDW等進行的資料整合（Integration）/整合（Consolidation）/融合（Mediation）。廣義的應用整合包含業務應用間的資料整合，即A的資料送往B，例如保險營業系統中的保單收費送往財務系統入帳。但應用整合更多是指A系統要求B完成一個操作，B完成後返回一個確認，以及這樣的多步操作形成一個流程，流程整合是應用整合（整合）的高階應用。資料整合往往是為分析目的完成的。不同系統的資料送往一個整合平臺，進行資料清洗和整合，為了實現分析應用。兩者結合起來，可以稱之為企業整合（EI）。
如上所述，兩者是有交叉的。特別是SOA與主資料管理相結合之後，主資料整合透過SOA實現，主資料為業務系統形成統一的檢視（在電信裡已經有SID的應用）。這種理念的出現體現了SOA對傳統業務系統架構的衝擊，也是應用整合的一個發展方向。但主資料管理並不能替代資料整合，不能替代資料的清洗整合。兩者服務於不同的目的，有不同（儘管可能有所重疊）的範圍。倒是EII的出現對傳統的資料整合架構有所衝擊。EII體現了一種實時資料整合的理念，來自不同源系統的資料不集中儲存，而是使用的時候邊傳輸邊整合。但顯然，目前EII的實現不能隔離對業務系統資料庫的訪問壓力，對於大量資料很難有效處理。
回覆 回覆，幷包含引用 » 為此帖評分： Text for clearing space
9
發件人： yushano@gmail.com - 檢視個人資料
日期： 2006年12月13日(星期三) 下午2時13分
電子郵件： "yush...@gmail.com"
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
感謝諸位賜教。如上所言，管理的整合很難。但正是管理的界限形成了資料統一規劃的界限，異構系統就是這樣形成的。對於一個企業來說，消除部門的異構資料還可以透過統一規劃的方法來達到共享，而對於像市級的各個專業局就是難以實現了。
就我目前調研的情況看，在市區一級的ＯＡ系統，聯合審批（所謂陽光政務），還有財政局因為要對其它部門實現統一國庫支付（兩千以上的採購），這些系統的橫向協同比較緊密，好像可以進行統一的資料規劃整合。
劉慶最後的應用整合提法令我很開竅，打個比喻，是否如同XML網路消除異構的方法，不是在文字的儲存編碼上去統一整合，而是在顯示介面的語言上統一整合？這樣就能與作業系統，資料庫，字元資料的儲存標準都無關？從而達到統一。
回覆 回覆，幷包含引用 » 為此帖評分：
10
發件人： goldenfish3 - 檢視個人資料
日期： 2006年12月19日(星期二) 下午2時39分
電子郵件： goldenfish3
尚未評分
評級：
顯示選項
回覆 | 答覆作者 | 轉發 | 列印 | 顯示個別帖子 | 顯示原始郵件 | 報告濫用行為 | 查詢此作者的帖子
這種情況下資料整合的挑戰首先來源於管理模式。市區政府想要利用這些資料，但這些資料的所有權並不直接屬於市區政府。以前遇到的情況是，市長辦公會請各部門一把手去，專門討論如何給資料的問題。每個部門都說自己的明細資料機密性很高，搞不好就引起社會問題，不願意給，能不能只給報表？如果給的話，能不能給去年的資料？或者給的話，只給一次？要想動態實時的拿到這些資料，更是不可能的任務。大的國企也有這個問題，法人層級太多，總部想要下面的資料也是被推三阻四，軟磨硬泡的不給。
其次，市區一級的綜合統計指標體系如何建立。從一個市區的角度自定義一套綜合統計指標體系，有點勉為其難。與國家統計局的統計口徑是否保持一致？如果全然一致，為什麼不從本市的統計局直接取？當然，統計局可能走的是一套自己的統計方法、例如抽樣；自己的頻度，例如一季一次；可能只向上級統計機構負責，而不向平級下級負責等等，以至於統計局的資料很難直接使用。統計指標體系的建立要把各主要業務部門的核心指標匯聚到一起，剔除重疊和不一致，有些需對跨部門的資料進行合併。這個指標體系的建立也是很大的挑戰。
最後才是技術架構如何建立的問題。沒有通用的或絕對正確的技術架構。它是解決具體問題的，隨著實際狀況的不同而調整。由於上述管理的和安全的原因，從源系統直接取數恐怕是很難實現的，退而求其次，只能要介面表或介面檔案。如果不能從源系統的資料直接匯出，可能還要定義介面格式，由開發系統的廠商提供。介面表（或介面檔案）放置到從介面緩衝區轉移到一個集中的場地（伺服器）進行資料整合。統一規劃的資料標準很難約束到每個部門的業務系統，畢竟都是垂直條線下來的；現實一點，只能約束介面標準。在設計中還要考慮資料如何儲存（資料結構）、取數的頻度、資料保留多久、整合後資料是否有需要回流到源系統等問題。此外，還要考慮有部分資料很難取到原始明細，要有人工補錄的手段。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/6517/viewspace-145450/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 談談資料湖和資料倉儲
- 淺談資料倉儲和大資料大資料
- 談談人工智慧和機器學習的資料架構人工智慧機器學習架構
- 資料倉儲架構分層設計架構
- 分層架構在資料倉儲的應用架構
- 談談對資料架構的幾點認識架構
- 淺談資料倉儲質量管理流程
- 大資料架構和模式（一）——大資料分類和架構簡介大資料架構模式
- 大資料分類和架構簡介大資料架構
- 數倉架構發展史架構
- 資料倉儲技術分類術語
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 談談如何從資料湖（Data Lake）架構轉向資料網格（Data Mesh）架構架構
- 談談公司中研發體系的架構架構
- 淺談hdfs架構與資料流架構
- 談談專案架構架構
- 談談“資料庫中介軟體”生態與發展資料庫
- 談談工業企業如何將資料編織與傳統資料倉儲結合
- 設計資料倉儲和資料倉儲的粒度
- 資料倉儲架構師的崗位職責和崗位要求架構
- 阿里支付寶架構師：談談我眼中的高併發架構【好文】阿里架構
- 淺談資料庫發展史和 OceanBase 的誕生資料庫
- [原創]淺談大型網際網路架構發展架構
- 怎樣的架構設計才是真正的資料倉儲架構（轉載）架構
- 資料倉儲(5)數倉Kimball與Inmon架構的對比架構
- 談談UI架構設計的演化UI架構
- 美團DB資料同步到資料倉儲的架構與實踐架構
- 談談有效開展資料分析的關鍵技能
- 構建資料倉儲
- 談談MVVM和鏈式網路請求架構MVVM架構
- 論資料倉儲架構前需要考慮的問題架構
- 資料倉儲的構建(ZT)
- 聽HashData CEO暢談雲原生資料倉儲
- 漫談“資料湖”之價值與架構架構
- 談一談資料儲存與物聯網
- 談談資料資產和資料產品的異同
- 資料庫和資料倉儲資料庫
- 談談關於 iOS 的架構以及應用iOS架構