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

Question

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

Очень простой пример:

 Customer Cash% 
 A        50 
 B        25 
 C        30

Правило: расскажите всем клиентам, которые имеют <50% наличными. </p>

Я не особо привязан к конкретному инструменту или идее, однако наши знания - это C #, XML и Sql Server. Все наши данные находятся в базах данных SQL SERVER.

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

Приветствие.

РЕДАКТИРОВАТЬ: я должен сказать, что это может стать сложным, в результате чего я хотел бы проверить кучу таблиц и их данных по «модели», чтобы увидеть, соответствует ли конкретный объект правилам. Например, может быть клиент «Модели», и вы хотите проверить, сколько клиентов не соблюдает правила модели, например, Наличные, последний платеж, гражданство и т. Д.

РЕДАКТИРОВАТЬ: Исходя из нескольких комментариев, я полностью понимаю, что "недействительные" данные должны быть предотвращены в первую очередь. Мой сценарий связан с тем фактом, что данные могут быть совершенно достоверными, однако они могут не следовать «домашним правилам», тогда вещи, которые не следуют правилам, могут быть оправданы.

Answer 1

Поскольку это еще не упомянуто, я бы посоветовал вам взглянуть на возможности интеллектуального анализа данных SQLServer . Одним из них является возможность выделить исключения в ваших данных.

Ознакомьтесь с этим видеоуроком по выделению исключений , чтобы начать работу.

Answer 2

Создайте скрипт операторов SQL, в котором один оператор равен одному правилу. В вашем примере ваше утверждение может быть:

INSERT INTO EXCEPTION 
   (RULE_NAME, DETAIL) 
VALUES 
("CASH_LEVEL_LOW", SELECT CUSTOMER_ID FROM CUSTOMER WHERE CUSTOMER.CASH < 50); 

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

Answer 3

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

Answer 4

Мне бы очень хотелось, чтобы система была динамичной, то есть довольно легко определить новые правила.

У вас уже есть такая система; это ваша база данных. В частности, проверочные ограничения служат для предотвращения ввода неверных данных вообще.

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

Вот пример: создать представление low_on_cash как select * из таблицы, где «Cash%» <50; </p>

В клиенте вы бы выдавали ошибку, если "select count (*) from low_on_cash" не вернул 0;

Если вы установили соглашение, согласно которому все такие представления были названы с префиксом, например, «error_report», ваш клиент мог бы выбрать все такие имена представлений из systables для базы данных в одном запросе, а затем повторить этот список, вызвав "select count(*) from " + viewname; регистрация ошибки для любого, который возвратил больше нуля строк.

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

Дополнительным преимуществом является то, что добавление любого механизма правил потребовало бы изучения его предметно-ориентированного языка для написания правил, обучения новых сотрудников на нем, и даже в этом случае неизбежно возникли бы сложные случаи, которые правила не могли бы охватить легко. Ваши кодировщики уже знают SQL, и он основан на 17-летнем стандарте ANSI, основанном на 20 более ранних годах использования, поэтому большинство ключевых случаев были исключены из языка.

Answer 5

Лучше всего было бы создать план обслуживания в SQL Server с одним шагом в плане для каждого правила. Каждое правило будет проверять данные и вставлять их в таблицу исключений, если обнаружит какие-либо несоответствующие правила. Это позволит вам использовать инструменты, предоставляемые SQL Server, и поддерживать довольно простое обслуживание самих правил (добавление, удаление и изменение порядка).