Курсовая работа
по дисциплине
«Базы данных и СУБД»
Разработка приложения для учета торговых операций магазина музыкальных товаров
Выполнил:
студент 394-1 группы
Самборецкий Станислав Сергеевич
Проверил:
ст.преподаватель кафедры
Программного обеспечения
Ялдыгин Валерий Борисович
Тюмень 2011
Оглавление
Оглавление. 2
ГЛАВА 1. Описание предметной области. Постановка задачи. 3
ГЛАВА 2. Нормализация. 4
ГЛАВА 3. Особенности реализации. 10
Приложение. Описание таблиц. 11
ГЛАВА 1. Описание предметной области. Постановка задачи
Магазин музыкальных товаров занимается продажей музыкальных инструментов и сопутствующих товаров, все, что необходимо музыкантам, развлекательным центрам и домам культуры: от музыкальных инструментов до световой и звуковой аппаратуры.
Товары магазин закупает у поставщиков, продукция продается по цене, рассчитанной из стоимости партии, в которой она была доставлена в магазин.
Продажей товара в магазине занимаются продавцы, у них есть модификаторы, по которым вычисляются комиссионные с продаж. Продавец за одну операцию продажи может продать несколько товаров разных типов. Продавцы также могут совершать предварительный заказ, покупатель получит данный товар при поступлении его на склад.
Клиентам предоставляется возможность обладания дисконтной картой, позволяющей совершать покупки со скидкой. Скидка накопительная, по мере накопления определенного количества покупок карта меняется на другую с более высоким процентом.
Стоящая передо мной задача: автоматизировать процесс учета реализации продукции магазина с помощью приложения, использующего реляционную Базу Данных.
ГЛАВА 2. Нормализация
Предположим, для хранения информации о проданных товарах нам необходима таблица с полями:
ТАБЛИЦА 1. Пример ненормализованной таблицы для данной задачи
| OrdedID | InstId | InstName | InstType | Count | Cost | DiscontId | Discont | Saler |
| Fender Strat D'Addario ProSteels | Гитара Струны | - | - | Иванов Иван | ||||
| Gibson Les Paul RotoSound BS9 | Гитара Струны | 5% | Петров Петр |
В данной таблице возникают следующие аномалии.
· Аномалии вставки. При добавлении проданного товара необходимо указывать всю информацию о товаре (наименование, тип). Также непонятно, как учитывать новый товар, ранее не поставлявшийся в магазин.
· Аномалии удаления. Удаление товаров определенного типа приводит к удалению заказов.
· Аномалии модификации. При попытке изменения значения одного из атрибутов для некоторого товара необходимо обновить соответствующие значения в строках для всех заказов с этим товаром. Если такой модификации будут подвергнуты не все требуемые строки данного отношения, база данных будет содержать противоречивые сведения.
Для того, чтобы устранить эти аномалии, необходимо привести отношение к Нормальной Форме Бойса-Кодда.
Первая нормальная форма (1НФ) – отношение, в котором на пересечении каждой строки и каждого столбца содержится одно и только одно значение.
Данное отношение мы можем привести к 1НФ, создав сложный первичный ключ, состоящий из столбцов Номер заказа и Номер товара. Данная пара будет уникальной при определенных заказчиком условиях.
ТАБЛИЦА 2. Отношение, соответствующее 1НФ
| OrdedID | InstId | InstName | InstType | Count | Cost | DiscontId | Discont | Saler |
| Fender Strat | Гитара | - | - | Иванов Иван | ||||
| D'Addario ProSteels | Струны | - | - | Иванов Иван | ||||
| Gibson Les Paul | Гитара | 5% | Петров Петр | |||||
| RotoSound BS9 | Струны | 5% | Петров Петр |
Необходимо ввести следующие определения.
Функциональная зависимость. Описывает связь между атрибутами отношения. Если в отношении R, содержащем атрибуты А и В, атрибут B функционально зависит от атрибута А, то каждое значение атрибута А связано только с одним значением атрибута B (Атрибуты A и B могут состоять из одного или нескольких атрибутов).
Детерминантом функциональной зависимости называется минимальная группа атрибутов, от которой зависит некоторый другой атрибут или группа атрибутов.
Полная функциональная зависимость. Если А и B – атрибуты отношения, то атрибут B находится в полной функциональной зависимости от атрибута А, если атрибут B является функционально зависимым от А, но не зависит ни от одного собственного подмножества атрибута A.
Вторая нормальная форма (2НФ) – отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.
Данное отношение не соответствует 2НФ: Атрибуты Тип Товара и Наименование Товара зависят от части первичного ключа Номер товара. Приведение в соответствие 2НФ заключается в следующем: Атрибуты, которые не могут быть выражены полной функциональной зависимостью в данном отношении, переносятся в другие таблицы. В итоге мы получаем таблицы:
Sells - таблица, содержащая сложный первичный ключ из атрибутов Номер заказа и Номер товара. Атрибуты, выраженные полной функциональной зависимостью: Количество и Завершенность заказа.
ТАБЛИЦА 3. Отношение Sells, соответствующее 2НФ
| OrdedID | InstId | Count | Complete |
Orders - таблица с первичным ключом Номер Заказа, имеющая атрибуты: Номер дисконтной карты, Данные о Владельце Дисконтной карты, Дата Совершения Покупки, Фамилия, Имя, Модификатор Продавца, совершившего операцию.
ТАБЛИЦА 4. Отношение Orders, соответствующее 2НФ
| OrdedID | DiscontId | OwnerFName | OwnerLName | Discont | Date | SalerId |
| - | - | - | - | 21.11.2011 | ||
| Александр | Розенбаум | 5% | 22.11.2011 |
InstrumentsList - Таблица с первичным ключом Номер Товара, имеющая атрибуты: Наименование, Описание, Тип Товара.
ТАБЛИЦА 5. Отношение InstrumentsList, соответствующее 2НФ
| InstrumentID | Name | Description | Type | ||
| Fender Strat | Гитара Fender Stratocaster, произведено в США | Гитара | |||
| D'Addario ProSteels | Сверхтонкие струны (9-42) для электрогитары | Струны | |||
| Gibson Les Paul | Легендарная гитара | Гитара | |||
| RotoSound BS9 | Отличные струны от британского производителя | Струны | |||
Транзитивная зависимость. Если для атрибутов А, B и C некоторого отношения существуют зависимости вида A→B и B→C, это означает, что атрибут C транзитивно зависит от атрибута А через атрибут B (при условии, что атрибут А функционально не зависит ни от атрибута B, ни от атрибута C). Транзитивная зависимость является одним из типов функциональной зависимости.
Третья нормальная форма (ЗНФ). Отношение, которое находится в первой и во второй нормальных формах и не имеет атрибутов, не входящих в первичный ключ, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа. По-другому можно сформулировать так: отношение находится в 3НФ в том и только том случае, если все не ключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.
Таблицы Orders и InstrumentsList не соответствуют 3НФ. Для приведения и в соответствие, необходимо часть информации перенести в другие таблицы. Таким образом образуются следующие таблицы:
TypeList - таблица, хранящая типы музыкальных инструментов.
ТАБЛИЦА 6. Отношение TypeList, полученное при приведении InstrumentsList к 3НФ
| TypeID | TypeName |
| Гитара | |
| Струны |
SalersList - таблица, хранящая данные о продавцах.
ТАБЛИЦА 7. Отношение SalersList, полученное при приведении Orders к 3НФ
| SalerID | FirstName | LastName | Modificator |
| Иван | Иванов | 0,05 | |
| Петр | Петров | 0,07 |
DiscontOwners - таблица, хранящая данные о владельцах дисконтных карт. Также для приведения этой таблицы к 3НФ, необходимо создать ещё одну таблицу.
DiscontTypes - таблица со скидками.
ТАБЛИЦА 8. Отношение DiscontOwners, полученное при приведении Orders к 3НФ
| DiscontID | OwnerFName | OwnerLName | SellCount | TypeID | PredDiscont |
| Александр | Розенбаум | - | |||
| Александр | Розенбаум |
ТАБЛИЦА 9. Отношение DiscontTypes, полученное при приведении Orders к 3НФ
| TypeID | TypeName |
| 0,95 | |
| 0,93 |
Нормальная форма Бойса-Кодда (НФБК). Определение для 3НФ предполагает, что отношение имеет только один потенциальный ключ (а именно первичный ключ). В связи с этим было дано более строгое определение, учитывающее возможное наличие нескольких потенциальный ключей. Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом. В нашем случае во все полученные отношения соответствуют НФБК.
В итоге нормализации была получена следующая База Данных.
Рис. 1 - Диаграмма Базы данных типа «Сущность-связь» (нотация IDEF1X)
ГЛАВА 3. Особенности реализации.
База данных была создана с помощью Системы Управления Базами Данных Microsoft SQL Server 2008 R2.
Приложение было написано на языке C# в среде разработки Visual Studio 2010 с использованием технологии ADO.NET.
Приложение. Описание таблиц
1. DealersList - Таблица, содержащая информацию о поставщиках.
| Поле | Тип | Комментарий |
| InstrumentId | INTEGER | Идентификатор поставщика (Первичный ключ) |
| CompanyName | NVARCHAR(50) | Наименование Компании-Поставщика |
2. InstumentsList - таблица, содержащая информацию о товарах
| Поле | Тип | Комментарий |
| DealerId | INTEGER | Идентификатор товара (Первичный ключ) |
| Name | NVARCHAR(50) | Наименование товара |
| Description | NVARCHAR(MAX) | Описание товара (может отсутствовать) |
| TypeId | INTEGER | Тип товара (внешний ключ) |
3. TypeList - таблица с видами продукции
| Поле | Тип | Комментарий |
| TypetId | INTEGER | Идентификатор типа (Первичный ключ) |
| TypeName | NVARCHAR(50) | Название типа товара |
4. Supplies - таблица с информацией о поставках
| Поле | Тип | Комментарий |
| SupplyId | INTEGER | Идентификатор поставки (Первичный ключ) |
| DealerId | INTEGER | Идентификатор поставщика (внешний ключ) |
| InstrumentId | INTEGER | Идентификатор товара (внешний ключ) |
| Count | INTEGER | Количество товара в партии |
| Sum | MONEY | Общая стоимость партии |
| Date | DATE | Дата поставки |
5. Prices - таблица с ценами на товар
| Поле | Тип | Комментарий |
| PriceId | INTEGER | Идентификатор Цены (Первичный ключ) |
| InstrumentId | INTEGER | Идентификатор товара (внешний ключ) |
| DateFrom | DATE | Дата установки цены |
| Value | MONEY | Цена |
6. Sells - таблица продаж
| Поле | Тип | Комментарий |
| OrderId | INTEGER | Идентификатор заказа (Внешний ключ, часть Первичного ключа) |
| InstrumentId | INTEGER | Идентификатор товара (Внешний ключ, часть Первичного ключа) |
| Count | INTEGER | Количество товара |
| Complete | Byte | Завершенность заказа (0 - не завершен, 1 - завершен) |
7. Orders - таблица информации по заказам
| Поле | Тип | Комментарий |
| OrderId | INTEGER | Идентификатор заказа (Первичный ключ) |
| Discont | INTEGЕR | Идентификатор дисконтной карты (может отсутствовать, внешний ключ) |
| Date | DATE | Дата совершения заказа |
| SalerId | INTEGER | Идентификатор продавца (внешний ключ) |
8. DiscontOwners - таблица с информацией о держателях дисконтных карт
| Поле | Тип | Комментарий |
| DiscontId | INTEGER | Идентификатор карты (Первичный ключ) |
| OwnerFName | NVARCHAR(50) | Имя держателя |
| OwnerLName | NVARCHAR(50) | Фамилия держателя |
| SellCount | INTEGER | Количество совершенных покупок |
| TypeId | Integer | Тип карты (Внешний ключ) |
| PredDiscont | Integer | Предыдущая карта держателя (внешний ключ, ссылается на эту же таблицу, может отсутствовать) |
9. DiscontTypes - таблица со скидками
| Поле | Тип | Комментарий |
| TypetId | INTEGER | Идентификатор типа (Первичный ключ) |
| Discont | Real | Скидка (вещественное число от 0 до 1 с 2-мя знаками после запятой) |
10. SalerList - список продавцов
| Поле | Тип | Комментарий |
| SalerId | INTEGER | Идентификатор (Первичный ключ) |
| FirstName | NVARCHAR(50) | Имя продавца |
| LastName | NVARCHAR(50) | Фамилия |
| Modificator | Real | Комиссионные с продажи |