Topic: Database Design based on OOP Module: Logical Database Mark: approximately 76% Sheffield Hallam University

1. ASSIGNMENT 1
Module:
Logical Database Development
Case Study:
Hallam Accommodation and Housing Agency
Group: D
Members
1. Traitet Thepbandansuk, SHU ID: 20043132, b0043132@my.shu.ac.uk
2. Saleh Al Shammakhi, SHU ID: 21051257, b1051257@my.shu.ac.uk
3. Afsaneh Tafazzoli Moghaddam: SHU ID 20049628, b0049628@my.shu.ac.uk
4. Raghavendra Rudrapaka: SHU ID: 21050184, b1050184@my.shu.ac.uk
5. Sunil Penubolu: SHU ID: 20053429, b0053429@my.shu.ac.uk
Tutors:
Mr. Alan Houldcroft
Mrs. Susan Curtis
Mr. Martin Beer
Module: Logical Database Development
Faculty: ACES
Submission Date: 16th December 2011

2. 1) ENTITY RELATIONSHIP
DIAGRAM
(ER-DIAGRAM)

4. 2) CLASS DIAGRAM

6. 3) USE CASE DIAGRAM

7. USE CASE
View Maintain
property Owner property Owner
View Maintain
Lease Property
View Maintain
Customer Customer
Agency Staff
View Appointment Maintain Appointment
of Viewing Property of Viewing Property
<<Include>>
Calculate Commission Maintain Lease
Maintain Promotion
Customer
Agency Staff
Search properties
<<Extend>>
Check Property
availability details
Cancel view appointment
Property Owner
View property details
Cancel lease
System Boundary View promotions

8. DISCUSSION

9. Features 1: Searching Properties
Requirement(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):
1. Special features belongs to Property (Not room)
2. System can support unlimited kinds of room and equipment.
Solution(s):
1. Create 'Room' entity and link to 'Property' entity.
2. Create 'Equipment' entity and link to 'Room' entity
3. Keep room's dimensions in feet unit, and convert to meter unit by Alternative Solution
using SQL formula.
4. When system record dimensions to database, there are 2
alternatives;
1. Convert to meter by programming.
2. Create Store Procedure to convert unit.
5. 'HeatingType' is an attribute of 'Property' entity.
6. 'SpeicialFeatures’ is a multi-value attribute of 'Property' entity.
7. Get Lists of Equipment for kitchen, bathroom, etc. by linking
between Room and Equipment Entity
8. Use SQL formula to get derived attribute such as RoomSpaceUK,
RoomSpaceMeter, RoomWitdthMeter and RoomLengthMeter
Benefits(s):
1. System can support searching properties details.
2. User can select unit both in feet and meter, then system will record
only one unit. (Reduce duplication of data)
3. User can search by using Room Type. (ex. Bedroom to get the
details in that room.) Why it is difficult to model?
4. Database can support limited types of Room and equipment.
5. User can easily find features of a property. 1. The feature has to be linked to many entities.
2. It is difficult to identify the Number Of rooms that should be
Alternative solution(s): located because if we locate it in property entity, it is easier for
1. Creating Feature Entity, and link it to both Property and Room in database to fill data into only one table, especially for
order to support Features in both a property and room. unfurnished house which doesn’t have room details.

10. 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):
1. Price for Tourist customer can be daily price.
2. Leasing prices are set following the leasing periods.
3. Database can keep four kinds of leasing prices; daily, weekly,
monthly and yearly.
4. Yearly price is the maximum leasing period for setting price.
Solution(s):
1. Create the price attribute as multi-value attribute in Property Entity.
2. Link Property and Lease Entity using PropertyNo attribute.
3. Create the price attribute in Leasing Entity.
4. When make a leasing contract, database can lookup each price
from Property Entity, and also find value in price attribute.
5. For making a contract for more than one year, system can calculate
the price by using yearly price * number of year.
Benefit(s):
1. Administrator can fill different Leasing prices when he/she registers
a property. Why it is difficult to model?
2. Database can support 4 kinds of leasing prices.
3. Database can search these prices from Property Entity. 1. There are many assumptions about setting up price such as
4. The price for any historical leasing contract will not change when what condition that price is based on?
leasing prices in Property being updated.
2. Price can be changed in the future, so how the database will
manage the history price is a difficulty.
Alternative solution(s):
1. 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.

