文章內容

數據庫中數據的性質和簡歷

發布時間: 2012/9/14 17:18:30

數據整體性

數據庫是一個單位或是一個應用領域的通用數據處理系統，他存儲的是屬于企業和事業部門、團體和個人的有關數據的集合。數據庫中的數據是從全局觀點出發建立的，他按一定的數據模型進行組織、描述和存儲。其結構基于數據間的自然聯系，從而可提供一切必要的存取路徑，且數據不再針對某一應用，而是面向全組織，具有整體的結構化特征。

數據共享性

數據庫中的數據是為眾多用戶所共享其信息而建立的，已經擺脫了具體程序的限制和制約。不同的用戶可以按各自的用法使用數據庫中的數據；多個用戶可以同時共享數據庫中的數據資源，即不同的用戶可以同時存取數據庫中的同一個數據。數據共享性不僅滿足了各用戶對信息內容的要求，同時也滿足了各用戶之間信息通信的要求。

發展簡史

數據管理的誕生

數據庫的歷史可以追溯到五十年前，那時的數據管理非常簡單。通過大量的分類、比較和表格繪制的機器運行數百萬穿孔卡片來進行數據的處理，其運行結果在紙上打印出來或者制成新的穿孔卡片。而數據管理就是對所有這些穿孔卡片進行物理的儲存和處理。然而，1 9 5 1 年雷明頓蘭德公司（Remington Rand Inc）的一種叫做Univac I 的計算機推出了一種一秒鐘可以輸入數百條記錄的磁帶驅動器，從而引發了數據管理的革命。1956 年IBM生產出第一個磁盤驅動器—— the Model 305 RAMAC。此驅動器有50 個盤片，每個盤片直徑是2 英尺，可以儲存5MB的數據。使用磁盤最大的好處是可以隨機地存取數據，而穿孔卡片和磁帶只能順序存取數據。

1951： Univac系統使用磁帶和穿孔卡片作為數據存儲。

數據庫系統的萌芽出現于60 年代。當時計算機開始廣泛地應用于數據管理，對數據的共享提出了越來越高的要求。傳統的文件系統已經不能滿足人們的需要。能夠統一管理和共享數據的數據庫管理系統（DBMS）應運而生。數據模型是數據庫系統的核心和基礎，各種DBMS 軟件都是基于某種數據模型的。所以通常也按照數據模型的特點將傳統數據庫系統分成網狀數據庫、層次數據庫和關系數據庫三類。

最早出現的是網狀 DBMS，是美國通用電氣公司Bachman等人在1961年開發成功的IDS（Integrated DataStore）。1961年通用電氣公司（General ElectricCo.）的Charles Bachman 成功地開發出世界上第一個網狀DBMS也是第一個數據庫管理系統—— 集成數據存儲（Integrated DataStore IDS），奠定了網狀數據庫的基礎，并在當時得到了廣泛的發行和應用。IDS 具有數據模式和日志的特征。但它只能在GE主機上運行，并且數據庫只有一個文件，數據庫所有的表必須通過手工編碼來生成。之后，通用電氣公司一個客戶——BF Goodrich Chemical 公司最終不得不重寫了整個系統。并將重寫后的系統命名為集成數據管理系統（IDMS）。

網狀數據庫模型對于層次和非層次結構的事物都能比較自然的模擬，在關系數據庫出現之前網狀DBMS要比層次DBMS用得普遍。在數據庫發展史上，網狀數據庫占有重要地位。

層次型DBMS是緊隨網絡型數據庫而出現的，最著名最典型的層次數據庫系統是IBM 公司在1968 年開發的IMS。

（Information Management System），一種適合其主機的層次數據庫。這是IBM公司研制的最早的大型數據庫系統程序產品。從60 年代末產生起，如今已經發展到IMSV6，提供群集、N路數據共享、消息隊列共享等先進特性的支持。這個具有3 0 年歷史的數據庫產品在如今的WWW應用連接、商務智能應用中扮演著新的角色。

