CS 221 Lecture Manual

OUR LADY OF FATIMA UNIVERSITY
COLLEGE OF COMPUTER STUDIES
WEEK 1
Traditional File-Based System

 manual file is set up to hold all external and internal correspondence relating to a project,
product, employee, or client, such files are labeled and stored in cabinets
 for security, cabinets have locks or may be located in secure areas of the building
File-Based System
 collection of application programs that perform services for the end-users such as the
production of reports
 an early attempt to computerize the manual filing system
 was developed in response to the needs of industry for more efficient data access
Limitations of File-Based Approach

1. Separation and isolation of data
2. Duplication of data
3. Data dependence
4. Incompatible file formats
5. Fixed queries / proliferation (production or creation) of application programs
Database – a shared collection of logically related data, and description of this data, designed to meet
the information needs of an organization
Database Management System (DBMS) – a software system that enables users to define, create,
maintain, and control access to the database
Characteristics of Dbase Approach
1. Self-describing nature of dbase system

The database contains not only the dbase itself but also a complete definition or
description of the dbase structure and constraints. The definition is stored in the system
catalog (also called as meta-data).
2. Insulation between programs and data, and data abstraction
CS221 - DATABASE MANAGEMENT SYSTEMS Page 1 of 41

The structure of data files is stored in the DBMS catalog separately from the access
programs (program independence). In DBMS environment, in adding another piece of
data, we just need to change the description of data in meta-data, no programs are
changed.
Data abstraction – characteristic that allows program-data independence and program
operation independence
3. Support of multiple views of the data
A database typically has many users, each of whom may require different perspective or
view of the dbase.
View – may be a subset of dbase
4. Sharing of data and multiuser transaction processing
 Must allow multiple users to access the dbase at the same time
 Concurrency control – the DBMS must include software to ensure that several users
trying to update the same data do so in a controlled manner so that the result of the
updates is correct
 On-Line Transaction Processing (OLTP) – DBMS should ensure that each subset or
record can be accessed by only one user at a time
Actors on the Scene

1. Database Administrators (DBA) – administers database environment such as database itself
and DBMS and related software. DBA is responsible for authorizing access to the dbase, for
coordinating and monitoring its use, and for acquiring software and hardware resources
a. accountable for problems such as breach of security or poor system response time
2. Database Designers – responsible for identifying the data to be stored in the dbase and for
choosing appropriate structures to represent and store this data
3. End-users – people whose jobs require access to the dbase for querying, updating, and
generating reports
Categories of End-Users
1. Casual end user – occasionally access the dbase, but they need different information each
time
 typically middle- or high-level managers or other occasional browsers
2. Naïve or parametric end users – make up a sizeable portion of dbase end user
 their main job function revolves around constantly querying and updating the dbase

 example: bank tellers, reservation clerks for airlines, hotels and car rentals
3. Sophisticated end users – include engineers, scientists, business analysts, and others
who thoroughly familiarize themselves with the facilities of DBMS
4. Stand-alone users – maintain personal dbases by using ready-made program packages
that provide easy-to-use menu- or graphics-based interfaces
4. System analysts and application programmer (software engineers)
1. System analysts – determine the requirements of end-users and develop specifications for
canned transactions (using standard types of queries and updates)
2. Application programmers – implement these specifications as programs, then they test,
debug, document and maintain the canned transactions
Intended Uses of DBMS

1. Controlling redundancy
2. Restricting unauthorized access
3. Persistent storage for program objects and data structure
4. Database interfacing using deduction rules (permitting interferencing and action using rules)
5. Providing multiple user interfaces
6. Representing complex relationships among data
7. Enforcing integrity constraints
8. Providing back-up and recovery
Disadvantages of DBMS
1. Complexity
2. Size
3. Cost of DBMS
4. Additional hardware costs
5. Cost of conversion
6. Performance
7. Higher impact failure

Implications of Dbase Approach
1. Potential for enforcing standards

 Dbase approach permits the DBA to define and enforce standards among dbase users
in a large organization
 Standards can be define for names and formats of data elements, display formats, report
structures, terminologies
2. Reduced application development time
 A prime selling feature of dbase approach is that developing a new application – such
as retrieval of certain data from the dbase for printing new application – takes very little
time.
3. Flexibility
 It may be necessary to change the structure of a dbase as requirements change.
Modern DBMS allow certain type of changes to the structure of the dbase without
affecting the stored data and the existing application programs.
4. Availability of up-to-date information
 DBMS makes the dbase available to all users. As soon as one user’s update is applied
to the dbase, all other users can immediately see this update.
5. Economies of Scale
 DBMS approach permits consolidation of data and applications, thus reducing the
amount of wasteful overlap between activities of data-processing personnel in different
projects or departments.

WEEK 2
Three-Level ANSI-SPARC Architecture
User 1 User 2 User n
External level View 1 View 2 ... View n
Conceptual level Conceptual Schema
Internal level Internal Schema
Physical data organization

Dbase
1. External Level – The user’s view of database. This level describes that part of the dbase that
is relevant to each user.
2. Conceptual level – The community view of the dbase. This level describes what data is stored
in the dbase and the relationships among data.
3. Internal level – The physical representation of the dbase on the computer. This level describes
how the data is stored in the dbase.

4. Physical level – may be managed by operating system under the direction of the DBMS.
– DBMS consists of items only the operating system knows, such as exactly how the
sequencing is implemented and whether the fields of internal records are stored as
contiguous bytes on the disk.
–
Dbase Schema – overall description of the dbase
Database Languages
2 Parts
1. Data Definition Language (DDL) – used to specify the database schema

 language that allows the DBA or user to describe and name entities, attributes, and
