When I've modeled databases, I would use a isType
description where you have isA
. You appear to have two types of Specs
; labelSpecs
and itemSpecs
. Common data belongs in Specs
entity, with type specific data in the appropriate subtype record. Normally subtypes are exclusive, so a Spec would be either a labelSpec
or an itemSpec
.
There's nothing in the ERD to constrain the model either way. Without suitable constraints, a child could be recorded as being born before his/her parent, a person could be their own child or parent, and cycles over any number of generations could exist.
For example, assuming the ERD is implemented as:
Person (personId PK, dateOfBirth, name, gender)
ChildOf (personId PK/FK, parentId FK)
we could record the following sets of rows:
Person (1, 2000-11-01, John, Male) ChildOf (1, 2)
Person (2, 1970-05-23, Jane, Female) ChildOf (2, 4)
Person (3, 1985-01-11, Jack, Male) ChildOf (3, 3)
Person (4, 1950-11-01, Joan, Female) ChildOf (4, 1)
There's nothing in the ERD to prevent any constraints either. As it stands, I would have to answer "yes" or "it depends on what unstated constraints you assume or implement" to both questions. If such constraints were required, I would recommend stating them explicitly.
Best Answer
I believe what it's trying to say is because weak entity sets don't have their own primary keys, they are dependent on the strong entity sets that they have a foreign key relationship with (because those related strong entity sets do have primary keys).
So in other words, a tuple in a weak entity set will be partitioned (split up) from other tuples in that same weak entity set by their related strong entity set tuples.
I'm assuming the purpose of weak entity sets is a form of normalization by breaking related fields out of the strong entity set into a separate related set all together (a weak entity set without a primary key).