Информационная система 'Складской учет мебельного магазина'

Информационная система 'Складской учет мебельного магазина'

Федеральное агентство по образованию Российской Федерации

Рязанский Государственный Радиотехнический Университет

Кафедра Вычислительной и прикладной математики

Курсовой проект

по дисциплине «Клиент-серверные приложения баз данных»

на тему: Информационная система «Складской учет мебельного магазина»

Выполнили: Ерхов Р.В., Кравченко Е.С.

Проверил: Благодаров А.В.

Рязань 2014

Содержание

Введение

. Анализ задачи

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

.2 Разработка общей архитектуры информационной системы

. Разработка серверной части информационной системы

.1 Разработка концептуальной модели данных

.1.1 Выявление сущностей, их атрибутов и ключей

.1.2 Выявление связей

.1.3 Построение CDM

.2 Разработка логической модели данных

.2.1 Заполнение сущностей атрибутами

.2.2 Проверка сущностей на соответствие нормальным формам

.2.3 Построение LDM

.3 Разработка физической модели данных

.3.1 Задание типов данных для полей таблиц

.3.2 Задание частных ограничений целостности данных

.3.3 Построение PDM

.3.4 Генерация SQL-скрипта для создания базы данных

Заключение

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

Приложение

Введение

Сложно представить современный город без крупной сети складов. Чаще всего таких складов гораздо больше одного. Тем самым образуя сеть складских комплексов. Наш проект и будет представлять собой одну из таких сетей.

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

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

·        СУБД: MS SQL Server 2005;

·        система программирования: Microsoft Visual C# 2005;

·        CASE средства проектирования баз данных: Sybase PowerDesigner 15.

1. Анализ задачи

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

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

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

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

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

1.2 Разработка общей архитектуры информационной системы

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

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

Рис. 1.1. Двухзвенная модель архитектуры клиент-сервер

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

2. Разработка серверной части информационной системы

.1 Разработка концептуальной модели данных

.1.1 Выявление сущностей, их атрибутов и ключей

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

) Клиент

Первичный ключ: Номер_клиента

) Заказ

Первичный ключ: Код_заказа

) Должности

Первичный ключ: Код_должности

) Сотрудники

Первичный ключ: Код_сотрудинка

) Отделы

Первичный ключ: Код_отдела

) Товар

Первичный ключ: Код_товара

) Тип товара

Первичный ключ: Артикул

)Возврат

Первичный ключ: Код_Возврата

)Поставщики

Первичный ключ: Код_Поставщики

)Склад

Первичный ключ: Номер_стеллажа

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

Рис. 2.1. Связь «Делает»

Один клиент может сделать несколько заказов. Каждый заказ может принадлежать только одному клиенту. Следовательно, имеет место связь 1..N. У каждого заказа должен быть заказчик. Одним клиентом может быть сделано несколько. Следовательно, для связи «Клиент → Заказ» будет использоваться кардинальность 0,n, а для связи «Заказ → Клиент» - 0..1.

Рис. 2.2. Связь «Содержит»

Много заказов могут содержать много товар. Много товаров может быть в разных заказах. Следовательно, имеет место связь N..N. Любой товар может быть в разных заказах. Следовательно, для связи «Заказ → Товар» будет использоваться кардинальность 0..N, а для связи «Товар → Заказ» - 0..N.

Рис. 2.3. Связь «Содержится на складе»

Для товара приписано только одно место хранения на складе. Место хранения обязательно есть у товара. Причем сущность Товар является главной. Следовательно, имеет место связь 1..1. Каждый товар имеет место на складе. Следовательно, для связи «Товар → Склад» будет использоваться кардинальность 0..1, а для связи «Склад → Товар» - 1..1.

Рис. 2.4. Связь «Поставляют на склад»

Много поставщиков поставляют товара на разные места хранения (склад). На разные места хранения (склад) могут поставлять разные поставщики. Следовательно, имеет место связь N..N. Следовательно, для связи «Поставщики → Склад» будет использоваться кардинальность 0..N, а для связи «Склад → Поставщики» - 0..N.

Рис. 2.5. Связь «Принадлежит»