11. 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):
1. System can keep the records of students in each group.
2. Only one customer who is group leader can make a contract.
3. If an accommodation is being rented by only one person, he/she will be the
group leader.
4. One customer can belong to only one group.
Alternative Solution
Solution(s):
1. Create 'Customer Entity' and Link to 'CustomerGroup' Entity.
2. Use 'CustomerType' attribute to separate kinds of customers.
3. Use 'CustomerGroup' entity to keep records of members in each group.
4. Use 'IsGoupLeader' attribute which is a Boolean data type to define who
will make a contract.
5. If an accommodation is rented by only one person, the 'IsGroupLeader'
attribute will be set as 'True'.
Benefit(s):
1. Database can keep records for members of student group who live in an
accommodation.
2. The 'IsGroupLeader' attribute can reduce duplication of data in
'CustomerGroup' entity when 'Customer Type' is not a group of students.
Why it is difficult to model?
Alternative solution(s): 1. It is difficult to define that how to fill attributes in customer
1. When we want to create relational database, we can make 'CustomerType' entity because different kinds of customers have different
Table to support inserting and changing name of 'Customer Type' in the attributes such as student has StudentId, Faculty and Course
future.
but professionals and tourist havenot those information.
Benefit(s) of alternative solution(s): However, after we had designed class diagram. It is very
useful to revisit modelling ER-Diagram again.
1. Database can summarize the group of data based on kinds of customers. 2. We had discussed that customer members are important to
2. Database will be flexible when we change and add description to any record in database or not? As a result, it is better if database
customer type. has records of student members because university can track
data when property has some problem.

12. 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):
1. Tourist are able to rent an accommodation for at least one day or more.
2. Daily price is a standard price for tourist.
3. System support offering special deals as amount of discount.
4. System support offering special deals as percentage of discount.
5. Database can support discount for all properties. For example, system offers 10%
discount during Christmas holiday.
Solution(s):
1. Link 'Promotion' Entity to 'Property' Entity.
2. Use ‘PromotionStartDate' and ‘PromotionToDate' attributes to set Promotion period.
3. When make a lease, link data between 'Property' and 'Promotion' Entity to calculate
price, then put the actual price into 'Lease' Entity.
4. Use 'DiscountType' attribute to select formula for calculating actual price.
For example
1. Discount by per cent: Actual Price = Price * DiscountRate
2. Discount by amount: Actual Price = PromotionPrice
Difficulty: How to manage offering same per cent of discount for all properties?
Example of Data
Record every
Record one record
Compared Solution property
(Alternative 1)
(Alternative 2)
PropertyNo in Promotion Entity Can be Null PropertyNo
Duplicate Data in Promotion Entity No Yes
Able to get data when link between
No Yes
Property and Promotion Entity
Conclusion:
We select alternative 2 to reduce duplication of data in 'Promotion' Entity.
Work Around:
1. When want to get 'Actual Price', select 'DiscountRate' from 'Promotion' Entity.
2. Use 'Discount Rate' to calculate Actual Price and fill it in ‘Lease’ Entity
Example of Simple Select statement: The first alternative has to insert all records of properties.
The second alternative can record only one record.
SELECT Price * (SELECT DiscountRate from Promotion WHERE '25/11/2011' >=
FromDate and '25/11/2011' <=EndDate) AS ActualPrice FROM Property.

