The Entity-Relationship Model

• An entity is a group of objects with the same properties, which are identified by the enterprise as having an independent existence.
• In part 1 of homework 4,
  • A PATIENT is an entity
  • A DRUG is an entity
  • A PRESCRIPTION is an entity
  • A ROOM might be an entity.
  • An ADMITTANCE might be an entity.
• These seem to be referred to as entity classes or entity types in different books.
• A entity instance or occurrence
  • This is an uniquely identifiable object of an entity type.
  • Bob Smith, Number 100-111 is an instance of a patient.
  • P100 Morphine is an instance of a drug.
• Entities have attributes
  • Attributes are properties of an entity or relationship.
  • Attributes describe the characteristics of an entity.
  • Attributes are simple (composed of a single component)
  • Or composition (composed of multiple components)
• Identifiers are attributes that name, or identify entity instances
  • We have been calling these candidate keys in database terms.
• A relationship is a meaningful association among entity types.
  • A relationship type is a collection of relationship
  • A relationship occurrence is an instance.
  • Relationships can be named
• The degree of a relationship shows the number of entities involved in the relationship.
  • Two is a binary relationship
  • Three is a ternary relationship.
  • We will decompose non-binary relationships into binary relationships.
• The cardinality of a relationship describes how many instances of one entity can participate in the relationship.
  • This is counted for both entity classes involved in the relationship.
  • A cardinality of 1:1 (one to one) means that one instance of each entity
  • For example, a patient has a one to one relationship with a bed
  • A cardinality of 1 to many means (1:N)that one instance of the first entity can be associated with many instances of the second entity
  • For example, A patient may have many prescriptions. (But somehow the prescriptions are unique to a patient)
  • A cardinality of many-to many (N:M) that each entity may be associated with multiples of the other.
  • In our example, the patient drug relationship is many to many
    • A patient may be prescribed many drugs.
    • A drug may be prescribed to many patients.
• Relationships can also be classified as optional or mandatory
  • In our model, A patient must have a bed, but we can have beds without patients. so this is Optional to Mandatory.
  • A patient may or may not have a drug prescribed to them, and a drug may or not be prescribed to a patient.
  • I can't think of a MANDATORY to MANDATORY relationship in our example.
• ER diagrams give us a way to indicate entities and relationships pictorially
  • Entities are drawn as boxes, with the Entity name at the top.
  • 
  • Relationships are indicated by lines.
  • The marks at the end of the lines indicate the maximum cardinality
  • 
  • Here a room may be assigned to many patients, but a patient must be assigned to one room.
  • MANDATORY and Optional are also represented on these lines.
  • 
  • Here a patient MUST be assigned to a room, but a room might not have any assigned patients.
• This is called the crow's foot model.
• Strong and Weak entities
  • A strong entity is an entity that can exist on it's own.
  • A person is a strong entity.
  • A weak entity is an entity that is existence dependent on some other entity
  • A prescription can not exist without out a drug.
  • A prescription can not exist without a person.
• ID-Dependent Entities
  • An entity is ID Dependent if the entity's identifier includes the identifier of another entity.
  • If we added a BED entity to our model.
  • An entity in BED would need both the bed number and the room number.
  • This is an example of an ID-Dependent entity.