In an earlier article on data modeling we promised to give you a set of exercises to practice finding entities and attributes. Here is the second installment of our problem set.
In an earlier article on data modeling we promised to give you a set of exercises to practice finding entities. Well, here they are. Have fun!
You’re finally ready to get down to real data modeling. We’ll start off with entities and their attributes. Entities are the basic building block of every data model. In this post, you’ll find out what they are and how to identify them.
Data modeling is an essential step in the process of creating any complex software. It helps developers understand the domain and organize their work accordingly. In this article, which begins a new series devoted to database modeling, we’ll try to convince you why you should include it in your projects and what it looks like.
The following fallacies are things that I hear all the time: “SQL is legacy. Why can’t we work with more modern tech?”, or “SQL is low level, like assembler. Would you prefer to work with assembler or with Java? Similarly, would you prefer to work with SQL or with Hibernate?” It’s time we move on and realize that with SQL, we can be incredibly productive and write awesome data logic in only a few lines of code.
The First Normal Form (1NF) is exceptional. The other normal forms (2NF, 3NF, BCNF) talk about functional dependencies and 1NF has nothing to do with functional dependencies. Moreover, we have precise definitions for other normal forms and there is no generally accepted definition of 1NF.
The article presents some concepts on how to decompose relations and what can go wrong. These concepts may seem complicated but they are so basic that you rarely see it written. Still, they are essential for understanding how the normalization process works. One may prepare a perfect meal just by following a recipe but no one can master the art of cooking without understanding what's going on behind-the-scenes. The same holds true with databases.
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.
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.
In this article I will show you how big an impact the number of entities in a relationship has on not only the readability of the diagram, but also the database itself.
We begin a new series on our blog: Vertabelo Challenges. Once in a while we’ll publish a new database modeling challenge on our blog so you can test your database modeling skills in Vertabelo. Don’t worry – the challenges will be fairly easy. Follow our Database Design 101 series on the blog and on Vertabelo Youtube channel, and you should be able to conquer all of them in no time.