• 20 hours
  • Medium

Free online content available in this course.



Got it!

Last updated on 3/6/20

Learn about class diagrams

Log in or subscribe for free to enjoy all this course has to offer!

UML stands for Unified Modeling Language.  It involves sketching up little diagrams that describe how elements of a system are connected!

Databases are all about collecting and saving information. Before you start collecting, you have to decide what to collect and that's where UML comes in.

What to collect?

A UML class diagram is a list of what you think should get collected in a database table.

A relational database is a database that is composed of a bunch of linked tables. A table is just like a spreadsheet, and in UML, we refer to tables as classes.

Here’s an example of a UML class diagram (we'll break it down in a second):

The UML diagram for the Restaurant class
The Restaurant class

The UML class diagram is a box that features a word, usually a noun, at the top of the box. This is the name of the class. There is a line and below the line, there is a list of attributes. In the  Restaurant  class, the attributes are things that we want to collect about each restaurant. If we were to turn the class diagram into a table, the attributes become the column titles:






Holy Cannoli



33 Sugo Street


Rough Burger

Burger Joint


22 Catsup Way


Tacky Hut



11 Scale Road

very cheap

To see this same concept with a different subject, here's another table that lists friends and their possible attributes:

























And here's a class diagram that describes that same Friend table:

When you draw a class diagram, you name the class, in this case Friend, and also name the attributes of the class. 

Choosing good names

Elephant, Pachyderm, PeanutEater, or Item?

Choosing a good name takes some thought! Even an elephant can be described in a myriad of ways.

Names are the building blocks to complex systems. If the names are not appropriate, the system can easily get confused. If the names are spot-on, everyone in a system can communicate effectively.

UML diagrams are amazing tools to help choose good names.

Since a database is a way of saving information in a way that models how a system operates, choosing good names and creating an accurate model of a system will require speaking to the the different players involved. Different people may have different views about a system.

A UML diagram is an excellent tool for this discussion. And through this discussion, you will develop a model that will start to reflect how the system operates.

This will require multiple drafts of UML diagrams and conversations in order to arrive at a clear image of the system.

If a system's components are named accurately, the model you make will be clear both to you and to your clients.

Check out this domain diagram:

A UML Domain diagram for a train station
A UML Domain diagram for a train station

Your clients may not know about how database work, but they'll be able to see what you are calling things and roughly how things are related.

For example, in the diagram above, a better name for  Trip  might be  Route , which your client might suggest to you. If something looks wrong, your client can question both your names and your logic about how the parts are connected.

Naming conventions

Naming conventions are like the grammar of a sentence. You choose your own words, but grammar rules dictate the form the word should take.

Here are some naming conventions for a class:

  • The name of the class should be a singular noun.

  • The first letter should be uppercase

  • If you need to make a table named with multiple words, they should be in UpperCamelCase.

An example of a class diagram
An example of a class diagram

The naming convention for an attribute is singular and lowerCamelCase.

Editing names

Choosing the right names is important for a database's schema. Accuracy in naming leads to accurate communication in your enterprise and accuracy in your code.

Nobody gets it on the first shot.

You need to choose names that are neither too specific nor too general.

Is the name too general or too specific?

For example, if you have a UML class for all things that you might eat in the morning, you could call it  Cereal .

If that is all you eat in the morning, then it could be a fine name.

But if you start having poached eggs for breakfast and put that in the  Cereal  table, it could lead to some scrambled logic about what should be put in this table. 

On the other hand, if you choose a name that is too general, like  Food , and if there is already another table named  Lunch , then your schema is confused. 

Somehow the word  Breakfast  comes to mind as the right name choice.

A more practical example would be in a company's database

For a company, you'd probably need to make a table for the employees, and you could call it  Employee. But if your clients start putting information about clients, freelancers, and vendors into this table, then its name,  Employee  will be confusing. 

Another programmer on your team may not understand that the  Employee  table contains more than just employees. Potentially, he or she would create another table for client information partially duplicating your  Employee  table.

If you had understood that the client wants to put all the personnel and client information in the same table, you would have probably chosen a name more general than "Employee." If you had named the table  User  the scrambling of information would probably have been avoided.

So after you create UML Class and Domain diagrams, review them with your clients. Their feedback for your name choices will be both invaluable for understanding ‌the system and for developing an accurate and usable model.

In the next chapter, we'll go over how class diagrams can interact.

Example of certificate of achievement
Example of certificate of achievement