Тема 4. Даталогическое проектирование
4.1. Общие сведения
Цель даталогического проектирования заключается создании ДЛМ, которая отображает логические связи между элементами данных безотносительно к их смысловому содержанию и среде хранения. Эта модель строится в терминах информационных единиц, предусмотренных в конкретной СУБД. На рисунке 4.1. показана последовательность разработки ДЛМ.
Рис.4.1. Последовательность разработки ДЛМ:
Д1- документация по СУБД; Д2 … Дi- документация по средствам проектирования; U1- набор допустимых даталогических конструкций; U2- операторы ЯОД; U3- ограничения, налагаемые СУБД на ДЛМ; U4- возможности физической организации данных; П- перечень хранимых показателей ( атрибутов); ДЛМ- даталогическая модель; ИЛМ- инфологическая модель; S1- средства проектирования.
Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также допускает использование определенных правил композиции логических структур более высокого уровня и составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру БД. Поэтому прежде чем приступить к построению ДЛМ, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, оценить возможность и целесообразность их использования.
Хотя даталогическое проектирование является проектированием логической структуры БД, на него оказывают влияние возможности физической организации данных, представляемые конкретной СУБД. Поэтому знание особенностей физической организации данных может быть полезным при проектировании логической структуры.
Логическая структура БД, а также сама заполненная данными БД являются отображением реальной ПО. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика ПО, отраженная в ИЛМ.
Результатом даталогического проектирования является описание логической структуры БД на ЯОД. В спроектированной логической структуре БД должны быть определены все информационные единицы и связи между ними, заданы имена информационных единиц, их тип и количественные характеристики ( например, длина поля).
4.2. Подход к даталогическому проектированию
Процесс проектирования БД предусматривает предварительную классификацию объектов ПО, систематизированное представление информации об объектах и связях между ними в ИЛМ.
На начальных этапах даталогического проектирования должен быть определен состав БД.
При проектировании логической структуры БД осуществляются преобразование исходной ИЛМ в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной ДЛМ отображаемой ПО.
Для любой ПО существует множество вариантов проектных решений ее отображения в ДЛМ. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.
Минимальная логическая единица данных для всех СУБД семантически одинакова и соответствует либо идентификатору объекта, либо свойству объекта или процесса.
Связи между объектами ПО, отраженные в ИЛМ, могут отображаться в ДЛМ либо посредством совместного расположения соответствующих им информационных элементов, либо путем объявления связи между ними. Не все виды связей, существующие в ПО, могут быть непосредственно отображены в конкретной ДЛМ. Так, многие СУБД не поддерживают непосредственно степень связь N:M между объектами. В этом случае в ДЛМ вводится дополнительный вспомогательный элемент, отображающий эту связь.
Следует иметь в виду, что связи, имеющиеся в ПО и отраженные в ИЛМ, могут быть представлены не только посредством структуры БД, но и программным путем. Например, при отображении обобщенных объектов можно не выделять подклассы на уровне логической структуры БД, а предусмотреть выделение подклассов программным путем при обработке хранимых данных.
Принимаемое проектное решение зависит не только от специфики отображаемой ПО, но и от характера обработки информации, хранимой в БД. Например, рекомендуется хранить вместе информацию, часто обрабатываемую совместно, и, наоборот, разделять по разным файлам информацию, не использующуюся одновременно. Информацию, используемую часто, и информацию, частота обращения к которой мала также следует хранить в разных файлах.