Class > Tlass > Taass > Tabss > Tabls > Table


Have you ever written a summary? Whether it was of a chapter from a literature book or of one of your class’s lessons, all you had to do was to read whatever you needed to, identify the main ideas and their most important complements and turn all of that into a new transcript. It’s simple, really. All you are doing is turning plain text into less plain text, but, what if that wasn’t the case? What if you wanted to change the source’s format and following a couple steps wasn’t enough?

Let’s say you just read a chapter from one of your school’s books and want to make a mind map with its information. Only identifying main ideas wouldn’t cut it, you would also need to classify them, connect them and be able to express ideas in fewer words. This isn’t as simple as a summary, and the same happens with timelines, diagrams, other kinds of maps and many other similar representations. The methods have essentially the same purpose, but extra or different steps may be needed to achieve it.

I’ve talked about class diagrams before and how they’re used in OOP to denote object classes, their attributes and methods; what their components are and why they can be useful. This time I will talk about one of the processes in which class diagrams get to be implemented, more specifically: converting class diagrams (or similar) to database tables.

Lots of tables in a class (get it?):

“Orderly Structure” flickr photo by cogdogblog https://flickr.com/photos/cogdog/2555287254 shared into the public domain using (CC0)

If you’ve ever worked with databases then you must know that they can be classified into relational and non-relational. In case you haven’t, I’ll explain the key (hehe) difference regarding class conversions: relational databases, which mostly use SQL for queries, store data in tables with both rows and columns; while non-relational databases change their way of representation depending on what type of data is supported.

Since relational databases’ tables always have the same structure (rows and columns), the way of mapping class representations into these tabulations is easier. This is also the reason why there are many tutorials on how to do this kind of translation. The process can be compared to the summaries I mentioned in the first paragraph of this entry. There’s not much to think about, you only need to identify certain patterns or elements in one representation and apply the appropriate method to make it work for the other. 

I found a very complete tutorial that even includes an example for how to follow the conversion process. I will now list the steps it includes and let you visit the website in case you are interested:

  1. Replace the standard identifier stereotype stid by pkey.
  2. Replace the platform-independent data type names by their SQL equivalents.
  3. Eliminate multi-valued attributes.
  4. Turn any enumeration data type into a corresponding table.
  5. Eliminate generalization relationships.
  6. Eliminate associations.
  7. Define an index for attributes that serve as a search field.

Yes, only seven steps are enough for this implementation of a class. But remember, they are designed to work for UML class diagrams, so other class representations may need some adjustments. Regardless, this is still simple.

On the other hand, classes can also be implemented in non-relational databases. The problem is that, since the structures used to store data may vary greatly there’s no standard method. Also, since non-relational databases are not as common nor studied, this kind of process may be even less common. This is similar to the example I gave with mind maps.

As I was doing research for this I found two websites, each explaining a different process to map class diagrams to non-relational databases. Now you may be thinking: Oh, well, if people already figured out how to map that, then the problem must’ve been solved, right?. But the thing is, they explain different processes because they focus on different non-relational structures. One does it for graphs, while the other, for documents. The fact that they only work for certain formats, along with the information included in these websites leads me to think that this kind of mapping can be more complicated than it seems. Also, both processes start from UML diagrams, so they’re not even complete in that regard. Regardless, they seem to work fine for what they claim, so that’s something, at least.

A funny thing happened as I finished writing this entry. I realized that the comparisons I made between mapping and summaries were actually present when redacting some of the paragraph in this post. Let me explain: since there’s so much information about relational databases and the conversion from classes to tables it was easy figuring out what to write. I just had to take the main ideas from any page I found: a summary. But it was different for the non-relational part, there was definitely enough information for me to use, sure, but I had to take different pieces from several websites so I could understand, reinterpret and write about it: somewhat similar to the example with mind maps.

Mapping to non-relational databases may be complicated, but not impossible. Using relational databases is the easier solution, though. Besides, SQL has by far more documentation, which is also a great advantage and why I’d definitely recommend using.

TL; DR: Stick to SQL.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: