Информационная система "Автомагазин"

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

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ СТРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ»

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

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

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

по дисциплине «Проектирование информационных систем в экономике»

на тему: Информационная система «Автомагазин»

Студент

Фащенко С.А.

Ростов-на-Дону, 2014

Содержание

Введение

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

1.1 Описание бизнес-процессов

1.2 Регламент бизнес процессов

1.3 Описание входных документов

1.4 Описание выходных документов

1.5 Информационные потребности пользователей

1.6 Запросы

1.7 Отчёты

1.8 Описание состава показателей обоснования технико-экономической эффективности выбранной технологии проектирования и методики их расчета

2. Функциональная модель данных

2.1 Функциональная модель IDEF0

3. Диаграмма потоков данных

3.1 Контекстная диаграмма

4. Концептуальная модель данных ИС

4.1 Документирование сущностей

4.2 Документирование связей

4.3 Документирование атрибутов

4.4 Диаграмма «Сущность-связь»

5. Логическая модель данных

5.1 Преобразование концептуальной модели данных в локальную логическую модель данных

5.2 Проверка модели с помощью правил нормализации

5.3 Определение требований поддержки целостности данных

5.4 Диаграмма «Сущность-связь»

6. Выбор и описание используемой СУБД

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

7.1 Физическая модель базы данных

7.2 Описание технологии доступа к базам данных

7.3 Структуры диалога и программного обеспечения

7.4 Блок-схема алгоритма обработки данных

7.5 Описание запросов и отчетов к базе данных

8. Описание средств защиты

9. Руководство пользователя ИС

10. Руководство программиста, администратора БД

Заключение

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

Приложения

Введение

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

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

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

Данное приложение позволит:

- хранить информацию в удобном виде;

- совместно использовать базы данных несколькими пользователями;

- просмотр отчеты по основным показателям системы (статистика продаж)

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

автоматизация автозапчасть программный microsoft

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

1.1 Описание бизнес-процессов

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

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

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

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

Система обеспечивает следующие возможности:

· продажа автозапчастей;

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

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

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

2. Возможность редактирования информации о марке, коду и др.

3. Возможность удаления запчасти.

4. Возможность добавления информации о клиенте

5. Возможность редактирования информации о клиенте.

6. Удаление информации о клиенте.

7. Также необходимо предусмотреть поиск, как по клиентам, так и по запчастям.

1.2 Регламент бизнес процессов

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

Бизнес-правила:

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

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

- данные по заказам хранятся в БД 3 года, а затем передаются в электронный архив;

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

- нельзя осуществлять продажу за прошедшие дни.

1.3 Описание входных документов

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

Эти сведения можно разделить на типы:

· сведения о заказе;

· сведения о покупателях;

· сведения о запчасти;

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

Сведения о покупателях включают: ФИО покупателя, телефон.

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

1.4 Описание выходных документов

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

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

1.5 Информационные потребности пользователей

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

1.6 Запросы

Перечень возможных запросов к базе данных:

- Выдать информацию о всех работниках;

- Выдать информацию о запчастях;

- Выдать информацию о клиентах;

- Выдать информацию о наличии запчастей;

- Редактирование полученной информации;

- Добавление информации;

1.7 Отчёты

Перечень возможных отчетов:

- Выдать список всех запчастей;

- Выдать список всех работников;

- Выдать список всех клиентов;

- Выдать список всех марок.

2. Функциональная модель данных

2.1 Функциональная модель IDEF0

На диаграмме IDEF0 отображены следующие функции:

1. Функция «Добавление и редактирование записи по клиентам» в качестве входного параметра имеет заполнение формы «Клиенты», выходным параметром являются данные в таблице «Client».

2. Функция «Добавление и редактирование записи по запчастям» в качестве входного параметра имеет заполнение формы «Запчасти», выходным параметром являются данные в таблице «Zapchast'».

3. Функция «Добавление и редактирование записи по сотрудникам» в качестве входного параметра имеет заполнение формы «Сотрудники», выходным параметром являются данные в таблице «User».

4. Функция «Составление отчёта по продажам» в качестве входных параметров имеет таблицы «Zapchast'», «Prodaga», выходным параметром является отчёт по продажам.

Диаграмма IDEF0 приведена в приложении 1.

