Моделирование данных: от сущностей к структурам данных. Структуры концептуальной модели

Размещено на http://www.allbest.ru/

Моделирование данных: от сущностей к структурам данных. Структуры концептуальной модели

Введение

база данных информационный

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

- именованные таблицы;

- именованные атрибуты (столбцы) таблиц;

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

- домены (области определения) каждого атрибута;

- именованные связи между таблицами;

- указание кардинальности связи.

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

Пример концептуальной модели, содержащей все перечисленные элементы, можно увидеть на рисунке 1.

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

Построением такой модели завершается процесс концептуального моделирования данных, включающего, как было показано в [1], этапы выделения типов сущностей и преобразования типов сущностей в объектные кластеры.

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

В заключение работы приводится схема, позволяющая составить наиболее общее и одновременно системное представление обо всех обязательных фазах даталогического моделирования и последовательности выполнения этих фаз.

Рисунок 1 - Пример схематического представления концептуальной модели данных

1. Категории структур данных

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

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

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

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

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

3. Минимизация объёма внешней и внутренней памяти, необходимой для хранения данных.

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

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

Всем только что перечисленным требованиям полностью соответствует множество, показанное на рисунке 2. Отметим, что более корректно говорить не о множестве, а об ориентированном графе, узлы которого представлены структурами с набором предопределённых связей между ними. Каждому типу структуры на схеме (рисунок 2) присвоен уникальный индекс, на который в дальнейшем будет делаться ссылка. Рассматриваются только связи, соответствующие кардинальности вида 1:M («один ко многим»), поскольку другой разрешённый в модели тип связи «1:1 (один к одному)» приводит к формированию уточняющих подмножеств зависимых одноуровневых структур. Такие типы связей к формированию базовой части структурного графа, соответствующего объектному графу, отношения не имеют и поэтому в работе не рассматриваются.

В составе структуры целесообразно выделять несколько групп атрибутов:

- атрибуты, посредством которых однозначно идентифицируется любая запись таблицы. Это так называемые первичные ключевые атрибуты или первичный ключ;

- внешние ключевые атрибуты или атрибуты, посредством которых «поддерживаются» связи между записями двух разных или одной и той же таблицы (если связь между записями рекурсивная);

- содержательные атрибуты или атрибуты, хранящие значения свойств объектов;

- атрибуты, которые принято называть «данными пересечения».

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

- атрибут, выполняющий роль «суррогатного» первичного ключа;

- атрибут, выполняющий функцию внешнего ключа;

- атрибут внешнего ключа, обеспечивающий поддержку рекурсивной связи в структуре ;

- «композитный» атрибут, дублирующий первичный ключ структуры (акие атрибуты именуют еще альтернативными ключами, подчеркивая тем самым факт уникальности (неповторимости) принимаемых ими значений);

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

- атрибут, предназначенный для хранения «данных пересечения»;

- информационный (содержательный) атрибут.

Перечисленные однородные атрибуты (атрибуты, относящиеся или к , или к и т.п.) могут «сцепляться» друг с другом и образовывать множества, которые в составе структур выполняют определённые функции.

Имеет смысл перечислить и описать эти множества.

