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

метки: Данные, Зоомагазин, Таблица, Атрибут, Товар, Структура, Название, Содержать

база данный таблица интерфейс

Темой данного курсового проекта является «Проектирование и разработка реляционной базы данных для информационной системы зоомагазина»

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

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

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

1. ПОСТРОЕНИЕ ИНФОЛОГИЧЕСКОЙ

КОНЦЕПТУАЛЬНОЙ МОДЕЛИ

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

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

1.1 Анализ предметной области и выявление необходимого набора сущностей

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

Наименование задачи — автоматизация учета продаж в зоомагазине.

Цель сотрудников магазина — накопление и систематизация информации о продажах в магазине.

Функции сотрудника:

Ведение учета продаж.

Составление поставок товаров.

Выявление наиболее популярных групп товаров.

Составление отчета о продажах.

Основные бизнес-правила:

Персональные данные как информация ограниченного доступа

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

Товар бывает 3-х видов: животные, аксессуары и корм.

Возраст сотрудников не может быть меньше 16 лет.

Клиент может приобрести за один раз несколько видов товаров.

Бракованный товар возвращается в магазин.

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

Перечень печатных отчетов:

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

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

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

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

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

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

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

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

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

1.2 Обоснование требуемого набора атрибутов для каждой сущности и выделение идентифицирующих атрибутов

Атрибут — поименованная характеристика сущности.

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

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

Сущность — «Аксессуары»:

Атрибуты: Название.

Сущность — «Вид млекопитающего»:

Атрибуты: Вид млекопитающего.

Сущность — «Вид птицы»:

Атрибуты: Вид птицы.

Сущность — «Вид рыбы»:

Атрибуты: Вид рыбы.

Сущность — «Возврат»:

Атрибуты: Причина, Дата возврата.

Сущность — «Гарантия»:

Атрибуты: Дата окончания, Примечания, Дата начала.

Сущность — «Должности»:

Атрибуты: Должность.

Сущность — «Животные»:

Атрибуты: Пол.

Сущность — «Касса»:

Атрибуты: Сумма, Дата и время.

Сущность — «Клиенты»:

Атрибуты: ФИО, Телефон.

Сущность — «Корм»:

Атрибуты: Название.

Сущность — «Млекопитающие»:

Атрибуты: Внешний облик, Покровы тела, Питание..

Сущность — «Оплата»:

Экономические субъекты Сущность специфика деятельности и основы формирования

... Глава1.Экономические субъекты: Сущность, специфика деятельности и основы формирования 1.1. Экономические ресурсы как основа формирования экономических субъектов экономика ... факторов национальной экономики. А процесс «производства» рабочим товара на своем рабочем месте оказывается процессом « ... всех. Но при определенных обстоятельствах данные ресурсы также могут стать экономическими. Так, в 70-х ...

Атрибуты: Дата продажи, Сумма.

Сущность — «Перечень товаров»:

Атрибуты: Цена, Название товара.

Сущность — «Поставки»:

Атрибуты: Дата поставки, Цена, Торговая надбавка.

Сущность — «Поставщики»:

Атрибуты: Страна, Адрес, Телефон, Наименование.

Сущность — «Поступление Товаров»:

Атрибуты: Партия, Кол во, Гарантия с, Гарантия по, Дата поступления.

Сущность — «Продажи»:

Атрибуты: Кол-во.

Сущность — «Птицы»:

Атрибуты: Цвет оперения.

Сущность — «Рыбы»:

Атрибуты: Тело, Питание.

Сущность — «Сотрудники»:

Атрибуты: ФИО, Дата рождения, Пол, Дата приема на работу, Образование.

Сущность — «Тип Акссесуары»:

Атрибуты: Тип акссесуары.

Сущность — «Тип Доставки»:

Атрибуты: Тип доставки.

Сущность — «Тип корм»:

Атрибуты: Тип корм.

