Update MP Mock Database.md

Author: pchemguy

MP Mock Database.md

@@ -6,7 +6,7 @@ parent: Materialized Paths
 permalink: /mat-paths/mock-database
 ---
 
-Materialized paths (MPs) model is one of several approaches to storing a tree structure in a relational database (for details, please see [References](../design-rules#TreesAndRDBMS)). This project focuses on developing SQL/SQLite scripts for performing various MPs operations using this [mock SQLite database][].
+Materialized paths (MPs) model is one of several approaches to storing a tree structure in a relational database (for details, please see [References][TreesAndRDBMS]). This project focuses on developing SQL/SQLite scripts for performing various MPs operations using this [mock SQLite database][].
 
 ### Schema
 
@@ -60,13 +60,13 @@ This table contains three independent and two stored generated columns. The form
 
 The category name should preferably include alphanumeric characters only. Other characters may cause problems; slashes, comma, and double quote are prohibited (see the CHECK constraint). Names starting with the tilde character are reserved for internal use.
 
-There are several [approaches](../design-rules#TreesAndRDBMS) to encoding the *prefix* value based on an FS-like path using node names or IDs. With fixed length IDs, the path separator is unnecessary. For example, 8-character ASCII IDs and delimiterless VARCHAR(255) (where available) may encode a hierarchy with up to 32 levels. The current implementation uses plain FS-like paths with the forward slash as the path separator. All prefixes are absolute and include trailing but not leading slash to simplify code. Top-level nodes have the blank string as their prefix.
+There are several [approaches][TreesAndRDBMS] to encoding the *prefix* value based on an FS-like path using node names or IDs. With fixed length IDs, the path separator is unnecessary. For example, 8-character ASCII IDs and delimiterless VARCHAR(255) (where available) may encode a hierarchy with up to 32 levels. The current implementation uses plain FS-like paths with the forward slash as the path separator. All prefixes are absolute and include trailing but not leading slash to simplify code. Top-level nodes have the blank string as their prefix.
 
-The *ascii_id* column is a random eight-character long string, which may contain alphanumeric ASCII characters, dash, and underscore (the last two characters bring the alphabet size to 2^6 characters). This column  encodes a 64-bit number generated from the *id* column. In practice, however, the process is the [opposite](../../patterns/ascii-id). The ID-based prefix encoding may use this column in the future.
+The *ascii_id* column is a random eight-character long string, which may contain alphanumeric ASCII characters, dash, and underscore (the last two characters bring the alphabet size to 2^6 characters). This column  encodes a 64-bit number generated from the *id* column. In practice, however, the process is the [opposite](../patterns/ascii-id). The ID-based prefix encoding may use this column in the future.
 
 The *path* column (generated from *prefix* and *name*) is the reference target of the foreign key from the *files_categories* table. This deliberate deviation from the more natural *id* or *ascii_id* targets simplifies several operations. 
 
-By definition, the employed MPs model fulfills [design **Rule #1**](../design-rules#Rules). The generated *path* column implements **Rule #3**, and the unique constraint enforces **Rule #5**. By design, each category can have only a single parent reference via the *prefix* column, which defines its parent's *path*, enforcing **Rule #2**. **Rule #4** is semantic and not subject to database controls. *name*/*prefix*/*path* collations enforce **Rule #6**. Many-to-many item-category relation tables implement **Rule #7**, and the separation of tables  for categories and items ensures **Rule #8**. The CHECK constraint on the *name* column ensures the absence of the most troublesome characters in the values.
+By definition, the employed MPs model fulfills [design **Rule #1**](./design-rules#Rules). The generated *path* column implements **Rule #3**, and the unique constraint enforces **Rule #5**. By design, each category can have only a single parent reference via the *prefix* column, which defines its parent's *path*, enforcing **Rule #2**. **Rule #4** is semantic and not subject to database controls. *name*/*prefix*/*path* collations enforce **Rule #6**. Many-to-many item-category relation tables implement **Rule #7**, and the separation of tables  for categories and items ensures **Rule #8**. The CHECK constraint on the *name* column ensures the absence of the most troublesome characters in the values.
 
 The last constraint is a self-referential foreign key *prefix* → *path* to the parent category. For now, both UPDATE and DELETE cascades are disabled. These cascades are only usable for basic scenarios and should not be relied upon in general.
 
@@ -103,4 +103,6 @@ As discussed later, the delete category operation moves the target subtree to th
 
 
 <!-- References -->
+
+[TreesAndRDBMS]: ./design-rules#TreesAndRDBMS
 [mock SQLite database]: https://github.com/pchemguy/SQLite-SQL-Tutorial/raw/gh-pages/Assets/database/Materialized%20Paths.db