3. Диаграмма потоков данных

3.1 Контекстная диаграмма

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

«Поиск клиентов» - эта функция предоставляет информацию о клиентах.

«Поиск сотрудников» - эта функция предоставляет информацию о сотрудниках.

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

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

DFD-диаграмма приведена в приложении 2.

4. Концептуальная модель данных ИС

4.1 Документирование сущностей

Подходя к вопросу документирования сущностей, перечислим выявленные сущности словарь данных БД «автосалон» (табл. 1).

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

Имя сущности	Описание	Псевдоним	Описание использования
Сотрудники	Предоставляет полный перечень всех сотрудников и основную информацию о них	-	Позволяет начальству найти необходимую информацию о сотрудниках
Запчасти	Предоставляет полный перечень автозапчастей	-	Позволяет сотрудникам найти необходимую информацию об автозапчастях
Клиенты	Предоставляет полный перечень клиентов и основную информацию о них	-	Позволяет сотрудникам найти необходимую информацию о клиентах
Склад	На складе находятся все имеющиеся в наличае запчасти	-	Позволяет сотрудникам проверить наличие необходимой запчасти на складе
Продажа	Предоставляет список выбранных запчастей, ФИО клиента, дату, сумму проданных запчастей	-	Позволяет оформлять заказ на запчасти, выбранные покупателем

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

4.2 Документирование связей

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

Таблица 2. Определение типов связей

Сущность	Тип связи	Сущность	Кардинальность	Модальность
Сотрудники	Сотрудник обслуживает клиента	Клиент	1:М	Д:М
Запчасть	Сотрудник предлагает запчасть	Сотрудник	М:1	М:Д
Клиент	Клиент выбирает запчасть	Запчасть	1:М	М:Д
Запчасть	Запчасть находится на складе	Склад	М:1	М:Д
Продажа	Клиент покупает запчасть	Клиент	М:1	М:Д

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

4.3 Документирование атрибутов, доменов атрибутов и ключей

Рассмотрим документирование атрибутов, доменов атрибутов и ключей (табл. 3).

Таблица 3. Определение атрибутов и связывание их с сущностями

Имя сущности	Атрибут	Описание атрибута	Тип данных и длина	Ограничение	Значение по умолчанию	Допустимость
Сотрудники	Id	Код каждого сотрудника	int	Первичный ключ	-	NOT NULL
Сотрудники	ФИО	ФИО каждого сотрудника	Varchar (50)	-	-	NOT NULL
Сотрудники	Роль	Должность сотрудника	Varchar (30)	-	-	NOT NULL
Продажа	Id	Код каждой продажи	int	Первичный ключ	-	NOT NULL
Продажа	Id сотр	Код каждого сотрудника	int	Потенциальный ключ	-	NOT NULL
Продажа	Id клиента	Код каждого клиента	int	Потенциальный ключ	-	NOT NULL
Продажа	Id запчасти	Код каждой запчасти	int	Потенциальный ключ	-	NOT NULL
Продажа	Сумма	Расчет суммы покупки	money	-	-	NOT NULL
Продажа	Дата	Дата оформления продажи	date	-	-	NOT NULL
Продажа	Статус	Совершена ли продажа	date	-	-	NOT NULL
Склад	Id	Склад автозапчастей	int	Первичный ключ	-	NOT NULL
Склад	Название	Название склада	Varchar (30)	-	-	NOT NULL
Клиенты	Id клиента	Код каждого клиента магазина	int	Первичный ключ	-	NOT NULL
Клиенты	ФИО	ФИО клиента	Varchar (50)	-	-	NOT NULL
Запчасть	Id	Код запчасти	int	Потенциальный ключ	-	NOT NULL
Запчасть	Марка	Марка запчасти	Varchar (30)	-	-	NOT NULL
Запчасть	Код	Код запчасти	Varchar (30)	-	-	NOT NULL

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

4.4 Диаграмма «Сущность-связь»

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

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

Рисунок 1. Диаграмма «Сущность-связь»

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

5. Логическая модель данных

5.1 Преобразование концептуальной модели данных в локальную логическую модель данных

Исходными данными для диаграмм логической модели служат диаграммы концептуальной модели ИС.

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

