Atomic Data…?

[ChrisO]

A few general questions about the nature of atomic data.

What exactly does it mean?

If a field in a table defaults to Now() does it not store both Date and Time in the one field? Sometimes we want just the Date and sometimes we want just the Time.

If a telephone number requires Country Code, Area Code, Number and Extension is it not placing four (4) atomic chunks of data in the one field? If a database requires knowing each individual digit, perhaps for hardware routing purposes, should not all digits be stored in a different field and maybe also in related tables?

If a person has more than one Title, should the titles go into more than one field?
If a person has more than one Initial, should the initials go into more than one field?

If a Surname may be O’Brien, le Chartier or Du Pont, should not the surname field be broken down to more fields to allow for easier criteria for surname grouping?

Atoms were once thought to be atomic. (Perhaps a Quark of fate? )

In other words, if we cannot satisfy the requirements for atomic data (First Normal Form), then what claim do we have on the remainder?

Regards,
Chris.

 

[ChrisO]

Thanks for taking the time to put that together Pat.

Discussions on database theory sometimes seem to miss your point…
“Above all, relational database theory makes sense. Use common sense when breaking attributes into their atomic parts.”

Finding that “common sense” limit at times seems to vary from database to database.

With only slight reference to the atomic nature of the data: -
Names of people are my biggest problem at the moment because of the fact that I get data, from another system, in just three fields… FirstName Surname and PreferredName all in uppercase, sometimes hyphenated and sometimes without the PreferredName.

The biggest problem is the uppercase since all information about proper case has been lost and can’t easily be regained.

I guess that’s the point with the Date/Time field as well… once the information is thrown away it can’t be regained. It’s the two pieces of data together that specify a single point in time.

We could separate the data into Date and Time fields, which may better serve the atomic nature of data, but as you say…would it make sense to do so?

Thanks again and regards,
Chris.

 

[WayneRyan]

Hi Chris & Pat,

Nice discussion.

Time is a purely "atomic" data element. Its units are static and
doing operations like DateDiff, DateAdd and so on are very easy.
You can display it in a multitude of ways, but it's stored "atomically".

To me "atomic" is breaking down:

9 feet
3 yards
108 inches

You'll kill yourself trying to parse them.

Good thread!

Wayne

 

[ChrisO]

G’day and thanks Pat and Wayne

Now for a short explanition…

The original and subsequent posts of mine were somewhat rhetorical.
I knew I could not pull this off without the help of others.

My aim is to open a discussion on the practical application of normalization.
(Sometimes the no-bodies require the help of the some-bodies to do things.)

I did not ask Pat or Wayne to reply but that was my hope, and that you did superbly, so much so that I think it requires an entry in the FAQ.

Normalization and Common Sense
subheading Atomic Data

next subheading …Storing Calculated Values
(Believe me I will get around to it.)

I hope you forgive me, Pat and Wayne, for the apparent waste of your time, but the postings that you make are never a waste of time.

Regards,
Chris.

 

[Kraj]

We could separate the data into Date and Time fields, which may better serve the atomic nature of data, but as you say…would it make sense to do so?

Let me reiterate...according to Pat's post if you created a seperate field for date and time, you would actually be storing the same value twice; it would just be formatted differently.

And to summarize Pat's original post...,"It depends on what you need to do." Part of good system development is understanding the requirements. If your users need a slice of bread, don't give 'em a farm.