FIT2094 Databases
2022 Summer Semester B
Assignment 1A – Conceptual Model – National Fire System (NFS)
Assignment weighting 5%
Assignment marked out of 100 and released as a grade out of 5
Your task for this assignment is to design a database which can be used to support tracking of the building damage caused by bushfires – a National Fire System (NFS).
When a bushfire starts it is noted as a fire event. Each fire event is assigned a unique identifier such as F20200135 and given a name such as “West Forest Fire” (fire event names are not unique, the same name may be reused many times). For a given fire, the date on which the fire started, the coordinates of the estimated start location (latitude and longitude), and the number of hectares which were burnt, are recorded. Sometimes one fire event may spark further fire events, for example when embers travel many kilometres in the wind and start a new fire. The NFS needs to record if a particular fire event was started by sparks from another fire event. Fire events occur within Local Government Areas (LGAs) – a given fire event may involve many LGAs.
A bushfire may impact a property and damage buildings located on that property. The assessment of such damage is the major task of the NFS.
Properties are identified by a unique national property id and have their street address/location and property size in hectares recorded as part of the system. Such properties may be a farm property, a residential property (in a city or town) or a business property. Each property has a single owner who is identified by an owner id. The owner’s name and contact phone number are also recorded. A particular owner may own several properties. For properties such as groups of apartments/villas or units owned by individuals which share lawns, roads etc (i.e. a strata title), the owner of the property, for this scenario, will be taken as the body corporate. In this way, all properties will be regarded as having only a single owner.
Properties are located in a local government area or LGA. Each LGA is assigned a unique LGA code, for example, 45. The LGA’s name, for example, “Wardinia”, size (in hectares), state the LGA is located in, Chief Executive Officer’s name, and bushfire contact phone number are recorded.
A property may have one or more buildings located on the property. Each building on the property is assigned a building number for that property. These building numbers are reused for each property – for example, property 4231212 may have a building number 1, but also property 2133251 may also have a building number 1. Some properties may have no buildings located on them. For a building, the NFS must record the date the building was approved for construction and the size of the building in square metres. If a building is replaced due to fire damage the new building will be assigned a new building number ie. building numbers are not reused within a property.
Page 1 of 6
For this system, we will assume that insurance takes place at a building level only. Each building may be insured by an insurance company, although not all buildings are covered in this manner. For a given building, there will only be a single insurance cover at a particular point in time. However, a given building may be insured by different insurance companies over time. Each insurer is identified by an insurance code, the insurer’s name and contact phone number are also recorded.
An LGA employs several fire damage assessors who carry out initial assessment for all damaged buildings, regardless of insurance cover. These assessors assign a building damage assessed cost. Following this visit by the LGA assessor, the damage is added to the NFS system. Once added, if the building is insured, an insurance assessor will visit and determine the amount to be paid under the building¡¯s current insurance coverage (this may not be the same as the damage cost assessed by the LGA assessor).
Insurance companies employ insurance assessors to visit each building which has been damaged by a fire event, evaluate the building damage assessed cost, and determine the amount to be paid to the building owner. This determination may require multiple visits. Although several visits may be required, only one assessor is used to assess the damage of a given building due to a particular fire event.
All assessors are identified by a unique assessor id. The system needs to record the assessor¡¯s name, their contact number, the type of assessor (LGA or Insurer), and the insurer they currently work for or the LGA they are employed by.
REMEMBER you must keep up to date with the Moodle Ed Assignment 1A forum where further clarifications may be posted (this forum is to be treated as your client).
To view Assignment 1A only posts, select the Assignment 1A forum from the Categories list in the left panel.
Once selected you can Filter the posts via the Filter option at the top of the list of posts:
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).
Page 2 of 6
Please ENSURE you include your group name (eg. Group01) on every page of any document you submit. If a document is a multipage document, please also make sure you include page numbers on every page.
GIT STORAGE
All working files, as your group works on this assignment task, must be stored in Git and must show a clear history of development. Your work for this task MUST be saved in your group¡¯s working directory in the Assignments/Ass1A folder and regularly pushed to the FIT GitLab server to build this history of development. Any submission with less than six pushes to the FITGitLab server will incur a grade penalty of 10 marks (a 10 mark deduction). Please note that six pushes is a minimum, in practice we would expect significantly more. This number of pushes must be evenly distributed amongst group members.
Groups must regularly check that their pushes have been successful by logging in to the web interface of the FITGitLab server; you must not simply assume they are working. Before submission, via Moodle, you must log in to the web interface of the FITGitLab server and ensure your submission files are present on the FITGitLab server.
Git automatically maintains a history of all files pushed to the server, you do not need to, and MUST not, add a version name to your various versions, please ensure you use the same name for all versions of a particular file. Check Git File Versions video under session 3 block on Moodle if you need to clarify this.
Microsoft Teams private group channels have been provided so that group members can meet/communicate and share screens between one another.
The task to complete:
(i) Using LucidChart, prepare a FULL conceptual model (Entity Relationship Diagram) using
crow¡¯s foot notation for the National Fire System (NFS) described above.
¡ñ For this FULL conceptual model (ERD), include:
¡ð identifiers (keys) for each entity
¡ð all required attributes, and
¡ð all relationships. Cardinality (min and max) and connectivity for all
relationships must be shown on the diagram.
¡ñ Surrogate keys must not be added to this model.
Your model must conform to the FIT2094 ERD standards listed in the session 3 tutorial document (page 7).
(ii) 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.
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.
Page 3 of 6
Note that you can share your LucidChart working model between group members via the Share button
in the top right of an open LucidChart document – one student in the group should set up the initial model in a new empty tab and then share this with fellow group members, giving the other group members edit access:
Page 4 of 6
Submission Requirements
Assignment 1A:
Due: Tuesday, 18th January 2022 2 PM (AEDT)
The following files are to be submitted and must exist in your Group FITGitLab server repo: ¡ñ A single page pdf file containing your full final conceptual model. Name the file
nfs_conceptual.pdf. This file must be created via File – Export (or Download As) – PDF from LucidChart (do not use screen capture) and must be able to be accessed with a development history via Gist. You must create this development history by downloading your PDFs (don’t forget to use the same name) and committing/pushing to Git as you work on your model.
¡ñ A PDF document containing any assumptions you wish to make your marker aware of (create the document in MS Word or Google Docs and save it as PDF). Name the file nfs_assumptions.pdf. If you have made no assumptions, submit the document with a single statement saying “No assumptions made”. The source document, as an MS Word document must be available in your GitLab account (for Google Docs simply download as Microsoft Word before adding to your repo).
¡ñ A PDF document of your Group Diary named as nfs_group##_diary.pdf (replace ## with your group number eg. nfs_group01_diary.pdf for Group01)
These three PDF files must be submitted via Moodle before the due date/time (times are expressed in Australia/Melbourne local time). Do not zip these files into one zip archive, submit three independent PDF files. The files must be submitted by all group members for the group submission to be valid.
Late submission will incur penalties as outlined in the unit guide (5 marks deduction per 12 hours or part thereof).
Please note we cannot mark any work on the Git 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. Please carefully read the documentation under “Assignment Task Submission” on the Moodle Assessments page.
Page 5 of 6
Marking Rubric
Outstanding (HD)
Adequate (Range P – D)
Not Adequate (N)
Identified the required Entities [30 marks]
¡ñ All/most entities identified.
¡ñ All/most keys are correctly identified.
¡ñ No “extra” entities included
¡ñ Majority of entities identified.
¡ñ Majority of keys are correctly identified.
¡ñ None or few of entities identified.
¡ñ None or few of keys are correctly identified
Identified the correct attributes for each Entity [30 marks]
¡ñ All/most required attributes identified and placed in correct entities.
¡ñ No “extra” attributes included
¡ñ Majority of required attributes identified and placed in correct entities.
¡ñ None/few required attributes identified and placed in correct entities.
Identified the required Relationships [10 marks]
¡ñ All/most required relationships identified.
¡ñ No “extra” relationships included
¡ñ Majority of required relationships identified.
¡ñ None/few required relationships identified.
Identified all Cardinalities for every relationship [20 marks]
¡ñ All/Most of depicted relationships
Connectivity and Cardinality correctly identified.
¡ñ Majority of depicted relationships
Connectivity and Cardinality correctly identified.
¡ñ None/few of depicted relationships
Connectivity and Cardinality correctly identified.
Able to correctly use the required notation convention and be consistent in its usage.
[10 marks]
¡ñ All notations in the model are consistent and follow FIT2094 ERD standards.
¡ñ Most notations in the model are consistent and follow FIT2094 ERD standards.
¡ñ Few notations in the model are consistent or follow FIT2094 ERD standards.
Able to correctly push the model to FITGitLab server with a development history of at least six pushes.
If less than six pushes showing a clear development history a grade deduction of 10 marks applied.
Page 6 of 6