 In large RDM implementations containing dozens of datasets and hundreds of business rules, choosing the appropriate Ataccama RDM capability improves consistency, reduces implementation effort, and makes solutions easier to maintain.
Â
Selecting the Right Validation Mechanism
Â
The first design decision is not how to write a validation, but which Ataccama RDM capability is best suited to implement the business requirement.
Â
Using Dataset Configuration
Â
Required
Use the Required property for mandatory attributes instead of validation expressions such as: column is not null
 Generated
Use the Generated property for business key attributes that should remain unchanged after record creation.
Â
Â
Using Custom Data Types (Domains)
Â
Reusable attribute constraints should be implemented as Project Data Types (Domains) rather than duplicating the same validation logic across multiple datasets.
Â
Â
Typical examples include:
| Requirement | Domain Example | Configuration |
|---|---|---|
| Data type | Integer, Long, Float, Boolean, Date | Base data type |
| Maximum string length | string_15, string_255, string_4000 | Size = 15, 255, 4000 |
| Whitespace handling | string_trimmed | Regular expression: ^[^ ]+( [^ ]+)*$ |
| Standard value lists | string_Y_N, string_0_1 | Regular expression: ^(Y|N|-)$ |
Â
Using Lookup relationships
Â
Use Lookup Relationships whenever an attribute must reference values maintained in another RDM dataset rather than validating them manually. Typical examples include status codes, countries, role codes, and product categories.Â
Â
Â
Expression Validation
Â
Use Expression Validation for business rules that are evaluated within a single record.
Â
SQL Validation
Â
Use SQL Validation when the rule requires comparing multiple records.
Â
Decision Process
Â
Start with Dataset Configuration. Where a constraint is reusable across multiple attributes, implement it as a Data Type (Domain). Use Expression Validation for record-level business rules and SQL Validation for business rules that compare multiple records.Â
1. Is the attribute mandatory, unique, part of a business key, or non-editable after creation?
→ Use Required, Primary Key / Unique Key, or Generated.
2. Does the attribute require a specific data type or additional constraints?
(e.g. maximum length, whitespace handling)
→ Use Data Types (Domains).
3. Must the value exist in a controlled reference dataset?
→ Use Lookup Relationship.
4. Is the business rule specific to an attribute or based on values within a single record?
→ Use Expression Validation.
5. Does the business rule compare multiple records?
→ Use SQL Validation.
 Â
| Requirement | RDM Capability | Example |
|---|---|---|
| Mandatory attributes | Required property | Required = true |
| Duplicate business keys | Primary Key / Unique Key | Single or composite business key |
| Non-editable business key attributes | Generated property | Business key attributes cannot be modified after record creation |
| Common attribute constraints | Data Types (Domains) | Data type, length, decimal precision, whitespace handling |
| Reference data validation | Lookup Relationship | Statuses, role codes, countries |
| Attribute- and record-level business rules | Expression Validation | Date order, format validation, numeric ranges |
| Cross-record business rules | SQL Validation | Overlapping effective periods, continuity checks |
