IB Computer Science B.2.3 Rules and Data Representation Notes

Solution

1. The fixed array collapses when the school adds half-periods or alternating A/B weeks, so the structure is not future-proof.
2. A relational table (teacherID, day, period) is more flexible.
3. Declaring (teacherID, day, period) as UNIQUE enforces the rule that a teacher cannot be double-booked.

Solution

• Repeating address columns signal a non-normalised design: changes to one field risk inconsistency in the others.
• Splitting addresses into a separate Address table eliminates redundancy and update anomalies.
• A foreign-key rule from Student.addressID to Address.id preserves referential integrity.

Solution

1. JSON is human-readable but large and type-unsafe; strings like "high" can slip into numeric fields.
2. A binary, schema-driven format (e.g., Protocol Buffers) enforces data types and cuts bandwidth.
3. A rule that temperature must be between –50 °C and 60 °C filters obvious sensor errors.

Solution

1. Treating "Ali" and "ali" as different users confuses login and mentions; the rule lacks clarity.
2. Converting all usernames to lowercase before storage simplifies look-ups and avoids duplicates.
3. A UNIQUE constraint on the lowercase column enforces the rule consistently.

Solution

1. Allowing letters defeats the numeric seat-ordering logic; the representation is fine but the rule is missing.
2. A CHECK (seatID ~ '^[0-9]{4}$') regex restricts inputs to four digits only.
3. This ensures seats sort naturally and prevents allocation errors.