13. 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):
1. The details of the dates are periods that shows that no customer
has made a lease.
2. Reservation is advanced lease that will be recorded in database.
3. 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):
1. Create Property and Lease Entities, then links by PropertyNo.
2. Database can check when customers make leases by using
StartDate and EndDate attribute in Lease entity.
Benefit(s): Countermeasure
1. Make it simple by using only 2 entities to search that a property is
available or unavailable.
2. System can support advanced reservation by using lease entity.
More Problems(s):
1. How to know that customers already paid for deposit or not? (For
agency)
2. How to support for deposit payment?
3. How to support for payment in each period?
Countermeasure:
1. Add the Payment Entity and link to lease entity.
2. Database will support payment, both deposit and period payment.
Add Payment Entity to record deposit of lease

14. Feature 6: Owner who has property at different branches
Solution 1
Requirement(s):
1. The system can support consolidating the property registers that
these offices maintain into a single integrated system.
Assumption(s):
1. One owner can have property that has been registered in more
than one branch. Picture 1
Difficulties:
1. First of all, we had designed Branch entity link to Owner and Cannot link between
Property Entities, respectively. (See picture 1). branch and property
2. Then, as we had discussed, it is possible that one owner can entity
has many properties at different branches.
3. 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:
1. Link between branch and property entity. Solution 2
2. Add BranchNo as Foreign key in the Property Entity.
Benefit(s):
1. Database able to support one owner who registers more than
one branches.
Alternative Work around:
Picture 2
1. If has no link between Branch and Property Entity, system has to
create a new OwnerNo for that owner.

15. Feature 6: Number of Rooms
Requirement(s):
1. The system can support recording number of bedrooms, bathrooms and reception
room. Solution 1
Assumption(s):
1. User able to fill only number of rooms, property description without other room
details.
Difficulties(s):
1. Difficult to decide where NoOfRoom attribute should be placed.
Analysis 2 solutions:
1. Create NoOfBedroom, NoOfBathRoom and NoOfReceptionRoom in property entity
2. Create NoOfRoom in Room entity Duplicated Attributes and
Data inconsistency
1) Place in both Property 2) Place in only Room
Solution
and Room Entity Entity
Database is easy to fill number of
rooms without inserting into room YES NO
details in Room Entity.
Data inconsistency may occur
because user may fill number of
YES NO
rooms in property entity don't same
as number of room in Room Entity
Decision NO YES Solution 2
Reason Prevent data inconsistency
Data
inconsistency
Database can support
no of each room.
Example of data

16. 4.1 POTENTIAL PROBLEMS
IN THE MODEL WHICH HAVE
BEEN HANDLED

17. 1) Multi-value Attribute
Entity
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?
1. Price[1..4]: Separating Property Table into 4 columns;
PriceDaily, PriceWeekly, PriceMonthly and PriceYearly because
there are only 4 attributes.
2. 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 Relational Database
P0001-01.jpg, P0001-02.jpg, etc.
3. Feature[0..n]: Create Feature table with FeatureNo and
FeatureDesc columns, and link between two tables with
FeatureNo.
Benefits:
1. Database can record unlimited features of property.
2. No need to create table for Price. However, database can
support only 4 leasing price. Record features in each
3. No need to create table for Pictures. property
4. System can record unlimited pictures of each property.

18. 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 1
1. Keep to Database: Create Picture Table
2. 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

19. 2.1) Derived Attribute
Problem: Derived Attribute
Entities (Tables)
Detail:
There are derived attributes in some entities(tables);
1. Room table:
• RoomSpaceUK
• RoomSpaceMeter
• RoomWidthMeter
• RoomLengthMeter
2. Lease Table:
• Commission
How to handle?
1. Create view to show values from derived attribute. For example of
formula as following;
• RoomSpaceUK = RoomWidthUK * RoomLengthUK
• RoomSpaceMeter = RoomSpaceUK / 0.3048 Relational Database
• 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;
SQL command to
calculate room
2. Use that view to show derived attributes.
dimensions and space
Benefits
1. No need to create those columns in the Room table
2. Prevent data inconsistency: Programmer may save wrong data into
database such as RoomWidthMeter <> RoomWidthUK / 0.3048

20. 2.2) Derived Attribute (Example)
Create View
Derived Attribute

