Чтобы иметь возможность извлекать информацию из базы данных, ее туда нужно поместить. А перед этим необходимо определить, как именно должна выглядеть база данных. Процесс, в ходе которого решается, какой вид будет иметь создаваемая база данных, называется проектирование базы данных. Качественный проект базы данных является основой построения надежной высокопроизводительной системы.
Проектирование базы данных – очень важный процесс, определяющий, в основном, жизнеспособность информационной системы, но это только один из этапов полного цикла разработки системы. Весь цикл разработки системы состоит из нескольких этапов, на каждом из которых необходимо выполнить определенные процедуры. Такой подход к разработке базы данных обеспечивает преобразование информационных потребностей предприятия в рабочую базу данных.
§ Стратегия и анализ
Изучение и анализ потребностей предприятия в информации. Информационные потребности выясняются в ходе бесед с управляющим персоналом. Одновременно изучаются документы и электронные файлы, которые используются на предприятии для хранения и обработки данных. На этом этапе необходимо ответить на следующие вопросы:
§ Откуда и в каком виде поступает информация?
§ Как она будет вводиться в систему и кто будет этим заниматься?
§ Как часто изменяется информация?
§ Какие параметры системы наиболее критичны с точки зрения надежности?
§ Какие данные будут запрашиваться наиболее часто?
§ В каком виде информация будет извлекаться, и для кого она предназначена?
§ Логическое проектирование
Построение логической модели системы. Описания, полученные на этапе стратегии и анализа, преобразуются в графическое представление информационных потребностей и бизнес-правил предприятия (ER-моделирование). Полученный макет таблиц и связей между ними обсуждается совместно с аналитиками и экспертами.
§ Физическое проектирование
Сущности, представленные в ER-модели, преобразуются в таблицы, атрибуты – в столбцы, связи – во внешние ключи, бизнес-правила – в ограничения. Создаются индексы, обеспечивающие прямой и быстрый доступ к данным. Создаются представления, представляющие собой логические таблицы, предназначенные для более удобного вывода данных. Определяется количество памяти, необходимое для размещения таблиц.
На этом этапе, в основном, закладывается производительность системы, т.к. если база данных спроектирована недостаточно хорошо, дальнейшие усилия по настройке не смогут ликвидировать все недостатки системы. Поэтому вопросы производительности должны рассматриваться именно при физическом проектировании базы данных.
На этапе физического проектирования необходимо, также, учитывать возможность интеграции с другими, существующими или только планируемыми, системами. Качественный проект должен обеспечивать как единообразие, так и интеграцию прикладных систем.
Не забывайте документировать все решения, которые Вы принимаете в процессе проектирования системы, это поможет избежать повторных ошибок.
Пользуйтесь готовыми решениями, это позволит сократить время, необходимое для создания проекта базы данных.
§ Кодирование и документирование
Создание опытной системы. Написание и выполнение команд для создания объектов базы данных. Создание пользовательских приложений. Разработка пользовательской документации и руководств по эксплуатации системы.
§ Внедрение и отладка
Совершенствование опытной системы. Ввод пользовательских приложений в эксплуатацию. Тестирование.
§ Эксплуатация
Передача системы пользователям. Эксплуатация системы. Сопровождение: наблюдение за работоспособностью, усовершенствование.
Основой проектирования является модель данных, которая создается для более глубокого понимания проекта базы данных. На каждом этапе разработки системы строится новая модель данных на основе модели, полученной на предыдущем этапе. В конечном итоге модель данных преобразуется в таблицы базы данных (Рисунок 1).
Рисунок 1 Модели данных
В проектировании базы данных немаловажным является этап логического проектирования. Чем тщательнее продумана логическая структура базы данных, тем меньше приходится модифицировать уже работающую базу данных. К тому же логическое проектирование играет существенную роль в обеспечении целостности данных. Поэтому необходимо сначала разработать логическую структуру основных компонентов базы данных и только потом заниматься физическим проектированием.
В основе реляционной модели организации баз данных лежит технология моделирования взаимосвязей, которая позволяет формализовать процесс построения логической структуры. Наиболее популярна методика, предложенная П.П.Ченом в 1976 году – методика диаграмм взаимосвязей между объектами (Entity-Relationship Diagram). После построения ER-диаграммы результат может быть преобразован в реляционную модель, а реляционная модель – в физическую.
ER-диаграмма создается на основе документов, которые описывают информационные потребности и правила организации данных. ER-диаграмма состоит из:
§ Сущностей (Entity) – предметов или фактов, информацию о которых необходимо хранить (сотрудник фирмы; проект, реализуемый фирмой и т.д.).
§ Атрибутов (Attributes) – нечто, что описывает или квалифицирует сущность (атрибут сущности “сотрудник” – зарплата, атрибут сущности “проект” – сметная стоимость).
§ Связей (Relationship) – ассоциативной связи между двумя сущностями (между сотрудниками и проектами, в которых они принимают или не принимают участие). Связь характеризуется обязательностью (необязательностью) и соотношением количества элементов на ее сторонах.
Рассмотрим пример. Пусть имеется некоторая проектная организация, имеющая определенный штат сотрудников. Организация разрабатывает несколько проектов, каждый из которых имеет уникальный номер, название, и, возможно, проектную стоимость. Кроме того, проект может содержать подпроекты, имеющие свой номер и название. Сотрудник имеет фамилию, имя, и, возможно, контактный телефон. Каждый сотрудник может участвовать в одном или более проектов, каждый проект должен быть закреплен хотя бы за одним сотрудником. Каждый сотрудник может иметь начальника и может руководить несколькими сотрудниками.
Сущность (Entity) – предмет или факт, информацию о котором необходимо хранить (сотрудник, проект, подпроект).
Для представления сущностей в ER-диаграммах используется следующая система обозначений (Рисунок 2):
§ Рамка со скругленными концами
§ Уникальное имя сущности
§ Имя сущности пишется прописными буквами
Рисунок 2 Сущности в ER-диаграмме
Атрибуты (Attributes) – нечто, что описывает или квалифицирует сущность.
Если сущность не имеет атрибутов, необходимых с точки зрения бизнеса, она не входит в набор требований к системе и не должна появляться в модели.
Каждый атрибут обязателен или необязателен (опционален).
Каждый экземпляр сущности должен быть однозначно узнаваем. Для различения экземпляров сущности служит уникальный идентификатор (UID) – любая комбинация атрибутов и/или связей.
Для представления атрибута в ER-диаграмме используется следующая система обозначений (Рисунок 3):
§ Уникальное имя атрибута указывается строчными буквами
§ Обязательные атрибуты помечаются звездочкой (*)
§ Необязательные атрибуты помечаются символом “o”
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.