Build the Entity
Build the Entity moves from basic modeling decisions to a complete connection path.
- What it teaches
- Entities, attributes, attribute quality, primary keys, shared identifiers, and connection paths.
- How it works
- Four rounds ask learners to sort attributes, diagnose or question attribute quality, choose primary keys, and build connection paths through shared identifiers. Drag-and-drop and click/tap controls support the activity.
- Examples
- online sneaker purchase, student course registration, medical appointment, and employee project assignment.
- Use
- Introduce or reinforce foundational relational-modeling decisions before moving into cardinality and relationship strength.
Pick the Cardinality
Pick the Cardinality turns verbal business rules into minimum and maximum participation decisions and then into Crow’s Foot notation.
- What it teaches
- Business rules, minimum and maximum cardinality, and Crow’s Foot notation.
- How it works
- Seven questions are organized into three rounds covering unary, binary, and bridge-entity relationships. Learners make endpoint-by-endpoint cardinality choices and receive feedback.
- Examples
- employee mentorship, marriage, course prerequisites, customer orders, device warranty, club membership, and project assignment.
- Use
- Practice interpreting both ends of a relationship from business rules rather than memorizing notation in isolation.
How Strong is the Relationship?
The activity separates relationship strength from ordinary association by asking whether the parent’s primary key becomes part of the child’s primary key.
- What it teaches
- Identifying and non-identifying relationships, parent primary-key migration, and child primary-key/foreign-key (PK/FK) structure.
- How it works
- Eight relationship scenarios ask learners to classify strong or weak relationships from the displayed keys, with immediate classification feedback. The evidence is whether the parent’s primary key becomes part of the child’s primary key, rather than business-language intuition alone.
- Examples
- Customer → Order, Order → Order Item, Department → Employee, two Course → Class variants, Employee → Dependent, Maintenance → Maintenance Line, and the EMP_EDUC bridge.
- Use
- Compare structurally similar-looking relationships to see why different key arrangements produce different classifications, even when the business language sounds similar.
How Strong is the Entity?
The activity asks a different question from relationship strength: can the target entity be identified independently, or does its identity require an identifying owner?
- What it teaches
- Strong versus weak entity identity, independent identifiers, owner-dependent identity, composite identifiers, and PK/FK evidence.
- How it works
- Twelve entity scenarios ask learners to classify strong or weak entities. Identifier evidence is highlighted after checking; first-check scoring and a completion summary support review.
- Examples
- recording artists and track takes, project cameras and video projects, construction equipment, edit versions, VR scene objects, workshop instructors and meetings, scheduled flights, event venues, software build attempts, and fabrication job components.
- Use
- Distinguish identity from importance, relationship presence, or the mere existence of a foreign key. Keyboard choices include 1 for strong and 2 for weak; reduced-motion support is available.
How Normalizing.
How Normalizing. follows one project–employee–job dataset through three successive repairs so the reason for normalization remains visible across the whole exercise.
- What it teaches
- Functional, partial, and transitive dependencies; composite primary keys; foreign keys; and normalized table design through first, second, and third normal form (1NF, 2NF, and 3NF).
- How it works
- The same project–employee–job dataset progresses through three staged repairs. Learners split records, choose keys, drag or place attributes, inspect dependencies, and then run assignment-lookup and rate-update tasks. Keeping one dataset across the stages makes the reason for each repair visible, rather than presenting the normal forms as unrelated definitions.
- Examples
- 1NF splits repeating project–employee groups and identifies the composite assignment key; 2NF separates project, employee, and assignment facts; 3NF moves the hourly rate to JOB. Follow-up tasks locate Alex Rivera’s six hours on Rolling Tide and update the Designer rate from $90 to $95 once in JOB rather than in multiple records.
- Use
- Make dependencies and the practical effects of a cleaner model concrete. The activity runs locally in the browser with no account, tracking, or external dependencies.