The following shows two tables, one has employee details and has their address. If both the tables has 'one to one' relationship (i.e one employee has only one address and vice versa), then why not combine the two into one table, like shown below.
Normalization is a quality decision while de-normalization is a performance decision.
If you would join the two tables, and store them as one, your reads and writes would be faster because you will not have to go through the query to join these two tables to work with their combined data.
However, if you keep the tables separate, then looking at individual tables' data may make more sense to you and also give you the freedom to modify one table's data without touching other's. But to work with the joined data of the two tables in 1 to 1 relation would force you to write a (maybe unnecessary) join query every time.
The decision is yours to make in the end. IMO, unless the performance of separated tables is below acceptance, leaving the data stored in a cleaner manner may be a better idea.
There are two kinds of database analysis methods. The first form is one that simplifies the schema in the case of the table used, employees and address it should merge. The other method is called the third form, it consists in making the tables as independent as possible. In the case of the table employees and address it should be separated. There is no right or wrong method it is a choice to make. However, if the database contains many tables, it is more sensible to simplify and get to the first form, but there is no obligation.
If you always have a 1-1 relationship then you have a mutual functional dependency so you get no normalisation benefit.
However there may be reasons to do this:
On the other hand aggregation across the join becomes more expensive.