· связи типа «многие ко многим»;

· рекурсивные связи;

· связи с атрибутами.

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

5.2 Проверка модели с помощью правил нормализации

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

Ниже приводятся краткие сведения из теории нормализации.

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

Функциональная зависимость определяется следующим образом. Пусть A и B - произвольные наборы атрибутов отношения. Тогда B функционально зависит от A (A > B), в том и только в том случае, если каждому значению A соответствует в точности одно значение B. Левая часть функциональной зависимости (A) называется детерминантом, а правая (B) - зависимой частью. В частности, в отношении А может быть первичным ключом, а B - набором неключевых атрибутов, так как одному значению первичного ключа в точности соответствует одно значение набора неключевых атрибутов.

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

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

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

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

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

Транзитивная зависимость. Если для атрибутов А, В и С некоторого отношения существуют зависимости вида А > В и В > С, то атрибут С транзитивно зависит от атрибута А через атрибут В.

Нормальная форма Бойса-Кодда. Отношение находится в BCNF, если оно находится в 3NF и каждый детерминант отношения является его возможным ключом.

4NF. Отношение находится в 4NF в том и только в том случае, если в нем отсутствуют нетривиальные многозначные зависимости.

Нетривиальная многозначная зависимость. В отношении с атрибутами А, В и С существует нетривиальная многозначная зависимость, если для каждого значения атрибута А имеется набор значений атрибута В (A ?>> B) и набор значений атрибута С (A ?>> С), но между атрибутами В и С нет зависимостей.

5NF (нормальная форма проекции соединения, PJNF). Отношение находится в 5NF, если в нем нет зависимостей соединения.

Зависимость соединения. В отношении с атрибутами А, В и С существует зависимость соединения, если для каждого значения атрибута А имеется набор значений атрибута В (A ?>> B) и набор значений атрибута С (A ?>> С), а также существует многозначная зависимость между атрибутами В и С (В ?>> С или С ?>> B).

5.3 Определение требований поддержки целостности данных

Главная особенность SQL-технологий наличие у сервера СУБД специальных средств контроля целостности данных, не зависящих от клиентских программ и привязанных непосредственно к таблицам. За контролем целостности данных следит сервер, и при нарушении правил целостности данных сервер известит клиента об ошибке.

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

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

SQL-серверы, как правило, поддерживают следующие ограничители.

NOT NULL - проверка на непустое значение. NULL - специальное понятие в СУБД, которое означает "пусто". "Пусто" и "0(ноль)" не равны друг другу!

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

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

SQL-технология позволяет на уровне столбца задавать домены значений, т.е. строго определенные наборы или диапазоны значений, для помещаемых в столбец данных. В частности можно реализовывать ограничения ссылочной целостности (referential integrity constraint) и проверки фиксированного условия. Ограничение ссылочной целостности не позволяет значениям из столбца одной таблицы принимать значения кроме как из присутствующих в столбце другой таблицы. Это делается при помощи ограничителей FOREIGN KEY (внешний ключ) и REFERENCES (указатель ссылки). Таблица, содержащая FOREIGN KEY, считается родительской таблицей. Таблица, содержащая REFERENCES, считается дочерней таблицей. Внешний ключ и указатель ссылки могут находиться в одной таблице, т.е. родительская таблица одновременно является дочерней.

FOREIGN KEY - внешний ключ. Назначает столбец или комбинацию столбцов в текущей (родительской) таблице в качестве внешнего ключа для ссылки из других таблиц.

REFERENCES - указатель ссылки (или родительский ключ). Указывает на столбец (комбинацию столбцов) в родительской таблице, ограничивающую значения в текущей (дочерней) таблице.

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

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

5.4 Диаграмма «Сущность-связь»

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

6. Выбор и описание используемой СУБД

Microsoft SQL Server R2-- система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов -- Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка. Эта разработка корпорации Microsoft, является популярной среди малых и средних предприятий. Используется во многих крупных компаниях.

Microsoft SQL Server 2008 R2 представляет новое поколение масштабируемых решений в области систем управления базами и хранилищ данных для задач, требующих быстрого получения и анализа информации. Он нацелен на решение широкого круга задач во всех областях бизнеса, в том числе и в электронной коммерции.

