小編給大家分享一下怎么使用XML化的思維組織數(shù)據(jù)，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計、網(wǎng)站制作、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)城西,十余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

以往數(shù)據(jù)更多的通過人工錄入，從專用網(wǎng)絡(luò)協(xié)議的終端轉(zhuǎn)移到“玻璃房子”里的大鐵盒子，現(xiàn)在信息無所不在、無時不在，不過不一定都會匯總到您公司里，很多時候大家是在一個“平”的世界里分享數(shù)據(jù)，信息來源的渠道多了、信息本身的變化也更加頻繁。不僅如此隨著Web 2.0、Enterprise 2.0和Internet Service Bus等一系列概念的出現(xiàn)，您發(fā)現(xiàn)單單從自己的“玻璃房子”里找供貨商提供的倉庫地址遠不如Google Map方便。

似乎以往桎梏數(shù)據(jù)的各種枷鎖在互聯(lián)網(wǎng)下被一一打破，但作為IT從業(yè)者，我們的工作是為用戶提供它們所需的數(shù)據(jù)和他們希望獲取信息的手段，因此應(yīng)用必須能夠經(jīng)得起各種變化，包括以往我們關(guān)心的用戶界面的變化、應(yīng)用間調(diào)用的變化、應(yīng)用內(nèi)部邏輯的變化，還有步伐越來越快但又是最根本變化——數(shù)據(jù)自身的變化。

關(guān)系模型告訴我們要用二維表格描述信息世界，但這是太“不”自然不過了，看看手邊的一本書或是家里的裝修計劃、馬上要開工項目的任務(wù)分解，好像套到一個二維表格里總不合適，而且即便通過“實體——關(guān)系”生硬的削足適履后，在快速變化的環(huán)境下又總是要牽涉到“數(shù)據(jù)——應(yīng)用——前端交互”一系列變動，而且經(jīng)常是牽一發(fā)動全身。

似乎很多新一代應(yīng)用已經(jīng)找到了更適合新趨勢的方案——XML，用一種更貼近我們自己思維的方式組織應(yīng)用、組織用戶體驗。那么對于企業(yè)而言，組織數(shù)據(jù)這種相對基礎(chǔ)性的工作是否也可以用XML的思維進行呢？應(yīng)該可以。

應(yīng)對數(shù)據(jù)實體自身的變化

數(shù)據(jù)實體以往總是被假設(shè)為應(yīng)用中最為穩(wěn)定的部分，無論我們用設(shè)計模式還是采用各種開源的開發(fā)框架（包括這些框架本身）都是盡量在適應(yīng)應(yīng)用本身變化的問題，那么現(xiàn)實的情況如何呢？

l 我們需要交換的數(shù)據(jù)實體經(jīng)常要根據(jù)自身、合作方的需要變化；

l 合作方給我們的數(shù)據(jù)實體也常常變化；

l 隨著SOA和Enterprise 2.0概念的推出，數(shù)據(jù)實體本身從多個源mash up出來，同時數(shù)據(jù)實體本身也被反復(fù)的拼裝和組合；

l 隨著業(yè)務(wù)的細化，我們自己的員工總是希望獲取越來越豐富，同時也越來越詳盡的信息；

因此，以往視需求也好、設(shè)計也好認(rèn)為可以最早固定下來的數(shù)據(jù)實體在愈發(fā)敏捷的技術(shù)和業(yè)務(wù)現(xiàn)狀前需要不斷調(diào)整。為了適應(yīng)這個要求我們可以自頂向下入手，不斷調(diào)整應(yīng)用自身的柔性；另一個方式是從“根”上處理這個問題，采用自身就可以不斷適應(yīng)這些變化的新數(shù)據(jù)模型，例如：XML數(shù)據(jù)模型和XML相關(guān)技術(shù)家族。

例如，定義用戶實體的時候，最初下面的信息就夠了，其中ICustomer是應(yīng)用會使用的用戶接口，而CUSTOMER為關(guān)系數(shù)據(jù)庫方式下的表示，為XML方式：