relationships required for the application, together with any associated integrity and security
constraints
 the result of the compilation of the DDL statements is a set of tables stored specified file
collectively called system catalog
 meta-data contains definitions of records , data items
2. Data Manipulation Language (DML) – is used both read and update the database
 a languages that provides a set of operations to support the basic data manipulation
operations on the data held in the database
Data Manipulation Operations:

1. insertion of the new data into the database
2. modification of the data stored in the database
3. retrieved of the contained in the database
4. deletion of the data from the database
 These languages are also called data sublanguages (e.g., COBOL, Fortran, Pascal, Ada, C,
C++, Java, or VB)

Data Model – a collection of concepts that can be used to describe a set of data, the operations to
manipulate the data, and a set of integrity rules for the data

3 Broad Categories of Data Model
1. Object-Based Data Models

 use concepts such as entities, attributes and relationships
 entity – distinct object (a person, place, thing, concept, event)
 attribute – properly that describe some aspect of the object
 relationship – is an association between entities
 entity-relationship model – one common type of object-based data model
2. Record-Based Data Model

 the database is consists of a number of fixed-format records possibly of differing
types
 Relational data model – data and relationships are represented as tables, each of
which has a number of columns with a unique name
Example:
Employee
EmpNum EmpName DeptNum Salary
2001 C. Cristobal 001 10000
2002 C. Malay 002 13000
2003 O. Ternida 001 15000
2004 N. Felicerta 002 11000
2005 E. Smith 003 12000
2006 R. Distor 003 13500
Department
DeptNum DeptName Budget
001 Courseware 40000
002 MIS 60000
003 Engineering 70000

 Network data model - the records are organized as generalized graph structures
with records appearing as nodes and sets as edges in the graph.
Example:
2001 C. Critobal 001 10000

001 Courseware 40000
2003 O. Ternida 001 15000
2002 C. Malay 002 13000

002 MIS 60000
2004 N. Felicerta 002 11000
2005 E. Smith 003 12000

003 Engineering 70000
2006 R. Distor 003 13500
Hierarchical data model - data is represented as collection of records and relationships are
represented by sets, however it allows a node (record) to have only one parent
 Files are arranged in a top-down structure that resembles a tree or
genealogy chart. It is a restricted type of network model.
3. Physical Data Model

 describe how data is stored in the computer representing information such as record
structure, record orderings, and access paths
 Conceptual modeling – or conceptual database design, process of constructing a model of
the information use in an enterprise that is independent of implementation details such as
the target DBMS, application programs, programming language

Functions of DBMS
1. Data storage, retrieval, and update
 A DBMS must furnish users with the ability to store, retrieve, and update data in the
database.
2. A user-accessible catalog
 A DBMS must furnish a catalog in which descriptions of data items are stored and which is
accessible to users.
3. Transaction support
 A DBMS must furnish a mechanism which will ensure either that all the updates
corresponding to a given transaction are made or that none of them is made.
4. Concurrency control services
 A DBMS must furnish mechanism to ensure that the database is updated correctly when
multiple users are updating the database concurrently.
5. Recovery services
 A DBMS must furnish a mechanism for recovering the database in the event that the
database is damaged in any way.
6. Authorization services
 A DBMS must furnish a mechanism to ensure that only authorized users can access the
database.
7. Support for the communication
 DBMS must be capable of integrating with communication software.
8. Integrity services
 DBMS must furnish a means to ensure that both data in the database and changes to the
data follow certain rules.
9. Services to promote data independence.
 A DBMS must include facilities to support the independence of programs from the actual
structure of the database.
10. Utility services
 A DBMS should provide a set of utility services.
CS 221 – DATABASE MANAGEMENT SYSTEM Page 9 of 41

COMPONENTS OF DBMS
1. Computer-aided software engineering (CASE) tools – Automated tools used to design

databases and application programs.
 The term "Computer-aided software engineering" (CASE) can refer to the software used for
the automated development of systems software, i.e., computer code. The CASE functions
include analysis, design, and programming. CASE tools automate methods for designing,
documenting, and producing structured computer code in the desired programming
language.
2. Repository – Centralized storehouse for all data definitions, data relationships, screen and
report formats, and other system components. A repository contains an extended set of
metadata important for managing databases as well as other components of an information
system.
Metadata – are data that describe the properties or characteristics of other data. Some
of these properties include data definitions, data structures, and rules or constraints.
3. Database management system (DBMS) – Commercial software (and occasionally, hardware
and firmware) system used to define, create, maintain, and provide controlled access to the
database and also to the repository.
4. Database – An organized collection of logically related data, usually designed to meet the
information needs of multiple users in an organization.
5. Application programs – Computer programs that are used to create and maintain the
database and provide information to users.
6. User interface – Languages, menus, and other facilities by which users interact with various
system components, such as CASE tools, application programs, the DBMS, and the repository.
7. Data administrators – Person who are responsible for the overall information resources of an
organization. Data administrators use CASE tools to improve the productivity of database
planning and design.
8. System developers – Persons such as systems analysts and programmers who design new
application programs. System developers often use CASE tools for system requirements
analysis and program design.
9. End users – Persons throughout the organization who add, delete, and modify data in the
database and who request or receive information from it.

WEEK 3 & WEEK 4
Brief History of the Relational Model

 was first proposed by E. F. Codd
 although interest in the relational model came from several directions, the most significant
research may be attributed to three projects:
1. Prototype Relational DBMS System R

 at IBM’s San Jose Research Laboratory in California
 was designed to prove the practicality of the relational mode
2. INGRES (Interactive Graphics Retrieval System)
 Project at the University of California at Berkely
 Involved the development of a prototype RDBMS
