Database Design for Tracking Divination Variables

BY NICOLE LAU

One reading is insight. Ten readings are data. One hundred readings are patterns. A well-designed database transforms scattered readings into a knowledge base that reveals: Which methods work best for you? Which variables predict accurate outcomes? How has your prediction accuracy improved over time? What recurring themes appear in your life?

This article provides complete database schemas for DDMT practice—from simple spreadsheet structures to advanced relational databases—designed to capture, organize, and analyze divination data for pattern recognition and continuous improvement.

Database Design Principles for DDMT

Principle 1: Normalize Data (Avoid Redundancy)

Don't repeat information. Store each piece of data once, link with relationships.

Bad design: Store "Tarot: The Tower, I Ching: Hex 23, Astrology: Pluto transit" as one text field
Good design: Separate tables for Readings, Tarot_Cards, I_Ching_Hexagrams, Astrology_Transits, linked by IDs

Principle 2: Capture Metadata (Context Matters)

Every reading needs: Date, Time, Location, Emotional state, Life context

Why: Patterns emerge ("I'm more accurate in the morning," "Readings during full moon are different")

Principle 3: Enable Validation (Track Predictions vs. Reality)

Every prediction needs: Expected outcome, Actual outcome, Accuracy rating, Learning

Why: Validation is how you improve. Without tracking outcomes, you can't measure accuracy.

Principle 4: Support Queries (Make Data Searchable)

Design for questions you'll ask: "Show all career readings," "What's my average accuracy for I Ching?" "Which variables appear most in accurate predictions?"

Schema 1: Simple Spreadsheet Database (Tier 1)

Single Table Design (Beginner-Friendly)

Table: Readings_Archive

Columns:
1. Reading_ID (auto-number, primary key)
2. Date (date format)
3. Time (time format)
4. Question (text)
5. Category (dropdown: Career, Relationship, Health, Finance, Spiritual, Other)
6. Method (dropdown: Tarot, I Ching, Astrology, Multi-System)
7. Tarot_Cards (text, comma-separated if multiple)
8. I_Ching_Hexagram (text)
9. Astrology_Indicators (text)
10. Key_Variables (text, comma-separated)
11. Average_Polarity (number, -10 to +10)
12. Convergence_Percent (number, 0-100)
13. Prediction (text, what you expect to happen)
14. Decision_Made (text)
15. Validation_Date (date, when to check outcome)
16. Actual_Outcome (text, filled in later)
17. Accuracy (dropdown: Exact, Close, Partial, Inaccurate)
18. Learning (text, insights from validation)
19. Notes (text, any additional context)

Advantages:
• Simple (one table, easy to understand)
• Works in Google Sheets or Excel
• No technical knowledge required

Limitations:
• Redundancy (if same card appears in multiple readings, stored multiple times)
• Hard to analyze ("Which cards appear most often?" requires text parsing)
• Doesn't scale well (100+ readings become unwieldy)

When to Use

• Beginners (first 50 readings)
• Personal practice (not professional/research)
• Quick setup (can start immediately)

Schema 2: Multi-Table Spreadsheet (Tier 2)

Normalized Design (Intermediate)

Table 1: Readings

Columns:
• Reading_ID (primary key)
• Date
• Time
• Question
• Category
• Method
• Convergence_Percent
• Decision_Made
• Status (dropdown: Pending, Validated, Archived)

Table 2: Variables

Columns:
• Variable_ID (primary key)
• Reading_ID (foreign key → Readings.Reading_ID)
• Variable_Name
• Category (Internal, External, Relational, Temporal)
• Polarity (-10 to +10)
• Tarot_Card
• I_Ching_Hex
• Astrology_Indicator

Table 3: Outcomes

Columns:
• Outcome_ID (primary key)
• Reading_ID (foreign key → Readings.Reading_ID)
• Validation_Date
• Predicted_Outcome
• Actual_Outcome
• Accuracy (Exact, Close, Partial, Inaccurate)
• Learning

