Revision Qu No 3 Ans_2

8/3/2019 Revision Qu No 3 Ans_2

1/88

B. Information Technology (Hons.)CMPB245:Database Design

Normalization

Pt. 1


2/88

2

Objectives

Explain the purpose of normalization and the

problems associated with redundantinformation

Identify the types of update anomalies

Explain the concept of functional

dependency


3/88

Normalization:The Purpose

Objective 1


4/88

4

Relational Data Analysis

Edgar Codd of IBM, proposed the application

of mathematical set theory and algebra to theorganization of data


Application of mathematical principles to the

storage and manipulation of data, therebyreducing redundancy and increasing flexibility


5/88

5


Prior to relational model

Data tended to be stored in a relatively ad-hocfashion

File structures frequently mirrored the paperdocuments

Data duplication hence data redundancy was rife,leading to problems with maintenance andflexibility


6/88

6

Normalization

Purpose

To develop a logical data model, we must

create an accurate representation of the data, itsrelationship and constraints

This is achieved by

creating a set of relations using a technique called

Normalization


7/887

Normalization

Definitions

A technique for producing a set of rela-tions

with desirable properties, based on the datarequirements of the enterprise

A process of producing tables which con-form to specified standards, known as

Normal Forms


8/888

Normalization

Definitions

A formal method that identifies relations

based on their primary key and the functionaldependencies among their attributes

A process of identifying and regroupingattributes so that data duplication and

anomalies are avoided


9/889

Normalization

Information Reduncancy

One of the aims of database design is to

group attributes into relations to minimizeinformation redundancy

This also reduces the storage space

What sort of redundancy encountered and

how can we avoid it?


10/8810

Branch_No Tel_No

16 Argyll St., Aberdeen

163 Main St., Glasgow

0171-8861212

01224-67125

0141-3392178

Staff_No SName Position BAddressSalary

SL21 John White Manager

SG37 Ann Beech Sen.

Assist.SG14 David Ford Deputy

SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

Normalization


Consider the Staff_Branchrelation which

stores data about staffs working at a parti-cular branch STAFF_BRANCH


11/8811

Normalization


The details of a branch is repeated for every

member of staff located at that branchBranch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


12/88

Branch_No Tel_NoBAddress



0171-8861212

01224-67125

0141-3392178

B5

B3

B7

22 Deer Rd., London

BRANCH

Branch_NoStaff_No SName Position Salary


SG37 Ann Beech Sen. Assist.

SG14 David Ford Deputy

SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5 STAFF


13/88

Update Anomalies:The Types

Objective 2


14/88

14

Normalization

Update Anomalies

Refers to the inconsistencies of updating

(adding, modifying and deleting) informa-tion Can be classified as

Insertion anomalies

Deletion anomalies

Modification anomalies


15/88

15

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

Mary Howe

Susan Brand Manager

Assistant

30000

12000

18000

24000

9000

B5

B3

B3

B3

B7

22 Deer Rd., London



0141-3392178

0141-3392178

STAFF_BRANCH

Update Anomalies

Insertion Anomalies (Case 1)

To insert details of new members of staff (in

Staff_Branch relation)


16/88

16

Update Anomalies


Correct details of branch at which the staff

are to be located, must be entered

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Dear Rd., London


0141-3392178

0141-3392178

0171-8861222

STAFF_BRANCH


17/88

17

Update Anomalies


To insert details of a new branch that has no

staff allocated

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

Mary Howe

Susan Brand Manager

Assistant

30000

12000

18000

24000

9000

B5

B3

B3

B3

B7

22 Deer Rd., London



0141-3392178

0141-3392178

STAFF_BRANCH


18/88

18

Update Anomalies


Nulls must be entered into the attributes for

staff, e.g. Staff_No

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

Mary Howe

Susan Brand Manager

Assistant

30000

12000

18000

24000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


19/88

19

Update Anomalies


Since Staff_No is the primary key, entering

nulls violates entity integrity!

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

Mary Howe

Susan Brand Manager

Assistant

30000

12000

18000

24000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


20/88

20

Update Anomalies

Deletion Anomalies

If a staff is deleted from the Staff_Branch

relation that represents the last member ofstaff at a branch, information about thatbranch is also lost!

Branch_No Tel_No


0171-8861212

0141-3392178



SG37 Ann Beech Sen.Assist.


SL41 Julie Lee Assistant

30000

12000

18000

9000

B5

B3

B3

B5

