Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

FIT2094 Databases

Normalisation and Logical Database Design - World Cruises (WC)



Purpose

Given the provided case study from assignment 1A, and additional forms/documents related to the case study, students will be asked to transform the information provided into a sound database design and implement it in Oracle. This task covers learning outcomes:

1. Apply the theories of the relational database model;

2. Develop a sound relational database design;

3. Implement a relational database based on a sound database design.



Your task

This is an open book, group task (students will work in groups of two or three students with members selected randomly). The final output for this task will be a logical model implemented in the Oracle RDBMS




INSTRUCTIONS

This task continues the work you have started in assignment 1A by refining/extending the model you developed and implementing it as a set of tables under your Monash Oracle   database account.

Since this is an ongoing development process based on your assignment 1A submission      and marker feedback, you must ensure that your assignment 1A submission and the    marker feedback remains confidential and is only seen by the members of your group and the FIT2094 teaching staff.

Assignment 1B's brief must be read in conjunction with the assignment 1A brief - ie. your      final model must encompass both sets of requirements. You may modify your assignment 1A conceptual model in any manner you wish as you work through assignment 1B, provided      your final model meets both sets of requirements.

In developing your final logical data model, composite attributes present on your conceptual model must be expanded into their component simple attributes, unless otherwise directed. If the supplementary material presented in this document does not guide you in deciding the components you may make any reasonable decision on their simple component attributes.

Further discussions with World Cruises have revealed the points listed below:

a.  World Cruises record for each passenger their contact phone number, for a minor no contact number will be recoded, the contact for their guardian will be used (in            modelling this point keep phone number as a simple attribute of passenger, do not    create a further PHONE relation)

b.   at ports, where a cruise stops, local entrepreneurs offer various tours to the                passengers which they can participate in while the ship is in port. The tours are not    specific to a particular cruise, any ship which is in port can have passengers partake  in an advertised tour. Some tours provide audio commentary to help explain what      passengers are experiencing. Where possible the tours are encouraged to supply the commentary in a range of languages so as to support the needs of as many               passengers as possible. The commentary languages available for a tour must be       stored as part of your model.

Tours are offered at regular intervals for example every weekday, every Saturday, on Monday only, etc (this range of offerings may be changed regularly, including adding new ranges). A particular tour only runs once on any given date.

Each offering of a particular tour uses the same tour number. Tour numbers are   reused for each port ie. each port has a tour number 1. Each tour has a minimum number of participants, a particular tour offering is not run unless this minimum    number of participants have booked for it.

c.   cabins across the various ships are assigned a cabin class as one of the following

○    interior

    ocean view

○    balcony, or

    suite

These classes are fixed and will not be modified.


d.   country codes stored in the system make use of the ISO 3166-1 Alpha-2 codes eg. Australia is AU

e.   languages stored in the system are stored as ISO 639-1 Alpha-2 codes eg. English is EN

f.    latitudes and longitudes stored in the system are stored in decimal form, for example the latitude and longitude of Hobart, Tasmania, Australia is:

    latitude: -42.8825088

    longitude: 147.3281233

World Cruises have supplied the following forms which are used within their business:

(i) Tours which are available in a given port:

(ii) Participants for a particular tour instance:

 

REMEMBER you must keep up to date with the Ed Assignment 1B forum where further      clarifications may be posted (this forum is to be treated as your client). Please be careful to

ensure you do not publicly post anything which includes your reasoning, logic or any part of your work to this forum, doing so violates Monash plagiarism/collusion rules and   has significant academic penalties. Use private posts or email your allocated tutor to raise    such questions.

You are free to make assumptions if needed however they must align with the details here    and in the assignment forums and must be clearly documented (see the required submission files). Other than surrogate keys, where appropriate, you must remember the design adage  "All that is required has been included and all that is included was required" ie. you must not add features outside the requirements expressed in the brief.

TASKS

ENSURE your group name and members names are shown on every page of any         document you submit. If a document is a multipage document (such as the normalisation), please also make sure you include page numbers on every page.

GIT STORAGE

