# Infor LN Domain Structure Design: Architecture Guide > Source: https://netray.co/resources/infor-ln-domain-structure-design-guide > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Knowledge Base ## Short answer Design robust Infor LN domain structures including data dictionary domains, table relationships, key definitions, and index strategies for BAAN/LN development. ## Category infor-ln ## Content **Intro:** The data dictionary domain system is the architectural foundation of Infor LN. Every field in every table and every variable in every BShell script is typed by a domain. Domains enforce consistency across the entire application: a customer code is always the same length, format, and validation rule whether it appears in Sales Orders, Accounts Receivable, or Project Management. Designing domain structures correctly at the start of a customization project prevents cascading rework and data integrity issues downstream. **Sections:** #### Domain Types and the Data Dictionary Hierarchy **Body:** The LN data dictionary uses a hierarchical domain system. Base domains define primitive types (string, long, double, date, enum). Extended domains inherit from base domains and add business-specific attributes (length, format mask, validation, zoom reference). Table column domains inherit from extended domains and bind to specific database storage. This three-level hierarchy means that changing a base domain's validation rule propagates to every table column and BShell variable that uses it, a powerful but dangerous capability that requires careful governance. **Bullets:** Base domains are defined in the System module (tc): tcstring (variable-length string), tclong (32-bit integer), tcdouble (floating-point), tcdate (date), tcbool (boolean), tcenum (enumeration), these are rarely modified Extended domains add business context: tcitem (12-character item code with uppercase enforcement), tccom100 (business partner code with zoom to BP master), tcamnt (amount with 2-decimal precision and currency formatting), defined in module-level data dictionaries Create a custom domain: navigate to Data Dictionary Maintenance (ttadv1600m000), define the domain code following the naming convention [module][sequence] (e.g., tcspc001 for a custom spare parts module domain), set the base type, length, format mask, and validation expression Domain validation expressions use BShell syntax: 'val.expr = (i.field >= 0 and i.field <= 9999)' enforces a numeric range; 'val.expr = (match$(i.field, "[A-Z][0-9]*"))' enforces an alphanumeric pattern CRITICAL: never modify standard Infor LN domains directly; always create custom domains that inherit from standard domains; this protects your customizations during LN upgrades where standard domains may be overwritten #### Table Design and Key Definition Patterns **Body:** LN tables are defined in the data dictionary with explicit key structures that control both database indexing and application-level record access. Every table must have a primary key (key 1) that uniquely identifies each record. Secondary keys (key 2 through key N) define alternative access paths used by sessions, reports, and BShell queries. Key design directly impacts performance: a poorly designed key forces full table scans on large transaction tables, while an over-indexed table suffers write performance degradation. **Bullets:** Primary key (key 1) design: include the company code (tcemm050.comp) as the first segment for multi-company installations; follow with the natural business key (order number, item code); keep primary keys to 3-4 segments maximum for optimal index performance Secondary keys for session access: define a key that matches the session's default sort order; for example, a Sales Order Lines session that sorts by order number + line number needs a key on (comp, orno, pono) to avoid a database sort operation Define keys in the data dictionary: navigate to Table Definition (ttadv4500m000), select the table, open the Keys tab, add key segments in order; each segment references a table column; mark the key as Unique if it enforces a business constraint Index strategy for transaction tables: limit to 5-6 keys maximum on high-volume tables (>1M rows); each additional key adds write overhead; use the LN SQL Trace facility (ttadv9600m000) to identify which keys are actually used by sessions and remove unused keys For multi-company tables, always use a composite key starting with the company field to enable company-level data partitioning and prevent cross-company data leakage in queries #### Relationships, References, and Data Integrity **Body:** LN enforces referential integrity through domain references and table relationships, not through database-level foreign keys. When a domain has a reference session defined, LN automatically validates that any value entered for that domain exists in the referenced table. Table relationships are defined in the data dictionary as parent-child links that control cascade delete behavior and navigation between related sessions. This application-level referential integrity gives LN flexibility but requires disciplined configuration. **Bullets:** Domain references: when domain tcitem has reference session tcibd0101s000 (Item Master zoom), every field typed as tcitem automatically validates against the Item Master table; invalid item codes are rejected at input time with the message 'Value not found in [table]' Parent-child relationships: define in Table Relationships (ttadv4540m000); a parent-child link between Order Header (tdsls400) and Order Lines (tdsls401) ensures that deleting an order header cascades to delete its lines; set the relationship type to 'Restrict' to prevent header deletion when lines exist Soft references: for optional relationships (e.g., a project code on a purchase order that may or may not reference the Project Master), use a conditional validation in the BShell after.field trigger instead of a domain reference; this prevents mandatory lookup validation on optional fields Cross-module references: when your custom table references a standard LN table in another module (e.g., referencing tcibd001 Item Master from a custom quality module), always use the standard domain type (tcitem) to ensure the reference is maintained during LN upgrades Data migration consideration: when loading data via batch import, temporarily disable domain validation using db.set.validation(false) in the BShell import script to bypass reference checks; re-enable validation after import and run a separate validation report to identify orphaned references **Cta:** Design scalable Infor LN domain architectures with Netray's AI-powered analysis, get automated data dictionary reviews and optimization recommendations. ## Related Slugs - infor-ln-bshell-programming-fundamentals - infor-ln-table-extensions-development - infor-ln-session-creation-modification ## Search terms Infor LN domain structure, BAAN data dictionary design, LN table key definition, Infor LN data model architecture, BAAN domain types guide --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json