Logical DB Design (OOP)

36
ASSIGNMENT 1 Module: Logical Database Development Case Study: Hallam Accommodation and Housing Agency Group: D Members 1. Traitet Thepbandansuk, SHU ID: 20043132, [email protected] 2. Saleh Al Shammakhi, SHU ID: 21051257, [email protected] 3. Afsaneh Tafazzoli Moghaddam: SHU ID 20049628, [email protected] 4. Raghavendra Rudrapaka: SHU ID: 21050184, [email protected] 5. Sunil Penubolu: SHU ID: 20053429, [email protected] Tutors: Mr. Alan Houldcroft Mrs. Susan Curtis Mr. Martin Beer Module: Logical Database Development Faculty: ACES Submission Date: 16 th December 2011

description

Topic: Database Design based on OOPModule: Logical DatabaseMark: approximately 76%Sheffield Hallam University

Transcript of Logical DB Design (OOP)

Page 1: Logical DB Design (OOP)

ASSIGNMENT 1

Module: Logical Database Development

Case Study:

Hallam Accommodation and Housing Agency

Group: D

Members1. Traitet Thepbandansuk, SHU ID: 20043132, [email protected]. Saleh Al Shammakhi, SHU ID: 21051257, [email protected]. Afsaneh Tafazzoli Moghaddam: SHU ID 20049628, [email protected]. Raghavendra Rudrapaka: SHU ID: 21050184, [email protected]. Sunil Penubolu: SHU ID: 20053429, [email protected] Tutors:

Mr. Alan HouldcroftMrs. Susan CurtisMr. Martin Beer

 Module: Logical Database DevelopmentFaculty: ACESSubmission Date: 16th December 2011

Page 2: Logical DB Design (OOP)

1) ENTITY RELATIONSHIP DIAGRAM

(ER-DIAGRAM)

Page 3: Logical DB Design (OOP)
Page 4: Logical DB Design (OOP)

2) CLASS DIAGRAM

Page 5: Logical DB Design (OOP)
Page 6: Logical DB Design (OOP)

3) USE CASE DIAGRAM

Page 7: Logical DB Design (OOP)

USE CASE

View property details

Maintain Appointment of Viewing Property

Maintain property Owner

Maintain Property

Maintain Promotion

Check Property availability details

Maintain Lease

Maintain Customer

View promotions

Customer

Agency Staff

<<Extend>>

Search properties

Calculate Commission

<<Include>>

System Boundary

Cancel view appointment

Cancel lease

Property Owner

View Appointment of Viewing Property

Viewproperty Owner

ViewCustomer

ViewLease

Agency Staff

Page 8: Logical DB Design (OOP)

DISCUSSION

Page 9: Logical DB Design (OOP)

Features 1: Searching PropertiesRequirement(s):1. System able to support searching for appropriate properties

that have details of individual rooms within a property including dimension of room, heating type, appliances for kitchen, fittings for bathroom, any special features.

Assumption(s):2. Special features belongs to Property (Not room)3. System can support unlimited kinds of room and

equipment.

Solution(s):4. Create 'Room' entity and link to 'Property' entity.5. Create 'Equipment' entity and link to 'Room' entity6. Keep room's dimensions in feet unit, and convert to meter

unit by using SQL formula.7. When system record dimensions to database, there are 2

alternatives;1. Convert to meter by programming.2. Create Store Procedure to convert unit.

8. 'HeatingType' is an attribute of 'Property' entity.9. 'SpeicialFeatures’ is a multi-value attribute of 'Property'

entity.10. Get Lists of Equipment for kitchen, bathroom, etc. by linking

between Room and Equipment Entity 11. Use SQL formula to get derived attribute such as

RoomSpaceUK, RoomSpaceMeter, RoomWitdthMeter and RoomLengthMeter

Benefits(s):12. System can support searching properties details.13. User can select unit both in feet and meter, then system

