There are no attributes

posted by cjh, 23 April 2008

Things don’t have attributes, they have relationships to other things.

Programmers get taught to sort things into objects and their attributes, but that isn’t always helpful. We tend to treat anything we can write down as a value (like a name, a number, or a date) as an attribute of something. But sometimes, a value identifies a thing, and that thing might have other attributes. So the distinction breaks down, and we have to rearrange. In a database, that can mean a lot of extra work.

In a semantic model things don’t have attributes, they have relationships. A relationship might be to a value, and perhaps a given thing may allow only one value in that relationship. That makes it seem like an attribute, but we need to keep those ideas separate.

Is your birth date an attribute? No, it’s just a date to which you have a special relationship - the birth date relationship. Other people have other relationships to that date, and so do other things. Somebody registered their car that same day. The same date plays roles in other relationships, and those roles might even carry meaning in relation to your birth date.

Because you have only one birthdate, it seems obvious to store it as an attribute. That means it’s yours, and not intrinsically related to other things. But what if you made the wrong decision about which concept the birthdate belongs to?

Consider your birth place. Places have their own identity, just as dates do. You only have one birth place, so that could be an attribute too. But there were other people present at your birth… your mother for instance. Your doctor, and nurses. If these things matter in a database you’re designing, you might need to model the birth event. Birth place and birth date are now seen to be attributes of your birth event, not attributes of you at all. The other people involved in your birth also have a relationship to that birth event.

Consider your given name… or is that names? Do the separate names matter, or just the string of names joined up with spaces separating them? That depends on what purpose you have in using the names. You might want to be able to quickly find all the people who have “John” as a middle name - then it might make sense to store the names separately, not as an attribute of the person object.

The same reasoning follows for every kind of attribute. If you start out by thinking about objects (entities) and their attributes, you make assumptions about the way your data will be used.

Instead, start by thinking about how entities are related to values (and to other entities), and make sure you have that clear in your mind. Describe each relationship, using expressions such as “Person was born in Birth” and “Birth is of Person”, “Birth occured on birth-Date”, “Birth occured at birth-Place”, “Person (as Mother) gave Birth”. A hyphen after each adjective will help keep the idea of Place and Date separate from birth date and birth place, while making it clear that birth date is a special role of a Date.

Continue this process of semantic modeling until you have described most of the entities and values that matter, and the relationships (fact types) that join them up.

As you go, you can also record the cardinality of each relationship: “Birth was at exactly one birth- Place”. The “exactly one” isn’t part of the relationship, it’s just a constraint over it. It limits the cardinality of the relationship. Other constraint expressions you might use are “at least one”, or “at most one”. Don’t forget that when you say “exactly one”, or “at least one”, you will need to always know the answer. If you ever need to store information about a Birth but you might not know the birth date, say “at most one”.

When you’re done, or nearly done, you’ll know whether you need a separate Birth table in addition to the Person table, or a separate GivenNames table. Of all the things that you’ve decided matter to you, if Birth is only relevant to one of them (the Person) then since there’s only one Birth per person, then you may be able to absorb the birth date and place as columns of the Person table. It’s a little more complicated than that, but not much.

This is one reason why semantic modeling works better than traditional ER or UML modeling. It’s possible to make a complete model before making decisions about which things are attributes and which aren’t. It still won’t be your final model, but you’ve postponed some bad decisions so you can make good ones instead.

Because of these rules about when you can absorb things, even small changes or additions to your semantic model will cause changes in which tables you need. The shape of your relational database will always be more prone to change than the original semantic structure. For example, a new requirement might be to link up the Birth to the hospital records management system, to be used in paying the medical staff who assisted. Suddenly the Birth details don’t look very Personal any more - even though they haven’t changed!

But because your semantic model hasn’t changed much, you should be able to get away with making only small changes in your code - assuming you followed through properly! As long as the details of the changed tables are hidden under a semantic layer. But that’s a problem for another time…

In the meantime, restrain yourself making from early assignments concerning attributes, and you’ll find you discover new meanings in the information that embodies the rules of your business.