CS4.

301 Data &

Applications
Ponnurangam Kumaraguru (“PK”)
#ProfGiri @ IIIT Hyderabad

[Link] /in/ponguru @ponguru [Link]

ER DIAGRAM – Relationship
Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS,
SUPERVISION, DEPENDENTS_OF

2
Recursive Relationship
Type is: SUPERVISION
(participation role
names are shown)

3
Weak Entity Types
An entity that does not have a key attribute and that is identification-dependent on another entity
type.
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 relationship 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
4
Example Attribute of a Relationship Type:
Hours of WORKS_ON

5
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)
Must have minmax, min0, max 1
Derived from the knowledge of mini-world constraints
Cardinality & Participation taken together called structural constraints; (m,n); m = 0 is partial, m = 1 total
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

6
The (min,max) notation for
relationship constraints

Read the min,max numbers next to the entity

type and looking away from the entity type
7
COMPANY ER Schema Diagram using (min, max)
notation

8
Alternative diagrammatic notation
ER diagrams is one popular example for displaying database schemas
Many other notations exist in the literature and in various database
design and modeling tools
UML class diagrams is representative of another way of displaying ER
concepts that is used in several commercial design tools

9
UML class diagram for COMPANY
database schema

10
Other alternative diagrammatic
notations

11
 Some of the Automated Database Design
Tools (Note: Not all may be on the market now)
COMPANY TOOL FUNCTIONALITY
Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration, space and security
management
Oracle Developer 2000/Designer 2000 Database modeling, application development
Popkin System Architect 2001 Data modeling, object modeling, process modeling,
Software structured analysis/design
Platinum Enterprise Modeling Suite: Data, process, and business component modeling
(Computer Erwin, BPWin, Paradigm Plus
Associates)

Persistence Pwertier Mapping from O-O to relational model

Inc.
Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA
Resolution Ltd. Xcase Conceptual modeling up to code maintenance
Sybase Enterprise Application Suite Data modeling, business logic modeling
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C+
+
12
Typical DBMS
Component Modules
Centralized and
Client-Server DBMS Architectures
Centralized DBMS:
Combines everything into single system including- DBMS software, hardware,
application programs, and user interface processing software.
User can still connect through a remote terminal – however, all processing is
done at centralized site.
A
Physical
Centraliz
ed
Architect
ure
Logical two-tier client server architecture
Three-tier client-server architecture
The Relational Data Model and Relational
Database Constraints
Informal Definitions

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)
Example of a Relation
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

Sometimes row-ids or sequential numbers are assigned as keys to identify

the rows in a table
Called artificial key or surrogate key
This lecture

22
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.
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)
Formal Definitions - Domain
A domain has a logical definition:
Example: “USA_phone_numbers” are the set of 10 digit phone numbers valid in the U.S.
A domain also has a data-type or a format defined for it.
The USA_phone_numbers may have a format: (ddd)ddd-dddd where each d is a decimal digit.
Dates have various formats such as year, month, date formatted as yyyy-mm-dd, or as dd
mm,yyyy etc.

The attribute name designates the role played by a domain in a relation:

Used to interpret the meaning of the data elements corresponding to that attribute
Example: The domain Date may be used to define two attributes named “Invoice-date” and
“Payment-date” with different meanings
Formal Definitions - State
The relation state is a subset of the Cartesian product of the domains
of its attributes
each domain contains the set of all possible values the attribute can take.
Example: attribute Cust-name is defined over the domain of character
strings of maximum length 25
dom(Cust-name) is varchar(25)
The role these strings play in the CUSTOMER relation is that of the
name of a customer.
Formal Definitions - Summary
Formally,
Given R(A1, A2, .........., An)
r(R)  dom (A1) X dom (A2) X ....X dom(An)
R(A1, A2, …, An) is the schema of the relation
R is the name of the relation
A1, A2, …, An are the attributes of the relation
r(R): a specific state (or "value" or “population”) of relation R – this is a set of
tuples (rows)
r(R) = {t1, t2, …, tn} where each ti is an n-tuple [All Rows in a table]
ti = <v1, v2, …, vn> where each vj element-of dom(Aj) [Single Row in the table]
Formal Definitions - Example
Let R(A1, A2) be a relation schema:
Let dom(A1) = {0,1}
Let dom(A2) = {a,b,c}
Then: dom(A1) X dom(A2) is all possible combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }

