Курсовое_проектир методич указания. Методические указания к курсовому проектированию по курсу "Базы данных" Составитель
 Скачать 340.75 Kb.
|
|
1.3. Особенности проектирования реляционной базы данных Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности. Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Они обусловлены отсутствием средств явного представления типов множественных связей между объектами ПрО и неразвитостью средств описания ограничений целостности на уровне модели данных. Для решения подобных проблем проводится нормализация отношений. Механизм нормализации реляционных отношений разработал Э.Ф. Кодд (E.F. Codd). Этот механизм позволяет по формальным признакам любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы. Декомпозицией схемы отношения R называется замена её совокупностью схем отношений Аi таких, что  ,и не требуется, чтобы отношения Аi были непересекающимися. Первая нормальная форма относится к понятию простого и сложного (составного или многозначного) атрибута (см. п.1.2.1). Первая нормальная форма (1НФ). Отношение приведено к 1НФ, если все его атрибуты простые. Для того чтобы привести к 1НФ отношение, содержащее сложные атрибуты, нужно: разбить составные атрибуты на простые, построить декартово произведение всех многозначных атрибутов с кортежами, к которым они относятся. Для идентификации кортежа в этом случае понадобится составной ключ, включающий первичный ключ исходного отношения и все многозначные атрибуты. Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y – атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует единственное значение 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). Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X–»Y, для которой Y ⊂ X или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется, то такая зависимость называется нетривиальной. Четвертая нормальная форма (4НФ). Отношение находится в 4НФ, если оно находится в 3НФ и в нём отсутствуют нетривиальные многозначные зависимости. Для того чтобы привести отношение к 4НФ, нужно построить две или более проекции исходного отношения, каждая из которых содержит ключ и одну из многозначных зависимостей. Описание этого метода достаточно подробно изложено в [1], поэтому, чтобы не повторяться, будем рассматривать этот метод на примере проектирования конкретной базы данных. 2. ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ В качестве примера возьмем базу данных проектной организации. Основной вид деятельности такой организации – выполнение проектов по договорам с заказчиками. 2.1. Инфологическое проектирование 2.1.1. Анализ предметной области База данных создаётся для информационного обслуживания руководства организации, руководителей проектов и участников проектов. БД должна содержать данные об отделах организации, сотрудниках и проектах. В соответствии с предметной областью система строится с учётом следующих особенностей: Каждый сотрудник работает в определённом отделе, в каждом отделе могут работать несколько сотрудников. Каждый проект относится к определённому отделу, каждый отдел может отвечать за выполнение нескольких проектов. Каждый сотрудник может принимать участие в выполнении нескольких проектов, над каждым проектом может трудиться несколько сотрудников. Для каждого проекта назначается руководитель из числа сотрудников того отдела, к которому относится проект. Каждый проект должен быть выполнен в заданные сроки, каждый проект может состоять из нескольких этапов. Если проект состоит из одного этапа, то сроки его выполнения должны совпадать со сроками выполнения проекта в целом. Оклад сотрудника зависит от занимаемой должности, за участие в проектах сотрудник получает дополнительное вознаграждение. Виды участия сотрудников в проектах: руководитель, консультант, исполнитель. Каждый отдел занимает одно или несколько помещений (комнат), в каждом помещении может быть один или несколько стационарных телефонов. Примечание. Описания особенностей ПрО должно быть достаточно для того, чтобы создать ER–диаграмму. Для создания ER-модели необходимо выделить сущности предметной области: Отделы. Атрибуты: название, аббревиатура, комнаты, телефоны. Сотрудники. Атрибуты: ФИО, паспортные данные, дата рождения, пол, ИНН (индивидуальный номер налогоплательщика), номер пенсионного страхового свидетельства, адреса, телефоны (рабочий, домашний, мобильный), данные об образовании (вид образования (высшее, средне-специальное и т.д.), специальность, номер диплома, дата окончания учебного заведения), должность, оклад, логин (имя пользователя). Примечания: 1. Логин потребуется нам для назначения дифференцированных прав доступа. 2. В нашем задании не предусмотрена полная информационная поддержка сотрудников отдела кадров, поэтому мы не будем отражать в БД такие сведения как дату поступления сотрудника на работу, его переводы с одной должности на другую, уходы в отпуска и т.п. Проекты. Атрибуты: номер договора; полное название проекта; сокращённое название проекта; дата подписания договора; заказчик; контактные данные заказчика; дата начала проекта; дата завершения проекта; сумма по проекту; дата реальной сдачи проекта; сумма, полученная по проекту на текущую дату. Этапы проекта. Атрибуты: номер по порядку, название, дата начала этапа, дата завершения этапа, форма отчетности, сумма по этапу, дата реальной сдачи этапа; сумма, полученная по этапу на текущую дату. Исходя из выявленных сущностей, построим ER–диаграмму (рис. 2). Напомним, что пометки у линий означают степень связи: 1:1, 1:N и N:M.  Рис. 2. ER–диаграмма ПрО «Проектная организация» 2.1.2. Анализ информационных задач и круга пользователей системы Определим группы пользователей, их основные задачи и запросы к БД: Руководители организации: заключение новых договоров; назначение руководителей проектов; получение списка всех участников проектов; изменение должностных окладов и штатного расписания; получение полной информации о проектах; внесение изменений в данные о проектах; архивирование данных по завершённым проектам. Примечание. Архивирование данных в этом пособии подробно не рассматривается. Это сделано для того, чтобы не перегружать схему БД. Руководитель проекта: назначение участников проекта; получение списка сотрудников, работающих над конкретным проектом; получение полной информации о проекте, руководителем которого он является; получение сведений о сотрудниках, которые могут стать участниками проекта; определение размера дополнительного вознаграждения сотрудников по конкретному проекту; внесение изменений в данные об этапах проекта. Сотрудники отдела кадров: приём/увольнение сотрудников; внесение изменений в данные о сотрудниках. Бухгалтеры: получение ведомости на выплату зарплаты. Сотрудники – участники проектов: просмотр данных о других участниках проекта; просмотр данных о сроках сдачи проекта и форме отчётности. |