Размещено на http: //www. allbest. ru/

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение высшего образования «Московский государственный технологический университет «СТАНКИН»

(ФГБОУ ВО МГТУ «СТАНКИН»)

ИНСТИТУТ информационных систем и технологий

Кафедра информационных систем

Отчет по самостоятельной работе

по дисциплине «Управление данными»

на тему: «Проектирование базы данных магазина игрушек»

Студент группа ИДБ-16-06 Якубова В.А.

Руководитель старший преподаватель

Быстрикова В. А.

Москва 2018



Оглавление

• 1. Анализ предметной области
• 2. Концептуальное проектирование
• 3. Логическое проектирование
• 4. Физическое проектирование
• Заключение
• Список использованной литературы
• Приложения


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

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

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

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

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

Основные функции магазина:

· формирование товарных запасов и поддержание их на необходимом уровне;

· предоставление покупателю всей необходимой информации о продаваемом товаре;

· соблюдение баланса между предложением и спросом путем поддержания цен на приемлемом для потребителя уровне;

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

В качестве первого примера, за неимением готовых БД детских магазинов, возьмем сайт интернет-магазина Игро-ландия (https://www.toys-land.ru/). Главная страница, а по совместительству - каталог товаров, сайта выглядит следующим образом (рисунок 1.1).

Рисунок 1.1 Каталог товаров на сайте

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



Рисунок 1.2 Информация об игрушках

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

· возможность онлайн-консультирования со специалистом;

· информация об акциях и скидках;

· функция поиска по сайту, упрощающая процесс выбора подходящей позиции;

· новостной раздел, где пользователь может узнать больше о магазине и режиме работы.

В качестве второго примера рассмотрим программный продукт «1С: Магазин одежды и обуви 8». Он предназначен для автоматизации розничных продаж в бутиках и магазинах, торгующих одеждой, обувью, аксессуарами, товарами для спорта и активного отдыха. Решение автоматизирует как одиночные магазины, так и розничные торговые сети.

Функции «1С: Магазин одежды и обуви 8»:

Складские операции.

-Отслеживание поступления и перемещения товара (рис. 1.3 и 1.4);



Рисунок 1.3 Лист учета поступления товаров

Рисунок 1.4 Лист учета перемещения товаров

Формирование отчетов.

-Анализ продаж магазина (рис. 1.5);

-Анализ продуктивности работы магазина;



Рисунок 1.5 Анализ продаж магазина

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

-Добавление и редактирование сведений о товаре (рис. 1.6);

-Возможность поиска товаров по их характеристикам (рис. 1.7).

Рисунок 1.6 Общая информация о конкретном товаре



Рисунок 1.7 Страница поиска товара по цветоразмерным характеристикам

Учет и хранение сведений о сотрудниках магазина.

-Расчет заработной платы;

-Составление графика работы.

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

Учет и хранение сведений о сотрудниках магазина;

Ведение клиентской базы;

Ведение базы выставляемых на продажу товаров;

Складские операции.

2. Концептуальное проектирование

Концептуальное проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Конечный результат этапа концептуального проектирования - информационно-логическая модель данных предметной области (концептуальная модель). Она определяет состав и структуры данных предметной области, функциональную связь между ними.

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

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

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

Сотрудник может совершать следующие действия:

1. Ведение клиентской базы.

2. Подтверждение и отправка заказа.

3. Изменение информации об игрушках.

4. Проверка наличия той или иной позиции на складе.

Клиент может совершать следующие действия:

1. Поиск информации об игрушках.

2. Составление и отправка заказа на обработку.

Директор может выполнять те же действия, что и сотрудник, а также:

1. Ведение базы сотрудников.

2. Проведение закупок.

Рассмотрим составление диаграммы вариантов использования (рисунок 2.1).

Рисунок 2.1 Диаграмма вариантов использования

Для функционирования выделенных задач нужно хранение и представление данных о следующих объектах:

· Клиенты

· Сотрудники

· Заказы

· Игрушки

· Поставщики

· Поставки

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

· Условно-постоянные данные (например, характеристики продаваемых игрушек)

· Данные, которые оперативно обновляются при каждом решении задачи (какая игрушка, в каком количестве продана, поступила, когда)

3. Логическое проектирование

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

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

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

Атрибут сущности - определенное, далее неделимое свойство сущности. Каждый экземпляр сущности определяется совокупность значений атрибутов.

Ключ сущности - атрибут (набор атрибутов), однозначно идентифицирующий экземпляр сущности.

Связь - логическое соотношение между сущностями. Степень связи - максимальное количество экземпляров одной сущности, связанных с одним экземпляром другой сущности, может иметь тип 1:1, 1:М, М:1 или М:М.

На предыдущем этапе были выделены объекты, для которых необходимо хранить информацию. Они станут сущностями при построении ER-диаграмм.

Рассмотрим ER-диаграмму «Клиент составляет заказ».

Рисунок 3.1 ER-диаграмма «Клиент составляет заказ»

Связь СОСТАВЛЯЕТ (рис. 3.1) имеет тип 1:М, так как каждый клиент может составить один или несколько заказов. Сущность КЛИЕНТ имеет обязательный класс принадлежности, так как предполагаем, что клиент обязательно обратился в магазин для оформления заказа. Сущность ЗАКАЗ имеет обязательный класс принадлежности, так как ЗАКАЗ обязательно должен составить какой-либо КЛИЕНТ.

Рассмотрим ER-диаграмму «Заказ состоит из игрушек».

Рисунок 3.2 ER-диаграмма «Заказ состоит из игрушек»

Связь ИМЕЕТ (рис. 3.2) имеет тип М:М, так как каждый ЗАКАЗ может содержать несколько ИГРУШЕК, а одна и та же ИГРУШКА может содержаться в нескольких ЗАКАЗАХ. Сущность ЗАКАЗ имеет обязательный класс принадлежности, так как в заказе должна содержаться хотя бы одна ИГРУШКА. Сущность ИГРУШКА имеет необязательный класс принадлежности, так как ИГРУШКА необязательно кем-то заказана.

Рассмотрим ER-диаграмму «Поставщик совершает поставку».

Рисунок 3.3 ER-диаграмма «Поставщик совершает поставку»

Связь СОВЕРШАЕТ (рис. 3.3) имеет тип 1:М, т.к. ПОСТАВЩИК может совершить множество ПОСТАВОК, а конкретную ПОСТАВКУ совершает конкретный ПОСТАВЩИК. Сущность ПОСТАВЩИК имеет обязательный класс принадлежности, т.к. подразумеваем, что ПОСТАВЩИК обязательно должен был совершить хотя бы одну ПОСТАВКУ. ПОСТАВКА имеет обязательный класс принадлежности, потому что ПОСТАВКУ обязательно совершил какой-то ПОСТАВЩИК.

Рассмотрим ER-диаграмму «Сотрудник выполняет заказ».



Рисунок 3.4 ER-диаграмма «Сотрудник выполняет заказ»

Связь ВЫПОЛНЯЕТ (рис. 3.4) имеет тип 1:М, т.к. СОТРУДНИК может выполнять множество ЗАКАЗОВ, а в выполнении ЗАКАЗА участвует только один СОТРУДНИК . Сущность СОТРУДНИК имеет необязательный класс принадлежности, т.к. СОТРУДНИК может не участвовать в выполнении ни одного ЗАКАЗА. Сущность ЗАКАЗ имеет обязательный класс принадлежности, т.к. ЗАКАЗ обязательно должен выполнить какой-либо сотрудник.

Рассмотрим ER-диаграмму «Поставка имеет товар».

Рисунок 3.5 ER-диаграмма «Поставка состоит из игрушек»

Связь СОСТОИТ ИЗ (рис. 3.5) имеет тип М:М, т.к. ИГРУШКА может содержать в себе множество ИГРУШЕК, и ИГРУШКА может содержаться во множестве ПОСТАВОК. Сущность ПОСТАВКА имеет обязательный класс принадлежности, т.к. в ПОСТАВКЕ обязательно содержится хотя бы одна ИГРУШКА.

Сущность ИГУШКА имеет необязательный класс принадлежности, т.к. ИГРУШКА может не содержаться в ПОСТАВКЕ.

Рассмотрим ER-диаграмму «Игрушка имеет категорию».



Рисунок 3.6 ER-диаграмма «Игрушка имеет категорию»

Связь ИМЕЕТ (рис. 3.6) имеет тип М:1, т.к. ИГРУШКА может принадлежать только к одной КАТЕГОРИИ, и в каждой КАТЕГОРИИ может содержаться одна или несколько ИГРУШЕК. Сущность КАТЕГОРИЯ имеет обязательный класс принадлежности, т.к. в КАТЕГОРИИ обязательно содержится хотя бы одна ИГРУШКА. Сущность ИГУШКА имеет обязательный класс принадлежности, т.к. ИГРУШКА обязательно должна иметь принадлежность к какой-либо одной КАТЕГОРИИ.

Теперь сформируем набор предварительных отношений с указанием первичного ключа для каждого из них. Для этого применим правила формирования отношений. Связь СОСТАВЛЯЕТ (рис. 3.1) удовлетворяет условиям правила 4, в соответствии с которым получаем 2 отношения:

1. Клиент (КодКлиента, …)

2. Заказ (КодЗаказа, КодКлиента, …) - добавился неключевой атрибут КодКлиента.

Связь СОСТОИТ ИЗ (рис. 3.2) удовлетворяет условиям правила 6, в соответствии с которым получаем 3 отношения:

1. Заказ (КодЗаказа, …)

2. Игрушка (КодИгрушки, …)

3. ЗаказаннаяИгрушка (КодЗаказа, КодИгрушки, …)

Связь СОВЕРШАЕТ (рис. 3.3) удовлетворяет условиям правила 4, в соответствии с которым получаем 2 отношения:

1. Поставщик (КодПоставщика, …)

2. Поставка (КодПоставки, КодПоставщика, …)

Связь ВЫПОЛНЯЕТ (рис. 3.4) удовлетворяет условиям правила 4, в соответствии с которым получаем 2 отношения:

1. Сотрудник (КодСотрудника, …)

2. Заказ (КодЗаказа, КодСотрудника, …) - добавился неключевой атрибут КодСотрудника

Связь СОСТОИТ ИЗ (рис. 3.5) удовлетворяет условиям правила 6, в соответствии с которым получаем 3 отношения:

1. Поставка (КодПоставки, …)

2. Игрушка (КодИгрушки, …)

3. Сделка (КодПоставки, КодИгрушки, …)

Связь ИМЕЕТ (рис. 3.6) удовлетворяет условиям правила 4, в соответствии с которым получаем 2 отношения:

1. КатегорияИгрушки (КодКатегории, …)

2. Игрушка (КодИгрушки, КодКатегории, …) - добавился неключевой атрибут КодКатегории

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

1. Клиент (КодКлиента, ФИО, Телефон)

2. Сотрудник (КодСотрудника, ФИО, Должность, Телефон)

3. КатегорияИгрушки (КодКатегории, НазваниеКатегории)

4. Игрушка (КодИгрушки, КодКатегории, НазваниеИгрушки, Цена, Количество)

5. Поставка (КодПоставки, КодПоставщика, ДатаИсполнения, ЦенаДоставки)

6. Сделка (КодПоставки, КодИгрушки, Количество)

7. ЗаказанныеИгрушки (КодЗаказа, КодИгрушки, Количество)

8. Поставщик (КодПоставщика, Название, Город, Телефон)

9. Заказ (КодЗаказа, КодКлиента, КодСотрудника, ДатаЗаказа, ДатаИсполнения, Стоимость, Статус)



4. Физическое проектирование

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

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

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

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

В таблице «Клиент» (табл. 4.1) хранится информация обо всех клиентах магазина.

Таблица 4.1 Структура таблицы «Клиент»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Ограничение	Ссылка
КодКлиента	smallint	NOT NULL	Первичный
ФИО	varchar(50)	NOT NULL
Телефон	varchar(50)	NOT NULL

В приложении А (п.1) приведен код SQL-оператора для создания таблицы «Клиент». В приложении Б (Рисунок Б.1) приведен пример заполнения таблицы «Клиент».

В таблице «Сотрудник» (табл. 4.2) хранится информация обо всех сотрудниках магазина.

Таблица 4.2 Структура таблицы «Сотрудник»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Ограничение	Ссылка
КодСотрудника	smallint	NOT NULL	Первичный
ФИО	varchar(50)	NOT NULL
Должность	varchar(50)	NOT NULL
Телефон	varchar(50)	NOT NULL

В приложении А (п. 2) приведен код SQL-оператора для создания таблицы «Сотрудник». В приложении Б (рис. Б.2) приведен пример заполнения таблицы «Сотрудник».

В таблице «КатегорияИгрушки» (табл. 4.3) хранится информация о всех категориях продаваемых игрушек.

Таблица 4.3 Структура таблицы «КатегорияИгрушки»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Ограничение	Ссылка
КодКатегории	smallint	NOT NULL	Первичный
Название Категории	varchar(50)	NOT NULL

В приложении А (п. 3) приведен код SQL-оператора для создания таблицы «КатегорияИгрушки». В приложении Б (рис. Б.3) приведен пример заполнения таблицы «КатегорияИгрушки».

В таблице «Игрушка» (табл. 4.4) хранится информация о всех доступных игрушках в магазине.

Таблица 4.4 Структура таблицы «Игрушка»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Огран.	Ссылка
КодИгрушки	smallint	NOT NULL	Первичный
КодКатегории	smallint	NOT NULL	Внешний			Категория Игрушки (Код Категории)
Название Игрушки	varchar(50)	NOT NULL
Тип	varchar(50)	NOT NULL
Цена	int	NOT NULL			>0
Количество	int	NOT NULL			>=0

В приложении А (п. 4) приведен код SQL-оператора для создания таблицы «Игрушка». В приложении Б (рис. Б.4) приведен пример заполнения таблицы «Игрушка». В таблице «Поставщик» (табл. 4.5) хранится информация обо всех поставщиках магазина.



Таблица 4.5 Структура таблицы «Поставщик»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Огранич.	Ссылка
КодПоставщика	smallint	NOT NULL	Первичный
Название	Varchar(50)	NOT NULL
Город	Varchar(50)	NOT NULL
Телефон	Varchar(50)	NOT NULL

В приложении А (п. 5) приведен код SQL-оператора для создания таблицы «Поставщик». В приложении Б (рис. Б.5) приведен пример заполнения таблицы «Поставщик».

В таблице «Поставка» (табл. 4.6) хранится информация обо всех поставленных товарах в магазин.

Таблица 4.6 Структура таблицы «Поставка»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Огран.	Ссылка
КодПоставки	smallint	NOT NULL	Первичный
КодПоставщика	smallint	NOT NULL	Внешний			Поставщик (Код Поставщика)
Дата Исполнения	date	NOT NULL		Текущая дата
ЦенаДоставки	Int	NOT NULL		0	>=0

В приложении А (п. 6) приведен код SQL-оператора для создания таблицы «Поставка». В приложении Б (рис. Б.6) приведен пример заполнения таблицы «Поставка».

В таблице «Заказ» (табл. 4.7) хранится информация о всех поставленных товарах в магазин.



Таблица 4.7 Структура таблицы «Заказ»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Огран.	Ссылка
КодЗаказа	smallint	NOT NULL	Первичный
КодКлиента	smallint	NOT NULL	Внешний			Клиент (КодКлиента)
КодСотрудника	smallint	NOT NULL	Внешний			Сотрудник (Код Сотрудника)
ДатаЗаказа	date	NOT NULL		Текущая Дата
Дата Исполнения	date	NOT NULL
Стоимость	int	NOT NULL			>0
Статус	Varchar(50)	NOT NULL

В приложении А (п. 7) приведен код SQL-оператора для создания таблицы «Заказ». В приложении Б (рис. Б.7) приведен пример заполнения таблицы «Заказ».

В таблице «ЗаказанныеИгрушки» (табл. 4.8) хранится информация обо всех проданных магазином игрушках.

Таблица 4.8 Структура таблицы «ЗаказанныеИгрушки»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Огран.	Ссылка
КодЗаказа	smallint	NOT NULL	Первичный, Внешний			Заказ (КодЗаказа)
КодИгрушки	smallint	NOT NULL	Первичный, Внешний			Игрушка (КодИгрушки)
Количество	int	NOT NULL		1	>0

В приложении А (п. 8) приведен код SQL-оператора для создания таблицы «ПроданныйТовар». В приложении Б (рис. Б.8) приведен пример заполнения таблицы «ПроданныйТовар».

В таблице «Сделка» (табл. 4.9) хранится информация о всех поставленных игрушках в магазин.

Таблица 4.9 Структура таблицы «Сделка»

Имя поля	Тип данных	Обязательное поле	Ключ	Знач. по умолчанию	Ограничение	Ссылка
КодПоставки	smallint	NOT NULL	Первичный, Внешний			Поставка (Код Поставки)
КодИгрушки	smallint	NOT NULL	Первичный, Внешний			Игрушка (Код Игрушки)
Количество	int	NOT NULL		1	>0
Стоимость	int	NOT NULL			>0

В приложении А (п. 9) приведен код SQL-оператора для создания таблицы «Сделка». В приложении Б (рис. Б.9) приведен пример заполнения таблицы «Сделка».

После создания структуры таблиц необходимо установить связи между таблицами. Для построения схемы данных (рис 4.1) был использован инструмент SQL Server Management Studio. Данная программа позволяет строить наглядные схемы данных, подключаясь непосредственно к базе данных, а также создавать связи между таблицами.



Рисунок 4.1 Схема данных



Заключение

Данная работа посвящена проектированию базы данных для магазина мягких игрушек.

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

В ходе работы были решены следующие задачи:

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

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

3. На этапе логического проектирования были построены диаграммы «сущность-связь» для объектов, которые были выделены на прошлом этапе. Были определены типы связей между объектами и классы принадлежности сущностей. На основе анализа ER- диаграмм были сформированы следующие отношения с первичными и внешними ключами: клиент, сотрудник, игрушка, КатегорияИгрушки, поставка, поставщик, заказ, ЗаказанныйТовар, сделка и добавлены неключевые атрибуты.

4. В процессе физического проектирования были определены требования к структуре таблиц базы данных, с помощью SQL - операторов созданы таблицы и связи между ними в среде SQL Server Management Studio и SQL Server.

5. 

Список использованной литературы

1. Сайт «Википедия» [Электронный ресурс] - Режим доступа: https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85, свободный. Дата обращения: 17.11.2018 г.

2. Сайт «Игро-ландия» [Электронный ресурс] - Режим доступа: https://www.toys-land.ru/, свободный. Дата обращения: 17.11.2018 г.

3. Сайт «1С: Предприятие» [Электронный ресурс] - Режим доступа: https://solutions.1c.ru/catalog/boutique/features/, свободный. Дата обращения: 09.12.2018 г.

4. Сайт «Майкрософт» [Электронный ресурс] - режим доступа: https://www.microsoft.com/ru-ru/sql-server/sql-server-downloads/, свободный. Дата обращения 17.11.2018 г.



Приложение А

база данные access продажа

SQL-операторы создания таблиц

1. SQL-операторы, необходимые для создания таблицы «Клиент»

CREATE TABLE Client (

id_client smallint PRIMARY KEY,

FIO varchar(50) NOT NULL,

phone varchar(50) NOT NULL );

2. SQL-операторы, необходимые для создания таблицы «Сотрудник»

CREATE TABLE Sotr (

id_sotr smallint PRIMARY KEY,

FIO varchar(50) NOT NULL,

post varchar(50) NOT NULL,

phone varchar(50) NOT NULL

);

3. SQL-операторы, необходимые для создания таблицы «КатегорияИгрушки»

CREATE TABLE KategoryToy (

id_kategory smallint PRIMARY KEY,

name_kategory varchar(50) NOT NULL

);



4. SQL-операторы, необходимые для создания таблицы «Игрушка»

CREATE TABLE Toy (

id_toy smallint PRIMARY KEY,

id_kategory smallint REFERENCES KategoryToy(id_kategory),

name_toy varchar(50) NOT NULL,

cost int NOT NULL CHECK (cost > 0),

number_toy int NOT NULL CHECK (number_toy >= 0),

);

5. SQL-операторы, необходимые для создания таблицы «Поставщик»

CREATE TABLE Supplier (

id_supplier smallint PRIMARY KEY,

name_sup varchar(50) NOT NULL,

city varchar(50) NOT NULL,

phone varchar(50) NOT NULL

);

6. SQL-операторы, необходимые для создания таблицы «Поставка»

CREATE TABLE Delivery (

id_delivery smallint PRIMARY KEY,

id_supplier smallint NOT NULL REFERENCES Supplier(id_supplier),

execution_date date NOT NULL DEFAULT getdate(),

cost_delivery int NOT NULL DEFAULT '0' CHECK (cost_delivery >= 0)

);



7. SQL-операторы, необходимые для создания таблицы «Заказ»

CREATE TABLE Client_Order (

id_order smallint PRIMARY KEY,

id_sotr smallint NOT NULL REFERENCES Sotr(id_sotr),

id_client smallint NOT NULL REFERENCES Client(id_client),

order_date date NOT NULL DEFAULT getdate(),

execution_date date,

order_status varchar(50) NOT NULL

);

8. SQL-операторы, необходимые для создания таблицы «ЗаказанныеИгрушки»

Create table Toy_deal (

id_order smallint REFERENCES Client_Order(id_order),

id_toy smallint REFERENCES Toy(id_toy),

number int NOT NULL DEFAULT '1' CHECK (number > 0),

PRIMARY KEY (id_order, id_toy)

);

9. SQL-операторы, необходимые для создания таблицы «Сделка»

CREATE TABLE Deal (

id_delivery smallint REFERENCES Delivery(id_delivery),

id_toy smallint REFERENCES toy(id_toy),

number int NOT NULL DEFAULT '1' CHECK (number > 0),

value int NOT NULL CHECK (value > 0),

PRIMARY KEY (id_delivery, id_toy) );



Приложение Б

Пример заполненных таблиц

1. Данные для таблицы «Клиент»

Рисунок Б.1

2. Данные для таблицы «Сотрудник»

Рисунок Б.2

3. Данные для таблицы «КатегорияИгрушки»

Рисунок Б.3



4. Данные для таблицы «Игрушка»

Рисунок Б.4

5. Данные для таблицы «Поставщик»

Рисунок Б.5

6. Данные для таблицы «Поставка»



Рисунок Б.6

7. Данные для таблицы «Заказ»

Рисунок Б.7



8. Данные для таблицы «ЗаказанныеИгрушки»

Рисунок Б.8

9. Данные для таблицы «Сделка»

Рисунок Б.9

Размещено на Allbest.ru

...