Skip to content

Commit 1450b36

Browse files
Merge pull request dimitri-yatsenko#31 from dimitri-yatsenko/claude/restore-sales-er-diagram-011DZnQEUdeQmyEUkma61rhh
Restore Classic Sales ER diagram examples
2 parents 060be70 + 2fc66d6 commit 1450b36

File tree

1 file changed

+3
-15
lines changed

1 file changed

+3
-15
lines changed

book/30-design/060-diagrams.ipynb

Lines changed: 3 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -411,11 +411,7 @@
411411
{
412412
"cell_type": "markdown",
413413
"metadata": {},
414-
"source": [
415-
"## Real-World Example: Classic Sales Database\n",
416-
"\n",
417-
"Let's examine a real database—the [MySQL tutorial sample database](https://www.mysqltutorial.org/getting-started-with-mysql/mysql-sample-database/):"
418-
]
414+
"source": "## Real-World Example: Classic Sales Database\n\nLet's examine a real database—the [MySQL tutorial sample database](https://www.mysqltutorial.org/getting-started-with-mysql/mysql-sample-database/).\n\n### Traditional ER Diagram\n\nHere is the classic Entity-Relationship diagram from the MySQL tutorial:\n\n![Classic Sales ER Diagram](../images/mysql-classic-sales-ERD.png)\n\nThis diagram uses Crow's Foot notation, where:\n- Lines with crow's feet indicate \"many\" relationships\n- Single lines indicate \"one\" relationships\n- The diagram shows cardinality but not the semantic nature of relationships\n\n### DataJoint Diagram\n\nNow let's see how the same database appears in DataJoint notation:"
419415
},
420416
{
421417
"cell_type": "code",
@@ -432,15 +428,7 @@
432428
{
433429
"cell_type": "markdown",
434430
"metadata": {},
435-
"source": [
436-
"**Reading this diagram**:\n",
437-
"1. **Independent entities at top**: `Productline`, `Office`, `Customer` (underlined)\n",
438-
"2. **Follow solid lines down**: Track how primary keys cascade through the hierarchy\n",
439-
"3. **Identify association tables**: Look for converging lines (e.g., `Orderdetail` links `Order` and `Product`)\n",
440-
"4. **Dashed lines**: Reference relationships that don't cascade identity\n",
441-
"\n",
442-
"The vertical layout reveals the workflow: create products and customers first, then orders, then order details."
443-
]
431+
"source": "### Comparing the Two Diagrams\n\n**Reading the DataJoint diagram**:\n1. **Independent entities at top**: `Productline`, `Office`, `Customer` (underlined)\n2. **Follow solid lines down**: Track how primary keys cascade through the hierarchy\n3. **Identify association tables**: Look for converging lines (e.g., `Orderdetail` links `Order` and `Product`)\n4. **Dashed lines**: Reference relationships that don't cascade identity\n\n**Key differences from the ER diagram**:\n\n| Aspect | Traditional ER (Crow's Foot) | DataJoint |\n|--------|------------------------------|-----------|\n| **Layout** | Arbitrary arrangement | Top-to-bottom workflow order |\n| **Line meaning** | Cardinality only (one vs. many) | Semantic relationship type |\n| **Primary key cascade** | Not visible | Solid lines show direct join paths |\n| **Workflow sequence** | Must read documentation | Clear from vertical structure |\n\nThe vertical layout reveals the workflow: create product lines and offices first, then products and employees, then customers and orders, and finally order details and payments.\n\n:::{seealso}\nFor the complete schema with data and example queries, see the [Classic Sales](../80-examples/010-classic-sales.ipynb) example.\n:::"
444432
},
445433
{
446434
"cell_type": "markdown",
@@ -619,4 +607,4 @@
619607
},
620608
"nbformat": 4,
621609
"nbformat_minor": 4
622-
}
610+
}

0 commit comments

Comments
 (0)