22 Deer Rd., London


22 Deer Rd., London

0141-3392178

0171-8861212

STAFF_BRANCH


21/88

21

Update Anomalies

Modification Anomalies

To change the value of one of the attri-butes

of a particular branch, e.g. Tel_ No. The rows for all staffs located at that branch must

be updated as well

Branch_No Tel_No


0171-8861212

0141-3392178



SG37 Ann Beech Sen.Assist.


SL41 Julie Lee Assistant

30000

12000

18000

9000

B5

B3

B3

B5

22 Deer Rd., London


22 Deer Rd., London

0141-3392178

0171-8861212

STAFF_BRANCH


22/88

Functional Dependency: TheConcept

Objective 3


23/88

23

Functional Dependencies

Definition

Describes the relationship between attributes

in a relation e.g. if A and B are attributes of a relation, B is

functionally dependent on A, if each value of A isassociated with exactly one value of B

BB is functionally

dependent on A

Attribute Attribute

A


24/88

24


Determinant

The determinant of a functional dependency

refers to the attribute or group of attributeson the left-hand side of the arrow

A is the determinant of B

BB is functionally

dependent on A

Attribute Attribute

A


25/88

25


Example

Consider the attributes Staff_Noand Position

of the Staff_ Branch relation

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


26/88

26


Example

For a specific Staff_No, e.g., SL21, we candetermine the Position of that staff asManager

23

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


27/88

27


Example

Thus, Positionis functionally dependent onStaff_No

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


28/88

28


Example

The opposite is not true because Staff_Noisnot functionally dependent on Position

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


29/88

29


Example

There is another member of staff which holdsthe position of a Manager

Branch_No Tel_No



0171-8861212

01224-67125

0141-3392178



SG37 Ann Beech Sen. Assist.


SA9

SG5

SL41

Mary Howe

Susan Brand

Julie Lee

Manager

Assistant

Assistant

30000

12000

18000

24000

9000

9000

B5

B3

B3

B3

B7

B5

22 Deer Rd., London


22 Deer Rd., London


0141-3392178

0141-3392178

0171-8861212

STAFF_BRANCH


30/88

30

25


ExamplePosition is functionally

dependent on Staff_NoStaff_No Position

Staff_No SL21 Manager

Staff_No is not functionally

dependent on PositionPosition Staff_No

Manager

Staff_No SL21

Staff_No SG5

Determinant of

X X


31/88

31


Identification

How to identify functional dependencies?

Analyze each attribute e.g. Staff_No

Check to see if other attributes in the relationare functionally dependent on it

e.g. see pg. 194, Example 6.2

Analyze all other attributes


32/88

32


Identification

Group all attributes which are functio-nallydependent on a particular attribute, e.g.

Staff_No SName SAddress Position Salary

Branch_No Tel_No BAddress

BAddress Branch_No


33/88

33


Exercise

A manufacturing company distributes itsproducts to its customers via distributiondepot which keep stocks of its products

Preliminary studies indicate that the followingare sample data of orders

Identify all functional dependencies


34/88

RELATIONNAME

CUSTOMER ORDER

Customer Order No.

Customer No.Customer Name

Customer Address

Customer Tel. No.

Depot No.

Depot Name

Product No.

Product Quantity

Product Name

Product Price

T1209

TUBE

500

189.50

P1235

203XYZ Ent.

2 Jln. P/2E

8252211

D-012

Bangi

G107

GASKET

300

280.90

O876

O-RING

432

130.70

ATTRIBUT

ES

Sample Data


35/88

Customer OrderNo.

Customer No. Customer Name

Customer Address Customer Tel. No.

Depot No. Depot Name

Product No.

Product Quantity

Product Name

Customer No. Customer Name Customer Address

Customer Tel. No.


Product No. Product Name Product Price


36/88

Unnormalized Form(UNF)

Objective 1


37/88

37

Unnormalized Form

(UNF)

A table that contains one or more repeatinggroups

Transfer the information from the source intoa table format with rows and columns

The table is in Unnormalized Form (UNF)

See pg. 201


38/88

First Normal Form(1NF)

Sub-Objective 2a


39/88

39

First Normal Form

(1NF)

A relation in which the intersection of eachrow and column contains one and only onevalue

To transform the UNF to 1NF we identify andremove repeating groups within the table


40/88

40

First Normal Form

(1NF)

Repeating group

A group of attributes that occurs with multiplevalues for a single occurrence of the nominatedkey attribute(s) for that table

