DBMS Second Chapter
DBMS Second Chapter
Entities
An entity is an object that has existence and is distinguishable from other objects
Physical existence
Person, car, employee etc.
Conceptual existence
Company, job, university course
An entity lies within the scope of the business world being modelled.
Each entity has attributes – the particular properties that describe it.
Attributes
Attributes are properties used to describe an entity.
For example an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate
A specific entity will have a value for each of its attributes.
For example a specific employee entity may have Name=‘Ram', SSN='123456789',
Address ='731, RR Nagar, Bangalore, Karnataka', Sex='M', BirthDate='09-JAN-65‘
Each attribute has a data type associated with it e.g. integer, string, date etc.
Each attribute must have a unique name across the entity.
Types of Attributes
Simple
o Each entity has a single atomic value for the attribute. For example, SSN or Sex.
Composite
o The attribute may be composed of several components.
o The value of a composite attribute is the concatenation of the values of its simple
attributes.
o Composition may form a hierarchy where some components are themselves
composite.
o If components of the composite attributes have to be referred, it is necessary to store
the components separately.
o If composite attribute is referred only as a whole, there is no need to subdivide it into
component attributes e.g. if address has to be referred as a whole only, there is no
need to divide it.
Composite attributes (Example)
For example, Address (Apt#, House#, Street, City, State, ZipCode, Country)
Name (FirstName, MiddleName, LastName).
Single-valued
Only single value for a particular entity e.g. age
Multi-valued
An entity may have multiple values for that attribute.
Multiple value may have lower and upper bounds on the number of values.
For example,
Color of a CAR: {Color}
phone_numbers: {phone number}
Stored attributes
Stored in the database
Derived attributes
Can be computed from other related attributes
E.g. Birthdate ---stored
Age ----derived
Null values
A particular entity may not have the value for a particular attribute
o Value is not applicable
o Value is unknown
A special value NULL is written
e.g. Every employee may not have Fax no.
Complex attributes
o Composite attributes can be nested arbitrarily.
o Components of a composite attribute can be shown in () and multivalued attribute can be
shown in {}.
For example:
{Address_phone ({phone (Area_code, phone_number)}, Address (Street_Address (Number,
Street, Apartment_No), City, State, Zip))}
Entity Type
An entity type defines a collection of entities that have the same attributes
Each entity if defined in database by its name and attributes.
Each entity type must have a name that is unique across the entire model and has a
consistent meaning across the modelling team and the end users.
For example,
EMPLOYEE is an entity type
PROJECT is an entity type.
Entity set
The collection of all entities of a particular entity type in the database at any point of time
is called an entity set.
The entity set is usually referred to using the same name as the entity type.
For example,
EMPLOYEE refers to both
o ‘type of entity’
o ‘set of entity (Employee type)’
Notations
Entity type by rectangular box enclosing the entity type name
Attributes by ovals attached to entity type by straight line
Composite attributes shown by attaching components to it
Multivalued by double oval
Example
Relationships
A relationship is an association among two or more entities.
Whenever an attribute of one entity type refers to the attribute of another entity type, some
relationship exists.
Specifically a relationship relates two or more distinct entities with a specific meaning
o For example, manager of the DEPARTMENT refers to an employee who manages
the department.
o Department of EMPLOYEE refers to the department for which the employee works.
Relationships Type
Relationships of the same type are grouped or typed into a relationship type.
o For example, the WORKS_FOR relationship type in which EMPLOYEEs and
DEPARTMENTs entities participate,
o or The MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs
entities participate.
More than one relationship type can exist with the same participating entity types.
o For example, MANAGES and WORKS_FOR are distinct relationships between
EMPLOYEE and DEPARTMENT, but with different meanings and different
relationship instances.
Relationships Set
A relationships set is a set of relationships of the same type.
A relationship set and a relation type are referred to by the same name.
The relationship set R is a set of relationship instances r i, where each ri associates n
individual entities (e1, e2, ….., en), and each entity ej in ri is a member of entity type Ej,
1≤ j ≤ n
E.g. each employee and department participates in the relationship of works_for.
Some instances in the WORKS_FOR relationship set, which represents a relationship type
WORKS_FOR between Employee and department
Recursive relationship
In some cases, same entity participates more than once in a relationship type and plays
different roles.
In such cases, role names become necessary for distinguishing the meaning of each
participation
Such relationship types are called Recursive relationship.
Example
Constraints on Relationships
Structural Constraints on Relationship Types (Also known as ratio constraints) are
determined from the mini-world situation.
o Maximum Cardinality (or cardinality ratio)
o Minimum Cardinality (also called participation constraint or existence dependency
constraints)
Total Participation
Total Participation is a constraint when every entity in the entity set participates in at least
one relationship in the relationship set.
Total Participation is also called existence dependency.
Shown by double lining the link
For example
o Every employee must work in some department
o Every employee must work on some project
Partial Participation
Partial participation is the constraint when some entities may not participate in any
relationship in the relationship set.
Represented by single line link.
Example: participation of ‘EMPLOYEE’ as manager in relationship type ‘MANAGES’ is
partial
Three binary 1:N relationships relate SUPPLY to the three participating entity types.
A surrogate key “Supply_id” can also be introduced to convert weak entity as regular entity
Choosing between Binary and Ternary (or higher-degree) Relationships
End of chapter 2