不過緊接著我們就發(fā)現(xiàn)這個實體設(shè)計有些問題，因為還要增加用戶的辦公室電話、住宅電話，還有可能1、2個電子郵件，他的MSN或Skype號碼等。不考慮其他問題，僅僅從關(guān)系模型范1的要求，那么RDBMS和XML兩個模型發(fā)展的結(jié)果就成了：

不難看出，雖然僅僅只是“客戶”數(shù)據(jù)實體末節(jié)“聯(lián)系信息”的一個變化，關(guān)系模型和XML模型在適應(yīng)性方面就有非常大的區(qū)別，關(guān)系模型需要不斷擴展出新的關(guān)系用來描述不斷細化的數(shù)據(jù)實體，而XML模型自身的層次性可以提供變化條件下，自身的不斷延伸和擴展。實際項目中，“學(xué)歷情況”、“工作經(jīng)驗情況”等信息也存在類似的問題，關(guān)系模型下即便某位客戶希望把某階段工作情況的“借調(diào)”方式補充進去，也會發(fā)現(xiàn)因為設(shè)計上沒有預(yù)留相應(yīng)的字段，因此只好把它作為字符串“揉”在“工作單位”字段里，后面補充個“（借調(diào)）”，這等于僵化的數(shù)據(jù)模型本身抹殺了數(shù)據(jù)的業(yè)務(wù)語義中包括的信息；而層次模型可以把它作為一個子節(jié)點或?qū)傩詠砻枋?，這樣不僅可以把關(guān)系模型下需要多個關(guān)系（客戶、學(xué)歷情況、工作經(jīng)驗、聯(lián)系信息）集中在一個數(shù)據(jù)實體內(nèi)部，而且可以把每個實體自身的擴展信息（例如“工作模式”：借調(diào)、交流、短期集中）等也描述在數(shù)據(jù)實體內(nèi)部，同時從外部應(yīng)用看“客戶”實體本身依然是一個實體，這樣用更貼近現(xiàn)實業(yè)務(wù)情景的數(shù)據(jù)實體才能更有效的適應(yīng)外部變化。

上面我們討論的僅僅是一個數(shù)據(jù)實體，進一步發(fā)展到具體業(yè)務(wù)領(lǐng)域模型模型的時候，往往需要同時綜合多個數(shù)據(jù)實體協(xié)作完成業(yè)務(wù)功能，這時候情形又如何呢？比如：保單需要客戶提供除了上述信息外的個人健康信息，子女、父母、伴侶家庭主要成員信息，同時會從其他從業(yè)機構(gòu)獲取用戶的信用信息等，而且不同的數(shù)據(jù)實體組合主要用于企業(yè)內(nèi)部的各異的應(yīng)用領(lǐng)域，因此從數(shù)據(jù)使用角度看為了盡量讓應(yīng)用部分穩(wěn)定，最好是數(shù)據(jù)實體穩(wěn)定，但僅僅用戶信息的聯(lián)系方式部分就可能會反復(fù)的變化，如果讓應(yīng)用完全依賴這些變化因素組合后的結(jié)果，那么應(yīng)用的穩(wěn)定性確實難以保證，那么從源頭上第一步先盡量保證不同應(yīng)用盡量僅依賴于具體一個實體也許是有效改進的第一步，這時候XML的層次特性優(yōu)勢又顯示出來了，比如我們可以根據(jù)不同的應(yīng)用主題，自由組合這些信息：

這樣應(yīng)用面對的就是一個統(tǒng)一的實體，相應(yīng)的采用專用的XML技術(shù)可以保證應(yīng)用框架不變的情況下，新的業(yè)務(wù)可以動態(tài)響應(yīng)變化的數(shù)據(jù)實體。

應(yīng)對數(shù)據(jù)和內(nèi)容的集成

上面提的數(shù)據(jù)實體更多是在一個已經(jīng)集中后的語境下討論的，但除了概念上的設(shè)計外，使用中還有一個具體的問題就是如何如何把他們“聚集”到一起，這個一般通過數(shù)據(jù)集成實現(xiàn)。

