Database Reference
In-Depth Information
•
Each Employee may manage one or many Employees.
•
Each Employee may be managed by one or many Employees.
Using sample values such as
Bob
and
Jill
and sketching a hierarchy or network can really
help you to understand, and therefore validate, cardinality. The one-to-many captures a
hierarchy where each employee has at most one manager. The many-to-many captures a
network in which each employee may have one or many managers such as
Jane
working
for
Bob
,
Ken
, and
Sven
. (I would definitely update my resume if I were
Jane
.)
It is interesting to note that in both figures, there is optionality on both sides of the rela-
tionship. In these examples, it implies we can have an
Employee
who has no boss (such as
Mary
) and an
Employee
who is not a manager (such as
Jane
).
Data modelers have a love-hate relationship with recursion. On the one hand, recursion
makes modeling a complex business idea very easy and leads to a very flexible modeling
structure. We can have any number of levels in an organization hierarchy on both of these
models, for example. On the other hand, some consider using recursion to be taking the
easy way out of a difficult modeling situation. There are many rules that can be obscured
by recursion. For example, where is the
Regional Management Level
on these models? It is
hidden somewhere in the recursive relationship. Those in favor of recursion argue that you
may not be aware of all the rules and that recursion protects you from having an incomplete
model. The recursion adds a level of flexibility that ensures that any rules not previously
considered are also handled by the model. It is therefore wise to consider recursion on a
case-by-case basis, weighing obscurity against flexibility.
