Scribd
Upload
157 views6 pages

FIT9132 Tutorial 6 Sample Solution

Uploaded by

Le Duy Tho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
157 views6 pages

FIT9132 Tutorial 6 Sample Solution

Uploaded by

Le Duy Tho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

FIT9132 Introduction to Databases

Week 6 Tutorial Suggested Solution


LOGICAL MODELLING
FIT Database Teaching Team

FIT9132 2020 S1

FIT9132 Introduction to Databases

Author: FIT Database Teaching Team

License: Copyright © Monash University, unless otherwise stated. All Rights Reserved.

COPYRIGHT WARNING
Warning

This material is protected by copyright. For use within Monash University only. NOT FOR
RESALE.

Do not remove this notice.

1
6.2 Using SQL Developer Data Modeler
6.2.3 Develop a model - Stage 1 The Logical Mode

Customer Orders Case Study

2
6.3 Property-Rental Model
6.3.1 Drawing Logical Model

Note:
● Surrogate keys of rent_agreement_no and dam_no added to RENT and DAMAGE
respectively. Note that when a surrogate key is added, a unique identifier is created
to maintain the natural key.
● Since the model is to be implemented in Oracle date and time can be stored in a
single DATE type attribute
● In one to one relationship between PAYMENT and DAMAGE, the FK should be
placed in DAMAGE (remember that you have to place FK in a relation such that the
database has less null values). Thus, the Dominant Role is set as PROPERTY and
the FK is placed in DAMAGE.

3
Part of the case study indicates that the payment type must be recorded as Rent, Bond or
Damage. This should be enforced by adding a CONSTRAINT. This constraint becomes part
of the database structure, if the user wishes to add a new option, say 'F' for future rent
payments then the structure must be altered.

The picture below shows controlling pay_type via a CONSTRAINT (CHK_PAY_TYPE) - add
a check clause to payment.pay_type:

The case study also indicates that it needs flexibility in the design to be able to add new, and
remove current, payment methods as circumstances change. This should be handled by
adding a LOOKUP table. Lookup tables are a good approach where there is likely to be a
need to extend the possible values for an attribute. In the diagram, we add a new relation
(PAYMETHOD) and add a relationship between PAYMETHOD and PAYMENT relation. Note
that the name of FK can be different from PK name. You can change the name of FK by
double click the FK attribute in child relation → change the attribute name.

4
5
6.3.2 Generate Relational (Physical) Model

The schema file is provided as part of this solution.

To capture the full run of your schema file you must insert a SPOOL and ECHO on
command at the top of your file, and a SPOOL OFF and ECHO off at the end of your script.

For example - added to the top of your script:


-- Capture run of script in file called rental-run.txt
SET ECHO ON
SPOOL prop_rental_schema_output.txt

-- Database Teaching Team


-- Property Rental Logical Model Schema script file
-- Schema file includes example constraint to control pay_type

….. the SQL Developer Generated Script goes here …...


-----------------------------------------------------
SPOOL off
set echo off

Please check the sample solution schema files to see this in action.

You might also like