1Курсовая работа. Тема курсовой работы Разработка базы данных магазина бытовой техники. Целью курсовой работы является разработка базы данных магазина бытовой техники. 4

• Название: Тема курсовой работы Разработка базы данных магазина бытовой техники. Целью курсовой работы является разработка базы данных магазина бытовой техники. 4
• Дата: 14.02.2023
• Размер: 5.23 Mb.
• Имя файла: 1Курсовая работа.docx
• Тип: Реферат; #936156

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 4

Тема курсовой работы «Разработка базы данных магазина бытовой техники. Целью курсовой работы является разработка базы данных магазина бытовой техники. 4

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

- сведения о товарах, поставщиках и производителях товара; 5

- сведения о продажах магазина; 5

- регистрацию покупателей магазина; 5

- сведения партиях товаров. 5

Разработка структуры базы данных начинается с выбора типа базы данных. 5

Мы будем использовать наиболее распространенные базы данных, которыми являются реляционные базы данных. Реляционная модель будет реализована на основе инфологической модели «сущность – связь» 5

База данных будет создаваться в СУБД MS Access. 5

1. Теоретические основы проектирования и разработки баз данных 6

1.1. Основные принципы проектирования реляционных баз данных 6

1.2. Этапы физической реализации проектируемой базы данных 8

2. Существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта по теме курсового проекта 11

1.Счет на оплату покупки; 11

2.Итоги дня; 11

3.Вывод товара по поставщику; 11

4.Наличие товара на складе; 11

5.Анализ продажи товаров. 11

При работе с базой данных продавец должен уметь решать следующие задачи такие, как: 11

1.Обеспечение продажи товара; 11

2.Формирование счета на оплату покупки; 11

3.Владеть информацией о наличии товара на складе и о продаваемом товаре; 12

3. Даталогическое и инфологическое проектирование по выбранной теме курсового проекта 13

3.1. Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей 13

3.2. Построение диаграмм ER-типа с учетом всех сущностей и их связей 16

3.3. Проведение процесса нормализации и денормализации 17

3.5. Схема проектируемой базы данных 19

3.6. Проектирование ER-модели в реляционную модель 20

4. Физическая реализация проектируемой базы данных 24

4.1. Средства создания, изменения описания, удаления таблиц и данных 24

4.2. Формирование простых и сложных запросов к базе данных 27

4.3. Способы повышения производительности доступа к данным 30

СПИСОК ЛИТЕРАТУРЫ 36

ВВЕДЕНИЕ

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

Тема курсовой работы «Разработка базы данных магазина бытовой техники. Целью курсовой работы является разработка базы данных магазина бытовой техники.

Задачами разработки курсовой работы являются разработка и создание базы данных. Разработанная база должна выполнять следующие задачи:

- содержать подробные сведения о продаваемых магазином товарах, поставщиках товаров, покупателях и продажах магазина;

- формировать информацию о счетах на оплату покупки, с учетом предоставляемой скидки; об итогах продаж; о количестве товаров на складах;

- позволяет в любое время просматривать информацию о товарах, поставщиках и покупателях товара, а также легко модифицировать ее (добавлять, редактировать, удалять: при работе с ней работников магазина);

- обеспечивает получение информации о количестве проданного товара и анализ продажи товаров;

- обеспечивает организацию защиты посредством логина и пароля

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

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

- сведения о товарах, поставщиках и производителях товара;

- сведения о продажах магазина;

- регистрацию покупателей магазина;

- сведения партиях товаров.

Разработка структуры базы данных начинается с выбора типа базы данных.

Мы будем использовать наиболее распространенные базы данных, которыми являются реляционные базы данных. Реляционная модель будет реализована на основе инфологической модели «сущность – связь»

База данных будет создаваться в СУБД MS Access.

1. Теоретические основы проектирования и разработки баз данных

1.1. Основные принципы проектирования реляционных баз данных

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

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

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

Такая ориентированная на человека модель фактически полностью не зависит от физических параметров среды, где хранятся данные, такой как память человека или ЭВМ. Поэтому инфологическая модель не видоизменяется до тех пор, пока изменения в реальном мире (то, что относится к предметной области) не потребуют изменения в модели соответствующего участка описания, чтобы эта модель продолжала достоверно отображать предметную область.

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

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

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