1973 年Cullinane 公司（也就是后來的Cullinet軟件公司），開始出售Goodrich 公司的IDMS 改進版本，并且逐漸成為當時世界上最大的軟件公司。

關系數據庫的由來

網狀數據庫和層次數據庫已經很好地解決了數據的集中和共享問題，但是在數據獨立性和抽象級別上仍有很大欠缺。用戶在對這兩種數據庫進行存取時，仍然需要明確數據的存儲結構，指出存取路徑。而后來出現的關系數據庫較好地解決了這些問題。

1970年，IBM的研究員E.F.Codd博士在刊物《Communication of the ACM》上發表了一篇名為“A Relational Model of Data for Large Shared Data Banks”的論文，提出了關系模型的概念，奠定了關系模型的理論基礎。盡管之前在1968年Childs已經提出了面向集合的模型，然而這篇論文被普遍認為是數據庫系統歷史上具有劃時代意義的里程碑。Codd的心愿是為數據庫建立一個優美的數據模型。后來Codd又陸續發表多篇文章，論述了范式理論和衡量關系系統的12條標準，用數學理論奠定了關系數據庫的基礎。關系模型有嚴格的數學基礎，抽象級別比較高，而且簡單清晰，便于理解和使用。但是當時也有人認為關系模型是理想化的數據模型，用來實現 DBMS是不現實的，尤其擔心關系數據庫的性能難以接受，更有人視其為當時正在進行中的網狀數據庫規范化工作的嚴重威脅。為了促進對問題的理解，1974 年ACM牽頭組織了一次研討會，會上開展了一場分別以Codd和Bachman為首的支持和反對關系數據庫兩派之間的辯論。這次著名的辯論推動了關系數據庫的發展，使其最終成為現代數據庫產品的主流。

1969： Edgar F.“Ted” Codd發明了關系數據庫。

1970年關系模型建立之后，IBM公司在San Jose實驗室增加了更多的研究人員研究這個項目，這個項目就是著名的System R。其目標是論證一個全功能關系DBMS的可行性。該項目結束于1979年，完成了第一個實現SQL的 DBMS。然而IBM對IMS的承諾阻止了System R的投產，一直到1980年System R才作為一個產品正式推向市場。IBM產品化步伐緩慢的三個原因：IBM重視信譽，重視質量，盡量減少故障；IBM是個大公司，官僚體系龐大；IBM內部已經有層次數據庫產品，相關人員不積極，甚至反對。

然而同時，1973年加州大學伯克利分校的Michael Stonebraker和Eugene Wong利用System R已發布的信息開始開發自己的關系數據庫系統Ingres。他們開發的Ingres項目最后由Oracle公司、Ingres公司以及硅谷的其他廠商所商品化。后來，System R和Ingres系統雙雙獲得ACM的1988年“軟件系統獎”。

1976年霍尼韋爾公司(Honeywell)開發了第一個商用關系數據庫系統——Multics Relational Data Store。關系型數據庫系統以關系代數為堅實的理論基礎，經過幾十年的發展和實際應用，技術越來越成熟和完善。其代表產品有Oracle、IBM公司的 DB2、微軟公司的MS SQL Server以及Informix、ADABASD等等。

結構化查詢語言(SQL)

1974 年，IBM的Ray Boyce和Don Chamberlin將Codd關系數據庫的12條準則的數學定義以簡單的關鍵字語法表現出來，里程碑式地提出了SQL(Structured Query Language)語言。SQL語言的功能包括查詢、操縱、定義和控制，是一個綜合的、通用的關系數據庫語言，同時又是一種高度非過程化的語言，只要求用戶指出做什么而不需要指出怎么做。SQL集成實現了數據庫生命周期中的全部操作。SQL提供了與關系數據庫進行交互的方法，它可以與標準的編程語言一起工作。自產生之日起，SQL語言便成了檢驗關系數據庫的試金石，而SQL語言標準的每一次變更都指導著關系數據庫產品的發展方向。然而，直到二十世紀七十年代中期，關系理論才通過SQL在商業數據庫Oracle和DB2中使用。

