我們專案的定性分析：
首先，我們經常提到的運算元據儲存（
ods）與資料倉儲（
dw）的區別：
ods是介於db
和dw
之間的一種資料儲存技術，和原來面向應用的分散的
db相比，
ods中的資料組織方式和資料倉儲（
dw）一樣也是面向主題的和整合的，所以對進入
ods的資料也象進入資料倉儲的資料一樣進行整合處理。另外
ods只是存放當前或接近當前的資料，如果需要的話還可以對
ods中的資料進行增、刪和更新等操作，雖然
dw中的資料也是面向主題和整合的，但這些資料一般不進行修改，所以
ods和
dw的區別主要體現資料的可變性、當前性、穩定性、彙總度上。
簡單說ods只是業務資料庫的乙個備份或者映像，
ods中的資料也盡量不做轉換，而是原封不動地與業務資料庫保持一致，目的是為了使資料倉儲的處理和決策支援要求
olap
（聯機分析處理）與
oltp
（聯機事務處理）系統相隔離，減少決策支援要求對
oltp
系統的影響。
為什麼需要有乙個
ods系統呢？一般在帶有
ods的系統體系結構中，
ods都具備如下幾個作用： 1
）在業務系統和資料倉儲之間形成乙個隔離層； 2
）轉移一部分業務系統細節查詢的功能：
ods的資料從粒度、
組織方式等各個方面都保持了與業務系統的一致，那麼原來由業務系統產生的報表、細節資料的查詢自然能夠從
ods中進行，從而降低業務系統的查詢壓力； 3
）完成資料倉儲中不能完成的一些功能：
資料倉儲從巨集觀角度滿足企業的決策支援要求，而
ods層則從微觀角度反映細節交易資料或者低粒度的資料查詢要求。
經過上面對一些概念的描述，我一直在想，我們當前的電子銀行專案或給其他行開發的基於
odsb
開發的專案是
dw嗎？我們面對的是客戶提出的幾十甚至上百張的報表需求，專案完成的是以幾個業務主題建設的資料倉儲嗎？如果是資料倉儲，那提供使用者靈活的多維立方體、
olap
（聯機分析處理）分析中那裡？這些問題經過思考過後，我總結得出：雖然提供給使用者的是一大堆各種各樣的報表，但是資料倉儲的架構是存在的，首先在資料準備區（資料平台）中建立一致性維度、建立一致性事實的計算方法；其次在一致性維度、一致性事實的基礎上逐步建立資料集市，這個為電子銀行部提供的其實就是乙個資料集市，我們在這個資料集市上產生了業務報表，如果客戶需要，完全可以建立幾個如「渠道簽約分析」、「渠道交易分析」等業務主題，再通過
cognos
工具產生對應的多維立方體，提供管理層使用者上捲、下鑽等資料分析。這樣我們以後為其他部門每次增加資料集市，都會在資料準備區整合一致性維度，並將整合好的一致性維度同步更新到所有的資料集市。這樣，建立的所有資料集市合在一起就是乙個整合好的資料倉儲。這種資料倉儲架構（自下而上）具有逐步建設的特點，它的開發周期比其他架構（自上而下）方式的開發周期要短，風險和相應的成本也要低。
其實資料倉儲的建設還有一種「企業資訊工廠」（自上而下）的實現方式是，首先進行全企業的資料整合，建立企業資訊模型，即
edw。對於各種分析需求再建立相應的資料集市或者探索倉庫，其資料**於
edw，原子層給建立
olap
帶來一定的複雜性，但是對於建立更複雜的應用，如挖掘倉庫、探索倉庫提供了更好的支援。這類架構的建設週期比較長，相應的成本也比較高。使用者在短時間看不到想要的結果。
另外，基於
odsb
的報表開發類專案，在專案管理中也與一般的應用系統有所不同，這裡就不詳細說明了。
電子銀行業務分析系統 專案總結3 計畫執行總結
專案計畫執 況，主要從下面三個方面說明 1 專案內容 專案原需求要求完成報表數量有 88張，開發過程中由於對複雜而且過寬的報表拆分後，總過完成了 105張報表，再加上後期變更和新增需求追加了 20張報表，截至現在為止共開發 125張報表，17個維護模組。2 專案工期 專案工期原計畫是 2009年9 ...
銀行業務排程系統
一 銀行業務排程系統 一 需求 模擬實現銀行業務排程系統邏輯，具體需求如下 1.銀行內有6個業務視窗，1 4號視窗為普通視窗，5號視窗為快速視窗，6號視窗為vip視窗。2.有三種對應型別的客戶 vip客戶，普通客戶，快速客戶 辦理如交水電費 費之類業務的客戶 3.非同步隨機生成各種型別的客戶，生成各...
銀行業務系統1
用const定義全域性的常變數password，作為銀行卡的密碼。判斷輸入的密碼是否正確，如果不正確，提示，否則，繼續下面的工作。用switch多分支完成顯示。cpp view plaincopy all gight reserved.檔名稱 temp.cpp 版本號 v1.0 includeusi...