ER |
An identifier is also called a KEY, or PRIMARY KEY - this is one of the 'key' concepts in all of database theory!! We'll talk much more about keys later.
FYI - here is a page on the various types of attributes.
In Crow's Foot notation, 'bold' attributes are 'required' (can't be null).
Connectivity: 1:1, 1:M or M:N (three diff ways by which two entities are related).
Cardinality: (min,max) for 1:1, 1:M or M:N (eg. 1:1 can have (1,0) as its cardinality, 1:M can have (0,4) as its cardinality). Sometimes, min is called 'modality' (and max is cardinality). The 'inside' symbols denotes min, and the outside ones, max.
Confusingly, the # rows in a table is ALSO called table's cardinality (and, # of columns is called the table's degree).
Also confusingly, 1:1, 1:M, M:N are called 'cardinality ratios'!
Existence independence implies a strong entity; but, existence dependence (alone, ie. by itself) does NOT imply a weak entity (there needs to be one more condition, based on 'relationship strength', for it to become 'weak').
In other words, we need to look at where the FK in the dependent entity is located.
An entity B is "existent dependent" on another entity A, if, a row in B can only exist when its FK is NOT NULL, ie. a corresponding entry exists in A.
Eg. if A is EMPLOYEE and B is DEPENDENT, a dependent (eg. child) in B can only exist if there is a corresponding employee (eg. Dad) in A. THIS ALONE DOES NOT MAKE 'B' A WEAK ENTITY!
Again, it's all about the FK [WHERE it goes], in the dependent entity!
So, here, CLASS is **not** a weak entity.
CLASS is now a weak entity (because: it is existence dependent, AND has a strong relationship).
A weak entity needs to satisfy two conditions: existence dependence, strong (identifying/owning) relationship with a parent.
Note that a weak entity implies existence dependence, but existence dependence does not imply a weak entity!
Note too that a weak entity implies a strong ("owning" or "identifying") relationship.
Removing the controlling (owning) entity's key from a weak entity's PK will result in **duplicates** for remaining PK(s) - THAT is what makes it 'weak'.
Payment cannot exist independent of Loan, AND needs Loan's key to be part of its own key, so it is a weak entity.