1986年，ANSI把SQL作為關系數據庫語言的美國標準，同年公布了標準SQL文本。目前SQL標準有3個版本�；維QL定義是ANSIX3135-89，“Database Language - SQL with Integrity Enhancement”[ANS89]，一般叫做SQL-89。SQL-89定義了模式定義、數據操作和事務處理。SQL- 89和隨后的ANSIX3168-1989，“Database Language-Embedded SQL”構成了第一代SQL標準。ANSIX3135-1992[ANS92]描述了一種增強功能的SQL，現在叫做SQL-92標準。SQL-92包括模式操作，動態創建和SQL語句動態執行、網絡環境支持等增強特性。在完成SQL-92標準后，ANSI和ISO即開始合作開發SQL3標準。SQL3的主要特點在于抽象數據類型的支持，為新一代對象關系數據庫提供了標準。

數據庫巨人的誕生

——甲骨文公司（Oracle）

1976 年IBM E.F.Codd發表了一篇里程碑的論文“R系統:數據庫關系理論”，介紹了關系數據庫理論和

甲骨文公司

查詢語言SQL。Oracle的創始人Ellison非常仔細地閱讀了這篇文章，被其內容震驚，這是第一次有人用全面一致的方案管理數據信息。作者E.F.Codd十年前就發表了關系數據庫理論，并在IBM 研究機構開發原型，這個項目就是R系統，存取數據表的語言就是SQL。Ellison看完后，敏銳意識到在這個研究基礎上可以開發商用軟件系統。而當時大多數人認為關系數據庫不會有商業價值。Ellison認為這是他們的機會:他們決定開發通用商用數據庫系統Oracle，這個名字來源于他們曾給中央情報局做過的項目名。幾個月后，他們就開發了Oracle 1.0 。但這只不過是個玩具，除了完成簡單關系查詢不能做任何事情，他們花相當長的時間才使Oracle變得可用，維持公司運轉主要靠承接一些數據庫管理項目和做顧問咨詢工作。而IBM卻沒有計劃開發，為什么藍色巨人放棄了這個價值上百億的產品，原因有很多：IBM的研究人員大多是學術出身，他們最感興趣的是理論，而非推向市場的產品，從學術上看，研究成果應公開，發表論文和演講能使他們成名，為什么不呢？還有一個很主要的原因就是IBM 當時有一個銷售得還不錯的層次數據庫產品IMS。直到1985年I B M 才發布了關系數據庫D B 2 ,Ellision那時已經成了千萬富翁。Ellison曾將IBM 選擇Microsoft 的MS-DOS作為IBM-PC機的操作系統比為：“世界企業經營歷史上最嚴重的錯誤，價值超過了上千億美元。”IBM 發表R系統論文，而且沒有很快推出關系數據庫產品的錯誤可能僅僅次之。Oracle 的市值在1996年就達到了280億美元。

面向對象數據庫

隨著信息技術和市場的發展，人們發現關系型數據庫系統雖然技術很成熟，但其局限性也是顯而易見的：它能很好地處理所謂的“表格型數據”，卻對技術界出現的越來越多的復雜類型的數據無能為力。九十年代以后，技術界一直在研究和尋求新型數據庫系統。但在什么是新型數據庫系統的發展方向的問題上，產業界一度是相當困惑的。受當時技術風潮的影響，在相當一段時間內，人們把大量的精力花在研究“面向對象的數據庫系統(object oriented database)”或簡稱“OO數據庫系統”。值得一提的是，美國Stonebraker教授提出的面向對象的關系型數據庫理論曾一度受到產業界的青睞。而Stonebraker本人也在當時被Informix花大價錢聘為技術總負責人。