The nominated key attribute(s) refers to the

attribute(s) that uniquely identify each rowwithin the unnormalized table


41/88

41

First Normal Form

(1NF)

Two ways to remove repeating group:

First approach Enter appropriate data in the empty columns of

rows containing the repeating data

The resulting table (relation) contains atomic

values at the intersection of each row and column


42/88

42

First Normal Form

(1NF)

Second approach

Select an attribute or attributes as a key for theunnormalized table

Remove the repeating groups by placing therepeating data, along with a copy of the originalkey attribute(s) to a separate relation

Identify primary keys for the new relation


43/88

43

Unnormalized Form

UNF Example

Examine the DreamHome Customer RentalDetails form on pg. 216, Fig. 6.6

The information in the forms are transformedinto a table format (Unnormalized Form)

The key attribute is identified as Customer

_No.


44/88

44

Customer_No CName Property_No PAddress RentStart RentFinish Rent Owner_No OName

CR76 John Kay PG4 6 Lawrence Street, 1-Jul-93 31-Aug-95 350 CO40 Tina

GlasgowPG16 5 Novar Drive, 1-Sep-95 1-Sep-96 450 CO93 Tony

Glasgow

CR56 Aline Stew PG4 6 Lawrence Street, 1-Sep-92 10-Jun-93 350 CO40 TinaGlasgow

PG36 2 Manor Road, 10-Oct-93 1-Dec-94 375 CO93 TonyGlasgow

PG16 5 Novar Drive, 1-Jan-95 10-Aug-95 450 CO93 Tony

CUSTOMER_RENTAL TABLE

Unnormalized Form

UNF Example

Transform the information into a table for-mat(Unnormalized Form)


45/88

45




Glasgow




CUSTOMER_RENTAL TABLE

Unnormalized Form

UNF Example

Then, identify the repeating group

(Property_No, PAddress, RentStart, RentFinish,Rent, Owner_No., OName)


46/88

46




Glasgow




Unnormalized Form

UNF Example

These attributes repeat for each Customer_No

e.g. there are two values for Property_No (PG4and PG16) for customer John Kay


47/88

47

First Normal Form (1NF)

Example: First Approach

Remove the repeating group

By entering the appropriate customer data in each row

The primary key is then identified The primary key is the composite key (Customer_No,

Property_No)

The relation is in 1NF

There is a single value at the intersection of each row andcolumn


48/88

48

CUSTOMER_RENTAL RELATION

Customer_No Property_No CName PAddress RentStart RentFinish Rent Owner_No OName

CR76 PG4 John Kay 6 Lawrence Street, 1-Jul-93 31-Aug-95 350 CO40 TinaGlasgow

CR76 PG16 John Kay 5 Novar Drive, 1-Sep-95 1-Sep-96 450 CO93 TonyGlasgow

CR56 PG4 Aline Stew 6 Lawrence Street, 1-Sep-92 10-Jun-93 350 CO40 TinaGlasgow

CR56 PG36 Aline Stew 2 Manor Road, 10-Oct-93 1-Dec-94 375 CO93 TonyGlasgow

CR56 PG16 Aline Stew 5 Novar Drive, 1-Jan-95 10-Aug-95 450 CO93 Tony




49/88

49

Prop_Rental_Owner (Customer_No, Property_No,Paddress, RentStart,

RentFinish,Rent, Owner_No, OName)

Customer (Customer_No, CName)


Example: Second Approach

Remove the repeating group to a separate relation

Add a copy of the original key attribute (Customer

_No) Identify a primary key for each relation


50/88

50

Unnormalized Form (UNF) First Normal Form (1NF)

Customer_No

CNameProperty_NoPAddressRentStartRentFinish

RentOwner_NoOName



Which ofthese attributesare repeating?Remove and

group repeating

items in a separaterelation


51/88

51


Customer_No

CName

Property_NoPAddress

RentStartRentFinishRentOwner_No

OName

MOVE



This isa separate

relation

Identifyprimary

key


52/88

52


Customer_No

CName

Property_NoPAddress


OName

MOVE



What do

we do withthese?


53/88

53


Customer_No

CName

Property_NoPAddress


OName

MOVE



We now

have tworelations


54/88

54


Customer_No

CName

Property_NoPAddress


OName

Whatnext?



Customer_No

Add a copy ofthe original

key attribute


55/88

55


Customer_No

CName

Customer_NoProperty_NoPAddress


OName




56/88