Сущность — «Тип Животные»:

Атрибуты: Тип Животные.

Сущность — «Тип млекопитающие»:

Атрибуты: Тип млекопитающие.

Сущность — «Тип птицы»:

Атрибуты: Тип птицы.

Сущность — «Тип рыбы»:

Атрибуты: Тип рыбы.

Сущность — «Тип товара»:

Атрибуты: Тип товара.

1.3 Определение связей между объектами

Следующим этапом в проектировании инфологической модели является установление связи между сущностями.

Связь — это ассоциирование двух или более сущностей. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

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

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

Этот процесс изображен на рис. 1.1

Рисунок 1.1 — Концептуальная схема базы данных

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

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

Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели (англ. entity-relationship model).

По правилам построения ER-диаграмм в нотации Crow’s Foot (рус. «воронья лапка») сущность изображается в виде прямоугольника. Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Атрибуты сущности записываются внутри прямоугольника, изображающего сущность.

На основе проведенного проектирования, в частности на основе инфологической схемы, приведенной на рис. 1.1, получим ER-диаграмму, проектируемой базы данных, представленную в приложении A на рис. А.2.

2. ПОСТРОЕНИЕ СХЕМЫ РЕЛЯЦИОННОЙ

БАЗЫ ДАННЫХ

2.1 Построение набора необходимых отношений базы данных

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

Рисунок 2.1 — Набор необходимых отношений базы данных

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

2.2 Задание первичных и внешних ключей определенных отношений

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

Таблица 2.1 — Первичные и внешние ключи отношений

№ п/п	Название таблицы	Первичный ключ	Внешние ключи
	Аксессуары	ID_Аксессуары	ID_тип_аксессуаров
	Вид_млекопитающего	ID_вид_млекопитающего
	Вид_птицы	ID_вид_птицы
	Вид_рыбы	ID_вид_рыбы
	Возврат	Number	IDПродажа
	Гарантия	Number	IDПродажа
	Должности	ID
	Животные	ID_Животные_товар	ID_тип_животные
	Касса	ID
	Клиенты	ID
	Корм	ID_Корм	ID_тип_корм
	Млекопитающие	ID_млекопитающие	ID_тип_млекопитающие ID_вид_млекопитающего
	Оплата	ID	IDКасса IDКлиента ID_сотрудника
	Перечень_товаров	ID_товара	ID_тип_товара
	Поставки	ID	ID_поставщика IDТовара ID_Тип_доставки
	Поставщики	ID
	ПоступлениеТоваров	ID	IDПоставки IDтовар IDСотрудника
	Продажи	IDПродажи	IDТовара IDОплата
	Птицы	ID_товар_птицы	ID_тип_птицы ID_вид_птицы
	Рыбы	ID_товар_рыбы	ID_тип_рыбы ID_вид_рыбы
	Сотрудники	ID	ID_должности
	Тип_акссесуары	ID_тип_Акссесуары
	Тип_доставки	ID_Тип_доставки
	Тип_животные	ID_тип_животные
	Тип_корм	ID_тип_корм
	Тип_млекопитающие	ID_тип_млекопитающие
	Тип_птицы	ID_тип_птицы
	Тип_рыбы	ID_тип_рыбы
	Тип_товара	ID_тип_товара

2.3 Приведение отношения БД к третьей нормальной форме

Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.[4]

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

Определение 3НФ — неключевые атрибуты не должны определять другие неключевые атрибуты.

2.4 Определение ограничений целостности для внешних ключей отношений и для отношений в целом

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

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

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

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

Ограничение целостности, накладываемые на разрабатываемую систему:

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

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

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

2.5 Графическое представление связей между внешними и первичными ключами

По результатам нормализации, определении первичных и внешних ключей, связей между сущностями, была получена схема реляционной базы данных, представленная в приложении B. Полученная ER-диаграмма построена по методу Crow’s Foot (рус. «воронья лапка») [4].