Relationships:
• One Reading → Many Variables (1:N)
• One Reading → One Outcome (1:1)

Advantages:
• Less redundancy (variables stored separately)
• Better analysis (can query "Show all readings with The Tower card")
• Scales better (can handle 100-500 readings)

Limitations:
• More complex (requires understanding relationships)
• Harder to set up in spreadsheets (need VLOOKUP or similar)

Implementation in Google Sheets

Sheet 1: Readings (main data)
Sheet 2: Variables (linked via Reading_ID)
Sheet 3: Outcomes (linked via Reading_ID)

Use VLOOKUP to pull data across sheets:
=VLOOKUP(A2, Variables!A:H, 3, FALSE) // Get Variable_Name for Reading_ID in A2

Schema 3: Relational Database (Tier 3)

Full Normalization (Advanced)

Table 1: Readings

```sql
CREATE TABLE Readings (
reading_id SERIAL PRIMARY KEY,
date DATE NOT NULL,
time TIME,
question TEXT NOT NULL,
category VARCHAR(50),
method VARCHAR(50),
convergence_percent INTEGER CHECK (convergence_percent BETWEEN 0 AND 100),
decision_made TEXT,
status VARCHAR(20) DEFAULT 'Pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```

Table 2: Variables

```sql
CREATE TABLE Variables (
variable_id SERIAL PRIMARY KEY,
reading_id INTEGER REFERENCES Readings(reading_id) ON DELETE CASCADE,
variable_name VARCHAR(100) NOT NULL,
category VARCHAR(50),
polarity INTEGER CHECK (polarity BETWEEN -10 AND 10),
interpretation TEXT
);
```

Table 3: Tarot_Cards

```sql
CREATE TABLE Tarot_Cards (
card_id SERIAL PRIMARY KEY,
variable_id INTEGER REFERENCES Variables(variable_id) ON DELETE CASCADE,
card_name VARCHAR(100) NOT NULL,
position VARCHAR(50),
reversed BOOLEAN DEFAULT FALSE
);
```

Table 4: I_Ching_Hexagrams

```sql
CREATE TABLE I_Ching_Hexagrams (
hexagram_id SERIAL PRIMARY KEY,
variable_id INTEGER REFERENCES Variables(variable_id) ON DELETE CASCADE,
hexagram_number INTEGER CHECK (hexagram_number BETWEEN 1 AND 64),
hexagram_name VARCHAR(100),
changing_lines TEXT
);
```

Table 5: Astrology_Indicators

```sql
CREATE TABLE Astrology_Indicators (
indicator_id SERIAL PRIMARY KEY,
variable_id INTEGER REFERENCES Variables(variable_id) ON DELETE CASCADE,
planet VARCHAR(50),
sign VARCHAR(50),
house INTEGER,
aspect VARCHAR(50),
transit_type VARCHAR(50)
);
```

Table 6: Outcomes

```sql
CREATE TABLE Outcomes (
outcome_id SERIAL PRIMARY KEY,
reading_id INTEGER REFERENCES Readings(reading_id) ON DELETE CASCADE,
validation_date DATE,
predicted_outcome TEXT,
actual_outcome TEXT,
accuracy VARCHAR(20) CHECK (accuracy IN ('Exact', 'Close', 'Partial', 'Inaccurate')),
learning TEXT,
validated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```

Relationships:
• Readings 1:N Variables
• Variables 1:N Tarot_Cards (one variable can have multiple cards if spread)
• Variables 1:N I_Ching_Hexagrams
• Variables 1:N Astrology_Indicators
• Readings 1:1 Outcomes

Advantages

• Full normalization (zero redundancy)
• Powerful queries (complex pattern analysis)
• Scales infinitely (1000+ readings no problem)
• Data integrity (foreign keys prevent orphaned records)
• Multi-user support (if using PostgreSQL/MySQL)

Example Queries

Query 1: Average accuracy by method

