Normalisation

First normal form asks for a simple grid.

Each box holds one value, not a comma-separated list.

You do not store the same kind of fact in repeating columns (Book1, Book2, Book3). When the number of books can grow, those extra columns always run out.

Each row can be identified.

The fix is the shape you already know: one loan per row, not one member with a handful of book columns.

Before the second and third checks, you need one idea: functional dependency.

If you know one field, you can work out another. In Members, MemberID 1 always goes with Sophie Walsh. We say FullName depends on MemberID.

On George's loan sheet, Phone always matches the member, not the book. Phone depends on MemberID, not on MemberID + BookID together. That is the kind of dependency the next two normal forms remove.

Look at the 1NF sheet again. Suppose the identity of a row is the pair MemberID + BookID (this member, this book).

Phone does not describe that pair. It describes the member only. Title describes the book only. Both facts are copied onto every loan.

Second normal form says: if the identity is made of more than one field, every other fact must depend on the whole identity, not just a piece of it. Phone depends only on MemberID — that is a partial dependency. It does not belong on the loan row.

The everyday fix is the one Amelia already uses: Members holds the phone. Books holds the title. Loans holds MemberID, BookID, and the date.

Even after phones and titles have gone home, a table can still hide a copy.

Oliver wants a daily fine: adults £2.00, students £0.50. George types MembershipType and DailyFine on every member row. Sophie and Harry both show £2.00. If the board later changes the adult fine to £2.50, George must edit every adult. Miss one row, and two adults pay different rates.

DailyFine does not depend on MemberID. It depends on MembershipType. A fact that depends on another non-key fact is a transitive dependency. It does not belong in that table.

Third normal form says: extra facts must depend on the key, the whole key, and nothing but the key. DailyFine belongs in a small MembershipTypes table. Members only stores which type the person is.