Представленная трехуровневая архитектура (инфологический, даталогический и физический уровни) даёт возможность обеспечить независимость хранимых данных от программ, которые их используют. Хранимые данные могут быть перенесены на другие носители или их физическая структура может быть преобразована, а также дополнена полями для новых приложений, что повлечет за собой лишь модификацию физической и, возможно, даталогической модели данных. Важно, что такие изменения физической и даталогической моделей не будут заметны для пользователей системы (будут «прозрачными» для них) так же, как не будут замечены и вновь подключаемые пользователи. Кроме того, независимость данных обеспечит широкую возможность по созданию приложений для решения новых задач без уничтожения существующих.

Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели [5]. В общем случае можно выделить следующие этапы проектирования:

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.

3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.

4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект.

1.2. Этапы физической реализации проектируемой базы данных

Физическое проектирование это определение особенностей хранения данных, методов доступа и т.д [6].

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

Процедуры физического проектирования следующие.

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

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

Все решения, принятые в связи с реализацией бизнес-правил предметной области, подробно описываются в сопутствующей документации.

3. Проектирование физической организации базы данных. На этом этапе выбирается оптимальная файловая организация для таблиц. Выявляются транзакции, которые будут проходить в проектируемой базе данных, и выделяются наиболее существенные из них. Производится анализ пропускной способности транзакций – количество транзакций, которые могут быть выполнены в заданный промежуток времени, и время ответа – интервал времени, за который выполняется одна транзакция. Стараются увеличить пропускную способность транзакций и сократить время ответа. Используя указанные показатели, принимают решения об оптимизации производительности базы данных с помощью определения индексов в таблицах, уменьшающих время выборки данных из базы, или снижают требования к уровню нормализации таблиц. Производят оценку дискового объема памяти, необходимого для размещения создаваемой базы данных. Стремятся его минимизировать.

Принятые решения по изложенным вопросам вносятся в сопутствующие документы.

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

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

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

2. Существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта по теме курсового проекта

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

Работа менеджера магазина состоит в анализе продаж товаров, наличия товаров на складах; добавлении или изменении информации о товарах, поставщиках, покупателях, партиях товара.

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

В базе данных банка используются следующие входные данные:

– информация о товаре;

– информация о продаже товаров;

– информация о покупателях;

- информация поставщиках и партиях товара.

Выходной информацией являются результаты работы запросов, на печать информация выводится в виде отчетов, а именно:

1. 
   Счет на оплату покупки;
   
2. 
   Итоги дня;
   
3. 
   Вывод товара по поставщику;
   
4. 
   Наличие товара на складе;
   
5. 
   Анализ продажи товаров.
   

При работе с базой данных продавец должен уметь решать следующие задачи такие, как:

1. 
   Обеспечение продажи товара;
   
2. 
   Формирование счета на оплату покупки;
   
3. 
   Владеть информацией о наличии товара на складе и о продаваемом товаре;
   

Менеджер магазина должен уметь решать следующие задачи:

1. 
   Анализ продаж товаров, наличие товаров на складах;
   
2. 
   Добавление или изменение информации о товарах, поставщиках, покупателях, партиях товара.
   

3. Даталогическое и инфологическое проектирование по выбранной теме курсового проекта

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

Создание инфологической модели является естественным продолжением исследований предметной области, но в отличие от него является представлением БД с точки зрения проектировщика (разработчика). Наглядность представления такой модели позволяет экспертам предметной области оценить ее точность и внести исправления. От правильности модели зависит успех дальнейшей разработки [7].

3.1. Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей

В проекте «База данных магазина бытовой техники» в соответствии с предметной областью были созданы следующие сущности:

• 
  «Товары» – хранится информация об продаваемых в магазине товарах;
  
• 
  «Типы товаров» – хранится информация о типах продаваемого товара;
  
• 
  «Производители» – хранится информация о производителях товара;
  
• 
  «Партии товара» – хранится информация о партиях поступившего в магазин товара;
  
• 
  «Поставщики» – хранится информация о поставщиках поступившего в магазин товара;
  