- множество атрибутов простого первичного ключа (simple key (английские названия приводятся для того, чтобы, если читатель знаком или желает познакомиться с работами, написанными на английском языке, ему было легче ориентироваться в уже сложившемся терминологическом аппарате). ;

- множество атрибутов составного первичного ключ (compound key).

В свою очередь в указанном множестве можно выделить два подмножества: . (Второе подмножество не является обязательным и может отсутствовать в составе составного первичного ключа.)

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

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

Следующее подмножество включает только «виртуальные» атрибуты - . Здесь L - количество связей вида «1:M», которые действуют между t - таблицей и элементами множества виртуальных структур. Как и в предыдущем случае, разным могут соответствовать одни и те же виртуальные структуры.

Следующее множество, которое также целесообразно выделять в составе структуры, - это множество внешних ключевых атрибутов - .

. Как и в случае с , каждому ставится в соответствие , ().

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

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

. Следовательно, каждому ставится в соответствие , (). Единственное отличие, существующее между элементами двух множеств и , состоит в том, что двум разным нельзя поставить в соответствие один и тот же .

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

После перечисления атрибутов и групп атрибутов можно перейти к рассмотрению атрибутного состава каждого типа унифицированной структуры.

Целесообразно выделять минимальный (обязательный) и расширенный атрибутные наборы. Руководствуясь схемами, представленными на рисунке 1, запишем следующее:

; .

; .

; .

.

.

; .

Верхним индексом «М» помечены структуры с минимальным набором атрибутов. Соответственно индекс «E» присвоен структурам, обладающим расширенным набором атрибутов.

Как будет показано далее, шести типов структур достаточно для представления в модели всех разновидностей объектов, рассмотренных в [2]. Тем не менее введём ещё один вспомогательный структурный тип, использование которого уменьшит негативные последствия потенциальной модернизации структурного графа модели данных.

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

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

Обязательным условием реализации сказанного является постоянство атрибутного состава упомянутого ключа. Добиться этого можно одним простым «техническим» решением - «разнести» программные блоки формирования и использования составного первичного ключа. Другими словами, создать отдельную структуру и разместить в ней атрибуты составного первичного ключа. Для этого выполним следующее преобразования структуры (рисунок 3). Структура распадается на базовую часть - , где будет организовано хранение «данных пересечения» и вспомогательную часть - , функция которой - формирование соответствий между значениями простого первичного суррогатного ключа и значениями составного первичного ключа модифицируемой структуры . Формально речь идёт об установлении соответствия , которое находит своё отражение в структуре . Продемонстрируем данное преобразование на примере подсхемы модели данных (рисунок 4), предназначенной для фиксации текущих остатков товаров на складах торговой компании. В структуре хранятся данные, устанавливающие соответствие между атрибутом «ID__товарной позиции» и набором атрибутов «ID_склада, ID_товара, ID_материально ответственного лица». Соответственно в вместо составного первичного ключа, используемого в , задействован простой суррогатный первичный ключ - «ID_товарной позиции».

В дальнейшем, если, например, нужно будет учитывать «срок годности товара» (дату истечения срока годности) достаточно включить в структуру соответствующий дополнительный атрибут, что никаким образом не отразится на количественном и содержательном составе атрибутов в -структуре.

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

2. Запрещённые и разрешённые «наследования»

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

Множество структур модели данных образуют три непересекающихся подмножества: - подмножество входных структур, - подмножество выходных структур, - подмножество промежуточных структур.

Справедливо: .

Обозначим через связь между структурой с индексом l и структурой, имеющей индекс m (кроме нижнего индекса в обозначении структуры будем также использовать верхний индекс для обозначения её «классовой» принадлежности). Например, , где k - номер класса (вида) структуры {1,2,3,6}). Соответственно пусть - множество связей «входящих» в структуру , - множество связей, направленных из структуры .

Можно записать следующее:

;

;

.

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

Связи и запрещены. Представленный подграф иллюстрирует недопустимость прямого наследования простого первичного ключа составным простым ключом, если первый был уже опосредованно наследован промежуточными структурами. Аналогичным образом запрещены опосредованные наследования в случаях замещения -структуры на структуру вида . Примеры соответствующих подграфов показаны на том же самом рисунке 5. Нетрудно заметить, что в структурном графе модели данных не должны присутствовать циклы. Таким образом, структурный граф должен быть ациклическим. Другая запрещенная конструкция и разрешенные комбинации конструкций подграфа изображены на рисунке 6.



Пусть в составе структурного графа присутствуют подграфы B, C, D (рисунок 6). Для подграфа B запрещённые связи: , . Для подграфа С: , . Для подграфа D: , .

Все ограничения на структуру связей вытекают из особенностей кластерной организации объектов, которая была изложена в [2].

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

Ещё на одну разновидностей связей следует обратить внимание. Это связи: и . Структура типа не может появиться в структурном графе, если подобные связи не будут иметь место.

Таким образом, природа введённых в [2] объектов в совокупности с их естественной кластерной организацией исключают появление ряда связей между структурами, представляющими эти объекты в модели данных.

3. Атрибуты структур концептуальной модели

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

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

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

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

Дело в том, что в «заблуждение» специалистов, занятых проектированием моделей данных, как правило, вводят два фактора: наличие ЕСКК (Единой системы классификации и кодирования информации) и локальных, характерных для конкретной предметной области внутренних систем классификации и кодирования данных. В перечисленных системах присутствуют действительно уникальные атрибуты - так называемые идентификационные блоки, являющиеся естественными претендентами на роль первичных ключей. И именно они зачастую становятся первичными ключами, что по целому ряду причин, о которых речь пойдёт далее, не может считаться хорошей практикой.

