Логическое проектирование баз данных

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

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

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

Реализация принципа явного выделения подклассов в структуре БД существенно зависит от специфики СУБД.

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

Как отмечалось выше, в ИЛМ описывается не отдельный объект, а класс объектов. Но в редких случаях бывает, что класс включает в себя только один экземпляр объекта. Например, если предметной областью является какой-то конкретный институт, то класс объектов ИНСТИТУТ будет содержать только один экземпляр объекта. Таким «вырожденным» классам объектов обычно не ставится в соответствие отдельный файл базы данных.

2.4 Определение состава базы данных

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

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

Такой подход имеет очевидные достоинства:

простота и однозначность в принятии решения «что хранить»;

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

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

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

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

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

Известен размер обычной стипендии.

Тем, кто не имеет удовлетворительных оценок, назначается стипендия на 25% выше, чем обычная.

Тем, кто имеет только отличные оценки, стипендия увеличивается на 50% от размера обычной стипендии.

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

полученная величина многократно используется в дальнейшем;

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

размер стипендии не должен изменяться в течение семестра. Кроме того, имея реальный файл «Начисленная стипендия», легче контролировать его полноту и достоверность.

Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.

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

2.5 Введение искусственных идентификаторов

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

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

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

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

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

2.6 Особенности логических моделей

2.6.1 Внутризаписная структура

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

В случае иерархической внутризаписной структуры в состав записи могут входить не только простые, но и составные компоненты. Это могут быть векторы (когда повторяются однотипные элементы), повторяющиеся группы (когда в записи может присутствовать несколько экземпляров составных единиц информации, включающих в себя несколько разнотипных элементов), а также неповторяющиеся составные единицы информации внутри записи. Например, если мы имеем запись ЛИЧНОСТЬ, то в ее состав могут входить простые элементы, такие, как ТАБЕЛЬНЫЙ НОМЕР, ФАМИЛИЯ и т. д., вектор ИНОСТРАННЫЙ ЯЗЫК (предполагается, что человек может владеть несколькими иностранными языками), повторяющаяся группа ПОСЛУЖНОЙ СПИСОК, включающая элементы: ДАТА НАЗНАЧЕНИЯ, ДАТА УВОЛЬНЕНИЯ, МЕСТО РАБОТЫ, ДОЛЖНОСТЬ, а также неповторяющаяся группа АДРЕС, состоящая из элементов ГОРОД, УЛИЦА, ДОМ, КВАРТИРА-

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

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

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

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

2.6.2 Межзаписная структура

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

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

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

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

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

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