[mcgivernj]

26/08/2021 at 6:51 am

Morning all
Looking at the 2020 AH SQA paper question 7b – and it’s got me confused.
Solution says me that parking space is a weak entity. Why (as it has no primary key dependant on other entities)? Foreign key something to do with it? And does that mean every entity with a foreign key is a weak entity?
And why is the line between carPark and Parking Space not dotted if one of the entities is weak?

There was me thinking strong and weak entities was a very straightforward matter. Appreciate any feedback.

[Peter Thoresen]

26/08/2021 at 10:39 am

This threw me as well, thinking strong/weak was about the primary keys.

From the course specification:
The primary key of a strong entity uniquely identifies each occurrence within the entity

However this does not mean weak entities cannot have similar primary keys.

In the question, ParkingSpace has it’s own independent primary key. However it is in mandatory relationship with CarPark. An ParkingSpace must have a CarParkID, so there a dependency which makes it a Weak Entity.

[Peter Thoresen]

26/08/2021 at 10:42 am

From course specification: The presence of a weak entity is indicated by using a dotted line to represent the relationship between the weak entity and its owner entity

I think the lack of dotted line is an error.

[Susan Denham]

26/08/2021 at 11:24 am

Peter, I completely understand what you say there, but in the appendices provided by the SQA, they give the hotel and resort example. They define that Hotel is strong identity in exactly the same scenario as the Parking Space. Hotel is mandatory with Resort, has its own primary key, but is defined as strong not weak?? The question is almost an exact copy of the same setup just with a different scenario. How can the answer be different?

[Peter Thoresen]

26/08/2021 at 11:42 am

It could well be a mistake in either in the appendices or in the exam paper.

If so, we need to know which so we can ensure that pupils are taught and marked on the same requirements.

[Paul Gardner]

26/08/2021 at 11:44 am

I think it should be clear from the analysis but it is also a design decision.

Analysis
1) Strong entity is not dependent on any other entity. Weak entity depends on strong entity:
CarPark is strong. ParkingSpace is weak if it depends on CarPark (i.e if a parking space can’t exist on its own without a CarPark).

Design
2) Strong entity always has a primary key. Weak entity has a partial discriminator key.
ParkingSpace appears strong as it has a simple primary key such that spaceIDs are unique across every car park.
But the primary key of ParkingSpace could have been designed as a composite key (carParkID, spaceID) such that spaceID is only unique per car park. In that case ParkingSpace would be considered weak.

Referring to the original question. The lack of a dotted line in the diagram suggests strong, the vertical bar next to CarPark suggests weak (a ParkingSpace depends on an existing CarPark) but the table design with spaceID (alone) as the primary key shows that ParkingSpace has been designed as a strong entity.

[mcgivernj]

26/08/2021 at 1:01 pm

Thanks for the feedback everyone. Not sure I’m much clearer, in truth!
Looking further at the question, the ParkingSpace entity couldn’t have a single attribute key of spaceID as the entity concerns whether the space is occupied or not which will clearly change over time and the same spaceID value will have to be replicated in other occurences of the entity. In fact, I can’t see that ParkingSpace with the 3 given attributes will every be able to produce a unique value. Had it a composite key of carParkID and spaceID then that would suggest it was a weak entity in line with the course spec. documents. But as the question stands – it isn’t!

I also wasn’t aware, as Paul says, that relational participation influences whether the relationship line is shown as solid or dotted. All not as straightforward and smooth as it appears in the course specification.

[Paul Gardner]

26/08/2021 at 1:56 pm

The ‘occupied’ field is probably there to provide a quick way of showing *currently* occupied in the implemented database.

The ParkingRecord entity implements the many:many realationship between Driver and ParkingSpace and holds all the necessary fields to capture the history of which drivers are occupying/have occupied which parking space. Without the ‘occupied’ field in PartkingSpace a query to find free spaces would need to search ParkingRecord for spaces where the departure time is null. When implemented, application code or database triggers would be needed to update the ‘occupied’ field and give a quick way to identify currently occupied/vacant spaces.

[Paul Gardner]

26/08/2021 at 2:00 pm

https://www.cs.dartmouth.edu/~cs61/Lectures/04%20-%20ER%20Modeling/04%20-%20ER%20Modeling.html

has a good description of strong and weak entities and relationships and how they can be implemented.

• This reply was modified 1 year ago by Paul Gardner. Reason: spelling mistake
• This reply was modified 1 year ago by Paul Gardner. Reason: spelling

[tmcguire]

26/08/2021 at 2:08 pm

Strong/Weak Entities (Weak entities usually illustrated by double box) are not the same as Strong/Weak relationships (Strong relationships often illustrated by a dashed line). We seem to have a hybrid of these.

For this question I’m pretty sure it’s a mistake in the marking scheme. When I marked the paper I changed the marking scheme. We were selected for ACM moderation I sent the scripts along with the adapted marking scheme. Quality assurance feedback made no comment about it.

Not AH specific but Greg Reid posted this update

Greg Reid posted an update
5 months ago

I’ve had a few emails over the last week asking if it’s OK to modify the SQA marking instructions for this year’s published exam and assignment.

The best way to approach the exam and assignment we published is not to think of the assessments as official SQA documents that can’t be modified. They are just resources for you to do what you like with this year.

In a normal year marking instructions (MIs) go through 4 x 10 hour days of Standardisation where we look at hundreds of candidates answers. This process refines the MIs based on alternative responses to those the writer and checkers thought of when producing the assessment. Although we tried our best to finalise the MIs, without this process you will find alternative answers that you will want to add to the MIs.

We aim to provide broad principles which any response can be marked against as it is not possible to provide a complete set of definitive answers. Even when MIs are standardised, SQA markers will award marks to any other alternative correct answers they come across. Good practice would be to add these to your MIs, especially if this is specific to the way you have taught something.

Additionally, if you find an error in the MIs published this year feel free to change it. Without Standardisation a mistake or a better answer than those included may have been missed. (For the Higher assignment a couple of teachers have noted that the hover colour is wrong in the MIs for the web task.)

Any questions, get in touch (greg.reid@sqa.org.uk)

• This reply was modified 1 year ago by tmcguire. Reason: Weak entity double box

[Paul Gardner]

26/08/2021 at 5:20 pm

Sorry if I caused confusion by suggesting that that relational participation influences whether the relationship line is shown as solid or dotted. I was looking at it the other way around.

An entity is weak if it depends on another entity for it to exist *and* it gets at least part of its primary key from the other entity.

The diagram’s mandatory relationship suggests that ParkingSpace depends on CarPark.
But the database structure shows that CarPark has an independent primary key.
carParkID is a manadatory foreign key in ParkingSpace but not part of the primary key.
So, ParkingSpace is a strong entity and the relationship line is shown solid.

If carParkID was a mandatory part of a composite key in ParkingSpace, then ParkingSpace would be a weak entity and the relationship line would be shown dotted.

[Susan Denham]

26/08/2021 at 5:28 pm

So we are correct in saying, the MS was incorrect and there should be 3 strong and only 1 week entity.

[Paul Gardner]

26/08/2021 at 6:20 pm

Yes. The table design matches the diagram which shows three strong entities.

[mcgivernj]

26/08/2021 at 10:25 pm

Thanks again folks, all very helpful. Now for part (ii) of the same question…..
Marking scheme says ParkingRecord is mandatory in relationship and ParkingSpace is optional. They’re the wrong way round aren’t they?

[mcgivernj]

27/08/2021 at 9:28 am

Scrap that last one. Relationship participation all good.