1. 程式人生 > >Java架構-資料建模 NoSQL 資料庫的概念和物件建模符號

Java架構-資料建模 NoSQL 資料庫的概念和物件建模符號

在最近的2018資料架構峰會上,Ted Hills主持了一個研討會,該研討會的主題是關係資料庫和 NoSQL 資料庫的資料建模。

他表示,NoSQL 運動幫助了資料庫社群明白了兩件事。首先,並非每個應用程式都需要 ACID,並且,放寬 ACID 以能擴充套件到網際網路規模。其次,表格資料組織很適合大量的資料,但未必適合所有的資料集。但是,隨著時間的流逝,SQL/NoSQL 的顯著區別將會消失,DBMS 使用者則會因為有了更多選擇而獲得收益。

實體關係(entity-relationship,簡稱 ER)建模技術已經在 SQL 資料庫上應用很長時間了,但是,對於 NoSQL 資料庫來說,它們的工作方式是不一樣的。在研討會上,Hills 討論了概念和物件建模符號(the Concept and Object Modeling Notation,簡稱 COMN,發“common”的音)。COMN 用於表示新的資料庫結構,不同的 NoSQL 資料庫均支援該資料庫結構。

他談到了對以 COMN 符號表示新的多模型 NoSQL 資料庫的承諾。無論是資料建模人員,還是程式開發人員都可以使用它,開發人員能夠在 COMN 中用資料對軟體建模。Hills 也討論了建模無模式(schema-less)資料庫的方法。

InfoQ 與 Hills 進行了對話,討論了與 NoSQL 中的資料建模和 COMN 符號有關的話題。

InfoQ:您能否對概念和物件建模符號(COMN)下個定義?

  • Ted Hills:概念和物件建模符號(COMN)是一種資料建模符號,其能用一種熟悉的圖形符號(框和線)來表示需求、圖形和本體性謂詞、邏輯資料、軟體類結構和 NoSQL 及 SQL 的物理實現,該圖形符號能對這些非傳統實現中層之間的重要對映進行建模。

InfoQ:您能否談談 NoSQL 資料庫背景中的概念和物件建模符號(COMN)?以及資料建模和關係資料庫建模之間的不同之處在哪裡?

Hills:實體關係(Entity-relationship,簡稱 E-R)和其他符號假設資料將最終儲存於表格中。隨著 NoSQL 資料庫的出現,現在我們可以把資料存於圖形和文件中,也可以儲存於其他表格結構中,如寬列表(wide-column table)、面向列的表格和鍵 / 值對。我們不再假設從邏輯資料設計到物理實現的對映接近 1:1。此外,物理實現建模,包括非表結構(non-tabular structure)建模,甚至查詢建模,都變得比以往更為重要。COMN 使各種各樣的物理結構和所代表的資料的重要對映得以表達。

InfoQ:對於每種 NoSQL 資料庫,資料建模方法是不同的嗎?比如,像 Cassandra 這樣的寬列資料庫(wide-column database)?以及像 Neo4j 這樣的圖形資料庫?

Hills:是的, 對大多數 NoSQL 資料庫型別來說,資料建模的重點是不同的。屬性圖形資料模型關注於關係,而後用資料屬性來註釋節點和關係。知識圖形資料模型也關注關係,但新增子 / 超型別關係。文件(XML 和 JSON)資料模型把層次關係放在首位。因此,儘管物理資料模型的焦點隨每個 NoSQL 資料庫的型別而改變,但 COMN 可以用於每種資料庫。此外,它可以代表所有這些非傳統資料結構和表(還沒消失),並把物理模型和邏輯資料模型相關聯,理想情況下,邏輯資料模型不會受物理表示選擇的影響。

InfoQ:您能談談多模型 NoSQL 資料庫嗎?還有,它們如何能有助於不同資料結構的資料管理?

Hills:在 NoSQL 的世界裡,必須為你的資料選擇一個物理表示,而且這些資料必須是最適合你的應用程式的。是否需要隨機寫入或只在日誌的末尾寫入?是否需要圍繞分層文件結構來組織資料?或是圍繞關係來組織資料?很多 NoSQL DBMS 只提供一種方法來組織資料。如果需要改變資料組織,或需要更多的方式來組織資料,那麼就不得不改變整個 DBMS。這涉及到處理不同的供應商、不同的支援需求、不同的程式語言和 API 等等。它可不是個平凡的資料庫。如果相反,使用支援多個數據組織的混合 DBMS,那麼使用多種方法來組織你的資料就變得更容易了,並且如果要改變主意也不是件難事。