Средства моделирования Crow’s Foot специально разработаны для построения реляционных информационных систем. На ней изображаются все отношения базы данных, а также связей между внешними и первичными ключами. Первичные ключи обозначаются знаком ключа, внешние ключи обозначаются знаком ссылки.

3. СОЗДАНИЕ СПРОЕКТИРОВАННОЙ БАЗЫ ДАННЫХ

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

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

INT — Целочисленный тип. Размер — 4 байта

NVARCHAR — Строковый тип

BIT — Битовый тип. Используется как логический тип

DATE — Тип, определяющий дату

DATETIME — Тип, определяющий дату и время

FLOAT — Вещественный тип

MONEY — Денежный тип

REAL — Вещественный тип

Опишем все таблицы, которые будут созданы в базе данных.

Таблица Аксессуары содержит название аксессуара. Ее структура приведена в таблице 3.1.

Таблица 3.1 — Характеристика атрибутов таблицы Аксессуары

Имя атрибута	Тип	Описание
ID_Аксессуары	INT	Идентификатор аксессуара
Название	NVARCHAR(50)	Название аксессуара
ID_тип_аксессуаров	INT	Идентификатор типа аксессуара

Таблица Вид_млекопитающего содержит информацию о виде млекопитающего. Ее структура приведена в таблице 3.2.

Таблица 3.2 — Характеристика атрибутов таблицы Вид_млекопитающего

Имя атрибута	Тип	Описание
ID_вид_млекопитающего	INT	Идентификатор вида млекопитающего
Вид_млекопитающего	NVARCHAR(50)	Вид млекопитающего

Таблица Вид_птицы содержит информацию о виде птиц. Ее структура приведена в таблице 3.3.

Таблица 3.3 — Характеристика атрибутов таблицы Вид_птицы

Имя атрибута	Тип	Описание
ID_вид_птицы	INT	Идентификатор вида птиц
Вид_птицы	NVARCHAR(50)	Вид птицы

Таблица Вид_рыбы содержит информацию о виде рыб. Ее структура приведена в таблице 3.4.

Таблица 3.4 — Характеристика атрибутов таблицы Вид_рыбы

Имя атрибута	Тип	Описание
ID_вид_рыбы	INT	Идентификатор вида рыб
Вид_рыбы	NVARCHAR(50)	Вид рыб

Таблица Возврат содержит информацию о возврате товара, который был бракованный и причины возврата. Также дату возврата. Ее структура приведена в таблице 3.5.

Таблица 3.5 — Характеристика атрибутов таблицы Возврат

Имя атрибута	Тип	Описание
Number	INT	Идентификатор возврата
Причина	NVARCHAR(50)	Причина
IDПродажа	INT	Идентификатор продажи
Дата_ возврата	DATE	Дата возврата

Таблица Гарантия содержит информацию о гарантии, а именно: примечание и дату окончания и дату начало. Ее структура приведена в таблице 3.6.

Таблица 3.6 — Характеристика атрибутов таблицы Гарантия

Имя атрибута	Тип	Описание
Number	INT	Идентификатор гарантии
Дата_окончания	DATE	Дата окончания
Примечания	NVARCHAR(50)	Примечание
IDПродажа	INT	Идентификатор продажи
Дата_начало	DATE	Дата продажи

Таблица Должности служит для указания к какому типу принадлежит товар. Ее структура приведена в таблице 3.7.

Таблица 3.7 — Характеристика атрибутов таблицы Должность

Имя атрибута	Тип	Описание
ID	INT	Идентификатор должности
Должность	NVARCHAR(50)	Должность сотрудника

Таблица Животные о товаре животные, а именно его пол. Ее структура приведена в таблице 3.8.

Таблица 3.8 — Характеристика атрибутов таблицы Животные