will record only one unit. (Reduce duplication of data)14. User can search by using Room Type. (ex. Bedroom to get

the details in that room.)15. Database can support limited types of Room and

equipment.16. User can easily find features of a property.

Alternative solution(s):17. Creating Feature Entity, and link it to both Property and

Room in order to support Features in both a property and room.

Alternative Solution

Why it is difficult to model?

1. The feature has to be linked to many entities.2. It is difficult to identify the Number Of rooms that

should be located because if we locate it in property entity, it is easier for database to fill data into only one table, especially for unfurnished house which doesn’t have room details.

Page 10: Logical DB Design (OOP)

Feature 2: Leasing Prices

Requirement(s):1. System supports leasing from 1 week to 2 years.2. System supports leasing for tourist customers.3. System supports quoting price as weekly, monthly and

longer.

Assumption(s):4. Price for Tourist customer can be daily price.5. Leasing prices are set following the leasing periods.6. Database can keep four kinds of leasing prices; daily,

weekly, monthly and yearly.7. Yearly price is the maximum leasing period for setting price.

Solution(s):8. Create the price attribute as multi-value attribute in

Property Entity.9. Link Property and Lease Entity using PropertyNo attribute.10. Create the price attribute in Leasing Entity.11. When make a leasing contract, database can lookup each

price from Property Entity, and also find value in price attribute.

12. For making a contract for more than one year, system can calculate the price by using yearly price * number of year.

Benefit(s):13. Administrator can fill different Leasing prices when he/she

registers a property.14. Database can support 4 kinds of leasing prices.15. Database can search these prices from Property Entity.16. The price for any historical leasing contract will not change

when leasing prices in Property being updated.

Alternative solution(s):17. Creating 'Pricing Entity' to support checking price in each

period. One of the benefits of this model is that the system can support unlimited kinds of leasing price.

Why it is difficult to model?

1. There are many assumptions about setting up price such as what condition that price is based on?

2. Price can be changed in the future, so how the database will manage the history price is a difficulty.

Page 11: Logical DB Design (OOP)

Feature 3: Kinds of customers

Requirement(s):1. The system can keep the records of the various types of

customers such as Students, groups of students, professionals and holiday people.

Assumption(s):2. System can keep the records of students in each group.3. Only one customer who is group leader can make a contract.4. If an accommodation is being rented by only one person, he/she

will be the group leader.5. One customer can belong to only one group.

Solution(s):6. Create 'Customer Entity' and Link to 'CustomerGroup' Entity.7. Use 'CustomerType' attribute to separate kinds of customers.8. Use 'CustomerGroup' entity to keep records of members in each

group.9. Use 'IsGoupLeader' attribute which is a Boolean data type to

define who will make a contract.10. If an accommodation is rented by only one person, the

'IsGroupLeader' attribute will be set as 'True'.

Benefit(s):11. Database can keep records for members of student group who live

in an accommodation.12. The 'IsGroupLeader' attribute can reduce duplication of data in

'CustomerGroup' entity when 'Customer Type' is not a group of students.

Alternative solution(s):13. When we want to create relational database, we can make

'CustomerType' Table to support inserting and changing name of 'Customer Type' in the future.

Benefit(s) of alternative solution(s):

14. Database can summarize the group of data based on kinds of customers.

15. Database will be flexible when we change and add description to any customer type.

Alternative Solution

Why it is difficult to model?1. It is difficult to define that how to fill attributes in

customer entity because different kinds of customers have different attributes such as student has StudentId, Faculty and Course but professionals and tourist havenot those information. However, after we had designed class diagram. It is very useful to revisit modelling ER-Diagram again.

2. We had discussed that customer members are important to record in database or not? As a result, it is better if database has records of student members because university can track data when property has some problem.

Page 12: Logical DB Design (OOP)

Feature 4: Special Deals for Tourist Market

Requirement(s):1. The system support offering special deals at various time of year for