Преимущества Microsoft SQL Server 2008 R2:

· Масштабируемость и надежность. SQL Server 2008 R2 обеспечивает практически неограниченный рост объемов хранения данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. Это безопасная, надежная, масштабируемая платформа, защищающая информацию в приложениях и повышающая её доступность.

· Скорость создания решений. SQL Server 2008 R2 в сочетании с.NET Framework уменьшает время разработки, внедрения и выхода на рынок современных приложений, ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях, предоставляет широкие возможности для создания Web-приложений. Среда ADO.NET Entity Framework повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. устройства, а позже синхронизовать их с центральными серверами.

Ядро реляционной базы данных SQL Server 2008 R2 включает следующие возможности для создания и поддержки различных приложений с хранилищами данных:

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

· Выполнение онлайновых операций над индексами.

· Гранулированные операции резервного копирования/восстановления.

· Быстрая инициализация файлов.

Платформа данных SQL Server R2 включает следующие инструменты:

· Реляционная база данных: безопасное, надёжное, масштабируемое ядро с улучшенной производительностью и поддержкой структурированных и неструктурированных (XML) данных.

· Reporting Services: исчерпывающее решение для создания, управления и доставки как традиционных бумажных отчётов, так и интерактивных, основанных на технологии WWW отчётов.

· Инструменты разработки: SQL Server R2 предлагает интегрированные инструменты разработки для ядра базы данных, извлечения, трансформации и загрузки данных, извлечения информации, OLAP и отчётности.

· И многие другие инструменты.

Основные возможности Microsoft SQL Server 2008 R2:

· Интеграция в существующие системы без программирования, используя встроенную поддержку W3C стандартов, включая XML, Xpath, XSL и HTTP. Позволяет просмотр и доступ к реляционным данным, используя технику простого сопоставления XML элементов и атрибутов реляционной схемы.

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

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

* Удобство разработки приложений. Интеграция с Microsoft Visual Studio и NET Framework дает возможность создавать хранимые процедуры на языках, отличных от T-SQL.

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

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

7.1 Физическая модель базы данных

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

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

Рисунок 2. Физическая модель базы данных «Автомагазин»

К вопросам организации данных относятся:

· выбор типа записи - единицы обмена в операциях ввода-вывода;

· выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

выбор способа адресации и метода доступа к записям.

Стадия физического проектирования БД в общем случае включает:

· выбор способа организации БД;

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

· описание отображения концептуальной схемы во внутреннюю.

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

7.2 Описание технологии доступа к базе данных

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

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

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

Основной принцип технологии клиент-сервер - разделение функций стандартного интерактивного приложения на четыре группы:

Функции ввода и отображения данных (интерфейс).

Прикладные функции.

Функции хранения данных и управления информационными ресурсами.

Служебные функции.

7.3 Структуры диалога и программного обеспечения

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

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

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

7.4 Блок-схема алгоритма обработки данных

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

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

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

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

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

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

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

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

7.5 Описание запросов и отчетов к базе данных

1) Самая дорогая продажа

CREATE PROCEDURE [dbo].[BestDeal]

- Add the parameters for the stored procedure here

- @name varchar(50),

- @dolgnost varchar(50)

AS

BEGIN

SELECT MAX(cena)

FROM Zapchast'.dbo.Prodaga

END

2) Все продажи

CREATE PROCEDURE [dbo].[DealList]

- Add the parameters for the stored procedure here

- @name varchar(50),

--@dolgnost varchar(50)

AS

BEGIN

SELECT id_rabotnik,id_pokupatel,id_zapchast',data

FROM Prodagi

END

3) Список всех работников

CREATE PROCEDURE [dbo].[RabotnikList]

-- Add the parameters for the stored procedure here

@name varchar(50),

@dolgnost varchar(50),

@phone int

AS

BEGIN

select name,dolgnost,phone

from Zapchast'.dbo.Rabotnik

END

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

namespace avtozapchasti

public partial class ФормаОтчетПоПродажам : Form

{

public ФормаОтчетПоПродажам()

InitializeComponent();

}

private void ФормаОтчетПоПродажам_Load(object sender, EventArgs e)

{

this.ПродажаTableAdapter.Fill(this.АвтозапчастиDataSet.Продажа);

this.reportViewer1.RefreshReport();

}

