Файл: Курсовая работа по дисциплине Базы данных База данных Магазин товаров для спорта Исполнитель студент группы 4301.docx

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ

ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего и профессионального образования

«Казанский национальный исследовательский технический университет

имени А.Н. Туполева»

(КНИТУ-КАИ)

---------------------------------------------------------------------------------------------------------------------

Кафедра АСОИУ

Курсовая работа

по дисциплине «Базы данных»

База данных «Магазин товаров для спорта»

Исполнитель: студент группы 4301

П.С. Калиновский

Руководитель: доцент кафедры АСОИУ

И.И. Бикмуллина

Оценка _________________

Подпись _________________

«___» ____________2018

Казань 2018

Оглавление

1. Задание

Выполнить проектирование и создать базу данных «Магазин товаров для спорта»

2. Анализ и описание предметной области

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

---

Работать с базой данных «Магазин товаров для спорта» будут следующие пользователи:

- Продавцы

- Экономисты

- Директор

3. Цели и задачи создания базы данных «Магазин товаров для спорта»

Проанализировав предметную область, мы можем сказать, что разработка базы данных для магазина спорттоваров актуальна. Целью разработки базы данных «Магазин товаров для спорта» и автоматизированной системы для работы с ней является повышение качества обслуживания клиентов (пресечение путаницы при схожих наименованиях товаров и улучшение работы продавцов), достижение полной систематизации товаров и увеличение прибыли магазина.
Задачами автоматизированной системы являются:

1. Поддержание актуальности данных о товарах

2. Выдача информации о том или ином товаре

3. Формирование информации о продажах и закупках товара

4. Выдача информации о наличии товара в другом магазине

5. Реализация покупки товара

6. Выдача информации о невостребованных и неприбыльных товарах
Дерево целей:

4. Проектирование базы данных

4.1. Входные и выходные данные задач

Входными данными задач являются:

Информация о товаре, информация о покупке товара, информация для экономистов

Информация о товаре:

Код товара

Название

Фирма

Количество в магазине

Общее количество в магазине

Наличие в другом магазине

Название группы

Раздел

Цена продажи

Количество проданного товара

Цена закупки

Количество закупленного товара
Информация о покупке товара:

ID покупки

Код товара

Фирма

ФИО покупателя

4.2. Инфологическое проектирование базы данных

Выделим основные сущности:

сущность «Товар»

сущность «Покупка»

Инфологическая модель базы данных «Магазин товаров для спорта»:


4.3. ВыборСУБД

Выбираем СУБД Microsoft Office Access.

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

---

В СУБД поддерживаются различные модели данных.

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

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

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

СУБД Microsoft Access является системой управления реляционной базы данных, включающих все необходимые инструментальные средства для создания локальной базы данных , общей базы данных в локальной сети с файловым сервером или базы данных на SQL-сервере, а также для создания приложений пользователя, работающего с этими базами данных. База данных Access, создаваемая на локальном компьютере, отличается от баз данных других настольных СУБД. В её файле могут храниться не только данные, но и объекты интерфейса – формы, отчёты, а также программный код. Благодаря этому можно создать приложение, целиком хранящееся в одноединственном MDB-файле, что существенно упрощает как создание, так и распространение приложений для работы с базами данных.

СУБД Access включает разнообразные и многочисленные относительно автономные программные средства, ориентированные на создание объектов база данных и приложений пользователя.

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

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

---

Среди многочисленных средств графического конструирования и диалоговых средств Access следует выделить средства для создания:

• 
  таблиц и схем баз данных;
  
• 
  запросов выборки, отбирающих и объединяющих данные нескольких таблиц в виртуальную таблицу, которая может использоваться во многих задачах приложения;
  
• 
  запросов на изменение баз данных;
  
• 
  экранных форм, предназначенных для ввода, просмотра и обработки данных в диалоговом режиме;
  
• 
  отчётов, предназначенных для просмотра и вывода на печать данных из базы и результатов их обработки в удобном для пользователя виде;
  
• 
  страниц доступа к данным, обеспечивающим работу с базами данных в среде Internet;
  
• 
  интерфейса управления приложением пользователя: меню, кнопочных форм, панелей управления приложением, позволяющих объединить различные операции по работе с базой данных в единый технологический процесс.
  

4.4. Даталогическое проектирование базы данных

Даталогическим (логическим) проектированием называют проектирование логической структуры БД в среде конкретной СУБД. Выберем в качестве модели данных реляционную базу данных (РБД).

Существуют разные способы проектирования логической структуры РБД. Рассмотрим способ проектирования, основанный на анализе инфологической модели и переходе от нее к реляционным отношениям.

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

Получили следующие отношения:

Товар (Код товара , Название , Фирма , Количество в магазине , Общее количество в магазине , Наличие в другом магазине , Название группы , Раздел , Цена продажи , Количество проданного товара , Цена закупки , Количество закупленного товара)

Покупка (ID покупки , Код товара , Фирма , ФИО покупателя)

4.4.1. Нормализация отношений

Следующим шагом в проектировании РБД является нормализация отношений.

Рассмотрим отношение «Товар».

Отношение «Товар» в 1НФ, так как все его атрибуты простые.



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

---

До декомпозиции:




После декомпозиции:



Отношение «Товар» во 2НФ, так как оно находится в 1НФ, и каждый ее не ключевой атрибут функционально полно зависит от составного ключа.

Отношение «Товар» в 3НФ, так как оно находится в 2 НФ, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Рассмотрим отношение «Покупка».



Отношение «Покупка» в 1НФ, так как все его атрибуты простые.

Отношение «Покупка» во 2НФ, так как оно находится в 1НФ, и каждый ее не ключевой атрибут функционально полно зависит от составного ключа.

Отношение «Покупка» в 3НФ, так как оно находится в 2 НФ, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Даталогическая модель базы данных «Магазин товаров для спорта»:

4.2.2. Определение структуры таблиц реляционной базы данных «Магазин товаров для спорта»

Определим структуры таблиц в среде СУБД Microsoft Access 2013. Дадим названия таблицам и атрибутам, определим типы данных и размерность атрибутов. В таблицах выберем первичные ключи и индексированные поля.

Таблица 1. Структура таблицы «Товар»

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное поле
Товар	Код товара	Числовой	5	Первичный ключ
	Название	Текстовый	20
	Общее количество в магазине	Числовой	5
	Наличие в другом магазине	Текстовый	20
	Название группы	Текстовый	20
	Раздел	Текстовый	20

---