Н.В. Усманова - Проектирование баз данных (Методические указания по выполнению курсовой работы), страница 2

Создание модели предметной области.5. Определение групп пользователей и перечня задач, стоящихперед каждой группой.6. Выбор аппаратной и программной платформы для реализации БД.7. Создание логической схемы БД.8. Создание схем отношений, определение типов данных атрибутови ограничений целостности.9. Нормализация отношений (до третьей или четвёртой нормальнойформы).10. Определение прав доступа пользователей к объектам БД.11.

Написание текста создания основных объектов базы данных наязыке SQL в синтаксисе выбранной СУБД (пользователи, таблицы и др.).12. Написание текста создания вспомогательных объектов базыданных (представления, индексы, триггеры, роли и т.д.).Эти шаги можно объединить с 3 этапа: 1. Инфологическоепроектирование (1-6). 2. Логическое проектирование БД (7-10).

3.Физическое проектирование БД (11-12). На сегодняшний день несуществует формальных способов моделирования реальности, ноинфологическийподходзакладываетосновыметодологиипроектирования базы данных как модели предметной области.61.

Инфологическое проектированиеОсновными задачами этапа инфологического проектированияявляются определение предметной области системы и формированиевзгляда на неё с позиций сообщества будущих пользователей БД, т.е.информационно-логической модели ПрО.Инфологическая модель ПрО представляет собой описаниеструктуры и динамики ПрО, характера информационных потребностейпользователей в терминах, понятных пользователю и не зависимых отреализации БД. Это описание выражается в терминах не отдельныхобъектов ПрО и связей между ними, а их типов, связанных с нимиограничений целостности и тех процессов, которые приводят к переходуПрО из одного состояния в другое.Основными подходами к созданию инфологической моделипредметной области являются:1.

Функциональный подход к проектированию БД («от задач»).2. Предметный подход к проектированию БД («от предметнойобласти»).3. Метод «сущность-связь» (entity–relation, ER–method).Мы будем использовать метод «сущность–связь» как наиболеераспространённый (в нотации П. Чена). Приведём основные термины,которыми мы будем пользоваться:Сущность – это объект, о котором в системе будут накапливатьсяданные. Для сущности указывается название и тип (сильная или слабая).Сильные сущности существуют сами по себе, а существование слабыхсущностей зависит от существования сильных.Атрибут – свойство сущности. Различают:1) Идентифицирующиеиописательныеатрибуты.Идентифицирующие позволяют отличить один экземпляр сущности отдругого.

Описательные атрибуты заключают в себе интересующие нассвойства сущности.2) Составные и простые атрибуты. Простой атрибут имеетнеделимое значение. Составной атрибут является комбинациейнескольких элементов, возможно, принадлежащих разным типам данных(ФИО, адрес и др.).3) Однозначные и многозначные атрибуты (могут иметьсоответственно одно или много значений для каждого экземплярасущности). Например, дата рождения – это однозначный атрибут, а номертелефона – многозначный.4) Основные и производные атрибуты. Значение основногоатрибута не зависит от других атрибутов; значение производного атрибутавычисляется на основе значений других атрибутов. Например, возраствычисляется на основе даты рождения и текущей даты.75) Обязательные и необязательные (первые должны быть указаныпри размещении данных в БД, вторые могут не указываться).Для каждого атрибута необходимо определить название, указать типданных и описать ограничения целостности – множество значений,которые может принимать данный атрибут.Связь – это осмысленная ассоциация между сущностями.

Для связиуказывается название, тип (факультативная или обязательная),кардинальность (1:1, 1:n или m:n) и степень (унарная, бинарная, тернарнаяили n-арная).На рис. 1 приведены обозначения, которые мы будем использоватьв ER-диаграммах.Рис.1.

Обозначения, используемые в ER-диаграммахОпределение требований к операционной обстановкеПосле создания модели ПрО определяются требования коперационной обстановке. На этом этапе производится оценкатребований к вычислительным ресурсам, необходимым дляфункционирования системы, определение типа и конфигурацииконкретной ЭВМ, выбор типа и версии операционной системы. Объёмвычислительных ресурсов зависит от предполагаемого объёмапроектируемой базы данных и от интенсивности их использования.

ЕслиБД будет работать в многопользовательском режиме, то требуетсяподключение её к сети и наличие соответствующей многозадачнойоперационной системы.2. Логическое проектирование реляционной БДНа этапе логического проектирования разрабатывается логическая(концептуальная) структура БД. Для реляционной модели существуютформальные правила, которые позволяют преобразовать инфологическуюмодель ПрО в виде ER-диаграммы в логическую схему базы данных.Кроме получения схемы БД в целом на этом этапе выполняют созданиесхем отношений и их нормализацию.

Этот этап более подробнорассмотрен в Приложении 4 "Пример проектирования реляционной базыданных".Проектирование схемы БД должно решать задачи минимизациидублирования данных и упрощения процедур их обработки и обновления.При неправильно спроектированной схеме БД могут возникнутьаномалии модификации данных. Они обусловлены отсутствием средств8явного представления типов множественных связей между объектамиПрО и неразвитостью средств описания ограничений целостности науровне модели данных.Для решения подобных проблем проводится нормализацияотношений. Механизм нормализации реляционных отношенийразработал Э.Ф.

