Unit-2

DATA MODELING

• Entity Relationship Model : Types of

Attributes, Relationship, Structural Constraints
–
• Relational Model: Relational model
Constraints –
• Mapping ER model to a relational schema
• Integrity constraints
 Overview of Database Design Process

• Two main activities:

– Database design
– Applications design
• Database design
– To design the conceptual schema for a database
application
• Applications design focuses on the programs
and interfaces that access the database
– Generally considered part of software engineering

Slide 3- 2
 Overview of Database Design Process

Slide 3- 4
• Courtesy- https://www.youtube.com/watch?v=9jc3lt_kekY
 ER Model Concepts
• Entities
• Entities are specific objects or things in the mini-world that are represented in
the database.

• Attributes
– Attributes are properties used to describe an entity.

• Relationships
– Relationship is an association among two or more entities.

Slide 3- 7
 Entity Relationship Model

• Courtesy- https://www.guru99.com/er-diagram-tutorial-dbms.html
Characteristics of an Entity
 Types of Attributes
• Simple Attributes
• Composite Attributes
• Single valued Attributes
• Multivalued Attributes
• Derived Attributes
• Key Attributes
 Composite Attributes
• Composite
– The attribute may be composed of several components. For
example:
• Address(Apt#, House#, Street, City, State, ZipCode, Country), or
• Name(FirstName, MiddleName, LastName).
• Composition may form a hierarchy where some components are
themselves composite.
 Single Valued Attributes

• Single valued attributes are those attributes

which can take only one value for a given
entity from an entity set.
 Multi Valued Attributes-

• Multi valued attributes are those attributes

which can take more than one value for a
given entity from an entity set.
 5. Derived Attributes-

• Derived attributes are those attributes which

can be derived from other attribute(s).
 6. Key Attributes-

• Key attributes are those attributes which can

identify an entity uniquely in an entity set.
• It may be composite.
Notations for ER Diagram
Relationship in ER Model
 Example COMPANY Database
• We need to create a database schema design
based on the following (simplified)
requirements of the COMPANY Database:
– The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We
keep track of the start date of the department
manager. A department may have several
locations.
– Each department controls a number of PROJECTs.
Each project has a unique name, unique number
and is located at a single location.
Slide 3- 37
 Example COMPANY Database (Contd.)
– We store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate.
• Each employee works for one department but may
work on several projects.
• We keep track of the number of hours per week that an
employee currently works on each project.
• We also keep track of the direct supervisor of each
employee.
– Each employee may have a number of
DEPENDENTs.
• For each dependent, we keep track of their name, sex,
birthdate, and relationship to the employee.

Slide 3- 38
 Refining the COMPANY database schema by
introducing relationships
• By examining the requirements, six relationship types are
identified
• All are binary relationships( degree 2)
• Listed below with their participating entity types:
– WORKS_FOR (between EMPLOYEE, DEPARTMENT)
– MANAGES (also between EMPLOYEE, DEPARTMENT)
– CONTROLS (between DEPARTMENT, PROJECT)
– WORKS_ON (between EMPLOYEE, PROJECT)
– SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE
(as supervisor))
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

Slide 3- 39
 ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Slide 3- 40
 Discussion on Relationship Types
• In the refined design, some attributes from the initial entity
types are refined into relationships:
– Manager of DEPARTMENT -> MANAGES
– Works_on of EMPLOYEE -> WORKS_ON
– Department of EMPLOYEE -> WORKS_FOR
– etc
• In general, more than one relationship type can exist between
the same participating entity types
– MANAGES and WORKS_FOR are distinct relationship types
between EMPLOYEE and DEPARTMENT
– Different meanings and different relationship instances.

Slide 3- 41
 Recursive Relationship Type
• An relationship type whose with the same participating entity
type in distinct roles
• Example: the SUPERVISION relationship
• EMPLOYEE participates twice in two distinct roles:
– supervisor (or boss) role
– supervisee (or subordinate) role
• Each relationship instance relates two distinct EMPLOYEE
entities:
– One employee in supervisor role
– One employee in supervisee role