21. 3.1) Composite Attribute: Address
ER-DIAGRAM
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?
1. In the Property table, create columns as District, Town, county
Relational Database Design
and Postcode.
2. Create view to combine Address together.
3. Use LIKE on SQL command to search District, postcode and
partial of postcode. Ex. SELECT * FROM VIEW_PROPERTY
WHERE Address LIKE %[keyword]%
Alternative
1. Use SQL command to search such as SELECT PropertyName from
PROPERTY WHERE Postcode LIKE ‘%[Partial_Postcode]% OR
District LINK [input_district]
Benefit of Alternative
1. It is faster than searching from combining attributes because
database is searched only particular columns.
Example of SQL
command

22. 3.2) Composite Attribute: Phone Numbers
ER-Diagram
Problem: Composite attribute
Detail:
1. PhoneNo [0..3] is a composite attribute including Landline, Mobile
and Fax No
Relational Database
How to handle?
1. Separate composite attribute to 3 columns and names as
Landline, Mobile and Fax.
Benefit
1. Easy to understand the names of columns by using Landline,
Mobile and Fax as column name.
Name Phone Columns
as Landline, Mobile and
Fax

23. 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:
1. There are some Many to Many relationship such as relationship
between Branch and User entity.
How to handle?
1. Create the RegisterUser table at the middle of both entities
2. Link among 3 tables. (See picture) Relational Database
Benefits
1. Remove weak entity problem.
2. Database can support creating VIEW that link data between
Branch and user.
3. Database can use BranchNo and UserName as primary keys in
Branch and User tables, respectively.
Inserted table
between M:M
entity

24. 5) Design Table to Record Student members in each group
Assumption: ER-Diagram
1. System can support recording all members in
student group.
Benefit:
1. Agency can find any member who lives in a house
when house has some problem.
Comparison:
1. Separate to 2 tables
Solution1
2. Combine to single table and add more column
3. Combine to single table and use
Example data
CustomerType column
Analysis from recording data
Choose this solution
Solution 1 2 3
How to do? Separate Table Combine Table Combine Table
Combine table and use new Combine table and use same Solution 2 Solution 3
Concept Separate Table
column as StudentGroup column as CustomerType
Number of Table 2 1 1
Record CusetomerNo and
How to record data? Use StudentGroup to identify Use CustomerType to identify
GroupNo in CustomerGroup
Difficult and not flexible
because when database create
Grouping by SQL Command Easy and flexible Easy and flexible the master table for customer
type, it will difficult to group
each Customer Type.
Decision Good Best Not Good

25. 6) Kind of customers
Subject: Kinds of customers ER-Diagram
Features:
1. The system can keep record of various kinds of customers ex. Students, groups of students,
professionals and holiday people.
Problems:
1. We combine 3 Entities of Staff, Owner and Customer into User Table.
Solution for modeling relational database
1. Use UserType column in the User table to identify Type of User 3 entities will be
combine into two
Type of User
• Staff
tables
• Owner
• Student Customer Table
• Group of Student Customer
• Tourist Customer
2. Use UserType table to show Description of each user type (Column UserTypeName)
Benefits
1. Combine 3 entities with only one table.
2. Database is flexible when a user changes or adds description of user type because the UserType
value will be unchanged.
3. 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 Add user type
table to enhance
flexibility
Example data in
database

26. 4.2 HOW ANY HIERARCHIES
MODELLED IN CLASS DIAGRAM
COULD BE HANDLED ?

27. 1) Specialization and Generation of User Class
Hierarchy of the USER CLASS
1. Superclass: User
2. Subclass: Staff, Owner and Customer
Assumption
1. A user (person) can be both customer and owner.
2. User Type has only Staff, Owner and customer.
How to model?
1. Create only 2 tables to record database from subclass.
2. Use UserType attribute to identify type of users.
Example of values in UserTypeName column
1. Professional Example of Relational Database
2. Tourist
3. Student
4. GroupOfStudent
Reason:
1. Every attribute in Subclass is almost the same.
Benefits:
1. Easy to insert, update data in database.
2. Reduce complexity of database