tourist market.

Assumption(s):2. Tourist are able to rent an accommodation for at least one day or more.3. Daily price is a standard price for tourist.4. System support offering special deals as amount of discount.5. System support offering special deals as percentage of discount.6. Database can support discount for all properties. For example, system

offers 10% discount during Christmas holiday.

Solution(s):7. Link 'Promotion' Entity to 'Property' Entity.8. Use ‘PromotionStartDate' and ‘PromotionToDate' attributes to set

Promotion period.9. When make a lease, link data between 'Property' and 'Promotion' Entity to

calculate price, then put the actual price into 'Lease' Entity.10. Use 'DiscountType' attribute to select formula for calculating actual price.

For example 1. Discount by per cent: Actual Price = Price * DiscountRate2. Discount by amount: Actual Price = PromotionPrice

Difficulty: How to manage offering same per cent of discount for all properties?

Conclusion:We select alternative 2 to reduce duplication of data in 'Promotion' Entity.

Work Around:11. When want to get 'Actual Price', select 'DiscountRate' from 'Promotion'

Entity.12. Use 'Discount Rate' to calculate Actual Price and fill it in ‘Lease’ Entity

Example of Simple Select statement:

SELECT Price * (SELECT DiscountRate from Promotion WHERE '25/11/2011' >= FromDate and '25/11/2011' <=EndDate) AS ActualPrice FROM Property.

Compared SolutionRecord one record

(Alternative 1)

Record every property

(Alternative 2)

PropertyNo in Promotion Entity Can be Null PropertyNo

Duplicate Data in Promotion Entity No Yes

Able to get data when link between Property and Promotion Entity

No Yes

Example of Data

The first alternative has to insert all records of properties.The second alternative can record only one record.

Page 13: Logical DB Design (OOP)

Feature 5: Search availability of properties.

Requirement(s):1. Prospective customers can use web to search for suitable

property.2. The system can show details of the dates when a property

is available.

Assumption(s):3. The details of the dates are periods that shows that no

customer has made a lease.4. Reservation is advanced lease that will be recorded in

database.5. The available period can be the period that a

accommodation is empty before someone make a lease. For example, there are 2 lease as following;

• 1 Aug 2011 to 31 Dec 2011• 1 Feb 2012 to 31 Feb 201

Therefore, a prospective customer can make lease between 1 Jan 2012 to 31 Jan 2012.

Solutions(s):6. Create Property and Lease Entities, then links by

PropertyNo.7. Database can check when customers make leases by using

StartDate and EndDate attribute in Lease entity.

Benefit(s):8. Make it simple by using only 2 entities to search that a

property is available or unavailable.9. System can support advanced reservation by using lease

entity.

More Problems(s):10. How to know that customers already paid for deposit or

not? (For agency)11. How to support for deposit payment?12. How to support for payment in each period?

Countermeasure:13. Add the Payment Entity and link to lease entity.14. Database will support payment, both deposit and period

payment.

Countermeasure

Add Payment Entity to record deposit of lease

Page 14: Logical DB Design (OOP)

Feature 6: Owner who has property at different branches

Requirement(s):1. The system can support consolidating the property

registers that these offices maintain into a single integrated system.

Assumption(s):2. One owner can have property that has been registered in

more than one branch.

Difficulties:3. First of all, we had designed Branch entity link to Owner

and Property Entities, respectively. (See picture 1).4. Then, as we had discussed, it is possible that one owner

can has many properties at different branches.5. Therefore, the problem arose when the database cannot

specify that which properties are managed by particular branch because after linking among three entities, the data will show that both branches have same properties.

Solution:6. Link between branch and property entity.7. Add BranchNo as Foreign key in the Property Entity.

Benefit(s):8. Database able to support one owner who registers more

than one branches.

Alternative Work around:9. If has no link between Branch and Property Entity,

system has to create a new OwnerNo for that owner.

