Создание правил качества данных

Качество данных измеряет целостность данных в организации. Вы оцениваете качество данных с помощью оценок качества данных. Единый каталог Microsoft Purview создает оценки на основе оценки данных в соответствии с правилами, которые вы определяете.

Правила качества данных — это важные рекомендации, устанавливаемые организациями для обеспечения точности, согласованности и полноты данных. Эти правила помогают поддерживать целостность и надежность данных.

Ниже приведены некоторые ключевые аспекты правил качества данных.

• Точность. Данные должны точно представлять реальные сущности. Контекст имеет значение! Например, если вы храните адреса клиентов, убедитесь, что они соответствуют фактическим расположениям.

• Полнота. Это правило идентифицирует пустые, пустые или отсутствующие данные. Он проверяет наличие всех значений, хотя и не обязательно правильных.

• Соответствие. Это правило гарантирует, что данные соответствуют стандартам форматирования данных, таким как представление дат, адресов и допустимых значений.

• Согласованность. Это правило проверяет, соответствуют ли разные значения одной записи заданному правилу и нет ли противоречий. Согласованность данных обеспечивает равномерное представление одной и той же информации в разных записях. Например, если у вас есть каталог продуктов, согласованные названия и описания продуктов имеют решающее значение.

• Своевременность. Это правило направлено на обеспечение доступности данных в максимально короткое время. Это гарантирует актуальность данных.

• Уникальность. Это правило проверяет, не дублируются ли значения. Например, если на каждого клиента должна быть только одна запись, то для одного клиента не будет нескольких записей. Каждый клиент, продукт или транзакция должен иметь уникальный идентификатор.

Жизненный цикл качества данных

Создание правил качества данных — это шестой шаг в жизненном цикле качества данных. Ниже приведены следующие шаги.

1. Назначьте пользователям разрешения на управление качеством данных в Единый каталог для использования всех функций качества данных.
2. Зарегистрируйте и проверьте источник данных в Схема данных Microsoft Purview.
3. Добавьте ресурс данных в продукт данных.
4. Настройте подключение к источнику данных, чтобы подготовить источник к оценке качества данных.
5. Настройте и запустите профилирование данных для ресурса в источнике данных.

Необходимые роли

• Для создания правил качества данных и управления ими пользователям требуется роль администратора качества данных.
• Чтобы просмотреть существующие правила качества, пользователям требуется роль читателя качества данных.

Просмотр существующих правил качества данных

1. В Единый каталог выберите Управление работоспособностью, а затем — Качество данных.

2. Выберите домен управления, а затем — продукт данных.

3. Выберите ресурс данных из списка Ресурсы данных .

4. Перейдите на вкладку Правила , чтобы просмотреть существующие правила, применяемые к ресурсу.

5. Выберите правило, чтобы просмотреть журнал производительности примененного правила к выбранному ресурсу данных.

   

Доступные правила качества данных

Качество данных Microsoft Purview позволяет настроить следующие правила. Эти правила доступны в готовых версиях и предлагают способ измерения качества данных с низким уровнем кода и без кода.

Компонент ранжирования по актуальности

Правило актуальности проверяет, обновляется ли ресурс в течение ожидаемого времени. Актуальность определяется выбором дат последнего изменения.

Уникальные значения

В правиле Уникальные значения указано, что все значения в указанном столбце должны быть уникальными. Все уникальные значения обрабатываются как проходные, а не уникальные — как сбой. Если правило пустых и пустых полей не определено в столбце, для целей этого правила игнорируются значения NULL или пустые.

Соответствие строкового формата

Правило форматирования соответствия проверяет, являются ли все значения в столбце допустимыми. Если правило пустых или пустых полей для столбца не определено, оно игнорирует значения NULL или пустые.

Это правило может проверить каждое значение в столбце с помощью трех разных подходов:

1. Перечисление. В этом подходе используется разделенный запятыми список значений. Если вычисленное значение не соответствует одному из перечисленных значений, проверка не выполняется. Можно экранировать запятые и обратные косые черты с помощью обратной косой черты (\). Таким образом, a \, b, c содержит два значения: первое — , a , b а второе — c.

1. Как шаблон. like(<i>&lt;string&gt;</i> : string, <i>&lt;pattern match&gt;</i> : string) => boolean Шаблон — это строка, которая соответствует правилу буквально. Исключениями являются следующие специальные символы: _ соответствует любому одному символу .posix во входных данных (аналогично регулярным выражениям) % соответствует нулю или нескольким символам во входных данных (аналогично .posix регулярным выражениям). Escape-символ — Если . escape-символ предшествует специальному символу или другому escape-символу, следующий символ сопоставляется буквально. Невозможно экранировать любой другой символ.

   • like('icecream', 'ice%') -> true

   

