Проектирование реляционной базы данных

Значит, для создания БД надо сначала проанализировать ПрО и создать

её модель (это называется инфологическим проектированием)
После создания модели ПрО определяются требования к операционной обстановке, выбор СУБД
Этап логического проектирования – ER-диаграмма формальным способом преобразуется в схему реляционной базы данных (РБД) (составление таблиц отношений, нормализация)
физическое проектирование полученных отношений, описываемых на языке DDL (Data definition language) – языке определения данных, который поддерживается выбранной СУБД

ПрО, характера информационных потребностей пользователей в терминах, понятных пользователю и

не зависимых от реализации БД.

Функциональный подход к проектированию БД ("от задач").
2. Предметный подход к

проектированию БД ("от предметной области").
3. Метод "сущность-связь" (entity–relation, ER–method).

накапливаться данные. Для сущности указывается название и тип (сильная или

слабая). Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных.

простые атрибуты.
Однозначные и многозначные атрибуты
Основные и производные атрибуты.
Обязательные и необязательные

к вычислительным ресурсам, необходимым для функционирования системы, определение типа и

конфигурации конкретной ЭВМ, выбор типа и версии операционной системы

таких критериев, как:
тип модели данных и её адекватность потребностям рассматриваемой

ПрО;
характеристики производительности;
набор функциональных возможностей;
удобство и надежность СУБД в эксплуатации;
стоимость СУБД и дополнительного программного обеспечения

структура БД.
Кроме получения схемы БД в целом на этом этапе

выполняют создание схем отношений и их нормализацию

т.е. физической структуры БД
Результаты этого этапа документируются в форме схемы

хранения на языке определения данных
Одной из важнейших составляющих проекта базы данных является разработка средств защиты БД

минимизации дублирования данных и упрощения процедур их обработки и обновления

сокращения избыточности. В ходе этого процесса неоптимальная таблица разбивается на

две и более таблиц, между которыми создаются отношения.
Нормализация является основой для удаления из сущностей нежелательных транзитивных и функциональных зависимостей

по значению некоторого другого атрибута. Например, зная название страны, можно

определить ее столицу. Следовательно, между страной и столицей имеется функциональная зависимость.

умолчанию находятся в первой нормальной форме.
Основные принципы первой нормальной формы
главный

‑ заключается в том, что любая запись таблицы должна содержать описание одной сущности,
второй – таблица должна иметь первичный ключ.
третий – ячейки не должны содержать групп значений. Если в ячейке содержится группа значений, то пропадает возможность осуществлять отбор записей отдельно по каждому из критериев

только тогда, когда на пересечении каждого столбца и каждой строки

находятся только элементарные значения атрибутов.

она находится в первой нормальной форме, а каждый ее неключевой

атрибут функционально полно зависит от ключа (или от каждого компонента первичного ключа – для таблиц с составными ключами, состоящими из двух и более атрибутов)

Таблица, в которой первичным ключом является один столбец, автоматически считается имеющей вторую нормальную форму

разбить его на проекции со схемами:
(ФИО, Номер зачетной книжки, Группа)

и
(Номер зачетной книжки, Дисциплина, Оценка).

находится во второй нормальной форме и все ее неключевые атрибуты

зависят только от первичного ключа и не зависят от других неключевых атрибутов.

находится в третьей нормальной форме и каждый детерминант отношения является

возможным ключом отношения

в каждом отделе могут работать несколько сотрудников.
– Каждый проект относится

к определённому отделу, каждый отдел может отвечать за выполнение нескольких проектов.
– Каждый сотрудник может принимать участие в выполнении нескольких проектов, над каждым проектом может трудиться несколько сотрудников.
– Для каждого проекта назначается руководитель из числа сотрудников того отдела, к которому относится проект.
– Каждый проект должен быть выполнен в заданные сроки, каждый проект может состоять из нескольких этапов. Если проект состоит из одного этапа, то сроки его выполнения должны совпадать со сроками выполнения проекта в целом.
– Оклад сотрудника зависит от занимаемой должности, за участие в проектах сотрудник получает дополнительное вознаграждение.
– Виды участия сотрудников в проектах: руководитель, консультант, исполнитель.
– Каждый отдел занимает одно или несколько помещений (комнат), в каждом помещении может быть один или несколько стационарных телефонов.

паспортные данные, дата рождения, пол, ИНН (индивидуальный номер налогоплательщика), номер

пенсионного страхового свидетельства, адреса, телефоны (рабочий, домашний, мобильный), данные об образовании (вид образования (высшее, среднеспециальное и т.д.), специальность, номер диплома, дата окончания учебного заведения), должность, оклад, логин (имя пользователя).

