6

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?

Chandima Gayan
  • 87
  • 1
  • 5
  • 6
    You can divide a last name into letters, but that doesn't make it a composite attribute. Would you ever want to know *only* the "months" component of someone's age? – Kilian Foth Dec 12 '16 at 11:15
  • 11
    So you store your age (say 20 years, 10 months, 5 days) in the DB and now you're always that old? –  Dec 12 '16 at 11:23
  • Thank you, I got the idea about the name being divided into letters thing as soon as I posted the question, I guess it's not how you can "say" something but about how you can factually store something. Thanks for the answers :) – Chandima Gayan Dec 12 '16 at 11:40
  • @ThomasKilian Age doesn't necessarily have to be a dynamic thing. "Age when patient first contracted cooties" would be something that doesn't change. – Blrfl Dec 12 '16 at 12:26
  • 1
    @Blrfl Getting philosophic? Age is always dynamic. "Age at" is static, though pointless as you can calculate it from the birthday (which is definitely static). –  Dec 12 '16 at 13:06
  • 9
    Please read [Falsehoods Programmers Believe About Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) as you seem to be believing some falsehoods about names. – Lars Viklund Dec 12 '16 at 14:28
  • 12
    Please don't store age in the database... Store Birth Date sure, but not age! – Milney Dec 12 '16 at 15:11
  • @Blrfl, in that case you would save both the patient's birthdate and the diagnosis date. No ages involved. – Arturo Torres Sánchez Dec 12 '16 at 21:24
  • 1
    @LarsViklund, I hate that article because it points out problems but proposes no solutions. (e.g. people with no Unicode name). – Arturo Torres Sánchez Dec 12 '16 at 21:25
  • 1
    @ArturoTorresSánchez Good point, but if you can make someone aware of the trivial mistakes even in a westernish market, it's a net win. – Lars Viklund Dec 13 '16 at 10:03
  • @ArturoTorresSánchez What happens when you've got a very large data set a frequent query is at age-at? My point is that storing something that way, whether in a calculated column or an expression-based index, can be a good thing to do _depending on the use case_. "Always/never do X" is rarely good advice 100% of the time. – Blrfl Dec 13 '16 at 11:37
  • @Blrfl, you're right in that regard. However, I never said “never”, it was just an example where you don't need to store the age, but compute it. Of course the requirements will dictate whether you want to do that or not. – Arturo Torres Sánchez Dec 13 '16 at 16:18

4 Answers4

30

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?

Or

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".

RubberDuck
  • 8,911
  • 5
  • 35
  • 44
  • The questions "Can age be a composite attribute" and "Can age be stored as a composite" are completely unrelated, until one starts to mutilate her logical data model to better fit her physical data model for performance purposes. – Joker_vD Dec 12 '16 at 16:10
  • 3
    @Joker_vD as always, it depends. Is this for a transactional db underneath an application? Then no, don't do this. Is it warehoused for reporting where no general purpose language will consume the data? Ok, yup. Optimize the storage for that. – RubberDuck Dec 12 '16 at 16:12
  • 1
    Furthermore in Korea, when you're born you have 1 years already so the function is different ;D – Walfrat Dec 13 '16 at 13:50
  • @Walfrat *sigh* [internationalization...](https://youtu.be/0j74jcxSunY) – RubberDuck Dec 18 '16 at 14:24
6

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.

Bradley Thomas
  • 5,090
  • 6
  • 17
  • 26
2

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.

user
  • 2,703
  • 18
  • 25
Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
0

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.

Lucas
  • 298
  • 1
  • 4