最近一直在sony參與乙個dw專案（sony china tri-one project），主要負責將使用者的生產及供分析資料從sap中etl到搭建在oracle中的pool裡，並為其它系統提供相應資料介面。並且這個pool也是由我們負責根據使用者的需求來設計並構建。客觀地說，我們的工作部分是整個dw專案中這個分支專案的基礎與關鍵核心。當然，了解和熟悉dw專案的人也都會贊同我的觀點。毋庸置疑，整個專案規模是很龐大，參與此專案的也都是幾個大公司，如ibm、hp、fujitsu等，我公司的名氣顯然沒前面幾個大，因此在整個專案中也只是分了一小杯羹。前面的幾個公司參與此專案的大多
二、三十號人馬，顯得浩浩蕩蕩，而我們專案組連pm才總共3人。不過做的事情卻是這個分支專案中最累最繁雜的部分。目前我們的工作部分已進入到提供相應資料介面的階段，應該說已經接近尾聲。現在將前段時間工作中的心得與積累下來的一些零碎東西整理成文。
先總體來看這個專案，應該說，我們負責的部分有4個核心階段：
一、需求資料從sap系統遷移到oracle系統階段
二、pool的需求分析、設計和構建階段
三、資料從ods中etl到pool的階段
四、向其它系統提供資料介面階段
接下來，就每個階段的工作過程及要點做乙個大致的總結和回顧。
一、需求資料從sap系統遷移到oracle系統階段
通常的dw專案實施中，在這一階段，為了避免複雜的業務或者轉換邏輯直接與生產系統載入而往往提供ods層。出於技術層面上的考慮及使用者的認可，我們也設計並提供這一資料層，以保證資料在不同的系統間遷移時的平滑過渡。因為sap系統不像別的erp系統一樣，它對自身的管理以及安全性方面有著更高和更嚴謹的要求，我們也只能借助乙個使用者提供的應用層有限地來了解sap的db結構。因此，我們必須借助etl工具（對於這個專案客戶選用的是informatica）來將構建dw用到的sap中很多系統表抽取到oracle系統中，以便研究和搞清其結構和關係。使用者對整個專案過程中任何設計、開發和測試的要求都很嚴格，想盡量避免頻繁地無謂地與sap進行資料互動。最重要的是，使用者現場有3個sap環境，分別是開發、測試與生產環境，因此通過informatica設計產生的abap程式都將在這3個環境下註冊並移植，所以，使用者是不希望看到未經嚴格測試而通過的abap程式在3個環境中反覆註冊移植的現象（因為移植的工作是由使用者來做的^_^）。總體看，這個階段的工作是比較簡單，但比較費時繁瑣的。
二、pool的需求分析、設計和構建階段
通過前一階段的工作，我們從使用者的大致需求出發，已經將專案中涉及到的sap系統表抽到了oracle平台上。這樣對我們深入分析表結構與表間的關係及了解掌握其業務邏輯帶來了極大的便利，同時也盡可能減少了與sap系統的互動。這一階段的工作中，我們首先熟悉了系統中的表結構及資料關係，一定程度上理解了資料關係中所包含和體現的業務邏輯，然後就又回頭對照使用者excel式的需求條目細緻地去分析如何將需求完全、合適地載入整合到要設計出的業務模型裡面。當然了，這個階段中與使用者的溝通是十分關鍵和必要的，因為只有與使用者進行全方位的交流和明確的確認，才能真正體會到使用者的實際需求，不至於出現對業務邏輯產生理解偏差的現象。所以，這個階段中大小會議成了主旋律。在清晰地理解了使用者需求、資料關係和業務邏輯後，我們就借助powerdesigner來著手設計業務模型了。我們大致是按照業務模組來分工做模型設計的，在做模型設計的過程中，當問題積累到一定程度後就又同使用者進行交流以澄清、確認或加以說明。反反覆覆就是為了明明白白。pool的業務模型最終成型了，緊接著就是根據將其生成物理模型，並最終建立到oracle裡。應該說，這一階段是這個專案中最艱苦、最熬人，同時也是最為關鍵的乙個階段。不過，一旦將這一階段做好、做紮實了，那後面的工作就會變的得心應手、一馬平川了。
三、資料從ods中etl到pool的階段在準備好開發文件後，就開始著手設計etl實現了。informatica是dw專案裡常用的etl工具，其豐富的功能、強大的效率和跨平台、支援多種db系統間遷移的特點使其贏得了很多使用者的好評和相當的市場份額。這個專案中，客戶選用informatica產品的版本是5.1.1，版本雖然偏舊，不過已經夠用也依然好用。server是一台hp9000/800的機器，2個cpu，1g記憶體，這個配置作為etl伺服器已經足夠用了。由於對informatica的使用已經駕輕就熟，所以在這個階段，我個人主張對客戶的提議和要求是來者不拒的。我一直認為，事情沒有做不到，只有想不到；只有泥想的出，我就一定可以做到。「髒」資料是這個階段要遇到的「大佬」，違背了客戶業務邏輯、預先定義的約束和個別不完整的資料會在設計嚴謹、完善的etl實現中被檢出，這就是所謂的「髒」資料。當然，大多的「髒」資料屬於問題資料，但「髒」資料並不一定全是問題資料，個別「髒」資料的產生也可以從一方面來驗證etl中所載入的業務邏輯。「髒」資料的清洗工作是需要經常與客戶進行反饋，並配合客戶來共同完成的。應該說，這個階段中比較撓頭的就是對「髒」資料的清洗工作。在這個階段，技術難點永遠不會成為問題解決中的障礙，當然，前提要求是泥必須具備了一定的水準。出於對個別技術問題的興趣和客戶的特殊要求，我對informatica的內部結構和repository自身的元資料管理深入研究了一番，又積攢了一點認識（至於這方面的東東，日後我會單獨整理成文）。
四、提供資料介面階段
通過第三個階段的工作，根據客戶的需求已經將所有的分析資料或指標資料組織到了pool層。也就是說，在這個分支專案中，下游系統所需資料已經被pool全部涵蓋。下游系統所需的資料可以在pool層直接或者做一些簡單的表間關聯後獲取。因此，這一階段工作做起來就相當輕鬆。應當稍加說明的，下游系統對資料提供形式大致有兩種需求：一是直接入庫，一是以平面檔案的形式提供。當然，這也都是小case。總體來看，這一階段屬於工作量的階段。
後記：整個專案過程中，由於與客戶溝通順暢、相互配合良好，以及我們3人的共同努力，整個專案進展相當順利，大夥做的也比較開心。另，全文中我並沒有提及經常遇到的增量和全量的問題，etl後的資料核對，以及與oracle打交道時相應的資料庫設定及效能調整方面的問題，因為這些問題太有代表性，太普及了，因此，不提也罷 ^_^
專案的總結
現在的專案快到結束了，該總結一下了。先寫下有關這個專案的一些標籤 三個月，乙個專案，還沒有做完，剛畢業，專案老套，技術落 後，同事缺乏交流，老闆不願重視，自己創造力不足，工作缺乏激情，做事條理不明，計畫嚴重滯後。剛畢業，進了一家好像很有前景的小公司，給了乙個 平台專案，從八月到十一月，三個月了，專案...
專案的總結
寫了兩天的課程設計，hibernate和stuts的結合，講一下自己的心得體會。以前這種感覺小，但是隨著慢慢的，這種感覺越來越強烈。乙個專案的實現這幾個步驟必不可少，否則，你的專案會出現你預想不到的問題。定義階段 一 需求分析，在寫專案時，要實現什麼首先要做需求分析，這個太重要了。二 可行性初步計畫...
專案回顧 總結
一 團隊中每個人針對專案回顧模板中的問題，用markdown語法寫下自己的思考和回答並發布到自己的 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體主要解決藥品庫存量的管理，我們定義清楚，我們軟體面對的使用者是醫生和藥品庫存管理人員，面對的場景是醫院 是...