Bicycle Sharing Scheme - ER Diagram
I think there would need to be a MemberPhone table, since the description mentions storing multiple phones per member
I would create tables to store the possible values for for BicycleMake, Bicycle (which contains an attribute linking to a model), BicycleColor, and BicycleSize. Given these tables, there wouldn't need to be a reference to the BicycleMake in Bicycle.
I feel like the Total Rental Length attribute doesn't need to be stored, since this could be derived from the pick-up time and drop-off time. Or better yet, the drop-off time doesn't need to be stored, since it can be derived from the pickup time and total length (DateTime + int is smaller than DateTime + DateTime).
How were you planning on storing the sponsorships?
I suspect that subscription information would need to be stored, such as when a subscription was purchased, and what type it is (monthly, yearly, daily, ...). If this does need to be stored, then it's possible that the membership status can be derived from the subscription information, if the membership status is simply whether the member has an active subscription or not. I would ask questions about this...
Bicycles should have an attribute for what terminal it's currently stored in (perhaps a null-value meaning it's not currently in a Terminal). Otherwise, how do you know which terminal a bicycle is in if it has yet to be rented?
I think the Terminal_Info table is unnecessary, since the number of bicycles at a terminal is duplicating data.
I feel like the GPS tracking number would need to be stored for the bicycles. I would ask questions for this...