Оглавление
Введение
1. Теоретическая часть
1.1 Понятие ИС и ее жизненного цикла, этапы проектирования ИС
1.2 Подход к проектированию информационной системы, реализованный в проекте
1.3 Характеристика CASE-средства для моделирования бизнес-процессов предметной области и выбранного метода (IDEF0 или DFD - общие сведения, состав диаграмм)
1.4 Характеристика CASE-средства для создания модели данных предметной области. ERD модель (общие сведения, состав диаграммы "сущность-связь")
1.5 Роль и место базы данных в информационной системе, обоснование выбора используемой в проекте СУБД
2. Проектная часть курсовой работы
2.1 Описание предметной области задачи
2.2 Постановка задачи
2.3 Построение модели потоков данных (IDF0, DFD) в BPwin
2.4 Построение модели данных в ERwin
2.5 Создание базы данных
Заключение
Список использованной литературы
Приложения
Информационные системы (ИС) управления предприятиями присутствуют на Российском рынке относительно недавно, эксперименты с внедрением данных систем на отечественных предприятиях стали проводиться в основном с начала 90-х годов. Количество внедрений изменяется десятками, качество внедрения зачастую является предметом споров, слухов, домыслов и разочарований. В то же время, интерес к ИС не угасает, и руководители предприятий "отваживаются" на рискованные шаги.
Реорганизация деятельности предприятия, особенно если такая реорганизация связана с внедрением корпоративных информационных систем, связана с серьезным риском. Можно привести множество примеров, когда проекты по внедрению готовых или разработанных под заказ информационных систем оканчивались неудачей. Между тем существующие и опробованные в течение многих лет методики и инструментальные средства позволяют минимизировать риски и решать ключевые вопросы, возникающие на различных этапах реорганизации бизнес-процессов предприятия, в том числе реорганизации, сопровождающейся внедрением информационных систем. [1]
В связи с большим документооборотом, есть насущная необходимость в автоматизации процесса их формирования. Используя имеющиеся СУБД можно решить эту проблему. В данной работе поставлена цель: рассмотрение возможностей формирования отчетов; задача: автоматизация формирования отчетов по отгрузке товаров в разрезе клиентов. Для решения задачи выбраны две методологии: IDEF0 и DFD. Решение основной части проходит с помощью методологии DFD. Инструментальным средством выбрана СУБД.
Информационная система (ИС) в целом - автоматизированная система, предназначенная для организации, хранения, пополнения, поддержки и представления пользователям информации в соответствии с их запросами. [2]
Под жизненным циклом системы обычно понимается непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент ее полного изъятия из эксплуатации. Современные сети разрабатываются на основе стандартов, что позволяет обеспечить, во-первых, их высокую эффективность и, во-вторых, возможность их взаимодействия между собой. Вообще говоря, все стандарты на информационные системы (как и на любые системы, вообще) можно разбить на следующие два основных класса:
Функциональные стандарты, определяющие порядок функционирования системы в интересах достижения цели, поставленной перед нею ее создателями.
Стандарты жизненного цикла, определяющие то, как создается, развертывается, применяется и ликвидируется система.
Модели, определяемые стандартами этих двух классов, конечно же взаимосвязаны, однако решают совершенно разные задачи и характеризуются принципиально различными подходами к их построению.
Например: наиболее полной функциональной моделью системы является сама система, однако "биография" самой системы ни в коем случае не может рассматриваться в качестве модели ее жизненного цикла. Куда ближе к модели жизненного цикла информационной системы является описание жизни живого существа, начиная с момента зачатия.
Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее проектирования:
предпроектный анализ (включая формирование функциональной и информационной моделей объекта, для которого предназначена информационная система);
проектирование системы (включая разработку технического задания, эскизного и технического проектов);
разработку системы (в том числе программирование и тестирование прикладных программ на основании проектных спецификаций подсистем, выделенных на стадии проектирования);
интеграцию и сборку системы, проведение ее испытаний;
эксплуатацию системы и ее сопровождение;
развитие системы. [3]
1.2 Подход к проектированию информационной системы, реализованный в проектеМожно выделить два основных подхода к проектированию современных информационных систем - структурный и процессный. Первый основан на использовании организационной структуры предприятия, когда проектирование информационной системы идет по подразделениям. Технологии деятельности всего предприятия в этом случае описываются через технологии работы его подразделений. Главным недостатком структурного подхода является привязка к организационной структуре, которая довольно часто меняется, поэтому в проект информационной системы постоянно приходится вносить изменения.
Несколько по-иному обстоит дело при процессном подходе. Этот подход ориентирован не на организационную структуру, а на бизнес-процессы. При процессном подходе предприятие рассматривается как совокупность взаимосвязанных и взаимозависимых бизнес-процессов. В отличие от организационной структуры они меняются достаточно редко. Основных бизнес-процессов на предприятии немного, обычно не более десяти. А вот число обеспечивающих бизнес-процессов может достигать нескольких десятков.
Процессный подход подводит к необходимости перехода на так называемое тонкое производство, или тонкую ресурсосберегающую структуру (Lean production).
Основными чертами такой реорганизации являются:
широкое делегирование полномочий и ответственности исполнителям;
сокращение количества уровней принятия решений;
сочетание принципа целевого управления с групповой организацией труда;
повышенное внимание к вопросам обеспечения качества продукции или услуг.
Процессный подход к анализу и моделированию бизнес-процессов и последующей разработке требований к информационным системам позволяет оперативно изменять и дорабатывать технологии, безболезненно (без остановки производства) модернизировать информационную систему предприятия. [4]
В проекте реализован процессный подход, ввиду удобства его использования.
В качестве средств структурного анализа и проектирования, наиболее распространенны следующие нотации:
SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм (рис.1). Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).
Рис.1 Модель в нотации IDEF0
DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.
ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).
Таким образом мы можем сделать следующие выводы по практическому использованию: применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов на этапе анализа.
По диаграммам делаем следующий вывод: наиболее существенное различие между разновидностями структурного анализа заключается в их функциональности.
Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации. Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д.
DFD позволяет проанализировать информационное пространство системы и используется для описания документооборота и обработки информации. Поэтому, диаграммы DFD применяют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.
Нельзя говорить о достоинствах и недостатках отдельных нотаций. Возможны ситуации, при которых анализ IDEF0 не обнаружил недостатков в деятельности организации с точки зрения технологического или производственного процесса, однако это не является гарантией отсутствия ошибок. Поэтому в следующем этапе анализа необходимо перейти к исследованию информационных потоков с помощью DFD и затем объединить эти пространства с помощью последней нотации - IDEF3.
Что касается IDEF1X, наряду со многими достоинствами, существенным недостатком является невозможность адекватно и полно описать предметную область. Поэтому, код клиентского приложения, генерируемый в дальнейшем на основе информации о структуре БД, не позволяет построить эффективное приложение со сложной бизнес - логикой. Это вызвано тем, что данные для хранения в БД необходимо представить в таблицах, к структуре которой предъявляются требования нормализации.
1.4 Характеристика CASE-средства для создания модели данных предметной области. ERD модель (общие сведения, состав диаграммы "сущность-связь")Цель моделирования данных - обеспечить разработчика ЭИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые может быть относительно легко отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г. и получила дальнейшее развитие в работах Ричарда Баркера. Различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером (Oracle Designer). В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF 1Х. [5]
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними.
Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Эти диаграммные техники используются, прежде всего, для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования иерархических и сетевых баз данных).
Диаграммы "сущность-связь" включают:
сущности;
атрибуты;
связи.
Сущность (Entity) - любой объект, событие или концепция, имеющие существенное значение для предметной области, и информация о которых должна сохраняться.
Каждая сущность является множеством подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от остальных.
Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области. Атрибут предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями. Связь (Relationship) - поименованное логическое соотношение между двумя сущностями, значимое для рассматриваемой предметной области.
Сущность является независимой, если каждый экземпляр ее может быть однозначно идентифицирован без определения его отношений с другими сущностями. Независимая сущность изображается прямоугольником с четко выраженными углами. Сущность является зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимая сущность изображается прямоугольником со скругленными углами.
Первичный ключ (Primary Key) - это атрибут или группа атрибутов, однозначно идентифицирующих экземпляр сущности. На диаграмме первичные ключи размещаются выше горизонтальной линии. Ключ может быть сложным, т.е. состоять из нескольких атрибутов.
Альтернативный ключ (Alternate Key) - потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n. m, где n - порядковый номер ключа, m - порядковый номер атрибута в ключе.
Внешние ключи (Foreign Key) создаются автоматически, когда сущности соединяются связью (миграция ключа). Связи между таблицами реляционной БД представляются одинаковыми ключами в таблицах (внешними ключами).
Связи (логические отношения между сущностями) именуются глаголами или глагольными фразами. Имена связей выражают некоторые ограничения или бизнес-правила и облегчают чтение диаграмм.
На логическом уровне можно установить:
идентифицирующую связь один-ко-многим;
неидентифицирующую связь один-ко-многим;
связь многие-ко-многим.
Разработка ERD включает следующие основные этапы:
Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
Идентификация отношений между сущностями и указание типов отношений.
Разрешение неспецифических отношений (отношений многие-ко-многим).
1.5 Роль и место базы данных в информационной системе, обоснование выбора используемой в проекте СУБДОсновной функцией любой СУБД является поддержка независимости, целостности и непротиворечивости данных в условиях коллективного использования. Независимость данных понимается как способность СУБД создавать различные представления об одних и тех же хранимых данных, остающихся инвариантными к изменениям среды функционирования БД [25]. Требуемая степень независимости данных достигается в результате введения внешнего, концептуального и внутреннего уровней определения и манипулирования данными. С внешней точки зрения база данных - это совокупность различных информационных моделей ПО, предназначенных для информационных потребностей пользователей; с концептуальной - база данных есть общая модель ПО, обеспечивающая поддержку различных прикладных систем; с внутренней - база данных рассматривается как физическое представление данных в конкретной среде, используемой для хранения информации. Являясь информационной моделью ПО, база данных обеспечивает коллективное использование информации и необходимые условия для естественной эволюции существующих приложений ИС без их разрушения.
Благодаря концепции БД обеспечивается независимость описания предметной области и задач приложений от структур данных и методов их обработки, программ - от логической структуры базы данных, логической структуры данных - от методов их физической организации.
В информационных системах, использующих БД, можно:
сделать программы ввода, модификации и поиска данных независимыми от программ содержательной обработки приложений;
минимизировать объем хранимых данных путем сокращения их дублирования;
избежать противоречий в хранимых данных;
обеспечить сохранность и целостность информации:
многократно использовать одни и те же данные различными прикладными программами;
обеспечить гибкость и адаптивность структуры данных к изменяющимся информационным потребностям пользователей;
поддерживать адекватность базы данных моделируемой ПО;
обеспечить защиту данных от несанкционированного доступа.
Концепция БД позволяет создавать интегрированные информационные системы, поддерживающие сложные и разнообразные структуры объектов предметной области, содержащие большое число типов данных, значительные объемы фактографической или текстовой информации, а также сделать реальной задачу обеспечения высокой достоверности обработки и хранения больших объемов данных. [6]
Функционирование организации по продаже канцелярских товаров: ООО "КТ" осуществляет продажу канцелярских товаров. Хранится следующая информация о предприятиях-клиентах: название, юридический адрес, телефон, руководитель, главный бухгалтер. Клиентами являются магазины, частные предприятия, кафе, туристические фирмы. Менеджер оформляет заказ, в котором указано наименование заказчика, дата заказа, наименование товара, количество товара, а так же отметки о выполнении\не выполнении заказа, и о выполнении\не выполнении оплаты заказчиком. Заключается двусторонний договор. После выполнения заказа составляется отчет в разрезе клиента, в котором указывается наименование клиента, дата заказа, наименование, количество и цена товара, и выводится общий итог по стоимости.
2.2 Постановка задачи
2.2.1 Цель проектирования ИС:
Потребность в создании ИС обусловлена необходимостью автоматизации деятельности фирмы.
2.2.2 Основные функции, требующие автоматизации:
учет клиентов и заказов;
учет договоров.
2.2.3 Используемые документы и их описание:
Товар - внутренний документ, содержащий информацию о наличии товара, о его цене. Функция: учет товара.
Клиент - внутренний документ, содержащий информацию о клиенте. Функция: учет клиентов.
Заказ - внутренний документ, содержит информацию о всех заказах, сделанных клиентами. Функция: учет заказов.
Договор - исходящий документ. Функция: юридическое обоснование.
Отчет - внутренний документ, составляется на основе запроса по клиентам и товару.
2.3 Построение модели потоков данных (IDF0, DFD) в BPwinАнализ предметной области организации отгрузки товара и получения отчетов по данному процессу проведем с помощью CASE-средства BPwin с использованием двух методов IDF0 и DFD. Выбор данных методов обусловлен следующими факторами:
IDF0 - необходимостью определения соответствующих областей в исследуемой системе, на которых необходимо сфокусировать внимание в первую очередь (моделирование деятельности фирмы с целью построения некоторой информационной системы);
DFD - данные диаграммы используются для описания документооборота и обработки информации. Они являются дополнением к модели IDEF0 для более наглядного отображения текущих операций с документами в системах обработки информации.
На контекстной диаграмме А-0 отображена система управления процессом.
Report for Diagram: A-0, Организация процесса отгрузки товара
Activity Name: Организация процесса отгрузки товара
Link Name: Канцелярские принадлежности
Link Name: Материалы
Link Name: Услуги организации
Link Name: Стандарты
Link Name: Мнение эксперта
Link Name: Персонал
Link Name: Оборудование
Link Name: Сведения о клиенте
Организация работы фирмы - совокупность технологических процессов. Основным результатом этого технологического процесса является оказание различных услуг. Процесс работы подразделяется на 2 непрерывных потока, Один ориентирован на товар, второй - на клиента. (А0)
Report for Diagram: A0, Организация процесса отгрузки товара
Activity Name: Комплектование набора товаров
Activity Name: Обслуживание клиентов
Link Name: Канцелярские принадлежности
Link Name: Материалы
Link Name: Услуги организации
Link Name: Стандарты
Link Name: Мнение эксперта
Link Name: Персонал
Link Name: Оборудование
Link Name: Отгружаемый товар
Link Name: Сведения о клиенте
Следующие две диаграммы - это частные случаи декомпозиции подсистем рассматриваемого процесса. В них выделяются основные процессы. Ниже приведены отчеты по каждой из диаграмм. (А2, А23)
Report for Diagram: A2, Обслуживание клиентов
Подсистемы:
Activity Name: Оформление "карточки" клиента
Activity Name: Оформление пакета документов
Activity Name: Предоставление услуги
Потоки данных:
Link Name: Услуги организации
Link Name: Стандарты
Link Name: Мнение эксперта
Link Name: Персонал
Link Name: Оборудование
Link Name: Отгружаемый товар
Link Name: Пакет документов клиента
Link Name: Готовый пакет документов
Link Name: Карточка клиента
Link Name: Документация
Link Name: Сведения о клиенте
Link Name: Карточка документов клиента
Хранилища:
Data Store Name: База клиентов
Data Store Name: Хранилище оформленных документов
Report for Diagram: A23, Предоставление услуги
Подсистемы:
Activity Name: Прием заявки
Activity Name: Поиск заказанного товара
Activity Name: Заполнение первичной документации
Activity Name: Отгрузка товара
Потоки данных:
Link Name: Услуги организации
Link Name: Стандарты
Link Name: Мнение эксперта
Link Name: Персонал
Link Name: Оборудование
Link Name: Готовый пакет документов
Link Name: Сведения о клиенте
Link Name: Отложенные заявки
Link Name: Заявка на товар
Link Name: Первичная документация
Link Name: Отчет об отгрузке
Link Name: Заявка на склад
Link Name: Документы на отгрузку
Link Name: Отчет о наличии
Link Name: Выполненная заявка
Link Name: Отказ
Хранилища:
Data Store Name: БД выполненных заявок
Data Store Name: БД отложенных заказов
Data Store Name: БД отчетов
Внешние сущности:
External Name: Клиент
2.4 Построение модели данных в ERwinErwin имеет два уровня представления данных: логический и физический.
2.4.1 Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели логического уровня называются сущностями и атрибутами.
Рис.1 Диаграмма ERD-уровень сущности
Рис.2 Диаграмма ERD-уровень атрибутов
2.4.2 Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится вся информация обо всех объектах БД. Исходя из этого можно утверждать, что одна и та же логическая модель может быть представлена несколькими физическими. Представленные в физической модели атрибуты несут конкретную информацию о конкретных физических объектах.
Разделение модели данных на логическую и физическую решают важную задачу наиболее оптимального представления данных, удобного для понимания как специалистам, так и простым пользователям.
Рис.3 Диаграмма ERD-физическая модель
Вторая задача - масштабирование. Существует реальная возможность создания физической модели под любую поддерживаемую ERwin СУБД на основе одной логической модели.
2.5 Создание базы данныхСоздадим базу данных "Отгрузка товаров в разрезе клиентов" в СУБД MS Access. Основным назначением базы данных "Отгрузка товаров в разрезе клиентов" будет автоматизация функции по учету клиентов и заказов.
Рис.1 Схема данных БД "Отгрузка товаров в разрезе клиентов"
... в поставке Microsoft IIS 4.0 уже есть встроенный обработчик ASP. Разработка проекта: 4.1 Перенос базы данных на Microsoft SQL Server. Перенос базы данных компании «ТКС 008» осуществлялся с локального сервера в телефонной службе на WEB-сервер компании. Механизм передачи информации выглядит следующим образом: с сервера телефонной службы, с помощью специально написанной программы, информации из ...
... обслуживания клиентов и гибких систем скидок. ВЫБОР СТРАТЕГИИ МАРКЕТИНГА ПРИ ВЫВОДЕ ТОВАРА НА РЫНОКПри выводе своих товаров и услуг на рынок, ЗАО «ПетроКанцОпт» использует стратегию пассивного маркетинга. Для этой стратегии характерны низкие цены на товары и услуги и минимальные расходы на стимулирование сбыта. Учитывая тяжелое экономическое положение в стране, можно с уверенностью сказать, что ...
... этого перечня может быть различной, но, как правило, она должна включать внешние факторы для их ранжирования по степени воздействия на организацию и оценку воздействия. 1.2.2 Анализ внутренней среды организации При разработке стратегии организации менеджеры должны исследовать не только внешнюю среду, но и ситуацию внутри организации. Необходимо идентифицировать те внутренние перемены, которые ...
... широкую торговую сеть в крупных городах России. По организации и ведению бухгалтерского учёта, а также составлению отчетности, в ЗАО "Электрокомплектсервис" применяется Общая система налогообложения. В состав Холдинга входят несколько предприятий – дистрибьюторов, работающих по упрощенной системе налогообложения. Особенностями малого бизнеса являются: деятельность в хозяйственной сфере с целью ...
0 комментариев