28. 2) Specialization and Generation of Customer Class
Hierarchy of the CUSTOMER CLASS
1. Superclass: Customer
2. Subclass: Student and tourist
How to model?
1. Create student table to record Student No, University and
faculty, Course and IsGroupLeader.
2. Link between student and user table with UserName
column
Relational Database
Reason:
1. There are many attributes in Student Class different from
the Tourist Class.
Benefits:
1. Database can reduce duplicated data when it records data
for tourist or student customer.

29. 3) Specialization and Generation of Property Class
Hierarchy of the PROPERTY CLASS
1. Superclass: Property
2. Subclass: House and Flat
How to model?
1. Create Only Property to record data for House and flat
2. Use PropertyType attribute to identify type of property.
3. Use PropertyType attribute to identify type of House
Example of value in PropertyType
1. Flat
2. Detached House Property Table
3. Terraced House
Reason:
1. Every attribute is almost the same
Benefits:
1. Database can reduce duplicated data when it records data
for tourist or student customer.
2. Reduce complexity of database

30. 4.1) EXAMPLE DATA
design
Link 3 tables to identify user
in each type
Ex.
• Tourist Customer
• Student Customer
• Owner
• Group of Student Staff

31. 4.2) EXAMPLE DATA
Table Outcome Class Diagram Design
Use column Property to
identify each property type design
from subclass
Property Type
1. Flat
2. House (Detached &
Terraced house)

32. APPENDIX

33. SQL CREATE TABLE STATEMENT
CREATE TABLE TM_BRANCH( CREATE TABLE TM_USERGROUP(
BranchNo int NOT NULL, UserName int NOT NULL,
BranchName VARCHAR(100) NOT NULL, UserGroup VARCHAR(10) NOT NULL,
District VARCHAR(100), UserTypeName VARCHAR(100) NOT NULL,
Town VARCHAR(100), CONSTRAINT USERTYPE_PK PRIMARY KEY (UserName,UserTypeName)
County VARCHAR(100), CONSTRAINT USER_USERTYPE_FK FOREIGN KEY (UserName)
Postcode VARCHAR(100), REFERENCES TM_USER(UserName));
LandLine VARCHAR(100),
Mobile VARCHAR(100), CREATE TABLE TM_REGISTERUSER (
Fax VARCHAR(100), UserName VARCHAR(20) NOT NULL,
RegisterDate Date NOT NULL, BranchNo int NOT NULL,
CONSTRAINT BRANCH_PK PRIMARY KEY (BranchNo)); RegisterDate Date NOT NULL,
CONSTRAINT REGISTERUSER_REGISTERUSER_PK1 PRIMARY KEY
CREATE TABLE TM_USERTYPE( (UserName,BranchNo),
UserType int NOT NULL, CONSTRAINT REGISTERUSER_USER_FK FOREIGN KEY (UserName)
UserTypeName VARCHAR(100) NOT NULL, REFERENCES TM_USER(UserName),
CONSTRAINT USERTYPE_PK PRIMARY KEY (UserType)); CONSTRAINT REGISTERUSER_BRANCH_FK FOREIGN KEY (BranchNo)
REFERENCES TM_BRANCH(BranchNo));
CREATE TABLE TM_USER (
UserName VARCHAR(20) NOT NULL, CREATE TABLE TM_STUDENT (
Pssword VARCHAR(20), UserName VARCHAR(20) NOT NULL,
UserType int NOT NULL, StudentNo VARCHAR(20) NOT NULL,
FirstName VARCHAR(100) NOT NULL, StudentGroup VARCHAR(20) NOT NULL,
LastName VARCHAR(100), IsGroupLeader CHAR(1) NOT NULL,
Address1 VARCHAR(100), Faculty VARCHAR(100) NOT NULL,
District VARCHAR(100), Course VARCHAR(100) NOT NULL,
Town VARCHAR(100), CONSTRAINT STUDENT_PK PRIMARY KEY (UserName),
County VARCHAR(100), CONSTRAINT STUDENT_USER_FK FOREIGN KEY (UserName)
Postcode VARCHAR(100), REFERENCES TM_USER(UserName));
LandLine VARCHAR(100),
Mobile VARCHAR(100), CREATE TABLE TM_FEATURE (
Fax VARCHAR(100), FeatureNo int NOT NULL,
Email VARCHAR(100), PropertyNo int NOT NULL,
CONSTRAINT USER_PK PRIMARY KEY (UserName), CONSTRAINT ROPERTYFEATURE_PK PRIMARY KEY (FeatureNo
CONSTRAINT USER_USERTYPE_FK FOREIGN KEY (UserType) ,PropertyNo),
REFERENCES TM_USERTYPE(UserType)); CONSTRAINT ROPERTYFEATURE_FEATURE_FK FOREIGN KEY
(FeatureNo) REFERENCES TM_FEATURE(FeatureNo),
CONSTRAINT ROPERTYFEATURE_PROPERTY_FK FOREIGN KEY
(PropertyNo) REFERENCES TM_PROPERTY(PropertyNo));

