Tables and Relationships
Designing tables
Good design starts with deciding what each table represents and giving it a single subject. Each field should hold one atomic value, have a sensible data type (text, number, date/time, currency, yes/no), and carry constraints such as required (not null), unique, or a default value. Field size and format matter: a short text field cannot store a long description, and a date field should not hold free text. Understand the purpose of validation rules and input masks, and know the difference between a validation rule (rejects invalid data) and an input mask (controls the pattern typed).
Relationships
Relationships link tables through keys. Know one-to-many (most common), one-to-one and many-to-many. A many-to-many relationship cannot be implemented directly in a relational database; it is resolved with a junction (linking) table holding foreign keys to both sides. Referential integrity prevents orphan records by stopping deletion or change of a referenced primary key. Understand cascade update and cascade delete as options, and when they are risky.
Traps
Questions often show a scenario and ask how many tables are needed; look for repeated groups that should be split out. Another trap is assuming a relationship is automatically created by similar field names. Also watch for confusion between a lookup field (helps data entry) and a relationship (enforces integrity).
Worked example
A library lends many books to one member over time, and each copy belongs to one title. Members-to-loans is one-to-many; titles-to-copies is one-to-many; a many-to-many between members and titles needs a loans table in between.