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 (0,1) [or (1,0)] as its cardinality, 1:M can have (0,4) [or (4,0)] 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') - we need to look at where the FK in the dependent entity is located, to determine "weak entity-ness".

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!

A weak entity:

• is a dependent one
• has a strong relationship

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.

"All together now!"