Как составить базу данных магазинов

Время на прочтение
4 мин

Количество просмотров 121K

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9, 10-13
Продолжение. Каскадное удаление данных.

14. Другой пример: база данных интернет-магазина.

Вы познакомились, я надеюсь, с основными концепциями создания баз данных и теперь вы можете спроектировать простую реляционную базу данных. В примере ниже я резюмирую задачи, с которыми вы столкнетесь при разработке базы данных.
P.S. Информация ниже в очень упрощенной форме моделирует мыслительный процесс при создании базы данных.

Система интернет-магазина.

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

• Отображение товаров
• Классификация товаров
• Регистрация клиентов
• Добавление товаров в корзину покупок
• Отображение содержимого корзины покупок
• Оформление заказов посетителями
• И т.д.

Определяем сущности и отношения.

Из списка задач мы можем вывести сущности, которые имеют важные роли в нашей системе. Товары, категории, клиенты и заказы – сущности, которые можно найти почти в каждой базе данных интернет-магазина. В данном примере я покажу вам модель, содержащую только следующие сущности: клиент, заказ и товар. Определившись с сущностями, мы можем подумать над связями между ними.

• Между заказом и товаром существует связь многие-ко-многим. Каждый заказ содержит 1 или более товаров и каждый товар может быть связан с 0, 1 или большим количеством заказов. Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – источники данных (order — заказ и products — товары) и одна – соединительная (OrderProducts), что вы и можете увидеть на картинке ниже. Обратите внимание на то, что и заказы и товары имеют связь один-ко-многим с соединительной таблицей. Вместе они образуют связь многие-ко-многим между заказами и товарами.
• Клиенты и заказы имеют связь один-ко-многим. Каждая запись о клиенте может быть связана с множественными записями о заказах (заказами) и наоборот, каждая запись о заказе (конкретный заказ) может быть связана только с одной записью о клиенте.

Данная таблица является простым примером. “Настоящая” таблица клиентов, конечно, содержит больше информации (адрес, город и т.д.)

Некоторые замечания о данной модели.

Таблица заказов (order)

Каждая запись таблицы заказов, каждый заказ связан с уникальной записью о клиенте, с уникальным клиентом с помощью внешнего ключа – поля customer_id.

Количество заказов.

Если вы задались вопросом, а можете ли вы добавить, например, поле количества заказов (order_quantity), то ответ – нет. Эти данные могут быть получены из существующих данных. Общее количество товаров в заказе (order_quantity) может быть получено из таблицы OrderProduct. Запрос, который находит количество товаров в заказе может быть легко сформирован с помощью SQL.

Тип платежа.

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

Общая сумма заказа.

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

Хранение истории цен на товары.

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

Таблица товаров.

В таблице товаров цены на товары хранятся без учета НДС. Цена с НДС может быть вычислена с помощью программного кода или с помощью SQL-запроса. Вот почему я не храню цены с включенным НДС. Вы должны знать, что хранение стоимости товаров таким образом может иметь смысл и в будущем. В рассматриваемой модели цена товара хранится в единственном поле таблицы. Однажды изменив цену на товар, вы теряете прежнюю стоимость. Но если вы хотите иметь возможность получать отчеты о продажах в прошлом из вашей базы данных, то вы должны хранить историю цен для каждого товара. Если товар менял стоимость дважды в определенном году, то вам нужна история цен, чтобы знать сколько денег вы выручили за этот товар в данном году. А так как НДС, на величину которого возрастает цена товара при продаже, не достается вам, то и учитывать его в отчетах о полученной прибыли за товар бессмысленно.

15. Вывод и дальнейшее чтение.

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

Куда двигаться дальше?

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

Другим логичным шагом после прочтения данного руководства будет ознакомление со структурированным языком запросов (SQL). Моделирование баз данных с помощью Mysql workbench или управление ими с помощью Sqlyog – это все здорово, но… если вы действительно хотите понимать как пользоваться базами данных, то SQL – это навык без которого у вас этого не получится. У W3Schools имеются неплохие уроки по SQL, с которых вы можете начать.

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

РОССИЙСКОЙ ФЕДЕРАЦИИ

БРЯНСКИЙ ГОСУДАРСТВЕННЫЙ

ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра «Информатика и программное
обеспечение»

РАЗРАБОТКА
БД «МАГАЗИН СПОРТТОВАРОВ»

КУРСОВАЯ РАБОТА

Руководитель:

_________ д.т.н., проф. П.В.
Стульчик

«___» ___________ 2020 г.

Студент гр З10-ПО1

____________________ ФИО

«___» ___________ 2020 г.

БРЯНСК, 2020

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

1.
ПРОЕКТИРОВАНИЕ БД «МАГАЗИН СПОРТТОВАРОВ»

1.1.
Концептуальное и логическое проектирование

1.2.
Описание БД

2.
РАЗРАБОТКА БД В MS ACCESS

3.
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ БД «МАГАЗИН СПОРТТОВАРОВ»

ЗАКЛЮЧЕНИЕ

СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

СУБД разрабатывались из-за
потребности в  выделении и обобщении  информационной системы (ИС) с целью
управления сложно структурированными данными. 

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

Объектом исследования данной
курсовой работы является  СУБД Microsoft Access. Предмет
исследования – БД «Магазин спорттоваров».  Цель работы – получение
концептуального представления о разработки БД в СУБД
Microsoft Access.

Для достижения
поставленной цели требуется решить ряд исследовательских задач:

1.  сделать концептуальное и
инфологическое проектирование  БД;

2.  выполнить физическое
проектирование БД;

3.  провести тестирование и
отладку БД;

4.  составить руководство
пользователя БД.

 

1. ПРОЕКТИРОВАНИЕ БД «МАГАЗИН СПОРТТОВАРОВ»

1.1. Концептуальное и логическое проектирование

1. 
Определение типов сущностей.

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

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

Под сущностью понимается  класс однотипных
объектов, используемых  в модели БД.

В БД «Магазин спорттоваров» в качестве  сущностей
используются: Классификатор товаров, Товары, Клиенты и Продажи

          

 

Рисунок 1 – Сущности БД «Магазин спорттоваров»

Экземпляр сущности – это  конкретный представитель этой сущности.  Для
каждого экземпляра сущности экземпляры сущностей  являются уникальными.

2. 
Определение атрибутов сущностей.

Атрибут сущности  – это ее конкретное
свойство или  характеристика.  В  БД «Магазин спорттоваров» у
каждой сущности недопустимо совпадение своих атрибутов: у класса спорттоваров –
кода товара, у товара  – его артикула, у клиента — № клиентской карты, у
продажи — № транзакции.

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

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

Список
сущностей БД «Магазин спорттоваров» и их атрибутов представлен на рисунке 2 и в
таблице 1.

Таблица 1 – Сущности БД «Магазин спорттоваров»

Таблица Классификатор товаров	Таблица Клиенты
1.   Код товара (ключ) – счетчик	1.     № карты (ключ) – числовое
2.   Наименование – текстовое	2. Фамилия – текстовое
3.   Характеристики – текстовое	3. Имя – текстовое
Таблица Товары	4. Отчество — текстовое
1. Артикул (ключ) – счетчик	5. Телефон — текстовое
2. Код товара — числовое	6. Скидка — числовое
3. Размер – числовое	Таблица Продажи
4. Цвет  – текстовое	1. № транзакции (ключ) –  счетчик
5. Цена  — денежное	2. Дата – дата/время
6. Количество — числовое	3. № карты – числовое
	4. Артикул – числовое
	5. Количество — числовое
	6. Стоимость — денежное

Рисунок 2 – Атрибуты сущностей БД «Магазин спорттоваров»

К
сильным  сущности БД «Магазин спорттоваров» относятся: Клиенты и Классификатор товаров.
Сущность Продажи —  слабая (зависимая). Сущность  Товары одновременно сильная и
слабая.

3. 
Определение типов связей.

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

В БД «Магазин спорттоваров» существуют следующие  связи один ко
многим между сущностями:  Классификатор товаров – Товары, Товары – Продажи,
Клиенты – Продажи.

4.  Определение
атрибутов и их связь  с типами сущностей и связей.

В перечисленных бинарных связях между сущностями используются
следующие атрибуты: Классификатор товаров – Товары (Код товара), Товары – Продажи
(Артикул), Клиенты – Продажи (№ карты).

5. 
 Определение потенциальных и первичных ключей.

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

В  БД «Магазин
спорттоваров»  потенциальными и первичными ключами являются: Классификатор товаров
– Код товара, Товары – Артикул, Клиенты — № карты, Продажи — № транзакции (рис.
3). 

6. 
Нормализация.

Нормальная форма —
требование, предъявляемое к структуре таблиц в теории реляционных баз данных для
устранения из базы избыточных функциональных зависимостей между атрибутами
(полями таблиц). Цель нормализации: исключить избыточное дублирование данных,
которое является причиной аномалий, возникших при добавлении, редактировании и
удалении кортежей (строк таблицы).

Рисунок 3 – Ключи сущностей БД «Магазин спорттоваров»

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

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

Переменная отношения сущности находится
в 3НФ форме при выполнении следующих условий:

·    
переменная
отношения сущности  находится во второй нормальной форме.

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

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

7. 
Построение диаграммы Питера Чена «Сущность-связь». 

Для иллюстрации
рассматриваемой предметной области – работы  магазина спорттоваров   построим
диаграмму «Сущность-связь» (рис. 4).

1.2. Описание БД

Общие сведения:

БД «Магазин спорттоваров»
—  это организованная структура, предназначенная хранения информации
о классификаторе спорттоваров, спорттоварах в наличии в магазине согласно
артикулу, клиентах и продажах.

Функциональное назначение:

1. 
уменьшение объема ручного труда при ведении документооборота;

2. 
оперативность получения данных по анализу  расчета продаж;

3. 
эффективность и грамотность расчетов;

4. 
надежное хранение данных.

Используемые технические
средства:

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

·     процессор
типа с тактовой частотой не ниже 1,5 Ггц;

·     1 Гб ОЗУ;

·     10 Мб на
жестком диске;

·     клавиатура;

·     мышь;

·     VGA монитор,
с минимальным разрешением 640×480 пикселей.

Входные данные: заполнение БД.

Выходные данные: отчеты.

 

 

 

 

 

2. РАЗРАБОТКА БД В MS ACCESS

1.  Разработка таблиц.

Создадим таблицы БД  с  помощью Конструктора таблиц, укажем
типы полей,  параметры для каждой из таблиц (рис. 5-11):

Рисунок 5 – Таблица Классификатор товаров. Режим Конструктора

Рисунок 6 – Таблица Товары. Режим Конструктора

Рисунок 7 – Таблица Товары. Режим Конструктора

Рисунок 8 – Таблица Клиенты. Режим Конструктора

Рисунок 9 – Таблица Продажи. Режим Конструктора

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

2.      
Создание 
схемы данных.

Разработаем  схему данных (рис. 10):

Рисунок 10 – Схема данных БД «Магазин спорттоваров»

3.      
Разработка
форм.

Создадим  формы по созданным таблицам  с помощью Конструктора
и Мастера форм, добавим управляющие кнопки (рис. 11-14):

Рисунок 11 – Форма Классификатор товаров

Рисунок 12 – Форма Клиенты

Рисунок 13 –Составная форма Товары

Рисунок 14 – Составная форма Товары-продажа

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

После окончания транзакции по покупке Продавцу необходимо
исправить количество товара (остаток). 

4.      
Разработка
запросов.

Запросы создаются с помощью  Конструктора и Мастера Запросов.

4.1. Параметрический запрос  — поиск
остатка товара по  наименованию  (рис. 15-16).

Рисунок 15 – Запрос1. Конструктор

SQL-запрос:

SELECT [Классификатор товаров].Наименование, [Классификатор
товаров].Характеристики, Товары.Размер, Товары.Цвет, Товары.Цена,
Товары.Количество

FROM [Классификатор товаров] LEFT JOIN Товары ON
[Классификатор товаров].[Код товара] = Товары.[Код товара]

WHERE ((([Классификатор товаров].Наименование)=[Введите
название спорттовара]));

Рисунок 16 – Результат Запроса

4.2. Запрос с условием – запрос
клиентов со скидкой свыше 10% (рис. 17-18).

Рисунок 17 – Запрос2. Конструктор

SQL-запрос:

SELECT Клиенты.[№ карты], Клиенты.Фамилия, Клиенты.Имя,
Клиенты.Отчество, Клиенты.Скидка

FROM Клиенты

WHERE (((Клиенты.Скидка)>10));

Рисунок 18 – Результат Запроса  

4.3. Запрос с группировкой
параметрический – наименование спорттовара и ее продажа за указанный месяц
текущего года (рис. 19-20):

Рисунок 19 – Запрос3. Конструктор

SQL-запрос:

SELECT [Классификатор товаров].Наименование,
Sum(Продажи.Количество) AS [Sum-Количество]

