Database Basics

<Trainer Info>

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Agenda

 Database Concepts
 Entity Relationship Modeling

 Normalization

 Tips for DB Designing

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Data Model
A data model is a “description” of both a container for
data and a methodology for storing and retrieving data
from container.

“you can think of a data model as the infrastructure of the

data organizations, in other words, the way data is
presented to the user.”

Data model is…..

Not a thing
You cannot touch it
Data model are abstractions, mathematical algorithms &
Concepts.
You can not touch a data model.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 3 04e-BM/NS/HDCV/FSOFT v2/4

 Database Systems Models

Data base management systems follow particular

models (known as database models) to store and
manipulate
data. A data base model is characterized by:

1. The way it stores data : STRUCTURE

2. The way data in the

structure are manipulated: OPERATIONS

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 4 04e-BM/NS/HDCV/FSOFT v2/4

 Evolution of Database Model

Limitations
Searching for
records
Data Redundancy
Data Inconsistency •Table
Indexed •Table
•Table
file

Index

FLAT
FILE
Advantages
Data in books
and registers •Overcame limitations
•Compact
•Easy to use
•Accurate
5
©Manual databases
FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 The Relational Database
 “A DBMS that manages data as collection of
tables in which all data relationships are
represented by common values in related
tables.”

 “A DBMS that follows all the twelve rules of

CODD is called RDBMS”

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 TABLE Structure 1/2
Primary
Key
Supplier
SCode SName Quantity City

S1 Kamran 20 Lahore

S2 Zafar 10 Islamabad
Tuple Card
s S3 Azmat 40 Karachi inalit
y
S4 Abdul 34 Lahore

S5 Nasir 25 Islamabad

Attributes
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 TABLE Structure 2/2

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Ex: Instance of Students Relation

Student(studno,name,address)
Schema
Course(courseno,lecturer)

Student(123,Bloggs,Woolton)
(321,Jones,Owens) Instance

sid Name Login age GPA

53666 Jones Jones@ca 18 3.4

53444 smith Smith@ecs 18 3.2
53777 Blake Blake@aa 19 3.8

• Cardinality = 3, arity = 5 , all rows distinct

• Do all values in each column of a relation

instance have to be distinct?
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Relational Database Concepts

Table

Field
CD_ID Title Artist Genre
1 The Wall Pink Floyd Rock
Record 2 Blue Train John Coltrane Jazz
3 Requiem W.A. Mozart Classical

10
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Basic component of a Relation

Tuple:
 The actual data values for the attributes of a relation are
stored in tuples, or rows, of the table.
 It is not necessary for a relation to have rows in order to be
a relation; even if no data exists for the relation
 The relation remains defined with its set of attributes
Attribute:
The term attribute refers to characteristics. This simply
means that what the column contains will be defined by the
attribute of the column
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Examples of Attribute Domains

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 DBMS vs. RDBMS
DBMS RDBMS
The concepts of relationships is It is based on the concept
missing in a DBMS. If it exits it is
very less. Of relationships

Speed of operation is very slow Speed of operation is very Fast

Hardware and Software  Hardware and Software
requirements are minimum requirements are High

Platform used is normally DOS Platform used can be any DOS,

UNIX,VAX,VMS, etc
Uses concept of a file Uses concept of table

DBMS normally use 3GL RDBMS normally use a 4GL

Examples are dBase, FOXBASE, etc Examples are ORACLE, INGRESS,

SQL Server 2000 etc
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Popular RDBMS
 Oracle
 Sybase

 Microsoft SQL Server

 Informix

 Ingress

 DB2

14
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 RDBMS Users

 Database admin
 Database designer
 Developer
 Implementer
 End users.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Database design

 Database design is the process of producing a detailed

data model of a database
 Process of Database Design:
 Determine the relationships between the different
data elements.
 Superimpose a logical structure upon the data on the
basis of these relationships
Database designs also include ER (
Entity-relationship model) diagrams.
An ER diagram is a diagram that helps to design
databases in an efficient way.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Design Process

Real
world Requirement  Survey
 Interview
collection &  Collect requirement
Analysis  Analisys

 Specification Requirement
database

Conceptual  Modelling
design  Design

Conceptual  ER Modelling
model

……..

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
ER Model Overview

 ER Model: high-level data model that is

useful in developing a conceptual design
for a database
 ER Diagram (ERD): one of the first steps
in designing a database
 ERD Elements: entities, relationships, and
attributes

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Sample E-R Diagram

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 19 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Basic E-R Notation

A special
Entity entity that is
symbols also a
relationship

Attribute
Relationship symbols
symbols

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 20 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Attributes

 Attribute - property or characteristic of an