название проекта; дата подписания договора; заказчик; контактные данные заказчика; дата

начала проекта; дата завершения проекта; сумма по проекту; дата реальной сдачи проекта; сумма, полученная по проекту на текущую дату.
Этапы проекта. Атрибуты: номер по порядку, название, дата начала этапа, дата завершения этапа, форма отчетности, сумма по этапу, дата реальной сдачи этапа; сумма, полученная по этапу на текущую дату.

основные задачи и запросы к БД:
1. Руководители организации:
заключение новых договоров;
назначение

руководителей проектов;
получение списка всех участников проектов;
изменение должностных окладов и штатного расписания;
получение полной информации о проектах;
внесение изменений в данные о проектах;
архивирование данных по завершённым проектам.

основные задачи и запросы к БД:
2. Руководитель проекта:
назначение участников проекта;
получение

списка сотрудников, работающих над конкретным проектом;
получение полной информации о проекте, руководителем которого он является;
получение сведений о сотрудниках, которые могут стать участниками
проекта;
определение размера дополнительного вознаграждения сотрудников по
конкретному проекту;
внесение изменений в данные об этапах проекта.

основные задачи и запросы к БД:
3. Сотрудники отдела кадров:
приём/увольнение сотрудников;
внесение

изменений в данные о сотрудниках.
4. Бухгалтеры:
получение ведомости на выплату зарплаты.
5. Сотрудники – участники проектов:
просмотр данных о других участниках проекта;
просмотр данных о сроках сдачи проекта и форме отчётности.

(хотя бы ориентировочно) объём работы организации (т.е. количество проектов и

сотрудников), а также иметь представление о характере и интенсивности запросов.

для реализации требуемых функций подходят почти все СУБД для ПЭВМ

(MS Access, Firebird, MySQL и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными

создаётся на основании схемы базы данных

Фамилия и Имя, отчество, Паспортные данные на Номер паспорта (уникальный),

Дата выдачи и Кем выдан, а Данные об образовании – на Вид образования, Специальность, Номер диплома и Год окончания учебного заведения.
Многозначные атрибуты Комнаты и Телефоны из отношения ОТДЕЛЫ вынесем в отдельное отношение КОМНАТЫ, а домашние и мобильные телефоны и адреса сотрудников – в отношение АДРЕСА-ТЕЛЕФОНЫ.
Так как в комнате может не быть телефона, первичный ключ отношения КОМНАТЫ не определен (ПК не может содержать null–значения), но на этих атрибутах можно определить составной уникальный ключ. В отношении АДРЕСА-ТЕЛЕФОНЫ также нет потенциальных ключей: оставим это отношение без первичного ключа, т.к. на это отношение никто не ссылается.
Данные об образовании сотрудников также вынесем в отдельное отношение

чтобы дополнительные номера телефонов сотрудника можно было вычислить из других

кортежей с таким же номером комнаты.
Связь между отношениями СОТРУДНИКИ и КОМНАТЫ реализуем через составной внешний ключ (Номер комнаты, Рабочий телефон).
Мы также удалим вычислимый атрибут Полученная сумма из отношения ПРОЕКТЫ, т.к. он является суммой значений аналогичного атрибута из отношения ЭТАПЫ ПРОЕКТОВ.
Но атрибут Стоимость проекта оставим, т.к. она фигурирует в документации по проекту.

ПРОЕКТА и УЧАСТИЕ. Неключевые атрибуты этих отношений функционально полно зависят

от составных первичных ключей.
3НФ. В отношении ПРОЕКТЫ атрибут Данные заказчика зависит от атрибута Заказчик, а не от первичного ключа, поэтому его следует вынести в отдельное отношение ЗАКАЗЧИКИ.

из следующих значений: 'начальное', 'среднее', 'средне-специальное', 'высшее'.
2. Атрибут Роль может

принимать одно из двух значений: 'исполнитель' или 'консультант'.
3. В поле Доплата хранится величина доплаты сотруднику за участие в проекте (в процентах к его окладу). Значение поля больше либо равно 0.
4. Нумерация в поле Номер этапа начинается с 1 и является непрерывной для каждого проекта.
5. Дата начала первого этапа проекта должна соответствовать началу проекта в целом, дата завершения последнего этапа должна соответствовать завершению проекта в целом. Этапы не должны пересекаться по времени и между ними не должно быть разрывов.
6. Стоимость проекта должна быть равна сумме стоимостей всех этапов этого проекта.

ролей и прав доступа (grant)

или частичное), в какое время и т.д.