REVIEWER IN INFORMATION MANAGEMENT  Requires a Database Management System

(DBMS)
MOUDLE 1 – DATABASE ENVIRONMENT AND
DEVELOPMENT PROCESS Database Management System
Definitions  A software system that is used to create,
maintain, and provide controlled access to user
 Database: organized collection of logically
databases
related data
 Data: stored representations of meaningful
objects and event
o Structured: numbers, text, dates
o Unstructured: images, video,
documents
 Information: data processed to increase
knowledge in the person using the data
 Metadata: data that describes the properties Advantages of the Database Approach
and context of user data
1. Program-data independence
Disadvantages of File Processing 2. Planned data redundancy
 Program-Data Dependence 3. Improved data consistency
o All programs maintain metadata for 4. Improved data sharing
each file they use 5. Increased application development productivity
 Duplication of Data 6. Enforcement of standards
o Different systems/programs have 7. Improved data quality
separate copies of the same data 8. Improved data accessibility and responsiveness
9. Reduced program maintenance
 Limited Data Sharing
10. Improved decision support
o No centralized control of data
 Lengthy Development Times Cost and Risks of the Database Approach
o Programmers must design their own file
formats 1. New, specialized personnel
2. Installation and management cost and
 Excessive Program Maintenance
o 80% of Information Systems budget complexity
3. Conversion costs
4. Need for explicit backup and recovery
5. Organizational conflict

Elements of the Database Approach

 Data models
o Graphical system capturing nature and
relationship of data
o Enterprise Data Model
 High-level entities and
relationships for the
organization
SOLUTION: The DATABASE Approach o Project Data Model
 More detailed view, matching
 Central repository of shared data
data structure in database or
 Data is managed by a controlling agent data warehouse
 Stored in a standardized, convenient form
  Entities o Define database during development of
o Noun from describing a person, place, initial prototype
object, event, or concept o Repeat implementation and
o Composed of attributes maintenance activities with new
 Relationships prototype versions
o Link between entities
Systems Development Life Cycle
o Usually one-to-many (1:M) or many-to-
many (M:N)
 Relationship Databases
o Database technology involving tables
(relations) representing entities and
primary/foreign keys representing
relationships

Components of the Database Environment

 CASE Tools
o Computer-aided Software Engineering
1. Planning
 Repository
o Purpose – Preliminary understanding
o Centralized storehouse of metadata
o Deliverable – Request for study
 Database Management System (DBMS)
o Database Activity – Enterprise
o Software for managing the database
modeling and early conceptual data
 Database
modeling
o Storehouse of the data
2. Analysis
 Application Programs
o Purpose – Thorough requirements
o Software using the data
analysis and structuring
 User Interface o Deliverable – Functional system
o Text and graphical displays to users specifications
 Data/Database Administrators o Database Activity – Thorough and
o Personnel responsible for maintaining integrated conceptual data modeling
the database 3. Logical Design
 System Developers o Purpose – information requirements
o Personnel responsible for designing elicitation and structure
databases and software o Deliverable – Detailed design
 End Users specifications
o People who use the applications and o Database Activity – Logical database
databases design (transactions, forms, displays,
Two Approaches to Database and IS Development views, data integrity, and security)
4. Physical Design
 SDLC (System Development Life Cycle) o Purpose – Develop technology and
o Detailed, well-planned development organizational specifications
process o Deliverable – Program/data structures,
o Time-consuming, but comprehensive technology purchases, organization
o Long development cycle redesigns
 Prototyping o Database Activity – Physical database
o Rapid Application Development (RAD) design (define database to DBMS,
o Cursory attempt at conceptual data physical data organization, database
modeling processing programs)
 5. Implementation
o Purpose – Programming, testing,
training, installation, documenting
o Deliverable – Operational programs,
documentation, training materials
o Database Activity – Database
implementation, including coded
programs, documentations, installation
and conversion
6. Maintenance
o Purpose - Monitor, repair, enhance
o Deliverable – Periodic adults
o Database Activity – Database
maintenance, performance analysis and
tuning, error corrections