• 
  «Продажи» – хранится информация о продажах товара;
  
• 
  «Покупатели» – хранится информация о покупателях товара;
  

Каждому объекту соответствуют свои атрибуты:

• 
  «Товары» – Код товара, Код типа, Название, Код производителя, Дата выпуска, Срок гарантии, Цена, Номер партии, Количество на складе, Изображение;
  
• 
  «Типы товаров» – Код типа, Наименование;
  
• 
  «Производители» – Номер производителя, Производитель;
  
• 
  «Партии товара» – Номер партии, Номер поставщика, Дата;
  
• 
  «Поставщики» – Номер поставщика, Название;
  
• 
  «Продажи» – Номер покупателя, Код товара, Количество, Дата покупки, Скидка %;
  
• 
  «Покупатели» – Номер покупателя, Фамилия (Название фирмы), Имя, Отчество, Номер паспорта, Контактный телефон, Номер кредитного счета.
  

Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Товары» это будет уникальный код товара, для сущности «Типы товаров» это будет уникальный код типа. Сущность «Производители» определяется уникальным номером производителя, сущность «Партии товара» - уникальным номером партии. Сущность «Поставщики» определяется уникальным номером поставщика. Для сущности «Продажи» будет составной ключ Номер покупателя и код товара и для сущности «Покупатели» - уникальный номер покупателя.

При проведении связи между сущностями первичный ключ главной сущности помещается в дочернюю сущность, то есть в сущность «Товары» будет вставлен первичный ключ сущности «Типы товаров» - Код типа, а также первичный ключ сущности «Производители» - Код производителя и сущности «Партии товара» - Номер партии. В сущность Партии товара будет вставлен первичный ключ сущности «Поставщики» - Номер поставщика.

В базе данных банка определены следующие отношения между таблицами:

Таблица 3.1.1. – Классификация связей

№	Родительская таблица	Дочерняя таблица	Ключи		Вид связи
1	Типы товаров	Товары	Код типа	Код типа	1:М
2	Производители	Товары	Номер производителя	Номер производителя	1:М
3	Партии товара	Товары	Номер партии	Номер партии	1:М
4	Поставщики	Партии товара	Номер поставщика	Номер поставщика	1:М
5	Товары	Продажи	Код товара	Код товара	1:М
6	Покупатели	Продажи	Номер покупателя	Номер покупателя	1:М

Выбор таких связей между таблицами «Типы товаров», «Товары» и «Производители», «Товары» обусловлен тем что, у одного типа товаров может быть несколько марок, и один Производитель может выпускать несколько товаров. Выбор связи между таблицами «Партии товара» и «Товары» обусловлен тем что, в одной партии товара может быть несколько товаров. Выбор связи между таблицами «Поставщики» и «Партии товара» обусловлен тем что, в один поставщик может поставить в магазин несколько партий. Выбор таких связей между таблицами «Товары», «Продажи» и «Покупатели», «Продажи» обусловлен тем что, один товар может продаваться несколько раз, и один покупатель может приобрести несколько товаров.

3.2. Построение диаграмм ER-типа с учетом всех сущностей и их связей

Существует несколько способов описания инфологической модели, однако, в настоящее время одним из наиболее широко распространенных подходов, применяемых при инфологическом моделировании, является подход, основанный на применении диаграмм «сущность-связь» (ER – Entity Relationship) [1].

На рисунке 3.2.1 представлена инфoлoгическaя модель базы данных, на которой отображены все сущности БД, отношение между ними и атрибуты.



Рисунок 3.2.1 – Инфологическая модель базы данных

3.3. Проведение процесса нормализации и денормализации

Описание процедуры нормализации и определения 1НФ, 2РФ, 3НФ и НФБК [1]:

• 
  Первая нормальная форма. Переменная-отношение находится в 1НФ тогда и только тогда, когда ее в любом допустимом значении этой переменной-отношения каждый ее кортеж содержит только одно значение для каждого из атрибутов.
  
• 
  Вторая нормальная форма. Переменная-отношение находится в 2НФ тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо зависит от ее первичного ключа.
  
