Information Management |

COMP 010
SECOND SEMESTER

UNIT 01: Database Environment and Database Concepts

FILE
DATA
→ A collection of related records
→ It could be structured or unstructured
→ Also referred to as “Tables“
→ Facts, Texts, Graphics, Images, Sound, and
Video segments.

DATABASE
→ An organized collection of logically related
data. Managed by a controlling agent DBMS

INFORMATION
→ Through the information given we can easily make
a decision
→ Data processed to be useful in decision making

DATA HIERARCHY
→ How data is usually stored
METADATA
BIT → Data that describes data
→ The smallest unit of data → Description of the properties or
→ Has only two vales [ 0 , 1 ] characteristics of the data
- Datatype
BYTES
- Field sizes
→ Represents one character
- Allowable values
→ Any special character
- Documentation
→ 8 bits make one byte
→ Values [ A, 1, ?]

FIELD
→ Represents a combination of bytes
→ Make up one aspect of a Business Object
→ Also called as “Column“ or “Attributes“
Example: Student Number, Student Name

DATA NAME
RECORD
→ A combination of related fields → User define
→ Also called as “Row” or “Tuple“ Rules in giving Data Name:
1.) Should be documenting or self-documenting
2.) It is descriptive for its content
3.) No special character except underscore
4.) No embeded space
Information Management |
COMP 010
SECOND SEMESTER

UNIT 01: Database Environment and Database Concepts

DATA TYPE COMPONENTS OF DATABASE ENVIRONMENTT

→ It tell us what type of data you will store in your field
→ It could be Alphabetic, Numeric, or Decimal DATA ADMINISTRATORS
→ They are the one’s who see to it that data is
[Note] VarChar
always available
→ We will use varchar if the content is
varying length SYSTEM DEVELOPERS
→ Char was use mostly for those with fixed → The one’s who created data
length
END USERS
→ The one’s that consumed the data
LENGTH
→ How long is the length that we are going to assign
→ For us to be able to know the length we should know
our data.

MIN-MAX
→ Allowable values
→ Stricter Contraints
→ Identify exactly what values we may just input in
particular field

DESCRIPTION
→ Description of the data (malamang)

TRADITIONAL FILE PROCESSING

DATABASE MANAGEMENT SYSTEM
→ Collection of programs that enable users to create → Stores data in seperate computer files
and maintain a database → System use to store store and manage data that
→ General purpose software system that facilitates the involves each department within organization
processes of; Defining, Constructing, and Sharing having its own set of files
databases among various users and applications. → Often creating data redundancy and data
isolation

DISADVANTAGES OF TRADITIONAL FILE PROCESSING

1.) DATA REDUNDANCY (Duplication of Data)

→ Different systems/programs have seperate
copies of the same data.
- Data integrity may suffer
- Inefficient use of storage spaces

2.) LIMITED DATA SHARING

→ No centralized control of data
Information Management |
COMP 010
SECOND SEMESTER

UNIT 01: Database Environment and Database Concepts

3.) ORGANIZATIONAL CONFLICT
3.) PROGRAM DATA DEPENDENCE
→ Whenever there is any change data the program has → Conflicts in reaching consensus on data definitions
to be updated as well and ownership
→ It leads to;
- excessive programming
THE RANGE OF DATABASE APPLICATIONS
- maintenance
- lengthy development times
1.) PERSONAL DATABASE
→ Standard desktop database
ADVANTAGES OF DATABASE APPROACH
2.) WORKGROUP DATABASE
1.) PROGRAM DATA INDEPENDENCE → Connected to Local Area Network (LAN)
→ Metadata Stored is repository, so applications don’t → <25 users
need to worry about data formats
3.) DEPARTAMENTAL DATABASE
2.) PLANNED DATA REDUNDANCY
→ Connected to Local Area Network (LAN)
→ Leads data to increase its integrity/consistency
→ <25 - 100 users
→ No Duplication except probably if redundancy is
being used for backup purposes 4.) ENTERPRISE DATABASE
→ Connected to Wide Area Network (WAN)
3.) IMPROVED DATA SHARING
→ hundreds of thousand users
→ Different users get different views of data

4.) ENFORCEMENT OF STANDARDS

