Проектирование базы данных. Основные задачи проектировщика БД. Логическое и физическое проектирование БД

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

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

- объединение в единое целое фрагментарных представлений о различных свойствах одной и той же сущности;

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

- образование супертипов и подтипов подобных сущностей.

При объединении локальных представлений используют три основополагающие концепции:

Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение. Наборы атрибутов исходных сущностей при этом объединяются. Например, СОТРУДНИК для отдела кадров и СОТРУДНИК для отдела закупок – это один и тот же тип сущности, возможно, с разным набором атрибутов.

Агрегация. Позволяет рассматривать связь между элементами как новый элемент.

Например, связь экзаменовать между сущностями ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, СТУДЕНТ может быть представлена агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.

Обобщение. Позволяет образовывать многоуровневую иерархию обобщений.

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

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

На этапе анализа общей концептуальной модели также решаются следующие задачи:

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

2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к данным ИС.

3. Создание внешней спецификации тех функций (процессов), которые ИС должна выполнять. Спецификации служат основой для разработки приложений.

Определение требований к операционной обстановке

Проводится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, выбор типа и конфигурации ЭВМ, типа и версии операционной системы (ОС).

На выбор оказывают влияние такие показатели, как:

- примерный объём данных в БД;

- динамика роста объёма хранимых данных;

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

- интенсивность запросов к данным по типам запросов;

- требования ко времени отклика системы по типам запросов;

режим работы (интерактивный, реального времени).

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

Выбор СУБД и инструментальных программных средств

Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на процесс проектирования БД и реализации информационной системы.

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

- тип модели данных, которую поддерживает данная СУБД;

- характеристики производительности СУБД;

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

- степень оснащённости СУБД инструментарием для администрирования