2. Регулярное выражение: regexMatch(<i>&lt;string&gt;</i> : string, <i>&lt;regex to match&gt;</i> : string) => boolean

   Проверяет, соответствует ли строка заданному шаблону регулярных выражений. Используйте <regex>(обратная кавычка) для сопоставления строки без экранирования.

   • regexMatch('200.50', '(\\d+).(\\d+)') -> true
   • regexMatch('200.50', `(\d+).(\d+)`) -> true

   

Соответствие типов данных

Правило сопоставления типов данных указывает ожидаемый тип данных для связанного столбца. Так как обработчик правил работает во многих разных источниках данных, он не может использовать собственные типы, такие как BIGINT или VARCHAR. Вместо этого она использует собственную систему типов и преобразует собственные типы в эту систему. Это правило сообщает обработчику проверки качества, какой из его встроенных типов следует использовать для собственного типа. Система типов данных поступает из системы типов Microsoft Azure Поток данных, используемой в Фабрика данных Azure.

Во время проверки качества подсистема проверяет все собственные типы на соответствие типам данных. Если не удается перевести собственный тип в тип соответствия типа данных, он обрабатывает строку как ошибку.

Повторяющиеся строки

Правило повторяющихся строк проверяет, является ли сочетание значений в столбце уникальным для каждой строки таблицы.

В следующем примере ожидается, что объединение CompanyName, CustomerID, EmailAddress, FirstName и LastName создает уникальное значение для всех строк таблицы.

Каждый ресурс может иметь ноль или один экземпляр этого правила.

Пустые и пустые поля

Правило пустых и пустых полей утверждает, что указанные столбцы не должны содержать значения NULL. Для строк правило также запрещает пустые значения или значения, доступные только для пробелов. Во время проверки качества данных подсистема обрабатывает любое значение в этом столбце, которое не равно NULL, как правильное. Это правило влияет на другие правила, такие как уникальные значения или правила сопоставления форматов . Если это правило не определено для столбца, эти правила автоматически игнорируют любые значения NULL при выполнении в этом столбце. Если вы определяете это правило для столбца, эти правила проверяют значения NULL или пустые значения в этом столбце и учитывают их для оценки.

Подстановка таблицы

Правило подстановки таблиц проверяет каждое значение в столбце, в котором определяется правило, и сравнивает его со ссылочной таблицей. Например, основная таблица содержит столбец с именем location, который содержит города, штаты и почтовые индексы в формате "город, регион zip". Справочная таблица с именем "citystate" содержит все юридические сочетания городов, штатов и почтовых индексов, поддерживаемые в США. Цель состоит в том, чтобы сравнить все расположения в текущем столбце с этим списком ссылок, чтобы убедиться, что используются только юридические сочетания.

Чтобы настроить это правило, введите имя "citystatezip" в диалоговом окне поиска ресурсов. Затем выберите нужный ресурс и столбец, с которым вы хотите сравнить.

Пользовательские правила

Настраиваемое правило позволяет указать правила, проверяющие строки на основе одного или нескольких значений в этой строке. Для создания настраиваемых правил можно использовать язык регулярных выражений, Фабрика данных Azure выражений и язык выражений SQL.

Пользовательское правило состоит из трех частей:

1. Выражение строки. Это логическое выражение применяется к каждой строке, одобренной выражением фильтра. Если это выражение возвращает значение true, строка проходит. Если возвращается значение false, строка завершается ошибкой.

2. Выражение фильтра. Это необязательное условие сужает набор данных, для которого вычисляется условие строки. Чтобы активировать его, установите флажок Использовать выражение фильтра . Это выражение возвращает логическое значение. Выражение фильтра применяется к строке, и если оно возвращает значение true, то эта строка считается для правила. Если выражение фильтра возвращает значение false для этой строки, это означает, что строка игнорируется в целях этого правила. По умолчанию выражение фильтра передает все строки, поэтому если не указать выражение фильтра, учитываются все строки.

3. Выражение NULL: проверяет, как следует обрабатывать значения NULL. Это выражение возвращает логическое значение, которое обрабатывает случаи, когда данные отсутствуют. Если выражение возвращает значение true, выражение строки не применяется.

