關系數據庫是當今用來削減成本、減少 IT 經費和加快現有流程（可能讓一些人驚歎）的主要技術。但是敏銳的觀察家們已經注意到，穩定的采集、修改和調整的流程已經使數據管理技術成為公司必備的技術。
IBM 數據庫雜志咨詢了 Arvind Krishna（IBM 數據管理和全球信息管理開發的副總裁）如何識別數據庫技術中的關鍵創新，而這些關鍵創新反過來又能推動 IBM 客戶和合作伙伴之間的創新。Krishna 領導一個數千名開發人員的團隊，其工作是持續創新數據庫技術來滿足客戶的需求，有時預測客戶尚未察覺但是確實存在的需求。當然，Krishna 承認，客戶經常以他和開發人員從未想到的方式使用他們團隊的創新。
一個關鍵例子：XML。雖然 IBM 從一開始就清晰地察覺到 XML 的潛力（兩年前在 DB2 9 中引入的 pureXML 功能花了五年時間而產生），但是客戶將這種技術運用得如此廣泛還是給 Krishna 留下了深刻的印象。例如，新紐約州稅務部門現在在線處理幾百萬條稅收檔案，為公民加快了流程並降低了相關的勞動力和數據管理成本。按照傳統方法，納稅申報單處理不管在哪裡都需要兩天到兩個月。
DB2 的 pureXML 僅僅是 IBM 數據庫產品中的許多創新之一。Krishna 提到，對客戶和合作伙伴產生重大影響的其它開發包括：
深度壓縮，它可以為客戶節約 30% 至 50% 的存儲成本。IBM 客戶 Sun Trust 已經在一個在線案例研究中公開共享其壓縮工作的結果，IBM 提供一個在線工具讓潛在客戶計算他們自己類似的節約的成本。
數據庫引擎內部的存儲過程，它向 Java 應用程序開放主機數據。
集群技術及其在確保高可用性中的角色（參照參考資源 “Cheetah 2：總是開啟” 獲取詳細信息）。
pureQuery 和 Data Studio，它們為 Java 開發人員提供透明的優化（參照參考資源 “IBM Data Studio pureQuery Runtime for z/OS Performance” 獲取詳細信息）。
非復制分析，它停止數據集市的快速增長。
U2 的開發人員客戶機功能，它利用 Windows 平台的原生能力。
該列表包括了許多數據管理基本原理。從 Krishna 的觀點來看，這都不能忽視，因為它們對 IT 部門的成本有驚人的影響。“很容易被雲計算和 Google 創造的許多術語搞糊塗”，Krishna 說。“但是考慮壓縮：我們的許多中型客戶每年單在存儲上就花費 2000 萬美元。如果您可以省下 1000 萬美元成本，那是一項極大的節約。而且那僅僅是采購成本。如果您花時間考慮一下，收獲將更大”。
那種更多地使用數據的同時保持低成本的動力與 IBM 最早的數據庫信息管理系統（Information Management System，IMS）關系特別大，它開始於 40 年前。今天，IMS 被許多大型銀行用來存儲其核心應用程序中使用的數據。IMS 10 允許此數據通過 Web 服務（Krishna 指出，大部分大學畢業生已經知道如何使用）公開給現代 Java 應用程序使用。開發人員無需先學習 IMS 就可以獲取其數據。
通過壓縮節約資金、簡化可重用編程和降低能源消耗減少了新項目的預算，這使得可以在客戶層面進行創新。每個行業的客戶都在關注那些有利於關鍵競爭優勢的信息技術。
在接下來的部分，您將看到五個創新的基於數據的方法，用於解決業務問題；這個小例子僅僅提示了可能性。期望隨著業務壓力增長看到更有創造性的數據技術應用程序。“隨著成本在基礎經濟中變得越來越重要，您將看到人們更多地利用數據，而不是更少”，Krishna 認為。
在 wiki.ibmdatabasemag.com/index.PHP/Case_StudIEs 上閱讀關於 MTV、Univar USA 和其它公司使用其數據的更多信息。
要注意的三種趨勢
1. 流程和事件處理。
“在技術世界中，速度始終很重要”，Krishna 說。企業需要速度和低延遲的組合來獲得業務優勢。在華爾街的術語中，那意味著處理股票交易獲得洞察力，從而提供超過競爭者的毫秒級優勢。
2. 大型集群系統。
服務器整合（通過虛擬化或使用多核處理器）的趨勢意味著公司將繼續創建包含幾百或幾千工作負載的集群系統。這些系統將需要自動負載管理和不對稱的容錯能力；換句話說，系統必須在沒有系統管理員或 DBA 介入的情況下將工作負載傳遞給合適的節點。
3. 常駐內存技術。
IBM 打算在其數據庫產品（包括 Informix Dynamic Server、DB2 及其數據倉庫解決方案）中使用因收購 Solid Information Technology 公司（2008 年 1 月關閉）而獲得的技術。“想像一下，對於應用程序，常駐內存數據庫的運行延遲比基於磁盤的數據庫低 100 倍”，Krishna 說。
虛擬現實
使用 Informix Dynamic Server 將一部分現實世界帶到虛擬世界。
這個夏天，IBM 和 Linden 實驗室大力宣揚遠距離傳輸方面的突破。對不起，Trekkies，您任何時候都不會很快理解的。除非您也是 Linden 實驗室的 Second Life 等在線 3D 世界的愛好者。兩個公司的研究人員第一次成功地從 Second Life PrevIEw Grid 將 “avatar”（這些虛擬世界中的人物的圖形化表現）遠距離傳輸到基於 OpenSim 的世界。
如果您不理解滿世界跳躍的 avatar，那麼您可能需要學習關於虛擬世界方面的知識。3D 虛擬世界環境由 2D Internet 的最好想法擴展而來，為創造視覺效果的應用程序提供一個框架。在虛擬世界中，合作者共享一個設計空間並且可以同時使用相同的元素。發生的更改對於所有參與方都立即可用嗎？是的，根本無需等待就可以看到。
3D 環境中的在線零售可能性超出 2D Internet。考慮購買一台純平電視放到一個正在進行改造的客廳裡。為了家庭舒適，您可以構建一個房間的幾何模型並嘗試不同的家具、電視和地毯。您甚至可以請求您的室內設計師與您實時協作。
您可能想要在購買之前查看評論和價格，因此您可以保存當前配置，在您返回時恢復。
目前，虛擬世界缺少基礎設施來啟用這種假設的購物之旅的各個方面。因為虛擬世界沒有設計成利用外部數據庫來獲取 2D 購物網站上提供的功能（檢索產品信息和定價、維護購物車、完成校驗等）。
為了克服這些缺點，IBM 正在構建使用 Informix Dynamic Server（IDS）的框架，實現在虛擬世界（例如 Second Life、OpenSim 和 OpenCroquet）和企業應用程序（例如 WebSphere Commerce）之間進行操作。根據 IBM 的 Lance Feagan（項目開發人員主管）的介紹，IDS 的 OLTP 性能、易用性以及空間和時間能力適合於虛擬環境。
接口將把過去五十年磨煉的企業數據管理能力帶到虛擬領域。反過來，虛擬世界將為它們的使用提供新的途徑。Feagan 展望虛擬會議（在虛擬會議中混合媒體通信使用來自 Lotus Teamroom 和 Sametime 的文檔）可以被重放和分析。
在零售中，Feagan 將 avatar 行為跟蹤看作是深入了解虛擬購買方式的渠道，或允許為特定的 avatar 度身定做廣告。例如，一個 avatar 觀察一個產品很長時間但是沒有購買，那麼在返回光顧時可以提供一個折扣。
“一旦收集到信息，那麼您就可以挖掘它”，Feagan 說。正如現實世界中一樣。
收費公路系統
對高峰期間行駛的車輛收費使得斯德哥爾摩的道路變得暢通。
您是否會為高峰期間駕駛付費（如果它改善了您的通行狀況和您家鄉城市的空氣質量）？斯德哥爾摩的市民會這麼做（因為這個駕駛計劃被證明是可行的）。
投票通過的斯德哥爾摩道路擁擠收費系統於 2007 年 8 月開始實行，並因此把交通量降低了 18%。對於一個由橋梁連接的島嶼和相對較少的道路構成的城市，這顯著改善了生命質量。由於成千上萬的工人從偏僻區域開車到城市中，交通量出現了超出容量的征兆。從那些在收費期間駕駛的工人那裡收到的費用將用於建設更多橋梁和鐵路。
這個 IBM 構造的系統使用 DB2、SAP 和 WebSphere 軟件。擁擠區域中的攝像頭拍攝收費期間的車牌。然後圖像被傳輸到中央系統，存儲在那裡並由光學字符識別（OCR）技術或手動（如果 OCR 無法識別圖像）進行處理。
然後車主信息被從國家車輛登記處（這些信息存儲在 DB2 數據庫中）抽取出來；帳單信息被發送到 SAP 財務應用程序，由它發出稅款通知並處理支付和罰款。如果車輛上安裝有發射機應答器，那麼駕駛員可以通過直接記入借方來支付費用，或者他們可以在便利店、銀行或通過 Internet 進行支付。IBM WebSphere Application Server 在後端 SAP 軟件和 Web 網站（商店用它來與擁擠收費系統進行通信）之間進行連接。
因為官方計劃的采用取決於公眾投票，所以系統的精確性對於公眾接受至關重要。駕駛計劃達到並超出設定的精確性目標。
IBM 還與倫敦、新加坡和布裡斯班（澳大利亞城市）合作應對擁擠挑戰；到目前為止，斯德哥爾摩項目（覆蓋超過九英裡）是這種類型的最大項目。
在 ibm.com/press/us/en/pressrelease/24414.wss 上閱讀關於斯德哥爾摩項目的更多信息。
速度需求
常駐內存關系數據庫 solidDB 改寫了期望的響應時間。
2008 年 1 月，IBM 成功收購 Solid Information Technology（常駐內存數據庫 solidDB 的制造者）。solidDB 關系數據庫本身補充了 IBM 現有（基於磁盤）的關系型組合；事實上，在六月份，IBM 宣布了針對 DB2 和 IDS 的 solidDB 緩存。
根據 Paola Lubet（Solid 公司營銷和業務開發高級副總裁）的說法，雖然最近的重大收購引起對常駐內存系統的關注，但是市場上仍然有一些混淆。她解釋，常駐內存系統和基於磁盤的系統之間的差別在於：基於磁盤的系統將數據存儲在磁盤上（如同名稱所指）並且只將正被讀取或更改的數據移動到主內存。常駐內存的關系型系統一直將所有數據保存在主內存中，使得響應時間可以用微秒為而不是毫秒進行測量。它每秒可以支持好幾萬條事務。
那麼，solidDB 是否意味著基於磁盤的關系型數據庫將消亡呢？Lubet 說不會。原因之一是，數據的大小受計算機中內存的大小限制。雖然在關系數據庫中存儲 GB 級數據在今天並不少見，但是 GB 級可用內存仍然不多。將基於磁盤的系統與常駐內存的系統一起使用使組織可以將頻繁訪問的數據放到內存中，同時將較少訪問的數據保留在基於磁盤的系統中。在許多業務應用中，不同數據對應不同的響應時間是很有意義的。
Lubet 說：“如果您在市場上觀察 solidDB 的實現，會發現它通常被其它數據庫包圍，因為公司需要對數據進行許多處理”。在改造 solidDB 用於 OLTP 事務的場合，DB2 和 IDS 允許復雜的浏覽和更大范圍的使用。solidDB 緩存解決方案的可用性指公司可以根據各種業務需求將 DB2 或 IDS 數據集移動到 solidDB 中，反之亦然。
在財務服務公司中，許多應用程序處理大量的信息，只存儲一些信息用於分析。對於這種情況，公司可以將數據臨時存儲在 solidDB 緩存中。如果需要保留全部數據或部分數據用於將來分析，那麼數據可以被移回到 DB2 或 IDS 系統。
常駐內存的數據庫的速度和低延遲結合基於磁盤的系統的傳統能力，使許多以前不可能實現的業務應用變得切實可行。Lubet 期盼這樣一個零售場合，購物者只需走過檢查站，就會立即將裝滿 RFID 標簽的貨物的購物車記入現金記錄機。然後可以將關於該事務的信息存儲到基於磁盤的系統中，用於將來分析。
Lubet 指出，“重要的是，該組合允許公司使用他們認為是最佳的工具”。
在 ibm.com/software/data/soliddb 上學習關於 solidDB 的更多知識。
童子軍的榮譽
基於 UniData 的解決方案使英國童子軍志願者准備就緒。
男女童子軍通常會想到營火會、帳篷和甜點售賣的場景，但是很少想到計算機和技術。
但是童子軍的普及（世界上有 2800 萬成員）使得成員管理成為一種不同尋常的挑戰。光是基於英國的童子軍協會就管理 80000 個志願者，他們參與 600 個不同的角色，支持 400000 個年輕成員。每個志願者在接受角色特定的培訓之前必須通過犯罪背景檢查和其它篩選。
為了簡化志願者管理，童子軍協會采用 APT 解決方案（aptsolutions.Net）來開發一個構建於 IBM UniData 之上的低維護成員系統。這個基於 Web 的系統讓志願者負責他們自己記錄的一部分，減少在線管理人員的管理任務。
James Wren（團體成員領袖）說，一些維護任務不可避免，但是團體花費太多的時間來發展流水線化的系統（他將這歸因於早期的戰略性選擇）。“我們決定使用帶有預訂開發的離架系統，從而可以享用其它客戶在同一個包中實現的開發”，他解釋道。
啟用 Web 的系統通過必需的培訓和犯罪記錄檢查流程來跟蹤志願者的進度，並為電子和印刷通信動態分開聽眾。
在接下去的 12 個月中，組織計劃擴展系統來同時管理所有年輕成員的關系，而無需所有的程序員或 DBA 都參與。
pureXML、Ruby on Rails 和 Web Services
花店終端銷售系統正在顯出成效。
通過本地或在線花店將花送到遠方的能力不是什麼新聞。但是處理這些訂單並將其發送到合適位置的方式正在經歷激進的改變。
將由 Philip Nelson（ScotDB 公司）帶領的團隊開發的新花店終端銷售系統連接到 BloomNet 電話服務。基於浏覽器的 Ruby on Rails 應用程序（由 DB2 Express-C 數據庫支持）允許與鮮花服務進行通信，它將訂單從一個花店發送到另一個花店。與大部分鮮花電話服務一樣，BloomNet 允許通過 Web 服務進行這種通信，減少成本和錯誤並加快流程。
BloomNet 解決方案處理關系數據和 XML 數據的混合來實現三個關鍵功能：
生成發送到 BloomNet 的請求消息。用來填充這些消息的數據存在關系表中，但是消息必須以 XML 文檔發送。一個單個（雖然復雜）的 SQL 語句使用選擇的 ANSI 標准 XML 函數生成所需的 XML 文檔。
處理來自 BloomNet 的消息（接收或拒絕訂單、改變價格等）。每個成員花店都必須使用 Web 服務每 15 分鐘從 BloomNet 請求等待決定的消息（根據 BloomNet 建議）；所有等待決定的消息都以一個 XML 文檔（必須存儲用於審計並且以某種方式起作用）傳輸。所有接收到的消息都存儲在 DB2 表的 XML 列中；一個 SQL/XML 內的 XPath 表達式從 XML 抽取所需的數據。ScotDB 的 Philip Nelson 高度評價 DB2 的 SQL/XML 中的強大 XPath 支持，可以簡化從復雜 XML 文檔進行的信息檢索。
訪問 BloomNet 成員目錄（一個單個的 6MB XML 文檔）。下訂單之前，發送方花店必須使用目錄中的詳細信息（通常是提供的郵編，但是可能有其它標准）來選擇一個首選的供應花店。除了情人節、母親節和其它鮮花需求大的日期，目錄通常每星期刷新一次。在那些關鍵的時期每 15 分鐘刷新一次，使得發送方花店可以知道哪個供應花店因為存貨耗盡而不可用。在最關鍵的業務期間，以這個規則的時間間隔將目錄處理成關系格式的開銷會導致服務中斷。因此，開發團隊選擇以 XML 列本地存儲該目錄，並且使用 SQL/XML 進行訪問。存儲過程執行搜索。
Nelson 認為 pureXML 在目錄訪問場合中特別有利。使用 pureXML 列存儲目錄允許單個插入語句，從而使最新的目錄信息可用，盡量減少對使用該目錄的應用程序的影響。並且，因為數據以解析後的 XML 格式存儲，所以相關的文檔和文檔中單個的元素可以快速定位。
