One of the items you may have seen on the tools that you were using on Set up for an ERD is that you were asked if you wanted to reverse engineer it. Do not let the term “Reverse Engineer” confuse or scare you.
Reverse Engineer – in this case – just means that the tool will take an existing database and create the ERD for it. If you have an existing database or you find it easier to work in your database tool of choice, then you will absolutely love this feature. In other words, you can go from this:
to this:
How does the ERD tool know even the basics of how each table relates to another table? Well, my friend, I’m glad you asked.
Simply put, it’s because of keys. No, not the Florida Keys.
Not the “Keys to the Highway” – that famous blues song by “Big Bill” Broonzy.
No, I’m talking about the keys of a relational database.
The first type of key I want to go over is known as a primary key. Primary Keys are the minimum amount of data that will make each row of a table unique. For example, if you have a table with data such as this:
The BusinessEntityID is the Primary Key in this case and it will make sure that you are talking about one specific person. For example, if I mention BusinessEntityID 10, I will be talking about Michael Raheem. Now, there could be several other times that Michael Raheem is mentioned in this one specific table – but since there could be multiple different people named Michael Raheem, BusinessEntityID 10 is only talking about this one.
Now, you may ask – why aren’t we using the social security number as a primary key? For that, let’s delve fairly deep into that next time, and what makes some items great for a primary key. Until then…