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 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:
33 Sugo Street
22 Catsup Way
11 Scale Road
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:
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 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.
The naming convention for an attribute is singular and lowerCamelCase.
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
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
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.