Одному типу может принадлежать много товара. Каждый товар может принадлежать только одному типу. Следовательно, имеет место связь 1..N. Необязательно на каждой должности должен работать сотрудник. Следовательно, для связи «Тип товара→ Товар» будет использоваться кардинальность 0..N, а для связи «Товар → Тип товара» - 0..1.

Рис. 2.6. Связь «Оформляет»

Один сотрудник может оформлять несколько заказов. Каждый заказ может принадлежать только одному сотруднику. Следовательно, имеет место связь 0..N. Необязательно, что поставке будет тот или иной препарат. Но в поставке должен быть один определённый препарат. Следовательно, для связи «Сотрудники → Заказ» будет использоваться кардинальность 0..N, а для связи «Заказ → Сотрудники» - 0..1.

Рис. 2.7. Связь «Закрепляется за»

информационный архитектура атрибут серверный

Одна должность может принадлежать многим сотрудникам. Один сотрудник может находиться только на одной должности. Следовательно, имеет место связь 0..N. Следовательно, для связи «Должность → Сотрудники» будет использоваться кардинальность 0..N, а для связи «Сотрудники → Должность» - 0..1.

Рис. 2.8. Связь «Закрепляется за.»

Один отдел может принадлежать многим сотрудникам. Один сотрудник может находиться только в одном отделе. Следовательно, имеет место связь 0..N. Следовательно, для связи «Отдел → Сотрудники» будет использоваться кардинальность 0..N, а для связи «Сотрудники → Отдел» - 0..1.

Рис. 2.9. Связь «Определенных»

Один возвращенный товар может относиться ко многим заказам. Один заказ может относиться только к одному ввернутому товару. Следовательно, имеет место связь 0..N. Следовательно, для связи «Возврат → Заказ» будет использоваться кардинальность 0..N, а для связи «Заказ → Возврат» - 0..1.

Рис. 2.10. Связь «Возврат на склад»

На одно место хранения (склад) может приходить много возвращенного товара. Один ввернутый товар может находиться только на одном месте хранения (склад). Следовательно, имеет место связь 0..N. Следовательно, для связи «Склад → Возврат» будет использоваться кардинальность 0..N, а для связи «Возврат → Склад» - 0..1.

2.1.3 Построение CDM

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

Рис. 2.11. Концептуальная модель данных для предметной области «Складской учет мебельного магазина».

2.2 Разработка логической модели данных

.2.1 Заполнение сущностей атрибутами

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

.        Клиент:

)        Номер клиента,

)        Фамилия,

)        Имя,

)        Отчество,

)        Адрес,

)        Телефон;

.        Заказ:

)        Код заказа,

)        Клиент

)        Код товара,

)        Код сотрудника,

)        Возврат,

)        Дата заказа,

.        Товар:

)        Код товара,

)        Название,

)        Цена товара,

)        Страна производитель;

)        Артикул;

.        Склад:

)        Номер стеллажа,

)        Код товара;

)        Количество;

.        Возврат:

)        Код возврата,

)        Склад,

)        Код заказа,

)        Причина возврата;

.        Тип товара:

)        Артикул,

)        Наименование;

.        Поставщики:

)        Код поставщика,

)        Название,

)        Адрес,

)        Телефон;

.        Сотрудники:

)        Код сотрудника,

)        Код заказа,

)        Код отдела,

)        Фамилия,

)        Имя,

)        Отчество,

)        Адрес,

)        Телефон,

)        Дата найма,

)        Код должности;

.        Отдел:

)        Код отдела,

)        Название,

)        Кабинет,

)        Часы работы;

.        Должность:

)        Код должности,

)        Название,

)        Зарплата;

.        Содержит:

)        Товар,

)        Заказ,

)        Цена,

)        Количество,

2.2.2 Проверка сущностей на соответствие нормальным формам

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

На рисунке 2.12 показана диаграмма функциональных зависимостей для отношения «Клиент».

Рис. 2.12. Диаграмма функциональных зависимостей для отношения «Клиент»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.13 показана диаграмма функциональных зависимостей для отношения «Сотрудники».

Рис. 2.13. Диаграмма функциональных зависимостей для отношения «Сотрудники»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.14 показана диаграмма функциональных зависимостей для отношения «Должности».

Рис. 2.14. Диаграмма функциональных зависимостей для отношения «Должности»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.15 показана диаграмма функциональных зависимостей для отношения «Отделы».

