It's UWAweek 47

help1402

This forum is provided to promote discussion amongst students enrolled in CITS1402 Relational Database Management Systems.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

How do I ask a good question?
Displaying the 2 articles in this topic
Showing 2 of 684 articles.
Currently 10 other people reading this forum.


 UWA week 35 (2nd semester, week 6) ↓
SVG not supported

Login to reply

👍?
helpful
3:26pm Mon 26th Aug, Andre H.

Hi everyone, I just wanted to put up some discussion to see your view regarding this point in the project. So we do have this point here in the scenario. For each make of car, the daily rental tariff ($ 3) is recorded for each of the tariff types

So I assume we can infer a weak entity “make” like this Image

Since we already have a weak entity named “Make” then we should put that in our entity data dictionary. So we can at least show it like this. Image

So currently we have like this redundancy, I think we can swap out “make” in vehicle to use the “make_name from our make entity Image

So the relationship will somehow become like this Image

However, since we have already removed the make, won’t that mean in the atttribute dictionary vehicle will lose the “make” field (since we cannot put foreign key because we are still in conceptual stage)? Image

I wanted to know if some of you maybe have different opinion or different way to solve this.


SVG not supported

Login to reply

👍?
helpful
11:19pm Mon 26th Aug, Jichunyang L.

Hi,

Good thinking!

I think you can have 2 options:

Option 1: Retain "Make" as an independent entity if you anticipate adding more attributes to it in the future. This approach allows for extensibility but might introduce some redundancy in the current model.

Option 2: Treat "make_name" as an attribute of the "Vehicle" entity if you foresee that "Make" will remain simple without additional details. This simplifies the schema but restricts the ability to expand "Make" related details in the future.

These options provide flexibility depending on your project's specific needs and anticipated developments.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  8:08AM Aug 25 2024
Privacy policy