InofQ:一般而言,微服務如何有助於資料建模?

Hills:我不會說微服務本身有助於資料建模任務,但是,對資料架構,它們的確有顯著的積極影響。微服務必須設計成自給自足的:它始終必須持有本地所需的所有資料。這涉及兩種型別的資料:微服務建立和維護的資料,以及微服務必須從外部源獲取的資料。對微服務來講,資料如何儲存在微服務外部的物理模型不重要,但是,資料如何到達微服務的模型卻很重要。那可以是 XML 或 JSON 文件。資料模型需要表示文件結構及微服務將如何儲存資料,並需要表達它們之間的對映關係,這種關係可能具有重要意義。COMN 能夠同時表達模型和它們的對映關係。

InofQ:您在會議演示中談到了狀態和陳述。您能否討論一下如何在資料庫中建模這些概念?

Hills:每個 DBMS,無論是 NoSQL 還是 SQL,最終,都是把無意義的物理狀態(高電壓和低電壓,或者開和關)和有意義的事物建立對映關係,從而表示資料。我們把這個對映稱為物理表示。在更高的層次上,我們使用表、圖形和文件等結構來表示關係。理解的關鍵是邏輯資料模型應該完全忽略這些物理對映問題。邏輯資料模型應該把重點完全放在資料的含義上以及資料如何按照邏輯表示問題域內的資料。但是,在從邏輯模型轉移到物理模型時,保留從物理模型到邏輯模型的對映關係以及物理表示設計都變得至關重要了。

InfoQ:NoSQL 資料庫領域的新興趨勢是什麼?

Hills:主流趨勢是,NoSQL 和 SQL 之間的差別變得越來越少。對於初學者來說,術語“NoSQL”開始意味著“no SQL(沒有 SQL)”,也即不支援表數格據庫的標準結構化查詢語言。然而現在,它意味著“not only SQL(不只是 SQL)”,這意味著越來越多的“NoSQL”DBMS 開始支援 SQL。在早期,NoSQL 不提供 ACID 強度交易,而這對金融應用程式是至關重要的。現在,很多 NoSQL DBMS 實現了 ACID。同時,一些 SQL DBMS 正允許放寬 ACID,使它們能夠擴充套件到和一些 NoSQL DBMS 幾乎相同的水平。有些混合 DBMS 支援表格和非表格資料組織。最終可能會出現,每個 DBMS 都支援各種物理資料組織,以及 ACID 和非 ACID(“BASE”),所有這些都由使用者選擇。SQL 誕生於表格時代,目前還沒有替代者,而這個事實將會阻礙這一完整的轉型。但是,COMN 可以適用於所有這些資料組織。

Ted 還表示,傳統建模工具供應商對基於每次三層和一個應用的資料模型的觀點很有侷限,NoSQL 建模工具專注於物理建模以排除邏輯資料模型和真實世界模型。像 COMN 這樣的工具能有助於資料建模,COMN 的承諾是代表資料管理的新多模型世界。

關於 COMN 的更多資訊,包括完整規範、白皮書和 Visio 模板,可以從DATAVERITY 網站免費獲取。

希望此文能幫到大家的同時,也聽聽大家的觀點。歡迎留言討論,加關注,分享你的高見!持續更新

我本人邀約各大BATJ架構大牛共創Spring Cloud構建微服務架構的交流社群。 (群號:547793198)歡迎各路架構師、開發者,學習與交流使用Spring Cloud諸多強大元件的實戰經驗。

為什麼某些人會一直比你優秀,是因為他本身就很優秀還一直在持續努力變得更優秀,而你是不是還在滿足於現狀內心在竊喜!

合理利用自己每一分每一秒的時間來學習提升自己,不要再用"沒有時間“來掩飾自己思想上的懶惰!趁年輕,使勁拼,給未來的自己一個交代

  • To-陌霖Java架構

分享網際網路最新文章 關注網際網路最新發展