Your work for these tasks MUST be saved in your group local working directory (repo) in the Assignment 1B folder and regularly pushed to the FIT GitLab server to build a clear history of development of your model. Any submission with less than nine pushes to the FITGitLab      server will incur a grade penalty of 10 marks. Please note nine pushes is a minimum, in        practice we would expect significantly more. This number of pushes must be evenly              distributed amongst group members.

Before submission via Moodle you must log into the web interface of the GitLab server and ensure your files are present in the group repo.

All source documents must be available in your group's FIT GitLab server account or your MS Teams channel and must not be modified in any manner following your submission.

If multiple students work on a logical model at the same time, merging these changes can be quite difficult. For this reason you are required to take a simple approach to working on the   model - whenever a particular student wishes to work on the model you should go to  the Git Server web interface and check if the assignment 1B folder has been locked by another        member of your group.

If it has, you must not carry out any work on the assignment task.

If it has not been locked, you can proceed to lock the folder by selecting "Lock":

 

Ensure you are located in the correct folder.

You will know the items are locked as each will have a lock icon attached to it:

 

If you hover over the padlock icon, you will be able to see who currently has the folder locked.

When you have completed your work, and pushed it to Git, you should return to the Git web interface and unlock the folder:

 

It is our expectation that all members of the group will contribute to building the model, it must not be completed by just one member. In assessing your group's work we will   examine the commit log to ensure all members of the group have participated.

Task to complete:

1.   Perform normalisation to 3NF for the data depicted in the sample documents.

The approach you are required to use is the same approach as shown in the        normalisation applied class solution. The normalisation must be carried out form by form, beginning by representing the document you are working on as a single UNF relation and then moving through 1NF, 2NF and 3NF.

During normalisation, you must:

○    Not add surrogate keys.

    Include all attributes (you must not remove any attribute as derivable)

○    Clearly show UNF, 1NF, 2NF and 3NF.

    Clearly identify the Primary Key in all relations.

○    Clearly identify all dependencies at the various normalisation stages (Partial at 1NF, Transitive at 2NF and Full at 3NF). You should use the same notation

as depicted in the normalisation sample solutions, for example: attr1 -> attr2, attr3

If none exist you must note this by stating:

No partial dependencies present and/or

No transitive dependencies present

    If required, carry out attribute synthesis.

The attribute names used throughout your normalisation and those on your subsequent logical model must be the same.

Your normalisation must be carried out in an MS Word document in your group’s private MS Teams channel so that a full development history is available.

2.   Based on your group’s assignment 1A conceptual model, your markers feedback, your reading of this case study and the normalisations you carried out in step 1 above,        prepare a logical level design for the World Cruises database.

○   The logical model must be drawn using the Oracle Data Modeler. The          information engineering or Crow’s foot notation must be used in drawing the model. Your logical model must not show data types.

    All relations depicted must be in 3NF

○    You are required to add at least one surrogate key to your design (you are free to select the most appropriate relation to make this change in)

○    All attributes must be commented in the database (ie. the comments must be part of the table structure, not simply comments in the schema file).

○    Check clauses/look up tables must be applied to attributes where appropriate.

○    You MUST include the legend as part of your model. Please edit the legend panel to show your group name

○    Note that your GIT repository must clearly indicate your development history with multiple commits/pushes as you work on your model.

3.   Generate the schema for the database in Oracle Data Modeler and use the schema to create the database in your Oracle account (this should be tested in your individual Oracle accounts - a group Oracle account is not available).

The only edit you are permitted to carry out to the generated schema file is to add     header comment/s containing your details (group/members names) and the                commands to spool/echo your run of the script. In generating your schema file ensure you:

○  Capture the output of the run of your schema statements using the spool command.

   Ensure your script includes drop table statements at the start of the script .

  Name the schema file as wc_schema.sql.

4.   Maintain a Group Diary which records when the group met/communicated to            discuss/work on the task, including the date, who was present and a brief statement of what occurred. This Group Diary must be maintained in Microsoft Teams as a      shared document in your private group channel.

