Database design including people and organisation

Question

I recently discovered the subtype/supertype method in relational database design and therefore this question: is this a correct design mixed with subtype/supertype design method?

Before I have addressed persons and organisations as two distinct types. I understand that it's a better method to have party a supertype of people and organisation. Now, having that settled, adding adresses and additional_addresses both apply for organisations as well as for persons, thus connecting them to the supertype parties.

Furthermore, different groups of people I need to keep records of, like employees, projectcontacts and suppliercontacts. These are all distinct types of persons, within a party. Is this a correct way of joining the table with persons to accomplish this goal? Same goes for suppliers and debtors, linked to the organisation table, since supplier and debtors are always organisations.

I believe this is a good way of design but I might miss out something with the primary and foreign keys, especially when looking at SupplierContacts. There is a foreign key of partyid which should refer to a person, and also a foreign key of supplierid, but this supplierid also refers to a certain partyid in its own table. Won't this be a ridiculously hard work to be able to query information out of this table and is this design even a proper one?

My main concern is the fact that many tables need to refer to a person ÓR an organisation, and instead of having two foreign keys everywhere, leaving one NULL at all times since I store a record of either a person OR an organisation, now I only have one foreign key: partyid.

Answer 1

The answer relies on the art of designing primary keys.

You have used surrogate identifier as the primary key for parties table (one of the common pitfalls of developers), in the mean time this is not possible to detect a row in parties table is actually a person or organization with out joining to persons or organization tables.
So when ever you use the PK of parties as a FK in other table, that wouldn't be detectable if the party is the desired one, you are loosing business logic, its the side effect of using surrogate key.

Solution: Choose a natural key for parties table.
It would be recommended to have a discriminator column in parties table called party_type (an enumeration, values would be person=1 and organization=2).
The primary key of the parties table could be {party_name + party_type}.
In the aggregation tables like SupplierContacts having a check constraint on {party_type = 1} will solve the problem.

Note that the solution is aimed to solved the problem in database-design level, as an alternative you can extra work in your application level to archive data integrity (less advised yet mostly used by developers !)

Answer 2

I'm not entirely clear on the question you're asking here.

I'm not aware of any database engines that support subtyping natively - they are used for conceptual modeling, and in the physical design they are implemented with whatever the database engine will support.

It may be much more useful to model this as a physical data model - because your decision about primary and foreign keys will almost certainly have to change depending on the way in which you physically represent the sub types.

There are several ways of converting the logical concept of "sub type" to a physical data model - the 3 most common are:

• table per subtype. This means your foreign keys may need to link to multiple tables (e.g. "person" or "organisation"), but your queries/joins are straightforward.
• supertype table with common attributes, separate tables for subtype data (e.g. "party", "person" and "organisation") - in this case your foreign key goes to "party", but to get the subtype data, you have to include the join to the subtype table. This complicates your SQL.
• common table with lots of nullable columns (e.g. "party" with all columns for person and organisation). This makes the foreign key simple - but again, your data access logic gets messy.

To help you evaluate the design, it's worth working through obvious questions like "what's the phone number of supplier x's main contact?", "how many people work on project y?" as SQL queries and see how your schema supports this.