然而，數年的發展表明，面向對象的關系型數據庫系統產品的市場發展的情況并不理想。理論上的完美性并沒有帶來市場的熱烈反應。其不成功的主要原因在于，這種數據庫產品的主要設計思想是企圖用新型數據庫系統來取代現有的數據庫系統。這對許多已經運用數據庫系統多年并積累了大量工作數據的客戶，尤其是大客戶來說，是無法承受新舊數據間的轉換而帶來的巨大工作量及巨額開支的。另外，面向對象的關系型數據庫系統使查詢語言變得極其復雜，從而使得無論是數據庫的開發商家還是應用客戶都視其復雜的應用技術為畏途。

數據管理的變革

二十世紀六十年代后期出現了一種新型數據庫軟件：決定支持系統(DSS)，其目的是讓管理者在決策過程中更有效地利用數據信息。于是在1970年，第一個聯機分析處理工具——Express誕生了。其他決策支持系統緊隨其后，許多是由公司的IT部門開發出來的。

1985年，第一個商務智能系統(business intelligence)由Metaphor計算機系統有限公司為Procter & Gamble公司開發出來，主要是用來連接銷售信息和零售的掃描儀數據。同年， Pilot 軟件公司開始出售第一個商用客戶/服務器執行信息系統——Command Center。同樣在這年，加州大學伯克利分校Ingres項目演變成Postgres，其目標是開發出一個面向對象的數據庫。此后一年， Graphael公司開發了第一個商用的對象數據庫系統—Gbase。

1988年，IBM公司的研究者Barry Devlin和Paul Murphy發明了一個新的術語—信息倉庫，之后，IT的廠商開始構建實驗性的數據倉庫。1991年，W.H. "Bill" Inmon出版了一本“如何構建數據倉庫”的書，使得數據倉庫真正開始應用。

1991： W.H.“Bill” Inmon發表了”構建數據倉庫”

二十世紀九十年代，隨著基于PC的客戶/服務器計算模式和企業軟件包的廣泛采用，數據管理的變革基本完成。數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。Internet的異軍突起以及XML語言的出現，給數據庫系統的發展開辟了一片新的天地。

非關系型數據庫

隨著互聯網web2.0網站的興起，非關系型的數據庫現在成了一個極其熱門的新領域，非關系數據庫產品的發展非常迅速。而傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，例如：

1、High performance – 對數據庫高并發讀寫的需求

web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發寫請求的需求，例如像JavaEye網站的實時統計在線用戶狀態，記錄熱門帖子的點擊次數，投票計數等，因此這是一個相當普遍的需求。

2、Huge Storage – 對海量數據的高效率存儲和訪問的需求

類似Facebook，twitter，Friendfeed這樣的SNS網站，每天用戶產生海量的用戶動態，以Friendfeed為例，一個月就達到了2.5億條用戶動態，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關系數據庫也很難應付。

3、High Scalability && High Availability- 對數據庫的高可擴展性和高可用性的需求

在基于web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什么數據庫不能通過不斷的添加服務器節點來實現擴展呢？

在上面提到的“三高”需求面前，關系數據庫遇到了難以克服的障礙，而對于web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地，例如：

1、數據庫事務一致性需求

很多web實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。

2、數據庫的寫實時性和讀實時性需求

對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多web應用來說，并不要求這么高的實時性，比方說我（JavaEye的robbin）發一條消息之后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。

3、對復雜的SQL查詢，特別是多表關聯查詢的需求

任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

因此，關系數據庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數據庫應運而生，各種各樣非關系數據庫，特別是鍵值數據庫(Key-Value Store DB)風起云涌，多得讓人眼花繚亂。

海洋QQ1359731023
電話0371-63322216

本文出自：億恩科技【www.laynepeng.cn】

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]

上一篇 >> 揭秘TPM安全芯片技術及加密應用
下一篇 >> 創業并快樂著的六個習慣

一级女人毛片人一女人-一级女性大黄生活片免费-一级女性全黄久久生活片-一级女性全黄生活片免费-国产美女在线一区二区三区-国产美女在线观看

服務器租用

服務器托管

機柜批發

云服務器

建站俠

空間/域名

安全保姆

幫助類別

幫助中心