Е. З. Зиндер
Корпорация LVS, тел.(095)330-15-37 , Российская Ассоциация пользователей ORACLE , ez@lvs.msk.su
- 6.1. Бизнес-правила на основе анализа информационных требований
- 6.2. Решение N2 ("Список c контролем")
- 6.3. Решение N3 ("Правильная классификация + нормализация")
Распространение инструментов класса Upper-CASE усилило интерес к проблемам, методам и качеству концептуального и логического проектирования баз данных (БД). Вместе с тем, критерии качества часто понимаются упрощенно, сквозной анализ и оценка проектных вариантов не рассматриваются. (Заметим, что элементы такого анализа обосновывали пользу употребления отношений высокой степени нормализации - 3NF, 4NF.) Сквозной сравнительный анализ вариантов связывает проектные решения со всеми последствиями этих решений, как бы они не были отдалены в цепочке этапов жизненного цикла разрабатываемой автоматизированной системы (АС): логическое проектирование БД, разработка прикладных программ и т.д. вплоть до адаптации к будущим изменениям требований. Использование сквозного сравнительного анализа - один из предметов этой статьи.
1. Введение
Существует мнение, что деление проектирования на этапы, обособленные друг от друга и методически, и инструментально, делает сквозной анализ решений мало полезным. За последние 25 лет в данной области проделана огромная работа по обеспечению независимости решений, принимаемых на разных этапах. Этому, например, отвечает обособление групп операторов в языках описания данных, каждая из которых служит описанию своего слоя модели БД: слоя логической схемы, слоя внешних представлений данных и др. Благодаря этим усилиям проекты БД и АС в целом получают приемлемые гибкость и стоимость сопровождения.
Однако, качество решений, принятых на первых этапах проектирования, существенно определяет качество результатов, получаемых на последующих этапах, причем в большинстве случаев решения необратимы в следующем смысле: обособленность инструментов последующих этапов не позволяет устранять недостатки решений предыдущих или приводит к потере целостности моделей БД.
Рассмотрение процедур сквозного анализа и сравнительной оценки проектных вариантов - весьма широкое направление общей методологии проектирования. Ниже примером служит только один вид проектных решений, соответствующих проблем, вариантов и оценок.
Здесь рассматриваются аспекты качества, определяемые на базисном уровне принятия решений - при определении понятий и их признаков, моделирующих предметную область (ПрО) заказчика, включая классификацию используемых понятий по значениям их признаков. Показывается, что корректная классификация, однозначно связанная с корректным определением состава признаков понятий, всегда должна закладываться в основу проекта. Корректные классификации значений признаков и способы их практического использования - другой предмет статьи.
Переходя от логической терминологии к инфологической: рассматривается корректность используемой или выбираемой системы классификации и кодирования, зависящий от этого выбора состав атрибутов объектов, множеств их допустимых значений (доменов), правил и процедур контроля целостности. Описывается то, как принимаемые в этой области решения определяют не только структуру БД, но также и устойчивость приложений (при изменениях в информационных требованиях), и удобство работы пользователя. Демонстрируется подход к оценке проектных вариантов как к одной из задач аналитика-проектировщика.
2. Обычные подходы
Традиционно основное внимание уделялось определению структуры БД на основе набора именованных атрибутов и зависимостей между ними (функциональных, многозначных). Последнее время активно рассматривается "встраивание" в БД ограничений целостности, задаваемых т.н. бизнес-правилами (business rules).
В случаях, когда рассматриваются вопросы классификаций объектов (например, на уровне сущностей ER-модели), состав атрибутов обычно считается заданным или получаемым непосредственно из форм документов АС и протоколов интервью с представителями заказчика. При этом качество таких атрибутов редко подвергается тщательному анализу и оценке последствий их использования.
Если же рассматривается выбор обобщенной модели ПрО, вводятся, чаще всего "из разумных соображений", некие обобщенные атрибуты. При этом оценка принимаемых решений ограничивается рассуждениями типа: "сопровождение будущего развития системы упростится, хотя программирование и будет труднее и менее очевидным, чем при классически спроектированной БД".
Отметим существование отдельных указаний на необходимость учитывать эту сторону анализа в проектировании. Так, Р. Баркер в глоссарии к своей серии книг по CASE-Методу (CASE*Method) определяет атрибут как "...свойство, позволяющее квалифицировать, идентифицировать, классифицировать, измерять сущность..." (выделение мое - Е.З.). Тем не менее, практически далее таких определений дело не идет. В то же время, само требование к атрибуту позволять классифицировать сущность может дать аналитику конструктивное средство анализа, если рассматривать корректные классификации, удовлетворяющие соответствующим логическим правилам.*)
3. Способ изложения и используемые примеры
Изложение ведется в форме разбора типичного случая маленького фрагмента БД. Разбирается фрагмент, в котором схема БД и процедуры работы с соответствующими данными сильно зависят от качества используемых классификаторов. Разработчик может улучшить решение, уточняя предложенную ему классификацию значений признаков, заложенную в существующих кодификаторах, причем без радикальной переделки последних.
Описываются варианты решения начиная с тривиального, но неудачного, на наш взгляд, варианта. Детальным образом сравниваются два центральных варианта. Затем обсуждаются улучшенный вариант и возможности использования искусственных приемов. В конце кратко рассматриваются два варианта для еще одного аналогичного случая.
Показывается, что одного "правильного" или всегда лучшего результата не существует. Предлагается способ анализа, позволяющий получить оценить варианты, предпочтительные в тех или иных ситуациях.
Примеры предельно просты, а сравнительный анализ требует рассмотрения способов программирования запросов и контроля целостности, поэтому примеры описаны сразу на уровне SQL. Поскольку главным является выбор набора атрибутов и их значений, модель более высокого уровня ничего дополнительного не дала бы, и дальнейшее изложение ведется в терминах таблиц, строк, столбцов и полей, а не сущностей (например, ER-модели) и т.п.
Описываемая проблема имеет место при использовании любой модели данных, включая модели ADABAS, UniVerse, и др. Если имеются средства работы со списками или вложенными таблицами, упрощается только запись некоторых сравнений. Все же, ситуации наиболее громоздких решений характерны для реляционной модели, почему она далее и подразумевается. В качестве примеров используются минимальные фрагменты текстов. Они не подразумевают конкретную СУБД, но очевидным образом допрограммируются на диалекте SQL с процедурными расширениями СУБД ORACLE.
4. Начальная ситуация разработчика
Рассмотрим ситуацию, когда разработчику поступили требования на создание БД и экранных форм доступа к данным исходя из некоторого описания и приложенных распечаток существовавших ранее файлов.
Предположим, в БД необходимо поддерживать сведения о людях, организациях и связях между ними. Такого рода сведения могут быть использованы в управлении кадрами, при описании агентов и клиентов в коммерческой деятельности, в базе данных профилактической работы участкового инспектора и других реальных случаях.
При описании связи требуется указать качественные характеристики связи человека ("персоны") с некоей фирмой. Пусть в характеристики связи входит, связана ли персона с фирмой каким-то образом и каким (какими) именно из перечисленных в кодификаторе, поступившем разработчику БД?
У многих возникнут справедливые замечания к качеству классификации, заложенной в кодификаторе TVS. Учтем их, но несколько позже. Существенно, что кодификаторы подобного качества поступают к разработчикам достаточно часто.
Кодификатор признака "ВИД СВЯЗИ" (в БД ему соответствует таблица TVS)
| Код (KVS) | Наименование (VS) |
|
1 2 3 4 5 6 7 |
работает
работал по супругу по родственникам владелец совладелец акционер |
Здесь признак "вид связи" имеет обобщенный характер. Разработчик сразу фиксирует, что одна персона может одновременно и работать в некоей фирме, и быть ее акционером, и, может быть, иметь другой признак (признаки) связи с фирмой.
5. Пример базы данных для первого решения
Разработчик определяет в БД следующие таблицы: P - "Персона", строка соответствует одному "физическому лицу", F - "Фирма", строка соответствует одному "юридическому лицу", S1 - "Связь", строка соответствует ...
Тут часто принимается решение, по которому одна строка таблицы S1 хранит одно значение признака "Вид связи". Рациональность этого решения обсуждается далее.
ОПИСАНИЕ ТАБЛИЦ ПРИМЕРА ДЛЯ РЕШЕНИЯ N1
create table P (KP varchar primary key, /* ключ персоны */ ...); create table F (KF varchar primary key, /* ключ фирмы */ ...); create table S1 (KP varchar references P(KP), /* ключ персоны */ KF varchar references F(KF), /* ключ фирмы */ VS varchar references TVS (VS) /* вид связи*/) primary key (KP,KF,VS); create table TVS (KVS varchar primary key, /* код вида связи */ VS varchar unique not null /* вид связи: название */);
Для простоты изложения в таблицах P и F обрабатывается только некий "ключ" без задания фамилий, адресов, названий и т.п.
Рисунок 1.
Ошибочные данные, которые могут быть введены в БД при Решении N1.
При таком решении для одной строки таблицы P и одной строки таблицы F может существовать несколько строк таблицы S1, каждая из которых содержит свое значение вида связи в столбце VS (для наглядности будем представлять эти значения наименованиями признака, а не кодами).
Также, в каждой из этих строк S1 содержатся ключи соответствующих строк P (в столбце KP) и F (в столбце KF). Первичным ключем S1 объявлено объединение столбцов KP,KF,VS. Ожидается, что благодаря этому обеспечивается некоторый уровень "логического контроля" совокупности значений вида связи VS у одной пары "Персона" - "Фирма". Назовем это Решением N1 - "Список без дублей".
Очевидно, что при указанном контроле возможно появление связей, в которых "Персона" одновременно и владелец фирмы, и ее совладелец, и акционер, что или неверно, или явно избыточно при тривиальной зависимости одних значений VS от других.
Поэтому указанный вариант непосредственно в описанном виде практически не применяется. Вернемся к более детальному анализу предметной области.
6. Дальнейший анализ. Получение второго и третьего решений
6.1. Бизнес-правила на основе анализа информационных требований
При детальном анализе нужно, как обычно, исчерпывающим образом описать содержательные правила решений о допустимых состояниях персоны, фирмы и связи между ними, принятые в рассматриваемой области. На них и оценках стоимости их реализации в разных проектных вариантах будет производиться выбор структуры БД.
Пусть эти т.н. бизнес-правила таковы:
п1) при включении связи она создается обязательно с описанием вида связи,
п2) если персона есть владелец фирмы, то не должен использоваться ни вид связи "совладелец", ни вид связи "акционер",
п3) если персона есть совладелец фирмы, то не должен использоваться ни вид связи "владелец", ни вид связи "акционер",
п4) при любых значениях вида связи из списка "владелец", "совладелец", "акционер", "по супругу", "по родственникам" персона может иметь вид связи либо "работает", либо "работал", либо ни того, ни другого,
п5) при любых значениях вида связи из списка "владелец", "совладелец", "акционер", "работает", "работал" персона может иметь вид связи либо "по супругу", либо "по родственникам" , либо ни того, ни другого (предполагается, что связь "по супругу" имеет как бы более высокий приоритет, чем "по родственникам"),
п6) при удалении непустых сведений о всех видах связи между конкретными персоной и фирмой никакие данные о связи между ними в таблице S содержаться не должны.
(Конечно, это не все правила. Не рассматривается, например, ограничение, по которому у фирмы не может быть двух разных владельцев. Поддержка этого ограничения почти одинаково добавляется ко всем описываемым вариантам и потому не влияет на качество примеров. Они - всего лишь примеры!)
Реализация этих правил может производиться и на практике производится на основе одного из следующих принципиально разных решений.
6.2. Решение N2 ("Список c контролем")
В качестве основы берется Решение N1 с сохранением использования обобщенного признака "вид связи". Для выполнения ограничений целостности, определяемых бизнес-правилами, списковое представление видов связей дополняется набором действий по контролю целостности, которые могут быть реализованы в процедурах контроля в приложениях (что не очень хорошо), в триггерах и хранимых процедурах БД (что лучше), но реализуют соответствующие правилам п1) - п6) действия при включении, исключении и корректировке данных о связи персоны и фирмы.
Рисунок 2
. Правильные данные, которые могут быть введены
в БД при решении N2 ("Список с контролем").
При таком решении содержание таблиц примера рис. 1 после исправления неправильных данных и добавления в таблицу S1 данных по другим персонам/фирмам может иметь вид, приведенный на рис. 2.
Это решение отличается сложным осуществлением процедур контроля вводимых и корректируемых данных, усложненностью многих запросов. Тем не менее, встречаются его использования на практике. Поэтому именно с него мы начнем детальный сравнительный анализ.
Для иллюстрации опишем часть процедур. Не будем описывать этот контроль с прямым использованием приведенного ранее кодификатора TVS и отдельных бизнес-правил, это будет слишком громоздко и искусственно. Более естественно отразить часть бизнес-правил в виде значений в специально добавленном столбце NK в таблице TVS.
|
|
|
|
|---|---|---|
|
2 |
работал |
1 |
|
4 |
по родственникам |
2 |
|
6 7 |
совладелец акционер |
3 3 |
Эти значения будут фиксировать разбиение видов связей на независимые друг от друга, "ортогональные" классы с номером класса, записанном в NK (независимость означает, что приписывание одной паре Фирма, Персона вида связи из одного класса никак не ограничивает возможность приписывания ей вида связи из другого класса). Выделяются три "ортогональных" класса связи:
NK = 1 - связь по работе, NK = 2 - связь по родственникам, NK = 3 - связь по собственности.
Заметим, что эти номера классов не только облегчат программирование, но они же однозначно связаны с корректной классификацией связей на основе модифицированного кодификатора, таблицы TVS123.
ОПИСАНИЕ ТАБЛИЦ ПРИМЕРА ДЛЯ РЕШЕНИЯ 2 (только отличия)
create table TVS123 (KVS varchar primary key, /* код вида связи */ VS varchar unique not null, /* вид связи: название */ NK varchar not null /* номер - код - классификации */);
Тогда контроль ввода новой связи может основываться на следующем фрагменте процедуры (здесь и далее переменные, имя которых оканчивается на "_W", являются рабочими (локальными или глобальными) переменными процедур контроля, переменные, начинающиеся с префикса "NEW_", хранят соответствующие остальной части имени новые значения, включаемые или корректирующие таблицу связей фирм и персон):
select NK into NK_W from TVS123
where VS = NEW_VS_W;
FLAG_W :=0; select 1 into
FLAG_W from dual where
exist (select * from S1 where
KP = NEW_KP_W and
KF = NEW_KF_W and
VS in (select B.VS from TVS123 B
where B.NK = NK_W) );
if FLAG_W > 0 then /* сообщение
о том, что включаемый вид связи
противоречит ранее включенным
*/ end if;
Этот контроль не столько сложен по описанию, сколько по выполнению. (Текст выглядел бы сложнее, если бы содержал и контроль наличия включаемого вида связи NEW_VS_W в кодификаторе TVS123.) Здесь также не разбирается контроль на допустимость корректировки вида связи VS в S1. Этот контроль имеет ту же оценку сложности, что и контроль допустимости включения.
Далее, пользователю, формирующему нерегламентированный запрос (например, с помощью любого инструмента класса QBE или BROWSER), или программисту, разрабатывающему конкретное приложение, будет сложно описывать запросы такого типа: "Найти те фирмы, владельцы или совладельцы которых работают в этих же фирмах".
Вот возможный текст такого запроса:
select KF from S1 A
where A.VS = "владелец"
or A.VS = "совладелец"
and A.KP in
(select KP from S1 B
where A.KP = B.KP
and A.KF = B.KF
and B.VS = "работает");
Такие запросы будут и обрабатываться существенно дольше, чем хотелось бы. (Это - простейший по чтению текст. Существуют более красивые, но менее очевидные решения, по сути же они - одной сложности.)
Наконец, пользователь для одной конкретной пары "персона-фирма" будет работать на экране со списком видов связей переменной, хотя и небольшой, длины, с произвольным порядком содержательных компонентов. Считается, что это сложнее и утомительней работы с фиксированным расположением, на основе которого может возникать динамический стереотип действий оператора. Также считается, что при работе со списками произвольного состава и порядка процент ошибок оператора выше.
Можно сказать, что решение N2 работает с "не совсем атомарным" атрибутом "вид связи" (требование атомарности - базовое в нормализованных отношениях). "Не совсем атомарность" проявляется в том, что одна пара разных значений вида связи (например, "работал, акционер") может характеризовать одну связь, а другая (например, "владелец, совладелец") - не может. Это значит, что в таком виде связи есть "еще что-то" кроме характеристики связи, следовательно, содержательно он не атомарен, и, следовательно, S1 не совсем нормализована!
Однако, это решение обладает и преимуществами, описываемыми в дальнейшем.
6.3. Решение N3 ("Правильная классификация + нормализация")
На основе правил п1) - п6) проводится не только включение в кодификатор и таблицу TVS привязки значений к классам, но, в полном соответствии с определением атрибута для возможности осуществления корректной классификации вида связи по правилам классификации, выделяются три разных, независимых друг от друга, "ортогональных" признака вида связи: VSRA - вид связи по работе, VSRO - вид связи по родственникам, VSSO - вид связи по собственности. Эти признаки используются как самостоятельные основания классификации вида связи и получается три кодификатора:
|
|
|
|---|---|
|
2 |
работал |
|
|
|
|---|---|
|
4 |
по родственникам |
|
|
|
|---|---|
|
6 7 |
совладелец акционер |
Часто нетехнологично разбивать одну таблицу кодификатора на несколько, включающих соответствующие подмножества строк. В этом случае полезно использовать как общий прием добавление в таблицу исходного кодификатора столбца, в котором отмечается разделение на нужные подмножества строк. Такой прием оправдан, например, когда кодификатор велик, а его содержание поставляется извне. Примером такого разделения является описанная выше таблица TVS123.
Однако, суть Решения N3 не зависит от выбора способа разделения кодификатора на корректные классификации, а кодификаторы TVSRA, TVSRO, TVSSO могут быть созданы как представления (VIEW) на таблице TVS123.
(Часто требуется вводить такие дополнительные разбиения кодификатора, в которых одна строка входит более чем в одну классификацию. В этих случаях можно добавлять несколько столбцов с отметками о принадлежности соответствующим классификациям. Кроме того, дополнительный столбец будет полезен, если полезно выводить пользователю строки кодификатора в полезном именно ему порядке.)
После такого исправления содержательной классификации становится очевидным переход к использованию в качестве средства реализации связи таблицы S3, которая кроме KP и KF содержит столбцы для действительно атомарных значений:
VSRA - вид связи по работе,
VSRO - вид связи по родственникам,
VSSO - вид связи по собственности.
ОПИСАНИЕ ТАБЛИЦ ПРИМЕРА ДЛЯ РЕШЕНИЯ 3
(только отличия в основной таблице; таблицы или представления TVSRA, TVSRO, TVSSO имеют очевидную структуру, аналогичную TVS,
и не описываются)
create table S3 (KP varchar references P(KP), /* ключ персоны */ KF varchar references F(KF), /* ключ фирмы */ VSRA varchar references TVSRA(VSRA), /*вид связи по работе*/ VSRO varchar references TVSRO(VSRO), /*вид связи по родственникам*/ VSSO varchar references TVSSO(VSSO) /*вид связи по собственности*/) primary key (KP,KF);
При таком решении пример на рис. 1 после исправления неправильных данных и добавления в таблицу S3 данных по другим персонам/фирмам может иметь вид, приведенный на рис. 3.
Регулярные методы проектирования БД в данном случае опираются на очевидные функциональные зависимости:
(KP,KF) -> VSRA, (KP,KF) -> VSRO, (KP,KF) -> VSSO.
Первичным ключем S является пара столбцов (KP,KF), и Решение N3 со схемой S3, приведенной на рис. 3, становится, как может показаться, единственно правильным решением!
Рисунок 3.
Данные, кторые могут быть введены в БД при Решении N3 ("Правильная
классификация")
Это решение использует простые и традиционные при классическом проектировании БД способы контроля и вводимых, и корректируемых данных. Далее, пользователю и программисту будет просто описывать запросы типа: "Найти те фирмы, владельцы или совладельцы которых работают в этих же фирмах", и эти запросы будут выполняться быстро:
select KF from S3
where VSSO = "владелец" or
VSSO = "совладелец" and
VSRA = "работает");
На экране пользователю будет просто формулировать запросы указанного типа , поскольку в экранных формах работа и по запросам, и по вводу идет в трех фиксированных поименованных полях экрана для одного экземпляра связи, например (фрагмент экрана):
Однако, это решение в некоторых отношениях и ситуациях может оказаться гораздо хуже, чем Решение N2!
7. Параллельное сравнение Решений N2 и N3
Проведем сравнительное описание этих решений по типам выполняемых действий.
Отметим еще раз, что контроль допустимых значений вида связи в Решении N2 предполагается основывать не на таблице TVS, и не на трех таблицах TVSRA, TVSRO, TVSSO, а на таблице TVS123 со столбцом, хранящим номера непересекающихся подмножеств значений для "ортогональных" признаков. Благодаря этому, контроли будут основаны не на значениях кодов видов связи, которые могут быть в любой момент по крайней мере дополнены, но будут использовать принадлежность хранимого и вводимого видов связи к более стабильным во времени описателям - номерам классов в кодификаторе TVS123.
Заметим, что из последнего следует:
- правильная классификация хранимых признаков нужна не только в Решении N3, но и в Решении N2,
- в рассмотрение введен еще один фактор: возможные изменения в системе в ходе ее эксплуатации.
Теперь само сравнение. В приводимой ниже таблице рассматриваются преимущества и недостатки Решений N2 и N3 для набора возможных операций над БД, точнее - над таблицей связи между фирмами и персонами. В число операций включены как традиционно рассматриваемые операции над строками таблицы, так и операции по реконструкции БД при развитии требований к системе.
Главный недостаток Решения N3 указан в П.7, связан с возможным появлением новых признаков, нарушающих уточнение классификации, сделанное выше в T123, и зависит от частоты таких появлений. При значительной частоте появлений новых признаков постоянные переделки могут стать "ночным кошмаром"!
Проектировщик-аналитик может воспользоваться таблицей для уточнения сравнительного анализа. Для этого он должен добавить к таблице еще два столбца, в которых проставить свою оценку частоты каждой операции и удельной стоимости каждого преимущества и недостатка. Реалистично рассматривать относительные стоимости в баллах или иных относительных единицах. Баланс оценок преимуществ и недостатков может дать основания для более уверенного выбора решения.
8. Переход к тщательному анализу. Получение более устойчивого Решения N4
Как указывалось, добавление новых значений видов связи, только дополняющих выделенные классы без их переразметки или без дополнительных классов значений в T123, не выявляет недостатков Решения N3. Так, может добавиться значение "работает по совместительству", которое войдет в подмножество с NK = 1, и при Решении N3 переделки не потребуются, так как это значение будет значением имеющегося признака VSRA.
Приведем изменения в правилах, которые повлекут появление новых признаков.
Предположим, потребовалось:
п7) учитывать связи не только по супругам или родственникам, но и по знакомым,
п8) при этом указывать отдельно, есть ли связь по супругу, есть ли по родственникам и есть ли по знакомым.
Произведем разбиение позиций в TVS123, которое позволит перейти к использованию устойчивого набора классов значений, такого набора, который не будет легко "ломаться" при очередных изменениях в постановках задач. В результате кодификатор TVS123 получит такое наполнение:
|
|
|
|
|---|---|---|
|
2 |
работал |
1 |
|
|
|
|
|
|
|
|
|
6 7 |
совладелец акционер |
3 3 |
|
|
|
|
На основе измененных правил и, что важно, тщательной классификации проводится выделение уже пяти "ортогональных" признаков вида связи:
VSRA - вид связи по работе (NK=1), VSRO - вид связи по родственникам (NK=2), VSSO - вид связи по собственности (NK=3), VSSU - вид связи по супругу (NK=4), VSZNA - вид связи по знакомым (NK=5).
В таблицу S3 добавляются столбцы VSSU и VSZNA, затем производится корректировка, заменяющая в VSRO значения "по супругу" на NULL с помещением этих значений "по супругу" в соответствующие поля VSSU.
Далее, в экранных формах должны быть проделаны изменения для перехода к работе с пятью фиксированными поименованными полями экрана для одного экземпляра связи, например (фрагмент экрана):
Назовем такое изменение Решением N4.
Обсуждение этих вариантов важно в случаях высокой изменчивости приведенного рода в описаниях признаков объектов БД, когда появляются "новые" признаки, причем возможно на месте одного "старого". Особенно высокой эта изменчивость является тогда, когда признаки и их значения получены с нарушениями правил классификации понятий, лежащих в основе построения информационной модели. К сожалению, такие ситуации в практической работе встречаются гораздо чаще, чем хотелось бы, и могут быть очень обременительными. Преимущества третьих, четвертых и т.п. форм тонут в постоянных переделках.
Соответственно, встает вопрос: последние ли изменения такого рода проделаны при получении Решения N4? Если нет, то зачем вообще понадобилось рассматривать Решения и N3, и N4? Может быть, вернуться к Решению N2 и применять его как можно чаще? Но не исчезают и недостатки решения N2, которые будут мешать все время эксплуатации!
В связи с этим, обратим внимание на важное отличие Решения N4 от остальных. Оно основано на правилах предметной области, измененных таким образом, что описаны не столько бизнес-правила, сколько такие объективно существующие правила, которые не зависят от правил документооборота или правил принятия деловых решений. Отвечая самой природе вещей по этим "природным правилам" одновременно и независимо может существовать и связь по супругу, и связь по родственникам. Такое выделение признаков и соответствующая классификация обеспечивают системе гораздо большую стабильность во времени. Другими словами, Решение N4 не страдает от нестабильности Решения N3, и не обладает недостатками Решения N2.
Конечно, Решение N4 требует от разработчика глубокого и тщательного анализа. Требуется анализировать как классификацию объектов по набору признаков, которые должны быть и ортогональны, и по возможности, отражать "природные" характеристики информационных объектов, так и наборы значений признаков, которые также должны быть (должны стать!) ортогональны. Все же, как видно из примеров, при таком подходе может не требоваться радикальная ломка доставшихся в наследство кодификаторов, если, конечно, они не содержат еще более тяжелых противоречий (что, к сожалению, бывает далеко не всегда).
Решение N4 рекомендуется и по другой причине. Дело в том, что в этом случае достигается и другая цель, специально не рассматривавшаяся в этой статье: только при использовании точно определенных и корректно классифицированных понятий в фактографических частях БД накапливаются достаточно достоверные данные, осмысленно, а не "как-нибудь" помещаемые туда пользователями. В результате, пользователь будет получать качественную информацию из БД и принимать, соответственно, качественные решения. Естественно, что и разработчик что-нибудь от этого выиграет. Это существенный фактор и он достоин соответствующей оценки в ходе сравнительного анализа.
9. Искусственные приемы, улучшающие Решение N2
Ниже кратко описаны два искусственных приема, позволяющие за счет внесения избыточности в БД ликвидировать часть недостатков Решения N2, по крайней мере в части скорости выполнения проверок целостности.
Первый прием состоит во включении в таблицу связи S1 избыточного столбца NK, в который включается номер класса значений вида связи VS. Назовем это решением N2A. Пример модифицированной таблицы S1A.
|
|
|
|
|
|---|---|---|---|
|
10 10 11 10 11 |
20 20 20 21 21 |
по супругу акционер совладелец работал по родственникам |
2 3 3 1 2 |
ОПИСАНИЕ ТАБЛИЦ ПРИМЕРА ДЛЯ РЕШЕНИЯ N2A (только отличия)
create table S1A (KP varchar references P(KP), /* ключ персоны */ KF varchar references F(KF), /* ключ фирмы */ VS varchar references TVS(VS), /* вид связи*/ NK varchar references TVS(NK) not null /* номер классификации */ ) primary key (KP,KF,NK);
Такое решение используется часто и применяется квалифицированными разработчиками. В этом случае запрос проверки при включении новой связи уже описаны на декларативном уровне, и это решение казалось бы является хорошим во всех отношениях.
К сожалению это не так. Во-первых, таблица S1A не находится в нормальной форме Бойса-Кодда. Есть функциональные зависимости и (KP,KF,NK) VS, и VS NK. Избыточность приводит, например, к проблемам при необходимости провести корректировку существующего вида связи с изменением значения на принадлежащее другому классу. Может требоваться дополнительное кодирование при программировании включения и др.
Во-вторых, если проанализировать позиции в таблице сравнения Решений N2 и N3, то можно заключить, что решение N2A существенно отличается от N2 только в позиции "1. Включение связей и добавление новых видов связей". В этой позиции решения N2A и N3 практически сравниваются. Зато появляется новый недостаток из-за необходимости поддерживать избыточные данные в столбце NK таблицы S1A. (Поддержка такой избыточности может программироваться на основе зависимости VS -> NK и таблицы TVS123 или делаться вручную и здесь не описывается.)
Таким образом, радикального исправления недостатков Решения N2 не наблюдается. (Кроме того, мы рассматриваем предмет на простых примерах, а в реальной практике может потребоваться работа с двумя и более уровнями классификации/кодификации. В этом случае прием Решения N2A дает еще меньше.)
Второй прием заключается в модификации первого, но требует еще и изменения формы хранимых элементов данных. Он состоит во включении в таблицу связи S1, в начало элемента VS избыточных позиций, в которые включается значение номера класса вида связи. Назовем это решением N2B. Пример модифицированной таблицы S1B:
Для работы с такой таблицей придется поддерживать и в кодификаторе аналогичный дополнительный столбец. Но многие могут сопоставить такое решение с аналогичным по сути и традиционно-привычным использованием составных иерархических кодов.
В этом случае проверку при включении новой связи надо программировать самому, но она относительна проста и может быть основана на действиях:
FLAG_W := 0;
select 1 into FLAG_W from dual
where exist (select * from S1B
where KP = NEW_KP_W and
KF = NEW_KF_W and
SUBSTR (VSB,1,1) = SUBSTR (NEW_VSB_W,1,1);
if (FLAG_W > 0) then
/* сообщение о том, что
включаемый вид связи
противоречит ранее включенным */
end if;
Однако, и здесь существенного улучшения нет. Решение N2B лучше, чем N2A, в операциях включения из-за того, что "иерархический код" включается в столбец VSB одной операцией, но при этом контроль остается более тяжелым, чем в Решении N3, и появляется новый недостаток из-за необходимости поддерживать избыточную структуру элемента "вид связи". Правда, поддержка такой избыточности может быть не очень чувствительной и даже привычно-незаметной, если перейти к работе с кодами признаков видов связи. (Вспомним, что в наших примерах названия видов связи включались в таблицы S1, S3, S1A, S1B вместо кодов KVS только для наглядности.)
На самом деле, нет ничего удивительного в том, что решение N4 остается лучшим при условии достижения известной стабильности в составе уже запроектированных атрибутов. Ведь, в противном случае, не проектировались бы в 99% случаев раздельными такие атрибуты персоны, как "Фамилия", "Домашний адрес" или "Рост", а всегда использовался бы обобщенный атрибут "Свойство персоны" с соответствующим списком значений!
10. Заключительный пример с ложным множественным полем
В заключение кратко рассмотрим еще один характерный случай. В этом случае недостатки в классификации приводят к решениям, аналогичным Решению N2, но, на первый взгляд, гораздо более оправданным, так как внешне эти решения связаны всего лишь с попыткой представления множественных полей в условиях ограничений реляционной модели.
Пусть надо представить приметы внешности человека, например, его глаз. Понятно, что про глаза можно сказать многое и изложить это в любом порядке. Например:
"голубые, большие, раскосые", или
"узкие, светлые, близко посаженные".
Естественно, составляются кодификаторы и на этот предмет, они часто очень похожи по качеству на кодификатор TVS и приводят к попыткам задавать приметы глаз списком. Поскольку у человека может быть много видов примет (кроме глаз еще приметы лица, волос, фигуры и др.), число дополнительных табличек (например, к основной таблице P - "персона") для задания таких списков сильно растет. В результате, проявления недостатков Решения N2 сильно увеличиваются.
Иногда делаются попытки достичь компромисса, располагая для моделирования списка признаков ограниченной длины несколько (например, пять или десять) однотипных полей в таблице основного информационного объекта. Так, в таблице P располагается пять однотипных полей для записи значений примет глаз:
create table P
( KP varchar primary key
/* ключ персоны */, ...
GLAZA1 varchar,
/* признак глаз*/
GLAZA2 varchar,
/* признак глаз*/
GLAZA3 varchar,
/* признак глаз*/
GLAZA4 varchar,
/* признак глаз*/
GLAZA5 varchar
/* признак глаз*/ ... );
Оценка такого способа так же неблагоприятна, как и Решения N2, и, во многом, по аналогичным причинам. В то же время, если корректно классифицировать используемые признаки глаз, можно убедиться, что они представляются следующими "ортогональными" признаками:
- цвет глаз,
- размер глаз,
- разрез глаз,
- глубина посадки глаз,
- расстояние между центрами глаз.
Соответствующие пять столбцов с индивидуальными доменами (списками значений) включаются в основную таблицу P и обрабатываются по правилам Решения N4. Полученная информационная модель оказывается весьма устойчивой к изменениям. (Естественно, может осуществляться ее развитие за счет дополнительных признаков, которые могут носить любой, в том числе, действительно списковый характер).
11. ЗАКЛЮЧЕНИЕ
Невозможно переоценить важность тщательного анализа и корректных классификаций для создания качественных баз данных. Часто разработчик может улучшить решение, уточняя предложенную ему классификацию значений признаков, заложенную в существующих, "доставшихся в наследство" кодификаторах, причем без радикальной ломки последних. Более того, использование корректной классификации рекомендуется всегда, при использовании любого из двух основных проектных вариантов: использование набора конкретных признаков объекта или, как альтернатива, одного обобщенного признака.
Качество проектных решений растет при использовании классификаций, учитывающих не только бизнес-правила, заданные в требованиях, но и более основательные, стабильные, "природные" объективные правила, лежащие ближе к глубинной природе классифицируемых предметов. Требуется тщательный анализ объектов и по набору признаков, которые должны быть ортогональны, и по наборам значений этих признаков, которые должны быть (должны стать!) ортогональны.
При этом подходе достигается и другая цель: только при использовании точно определенных и корректно классифицированных понятий в фактографических частях БД накапливаются достаточно достоверные данные, осмысленно, а не "как-нибудь" помещаемые туда пользователями.
Вместе с тем, единственного "правильного" или всегда лучшего проектного варианта не существует. Однако, при использовании изложенных рекомендаций число решений, остающихся в арсенале проектировщика и лежащих в диапазоне допустимого риска, становится невелико. Полезно оценивать варианты решений, предпочтительные в тех или иных ситуациях. Для этого применяется сквозной сравнительный анализ проектных вариантов, в котором сравниваются все основные режимы работы с БД, включая ее развитие в будущем при изменении требований к системе. Такой анализ может делаться на простом качественном уровне, либо углубляться в сторону получения численных оценок проектных решений.
Как один из вариантов, обобщенные решения остаются в арсенале проектировщика, и, при условии корректной классификации, могут иметь свои преимущества, хотя и не так часто, как этого иногда хотелось бы.
Благодарности.
Этот текст вырос из практических коллизий и заинтересованных обсуждений большого числа коллег, которые согласились со мной в том, что проблема не совсем тривиальна. Особо благодарен С.Кузнецову, М.Михеенкову и А.Шкотину, способствовавшим улучшению стиля (но вызвавших и увеличение объема!).
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|