Merge pull request dimitri-yatsenko#19 from dimitri-yatsenko/claude/fix-glossary-index-015ZtpfYQuusa2bPgFr8Y41p

Claude/fix glossary index 015 ztpf y quusa2b pg fr8 y41p

Author: dimitri-yatsenko

book/00-introduction/00-purpose.md

@@ -4,7 +4,7 @@ title: Purpose
 
 ## What is DataJoint?
 
-**{index}`DataJoint` is a {index}`computational database` language and platform that enables scientists to design, implement, and manage data operations for research by unifying data structures and analysis code.** It provides {index}`data integrity`, {index}`automated computation`, {index}`reproducibility`, and seamless collaboration through a {index}`relational database` approach that coordinates relational databases, code repositories, and object storage.
+**DataJoint is a computational database language and platform that enables scientists to design, implement, and manage data operations for research by unifying data structures and analysis code.** It provides data integrity, automated computation, reproducibility, and seamless collaboration through a relational database approach that coordinates relational databases, code repositories, and object storage.
 
 ## Who This Book Is For
 
@@ -28,18 +28,18 @@ Here's what makes DataJoint different: **your database schema IS your data proce
 
 Traditional databases store and retrieve data. DataJoint does that too, but it also tracks what gets computed from what. Each table plays a specific role in your workflow:
 
-- **{index}`Manual table`s**: Source data entered by researchers
-- **{index}`Imported table`s**: Data acquired from instruments or external sources
-- **{index}`Computed table`s**: Results automatically derived from upstream data
-- **{index}`Lookup table`s**: Reference data and parameters
+- **Manual tables**: Source data entered by researchers
+- **Imported tables**: Data acquired from instruments or external sources
+- **Computed tables**: Results automatically derived from upstream data
+- **Lookup tables**: Reference data and parameters
 
 This workflow perspective shapes everything:
 
 **Schema as a Map**: Your database diagram becomes a visual flowchart showing exactly how data moves from raw inputs to final results. Dependencies are explicit, not hidden in scattered scripts.
 
 **Intelligent Diagrams**: Different table types get distinct visual styles. One glance tells you what's manual, what's automatic, and how everything connects.
 
-**{index}`Provenance`, Not Just Integrity**: {index}`Foreign key`s mean more than "this ID exists." They mean "this result was computed FROM this input." When upstream data changes, DataJoint ensures you can't accidentally keep stale downstream results. This is why DataJoint emphasizes INSERT and DELETE over UPDATE—changing input data without recomputing outputs breaks your science, even if the database technically remains consistent.
+**Provenance, Not Just Integrity**: Foreign keys mean more than "this ID exists." They mean "this result was computed FROM this input." When upstream data changes, DataJoint ensures you can't accidentally keep stale downstream results. This is why DataJoint emphasizes INSERT and DELETE over UPDATE—changing input data without recomputing outputs breaks your science, even if the database technically remains consistent.
 
 For scientific computing, this workflow-centric design is transformative. Your database doesn't just store results—it guarantees they're valid, reproducible, and traceable back to their origins.
 
@@ -62,7 +62,7 @@ This book provides the skills to transform research operations: from fragile scr
 
 ## DataJoint and SQL: Two Languages, One Foundation
 
-**{index}`SQL` (Structured Query Language)** powers virtually every relational database. DataJoint wraps SQL in Pythonic syntax, automatically translating your code into optimized queries.
+**SQL (Structured Query Language)** powers virtually every relational database. DataJoint wraps SQL in Pythonic syntax, automatically translating your code into optimized queries.
 
 You could learn DataJoint without ever seeing SQL. But this book teaches both, side by side. You'll understand not just *what* works but *why*—and you'll be able to work directly with SQL when needed.
 

book/00-introduction/05-executive-summary.md

@@ -11,7 +11,7 @@ Standard database solutions address storage and querying but not computation. Da
 
 ## The DataJoint Solution
 
