“类图”和“类图”有什么区别？和“数据模型”；在 UML 中？
我有作业，我应该画一个类图和数据模型。我写了类图。我不知道如何处理数据模型。 有什么区别？
根据互联网上的文字，它们在我看来，即：类图和数据模型是同一件事。
类图和数据模型之间有什么区别。
I have homework and I'm supposed to draw a class diagram AND data model. I wrote the class diagram. I don't know what to do about the data model. What are the differences?
According to texts on the Internet they seems to me, ie: class diagrams and data models are the same thing.
What is the difference between class diagrams and data models.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能已经知道，
统一建模语言是一种用图表描述系统的方法。它们不仅与软件相关，还可以与硬件、经济、日常用品甚至任何事物相关，尽管它们更普遍地与软件系统一起使用。类图详细说明了如何将系统拆分为离散对象、这些对象如何相互关联以及它们可能具有的任何已知接口。类图中的每个类都可以保存数据和函数。
例如，一个 Car 类有一个 Engine、一个 Steering Wheel 类以及与其链接的多个 Wheel、Door、Seat 和 Pedal 类。在所有这一切中，类图都是静态的。
我不太清楚你所说的数据模型是什么意思。
我见过用于建模数据库表的类图，通常这些没有任何功能元素，只是显示数据表如何相互关联。
有人认为需要对数据图的 UML 标准进行补充，但迄今为止尚未获得批准。
这是因为数据的持久性、表之间的关键关系和约束可能很难使用标准类图进行建模，并且大多数 UML 工具都会对标准进行调整以实现这一点。
然后还有
数据流图，它们实际上是活动图，用于显示系统内进程之间的数据流。现在，如果我们回到类图并假设数据图用于对数据库建模，那么您会注意到有一些可能被忽略的差异。
类图上的类可以具有数据属性（代码变量等）和功能属性（方法、过程、函数等），但类的这些元素也可以具有访问属性（私有、公共等）。类图还可以显示继承，例如大众汽车是汽车，福特也是汽车，两者都将从汽车继承，这可以显示。
数据库意义上的数据图将显示数据项（数据库表中的列/字段），但访问属性（公共、私有等）的概念或继承的概念没有任何意义，因此可以不被显示。
这是因为它不是对同时具有数据和功能的离散对象进行建模，而是对与这些对象关联的数据进行建模。例如，汽车表可能具有到制造商表的关系链接，其中存储了值大众汽车和福特。它可能有一个“车轮”列，但这只会显示车轮的数量。数据库的存储过程存在于从数据中提取的级别 - 它们利用数据，但不受它们从中获取数据的数据表的控制或拥有。
我可能没有很好地解释自己，但我希望我能有所帮助。
这是一个有用的网站
这是另一个，在该网站上 具体的数据建模。
Unified Modelling Language, as you may already know, is a means of describing systems with diagrams. They don't just relate to software, but can also relate to hardware, economics, everyday items, in fact anything, although they are more generally used with software systems.A
class diagramdetails how you have split your system into discrete objects, how those objects relate to each other and any know interfaces that they may have. Each class in a class diagram can hold both data and function.For example a Car class has an Engine, a Steering Wheel class and multiple Wheel, Door, Seat and Pedal classes linked to it. In all of this a class diagram is static.
I'm not exactly sure what you mean by data model.
I've seen class diagrams used to model database tables, usually these are without any functional element and just show how the data tables relate to each other.
There are those that argue that there needs to be an addition to the UML standard for Data Diagrams, but as yet none have been ratified.
This is because persistence of data, key relationships and constraints between tables can be difficult to model with a standard class diagram and most UML tools implement tweaks to the standard in order to allow this.
Then there are
dataflow diagramswhich are reallyActivity diagrams, used to show the flow of data between processes within a system.Now if we go back to class diagrams and assume that a data diagram is used to model a database then you'll notice that there a few differences that may be overlooked.
A class on a class diagram can have data properties (code variables etc) and functional properties (methods, procedures, functions etc.) but these elements of a class can also have access properties (private, public etc.). A class diagram can also show inheritence e.g. a Volkswagon is a Car, so is a Ford, both will inherit from Car and this can be shown.
A
data diagramin the database sense will show data items (columns/fields in database tables) but the idea of access properties (public, private etc.) or the idea of inheritence has no meaning and thus can't be shown.This is because it isn't modelling discrete objects that have both data and function but the data associated with those objects. For example a Car table may have a relational link to a Manufacturers table in which is stored the values Volkswagon and Ford. It may have a Wheels column, but this will only show the number of wheels. Stored procedures for the database exist at a level labstracted from the data - they utilise the data, but are not governed or owned by the data tables that they get the data from.
I've probably not explained myself very well, but I hope that I've helped.
Here's a useful site
And here's another and on that site data modelling specifically.
一般来说，数据模型定义了数据库的实现方式。这些图是实体图。类模型是系统中对象之间的功能关系。类有数据，但它不是数据模型。设计同时具有类模型和数据模型。举一个简单的例子，客户存在一个数据模型。该数据模型就是我们的客户数据库的设计。存在类模型设计来实现如何处理客户订单。数据模型是数据库设计者使用的。类模型是软件设计者用来实现订购业务功能的模型。数据模型和类模型都有图表。他们使用不同的符号和规则。类图与实体图。两种不同类型的图表。
Generally data models define how the database is implemented. Those diagrams are entity diagrams. A class model is the functional relationships between objects in your system. A class has data but it isn't the data model. A design has both a class model and a data model. As a simple example, a data model exists for a customer. That data model was the design for our customer database. A class model design exists to implement how to process a customer order. The data model is what the database designer uses. The class model is what the software designer uses to implement a ordering business function. Both the data model and class model have diagrams. They use different symbols and rules. Class diagram vs Entity diagram. Two different kinds of diagrams.
数据建模不是专注于对象方法的 UML。
话虽如此，您可以在对象级别的类图中进行建模，并使用 Java 代码中的 Hibernate 注释创建数据库。
我的意思是您创建代码并同时添加持久性注释。这将在部署时创建您的数据库。
如果您使用 Omondo Persistence 配置文件，不应该进行数据建模的 UML 也可以在部署级别创建数据。这意味着您可以在对象级别建模并创建数据库。非常强大的方法，因为数据创建阶段现在与对象结合在一起
这仍然是一项举措，但如果大公司采用这种方法，它可能会成为一种标准，这对我来说是我推荐的 Java 编码的最佳实践之一。
Datamodeling is not UML which is focused on object approach.
Having said that you can model inside a class diagram at object level and create your database using Hibernate annotations in the Java code.
I mean that you create your code and add persistence annotation at the same time. This would create your database at deployment.
UML which is not supposed to be datamodeling can also create data at deployment level if you use the Omondo Persistence profile. It means that you can model at object level and also create your database. Very powerful approach because the data creation stage is now joined with the object
This is still an initiative but it could become a standard if bigger companies adopt this approach which is for me one of the best practices when codding in Java that I would recommend.