Имя атрибута	Тип	Описание
ID_Животные_товар	INT	Идентификатор товара (животные)
ID_тип_животные	INT	Идентификатор типа животного
Пол	NVARCHAR(50)	Пол животного

Таблица Касса служит для учета продаж. Ее структура приведена в таблице 3.9.

Таблица 3.9 — Характеристика атрибутов таблицы Касса

Имя атрибута	Тип	Описание
ID	INT	Идентификатор кассы
Сумма	MONEY	Сумма кассы
Дата_и_время	DATETIME	Дата и время покупки

Таблица Клиенты содержит информацию о покупателях. Ее структура приведена в таблице 3.10.

Таблица 3.10 — Характеристика атрибутов таблицы Клиенты

Имя атрибута	Тип	Описание
ID	INT	Идентификатор клиента
ФИО	NVARCHAR(50)	Фамилия, Имя, Отчество клиента
Телефон	NVARCHAR(20)	Телефон клиента

Таблица Корм содержит информацию о корме. Ее структура приведена в таблице 3.11.

Таблица 3.11 — Характеристика атрибутов таблицы Корм

Имя атрибута	Тип	Описание
ID_Корм	INT	Идентификатор корма
Название	NVARCHAR(50)	Название корма
ID_тип_корм	INT	Идентификатор типа корма

Таблица Млекопитающие содержит информацию о млекопитающем, а именно: внешний облик, покровы тела, питание. Ее структура приведена в таблице 3.12.

Таблица 3.12 — Характеристика атрибутов таблицы Млекопитающие

Имя атрибута	Тип	Описание
ID_млекопитающие	INT	Идентификатор типа торговой точки
Внешний_облик	NVARCHAR(50)	Внешний облик млекопитающего
Покровы_тела	NVARCHAR(50)	Покровы тела млекопитающего
Питание	NVARCHAR(50)	Питание млекопитающего
ID_тип_млекопитающие	INT	Идентификатор типа млекопитающего
ID_вид_млекопитающего	INT	Идентификатор вида млекопитающего

Таблица Оплата для учёта покупки товара, указания даты продажи, суммы проданного товара. Ее структура приведена в таблице 3.13.

Таблица 3.13 — Характеристика атрибутов таблицы Оплата

Имя атрибута	Тип	Описание
ID	INT	Идентификатор оплаты
Дата продажи	DATE	Дата продажи
IDКасса	INT	Идентификатор кассы
Сумма	MONEY	Сумму оплаты
IDКлиента	INT	Идентификатор клиента
ID_сотрудника	INT	Идентификатор сотрудника

Таблица Перечень_товаров служит для учёта цены, названия товара. Ее структура приведена в таблице 3.14.

Таблица 3.14 — Характеристика атрибутов таблицы Перечень_товаров

Имя атрибута	Тип	Описание
ID_товара	INT	Идентификатор товара
Цена	MONEY	Цена товара
Название_товара	NVARCHAR(50)	Название товара
ID_тип_товара	INT	Идентификатор типа товара

Таблица Поставки служит для хранения данных о поставке, дате поставки, цене поставки и надбавки. Ее структура приведена в таблице 3.15.

Таблица 3.15 — Характеристика атрибутов таблицы Поставки

Имя атрибута	Тип	Описание
ID	INT	Идентификатор товара
Дата_поставки	DATE	Цена товара
ID_поставщика	INT	Название товара
ID_сотрудника	INT	Идентификатор типа товара
Цена	MONEY	Сумма
Торговая_надбавка	REAL	Торговая надбавка
IDТовара	INT	Идентификатор товара
ID_Тип_доставки	INT	Идентификатор типа доставки

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

Таблица 3.16 — Характеристика атрибутов таблицы Поставщики

Имя атрибута	Тип	Описание
ID	INT	Идентификатор товара
	NVARCHAR(50)	Цена товара
Адрес	NVARCHAR(200)	Название товара
Телефон	NVARCHAR(25)	Идентификатор типа товара
Наименование	NVARCHAR(150)	Сумма

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

