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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Физическое проектирование БД “Московская доставка”

На основе реляционной модели произведена программная реализация. База данных содержит 9 таблиц:

• 
  Товары
  
• 
  Клиенты
  
• 
  Склады
  
• 
  Курьеры
  
• 
  Точки самовывоза
  
• 
  Менеджеры
  
• 
  Заказы
  
• 
  Количество по позиции
  
• 
  Промежуточная таблица “товары к сладам”, реализующая связь многие ко многим между данными таблицами
  

Р исунок 10 – Таблица клиентовРисунок 11 – Таблица курьеров Рисунок 12 – Таблица менеджеров Рисунок 13 – Таблица товаров Рисунок 14– Таблица точек самовывоза Рисунок 15 – Таблица складовР исунок 16 – Таблица товары к складамРисунок 17 – Таблица заказовРисунок 18 – Таблица количества по позиции

3.3 Реализация ограничений

С базой могут работать курьеры, менеджеры и клиенты. Курьеры и менеджеры могут просматривать заказы, распределенные на них. Клиенты могут оформлять заказы и видеть информацию о них.Для того, чтобы удалять товары, если они не хранятся ни на одном из складов, создадим триггер: CREATE OR REPLACE TRIGGER noProduct

BEFORE DELETE ON Warehouses FOR EACH ROWDECLARE CURSOR productOnDelete IS SELECT Products.Product_ID FROM Products MINUS (SELECT Product_to_warehouse.Product_ID FROM Product_to_warehouse GROUP BY Product_to_warehouse.Product_ID);BEGIN DELETE FROM Product_to_warehouse WHERE Warehouse_ID = :old.Warehouse_ID; FOR prod IN productOnDelete LOOP DELETE FROM Products WHERE Product_ID = prod.Product_ID; END LOOP;END;/Для того, чтобы назначать заказам менеджера, создадим триггер: CREATE OR REPLACE TRIGGER giveManagerBEFORE INSERT ON Orders FOR EACH ROWDECLARE managerID int(5) := 10000 ; managerOrders int(5) := 10000 ; CURSOR managerChoose IS SELECT Manager_ID, COUNT(*) AS MOrders FROM Orders GROUP BY Manager_ID;BEGIN FOR man IN managerChoose LOOP IF man.MOrders < managerOrders THEN BEGIN managerID := man.Manager_ID; managerOrders := man.MOrders; END; END IF; END LOOP;:new.Manager_ID := managerID;END;/Для того, чтобы назначать заказам курьера, создадим триггер:CREATE OR REPLACE TRIGGER giveCourierBEFORE INSERT ON Orders FOR EACH ROWDECLARE courierID int(5) := 10000 ; courierOrders int(5) := 10000 ; CURSOR courierChoose IS SELECT Courier_ID, COUNT(*) AS MOrders FROM Orders GROUP BY Courier_ID;BEGIN FOR cur IN courierChoose LOOP IF cur.MOrders < courierOrders THEN BEGIN courierID := cur.Courier_ID; courierOrders := cur.MOrders; END; END IF; END LOOP;:new.Courier_ID := courierID;END;/

3.4 Безопасность и контроль

Средства безопасности в Oracle можно разделить на две категории:

• 
  Безопасность доступа.
  
• 
  Безопасность данных.
  

Безопасность доступа.В Oracle имеется целый ряд механизмов для идентификации и верификации пользователей. Самый простой из них – обязательное указание пользователем своих имени и пароля при каждом подключении. Эта верификация должна выполняться независимо от того, какое внешнее интерфейсное средство используется для доступа к базе данных. Идея состоит в том, чтобы допустить пользователей к работе со средствами базы данных только после того, как он установит санкционированное соединение с ней. Имя пользователя и пароль сверяются с указанными в таблице SYS.USERS, куда пароль заносится в зашифрованной форме.В большинстве приложений баз данных существуют разные категории пользователей, которые работают с разными частями системы и имеют разные права на просмотр и изменение данных. В простом случае может быть всего два класса пользователей: те, кто вводит данные, и менеджеры, выполняющие запросы к данным. Но в большинстве случаев существует несколько категорий пользователей, и функциональные возможности, к которым они должны иметь доступ, пересекаются. В таких