Prototyping Database Methodology

Managing Projects

 Project
o A planned undertaking of related
activities to reach an objective that has
a beginning and an end
o Initiated and planned in the planning
stage of SDLC
o Executed during analysis, design, and
implementation
Database Schema o Closed at the end of implementation
 External Schema Managing Projects: People Involved
o User views
o Subsets of conceptual schema  Business analysts
o Can be determined from business-  Systems analysts
function/data entity matrices  Database analysts and data modelers
o DBA determines schema for different  Data/Database administrators
users  Project managers
o Different people have different views of  Users
the database, these are the external  Programmers
schema  Database architects
 Conceptual Schema  Other technical experts
o E-R models
Evolution of Database
 Internal Schema
o Logical structures  Driven by four main objectives:
o Physical structures o Need for program-data independence->
o The internal schema is the underlying reduced maintenance
design and implementation o Desire to manage more complex data
types and structures
o Ease of data access for less technical
personnel
 o Need for more powerful decision Multitiered client/server database architecture
support platforms

Evolution of Database Technologies

Transcribed from image above

1. Flat Files (1960 – 2010)

2. Hierarchical (1968? – 2010)
3. Network (1970 – 2000) MODULE 2 – MODELING DATA IN THE ORGANIZATION
4. Relational (1980 – 2010)
Data
5. Data warehousing (1987? – 2010)
6. Object-oriented (1990 - 2010)  Explanation of a term or fact
7. Object relational (1992? – 2010) o Term – word or phrase with specific
meaning
o Fact – association between two or more
terms
 Guidelines for good data definition
o A concise description of essential data
meaning
o Gathered in conjunction with systems
requirements
o Accompanied by diagrams
The Range of Database Applications o Achieved by consensus, and iteratively
refined
 Personal databases
 Multitier client/server databases A Good Data Name Is:
 Enterprise applications  Related to business, not technical,
o Enterprise resource planning (ERP) characteristics
systems  Meaningful and self-documenting
o Data warehousing implementation  Unique
Summary of Database Applications  Readable
 Composed of words from an approved list
 Repeatable
 Written in standard syntax
E-R Model Constructs Data Modeler Drawing Conventions (Barker Notation)

 Entities:  Entities are represented by softboxes

