CSC 263 Database Systems

Lecture 5

Salem State University

Computer Science Department
Spring 2020
Instructor: Dr. Fatema Nafa
 Course Information
Instructor:
Dr. Fatema Nafa
Wednesdays & Fridays: 9:00 pm - 10:40 pm
Office Hours: Wednesdays 11:00 pm – 12:00 pm & by appointment

Prerequisites
CSC 115 or CSC 202J.

Textbook
Title: Fundamentals of Database Systems 7th Edition
Authors: by Ramez Elmasri and Shamkant B. Navathe
Publisher: Pearson 2017
ISBN-13: 978-0133970777
ISBN-10: 0133970779
2
3
 Learning Objectives
• After completing this lecture, you will be able to:
• Describe the relational database model’s logical structure
• Identify the relational model’s basic components and explain the structure,
contents, and characteristics of a relational table
• Use relational database operators to manipulate relational table contents
• Explain the purpose and components of the data dictionary and system
catalog
• Identify appropriate entities and then the relationships among the entities
in the relational database model
• Describe how data redundancy is handled in the relational database model
• Explain the purpose of indexing in a relational database
Review Questions

5
Integrity Rules
 Integrity Rules
• The CUSTOMER table’s primary key is CUS_CODE. The CUSTOMER
primary key column has no null entries, and all entries are unique.
Similarly, the AGENT table’s primary key is AGENT_CODE, and this
primary key column is also free of null entries.

• The CUSTOMER table contains a foreign key, AGENT_CODE, that

links entries in the CUSTOMER table to the AGENT table. The
CUS_CODE row identified by the (primary key) number 10013 contains a
null entry in its AGENT_ CODE foreign key because Paul F. Olowski
does not yet have a sales representative assigned to him. The remaining
AGENT_CODE entries in the CUSTOMER table all match the
AGENT_CODE entries in the AGENT table.

7
Entity integrity. Integrity Rules
• The CUSTOMER table’s primary key is CUS_CODE. The CUSTOMER
primary key column has no null entries, and all entries are unique.
Similarly, the AGENT table’s primary key is AGENT_CODE, and this
primary key column is also free of null entries.

Referential integrity.
• The CUSTOMER table contains a foreign key, AGENT_CODE, that
links entries in the CUSTOMER table to the AGENT table. The
CUS_CODE row identified by the (primary key) number 10013 contains a
null entry in its AGENT_ CODE foreign key because Paul F. Olowski
does not yet have a sales representative assigned to him. The remaining
AGENT_CODE entries in the CUSTOMER table all match the
AGENT_CODE entries in the AGENT table.

8
9
 Integrity Rules
• Ways to handle nulls
• Flags
• Special codes used to indicate the absence of some value
• Constraints
• NOT NULL constraint: placed on a column to ensure that every
row in the table has a value for that column
• UNIQUE constraint: restriction placed on a column to ensure that
no duplicate values exist for that column
 Relational Algebra
• Theoretical way of manipulating table contents using
relational operators
• Relvar: variable that holds a relation
• Heading contains the names of the attributes
• Body contains the relation
• Relational operators have the property of closure
• Closure: use of relational algebra operators on existing relations
produces new relations
 Relational Set Operators
Select (restrict)
• Unary operator that yields a horizontal subset of a table
Project
• Unary operator that yields a vertical subset of a table
Union
• Combines all rows from two tables, excluding duplicate rows
• Union-compatible: tables share the same number of columns, and their
corresponding columns share compatible domains
Intersect
• Yields only the rows that appear in both tables
• Tables must be union-compatible to yield valid results
13
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
Relational Set Operators
 Relational Set Operators
• Difference
• Yields all rows in one table that are not found in the other
table
• Tables must be union-compatible to yield valid results
• Product
• Yields all possible pairs of rows from two tables
Relational Set Operators
Relational Set Operators
 Relational Set Operators
• Joins allow information to be intelligently combined from two or more
tables
• Natural join: links tables by selecting only the rows with common values in
their common attribute
• Equijoin: links tables on the basis of an equality condition that compares
specified columns of each table
• Theta join: links tables using an inequality comparison operator
• Inner join: only returns matched records from the tables that are being joined
• Outer join: matched pairs are retained and unmatched values in the other table
are left null
• Left outer join: yields all of the rows in the first table, including those that do not
have a matching value in the second table
• Right outer join: yields all of the rows in the second table, including those that do
not have matching values in the first table
 Relational Set Operators
• Divide
• Uses one double-column table as the dividend and one
single-column table as the divisor
• Output is a single column that contains all values from
the second column of the dividend that are associated with
every row in the divisor
Relational Set Operators
 Relational Set Operators

Output is a single column that contains all values from the

second column of the dividend that are associated with every
row in the divisor
 Data Dictionary and the System Catalog

• Data dictionary
• Description of all tables in the database created by the user and designer
• System catalog
• System data dictionary that describes all objects within the database
• Homonyms and synonyms must be avoided to lessen confusion
• Homonym: same name is used to label different attributes
• Synonym: different names are used to describe the same attribute
 Relationships within the Relational
