1

Let's say that a "person" can be a "client" OR a "supplier". Using EER we could have something like this:

enter image description here

The problem with this solution is that a person can be BOTH a client and a supplier. Is there a way to restrict a "person" for just one specialization?

Caio
  • 3,178
  • 6
  • 37
  • 52
  • 1
    Both **exclusivity** (which is what you asked) and **presence** of child rows [can be declaratively enforced](http://stackoverflow.com/a/12261722/533120). But enforcing it in the application logic (e.g. in stored procedures or middle tier) may turn-out to be a lesser evil. Usually, declarative constraints should be preferred, but this particular case may be one of few exceptions. – Branko Dimitrijevic Aug 14 '14 at 14:03
  • Why didn't you use the diagramming symbol for specialization that EER adds to the mix? – Walter Mitty Aug 14 '14 at 19:10

2 Answers2

1

You can add a new table which will contain the person.ID, the type of the person (client or supplier) and the ID from the corresponding table.

This will allow you further filtering and selecting the clients by type later on the project if needed from Business point of view.

Atanas Desev
  • 858
  • 5
  • 13
0

And it is not a realistic business scenario that the same Person can indeed be both supplier and customer ?

Incidentally, the cardinality indicators in the model as you have shown it here ******actively require***** each Person to be a Customer ******as well as******* a supplier !!!

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52