@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix edu: <https://knobit.org/def/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://knobit.org/id/task/dq-rule-derivation/C3> a edu:Question ;
    rdfs:label "C3 (2 points)"@en ;
    dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
    schema:hasPart <https://knobit.org/id/register/data-quality#QI-359>,
        <https://knobit.org/id/register/data-quality#QI-360> ;
    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 .

edu:Question rdfs:label "Question"@en,
        "Küsimus"@et .

<https://knobit.org/id/register/data-quality#QI-359> rdfs:label "dq-rule-derivation C3a: unenforced UNIQUE checked on Snowflake, enforced NOT NULL left alone"@en .

<https://knobit.org/id/register/data-quality#QI-360> rdfs:label "dq-rule-derivation C3b: format CHECK lost on Snowflake rewritten in Snowflake regex"@en .