→ All data access is done in the same way
EVOLUTION OF DATABASE SYSTEMS
5.) IMPROVED DATA QUALITY
→ Constraints, data validation rules FLATFILES (1960's)
→ A database designed around a single table or
6.) BETTER DATA ACCESSIBILITY
file.
→ Use of standard data query language (SQL)
7.) INCREASED PRODUCTIVITY OF APPLICATION HIERARCHICAL (1970's)
DEVELOPMENT → Data model in which the data is organized into
→ Developer can focus on specifics functions a tree-like structure ; confined up to one to
→ Provision of high level productivity tools many relationship.

8.) IMPROVED DECISION SUPPORT NETWORK ( 1970'S )

→ Databases expressly designed for decision support → Much like hierarchical model except that it
applications permitted many to many relationship.

COSTS AND RISKS OF THE DATABASE APPROACH RELATIONAL DATABASE ( 1980'S )

→ Organizes data in the form of tables/entities
1.) UP-FRONT COSTS and establish the relationships between them by
→ Installation management costs and complexity means of common fields;
→ Conversion Costs example:
2.) ON-GOING COSTS - MySQL (opensource)
→ Requires new, specialized personnel - SQL Server
→ Need for explicit backup and recovery - IBM DB2 and Oracel
Information Management |
COMP 010
SECOND SEMESTER

UNIT 01: Database Environment and Database Concepts

OBJECT ORIENTED DTABASE (1990's)

→ Subscribes to a model with information
represented by objects
→ Encapsulates both data and behavior
OBJECT RELATIONAL (1990's)
→ Provide a middle ground between relational data
bases and OODB

NO SQL ( 2000's )
→ New generation of databases that addresses
the specific challenges of Big Data.
→ Mostly used for non-structured data.
example:
- Monggo Do
- Amazon Dynomo DD

OTHER CONCEPTS...

DATA WAREHOUSE
→ Subject oriented, Integrated, Time variant, and
non-volatile collection of data used in support
of management decision making and business
intelligence.

WEB ENABLED DATA

→ Database with web based interface; standard
database facilities but accessed remotely.
Information Management |
COMP 010
SECOND SEMESTER

UNIT 02: DATABASE DEVELOPMENT ACTIVITIES

SYSTEM DEVELOPMENT LIFE CYCLE ANALYSIS
→ It is the phase that a system development undergo
Purpose
→ To analyze the business situation thoroughly to
determine requirements to structure those
requirements, and to select among competing
system features.
→ This is where the detailed analysis is done.

Deliverables
→ The functional specifications for a system that
meet users requirements and is feasible to develop
and implement.
-Doable
Figure 1: System Development Life Cycle -Can be implemented
-Should out way the cause

PLANNING
DESIGN
→ Is generally a high level so you do not go to the → The phase where you create the structure of your
details of what must be done but you know there is database
something that must be done.
Purpose
Purpose → To elicit and structure all information requirements
→ To develop a preliminary understanding of a → To develop all technology and organizational speci
business situation. -fications.
→ How information systems might help solve a Deliverables
problem or make an opportunity possible. → Detailed technical/Functional specifications of all
data, forms, reports, displays, and processing rules
Deliverables → Programs and database structures, technology
→ Written request to study the possible changes purchases, physical site plans, and organizational
to an existing system or the development of a redesigns
new system → Anything technical will happen in design
→ Addresses an information systems solutions to the
business problems or opportunities

[Take Note] ... [Take Note] ...

→ Sometimes people called Deliverables as BOR (
Business Opportunity Report) because BOR are Table 1: DIFFERENCES OF ANALYSIS AND DESIGN
able to create a new application.
→ Output of planning stage - The BOR or written ANALYSIS DESIGN
request for business solution
Where we will determine Where the idea in
the requirements Analysis is executed

More Detailed More structured

 Information Management |
COMP 010
SECOND SEMESTER

UNIT 02: DATABASE DEVELOPMENT ACTIVITIES

IMPLEMENTATION [Take Note] ...
Purpose → An enterprise data model establishes the range
and general contents of organizational databases
→ To write programs
→ If there is business solutions which might be
→ Build data files
probably done, as part of the database activity they
→ Test and Install new system
should know what are the database needs. Which
→ Train users
maybe related to that PLANNING.
→ Finalize documentation
→ Development - test through QA bigger
percentage in developing is Testing ANALYSIS
Deliverables 1.) CONCEPTUAL DATA MODELING (cont’d)
→ Programs that work accurately and to → Develop preliminary conceptual data modeling
specifications documentations and training including entities and relationships
materials → Compare preliminary conceptual data modeling
with enterprise data model
[Take Note] ...
→ Develop detailed conceptual model (data model)
Documentation is important because it helps us to; - Entities
→ For guidelines - Relationships
→ To track process - Attributes
→ To have an idea about the system - Business Rules

[Take Note] ...

MAINTENANCE
→ Here we are doing the ERD or Entity Relationship
Purpose Diagrams
→ To monitor the operation and usefulness of a
system
→ To repair and enhance the system DATABASE DESIGN

Deliverables 1.) CONCEPTUAL DATA MODELING

→ Periodic audits of the system to demonstrate → Includes high level data constructs
whether the system is accurate and still meets → Non-technical names
users need → Represents data from the view point
→ Independent of any technology
ACTIVITIES IN SDLC ( PER STAGE)
[Take Note] See the table below to know the
PLANNING differences between Logical and Physical Data
Modeling
1.) ENTERPRISE MODELING
→ Analyze current data processing
→ Analyze the general business functions and
their database needs.
→ Justify need for new data and databases in
support of business
→ An integrated view of data
→ Produced and consumed across an entire
organization
→ Data Architectural Framework used for
integration enabled the identification of shareable
or redundant data
Information Management |
COMP 010
SECOND SEMESTER

