Постановка задачи
Программа «Сайт магазина игровых приставок» была создана для того, чтобы пользователь, в данном случае администратор магазина, имел возможность изменения, удаления или редактирования БД вне зависимости от того, где он находится.
В данной курсовой работе необходимо разработать программу, в которой обработка данных организована в виде реляционной базы данных. Наиболее важным требованием является формирование таблиц реляционной базы данных в соответствии с третьей нормальной формой нормализации отношений.
Для реализации поставленной задачи необходимо:
Рассмотреть функции, которыми должна обладать программа.
Сделать анализ выбранной предметной области, а именно «Сайт игровых приставок» и на его основе создать данные, из которых будет состоять БД.
Разработать БД, пройти все 4 стадии ее проектирования.
С помощью SQL запросов, сформировать доступ к изменениям данных в БД.
Реализовать программу «Сайт магазина игровых приставок». Программа должна иметь графический интерфейс и содержать техническую документацию.
Описание предметной области и обзор подходов к решению задачи
На сегодняшний день индустрия игр и игровых приставок набирают все большую популярность. В след за разработкой мощных процессоров, звуковых и графических карт, Unix, CD- и DVD-приводов развилась и игровая индустрия. С каждым годом приставки становятся все мощнее и создают огромную конкуренцию персональным компьютерам, игры, создаваемые для консолей с каждым годом, становятся все более и более реалистичными [1]. Последней разработкой в сфере игровых консолей является так называемая «виртуальная реальность».
Виртуальная реальность – это созданный техническими средствами мир, передаваемый человеку через его ощущения: зрение, слух, обоняние, осязание и другие. Виртуальная реальность имитирует как воздействие, так и реакции на воздействие. Для создания убедительного комплекса ощущений реальности компьютерный синтез свойств и реакций виртуальной реальности производится в реальном времени [2].
Поскольку развивается разработка игр и платформ, которые их воспроизводят, развивается и их торговля. Продажа игровых консолей осуществляется как удаленно, через официальные сайты разработчиков или интернет-магазины, так и через официальные магазины и магазины, специализирующиеся на продаже электроники. Именно для удаленной продажи игровых консолей и разработана программа «Сайт магазина игровых приставок».
С помощью разработанной программы администратор интернет-магазина будет иметь возможность удобно отслеживать все данные, которые имеются на сайте, это могут быть и списки поставщиков, и списки пользователей, и списки всего имеющего товара. Также с помощью этой программы пользователей будет иметь возможность редактировать, добавлять или создавать самостоятельно записи, имеющиеся в БД интернет-магазина.
Проектирование базы данных «сайт игровых приставок»
Для разработки программы «Сайт игровых приставок» была создана база данных, которая в зависимости от требований пользователя состоит из 5-ти таблиц, а именно из таблиц «Категории», «Товар», «Заказ», «Покупатель» и «Производитель».
Существует 4 стадии проектирования БД:
Создание простановка задачи и описание предметной области - на этом этапе определяются границы предметной области, т.е ее объектное наполнение, а также формализуются основные требования к будущей БД;
Концептуальное проектирование БД - на этой стадии выявляются все объекты будущей базы данных, их характеристики и связи между собой;
Логическое проектирование БД - на этом этапе идет преобразование концептуальной модели в логическую модель данных для конкретного типа СУБД или иными словами – описывается схема данных создаваемой БД;
Физическое проектирование БД - окончательный этап проектирование, на котором окончательно организовывается файлы, журналы, резервные копии, составы индексов будущей БД.
3.1 Описание концептуальной модели БД
3.1.1 Задачи и объекты предметной области
Требуется разработать информационную систему для автоматизации учета заказов товаров. Система должна предусматривать возможность ввода данных в таблицы, а также их удаление и редактирование. Каждый товар в таблице может иметь уникальный внутренний номер и полное наименование. Каждый товар может относится сразу к нескольким категориям. Каждый товар может присутствовать в нескольких экземплярах. Также каждый товар должен иметь поставщика, а пользователь сайта может одновременно сделать несколько заказов.
Каждый товар, имеющийся в магазине, характеризуется следующими параметрами:
• уникальный шифр (id);
• название;
• описание;
• цена;
• количество;
• категорию;
• производителя.
Товары могут иметь одинаковые названия, но они различаются по своему уникальному шифру.
Каждый товар имеет определенную категорию, которая характеризуется такими параметрами:
• уникальный шифр (id);
• название;
• описание.
В одной категории может быть несколько одинаковых товаров, которые отличаются уникальным шифром. Один товар может относится сразу к нескольким категориям.
У каждого товара есть свой производитель, который имеет такие параметры:
• уникальный шифр (id);
• название.
Каждый товар в определенный момент времени может приобрести покупатель, который имеет такие сведения:
• Уникальный шифр (id);
• Имя;
• Электронная почта.
Покупатели могут иметь одинаковые имена, поэтому каждый покупатель должен иметь свой уникальный шифр.
Один и тот же товар могут заказать сразу несколько покупателей. Каждый заказ характеризуется такими параметрами:
• Уникальный шифр (id);
• Товар;
• Покупатель.
3.1.2 Пользователи
С данной программой должны работать следующие группы пользователей:
• Администрация сайта.
При работе с системой администратор должен иметь возможность решать следующие задачи:
Просматривать список имеющихся товаров, а также добавлять новые товары, изменять или удалять их;
Просматривать список покупателей, удалять или изменять их;
Просматривать список производителей, добавлять новых, изменять или удалять их данные;
Просматривать список категорий, иметь возможность изменять имеющиеся категории, добавлять новые категории или удалять уже неактуальные категории;
Просматривать список заказов товаров, добавлять новые заказы, удалять уже доставленные заказы и редактировать уже имеющиеся заказы.
3.1.3 ER-диаграмма
ER-диаграмма — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных.
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь.
ER-модель базы данных «Сайт игровых приставок» можно просмотреть на рисунке А.1.
3.2 Описание логической модели БД
Логическое проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных логическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Реляционную модель базы данных «Сайт игровых приставок» можно просмотреть на рисунке А.2.
3.2.1 Нормализация отношений
Процесс проектирования БД с использованием метода нормальной формы (НФ) является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств, предшествующих НФ.
Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда все его кортежи содержит во всех своих атрибутах лишь атомарные значения, и все значения ключевых атрибутов не пусты.
Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все каждый его атрибут, не входящие в первичный ключ, связан полной функциональной зависимостью с первичным ключом.
Отношение находится в третьей нормальной форме (3НФ), если оно удовлетворяет определению 2НФ, и не один из ее не ключевых атрибутов не зависит функционально ни от какого другого не ключевого атрибута.
Для нормализации отношений БД «Сайт игровых приставок» рассмотрим таблицу «Заказ товара», которая содержит следующую информацию:
сведения о покупателе;
сведения о производителе и количество заказанного товара;
сведения о товаре и категории к которой он относится;
сведения о поставщиках товара.
Структуру таблицы «Сайт игровых приставок» можно посмотреть в таблице В.1 Примеры хранимых данных можно посмотреть в таблице В.2.
В этой таблице содержится значительное количество повторяющейся информации. Например, сведения о каждом покупателе повторяются для каждого сделанного им заказа. Такая структура таблицы приведет к трате значительного времени на ввод повторяющихся данных. Наличие повторяющейся информации приведет к неограниченному увеличению объема базы данных, возрастет вероятность ошибок при вводе.
Приведенная таблица В.2 не является нормализованной.
Для удовлетворения условий первой нормальной формы таблица должна иметь по крайней мере один уникальный ключ. Поэтому для выполнения условия необходимо создать индекс (определить ключ), который включал бы совокупность всех полей таблицы, однозначно определял запись.
1 НФ должна устранять повторяющиеся группы полей. Поскольку каждый покупатель может заказать несколько товаров, необходимы две таблицы.
Разобьем таблицу «Сайт игровых приставок» на «Покупатель» и «Заказ». Результат можно просмотреть на рисунке А.3.
Понятие 2-ой нормальной формы применимо только к таблицам имеющим составной ключ.
В данном примере таблица «Заказ» имеет составной индекс: Уникальный шифр покупателя + Уникальный шифр товара.
Для приведения таблицы ко второй нормальной форме разделим таблицу «Заказ» на две. Приведение ко второй нормальной форме можно посмотреть на рисунке А.4.
В таблице «Товар» поле Описание_категории содержит описания различных категорий, которые однозначно определяются значением поля Категории. Поскольку неиндексное поле Описание_категории однозначно определяется другим неиндексным полем Название_категории, то таблица «Товар» не является таблицей в третьей нормальной форме. Тоже и с полем Название_производителя.
Для приведения таблиц к третьей нормальной форме создадим новые таблицы
«Категории» и «Производитель». Приведение к третьей нормальной форме можно посмотреть на рисунке А.5.