thinkwise-datamodeling-guidelines

Applies naming and design conventions to Thinkwise Software Factory data models.

5|Updated Aug 25, 2026
One-click install
npx skills add https://github.com/rkortThinkwise/sf-mcp-skills-temp --skill thinkwise-datamodeling-guidelines-rkortthinkwise
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: thinkwise-datamodeling-guidelines
Source: https://github.com/rkortThinkwise/sf-mcp-skills-temp/tree/main/thinkwise-datamodeling-guidelines
Command: npx skills add https://github.com/rkortThinkwise/sf-mcp-skills-temp --skill thinkwise-datamodeling-guidelines-rkortthinkwise

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Designing or reviewing a Thinkwise Software Factory data model without consistent conventions leads to inconsistent naming, misclassified entities, wrong column types, and validation errors that only surface at generation time. This Skill provides the reference guidelines for domains, tables, columns, and references so every sf_mcp change is checked against the conventions before being proposed or executed. ## Core Features & Use Cases - Naming and classification rules: Enforces singular lowercase underscore-separated names, classifies tables as strong entities, weak entities, link tables, or inheritance tables, and defines primary/foreign key naming. - Column and domain design: Covers data types, identity columns, defaults, calculated columns, column order, grid/form visibility, grouping, and data sensitivity classification. - Modeling workflow guidance: Includes menu placement decisions, bulk-import task detection, and verified API write quirks for scripting changes through a metadata-driven modeling API. - Use Case: When asked to add a sales_order_line table to an existing model, the Skill guides naming it as a weak entity of sales_order, placing the parent foreign key first in the primary key, choosing domains, and setting grid visibility before committing via sf_mcp. ## Quick Start Review my Thinkwise data model and check the table and column names against the Thinkwise modeling guidelines before I create a new sales order entity.

Frequently Asked Questions about thinkwise-datamodeling-guidelines

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I name tables and columns in a Thinkwise data model?

Use singular, lowercase, self-explanatory names split with underscores, avoiding abbreviations and SQL reserved words. Primary keys follow the pattern <table_name>_id, and foreign keys must exactly match the parent table's primary key column name.

How do I classify entities in Thinkwise Software Factory?

Classify every table as a strong entity, weak entity, link table, or inheritance table before modeling columns. Weak entities include the parent foreign key first in the primary key, while pure link tables use only the composite of both foreign keys with no identity column.

When should I use a calculated column instead of a real column?

Default to a physically stored column and use a calculated column only when the value is always derived from other data. Use calculated_column for same-row formulas and expression for cross-table subqueries, keeping in mind expression columns re-run per row read.

Does the Thinkwise modeling API have known write quirks?

Yes, verified quirks include enum fields rejecting readable keys, fields silently failing in multi-field writes, and extra NOT-NULL order-number fields on child rows. Re-read fields after combined writes and retry failures as isolated single-field writes.

Should weak entities and link tables appear on the menu?

Usually not, since they exist as detail rows or associations under a parent subject. Strong entities and inheritance parents are the default top-level menu candidates, and the user should confirm which candidates actually get menu items.