-**DataJoint introduces the {index}`Relational Workflow Model`**—an extension of classical relational theory that treats computational transformations as first-class citizens of the data model. The database {index}`schema` becomes an executable specification: it defines not just what data exists, but how data flows through the pipeline and when computations should run.
+**DataJoint introduces the Relational Workflow Model**—an extension of classical relational theory that treats computational transformations as first-class citizens of the data model. The database schema becomes an executable specification: it defines not just what data exists, but how data flows through the pipeline and when computations should run.
 
 This creates what we call a **Computational Database**: a system where inserting new raw data automatically triggers all downstream analyses in dependency order, maintaining computational validity throughout. Think of it as a spreadsheet that auto-recalculates, but with the rigor of a relational database and the scale of distributed computing.
 
@@ -21,16 +21,16 @@ This creates what we call a **Computational Database**: a system where inserting
 Unlike Entity-Relationship modeling that requires translation to SQL, DataJoint schemas are directly executable. The diagram *is* the implementation. Schema changes propagate immediately. Documentation cannot drift from reality because the schema is the documentation.
 
 **Workflow-Aware Foreign Keys**
-Foreign keys in DataJoint do more than enforce {index}`referential integrity`—they encode computational dependencies. A computed result that references raw data will be automatically deleted if that raw data is removed, preventing stale or orphaned results. This maintains *{index}`computational validity`*, not just *referential integrity*.
+Foreign keys in DataJoint do more than enforce referential integrity—they encode computational dependencies. A computed result that references raw data will be automatically deleted if that raw data is removed, preventing stale or orphaned results. This maintains *computational validity*, not just *referential integrity*.
 
 **Declarative Computation**
-Computations are defined declaratively through {index}`make() method`s attached to table definitions. The {index}`populate()` operation identifies all missing results and executes computations in dependency order. Parallelization, error handling, and job distribution are handled automatically.
+Computations are defined declaratively through make() methods attached to table definitions. The populate() operation identifies all missing results and executes computations in dependency order. Parallelization, error handling, and job distribution are handled automatically.
 
-**{index}`Immutability` by Design**
+**Immutability by Design**
 Computed results are immutable. Correcting upstream data requires deleting dependent results and recomputing—ensuring the database always represents a consistent computational state. This naturally provides complete provenance: every result can be traced to its source data and the exact code that produced it.
 
 **Hybrid Storage Model**
-Structured metadata lives in the relational database ({index}`MySQL`/{index}`PostgreSQL`). Large binary objects (images, recordings, arrays) live in scalable {index}`object storage` (S3, GCS, filesystem) with the database maintaining the mapping. Queries operate on metadata; computation accesses objects transparently.
+Structured metadata lives in the relational database (MySQL/PostgreSQL). Large binary objects (images, recordings, arrays) live in scalable object storage (S3, GCS, filesystem) with the database maintaining the mapping. Queries operate on metadata; computation accesses objects transparently.
 
 ## Architecture Overview
 
@@ -70,17 +70,17 @@ This book provides comprehensive coverage of DataJoint from foundations through
 
 **Part II: Design**
 - Schema design principles and table definitions
-- {index}`Primary key`s, foreign keys, and dependency structures
-- {index}`Master-part relationship`s for hierarchical data
-- {index}`Normalization` through the lens of workflow entities
+- Primary keys, foreign keys, and dependency structures
+- Master-part relationships for hierarchical data
+- Normalization through the lens of workflow entities
 - Schema evolution and migration strategies
 
 **Part III: Operations**
 - Data insertion, deletion, and transaction handling
 - Caching strategies for performance optimization
 
 **Part IV: Queries**
-- DataJoint's five-operator {index}`query algebra`: {index}`restriction`, {index}`projection`, {index}`join`, {index}`aggregation`, {index}`union`
+- DataJoint's five-operator query algebra: restriction, projection, join, aggregation, union
 - Comparison with SQL and when to use each
 - Complex query patterns and optimization
 

book/20-concepts/00-databases.md