Picture 1

Picture 2

Solution 1

Solution 2

Cannot link between branch and property

entity

Page 15: Logical DB Design (OOP)

Feature 6: Number of Rooms

Requirement(s):1. The system can support recording number of bedrooms, bathrooms and

reception room.

Assumption(s):2. User able to fill only number of rooms, property description without other

room details.

Difficulties(s):3. Difficult to decide where NoOfRoom attribute should be placed.

Analysis 2 solutions:4. Create NoOfBedroom, NoOfBathRoom and NoOfReceptionRoom in

property entity5. Create NoOfRoom in Room entity

Solution1) Place in both Property

and Room Entity2) Place in only Room

Entity

Database is easy to fill number of rooms without inserting into room details in Room Entity.

YES NO

Data inconsistency may occur because user may fill number of rooms in property entity don't same as number of room in Room Entity

YES NO

Decision NO YES

Reason   Prevent data inconsistency

Solution 1

Solution 2

Duplicated Attributes and Data inconsistency

Database can support no of each

room.Example of data

Data inconsistency

Page 16: Logical DB Design (OOP)

4.1 POTENTIAL PROBLEMS

IN THE MODEL WHICH HAVE

BEEN HANDLED

Page 17: Logical DB Design (OOP)

1) Multi-value Attribute

Problem: Multi-value Attribute

Detail:1. There are multi-value attributes in Property Entity such

as Price[1..4], Picture[0..n] and Feature[0..n].

How to handle?2. Price[1..4]: Separating Property Table into 4 columns;

PriceDaily, PriceWeekly, PriceMonthly and PriceYearly because there are only 4 attributes.

3. Picture[0..n]: There are not column for picture in the table. Pictures can save as files with similar name as PropertyID. For example, if Property Id is P0001, the picture file names will be P0001-01.jpg, P0001-02.jpg, etc.

4. Feature[0..n]: Create Feature table with FeatureNo and FeatureDesc columns, and link between two tables with FeatureNo.

Benefits:5. Database can record unlimited features of property.6. No need to create table for Price. However, database can

support only 4 leasing price.7. No need to create table for Pictures.8. System can record unlimited pictures of each property.

Relational Database

Entity

Record features in each property

Page 18: Logical DB Design (OOP)

1) Multi-value Attribute ( Recording Picture )

Issue: How to record pictures of each property?

Alternative about pictures issue:1. Create a new Picture Table which has PictureNo and Picture attributes with using data type as object, then

link between Property and Picture table.

Solution 12. Keep to Database: Create Picture Table3. Keep in File System: Use pictures like PropertyNo ex. P0001- 01.jpg, P0001-02.jpg.

Comparison Table

Solution 1) Keep pictures in Database 2) Keep picture in File System

Easy to backup only Database YES NO

Growing of database FAST NO

Has PictureNo Attribute in Property Table YES NO

Has Picture Table YES NO

Page 19: Logical DB Design (OOP)

2.1) Derived Attribute

Problem: Derived Attribute

Detail:There are derived attributes in some entities(tables);1. Room table:

• RoomSpaceUK• RoomSpaceMeter• RoomWidthMeter• RoomLengthMeter

2. Lease Table: • Commission

How to handle?

3. Create view to show values from derived attribute. For example of formula as following;

• RoomSpaceUK = RoomWidthUK * RoomLengthUK• RoomSpaceMeter = RoomSpaceUK / 0.3048• RoomWidthMeter = RoomWidthUK / 0.3048• RoomLengthMeter = RoomLengthUK / 0.3048• CommissionRate = Price * CommissionRate• Example of SQL view statement:

CREATE VIEW VIEW_PROPERTY AS SELECT RoomWidthUK * RoomLengthUK AS RoomSpaceUK FROM Room;

4. Use that view to show derived attributes.

Benefits5. No need to create those columns in the Room table6. Prevent data inconsistency: Programmer may save wrong data into

