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

Руководитель проекта:· назначение участников проекта;· получение списка сотрудников, работающих над конкретным проектом;· получение полной информации о проекте, руководителем которого он является;· получение сведений о сотрудниках, которые могут стать участниками проекта;· определение размера дополнительного вознаграждения сотрудников поконкретному проекту;· внесение изменений в данные об этапах проекта.3. Сотрудники отдела кадров:· приём/увольнение сотрудников;· внесение изменений в данные о сотрудниках.4. Бухгалтеры:· получение ведомости на выплату зарплаты.215.

Сотрудники – участники проектов:· просмотр данных о других участниках проекта;· просмотр данных о сроках сдачи проекта и форме отчётности.1.3. Определение требований к операционной обстановкеДля выполнения этого этапа необходимо знать (хотя бы ориентировочно) объёмработы организации (т.е. количество проектов и сотрудников), а также иметьпредставление о характере и интенсивности запросов.Объём внешней памяти, необходимый для функционирования системы,складывается из двух составляющих: память, занимаемая модулями СУБД (ядро,утилиты, вспомогательные программы), и память, отводимая под данные (МД). Дляреальных баз данных обычно наиболее существенным является МД.На основе результатов анализа ПрО можно приблизительно оценить объём памяти,требуемой для хранения данных.

Примем ориентировочно, что:· одновременно осуществляется около десяти проектов, работа над проектомпродолжается в среднем год (по 1К на каждый проект);· каждый проект состоит в среднем из четырёх этапов (по 0,5К на этап);· в компании работают 100 сотрудников (по 0,5К на каждого сотрудника);· в выполнении каждого проекта в среднем участвуют 10 сотрудников (по 0,2К);· устаревшие данные переводятся в архив (накапливаются в архиве БД).Тогда объём памяти для хранения данных за первый год примерно составит:Mд = 2(10*1+10*4*0,5+100*0,5+(10*10*0,2)) = 200 К,Коэффициент 2 необходим для того, чтобы учесть необходимость выделенияпамяти под дополнительные структуры (например, индексы). Объём памяти будетувеличиваться ежегодно на столько же при сохранении объёма работы.Требуемый объём оперативной памяти определяется на основании анализаинтенсивности запросов и объёма результирующих данных.

Для нашей БД требуемыйобъём памяти мал, поэтому никаких специальных требований к объёму внешней иоперативной памяти компьютера не предъявляется.ГЛАВА 2. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫДАННЫХ2.1. Преобразование ER–диаграммы в схему базы данныхБаза данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибутысущностей (рис. 2).22Рис. 2. Уточнённая ER–диаграмма проектной организацииПримечание. Многозначные атрибуты на рисунке выделены подчеркиванием.Преобразование ER–диаграммы в схему БД выполняется путем сопоставлениякаждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы) БД. Связьтипа 1:n (один-ко-многим) между отношениями реализуется через внешний ключ.Ключ вводится для того отношения, к которому осуществляется множественная связь.Внешнему ключу должен соответствовать первичный или уникальный ключосновного (родительского) отношения.Связь участвовать между ПРОЕКТАМИ и СОТРУДНИКАМИ принадлежит ктипу n:m (многие-ко-многим).

Этот тип связи реализуется через вспомогательноеотношение Участие, которое содержит комбинации первичных ключейсоответствующих исходных отношений.Для схемы БД будем использовать обозначения, представленные на рис. 3.23Рис. 3. Обозначения, используемые на схеме базы данныхПолученная схема реляционной базы данных (РБД) приведена на рис. 4.Рис. 4. Схема РБД, полученная из ER–диаграммы проектной организацииБинарная связь между отношениями не может быть обязательной для обоихотношений.

Такой тип связи означает, что, например, прежде чем добавить новыйпроект в отношение ПРОЕКТЫ, нужно добавить новую строку в отношение ЭТАПЫ,и наоборот. Поэтому для такой связи необходимо снять с одной стороны условиеобязательности. Так как все эти связи будут реализованы с помощью внешнего ключа,снимем условие обязательности связей для отношений, содержащих первичныеключи.Схема на рисунке 4 содержит три цикла:－ «сотрудники–проекты–участие–сотрудники»;－ «отделы–сотрудники–проекты–отделы»;－ «отделы–сотрудники–участие–проекты–отделы».Цикл допустим только в том случае, если связи, входящие в него, независимы другот друга.

Например, для нашей ПрО справедливо такое правило: сотрудник любогоотдела может быть участником (исполнителем или консультантом) проекта любогоотдела. Эти связи независимы, поэтому цикл «отделы–сотрудники–участие–проекты–отделы» не будет приводить к нарушению логической целостности данных.С другой стороны, только сотрудник отдела, отвечающего за выполнение проекта,может быть руководителем проекта. Но система не помешает нам назначитьруководителем проекта сотрудника любого отдела. При добавлении проекта свнешним ключом Руководитель система проверит только, что такой человек есть втаблице СОТРУДНИКИ.

