C3 (2 points)
https://knobit.org/id/task/dq-rule-derivation/C3
Also as Turtle · JSON-LD · RDF/XML
| dcterms:license | https://creativecommons.org/licenses/by/4.0/ |
|---|---|
| owl:sameAs | https://bitbucket.org/reffa/ontology/id/task/dq-rule-derivation/C3 |
| rdfs:label | C3 (2 points) en |
| schema:hasPart | dq-rule-derivation C3a: unenforced UNIQUE checked on Snowflake, enforced NOT NULL left alone |
| schema:hasPart | dq-rule-derivation C3b: format CHECK lost on Snowflake rewritten in Snowflake regex |
| schema:identifier | C3 |
| schema:position | 3 |
| schema:text | The platform, 1 each: (a) BR-201: Snowflake accepts UNIQUE and does not enforce it, so a set uniqueness check over iban backs uk_dim_deposit_account_iban, while BR-203 (currency_code NOT NULL, which Snowflake does enforce) gets no check and is in not_checked; the BR-203 half is earned only with the BR-201 check; (b) BR-202: the mart's DDL declares no IBAN format constraint, so CORE's ck_iban_format stops at the extract and LP rows never had it; either resolution passes - a validity check in Snowflake regex syntax (REGEXP_LIKE or RLIKE), or a CHECK constraint on DIM_DEPOSIT_ACCOUNT.iban in Snowflake syntax proposed as a physical finding (the table is loaded by MERGE, which Snowflake's CHECK covers, so no load-path caveat is needed). Relying on CORE's constraint fails, and so does PostgreSQL's ~ operator. en |