[Informatics] Info exam - B1b - The Curse of Chen !

Robert Hind robert at yinnar.com
Wed Nov 23 16:29:31 AEDT 2016


I would disagree with your statement "One customer can buy Reebok Pumps and
Nike Air Jordans (but not in the same purchase)"
 
In real life of course you might buy several items in the one purchase and
on the one invoice. Would require an extra table as well, so you might have
a SALES table with SalesID, DateOfSale, PuchaserID, TotalPaid, etc plus a
SALESDETAILS table which would contain the details for each of the items in
a particular sale: ItemID, ItemPrice, ItemQuantity . . . 
 
Databases can be such fun
 
Robert Hind
Ex Traralgon and Ashwood
Retired

  _____  

From: informatics-bounces at edulists.com.au
[mailto:informatics-bounces at edulists.com.au] On Behalf Of Garth, Lucas A
Sent: Wednesday, 23 November 2016 4:03 PM
To: Year 12 VCE Informatics Teachers' Mailing List
Subject: Re: [Informatics] Info exam - B1b - The Curse of Chen !



Hi Mark

 

Surely this is doable in terms of the drawing - to link customer and shoe
with M:N and use the verb PURCHASES or BUYS:


Cardinality - The number of entities to which another entity can be
associated through a relationship

The diagrams on the right show, in order:

one-to-one

one-to-many

many-to-one

many-to-many

 

 



 

 

I agree that the answer should be many to many (M:N) because of the use of
the word customers rather than customer.  Many customer can buy Nike Air
Jordans.  One customer can buy Reebok Pumps and Nike Air Jordans (but not in
the same purchase).

 

This situation is where an ERD is going to differ to how the database is
actually built. Whenever there's a M:N, generally there's a linking table
created in the middle with the primary keys of the entities.  In this case
the middle table could conceivably be the sales table that can then link the
item and shoe and contain the sales date and amount values.  (But this would
potentially make it an entity.shh)

 

I also agree there should be a sales table.  It's part of a list of the
types of databases (sales & customer, payments, music, bookings) that I
teach my students to be ready for the exam (and real life).

 

Lucas

 

From: informatics-bounces at edulists.com.au
[mailto:informatics-bounces at edulists.com.au] On Behalf Of Mark
Sent: Wednesday, 23 November 2016 3:14 PM
To: Year 12 VCE Informatics Teachers' Mailing List
Subject: [Informatics] Info exam - B1b - The Curse of Chen !

 

Hi all. Apologies again if this question has already been discussed to
death, but I have restrained from reading exam discussion until I finish the
first draft of my post mortem.

 

So, B1b and Chen !

 

(I added the exclamation mark to make dull ERD discussion more exciting. Did
it work?)

 

Point 1.

 

I'm guessing the markers are expecting a diamond labelled "BUYS" with a 1
(customer) to M (shoe) relationship since the question said that one
customer can buy more than one pair of shoes.

 

But in the real world many types of shoes can be bought by many different
customers, so it should be many-to-many (M:N). 

 

Will markers accept a common-sense answer?


 

Point 2.

 

"Date Sold" is shown as an attribute of the SHOE entity. This is absurd.
This would mean that each style of shoe could only ever be sold once.

 

Obviously, 'Date Sold' is an attribute of a transaction entity, not a shoe
entity, so the ERD violates 3NF.

 

How can a Chen ERD make the correct relationship clear? I've been trying to
sketch it out using VCAA conventions, without success. 

 

Should the "Date Sold" actually be an attribute of the "Buys" relationship? 

 

Can Chen relationships even have attributes? 

 

Not according to VCAA's 'ER
<http://www.vcaa.vic.edu.au/Documents/vce/computing/Informatics_examination_
ER_Conventions.docx> Conventions' document. 

 

But it's the only way I can do it using VCAA's Chen conventions.

 

 

Newsflash. Research in The Real World (TM) reveals Chen relationships CAN
have attributes !

 

See http://www.conceptdraw.com/How-To-Guide/erd-how-to-draw-er-diagrams

 

Specifically -
http://www.conceptdraw.com/How-To-Guide/picture/Chen-ERD--sample.png

 

It shows how relationships can have attributes attached, for example the
"Has" relationship has attributes, "LastPlayed" and "CreatedOn".

 

But then again, the Conceptdraw site also tells us there are scary beasties
like : multivalue attributes; derived attributes; weak (identifying)
relationships; and associative entities - so I suppose we should be grateful
that students have been firewalled from some of The Real World.

 

 

Warning - pointless rant begins...

(don't say you weren't warned)

 

Maybe I just am prejudiced against nice Mr Chen (who probably did many
wonderful things in his career) but I can't accept an ERD that makes no
logical sense and makes me feel all icky inside*. 

 

Maybe it's just VCAA's interpretation of his work that fails to satisfy.  If
VCAA made a movie of 'The Sound of Music', I'd bet they would leave out all
of the songs in order to make the film shorter **.

 

So, long live crows feet ERDs ! 

 

OK. I've come out and said it proudly. I've been quiet on the issue until
now, but crows feet rock my world***.

 

Regards,

Mark

 

P.S. This entire post may be a cunning plan to get you to look deeply into a
single exam question and find the deliberate glaring error in my analysis
and formulate an equally-cunning substantiated repudiation of my thesis.

 

FOOTNOTES

 

* Adam Sandler movies do much the same thing to me.

** This reputedly happened in South
<http://unrealfacts.com/one-south-korean-theatre-removed-all-music-scenes-fr
om-the-sound-of-music/> Korea.

*** It has been established before now that my life is not at all rocked. It
is sad and wretched. I eat tinned dolmades (sorry, Litsa), dogs are not my
best friend, and I still want Pluto to be a planet. Sob.

 

-- 

 

Mark Kelly

 

 <mailto:mark at vceit.com> mark at vceit.com

http://vceit.com

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7924 / Virus Database: 4664/13459 - Release Date: 11/22/16


IMPORTANT - This email and any attachments may be confidential. If received
in error, please contact us and delete all copies. Before opening or using
attachments check them for viruses and defects. Regardless of any loss,
damage or consequence, whether caused by the negligence of the sender or
not, resulting directly or indirectly from the use of any attached files our
liability is limited to resupplying any affected attachments. Any
representations or opinions expressed are those of the individual sender,
and not necessarily those of the Department of Education and Training.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/informatics/attachments/20161123/7cf3aeb0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5078 bytes
Desc: not available
Url : http://www.edulists.com.au/pipermail/informatics/attachments/20161123/7cf3aeb0/attachment-0001.png 


More information about the informatics mailing list