FROM ([Классификатор товаров] INNER JOIN Товары ON
[Классификатор товаров].[Код товара] = Товары.[Код товара]) INNER JOIN Продажи
ON Товары.Артикул = Продажи.Артикул

GROUP BY [Классификатор товаров].Наименование,
Month([Продажи]![Дата])

HAVING (((Month([Продажи]![Дата]))=[Введите № месяца]));

Рисунок 20 – Результат Запроса

4.4. Перекрестный запрос – дата
продажи и итоги  (рис. 21-22):

Рисунок 21– Запрос4. Конструктор

SQL-запрос:

TRANSFORM Sum(Продажи.Количество) AS [Sum-Количество]

SELECT Продажи.Дата, Sum(Продажи.Количество) AS [Итоговое
значение Количество]

FROM ([Классификатор товаров] INNER JOIN Товары ON
[Классификатор товаров].[Код товара] = Товары.[Код товара]) INNER JOIN Продажи
ON Товары.Артикул = Продажи.Артикул

GROUP BY Продажи.Дата

PIVOT [Классификатор товаров].Наименование;

Рисунок 22 – Результат Запроса

4.5. Запрос на обновление данных – изменение
№ телефона по № карты клиента (рис. 23-24):

Рисунок 23– Запрос5. Конструктор

SQL-запрос:

UPDATE Клиенты SET Клиенты.Телефон = [Введите № телефона]

WHERE (((Клиенты.[№ карты])=[Введите № карты]));

Рисунок 24 – Результат Запроса

4.6. Запрос на создание таблицы – Архив
продаж   (рис. 25-26):

Рисунок 25– Запрос6. Конструктор

SQL-запрос:

SELECT Продажи.* INTO [Продажи-архив]

FROM Продажи;

Рисунок 26 – Результат Запроса

4.7. Запрос на удаление – удаление
продаж до 01.06.2020  (рис. 27-28):

Рисунок 27– Запрос7. Конструктор

SQL-запрос:

DELETE Продажи.Дата

FROM Продажи

WHERE (((Продажи.Дата)<#6/1/2020#));

Рисунок 28 – Результат Запроса

4.8. Запрос с вычислением – суммарная
выручка по наименованию спорттовара за указанный месяц (рис. 29-30):

Рисунок 29– Запрос8. Конструктор

SQL-запрос:

SELECT [Классификатор товаров].Наименование,
Sum([Продажи]![Количество]*[Продажи]![Стоимость]) AS Итого

FROM ([Классификатор товаров] INNER JOIN Товары ON
[Классификатор товаров].[Код товара] = Товары.[Код товара]) INNER JOIN Продажи
ON Товары.Артикул = Продажи.Артикул

GROUP BY [Классификатор товаров].Наименование,
Month([Продажи]![Дата])

HAVING (((Month([Продажи]![Дата]))=[Введите № месяца]));

Рисунок 30 – Результат Запроса

5.      
Разработка
отчетов.

Разработаем отчеты по созданным запросам с помощью Мастера и
Конструктора форм.

5.1. Отчет по выручке (рис. 31-32):

Рисунок 31 – Отчет по выручке. Конструктор

Рисунок 32 – Отчет по выручке

5.2. Отчет по номенклатуре  (рис. 33-34):

Рисунок 33 – Отчет по номенклатуре. Конструктор

Рисунок 34 – Отчет по номенклатуре. Конструктор

5.3. Отчет по продажам за месяц (рис.
35-36):

Рисунок 35 – Отчет по продажам. Конструктор

Рисунок 36 – Отчет по продажам. Конструктор

6.  Разработка макросов для
открытия запросов (рис. 37):

Рисунок 37 – Макросы БД «Магазин спорттоваров»

7.  Разработка Главной
кнопочной формы (рис. 38-39):

Рисунок 38 – Главная кнопочная форма БД «Магазин спорттоваров»

Рисунок 39 – Дополнительные кнопочные формы

3. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
БД «МАГАЗИН
СПОРТТОВАРОВ»

Польз. БД	Автоматизируемые функции	Требуемые данные	Объект БД
Менеджер по продажам	Ввод данных о номенклатуре спорттоваров Ввод данных о клиентах Ввод данных о товарах Ведение продаж Поиск остатка товара по наименованию Поиск клиентов со скидкой свыше 10 % Получение результирующей информации о продажи спорттоваров за указанный месяц Получение результирующей информации о продажах по дням и номенклатуре Получение результирующей информации о выручке за указанный месяц Изменение № телефона клиента Создание архива продаж Удаление продаж до 01.06.2020	Данные о номенклатуре  спорттоваров Персональные данные клиентов и % скидки Данные о товарах Данные о продажах Наименование товара № месяца № месяца № карты	Главное меню – Формы – Классификатор товаров Главное меню – Формы — Клиенты Главное меню – Формы – Товары Главное меню – Формы – Товары-продажи Главное меню – Запросы – Остаток спорттоваров по наименованию; Отчеты – Отчет по номенклатуре Главное меню – Запросы – Клиенты со скидкой свыше 10 Главное меню – Запросы – Продажи спорттоваров за месяц; Отчеты – Отчет по продажам Главное меню – Запросы – Продажи-итоги Главное меню – Запросы – Выручка за месяц; Отчеты – Отчет по выручке Главное меню – Технологические запросы – Изменение № телефона клиента Главное меню – Технологические запросы – Создание архива продаж Главное меню – Технологические запросы – Удаление продаж до 01.06.2020
Владелец магазина спорттоваров	Получение результирующей информации о продажи спорттоваров за указанный месяц Получение результирующей информации о продажах по дням и номенклатуре Получение результирующей информации о выручке за указанный месяц	№ месяца № месяца	Главное меню – Запросы – Продажа спорттоваров за месяц; Отчеты – Отчет по продажам Главное меню – Запросы – Продажи-итоги Главное меню – Запросы – Выручка за месяц; Отчеты – Отчет по выручке

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

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

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

В данный момент СУБД – это  наиболее сложный программный
продукт на рынке, он составляет его основу. Сейчас ведутся разработки по
сочетанию обычных  СУБД с  объектно-ориентированным программированием  и
Интернет-технологиями.

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

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

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

БД обладают различными возможностями, такими как:

·      манипуляции
с большими объемами информации;

·      гарантия
максимально возможной компактности хранения данных;

·      возможность
извлечения из БД заданной информации в определенной предметной области;

·       отображение
информации в удобном для пользователя виде и форме;

·      обеспечение
высокой скорости доступа к данным;

·      гарантия
надежности хранимой информации, предоставление только  санкционированного
доступа к данным для определенных пользователей;

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

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

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

В данной работе освящен   процесс  разработки 
БД «Магазин спорттоваров» в СУБД Microsoft Access. В результате  работы была исследована предметная область – работа
магазина спорттоваров,  спроектирована БД,  созданы  и заполнены таблицы,
формы, запросы и отчеты.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Источники на русском языке

1.  Пушкина
Н., Бекаревич Ю. «Самоучитель Microsoft Access 2013».
Изд.: «БХВ-Петербург», 2014 г.

2. 
Сенченко П.Ф. «Организация баз данных»:
Учебное пособие. Изд.: «ТУСУР», 2015 г.

3. 
Филиппов И.Е. «Microsoft Access 2010 в
примерах»: Учебное пособие. Изд.: «Казанский университет», 2013 г.

Источники на иностранных языках

4. 
Conrad J. «Microsoft Access 2013 Inside Out». Microsoft
Press. 2013.

5. 
Lambert J. «Microsoft Access 2013 Step By Step». Microsoft
Press. 2013.

6. 
Alexander M. «Access2013 Bible». Wiley, 2013.

7. 
 John P. «MOS 2013 Study Guide for
Microsoft Access Exam 77-424». Microsoft Press. 2013.

Электронные ресурсы

8.  Сайт Microsoft. Основные сведения о запросах (основы Access,
часть 3):
https://support.office.com/ru-ru/article/Основные-сведения-о-запросах-основы-Access-часть-3-ce3b5537-14c6-4994-ba67-4de898df7c0b
#office (дата обращения 18.06.2020)

9.  Сайт Microsoft. Разработка и
создание таблиц для базы данных (основы Access часть 1):
https://support.office.com/ru-ru/article/Разработка-и-создание-таблиц-для-базы-данных-основы-Access-часть-1-bff6e7b2-3055-419b-8751-1ade558ea31f
#office (дата обращения 18.06.2020)

10.   Сайт Microsoft. Создание связи
между таблицами (основы Access, часть 2):
https://support.office.com/ru-ru/article/Создание-связей-между-таблицами-основы-Access-часть-2-a93d9491-8724-4cd3-96df-ce504914692f
#office (дата обращения 18.06.2020)

11.   Сайт Microsoft: https://support.office.com/ru—ru/article/Краткое-руководство-по-началу-работы-с-Access-2013-aa404d26-ce42-4dd2-ac5e-51f9f39f7275?CorrelationId=4992aa0a—d461-40d5-a201-6bd790491acf&ui=ru—RU&rs=ru—RU&ad=RU&ocmsassetID=HA103673689 (дата обращения 18.06.2020)

12.   Сайт Microsoft. Изменение данных в Access
2013 с помощью запросов на обновление:
https://support.office.com/ru-ru/article/Изменение-данных-в-Access-2013-с-помощью-запросов-на-обновление-38275063-be1c-48bf-9190-7ea25a867ff4
#office (дата обращения 18.06.2020)

13.   Сайт Microsoft. Основные задачи
для базы данных Access рабочего стола: https://support.office.com/ru-ru/article/Основные-задачи-для-базы-данных-Access-рабочего-стола-5ddb8595-497c-4366-8327-ae79d2abdc9c?ctt=5&origin=ha102840210&CorrelationId=26061447-e303-4879-8033-1fcdb040c906&ui=ru-RU&rs=ru-RU&ad=RU&ocmsassetID=HA102809525 (дата обращения 18.06.2020)

14.   Сайт «Access—video»: http://access—video.ru/video—pro—access.html (дата
обращения 18.06.2020)

15.   Сайт Artmens: http://artmens.ru/watch/access—dlya—nachinayushchikh—urok-4-sozdanie—zaprosa/I7e—lIZ2gqM (дата обращения 18.06.2020)

16.   Сайт «Программа Microsoft Access —
электронное пособие»: http://access.my—study.info/files/beginner.php (дата
обращения 18.06.2020)

