It's UWAweek 42 (2nd semester, week 12)

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 9 articles in this topic
Showing 9 of 612 articles.
Currently 118 other people reading this forum.


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

Login to reply

👍?
helpful
12:06pm Tue 27th Aug, ANONYMOUS

Hello, Worksheet number 2 has a question that goes as follows: Q) Display credit code, and the count of publishers in a column called Number of publishers. Then group according to the creditcode for all the cases where either the count is greater than 2 or the city or phone is not empty. Then apply ascending order. Solution: SELECT creditcode, count(cust_id) AS 'Number of Publishers' FROM publishers GROUP BY creditcode HAVING count(cust_id) > 2 and city OR phone IS NOT NULL ORDER BY creditcode ASC; My query is that: 1) In the HAVING clause, shouldn't the answer by "OR city OR phone IS NOT NULL"? Why is it and when the question explicitly states "either or" 2) Can we have an alternative solution that goes like this, using the where clause: select creditcode, count(cust_id) as "number of publishers" from publishers where city or phone is NOT NULL group by creditcode having count(cust_id)>2 order by count(cust_id) desc; Would this be incorrect? If so then why? Thanks


SVG not supported

Login to reply

👍?
helpful
5:11pm Tue 27th Aug, ANONYMOUS

Fellow student response! The context for Worksheet 2 was the same as Lab 2 so I used the data provided for that lab on the Jinhong server to test the queries you proposed and this is what I found:

  1. Not sure why this is. All I can say for sure is that for the data provided in Lab 2, both the 'AND' statement in the solution and 'OR' statement you have provided will give the same result. I tried some other updates and inserts to see if the results would change but I just ended up confusing myself more so I won't put them here. Hopefully someone else can provide some further clarification?

  2. This alternative query will not give the same result as the solution because the 'WHERE' clause is executed before the 'HAVING' clause. This means the alternative query knocks out any tuples that have null city/phone fields and then checks that count(cust_id)>2, rather than the solution which checks for one or the other on the same line. Hope that helps :>


SVG not supported

Login to reply

👍?
helpful
6:53pm Tue 27th Aug, Mehwish N.

Hi, In principle the AND and OR should not give the same result, however, given the tiny amount of data the sample file has, it may give you the same result. You can add more test data to test your queries on your own computer.

The where clause will get executed before groupby. It is possible that for certain scenarios it may not make a difference but what this actually does is that it filters out rows before grouping them and then applying the filtering via the having clause.

Cheers


SVG not supported

Login to reply

👍?
helpful
3:34pm Wed 28th Aug, Adam W.

Hi, This has also been updated, there is an issue with the way the conditions in the having are evaluated. HAVING count(cust_id) > 2 AND city OR phone IS NOT NULL should be HAVING COUNT(cust_id) > 2 AND (city IS NOT NULL OR phone IS NOT NULL) You need to have the criteria attached to both of the boolean checks (for city and for phone). It could be that sqlite lets you do this, by evaluating the 'city' as true automatically, then it would be 'TRUE OR phone IS NOT NULL' which would automatically mean its always going to be TRUE. Thanks, Adam. ANONYMOUS wrote:
> Hello, > > > Worksheet number 2 has a question that goes as follows: > > Q) Display credit code, and the count of publishers in a column called Number of > publishers. Then group according to the creditcode for all the cases where either the > count is greater than 2 or the city or phone is not empty. Then apply ascending order. > > Solution: > > SELECT creditcode, count(cust_id) AS 'Number of Publishers' > FROM publishers > GROUP BY creditcode > HAVING count(cust_id) > 2 and city OR phone IS NOT NULL > ORDER BY creditcode ASC; > > > My query is that: > > 1) In the HAVING clause, shouldn't the answer by "OR city OR phone IS NOT NULL"? Why is it and when the question explicitly states "either or" > > 2) Can we have an alternative solution that goes like this, using the where clause: > > select creditcode, count(cust_id) as "number of publishers" > from publishers > where city or phone is NOT NULL > group by creditcode > having count(cust_id)>2 > order by count(cust_id) desc; > > Would this be incorrect? If so then why? > > Thanks


SVG not supported

Login to reply

👍?
helpful
10:37pm Wed 28th Aug, ANONYMOUS

So the final correct would be like this ? ------------------------------------------------------------- SELECT creditcode, count(cust_id) AS 'Number of Publishers' FROM publishers GROUP BY creditcode HAVING COUNT(cust_id) > 2 AND (city IS NOT NULL OR phone IS NOT NULL) ORDER BY creditcode; -------------------------------------------------------------


SVG not supported

Login to reply

👍?
helpful
1:25pm Thu 29th Aug, ANONYMOUS

I was thinking it would be: SELECT creditcode, count(cust_id) AS 'Number of Publishers' FROM publishers WHERE city IS NOT NULL OR phone IS NOT NULL GROUP BY creditcode HAVING COUNT(cust_id) > 2 ORDER BY creditcode; Am I wrong?


SVG not supported

Login to reply

👍?
helpful
5:10pm Thu 29th Aug, Chien-An T.

Given the statement "Then group according to the creditcode for all the cases where 'EITHER' the count is greater than 2 or the city or phone is not empty." in the Question, we know that EACH of the following fulfilled SHOULD be listed: 1. count(cust_id) is greater than 2 2. the city or phone is not empty So these are the "OR" relationship, for instance, the following extreme condition should be listed: a. count(cust_id) <= 2 but the city or phone is not empty b. count(cust_id) > 2 but the city and phone are both empty And since the WHERE query will process before aggregator and grouping/having queries, we cannot use WHERE query for this 'OR' relationship otherwise it will become an 'AND' relationship Hence the query should be: SELECT creditcode, count(cust_id) AS 'Number of Publishers' FROM publishers GROUP BY creditcode HAVING COUNT(cust_id) > 2 OR city IS NOT NULL OR phone IS NOT NULL ORDER BY creditcode;


SVG not supported

Login to reply

👍?
helpful
9:31am Fri 30th Aug, ANONYMOUS

In that case, shouldn't the GROUP BY clause also have phone and city in it? In one of the slides I saw that if attributes are not in an aggregate function in the HAVING clause, they must be mentioned in the GROUP BY clause.


SVG not supported

Login to reply

👍?
helpful
8:09pm Fri 30th Aug, Chien-An T.

ANONYMOUS wrote:
> In that case, shouldn't the GROUP BY clause also have phone and city in it? In one of the slides I saw that if attributes are not in an aggregate function in the HAVING clause, they must be mentioned in the GROUP BY clause.
Yes you are right The SQL standard requires that HAVING must reference only columns in the GROUP BY clause or columns used in aggregate functions. However this usage of HAVING clause is supported and workable in SQLite & MySQL (Yes we are able to derive the correct query with this syntax) If we follow the SQL standard, the following query is both syntactically & semantically correct: SELECT creditcode, COUNT(cust_id) AS 'Number of Publishers' FROM publishers WHERE city IS NOT NULL OR phone IS NOT NULL OR creditcode IN ( SELECT creditcode FROM publishers GROUP BY creditcode HAVING COUNT(cust_id) > 2 ) GROUP BY creditcode ORDER BY creditcode;

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