UNIT 02: DATABASE DEVELOPMENT ACTIVITIES

TWO APPROACHES TO DATABASE AND
LOGICAL DATA PHYSICAL DATA
MODEL MODELING INFORMATION SYSTEMS DEVELOPMENT

Includes: Includes:
- Entities (tables) - Tables - Datatypes 1.) WATERFALL
- Attributes (columns/fields) - Columns - Validation Rules
- Keys - Database Trigger
→ System development life cycle
- Relationships (Keys)
- Access Contraints → Detailed, Well-planned development process
→ Time-consuming, but comprehensive
This is more identifying
In physical data model we are → Long Development cycle
- Entities (tables)
adding more to those that we 2.) RAPID APPLICATION DEVELOPMENT
- Attributes (columns/fields)
had identified data types
- Relationships (Keys) → Iterative process of rapidly, repeating analysis,
design, and implementation
→ Repeat certain faces
Use business names for We give more structured to → PROTOTYPING popular RAD method, it repeats
entities and attributes . the attributes and etc...
implementation and maintenance activities with
new prototypes

Use more defined and less

generic specific names for
AGILE SOFTWARE DEVELOPMENT
More business like
- tables - columns
- Scrum - Lean
such as abbreviated column
- Kanban - XP
names limited by DBMS
COREVALUES OF AGILE
Requires a knowledge of the
1.) Individuals and interactions over process
Independent of Technology specific DBMS that will be
used and tools
2.) Working software over comprehensive
documentations
Describes the data in terms of 3.) Customer collaboration over contract
data management technology ---------------------------- negotiation
which will be used 4.) Responding to change over following app

AGILE METHODS MOSTLY FOCUS

1.) Satisfying customers
DATABASE IMPLEMENATION 2.) Develop projects with inspired contributors
→ In terms of processing more on sequel programs 3.) Interactions are best when done in person
back end programs 4.) Software that works is a measure of
→ In terms of documentation more one database process
documentation 5.) Reflect and adapt
→ Install database and convert data from prior
RAD OR AGILE SHOULD BE CONSIDERED:
systems
→ This is really more of fine tuning of the data base 1.) Involves unpredictable or changing
→ The more index file the slower the processing requirements
maybe 2.) If most of the necessary database
→ Analyzes database and databases applications structure already exist
to ensure that evolving information requirements
are met
[Take Note]...
→ Tune database for improvement
→ AGILE prioritize that needs of the customer needs
→ Fix errors
Information Management |
COMP 010
SECOND SEMESTER

UNIT 03: RELATIONAL DATA MODEL

RELATIONAL DATA MODEL
4.) STORED vs DERIVED ATTRIBUTES
→ Represent data in the forms of tables
→ A named two-dimensional table is called a relation
STORED ATTRIBUTES DERIVED ATTRIBUTES
→ Each relation consists of named columns and an
arbitrary number of unnamed rows Physically stored in It could be get from
→ A named column is called attributes database other attributes
→ Each row of a relation corresponds to a record
that constraints data
→ Generally for structured data

