Interactive Data Transforming | Lecture 2
Entity-Relationship Model is a detailed, logical representation of the data for an
organization/business. It’s a way to visualize and design the structure of a database. It’s expressed in
terms of the following concepts:
1. Entities
Entity type
Collection of entities that share common properties or characteristics. For example,
“Car” could be an entity type. It represents all cars in general.
Entity instance
A person, place, object, event, concept. For example, “A red Toyota Corolla with
license plate ABC123”. This is a specific car that belongs to the broader category of
“Car”.
An Entity should be
- An object that will have many instances in the database. For example, if you have an
entity called “Student” the database will have many individual students, each as a
separate instance
- An object that will be composed of multiple attributes. For example, a “Student” entity
might have attributes like “Name, Student, ID, Date of Birth and Email”.
- An object that we are trying to model. For example, if you’re building a database for a
school, “Student”, “Course”, and “Teacher” are all entities that you want to model.
Guidelines for Naming Entity Types
- Singular noun, specific to organization, concise of abbreviation Customer instead of
Customers or Order instead of Ord. This helps keep things clear and consistent.
- For event entities, the result not the process. Use Order Placed instead of Placing Order
- Name consistent for all diagrams Use the same names for entity types throughout all
your diagrams to avoid confusion and ensure clarity.
Strong Entity VS Weak Entity
Strong Entity
Exists independently: A strong entity can stand alone. It doesn’t need any other
entity to exist. For example, a “Car” can exist by itself in a database.
Unique identifier: It has something unique that identifies it, like a car’s VIN (Vehicle
Identification Number
, Weak Entity
Depends on a strong entity: A weak entity can’t exist by itself. It relies on a strong
entity to make sense. For example, a “Car Insurance Policy” might depend on a
specific car to exist. Without the car, the insurance policy doesn’t make sense.
No unique identifier: It doesn’t have a completely unique identifier on its own. It
usually has a partial identifier, like a policy number, but that number might not be
unique without the context of the car it’s related to.
Entity box and partial identifier have double lines Suppose you have a strong entity
called Customer and a weak entity called Order. The Order entity might have a partial
identifier like OrderID. An order is dependent on a customer. Instead, you can
combine OrderID with CustomerID to create a composite key. The weak entity in the
ER diagram will have double lines, and the partial identifier will be underlined with
double lines as well.
2. Attributes:
These are the details about each entity. For a “Student” entity, attributes could be “Name, ID
Number, and Data of Birth.”
Properties of an entity or relationship type.
Required versus Optional
Required Must have a value for every entity (or relationship) instance with which it is
associated In a Customer entity, CustomerID might be a required attribute because every
customer must have an ID
Optional May not have a value for every entity (or relationship) instance with which it is
associated. In a Customer entity, MiddleName might be an optional attribute because not
every customer has to provide a middle name
Composite versus Simple
Composite Below you see a composite attribute. It’s an attribute that has meaningful
component parts (sub-attributes). It’s the attribute that you can break down into smaller,
more specific parts. In this case, Address is the composite attribute and the street address
etc. are the component attributes.
