0% found this document useful (0 votes)
13 views3 pages

Key Elements of an ER Diagram

Uploaded by

kamleshkc191
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views3 pages

Key Elements of an ER Diagram

Uploaded by

kamleshkc191
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Key Elements of an ER Diagram

1. Entity Sets

o Definition: An entity set represents a group of similar objects or concepts in the real
world. These objects have similar attributes, and the collection of entities is known
as an entity set.

o Example: Think of a "Customer" entity set in a retail database. Each individual


customer (like Alice, Bob, or Carol) is an entity, and all these customer entities
together form the "Customer" entity set.

o Representation: In ER diagrams, entity sets are represented by rectangles, labelled


with the entity set’s name (e.g., "Customer").

o Use in Database Structure: Each entity set typically becomes a table in a relational
database. For instance, the "Customer" entity set translates to a "Customer" table,
where each row in the table represents a different customer.

2. Attributes

o Definition: Attributes are properties or characteristics that describe an entity. Every


entity within an entity set will have these attributes with unique values per entity.

o Types of Attributes:

 Simple: Atomic attributes that cannot be divided further, such as "Age" or


"ID."

 Composite: Attributes that can be broken down into sub-attributes. For


example, an address can be divided into "Street," "City," and "ZIP Code."

 Derived: Attributes calculated from other attributes, such as "Age" derived


from "Date of Birth."

 Multi-valued: Attributes that can hold multiple values, such as "Phone


Numbers" where a person might have multiple contact numbers.

o Representation: In ER diagrams, attributes are depicted as ovals connected to the


corresponding entity set.

o Use in Database Structure: Attributes become the columns of the table representing
the entity set. For instance, the "Customer" entity set might have attributes like
"CustomerID," "Name," and "Address," which translate to columns in the
"Customer" table.

3. Relationships

o Definition: Relationships define how entities interact or associate with each other.
They establish logical connections between entity sets.

o Types of Relationships:

 Unary (Recursive): A relationship where an entity is related to itself. For


example, an employee might "supervise" another employee.
 Binary: A relationship between two different entity sets, like a "Customer"
placing an "Order."

 Ternary and Higher-order: Relationships involving three or more entity sets.


For example, a relationship among "Doctor," "Patient," and "Medication"
could represent a prescription.

o Representation: In ER diagrams, relationships are shown as diamonds connecting


the involved entity sets. The name of the relationship, like "Enrolled In" or "Placed,"
is written inside the diamond.

o Use in Database Structure: Relationships become the foreign keys in the database
schema. For instance, if a "Customer" places an "Order," the "Order" table might
have a "CustomerID" column (foreign key) to link to the "Customer" table.

4. Cardinality Constraints

o Definition: Cardinality specifies the number of instances of one entity that can or
must be associated with instances of another entity in a relationship.

o Types of Cardinality:

 One-to-One (1:1): One entity instance is associated with one instance of


another entity. Example: each "Passport" is linked to one "Person."

 One-to-Many (1:M): One entity instance can relate to multiple instances of


another entity. Example: a single "Customer" can place multiple "Orders."

 Many-to-One (M:1): Many instances of an entity can relate to a single


instance of another entity. Example: multiple "Orders" can be linked to one
"Store."

 Many-to-Many (M:N): Instances of both entities can be associated in


multiple ways. Example: "Students" enrolling in multiple "Courses" and
"Courses" having multiple "Students."

o Representation: Cardinality constraints are often shown in ER diagrams by placing


symbols like 1, N, or M near the entity sets in a relationship.

o Use in Database Structure: Cardinality determines table structure and relationships,


such as the need for a join table in many-to-many relationships. For example,
"Student" and "Course" entity sets would require an intermediate table, say
"Enrolment," to manage the many-to-many relationship.

5. Primary Keys and Foreign Keys

o Primary Keys:

 A primary key uniquely identifies each entity instance within an entity set,
ensuring there is no duplicate data in the table. For instance, "CustomerID"
might uniquely identify each customer in the "Customer" entity set.

o Foreign Keys:
 Foreign keys are attributes in one table that refer to the primary key of
another table, establishing a link between the two tables.

o Use in Database Structure: Primary keys and foreign keys enforce the structure
created by relationships. They maintain data integrity by defining how data in
different tables connects, making sure that a customer’s order references a valid
"CustomerID," for example.

How Entity Sets and Relationships Shape the Database Structure

 Entity Sets → Database Tables: Each entity set is typically transformed into a table in the
database. This process of translating the ER diagram into a relational schema result in tables
for each entity set, with columns representing attributes.

 Relationships → Table Connections: Relationships define the ways in which these tables
interact. Through foreign keys, the database establishes these connections, allowing data
from different tables to be linked and queried together.

 Normalization: Using ER diagrams encourages a normalized design, meaning data is


organized efficiently, redundantly minimized, and relationships clearly defined. For example,
if "Customer" and "Order" are separate entity sets with a one-to-many relationship, they
become separate tables where "Order" references "Customer" by a foreign key, reducing
duplicate customer information across orders.

ER diagrams thus serve as blueprints for database construction. They ensure that each entity is
clearly represented, all attributes are properly defined, and relationships are logically organized—
resulting in a relational schema that is efficient, organized, and maintains data integrity.

You might also like