database such as RoomWidthMeter <> RoomWidthUK / 0.3048

Relational Database

Entities (Tables)

SQL command to calculate room

dimensions and space

Page 20: Logical DB Design (OOP)

2.2) Derived Attribute (Example)

Derived Attribute

Create View

Page 21: Logical DB Design (OOP)

3.1) Composite Attribute: Address

Problem: Composite attribute: Address

Details:1. Address is a composite attribute with District, Town,

County and postcode attributes.2. The facility for searching based on district, postcode and

partial of postcode.

How to handle?3. In the Property table, create columns as District, Town,

county and Postcode.4. Create view to combine Address together.5. Use LIKE on SQL command to search District, postcode

and partial of postcode. Ex. SELECT * FROM VIEW_PROPERTY WHERE Address LIKE %[keyword]%

Alternative6. Use SQL command to search such as SELECT

PropertyName from PROPERTY WHERE Postcode LIKE ‘%[Partial_Postcode]% OR District LINK [input_district]

Benefit of Alternative7. It is faster than searching from combining attributes

because database is searched only particular columns.

Relational Database Design

ER-DIAGRAM

Example of SQL command

Page 22: Logical DB Design (OOP)

3.2) Composite Attribute: Phone Numbers

Problem: Composite attribute

Detail:1. PhoneNo [0..3] is a composite attribute including

Landline, Mobile and Fax No

How to handle?2. Separate composite attribute to 3 columns and names as

Landline, Mobile and Fax.

Benefit3. Easy to understand the names of columns by using

Landline, Mobile and Fax as column name.

Relational Database

Name Phone Columns as Landline, Mobile and

Fax

ER-Diagram

Page 23: Logical DB Design (OOP)

4) Compound Key

Problem: Compound key

Assumption:1. Some tourist customers can rent accommodation from

more than one branch.2. Some property owner can register properties more than

one branch.

Detail:3. There are some Many to Many relationship such as

relationship between Branch and User entity.

How to handle?4. Create the RegisterUser table at the middle of both

entities5. Link among 3 tables. (See picture)

Benefits6. Remove weak entity problem.7. Database can support creating VIEW that link data

between Branch and user.8. Database can use BranchNo and UserName as primary

keys in Branch and User tables, respectively.

Relational Database

Inserted table between M:M

entity

Page 24: Logical DB Design (OOP)

Assumption:

1. System can support recording all members in

student group.

Benefit:

2. Agency can find any member who lives in a house

when house has some problem.

Comparison:

3. Separate to 2 tables

4. Combine to single table and add more column

5. Combine to single table and use

CustomerType column

Analysis from recording data

ER-Diagram

5) Design Table to Record Student members in each group

Solution 2

Solution1

Solution 3

Solution 1 2 3

How to do? Separate Table Combine Table Combine Table

Concept Separate TableCombine table and use new

column as StudentGroupCombine table and use same

column as CustomerType

Number of Table 2 1 1

How to record data?Record CusetomerNo and

GroupNo in CustomerGroupUse StudentGroup to identify Use CustomerType to identify

Grouping by SQL Command Easy and flexible Easy and flexible

Difficult and not flexible because when database create the master table for customer type, it will difficult to group

each Customer Type.

Decision Good Best Not Good

Example data

Choose this solution

Page 25: Logical DB Design (OOP)

Subject: Kinds of customers

Features:

1. The system can keep record of various kinds of customers ex. Students, groups of students, professionals and holiday people.

Problems:

2. We combine 3 Entities of Staff, Owner and Customer into User Table.

Solution for modeling relational database

3. Use UserType column in the User table to identify Type of User

Type of User• Staff• Owner• Student Customer• Group of Student Customer• Tourist Customer

4. Use UserType table to show Description of each user type (Column UserTypeName)

Benefits5. Combine 3 entities with only one table.6. Database is flexible when a user changes or adds description of user type because the

