Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования
«РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ СТРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ»
Институт информационных систем и технологий
Кафедра прикладной математики и вычислительной техники
КУРСОВАЯ РАБОТА
по дисциплине «Проектирование информационных систем в экономике»
на тему: ИНФОРМАЦИОННАЯ СИСТЕМА «Автомагазин»
Студент группы ПИ-520, шифр 36552 С.А. Фащенко
Специальность – 080801 – Прикладная информатика в экономике
Руководитель работы доц., канд. физ.-мат. наук В.В. Мисюра
Курсовая работа защищена с оценкой
Принял доц., канд. физ.-мат. наук В. В. Мисюра
Ростов-на-Дону, 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. Документирование доменов атрибутов………………………………………
4.5 Документирование ключей…………………………………………………..
4.6 Диаграмма «Сущность-связь» ……………………………………………….
5. ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ .............................................................
5.1. Преобразование концептуальной модели данных в локальную логическую модель данных…………………………………………………………………….
5.2. Проверка модели с помощью правил нормализации………………………
5.3. Определение требований поддержки целостности данных……………….
5.4. Диаграмма «Сущность-связь»……………………………………………….
6. ВЫБОР И ОПИСАНИЕ ИСПОЛЬЗУЕМОЙ СУБД…………………………..
7. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ………………………………...
7.1. Физическая модель базы данных…………………………………………….
7.2. Описание технологии доступа к базам данных…………………………
7.3. Структуры диалога и программного обеспечения………………………
7.4. Блок-схема алгоритма обработки данных…………………………………
7.5. Описание запросов и отчетов к базе данных…………..………………….
8. ОПИСАНИЕ СРЕДСТВ ЗАЩИТЫ…………………………………………
9. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ ИС…………………………………….
10. РУКОВОДСТВО ПРОГРАММИСТА, АДМИНИСТРАТОРА БД............
11. ЗАКЛЮЧЕНИЕ..................................................................................................
12. СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ................................................
13. ПРИЛОЖЕНИЯ..................................................................................................
ВВЕДЕНИЕ
Данная работа посвящена разработке и внедрению модуля автоматизации продажи автозапчастей.
Целями ИС является анализ, проектирование, разработка и внедрение в эксплуатацию модуля, который должен автоматизировать функцию выбора и поиска, сформированных главной программой данных и отвечать требованиям заказчика.
Помимо главной задачи, для получения дальнейшего хода анализа данных, модуль должен формировать отчеты работы электронного каталога в целом. Полученная обработанная информация, сохраненная в простейших отчетах, послужит основными данными для работы экономического отдела компании.
Данное приложение позволит:
-хранить информацию в удобном виде;
-совместно использовать базы данных несколькими пользователями;
-просмотр отчеты по основным показателям системы (статистика продаж)
Основная цель разрабатываемой АИС –доступ, самостоятельный выбор и поиск продавцом или менеджером, запчасти, необходимые покупателю.
При выполнении курсового проекта использовались такие программные средства как EnterpriseArchitect, MicrosoftVisualStudio 2010, Microsoft SQL Server 2008, Среда SQL ServerBusinessIntelligenceDevelopmentStudio.
Исходными данными для решения ряда задач текущего и дальнейшего планирования работы компании являются материалы, полученные при детальном изучении функциональной деятельности компании по основному направлению - предоставление услуг по продаже автозапчастей.
Разработка требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований.
Система «Автозапчасти» предназначена для автоматизации деятельности кассиров и менеджеров, обслуживающих покупателей. Эксплуатация системы предполагается на вычислительном комплексе, расположенном непосредственно в автомагазине. Сам программный продукт состоит из набора модулей, которые позволяют, автоматизировано выполнить процесс продажи запчастей, контроля информации о покупателе, запчасти и её характеристиках, позволяют выполнить отчет по имеющейся информации.
Для своей деятельности организация должна иметь у себя в штате менеджеров, кассиров, системных администраторов (если необходимо), бухгалтеров, офис менеджера и т.д.
Система обеспечивает следующие возможности:
· продажа автозапчастей;
· как прямая продажа, так и продажа по предварительным заказам;
Чтобы знать какой клиент приобрел запчасть, какие запчасти есть, информационная система должна отвечать следующим требованиям:
1. Возможность добавления новой запчасти и недопущение добавления одной и той же запчасти несколько раз.
2. Возможность редактирования информации о марке, коду и др .
3. Возможность удаления запчасти.
4. Возможность добавления информации о клиенте
5. Возможность редактирования информации о клиенте.
6. Удаление информации о клиенте.
7. Также необходимо предусмотреть поиск, как по клиентам, так и по запчастям.
1.2. Регламент бизнес процессов
Приведенные здесь бизнес-правила на этапах логического и физического проектирования БД будут рассматриваться как совокупность ограничений целостности. Выполнение указанных ограничений, должно контролироваться в разрабатываемой системе.
Бизнес-правила:
- значения характеристик запчасти должны быть из области допустимых значений;
- при оформлении покупки необходимо учитывать категорию клиента, так как на каждой категории существует скидка;
- данные по заказам хранятся в БД 3 года, а затем передаются в электронный архив;
- при оформлении покупки необходимо заполнять все поля;
- нельзя осуществлять продажу за прошедшие дни.
Описание входных документов подразумевают ввод данных, которые будут использоваться в проектируемой базе данных.
Эти сведения можно разделить на типы:
Сведения о заказе включают: марку запчасти, идентификационный код, год выпуска, сумму заказа.
Сведения о покупателях включают: ФИО покупателя, телефон.
Сведения о запчастях включают: марку запчасти, идентификационный код, год выпуска, цена.
Результатом вывода элементов базы данных являются следующие сообщения: информация о проданных запчастях; информация о продаже, включающая в себя дату, информацию о клиенте, информацию о стоимости запчасти. Сведения об оплате включают: ФИО продавца, оформляющего заказ, марку запчасти, код, цена, дата продажи. Выходные сообщения должны выводиться на экран монитора, и храниться в виде файлов базы данных для последующей обработки.
Таким образом, основным выходным документом является отчет по продажам.
Информационные потребности пользователей выражаются в следующем: пользователям базой данных необходимо находить нужную им информацию в БД, например, сведения о запчастях, просматривать ее, анализировать, вносить изменения или удалять данные. Для этих целей используют отчеты и запросы.
1.6. Запросы
Перечень возможных запросов к базе данных:
1.7. Отчёты
Перечень возможных отчетов:
2.1 Функциональная модель IDEF0
На диаграмме IDEF0 отображены следующие функции:
Диаграмма IDEF0 приведена в приложении 1.
3.1. Контекстная диаграмма
«Поиск запчасти» - эта функция принимает от покупателя информацию и ищет среди имеющихся запчастей, ту, которая удовлетворяет потребности покупателя.
«Поиск клиентов» - эта функция предоставляет информацию о клиентах.
«Поиск сотрудников» - эта функция предоставляет информацию о сотрудниках.
«Продажа» - эта функция выбирает среди множества запчастей ту, которую хочет приобрести покупатель, позволяет оформить договор по продаже.
В результате исследования информационных потоков была построена DFD модель, которая показывает, какие информационные потоки возникают при выполнении функций.
DFD-диаграмма приведена в приложении 2.
4.1. Документирование сущностей
Подходя к вопросу документирования сущностей, перечислим выявленные сущности словарь данных БД «автосалон» (табл. 1).
|
Имя сущности |
Описание |
Псевдоним |
Описание использования |
|
Сотрудники |
Предоставляет полный перечень всех сотрудников и основную информацию о них |
- |
Позволяет начальству найти необходимую информацию о сотрудниках |
|
Запчасти |
Предоставляет полный перечень автозапчастей |
- |
Позволяет сотрудникам найти необходимую информацию об автозапчастях |
|
Клиенты |
Предоставляет полный перечень клиентов и основную информацию о них |
- |
Позволяет сотрудникам найти необходимую информацию о клиентах |
|
Склад |
На складе находятся все имеющиеся в наличае запчасти |
- |
Позволяет сотрудникам проверить наличие необходимой запчасти на складе |
|
Продажа |
Предоставляет список выбранных запчастей, ФИО клиента, дату, сумму проданных запчастей |
- |
Позволяет оформлять заказ на запчасти, выбранные покупателем |
Таблица 1. Определение типов сущностей
В данной таблице рассмотрены сущности и описание их использования.
Подходя к вопросу документирования связей, перечислим выявленные связи между сущностями, это может выражаться сведениями о типах связей (табл. 2).
|
Сущность |
Тип связи |
Сущность |
Кардинальность |
Модальность |
|
Сотрудники |
Сотрудник обслуживает клиента |
Клиент |
1:М |
Д:М |
|
Запчасть |
Сотрудник предлагает запчасть |
Сотрудник |
М:1 |
М:Д |
|
Клиент |
Клиент выбирает запчасть |
Запчасть |
1:М |
М:Д |
|
Запчасть |
Запчасть находится на складе |
Склад |
М:1 |
М:Д |
|
Продажа |
Клиент покупает запчасть |
Клиент |
М:1 |
М:Д |
Таблица 2. Определение типов связей
В данной таблице выявлены типы связей между сущностями, а так же модальность и кардинальность между различными имеющимися сущностями.
Рассмотрим документирование атрибутов, доменов атрибутов и ключей (табл 3).
|
Имя сущности |
Атрибут |
Описание атрибута |
Тип данных и длина |
Ограничение |
Значение по умолчанию |
Допустимость |
|
1 |
2 |
3 |
4 |
5 |
6 |
8 |
|
Сотрудники |
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 |
Таблица 3. Определение атрибутов и связывание их с сущностями
В данной таблице рассмотрены описание каждого из атрибутов, типы данных и длина, ограничения, а так же наличие значения по умолчанию и допустимость.
Модель сущность-связь модель данных, позволяющая описывать концептуальные схемы предметной области.
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 R2 включает следующие инструменты:
Основные возможности Microsoft SQL Server 2008 R2:
На основании этих преимуществ, по сравнению с другими СУБД, и возможностей СУБД была выбрана эта система управления реляционными базами данных
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. ОПИСАНИЕ СРЕДСТВ ЗАЩИТЫ
С целью защиты информации в базе данных «Автомагазин» была создана форма авторизации, благодаря которой, без ввода определенных данных (имени и пароля) дальнейшее пользование базой невозможно. Перейдем к описанию средств защиты:
Форма авторизации
Можно войти под администратором и под покупателем, так же можно зарегистрироваться, в зависимости от того под каким пользователем осуществляется вход открываются различные формы: форма администратора и форма покупателя.
Код данной формы
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. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ ИС
Рассмотрим пошаговое руководство для пользователя информационной системой, которым в данном случае, является менеджер автосалона:
10. РУКОВОДСТВО ПРОГРАММИСТА, АДМИНИСТРАТОРА БД
Администратор базы данных выполняют работы по созданию и обеспечению функционирования БД на протяжении всех этапов жизненного цикла системы.
Администраторы базы данных выполняют большой круг разнообразных функций:
Для реализации всех поставленных задач, администратору БД необходимо открыть продукт в Microsoft SQL server Management Studio.
ЗАКЛЮЧЕНИЕ
В данной курсовой работе была разработана база данных "Автомагазин".
С помощью базы данных можно без затруднений и специальных знаний вести базу данных, которая позволяет делать все операции с продажей автозапчастей. То есть добавлять, изменять, удалять и просматривать все имеющиеся и вводимые данные.
Кнопочная форма позволяет просматривать отчеты, искать необходимую информацию .
Целью курсового проекта было спроектировать и реализовать инфор-мационную систему на основе БД в среде Microsoft SQL Server 2008 . Сис-тема имеет интуитивный интерфейс, обеспечивающий работу "наивного" пользователя, в данном случае кассира или менеджера по продажам. Это качество значительно расширяет круг возможных пользователей программы и увеличивает ее коммерческую привлекательность.
Система работает достаточно устойчиво и не теряет работоспособность ни при каких, даже некорректных, действиях пользователя. В разработанной БД использованы все возможности СУБД по поддержке целостности данных и ссылочной целостности. В рамках задания реализованы все требуемые функций. В диалоговых средствах используются только термины, понятные пользователю, цветовая гамма – по общепринятым рекомендациям.
Экранные формы для ввода и корректировки максимально «похожи» на привычные для пользователя документы.
Программный продукт обеспечивает выполнение перечисленных ниже операций над базами данных:
1. база состоит из связанных таблиц
2. для обеспечения просмотра и поиска используется упорядоченность с помощью индексации и сортировки.
3. вся информация поддается просмотру и редактированию. Записи, содержащие много полей, можно просматривать как в табличном, так и в постраничном виде.
4. программа позволяет производить поиск или выборку информации по произвольному запросу.
Ещё как интеграция информационных систем во все сферы жизни увеличивается с каждым днем, то актуально становится разработка подобных баз данных. При этом разработчик должен учитывать то, что наиболее простые БД могут быть подвержены избыточности, но при этом нельзя и увлекаться делением БД на много составных таблиц. Также современные средства дружественного интерфейса позволяют разработать интуитивно понятные приложения, что является одним из основных требований заказчика. При создании БД необходимо принять во внимание область, для которой разрабатывается база данных. Например, при формировании БД для магазина, разработчик должен ориентировать её в первую очередь на продажу.
ПРИЛОЖЕНИЯ
Приложение 1. Диаграмма IDEF0
Приложение 2. Диаграмма DFD – модель потоков данных.
Прилодение 3. Диаграмма «Сущность-связь» (ER-диаграмма)
