my question would be can age be considered a composite attribute? Because name is a composite attribute and it can be divided into first name, middle name and last name. And therefore can age be a composite attribute since you can divide it into years, months and then days?
Can age be a composite attribute? No. age is a function of birthdate and now.
age = now - birthdate
So, what about birthdate? Can it be a composite attribute?
Yes, it can, but it only makes sense to store dates as a composite in data warehousing situations.
Often, when warehousing data, you would store year, month, and day as separate things to make it easier to write queries such as
How many people were born in March?
Of all the people born in 1982, how many have blue eyes. How does that compare to April 1992?
You'd also likely have a table that maps dates to quarters, so you could ask things like:
How do birth rates compare between Q1 and Q2 over the last decade?
These are contrived examples, but hopefully illustrate the point. I'd recommend doing some research on "star schema" databases and "slowly changing metrics".
Yes, you can store Age as a composite of year, month, date, hour, minute, second in the database if you want to.
However this is probably not a good idea in most cases, because Age can be derived from other values that are usually preferable to have stored in the database. The main reason is that it is better to store birthdate rather than Age; because birthdate is constant but Age depends on the current time. As soon as you save your Age, (unless it is some kind of value for "Age at a certain time", rather than dynamic age) then it will be increasingly incorrect over time.
Storing data that can be derived from other pieces of data is also a violation of some levels of Normal Form and can lead to issues such as data redundancy and inconsistency.
In layman's terms:
Usually age is not stored since it's such a volatile attribute. It changes by the second. So storing it is an universally recognized bad idea.
Usually date of birth is stored instead.
What you want is a representational requirement that can be easily calculated at presentation time or in a database view by writing a rather trivial function -- in the case there isn't already a built in format function in the RDBMS or the development language that already does that.
In conclusion: yes, you could do that, but that would be strongly inadvisable.
store the birthdate and calculate the age everytime
Like the others said there is no meaning in storing age directly.
it is not efficient to decompose or normalize too much
Although you can represent dates as 3 column day, month an year this is not efficient at all.
There is only performance advantage in splitting fields that can be indexed. And indexing the any combinations of day, month and year is way less efficient than index the date field instead.
For administrative software systems the performance bottleneck is usually data transfer not processing.