entity type
 Classifications of attributes:
Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attributes
Identifier Attributes

21
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Entity Relationship Modeling
Identifiers (Keys)
 Identifier (Key) - An attribute (or combination of
attributes) that uniquely identifies individual
instances of an entity type
 Simple Key versus Composite Key
 Candidate Key – an attribute that could be a
key…satisfies the requirements for being a key
 Characteristics of Identifiers:
 Will not change in value
 Will not be null
 No intelligent identifiers (e.g. containing locations or
people that might change)
 Substitute new, simple keys for long, composite keys

22
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Entity Relationship Modeling
A composite attribute

An attribute broken
into component parts

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 23 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Simple key attribute

The key is underlined

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 24 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Cardinality of Relationships 1/2
Relationships
 One – to – One: Each entity in the relationship will have

exactly one related entity

 One – to – Many: 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: Entities on both sides of the relationship

can have many related entities on the other side

Cardinality Constraints - the number of instances of one
entity that can or must be associated with each instance of
another entity.
 Minimum Cardinality

 If zero, then optional

 If one or more, then mandatory
 Maximum Cardinality: The maximum number
25
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Entity Relationship Modeling
Cardinality of Relationships 2/2

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 26 04e-BM/NS/HDCV/FSOFT v2/4

 Entity Relationship Modeling
Binary relationships

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 27 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model - Convert ER Models
to Relational schema (DB Design)

Rules for converting ER Model to

relational schema
Basic Conversion Rules

Entity Type Rule

1-M Relationship Rule

M-N Relationship Rule

Identification Dependency Rule

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 1 - Example

CUSTOMER entity type with

simple attributes

CUSTOMER relation

Biến đổi kiểu thực thể thông thường

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 ER Model: DB Design
Rule 2 - Example

Multivalued attribute becomes a

separate relation with foreign key

1–to–many relationship between original

entity and new relation

Convert Multivalue attribute

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 ER Model: DB Design
Rule 3 - Example

EMPLOYEE entity with Manages

relationship

EMPLOYEE relation with recursive foreign

key

Convert Unary relationship one to one

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 3 - Example

Convert binary relationship one to one

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 3 - Example

EMPLOYEE entity with

Manages relationship

EMPLOYEE relation with

recursive foreign key

Convert Unary relationship one to many

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 3 - Example

Note the mandatory one

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality

Convert Binary relationship one to many

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 3 - Example

Bill-of-materials
relationships (M:N)

ITEM and COMPONENT

relations

Convert Unary relationship many to many

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Rule 3 - Example

The Supplies
relationship will need to
become a separate
Composite primary key relation

New intersection
Foreign key relation
Foreign key

Convert Binary relationship many to many

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Another Converting Example

Convert Ternary relationship

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 ER Model: DB Design
Another Converting Example

Convert Ternary relationship

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
 Bad database designs results in:
 redundancy: inefficient storage.
 anomalies: data inconsistency, difficulties in
maintenance
 Normalization is the process of efficiently
organizing data in a database with two goals:
 First goal: eliminate redundant data
 for example, storing the same data in more than one
table
 Second Goal: ensure data dependencies make sense
 for example, only storing related data in a table

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Benefits of Normalization

 Less storage space

 Quicker updates
 Less data inconsistency
 Clearer data relationships
 Easier to add data
 Flexible Structure

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Update Anomalies

Relations that have redundant data may have

problems called update anomalies, which are
classified as ,
Insertion anomalies
Deletion anomalies
Modification anomalies

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Update Anomalies – Example 1/2

To insert a new staff with branchNo B007 into the

StaffBranch relation;
To delete a tuple that represents the last member of staff
located at a branch B007;
To change the address of branch B003.
StaffBranch
staffNo sName position salary branchNo bAddress
SL21 John White Manager 30000 B005 22 Deer Rd, London
SG37 Ann Beech Assistant 12000 B003 163 Main St,Glasgow
SG14 David Ford Supervisor 18000 B003 163 Main St,Glasgow
SA9 Mary Howe Assistant 9000 B007 16 Argyll St, Aberdeen
SG5 Susan Brand Manager 24000 B003 163 Main St,Glasgow
SL41 Julie Lee Assistant 9000 B005 22 Deer Rd, London

Figure 1 StraffBranch relation

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Normalization
Update Anomalies – Example 2/2
Staff
staffNo sName position salary branceNo
SL21 John White Manager 30000 B005
SG37 Ann Beech Assistant 12000 B003
SG14 David Ford Supervisor 18000 B003
SA9 Mary Howe Assistant 9000 B007
SG5 Susan Brand Manager 24000 B003
SL41 Julie Lee Assistant 9000 B005

