Re: data-modeling question

Syed wrote: > The rules are, an Employee can also be a customer, a supplier can also > be a customer, but a supplier cannot be an Employee and vice versa. The > relationship between super and sub is a ISA relationship. > The reason i use ID as a primary key is to narrow down the search path, > and time taken to retrieve the record as well as to reduce complexity of > unnecessary validation and also to follow the integrity rules and reduce > redundancy. Previously that is before genaralization, there exist 3 > separate tables with all the similar attributes. > Finaly the table Employee only left with ID attribute. Here i would like > to seek advice, should this table exist? how can i find out if a > customer is an employee? should i include another attributes in the > person table to define this? I would base that decision on the nature of your data. If a large percentage of our 'persons' are also employees you may save storage by including an employee flag in the person record. Obviously this is a denormalization. However, if there is a possibility of needing to add employee specific attributes in the future, say department, then the advantage in not having to recode later favors keeping the database normal, as it usually does. Hope that is enough. Unfortunately denormalization decisions are always data specific. Art S. Kagel