Lecture-02

Introduction –Data Models

Instances and Schemas

n Similar to types and variables in programming languages

n Schema – the logical structure of the database

l Example: The database consists of information about a set of customers and

accounts and the relationship between them

l Analogous to type information of a variable in a program

l Physical schema: database design at the physical level

l Logical schema: database design at the logical level

n Instance – the actual content of the database at a particular point in time

l Analogous to the value of a variable

n Physical Data Independence – the ability to modify the physical schema without
changing the logical schema

l Applications depend on the logical schema

l In general, the interfaces between the various levels and components should be
well defined so that changes in some parts do not seriously influence others.

Data Manipulation Language (DML)

n Language for accessing and manipulating the data organized by the appropriate data
model

l DML also known as query language

n Two classes of languages

 l Procedural – user specifies what data is required and how to get those data

l Declarative (nonprocedural) – user specifies what data is required without

specifying how to get those data

n SQL is the most widely used query language

Data Definition Language (DDL)

n Specification notation for defining the database schema

Example: create table instructor (

ID char(5),
name varchar(20),
dept_name varchar(20),
salary numeric(8,2))

n DDL compiler generates a set of table templates stored in a data dictionary

n Data dictionary contains metadata (i.e., data about data)

l Database schema

l Integrity constraints

 Primary key (ID uniquely identifies instructors)

 Referential integrity (references constraint in SQL)

– e.g. dept_name value in any instructor tuple must appear in

department relation
l Authorization

SQL
n SQL: widely used non-procedural language

l Example: Find the name of the instructor with ID 22222

select name
from instructor
where instructor.ID = ‘22222’

l Example: Find the ID and building of instructors in the Physics dept.

l select instructor.ID, department.building

from instructor, department
where instructor.dept_name = department.dept_name and
 department.dept_name = ‘Physics’

l Application programs generally access databases through one of

l Language extensions to allow embedded SQL
l Application program interface (e.g., ODBC/JDBC) which allow SQL queries to
be sent to a database

The Entity-Relationship Model

n Models an enterprise as a collection of entities and relationships

l Entity: a “thing” or “object” in the enterprise that is distinguishable from other

objects

 Described by a set of attributes

l Relationship: an association among several entities

Represented diagrammatically by an entity-relationship diagram

Relational Model
n Relational model

n Example of tabular data in the relational model

A Sample Relational Database
Chapter 2: Entity-Relationship
Model

n Entity Sets
n Relationship Sets
n Mapping Constraints
n Keys
n E-R Diagram
n Extended E-R Features
n Design of an E-R Database Schema
n Reduction of an E-R Schema to
Tables

Entity Sets
n A database can be modeled as:

l a collection of entities,

l relationship among entities.

n An entity is an object that exists and is distinguishable from other objects.

Example: specific person, company, event, plant

n Entities have attributes

Example: people have names and addresses

n An entity set is a set of entities of the same type that share the same properties.
 Example: set of all persons, companies, trees, holidays

Entity Sets customer and loan

customer- id customer- name customer- street customer- city number
loan- amount

Attributes
n An entity is represented by a set of attributes, that is descriptive properties possessed
by all members of an entity set.

Example:

customer = (customer-id, customer-name, customer-street, customer-city)

loan = (loan-number, amount)
n Domain – the set of permitted values for each attribute
n Attribute types:

l Simple and composite attributes.

l Single-valued and multi-valued attributes
 E.g. multivalued attribute: phone-numbers

l Derived attributes
 Can be computed from other attributes
  E.g. age, given date of birth

Composite Attributes

Relationship Sets
n A relationship is an association among several entities
Example:
Hayes depositor A-102
customer entity relationship set account entity
n A relationship set is a mathematical relation among n  2 entities, each taken from
entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}

where (e1, e2, …, en) is a relationship

l Example:

(Hayes, A-102)  depositor

Relationship Set borrower

n An attribute can also be property of a relationship set.

n For instance, the depositor relationship set between entity sets customer and account
may have the attribute access-date
Degree of a Relationship Set
n Refers to number of entity sets that participate in a relationship set.

n Relationship sets that involve two entity sets are binary (or degree two). Generally,
most relationship sets in a database system are binary.

n Relationship sets may involve more than two entity sets.

l E.g. Suppose employees of a bank may have jobs (responsibilities) at multiple

branches, with different jobs at different branches. Then there is a ternary
relationship set between entity sets employee, job and branch

n Relationships between more than two entity sets are rare. Most relationships are
binary. (More on this later.)

E-R Diagrams

Rectangles represent entity sets.

Diamonds represent relationship sets.

Lines link attributes to entity sets and entity sets to relationship sets.

Ellipses represent attributes

n Double ellipses represent multivalued attributes.

n Dashed ellipses denote derived attributes.

Underline indicates primary key attributes

Design of an ER Database Schema

❑ Symbols used in the ER diagram

Entity Set
Many to many

Relationship Set
Many to one

Attribute One to many

Derived Attribute One to one

Multi-valued Attribute Weak Entity Set

Primary Key

Total Participation
Partial Key
E-R Diagram with Composite, Multivalued,
and Derived Attributes

Mapping Cardinalities
n Express the number of entities to which another entity can be associated via a
relationship set.

n Most useful in describing binary relationship sets.

n For a binary relationship set the mapping cardinality must be one of the following types:

l One to one

l One to many

l Many to one

l Many to many
Mapping Cardinalities

One to one
One to many

Note: Some elements in A and B may not be mapped to any elements in the other set.

Mapping Cardinalities
Many to one Many to many

Note: Some elements in A and B may not be mapped to any elements in the other set.

One to one

Many to one
Many to Many
Relationship Sets with Attributes

Roles
 n Entity sets of a relationship need not be distinct

n The labels “manager” and “worker” are called roles; they specify how employee entities
interact via the works-for relationship set.

n Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to
rectangles.

n Role labels are optional, and are used to clarify semantics of the relationship

Cardinality Constraints
n We express cardinality constraints by drawing either a directed line (→), signifying
“one,” or an undirected line (—), signifying “many,” between the relationship set and
the entity set.

n E.g.: One-to-one relationship:

l A customer is associated with at most one loan via the relationship borrower

l A loan is associated with at most one customer via borrower

One-To-Many Relationship
n In the one-to-many relationship a loan is associated with at most one customer via
borrower, a customer is associated with several (including 0) loans via borrower
Many-To-One Relationships
n In a many-to-one relationship a loan is associated with several (including 0) customers
via borrower, a customer is associated with at most one loan via borrower

Many-To-Many Relationship
n A customer is associated with several (possibly 0) loans via borrower

n A loan is associated with several (possibly 0) customers via borrower

Participation of an Entity Set in a Relationship Set

Total participation (indicated by double line): every entity in the entity set participates in at
least one relationship in the relationship set

n E.g. participation of loan in borrower is total

n every loan must have a customer associated to it via borrower

Partial participation: some entities may not participate in any relationship in the relationship set

n E.g. participation of customer in borrower is partial

If some courses are not enrolled by any of the student, the participation of course will be
partial.
Weak Entity Type and Identifying
Relationship

More Weak Entity Set Examples

n In a university, a course is a strong entity and a course-offering can be modeled as a
weak entity

n The discriminator of course-offering would be semester (including year) and section-

number (if there is more than one section)
n If we model course-offering as a strong entity we would model course-number as an
attribute.

Then the relationship with course would be implicit in the course-number attribute

Representing Entity Sets as Tables

A strong entity set reduces to a table with the same at tributes