Java架构-数据建模 NoSQL 数据库的概念和对象建模符号

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Coco_Wditm/article/details/84543039

在最近的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 数据库吗?还有,它们如何能有助于不同数据结构的数据管理?

扫描二维码关注公众号,回复: 4249918 查看本文章

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架构

分享互联网最新文章 关注互联网最新发展

猜你喜欢

转载自blog.csdn.net/Coco_Wditm/article/details/84543039