3. Peterlee Relational Test Vehicle at the IBM UK Scientific Centre
 Principally for research into such issues as query processing and optimization,
and functional extension
Basic Terminologies
Relation
 a relation is a table with columns and rows
 relations are used to hold information about the objects to be represented in the database
Relational Model – is based on the mathematical concept of a relation, which is physically represented
as a table
Attributes – a named column of a relation
Branch
BranchNo Street City Postcode
B001 22 Deer Rd. London SW14EH
B002 16 Argyll Aberdeen AB23SU
B003 163 Main St. Glasglow GI19QX
B004 32 Manse Rd. Bristol BS99NZ

Foreign Key
Staff
StaffNo fName lName Position Gender DOB Salary BranchNo
SL21 John White Manager M 1-Oct-75 30000 B001
SG37 Ann Breech Assistant F 10-Nov-60 12000 B003
SG14 David Ford Supevisor M 24-Mar-58 18000 B003
SG09 Mary Howe Assistant F 19-Feb-70 9000 B004
Domain – is the set of allowable values for one or more attributes
Attribute Domain Name Meaning Domain Definition

BranchNo Branch numbers The set of all possible Char, size 4, B001-B999
branch nos.
Street Street names Set of all street names in Char, size 25
Britain
City City names Set of all city names in Char, size 15
Britain
Postcode Post codes Set of all post codes in Char, size 8
Britain
Gender Gender Gender of a person Char, size 1, M or F
DOB Date of Birth Possible values of staff Date, range from 1-1-20
birth dates
Salary Salaries Possible values of staff Monetary, 7 digits, 6000
salaries – 40000
Tuple – is a row of a relation
Degree – the degree of a relation is the number of attributes it contains

Example: Branch relation has a degree four.
Cardinality – the cardinality of a relation is the number of tuples it contains

Relational database
 a collection of normalized relations with distinct relation names
 consists of relations that are appropriately structured
Alternative Terminology
Formal Terms Alternative 1 Alternative 2
Relation Table File
Tuple Row Record
Attribute Column Field
Database Relations
Relation schema – a named relation defined by a set of attribute and domain name pairs
Domain – Branch Number, Street Name, City Name, Post Code

{(B005, 22 Deer Rd., London, SW14EH)}
Properties of Relations
 the relation has a name that is distinct from all other relation names
 each cell of relation contains exactly one atomic (single) value
 each attribute has a distinct name
 the values of an attribute are all from the same domain
 each tuple is distinct, there are no duplicate tuples
 the order of attributes has no significance
 the order of tuples has no significance

Relational Keys
Relational Keys
Superkey – an attribute, or set of attributes, that uniquely identifies a tuple within a relation
 Candidate key – a superkey such that no proper subset is a superkey within the relation
A candidate key for a relation has two properties:
1. uniqueness – in each tuple of relation, the values of candidate key are uniquely identify
that tuple
2. irreducibility – no proper subset of candidate key has the uniqueness property
Primary key – the candidate key that is selected to identify tuples uniquely with the relation
Alternate key – candidate keys that are not selected to be the primary key
Foreign key – an attribute, or set of attributes with one relation that matches the candidate key of some
possibly the same relation

Relational Integrity
Null
 Represents a value for an attribute that is currently unknown or is not applicable for this tuple.
 Deals with incomplete or exceptional data.
 Null represents the absence of a value and is not the same as zero or spaces, which are values.
2 principal rules for the relational model:

1. Entity Integrity
 In a base relation, no attribute of a primary key can be null.
2. Referential Integrity
 If foreign key exists in a relation, either the foreign key value must match a candidate key value
of some tuple in its home relation or foreign key value must be wholly null.
Enterprise Constraints
 Additional rules specified by users or database administrators.
 Eg., the maximum number of staff in a branch.
Views
 Base Relation – A named relation, corresponding to an entity in conceptual schema, whose
tuples are physically stored in database.
 View – Dynamic result of one or more relational operations operating on the base relations to
produce another relation.
o A view is a virtual relation that does not actually exist in the database but is produced
upon request, at time of request. Contents of a view are defined as a query on one or
more base relations.

WEEK 5
Database planning As a database system is a fundamental

component of the larger organization-wide
information system, the database application
System Definition lifecycle is inherently associated with the
lifecycle of the information system.
Requirements
Collection and
analysis
Database Design
Conceptual
database design
DBMS Application
SELECTION
Design
Logical database
design
Physical database
design
Prototyping Implementation
(optional)
Data conversion
and loading
Testing
Operational
maintenance
DATABASE APPLICATION LIFE CYCLE

Database planning – planning how the stages of the life cycle can be realized most efficiently and
effectively. The management activities that allow the stages of the database application to be realized
as efficiently and effectively as possible.
System definition – specifying the scope and boundaries of the database application, its users, and
application areas. It describes the scope and boundaries of the database application and major user
views.
Requirements collection and analysis – collection and analysis of the requirements of users and
application areas.
Database design – The process of creating a design for a database that will support the enterprise’s
operations and objectives. It includes the conceptual, logical, and physical design of the database.
 Conceptual Design – Data modeling is used to create an abstract database structure
that represents real-world objects in the most realistic way possible. The conceptual
model must embody a clear understanding of the business and its functional areas. At
this level of abstraction, the type of hardware and/ or database model to be used might
not yet identified. Therefore, the design must be software- and hardware-independent
so the system can be set up within any hardware or software platform chosen later.
 Logical Design – Translates the conceptual design into the internal model for a selected
database management system (DBMS) such as DB2, SQL Server, Oracle, and Access.
Therefore, the logical design is software-dependent.
 Physical Design – It is the process of selecting the data storage and data access