Slide 3- 42
 Weak Entity Types
• An entity that does not have a key attribute
• A weak entity must participate in an identifying relationship type with an
owner or identifying entity type
• Entities are identified by the combination of:
– A partial key of the weak entity type
– The particular entity they are related to in the identifying entity type
• Example:
– A DEPENDENT entity is identified by the dependent’s first name, and
the specific EMPLOYEE with whom the dependent is related
– Name of DEPENDENT is the partial key
– DEPENDENT is a weak entity type
– EMPLOYEE is its identifying entity type via the identifying relationship
type DEPENDENT_OF

Slide 3- 43
 Constraints on Relationships
• Constraints on Relationship Types
– (Also known as ratio constraints)
– Cardinality Ratio (specifies maximum participation)
• One-to-one (1:1)
• One-to-many (1:N) or Many-to-one (N:1)
• Many-to-many (M:N)
– Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)
• zero (optional participation, not existence-dependent)
• one or more (mandatory participation, existence-dependent)

Slide 3- 44
 Alternative (min, max) notation for
relationship structural constraints:
• Specified on each participation of an entity type E in a relationship type R
• Specifies that each entity e in E participates in at least min and at most
max relationship instances in R
• Default(no constraint): min=0, max=n (signifying no limit)
• Derived from the knowledge of mini-world constraints
• Examples:
– A department has exactly one manager and an employee can manage
at most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in MANAGES
– An employee can work for exactly one department but a department
can have any number of employees.
• Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
• Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

Slide 3- 45
 The (min,max) notation for
relationship constraints

Read the min,max numbers next to the entity type and looking
away from the entity type

Slide 3- 46
 COMPANY ER Schema Diagram using (min, max)
notation

Slide 3- 47
 Informal Definitions-Relation

• Informally, a relation looks like a table of values.

• A relation typically contains a set of rows.

• The data elements in each row represent certain facts that

correspond to a real-world entity or relationship
– In the formal model, rows are called tuples

• Each column has a column header that gives an indication of the

meaning of the data items in that column
– In the formal model, the column header is called an attribute
name (or just attribute)

Slide 5- 48
 Example of a Relation

Slide 5- 49
 Informal Definitions
• Key of a Relation:
– Each row has a value of a data item (or set of items) that
uniquely identifies that row in the table
• Called the key
– In the STUDENT table, SSN is the key

Slide 5- 50
 Formal Definitions - Schema
• The Schema (or description) of a Relation:
– Denoted by R(A1, A2, .....An)
– R is the name of the relation
– The attributes of the relation are A1, A2, ..., An
• Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)
– CUSTOMER is the relation name
– Defined over the four attributes: Cust-id, Cust-name, Address,
Phone#
• Each attribute has a domain or a set of valid values.
– For example, the domain of Cust-id is 6 digit numbers.

Slide 5- 51
 Formal Definitions - Tuple
• A tuple is an ordered set of values (enclosed in angled
brackets ‘< … >’)
• Each value is derived from an appropriate domain.
• A row in the CUSTOMER relation is a 4-tuple and would
consist of four values, for example:
– <632895, "John Smith", "101 Main St. Atlanta, GA 30332",
"(404) 894-2000">
– This is called a 4-tuple as it has 4 values
– A tuple (row) in the CUSTOMER relation.
• A relation is a set of such tuples (rows)

Slide 5- 52
 Definition Summary
Informal Terms Formal Terms
Table Relation
Column Header Attribute
All possible Column Domain
Values
Row Tuple

Table Definition Schema of a Relation

Populated Table State of the Relation
Slide 5- 53
 Example – A relation STUDENT

Slide 5- 54
 Relational Integrity Constraints
• Constraints are conditions that must hold on all valid relation
states.
• There are three main types of constraints in the relational
model:
– Key constraints
– Entity integrity constraints
– Referential integrity constraints
• Another implicit constraint is the domain constraint
– Every value in a tuple must be from the domain of its attribute
(or it could be null, if allowed for that attribute)

Slide 5- 55