I have read the definition of 1NF which is, "If each attribute of relation is atomic". Please tell me what is Atomic.
1NF requires that every attribute position in every tuple in every relation contains a single value of the appropriate type. The types can be arbitrarily complex. In fact, the types can be relations. (CJ Date's book Database in depth: relational theory for practitioners treats this issue in a way that's pretty easy to understand.)
"Atomic" has never really meant "indivisible", which is why that term is finally falling out of favor. Loosely speaking, "atomic" means if a value has component parts, the dbms either ignores the existence of those parts, or it provides functions to manipulate them. For example, a timestamp value has these parts.
That kind of value is obviously divisible, and all database management systems provide functions to manipulate those parts. They also provide a way to select a timestamp as a single value. (Which, of course, it is.)
"Atomic" refers to Codd's original notion from 1969 that each attribute in each tuple within a relation should consist of a single value and not allow multivalued structures of the kind supported in databases like the CODASYL model.
In modern SQL DBMSs atomicity isn't really an issue. SQL tables do not allow multivalued columns and values are always "atomic".
Atomic means data which cannot be divided further.
Rule of atomicity:
- rule 1: a column with atomic data can't have several values of the same type of data in the same column.
- rule2: a table with atomic data can't have several columns with the same datatype.
Like fullname column can't say that it could be atomic because it can be further divded into lastname, firstname. A column with interest could also be divided further, so a column which can't be divided is known as atomic.
It means that the key cannot be decomposed. Let's say that you have a table with three columns, forename, surname, and telephone_number. You declare a compound primary key on (forename, surname). That primary key is not atomic because it is actually composed of two columns. Now let's say you change your table to two columns, full_name and telephone_number, with a primary key on full_name. Is the key now atomic? No, because in your application you could split it into forename and surname still, on the space. Now let's make our table id, full_name and telephone_number, primary key on id (which is an integer). That is atomic, because the integer cannot be meaningfully decomposed.
Codd originally appears to have meant that no value is itself a set. This is a useful starting point but "atomic" has no ontological meaning when it comes to databases (something C. J. Date is right to point out). Codd tried to formalize the definition as something that could not be further decomposed outside of special database operations (i.e. a timestamp is atomic because extracting the year is a special database operation). In other words, if the database can break out sub-values, that is ok. But you should not have sets (unordered lists) or objects which require application logic to break down.
Over time and struggling with this issue in operational environments I would propose an intermediate definition of atomicity, one stricter than Codd and without the rabbit hole that Date discusses:
A value is atomic for purposes of first normal form if and only if:
- The value is not a set (yes, I know Date disagrees) and
- There are no foreign key references to any sub-portion of the field.
In particular, the representation of a value cannot determine its atomicity. Representing an IP address as "10.0.0.1" vs ARRAY[10,0,0,1] vs 167772161 does not matter for 1NF analysis since all three refer to the same atomic value.
In particular, common (and sometimes useful!) 1NF violations regarding atomicity include:
- Storing an array of tags to a blog post or comment.
- Storing tables within tables, where the inner table has a referential integrity requirement against another relation elsewhere.
These problems generate, more or less, the same data anomalies.
Consider a location on Earth. I can find it with (longitude, latitude) pairs or with the HTM (Hierarchical Triangular Mesh) code. Since they both measure the same data. This is a physical fact, which we can measure with a cell phone; it translates a grid number into [longitude, latitude] for you), they must both be either atomic or compound in your model.
Do not confuse the scale used for measurement and notation used to display the data with the nature of the data.