Let’s kick off this new subseries of RPG Academy with a review of database theory. You might already know a few of these things, but these concepts are crucial to the rest of this series on database modernization.

As this is the first article of a new subseries of RPG Academy, let me start with an overview of what you can expect from this and the next few articles. This subseries will focus on helping you set up your database modernization process. It will start with some database theory, which will be useful later, followed by some tools to help you in the modernization process. Then, it will discuss the database modernization process itself. However, it’s simply not possible to do a thorough discussion of this process in a single article or even a whole series. Entire books have been written about this subject, and even most of those don’t cover all the details. Here, you’ll get a helicopter view, zooming in on a few crucial details.

A Bit of Database Theory

Before learning about database modernization, there are a few key database concepts that you need to learn or revisit. I’ve tried to make this discussion short and simple, but if something is not clear, just Google “database fundamentals” or the name of the concept, and read more about it. This is not an article about database theory, so I won’t spend too much time on the topic.

Conceptual, Logical, and Physical Models

First of all, what is a model? One basic answer is that a model is an abstraction or representation of the real world that reveals all the features of interest to the users of the information in the model. Models are created to better understand a process, phenomenon, or activity. You use a model to provide a representation of items and events, and the relationship among them, and to provide all the basic concepts and rules for good communication between developers and users.

A database model is used to represent data about data, also known as metadata. A database model is an integrated collection of concepts for data description, data relationships, data semantics, and data constraints. Usually, a database model is used for a database schema description.

Here’s a brief description of the three database models:

• A conceptual model emphasizes information as seen by the business world. It identifies the entities and relationships of the business.
• A logical model is based on a mathematical model. It presents the information and entities in a fully normalized manner, where there is no duplication of data.
• A physical model implements a given logical model in a particular database product and version.

Database Normalization

Normalization is the process of removing redundant data from your tables to improve storage efficiency, data integrity, and scalability. A table in a relational database is said to be in a certain normal form if it satisfies certain constraints. Edgar Codd’s original definition defined three such forms. There are now other accepted forms, but let’s stick to the original three. Each normal form represents a stronger condition than the previous one, which means that a higher level of normalization cannot be achieved until the previous levels have been achieved.

Here are the three classic normal forms:

• First normal form (1NF) involves removing redundant data from horizontal rows. You want to ensure that there is no duplication of data in a given row and that every column stores the least amount of information possible (making the field atomic). For example, normalization eliminates repeating groups by putting each into a separate table and connecting them with a primary key–foreign key relationship. Imagine that you have a table with a client’s information and the addresses of its several locations. In each line, the client ID, name, and fiscal data is the same; only the address-related data is different. To achieve the first normal form, you’d have to separate the data into two tables, one for the basic client information, and another for the addresses. In the first table, named “Client Master,” there would be only one record per client. In the second table, named “Client Address,” each client address would be a record. The link between the two would be the client ID.
• Second normal form (2NF) deals with the redundancy of data in vertical columns. In other words, its goal is to make sure all the non-key columns are dependent on the table’s primary key. For instance, if an inventory table is in 2NF, you’d need to know the item ID (the table’s primary key) to determine the quantity in stock for that particular item. A column containing possible item container sizes does not directly relate to the item ID, so that column doesn’t belong in the inventory table. Instead, it should go in an item container table, where it will have a direct relation to that table’s primary key.
• Third normal form (3NF) involves looking for data in the tables that is not fully dependent on the primary key, but dependent on another value in the table. Having a column in a table that can be calculated from another column in the table, even if both columns depend directly on the table’s primary key, means the table is not in 3NF, but in 2NF instead. For example, having a column for item weight in pounds and another for weight in kilograms in an inventory table means that the table is not in the third normal form, because you can convert kilograms to pounds, and vice versa.

Only the Beginning

This article might have jogged the memory of some readers, while being something new for others. I’m not a big fan of theory, but this was a necessary first step for what’s to come. And speaking of what’s to come, the next article will focus on Entity Relationship Diagrams, also known as ERDs. They are a nice, tidy way of describing different types of data and their relation to each other.

As always, feel free to comment on, expand, or correct this article.