8. Описание средств защиты

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

Форма авторизации

Рисунок 3

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

Код данной формы

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace avto

{

public partial class Authorization : Form

{

public Authorization()

{

InitializeComponent();

}

My_func f;

private void Authorization_Load(object sender, EventArgs e)

{

f = new My_func();

}

private void button1_Click(object sender, EventArgs e)

{

DataTable dt_auth = f.Load_Passwords();

bool is_ok = false;

int id_reader=0;

if (te_login.Text=="admin" && te_passw.Text=="123")

{

Adminka a = new Adminka();

a.ShowDialog();

return;

}

for (int i = 0; i < dt_auth.Rows.Count; i++)

if (te_login.Text==dt_auth.Rows[i]["login"].ToString())

if (te_passw.Text == dt_auth.Rows[i]["password"].ToString())

is_ok = true;

id_reader = int.Parse(dt_auth.Rows[i]["id_reader"].ToString());

break;

}

else

{

MessageBox.Show("Не верный пароль!!");

te_passw.Text = "";

if (!is_ok)

{

MessageBox.Show("Такого пользователя не существует!!!!!!!");

te_login.Text = "";

te_passw.Text = "";

else

Form1 fo = new Form1(id_reader);

fo.ShowDialog();

}

private void label5_Click(object sender, EventArgs e)

{

Registrationcs r = new Registrationcs();

r.ShowDialog();

}

9. Руководство пользователя ИС

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

1. запускаем программу

2. вводим имя пользователя и пароль

3. нажимаем кнопку «Вход»

4. Слева на форме перечислены существующие формы БД, выберите и зайдите на необходимую вам форму для просмотра, получения или изменения информации.

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

10. Руководство программиста, администратора БД

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

Администраторы базы данных выполняют большой круг разнообразных функций:

1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса информации, определение потребностей пользователей, определение статуса пользователей, определение соответствия «данные - пользователь», определение объемно-временных характеристик обработки данных.

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

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

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

5. Защита данных от несанкционированного доступа:

· обеспечение парольного входа в систему: регистрация пользователей, назначение и изменение паролей;

· обеспечение защиты конкретных данных;

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

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

7. Обеспечение восстановления БД: разработка программно-технологических средств восстановления БД, организация ведения системных журналов.

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

9. Подготовка и поддержание системных программных средств: сбор и анализ информации о СУБД и других прикладных программ, приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек, развитие программных средств.

Для реализации всех поставленных задач, администратору БД необходимо открыть продукт в Microsoft SQL server Management Studio.

Заключение

В данной курсовой работе была разработана база данных "Автомагазин".

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

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

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

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

Экранные формы для ввода и корректировки максимально «похожи» на привычные для пользователя документы.

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

1. база состоит из связанных таблиц

2. для обеспечения просмотра и поиска используется упорядоченность с помощью индексации и сортировки.

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

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

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

Список использованных источников

1. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г.А. Титоренко. М.: ЮНИТИ, 2005. 399 с

2. Дейт К. Д. Введение в базы данных. К.: Диалектика, 2000. 848 с.

3. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. М.: Издательский дом «Вильямс», 2000. 1120 с.

4. Коннолли Т., Бегг К., Базы данных: проектирование, реализация и сопровождение. Теория и практика. М.: Издательский дом «Вильямс», 2003. 1440 с.

5. Калянов Г.Н. Консалтинг при автоматизации предприятий. М.: СИНТЕГ, 1997. 316 с.

6. Калашян А.Н., Калянов Г.Н. Структурные модели бизнеса: DFD-технологии. М.: Финансы и статистика, 2003. 256 с.

7. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. СПб.: БХВ-Петербург, 2004. 1040 с.

8. Федотова Д.Э. Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. М.: Горячая линия-Телеком, 2005. 160 с.

9. Ларсон Б. Разработка бизнес-аналитики в Microsoft SQL Server 2005. - СПб.: Питер, 2008 - 684 с.: ил.

Приложение 1

Диаграмма IDEF0

1. Оформление заказа.

Приложение 2

Диаграмма DFD - модель потоков данных.

Приложение 3

Диаграмма «Сущность-связь» (ER-диаграмма)

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