跳到內容

網絡數據庫模型與。關係模型

我們分析了關係數據庫模型和網絡數據庫模型的優缺點。每個模型如何工作並突出每個模型的優點,缺點和功能。這兩種模型之間的差異可能導致開發應用程序的成功或失敗。

以下內容討論了每個模型的工作方式,並重點介紹了每個模型的優點,缺點和功能。這兩種模型之間的差異可能導致開發應用程序的成功或失敗。

 

 

關係數據庫模型

您正坐在公共汽車上,回家。有點累了,但不是那麼困,您決定聽一些Bon Jovi的音樂。再次想想,您想看他的一部電影(想到狼來了)。 iPhone的聚光燈搜索效果很好。輸入“ Bon Jovi”作為關鍵字,媒體播放器將無縫查找他們存儲在設備上的音樂和電影(兩個不同的類別)。

像上面那樣的常見操作通常使用關係數據庫管理系統(RDBMS)。該數據庫稱為Media Collection,它定義了三個表ARTIST,ALBUM和MOVIE,分別存儲了藝術家的姓名,專輯和電影標題。當選擇一個特定的藝術家時,例如本例中的Bon Jovi,將發出SQL查詢以檢索屬於所選藝術家的所有專輯和電影標題。返回的數據通常按字母順序顯示在iPhone屏幕上。

 

關係數據模型的弱點

這些看似簡單的步驟揭示了關係數據模型固有的兩個基本弱點。第一個弱點是每個關係都需要在與之關聯的兩個表中都有重複的列。例如,ARTIST和ALBUM表都必須包含並維護一個存儲藝術家姓名的列,以便可以在藝術家及其專輯之間建立鏈接。這意味著要保持兩列“同步”,需要額外的存儲空間和編程開銷。更改藝術家的姓名意味著該藝術家的所有ALBUM條目都需要更新其“藝術家姓名”列。

第二個弱點,也是本文更相關的方面,是這樣一個事實,即單個關係只能包含兩個表,即主鍵(主)表和外鍵(引用)表。在音樂收藏數據庫中,ALBUM表和MOVIE表都需要引用ARTIST表。由於此限制,需要定義兩個單獨的關係;一種包含對ARTIST表的ALBUM表引用,另一種包含對ARTIST表的MOVIE表引用。

 

低效的數據檢索操作-關係數據模型

當查找與藝術家關聯的所有專輯和電影時,這轉化為效率很低的數據檢索操作。在第一個操作中,數據庫系統從ALBUM表中檢索所有相關專輯,並將結果集存儲在一個臨時位置。在第二個操作期間,執行與第一個操作相同的過程,只是這一次它從MOVIES中檢索結果。最後的操作將兩個結果集合併,必要時對其重新排序,然後返回合併的結果集。

當數據庫中的數據量相對較小並且有大量可用的計算資源時,關係模型的效率低下可能不是問題,特別是因為今天普通人擁有一台具有2GHz雙頻計算機的計算機並不少見核心CPU,配備2GB內存和500GB硬盤。另一方面,對於需要數據庫系統(DBMS)的小型計算機來說,存在一個快速興起的市場-智能手機,便攜式音樂播放器和GPS設備,僅舉幾例。這些手持式系統的CPU速度和內存有限,因此可以從DBMS中受益匪淺,DBMS可以在性能和磁盤使用方面實現靈活,高效的數據存儲和檢索。

網絡數據庫模型正是提供了這一點。

 

網絡數據庫模型

網絡模型是分層數據模型的增強形式,它表示記錄樹中的數據。表(記錄)之間的關係表示為集合。一組具有一個父記錄(所有者)和一個或多個子記錄(成員)。集合中的相關記錄通過指針直接鏈接,而不是像關係數據模型中那樣通過匹配重複的列進行鏈接。

 

關係數據模型 網絡數據模型

 

與單個所有者關聯的記錄

網絡數據庫模型允許來自多個表的記錄與另一表的單個所有者記錄相關聯。當從與一個主鍵表關聯的多個外鍵表中查詢結果時,與關係對應項相比,這提供了一定的優勢。在Media Collection數據庫中,ALBUM和MOVIE記錄也可以成為一組ARTIST記錄的成員,如圖2所示。這意味著可以通過一次操作檢索給定藝術家的專輯和電影。這消除了在操作中間存儲和可能重新排序臨時結果的需求,從而提高了查詢性能。無需存儲和維護重複的列,網絡數據庫還可以幫助減少磁盤空間和內存使用。

 

績效案例研究

實際數據表明,使用網絡數據庫可顯著提高性能並節省資源。在使用ARTIST,ALBUM和SONG表之間的三元關係的數據結構中,我們的SQL開發人員比較了使用台式機系統和小型消費類設備的關係數據庫模型和網絡數據庫模型的數據修改和查詢性能。他們發現,與關係數據模型相比,網絡模型使用更少的磁盤空間來存儲相同數量的記錄和關係。所有的存儲節省都可以歸因於用設置指針替換ARTIST-ALBUM和ALBUM-SONG外鍵索引。

刪除這些數據結構對存儲需求有巨大影響,因為典型的B樹索引所需要的空間約為其索引空間的1.3倍。他們還發現,網絡數據庫模型的插入性能提高了23倍,查詢性能提高了123倍,如表1所示。

 

網絡與關係基準
表1 – x86和ARM7系統上的關係模型和網絡模型的基準測試結果。

 

不同的管理要求意味著不同的數據結構以及不同的存儲和訪問數據方法。生成的系統可能由幾個沒有關係的表組成,也可能由數百個與復雜關係相關聯的表組成。儘管關係數據模型是事實上的標準,但我們現在知道,它並不總是為更複雜的數據管理問題提供最佳解決方案。與單獨的關係數據模型相比,選擇適當的數據模型,甚至組合多個模型可以產生更有效的結果。結果是節省了大量成本,提高了質量並增強了用戶體驗。

 

網絡模型集導航

結論-速度的網絡模型,可用性的關係

關係數據模型 由於其易用性而非常受歡迎,它需要鍵和索引表,這會大大降低應用程序的速度。這 網絡數據庫模型 提供了對數據的更快訪問,並且是快速應用程序的最佳方法。因此,如果您在媒體播放器上單擊喜歡的藝術家並在瞬間查看其20多個專輯和電影標題的列表,則可能是由引擎蓋下的網絡模型數據庫引擎驅動的。 Raima Database Manager利用這兩種模型,了解有關我們的更多信息 先進的數據建模 或者 立即下載免費試用版.

準備開始了嗎?