среда, 27 марта 2013 г.

Классификаторы. Системные требования

При проектировании различных информационных систем (ERP), витрин данных (Data Mart), хранилищ данных (Data Warehouse) возникает необходимость в описании требований к одному из относительно простых базовых информационных компонент – к классификаторам.
Объект Классификатор и связанное с ним действие Классифицирование, являются фундаментальными понятиями философии и математики. Текущие задачи IT заставляют искать и находить утилитарные подходы к их использованию, описывая основные принципы и понятия «Теории классификации» возможно более кратким и доступным языком.  В качестве конструктивного способа решения этой проблемы воспользуемся следующим подходом – построим необходимые определения объектов и методов классификации через описание их функционального назначения. При таком подходе к решению проблемы придется подготовить описание ее аспектов с различных сторон.
В современной литературе по теории классификации, логике, теории множеств  и общей теории систем, как правило, требования к классификации относятся к системной методологии и группируются следующим образом:




Приведенные требования относятся для классификации четких множеств объектов. Классификация состоит в отнесении объектов к непересекающимся подмножествам или классам эквивалентности. В некоторых процессах классификации возможно отнесение объектов к классам толерантности, которые представляют различные формы нечеткой классификации (кластеризация, диагностика, нечеткая типизация), но эти случаи не являются предметом данного рассмотрения.
 

Системные требования

Невыполнение любого из перечисленных требований приводит к неправильной (ошибочной) классификации.
  • Нормализация. Система единых корпоративных классификаторов хранится в нормализованной базе данных и является ее составной частью (1НФ, 2НФ, 3НФ, НФБК).
  • Уникальность. Каждая классификация объектов проводится только по общему основанию. Основание классификации – это признак, который дает возможность разделить всю совокупность классифицируемых объектов на подклассы этой совокупности.
  • Полнота. Количество классифицируемых объектов должно быть равно объему всего классифицируемого класса. Если объект относится к классу и задано основание классификации, то не существует объектов в этом классе, которые не могут быть классифицированы.
  • Непротиворечивость. Видовые понятия классификации должны взаимно исключать друг друга. Принципиально не может быть объектов, которые относятся одновременно к нескольким подклассам. Каждый классифицируемый объект может попасть только в один подкласс.
  • Непрерывность. Разбиение на подклассы должно быть непрерывным. Логическое разбиение на подклассы (видовые понятия) должно находиться на одном смысловом уровне классификации.
 
Классификатор - систематизированный перечень объектов, каждому из которых присвоен определенный код.
Основание классификации – наименование классификатора объектов, содержит систематизированный перечень объектов, видовых понятий.
 

Применение системных требований

1.      Рассмотрим простейший пример применения системных требований. Предположим, что необходимо создание классификатора «Цвет». Выберем за основу классификатора всем известные «Семь цветов радуги».
При отсутствии других информационных объектов, кроме классификатора «Цвет», таблица находится в Нормальной Форме Бойса-Кодда. Остальные системные требования относятся к семантическому (смысловому, содержательному) значению строк таблицы. Требования уникальности и полноты выполнены автоматически, поскольку отсутствует множество классифицируемых объектов. Требования непротиворечивости и непрерывности выполнены в силу физической сущности видовых понятий классификатора. Строки составлены так, что каждое видовое понятие классификатора «Цвет» (например, «Красный») соответствует определенному диапазону длин волн света для видимой части спектра.

2.      Немного усложним описание. Предположим, что имеется примитивная информационная система учета объектов, а классификатор «Цвет» используется для определения характеристики объекта.
С выполнением требования нормализации все обстоит благополучно, если среди объектов не будет «фазанов», т.е. весь объект окрашен в один цвет. Фазан своим многоцветием будет нарушать требование непротиворечивости. Что делать, если нужно регистрировать Фазанов? Следует изменить схему базы данных, но это будет уже другая информационная система.
В новой системе допускается регистрировать «фазанов», но у «Объекта» нет классификатора «Цвет». Классификатор «Цвет» теперь связан с таблицей «Цвет_Объекта». Если так мешают «стрелочки» и «квадратики», то можно ли стереть ненужное? Можно стереть, удалить вместе с требованием нормализации. Больше не будем рассматривать другие нюансы структур данных, вернемся к системному анализу классификатора «Цвет».
 
Предположим, что объекты могут быть белого или черного цвета. В таблицу «Цвет» достаточно добавить две строки: 0 – Белый; 8 – Черный. Однако будет нарушено требование непрерывности. Цвета «белый» и «черный» имеют другой смысловой уровень. Нет такой длины волны спектра, которая бы соответствовала этим цветам. Что делать? Менять смысловой уровень классификатора.
Известно, что все цвета на мониторе получаются при смешении Красного, Зеленого и Синего цветов (Red, Green, Blue - RGB). Каждый возможный цвет обозначается тремя шестнадцатеричными числами, каждое число от HEX(00) до HEX(FF). Белый цвет – RGB(FF,FF,FF), черный цвет – RGB(00,00,00), желтый цвет – RGB(FF,FF,00) смесь красного и зеленого цветов. Казалось бы, что технология RGB решила все проблемы с классификатором «Цвет». Однако появились новые проблемы. Наличие более 16 миллионов оттенков цветов затрудняют практическое использование классификатора, удовлетворяющего требованиям полноты, для описанной выше информационной системы. У каждого оттенка нет своего названия, а сами названия могут не быть общеупотребительными.  Понятно, что корпоративная система справочников и классификатором должна соответствовать многоуровневой модели данных, поддерживать механизм выборок или проекций.

3.      Немного усложним предыдущее описание. Предположим, что осуществляется построение CRM системы для мебельной фабрики, выпускающей двери.
 
Объект – это двери и другие сопутствующие изделия. Цвет объектов может быть, например - Дуб, Бук, Ясень, Венге, Вишня, Зебрано, Белый глянец. Цвет изделия нужен при заказах Клиентами через WEB магазин.
 
В этом примере при формировании корпоративного справочника «Цвет» мы понимаем, что столкнулись с некоторыми теоретическими проблемами. Например, «Зебрано», «Белый глянец» это вообще не чистый цвет, им нет соответствия в RGB. Что делать? Менять смысловой уровень, менять технологии пользовательского интерфейса по работе с информационной системой. В данном случае очевидно, что это не классификатор "Цвет", а классификатор "Фасад". Это совсем другой классификатор, в котором вместо кода RGB целесообразно использовать визуальную картинку части поверхности.

4.      Закончим на этом месте проведение анализа применения системных требований к классификатору «Цвет». Много других, не менее важных общих вопросов, связанных с классификаторами и справочниками, будут рассмотрены позднее. Для комплексного решения вопросов по формированию единых корпоративных справочников и классификаторов целесообразно использовать специализированные технологические системы MDM (Master Data Management).

1 комментарий:

  1. Пример использования классификатора "Цвет" может быть омрачен следующим обстоятельством. Можно разработать прекрасную систему классификаторов, применять классификаторы, удовлетворяющие всем требованиям теории, но все будет напрасно, если субъектом процедуры классифицирования окажется дальтоник.
    Это замечание подчеркивает необходимость серьезного отношения к обсуждаемой теме.

    ОтветитьУдалить