Рис. 2.15. Диаграмма функциональных зависимостей для отношения «Отделы»

Отношение находится в 1НФ, 2НФ, 3НФ, БКНФ.

На рисунке 2.16 показана диаграмма функциональных зависимостей для отношения «Поставщики».

Рис. 2.16. Диаграмма функциональных зависимостей для отношения «Поставщики».

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.17 показана диаграмма функциональных зависимостей для отношения «Склад».

Рис. 2.17. Диаграмма функциональных зависимостей для отношения «Склад»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.18 показана диаграмма функциональных зависимостей для отношения «Возврат».

Рис. 2.18. Новая диаграмма функциональных зависимостей для отношения «Возврат»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.19 показана диаграмма функциональных зависимостей для отношения «Товар».

Рис. 2.19. Диаграмма функциональных зависимостей для отношения «Товар»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.21 показана диаграмма функциональных зависимостей для отношения «Тип товара».

Рис. 2.20. Диаграмма функциональных зависимостей для отношения «Тип товара»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.21 показана диаграмма функциональных зависимостей для отношения «Заказ».

Рис. 2.21. Диаграмма функциональных зависимостей для отношения «Заказ»

Отношение находится в 1НФ, 2НФ, 3НФ, НФБК.

На рисунке 2.22 показана диаграмма функциональных зависимостей для отношения «Содержит».

Рис. 2.22. Диаграмма функциональных зависимостей для отношения «Содержит»

2.2.3 Построение LDM

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

Рис. 2.23. Логическая модель данных для предметной области «Складской учет мебельного магазина»

2.3 Разработка физической модели данных

.3.1 Задание типов данных для полей таблиц

Для полей таблиц были заданы типы, указанные в таблице 1.

Таблица 1

.3.2 Задание частных ограничений целостности данных

Частные ограничения целостности задаются первичными и внешними ключами, разрешением каскадного обновления. Ограничения целостности для взаимоисключающего законченного наследования будут реализованы на уровне хранимых процедур и путем запрета обычным пользователям БД выполнения запросов INSERT, UPDATE и DELETE напрямую. Это позволит не реализовывать данные ограничения с помощью триггеров, замедляющих работу БД при большой активности пользователей.

2.3.3 Построение PDM

Физическая модель приведена на рисунке 2.24.

Рис. 2.24. Физическая модель данных для предметной области «Аптека»

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

SQL-скрипт создания таблиц базы и частных ограничений целостности создан автоматически с помощью Sybase Power Designer. Код полученного скрипта, представлен в Приложении 1.

Заключение

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

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

1.      Вьейра Р. SQL Server 2000. Программирование ч.1 [Текст] / Р. Вьера. - М.: Изд-во "БИНОМ. Лаборатория знаний", 2004. - 736 с.

.        Вьейра Р. SQL Server 2000. Программирование ч.2 [Текст] / Р. Вьера. - М.: Изд-во "БИНОМ. Лаборатория знаний", 2004. - 808 с.

.        Троелсен Э. C# и платформа .NET 3.0. Специальное издание [Текст] / Э. Троелсен - СПб.: Питер, 2008. - 1456 с.

.        Библиотека MSDN для Microsoft Visual Studio [Электронный ресурс]. - Электрон. текст. дан. - Microsoft, 2012 - Режим доступа: http://msdn.microsoft.com/en-us/vstudio/aa718325, свободный.

Приложение

скрипт для создания БД

/* DBMS name: Microsoft SQL Server 2000 */

/* Created on: 03.12.2014 20:57:23 */

/* Table: Client */table Client (

Number int not null,

Lastname varchar(100) not null,

Name varchar(50) not null,

MiddleName varchar(50) not null,

Addres varchar(100) not null,

Phone int not null

)table Client

add constraint PK_CLIENT primary key nonclustered (Number)

/* Table: Divisions */table Divisions (

"Division name" varchar(100) not null,

Room int not null,

"Operating hours" datetime not null

)table Divisions

add constraint PK_DIVISIONS primary key nonclustered ("Division ID")

