• It's great to see some attention to conceptual/logical modeling from the SQL Server community. In my experience, DB practioners with that persuasion tend to jump right to table design, skipping some formative processes.

    I was especially interested in the presentation about unification (referred to as "overlapping foreign keys" in the article). Proper unification is a very important--and often overlooked--aspect of designing a logical model that enforces the business rules.

    I like your example because the unification issue is apparent at the logical modeling stage. More often, it does not crop up until surrogate keys are introduced during physical design.

    But, I do have an observation/question (not quite sure which) about which I hope some discussion will ensue.

    It has to do with the need for superkeys to the Vets and Pets entities in order to support the foreign keys. In other words, we have a situation where the primary key is not sufficient to support the business rules. Why? Superkeys are introduced to overcome that shortcoming. I understand the work around, but it seems to me to be exactly that. I can't help but think the logical design is flawed in some way that leads us to that point.

    I want to think about design alternatives a bit before I comment further, but maybe someone else as something to contribute.