Кодд (E.F. Codd). Этот механизм позволяет поформальным признакам любое отношение преобразовать к третьейнормальной форме.Проектирование реляционной базы данных проходит в том жепорядке, что и проектирование БД других моделей данных, но имеет своиособенности. Проектирование схемы БД должно решать задачиминимизации дублирования данных и упрощения процедур их обработкии обновления. При неправильно спроектированной схеме БД могутвозникнуть аномалии модификации данных. Они обусловленыотсутствием средств явного представления типов множественных связеймежду объектами ПрО и неразвитостью средств описания ограниченийцелостности на уровне модели данных. Для решения подобных проблемпроводится нормализация отношений.

Механизм нормализацииреляционных отношений разработал Э.Ф. Кодд (E.F. Codd). Этотмеханизм позволяет по формальным признакам любое отношениепреобразовать к третьей нормальной форме.Нормализация схемы отношения выполняется путём декомпозициисхемы. Декомпозицией схемы отношения R называется замена еёсовокупностью схем отношений Аi таких, чтоR  U Aiiи не требуется, чтобы отношения Аi были непересекающимися.Первая нормальная форма относится к понятию простого исложного (составного или многозначного) атрибута.Первая нормальная форма (1НФ).Отношение приведено к 1НФ, если все его атрибуты простые.Для того чтобы привести к 1НФ отношение, содержащее сложныеатрибуты, нужно:1) разбить составные атрибуты на простые,2) построить декартово произведение всех многозначных атрибутовс кортежами, к которым они относятся.Для идентификации кортежа в этом случае понадобится составнойключ, включающий первичный ключ исходного отношения и всемногозначные атрибуты.Вторая нормальная форма основана на понятии функциональнойзависимости.

Пусть X и Y – атрибуты некоторого отношения. Если влюбой момент времени каждому значению X соответствует единственное9значение Y, то говорят, что Y функционально зависит от X (X→Y).Атрибут X в функциональной зависимости X→Y называетсядетерминантом отношения.В нормализованном отношении все неключевые атрибутыфункционально зависят от ключа отношения.

Неключевой атрибутфункционально полно зависит от составного ключа, если онфункционально зависит от ключа, но не находится в функциональнойзависимости ни от какой части составного ключа.Вторая нормальная форма (2НФ).Отношение находится во 2НФ, если оно приведено к 1НФ и каждыйнеключевой атрибут функционально полно зависит от составногопервичного ключа. (Таким образом, если отношение в 1НФ имеет простойпервичный ключ, оно сразу находится во второй нормальной форме).Для того чтобы привести отношение ко 2НФ, нужно:－ построить его проекцию, исключив атрибуты, которые не находятся вфункционально полной зависимости от составного первичного ключа;－ построить дополнительно одну или несколько проекций на частьсоставного ключа и атрибуты, функционально зависящие от этойчасти ключа.Третья нормальная форма основана на понятии транзитивнойзависимости.

Пусть X, Y, Z – атрибуты некоторого отношения. При этомX→Y и Y→Z, но обратное соответствие отсутствует, т.е. Z не зависит отY или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X(X→→Z).Третья нормальная форма (3НФ).Отношение находится в 3НФ, если оно находится во 2НФ и каждыйнеключевой атрибут нетранзитивно зависит от первичного ключа.Для того чтобы привести отношение к 3НФ, нужно:－ построить проекцию, исключив транзитивно зависящие от ключаатрибуты;－ построить дополнительно одну или несколько проекций надетерминанты исходного отношения и атрибуты, функциональнозависящие от них.Исключение составляют случаи, когда для транзитивнойзависимости X→→Z (X→Y и Y→Z) либо Z зависит от Y, либо Y зависитот X, т.е.

между атрибутами X и Y, например, существует связь 1:1. Втакой ситуации декомпозиция отношения не производится.Четвертая нормальная форма основана на понятии многозначнойзависимости. Многозначная зависимость существует, если заданнымзначениям атрибута X соответствует множество, состоящее из нуля (илиболее) значений атрибута Y (X–»Y).Различают тривиальные и нетривиальные многозначные10зависимости. Тривиальной называется такая многозначная зависимостьX–»Y, для которой Y  X или X U Y = R, где R – рассматриваемоеотношение. Тривиальная многозначная зависимость не нарушает 4НФ.Если хотя бы одно из двух этих условий не выполняется, то такаязависимость называется нетривиальной.Четвертая нормальная форма (4НФ).Отношение находится в 4НФ, если оно находится в 3НФ и в нёмотсутствуют нетривиальные многозначные зависимости.Для того чтобы привести отношение к 4НФ, нужно построить двеили более проекции исходного отношения, каждая из которых содержитключ и одну из многозначных зависимостей.3.

Физическое проектирование БДЭтап физического проектирования заключается в определениисхемы хранения, т.е. физической структуры БД. Схема хранения зависитот той физической структуры, которую поддерживает выбранная СУБД.Физическая структура БД, с одной стороны, должна адекватно отражатьлогическую структуру БД, а с другой стороны, должна обеспечиватьэффективное размещение данных и быстрый доступ к ним.