reorder sections on primary key, lookups, and normalization

Author: dimitri-yatsenko

book/30-schema-design/025-primary-key.md renamed to book/30-schema-design/020-primary-key.md

@@ -229,13 +229,27 @@ The composite primary key `(state, district)` ensures that:
 
 For tracking marathon champions, you need both the **year** and the **division** (men's or women's) to uniquely identify each champion.
 
+(DataJoint)
+```python
+@schema
+class MarathonChampion(dj.Manual):
+    definition = """
+    year : int
+    division : enum('men', 'women')
+    ---
+    name : varchar(60)
+    country : char(2)
+    time_in_seconds : decimal(8,3)
+    """
+```
+(Equivalent SQL)
 ```sql
 CREATE TABLE marathon_champions (
     year YEAR NOT NULL,
     division ENUM('men', 'women') NOT NULL,
     name VARCHAR(60) NOT NULL,
     country CHAR(2) NOT NULL,
-    time TIME NOT NULL,
+    time_in_seconds : decimal(8,3) NOT NULL,
     PRIMARY KEY (year, division)
 );
 ```

book/30-schema-design/060-uuid.ipynb renamed to book/30-schema-design/025-uuid.ipynb

@@ -4,7 +4,73 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "# Database normalization \n",
+    "# Database Normalization \n",
+    "\n",
+    "# Normalization Principle\n",
+    "\n",
+    "A fundamental principle in database design is **normalization**—the practice of organizing data to minimize redundancy and dependency. One key aspect of normalization is that **each table should represent one distinct entity class**.\n",
+    "\n",
+    "## Why Separate Entity Types?\n",
+    "\n",
+    "Different entity types have different:\n",
+    "- **Identification systems**: How they are uniquely identified\n",
+    "- **Attributes**: What properties they have\n",
+    "- **Relationships**: How they connect to other entities\n",
+    "- **Business rules**: What constraints apply to them\n",
+    "\n",
+    "## Example: Pet Shop Database\n",
+    "\n",
+    "Consider designing a database for a pet shop. You might be tempted to put everything in one table:\n",
+    "\n",
+    "```sql\n",
+    "-- BAD DESIGN: Mixing different entity types\n",
+    "CREATE TABLE pet_shop_data (\n",
+    "    id INT PRIMARY KEY,\n",
+    "    name VARCHAR(50),\n",
+    "    type VARCHAR(20),  -- 'cat', 'dog', 'employee', 'customer'\n",
+    "    breed VARCHAR(30),\n",
+    "    salary DECIMAL(10,2),\n",
+    "    phone VARCHAR(20),\n",
+    "    address TEXT\n",
+    ");\n",
+    "```\n",
+    "\n",
+    "This design violates the normalization principle because it mixes:\n",
+    "- **Pets** (cats, dogs) with attributes like breed\n",
+    "- **Employees** with attributes like salary\n",
+    "- **Customers** with attributes like phone and address\n",
+    "\n",
+    "## Better Design: Separate Tables\n",
+    "\n",
+    "```sql\n",
+    "-- GOOD DESIGN: Separate entity types\n",
+    "CREATE TABLE pet (\n",
+    "    pet_id INT PRIMARY KEY,\n",
+    "    name VARCHAR(50) NOT NULL,\n",
+    "    species ENUM('cat', 'dog', 'bird', 'fish') NOT NULL,\n",
+    "    breed VARCHAR(30),\n",
+    "    birth_date DATE,\n",
+    "    owner_id INT\n",
+    ");\n",
+    "\n",
+    "CREATE TABLE employee (\n",
+    "    employee_id INT PRIMARY KEY,\n",
+    "    name VARCHAR(50) NOT NULL,\n",
+    "    position VARCHAR(30) NOT NULL,\n",
+    "    salary DECIMAL(10,2) NOT NULL,\n",
+    "    hire_date DATE NOT NULL\n",
+    ");\n",
+    "\n",
+    "CREATE TABLE customer (\n",
+    "    customer_id INT PRIMARY KEY,\n",
+    "    name VARCHAR(50) NOT NULL,\n",
+    "    phone VARCHAR(20),\n",
+    "    email VARCHAR(100),\n",
+    "    address TEXT\n",
+    ");\n",
+    "```\n",
+    "\n",
+    "Each table now represents a distinct entity class with appropriate attributes and identification systems.\n",
     "\n",
     "**Database normalization** is a set of principles for designing databases with clarity and logical rigor. \n",
     "Normalized designs communicate the mapping between real-world entities and their representations in database design. \n",