Vertabelo Academy

So you want to create your first database model but you don't know how to start? Read on! I assume you already know a little about tables, columns, and relationships. If you don’t, watch our video tutorials before you continue.

Database models require that objects be named. While several facets of naming an object deserve consideration, in this article we’ll focus on the most important one: defining a convention and sticking to it. But first off, let’s get the answer to the question why we should use naming conventions.

The most recognizable characteristic of crow’s foot notation (also known as IE notation) is that it uses graphical symbols to indicate the ‘many’ side of the relationship. The three-pronged ‘many’ symbol is also how this widely-used notation style got its name. Let’s see where crow’s foot is placed in the history of data modeling and take a look at its symbols.

Why do you need all of this normalization stuff? The main goal is to avoid redundancy in your data. Redundancy can lead to various anomalies when you modify your data. Every fact should be stored only once and you should know where to look for each fact. The normalization process brings order to your filing cabinet. You decide to conform to certain rules where each fact is stored. Nowadays the go-to normal forms are either the Boyce-Codd normal form (BCNF), which we will cover here today, or the third normal form (3NF), which will be covered later. (Yes, there are also the first, second, fourth, fifth normal form. We'll talk about them later.)

When we design a database, we draw an entity relationship diagram (ERD). It helps us understand what kind of information we want to store and what kind of relationships there are. It is imperative that this diagram is easy to read and understand. The number of entities in a relationship is the arity of this relationship. The aim of this article is to give some examples and show how big an impact the arity of relationships has on not only the readability of the diagram, but also the database itself.

In the process of designing our entity relationship diagram for a database, we may find that attributes of two or more entities overlap. In this case, we may create a subtype of the parent entity that contains distinct attributes and supertype entity. The article presents how to model inheritance and what are the features of each solution.

A good database design can be created by following a few simple rules. Here is my subjective list of nine tips for better data modeling.

It’s common knowledge that the best way to learn something is to practice it in a real-life scenario. Obviously, the same applies to database modeling. Therefore, in this article I decided to teach you how to create a simple database structure, taking a textbook example of a hotel room reservation system. I will show you how to get started and give you some ideas for extending the model.

Across the globe, the job portal site is a well-known feature of the Internet landscape. Big players like Indeed and Monster have turned job hunting and recruiting into a veritable online industry. Let’s dive into the elementary features leveraged by job portals and build a data model that can support them.

People love to communicate. We often joke that any software system always evolves into a messaging system. This article will explain the system requirements and step by step approach to design a data model for a messaging system.

Storing sales data properly and later combining it can lead to creating a predictive model with a high rate of accuracy. This new series of articles analyzes a database design for recording sales, starting with a simple example of a database model for sales in a coffee shop.

Let’s be honest: we all love to play games, especially on our computers. Until the Internet became widespread, most of us played computer games by ourselves, usually against AI opponents. It was fun, but as soon as you realized how the gameplay mechanics worked, the game lost most of its magic.