characteristics of the database. The storage characteristics are a function of the types
of devices supported by the hardware, the type of data access methods supported by
the system, and the DBMS. Physical design affects not only the location of the data in
the storage devices, but also the performance of the system.
DBMS selection (optional) – selecting a suitable DBMS for the database application.
Application design – designing the user interface and the application programs that use and process
the database.
Prototyping (optional) – building a working model of the database application, which allows the
designers or users to visualize and evaluate how the final system will look and function.
Implementation – creating the external, conceptual, and internal database definitions and the
application programs

Data conversion and loading – loading data from the old system to the new system
Testing – database application is tested for errors and validated against the requirements specified by
the users.
Operational maintenance – database application is fully implemented. The system is continuously
monitored and maintained. When necessary, new requirements are incorporated into the database
application through the preceding stages of the lifecycle.
User Views
Defines what is required of a database application from the perspective of a particular job role
(such as Manager or Supervisor) or enterprise application area (such as marketing, personnel,
or stock control).
Approaches to Database Design

The two main approaches to the design of a database are referred to as “bottom-up” and “top-down”.
The bottom-up approach begins at the fundamental level of attributes (that is, properties of entities and
relationships), which through analysis of the associations between attributes, are grouped into relations
that represent types of entities and relationships between entities. This approach is appropriate for the
design of simple databases with a relatively small number of attributes.
A more appropriate strategy for the design of complex databases is to use the top-down approach.
This approach starts with the development of data models that contain a few high-level entities and
relationships and then applies successive top-down refinements to identify lower-level entities,
relationships and the associated attributes.
Database design refers to the activities that focus on the design of the database structure that will be
used to store and manage end-user data. A good database – that is, a database that meets all user
requirements – does not just happen; its structure must be designed carefully. In fact, database design
is such a crucial aspect of working with databases. Even a good DBMS will perform poorly with a badly
designed database.
Proper database design requires the database designer to identify precisely the database’s expected
use. Designing a transactional database emphasizes accurate and consistent data and operational
speed.

WEEK 7
Entity-Relationship Modeling
 emphasis on data and not on actions on the data

 used for specifying databases
 now more popular since it is an element of object-oriented analysis
 Entity-Relationship Model - An approach to data modeling proposed by P. Chen in 1976. The
model says that you divide your database in two logical parts, entities (e.g. "customer",
"product") and relations ("buys", "pays for").
Entity ( entity symbol)
 A collection of things that share common properties or characteristics
 In a database, anything about which information can be stored; for example, a person, concept,
physical object or event. Typically refers to a record structure.
 May describe
 Roles-people or organizations: EMPLOYEE

 Tangible things: MACHINE, BUILDING
 Events: SALE, REGISTRATION
 Locations: STATE, BRANCH
 Concepts: COURSE
Entity Sets
 a set of entities of the same type
 (e.g., all persons having an account at a bank)
 tells about something or somebody in the system (e.g., customers)
 CUST1 CUST2 CUST3
 these form an entity set called CUSTOMER
 singular name since we model one customer at a time

 a noun, maybe with an adjective
Entity Instances
 A single occurrence of the entity

 There can be many instances of data stored in a database
Instances: Thomas Mavros

TAXPAYER
Eric Cantona
Diego Maradona
Glen Hoddle
Attribute ( - symbol for attribute )
 properties or characteristics of an entity
Types of Attributes
1. Simple or Atomic – indivisible (e.g., Age)

2. Composite – can be divided into simple attributes (e.g., Address  Street, Barangay, City)
3. Single-Valued – a single value attribute (e.g., Age = 27)
4. Multi-Valued – an attribute can have multiple values (e.g., College Degree = BSCS, BSBA, BEED)
5. Derived – value of an attribute that is derived from another attribute (e.g., Age is derived from
Birthday and Current Date, Birthday and Current Date are related attributes)
Entity Type
Composite Derived
Attribute Attribute
Multivalued
Attribute
Component
attributes

Relationship ( symbol for relationship)
 association between entities

 tells about some connection between entities
Customer Places Order
 PLACES is a relationship
 labeled with verb phrases
 Relationships are shown in a diamond

 The diagram can be read in both directions
Types of Relationship
1. one-to-one relationship (1:1)
In a company, each division is managed by only one manager and each manager manages only one
division
Managed
Department Manager
by
2. one-to-many relationship (1:N)
Among the automobile manufacturing companies, a company manufactures many cars, but a given car
is manufactured in only one company
manufactures
Company Car

3. many-to-many relationship (N:N)
In a college, every student takes many courses and every course is taken by many students
Student takes Course
Degree of Relationship
 the number of entity types that participate in the relationship

1. Unary Relationship – relationship between the instances of a single entity type. Also
called as recursive relationship.
is
Person married
to
2. Binary Relationship – relationship between the instances of two entity types. It is the
most common type of relationship encountered in the data modeling.
Product Line contains Products
3. Ternary Relationship – simultaneous relationship among the instances of three entity

types

Product
Vendor Suppliers Warehouse
 One instance of supplies might record the fact that vendor X can supply product C to
warehouse Y.
Cardinality Constraints
1. Minimum cardinality – the minimum number of instances of one entity that may be associated
with each instance of another entity
2. Maximum cardinality – the maximum number of instances of one entity that may be associated
with a single occurrence of another entity
Basic Relationship:
has Patient
Patient History
Relationship with Cardinality Constraints:
has Patient
Patient History

Relationship Cardinality
1. Mandatory One
2. Mandatory Many
3. Optional One
4. Optional Many

WEEK 9
Normalization
 a technique for producing a set of relations with desirable properties, given the data
