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 |