I keep messing up 1NF

Question

For me the most understandable description of going about 1NF so far I found is ‘A primary key is a column (or group of columns) that uniquely identifies each row. ‘ on www.phlo

Answer 1

On 1NF, from wikipedia, quoting Date:

According to Date's definition of 1NF, a table is in 1NF if and only if it is "isomorphic to some relation", which means, specifically, that it satisfies the following five conditions:

• There's no top-to-bottom ordering to the rows.
• There's no left-to-right ordering to the columns.
• There are no duplicate rows.
• Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else).

• All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps].

  —Chris Date, "What First Normal Form Really Means", pp. 127–8[4]

First two are guaranteed in any modern RDBMS.

Duplicate rows are possible in modern RDBMS - however, only if you don't have primary keys (or other unique constraints).

The fourth one is the hardest one (and depends on the semantics of your model) - for example your field Customer_address might be breaking 1NF. Might be, because if you make a contract with yourself (and any potential user of the system) that you will always look at the address as a whole and will not want to separate street name, street number and or floor, you could still claim that 1NF is not broken.

It would be more proper to break the customer address, but there are complexities there with which you would then need to address and which might bring no benefit (provided that you will never have to look a the sub-atomic part of the address line).

The fifth one is broken by some modern RDBMs, however the real importance is that your model nor system should depend on hidden elements, which is normally true - even if your RDBMS uses OIDs internally for certain operations, unless you start to use them for non-administrative, non-maintenance tasks, you can consider it not breaking the 1NF.