Capitalise subheadings in docs

Author: mhauru

docs/source/health_data.rst

@@ -20,7 +20,7 @@ Before getting into the config itself, we need to discuss a few peculiarities of
    However, some of these vocabulary tables may be too large to practically be writable to ``.yaml`` files, and will need to be dealt with manually.
    You should also check the license agreement of each standardized vocabulary before sharing any of the ``.yaml`` files.
 
-Dealing with circular foreign keys
+Dealing with Circular Foreign Keys
 ++++++++++++++++++++++++++++++++++
 
 SSG is currently unable to handle schemas with circular foreign keys properly.
@@ -51,7 +51,7 @@ One can then proceed with ``sqlsynthgen create-vocab`` to copy over the vocabula
 If the problematic foreign key constraints would be between non-vocabulary tables, one would need to keep them disabled for the whole duration of creating synthetic data, while putting in a manual mechanism that guarantees that the synthetic data created does respect the constraint, and then reenable the constraint at the end.
 Fortunately with OMOP this is not necessary.
 
-Vocabulary tables
+Vocabulary Tables
 +++++++++++++++++++++
 
 The OMOP schema has many vocabulary tables. Here's an excerpt from the CCHIC OMOP config file we've written:

docs/source/index.rst

@@ -39,7 +39,7 @@ Contents:
    glossary
 
 
-Indices and tables
+Indices and Tables
 ------------------
 
 * :ref:`genindex`

docs/source/introduction.rst

@@ -17,7 +17,7 @@ After migration, the database has the following structure:
   :width: 400
   :alt: The AirBnb database diagram.
 
-Default behavior
+Default Behavior
 ----------------
 
 SSG contains tools for replicating the schema of a source database.
@@ -99,7 +99,7 @@ Foreign key relations are respected by picking random rows from the table refere
 Even this synthetic data, nearly the crudest imaginable, can be useful for instance for testing software pipelines.
 Note that this data has no privacy implications, since it is only based on the schema.
 
-Vocabulary tables
+Vocabulary Tables
 -----------------
 
 The simplest configuration option available to increase fidelity is to mark some of the tables in the schema to be “vocabulary” tables.
@@ -166,7 +166,7 @@ To recap, “vocabularies” are tables that don’t need synthesising.
 By itself this adds only limited utility, since the interesting parts of the data are typically in the non-vocabulary tables, but it saves great amounts of work by fixing some tables with no privacy concerns to have perfect fidelity from the get-go.
 Note that one has to be careful in making sure that the tables marked as vocabulary tables truly do not hold privacy sensitive data, otherwise catastrophic privacy leaks are possible, where the original data is exposed raw and in full.
 
-Specifying row-based custom generators
+Specifying Row-based Custom Generators
 --------------------------------------
 
 As we’ve seen above, ``ssg.py`` is overwritten whenever you re-run ``make-generators``.
@@ -300,7 +300,7 @@ Still there are no privacy implications, but data can be generated that e.g. pas
 
 .. _source_statistics:
 
-Using aggregate statistics from the source data
+Using Aggregate Statistics from the Source Data
 -----------------------------------------------
 
 Beyond copying vocabulary tables, SSG allows for the original data to affect the synthetic data generation process only through a particular mechanism we call source statistics.
@@ -439,7 +439,7 @@ One final aspect of source statistics bears mentioning:
 At the top level of ``config.yaml`` one can also set ``use-asyncio: true``.
 With this, if there are multiple source stats queries to be run, they will be run in parallel, which may speed up ``make-stats`` significantly if some of the queries are slow.
 
-"Stories" within the data
+"Stories" Within the Data
 -------------------------
 
 The final configuration option available to users of SSG is what we call "story generators".