Таблица 3.17 — Характеристика атрибутов таблицы ПоступлениеТоваров

Имя атрибута	Тип	Описание
ID	INT	Идентификатор поступления товара
IDПоставки	INT	Идентификатор поставки
Партия	INT	Партия поступления
Кол_во	INT	Количество поступления
Гарантия_с	DATE	Гарантия с
Гарантия_по	DATE	Гарантия по
IDтовар	INT	Идентификатор товара
Дата поступления	DATE	Дата поступления
IDСотрудника	INT	Идентификатор сотрудника

Таблица Продажи содержит информацию о проданных товарах. Ее структура приведена в таблице 3.18.

Таблица 3.18 — Характеристика атрибутов таблицы Продажи

Имя атрибута	Тип	Описание
IDПродажи	INT	Идентификатор продажи
Кол_во	INT	Количество
IDТовара	INT	Идентификатор товара
IDОплата	INT	Идентификатор оплаты

Таблица Птицы содержит информацию о птицах, а именно цвет оперения. Ее структура приведена в таблице 3.19.

Таблица 3.19 — Характеристика атрибутов таблицы Птицы

Имя атрибута	Тип	Описание
ID_товар_птицы	INT	Идентификатор товара птицы
ID_тип_птицы	INT	Идентификатор типа птицы
Цвет оперения	NVARCHAR(50)	Цвет оперения
ID_вид_птицы	INT	Идентификатор вида птицы

Таблица Рыбы содержит информацию о рыбах, а именно: среда обитания и тело. Ее структура приведена в таблице 3.20.

Таблица 3.20 — Характеристика атрибутов таблицы Рыбы

Имя атрибута	Тип	Описание
ID_товар_рыбы	INT	Идентификатор товара птицы
Тело	NVARCHAR(50)	Идентификатор типа птицы
Питание	NVARCHAR(50)	Питание птиц
ID_тип_рыбы	INT	Среда обитания птиц
ID_вид_рыбы	INT	Идентификатор вида птицы

Таблица Сотрудники содержит информацию о сотрудниках, а именно: его образование, пол, Ф.И.О и дата рождения. Ее структура приведена в таблице 3.21.

Таблица 3.21 — Характеристика атрибутов таблицы Сотрудники

Имя атрибута	Тип	Описание
ID_	INT	Идентификатор сотрудника
ID_должности	INT	Идентификатор должности
ФИО	NVARCHAR(50)	Фамилия, Имя, Отчество сотрудника
Дата_рождения	DATE	Дата рождения
Пол	BIT	Пол сотрудника
Дата_приема_на_работу	DATE	Дата приема сотрудника на работу
Образование	NVARCHAR(50)	Образование сотрудника

Таблица Тип_аксессуары содержит информацию о типе аксессуара. Ее структура приведена в таблице 3.22.

Таблица 3.22 — Характеристика атрибутов таблицы Тип_аксессуары

Имя атрибута	Тип	Описание
ID_тип_Аксессуары	INT	Идентификатор типа аксессуаров
Тип_аксессуары	NVARCHAR(50)	Типы аксессуаров

Таблица Тип_доставки содержит информацию о типе доставки. Ее структура приведена в таблице 3.23.

Таблица 3.23 — Характеристика атрибутов таблицы Тип_доставки

Имя атрибута	Тип	Описание
ID_Тип_доставки	INT	Идентификатор типа доставки
Тип_доставки	NVARCHAR(50)	Типы доставки

Таблица Тип_животные содержит информацию о типе животных. Ее структура приведена в таблице 3.24.

Таблица 3.24 — Характеристика атрибутов таблицы Тип_животные

Имя атрибута	Тип	Описание
ID_тип_животные	INT	Идентификатор типа животных
Тип_животные	NVARCHAR(50)	Типы животных

