Welcome! Log In Create A New Profile

Advanced

Ambiguities in Assigment 2

Posted by stevenv 
Announcements Last Post
Announcement SoC Curricula 09/30/2017 01:08PM
Announcement Demarcation or scoping of examinations and assessment 02/13/2017 07:59AM
Announcement School of Computing Short Learning Programmes 11/24/2014 08:37AM
Announcement Unisa contact information 07/28/2011 01:28PM
Ambiguities in Assigment 2
April 30, 2007 10:57AM
There are way too many ambiguities in Assignment 2 for my liking, I sincerely hope that this is not an indication of what the exam will be like in Oct/Nov.

For instance (and I've already posted a thread about this), in Question 2.2 the question states "Which boat is still due for a service and when?" which indicates that the Next_Service value should be in the future but in the sample data, all the dates are in the past UNLESS you assume we are all living in 2005 right now and that requesting the current date will return some date where we can possibly have one of the given sample data thus occurring in the future.

Again, in question 2.11 where the question is "Delete the next service scheduled between 2005/01/01 and 2005/12/31". There are two services scheduled during these dates so how does one define "the next service scheduled" when if the current date is 2005/06/1, the next service is 2005/09/15 and if the current date is 2005/09/20 then the next service is 2005/10/10.

Furthermore, what is it exactly that they're asking for in 2.12? Is it something along the lines of page 638-640 of the textbook or is that they want some simple arithmetic to find the numerical difference between Spent_Hours for service request and job card tables respectively?
Re: Ambiguities in Assigment 2
May 01, 2007 07:13PM
for q2.1
The SERVICE_REQUEST table by itself won't have sufficient info for due service boad, you have to determine it in conjection with SLIP table by compare with the difference between both Slip_Num column in these two table.

My try:
select Boat_Name
from SLIP
where Slip_Num not in (select Slip_Num from SERVICE-REQUEST);



for q2.11
The question just want you to detelet the rows with the Next_Service column content between 2005/01/01 to 2005/12/31. It doesn't matter the current date.

My try:
delete from SERVICE_REQUEST
where Next_Service between #2005/01/01# and #2002/12/31#;


for q2.12
The question just want you to compare the SERVICE_REQUEST and the JOB_CARD table which obviously the Slip_Num, Category_Num,and Spent_Hours columns are the different columns and the Service_ID with content 1 and 2 in S_R table are different with the J_C table.

My try:
select *
from SERVICE_REQUEST
where * not in (select * from JOB_CARD);



How about q2.5 where in the text book can I find the SQL-92 standard. What four options they are talking about? Are they mean
restrict
cascade
constraint
unique ?

How about q1.13? what funcions can I use for the question? Maybe I should use Group by?

Any idea?
Re: Ambiguities in Assigment 2
May 01, 2007 11:27PM
Thanks for the response smiling smiley

2.1: Not a bad suggestion. Originally, someone suggested you 'fake' the current date returned by the function Now() to be sometime during 2005 and then write a query that would return the next service date. I tend to like your suggestion a bit more though.

2.11: The problem with that is that it will delete all services scheduled between those dates, not just the next service. I found a solution to this one where you use the MS Access function TOP 1 in conjunction with an order by which returns just the first record in date order which is essentially the next service.

2.12: This one is still stumping me.

2.5: Did some research online and found that they might be referring to cascade, delete, set null and set default. Not 100% sure about this one though.

1.13: This one was tricky but found that if you use a self-join you can have two copies of the dataset to work with i.e. two copies of description and two copies of charge and then all you have to do is the necessary comparisons on description and charge to write the query.

Steven
Re: Ambiguities in Assigment 2
May 02, 2007 06:14AM
1.12: How did you interpret this request?

To me it looks like they want us to create the table then insert the procedures from the TREATMENT table as well as a made-up Duration_Hour. Physician_ID and Cost should be left blank.
Re: Ambiguities in Assigment 2
May 02, 2007 12:15PM
Questions 2.1 and 2.12 contain ambiquities which make them impossible to evaluate fairly, i.e. no marks will be awarded for those questions. Exam questions are checked by external moderators so there should not be any ambiquities there.
Re: Ambiguities in Assigment 2
May 02, 2007 07:31PM
Q1.10
"List each patient's number and the total of his/her bill."

There is no price for a tonsillectomy or a private room, should we just answer the question without it?
Re: Ambiguities in Assigment 2
May 02, 2007 10:14PM
Don't worry about the cost of the treatment they received, focus on the CHARGES table which links patients with the charges against them.
avatar Re: Ambiguities in Assigment 2
May 03, 2007 08:04AM
stevenv Wrote:
-------------------------------------------------------
> Don't worry about the cost of the treatment they
> received, focus on the CHARGES table which links
> patients with the charges against them.


Yip, and use the SUM and Group By functions.
Re: Ambiguities in Assigment 2
May 03, 2007 04:05PM
vbiljja Wrote:
-------------------------------------------------------
> Questions 2.1 and 2.12 contain ambiquities which
> make them impossible to evaluate fairly, i.e. no
> marks will be awarded for those questions. Exam
> questions are checked by external moderators so
> there should not be any ambiquities there.

Is this considered an official response?
avatar Re: Ambiguities in Assigment 2
May 04, 2007 08:42AM
Well she is a senior lecturer at UNISA, and Lecturer for this Module (according to osprey), so I guess so. smile
Re: Ambiguities in Assigment 2
May 04, 2007 03:34PM
Oops tongue sticking out smiley
Sorry, only registered users may post in this forum.

Click here to login