Каждая часть правила работает аналогично существующим условиям Качество данных Microsoft Purview. Правило передается только в том случае, если выражение строки принимает значение TRUE для набора данных, соответствующего выражению фильтра, и обрабатывает отсутствующие значения, указанные в выражении NULL.

Пример. Правило, которое гарантирует, что "fareAmount" является положительным, а "tripDistance" является допустимым:

• Выражение строки: tripDistance > 0 AND fareAmount > 0
• Выражение фильтра: paymentType = 'CRD'
• Выражение NULL: tripDistance IS NULL

Создание настраиваемого правила

1. В Единый каталог перейдите в раздел Управление>работоспособностью Качество данных.
2. Выберите домен управления, продукт данных, а затем ресурс данных.
3. На вкладке Правила выберите Создать правило.

Создание настраиваемого правила с помощью выражения Фабрика данных Azure (ADF)

1. Чтобы создать правило с помощью регулярного выражения или выражения ADF, выберите Пользовательский в списке параметров правила, а затем нажмите кнопку Далее.

2. Добавьте имя правила и описание, а затем нажмите кнопку Создать.

   

Примеры пользовательских правил

Выражение фильтра и выражение строки определяются с помощью языка выражений Фабрика данных Azure с указанным здесь языком. Однако доступны не все функции, определенные для универсального языка выражений ADF. Полный список доступных функций находится в списке Функций, доступных в диалоговом окне выражения. Следующие функции, определенные здесь , не поддерживаются: isDelete, isError, isIgnore, isInsert, isMatch, isUpdate, isUpsert, partitionId, кэшированный поиск и функции Window.

Создание настраиваемого правила с помощью выражения SQL

Пользовательские правила SQL в Качество данных Microsoft Purview предоставляют гибкий способ определения проверок качества данных с помощью предикатов SPARK SQL. Эта функция позволяет пользователям создавать правила непосредственно в Spark SQL для расширенных сценариев проверки. Требуется только выражение строки; выражения filter и NULL необязательны для дальнейшей настройки. Используйте настраиваемые правила SQL для удовлетворения сложных бизнес-требований и повышения качества данных, используя все возможности Spark SQL. Пользовательские правила SQL обеспечивают сложную проверку данных, которая может быть невозможна только с выражениями ADF. Написав предикаты Spark SQL, вы можете удовлетворить уникальные бизнес-потребности и поддерживать высокие стандарты качества данных.

1. Чтобы создать правило с помощью языка выражений SQL, выберите Пользовательский (SQL) в списке параметров правила, а затем нажмите кнопку Далее.

