1. I understand we cannot put FKs as a listed attribute on the ER diagram/attribute dictionary, but what if this FK would be a part of a PK? Is it okay to not have an attribute identified as the PK or do we have to find some other PK? 2. In the occerence column in the data dictionaries, is it advised to have a specific example or to use entity names? So far I have been using entity names e.g., 'vehicle resides in depot', but I feel a more specific example e.g., 'ford focus resides in depot 01' is clearer to the reader. 3. Should we include an alias that is the same as the entity name if there are no aliases? Or just leave it blank? Apologies if any of these have already been answered in the forums, I couldn't seem to find any answers on these.

ANONYMOUS wrote: PK and FK can be the same, but it is not a best practice. Can you find a better FK in your table? No. You can have your own decision. It can be blank.

I'm sorry, I still don't quite understand. I will give an example (without revealing too much about my ER diagram): If I have a relationship 'Makes' between Client and Booking, and I want the PK in the Booking table to include clientID, would I put 'clientID {PK}' (perhaps as well as some other attribute to make a composite key) as an attribute despite clientID being a foreign key? If I do not include it then the it will be impossible to make a unique PK as someone else may make the same booking on the same day. We have been explicitly told in lectures and in these forums that we should NOT include FKs as attributes (in the attribute data dictionary/ER diagram) as they are implied by the relationships, but sometimes they are required to make a unique PK.

ERD is not an SQL database 1:1. Pretty sure in the lectures they mention strong vs weak entities and the difference between them. That's what I thought was relevant to this line of questioning.