[Take Note]...
→ A table is not always a relation but a relation is 5. IDENTIFIER
always a table → It should be constant
→ A relation is a form of table
→ Table is generic but not all table is relation CHARACTERISTIC OF IDENTIFIERS:
→ Must not change value
→ Not Null
CLASSIFICTAION OF ATTRIBUTES → Unique

1.) REQUIRED vs. OPTIONAL ATTRIBUTES [Take Note]...

→ DERIVED ATTRIBUTE is one which computed from ,
IDENTIFIERS is when you provide it you will be able
REQUIRED ATTRIBUTES OPTIONAL ATTRIBUTES to get the value of all other corresponding
attributes related to identifiers
Means it should It’s fine it doesn’t
contain a value have a value
PROPERTIES OF RELATION
1.) It has a unique name
2.) SIMPLE vs. COMPOSITE ATTRIBUTES 2.) No multi-valued allow
3.) Each row is unique
4.) Each attribute has a unique name
SIMPLE ATTRIBUTES COMPOSITE ATTRIBUTES
5.) Sequence of columns and rows is
No need to break Breaking down insignificant
down the information Informations

RELATIONAL KEYS
1.) PRIMARY KEYS
→ An attribute or a combination of attributes
that uniquely identifies each row in a relation
3.) SINGLE VALUED vs. MULTI-VALUED ATTRIBUTES → It is also the IDENTIFIERS

2.) FOREIGN KEYS

SINGLE-VALUED MULTI-VALUED
ATTRIBUTES ATTTIBUTES → Attribute used to establish the relationship
between two-tables
Could only be one Contains many value → A foreign key table always point to the
at one point time primary key of another table
→ Two-Attributes that link to relation
Information Management |
COMP 010
SECOND SEMESTER

UNIT 03: RELATIONAL DATA MODEL

3.) COMPOSITE KEY
→ A key that consists of more than one attributes

INTEGRITY CONSTRAINTS
→ Rules limiting acceptable values and actions
→ Facilitate maintaining the accuracy and
integrity of data

THREE TYPES OF CONSTRAINTS

1.) DOMAIN CONSTRAINTS

→ Set of values that can be assigned to an
attribute. It consists of;
- Domain Name - Data Type
- Meaning - Size
- Allowable Values
→ METADATA defines the domain constraints

2. ENTITY INTEGRITY
→ Ensures that every relation has a valid
primary key.

3. REFERENTIAL INTEGRITY
→ Rule that maintains consistency among the
rows of 2 relationships

[Take Note]...
→ Rule states that if there is a foreign key value must
match a primary key value or the foreign key must
be null
Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

NORMALIZATION
INSERTION ANOMALY ILLUSTRATION
→ Process of analyzing a relation to ensure that it CUSTOMER TABLE
is well formed
→ Involves decomposing relations to produce
smaller, well structured data
→ Formal process for deciding which attributes
should be grouped together in a relation so that
all anomalies are removed
→ If a relation is normalized (well-formed), rows
can be inserted , deleted, or modified without CUSTOMERId
creating anomalies → is our primary key (Pk must never be null)
→ You will Identify all of the data in what →It includes the customers and their car
application that is - put it in one table and you purchase
will determine if how we will break it in to
smaller table
→ Normalization is a logical data modelling
technique used to ensure that data are well
structured from an organization-wide view

[Take Note]...
→ We will deciding if what attribute should be
grouped together in one relation

GOALS OF NORMALIZATION For example: This one supposed to be the other

→ Minimize data redundancy thereby conserving car model that is to be added to our table how
space and avoiding anomalies ever as mentioned .
→ Make it easier to maintain data
→ Provide a better design that is improved
representation of the real world

MODIFICATION OF ANOMALIES
→ Are those that we encounter in tables that are
not normalized.

THREE TYPES OF ANOMALIES There is no customer yet. WE CANNOT add

So it means we can’t add some data in the
1.) INSERTION ANOMALY anything here, because it absence of some
→ Occurs when certain attributes cannot be is not yet purchase by attributes.
inserted into the database without the anybody. In that case, this
presence of other attributes is the example of
INSERTION ANOMALY.
 Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

What we do is to DECOMPOSE this into two or more

tables.
FOREIGN KEY