56

UnnormalizedForm (UNF)

First NormalForm (1NF)

RELATIONNAMES



Customer_NoCNameProperty_NoPAddressRentStartRentFinishRentOwner_NoOName

Customer_NoCName

Customer_NoProperty_NoPAddressRentStartRentFinishRentOwner_NoOName

CUSTOMER

PROP_RENTAL_OWNER


57/88

57

Customer_No CName

CR76 John Kay

CR56 Aline Stew

CUSTOMER

Customer_No Property_No PAddress RentStart RentFinish Rent Owner_No OName

CR76 PG4 6 Lawrence Street, 1-Jul-93 31-Aug-95 350 CO40 Tina

Glasgow

CR76 PG16 5 Novar Drive, 1-Sep-95 1-Sep-96 450 CO93 Tony

Glasgow

CR56 PG4 6 Lawrence Street, 1-Sep-92 10-Jun-93 350 CO40 Tina

Glasgow

CR56 PG36 2 Manor Road, 10-Oct-93 1-Dec-94 375 CO93 Tony

Glasgow

CR56 PG16 5 Novar Drive, 1-Jan-95 10-Aug-95 450 CO93 Tony

Glasgow

PROP_RENTAL_OWNER




58/88

Second Normal Form(2NF)

Sub-Objective 2b


59/88

59

Second Normal Form

(2NF)

Second Normal Form (2NF) is based on theconcept of full functional dependency

Full functional dependency

Indicates that if A and B are attributes of arelation, B is fully functionally dependent on A if B

is functionally dependent on A, but not on anyproper subset of A


60/88

60

(Staff_No, SName) Branch_No

Second Normal Form

Full Functional Dependency

Each value of (Staff_No, SName) is associated witha single value of Branch_No

But Branch_No is fully functionally dependent onStaff_No only, i.e. subset of (Staff_ No, SName)

Why?

Because a branch can have more than one staff with the

same name!


61/88

Customer OrderNo.

Customer No. Customer Name

Customer Address Customer Tel. No.


Customer No. Customer Name Customer Address

Customer Tel. No.


Product No. Product Name Product Price

Customer OrderNo.

Product No.Product Quantity


62/88

62

Second Normal Form

(2NF)

2NF applies to relations with composite key, i.e. aprimary key that is composed of two attributes

A relation with single attribute primary key is automaticallyin 2NF

A relation not in 2NF may suffer from updateanomalies

e.g. two rows are involved to change the property numberPG4


63/88

63

Second Normal Form

Definition

A relation that is in 1NF and every non-key isfully functionally dependent on the primarykey

The normalization of 1NF to 2NF involvesremoval of partial dependencies


64/88

64

Second Normal Form

Definition

If partial dependency exist,

Remove the functionally dependent attributes to anew relation

Copy their determinant to the new relation


65/88

65

Customer_NoProperty_NoCName

PAddressRentStartRentFinishRentOwner_No

OName

Customer_No, Property No RentStart

Customer_N

o

CName

Property_No

Owner_No OName

RentFinish

PAddress

Rent Owner_No OName

Second Normal Form


Using the first approach, the 1NF of the Customer_Rental relation is as shown

Determine the functional dependencies


66/88

66

CName

Primary key

Customer_No

Property_No

RentStart

RentFinish

OName

Owner_NoRent

PAddress Transitivedependency

Second Normal Form



67/88

67

Second Normal Form


To transform into 2NF

Create new relations by removing the non-keyattributes along with their determinant


68/88

68

Customer_No CName

CR76 John Kay

CR56 Aline Stew

CUSTOMER

RENTAL

Customer_No Property_No RentStart RentFinish

CR76 PG4 1-Jul-93 31-Aug-95

CR76 PG16 1-Sep-95 1-Sep-96CR56 PG4 1-Sep-92 10-Jun-93

CR56 PG36 10-Oct-93 1-Dec-94

CR56 PG16 1-Jan-95 10-Aug-95

PROPERTY_OWNER

Property_No PAddress Rent Owner_No OName

PG4 6 Lawrence Street, Glasgow 350 CO40 Tina

PG16 5 Novar Drive, Glasgow 450 CO93 Tony

PG36 2 Manor Road, Glasgow 375 CO93 Tony

Second Normal Form



69/88

69

Second Normal Form


Applies to tables with composite key

Remove non-key attributes which aredependent on only part of the primary key

to form a new table with the relevant partial keyas its primary key


70/88