Branch
branceNo bAddress
B005 22 Deer Rd, London
B007 16 Argyll St, Aberdeen
B003 163 Main St,Glasgow

Figure 2 Straff and Branch relations

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 1/7

Functional dependency describes the relationship

between attributes in a relation.
For example, if A and B are attributes of relation R, and B
is functionally dependent on A ( denoted A B), if each
value of A is associated with exactly one value of B. ( A
and B may each consist of one or more attributes.)

B is functionally
A B
dependent on A

Determinant Refers to the attribute or group of attributes

on the left-hand side of the arrow of a
functional dependency

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 2/7

Trival functional dependency means that the right-hand

side is a subset ( not necessarily a proper subset) of the left-
hand side.
For example: (See Figure 1)
staffNo, sName  sName
staffNo, sName  staffNo

They do not provide any additional information about possible integrity

constraints on the values held by these attributes.

We are normally more interested in nontrivial dependencies

because they represent integrity constraints for the relation.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 3/7

Main characteristics of functional dependencies in

normalization
•Have a one-to-one relationship between attribute(s) on
the left- and right- hand side of a dependency;

•hold for all time;

•are nontrivial.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 4/7

Identifying the primary key

Functional dependency is a property of the meaning or
semantics of the attributes in a relation. When a
functional dependency is present, the dependency is
specified as a
constraint between the attributes.

An important integrity constraint to consider first is the

identification of candidate keys, one of which is
selected to be the primary key for the relation using
functional dependency.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 5/7

Inference Rules
A set of all functional dependencies that are implied by a
given set of functional dependencies X is called closure
of X, written X+. A set of inference rule is needed to
compute X+ from X.

Armstrong’s axioms
1. Relfexivity: If B is a subset of A, them A  B
2. Augmentation: If A  B, then A, C  B
3. Transitivity: If A  B and B  C, then A C
4. Self-determination: A  A
5. Decomposition: If A  B,C then A  B and A C
6. Union: If A  B and A  C, then A B,C
7. Composition: If A  B and C  D, then A,C B,
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Normalization
Functional Dependencies 6/7

Minial Sets of Functional Dependencies

A set of functional dependencies X is minimal if it satisfies
the following condition:
• Every dependency in X has a single attribute on its right-
hand side

• We cannot replace any dependency A  B in X with

dependency C B, where C is a proper subset of A,
and still have a set of dependencies that is equivalent to
X.

• We cannot remove any dependency from X and still

have a set of dependencies that is equivalent to X.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Functional Dependencies 7/7

Example of A Minial Sets of Functional

Dependencies
A set of functional dependencies for the StaffBranch
relation satisfies the three conditions for producing a
minimal set.
staffNo  sName
staffNo  position
staffNo  salary
staffNo  branchNo
staffNo  bAddress
branchNo  bAddress
branchNo, position  salary
bAddress, position  salary
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Normalization
The Process of Normalization

• Normalization is often executed as a series of

steps. Each step corresponds to a specific
normal form that has known properties.

• As normalization proceeds, the relations become

progressively more restricted in format, and also
less vulnerable to update anomalies.

• For the relational data model, it is important to

recognize that it is only first normal form (1NF)
that is critical in creating relations. All the
subsequent normal forms are optional.
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4
 Normalization
First Normal Form – 1NF

 1NF is for creating a well-organized

database structure
 Rules
 Define the data items required, because they
become the columns in a table. Place related
data items in a table.
 ❑ Ensure that there are no repeating groups of
data.
 ❑ Ensure that there is a primary key.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
1NF Example

R
Mãsv Họtên Mãlớp Tênlớp Điểmthi
S1 Tiến L1 MT01 M1 9
S1 Tiến L1 MT01 M2 7
S1 Tiến L1 MT01 M3 8
S2 Trúc L1 MT01 M1 9
S2 Trúc L1 MT01 M2 8
S3 Hiền L2 MT02 M1 5

Quan hệ R không ở dạng chuẩn 1 vì thuộc tính Điểmthi là thuộc tính

phức hợp.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Dạng chuẩn 1 (3)

Mãsv Họtên Mãlớp Tênlớp Mônhọc Điểm

S1 Tiến L1 MT01 M1 9
S1 Tiến L1 MT01 M2 7
S1 Tiến L1 MT01 M3 8
S2 Trúc L1 MT01 M1 9
S2 Trúc L1 MT01 M2 8
S3 Hiền L2 MT02 M1 5