Классификация и кодирование данных (и на этом следует специальным образом акцентировать внимание) - далеко не одно и то же, несмотря на то, что эти два понятия принято использовать совместно. Их смешивание, если это происходит, становится своеобразной ловушкой (западнёй) для проектировщиков информационных систем. Что такое в контексте классификации и кодирования данных «суррогатный ключ»? Это атрибут, посредством которого производится исключительно кодирование данных - присваивается условное обозначение (код) определённому объекту реального мира. Очевидно, что «суррогатный» ключ обеспечивает поддержку в базах данных порядковой системы кодирования. Все остальные альтернативные системы кодирования информации - серийная, составная, поуровневая, мнемоническая, а также их различные комбинации - в «чистом» виде таковыми не являются. Это одновременно и системы классификации, и системы кодирования данных.

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

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

В качестве примера для иллюстрации перечисленных сравнительных характеристик рассмотрим идентификационный блок типичного общероссийского классификатора - «Общероссийского классификатора специальностей по образованию» (рисунок 7).

Таблица 1 - Сравнительная характеристика систем кодирования данных

№ п/п	Критерии сравнения	Системы кодирования
		Порядковые	Альтернативные (композитные)
1	Семантическая интерпретация	Отсутствует	Отсутствует
2	Контроль уникальности объектов	Не поддерживается	Поддерживается
3	Ограниченность диапазона значений, которые может принимать код (ключ)	Очень высокая	Ограниченная
4	Объём памяти, необходимый для хранения первичных и внешних ключевых атрибутов	Ограниченный	Высокий
5	Вероятность ввода ошибочных значений	Нулевая	Высокая
6	Трудоёмкость ввода значений кодов	Нулевая	Высокая



Многочисленные аспекты классификации во всех классификационных системах, что можно увидеть из представленной схемы (рисунок 7), жёстко «зашиваются» в так называемом идентификационном блоке - атрибуте, значения разрядов которого формируются в соответствии с предварительно заданными правилами (вообще говоря, давно настала необходимость радикального пересмотра системы кодирования информации в ЕСКК, поскольку существует очевидное противоречие между «удобством» системы кодов и последующей их интерпретацией в моделях данных. По всей видимости, коллективы людей, занятых моделированием данных для прикладных систем и разработки ЕСКК, никогда не пересекаются).

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

Вполне логично, что после этого потребность в идентификационном блоке отпадает сама собой.



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

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

В отношении следующего критерия, представленного в таблице 1, - критерия контроля уникальности объектов, преимущества альтернативных систем кодирования по сравнению с порядковой системой очевидны. Но ещё раз подчеркнём, что при одновременном задействовании «суррогатного» ключа, композитных и именованных атрибутов уникальность можно обеспечить на гораздо более высоком уровне.

Что касается следующих четырёх критериев - ограниченности диапазона значений, которые может принимать код (ключ), объёма памяти, необходимого для хранения первичных и внешних ключевых атрибутов, вероятности ввода ошибочных значений и трудоёмкости ввода данных, то здесь все достаточно очевидно, и преимущества порядковой системы кодирования прослеживаются особенно явно. Следующая группа атрибутов, которая ранее была выделена, - группа атрибутов внешних ключей (foreign keys). Внешние ключевые атрибуты, образующие подмножество , не что иное, как механизм поддержки взаимодействий между структурами реляционной модели. Если между двумя таблицами установлены соответствия вида «1 :1» или «1:M», если нет «данных пересечения», то дополнительный атрибут, реализующий функцию внешнего ключа, добавляется в дочернюю подчинённую таблицу. Функция внешнего ключа состоит в том, чтобы задать принадлежность части записей дочерней таблицы определённому подмножеству. В это подмножество входят все записи (объекты), имеющие одинаковое значение внешнего ключа. Нетрудно заметить, что таких подмножеств (причём обязательно непересекающихся подмножеств) будет ровно столько, сколько значений присвоено внешнему ключу.

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

В моделях данных «данные пересечения» представляются с помощью специальной категории объектов - «слабых сущностей» (все разновидности «слабых сущностей» подробно рассмотрены в [2]).

Формально все «слабые сущности» моделируются посредством -структуры.

Но особый интерес представляет природа (происхождение) подобных данных. Её рассмотрение приводит не только к новой трактовке понятия «свойство объекта», являющегося фундаментальным понятием в теории моделирования данных, но и последующей необходимости серьёзной ревизии самой теории. Остановимся на этом вопросе, затрагивая только его суть, а не следствия, которые выходят за рамки настоящей статьи.

Все содержательные атрибуты, под которыми и «скрываются» эти свойства, на рисунке 1 помечены нами как «наименование». Эти атрибуты на уровне естественного языка позволяют произвести отличие одного экземпляра объекта определённого типа от другого экземпляра. То, что подобные атрибуты присутствуют в структурах типа , и , призвано отразить факт постоянства этих атрибутов - низменности значений, которые они принимают. В действительности же ни один из подобных атрибутов не является абсолютно постоянным. Зафиксируем этот факт. Всегда существует вероятность, может быть, и не очень высокая, того, что какой-то экземпляр содержательного атрибута поменяет значение.