@@ -5,7 +5,7 @@ title: Databases
 ## What is a Database?
 
 ```{card} Database
-A **{index}`database`** is a dynamic (i.e. *time-varying*), systematically organized collection of data that plays an integral role in the operation of an enterprise.
+A **database** is a dynamic (i.e. *time-varying*), systematically organized collection of data that plays an integral role in the operation of an enterprise.
 It supports the enterprise's operations and is accessed by a variety of users in different ways. Examples of enterprises that rely on databases include hotels, airlines, stores, hospitals, universities, banks, and scientific studies.
 
 The database not only tracks the current state of the enterprise's processes but also enforces essential *business rules*, ensuring that only valid transactions occur and preventing errors or inconsistencies. It serves as the **system of record**, the **single source of truth**, accurately reflecting the current state and ongoing activities.
@@ -25,7 +25,7 @@ Databases are crucial for the smooth and organized operation of various entities
 ## Database Management Systems (DBMS)
 
 ```{card} Database Management System
-A {index}`Database Management System` ({index}`DBMS`) is a software system that serves as the computational engine powering a database.
+A Database Management System (DBMS) is a software system that serves as the computational engine powering a database.
 It defines and enforces the structure of the data, ensuring that the organization's rules are consistently applied.
 A DBMS manages data storage and efficiently executes data updates and queries while safeguarding the data's structure and integrity, particularly in environments with multiple concurrent users.
 
@@ -50,7 +50,7 @@ One of the most critical features distinguishing databases from simple file stor
 
 ### Authentication and Authorization
 
-Before you can work with a database, you must **{index}`authentication`**—prove your identity with a username and password. Once authenticated, the database enforces **{index}`authorization`** rules that determine what you can do:
+Before you can work with a database, you must **authentication**—prove your identity with a username and password. Once authenticated, the database enforces **authorization** rules that determine what you can do:
 
 - **Read**: View specific tables or columns
 - **Write**: Add new data to certain tables  
@@ -80,11 +80,11 @@ Modern databases typically separate data management from data use through distin
 
 ### Common Architectures
 
-**{index}`Server-client architecture`** (most common): A database server program manages all data operations, while client programs (your scripts, applications, notebooks) connect to request data or submit changes. The server enforces all rules and access permissions consistently for every client. This is like a library where the librarian (server) manages the books and enforces checkout policies, while patrons (clients) request materials.
+**Server-client architecture** (most common): A database server program manages all data operations, while client programs (your scripts, applications, notebooks) connect to request data or submit changes. The server enforces all rules and access permissions consistently for every client. This is like a library where the librarian (server) manages the books and enforces checkout policies, while patrons (clients) request materials.
 The two most popular open-source relational database systems: MySQL and PostgreSQL implement a server-client architecture.
 
-**{index}`Embedded database`s**: The database engine runs within your application itself—no separate server. This works for single-user applications like mobile apps or desktop software, but doesn't support multiple users accessing shared data simultaneously.
-{index}`SQLite` is a common embedded database @10.14778/3554821.3554842.
+**Embedded databases**: The database engine runs within your application itself—no separate server. This works for single-user applications like mobile apps or desktop software, but doesn't support multiple users accessing shared data simultaneously.
+SQLite is a common embedded database @10.14778/3554821.3554842.
 
 **Distributed Databases**: Data and processing are spread across multiple servers working together. This provides high availability and can handle massive scale, but adds significant complexity. Systems like Google Spanner, Amazon DynamoDB, and CockroachDB use this approach.
 
@@ -106,7 +106,7 @@ Separating data management from data use provides critical advantages:
 
 This book focuses on **DataJoint**, a framework that extends relational databases specifically for scientific workflows. DataJoint builds on the solid foundation of relational theory while adding capabilities essential for research: automated computation, data provenance, and reproducibility.
 
-The {index}`relational data model`—introduced by {index}`Edgar F. Codd` in 1970—revolutionized data management by organizing data into tables with well-defined relationships. This model has dominated database systems for over five decades due to its mathematical rigor and versatility. Modern relational databases like MySQL and PostgreSQL continue to evolve, incorporating new capabilities for scalability and security while maintaining the core principles that make them reliable and powerful.
+The relational data model—introduced by Edgar F. Codd in 1970—revolutionized data management by organizing data into tables with well-defined relationships. This model has dominated database systems for over five decades due to its mathematical rigor and versatility. Modern relational databases like MySQL and PostgreSQL continue to evolve, incorporating new capabilities for scalability and security while maintaining the core principles that make them reliable and powerful.
 
 The following chapters build the conceptual foundation you need to understand DataJoint's approach:
 - **Data Models**: What data models are and why schemas matter for scientific work