А значение внешних ключей Отдел в таблицахСОТРУДНИКИ и ПРОЕКТЫ сравнивать не будет.Таким образом, остальные циклы могут приводить к возможности нарушениялогической целостности данных. Существует несколько подходов для разрешенияситуаций, в которых связи, входящие в цикл, зависят друг от друга.24Рассмотрим эту ситуацию в общем случае. Сначала слегка упростим схему:реализуем связь «руководить» через таблицу УЧАСТИЕ – это позволит не отвлекатьсяна малозначительные детали.Будем считать, что в выполнении проекта могут участвовать только сотрудники,работающие в том же отделе, к которому относится проект (рис.

5,а). При циклическойсхеме СУБД не сможет гарантировать логическую целостность данных безиспользования дополнительных средств.Один из способов разрешения таких ситуаций – разорвать цикл, исключив одну изсвязей (рис. 5,б) или введя промежуточное отношение (рис. 5,в). В нашем случаеможно было бы разорвать связь «сотрудники–проекты», если бы каждый сотрудникучаствовал во всех проектах своего отдела. Промежуточное отношение можно былобы использовать, если бы существовала общая связь между сущностями, входящимив цикл.

Например, если бы каждый сотрудник заключал договор с отделом навыполнение работ в рамках проекта, то отношение ДОГОВОРЫ отражало бы связьмежду отделом, сотрудником и проектом.Рис.5. Некоторые способы разрешения циклов в схеме базы данныхДругой способ разрешения цикла заключается в том, что в промежуточноеотношение СОТРУДНИКИ – ПРОЕКТЫ, которое реализует связь многие-комногим,добавляются (мигрируют) внешние ключи Код отдела (D_id) из отношенийСОТРУДНИКИ и ПРОЕКТЫ (рис. 5,г). Эти ключи проверяются на равенство другдругу с помощью соответствующего ограничения целостности (check). Использованиеэтого способа возможно в том случае, когда соответствующие связи (отдел–проект иотдел–сотрудник) имеют тип один-ко-многим и являются обязательными.В тех ситуациях, когда все эти способы непригодны, логическая целостностьконтролируется программно или вручную. Если принято решение переложитьобязанности по контролю за логической целостностью данных на пользователя, то этиобязанности должны быть отражены в документации (в руководстве пользователя).25Примем для нашей ПрО, что руководитель проекта может одновременновыполнять и другие обязанности в этом проекте, чтобы цикл «сотрудники– проекты–участие–сотрудники» не приводил к возможности нарушения логической целостностиданных.

Зато цикл «отделы–сотрудники (руководители)–проекты–отделы» включаетзависимые связи: руководитель проекта назначается из того отдела, который отвечаетза выполнение проекта в целом. Здесь можно было бы применить разрыв связи«отделы–проекты» и определять, к какому отделу относится проект черезруководителя (по отделу руководителя проекта). Но такой подход в данном случаеимеет существенный недостаток. Заменив руководителя проекта сотрудником другогоотдела, можно одновременно изменить отдел, отвечающий за выполнение проекта, т.е.объединить в одно действие два независимых изменения, а это недопустимо.Исходя из вышесказанного, мы не будем разрывать связь, а примем решениереализовать эту проверку программно.

Приложение должно будет при назначениируководителя проекта выдавать список сотрудников того отдела, который отвечает завыполнение данного проекта. Руководителя можно будет выбрать только из этогосписка, а не вводить вручную.2.2. Составление реляционных отношенийКаждое реляционное отношение соответствует одной сущности (объекту ПрО) и внего вносятся все атрибуты этой сущности.

Для каждого отношения определяютсяпервичный ключ и внешние ключи (в соответствии со схемой БД). В том случае, еслибазовое отношение не имеет потенциальных ключей, вводится суррогатныйпервичный ключ, который не несёт смысловой нагрузки и служит только дляидентификации записей.Отношения приведены в табл. 1-5. Для каждого отношения указаны атрибуты с ихвнутренним названием, типом и длиной.

Типы данных обозначаются так: N –числовой, C – символьный тип фиксированной длины, V – символьный типпеременной длины, D – дата (этот тип имеет стандартную длину, зависящую от СУБД,поэтому она не указывается).Потенциальными ключами отношения ОТДЕЛЫ являются атрибутыАббревиатура и Название отдела. Первый занимает меньше места, поэтому мывыбираем его в качестве первичного ключа.Таблица 1. Схема отношения ОТДЕЛЫ (Departs)Содержание поляАббревиатура отделаНазвание отделаКомнатыТелефоныИмя поля Тип, длинаD_IDС(10)D_NAMEV(100)D_ROOMSV(20)D_PHONEV(40)Примечанияпервичный ключобязательное полеобязательное многозначное полеобязательное многозначное полеПотенциальными ключами отношения СОТРУДНИКИ являются поляПаспортные данные, ИНН и Номер страхового пенсионного свидетельства.

Все онизанимают достаточно много места, а паспортные данные кроме того могут меняться.Введём суррогатный первичный ключ Номер сотрудника.Таблица 2. Схема отношения СОТРУДНИКИ (Employees)Содержание поляНомерИмя поляE_IDТип, длинаПримечанияN(4)суррогатныйпервичныйключ26Фамилия, имя, отчествоДата рожденияПолПаспортные данныеИНННомер пенсионногостраховогосвидетельстваОтделДолжностьОкладE_NAMEE_BORNE_SEXE_PASPE_INNE_PENSV(50)DC(1)V(50)С(12)С(14)обязательное полеобязательное полеобязательное поле, 'м' или 'ж'обязательное полеобязательное полеобязательное уникальное полеE_DEPARTE_POSTE_SALС(10)V(30)N(8,2)Данные об образованииE_EDUV(200)АдресаТелефоныЛогинE_ADDRE_PHONEE_LOGINV(100)V(30)V(30)обязательное уникальное полеобязательное полеобязательное поле, > 12130руб.обязательноемногозначноеполемногозначное полемногозначное полеПримечание.