There are two concepts that are essential to any business software: what is being done; and who is doing it (a third concept is who or what something is being done to, with, or for). Before we can talk about anything else, we need to talk about people and how they fit into our system. People are so important to a model, they receive their own archetype in Peter Coad’s Color Modeling approach (well they share it with Organizations, Places, and Things but as we’ll see, they are conceptually interchangeable, because they are part of who is doing or who/what something is being done to, with, or for).
So how do you define a person? A Person entity has a Name (for the purpose of the series all entities are assumed to have an Id unless I state otherwise), and really that’s it. That’s all we have defined on our Person entity. Actually, some optional fields would include birthdate, Social Security Number (for the US, if you’re modeling a non-American person, SSN doesn’t apply). But in reality, I don’t think SSN belongs on a generic person model. There are only a few cases where you want to capture the SSN (for example in Human Resource/HCM applications), but as mentioned even in those cases, it’s not universally applicable. So our person entity ends up looking rather simple:
“Wait that’s it?” you ask. What about an address, a phone number, email address, SSN, phone number? What about all the information I need to gather for my customers, employees, and contractors? That’s a good question, or three actually. First and foremost, this is a conceptual model. What that that means is we’re going to break down these entities to their most basic components. Some times it will be prudent to simplify the models for the sake of performance (better queries, etc), I will leave that decision to you, the implementer. It’s best to be aware these raw elements exist so that should the need arise, you can extract them from a simplified model.
Before we go on to discuss the information that we might collect for a Person. Let’s look at the related Organization entity which can be a Legal Organization (such as a Company, Church, or School) or an Informal Organization like a Family, a Team or a Division in a Company. Again, take what you need, we’re doing a full tour for awareness.
Again the organization is spartan, containing only a name. Why don’t we add again address and other contact information to it? For simple models, it probably makes sense. But even for something as simple as a contact manager application, we’ll want to store multiple addresses and other forms of contact for a given person or organization. In order to simplify our model, because sometimes our system doesn’t want to differentiate between a Person and an Organization, we’ll add a common ancestor to both: the Party.
So back to the additional information we may want about a Party like the Address. Why not store it on the Party itself? Well like I said, what if we want to store more than one address? Or more than two? What if different addresses associated with a Party serve different purposes? For example as a Customer, I might have a Billing Address and a Shipping Address. But what if I want to sometimes send a Shipment to work? How does all of that work together? I have no less than 10 addresses stored in my account with an online retailer. Do I use them all on a regular basis? No, but I’m glad that they’re available when I need them.
What I’m getting at is rather than making an address an attribute on the Person entity (or even on the appropriate role), the Address should be a separate entity in and of itself. Len Silverston, David Hay, and Peter Coad all agree. Silverston and Hay cover these models pretty early. Coad talks about it pretty late in his book.
This model may seem overkill for getting a number for a given person. Like I said, you might want to elide some of the relations and entities for your model, but having more detail for clarity’s sake will allow you to simplify as needed. This model is the tip of the iceberg for the final model for Addresses in Silverston’s book, which goes into breaking down a postal address into a hierarchy of Geographic Regions. For most purposes if your storage mechanism supports GIS data structures, it will be simpler to leverage that than modeling the individual political and geographic hierarchies.
This has been a lot to consume (and share) for our first session. Look for Part 2 coming soon.