2. Добавьте имя правила и описание, а затем нажмите кнопку Создать.

   Сценарий	Выражения
   Проверяет правильные шаблоны строк (например, rateCodeId, начинающийся с "1" и числовой) и фильтрует по допустимым типам платежей.	Row: rateCodeId RLIKE '^1[0-9]+$' Filter: paymentType IN ('CRD', 'CSH') Null: rateCodeId IS NULL
   Обеспечивает правильное сравнение столбцов между puLocationId и doLocationId, а также тариф в сравнении с расстоянием поездки.	Row: puLocationId > doLocationId AND fareAmount > tripDistance * 10' Filter: paymentType <> 'CSH'' Null: tripDistance IS NULL
   Проверяет, находится ли тип paymentType в заданном списке (карта, наличные деньги), фильтруя строки на основе суммы тарифа.	Row: paymentType IN ('CRD', 'CSH')' Filter: fareAmount >= 50 Null: paymentType IS NULL
   Гарантирует, что расстояние находится в пределах инклюзивного диапазона (5–10 миль), при обработке значений NULL и фильтрации допустимых типов платежей.	Row: tripDistance BETWEEN 5 AND 10 Filter: paymentType <> 'CRD' Null: tripDistance IS NULL
   Гарантирует, что набор данных не превышает значение 20 % NULL для fareAmount.	Row: (SELECT avg(CASE WHEN fareAmount IS NULL THEN 1 ELSE 0 END) FROM nycyellowtaxidelta1BillionPartitioned) < 0.20' Filter: vendorID IN ('VTS', 'CMT')
   Проверяет, есть ли в наборе данных по крайней мере 2 отдельных значения paymentType.	Row: (SELECT count(DISTINCT paymentType) FROM nycyellowtaxidelta1BillionPartitioned) >= 2 Filter: vendorID IN ('1', '2')
   Гарантирует, что средняя сумма тарифа набора данных попадает в указанный диапазон (80 <= среднее <= 140).	Row: (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) BETWEEN 80 AND 140 ' Filter: paymentType IN ('CRD', 'CSH')
   Гарантирует, что максимальное значение tripDistance в наборе данных равно <10 милям.	Row: (SELECT max(tripDistance) FROM nycyellowtaxidelta1BillionPartitioned) <= 10.0 Filter: vendorID IN ('VTS', 'CMT')
   Гарантирует, что стандартное отклонение fareAmount ниже определенного порогового значения (< 30).	Row: (SELECT stddev_samp(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) < 30.0 Filter: vendorID IN ('VTS', 'CMT')
   Гарантирует, что медиана тарифа набора данных находится в пределах указанного порогового значения (<= 15).	Row: (SELECT percentile_approx(fareAmount, 0.5) FROM nycyellowtaxidelta1BillionPartitioned) <= 15.0 Filter: vendorID IN ('VTS', 'CMT')
   Гарантирует, что идентификатор поставщика является уникальным в наборе данных в рамках определенного paymentType.	Row: COUNT(1) OVER (PARTITION BY vendorID) = 1 Filter: paymentType IN ('CRD', 'CSH','1', '2') Null: vendorID IS NULL
   Гарантирует, что сочетание puLocationId и doLocationId является уникальным в наборе данных.	Row: COUNT(1) OVER (PARTITION BY puLocationId, doLocationId) = 1 Filter: paymentType IN ('CRD', 'CSH') Null: puLocationId IS NULL OR doLocationId IS NULL
   Гарантирует, что значение vendorId является уникальным для параметра paymentType.	Row: COUNT(1) OVER (PARTITION BY paymentType, vendorID) = 1 ,Filter: rateCodeId < 25, Null: vendorID IS NULL
   Гарантирует, что значение tpepPickupDateTime строки больше заданной метки времени отсечения.	Row: tpepPickupDateTime >= TIMESTAMP '2014-01-03 00:00:00' Filter: paymentType IN ('CRD', 'CSG', '1', '2') Null: tpepPickupDateTime IS NULL
   Каждая поездка должна быть завершена в течение 1 часа	Row: (unix_timestamp(tpepDropoffDateTime) - unix_timestamp(tpepPickupDateTime)) <= 3600 Filter: paymentType IN ('CRD', 'CSH', '1', '2') Null: tpepPickupDateTime IS NULL OR tpepDropoffDateTime IS NULL
   Сохраняет только самую высокую стоимость поездки для каждого места сбора.	Row: row_number() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1, Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0, Null: fareAmount IS NULL OR puLocationId IS NULL
   Все привязаны самые высокие тарифы на каждый пикап локации пропуска (не только сначала row_number).	Row: rank() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1 Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0 Null: fareAmount IS NULL OR puLocationId IS NULL
   Тариф не должен уменьшаться с течением времени для каждого типа оплаты.	Row: fareAmount >= lag(fareAmount) OVER (PARTITION BY paymentType ORDER BY tpepPickupDateTime) Null: tpepPickupDateTime IS NULL OR fareAmount IS NULL
   Тариф каждой строки в пределах 10 средних по группе по типу оплаты.	Row: abs(fareAmount - avg(fareAmount) OVER (PARTITION BY paymentType)) <= 10 Filter: paymentType IN ('CRD', 'CSH','1','2') Null: fareAmount IS NULL
   Общее количество поездок не должно превышать 20 миль.	Row: sum(tripDistance) OVER (ORDER BY tpepPickupDateTime ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) <= 20 Filter: paymentType = '1' Null: tripDistance IS NULL
   Проверяет, превышает ли тариф каждой поездки средний глобальный для соответствующих поставщиков.	Row: fareAmount > (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) Filter: vendorID IN ('VTS', 'CMT') Null: fareAmount IS NULL
   Проверяет, превышает ли значение tripDistance каждой строки, чем минимальное значение для его paymentType (Card/Cash).	Row: tripDistance > (SELECT min(u.tripDistance) FROM (SELECT tripDistance, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD', 'CSH') Null: tripDistance IS NULL
   Для каждой поездки проверяет, превышает ли тариф средний для своего типа оплаты.	Row: fareAmount > (SELECT avg(u.fareAmount) FROM (SELECT fareAmount, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD','CSH','1','2') AND vendorID IN ('VTS','CMT') Null: fareAmount IS NULL
   Проверяет, можно ли правильно представить столбец fareAmount (numeric) в виде строки, соответствующей числовой схеме (положительные числа с необязательным десятичным числом). При этом используется приведение, так как fareAmount является числовым столбцом.	Row: CAST(fareAmount AS STRING) RLIKE '^[0-9]+(\.[0-9]+)?$' Filter: paymentType IN ('CRD', 'CSH') Null: fareAmount IS NULL
   Гарантирует, что tpepPickupDateTime является допустимой меткой времени в формате гггг-ММ-дд ЧЧ:мм:сс. Этот столбец уже имеет формат DATETIME	Row: to_timestamp(tpepPickupDateTime, 'yyyy-MM-dd HH:mm:ss') IS NOT NULL Filter: paymentType IN ('CRD', 'CSH') Null: tpepPickupDateTime IS NULL
   Гарантирует, что значения paymentType нормализуются в нижнем регистре и не имеют начальных или конечных пробелов.	Row: lower(trim(paymentType)) IN ('card','cash') AND length(trim(paymentType)) > 0 Null: paymentType IS NULL OR trim(paymentType) = ''
   Безопасно вычисляет отношение fareAmount к tripDistance, гарантируя, что деление на ноль не произойдет, сначала проверив значение tripDistance > 0.	Row: CASE WHEN tripDistance > 0 THEN fareAmount / tripDistance ELSE NULL END >= 10 Filter: tripDistance > 0 AND vendorID IN ('VTS', 'CMT')
   Демонстрирует, как объединение может заменять значения NULL значениями по умолчанию (например, 0,0), и гарантирует, что возвращаются только допустимые строки.	Row: coalesce(fareAmount, 0.0) >= 5 Filter: paymentType IN ('CRD','CSH')

Рекомендации по написанию пользовательских правил SQL

• Не усложняйте выражения. Стремитесь писать четкие и простые выражения, которые просты в обслуживании.
• Используйте встроенные функции SPARK SQL. Используйте обширную библиотеку функций Spark SQL для обработки строк, обработки дат и числовых операций, чтобы свести к минимуму ошибки и повысить производительность.
• Сначала протестируйте небольшой набор данных. Проверьте правила для небольшого набора данных, прежде чем применять их в большом масштабе, чтобы выявить потенциальные проблемы на ранней стадии.

Известные ограничения и рекомендации по правилам выражений SQL

Неоднозначные ссылки на столбцы и затенение столбцов

• Проблема. Если столбец отображается как во внешнем запросе, так и во вложенном запросе (или в разных частях запроса) с одинаковым именем, Spark SQL может не решить, какой столбец следует использовать. Эта проблема приводит к логическим ошибкам или неправильному выполнению запроса. Эта проблема может возникнуть во вложенных запросах, вложенных запросах или соединениях, что приводит к неоднозначности или затенения.

• Неоднозначность. Возникает, когда имя столбца присутствует как во внешнем запросе, так и во вложенном запросе без четкой квалификации, что приводит к тому, что Spark SQL не уверен в том, на какой столбец следует ссылаться.

• Затенение. Указывает, когда столбец во внешнем запросе "переопределяется" или "затеняется" тем же столбцом во вложенном запросе, в результате чего внешняя ссылка игнорируется.

  Пример выражения:

  distance_km > 
  ( 
  SELECT min(distance_km) 
  FROM Tripdata t  
  WHERE t.payment_type = payment_type -- ambiguous outer reference  
  )
  

• Проблема. Неквалифицированный payment_type разрешается в ближайший область, имеющий столбец с таким именем, то есть внутренний t.payment_type, а не payment_type внешней строки. Это преобразует предикат в t.payment_type = t.payment_type (всегда TRUE), поэтому вложенный запрос становится глобальным мином, а не группой min.

• Решение. Чтобы устранить эту неоднозначность и избежать затенения столбцов, переименуйте внутренний столбец во вложенном запросе, гарантируя, что payment_type внешнего запроса остается однозначным.

Исправленное выражение:

  distance_km > 
  ( 
  SELECT min(u.distance_km) 
  FROM ( 
  SELECT distance_km, payment_type AS pt 
  FROM Tripdata 
  ) u 
   WHERE u.pt = payment_type   -- this `payment_type` now binds to OUTER row 
  )

• Во вложенном запросе столбец payment_type псевдонимируется как pt (то есть payment_type AS pt), а в условии используется you.pt.
• Во внешнем запросе исходный payment_type теперь можно четко ссылаться, и Spark SQL правильно разрешает его как внешний payment_type.

Операции с окном (учет производительности)

• Операции с окном, такие как ROW_NUMBER() и RANK(), могут быть дорогостоящими, особенно для больших наборов данных. Используйте их разумно и протестируйте производительность в небольших наборах данных, прежде чем применять их в большом масштабе. Рассмотрите возможность использования PARTITION BY для сокращения область данных.

Экранирование имени столбца в Spark SQL

• Если имена столбцов содержат специальные символы (например, пробелы, дефисы или другие символы, не являющиеся буквенно-цифровыми), их необходимо экранировать с помощью обратных знаков.
• Пример, если имя столбца — order-id, а правило должно быть больше 10.
• Неправильное выражение: order-id > 10
• Правильное выражение: `order-id`> 10

Ссылка на имя ресурса данных в выражениях

При ссылке на ресурс данных в выражениях SQL необходимо соблюдать определенные правила очистки. Имя исходного ресурса данных не требуется обновлять, но имя ресурса данных, на которое ссылается в выражениях SQL, должно быть очищено в соответствии со следующими критериями:

Если имя ресурса данных уже соответствует этим рекомендациям (то есть оно не содержит никаких специальных символов, символов подчеркивания в начале и нижнем значении и находится в пределах 64 символов), его можно использовать в выражениях SQL без каких-либо изменений.

Очистка имени набора данных

Выполните следующие действия, чтобы убедиться, что имя набора данных является допустимым для выражений SQL:

1. Удалить специальные символы. Удалите все символы, кроме букв, цифр и символов подчеркивания.
2. Обрезка подчеркивания. Удалите все начальные или конечные символы подчеркивания.
3. Усечение. Если итоговое имя превышает 64 символа, усечение его в соответствии с ограничением в 64 символов.

Пример: имя ресурса данных f07d724d-82c9-4c75-97c4-c5baf2cd12a4.parquet

1. Удаление специальных символов: f07d724d82c94c7597c4c5baf2cd12a4parquet
2. Обрезка подчеркивания: (В этом случае Н/Д, так как нет начальных или конечных подчеркивания.)
3. Усечение: итоговое имя имеет длину 54 символа, что ниже 64-символьного ограничения.

Окончательное справочное имя SQL: f07d724d82c94c7597c4c5baf2cd12a4parquet

Соединения не поддерживаются

Пользовательские правила SQL в Качество данных Microsoft Purview не поддерживают соединения. Правила должны работать с одним набором данных. Вы не можете объединить несколько таблиц или наборов данных при написании этих настраиваемых правил.

Неподдерживаемые операции SQL (DML, DCL и вредоносные sql)

Пользовательские правила SQL не поддерживают операции языка обработки данных (DML) или языка управления данными (DCL), такие как INSERT, UPDATE, DELETE, GRANT и другие вредоносные операции SQL, такие как TRUNCATE, DROP и ALTER. Эти операции не поддерживаются, так как они изменяют данные или состояние базы данных.

Автоматически созданные правила с помощью ИИ

Автоматизированное создание правил с помощью ИИ для измерения качества данных использует методы искусственного интеллекта (ИИ) для автоматического создания правил для оценки и улучшения качества данных. Автоматически созданные правила зависят от содержимого. Большинство общих правил создаются автоматически, поэтому вам не нужно прилагать много усилий для создания пользовательских правил.

Чтобы просмотреть и применить автоматически созданные правила, выполните следующие действия:

1. На вкладке Правила ресурса данных выберите Предложить правила.

2. Просмотрите список предлагаемых правил.

   

3. Выберите правила из списка предлагаемых правил для применения к ресурсу данных.

   

Ограничение

Для проверки качества данных можно применить не более 200 правил качества данных для каждого ресурса данных. Проверка завершается ошибкой, если для одного ресурса активно более 200 правил. Если необходимо определить более 200 правил для ресурса данных, они могут это сделать, но только до 200 правил могут находиться в активном состоянии (ON) в любой момент времени.

Чтобы обойти это ограничение, выполните приведенные ниже действия.

• Добавьте один и тот же ресурс данных в несколько продуктов данных, чтобы распределить между ними правила.
• Активируйте и деактивируйте правила по мере необходимости, чтобы одновременно было активно не более 200 правил.

Дальнейшие действия

1. Настройте и запустите проверку качества данных в продукте данных, чтобы оценить качество всех поддерживаемых ресурсов в продукте данных.
2. Просмотрите результаты сканирования , чтобы оценить текущее качество данных продукта данных.