As part of submission of your assignment each group member will be required to provide  confidential feedback on the group members performance/interactions. Where uneven     contributions to the task are noted the awarded mark will be amended (reduced) for members who have not fully participated.

Please note when working with your model ensure that you DO NOT select any export options from the Data Modeller menu:

 

such actions can fill your Oracle account space and render it unusable.

Submission Requirements

Assignment 1B: Due: Thursday, 28 April 2022, 4:30 PM (AEST)

The following files are to be submitted and must exist in your group FITGitLab server repo. The source files must exist in either your GitLab Repo or your MS Teams Private channel:

●  A pdf document showing your full normalisation of the sample World Cruise    documents showing all normal forms (UNF, 1NF, 2NF and 3NF). Name the file

wc_normalisation.pdf

●  A single page pdf file containing the final logical Model you created in Oracle Data   Modeler. Name the file wc_logical.pdf. This pdf must be created via File - Data        Modeler - Print Diagram - To PDF File from within SQL Developer, do not use screen capture.

●   A zip file containing your Oracle Data Modeler project (in zipping these files be sure you include the .dmd file and the folder of the same name). Name the file

wc_oraclemodel.zip.

Part of the assessment of your submission will involve your marker extracting your     model from this zip, opening it in SQL Developer Data Modeller, engineering to a new Relational model and from this your marker will generate a schema which will then be compared with your submitted schema (they must be the same for your schema to     be accepted). For this reason your model must be able to be opened by your         marker and contain your full model otherwise your task 2 and 3 will not be able to be fully marked resulting in significant loss ofmarks. You MUST carefully        check that your model is complete - ensure you take your submission archive, copy it to a new temporary folder, extract your submission parts, extract your model and        ensure it opens correctly before submission. Please view the video on Moodle under week 6, "Preparing Files for Submission", which demonstrates this process.

●  A schema file (CREATE TABLE statements) generated by Oracle Data Modeller. Name the file wc_schema.sql

●  The output from SQL Developer spool command showing the tables have been created. Name the file wc_schema_output.txt

●  A pdf document containing any assumptions you have made in developing the model or comments your marker should be aware of. If you have made no assumptions,      submit the document with a single statement saying "No assumptions made". Name the file wc_assumptions.pdf

●  A PDF copy of your group diary named as wc_group##_diaryAss1B.pdf (replace ## with your group number eg. wc_group01_diaryAss1B.pdf for group01)

These files must be submitted as individual files ie. you must upload to Moodle seven     separate files as named above (the seven files must not be zipped into a single archive)  before the assignment due date/time.  The files only need to be submitted by one           member of the group after the group has agreed that the submission is complete and ready to be graded.

Late submission will incur penalties of 10 marks deduction per day or part thereof late. Submissions are not accepted beyond 7 days late.

Please note we cannot mark any work on the FITGitLab Server, you need to ensure that  you submit correctly via Moodle since it is only in this process that you complete the required student declaration without which work cannot be assessed.

It is your responsibility to ENSURE that the files you submit are the correct files - we  strongly recommend after uploading a submission, and prior to actually submitting in Moodle, that you download the submission and double-check its contents.

Your assignment MUST show a status of "Submitted for grading" before it will be marked.

 

If your submission shows a status of "Draft (not submitted)" it will not be assessed and will incur late penalties after the due date/time.

Resubmission

If you wish to resubmit your assignment you must email your tutor, provide your full details  as listed in the Unit Information (see below) and request that they reopen your submission  for a second submission. Note if this resubmission is after the due date/time the submission will be regarded as late.

You must NOT assume that your tutor will be available if you require a resubmission close to the due date/time - they may have classes or not be available for other reasons, so do not    leave submission to the very last minute.

When you contact your tutor (or workshop leader) via email, please ensure you clearly       include your full name, unit code and applied class number as part of every email you send so they can identify who the message has come from. This will ensure we can respond as  quickly and accurately as possible.


Marking Guide

Submitted designs will be assessed against the optimal solution for this task - this optimal solution will be available as a sample solution after assignment 1B has been graded.