```sql
SELECT
r.method,
COUNT(*) as total_readings,
AVG(CASE
WHEN o.accuracy = 'Exact' THEN 100
WHEN o.accuracy = 'Close' THEN 75
WHEN o.accuracy = 'Partial' THEN 50
WHEN o.accuracy = 'Inaccurate' THEN 0
END) as avg_accuracy_percent
FROM Readings r
JOIN Outcomes o ON r.reading_id = o.reading_id
GROUP BY r.method
ORDER BY avg_accuracy_percent DESC;
```

Result: "Tarot: 78% avg accuracy, I Ching: 82%, Multi-System: 85%"

Query 2: Most common cards in accurate predictions

```sql
SELECT
tc.card_name,
COUNT(*) as frequency,
AVG(v.polarity) as avg_polarity
FROM Tarot_Cards tc
JOIN Variables v ON tc.variable_id = v.variable_id
JOIN Readings r ON v.reading_id = r.reading_id
JOIN Outcomes o ON r.reading_id = o.reading_id
WHERE o.accuracy IN ('Exact', 'Close')
GROUP BY tc.card_name
ORDER BY frequency DESC
LIMIT 10;
```

Result: "The Star appears in 15 accurate readings (avg polarity +8.2), The Tower in 12 (avg polarity -7.5)"

Query 3: Convergence vs. accuracy correlation

```sql
SELECT
CASE
WHEN r.convergence_percent >= 90 THEN '90-100%'
WHEN r.convergence_percent >= 75 THEN '75-89%'
WHEN r.convergence_percent >= 50 THEN '50-74%'
ELSE '0-49%'
END as convergence_range,
COUNT(*) as readings,
SUM(CASE WHEN o.accuracy IN ('Exact', 'Close') THEN 1 ELSE 0 END) * 100.0 / COUNT(*) as accuracy_rate
FROM Readings r
JOIN Outcomes o ON r.reading_id = o.reading_id
GROUP BY convergence_range
ORDER BY convergence_range DESC;
```

Result: "90-100% convergence → 89% accuracy, 50-74% convergence → 62% accuracy" (validates convergence hypothesis!)

Schema 4: NoSQL Document Database (Alternative)

MongoDB Structure (Flexible)

Collection: readings

```json
{
"_id": ObjectId("..."),
"date": ISODate("2026-01-08"),
"question": "Should I accept job offer?",
"category": "Career",
"method": "Multi-System",
"convergence_percent": 100,
"variables": [
{
"name": "Resources",
"category": "External",
"polarity": -7,
"tarot": {
"card": "Ten of Wands",
"position": "Present",
"reversed": false
},
"interpretation": "Overburdened, resources inadequate"
},
{
"name": "Timing",
"category": "Temporal",
"polarity": 0,
"i_ching": {
"number": 5,
"name": "Waiting",
"changing_lines": []
},
"interpretation": "Not now, wait for better timing"
}
],
"decision": "Decline offer, wait 18 months",
"outcome": {
"validation_date": ISODate("2027-07-08"),
"predicted": "Will find better opportunity in 18 months",
"actual": "Found better opportunity Month 18, accepted",
"accuracy": "Exact",
"learning": "Timing predictions very accurate with I Ching Hex 5"
},
"metadata": {
"time": "09:30",
"location": "Home",
"emotional_state": "Anxious but clear",
"moon_phase": "Waxing Gibbous"
}
}
```

Advantages:
• Flexible schema (can add fields without migration)
• Nested data (variables embedded in reading document)
• Fast reads (all data in one document)
• JSON format (easy to work with in JavaScript/Python)

Disadvantages:
• Harder to query across documents ("Show all readings with The Tower")
• Potential redundancy (if same card in multiple readings)
• Less data integrity (no foreign key constraints)

When to Use NoSQL

• Rapid prototyping (schema evolves frequently)
• Web/mobile apps (JSON is native format)
• Unstructured data (readings vary widely in structure)

