BCNF and 4NF for Database

Question

So I started out with these 3 tables and was told to modify them into BCNF and 4NF:

PRIVATE_SESSION (Trainer, Phone, Email, Fee, ClientLastName, ClientFirstName, ClientPhone, ClientEmail, Date, Time)

CLUB_MEMBERSHIP (ClientNumber, ClientLastName, ClientFirstName, ClientPhone, ClientEmail, MembershipType, EndingDate, Street, City, State, Zip)

CLASS (ClassName, Trainer, StartDate, EndDate, Cost)

*Also suggest a new table to keep track of client, the classes subscribed, and the amount paid while still keeping everything in BCNF and 4NF

=================================================================

So, I turned them into these 7 tables to try and comply with the BCNF and 4NF. Question is...is this even remotely correct? The definition of BCNF is satisfied if every determinate is a candidate key, which it looks like they are. 4NF is satisfied if it contains no multivalued dependencies I believe...and I tried separating the tables so they would not

TRAINER

ID (primary key),
TrainerLastName,
TrainerFirstName,
TrainerEmail,
TrainerPhone

TRAINER_SESSION

ID (primary key),
ID (foreign key from CLIENT_INFO.ID)
TrainingStartTime,
TrainingStartDate,
TrainingFee

CLIENT_INFO

ID (primary key),
ClientLastName,
ClientFirstName,
ClientPhone,
ClientEmail,

MEMBER_ADDRESS

ID (primary key),
ID (foreign key to CLIENT_INFO.ID),
State,
City,
Street,
Zip

MEMBERSHIP_INFO

ID (primary key),
ID (foreign key to CLIENT_INFO.ID),
MembershipType,
MembershipStartDate,
MembershipEndDate

CLUB_CLASS

ID (primary key),
TrainerID (foreign key to  TRAINER.ID),
ClassName,
ClassStartDate,
ClassEndDate,
ClassCost

CLASS_ENROLLMENT

(ClassID, MemberID) composite primary keys
TotalClasses,
TotalPaid

Answer 1

For a more recent version of the proposed schema (revision 11)

^{Since the schema is going to be revised, it is going to be hard to keep answers in sync with the current edition of the schema. Please bear that in mind when reviewing any given answer.}

Class Enrollment has the Total Classes and Total Paid fields which are not appropriate. The table should be key-only unless members can negotiate a per-class fee (discount) for the class compared with the list price (in which case it needs a 'fee paid') attribute. The totals should be calculated when necessary, or stored in a separate table independent of the specific class.

Membership Info and Member Address have acquired two columns called ID, which is confusing. Presumably, the second should be labelled Client ID in each table (that would be more reasonable). The question now arising is 'what is the cardinality of the relationship between Membership Info and Client Info, and between Member Address and Client Info?' For addresses, can a member exist without the address being known? Can a member have two or more addresses? If the answer to either of those is 'yes', then the design is OK. If the answer is 'no', it is not clear that you need both Client Info and Member Address. Similarly with Membership Info and Client Info.

Trainer Session has two ID fields. The second is presumably Client ID, but it also needs a Trainer ID to identify which trainer ran the session.

For the original version of the proposed schema (revision 6)

^{Or a 'close to original' version of the proposed schema.}

You've clearly not created a non-loss decomposition since the 'class name' element is missing.

The Class Expense table has no counterpart in the original tables.

It is not clear that the Trainer table is warranted from the original tables, though I agree with most of the fields. The Fee attribute is misplaced here, though.

The Train Session table is missing attributes, more or less however you slice and dice things. If it is meant to represent the private sessions, then you're missing trainer ID and client ID and fee. If it is meant to be generic with public (club) sessions, then you need a table somewhere that records the private sessions.

The triad of Member Info, Client Info and Membership Info are confused and/or confusing. Without supplemental information about how the database is supposed to handle the information, it is hard to know what's best to recommend. The Member Info table might be better named as Address. The Membership Info table has no connection to the Client Info table, so memberships are associated with an address but not with a person (and people are not associated with addresses).

The Club Class table is OK, I think.

Classes exist and are taught by trainers, but no-one is ever recorded as going to the classes.