70

Second Normal Form


Customer_No

Property_No

PAddressRentStart

RentFinish

Rent

Owner_No

OName

Consider the 1NF of theProp_Rental_Ow-ner

relation PAddress, Rent, Owner

_No and OName aredependent on only the

Property_No


71/88

71

Second Normal Form


Customer_No

Property_No

RentStart

RentFinish

PAddress

RentOwner_No

OName


72/88

72

Second Normal Form


Customer_No

Property_No

RentStart

RentFinish

PAddress

RentOwner_No

OName

MOVE

Add a copy of

the determinant


73/88

73

Second Normal Form


Customer_No

Property_No

RentStart

RentFinish

Property_No

PAddress

RentOwner_No

OName

Add a copy of

the determinant


74/88

74

Second Normal Form

Example: Second ApproachFirst NormalForm (1NF)

Second NormalForm (2NF)

RELATIONNAMES

Customer_No

CName

Customer_NoProperty_NoPAddressRentStart

RentFinishRentOwner_NoOName

Customer_No

CName

Customer_NoProperty_NoRentStartRentFinish

Property_NoPAddressRentOwner_NoOName

CUSTOMER

RENTAL

PROPERTY_OWNER


75/88

Third Normal Form(3NF)

Sub-Objective 2c


76/88

76

Third Normal Form

(3NF)

2NF have less redundancy than 1NF but still sufferupdate anomalies

e.g. if we want to update the name Tony, we will have toupdate two rows

This is caused by Transitive Dependency

PROPERTY_OWNER

Property_No PAddress Rent Owner_No OName

PG4 6 Lawrence Street, Glasgow 350 CO40 Tina

PG16 5 Novar Drive, Glasgow 450 CO93 Tony

PG36 2 Manor Road, Glasgow 375 CO93 Tony


77/88

77

Third Normal Form (3NF)

Transitive Dependency

A condition where A, B and C are attributesof a relation such that

if A B and B C

then C is transitively dependent on A via B

provided that A is not functionally dependent on Bor C


78/88

78

Staff_No Branch_Nodepends on Staff_No

Branch_No BAddressdepends on Branch_No

Staff_No BAddressdepends on Staff_No

Third Normal Form

Transitive Dependency

Consider the Staff_Branch relation of pg.209, Fig. 6.2

Branch_No functionally

BAddress functionally

BAddress transitively


79/88

79

Third Normal Form

Definition

A relation that is in 1NF and 2NF, and inwhich no non-key attribute is transitively

dependent on the primary key Remove the transitively dependent attribute(s) to

a new relation

Copy its determinant to the new relation


80/88

80

Third Normal Form

Second ApproachSecond Normal Form (2NF) Third Normal Form (3NF)

Customer_NoCName



OName functionallydepends on Owner_No

which functionallydepends on Property_No

Are there any non-key

attributes that aretransitively dependenton the primary key?


81/88

81

Third Normal Form


Customer_NoCName




82/88

82

Third Normal Form


Customer_NoCName


Property_NoPAddressRentOwner_No

OName

MOVE

What do we

do with all theseattributes ?


83/88

83

Third Normal Form


Customer_NoCName



OName

MOVE

Whatnext?

Make a copyof its

determinant


84/88

84

Third Normal Form


Customer_NoCName



Owner_No

OName

Identifythe primary

key

Make a copyof its

determinant


85/88

85

Third Normal Form


Customer_NoCName



Owner_No

OName


86/88

86

Second NormalForm (2NF)

Third NormalForm (3NF)

RELATIONNAMES

Third Normal Form

(3NF)

Customer_NoCName



Customer_NoCName



Owner_NoOName

CUSTOMER

RENTAL

PROPERTY_FOR_RENT

OWNER


87/88

87

All Normal Forms2nd. NormalForm (2NF)

3rd. NormalForm (3NF)

RELATIONNAMES

UnnormalizedForm (UNF)

1st. NormalForm (1NF)

Customer_NoCName



Customer_NoCName



Owner_NoOName

CUSTOMER

RENTAL

PROPERTY_FOR_RENT

OWNER

Customer_NoCName

Property_NoPAddressRentStartRentFinishRentOwner_No

OName

Customer_NoCName

Customer_NoProperty_NoPAddressRentStartRentFinish

RentOwner_NoOName


88/88

THE END

College of InformationTechnology

Revision Qu No 3 Ans_2

Documents

Transcript of Revision Qu No 3 Ans_2