（不過就像“架構(gòu)”一詞被過度濫用一樣，“數(shù)據(jù)集成”同樣被各個廠家根據(jù)自己的產(chǎn)品特征被定義成不同概念的組合，比如BI廠商力圖把它描繪成ETL的代名詞、提供數(shù)據(jù)交換平臺的廠商描述為實現(xiàn)BizTalk Framework的產(chǎn)品、對于SOA產(chǎn)品公司而言，數(shù)據(jù)集成則更多在于如何保證在有效治理的前提下提供數(shù)據(jù)服務(wù)，另外對于一些廠商而已，數(shù)據(jù)集成還包括業(yè)務(wù)語義組合等。）

但作為用戶，數(shù)據(jù)集成我們要著重關(guān)心什么問題呢？

l 數(shù)據(jù)實體的映射關(guān)系；

l 數(shù)據(jù)源的在各種交換協(xié)議、行業(yè)數(shù)據(jù)標(biāo)準(zhǔn)、安全控制約束下的互聯(lián)；

l 數(shù)據(jù)交換過程的編排；

l 數(shù)據(jù)實體的驗證和重構(gòu)；

l 數(shù)據(jù)介質(zhì)、數(shù)據(jù)載體的轉(zhuǎn)換；

雖然理論上這些工作用編碼完成不成問題，但隨著企業(yè)集成邏輯越來越復(fù)雜且變化越來越快，修改代碼即便可以應(yīng)付一下1：N的集成，但如果經(jīng)常是M：N的情況，那么就顯得力不從心了。是否可以有更簡化的辦法呢？僅從“映射”的邏輯層次說：

l 面向?qū)ο笏枷敫嬖V我們依賴倒置，要盡量依賴于抽象而不是具體，比如依賴于接口而非實體類型；

l 設(shè)計模式告訴我們，不兼容接口間適配器（Adapter）是個不錯的途徑；

那么數(shù)據(jù)領(lǐng)域是否也有類似的技術(shù)呢？XML Schema + XSLT也許就是個選擇。

上面是為了兼容新、老用戶實體做的轉(zhuǎn)換，同樣的如果需要進行上部分針對不同主體的數(shù)據(jù)實體聚合操作也完全可以借助在抽象數(shù)據(jù)定義（Schema）層次通過XSLT（Schema間的適配關(guān)系）完成。

這樣，我們可以在數(shù)據(jù)實體層次看到數(shù)據(jù)是如何聚合在一起的，但之前還需要解決一個問題：車輛信息、信用信息還有遺留系統(tǒng)的客戶信息都是分別保存在關(guān)系數(shù)據(jù)庫和合作方的Web Service中，如何連接起這個數(shù)據(jù)渠道呢？從現(xiàn)在看XML還是不錯的選擇。

不同數(shù)據(jù)介質(zhì)上的數(shù)據(jù)可以以他們本源的形式提取，比如平文本、關(guān)系數(shù)據(jù)庫、EDI報文或者是SOAP消息，通過不同的信息渠道傳遞到數(shù)據(jù)集成的匯聚點，然后根據(jù)目的數(shù)據(jù)源的需要，通過一個適配器轉(zhuǎn)換異構(gòu)的數(shù)據(jù)源。

這時候如果為每兩種類型都設(shè)計一個點對點的適配器，整體規(guī)模將沿著N^2級的趨勢發(fā)展，為此不妨先把他們統(tǒng)一為兼容這些信息的XML，然后用上面介紹的XSLT技術(shù)進行數(shù)據(jù)實體間的映射后，接著把XML再轉(zhuǎn)換成目標(biāo)數(shù)據(jù)源所需的形式，這樣整個適配體系復(fù)雜度降為N級。

接著，我們看看XML技術(shù)如何滿足只前提的那些數(shù)據(jù)集成要求：

l 數(shù)據(jù)實體的映射、數(shù)據(jù)介質(zhì)、數(shù)據(jù)載體的轉(zhuǎn)換、數(shù)據(jù)實體的驗證和重構(gòu)：

如上，先把數(shù)據(jù)統(tǒng)一轉(zhuǎn)換為XML，然后通過XML層次型優(yōu)勢，結(jié)合XML專用技術(shù)進行處理。

l 數(shù)據(jù)源的在各種交換協(xié)議、行業(yè)數(shù)據(jù)標(biāo)準(zhǔn)、安全控制約束下的互聯(lián)；