17.   Портал life—prog.ru:  http://life—prog.ru/access.php (дата обращения 18.06.2020)

18.   НОУ «Интуит»: http://www.intuit.ru/studies/courses/508/364/info (дата обращения 18.06.2020)

19.   Портал «Образовательная
галактика Intel»:
https://edugalaxy.intel.ru/index.php?act=attach&type=blogentry&id=3847 (дата обращения 18.06.2020)

20.  
Портал «Гипермаркет знаний 2008-2017»: https://edufuture.biz/index.php?title=Создание_базы_данных_в_среде_MS_Access._Полные_уроки (дата обращения 18.06.2020)

ПРИЛОЖЕНИЕ

Разработаем
презентацию по созданной БД.

Соглашение о конфиденциальности

и обработке персональных данных

1.Общие положения

1.1.Настоящее соглашение о конфиденциальности и обработке персональных данных (далее – Соглашение) принято свободно и своей волей, действует в отношении всей информации, которую ООО «Инсейлс Рус» и/или его аффилированные лица, включая все лица, входящие в одну группу с ООО «Инсейлс Рус» (в том числе ООО «ЕКАМ сервис»), могут получить о Пользователе во время использования им любого из сайтов, сервисов, служб, программ для ЭВМ, продуктов или услуг ООО «Инсейлс Рус» (далее – Сервисы) и в ходе исполнения ООО «Инсейлс Рус» любых соглашений и договоров с Пользователем. Согласие Пользователя с Соглашением, выраженное им в рамках отношений с одним из перечисленных лиц, распространяется на все остальные перечисленные лица.

1.2.Использование Сервисов означает согласие Пользователя с настоящим Соглашением и указанными в нем условиями; в случае несогласия с этими условиями Пользователь должен воздержаться от использования Сервисов.

1.3.Сторонами (далее – «Стороны) настоящего Соглашения являются:

«Инсейлс» – Общество с ограниченной ответственностью «Инсейлс Рус», ОГРН 1117746506514, ИНН 7714843760, КПП  771401001, зарегистрированное по адресу: 125319, г.Москва, ул.Академика Ильюшина, д.4, корп.1, офис 11 (далее — «Инсейлс»), с одной стороны, и

«Пользователь» –

либо физическое лицо, обладающее дееспособностью и признаваемое участником гражданских правоотношений в соответствии с законодательством Российской Федерации;

либо юридическое лицо, зарегистрированное в соответствии с законодательством государства, резидентом которого является такое лицо;

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

которое приняло условия настоящего Соглашения.

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

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

2.Обязанности Сторон

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

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

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

2.4.Не будут считаться нарушением настоящего Соглашения следующие случаи:

(а)если предоставленная информация стала общедоступной без нарушения обязательств одной из Сторон; 

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

