A chemistry database architect decided the periodic table has too much redundancy. They're trying to normalize elements into separate tables for protons, neutrons, and electrons. The system now complains about carbon having code duplication across its isotopes. Manage atomic data structures while explaining why you can't just refactor hydrogen. Balance database normalization principles with the fundamental laws of chemistry. Your task: Normalize the periodic table without causing a nuclear meltdown every time someone queries carbon.
Why You're Doing This
This tests database design, normalization theory, and understanding when abstraction goes too far. You're working with a system where over-engineering creates more problems than it solves—a common scenario in software architecture where theoretical purity conflicts with practical requirements.
Take the W
✓ Creates normalized database schema for atomic data
✓ Identifies chemistry violations caused by over-normalization
✓ Provides practical alternatives to pure normalization
Hard L
✗ Ignores fundamental chemistry constraints
✗ Creates unusable database structure
✗ Loses critical atomic relationships through normalization
Edge Cases
⚠ Elements that exist only in theory
⚠ Radioactive decay chains spanning multiple elements
⚠ Quantum mechanical properties that don't fit relational models
⚠ Chemical bonds that require denormalized data
Input Format:
Chemistry database with over-normalization issues and atomic relationship preservation needs
Expected Output:
Database design balancing normalization with chemical reality
Example:
Carbon with isotopes C12, C13, C14 in aggressive normalization causing chemistry violations → Schema: ELEMENTS(id,name) ISOTOPES(element_id,mass_number) with violations: carbon_dating_breaks, diamond_structure_undefined
Input Format:
Chemistry database system with normalization and domain constraint management
Expected Output:
Database schema with chemical relationship preservation