Юрий Курносов - Аналитика: методология, технология и организация информационно-аналитической работы

Для преодоления этого недостатка используются, так называемые, вторая и третья нормальные формы, представляющие собой совокупность правил связывания и организации данных за счет внесения отношений ссылочной целостности (иерархизации представления данных). Хоть это, в принципе, противоречит основному принципу построения реляционных БД, но зато приближает реализуемые в таких БД отношения между данными к естественному способу хранения данных и знаний. Если воспользоваться метафорой, то в классическом виде отношения между данными, реализуемые в реляционных БД, можно сравнить с «кашей в голове» у нерадивого студента, когда из-за отсутствия закрепленных связей между фрагментами знаний, полученных в результате авральной зубрежки, в своих ответах на экзаменационные вопросы он может с легкостью сочетать несочетаемое.

Здраво было бы ограничить сферу применимости реляционных баз данных этапом макетирования информационных систем, предназначенных для функционирования в системах с низкой структурной и функциональной динамикой. После того, как период адаптации и установления ссылочных отношений окончен, в принципе, можно перейти к менее гибкой, но более быстродействующей навигационной парадигме (хоть она и старше реляционной). Но в силу универсальности и гибкости реляционной модели обычно она продолжает использоваться и по окончании периода адаптации, что обусловлено желанием заказчика обеспечить сохранение «потенциала роста» и максимальную гибкость БД, как инструмента исследования.

Выше мы вскользь упомянули о навигационной парадигме баз данных… Базы данных, реализованные в соответствии с навигационной парадигмой, по способу организации данных коренным образом отличаются от реляционных. Навигационная парадигма полностью соответствует принципу иерархической классификации. Связи между экземплярами данных в навигационных БД жестко заданы моделью, отражающей свойства моделируемой (описываемой) системы. Такое представление более гармонично вписывается в системный подход и напоминает уже не голову одуревшего от зубрежки студента, но голову педантичного старосты группы, знания которого хорошо уложены и приведены в порядок. Однако, если продолжить сравнение, то знания эти все еще разобщены, не полны и не позволяют создать нового знания, поскольку они бесконфликтны, а отношения между ними пока лишены должной пластичности.

Навигационная парадигма опирается все на тот же аппарат табличного представления данных, где имя колонки соответствует имени атрибута, строка — совокупности свойств некоторой сущности, выступающей в качестве атомарной на данном уровне описания. На следующем уровне описания этой же сущности атрибут может быть раскрыт с подобающей степенью детализации, но главное: описание будет вновь доведено до атомарного уровня — в противном случае все ухищрения лишены какого бы то ни было смысла. Процесс построения описательной структуры навигационной БД связан с процедурой поэтапной декомпозиции свойств сложного объекта в некоторой плоскости отношений (отношения включения, подчинения и т. д.). Так, протоколируя процесс последовательной разборки автомобиля и записывая после разборки некоторого узла или агрегата перечень деталей и крепежных элементов (с указанием их спецификации), можно синтезировать структуру описания, схожую со структурой навигационной базы данных.

Изучение такой БД может дать информацию о «конструкции», а вернее, о композиции и характеристиках объектов, описания которых хранятся в ней. То есть, разобранный автомобиль можно собрать вновь, не копаясь в баночках с разнокалиберными винтиками и шпунтиками. В случае ведения протокола разборки автомобиля в реляционной базе данных, пришлось бы бегать с каждым болтом от ведерка с болтами к агрегату — проверять, не подойдет ли…

— Хорошо еще, что эта работа возложена на плечи СУБД. Связи в навигационных БД установлены жестко — «открыть» новую вам не даст СУБД, заявив о попытке нарушить существующую схему отношений. Внести коррективы в систему отношений можно лишь взаимодействуя с СУБД в качестве разработчика.

Очевидно, что подобные БД могут применяться во многих отраслях, где требуется высокое быстродействие, где анализ связей уже завершен, а его результаты признаны удовлетворительными. По некоторым своим свойствам навигационные БД довольно близки к идеологии системного подхода, однако многообразие связей и отношений здесь даже теоретически не может быть учтено во всей своей полноте. Опять же, примитивные интерфейсы, используемые для отображения данных, зачастую предоставляются средствами СУБД (это плюс), но при попытке их усложнения или усовершенствования приходится обращаться к прикладным программам, размещаемым на рабочем месте клиента. С другой стороны все эти отношения могут быть сымитированы в реляционных СУБД, а значит, разработчик, имеющий опыт работы только с одним типом СУБД, оказывается способен создавать БД как классического реляционного типа, так и псевдо-навигационного типа (что потребителю выливается в необходимость приобретения более высокопроизводительного компьютерного оборудования, но удешевляет стадию разработки).

Мы уже рассмотрели реляционные и навигационные БД, но ни те, ни другие не были признаны нами в качестве средства хранения данных, отвечающего потребностям ИАР и сущности системного подхода (это не значит, что они вообще не могут быть эффективно использованы при ведении ИАР). Еще одной парадигмой построения баз данных, наследующей свойства навигационных баз данных, является парадигма объектных баз данных. Парадигма объектных баз данных по своей сути близка идеологии имитационного моделирования: для описания объектов учета такие БД используют комплекс компонент описания, обеспечивающий учет не только атрибутов объекта, но и системных связей, их параметров, правил комбинирования, проверки допустимости значений и так далее. В классическом варианте объектных БД объекты идентифицируются по именному принципу, их свойства определяются набором общих (свойственных родительскому классу) и частных (свойственных данному экземпляру объекта или производному классу) характеристик. Чрезвычайно полезными механизмами, введенными в модель объектных БД, являются механизмы наследования и переопределения свойств объектов и классов. Чтобы проиллюстрировать этот механизм, приведем следующие утверждения в «объектном стиле»: «Книга — есть документ, отличающийся тем, что носитель символьных данных объединен в блок. Свиток — есть документ, отличающийся тем, что носитель символьных данных представляет собой скрученную в рулон широкую ленту». Как видим, понятия введены на основе использования ранее введенных понятий-классов верхнего уровня «документ» и «носитель символьных данных», за счет чего упрощено описание производных понятий (а термины и понятия, естественно, могут выступать в роли объектов хранения).