商業智能呼喚革命性的技術
Sybase軟件中國有限公司技術總監 盧東明指出，數據規模的增長，導致的數據存儲和傳輸，已經成爲當今數據庫及商務智能最大的挑戰。我們花在存儲方面的開銷包括：硬件開銷，折舊開銷，管理開銷，人員開銷已經達到了驚人的地步；另外，儘管在過去的25年中，硬盤的容量增長了10000倍，傳輸率增長了100倍，但有效傳輸帶寬（ETB）實際上下降了100倍。這些都成爲數據庫倉庫和商業智能性能方面最大的挑戰。
盧東明認爲，BI市場方面，同樣是需要專業的東西做專業的事情，就是說需要專門的數據庫產品來支撐企業的數據倉庫，數據挖掘等BI應用，Sybase給出的答案就是Sybase IQ系列產品和方案。這一觀點引發參會網友和技術專家熱烈的討論。
Sybase IQ的諸多特性，引起來大家的關注，一個是壓縮技術，IQ裏面的壓縮技術是自動有的，不需要設定或者是制訂才能產生的。 盧東明介紹，Sybase並沒有把IQ定位成一個壓縮型的數據庫而把它定位成列式數據庫，也就是它的根本，它的本原第一步是列式數據庫，壓縮的特性是隨着列式數據庫而來的。比如說DB2九版本也做到了某些壓縮的功能甚至非常好，但是跟IQ的理念不一樣，IQ是每個列自動進行壓縮，但有些數據也是不可壓縮的。
對於商業智能，廠商都在盲人摸象
另外，與會專家也談到了數據倉庫項目成敗的問題。除了技術問題以外，領域專家和業務方面的問題，也是導致數據倉庫項目失敗的重要原因。統計數據表明，數據倉庫項目80%都是失敗的。網友談到，不管是自己做項目，還是帶項目也好，實際上自己也挺失望的，搞不清楚數據倉庫的概念是成功的還是失敗的。
大部分專家贊同數據倉庫不光是一個存數據的問題，最重要的一個問題是業務問題，而本質上是業務問題。這些東西一定需要有一些業務專家來做這些東西，比如說做一些業務建模，還有質量的問題，不同業務數據系統數據質量可能存在一些問題，最終得到的結果整合過來以後得到的期望跟用戶有一定的差距，再一個問題是從業務數據庫到數據倉庫本身需要轉換，當中發生一些數據的損耗，這三個問題纔是最重要的。發生任何一個問題，做數據倉庫都不是成功的。
盧東明解釋了關於數據倉庫項目失敗率較高的原因，一個是數據倉庫跟傳統的業務型的項目比起來週期比較長，在它沒有成功的時候我們是不是把它叫做失敗的，這是有商榷的。就好象大家做車一樣，從中國汽車工業開始，在沒有做出很成功的車型或者企業的時候，我們是不是把中國的汽車工業稱爲失敗呢，我覺得不應該，大家都還在探索，國際上也不是每個都能成功，但是大家還是看到商務智能越來越有迫切性了。
盧東明認爲，對於ETL或者前端展示的作用在整個BI系統工程的過程中都佔有它的地位，在整體的架構上面，Sybase IQ只是做了一個其中的環節而已，並不是說我們解決了整體的東西，但是每個環節如果都能夠有各自的廠商進行突破性的進展，我想可能你會發現整個項目會比現在想象得容易得多。
“就好象我手機上面就有一個Excel的程序，這個東西十年前不可想象的，那個時候要想讓企業做一個電子表格的東西，他也會認爲這是非常難處理的事情，所以計算機的發展既給大家一個視角，也給大家一個歷史觀，也就是說計算機永遠在處理現在難辦的事情。對於ETL的過程，其實很多技術的進展也對整個體系的應用開發理念提出各種各樣的挑戰或者是各種新的見解，比如說ETL，好像大家覺得是順理成章的事情，一個項目有原數據，轉換要需要ETL，但是現在你會發現，有很多過程放在數據庫裏面比放在ETL裏面有成幾千倍的提高，現在有一個理念叫ELT，就是我抽取出來以後，先放到數據庫裏面，先L，這個比用ETL工具快不知道多少倍。那麼這個概念是怎麼提出來的，還是由於列式數據庫能夠顯示出來，如果沒有這樣的突破的話，我想ELT這個概念也出不來。”
盧東明總結到，廠商的各項功能及產品實現對於商業智能而言，就像盲人摸象一樣，沒有人能夠看到商務智能是一個整體的大象怎麼樣走，怎麼樣運轉，所以每個公司都圍繞着大象的某一個角度在做事情。
另外，與會專家也談到了數據倉庫項目成敗的問題。除了技術問題以外，領域專家和業務方面的問題，也是導致數據倉庫項目失敗的重要原因。統計數據表明，數據倉庫項目80%都是失敗的。網友談到，不管是自己做項目，還是帶項目也好，實際上自己也挺失望的，搞不清楚數據倉庫的概念是成功的還是失敗的。
大部分專家贊同數據倉庫不光是一個存數據的問題，最重要的一個問題是業務問題，而本質上是業務問題。這些東西一定需要有一些業務專家來做這些東西，比如說做一些業務建模，還有質量的問題，不同業務數據系統數據質量可能存在一些問題，最終得到的結果整合過來以後得到的期望跟用戶有一定的差距，再一個問題是從業務數據庫到數據倉庫本身需要轉換，當中發生一些數據的損耗，這三個問題纔是最重要的。發生任何一個問題，做數據倉庫都不是成功的。
盧東明解釋了關於數據倉庫項目失敗率較高的原因，一個是數據倉庫跟傳統的業務型的項目比起來週期比較長，在它沒有成功的時候我們是不是把它叫做失敗的，這是有商榷的。就好象大家做車一樣，從中國汽車工業開始，在沒有做出很成功的車型或者企業的時候，我們是不是把中國的汽車工業稱爲失敗呢，我覺得不應該，大家都還在探索，國際上也不是每個都能成功，但是大家還是看到商務智能越來越有迫切性了。
盧東明認爲，對於ETL或者前端展示的作用在整個BI系統工程的過程中都佔有它的地位，在整體的架構上面，Sybase IQ只是做了一個其中的環節而已，並不是說我們解決了整體的東西，但是每個環節如果都能夠有各自的廠商進行突破性的進展，我想可能你會發現整個項目會比現在想象得容易得多。
“就好象我手機上面就有一個Excel的程序，這個東西十年前不可想象的，那個時候要想讓企業做一個電子表格的東西，他也會認爲這是非常難處理的事情，所以計算機的發展既給大家一個視角，也給大家一個歷史觀，也就是說計算機永遠在處理現在難辦的事情。對於ETL的過程，其實很多技術的進展也對整個體系的應用開發理念提出各種各樣的挑戰或者是各種新的見解，比如說ETL，好像大家覺得是順理成章的事情，一個項目有原數據，轉換要需要ETL，但是現在你會發現，有很多過程放在數據庫裏面比放在ETL裏面有成幾千倍的提高，現在有一個理念叫ELT，就是我抽取出來以後，先放到數據庫裏面，先L，這個比用ETL工具快不知道多少倍。那麼這個概念是怎麼提出來的，還是由於列式數據庫能夠顯示出來，如果沒有這樣的突破的話，我想ELT這個概念也出不來。”
盧東明總結到，廠商的各項功能及產品實現對於商業智能而言，就像盲人摸象一樣，沒有人能夠看到商務智能是一個整體的大象怎麼樣走，怎麼樣運轉，所以每個公司都圍繞着大象的某一個角度在做事情。
大型應用設計中的數據庫架構
阿里巴巴首席DBA馮春培，在數據庫管理工作的第一線，對大型應用開發的數據庫系統架構，大規模數據庫的管理有着深刻的體會和見解。他認爲，大規模應用設計的前期，數據庫系統架構師的缺席，是導致後期數據庫分佈式存貯，管理，維護的重要原因。在應用設計時，數據庫架構師如何發揮作用，特別是在生產環境中，數據庫架構師的職責和任務有哪些，馮春培和大家分享了他在阿里巴巴數據庫管理，架構和設計的的經驗。
馮春培首先分析了DBA角色產生的過程以及隨後的分化。數據在今天變得越來越重要，於是產生了有人來管理維護數據庫，不能丟，有些企業像金融企業丟了跟錢都有關係，電信那邊少收點錢還沒有關係。當然有人管理數據庫，運用的問題就凸顯出來了，於是就產生了數據庫的管理維護的這些DBA很難有精力去支持前端的應用，前端應用的很多需求太多太複雜了，人的精力是有限的，於是DBA慢慢催生了兩種角色，一個叫管理DBA，是側重於後臺系統的維護、備份，考慮數據安全，另外也催生了開發DBA的角色，其實很多公司也在慢慢催生這種角色，我們公司這幾年一直在堅持這兩個方面，開發DBA剛開始跟開發部門打交道，後來發現總是跟他們打交道效率不高，因爲一旦到開發部門這兒很多需求就確定了，於是開發DBA的觸角就伸到需求開發，甚至已經伸展到運營部門那裏，非正式流程上的民間的組織行爲就產生了，然後呢，經常跟運營部門打交道之後他們也明白我們的重要性，也會跟我們溝通，我們有個感覺說，比如說下半年，下個季度公司裏面運營部門的人想幹什麼，我們有什麼準備，於是開發的這條線就有一個好的模型出來了。
DBA角色的侷限性
產生了這兩個角色以後，慢慢地我們發現這兩種角色已經滿足不了我們對未來發展的期望了，爲什麼呢？因爲某一個具體的產品DBA或者某一個開發DBA所面臨的是一些很具體的需求，要解決的是一個當前的，跟當前相關的很具體的問題，它很難去考慮或者推動我今年怎麼做，我明年後面會變成什麼樣子，因爲有時候一個長期的方向跟短期的行爲可能方向並不是一樣的，是分離的，裏面還牽扯到方方面面的因素以及成本的問題，比如你在公司裏面打算幹五年和打算幹一年考慮是不一樣的，所以要考慮價格的問題，比方對於產品級DBA來講，要高度的是什麼問題？最基本的說運用的壓力越來越增加。一個小型機可能只有四顆CPU，16級內存，後來換成八顆CPU，32級內存。產品DBA還要決定一臺機器承載不了的時候我應該怎麼做，通過多臺機器分擔壓力，以及可靠性問題的解決。產品DBA比較現實地在考慮這樣的問題。
阿里巴巴首席DBA馮春培，在數據庫管理工作的第一線，對大型應用開發的數據庫系統架構，大規模數據庫的管理有着深刻的體會和見解。他認爲，大規模應用設計的前期，數據庫系統架構師的缺席，是導致後期數據庫分佈式存貯，管理，維護的重要原因。在應用設計時，數據庫架構師如何發揮作用，特別是在生產環境中，數據庫架構師的職責和任務有哪些，馮春培和大家分享了他在阿里巴巴數據庫管理，架構和設計的的經驗。
馮春培首先分析了DBA角色產生的過程以及隨後的分化。數據在今天變得越來越重要，於是產生了有人來管理維護數據庫，不能丟，有些企業像金融企業丟了跟錢都有關係，電信那邊少收點錢還沒有關係。當然有人管理數據庫，運用的問題就凸顯出來了，於是就產生了數據庫的管理維護的這些DBA很難有精力去支持前端的應用，前端應用的很多需求太多太複雜了，人的精力是有限的，於是DBA慢慢催生了兩種角色，一個叫管理DBA，是側重於後臺系統的維護、備份，考慮數據安全，另外也催生了開發DBA的角色，其實很多公司也在慢慢催生這種角色，我們公司這幾年一直在堅持這兩個方面，開發DBA剛開始跟開發部門打交道，後來發現總是跟他們打交道效率不高，因爲一旦到開發部門這兒很多需求就確定了，於是開發DBA的觸角就伸到需求開發，甚至已經伸展到運營部門那裏，非正式流程上的民間的組織行爲就產生了，然後呢，經常跟運營部門打交道之後他們也明白我們的重要性，也會跟我們溝通，我們有個感覺說，比如說下半年，下個季度公司裏面運營部門的人想幹什麼，我們有什麼準備，於是開發的這條線就有一個好的模型出來了。
DBA角色的侷限性
產生了這兩個角色以後，慢慢地我們發現這兩種角色已經滿足不了我們對未來發展的期望了，爲什麼呢？因爲某一個具體的產品DBA或者某一個開發DBA所面臨的是一些很具體的需求，要解決的是一個當前的，跟當前相關的很具體的問題，它很難去考慮或者推動我今年怎麼做，我明年後面會變成什麼樣子，因爲有時候一個長期的方向跟短期的行爲可能方向並不是一樣的，是分離的，裏面還牽扯到方方面面的因素以及成本的問題，比如你在公司裏面打算幹五年和打算幹一年考慮是不一樣的，所以要考慮價格的問題，比方對於產品級DBA來講，要高度的是什麼問題？最基本的說運用的壓力越來越增加。一個小型機可能只有四顆CPU，16級內存，後來換成八顆CPU，32級內存。產品DBA還要決定一臺機器承載不了的時候我應該怎麼做，通過多臺機器分擔壓力，以及可靠性問題的解決。產品DBA比較現實地在考慮這樣的問題。
數據庫的規劃離不開存儲
馮春培認爲，數據庫的規劃和存儲技術也息息相關。更長遠一點還要考慮到，除了數據庫的層面的選擇，還有主機、存儲，這幾年大家都在流行幾個概念，虛擬化主機、虛擬化存儲，操作系統級別的，大家都在炒這些概念，但是這些概念落到實出，大家的期望是任何一個節點出問題了能持續地提供服務，還要解決數據庫擴展的問題，承載更大的壓力。
開發DBA這邊同樣會跟產品DBA配合，他要考慮什麼問題，我們的數據量越來越大，應用越來越複雜，比如說淘寶的壓力也越來越大，壓力一兩年可能翻一倍，或者一年翻兩倍，你怎麼應對，單純靠擴展主機的性能或者一兩個節點，從一個節點增加到三四個節點可能還是不能滿足要求，數據庫要拆分，怎麼拆分法，流行的叫水平分割和垂直分割的問題，垂直分割比如說把大運用拆成都獨立的小運用。這高垂直拆，但是垂直拆的時候單個業務可能有非常大的量，可能有幾億條數據，訪問量每天非常頻繁，現實的需求在我們很多具體的環境中衝突特別強烈，你按照這個業務拆也已經滿足不了要求了，就要考慮水平的分法，數據按照用戶分還是怎麼分，集羣裏面，拆分了以後，水平分割之後的數據庫，它實際上是由一組數據庫構成的，每個單點還要考慮安全性的問題，它也不是承擔某一個具體應用的人所能決定的，往往變化，甚至在某一個具體的公司裏面，在技術上基本上是一個變革，架構上的徹徹底底的變革，國外亞馬遜等在一兩年前就已經完成了變革，國內現在正在思考這個問題，比如說移動，包括我們公司，也在考慮這些東西怎麼個分法，怎麼解決擴展性的問題，這個問題其實就要站在一個相當高的高度看，因爲普通的角色產品DBA和開發DBA很難承載這個東西，因爲這不是數據庫的問題了，應用要配合做很多的改造，你必須獲得技術部門非常強有力的支持，投入很大的資源，這個事情一做可能要一年兩年甚至三年才能完成改造，這就不是我們普通的角色定義能完成得了的，於是我們在想，同樣，開發那邊有架構設計的，我們DBA這邊也要配套地催生做DB架構的角色來跟運用開發的架構遙相呼應，大家一起討論未來兩年我們要做成什麼樣子，最近半年我們要做什麼事情，下半年做什麼事情。做這個計劃。這個情況的產生呢，基本上跟我們今天要談論的已經是保持一致了，都到同一個方向上來了。
數據庫說起來很簡單，如果畫張圖就是一個垂直分割，下面水平分割，每一個具體的時限。如果沒有很大規模的話，可能還是牽扯到把有些應用拆分到其他的地方，但是這樣的一些動作會導致我們數據庫之間會不會產生數據同步，比如說你垂直分割的時候分到什麼力度，太粗了滿足不了，太細了維護成本太高。當然對於某個具體的點承載不了的時候，有的人也會考慮讀寫分離，一個寫四個讀。用這樣的讀寫分離的方式來解決可靠性的問題，一個點壞了我並不在意，不像我們以前一樣提心吊膽，07年我管了十幾二十套數據庫，可靠性要控制在一個層面上，到底是多少，我不知道各位有沒有做過統計，比如說07年我的數據庫117分鐘故障，當然是分佈到很多數據庫上，這117分鐘是影響應用的，做了很好的分離之後可能就不那麼嚴重了，壞了一個沒關係，我移到別的地方去就可以了，畫圖很容易，道理幾分鐘我就明白了，但是一旦做起來其實裏邊有非常多的問題，主機和存儲的搭配，操作系統版本的選擇，新功能要不要用啊，裏頭有很細的問題，管理數據庫的人有很多的問題，淘寶現在一個表加一個列，也要有一個人凌晨四點鐘才能做這個事情，在大規模的運用上有很多的問題。
那麼做數據庫的架構層面的設計和實施，你要能站在上面描繪這個藍圖，也要能貫徹實施，做成一個具體的東西，然後管理、維護、匹配都得跟上，這一整套下來才能使得我們的應用，那個時候比如說我們DBA項目組就可以跟老闆說，我支持你可擴展、保障地的可用性，沒問題。這是我的終極目標，我不希望說像以前一樣總是聽到各個業務部門迴應我說，我們這個數據庫什麼時候就不行了，撐不住了，你跟我說到底能夠支撐到什麼時候，由於業務發展，有時候具有爆炸性，不像傳統行業一樣，我就非常難以回答，這也是我的一個痛，所以說我也是希望未來的某一天，也許一年、兩年，那個時候我可以跟大家交流時候說，我們的數據庫非常好，可擴展、可靠性非常好。現在也許你的系統還比較小，但是總有一天越來越多的企業會提出這樣的要求，當這個機遇降臨的時候，你就可以勇敢地站起來，承擔責任，體現你的價值。
他的話題，引發了參會諸多高級DBA的共鳴和響應。
馮春培認爲，數據庫的規劃和存儲技術也息息相關。更長遠一點還要考慮到，除了數據庫的層面的選擇，還有主機、存儲，這幾年大家都在流行幾個概念，虛擬化主機、虛擬化存儲，操作系統級別的，大家都在炒這些概念，但是這些概念落到實出，大家的期望是任何一個節點出問題了能持續地提供服務，還要解決數據庫擴展的問題，承載更大的壓力。
開發DBA這邊同樣會跟產品DBA配合，他要考慮什麼問題，我們的數據量越來越大，應用越來越複雜，比如說淘寶的壓力也越來越大，壓力一兩年可能翻一倍，或者一年翻兩倍，你怎麼應對，單純靠擴展主機的性能或者一兩個節點，從一個節點增加到三四個節點可能還是不能滿足要求，數據庫要拆分，怎麼拆分法，流行的叫水平分割和垂直分割的問題，垂直分割比如說把大運用拆成都獨立的小運用。這高垂直拆，但是垂直拆的時候單個業務可能有非常大的量，可能有幾億條數據，訪問量每天非常頻繁，現實的需求在我們很多具體的環境中衝突特別強烈，你按照這個業務拆也已經滿足不了要求了，就要考慮水平的分法，數據按照用戶分還是怎麼分，集羣裏面，拆分了以後，水平分割之後的數據庫，它實際上是由一組數據庫構成的，每個單點還要考慮安全性的問題，它也不是承擔某一個具體應用的人所能決定的，往往變化，甚至在某一個具體的公司裏面，在技術上基本上是一個變革，架構上的徹徹底底的變革，國外亞馬遜等在一兩年前就已經完成了變革，國內現在正在思考這個問題，比如說移動，包括我們公司，也在考慮這些東西怎麼個分法，怎麼解決擴展性的問題，這個問題其實就要站在一個相當高的高度看，因爲普通的角色產品DBA和開發DBA很難承載這個東西，因爲這不是數據庫的問題了，應用要配合做很多的改造，你必須獲得技術部門非常強有力的支持，投入很大的資源，這個事情一做可能要一年兩年甚至三年才能完成改造，這就不是我們普通的角色定義能完成得了的，於是我們在想，同樣，開發那邊有架構設計的，我們DBA這邊也要配套地催生做DB架構的角色來跟運用開發的架構遙相呼應，大家一起討論未來兩年我們要做成什麼樣子，最近半年我們要做什麼事情，下半年做什麼事情。做這個計劃。這個情況的產生呢，基本上跟我們今天要談論的已經是保持一致了，都到同一個方向上來了。
數據庫說起來很簡單，如果畫張圖就是一個垂直分割，下面水平分割，每一個具體的時限。如果沒有很大規模的話，可能還是牽扯到把有些應用拆分到其他的地方，但是這樣的一些動作會導致我們數據庫之間會不會產生數據同步，比如說你垂直分割的時候分到什麼力度，太粗了滿足不了，太細了維護成本太高。當然對於某個具體的點承載不了的時候，有的人也會考慮讀寫分離，一個寫四個讀。用這樣的讀寫分離的方式來解決可靠性的問題，一個點壞了我並不在意，不像我們以前一樣提心吊膽，07年我管了十幾二十套數據庫，可靠性要控制在一個層面上，到底是多少，我不知道各位有沒有做過統計，比如說07年我的數據庫117分鐘故障，當然是分佈到很多數據庫上，這117分鐘是影響應用的，做了很好的分離之後可能就不那麼嚴重了，壞了一個沒關係，我移到別的地方去就可以了，畫圖很容易，道理幾分鐘我就明白了，但是一旦做起來其實裏邊有非常多的問題，主機和存儲的搭配，操作系統版本的選擇，新功能要不要用啊，裏頭有很細的問題，管理數據庫的人有很多的問題，淘寶現在一個表加一個列，也要有一個人凌晨四點鐘才能做這個事情，在大規模的運用上有很多的問題。
那麼做數據庫的架構層面的設計和實施，你要能站在上面描繪這個藍圖，也要能貫徹實施，做成一個具體的東西，然後管理、維護、匹配都得跟上，這一整套下來才能使得我們的應用，那個時候比如說我們DBA項目組就可以跟老闆說，我支持你可擴展、保障地的可用性，沒問題。這是我的終極目標，我不希望說像以前一樣總是聽到各個業務部門迴應我說，我們這個數據庫什麼時候就不行了，撐不住了，你跟我說到底能夠支撐到什麼時候，由於業務發展，有時候具有爆炸性，不像傳統行業一樣，我就非常難以回答，這也是我的一個痛，所以說我也是希望未來的某一天，也許一年、兩年，那個時候我可以跟大家交流時候說，我們的數據庫非常好，可擴展、可靠性非常好。現在也許你的系統還比較小，但是總有一天越來越多的企業會提出這樣的要求，當這個機遇降臨的時候，你就可以勇敢地站起來，承擔責任，體現你的價值。
他的話題，引發了參會諸多高級DBA的共鳴和響應。
XML數據庫在中國的應用狀況
調查數據顯示，2007年，IBm數據庫產品DB2取得驚人增長。筆者看到IBM官方內部目前還未對外公佈的統計數據是增長了140%。劉晶煒在這一數據的基礎上，做了中國XML 數據庫的應用分析的報告。可以看出，經過一年多的推廣，IBm新版數據庫DB2 V9的pureXml特性取得了巨大的成功，成爲吸引新用戶採納的重要賣點。
另外一個因素，關係數據庫面臨巨大挑戰，難以應對具有複雜、多變結構的數據。關係模型在以下方面面臨着挑戰：嚴格的數據及關係定義，高性能的索引機制，缺乏數據模型上的靈活性以及只能適合固定的結構化數據等。這些情況，大部分數據庫應用者和開發者都有所瞭解，也希望關係數據庫在這些方面有所突破。
劉晶煒以醫療領域數據和稅務行業應用爲例，說明了Xml數據庫如何解決關係數據庫難以解決的應用場景和問題。
劉晶煒談到，今天比較難的是做出一個系統能適應不同的需求。我們看到更多的一些變化是今天IT層面上的，其實我跟銀行的人都做過探討，今天IT尤其在數據層上面產生非常多的挑戰，涉及到架構層上的挑戰，過去十年二十年我們是以一個固定的業務需求，固定的業務需求直接推到固定的業務邏輯，這種邏輯套過來是一個一個單獨的業務系統，數據庫並不重要，只是保證系統穩定運行就好了，效率不好了我加臺機器，這是我們過去關注的重點，今天碰到的很大問題在哪，數據有了之後，要開始發生交互了。但是這種運用越做越多後發現數據的規劃不合理，因爲你這些數據應該不應該歸屬於你這個業務系統，開始只是在業務功能上思考這個問題，國外也是這個思路，走到一定程度發現，以前每個城市都是一個一個自己的房子建起來，建起來之後發現供暖、供電不應該由自己來管理，IT結構也是這樣，在數據層上一些大的企業認識到必須提到整體平臺上。
SOA必須從表層走向流程，再走向數據，一層層深入。我們希望未來的數據，銀行開戶這個動作，在網上可能開戶、開信用卡可能開戶，很多環節可以開戶，但是今天開戶的行爲被封裝在某個業務模型中，處理的邏輯、數據也不一致，這個剝離出來以後，對數據不需要人爲干預的一些操作濃縮成爲業務服務，來給各個功能系統服務，這塊會一層層，從底層的服務，這種概念已經談了好幾年了，這種服務的時候整個的思考邏輯是一種對象化的思考，在每個層級你會看到，它的接口銜接都基本上已經開始XML，這樣的大勢情況下，有什麼理由我們數據庫組織不應該改變。這也是帶來一個深層次的變化。
嘉賓的演講結束後，現場數據庫技術人員圍繞嘉賓就相關技術問題進行討論諮詢，多種技術觀點在會場上交流碰撞！與會數據庫專家表示，這次數據庫論壇不論是從參會人員的素質和層次，還是從交流的話題來看，都可稱得上是目前中國最高水平的數據庫技術沙龍。
調查數據顯示，2007年，IBm數據庫產品DB2取得驚人增長。筆者看到IBM官方內部目前還未對外公佈的統計數據是增長了140%。劉晶煒在這一數據的基礎上，做了中國XML 數據庫的應用分析的報告。可以看出，經過一年多的推廣，IBm新版數據庫DB2 V9的pureXml特性取得了巨大的成功，成爲吸引新用戶採納的重要賣點。
另外一個因素，關係數據庫面臨巨大挑戰，難以應對具有複雜、多變結構的數據。關係模型在以下方面面臨着挑戰：嚴格的數據及關係定義，高性能的索引機制，缺乏數據模型上的靈活性以及只能適合固定的結構化數據等。這些情況，大部分數據庫應用者和開發者都有所瞭解，也希望關係數據庫在這些方面有所突破。
劉晶煒以醫療領域數據和稅務行業應用爲例，說明了Xml數據庫如何解決關係數據庫難以解決的應用場景和問題。
劉晶煒談到，今天比較難的是做出一個系統能適應不同的需求。我們看到更多的一些變化是今天IT層面上的，其實我跟銀行的人都做過探討，今天IT尤其在數據層上面產生非常多的挑戰，涉及到架構層上的挑戰，過去十年二十年我們是以一個固定的業務需求，固定的業務需求直接推到固定的業務邏輯，這種邏輯套過來是一個一個單獨的業務系統，數據庫並不重要，只是保證系統穩定運行就好了，效率不好了我加臺機器，這是我們過去關注的重點，今天碰到的很大問題在哪，數據有了之後，要開始發生交互了。但是這種運用越做越多後發現數據的規劃不合理，因爲你這些數據應該不應該歸屬於你這個業務系統，開始只是在業務功能上思考這個問題，國外也是這個思路，走到一定程度發現，以前每個城市都是一個一個自己的房子建起來，建起來之後發現供暖、供電不應該由自己來管理，IT結構也是這樣，在數據層上一些大的企業認識到必須提到整體平臺上。
SOA必須從表層走向流程，再走向數據，一層層深入。我們希望未來的數據，銀行開戶這個動作，在網上可能開戶、開信用卡可能開戶，很多環節可以開戶，但是今天開戶的行爲被封裝在某個業務模型中，處理的邏輯、數據也不一致，這個剝離出來以後，對數據不需要人爲干預的一些操作濃縮成爲業務服務，來給各個功能系統服務，這塊會一層層，從底層的服務，這種概念已經談了好幾年了，這種服務的時候整個的思考邏輯是一種對象化的思考，在每個層級你會看到，它的接口銜接都基本上已經開始XML，這樣的大勢情況下，有什麼理由我們數據庫組織不應該改變。這也是帶來一個深層次的變化。
嘉賓的演講結束後，現場數據庫技術人員圍繞嘉賓就相關技術問題進行討論諮詢，多種技術觀點在會場上交流碰撞！與會數據庫專家表示，這次數據庫論壇不論是從參會人員的素質和層次，還是從交流的話題來看，都可稱得上是目前中國最高水平的數據庫技術沙龍。