requirements of an enterprise
 a method of organizing data elements in a database into tables
Purpose of Normalization
 supports database designers by presenting a series of tests, which can be applied to individual
relations so that a relational schema can be normalized to a specific form to prevent the
possible occurrence of update anomalies
 Data redundancy and update anomalies. A major aim of relational database is to group
attributes into relations to minimize data redundancy and thereby reduce file storage space
required by the implemented base relations.
Data Anomalies
 A data abnormality that exists when inconsistent changes to a database have been made. For
example, an employee moves, but the address change is corrected only in one file and not
across all files in the database.
1. An update anomaly is a data inconsistency that results from data redundancy and a partial
update. For example, each employee in a company has a department associated with them as
well as the student group they participate in.
Employee_ID Name Department Student_Group

123 J. Longfellow Accounting Beta Alpha Psi
234 B. Rech Marketing Marketing Club
345 B. Rech Marketing Management Club
456 A. Bruchs CIS Technology Org.
567 A. Bruchs CIS Beta Alpha Psi
If A. Bruchs’ department is an error it must be updated at least 2 times or there will be inconsistent data
in the database. If the user performing the update does not realize the data is stored redundantly the
update will not be done properly.

2. A deletion anomaly is the unintended loss of data due to deletion of other data. For example, if
the student group Beta Alpha Psi disbanded and was deleted from the table above, J.
Longfellow and the Accounting department would cease to exist. This results in database
inconsistencies and is an example of how combining information that does not really belong
together into one table can cause problems.
3. An insertion anomaly is the inability to add data to the database due to absence of other data.
For example, assume Student_Group is defined so that null values are not allowed. If a new
employee is hired but not immediately assigned to a Student_Group then this employee could
not be entered into the database. This results in database inconsistencies due to omission.
Update, deletion, and insertion anomalies are very undesirable in any database. Anomalies are avoided
by the process of normalization.
The Process of Normalization

Tabular Representation of the report format
PROJ
PROJ_NAM EMP_NU CHG_HOU ASSIGN_
_NU EMP_NAME JOB_CLASS
E M R HOURS
M
15 Evergreen 103 E. Arbough Elect. Engineer $84.50 23.8
101 G. News Dbase Designer $105.00 19.4
105 K. Johnson Dbase Designer $105.00 35.7
106 W. Smithfield Programmer $35.75 12.6
102 D. Senior System Analyst $96.75 23.8
18 Amber 114 A. Jones Applications $48.10 24.6
Wave Designer
118 J. Frommer General Support $18.36 45.3
104 A. Ramoras Systems Analyst $96.75 32.4
112 D. Smithson DSS Analyst $45.95 44.0
22 Rolling Tide 105 A. Johnson Dbase Designer $105.00 64.7
104 A. Ramoras Systems Analyst $96.75 48.4
113 D. Joenbrood Applications $48.10 23.6
Designer
111 G. Wabash Clerical Support $26.87 22.0
106 W. Smithfield Programmer $35.75 12.8
25 Starflight 107 M. Alonzo Programmer $35.75 24.6
115 T. Bawangi System Analyst $96.75 45.8
101 G. News Dbase Designer $105.00 56.3
114 A. Jones Applications $48.10 33.1
Designer
108 R. Systems Analyst $96.75 23.6
Washington
118 J. Frommer General Support $18.36 30.5
112 D. Smithson DSS Analyst $45.95 41.4

First Normal Form (1NF)

 Start by presenting the data in tabular format, where each cell has a single value and there are
no repeating groups. To eliminate the repeating groups, eliminate the nulls by making sure that
each repeating group attribute contains an appropriate data value.
 A relation in which the intersection of each row and column contains one and only one value.
A table in first normal form

PROJ
PROJ_NAM EMP_NU CHG_HOU ASSIGN_
_NU EMP_NAME JOB_CLASS
E M R HOURS
M
15 Evergreen 103 E. Arbough Elect. Engineer $84.50 23.8
15 Evergreen 101 G. News Dbase Designer $105.00 19.4
15 Evergreen 105 K. Johnson Dbase Designer $105.00 35.7
15 Evergreen 106 W. Smithfield Programmer $35.75 12.6
15 Evergreen 102 D. Senior System Analyst $96.75 23.8
18 Amber 114 A. Jones Applications $48.10 24.6
Wave Designer
18 Amber 118 J. Frommer General Support $18.36 45.3
Wave
18 Amber 104 A. Ramoras Systems Analyst $96.75 32.4
Wave
18 Amber 112 D. Smithson DSS Analyst $45.95 44.0
Wave
22 Rolling Tide 105 A. Johnson Dbase Designer $105.00 64.7
22 Rolling Tide 104 A. Ramoras Systems Analyst $96.75 48.4
22 Rolling Tide 113 D. Joenbrood Applications $48.10 23.6
Designer
22 Rolling Tide 111 G. Wabash Clerical Support $26.87 22.0
22 Rolling Tide 106 W. Smithfield Programmer $35.75 12.8
25 Starflight 107 M. Alonzo Programmer $35.75 24.6
25 Starflight 115 T. Bawangi System Analyst $96.75 45.8
25 Starflight 101 G. News Dbase Designer $105.00 56.3
25 Starflight 114 A. Jones Applications $48.10 33.1
Designer
25 Starflight 108 R. Systems Analyst $96.75 23.6
Washington
25 Starflight 118 J. Frommer General Support $18.36 30.5
25 Starflight 112 D. Smithson DSS Analyst $45.95 41.4
NOTE: The term first normal form (1NF) describes the tabular format in which:
 All of the key attributes are defined
 There are no repeating groups in the table. In other words, each row/column in