• 
  Третья нормальная форма. Переменная-отношение находится в 3НФ тогда и только тогда, когда она находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от ее первичного ключа. Под нетранзитивной зависимостью подразумевается отсутствие какой-либо взаимной зависимости.
  
• 
  Переменная-отношение находится в нормальной форме Бойса-Кодда тогда и только тогда, когда детерменанты всех ее функциональных зависимостей являются потенциальными ключами.
  

В базе данных банка проведена нормализация отношений:

Проанализировав таблицу «Товары», можно сделать вывод, что она находится в первой нормaльной фoрме, так как она имеет первичный ключ, каждое поле таблицы представляет уникaльный тип инфoрмации, все поля атомарны. Так же данная таблица находится и во 2НФ, так как она удовлетворяет условиям 1НФ, а так же каждое поле функционально зависит от пeрвичнoгo ключa, кoтoрый идeнтифицируeт исхoдный oбъект тaблицы. Тaблица «Товары» нaходится в 3НФ, так как она находится во 2НФ и не coдержит трaнзитивных зaвисимостей, т.е. столбцы, не являющиеся ключевыми, зaвисят от первичнoго ключа тaблицы и не зависят от всeх ocтальных стoлбцoв. Можно изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей. Таблица «Товары» находится в БКНФ, т.к она находится в 3НФ и в ней отсутствуют зависимости ключей от неключевых атрибутов [4].

Остальные таблицы аналогично таблице «Товары» находятся во всех четырех нормальных формах.

Таким обрaзом, прoанaлизирoвaв рaзрaбoтaнную бaзу дaнных, мoжнo сделать вывод, что она нормализована и соответствует четырем нормальным формам.

3.5. Схема проектируемой базы данных

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

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

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

На рисунке 3.5.1. пpивeдена схема бaзы дaнных магазина бытовой техники.



Рисунoк 3.5.1. – Сxeма бaзы дaнных магазина бытовой техники

3.6. Проектирование ER-модели в реляционную модель

Рассмотрим правила преобразования ER-модели в реляционную модель[3].

1. 
   Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть разными, потому что на имена сущностей не накладываются дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели.
   
2. 
   Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается конкретный тип данных допустимый в СУБД и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).
   
3. 
   Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).
   
4. 
   В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREIGN KEY).
   
5. 
   Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).
   

Исходя из вышеизложенных правил, приведем состав таблиц БД. Для каждого поля таблицы указывается тип данных и размер поля (количество символов). Для первичных ключeй будет введен запрет неопределенных значений. Для остальных полей вoзмoжность запрета неопределенных значений опpeдeляeтся требованиями предметной oблаcти.

Таблица 3.6.1. – Состав таблицы «Товары»

Наименование атрибутов	Тип полей	NULL
Код товара Код типа Название Код производителя Дата выпуска Срок гарантии Цена Номер партии Количество на складе Изображение	Числовой Числовой Текстовый (50) Числовой Дата/Время Число Денежный Числовой Числовой Поле объекта OLE	Нет Нет Нет Нет Да Да Нет Нет Нет Да

Таблица 3.6.2. – Состав таблицы «Типы товаров»

Наименование атрибутов	Тип полей	NULL
Код типа Наименование	Числовой Текстовый (50)	Нет Нет

Таблица 3.6.3. – Сoстaв тaблицы «Производители»

Наименование атрибутов	Тип полей	NULL
Номер производителя Производитель	Числовой Текстовый (50)	Нет Нет

Таблица 3.6.4. – Сoстaв тaблицы «Партии товара»

Наименование атрибутов	Тип полей	NULL
Номер партии Номер поставщика Дата	Числовой Числовой Дата/Время	Нет Нет Нет

Таблица 3.6.5. – Сoстaв тaблицы «Поставщики»

Наименование атрибутов	Тип полей	NULL
Номер поставщика Название	Числовой Текстовый (50)	Нет Нет

Таблица 3.6.6. – Сoстaв тaблицы «Продажи»

Наименование атрибутов	Тип полей	NULL
Номер покупателя Код товара Количество Дата покупки Скидка %	Числовой Числовой Числовой Дата/Время Числовой	Нет Нет Нет Нет Да