Database
• One-to-many (1:M)
• Norm for relational databases
• One-to-one (1:1)
• One entity can be related to only one other entity and vice versa
• Many-to-many (M:N)
• Implemented by creating a new entity in 1:M relationships with the original
entities
• Composite entity (i.e., bridge or associative entity): helps avoid problems
inherent to M:N relationships
• Includes the primary keys of tables to be linked
34
Relationships within the Relational
Database
Relationships within the Relational
Database
Relationships within the Relational
Database
 Data Redundancy Revisited
• The relational database facilitates control of data redundancies
through use of foreign keys
• Common attributes that are shared by tables
• To be controlled except the following circumstances:
• Sometimes data redundancy must be increased to make the database serve
crucial information purposes
• Sometimes data redundancy exists to preserve the historical accuracy of
data
Data Redundancy Revisited
 Indexes
• Orderly arrangement to logically access rows in a table
• Index key: index’s reference point that leads to data location
identified by the key
• Unique index: index key can have only one pointer value associated
with it
• Each index is associated with only one table
• The index key can have multiple attributes
 Codd’s Relational Database Rules
Dr. Codd’s 12 Relational
Database Rules
Rule Rule Name Description

1 Information All information in a relational database must be logically represented as

column values in rows within tables.
2 Guaranteed access Every value in a table is guaranteed to be accessible through a
combination of table name, primary key value, and column name.
3 Systematic treatment of nulls Nulls must be represented and treated in a systematic way, independent
of data type.
4 Dynamic online catalog based The metadata must be stored and managed as ordinary data—that is, in
on the relational model tables within the database; such data must be available to authorized users
using the standard database relational language.
5 Comprehensive data The relational database may support many languages; however, it must
sublanguage support one well-defined, declarative language as well as data definition,
view definition, data manipulation (interactive and by program), integrity
constraints, authorization, and transaction management (begin, commit,
and rollback).
6 View updating Any view that is theoretically updatable must be updatable through the
system.
7 High-level insert, update, and delete The database must support set-level inserts, updates, and deletes.
 Codd’s Relational Database Rules
Dr. Codd’s 12 Relational
Database Rules
Rule Rule Name Description

8 Physical data independence Application programs and ad hoc facilities are logically unaffected when
physical access methods or storage structures are changed.
9 Logical data independence Application programs and ad hoc facilities are logically unaffected when
changes are made to the table structures that preserve the original table
values (changing order of columns or inserting columns).
10 Integrity independence All relational integrity constraints must be definable in the relational
language and stored in the system catalog, not at the application level.
11 Distribution independence The end users and application programs are unaware of and unaffected by
the data location (distributed vs. local databases).
12 Nonsubversion If the system supports low-level access to the data, users must not be
allowed to bypass the integrity rules of the database.
13 Rule zero All preceding rules are based on the notion that to be considered
relational, a database must use its relational facilities exclusively for
management.
 Summary
• Tables are the basic building blocks of a relational database
• Keys are central to the use of relational tables
• Each table row must have a primary key

• Although tables are independent, they can be linked by common attributes

• The relational model supports several relational algebra functions
• A relational database performs much of the data manipulation work behind
the scenes
• Once you know the basics of relational databases, you can concentrate on
design
44
 Data Modeling Using the
Entity-Relationship (ER) Model
 Overview of Database Design Process
• Two main activities:
• Database design
• Applications design
• Focus in this part on conceptual 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
Overview of Database Design Process
 Methodologies for Conceptual
Design
• Entity Relationship (ER) Diagrams
• Enhanced Entity Relationship (EER) Diagrams
• Use of Design Tools in industry for designing and
documenting large scale designs
• The UML (Unified Modeling Language) Class
Diagrams are popular in industry to document
conceptual database designs
 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.
 Example COMPANY Database
• The database will store each EMPLOYEE’s social security
number, address, salary, sex, and birthdate.
• Each employee works for one department but may work on several
projects.
• The DB will keep track of the number of hours per week that an
employee currently works on each project.
• It is required to keep track of the direct supervisor of each employee.
• Each employee may have a number of DEPENDENTs.
• For each dependent, the DB keeps a record of name, sex,
birthdate, and relationship to the employee.
 ER Model Concepts
• Entities and Attributes
• Entity is a basic concept for the ER model. Entities are specific things
or objects in the mini-world that are represented in the database.
• For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
• Attributes are properties used to describe an entity.
• For example an EMPLOYEE entity may have the attributes 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='John
Smith', SSN='123456789', Address ='731, Fondren, Houston, TX',
Sex='M', BirthDate='09-JAN-55‘
• Each attribute has a value set (or data type) associated with it – e.g.
integer, string, date, enumerated type, …
 Types of Attributes
• Simple
• Each entity has a single atomic value for the attribute. For example, SSN
or Sex.
• 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.
• Multi-valued
• An entity may have multiple values for that attribute. For example, Color
of a CAR or PreviousDegrees of a STUDENT.
• Denoted as {Color} or {PreviousDegrees}.
 Types of Attributes
• In general, composite and multi-valued attributes
may be nested arbitrarily to any number of levels,
although this is rare.
• For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}
• Multiple PreviousDegrees values can exist
• Each has four subcomponent attributes:
• College, Year, Degree, Field
Example of a composite attribute
55