XML數(shù)據(jù)不僅可以跨越網(wǎng)絡(luò)、防火墻，而且可以很容易的用于互聯(lián)網(wǎng)環(huán)境（，不過您依然可以用消息隊列方式把他們定義為報文），數(shù)據(jù)本身不會因為特殊的二進制操作需要受到交換協(xié)議的限制。當(dāng)前，各個行業(yè)標(biāo)準(zhǔn)基本上都在使用XML描述自己的行業(yè)DM（Data Modal），即便您企業(yè)內(nèi)部的系統(tǒng)本身數(shù)據(jù)實體由于數(shù)據(jù)庫設(shè)計、歷史遺留等問題，本身不是符合這些DM的數(shù)據(jù)，但各種XML數(shù)據(jù)統(tǒng)一治理的協(xié)議和標(biāo)準(zhǔn)可以比較方便的實現(xiàn)轉(zhuǎn)換。對于安全性，似乎還有沒比基于WS-*相關(guān)協(xié)議更適合于互聯(lián)網(wǎng)環(huán)境下的安全標(biāo)準(zhǔn)家族，其中所有的標(biāo)準(zhǔn)無一例外都可以用XML實體定義數(shù)據(jù)和額外安全機制間的組合關(guān)系。

l 數(shù)據(jù)交換過程的編排；

對于同構(gòu)系統(tǒng)環(huán)境，或者是僅僅基于兼容中間件系統(tǒng)的平臺，可以采用遺留的工作流機制實現(xiàn)數(shù)據(jù)交換過程的編排，但為了適應(yīng)服務(wù)化的時代，可以采用更通用的BPEL標(biāo)準(zhǔn)，此時XML不僅僅是數(shù)據(jù)，同時他也作為執(zhí)行指令的形態(tài)出現(xiàn)，相比較一直標(biāo)榜跨平臺的Java技術(shù)而言，采用XML定義的交換過程更是跨語言的。

似乎集成已經(jīng)解決了很大的問題，但一個顯而易見的問題是所有的工作我們可能都要自己做一些實現(xiàn)，一步步告訴應(yīng)用怎么做，那么當(dāng)我們不再把Web僅僅當(dāng)成“新鮮事物”，而把它考慮成一個服務(wù)于我們信息內(nèi)容，并且可以交互的系統(tǒng)時，如何把這些散落的服務(wù)能力呈遞給我們自己呢？這時候也許XML開放的元數(shù)據(jù)定義的優(yōu)勢才真正體現(xiàn)出來。

應(yīng)對語義網(wǎng)絡(luò)的復(fù)雜性

除去各種語義算法以外，如何讓分散的各種繁多的服務(wù)聚合在一起為我們提供服務(wù)，其中XML一個非常關(guān)鍵的因素就是找到數(shù)據(jù)線索的主干，而且明確這條主干上實體間的關(guān)聯(lián)關(guān)系及其逐步分解細化的過程。這個層次的數(shù)據(jù)不僅是被動由應(yīng)用調(diào)用的對象，他們本身為應(yīng)用共了進一步推斷的支持。例如：

這里首先應(yīng)用了解到當(dāng)前處理的這個對象是鵝肉，由于鵝肉是一種黑肉，而黑肉是某種禽肉（fowl），禽肉可以食用，因此應(yīng)用可以逐步推斷鵝肉可以食用。上面的推斷過程并不復(fù)雜，但如果用關(guān)系數(shù)據(jù)庫實現(xiàn)卻相對比較復(fù)雜，用平文本書寫那就更難于實現(xiàn)了，試想一下如果同時把禽肉與蔬菜、甜點、海產(chǎn)品間的關(guān)系全部用關(guān)系數(shù)據(jù)庫或文本書寫，那實在太“難為”應(yīng)用了。而XML不同，它可以很自然的貼近我們思維的習(xí)慣，以一種開放但又交織的辦法描述我們熟悉的語義，無論是企業(yè)ERP環(huán)境的生產(chǎn)材料準(zhǔn)備過程，還是為了一次生日Party準(zhǔn)備自己下廚的采購計劃，亦然。

以上是“怎么使用XML化的思維組織數(shù)據(jù)”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！