/* Table: Employees */table Employees (

"Employee ID" int not null,

"Order ID" int not null,

"Division ID" int not null,

Lastname varchar(100) not null,

Name varchar(50) not null,

MiddleName varchar(50) not null,

Addres varchar(100) not null,

Phone int not null,

"Employment date" datetime not null,

"Post ID" int not null

)table Employees

add constraint PK_EMPLOYEES primary key nonclustered ("Employee ID")

/* Table: Goods */table Goods (

"Goods ID" int not null,

"Goods name" varchar(100) not null,

Price varchar(200) not null,

"Producing country" varchar(50) not null,

"Article number" varchar(100) not null

)table Goods

add constraint PK_GOODS primary key nonclustered ("Goods ID")

/* Table: "Goods type" */table "Goods type" (

"Article number" varchar(100) not null,

Name varchar(100) not null

)table "Goods type"

add constraint "PK_GOODS TYPE" primary key nonclustered ("Article number")

/* Table: "Order" */table "Order" (

"Order ID" int not null,

Client int null,

"Goods ID" int not null,

"Client ID" int not null,

"Employee ID" int not null,

"Return" int null,

"Order date" datetime not null

)table "Order"

add constraint PK_ORDER primary key nonclustered ("Order ID")

/* Table: Posts */table Posts (

"Post ID" int not null,

"Post name" varchar(100) not null,

Salary varchar(200) not null

)table Posts

add constraint PK_POSTS primary key nonclustered ("Post ID")

/* Table: "Return" */table "Return" (

"Return ID" int not null,

Warehouse int null,

"Order ID" int not null,

"Return reason" varchar(100) not null

)table "Return"

add constraint PK_RETURN primary key nonclustered ("Return ID")

/* Table: Suppliers */table Suppliers (

"Supplier ID" int not null,

Warehouse int null,

Name varchar(100) not null,

Addres varchar(100) not null,

Phone int not null

)table Suppliers

add constraint PK_SUPPLIERS primary key nonclustered ("Supplier ID")

/* Table: Warehouse */table Warehouse (

"Shelving number" int not null,

"Goods ID" int not null,

Quantity int not null

)table Warehouse

add constraint PK_WAREHOUSE primary key nonclustered ("Shelving number")

/* Table: содержит */table содержит (

Goods int not null,

Quantity int not null,

Price varchar(200) not null

)table содержит

add constraint PK_СОДЕРЖИТ primary key nonclustered (Goods, "Order")table Employees

add constraint FK_EMPLOYEE_ЗАКРЕПЛЯЕ_POSTS foreign key ("Post ID")

references Posts ("Post ID")

on update cascadetable Employees

add constraint FK_EMPLOYEE_ЗАКРЕПЛЯЮ_DIVISION foreign key ("Division ID")

references Divisions ("Division ID")

on update cascadetable Goods

add constraint "FK_GOODS_ПРИНАДЛЕЖ_GOODS TY" foreign key ("Article number")

references "Goods type" ("Article number")

on update cascadetable "Order"

add constraint FK_ORDER_ДЕЛАЕТ_CLIENT foreign key (Client)

references Client (Number)

on update cascadetable "Order"

add constraint FK_ORDER_ОПРЕДЕЛЕН_RETURN foreign key ("Return")

references "Return" ("Return ID")

on update cascadetable "Order"

add constraint FK_ORDER_ОФОРМЛЕТ_EMPLOYEE foreign key ("Employee ID")

references Employees ("Employee ID")

on update cascadetable "Return"

add constraint "FK_RETURN_ВОЗВРАТ Н_WAREHOUS" foreign key (Warehouse)

references Warehouse ("Shelving number")

on update cascadetable Suppliers

add constraint FK_SUPPLIER_ПОСТАВЛЯЮ_WAREHOUS foreign key (Warehouse)

references Warehouse ("Shelving number")

on update cascadetable Warehouse

add constraint FK_WAREHOUS_СОДЕРЖИТС_GOODS foreign key ("Goods ID")

references Goods ("Goods ID")

on update cascadetable содержит

add constraint FK_СОДЕРЖИТ_СОДЕРЖИТ_GOODS foreign key (Goods)

references Goods ("Goods ID")

on update cascadetable содержит

add constraint FK_СОДЕРЖИТ_СОДЕРЖИТ_ORDER foreign key ("Order")

references "Order" ("Order ID")

on update cascade