3.1.2. Результат даталогического проектирования

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

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

3.1.3. Подход к даталогическому проектированию

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

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

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

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

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

Для любой предметной области существует множество вариан­тов проектных решений ее отображения в даталогической модели. Методика проектирования должна обеспечивать выбор наиболее под­ходящего проектного решения.

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

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

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

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

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

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

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

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

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

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

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

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