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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

САНКТ-ПЕТЕРБУРГСКИЙ  ИНСТИТУТ МАШИНОСТРОЕНИЯ

КАФЕДРА ЭКОНОМИКИ И ПРЕДПРИНИМАТЕЛЬСТВА 
 
 
 
 

РЕФЕРАТ

по дисциплине Информационные технологии управления

на тему:

Классификация и проектирование информационных систем

 
 
 
 
 
Исполнитель: студентка гр.2803

     Каблуков С.Н.

Преподаватель: Самойлов В.В. 
 
 
 
 
 
 
 

Санкт - Петербург

2009

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

     Индустрия разработки автоматизированных информационных систем управления родилась в 50-х - 60-х  годах и к концу века приобрела вполне законченные формы. Материалы данного руководства являются обобщением цикла лекций по Автоматизированным Банковским Системам (АБС) и Автоматизированным системам управления конструкторско-технологическим проектированием (АСУ КТП), читаемым в МГТУ им.Н.Э.Баумана. Не смотря на имеющиеся различия в реализации функциональных модулей данных систем, общие подходы к их разработки во многом схожи, что позволило нам объединить вопросы их проектирования в рамках одного издания.

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

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

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

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

1. Методы проектирования информационных систем

 
1.1"Сверху-вниз"

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

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

 
1.2"Снизу-вверх".

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

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

 
1.3 Принципы "дуализма"

     Развитие  банковских структур и промышленных предприятий, увеличение числа филиалов, рост количества клиентов, необходимость повышения качества обслуживания предъявляли к автоматизированным системам новые требования. Новый подход к проектированию АИС заключается в сбалансированном сочетании двух предыдущих. В первую очередь это относилось к идеологии построения ядра системы: "Автоматизированная бухгалтерия - аналитический учет".

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

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

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

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

     Задача  проектирования АИС промышленных предприятий  более сложна, т.к. характер обрабатываемой информации еще более разнороден и сложно формализуем. Однако и здесь  можно выделить основную модель работы - это работа "от кода проекта". В общем случае код проекта представляет собой аналог (функциональный) лицевого счета, он имеет определенную разрядность, порядок (т.е. конкретная группа цифро-буквенного обозначения характеризует деталь, сборочную единицу, изделие и их уровень взаимосвязи). Причем конкретная часть кода характеризует технологические, конструкторские, финансовые и др. документы. Все это регламентируется соответствующими ГОСТами (аналог инструкций ЦБ для банков), поэтому может быть формализовано. При этом модульный подход к реализации АИС в этом случае еще более важен.

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

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

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

 
1.3. Этапы разработки  информационных систем.

     Итак, мы выбрали метод, которым будем  руководствоваться при проектировании автоматизированной информационной системы. Теперь нам необходимо спланировать комплекс работ по созданию нашей системы в соответствии с типовыми этапами разработки АИС, краткая характеристика которых приведена в табл.1.

     Таблица 1.Этапы проектирования АИС и их характеристики

2. ТЕХНОЛОГИИ СОЗДАНИЯ  РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ  СИСТЕМ

 
2.1. Иерархическая модель

     Первые  иерархические и сетевые СУБД были созданы в начале 60-х годов. Причиной послужила необходимость управления миллионами записей (связанных друг с другом иерархическим образом), например при информационной поддержке лунного проекта Аполлон. Среди реализуемых на практике СУБД этого типа преобладает система IMS (Information Management System компании IBM) (На данный момент это самая распространенная СУБД из всех данного типа). Применяются и другие иерархические системы: TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi - Access Retrieval System компании Control Data Corporation; System - 2000 разработки SAS-Institute.

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

     К ограничениям иерархической модели данных можно отнести:

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

 
2.2. Сетевая модель

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

     Сетевая модель данных - это представление  данных сетевыми структурами типов записей и связанных отношениями мощности один-к-одному или один-ко-многим. В конце 60-х конференция по языкам систем данных (Conference on Data Systems Languages, CODASYL) поручила подгруппе, названной Database Task Group (DTBG), разработать стандарты систем управления базами данных. На DTBG оказывала сильное влияние архитектура, использованная в одной из самых первых СУБД, Iategrated Data Store (IDS), созданной ранее компанией General Electric.Это привело к тому, что была рекомендована сетевая модель.

     Документы Database Task Group (DTBG) (группа для разработки стандартов систем управления базами данных) от 1971 года остается основной формулировкой сетевой модели, на него ссылаются как на модель CODASYL DTBG. Она послужила основой для разработки сетевых систем управления базами данных нескольких производителей. IDS (Honeywell) и IDMS (Computer Associates) - две наиболее известных коммерческих реализации. В сетевой модели существует две основные структуры данных: типы записей и наборы:

• Тип записей. Совокупность логически связанных элементов данных.
• Набор. В модели DTBG отношение один-ко-многим между двумя типами записей.
• Простая сеть. Структура данных, в которой все бинарные отношения имеют мощность один-ко-многим.
• Сложная сеть. Структура данных, в которой одно или несколько бинарных отношений имеют мощность многие-ко-многим.
• Тип записи связи. Формальная запись, созданная для того, чтобы преобразовать сложную сеть в эквивалентную ей простую сеть.

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

 
2.3. Ограничительные условия, поддерживающие целостность базы данных

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

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

 
2.4.. Сравнительные исследования типовых серверных платформ.

     Выбирая платформу для АИС, нужно учитывать  множество аспектов. На решение влияют соображения, связанные с надежностью (кластеризация и балансировка нагрузки), среды разработки, работы над содержанием узла и защиты информации. Результаты тестирования различных платформ широко представлены в периодической печати, представим здесь лишь некоторые обобщения материалов тестирования [].

     При проведении испытаний оценивались Solaris 2.6, Windows NT Server 4 и Red Hat Linux 6.02 (ядро 2.2.11) при эксплуатации четырех web-серверов, занимающих ведущие позиции в мире: Microsoft Internet Information Server 4 (IIS), Netscape Enterprise Server 3.61, Web Server 2.1 корпорации Sun и Stronghold Web Server 2.4.1 (популярный вариант Web-сервера Apache с функциями защиты от несанкционированного доступа) (на тестах использовались триал версии указанного программного обеспечения). Все платформы были испытаны с помощью новой версии эталонного теста WebBench отделения Ziff-Davis Benchmark Operation.  График испытания приведен в рисунке 1.

 
2.5. Защита данных

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

     Транзакция - элементарная единица работы, состоящая  из одного или нескольких операторов SQL;

     Все результаты транзакции или целиком  сохраняются (фиксируются), или.целиком  отменяются (откатываются назад). Фиксация транзакции делает изменения окончательными, занося их в базу данных, и после того как транзакция фиксируется, изменения не могут быть отменены. Откат отменяет все вставки, модификации и удаления, сделанные в транзакции; после отката транзакции ее изменения не могут быть зафиксированы. Процесс фиксации транзакции подразумевает запись изменений, занесенных в журнальный кэш SGA, в оперативные журнальные файлы на диске. Если этот дисковый ввод/вывод успешен, приложение получает сообщение об успешной фиксации транзакции. (Текст сообшения изменяется в зависимости от инструментального средства.) Фоновый процесс DBWR может записывать блоки актуальных данных Oracle в буферный кэш SGA базы данных позже. В случае сбоя системы Oracle может автоматически повторить изменения из журнальных файлов, даже если блоки данных Oracle не были перед сбоем записаны в файлы базы данных.

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

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

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

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

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

 
2.6. Привилегии системного уровня

     Каждый  пользователь Oracle, определяемый в базе данных, может иметь одну или несколько  из более чем 80 привилегий системного уровня. Эти привилегии очень тонко управляют правами выполнения команд SQL. Администратор базы данных назначает системные привилегии или непосредственно пользовательским учетным разделам Oracle, или ролям. Роли затем назначаются учетным разделам Oracle.

     Например, прежде чем создать триггер для  таблицы (даже если вы владелец таблицы как пользователь Oracle), нужно иметь системную привилегию, называемую CREATE TRIGGER, назначенную вашему учетному разделу пользователя Oracle, или роли, присвоенной учетному разделу.

     Привилегия CREATE SESSION - другая часто используемая привилегия системного уровня. Чтобы выполнить соединение с базой данных, учетный раздел Oracle должен иметь привилегию системного уровня CREATE SESSION.

     Привилегии  объектного уровня. Привилегии объектного уровня обеспечивают возможность выполнить определенный тип действия (выбрать, вставить, модифицировать, удалить и т.д.) с указанным объектом. Владелец объекта имеет полный контроль над объектом и может выполнять любые действия с ним; он не обязан иметь привилегии объектного уровня. Фактически владелец объекта - пользователь Oracle, который может предоставлять привилегии объектного уровня другим пользователям.

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

     Привилегии выдаются пользователям и ролям командой GRANT и отбираются командой REVOKE. Все привелегии можно разделить на системные и объектные. Системные привилегии относятся ко всему классу объектов, а объектные относятся к заданным объектам.

Заключение

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

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