(в)если предоставленная информация правомерно получена от третьей стороны без обязательства о сохранении ее в тайне до ее предоставления одной из Сторон; 

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

(д)если информация предоставлена третьему лицу с согласия той Стороны, информация о которой передается.

2.5.Инсейлс не проверяет достоверность информации, предоставляемой Пользователем, и не имеет возможности оценивать его дееспособность.

2.6.Информация, которую Пользователь предоставляет Инсейлс при регистрации в Сервисах, не является персональными данными, как они определены в Федеральном законе РФ №152-ФЗ от 27.07.2006г. «О персональных данных».

2.7.Инсейлс имеет право вносить изменения в настоящее Соглашение. При внесении изменений в актуальной редакции указывается дата последнего обновления. Новая редакция Соглашения вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Соглашения.

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

Пользователь имеет право отказаться от получения вышеуказанной информации, сообщив об этом письменно на адрес электронной почты Инсейлс — contact@ekam.ru.

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

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

Инсейлс вправе установить, что предоставление определенного Сервиса возможно лишь при условии, что прием и получение файлов cookie разрешены Пользователем.

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

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

3.Ответственность Сторон

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

3.2.Возмещение ущерба не прекращают обязанности нарушившей Стороны по надлежащему исполнению обязательств по Соглашению.

4.Иные положения

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

4.2.Если одно или несколько положений (условий) настоящего Соглашения являются либо становятся недействительными, то это не может служить причиной для прекращения действия других положений (условий).

4.3.К настоящему Соглашению и отношениям между Пользователем и Инсейлс, возникающим в связи с применением Соглашения, подлежит применению право Российской Федерации.

4.3.Все предложения или вопросы по поводу настоящего Соглашения Пользователь вправе направлять в Службу поддержки пользователей Инсейлс www.ekam.ru либо по почтовому адресу: 107078, г. Москва, ул. Новорязанская, 18, стр.11-12 БЦ «Stendhal» ООО «Инсейлс Рус».

Дата публикации: 01.12.2016г.

Полное наименование на русском языке:

Общество с ограниченной ответственностью «Инсейлс Рус»

Сокращенное наименование на русском языке:

ООО «Инсейлс Рус»

Наименование на английском языке:

InSales Rus Limited Liability Company (InSales Rus LLC)

Юридический адрес:

125319, г. Москва, ул. Академика Ильюшина, д. 4, корп.1, офис 11

Почтовый адрес:

107078, г. Москва, ул. Новорязанская, 18, стр.11-12, БЦ «Stendhal»

ИНН: 7714843760 КПП: 771401001

Банковские реквизиты:

Р/с 40702810600001004854

В ИНГ БАНК (ЕВРАЗИЯ) АО, г.Москва,
к/с 30101810500000000222, БИК 044525222

Электронная почта: contact@ekam.ru

Контактный телефон: +7(495)133-20-43

Проектирование базы данных продовольственного магазина средствами MS Access

Министерство образования Республики
Беларусь

Белорусский национальный технический
университет

Факультет информационных технологий и
робототехники

Пояснительная записка к курсовой
работе на тему:

«Проектирование базы данных
продовольственного магазина средствами MS Access»

Исполнитель: Студент гр. 107818 Жовнерчик Д.И.

Руководитель:

Минск 2011

ЗАДАНИЕ

по курсовой работе

Студенту гр.107818 Жовнерчику Дмитрию Ивановичу

. Тема работы: Проектирование базы данных продовольственного магазина
средствами MS Access

. Сроки сдачи студентом законченного проекта

3. Исходные данные к проекту: Необходимо создать базу
данных, предназначенную для директора продовольственного магазина. База данных
должна обеспечивать хранение сведений об имеющихся в нем товарах, о торговых
базах и товарах, хранящихся на этих базах. Магазин осуществляет закупку товаров
на разных базах, предпочитая при этом закупать одни виды товара на одних базах,
а другие на других. Магазин имеет несколько отделов. Каждый товар в магазине
продается, по крайней мере, в одном отделе. Каждый отдел имеет заведующего.
Товары, имеющиеся в магазине и хранящиеся на базах, характеризуются ценой и
количеством.

Директору могут потребоваться следующие сведения:

Какие товары имеются в магазине (на базе)?

Какие отсутствующие товары может заказать магазин на базе?

Какие товары, и в каком количестве имеются в отделе магазина?

Список заведующих отделами магазина?

Суммарная стоимость товара в каждом отделе?

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

. Содержание расчетно-пояснительной записки:

.Обследование предметной области

.Проектирование источников информации

.Перечень объектов, реализованных в базе данных

.Перечень SQL-запросов

.Разграничение прав доступа, администрирование

. Консультанты по работе (с указанием разделов проекта):

По всем разделам консультировал Дербан Андрей Николаевич

. Дата выдачи задания

. Календарный график работы над проектом (с указанием трудоемкости
отдельных этапов):

. Сбор теоретической части

. Разработка структуры базы данных

. Создание таблиц, заполнение таблиц записями

. Разработка запросов, форм, отчетов, макросов средствами MS Access

. Работа в среде Mysql,
разработка sql-запросов

. Разграничение прав доступа в MS Access

. Составление записки, разработка графической части

Оглавление

Введение

. Обследование предметной области

.1 Цель создания базы данных

.2 Предполагаемые задачи и функции

.3 Описание используемого программного обеспечения

. Проектирование источников информации

.1 Разработка структуры БД

.2 Инфологическое проектирование

.3 Структура таблиц

.4 Реляционная схема базы данных

. Перечень объектов, реализованных в базе данных

.1 Формы

.2 Отчёты

.3 Макросы

. Перечень SQL-запросов

.1 Запрос, показывающий какие товары необходимо заказать
магазину на базе

.2 Запрос, показывающий какие товары присутствуют в отделах
магазина

.3 Запрос, показывающий заведующих отделов

.4 Запрос, подсчитывающий суммарную стоимость товара в каждом
отделе

. Разграничение прав доступа, администрирование

Заключение

Литература

Введение

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

Управление любого предприятия ставит перед собой цели добиться
продвижения вперед, развития и прогрессирования в целом деятельности
предприятия.

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

В данной курсовой работе будем использовать реляционную СУБД ACCESS, входящую в состав пакета Microsoft Office 2003. Дружественный интерфейс и простота настройки,
эффективные средства создания таблиц, форм, запросов, отчетов, средства
организации работы с базами данных и защита информации — вот далеко не полный
перечень достоинств этого приложения.

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

1.
Обследование предметной области

1.1 Цель
создания базы данных

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

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

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