Таблица 3.6.7. – Сoстaв тaблицы «Покупатели»

Наименование атрибутов	Тип полей	NULL
Номер покупателя Фамилия Имя Отчество Номер паспорта Контактный телефон Номер кредитного счета	Числовой Текстовый (50) Текстовый (20) Текстовый (20) Числовой Текстовый (20) Текстовый (10)	Нет Нет Да Да Да Да Нет

4. Физическая реализация проектируемой базы данных

4.1. Средства создания, изменения описания, удаления таблиц и данных

Таблицы в базе данных магазина бытовой техники были созданы в режиме Конструктора:



Рисунок 4.1.1. Вид таблицы «Товары» в Конструкторе



Рисунок 4.1.2. Вид таблицы «Типы товаров» в Конструкторе



Рисунок 4.1.3. Вид таблицы «Производители» в Конструкторе



Рисунок 4.1.4. Вид таблицы «Партии товара» в Конструкторе



Рисунок 4.1.5. Вид таблицы «Поставщики» в Конструкторе



Рисунок 4.1.6. Вид таблицы «Продажи» в Конструкторе



Рисунок 4.1.7. Вид таблицы «Покупатели» в Конструкторе

Для всех связей, представленных на схеме, включено обеспечение целостности данных, каскадное удаление связанных записей (см. рисунок 4.1.8.).



Рисунок 4.1.8. Изменение связей

Таблицы были заполнены следующими данными:



Рисунок 4.1.9. Таблица Товары с заполненными данными



Рисунок 4.1.10. Таблица Типы товаров с заполненными данными



Рисунок 4.1.11. Таблица Производители с заполненными данными



Рисунок 4.1.12. Таблица Партии товаров с заполненными данными



Рисунок 4.1.13. Таблица Поставщики с заполненными данными



Рисунок 4.1.14. Таблица Продажи с заполненными данными



Рисунок 4.1.15. Таблица Товары с заполненными данными

4.2. Формирование простых и сложных запросов к базе данных

Выбopкa инфoрмaции ocущecтвляется при помощи запросов, которые представлены в этом рaздeлe.

1. Счет на оплату покупки. Суть запроса: сформировать отчет Счет на оплату покупки с расчетом цены со скидкой и условием отбора по фамилии или названию фирмы.



Рисунок 4.2.1. Вид запроса Счет на оплату покупки в конструкторе



Рисунок 4.2.2. Результат выполнения запроса Счет на оплату покупки

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



Рисунок 4.2.3. Вид запроса Итоги дня



Рисунок 4.2.4. Результат выполнения запроса Итоги дня

3. Вывод товара по поставщику. Суть запроса: сформировать отчет для менеджера магазина с выводом названия товара и количества на складе по поставщику.



Рисунок 4.2.5. Вид запроса Вывод товара по поставщику



Рисунок 4.2.6. Результат выполнения запроса Вывод товара по поставщику

4. Наличие на складе. Суть запроса: вывести количество запрашиваемого товара на складе.



Рисунок 4.2.7. Вид запроса Наличие на складе



Рисунок 4.2.8. Результат выполнения запроса Наличие на складе

5. Анализ продажи товаров. Суть запроса: сформировать сводную диаграмму для анализа продаваемости товара.



Рисунок 4.2.9. Вид запроса Анализ продажи товаров



Рисунок 4.2.10. Результат выполнения запроса Анализ продажи товаров

4.3. Способы повышения производительности доступа к данным

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

Открыть кнопочную форму АРМ продавца

Открыть кнопочную форму АРМ менеджера

Выход из приложения

Форма открывается автоматически при открытии базы данных.



Рисунок 4.3.1. Кнопочная форма базы данных банка

Существуют также связанные с ней формы, о которых говорилось выше.

1. 
   Кнопочная форма АРМ продавца, в которой предлагаются следующие действия:
   
   1. 
      Открыть форму Продажа товара для изменения или добавления данных;
      
   2. 
      Открыть отчет Счет на оплату покупки;
      
   3. 
      Открыть форму для просмотра данных об интересующем товаре;
      
   4. 
      Подать запрос о наличии товара на складе.
      
