大數據的「攔路虎」，信息孤島能否解決？
信息孤島是大數據的「攔路虎」，要根除信息孤島，必須認識到當前的信息孤島是不治之症。
到目前為止，全球無數事實已表明凡是用關係資料庫理論所開發出的信息系統肯定全是孤島型的，還無人能用關係資料庫理論根除信息孤島。關係資料庫產生信息孤島的根本原因在於關係資料庫的「關係」，由於關係資料庫中的數據與表結構、應用程序「關係」密切、緊密耦合，因此，當關係資料庫中的數據脫離了原來的生存環境而發送到其它信息系統之後，由於接收數據的信息系統中與接收到的數據之間沒有相應的表結構，也沒有相應的耦合「關係」，數據就成了無意義的。關係資料庫理論是信息孤島的發源地，要根除信息孤島的就必須根除「關係」，讓數據不依靠任何「關係」而在各個系統中都能獨立地表達出完整的含義。
要根除信息孤島，首先要搞清楚為什麼到目前為止信息孤島得不到根治
為了解決信息孤島問題，人們發明了EDI、ETL、ESB、EAI、BI等技術，然而全球的無數事實表明，用這些技術也不能從根本上解決信息孤島問題。
從技術上而言，當前的信息孤島是由於各個信息系統的數據結構各不相同而引起的，當系統A把結構化數據D發送給系統B時，由於系統B中沒有結構化數據D的數據結構，系統B需要採用轉換數據結構和數據內容的方式，或重新設計新的數據結構表的方式，才能把結構化數據D存貯到自己的系統中。
全球信息系統的數量超過千萬，全球所產生的數據超過數萬億條，這些數據的結構各不相同。
兩個系統之間的互聯互通約需要1個人月的工程量。
三個系統之間的互聯互通約需要：（3-1）*（3-2）=3個人月。
四個系統之間的互聯互通約需要：（4-1）*（4-2）*（4-3）=6個人月。
N個系統之間的互聯互通約需要：（N-1）*(N-2)*(N-3)*……*3*2*1個人月。
上述計算表明，隨著信息系統的數量的增加，要實現各個信息系統之間的數據的互聯互通，所付出的代價非常高，不可承受！這也表明，當前的信息孤島是不治之症。EDI、ETL、ESB、EAI、BI這類技術只能在局部緩解信息孤島問題，卻不能從整體上根除信息孤島問題。
鐵路鋼軌的標準化對根除信息孤島的啟示
由於我國的鋼軌與前蘇聯國家的鋼軌的標準不一樣，我國的火車到了前蘇聯國家就要花80分鐘的時間換車輪。我國鐵路交通通過鋼軌的標準化而使得火車在全國各地運行而不必換車輪。
信息孤島猶如火車在寬度各不相同的鋼軌上運行，鋼軌的標準化從根本上避免了「鐵路孤島」問題的產生。要根除信息孤島，也應該從數據結構化的標準化方面著手，下文中所到的萬能數據結構化就可以成為信息系統的「標準的鋼軌」，可用來根除信息孤島。
當前的EDI、ETL、ESB、EAI、BI這類技術都是通過「換車輪（轉換數據結構、轉換數據內容）」的方式來解決信息孤島問題。眾所周知的是「換車輪」的方式在鐵路交通中是不可行的，問題是到目前為止，IT行業還是用「換車輪」這種非常笨的方式解決「數據交通」問題。
當前的問題是：凡是用關係資料庫理論所設計出的信息系統，其中的數據肯定是異構的，猶如不同的火車需要運行在不同寬度的鋼軌上。
當前的情況：先利用關係資料庫理論設計出眾多的信息孤島，然後再去解決孤島問題。猶如先設計出車輪各不相同的火車及鋼軌，然後再通過換車輪的方式讓火車在寬度不同的鋼軌上行駛。
當前的誤區是：「換車輪」可解決孤島問題。
值得深思的問題是：為什麼機械行業的工程師很容易地就想到用鋼軌標準化的方式來實現火車的互聯互通，IT行業的工程師為什麼死死地抱著「換車輪」的方案不放？IT行業為什麼不走數據結構標準化的道路？
結論：凡是「換車輪」的方案，只能在局部上緩解信息孤島問題，肯定不能從根本上消除信息孤島。數據結構的標準化才是解決信息孤島的最佳方法。
關係資料庫的「關係」是產生信息孤島問題的根源
關係資料庫理論誕生於單機時代，只適用於孤島型系統中的數據處理。關係資料庫理論的創始人在創立關係資料庫時根本就未考慮如何處理眾多的信息系統中的數據問題。關係資料庫理論中沒有數據共享交換的概念，也沒有數據介面的概念，也沒有通信協議。TCP/IP協議產生於關係資料庫理論之後。因此，關係資料庫理論在大數據時代就暴露出了其致命的缺陷。關係資料庫理論之所以稱作是關係資料庫，就是因為關係資料庫是以「關係」為基礎的，「關係」是關係資料庫最為自豪的。然而正是因為「關係」才導致信息系統產生信息孤島！這是因為，如果數據與表結構、資料庫中的其它表及應用程序有密切的耦合關係，那麼相應的數據就只能在這個特定的環境中依靠特定的關係才是有意義的，一旦脫離了原來的環境，把數據發送到其它信息系統中，數據肯定會失真。
問題的根源之一：異構數據是信息孤島的根源，二維表是異構數據的根源
異構數據是信息孤島的根源，關係資料庫中的二維表則是異構數據的根源。關係資料庫是利用二維表來存貯數據，要存貯不同的數據，要用不同結構的表，其結果就是隨著信息系統的數量的增加，會產生無窮無盡的結構各不相同的表，也會產生無窮無盡的異構數據。下圖就說明了關係資料庫中的二維表是如何產生信息孤島的。
關係資料庫中的二維表雖說具有很多的優點，然而二維表卻會產生致命的無窮無盡的異構數據問題，也會因此而產生信息孤島問題。
關係資料庫中的數據必須以特定的數據結構表為基礎才能生存，即數據必須依靠特定的表的「關係」才是有意義的。這種數據與表的密切耦合關係在眾多的信息系統之間進行數據共享、交換、挖掘時就會產生嚴重的問題。
結論：只要利用關係資料庫理論設計信息系統，肯定會用到結構各不相同的二維表，並因此而不可避免地產生異構數據問題、信息孤島問題。
問題的根源之二：數據與表結構及應用程序密切耦合
關係資料庫理論之所以稱作是關係資料庫，就是因為關係資料庫是以「關係」為基礎的，「關係」是關係資料庫最為自豪的。然而由於關係資料庫中的每一條數據都是與特定的數據結構密切耦合的，而且與信息系統也是密切耦合的，因此，當關係資料庫中的某條數據一旦脫離了原來的生存環境而發送到其它的信息系統之後，由於接收數據的信息系統中沒有相應的數據結構，也沒有相應的應用程序來解讀接收到的數據，數據就變成了無意義的數據。
結論：關係資料庫中的數據與表結構及應用程序密切耦合是導致數據在眾多的系統之間難以共享交換的一個根本原因。
問題的根源之三：關係資料庫中大量使用代碼而導致數據在共享交換時失真
在利用關係資料庫理論設計信息系統時大量使用代碼也是產生信息孤島的一個重要原因。例如，對關係資料庫而言，下面的兩張表是合格的，然而由於這兩張表的表頭使用的是代碼，除了設計人員外，人們就看不懂表中內容的實際含義。
上述形式的數據是小數據時代的經典結構形式。其實「欄位名」也是很重要的信息，用代碼來表示欄位名會導致數據失真，這樣的數據在數據共享、交換、挖掘時就會出問題，需要編寫大量的程序來解讀表中的數據的實際含義。上述兩張表的實際含義為：
關係資料庫的技術人員已習慣用代碼來表達資料庫中的數據，例如有的用「1」表示男性，「0」表示女性，有的用「M」表未男性，用「W」表示女性。在單個信息系統中，可以通過程序來解讀數據。然而在大數據時代，所面臨的是數百萬個信息系統中的數千萬個結構各不相同的表，相應的數據量超過數千億條，要對如此之多的數據進行查詢、挖掘，需要編寫海量的程序才能解讀關係資料庫中的每一條數據的含義。
關係資料庫理論誕生於1970年的單機時代。關係資料庫的創始人在創立關係資料庫理論時所考慮的只是如何讓自己的系統存貯、識別數據，沒有考慮如何讓他人的系統也能存貯、識別數據，未考慮結構化數據在各個系統中的互聯互通的問題。凡是用關係資料庫理論所設計出的信息系統，其中的數據肯定都是與系統密切耦合的，只有自己的資料庫系統、只有自己的應用系統才能存貯、識別。關係資料庫理論的創始人在創立關係資料庫理論時沒有考慮數據脫離了原系統之後如何讓其它系統也能存貯、識別的問題。這就是用關係資料庫理論所設計出的信息系統都是信息孤島的根本原因。然而在大數據時代，人們更希望數據能夠在各個系統之間互聯互通、共享交換，希望結構化數據成為大家的系統都可以存貯、識別的數據。
問題的根源之四：沒有數據標準，沒有可遵守的標準
到目前為止，國際上還沒有為數據制訂標準，國內也未給數據制訂標準。因沒有標準，各個系統中的數據不統一，完全由系統的設計人員自己確定，不標準的數據在數據共享交換、挖掘時就會出現問題。例如，對於同一個人，在不同的系統中有的用「秦始皇」，有的用「贏政」，有的用「趙正」。
在大數據時代，關係數據理論不能適應眾多系統之間的數據共享交換
在大數據時代，人們不只是關注單個系統中的數據，更關注由數百萬個信息系統所組成的系統群之間的數據共享交換、互聯互通，相關數據多達數萬億條以上，數據來自數百萬個以上的、不同行業、不同單位、不同信息系統。如果各個系統中的數據都是與系統密切耦合的，脫離了原系統之後就變成了無意義的數據，那麼要對由數百萬個系統所組成的系統群中的數萬億條數據進行交換、查詢、挖掘，工程量將是非常大的，不可承受！由於關係資料庫中的數據與資料庫中表表結構及應用程序密切相關，因此而導致數據只能某個特定的環境中才是有意義的，一旦脫離了原來的生存環境，就成了無意義的數據，在數據共享、交換、挖掘時就需要編寫大量的程序。每一張表中的數據都要編寫100行左右的應用程序才能解讀其中的數據。當面臨數百萬以上的表時，就要編寫數億行的應用程序。
用獨立資料庫根除信息孤島的整體構思
獨立資料庫中只有一種表，即萬能數據結構表。獨立資料庫解決信息孤島、實現數據互聯互通的方法猶如鐵路運輸系統通過鋼軌的標準化而實現了火車在全國各地不用換車輪即可行駛，獨立資料庫是利用萬能數據結構表（猶如標準的鋼軌）實現數據結構的標準化，通過數據結構化的標準化而根除信息孤島。萬能數據結構表是一種通用的表、萬能的表，可以用一張表即可存貯各種各樣的結構化數據，例如下表只用一張萬能數據結構表就存貯了「銷售訂單表、銷售訂單明細表、患者基本情況表、住院病歷表」的數據。
我國的鐵路運輸系統通過鋼軌的標準化而從根本上避免了「換車輪」。
獨立資料庫的整體構思：把萬能數據結構表當作各種信息系統的「標準鋼軌」，各種信息系統只要全部以事物信息表這種「標準鋼軌」為基礎而設計，那麼這些信息系統中的結構化數據就可以象火車運行在全國各地的標準鋼軌上那樣順利地實現互聯互通而不用換車輪（轉換數據結構和內容、建立新的數據結構）。獨立資料庫是通過萬能數據結構表而實現數據結構的標準化，以數據結構的標準化來預防信息孤島問題的產生，實現數據的互聯互通。獨立資料庫是預防信息孤島疾病產生的「預防疾病」的方法，而不是治療現有信息孤島疾病的「治療疾病」的方法。
獨立資料庫徹底顛覆了關係資料庫理論，可預防信息系統產生信息孤島
獨立資料庫徹底顛覆了現有的關係資料庫理論。關係資料庫理論最為自豪的就是「關係」，然而大量的信息孤島問題表明「關係」是產生信息孤島的根源！因為，如果數據與資料庫系統中的其它表及應用程序之間存在耦合關係，那麼該數據就只能在某個特定的系統中才是有意義的，該數據一旦脫離了原系統，發送到其它系統之後，就會因為原有的耦合關係不存在而引起數據失真，這就是關係資料庫中的數據難以互聯互通的根本原因，也是關係資料庫系統產生信息孤島的根本原因。
針對此問題，「獨立資料庫」採取了與關係資料庫完全相反的策略，想盡一切辦法，徹底根除「關係」，徹底根除「數據與資料庫系統中的其它表及應用程序之間的耦合關係」，「讓數據獨立地表達出完整的含義」，嚴禁數據與資料庫中的其它表及應用程序存在耦合關係，讓數據成為大家的系統都可以識別的數據。只有當數據是獨立的、完整的，那麼數據在各個信息系統之間的互聯互通才會順利，否則，在數據交換時，就要花費大量的投資，編寫大量的程序來解除數據的耦合關係、解讀數據的含義，猶如換車輪。
現有技術在實現結構化數據互聯互通時，需要先轉換數據結構、轉換數據內容，或再建立新的表結構，然後才能把接收到的數據存貯到數據接收方的資料庫中，這需要編寫大量的程序才能實現。利用現有技術，編寫不出通用的結構化數據介面軟體，因為要接收100萬條結構各不相同的數據時，需要在數據的接收方的資料庫中再建立大量的表，甚至需要建立100萬個相應的數據結構表才可以接收這100萬條結構化數據並存貯到資料庫中。如果這100萬條結構化數據全部以萬能數據結構表的形式存貯，那麼，數據發送方只要利用通用的數據介面即可把數據發送到數據接收方的數據介面中，並把這100萬條數據直接存貯到數據介面中的事物信息表中。
利用獨立資料庫所設計出的各種信息系統中的數據與資料庫中的其它表及應用程序的耦合度為零，因此，當系統中的數據脫離了原來的信息系統之後，還能保持原來的含義不變，不會失真。
JUSFOUN｜ 九次方大數據
TAG:九次方大數據 |