Возьмём для примера объект, предназначенный для хранения списка персонала. Обязательные в этом случае содержательные атрибуты - это «Фамилия», «Имя», «Отчество». Но фамилию в течение жизни меняет, как минимум, половина населения. Изменение имени или отчества тоже иногда случается.

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

Какой же вывод можно сделать? Абсолютно постоянных содержательных атрибутов в природе не существует. Можно говорить разве только что об условно-постоянных атрибутах, но не более того. Другое дело, что в каких-то предметных областях динамика определённой группы содержательных атрибутов не столь важна, и поэтому нет необходимости её специальным образом отслеживать.

Тем не менее, если динамика имеет место быть, её приходится учитывать. В самой простой постановке поддержку динамики можно обеспечить посредством следующей подсхемы (рисунок 9), когда в -структуре фиксируется дата, на которую значение свойства (в данном случае «Фамилия») изменилось.



В этом случае атрибут «Фамилия» в структуре оказывается избыточным, но, чтобы сократить время на поиск текущего действительного «наименования», бывает удобно сохранить этот атрибут в составе .

Это один из случаев обоснованной, целесообразной избыточности данных. Вернёмся снова к «чистым» «данным пересечения» - данным, которые функционально полно зависят от совокупности атрибутов, образующих первичный ключ - .

«Данные пересечения», которые представляются с помощью , могут быть двух видов. Это либо содержательные данные, такие, например, как количество. Либо наследуемые данные, соответствующие значению простого первичного ключа связанной структуры. Вот два характерных примера (рисунок 10) подобных данных, иллюстрирующие сказанное.

Нам представляется, что нет необходимости давать пояснения к рисунку 10.

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

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



4. Соответствия между объектами и структурами. Проблемы замещения структур

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

Покажем, каким типам объектов, которые были выделены в [2], какие типы структур соответствуют. Таблица 2 содержит установленные соответствия.

Таблица 2 - Соответствия между типами объектов и категориями структур

№ п/п	Тип объекта	Категории структур
1.	Объект-тип
2.	Объект-знак
3.	Объект-группировка
4.	Слабая сущность

Заметим, что все представленные соответствия - это функции. Таким образом, карта объектов, если она включает разновидности объектов, перечисленных в таблице 2, может быть преобразована в схему организации данных, согласно простому и однозначному алгоритму.

На этом завершается системообразующий для модели данных этап создания её базовой структурной части. Но сама процедура конструирования модели на этом не завершается. В начале статьи упоминалось о такой характеристике модели данных, как её устойчивость. Понятно, что добиться устойчивости схемы организации данных в динамическом мире задача сложная и, может быть, неразрешимая. Напомним, что всякое вмешательство в структурную часть баз данных порождает цепочки изменений в других частях информационной системы, что крайне нежелательно по целому ряду причин, которые в конечном итоге приводят к снижению качества обработки данных в информационных системах [1]. Поскольку проблема замещения структур имеет определённое отношение к структурной части базы данных, её нужно, по крайней мере, здесь обозначить.

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

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

Заключение

В работе рассмотрен завершающий этап конструирования базовой части концептуальной модели данных - построение опорной структурной диаграммы базы данных. На схеме (рисунок 11) перечислены все этапы и последовательность их выполнения.

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

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

Речь в первую очередь идёт о двух задачах:

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

- формирование системы критериев качества концептуальной модели.

Обе эти задачи не могут быть решены в отдельности друг от друга, ввиду их тесной взаимосвязи. Кроме того, вторая задача является неотъемлемой частью другой задачи более высокого уровня - выбора системы критериев качества информационной системы как компонента предметной области, которую эта информационная система отражает. Но и это ещё не всё.

Качество модели данных может быть оценено при одном достаточно жёстком и существенном условии - фиксации разновидностей структур данных, которые могут быть задействованы в модели. Очевидно, что выбор какого-то другого «структурного набора» повлечёт за собой и пересмотр соответствующей критериальной основы.

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

Литература

1. Родионов, А. Н. Управление качеством экономической информации / А. Н. Родионов. - Хабаровск : Изд-во Хабар. гос. техн. ун-та, 2001. С. 224.

2. Родионов, А. Н. Моделирование данных : от сущностей к структурам данных. Сущности и объекты / А. Н. Родионов. - Хабаровск : Вестник ХГАЭП. 2010. № 1. С. 43 - 61.

Размещено на Allbest.ru

...