Понятие и классификация АИС

Тема 1. Понятие и классификация АИС

 

1.1Основные понятия и определения информационных систем

 

 

1. Общая характеристика информационных технологий. Основные понятия и определения. Информационная технология – это совокупность методов, производственных процессов и программно-технических средств, объединённых в технологическую цепочку, обеспечивающую сбор, хранение, обработку, вывод и распространение информации для снижение трудоёмкости процессов использования информационных ресурсов, повышения их надёжности и оперативности. Разберём подробнее составные части понятия информационной технологии. Совокупность методов и производственных процессов экономических информационных систем определяет – принципы, приёмы, методы и мероприятия, регламентирующие проектирование и использование программно-технических средств для обработки данных в предметной области. Цель применения ИТ – снижение трудоёмкости использования информационных ресурсов. Под информационными ресурсами понимается совокупность данных, представляющих ценность для организации (предприятия) и выступающих в качестве материальных ресурсов. К ним относятся файлы данных, документы, тексты, графики, аудио и видео информация и др. Информационная система – это система предназначенная для хранения, поиска и выдачи информации по запросам пользователей. Экономическая информационная система (ЭИС) – система для обработки экономической информации. Предметной областью ЭИС является бухучёт, статистика, банковская, кредитно-финансовая, страховая и другие виды экономической деятельности. Для использования ЭИС на рабочем месте её необходимо спроектировать посредством информационных технологий. При этом следует заметить, что ранее процесс проектирования ЭИС был отделён от процесса обработки экономических данных в предметной области. Сегодня он также существует самостоятельно и требует высокой квалификации специалистов-проектировщиков. Однако уже созданы ИТ, доступные любому пользователю и позволяющие совместить процесс проектирования отдельных элементов ЭИС с процессом обработки данных. Например: электронная почта, электронный офис, текстовые и табличные процессоры и т. д. Таким образом, на рабочем месте эксплуатируются как элементы ЭИС, разработанные проектировщиками, так и информационные технологии, позволяющие работнику авто формализовать свою деятельность. Процесс обработки данных в ЭИС невозможен без использования технических и программных средств. Технические средства включают в себя – компьютер, устройства ввода-вывода, оргтехнику, линии связи, оборудование сетей. Программные средства – обеспечивают обработку данных в ЭИС и состоят из общего и прикладного программного обеспечения.

 

 

1.2Предметная  область, информационное обеспечение

 

 

 Состав и способы создания информационного обеспечения

 

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

 

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

 

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

 

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

 

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

 

 

 

 

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

 

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

 

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

 

Функциональный подход в большей степени ориентирован на реализацию текущих запросов управленческого персонала строительной организации и не всегда учитывает перспектив развития автоматизи-рованной системы управления. При его использовании могут возникнуть трудности при объединении взглядов различных пользователей. Однако учет запросов руководителей производства позволяет улучшить характеристики функционирования информацион-ного обеспечения. Следует отметить, что подход “от запроса” позволяет руководителям строительных предприятий в наибольшей мере реализовать один из основополагающих принципов создания АСУ - “принцип новых задач”.

 

Отдельно взятый ни один из указанных подходов не дает достаточной информации для проектирования рационального информационного обеспечения АСУ. Целесообразно совместное применение обоих подходов с ведущим положением объектного подхода. Рекомендуется в качестве первоочередного шага в подготовке информационного обеспечения сделать акцент на подходе “от предметной области”. Однако подготовленную при этом информационную базу следует проанализировать с точки зрения возможности и эффективности выполнения заданных функций.

Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:

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

Язык SQL - универсальный способ манипулирования такими данными.

 

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

 

Предметная область

 

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

Сама предметная область

Модель предметной области

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

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

Собственно база данных и приложения

 

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

 

Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML, и др. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

 

Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

 

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

 

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

 

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

 

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

 

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