data-model-design — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited data-model-design (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
For analytics data products, default to star schema with strategic denormalization:
Fact tables contain events at the lowest useful grain:
Dimension tables contain context:
NEVER fully denormalize into One Big Table. Many-to-many relationships cause exponential row growth. A patient with 10 conditions and 5 medications creates 50 rows instead of 15.
ALWAYS start with the query patterns. What questions will consumers ask? Design the schema to make those queries simple. If 80% of queries filter by date and group by category, those should be the primary dimensions.
Type 1 - Overwrite the old value. Use when history doesn't matter (correcting a typo in a name).
Type 2 - Add a new row with effective dates. Use when you need to track what was true at a point in time (patient address at time of visit, product price at time of sale). Add effective_start_date, effective_end_date, and is_current flag.
Type 3 - Add a column for the previous value. Use when you only need one level of history (current_category, previous_category).
Default to Type 2 for any dimension where the business asks "what was it at the time of X?" Start with Type 1 for everything else and upgrade when the need emerges.
For every non-obvious modeling decision, write a lightweight ADR:
Keep ADRs in the repo alongside the schema. Future team members will ask "why is it modeled this way?" The ADR answers before they have to ask.
Before building, validate with limited data:
You probably won't design the OLTP schema. But you'll need to evaluate whether it's a reliable source for your data product.
Quick checklist before building on a source system:
Anti-patterns to flag immediately:
VARCHAR(255) on every string column (signals no thought about data types)FLOAT or DOUBLE for money (use DECIMAL or integer cents)VARCHAR breaks sorting and comparison)See schema-patterns.md for common dimensional modeling patterns.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.