UserType value will be unchanged.7. Summary data of each user or customer type is easy because the same User Type will

be not separated unintentionally such as user key user types as Student and STUDENT

ER-Diagram

6) Kind of customers

Example data in database

Table

Add user type table to enhance

flexibility

3 entities will be combine into two

tables

Page 26: Logical DB Design (OOP)

4.2 HOW ANY HIERARCHIES

MODELLED IN CLASS

DIAGRAM COULD BE

HANDLED ?

Page 27: Logical DB Design (OOP)

Hierarchy of the USER CLASS1. Superclass: User2. Subclass: Staff, Owner and Customer

Assumption3. A user (person) can be both customer and owner.4. User Type has only Staff, Owner and customer.

How to model?5. Create only 2 tables to record database from

subclass.6. Use UserType attribute to identify type of users.

Example of values in UserTypeName column7. Professional8. Tourist9. Student10.GroupOfStudent

Reason:11.Every attribute in Subclass is almost the same.

Benefits:12.Easy to insert, update data in database.13.Reduce complexity of database

Example of Relational Database

1) Specialization and Generation of User Class

Page 28: Logical DB Design (OOP)

Hierarchy of the CUSTOMER CLASS1. Superclass: Customer2. Subclass: Student and tourist

How to model?3. Create student table to record Student No,

University and faculty, Course and IsGroupLeader.4. Link between student and user table with

UserName column

Reason:5. There are many attributes in Student Class different

from the Tourist Class.

Benefits:6. Database can reduce duplicated data when it

records data for tourist or student customer.

Relational Database

2) Specialization and Generation of Customer Class

Page 29: Logical DB Design (OOP)

Hierarchy of the PROPERTY CLASS1. Superclass: Property2. Subclass: House and Flat

How to model?3. Create Only Property to record data for House and

flat4. Use PropertyType attribute to identify type of

property.5. Use PropertyType attribute to identify type of House

Example of value in PropertyType6. Flat7. Detached House8. Terraced House

Reason:9. Every attribute is almost the same

Benefits:10.Database can reduce duplicated data when it

records data for tourist or student customer.11.Reduce complexity of database

Property Table

3) Specialization and Generation of Property Class

Page 30: Logical DB Design (OOP)

4.1) EXAMPLE DATA

Link 3 tables to identify user in each type

Ex. • Tourist Customer• Student Customer• Owner• Group of Student Staff

design

Page 31: Logical DB Design (OOP)

4.2) EXAMPLE DATA

Use column Property to identify each property type from subclass

Property Type1. Flat2. House (Detached &

Terraced house)

design

Table Outcome Class Diagram Design

Page 32: Logical DB Design (OOP)

APPENDIX

Page 33: Logical DB Design (OOP)

CREATE TABLE TM_BRANCH( BranchNo int NOT NULL, BranchName VARCHAR(100) NOT NULL, District VARCHAR(100), Town VARCHAR(100), County VARCHAR(100), Postcode VARCHAR(100), LandLine VARCHAR(100), Mobile VARCHAR(100), Fax VARCHAR(100), RegisterDate Date NOT NULL, CONSTRAINT BRANCH_PK PRIMARY KEY (BranchNo)); CREATE TABLE TM_USERTYPE( UserType int NOT NULL, UserTypeName VARCHAR(100) NOT NULL, CONSTRAINT USERTYPE_PK PRIMARY KEY (UserType)); CREATE TABLE TM_USER ( UserName VARCHAR(20) NOT NULL, Pssword VARCHAR(20), UserType int NOT NULL, FirstName VARCHAR(100) NOT NULL, LastName VARCHAR(100), Address1 VARCHAR(100), District VARCHAR(100), Town VARCHAR(100), County VARCHAR(100), Postcode VARCHAR(100), LandLine VARCHAR(100), Mobile VARCHAR(100), Fax VARCHAR(100), Email VARCHAR(100), CONSTRAINT USER_PK PRIMARY KEY (UserName), CONSTRAINT USER_USERTYPE_FK FOREIGN KEY (UserType) REFERENCES TM_USERTYPE(UserType));