2. 
   Кнопочная форма АРМ менеджера, в которой предлагаются следующие действия:
   
   1. 
      Открыть формы на изменение или добавление данных Товары, Покупатели, Поставщики, Типы товаров, Партии товаров.
      
   2. 
      Открыть форму для просмотра Анализ продажи товаров.
      
   3. 
      Открыть отчеты Вывод товаров по поставщику и Итоги дня.
      

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



Рисунок 4.3.2. Форма Продажа товара

Форма для просмотра и анализа продаваемости товаров:



Рисунок 4.3.3. Форма Анализ продажи товаров

Так же для доступа к данным в базе данных магазина бытовой техники были разработаны отчеты:

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

Рисунок 4.3.4. Отчет Счет на оплату покупки

2. 
   Отчет Итоги дня позволяет вывести на печать покупателей, товары, количество, цену товара, цену со скидкой и общую стоимость продажи дня:
   

Рисунок 4.3.5. Отчет Итоги дня

3. 
   Отчет Вывод товара по поставщику позволяет вывести на печать номер партии, товары, цену, количество, хранимое на складе по интересующему поставщику:
   

Рисунок 4.3.6. Отчет Вывод товара по поставщику
ЗАКЛЮЧЕНИЕ

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

Разработанная база выполняет следующие задачи:

- содержит подробные сведения о продаваемых магазином товарах, поставщиках товаров, покупателях и продажах магазина;

- формирует информацию о счетах на оплату покупки, с учетом предоставляемой скидки; об итогах продаж; о количестве товаров на складах;

- позволяет в любое время просматривать информацию о товарах, поставщиках и покупателях товара, а также легко модифицировать ее (добавлять, редактировать, удалять: при работе с ней работников магазина);

- обеспечивает получение информации о количестве проданного товара и анализ продажи товаров;

- обеспечивает организацию защиты посредством логина и пароля

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

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

Была описана существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта по теме курсовой работы.

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

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

Данная база данных обладает рядом достоинств и недостатков.

Достоинствами являются:

- легкость и удобство в исполнении;

- широкие возможности расширения базы данных;

- быстрый поиск необходимых данных;

- возможность легкого переноса с одного компьютера на другой;

- возможность редактирования результатов запросов.

Недостатками являются:

- не высокий уровень безопасности.

СПИСОК ЛИТЕРАТУРЫ

1. 
   Дейт К. Введение в системы баз данных: проектирование. Реализация и управление. Пер. с англ. – СПб.: БХВ-Петербург, 2004. – 324 с.
   
2. 
   Малыхина М.П. Базы данных: основы, проектирование, использование, 2-е изд. перераб. и доп. – СПб.: БХВ-Петербург, 2007. – 528 с.
   
3. 
   Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с.
   
4. 
   Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д. Хомоненко.6-е изд., – СПб.: КОРОНА принт, 2009. – 736 с.
   
5. 
   Карпова Т.С. Базы данных: модели, разработка, реализация: Учебник для вузов / Т.С. Карпова – СПб.: Питер, 2002. – 303 с.
   
6. 
   Коннолли, Т. Базы данных: Проектирование, реализация и сопровождение: Теория и практика / Т. Коннолли, К. Бегг, А. Страчан; под ред. Т. Коннолли, К. Бегг. - Изд. 2-е, испр. и доп. - М. : Вильямс, 2003. - 1111 с.
   
7. 
   Балдин К. В. Информационные системы в экономике: Учебник / К. В. Балдин. - ИНФРА - М, 2008. - 395 с.
   
8. 
   Проектирование баз данных. СУБД Microsoft Access: Учебное пособие для вузов / Н. Н. Гринченко, Е. В. Гусев, Н. П. Макаров.,А. Н. Пылькин, Н. И. Цуканова. - М.: Горячая линия-Телеком, 2004. - 240с.
   
9. 
   Сеннов А. Access 2010. – СПб.: «Питер», 2010. – с.288.
   
10. 
    Мэтью Мак-Дональд. Access 2007 Недостающее руководство – СПб.: БХВ-Петербург, 2007. – 784с.
    
11. 
    Сергеев А.В.: Access 2007. Новые возможности. СПб.: Питер, 2008. –176 с.