Таблица Тип_корм содержит информацию о типе корме. Ее структура приведена в таблице 3.25.

Таблица 3.25 — Характеристика атрибутов таблицы Тип_корм

Имя атрибута	Тип	Описание
ID_тип_корм	INT	Идентификатор тип корма
Тип_корм	NVARCHAR(50)	Тип корма

Таблица Тип_млекопитающие содержит информацию о типе млекопитающих. Ее структура приведена в таблице 3.26.

Таблица 3.26 — Характеристика атрибутов таблицы Тип_млекопитающие

Имя атрибута	Тип	Описание
ID_тип_млекопитающие	INT	Идентификатор типа млекопитающие
Тип_млекопитающие	NVARCHAR(50)	Типы млекопитающих

Таблица Тип_птицы содержит информацию о типе птице. Ее структура приведена в таблице 3.27.

Таблица 3.27 — Характеристика атрибутов таблицы Тип_птицы

Имя атрибута	Тип	Описание
ID_тип_птицы	INT	Идентификатор тип птиц
Тип_птицы	NVARCHAR(50)	Тип птиц

Таблица Тип_рыбы содержит информацию о типе рыб. Ее структура приведена в таблице 3.28.

Таблица 3.28 — Характеристика атрибутов таблицы Тип_рыбы

Имя атрибута	Тип	Описание
ID_тип_рыбы	INT	Идентификатор тип рыб
Тип_Рыбы	NVARCHAR(50)	Тип рыб

Таблица Тип_товара содержит информацию о типе товара. Ее структура приведена в таблице 3.29.

Таблица 3.29 — Характеристика атрибутов таблицы Тип_товара

Имя атрибута	Тип	Описание
ID_тип_товара	INT	Идентификатор тип товара
Тип_товара	NVARCHAR(50)	Тип товара

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

CREATE TRIGGER [dbo].[MinusReturn]

ON [dbo].[Возврат]

AFTER INSERT

AS

BEGIN

SET NOCOUNT ON;

DECLARE @val money

SET @val = (SELECT Перечень_товаров.Цена

FROM Возврат INNER JOIN

Продажи ON Возврат.IDПродажа = Продажи.IDПродажи INNER JOIN

Перечень_товаров ON Продажи.IDТовара = Перечень_товаров.ID_товара

WHERE Возврат.Number IN (SELECT Number FROM inserted))

DECLARE @ide int

SET @ide = (SELECT MAX(ID) FROM dbo.Касса)

INSERT dbo.Касса VALUES (@ide+1,-@val,GETDATE())

END

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

• ALTER TABLE [dbo].[Сотрудники] WITH CHECK ADD CONSTRAINT [CK_Сотрудники] CHECK ((datediff(year,[Дата_рождения],[Дата_приема_на_работу])>(16)))

4. ЗАПИСЬ ВЫРАЖЕНИЙ, УКАЗАННЫХ В ВАРИАНТЕ

ЗАДАНИЯ ТИПОВ ЗАПРОСОВ НА ЯЗЫКЕ SQL

1. Вывести список товаров пользующихся наибольшим спросом у покупателей:

SELECT TOP (5) dbo.Перечень_товаров.Название_товара, COUNT(dbo.Продажи.IDТовара) AS Количество

FROM dbo.Перечень_товаров INNER JOIN

dbo.Продажи ON dbo.Перечень_товаров.ID_товара = dbo.Продажи.IDТовара

GROUP BY dbo.Перечень_товаров.Название_товара

ORDER BY Количество DESC

END

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

CREATE PROCEDURE zapros2

@date1 datetime,@date2 datetime

AS

Select Клиенты.ФИО, COUNT(Оплата.ID)

From Продажи, Оплата, Клиенты

Where Оплата.ID = Продажи.IDОплата AND

Оплата.IDКлиента = Клиенты.ID AND

Оплата.[Дата продажи]>@date1 AND Оплата.[Дата продажи]<@date2