SQL CREATE TABLE STATEMENT

CREATE TABLE TM_USERGROUP( UserName int NOT NULL, UserGroup VARCHAR(10) NOT NULL, UserTypeName VARCHAR(100) NOT NULL, CONSTRAINT USERTYPE_PK PRIMARY KEY (UserName,UserTypeName) CONSTRAINT USER_USERTYPE_FK FOREIGN KEY (UserName) REFERENCES TM_USER(UserName));  CREATE TABLE TM_REGISTERUSER ( UserName VARCHAR(20) NOT NULL, BranchNo int NOT NULL, RegisterDate Date NOT NULL, CONSTRAINT REGISTERUSER_REGISTERUSER_PK1 PRIMARY KEY (UserName,BranchNo), CONSTRAINT REGISTERUSER_USER_FK FOREIGN KEY (UserName) REFERENCES TM_USER(UserName), CONSTRAINT REGISTERUSER_BRANCH_FK FOREIGN KEY (BranchNo) REFERENCES TM_BRANCH(BranchNo)); CREATE TABLE TM_STUDENT ( UserName VARCHAR(20) NOT NULL, StudentNo VARCHAR(20) NOT NULL, StudentGroup VARCHAR(20) NOT NULL, IsGroupLeader CHAR(1) NOT NULL, Faculty VARCHAR(100) NOT NULL, Course VARCHAR(100) NOT NULL, CONSTRAINT STUDENT_PK PRIMARY KEY (UserName), CONSTRAINT STUDENT_USER_FK FOREIGN KEY (UserName) REFERENCES TM_USER(UserName)); CREATE TABLE TM_FEATURE ( FeatureNo int NOT NULL, PropertyNo int NOT NULL, CONSTRAINT ROPERTYFEATURE_PK PRIMARY KEY (FeatureNo ,PropertyNo), CONSTRAINT ROPERTYFEATURE_FEATURE_FK FOREIGN KEY (FeatureNo) REFERENCES TM_FEATURE(FeatureNo), CONSTRAINT ROPERTYFEATURE_PROPERTY_FK FOREIGN KEY (PropertyNo) REFERENCES TM_PROPERTY(PropertyNo));

Page 34: Logical DB Design (OOP)

CREATE TABLE TM_PROPERTY( PropertyNo int NOT NULL, BranchNo int NOT NULL, OwnerNo VARCHAR(20) NOT NULL, RegisterDate Date NOT NULL , PropertyName VARCHAR(100), PropertyType VARCHAR(20), DailyPrice FLOAT, WeeklyPrice FLOAT, MonthlyPrice FLOAT, YearlyPrice FLOAT, IsFurnished CHAR(1), TextualDesc VARCHAR(255), HeatingSystem VARCHAR(100), RoomNo VARCHAR(100), FlatNo VARCHAR(100), HouseNo VARCHAR(100), District VARCHAR(100), Town VARCHAR(100), County VARCHAR(100), Postcode VARCHAR(20), CONSTRAINT PROPERTY_NO_PK PRIMARY KEY (PropertyNo), CONSTRAINT PROPERTY_USER_FK FOREIGN KEY (OwnerNo) REFERENCES TM_USER(UserName), CONSTRAINT PROPERTY_FEATURE_FK FOREIGN KEY (FeatureNo) REFERENCES TM_FEATURE(FeatureNo), CONSTRAINT PROPERTY_BRANCH_FK FOREIGN KEY (BranchNo) REFERENCES TM_BRANCH(BranchNo));

SQL CREATE TABLE STATEMENT

