A lot of developers will work on software that is doing some administrative tasks. And each and every developer will have to come up with a data model (or object model) which would contain everything they need. And most of the time, they will choose a model that solves their own specific situation but which is hard to change if something new is required. And that’s because developers are too busy looking for details and thus they won’t see the general image.

The general image is that you basically deal with just four kinds of data. No matter if you’re building a web-shop, in-house banking solution, patient record administration or complex financial applications, you always have just four kinds of data: items, relations, transactions and contracts. So let’s take a closer look at these data entities…

Items

Items are just what the name suggests. It’s something physical in general, although electronic data and other things could also be considered items. Persons are items. A complete household is an item. Companies are items, so are products. Animals are items. Phones are items. And most importantly, money is an item. Items are the things you’re going to administer.

Items can be unique. For example, a person is unique. But when you just keep track of the number of employees without looking at the individual, then you basically have an infinite amount. The same with money since each coin is unique, but your bank account can technically hold quite a lot of those coins. Or none at all. Basically, you could subdivide items into two parts: singular and plural items. But this is just a special property for the Item entity. You could add a field called “IsPlural” to the entity or create two child classes that you derive from the Item object. (SingularItem and PluralItem.)

Relations

Relationships are what connects two items with one another. And there can be quite a lot of relations. A person has a father and mother and most have four grandparents, although some might not be alive anymore. Many people also have children. Other relationships could be a bank account that’s owned by a person, a certain amount of money in this bank account and you could also think of the relationships between an employee and his employer.

Relationships can be very complex but keep in mind that there are just two sides on any relationship. examples: I have 10 dollars. Mary-Anne works for McDonalds. This envelope contains a letter. By keeping it simple, the data model stays simple, although you might need multiple relationships to describe certain situation, like employment, your bank account or perhaps even your mortgage.

Contract

This is where you will need a contract, although that might sound a bit of strange when talking about family relations. Basically, it’s just something that will connect items to other items through relations. And, often enough, the word matches the collection of relations just fine. For example, when you work for an employer you will deal with several different relations. First of all, the direct relation between employer and employee. But also the relations between employee and salary, plus employer to salary. But also you and your colleagues will be related, although that would be implied because the generic relation between employees and employer. And of course there’s a relation between you and the office where you work, you and the desk that you work on, or the computer that you use at work. There are plenty of relations that you can define but in general, stick to just those relations that matter.

Contracts not only maintain relationships but in general will contain some logic to change those relations or that are related to specific actions that need to be taken to maintain the relationship.

Transactions

However, there’s one more thing we have to be aware of. And that’s time. And time changes things. People might have a divorce, lose their job or easier: spend money. In the employment example, there are many transactions to think of. Salary happens to be a regular transaction where the employee receives an amount of money. The employer will have to spend this, and the tax office will also have a small claim on the amount the employer pays out. Again, just focus on the transactions that are considered important within your solution.

In general, there are two kinds of transactions. One that creates a relationship and one that breaks it. But a transaction also occurs on a certain moment in time, be it the past or the future. And often the connection between items will require multiple transaction to describe a complete situation. We have the employer who loses a certain amount to pay salaries. We have the tax office (and other offices) that will receive money related to the salary. And the employee will receive an amount related to the salary. And these relations are linked to a contract. The same contract that defined the relations between the items.

Transactions don’t have to involve money, although they often do. But if you buy a steak at the local butcher, you not only have two transactions for you losing money and the butcher earning money (who will lose some again for VAT) but there’s also the transaction of the butcher losing a steak and you gaining a steak.

Conclusion

When you’re doing the financial administration for a company, you will deal automatically with items, contracts, relations and transaction, even though you might not realize it. When you’re building software for a library to keep track of book loans, you also have a similar setup, where transactions determine who is lending which book and when it’s expected to be returned.

Even when you’re baking a cake, you could apply this data model. All ingredients and utensils would be items. The recipe would be the contract. The relations are basically simple since the item is either an ingredient of the final cake, it it is used to bake the cake. And the transactions are just describing how you should put the ingredients into a bowl, mix them, fill the pan, put the pan in the oven, remove it from the oven, remove the cake from the pan, add ingredients to give cake some color and additional taste and then use a knife to slice the cake and eat it. Each of those steps should be taken at a specific moment in time and the transactions will specify when it’s time.

It is a strange example but it shows how flexible the data model actually is. So look at your own projects and see if you can recognize these entities that I’ve just described. Most software will have entities with multiple functions, where e.g. a Person record contains a link to parent records or child records. Or links to employer, bank accounts or whatever else. In general, such constructions would severely limit your options. And although a person won’t have more than two parents in general, a person could have two or more employers. So sad if your system can only handle one employer…

And while you don’t have to use this data model for your own solution, altering your data model to match this one will improve the flexibility of your whole design.