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

Министерство образования и науки Российской Федерации

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

Северокавказский государственный технический университет

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

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

по дисциплине «Программирование в компьютерных сетях»

Специальность 071900 (230201) «Информационные системы и технологии»

Студент Артемов В.В.

Руководитель Крахоткина Е.В.

Ставрополь 2011

Оглавление

Введение

• 1. Описание предметной области
• 2. Проектирование реляционной базы данных
• 2.1 Перечень атрибутов
• 3. Инфологическая модель базы данных
• 3.1 Описание связей
• 4. Даталогическое проектирование БД
• 5. Запросы к БД
• 6. Разработка представлений для отображения результатов выборки
• 7. Проектирование хранимых процедур
• 8. Проектирование триггеров
• 9. Проектирование клиентского приложения
• 9.1 Функциональное назначение
• 9.2 Описание входных и выходных форм
• 9.3 Разработка технологий доступа к базе данных
• 9.4 Руководство пользователя
• 10. Экономическое обоснование результатов внедрения программного продукта
• 11. Требования к техническому обеспечению
• Заключение
• Приложения

проектирование реляционный триггер программный

Введение

Реляционная СУБД (Система Управления Базами Данных) -- СУБД, управляющая реляционными базами данных. Понятие реляционный (англ. relation -- отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда.

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

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

· каждый элемент таблицы -- один элемент данных

· все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

· каждый столбец имеет уникальное имя

· одинаковые строки в таблице отсутствуют

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

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

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

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

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

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

информация о бригадах;

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

информация о заказах;

информация о клиентах.

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

2. Проектирование реляционной базы данных

В данном проекте «Грузоперевозки» главной таблицей является «Заказ». Если таблицу не разбивать на подтаблицы, то можно наблюдать избыточность данных, а это не допустимо. Чтобы это избежать добавляем следующие таблицы:

· «Бригада» - содержит информацию о бригадах;

· «Товар» - содержит информацию о товарах;

· «Склад» - содержит информацию о складах;

· «Клиент» - содержит информацию о клиентах.

2.1 Перечень атрибутов

Таблица «Клиент» содержит:

· id_клиента - уникальный идентификатор клиента

· ФИО - ФИО клиента

· Информация - информация о клиенте

· Адрес - адрес клиента

Таблица «Товар» содержит:

· id - уникальный номер товара

· Наименование - наименование поставляемого товара

· Склад - уникальный номер склада

· Информация - информация о товаре

Таблица «Склад» включает в себя:

· id - уникальный номер склада

· Наименование - наименование склада

· Адрес - адрес склада

· Информация - информация о складе

В таблице «Бригада» следующие столбцы:

· id - порядковый номер бригады

· Наименование - наименование бригады

· Информация - информация о бригаде

Таблица «Заказ» включает в себя:

· id - уникальный номер заказа

· Название - название заказа

· Дата - дата заказа

· Товар - уникальный номер товара

· Клиент - уникальный номер клиента

· Информация - информация о заказе

· Цена - цена доставки

3. Инфологическая модель базы данных

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.

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

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

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

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

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

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

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

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

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

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

3.1 Описание связей

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

Таблица «Клиент»	Таблица «Заказ»
id	Клиент
Тип отношений:	Один ко многим
Таблица «Склад»	Таблица «Заказ»
id	Склад
Тип отношений:	Один ко многим

Инфологическая модель данных представлена в Приложении 1, рис. 2.

4. Даталогическое проектирование БД

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

4.1 Состав таблиц БД

Таблица 4.1.1 Клиент

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
id	Int	11	Not Null
ФИО	Char	20
Информация	Char	512
Адрес	Char	96

Таблица 4.1.2 Товар

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
id	Int	11	Not Null
Наименование	Char	20
Склад	Int	11
Информация	Char	512

Таблица 4.1.3 Склад

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Id	Int	11	Not Null
Наименование	Char	50
Информация	Char	512
Адрес	Char	80

Таблица 4.1.4 Бригада

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Id	Int	11	Not Null
Наименование	Char	50
Информация	Char	512

Таблица 4.1.5 Заказ

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Id	Int	11	Not Null
Наименование	Char	50
Дата	Datetime	19
Товар	Int	11
Клиент	Int	11
Информация	Char	512
Цена	float	20

5. Запросы к БД

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

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

Запросы на SQL

1. Простой запрос с сортировкой

Select наименование, склад, товар, клиент, цена from заказ order by Цена

2. Выборка по дате

select * from Заказ where Заказ.[Дата]<'10.06.2011'

3. Выборка значений из определенного диапазона

SELECT * FROM заказ WHERE [цена] BETWEEN '10000' AND '30000'

4. Выборка данных по шаблону

select наименование, склад, товар, клиент, цена FROM заказ where Наименование like 'П%'

5. Выборка вычисляемого значения

SELECT наименование, склад, товар, клиент, цена+ цена*0.18 AS [Цена с НДС] From заказ

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

Представление - это динамическая таблица, служащая для отображения результатов выборки из информации. Представления являются удобным инструментом для работы с таблицами базы данных. Разработка представлений в SQL Server 2005 осуществляется в два этапа. На первом этапе оно создается при помощи утилиты SQL Server Enterprise Manager, а затем ее запуск осуществляется при помощи утилиты SQL Server Query Analyzer.

В базе данных разработано представление «Представление», в котором отображается: № заказа, название заказа, дата, товар, клиент, информация, Цена с НДС.

Рис. 6.1 Представление

7. Проектирование хранимых процедур

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

В курсовом проекте была разработана хранимая процедура, предназначенная для изменения поля «Цена» в таблице «Заказ» с учетом увеличения стоимости товара на 35%. Код процедуры:

CREATE PROCEDURE new as

UPDATE Заказ

set [Цена]=[Цена]*0.35

Для запуска процедуры используется команда:

exec new

SELECT*FROM Заказ

Рис. 7.1 Выполнение хранимой процедуры

8. Проектирование триггеров

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

В данном курсовом проекте для таблицы «Заказ» был разработан триггер - trigger_1. Действие этого триггера направлено на то чтобы пользователь не мог вводить отрицательные значения в поле «Цена». Код триггера:

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

GO

ALTER TRIGGER [dbo].[trigger_1]

ON [dbo].[Заказ]

AFTER INSERT,UPDATE

AS

BEGIN

IF EXISTS (SELECT * FROM dbo.Заказ WHERE [Цена]<0)

ROLLBACK TRAN

PRINT 'Цена не может быть меньше 0'

SET NOCOUNT ON;

END



Рис. 8.1 - Результат работы триггера

9. Проектирование клиентского приложения

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

Пользователи могут работать с БД, используя клиентское приложение. Приложение разработано в Microsoft Visual C# 2008.

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

Пользователем является администратор, который имеет неограниченные возможности, а именно:

· Добавление записей;

· Удаление записей;

· Просмотр записей;

· Сохранение записей;

· Сортировку записей;

· Редактирование записей.

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

9.2 Описание входных и выходных форм

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

Рис. 9.2.1 Окно авторизации пользователя.

Рис. 9.2.2. Сообщение о вводе неверного пароля при авторизации пользователя

Рис. 9. 2.3 Главное окно приложения.

9.3 Разработка технологий доступа к базе данных

Пользователем данного клиентского приложения является только администратор базы данных. Для того чтобы использовать все возможности разработанной программы требуется в окне авторизации (рисунок 9.2.1) при запуске программы ввести пароль - 123456. Если будет введен не правильный пароль, появится сообщение об ошибке (рисунок 9.2.2).

9.4 Руководство пользователя

Для запуска программного продукта нужно скопировать папку «Груз» на жесткий диск, после чего открыть файл Груз.exe

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

При запуске программы пользователь имеет возможность воспользоваться главным меню приложения. Завершение работы с приложением идентично другим Windows-приложениям - нажатием на красный крестик в правом верхнем углу.

10. Экономическое обоснование результатов внедрения программного продукта

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

Экономический эффект от использования программного продукта за период внедрения (T) можно рассчитать по формуле:

, (10.1)

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

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

, (10.2)

где Т - период внедрения;

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

- дисконтирующая функция, которая вводится с целью приведения всех затрат и результатов к одному моменту времени:

. (10.3)

В формуле (10.3) р - коэффициент дисконтирования, , - нормативный коэффициент капитальных вложений. Стоимостная оценка результатов t - расчетного периода =200 руб.

Затраты на разработку =300руб.

Таким образом в результате вычислений =529,24 руб., 229,24 руб.

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

. (10.4)

Здесь - затраты на ручную обработку информации, руб,

,

- объем информации, обрабатываемой вручную, Мбайт, Ц - стоимость одного часа работы, руб/час, - коэффициент, учитывающий дополнительные затраты времени на логические операции при ручной обработке информации, - норма выработки, Мбайт/час. З_а - затраты на автоматизированную обработку информации, руб, - время автоматической обработки (час), - стоимость одного часа машинного времени, руб/час; - время работы оператора, час; - стоимость одного часа работы оператора, руб./час.

В результате вычислений получили следующие результаты:

Затраты на автоматизированную обработку информации, З_а = 200 руб.

Затраты на ручную обработку информации, З_р = 735 руб.

Экономия средств от внедрения продукта, Э_у= 535 руб.

Экономический эффект от внедрения разработки в течение года использования можно определить по формуле:

, (10.5)

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

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

Тогда эффективность разработки может быть определена по формуле:

. (10.6)

Для разработанного проекта Эр = 0,72, использование на предприятии разработанного программного продукта считается экономически целесообразным, если значение . Вывод: база данных «Грузоперевозки» является экономически выгодным программным продуктом для внедрения в определенную сферу деятельности.

11. Требования к техническому обеспечению

Windows-приложение «Грузоперевозки» запускается на любом современном ПК, так как не требовательна к ресурсам, поэтому указание минимальных характеристик просто не имеет смысла.

Заключение

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

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

В данном проекте была создана реляционная база данных «Грузоперевозки», разработанная с помощью СУБД MS Microsoft SQL Server 2005.

Список информационных источников

1. Nilsen P. SQL Server 2005. Библия пользователя/Диалектика 2008. - 1228 с.

2. Дроздова В.И., Крахоткина Е.В., Федоров С.О. Базы данных. Методические указания к лабораторным работам для студентов специальности 351400. Ставрополь, СевКавГТИ, 2002.

3. Дроздова В. И., Крахоткина Е.В. Методические указания к выполнению курсового проекта по дисциплине «Базы данных» для студентов специальности 351400. Ставрополь, СевКавГТУ, 2004.

4. ru.wikipedia.org/wiki/Реляционная_СУБД

5. http://citforum.ru/database/dbguide/2-1.shtml - инфологическая модель данных

6. Каратыгин С.А., Тихонов А.Ф., Тихонова Л.Н. Visual FoxPro 6.0 // М.: Бином, 1999 - 784 с.

7. Ханcен Г., Ханcен Д. Базы данных. Разработка и управление / М.: Бином, 1999 - 704 с.

8. Баженова И.Ю. Visual Fox Pro 5.0//М.: Диалог МИФИ, 1997 - 320 с.

9. Глушаков С.В., Ломотько Д.В. Базы данных. Учебный курс // Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2000. - 504 с.

Приложения

Приложение 1

Рис. 1 - Даталогическая модель данных

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

Рис.2 - Инфологическая модель данных

Приложение 2

Запросы приложения «Грузоперевозки»

Рис.1 - Простой запрос с сортировкой

Рис.2 - Выборка по дате



Рис.3 - Выборка значений из определенного диапазона

Рис.4 - Выборка данных по шаблону



Рис.5 - Выборка вычисляемого значения

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