Table 1: Customer Table Table 2: Car Table [Take Note]...And the Car table has to point to the primary key
Contains the; Contains the; of the other table.The foreign key has to point to the pk of the
-customerId -carId other table. And in the table the carId is pk here so it means it’s
-customerName -Year the foreign key.
-carId -Make
-Model

[Take Note]... The first table must not only contain the
customerId and customerName but the carId as well.
Because this is the purchase of the customer , if we didn’t
include it here we really didn’t know if what he/she purchase.
And adding the carId we will know that this is the one he/she
purchase.

[Take Note]... In this part it shows that it is a foreign key

meaning that it is allowed to have another customer will buy
102. So it’s not unique here. The carId has to be unique because
it is a primary key.
PRIMARY KEY
FOREIGN KEY

[Take Note]... It should be the carId in the customer table. Why

not the carId in the car table? We said that the Foreign Key
(FK) should be a common attribute and as you can see it’s
right the carId is common ( we have the carId in the customer
table we the the carId in car table).

[Take Note]... And this is how we do solve INSERTION

ANOMALY . As you can see we were able add another record
now. You don’t need to have a customerId before you can add
in the car table, because we already have separated table.
 Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

2.) UPDATE ANOMALY this is how we DECOMPOSE it...

→ Exist when one or more instances of
Customer Table Car Table
duplicated data is updated but not all

UPDATE ANOMALY ILLUSTRATION

And when we do that , when we put all the car information to

the other table all the duplicates we may actually remove that
because it’s already in the first 102 and the duplicates may now
be removed.
Primary Key Foreign Key

As you can see here the CarId 102 has been bought by several
customers [ 3 to be specific]. And therefore the information
about the CarId 102 is repeated depending on the times it was
bought, and that’s the redundancy that we would want to
remove.

[Take Note]... Remember one of the goals of Normalization is

also to remove Data Redundancy.

And when we do that , when we put all the car information to

the other table all the duplicates we may actually remove that
1 MILLION
because it’s already in the first 102 [CustomerId No. 1] and the
duplicates may now be removed.

1 MILLION

Sometimes, when we would want also to update this instances

of duplicated data we might miss to update some instance. Like,
we may probably update the 1st one to 1M as well as the 2nd So how do we now reference - For example this customer
one. But we might not probably update the 3rd one. And how {CustomerId No. 4] so since this one [carId] is your foreign key
much more if there are more. This is just only 6 but in reality and [customerId] is our primary key
there could be more. And that’s what Update Anomaly is , you
are able to update some but not all these are supposed to be
same record data but it is having decrepancy because we were
not able to update all.
 Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

PRIMARY KEY FOREIGN KEY

The CustId No. 4 can refer to the record of CustId No. 1. If it

wants to know the details of carId 102 because it is just the
same. You don’t need to have specific record for each of those
purchase .

If it has the same carId number even if it’s ten you don’t need to
update it individually since you can get all the information just
by referring to one carId. Primary key: EmpID, EmpName, Address
Foreign key: DeptID
3.) DELETION ANOMALY Another PK: DeptID, DeptName, DeptMgr
→ Exist when certain attributes are lost because Just like what we did earlier we do not leave the DepartmentID
of the deletion of other attributes out of the Employee table because that is the information as to
→ We have to delete data, but int the process where or what department the employee belong. If we don’t
you are also deleting other data which are include the Department ID we will loose that information.
not supposed to be deleted
This is how we Decompose it...
FOR EXAMPLE:

So even if we delete this record, we keep the department where

the employee who resigned belongs.
For example, Chigusa Mami resigned so we have to delete her
record. In the process of deleting her record, we will be also We are also able to remove the redundancy. For example is the
deleting the department information where she belongs. But D02 and D01 in table 2 we can remove it since it already have
the department information is not supposed to be deleted. the record in table 1.
Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

DEFINITIONS... PARTIAL FUNCTIONAL DEPENDENCY

→ When a non-key attribute is functionally dependent on part
FUNCTIONAL DEPENDENCY (but not all) of the primary key.
→ Also describe this as relationship where knowing the value
of one attribute (or a set of attributes) is enough to tell you Take Note ... Is functionally dependent but not all of the
the value of another attribute (or a set of attributes) in primary key. The primary key we’re talking about this is
the same table. composite key. Because as it said here on part but not all
which means the primary key has many attributes attach to it
Examples:
so it means it’s more than one attribute that comprise the
SSS No. → EmpName, EmpContri...
primary key so it might be composite.
Bank Account No. → CustName, Amount of Deposit...
Take a look at this table
If you know the SSS number of a person. You will able
to retrieve the employees name, employees
contribution, the company where the employee work
for at least in the private sector. You will know all of
these. Given just one attribute [SSS No.] . And same in
the bank account no. you will able to know the
customer name, amount of deposit and etc... by the
one given attribute [ BANK ACCOUNT NO.].