34. SQL CREATE TABLE STATEMENT
CREATE TABLE TM_PROPERTY( CREATE TABLE TM_ROOMTYPE(
PropertyNo int NOT NULL, RoomType int NOT NULL,
BranchNo int NOT NULL, RoomTypeName VARCHAR(100) NOT NULL,
OwnerNo VARCHAR(20) NOT NULL, CONSTRAINT ROOMTYPE_PK PRIMARY KEY (RoomType));
RegisterDate Date NOT NULL ,
PropertyName VARCHAR(100), CREATE TABLE TM_ROOM(
PropertyType VARCHAR(20), RoomNo int NOT NULL,
DailyPrice FLOAT, PropertyNo int NOT NULL,
WeeklyPrice FLOAT, RoomType int NOT NULL,
MonthlyPrice FLOAT, RoomDesc VARCHAR(255),
YearlyPrice FLOAT, NoOfRoom int NOT NULL,
IsFurnished CHAR(1), RoomWidthUK FLOAT,
TextualDesc VARCHAR(255), RoomLengthUK FLOAT,
HeatingSystem VARCHAR(100), CONSTRAINT ROOM_PK PRIMARY KEY (RoomNo),
RoomNo VARCHAR(100), CONSTRAINT ROOM_PROPERTY_FK FOREIGN KEY (PropertyNo)
FlatNo VARCHAR(100), REFERENCES TM_PROPERTY(PropertyNo),
HouseNo VARCHAR(100), CONSTRAINT ROOM_ROOMTYPE_FK FOREIGN KEY (RoomType)
District VARCHAR(100), REFERENCES TM_ROOMTYPE(RoomType));
Town VARCHAR(100),
County VARCHAR(100), CREATE TABLE TM_EQUIPMENTTYPE(
Postcode VARCHAR(20), EquipType int NOT NULL,
CONSTRAINT PROPERTY_NO_PK PRIMARY KEY (PropertyNo), EquipDesc VARCHAR(255) NOT NULL,
CONSTRAINT PROPERTY_USER_FK FOREIGN KEY (OwnerNo) CONSTRAINT EQUIPMENT_TYPE_PK PRIMARY KEY (EquipType));
REFERENCES TM_USER(UserName),
CONSTRAINT PROPERTY_FEATURE_FK FOREIGN KEY (FeatureNo) CREATE TABLE TM_EQUIPMENT(
REFERENCES TM_FEATURE(FeatureNo), EquipNo int NOT NULL,
CONSTRAINT PROPERTY_BRANCH_FK FOREIGN KEY (BranchNo) RoomNo int NOT NULL,
REFERENCES TM_BRANCH(BranchNo)); 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));

35. SQL CREATE TABLE STATEMENT
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));

36. EXAMPLE OF RELATIONAL DATABASE