The relation state r(R)  dom(A1) X dom(A2)

For example: r(R) could be {<0,a> , <0,b> , <1,c> }
this is one possible state (or “population” or “extension”) r of the relation R, defined
over A1 and A2.
It has three 2-tuples: <0,a> , <0,b> , <1,c>
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
Example – A relation STUDENT
Characteristics Of Relations
Ordering of tuples in a relation r(R):
The tuples are not considered to be ordered, even though they appear to be in
the tabular form.
Ordering of attributes in a relation schema R (and of values within each tuple):
We will consider the attributes in R(A1, A2, ..., An) and the values in t=<v1,
v2, ..., vn> to be ordered .
(However, a more general alternative definition of relation does not require this ordering.
It includes both the name and the value for each of the attributes ).
Example: t= { <name, “John” >, <SSN, 123456789> }
This representation may be called as “self-describing”.
Same state as previous Figure (but
with different order of tuples)
Characteristics Of Relations
Values in a tuple:
All values are considered atomic (indivisible).
Each value in a tuple must be from the domain of the attribute for that column
If tuple t = <v1, v2, …, vn> is a tuple (row) in the relation state r of R(A1, A2, …, An)
Then each vi must be a value from dom(Ai)

A special null value is used to represent values that are unknown or not
available or inapplicable in certain tuples.
Characteristics Of Relations
Notation:
We refer to component values of a tuple t by:
t[Ai] or [Link]
This is the value vi of attribute Ai for tuple t
Similarly, t[Au, Av, ..., Aw] refers to the subtuple of t containing the values of
attributes Au, Av, ..., Aw, respectively in t
 CONSTRAINTS
Constraints determine which values are permissible and which are not in the database.
They are of three main types:
1. Inherent or Implicit Constraints: These are based on the data model itself. (E.g.,
relational model does not tuples to be duplicates)
2. Schema-based or Explicit Constraints: They are expressed in the schema by using the
facilities provided by the model. (E.g., max. cardinality ratio constraint in the ER model)
3. Application based or semantic constraints: These are beyond the expressive power of
the model and must be specified and enforced by the application programs.
Relational Integrity Constraints
Constraints are conditions that must hold on all valid relation states.
There are three main types of (explicit schema-based) constraints that can be
expressed in the relational model:
Key constraints
Entity integrity constraints
Referential integrity constraints
Another schema-based 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)
Key Constraints
Superkey of R:
Super Key is an attribute (or set of attributes) that is used to uniquely identifies all
attributes in a relation.
Is a set of attributes SK of R with the following condition:
No two tuples in any valid relation state r(R) will have the same value for SK
That is, for any distinct tuples t1 and t2 in r(R), t1[SK]  t2[SK]
This condition must hold in any valid state r(R)
Key of R:
A "minimal" superkey
A candidate key (or key) is a set of attributes (or attributes) that uniquely identify the
tuples in relation to or table.
Key Constraints (continued)
Example: Student{ID, First_name, Last_name, Age, Sex, Phone_no}
Two candidate keys: ID & {First_name, Last_name, Age, Sex, Phone_no}

Consider the STUDENT relation schema:

Attribute Ssn is a key, because no 2 students tuples can have the same Ssn
Any set of attributes that include Ssn, like {Ssn, Name, Age} is a superkey it uniquely
identifies all attributes in a relation
In general:
Any key is a superkey (but not vice versa)
Any set of attributes that includes a key is a superkey
A minimal superkey is also a key
Bibliography / Acknowledgements
Instructor materials from Elmasri & Navathe 7e

39
 [Link]

[Link]

/in/ponguru

ponguru
Thank you
[Link]@[Link]
for attending
the class!!!