intersection contains one and only one value, not a set of values.
 All attributes are dependent on the primary key.
Second Normal Form (2NF)

 A relation that is in first normal form and every non-primary-key attribute is fully functionally
dependent on the primary key.
 Any partial functional dependencies have been removed.
 Functional dependency – a constraint between two attributes
o For every relation R, attribute B is functionally dependent on attribute A.
o Example:
 SSN → Name, Address, Birthdate
 VIN → Make, Model, Color
 ISBN → Title, Author_Name
o Determinants – attribute on the left-hand side of the arrow in a functional dependency.
(e.g., SSN, VIN, ISBN)
 Partial Functional Dependency – a functional dependency in which one or more non-key
attributes are functionally dependent on part (but not all) of the primary key
Second Normal Form (2NF) conversion results
Table name: Project
PROJ_NUM PROJ_NAME
15 Evergreen
18 Amber Wave
22 Rolling Tide
25 Starflight
Table name: Employee
CHG_HOU
EMP_NUM EMP_NAME JOB_CLASS R
101 G. News Dbase Designer $105.00
102 D. Senior Systems Analyst $96.75
103 E. Arbough Elect. Engineer $84.50
104 A. Ramoras Systems Analyst $96.75
105 K. Johnson Dbase Designer $105.00
106 W. Smithfield Programmer $35.75
107 M. Alonzo Programmer $35.75
108 R. Washington Systems Analyst $96.75
111 G. Wabash Clerical Support $26.87
112 D. Smithson DSS Analyst $45.95
113 D. Joenbrood Applications $48.10
Designer
114 A. Jones Applications $48.10
Designer
115 T. Bawangi Systems Analyst $96.75
118 J. Frommer General Support $18.36

Table name: Assignment

PROJ_NU EMP_NU
ASSIGN_HOURS
M M
15 103 23.8
15 101 19.4
15 105 35.7
15 106 12.6
15 102 23.8
18 114 24.6
18 118 45.3
18 104 32.4
18 112 44.0
22 105 64.7
22 104 48.4
22 113 23.6
22 111 22.0
22 106 12.8
25 107 24.6
25 115 45.8
25 101 56.3
25 114 33.1
25 108 23.6
25 118 30.5
25 112 41.4
NOTE: A table is in second normal form (2NF) when:

 It is in 1NF.
 It includes no partial dependencies; that is, no attribute is dependent on only a
portion of the primary key.
(But it is still possible for a table in 2NF to exhibit transitive dependency; that is, one
or more attributes may be functionally dependent on nonkey attributes.)
Third Normal Form (3NF)

 A relation that is in first and second normal form, and in which no non-primary-key attribute is
transitively dependent on the primary key.
 Any transitive dependencies have been removed.
 Transitive dependency - a functional dependency between two or more non-key attributes.

Third Normal Form Conversion Results
Table name: Project

PROJ_NU
PROJ_NAME
M
15 Evergreen
18 Amber Wave
22 Rolling Tide
25 Starflight
Table name: Employee

EMP_NUM EMP_NAME JOB_CLASS
101 G. News Dbase Designer
102 D. Senior Systems Analyst
103 E. Arbough Elect. Engineer
104 A. Ramoras Systems Analyst
105 K. Johnson Dbase Designer
106 W. Smithfield Programmer
107 M. Alonzo Programmer
108 R. Washington Systems Analyst
111 G. Wabash Clerical Support
112 D. Smithson DSS Analyst
113 D. Joenbrood Applications Designer
114 A. Jones Applications Designer
115 T. Bawangi Systems Analyst
118 J. Frommer General Support
Table name: Job

JOB_CLASS CHG_HOUR
Applications $48.10
Designer
Clerical Support $26.87
Dbase Designer $105.00
DSS Analyst $45.95
Elect. Engineer $84.50
General Support $18.36
Programmer $35.75
Systems Analyst $96.75

Table name: Assignment

PROJ_NU EMP_NU
ASSIGN_HOURS
M M
15 103 23.8
15 101 19.4
15 105 35.7
15 106 12.6
15 102 23.8
18 114 24.6
18 118 45.3
18 104 32.4
18 112 44.0
22 105 64.7
22 104 48.4
22 113 23.6
22 111 22.0
22 106 12.8
25 107 24.6
25 115 45.8
25 101 56.3
25 114 33.1
25 108 23.6
25 118 30.5
25 112 41.4

WEEK 13
The methodology started by producing a local conceptual data model and then derived a set of
relations to produce a local logical data model. The logical database design phase concluded by
merging together the local data models.
In presenting a database design methodology we divide the design process into three main phases:
conceptual, logical, and physical database design. The phase prior to physical design, namely logical
database design, is largely independent of implementation details, such as the specific functionality of
the target DBMS and application programs, but is dependent on the target data model. The output of
this process is a global logical model consisting of an ER/relation diagram, relational schema, and
supporting documentation that describes this model, such as a data dictionary. Together, these
represent the sources of information for the physical design process, and they provide the physical
database designer with a vehicle for making tradeoffs that are so important to an efficient database
design.
Whereas logical database design is concerned with the what, physical database design is concerned
with how. It requires different skills that are often found in the different people. In particular, the
physical database designer must know how the computer system hosting the DBMS operates, and
must be fully aware of the functionality of the target DBMS. As the functionality provided by current
systems varies widely, physical design must be tailored to specific DBMS. However, physical database
design is not an isolating activity – there is often feedback between physical, logical, and application
design. For example, decisions taken during physical design for improving performance, such as
merging relations together, might affect the structure of the logical data model, which will have an
associated effect on the application design.
Logical Database Design
1. To develop a logical database, analyze the business of the organization that the database would
support, how the operations relate to each other, and what data is used in business operations.
After this analysis, model the data. This modeling involves studying data usage and grouping
data elements into logical units so that a task supported by one or more organizational units is
independent of support provided for other tasks.
2. By providing each task with its own data groups, changes in the data requirements of one task
will have minimal, if any, impact on data provided for another task. By having data managed as
a synthesis, data redundancy is minimized and data consistency among tasks and activities is
improved. The figure below graphically expresses this point.
3. Logical database design comprises two methods to derive a logical database design. The first
method is used to analyze the business performed by an organization. Following this analysis,
the second method is used to model the data that supports the business. These methods are:
A. Business Analysis
B. Data Modeling