o Entity instance–person, place, object,  Entity names go in the softboxes
event, concept (often corresponds to a  Entity names are always singular and written in
row in a table) capital letters
o Entity Type–collection of entities (often  Attributes are listed under entity names
corresponds to a table  Mandatory attributes are marked with an
 Relationships: asterisk: “*”
o Relationship instance–link between  Optional attributes are marked with a circle: “o”
entities (corresponds to primary key-  Unique identifiers are marked with a hash sign:
foreign key equivalencies in related “#
tables)
o Relationship type–category of
relationship…link between entity types
 Attributes:
o Properties or characteristics of an entity
or relationship type (often corresponds
to a field in a table

Business Rules

 Are statements that define or constrain some

aspect of the business
 Are derived from policies, procedures, events,
functions
 Assert business structure
 Control/influence business behavior
Sample E-R Diagram
 Are expressed in terms familiar to end users
 Are automated through DBMS software

A Good Business Rule is:

 Declarative– what, not how

 Precise– clear, agreed-upon meaning
 Atomic– one statement
 Consistent– internally and externally
 Expressible– structured, natural language
 Distinct– non-redundant
 Business-oriented– understood by business
people
Basic E-R Notation
Entities and Attributes  Weak entity
o dependent on a strong entity
 Entity – a person, a place, an object, an event,
(identifying owner)…cannot exist on its
or a concept in the user environment about
own
which the organization wishes to maintain data
o does not have a unique identifier (only
 Entity type – a collection of entities that share
a partial identifier)
common properties or characteristics
o entity box and partial identifier have
 Entity instance – A single occurrence of an double lines
entity type
 Identifying relationship
 Attribute–property or characteristic of an entity o links strong entities to weak entities
or relationship type

Example of a weak identity and its identifying relationship

Naming Attributes

 Name should be a singular noun or noun phrase

 Name should be unique
 Name should follow a standard format
o e.g. [Entity type name { [ Qualifier ] } ]
Class
 Similar attributes of different entity types
should use the same qualifiers and classes

Defining Attributes

 State what the attribute is and possibly why it is

important
 Make it clear what is and is not included in the
attribute’s value
 Include aliases in documentation
 State source of values
 Specify required vs. optional
Strong vs. Weak Entities, and Identifying Relationships  State min and max number of occurrences
allowed
 Strong entity
 Indicate relationships with other attributes
o exists independently of other types of
entities Classification of Attributes
o has its own unique identifier
• Required versus Optional Attributes
 identifier underlined with single
• Simple versus Composite Attribute
line
• Single-Valued versus Multivalued Attribute
• Stored versus Derived Attributes
• Identifier Attributes
Required vs. Optional Attributes Identifiers (Keys)

o Required – must have a value for every  Identifier (Key)

entity (or relationship) instance with which o An attribute (or combination of
it is associated attributes) that uniquely identifies
o Optional – may not have a value for every individual instances of an entity type
entity (or relationship) instance with which o Simple vs. Composite Identifier
it is associated o Candidate identifier – an attribute that
could be a key… satisfies the
requirement for being an identifier

Criteria for Identifiers

• Choose Identifiers that

o Will not change in value
o Will not be null
• Avoid intelligent identifiers (e.g., containing
locations or people that might change)
• Substitute new, simple keys for long, composite
Simple vs. Composite Attributes keys
o Composite attribute – an attribute that has
meaningful component parts (attributes)

o
Multi-valued and Derived Attributes
Simple and Composite Identifier Attributes
o Multivalued – may take on more than one
value for a given entity (or relationship) Modeling Relationships
instance
• Relationship Types vs. Relationship Instances
o Derived – values can be calculated from
o The relationship type is modeled as
related attribute values (not physically
lines between entity types…the
stored in the database)
instance is between specific entity
instances
• Relationships can have attributes
o These describe features pertaining to
the association between the entities in
the relationship
• Two entities can have more than one type of
relationship between them (multiple
relationships)
• Associative Entity
o combination of relationship and entity

Degree of Relationships

• Degree of a relationship is the number of entity

types that participate in it
 o Unary Relationship Cardinality of Relationships
o Binary Relationship
• One-to-One
o Ternary Relationship
o Each entity in the relationship will have
exactly one related entity
• One-to-Many
o An entity on one side of the relationship
can have many related entities, but an
entity on the other side will have a
maximum of one related entity
• Many-to-Many
o Entities on both sides of the
relationship can have many related
entities on the other side

Cardinality Constraints

Degree of Relationships • Cardinality Constraint

o the number of instances of one entity
Examples of Relationships of Different Degrees that can or must be associated with
• Unary Relationship each instance of another entity
• Minimum Cardinality
o If zero, then optional
o If one or more, then mandatory
• Maximum Cardinality
o The maximum number

Examples of Cardinality Constraints

• Mandatory cardinalities
• Binary Relationship

• Ternary Relationship
• One optional, one mandatory
 • Optional cardinalities Associative Entities

• An entity has attributes

• A relationship links entities together
• When should a relationship with attributes
instead be an associative entity?
o All relationships for the associative
entity should be many
o The associative entity could have
Examples of multiple relationships meaning independent of the other
entities
• Employees and departments
o The associative entity preferably has a
unique identifier, and should also have
other attributes
o The associative entity may participate in
other relationships other than the
entities of the associated relationship
o Ternary relationships should be
converted to associative entities
• Associative entity is like a relationship with an
attribute, but it is also considered to be an
entity in its own right

• Professors and courses (fixed lower limit MODULE 3 – ENHANCED ER MODEL

constraint)
Supertypes and Subtypes

• Enhanced ER model
o extends original ER model with new
modeling constructs
• Subtype
o A subgrouping of the entities in an
entity type that has attributes distinct
from those in other subgroupings
• Supertype
o A generic entity type that has a
relationship with one or more subtypes
Multivalued attributes can be represented as • Attribute Inheritance
relationships o Subtype entities inherit values of all
attributes of the supertype
o An instance of a subtype is also an
instance of the supertype
 Example of Generalization

• Three entity types: CAR, TRUCK, and

MOTORCYCLE

All three types have common attributes

• Generalization to VEHICLE supertype

Basic notation for supertype/subtype notation

Example of specialization
Basic notation for supertype/subtype

Relationships and Subtypes • Entity type: PART

• Relationships at the supertype level indicate

that all subtypes will participate in the
relationship
• The instances of a subtype may participate in a
relationship unique to that subtype. In this
situation, the relationship is shown at the
subtype level

Generalization and Specialization

• Specialization to MANUFACTURED PART and
• Generalization PURCHASED PART
o The process of defining a more general
entity type from a set of more
specialized entity types.
o BOTTOM-UP
• Specialization
o The process of defining one or more
subtypes of the supertype and forming
supertype/subtype relationships.
o TOP-DOWN
Constraints in Supertype/Subtype Relationships o Overlap Rule
 An instance of the supertype
• Completeness Constraints:
could be more than one of the
o Whether an instance of a supertype
subtypes
must also be a member of at least one
subtype
o Total Specialization Rule:
 Yes (double line)
 A rule that specifies that each
entity instance of a supertype
must be a member of some
subtype in the relationship.
o Partial Specialization Rule
 No (single line)
 A rule that specifies that an Example of Disjoint Rule
entity instance of a supertype is
allowed not to belong to any
subtype.

Example of Overlap Rule

• Subtype Discriminator
o An attribute of the supertype whose
values determine the target subtype(s)
Example of Total Specialization Rule o Disjoint
 a simple attribute with
alternative values to indicate
the possible subtypes
o Overlapping
 a composite attribute whose
subparts pertain to different
subtypes.
 Each subpart contains a
Boolean value to indicate
whether or not the instance
belongs to the associated
Example of Partial Specialization Rule subtype

• Disjointness Constraints
o Whether an instance of a supertype
may simultaneously be a member of
two (or more) subtypes
o Disjoint Rule
 An instance of the supertype
can be only ONE of the
subtypes
 Example of Disjoint (Subtype Discriminator)

Figure 3-13a Possible entity clusters for Pine Valley Furniture

in Microsoft Visio

Related group of entities could become clusters

Example of Overlap (Subtype Discriminator)

Figure 3-13b EER diagram of PVF entity clusters

Example of supertype/subtype hierarchy

Entity Clusters

• EER diagrams are difficult to read when there

are too many entities and relationships.
• Solution
o Group entities and relationships into
entity clusters.
• Entity cluster
o Set of one or more entity types and
associated relationships grouped into a Figure 3-14 Manufacturing entity cluster
single abstract entity type
MODULE 4 – LOGICAL DATABASE DESIGN

Relational Data Model 

 The relational data model represents data in Relation
the form of tables.
 Requirements for a table to qualify as a
Components of Relational Model relation:
o It must have a unique name.
 Data structure
o Every attribute value must be atomic
o Tables (relations), rows, columns
(not multivalued, not composite).
 Data manipulation
o Every row must be unique (can’t have
o Powerful SQL operations for retrieving
two rows with exactly the same values
and modifying data
for all their fields).
 Data integrity
o Attributes (columns) in tables must
o Mechanisms for implementing business
have unique names.
rules that maintain integrity of
o The order of the columns must be
manipulated data
irrelevant.
Relation o The order of the rows must be
irrelevant
 A relation is a named, two-dimensional table of  All relations are in 1st Normal Form
data.
 Relations (tables) correspond with entity types
 A table consists of rows (records) and columns and with many-to-many relationship types.
(attribute or field)
 Rows correspond with entity instances and with
Relational Keys many-to many relationship instances.
 Columns correspond with attributes.
 We must be able to store and retrieve a row of  The word relation (in relational database) is
data in a relation, based on the data values NOT the same as the word relationship (in E-R
stored in that row. model)
 Goal: every relation must have primary keys
 A primary key is an attribute or a combination Removing multivalued attributes from tables
of attributes that uniquely identifies each row
 The second property of relations listed in the
in a relation
preceding section states that no multivalued
 We designate a primary key by underlining the attributes are allowed in a relation.
attribute name(s).
 Thus, a table that contains one or more
 For example, the primary key for the relation multivalued attributes is not a relation.
EMPLOYEE1 is EmpID. Notice that this attribute
is underlined in Figure 4-1. In shorthand
notation, we express this relation as follows:


 A foreign key is an attribute (possibly
composite) in a relation that serves as the
primary key of another relation.
 For example, consider the relations EMPLOYEE1
and DEPARTMENT


Integrity Constraints correspond with the “parent”
side row to be deleted
1. Domain Constraints
 Set-to-Null – set the foreign key
o Allowable values for an attribute (See
in the dependent side to null if
Table 4-1). A domain definition usually
deleting from the parent side →
consists of the following components:
not allowed for weak entities
domain name, meaning, data type, size
o Referential integrity constraints are
(or length), and allowable values or
implemented with foreign key to
allowable range (if applicable).
primary key references.

Transforming EER Diagrams into Relations (may mga

example images sa module na di ko na sinama kasi
sobrang dami check nyo nalang dun)

 Mapping Regular Entities to Relations

o Simple attributes: E-R attributes map
directly onto the relation
o Composite attributes: Use only their
simple, component attributes
o Multivalued Attribute: Becomes a
2. Entity Integrity separate relation with a foreign key
o The relational data model allows us to taken from the superior entity
assign a null value to an attribute in the  Mapping Weak Entities
just described situations. A null is a o Becomes a separate relation with a
value that may be assigned to an foreign key taken from the superior
attribute when no other value applies entity
or when the applicable value is o Primary key composed of:
unknown.  Partial identifier of weak entity
o No primary key attribute may be null.  Primary key of identifying
All primary key fields MUST have data. relation (strong entity)
3. Referential Integrity  Mapping Binary Relationships
o Rule states that any foreign key value o One-to-Many – Primary key on the one
(on the relation of the many side) MUST side becomes a foreign key on the many
match a primary key value in the side
relation of the one side. (Or the foreign o Many-to-Many – Create a new relation
key can be null) with the primary keys of the two
entities as its primary key
o One-to-One – Primary key on
mandatory side becomes a foreign key
on optional side
 Mapping Associative Entities
o Identifier Not Assigned
 Default primary key for the
o association relation is
o For example: Delete Rules
composed of the primary keys
 Restrict –don’t allow delete of of the two entities (as in M:N
“parent” side if related rows
relationship)
exist in “dependent” side o Identifier Assigned
 Cascade – automatically delete  It is natural and familiar to end-
“dependent” side rows that users
  Default identifier may not be Data Normalization
unique
 Primarily a tool to validate and improve a logical
 Mapping Unary Relationships
design so that it satisfies certain constraints
o One-to-Many
that avoid unnecessary duplication of data
 Recursive foreign key in the
 The process of decomposing relations with
same relation
anomalies to produce smaller, well-structured
o Many-to-Many
relations
 Two relations:
 One for the entity type Well-Structured Relations
 One for an associative
relation in which the  A relation that contains minimal data
primary key has two redundancy and allows users to insert, delete,
attributes, both taken and update rows without causing data
from the primary key of inconsistencies
the entity  Goal is to avoid anomalies
 Mapping Ternary (and n-ary) Relationships  Types of Anomalies:
o One relation for each entity and one for o Insertion Anomaly
the associative entity  Adding new rows forces user to
o Associative entity has foreign keys to create duplicate data
each entity in the relationship o Deletion Anomaly
 Mapping Supertype/Subtype Relationships  Deleting rows may cause a loss
o One relation for supertype and for each of data that would be needed
subtype for other future rows
o Supertype attributes (including o Modification Anomaly
identifier and subtype discriminator) go  Changing data in a row forces
into supertype relation changes to other rows because
o Subtype attributes go into each of duplication
subtype; primary key of supertype  General rule of thumb: A table should not
relation also becomes primary key of pertain to more than one entity type
subtype relation  Why do these anomalies exist?
o 1:1 relationship established between o Because there are two themes (entity
supertype and each subtype, with types) in this one relation. This results
supertype as primary table in data duplication and an unnecessary
dependency between the entities
Summary of EER-to-Relational Transformations
Steps in Normalization
Functional Dependencies and Keys Determinants

 For example, consider the relation EMP COURSE  The attribute on the left side of the arrow in a
(EmpID, CourseTitle, DateCompleted) shown in functional dependency is called a determinant
Figure 4-7. We represent the functional  SSN, VIN, and ISBN are determinants in the
dependency in this relation as follows: preceding three examples. In the EMP COURSE
relation (Figure 4-7), the combination of EmpID
and CourseTitle is a determinant.

 The comma between EmpID and CourseTitle
stands for the logical AND operator, because 
DateCompleted is functionally dependent on
Candidate Keys
EmpID and CourseTitle in combination.
 The functional dependency in this statement  Candidate key is an attribute, or combination of
implies that the date when a course is attributes, that uniquely identifies a row in a
completed is determined by the identity of the relation.
employee and the title of the course  A candidate key must satisfy the following
 Typical examples of functional dependencies properties, which are a subset of the six
are the following: properties of a relation previously listed:
o SSN → Name, Address, Birthdate o Unique identification
 A person’s name, address, and  For every row, the value of the
birth date are functionally key must uniquely identify that
dependent on that person’s row. This property implies that
Social Security number (in other each nonkey attribute is
words, there can be only one functionally dependent on that
Name, one Address, and one key.
Birthdate for each SSN). o Nonredundancy
o VIN → Make, Model, Color  No attribute in the key can be
 The make, model, and the deleted without destroying the
original color of a vehicle are property of unique
functionally dependent on the identification.
vehicle identification number
(as above, there can be only
one value of Make, Model, and
Color associated with each
VIN).
o ISBN → Title, FirstAuthorName,
Publisher
 The title of a book, the name of
the first author, and the
publisher are functionally
dependent on the book’s
international standard book
number (ISBN)
First Normal Form

 No multivalued attributes
 Every attribute value is atomic
 Fig. 4-25 is not in 1st Normal Form (multivalued
attributes) ➔ it is not a relation.
 Fig. 4-26 is in 1st Normal form.
 All relations are in 1st Normal Form.

Second Normal Form

 1NF PLUS every non-key attribute is fully

functionally dependent on the ENTIRE primary
key
o Every non-key attribute must be
defined by the entire key, not by only
part of the key
o No partial functional dependencies
Anomalies in this Table (Figure 4-26)

 Insertion
o If new product is ordered for order
1007 of existing customer, customer
data must be re-entered, causing
duplication
 Deletion
o If we delete the Dining Table from
Order 1006, we lose information
concerning this item’s finish and price
 Update
o Changing the price of product ID 4
requires update in multiple records
 Why do these anomalies exist?
o Because there are multiple themes
(entity types) in one relation. This
results in duplication and an
unnecessary dependency between the
entities.
Third Normal Form

 2NF PLUS no transitive dependencies

(functional dependencies on non-primary-key
attributes)
 Note: This is called transitive, because the
primary key is a determinant for another
attribute, which in turn is a determinant for a
third
 Solution: Non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new
table and stays as foreign key in the old table

PUTANGINA ANG DAMI NANAMAN REREBYUHIN

ASDASDASDASDASDAS