What is the difference between 'class diagrams' and 'data models' in UML?

Question

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.

Answer 1

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 diagram details 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 diagrams which are really Activity 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 diagram in 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.

Answer 2

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.

Answer 3

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.