Data Collection Best Practices

Practice 1: Capture Immediately

Enter reading data right after the reading, not days later. Memory fades, details are lost.

Workflow:
1. Do reading
2. Immediately open database
3. Enter: Date, Question, Cards/Hexagrams, Interpretation
4. Set validation reminder (calendar alert)

Practice 2: Use Consistent Terminology

Don't write "The Tower" in one reading and "Tower card" in another. Use exact card names.

Solution: Dropdown lists (in spreadsheets) or reference tables (in databases) with standardized names.

Practice 3: Tag Liberally

Add tags beyond Category: #burnout, #career_transition, #relationship_crisis, #financial_planning

Why: Enables cross-category queries ("Show all readings tagged #burnout" regardless of category)

Practice 4: Validate Regularly

Set recurring task: "First Monday of each month, validate all readings from 3 months ago"

Why: Validation is how you improve. Without it, database is just a diary, not a learning system.

Practice 5: Backup Frequently

Database is your divination knowledge base. Losing it = losing years of insights.

Backup strategy:
• Spreadsheets: Auto-save to cloud (Google Drive, Dropbox)
• Databases: Weekly export to CSV + cloud backup
• Version control: Keep monthly snapshots (Jan_2026_backup.csv)

Analytics Queries (Pattern Recognition)

Query 1: Accuracy Trends Over Time

"Am I getting better at divination?"

```sql
SELECT
DATE_TRUNC('month', r.date) as month,
COUNT(*) as readings,
AVG(CASE WHEN o.accuracy IN ('Exact', 'Close') THEN 1.0 ELSE 0.0 END) as accuracy_rate
FROM Readings r
JOIN Outcomes o ON r.reading_id = o.reading_id
GROUP BY month
ORDER BY month;
```

Visualization: Line chart showing accuracy improving from 60% (Month 1) to 85% (Month 12)

Query 2: Variable Frequency Analysis

"What themes recur in my life?"

```sql
SELECT
variable_name,
COUNT(*) as frequency,
AVG(polarity) as avg_polarity
FROM Variables
GROUP BY variable_name
HAVING COUNT(*) >= 5
ORDER BY frequency DESC;
```

Result: "Fear appears 23 times (avg polarity -6.2), Confidence 18 times (+7.8), Resources 15 times (-3.1)"

Insight: "Fear is my most common challenge. Need to work on this."

Query 3: Best Time for Readings

"When am I most accurate?"

```sql
SELECT
EXTRACT(HOUR FROM r.time) as hour,
COUNT(*) as readings,
AVG(CASE WHEN o.accuracy IN ('Exact', 'Close') THEN 1.0 ELSE 0.0 END) as accuracy_rate
FROM Readings r
JOIN Outcomes o ON r.reading_id = o.reading_id
WHERE r.time IS NOT NULL
GROUP BY hour
HAVING COUNT(*) >= 3
ORDER BY accuracy_rate DESC;
```

Result: "9-10 AM: 92% accuracy (12 readings), 9-10 PM: 68% accuracy (15 readings)"

Insight: "I'm more accurate in the morning. Schedule important readings before noon."

Key Database Design Learnings

1. Start simple, evolve as needed
Begin with single-table spreadsheet. After 50 readings, migrate to multi-table. After 200, consider relational database.

2. Normalization reduces redundancy, enables analysis
Storing "The Tower" once (in reference table) vs. 15 times (in reading text) makes queries possible.

3. Validation data is as important as reading data
Prediction without validation = opinion. Prediction + validation = learning.

4. Metadata reveals hidden patterns
Time of day, moon phase, emotional state—these contextual factors affect accuracy.

5. Queries transform data into knowledge
100 readings in a database = data. Query showing "90%+ convergence → 89% accuracy" = knowledge.

Database design transforms DDMT from individual practice to systematic learning, from scattered readings to pattern recognition, from intuition to data-driven improvement. This is how you track divination variables at scale.