Natural System to Data Org
Published: 2020-09-28 15:47:55

#*Hello and welcome*

This post is going to discuss data normalization, largely the first two levels while mentioning the third level. There are six levels in total but these are considered the main levels necessary for most functional app building. The example is based on the Covid-Risk model built in the previous posts.

##**Basics of database naturalization**
Naturalization is essentially fancy terminology for saying that within a database everything should be organized so that the data isn't redundant, is relatable, and can be overall be retrieved as intended.   

Each form of naturalization has specific requirements for the level of abstraction. Each new form builds on the last one and establishes the next rule.

###**First Normal Form of Naturalization**
The first form/level requires that data be simplified and easily related between tables. This goes into the ideas of primary/foreign keys separating data where necessary.
* a table must have a unique primary key to identify the rows
* data within the table is separated in to clear, concise columns that are reduced down to their smallest data form
* data  or groups of data within a table is not repeated or redundant

As an example, the patient table of the coronavirus risk database shows the first form characteristics.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3lsibd29rp7z1xqi1ddo.PNG)

Each row is marked by a specific ID / primary key that then holds different foreign keys and the patient's specific data in the row. The row itself is split up to be in reduced form. Columns like 'symptoms' and 'general health' could in some cases be mistakenly made as one column saved as a string data type that would be inefficient. For example, one could say they have symptoms so their health is poor, but that isn't an efficient system or well-thought-out abstraction for this scenario.

Without being evident in this table alone, it was already edited for redundancy in a previous section of development so that it could reach the first form. The patient table relates to the Patient_Behavior table that then relates to a Behaviors table.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/797u2fq4yw16n9bsi61w.PNG)
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zfukter41fu59abyi27k.PNG)

This setup keeps the patient table from being inundated with behavior listings and repeated descriptions of behaviors.

###**Second Normal Form of Naturalization**
The second form/level of naturalization requires the conditions of form one to be met but then adds that any data within a table must relate directly back to the primary key identifier.
* must meet 1NF
* the data in a table relates to its stored primary key

For example, the Hospitals table in a proper second form looks like this;
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6r3e1n1xyi92hqa2k99j.PNG)

Any data in the table is directly related to the hospital identified, whether it be the status of the hospital or key identifying features.

A version of the table that wouldn't meet the second natural form would be as follows;
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/moakb46vlp3qmbttkatu.PNG)

The column 'population' was added into the table, possibly due to concerns of not being able to support the people in the area. This poses an issue for naturalization because the area's population doesn't relate to the hospital itself and shouldn't exist in the Hospital table. Instead, it relates to the zipcode which is already linked as a foreign key within Hospitals. The column for populations would be DROPPED and instead made a part of the Location table that stores zipcode.

Below is a video that gives a quick lowdown of the first two forms with these examples.

[Normal Form 1NF 2NF](https://youtu.be/RkWNr7DC5m4)

###**Third Normal Form of Naturalization**
The third form is effectively the last form necessary to understand for good basic app and database structure. It covers the idea of dependency within the table.
* must meet 1NF and 2NF
* there should be no columns that depend on any column other than the primary key/ columns should not be inter-dependent and only relate to PK

This essentially builds off of 2NF by saying that data must relate to the PK, but only the PK and not another foreign key or odd column.

Hope this was an accurate enough layman's description of naturalization that made you curious enough to learn more about data organization and abstraction.