create index of terms

Author: dimitri-yatsenko

book/20-concepts/00-databases.md

@@ -106,6 +106,8 @@ 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.
 
+**DataJoint introduces a new class of databases called Computational Databases**, where computational transformations are first-class citizens of the data model. Just as electronic spreadsheets automatically recalculate formulas when you enter new data, computational databases trigger cascades of computations specified by the schema whenever new data enters the system. In this model, the database schema doesn't just describe data structure—it encodes executable workflows where computations automatically execute when their dependencies are satisfied.
+
 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.
 
 DataJoint extends this proven foundation with workflow-aware capabilities that scientific computing requires. Throughout this book, you'll learn how to:

book/20-concepts/04-workflows.md

@@ -6,6 +6,8 @@ In the previous chapter, we saw how traditional relational databases excel at st
 
 **DataJoint solves these problems by treating your database schema as an executable workflow specification.** Your table definitions don't just describe data structure—they prescribe how data flows through your pipeline, when computations run, and how results depend on inputs.
 
+**The Relational Workflow Model defines a new class of databases, {index}`Computational Databases <computational database>`**, where computational transformations are first-class citizens of the data model. Just as electronic spreadsheets automatically recalculate formulas when you enter new data, computational databases trigger cascades of computations specified by the schema whenever new data enters the system. In this model, entering a new experimental session automatically triggers the computation of all downstream analyses that depend on it—no manual orchestration required.
+
 This chapter introduces the Relational Workflow Model—a fundamental extension of relational theory that makes databases workflow-aware while preserving all the mathematical rigor of Codd's model.
 
 ## A New Paradigm for Relational Databases
@@ -166,6 +168,8 @@ DataJoint represents the practical embodiment of the Relational Workflow Model,
 
 The Relational Workflow Model introduces a profound shift in perspective: the database schema itself becomes an executable specification of your workflow. This represents a fundamental departure from traditional database design, where conceptual modeling, implementation, and documentation are separate activities requiring translation between different representations.
 
+**The Relational Workflow Model defines Computational Databases**—systems where computational transformations are first-class citizens of the data model. Like electronic spreadsheets that automatically recalculate when you enter new values, computational databases automatically execute computations when new data enters the system. When you insert a new recording session, the database doesn't just store it—it identifies all downstream computations that should run and executes them in the correct order, ensuring that every analysis remains consistent with its inputs.
+
 When you define a DataJoint schema, you accomplish four critical tasks simultaneously. First, you design the conceptual model by identifying what workflow steps exist in your domain. Second, you implement the database structure by defining tables, attributes, and foreign keys that capture these workflow steps. Third, you specify the computations through `make()` methods that define how each workflow step transforms its inputs into outputs. Finally, you document the pipeline because the schema itself serves as the complete documentation of your workflow.
 
 This unified approach eliminates the traditional separation between conceptual design and implementation. Rather than drawing an ER diagram and then translating it into SQL tables—a process prone to errors and inconsistencies—you write a schema that directly expresses both the conceptual model and its implementation. When you generate a diagram, it's derived from the actual working schema, ensuring that your documentation is never out of sync with your implementation.