Методическое пособие по выполнению курсовой работы (проекта) по междисциплинарному курсу мдк 04. 01 «Технология разработки и защиты базы данных»
Построение логической модели, схемы базы данных
жүктеу/скачать 380,1 Kb.
|
6de276100d4c3cb0
- Бұл бет үшін навигация:
- 1.2.5.1.4 Выбор СУБД
| 1.2.5.1.3 Построение логической модели, схемы базы данных
Необходимо дать понятие, цель логического проектирования. Логическое проектирование БД, то есть описание БД в терминах принятой логической модели данных. Результат – схема реляционной БД. Необходимо обосновать выбор ключевых и внешних полей, способов связи между таблицами (в реляционной модели). Проверить нормализацию спроектированных таблиц. В случае необходимости нормализовать до 3 НФ. На этапе логического проектирования разрабатывается логическая структура БД, соответствующая логической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Будем рассматривать логическое проектирование БД для реляционной модели данных, так как современные СУБД – реляционные. Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Они обусловлены отсутствием средств явного представления типов множественных связей между объектами ПО и неразвитостью средств описания ограничений целостности на уровне модели данных. На этом этапе выполняются следующие действия: удаление связей M:N; удаление рекурсивных связей; удаление связей с атрибутами; удаление множественных атрибутов; перепроверка связей типа 1:1; удаление избыточных связей. Далее выполняется нормализация отношений. В рамках реляционной модели данных Э. Ф. Коддом (E. F. Codd) был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация отношений выполняется на основе анализа первичных ключей и существования функциональных зависимостей между атрибутами. Как правило нормализация выполняется в несколько этапов. Каждый этап соответствует определенной нормальной форме (НФ). При проектировании реляционных баз данных требование первой нормальной формы (1НФ) должны выполняться всегда, остальные по желанию проектировщика. Однако, чтобы исключить аномалии обновления и избыточность данных рекомендуется приводить отношение к третьей нормальной форме 3НФ. Требование 1НФ: все атрибуты должны быть атомарными. Ненормализованное отношение приводится к 1НФ следующими способами: выравнивание таблиц или добавление строк; один атрибут или группа атрибутов, которые назначены ключом отношения повторяющейся группы, помещается в отдельные отношения. Во вновь созданных отношениях устанавливаются свои первичные ключи. Требование 2НФ: отношение удовлетворяет 1НФ и каждый атрибут, который не входит в состав первичного ключа, функционально полно зависит от первичного ключа. Функциональная зависимость описывает связь между атрибутами отношения R(A,B) и обзначается. Атрибут (группа атрибутов) А называется детерминантом. Полная функциональная зависимость означает, что если атрибут В функционально зависит от первичного ключа, то зависит от полного его значения, а не какого-то подмножества. 2НФ применяется к отношениям с составными ключами. Для того чтобы привести отношение ко 2НФ, нужно исключить из отношения частичную зависимость и поместить ее в новое отношение вместе с копией их детерминанта. Требование 3НФ: Отношение находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Если в отношении R(A, B, C) имеют место следующие функциональные зависимости: А -> B и B -> C, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В. Для того чтобы привести отношение к 3НФ, нужно исключить из отношения транзитивную зависимость, поместив ее с новое отношение вместе с копией детерминанта. Процесс нормализации заключается в декомпозиции отношения посредством выполнения последовательных операций проекции. На этапе логического проектирования необходимо определить требования поддержки целостности данных. Ограничения целостности представляют собой ограничения, которые вводятся с целью предотвращения ввода в базу данных противоречивых данных. Различают следующие пять типов ограничений целостности: обязательные данные; ограничения для доменов атрибутов; целостность сущностей; ссылочная целостность; требования данного пользователя. 1.2.5.1.4 Выбор СУБД Необходимо выбрать СУБД для реализации базы данных, спроектированной на основе выбранной модели данных, обосновать свой выбор. Для начинающих пользователей предлагается проектируемую базу данных создать локальной, однопользовательской. жүктеу/скачать 380,1 Kb. Достарыңызбен бөлісу:
|