This table contains the flight number, flight date, from, to, and
No. of passengers.

SSS No. → EmpName, EmpContri...

PRIMARY KEY FOREIGN KEY

Bank Account No. → CustName, Amount of Deposit...

EmpName, EmpContri... is fully depedent to SSS No.

CustName, Amount of Deposit... is fully dependent to
Bank Account No.

Take Note ... Primary key is being describe here. Because

just like what we talk earlier a functional dependency is
unique. And if we have more than one attribute we called it
Composite Primary Key.
The primary key in this table is the 2 attributes which the flight
Number and Flight date. It is not allowed that its only the
Flight Number because it could not be unique and it’s also
not allowed that it’s only Flight date because there could be
so many flights. But the combination of the flight number and
flight date would give us a unique primary key. So even if you
have another flight number but different flight date this is still
unique. The combination becomes unique.
Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

TRANSITIVE DEPENDENCY
→ Functional dependency between the primary key and
one or more non-key attributes
→ Dependent on the primary key via another non-key
attribute

If we have a primary key A and a non-key domain B and C

where is C is more dependent on B than A and B is directly
dependent on A, then C can be considered as transitively
dependent on A.
Non-Key Attributes
→ Are those which are
not part of the primary
key

This mean if we have a primary key [ DEPTId] and a non-key

domain [MgrID] and [MgrName] is more dependent on
[MgrId] than [DeptId] and [MgrId] is directly dependent on
[DeptID], Then [MgrName] can be considered transitively
dependent on DeptID.

Take Note ... If you’re looking for transitive dependency the

non-key attribute in the table it can be a primary key if
probably group only with the other non-key attributes.
Question: Meron ba dito sa non-primary key which are partial
dependent? And if yes which part?
STEPS IN NORMALIZATION
Answer: From and To are partially dependent on the Flight
Number. Flight number is always referring to a flight → Normalization can be accomplished in stages, each of
from manila to kuala lumpur. Leaving in Manila at which corresponds to a normal form.
2:10 and arriving in kuala lumpur at 5:50. Basta
sinabing Flight Number UA36 you will know where
associated the flight is.
1.) FIRST NORMAL FORM
→ Any multivalued attribute also called as repeating
Question: Is the No. of passengers a partial dependency and
groups have been removed.
if it is, of what attribute? Is is a partial or full
dependency 2.) SECOND NORMAL FORM
Answer: It is not a partial dependency, it is a full → Any partial functional dependencies have been
dependency. Why? Because you need both flight number and removed
flight date for you to know the No. of passengers. You can’t
ask if how many is the passenger in Flight number UA36 3.) THIRD NORMAL FORM
because you will not able to know if it’s 200 or 190 or more
→ Any transitive dependencies have been removed
because you just ask the flight no. and there’s so many flights
in that flight no.
Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

Table with multi-valued attributes: In 1st Normal Formal

Say this is a manual form

Primary Key: OrderId, and Product Id

Non-key Attributes: Order Date, Cust ID, Customer Name,
Customer Address, Product Description, Product Finish, Unit
Price, and Order Quantity.
Partially Dependent in Order Id: Order Data, Cust ID,
Customer Name, and Customer Address.

Partially Dependent in ProdID: Product Description,

Product Finish, and Unit Price

And this how we will do that. Nilagay natin sa ibang record

Table with multi-valued attributes: yung bawat product ng order Id. Kanina isa lang ‘yung record
Not in 1st Normal Formal ng 1006 ngayon naging tatlo na. ‘Yung 1007 naman kanina ay
isa ngayon ay naging dalawang record na. So it means, for
this particular record we just have one value for product id ni 7
, isa lang din ang product description ni table, product finish,
unit price and ordered quantity. Tapos nilagay sa ibang record
‘yung 2nd product Id, ang ibigsabihin nito dito sa record na ‘to
isa lang ang product Id, product description ni table, product
finish, unit price and ordered quantity. Pero it has a lot of
redundancy since we repeated the record 3 times.