WEEK 14
Physical Database Design

The process of producing a description of the implementation of the database on secondary
storage; it describes the base relations, file organizations, and indexes used to achieve efficient
access to the data, and any associated integrity constraints and security measures.
The steps of the physical database design methodology are as follows:
Step 4 – Translate global logical data model for target DBMS.

a. Design base relations
b. Design representation of derived data
c. Design enterprise constraints
Step 5 – Design physical representation
5.1 Analyze transactions
5.2 Choose file organizations
5.3 Choose indexes
5.4 Estimate disk space requirements
Step 6 – Design user views
Step 7 – Design security mechanisms
Step 8 – Consider the introduction of controlled redundancy
Step 9 – Monitor and tune the operational system
The Physical Database Design Methodology for Relational Databases
Step 4 –Translate global logical data model for target DBMS

Objective: To produce a relational database schema from the global logical data model that can be
implemented in the target DBMS.
Step 4.1 Design base relations

Objective: To decide how to represent the base relations identified in the global logical data
model in the target DBMS.

Step 4.2 Design representation of derived data

Objective: To decide how to represent any derived data present in the global logical data model
in the target DBMS.
Step 4.3 Design enterprise constraints

Objective: To design the enterprise constraints for the target DBMS.
Step 5 – Design physical representation

Objective: To determine the optimal file organizations to store the base relations and the indexes that
are required to achieve acceptable performance that is, the way in which relations and tuples will be
held on secondary storage.
Step 5.1 Analyze transactions

Objective: To understand the functionality of the transactions that will run on the database and t
analyze the important transactions.
Step 5.2 Choose file organizations

Objective: To determine an efficient file organization for each base relation.
Step 5.3 Choose indexes

Objective: To determine whether adding indexes will improve the performance of the system.
Step 5.4 Estimate disk space requirements

Objective: To estimate the amount of disk space that will be required by the database.
Step 6 – Design user views

Objective: To design the user views that were identified during the requirements collection and analysis
stage of the relational database application lifecycle.
Step 7 – Design security measures

Objective: To design the security measures for the database as specified by the users.

WEEK 15
SQL
 Stands for Structured Query Language
 A standard computer language for accessing and manipulating databases
 Can execute queries against a database
 Can retrieve data from a database
 Can insert new records to a database
 Can delete records from a database
 Can update records in a database
SQL Data Definition Language (DDL)
1. Create the database. In the mysql program, issue this statement:
mysql> CREATE DATABASE company;
2. Creating a database does not select it for use; you must do that explicitly. To make company the
current database, use this command:
mysql> USE company;