CREATE TABLE TM_ROOMTYPE( RoomType int NOT NULL, RoomTypeName VARCHAR(100) NOT NULL, CONSTRAINT ROOMTYPE_PK PRIMARY KEY (RoomType)); CREATE TABLE TM_ROOM( RoomNo int NOT NULL, PropertyNo int NOT NULL, RoomType int NOT NULL, RoomDesc VARCHAR(255), NoOfRoom int NOT NULL, RoomWidthUK FLOAT, RoomLengthUK FLOAT, CONSTRAINT ROOM_PK PRIMARY KEY (RoomNo), CONSTRAINT ROOM_PROPERTY_FK FOREIGN KEY (PropertyNo) REFERENCES TM_PROPERTY(PropertyNo), CONSTRAINT ROOM_ROOMTYPE_FK FOREIGN KEY (RoomType) REFERENCES TM_ROOMTYPE(RoomType)); CREATE TABLE TM_EQUIPMENTTYPE( EquipType int NOT NULL, EquipDesc VARCHAR(255) NOT NULL, CONSTRAINT EQUIPMENT_TYPE_PK PRIMARY KEY (EquipType)); CREATE TABLE TM_EQUIPMENT( EquipNo int NOT NULL, RoomNo int NOT NULL, EquipType int NOT NULL, CONSTRAINT EQUIPMENT_PK PRIMARY KEY (RoomNo,EquipNo), CONSTRAINT EQUIPMENT_ROOM_FK FOREIGN KEY (RoomNo) REFERENCES TM_ROOM(RoomNo), CONSTRAINT EQUIPMENT_EQUIPMENTTYPE_FK FOREIGN KEY (EquipType) REFERENCES TM_EQUIPMENTTYPE(EquipType)); 

Page 35: Logical DB Design (OOP)

CREATE TABLE TT_APPOINTMENT( AppointNo int NOT NULL, PropertyNo int NOT NULL, CustomerNo VARCHAR(20) NOT NULL, AppointTime Date NOT NULL, AppointComment VARCHAR(255), CONSTRAINT APPOINTMENT_PK PRIMARY KEY (AppointNo), CONSTRAINT APPOINTMENT_PROPERTY_FK FOREIGN KEY (PropertyNo) REFERENCES TM_PROPERTY(PropertyNo), CONSTRAINT APPOINTMENT_USER_FK FOREIGN KEY (CustomerNo) REFERENCES TM_USER(UserName)); CREATE TABLE TT_LEASE( LeaseNo int NOT NULL, PropertyNo int NOT NULL, CustomerNo VARCHAR(20) NOT NULL, LeaseType VARCHAR(20) NOT NULL, Price FLOAT, NoOfPayment int NOT NULL, StartDate Date NOT NULL, EndDate Date, CancelDate Date, PaymentTerm VARCHAR(100) NOT NULL, CommissionRate FLOAT, CONSTRAINT LEASE_PK PRIMARY KEY (LeaseNo), CONSTRAINT LEASE_PROPERTY_FK FOREIGN KEY (PropertyNo) REFERENCES TM_PROPERTY(PropertyNo), CONSTRAINT LEASE_CUSTUSER_FK FOREIGN KEY (CustomerNo) REFERENCES TM_USER(UserName)); CREATE TABLE TT_PROMOTION( PromotionNo int NOT NULL, PropertyNo int NOT NULL, PromotionStartDate Date NOT NULL, PromotionEndDate Date NOT NULL, PromotionCancelDate Date, PromotionType VARCHAR(20), PromotionPrice FLOAT, DiscountRate FLOAT, CONSTRAINT PROMOTION_PK PRIMARY KEY (PromotionNo), CONSTRAINT PROMOTION_PROPERTY_FK FOREIGN KEY (PropertyNo) REFERENCES TM_PROPERTY(PropertyNo));

SQL CREATE TABLE STATEMENT

Page 36: Logical DB Design (OOP)

EXAMPLE OF RELATIONAL DATABASE