1.1.3 Требование к функциям бд.

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

Отчет должен содержать перечень функций базы.

1.4 Специальные требования по безопасности быстродействию, возможности многопоточной работы.

На данном этапе необходимо определить права доступа к базе каждой категории, определенной в п.п 1, характер обращений пользователей к базе (как много пользователей могут обратиться к базе одновременно , каков будет характер основной работы с базой).

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

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

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

Администрация будет иметь возможность работать и корректировать работу ломбарда «Джигурда» (для полного редактирования базы).

2. Специальные требования по безопасности, быстродействию, возможности многопоточной работы

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

Максимальные права для доступа к БД имеет администратор. Только он имеет право пополнять информацию в БД.

Прочие актеры при работе с БД не должны иметь прав на изменение информации. Права же на просмотр информации у них должны быть.

3. Анализ предметной области и определение сущностей и взаимосвязей

Для разрабатываемой базы можно выделить 1 сущность: изделие (номер изделия, вес изделия, материал изделия,).Основные сущности представлены на рисунке 3. НИЖЕ РИСУНОК

Между сущностями “Самолёт” и “Рейс” существует связь “многие ко многим”, так как один самолёт может совершать несколько рейсов. В тоже время один рейс могут совершать несколько самолётов.

Связь “один ко многим” будет связана с сущностью пассажиры по полю пассажиры.

Связь “один ко многим” будет связана с сущностью рейс по полю номер рейса.

Все оставшиеся связи будут “один к одному”.

4. Нормализация

Первая нормальная форма требует:

1. Предоставление информации в виде таблиц базы данных,

2. В таблицах не должно быть составных полей,

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

4. В таблицах не должно быть двух одинаковых записей.

Первая нормальная форма представлена на рисунке 4.

Рисунок 4 – первая нормальная форма

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

Произведем анализ смысловых зависимостей. В данной базе данных могут быть пассажиры с повторяющимися именами и фамилиями, поэтому чтобы исключить повторений в качестве первичного ключа для сущности «Пассажиры» будем использовать поле - № пассажира.

Для обеспечения удобства и простоты работы с базой данных, введем семантически незначащие первичные ключи. Ключевым полем в таблице «Пассажиры» будет № пассажира. В таблице «Должность» нет поля, которое бы однозначно определяло записи, поэтому вводится в качестве первичного ключа поле – код должности. В таблице «Билеты» в качестве ключевого поля можно выбрать поле № билета. В таблице «Самолёт» ключевым полем является – № самолета. В таблице «Рейс» ключевым полем является – № рейса. В таблице «Сотрудники» ключевым полем является семантически незначимое поле – код сотрудника.

Теперь все таблицы связаны. Во всех таблицах есть первичный ключ. Мы ввели семантически незначащие ключи для уменьшения избыточности по полям связи. Структура базы данных соответствует второй нормальной форме (рисунок 5).

Рисунок 5 – Вторая нормальная форма

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