Group by Клиенты.ФИО

END

3. Вывести общий доход от всех продаж за указанный промежуток времени:

CREATE PROCEDURE zapros3

@date1 date,@date2 date

AS

Select SUM(Оплата.Сумма) as Доход

From Оплата

Where Оплата.[Дата продажи]>@date1 AND Оплата.[Дата продажи]<@date

END

4. Вывести покупателя, который чаще всех покупает товар в нашем магазине:

Select Top 1 Клиенты.ФИО, COUNT(Оплата.ID)

From Продажи, Оплата, Клиенты

Where Продажи.IDОплата = Оплата.ID AND

Оплата.IDКлиента = Клиенты.ID

Group by Клиенты.ФИО

Order by COUNT(Оплата.ID) DESC

END

5. Вывести список товаров, которые не пользуются спросом у покупателей:

CREATE PROCEDURE zapros6

AS

Select Перечень_товаров.Название_товара

From Перечень_товаров

Where Перечень_товаров.ID_товара NOT IN

Select Продажи.IDТовар

From Продажи

END

6. Вывести список продавцов, продавших большее количество товаров:

CREATE PROCEDURE zapros7

AS

Select Сотрудники.ФИО, COUNT(Оплата.ID)

From Оплата, Сотрудники

Where Оплата.ID_сотрудника = Сотрудники.ID

Group by Сотрудники.ФИО

Order by COUNT(Оплата.ID)

END

7. Вывести производителя, которые поставили в магазин больше всего товаров:

CREATE PROCEDURE zapros8

AS

Select Поставщики.Наименование, ПоступлениеТоваров.Кол_во

From ПоступлениеТоваров,Поставки, Тип_доставки, Перечень_товаров, Поставщики

Where ПоступлениеТоваров.IDПоставки = Поставки.ID AND

Поставки.ID_Тип_доставки = Тип_доставки.ID_Тип_доставки AND

ПоступлениеТоваров.IDТовара = Перечень_товаров.ID_товара AND

Поставщики.ID = Поставки.ID_поставщика

ORDER BY ПоступлениеТоваров.Кол_во

END

8. Вывести список товаров, поставляемых сухопутным путем:

Select Перечень_товаров.Название_товара

From ПоступлениеТоваров,Поставки, Тип_доставки, Перечень_товаров

Where ПоступлениеТоваров.IDПоставки = Поставки.ID AND

Поставки.ID_Тип_доставки = Тип_доставки.ID_Тип_доставки AND

ПоступлениеТоваров.IDтовар = Перечень_товаров.ID_товара AND

Тип_доставки.Тип_доставки = ‘сухопутный’

END

9. Вывести список товаров у которых есть гарантия:

SELECT Перечень_товаров.Название_товара

FROM Перечень_товаров INNER JOIN

Поставки ON Перечень_товаров.ID_товара = Поставки.IDТовара INNER JOIN

ПоступлениеТоваров ON Поставки.ID = ПоступлениеТоваров.IDПоставки

WHERE ПоступлениеТоваров.Гарантия_по>GETDATE()

END

10. Вывести список товаров, у которых чаще всего встречается брак:

SELECT TOP(5) Перечень_товаров.Название_товара,Тип_товара.Тип_товара, COUNT(Возврат.IDПродажа) AS [Количество]

FROM Возврат INNER JOIN

Продажи ON Возврат.IDПродажа = Продажи.IDПродажи INNER JOIN

Перечень_товаров ON Продажи.IDТовара = Перечень_товаров.ID_товара INNER JOIN

Тип_товара ON Перечень_товаров.ID_тип_товара = Тип_товара.ID_тип_товара

GROUP BY Перечень_товаров.Название_товара, Тип_товара.Тип_товара

ORDER BY [Количество] DESC

END

5. ВЫБОР И ОБОСНОВАНИЕ СРЕДСТВ

