In the case study, it mentions that tariff type and depot should be recorded when a vehicle is hired - am I correct in thinking that these are foreign keys in the Hire entity (which connects Vehicles and Clients) and hence we shouldn't write them into the Hire attributes on the diagram or in the data dictionary? I'm assuming you'd record the id code of depot and tariff type so they would be FKs in Hire.

From my understanding, UML ERDs are not the same as database schemas; foreign keys are not explicit attributes, they are the database form of relationships in an entity relationship model. Each relationship in the ERM implies foreign keys.

It's difficult to separate the concerns of the database from the ERD since there is specification of types. In my opinion, this is just so the same information can be used when we generate a database to represent the ERM

Also, is there no need to connect the Hire entity with the Depot and Tariff Type entities directly seeing as Hire is connected to Vehicle which is in turn connected to Depot and additionally Vehicle connects to Make which connects to the Tariff Type entity?

See if you run into this problem

The case study also mentions that the odometer reading of a car is recorded when the car is hired - should 'odometer reading' then be written as an attribute in Hire, seeing as it is not a PK of Vehicles?

That logic checks out to me

Is hire time and date a single-valued attribute of type 'date'?

You might be asking this because people would think time and date are two different things. This is not true in software or SQL (typically).

Either way, just follow the specification exactly and you'll be fine.

Are type (EV, hybrid, fuel) and make different?

I am suspicious that 'make' is used incorrectly in the case study. Because they mentioned 'all cars are the current model'. That doesn't make sense to me since a Vehicle Make is the manufacturer.

Are hirers and clients the exact same?

Depends on your model.

I have a composite key made up of two foreign keys A and B - can I write the composite key in its entity as A{PK} B{PK} in my diagram? And I'm guessing this composite key should be in the data dictionary.

See my first comment

How should subclasses be expressed in the attributes data dictionary? Should we list them under the Entities column as usual but in their attributes only mention the attributes unique to that subclass? I'm guessing I should given an indication in the dictionary that they are a subclass of another entity as well.

Yeah that sounds right to me

Thank you very much in advance.

I think it's the blind leading the blind here