— значительно уменьшаются затраты времени на передачу дополнительной
информации.

В информационной системе предполагается наличие следующих функций:

ввод и редактирование информации о поставщиках и поставках товаров
(поставки);

ввод и редактирование данных о товарах;

формирование на основе данных о поставках и продажах следующих отчетов:

перечень товаров, закупленных в отчетный месяц на базах (количество,
наименование);

перечень проданных товаров;

.3 Описание
используемого программного обеспечения

база данное запрос
администрирование доступ

Microsoft Access — это
система управления базами данных (СУБД), предназначенная для создания и
обслуживания баз данных, обеспечения доступа к данным и их обработки.

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

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

Основными свойствами полей являются имя поля, тип поля, его размер,
определяющий предельную длину данных, размещаемых в этом поле, и др.

При работе с Microsoft Access 2000 и Microsoft Access 2003 используются следующие типы данных:

·  текстовый — тип данных, используемый для хранения простого
неформатированного текста, число символов в котором не должно превышать 255;

·        поле MEMO —
специальный тип данных, применяемый для хранения больших объёмов текста (до 65
535 символов);

·        числовой — тип данных для хранения чисел;

·  дата/время — тип данных для хранения значений даты и времени;

·  денежный — тип данных для хранения денежных значений (длина поля 8 байт);

·        счётчик — специальный тип данных, используемый для
автоматической нумерации записей;

·        логический — для хранения логических данных, которые могут
иметь одно из двух возможных значений Да или Нет;

·        поле объекта OLE —
специальный тип данных, предназначенный для хранения объектов OLE (электронных таблиц Microsoft Excel, документов Microsoft Word,
звукозаписей и др.);

·        гиперссылка — специальное поле для хранения адресов URL Web-объектов;

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

Числовые поля могут иметь следующие размеры:

·  байт (Byte) — целые числа от 0 до 255 (1 байт);

·        целое (Integer) — целые числа от минус 32768 до +32767 (2
байта);

·        длинное целое (Long Integer) — целые числа от минус
2147483648 до +2147483647 (4 байта);

·        одинарное с плавающей точкой (Single) — числа от минус 3,4´10³⁸ до +3,4´10³⁸ с точностью до 7
знаков (4 байта);

·        двойное с плавающей точкой (Double) — числа от минус 1,797´10³⁰⁸ до +1,797´10³⁰⁸ с точностью до 15
знаков (8 байт).

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

Взаимосвязанные двухмерные таблицы, являющиеся объектами СУБД, называются
реляционными таблицами, а сами СУБД — реляционными базами данных.

СУБД Microsoft Access 2000 и Microsoft Access 2003
ориентированы на работу с объектами семи различных типов: таблицами, запросами,
формами, отчётами, страницами, макросами, модулями.

Таблицы — это основной объект базы данных, в котором хранятся все данные,
имеющиеся в базе, а также структура базы (поля, их типы, свойства).

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

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

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

Страницы — это специальные объекты баз данных, реализованные в версиях Access 2000 и Access 2003. В более ранних версиях Access такие страницы доступа к данным отсутствуют. Эти
страницы являются диалоговыми Web-страницами,
т.е. осуществляют интерфейс между клиентом, сервером и базой данных,
размещённой на сервере.

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

Модули создаются пользователем путём применения интегрированной среды объектно-ориентированного
программирования Visual Basic for Applications (VBA). Основной идеей объектно-ориентированного
программирования является объединение данных и оперирующих ими функций в один
объект. Данные в VBA
рассматриваются как совокупность объектов (таблиц, форм, отчётов и т. д.),
имеющих свойства и методы, реализующие заранее определённые действия над
объектами.

2.
Проектирование источников информации

.1 Разработка
структуры БД

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

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

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

Не должно быть повторений и между таблицами.

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

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

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

Каждое поле должно быть связано с темой таблицы.

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

В таблице должна присутствовать вся необходимая информация.

— Информацию следует разбивать на наименьшие логические единицы.

2.2
Инфологическое проектирование

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип — связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому
представителю (экземпляру) сущности А соответствует 1 или 0 представителей
сущности В:

Студент может не «заработать» стипендию, получить обычную или
одну из повышенных стипендий.

Второй тип — связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А
соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то
существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).
Но в нашей работе такие типы связи нам не следует употреблять.

На рисунке 2.2. изображена инфологическая модель базы данных
продовольственного магазина.

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

2.3 Структура
таблиц

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

—   Текстовый. Текст или числа не требующие проведения расчётов.

—        МЕМО. Поле этого типа предназначено для хранения небольших
текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым
или проиндексированным.

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

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

—   Денежный. Денежные значения и числовые данные, используемые в
математических вычислениях.

—        Дата/Время. Дата и время хранятся в специальном фиксированном
формате.

На рисунке 2.3. можно увидеть таблицы для БД продовольственного магазина
в режиме конструктора.

Рис.2.3 Таблицы базы данных продовольственного магазина в режиме
конструктора

Далее на рисунке 2.3.1. приведены копии экранов таблиц с записями:

Рис. 2.3.1 Копии экранов таблиц с записями

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

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

. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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

Рис. 2.4 Реляционная структура СУБД Access для информационной системы продовольственного
магазина

3. Перечень
объектов, реализованных в базе данных

3.1 Формы

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

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

В данной Базе Данных в наличие имеются следующие формы:

)   Форма “Поставки товаров” (рисунок 3.1.1) является всеобъемлющей,
потому что при помощи ее можно сразу произвести добавление и изменение сразу в
4 таблицы (Поставщики, Поставка, Торговые базы, Сотрудники). Также она является
главной по отношению к формам “Торговые базы подчиненная”.

Рис. 3.1.1 Форма “Поставки товаров”

2) Форма “Торговая база подчиненная” (рисунок 3.1.2) является подчиненной
по отношению к форме “Поставки товаров”, с помощью которой можно внести
информацию о поставляемых товарах.

Рис.3.1.2 Форма “Торговые_базы1 подчиненная форма”

3) Кнопочная форма “База данных продуктового магазина” (рисунок 3.1.11)
является как бы обложкой базы данных. Именно с ней непосредственно работает
пользователь и получает возможность доступа к объектам базы данных. Это
обыкновенная форма с кнопками, обеспечивающими возможность открытия других
форм. Создать кнопочную форму позволяет специальное средство Access — диспетчер кнопочных форм.

Рис.3.1.11 Кнопочная форма “База данных продуктового магазина”

3.2 Отчёты