РАЗРАБОТКИ ПРИЛОЖЕНИЯ

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

Для создания приложения используется IDE Visual Studio 2010, а я зыком написания приложения был выбран — C#. Данное сочетание позволяет реализовать самые смелые идеи, т.к. предоставляет мощные средства для написания приложений.

Для соединения с базой данных было принято использовать ADO.NET Entity Framework — объектно-ориентированную технологию доступа к данным, являющуюся object-relational mapping (ORM) решением для .NET Framework от Microsoft.

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

6. РЕАЛИЗАЦИЯ ЗАКОНЧЕННОГО ПРИЛОЖЕНИЯ,

РАБОТАЮЩЕГО С СОЗДАННОЙ БАЗОЙ ДАННЫХ

6.1 Разработка и построение интерфейса главной и рабочей форм

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

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

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

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

Скриншоты главной и некоторых диалоговых окон представлены в приложении C.

6.2 Построение главного меню и кнопок панели инструментов

Главное меню программы представлено двумя пунктами: База данных, Отчеты. Данные пункты выполнены в стандартного меню.

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

Элементы выбора представлены объектами ComboBox и CheckBox, DatePicker.

6.3 Выполнение программного кода в среде Microsoft Visual C#

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

• ZooShopEntities database = new ISDatabaseEntities(DatabaseClass.GetConnection()); // создание контекста модели, для последующей работы с базой данных и её сущностями

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

Все запросы по работе с базой данных обращаются к контексту и строятся с помощью LINQ to Entity [2].

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

• database.Животные.Where(s=>s.Типы_животных.Тип_животных1
• Equals(“Рыба”);
• Результат выполненного запроса представляет собой последовательность IQueryable<T>, которую можно назначить в качестве источника данных для таблиц, и прочих элементов управления.

Функционал по работе с отчетами реализован посредствам подключаемой библиотеки DocX, в которой представлены методы для создания OpenXML документов и работы с ними.

ЗАКЛЮЧЕНИЕ

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

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

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

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

В процессе выполнения данной курсовой работы были закреплены навыки в программировании на языке C#, проектировании баз данных и реализации их в СУБД MS SQL Server 2008.

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

[Электронный ресурс]//URL: https://liarte.ru/kursovaya/zoomagazin-baza-dannyih/

Шилдт Г. Полный справочник по SQL.: Пер. с англ. — М.: ООО “И.Д. Вильямс”, 2004. — 752 c.: ил.

Раттц Д. LINQ язык интегрированных запросов в C# 2008 для профессионалов. Пер. с англ. — М.: Вильямс, 2008. — 645с.: ил.

Хернандес М., Вьескас Д. SQL-запросы. Практическое руководство.: Пер. с англ. — М.: Лори, 2003. — 473 c.: ил.

Коннолли Т., Бегг К., Базы данных. Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ. — М.: Вильямс, 2003. — 1500 с.: ил.

Jennings R., Professional ADO.NET 3.5 with LINQ and the Entity Framework.: — New York.: Wrox, 2009. — 560 c.: ил.

ПРИЛОЖЕНИЕ A

(обязательное)

КОНЦЕПТУАЛЬНАЯ СХЕМА БД

Рисунок A.1 — Инфологическая схема проектируемой базы данных

Рисунок A.2 — ER-диаграмма проектируемой базы данных по методу Crow’s Foot

ПРИЛОЖЕНИЕ B

(обязательное)

СХЕМА РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

Рисунок B.1 — Схема реляционной базы данных

ПРИЛОЖЕНИЕ C

(обязательное)

ГЛАВНАЯ И РАБОЧИЕ ФОРМЫ ПРИЛОЖЕНИЯ

Рисунок C.1 — Главная форма приложения. Вкладка «Перечень товаров».

Рисунок C.2 — Диалоговое окно оформления продажи.

Рисунок C.3 — Главная форма приложения. Вкладка «Продажи»