Take Note ... Order Id 1006 and 1007 is different record

Multivalued

And for order 1006 you will notice that the it has a 3 product
Id which is [ 7, 5, and 4]. It also has 3 product description
which is [ Tea table, TV stand, and Porch Swing] and so
with the rest. And in the order 1007 it has 2 values in proId,
PorDescri and etc... And this is what we need to do - to
remove all the multivalued attributes.
Information Management |
COMP 010
SECOND SEMESTER

UNIT 04: NORMALIZATION

CustomerId here points to the pk of the customer table

PRIMARY KEY FOREIGN KEY
and notice that it is also the foreign and primary key here
and it is allowed. And this order Ip will point to the Pk of the
order table or in the order ID is unique. And itong product
Id na ‘to ay will point to the PK of the product table where
the product table is unique.
Second Normal Form

Transitive Dependencies: Customer Name, and

Customer Address and they are dependent on Customer Id
[a non-key attribute as well] which is Customer ID is
dependent on Order ID [which is a primary key] OTHER WAY TO SHOW HOW TO WRITE;

Going to 3rd Normal Form UNF

ORDERPRODUCT(orderid,orderdate,custid,custname,custad
rs,{prodid,proddesc,prodfin,uprice,qty})

1NF
ORDERPRODUCT(orderid,orderdate,custid,custname,custad
rs,prodid,proddesc,prodfin,uprice,qty)
First Table: [primary key] Order Id [attributes] Order
date, then it has [foreign key] which is the Customer ID

Second Table: [primary key] Customer Id [attributes]

Customer Name and Customer Address

Third Normal Form

Information Management |
COMP 010
SECOND SEMESTER

UNIT 05: ERD

Business Rules
Relationship Characteristics
Define or constrain how data is handled in an
organization. A. Degree
Govern creation, update, and removal of data Number of entities involved:
in an information system. Unary: Self-relationship (e.g., PERSON marries PERSON)
Must be documented during the analysis phase Binary: Two entities (most common)
of database design. Ternary: Three entities

B. Cardinality
Data Modeling
Describes how many instances of one entity relate to
Process of documenting rules and policies that govern
another.
data.
One-to-One (1:1)
Produces a data model, often represented as an ERD.
One-to-Many (1:M)
ERD = Graphical representation of data and
Many-to-Many (M:N)
relationships.

Minimum Cardinality:
Components of ERD
→ 0 = optional, 1 = mandatory
A. Entity
Maximum Cardinality:
A real-world object or concept (e.g., STUDENT, BOOK,
→ The maximum number of entity instances that can be
SALE).
associated.
Entity Type: Group of similar entities (e.g., all students).
Entity Instance: One particular occurrence (e.g., Student
Symbols Example:
#123).
|| — Mandatory one
|O — Optional one
B. Attribute
|< — Mandatory many
Characteristics or properties of an entity (e.g.,
O< — Optional many
Student_ID, Name).
Each attribute holds data about a specific trait.
Strong vs. Weak Entities
C. Relationship
Association between entities (e.g., EMPLOYEE completes Strong Entity:
COURSE). Exists independently.
Can be: Has a unique identifier.
Drawn with a single-line rectangle.
- Relationship Type (general form of the relationship)
- Relationship Instance (a single, specific Weak Entity:
connection) Depends on a strong entity.
Has no unique identifier.
Naming Relationships Drawn with a double-line rectangle.
Needs a foreign key + partial key to be identified.
Use verb phrases in present tense (e.g., "Assigned_to",
"Manages").
Example:
Avoid vague terms like "Has".
ORDER (strong) → ORDER_ITEM (weak)
EMPLOYEE (strong) → DEPENDENT (weak)
Information Management |
COMP 010
SECOND SEMESTER

UNIT 05: ERD

Associative Entities

A relationship turned into an entity when it:

Has its own attributes
Participates in other relationships
Represents a M:N relationship

Example: Instead of just:

EMPLOYEE completes COURSE

Convert to:
EMPLOYEE – CERTIFICATE – COURSE Where
CERTIFICATE stores DateCompleted, Grade,
etc.

When to Use Associative Entities

Use when:
The relationship involves many-to-many.
The relationship has attributes of its own.
It needs to participate in other relationships.