В MS Access получать твердые копии результатов обработки данных
можно путем распечатки таблиц, запросов и форм, представленных в виде отчетов.
Отчет — это тип объектов в Access,
который используется для просмотра и печати данных. Отчет создается в тех
случаях, когда необходимо наглядно представить на экране или на бумаге сводную
информацию, хранящуюся в Базе Данных. Главное назначение отчета — формирование
выходных документов, которые будут представлять собой копию форм реальных
документов предприятия, с которыми непосредственно работает пользователь.

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

ü Отчет “Продажи по отделам” (рисунок 3.2.1), который
предоставляет информацию об проданных товаров в магазине.

Рис.3.2.1Отчет “ Продажи по отделам ”

ü Отчет “Товары закупленные по отделам”(рисунок 3.2.2), который
предоставляет информацию о закупленных магазином товаров по отделам.

Рис.3.2.2 Отчет “ Товары закупленные по отделам ”

ü Отчет “Сотрудники магазина”(рисунок 3.2.3), который
предоставляет информацию о сотрудниках работающих в магазине.

Рис.3.2.3 Отчет “ Сотрудники магазина ”

3.3 Макросы

Макросы — это небольшие программы, в которых содержатся макрокоманды Access (для которых можно определить
условие, если условие выполняется, то выполняется и сама макрокоманда),
предназначенные для выполнения одного или нескольких действий. Макрос можно
запускать из окна базы данных или связывать с событием.

Основным назначением макроса является создание элементов для
пользовательского интерфейса.

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

·  Отображение суммарной стоимости товаров по отделам;

Данные макросы связаны с кнопками на формах.

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

Далее перечисление копии экранов макроса (рисунок 3.3.1), макрокоманды
(рисунок 3.3.2) и соответственно отработка этого макроса (рисунок 3.3.3).

Рис.3.3.1 Копия экрана макроса

Рис.3.3.2 Копия экрана макрокоманд макроса1

Рис.3.3.3 Копия экрана отработки макроса1

4. Перечень SQL-запросов

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

4.1 Запрос,
показывающий какие товары необходимо заказать магазину на базе

Структура синтаксиса запроса на SQL:

SELECT magazin.name_tovar, otdel.name_otdel, magazin.kol_vo,
magazin.nalichieotdel INNER JOIN magazin ON otdel.kod_otdel =
magazin.kot_otdelBY magazin.name_tovar, otdel.name_otdel, magazin.kol_vo,
magazin.nalichie,.kod_tovara(((magazin.nalichie)=-1))BY otdel.name_otdel;

Результат выполнения запроса:

4.2 Запрос,
показывающий какие товары присутствуют в отделах магазина

Структура синтаксиса запроса на SQL:

SELECT magazin.name_tovar, otdel.name_otdel, magazin.kol_vo,
magazin.nalichieotdel INNER JOIN magazin ON otdel.kod_otdel =
magazin.kot_otdelBY magazin.name_tovar, otdel.name_otdel, magazin.kol_vo,
magazin.nalichie, magazin.kod_tovara(((magazin.nalichie)=-1))BY
otdel.name_otdel;

Результат выполнения запроса:

4.3 Запрос,
показывающий заведующих отделов

Структура синтаксиса запроса на SQL:

SELECT sotrudniki.name_otdel, doljnost.doljnost,
sotrudniki.familia, sotrudniki.imja,.щесруыемщ, doljnost.zarplataotdel INNER JOIN (doljnost INNER JOIN
sotrudniki ON doljnost.kod_dol = sotrudniki.kod_doljnosti)otdel.kod_otdel =
sotrudniki.kod_otdelBY sotrudniki.name_otdel, doljnost.doljnost,
sotrudniki.familia, sotrudniki.imja,.щесруыемщ, doljnost.zarplata(((doljnost.doljnost)=»менеджер»));BY sotrudniki.name_otdel;

Результат выполнения запроса:

4.4 Запрос,
подсчитывающий суммарную стоимость товара в каждом отделе

Структура синтаксиса запроса на SQL:

select a.name_otdel, sum(a.summa) as summa_otdel

(SELECT otdel.name_otdel, magazin.name_tovar, magazin.cena,
magazin.kol_vo, (cena)*(kol_vo) AS summaotdel INNER JOIN magazin ON
otdel.kod_otdel =magazin.kot_otdelBY otdel.name_otdel, magazin.name_tovar,
magazin.cena, magazin.kol_vo) aby a.name_otdel;

Результат выполнения запроса:

5.
Разграничение прав доступа, администрирование

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

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

Установка пароля при открытии базы данных — самый распространенный способ
защиты. После установки пароля, при открытии базы данных появляется диалоговое
окно, предлагающее пользователю ввести пароль. Открыть базу данных смогут лишь
те пользователи, которые введут правильный пароль. Этот способ достаточно
надежен (MS Access шифрует пароль таким образом, что к нему нет прямого
доступа при чтении файла базы данных), но он применяется только при открытии
базы данных. После открытия базы данных все объекты становятся доступными для
пользователя (пока не определена защита на уровне пользователей). Для базы
данных, которой совместно пользуется небольшая группа пользователей или на
автономном компьютере, установка пароля обычно оказывается достаточной.

Наиболее гибким и распространенным способом защиты базы данных является
защита данных на уровне пользователей. Этот способ защиты подобен способам,
используемым в большинстве сетевых систем. От пользователей требуется
идентифицировать себя и ввести пароль, когда они запускают MS Access. Внутри файла рабочей группы они идентифицируются как
члены группы. MS Access по умолчанию создает две группы:
администраторы (группа “Admins”) и пользователи (группа “Users”). Допускается
также определение других групп. Группам и пользователям предоставляются
разрешения на доступ, ограничивающие возможность доступа к каждому объекту базы
данных.

Следует отметить три главных преимущества защиты на уровне пользователей:

·  
программа
защищается как интеллектуальная собственность;

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

·  
защищаются
конфиденциальные сведения в базе данных.

В данной курсовой работе были созданы две группы пользователей, которые
наделены разными правами, то есть им присущи разные роли.

В первой группе “Admins”
содержится пользователь “Admin”,
у которого есть все привилегии на корректировку, удаление, восстановление,
администрирование базы данных.

Во второй группе Users
содержится один пользователь (“Директор).

Пользователь “Директор” имеет права на чтение таблиц, просмотр отчетов,
просмотр данных таблиц через формы, запуска макросов и просмотр отображаемых
результатов в случае отработки макрокоманд(надо учесть то, что могут не
отрабатывается макросы, так как есть разные макрокоманды, которые открывают тот
перечень объектов, которые разрешен данному пользователю). Ограничение прав
пользователя “Директор”: запрещена работа с запросами; запрещено удалять,
обновлять, вносить какие-либо корректировки в базу данных. Для пользователя
“Директор” характерен просмотр и чтение объектов базы данных. Это объясняется
тем, что для него важно функционирование и отображение необходимой информации в
наглядном виде.

