Файл: Разработка бд для асу Московская доставка Курсовая работа Студента 4 курса дневного отделения группа Студент (подпись).docx

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

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

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• 
  Декомпозиция (разбиение);
  
• 
  Синтез;
  

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

• 
  каждой сущности ставится в соответствие отношение;
  
• 
  каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;
  
• 
  первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);
  
• 
  в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);
  
• 
  по умолчанию, все атрибуты, не входящие в PK, необязательны;
  
• 
  для отражения категоризации сущностей возможны несколько вариантов;
  
• 
  все связи М:М должны быть раскрыты
  

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

Клиенты:

• 
  Идентификатор клиента – int, NOT NULL, PK
  
• 
  Логин клиента – varchar(20), NOT NULL, UNIQUE
  
• 
  Hash пароля клиента – varchar(50), NOT NULL, UNIQUE
  
• 
  Имя клиента – varchar(45), NOT NULL, UNIQUE
  
• 
  Тип клиента – varchar(20), NOT NULL
  
• 
  Адрес клиента – varchar(45), NOT NULL
  
• 
  Контактный номер – varchar(15), UNIQUE
  
• 
  Электронный адрес – varchar(45), UNIQUE
  

Курьеры:

• 
  Идентификатор курьера – int, NOT NULL, PK
  
• 
  Логин курьера – varchar(20), NOT NULL, UNIQUE
  
• 
  Hash пароля курьера – varchar(50), NOT NULL, UNIQUE
  
• 
  Имя курьера – varchar(45), NOT NULL, UNIQUE
  
• 
  Дата рождения – date
  
• 
  Паспортные данные – varchar(100), NOT NULL, UNIQUE
  
• 
  Дата приема на работу – date, NOT NULL
  
• 
  Контактный номер - varchar(15), NOT NULL, UNIQUE
  

Менеджеры:

• 
  Идентификатор менеджера – int, NOT NULL, PK
  
• 
  Логин курьера – varchar(20), NOT NULL, UNIQUE
  
• 
  Hash пароля курьера – varchar(50), NOT NULL, UNIQUE
  
• 
  Имя курьера – varchar(45), NOT NULL, UNIQUE
  
• 
  Дата рождения – date
  
• 
  Паспортные данные – varchar(100), NOT NULL, UNIQUE
  
• 
  Дата приема на работу – date, NOT NULL
  
• 
  Контактный номер - varchar(15), NOT NULL, UNIQUE
  

---

Заказы:

• 
  Идентификатор заказа – int, NOT NULL, PK
  
• 
  Идентификатор клиента– int, FK, NOT NULL
  
• 
  Идентификатор курьера – int, FK, NOT NULL
  
• 
  Дата доставки - date
  
• 
  Метод оплаты – varchar(45), NOT NULL
  
• 
  Идентификатор точки самовывоза– int, FK
  
• 
  Идентификатор менеджера– int, FK, NOT NULL
  

Количество по позиции:

• 
  Идентификатор заказа – int, NOT NULL, PK
  
• 
  Идентификатор товара– int, FK, NOT NULL
  
• 
  Идентификатор заказа– int, FK, NOT NULL
  
• 
  Количество – int, NOT NULL
  

Товары:

• 
  Идентификатор товара – int, PK, NOT NULL
  
• 
  Название – varchar(45), NOT NULL, UNIQUE
  
• 
  Цена – int, NOT NULL
  
• 
  Описание– varchar(45)
  

Точки самовывоза:

• 
  Идентификатор точки – int, PK, NOT NULL
  
• 
  Адрес точки – varchar(45), NOT NULL
  

Склады:

• 
  Идентификатор склада – int, PK, NOT NULL
  
• 
  Адрес склада – varchar(45), NOT NULL
  

Исходя из приведенных отношений, построим даталогическую схему БД (рисунок 9):



Рисунок 9 – Даталогическая схема БД

---

2.4 Нормализация схемы базы данных

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

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

Таблица находится в первой нормальной форме, если каждый её атрибут атомарен, то есть может содержать только одно значение. Таким образом, не существует 1НФ таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1НФ обычно требуется разбить таблицу на несколько отдельных таблиц.

Отношение находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2НФ нет не ключевых атрибутов, зависящих от части составного ключа.

Отношение находится в третьей нормальной форме, если она находится во второй нормальной форме 2НФ и при этом любой ее не ключевой атрибут зависит только от первичного ключа. Таким образом, отношение находится в 3НФ тогда и только тогда

---

, когда оно находится во 2НФ и отсутствуют транзитивные зависимости не ключевых атрибутов от ключевых.

3НФ – отношение находится в 3НФ, если оно находится во 2НФ и не содержит транзитивных зависимостей. Все отношения данной модели находятся в 3НФ, т.к. ни в одном из них нет транзитивных зависимостей.

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

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

Выводы по главе 2

Во второй главе курсовой работы приведена разработка информационно-логической модели. Выделены сущности, дано их описание и построена инфологическая модель предметной области. Были описаны существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), указаны их достоинства и недостатки, и сделан выбор в пользу реляционной модели. На основании инфологической модели построена реляционная модель данных, дан список атрибутов ее отношений и проведена нормализация до третьей нормальной формы. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой информационной системы в одной из реляционных СУБД.

Глава 3. Программная реализация БД для курьерской службы “Московская доставка”

В данной главе проведем анализ и выбор СУБД для реализации базы данных курьерской службы “Московская доставка”. Она содержит 9 таблиц, которые будут спроектированы в разделе Физическое проектирование БД. Также будут показаны скриншоты готовых таблиц. В конце главы будут приведены 3 триггера для данной базы.

3.1 Анализ и выбор СУБД

Основываясь на данных, полученных в пункте 1.2 данной работы, можно сделать вывод, что для реализации данной базы данных, необходимо использовать профессиональную СУБД, так как объект автоматизации является средним бизнесом. Таким образом, итоговый выбор был сделан в пользу Oracle Database, так как она предоставляет широкие возможности и может быть использована бизнесами от малых до больших. Некоторые особенности Oracle Database:

---

• 
  Позволяет работать с удаленной базой данных, что дает возможность осуществлять доступ к одной базе с разных компьютеров в учебном заведении;
  
• 
  Поддерживает одновременную работу сразу нескольких пользователей с базой данных;
  
• 
  Предоставляет высокий уровень защиты данных;
  
• 
  Обладает невысокими требованиями к аппаратной части серверов;
  
• 
  Позволяет создавать БД любых масштабов
  

---