- •Проектирование реляционной базы данных
- •Введение в проектирование реляционных баз данных
- •Этапы проектирования базы данных
- •1. Инфологическое проектирование
- •2. Определение требований к операционной обстановке
- •3. Выбор субд и других программных средств
- •4. Логическое проектирование бд
- •4.1 Особенности проектирования реляционной база данных
- •5. Физическое проектирование бд
- •Требования к оформлению курсовой работы
- •Организация защиты курсовой работы
- •Список литературы
- •Проектирование реляционной базы данных
4. Логическое проектирование бд
На этапе логического проектирования разрабатывается логическая структура БД, соответствующая логической модели ПрО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД.
База данных создаётся на основании схемы базы данных. Инфологическую модель данных, построенную в виде ER-диаграммы, следует преобразовать в схему БД. Преобразование ER-диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, в таблицы-отношения (таблицы БД).
Для этого необходимо выполнить следующие шаги процедуры проектирования модели.
1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы.
2. Представить каждую ассоциацию (связь вида «многие-ко-многим» или «многие-ко-многим-ко-многим» и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.
3. Представить каждую характеристику как базовую таблицу с внешним ключом идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и её первичный ключ – по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует «уникальность в рамках описываемой сущности».
4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешнем ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.
5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.
6. Для исключения из проекта непреднамеренных нарушений каких-либо принципов нормализации, выполнить процедуры нормализации.
7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.
8. Указать ограничения целостности проектируемой БД и дать (при необходимости) краткое описание полученных таблиц и их полей.
4.1 Особенности проектирования реляционной база данных
Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности.
Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных, которые обусловлены отсутствием средств явного представления типов множественных связей между объектами ПО и неразвитостью средств описания ограничений целостности на уровне модели данных.
Для решения подобных проблем проводится нормализация отношений. Нормализация схемы отношения выполняется путем декомпозиции схемы.
5. Физическое проектирование бд
Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, то есть отображения логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам “физической” БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.
Одной из важнейших составляющих проекта базы данных является разработка средств защиты БД. Защита данных имеет два аспекта: защита от сбоев и защита от несанкционированного доступа. Для защиты от сбоев разрабатывается стратегия резервного копирования. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только а соответствии с его правами доступа.
СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
Введение.
1. Инфологическое проектирование БД.
Раздел должен содержать.
Анализ предметной области: назначение БД; состав данных и возможности БД; отразить свойства БД в соответствии с ПО; выделить базовые сущности и их атрибуты; выделить связи и их атрибуты; построить ER- диаграмму.
Анализ информационных задач и круга пользователей системы: какие группы пользователей обслуживаются; границы информационной поддержки пользователей (функциональные возможности, готовые запросы и т.п.).
2. Определение требований к операционной обстановке, в которой будет функционировать информационная система. Раздел должен содержать: объём работы информационной системы; объём внешней памяти, занимаемый модулями СУБД; объём памяти, отводимой под данные; представление о характере и интенсивности запросов.
3. Выбор системы управления базой данных (СУБД).
Раздел должен содержать обоснование выбора СУБД для реализации требуемых функций системы и других инструментальных программных средств.
4. Логическое проектирование БД.
Раздел должен содержать: преобразование ER-диаграммы в схему БД; составление реляционных отношений; нормализацию полученных отношений (до 3НФ); окончательные схемы отношений БД с указанием ключей и других ограничений целостности.
5 . Физическое проектирование БД.
Раздел должен содержать ввод данных в таблицы - отношения; создание форм, отчетов, запросов; разработку средств защиты БД.
Заключение.