Quan hệ R ở 1NF vì các thuộc tính của R không là thuộc tính đa trị,
không là thuộc tính phức hợp.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
1NF Disadvantage

 Các bất thường của quan hệ ở 1NF

 Thêm vào
 Không thể thêm thông tin của sinh viên mới có mã là
S4, tên là Thành, thuộc lớp có mã là L1 nếu sinh viên
này chưa đăng ký học môn học nào cả.
 Cập nhật
 Sửa tên của sinh viên có tên là Tiến với tên mới là
Thành sẽ phải sửa tất cả các hàng của sinh viên này.
 Xóa bỏ
 Xóa thông tin sinh viên S3 đăng ký môn học M1 sẽ làm
mất thông tin của sinh viên này.
 Nguyên nhân
 Tồn tại thuộc tính không khóa phụ thuộc hàm riêng
phần vào khóa.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Second Normal Form – 2NF

 2NF: it is in 1NF and every non-prime attribute of the

table is either dependent on the whole of a candidate
key, or on another non prime attribute.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
2NF Example
R
Mãsv Họtên Mãlớp Tênlớp Mônhọc Điểm
S1 Tiến L1 MT01 M1 9
S1 Tiến L1 MT01 M2 7
S1 Tiến L1 MT01 M3 8
S2 Trúc L1 MT01 M1 9
S2 Trúc L1 MT01 M2 8
S3 Hiền L2 MT02 M1 5

Các phụ thuộc hàm: Khóa của R: {Mãsv, Mônhọc}

Mãsv  {Họtên, Mãlớp}
Mãlớp  Tênlớp
{Mãsv, Mônhọc}  Điểm
Lược đồ quan hệ R không ở 2NF vì thuộc tính không khóa Họtên phụ
thuộc hàm riêng phần vào khóa {Mãsv, Mônhọc}.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
2NF Example

R1 R2

Mãsv Họtên Mãlớp Tênlớp Mãsv Mônhọc Điểm

S1 Tiến L1 MT01 S1 M1 9
S2 Trúc L1 MT01 S1 M2 7
S3 Hiền L2 MT02 S1 M3 8
S2 M1 9
Khóa của R1: Mãsv
S2 M2 8
S3 M1 5
Khóa của R2: {Mãsv, Mônhọc}

Lược đồ quan hệ R1 và R2 đều ở 2NF vì các thuộc tính không khóa

đều phụ thuộc hàm đầy đủ vào khóa.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
2NF Disadvantage

 Các bất thường của quan hệ ở 2NF

 Thêm vào
 Không thể thêm thông tin của lớp L3 có tên là MT03 nếu
chưa có sinh viên nào học lớp này.
 Cập nhật
 Sửa tên của lớp có mã L1 với tên mới là MT_1 sẽ phải
sửa tất cả các hàng của lớp này.
 Xóa bỏ
 Xóa thông tin của sinh viên có mã S3 sẽ làm mất thông tin
của lớp L2.
 Nguyên nhân
 Tồn tại thuộc tính không khóa phụ thuộc bắc cầu vào khóa.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
Third Normal Form – 3NF

 3NF: is in second normal form and All

nonprimary fields are dependent on the
primary key.
 Purpose: reduce the amount of wasted
storage and data redundancy

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
3NF - Example

R1

Mãsv Họtên Mãlớp Tênlớp

S1 Tiến L1 MT01
S2 Trúc L1 MT01
S3 Hiền L2 MT02

Lược đồ quan hệ R1 không ở 3NF vì thuộc tính không khóa Tênlớp

phụ thuộc bắc cầu vào khóa Mãsv.
Mãsv  Mãlớp Mãlớp  Tênlớp
Mãlớp / Mãsv Tênlớp  {Mãsv, Mãlớp}

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
3NF - Example

R11 R12

Mãlớp Tênlớp Mãsv Họtên Mãlớp

L1 MT01 S1 Tiến L1
L2 MT02 S2 Trúc L1
S3 Hiền L2
Khóa của R11: Mãlớp
Khóa của R12: Mãsv

Lược đồ quan hệ R11 và R12 đều ở 3NF vì các thuộc tính không khóa
đều không phụ thuộc bắc cầu vào khóa.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization
A database “Best” Practice

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization - 1NF

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization - 2NF

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Normalization - 3NF

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Tips for DB Designing
 Don’t design a database that copes with the norm.
 Choose meaningful names for tables and fields.
 Try to keep names simple
 Be consistent in your naming and choice of data
type.
 Analyze your data needs on paper first.
 Pick your primary key carefully.
 Create an index
 Add a multicolumn index.
 Avoid using reserved words as table or field names.
 Consider storage space requirements.

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4

 Q&A

Q&A

© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/4