CODEWITHSUNDEEP
mysqlsqldatabaseentity-relationshipdatabase-normalization
Tantaros
Tantaros

Reputation: 233

When to apply normalization principles during ER Diagram creation

I'm new to databases.

In a database design process, I know that normalization is a step that occurs after the creation of the tables.

But is it to apply some of the normalization principles during ER Diagram creation? If it is possible, it is a good practise or is it better to normalize after the tables' creation?

Upvotes: 0

Views: 865

Answers (1)

Ron Ballard
Ron Ballard

Reputation: 701

As someone who has worked with databases for decades, I have, for a long time, had a problem with the idea that you design a database wrongly first and then go through this theoretical process of normalisation to put it right. This is all very long-winded and involves different teminology (ER modelling) and expensive diagramming tools.

I think it is important to understand the design principles: why do we store atomic fields in every column? why do we avoid repeating groups? why do we have primary and foreign keys? (and quite a few more).

It is also important to understand the system you are modelling and what the users need to do with it. The best way to do this is to work with it.

So I go straight from discussions with the users to the create table statements in a plain text editor. I have a checklist of what my tables should be like and how they should relate to one another, and my databases are always normalised. My database designs are refactored and migrated on every iteration, and I don't have a bunch of fancy diagrams to fix every time.

This is implied in the Ruby on Rails books (by Sam Ruby and others) and is described in mine (which you can find on my profile if you're interested). The free resource https://www.w3schools.com/sql/default.asp is very good but I think the process of designing a good database is not very accessible there.

Upvotes: 1

Related Questions