Заключение

В результате проведенной работы разработана база данных
продовольственного магазина, структура и схема базы данных, разработаны формы
для просмотра и ввода данных, созданы различные типы запросов и отчетов
согласно заданию, созданы макросы. Еще одним важным аспектом базы данных
является возможность отбора из большого объема имеющихся данных необходимой
информации, которую, в свою очередь, можно представить в форме различного вида
отчетов, что позволяет более наглядно просмотреть информацию и оценить общую
работу продовольственного магазина. Приобретены навыки по проектированию базы
данных и созданию различных объектов базы данных в среде MS Access 2003.

Литература

1.  Кауфельд Джон. Microsoft Office Access 2003 для
«чайников». — М.: Диалектика, 2004. — 320 с.

2.      Пасько В. Аccess 2000 для пользователя. — К.: BHV,1999. — 384с.

.        Гончаров А.Ю. Аccess 2003 Самоучитель с примерами. — М.: КУДИЦ-ОБРАЗ, 2004
— 272 с.

4.  Методическая литература по MS Access.

август
8
, 2016

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

Какие данные нам нужны

Почти всю нужную информацию мы узнали из предыдущей вводной статьи.
Нам нужна таблица товаров, которая содержит стандартный набор:
артикул — он же ключ таблицы (автоинкремент), название, цену (для простоты пусть будет целое число).
Рейтинг или популярность, условимся, что это будет целое число от 1 до 10.
Значения мы проставим в базе руками и фото — название файла с фото товара.
Отдельно будут 2 поля — категория товара и бренд.
Опять-таки для упрощения условимся, что каждый товар может принадлежать только одной категории.
Бренд у товара тоже один.
Бренды и категории вынесем в отдельные таблицы.
В основной таблице с товарами будем хранить только айдишники категорий и брендов.

Чтобы было чуть нагляднее, ниже скриншот из dbForgeStudio — таблица товаров с заполненными данными

Создаем нужные таблицы

Сначала вспомогательные таблицы категорий и брендов.

    create table categories(
        id int(10) unsigned not null auto_increment,
        category varchar(255) not null,
        primary key (id)
    )
    engine = innodb
    auto_increment = 4
    avg_row_length = 5461
    character set utf8
    collate utf8_general_ci;

    create table brands(
        id int(10) unsigned not null auto_increment,
        brand varchar(255) default null,
        primary key (id)
    )
    engine = innodb
    auto_increment = 7
    avg_row_length = 2730
    character set utf8
    collate utf8_general_ci;

Как видим, обе таблицы крайне просты — id и название ккатегории или бренда.
Теперь таблица товаров.

    create table goods(
        id int(10) unsigned not null auto_increment,
        good varchar(255) not null,
        category_id int(10) unsigned not null,
        brand_id int(10) unsigned not null,
        price int(11) unsigned not null,
        rating int(11) unsigned not null default 0,
        photo varchar(255) not null,
        primary key (id),
        index FK_goods_brands_id (brand_id),
        index FK_goods_categories_id (category_id),
        constraint FK_goods_brands_id foreign key (brand_id)
        references brands (id) on delete cascade on update cascade,
        constraint FK_goods_categories_id foreign key (category_id)
        references categories (id) on delete cascade on update cascade
    )
    engine = innodb
    auto_increment = 15
    avg_row_length = 1170
    character set utf8
    collate utf8_general_ci;

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

Заполняем их данными

Пусть у нас будет 3 категории

    INSERT INTO categories VALUES 
        (1, 'Ноутбуки'),
        (2, 'Смартфоны'),
        (3, 'Видеокарты');

6 брендов

    INSERT INTO brands VALUES 
        (1, 'Apple'),
        (2, 'Samsung'),
        (3, 'Acer'),
        (4, 'Lenovo'),
        (5, 'Asus'),
        (6, 'Gigabyte');

и 14 товаров

    INSERT INTO goods VALUES 
        (1, 'Ноутбук Apple MacBook Air', 1, 1, 60000, 8, 'apple_macbook_air.jpg'),
        (2, 'Ноутбук Apple MacBook Pro', 1, 1, 70000, 9, 'apple_macbook_pro.jpg'),
        (3, 'Ноутбук Lenovo IdeaPad', 1, 4, 17000, 5, 'lenovo_idea_pad.jpg'),
        (4, 'Ноутбук Lenovo G5030', 1, 4, 16000, 7, 'lenovo_g5030.jpg'),
        (5, 'Ноутбук Acer Aspire', 1, 3, 21000, 8, 'acer_aspire.jpg'),
        (6, 'Смартфон Samsung Galaxy A7', 2, 2, 30000, 9, 'samsung_galaxy_a7.jpg'),
        (7, 'Смартфон Samsung Galaxy A5', 2, 2, 17000, 8, 'samsung_galaxy_a5.jpg'),
        (8, 'Смартфон Apple iPhone SE', 2, 1, 38000, 10, 'apple_iphone_se.jpg'),
        (9, 'Смартфон Asus Zenfone Laser', 2, 5, 12000, 6, 'asus_zenfone_laser.jpg'),
        (10, 'Смартфон Lenovo A5000', 2, 4, 11000, 3, 'lenovo_a5000.jpg'),
        (11, 'Смартфон Lenovo P90', 2, 4, 16000, 5, 'lenovo_p90.jpg'),
        (12, 'Видеокарта ASUS', 3, 5, 2000, 8, 'asus_video.jpg'),
        (13, 'Видеокарта GIGABYTE GT-740', 3, 6, 6000, 9, 'gigabyte_video_gt740.jpg'),
        (14, 'Видеокарта GIGABYTE GTX-960', 3, 6, 14000, 10, 'gigabyte_video_gtx960.jpg');

Все файлы с картинками найдете в архиве с исходниками, папка goods.

P.S. Исходники пока не выкладываю, они будут после публикации всех уроков этой серии.

Следующий урок про структуру проекта и базовую верстку готовится к публикации.
За обновлениями и выходом следующих статей следите здесь на сайте или в твиттере
@webdevkin15

UPDATED: урок про структуру проекта и верстку опубликован

Все об интернет-магазинах

Анонсы статей, обсуждения интернет-магазинов, vue, фронтенда, php, гита.

Истории из жизни айти и обсуждение кода.