Database changed
3. Use a CREATE TABLE statement to specify the layout of your table:
mysql> CREATE TABLE emp (empno INT(2) PRIMARY KEY, lname VARCHAR(15), fname
VARCHAR(15), category VARCHAR(1), rate DECIMAL(5,2);
4. Once you have created a table, SHOW TABLES should produce some output:
mysql> SHOW TABLES;

+-----------------------+
| Tables in company |
+-----------------------+
| emp |
+-----------------------+

5. To verify that your table was created the way you expected, use a DESCRIBE statement:
mysql> DESCRIBE emp;

+----------+--------------+-------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+-------+-----+---------+-------+
| empno | int(2) | NO |PRI | NULL | |
| lname | varchar(15) | YES | | NULL | |
| fname | varchar(15) | YES | | NULL | |
| category | varchar(1) | YES | | NULL | |
| rate | decimal | YES | | NULL | |
+----------+--------------+-------+----+----------+------+
SQL Data Manipulation Language (DML)
1. SELECT – extracts or retrieves data from a database table
 SELECT * FROM emp;

Empno lname fname category rate
11 Radebe Vincent A 600.00
12 James Pauline B 500.00
16 Ramoraz Charles C 400.00
17 Williams Monique B 500.00
 SELECT lname, rate FROM emp;

Lname rate
Radebe 600.00
James 500.00
Ramoraz 400.00
Williams 500.00

 SELECT * FROM emp WHERE category=’B’;

empno lname fname category rate
 SELECT * FROM emp WHERE rate <=500;

empno lname fname category rate
 SELECT DISTINCT category FROM emp;

category
A
B
C
B
 SELECT empno, lname, fname FROM emp ORDER BY lname;

Empno lname fname
12 James Pauline
11 Radebe Vincent
16 Ramoraz Charles
17 Williams Monique
 SELECT empno, lname, fname FROM emp ORDER BY lname DESC;

Empno lname fname
17 Williams Monique
16 Ramoraz Charles
11 Radebe Vincent
12 James Pauline

 SELECT * FROM emp WHERE lname LIKE ‘R%’;

 SELECT * FROM emp WHERE lname LIKE ‘Ra%’;
Empno lname fname Category rate
 SELECT * FROM emp WHERE fname LIKE ‘%e’;

 SELECT * FROM emp WHERE fname LIKE ‘%ne’;

 SELECT * FROM emp WHERE lname LIKE ‘%e%’;

 SELECT * FROM emp WHERE lname LIKE ‘_______’;

 ‘_______’ (seven underscore characters = seven characters)

 SELECT COUNT(*) FROM emp;

 COUNT(*) - counts the number of rows
Count(*)
4

 SELECT category , COUNT(*) FROM emp GROUP BY category;

 GROUP BY – group all records for each category
category Count(*)
A 1
B 2
C 1
2. UPDATE – updates data in a database table

 UPDATE emp SET lname=’Mendoza’ WHERE empno=17;
17 Mendoza Monique B 500.00
3. DELETE – deletes data from a database table
 DELETE FROM emp WHERE empno=11;

4. INSERT INTO – inserts new data into a database table
 INSERT INTO emp VALUES (18,’Manucom’,’Eurika’,’A’,600);

18 Manucom Eurika A 600.00

WEEK 17
Database Issues
Data is a valuable resource that must be strictly controlled and managed, as with corporate resource.
Part or all of the corporate data may have strategic importance to an organization and should therefore
be kept secure and confidential.
Integrity
Integrity constraints also contribute to maintaining a secure database system by preventing data from
becoming invalid, and hence giving misleading or incorrect results.
Database Security
- mechanisms that protect the database against international or accidental threats.
Security considerations apply not only to the data held in a database: breaches of security may affect
other parts of the system, which may in turn affect the database.
Transaction Support
Transaction is an action, or series of actions, carried out by a single user or application program, which
reads or updates the contents of the database.
A transaction should always transform the database from one consistent state to another.
Concurrency Control
The process of managing simultaneous operations on the database without having them interferes with
one another.
A major objective in developing a database is to enable many users to access shared data
concurrently. Concurrent access is relatively easy if all users are only reading data, as there is no way
that they can interfere with one another. However, when two or more users are accessing the
database simultaneously and at least one is updating data, there may be interference that can result in
inconsistencies.
Recoverability
Serializiability identifies schedules that maintain the consistency of the database, assuming that none of
the transactions in the schedule fails. An alternative perspective examines the recoverability of
transactions within a schedule. If a transactions fails, the atomicity property requires undo the effects of
the transaction. In addition, the durability property states that once a transaction commits, its changes
cannot be undone.

CS 221 Lecture Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS 221 Lecture Manual

Uploaded by

Copyright:

Available Formats

OUR LADY OF FATIMA UNIVERSITY

COLLEGE OF COMPUTER STUDIES

Traditional File-Based System

Limitations of File-Based Approach

Characteristics of Dbase Approach

1. Self-describing nature of dbase system

CS221 - DATABASE MANAGEMENT SYSTEMS Page 1 of 41

Actors on the Scene

CS221 - DATABASE MANAGEMENT SYSTEMS Page 2 of 41

4. System analysts and application programmer (software engineers)

Intended Uses of DBMS

CS221 - DATABASE MANAGEMENT SYSTEMS Page 3 of 41

Implications of Dbase Approach

1. Potential for enforcing standards

CS221 - DATABASE MANAGEMENT SYSTEMS Page 4 of 41

Three-Level ANSI-SPARC Architecture

User 1 User 2 User n

External level View 1 View 2 ... View n

Conceptual level Conceptual Schema

Internal level Internal Schema

Physical data organization

CS221 - DATABASE MANAGEMENT SYSTEMS Page 5 of 41

1. Data Definition Language (DDL) – used to specify the database schema

Data Manipulation Operations:

CS221 - DATABASE MANAGEMENT SYSTEMS Page 6 of 41

3 Broad Categories of Data Model

1. Object-Based Data Models

2. Record-Based Data Model

CS221 - DATABASE MANAGEMENT SYSTEMS Page 7 of 41

2001 C. Critobal 001 10000

2003 O. Ternida 001 15000

2002 C. Malay 002 13000

2004 N. Felicerta 002 11000

2005 E. Smith 003 12000

2006 R. Distor 003 13500

3. Physical Data Model

CS221 - DATABASE MANAGEMENT SYSTEMS Page 8 of 41

CS 221 – DATABASE MANAGEMENT SYSTEM Page 9 of 41

1. Computer-aided software engineering (CASE) tools – Automated tools used to design

CS 221 – DATABASE MANAGEMENT SYSTEM Page 10 of 41

WEEK 3 & WEEK 4

Brief History of the Relational Model

1. Prototype Relational DBMS System R

CS 221 – DATABASE MANAGEMENT SYSTEM Page 11 of 41

Domain – is the set of allowable values for one or more attributes

Attribute Domain Name Meaning Domain Definition

Tuple – is a row of a relation

Degree – the degree of a relation is the number of attributes it contains

Cardinality – the cardinality of a relation is the number of tuples it contains

CS 221 – DATABASE MANAGEMENT SYSTEM Page 12 of 41

Domain – Branch Number, Street Name, City Name, Post Code

CS 221 – DATABASE MANAGEMENT SYSTEM Page 13 of 41

CS 221 – DATABASE MANAGEMENT SYSTEM Page 14 of 41

2 principal rules for the relational model:

CS 221 – DATABASE MANAGEMENT SYSTEM Page 15 of 41

Database planning As a database system is a fundamental

DATABASE APPLICATION LIFE CYCLE

CS 221 – DATABASE MANAGEMENT SYSTEM Page 16 of 41

CS 221 – DATABASE MANAGEMENT SYSTEM Page 17 of 41

Approaches to Database Design

CS 221 – DATABASE MANAGEMENT SYSTEM Page 18 of 41

 emphasis on data and not on actions on the data

Entity ( entity symbol)

 A collection of things that share common properties or characteristics