Just a first thought.

Why is userid the pk of your fitnessdetails entity ?

Can a user only have a single fitness detail ?

IMO a user can change bodiweight and bmr over time, isn't it ?

I would also add length to the data (because that may also change in time)

btw isn't bmr a calculated value ? (maybe make it just a calculated column)

I would join workoutsession and workoutmetrics because IMO these are 1:1 related and move the date column to the fitnessdetails entity.

If you intend to store typical training sessions (cfr templates) out of which users can chose, I see a point for workoutsession, otherwise I dont.

IMO workoutmethod should be a parameter entity, defining the individual types of workout ways. For the moment containing 3 rows.

How about adding an active indicator or datestart dateend kind of info.

Unless you plan these parameters always to be available and active.

You would need an extra users entity, providing name, ... info.

Are you only going to register full workouts ?

If not, you may want to pull over some extra columns regarding distance, time, .. to your workoutsession entity, to be able to handle these exceptions. In that case, you'll have to pose the extra question if you are only going to store the exceptions in these columns, or always add the template values in these rows.

Keep in mind to add indexes for your fk columns, if you translate your entities to tables.

Happy holidays.

Johan