Полный курс лекций по Информационным системам информационные системы
| Вид материала | Курс лекций |
СодержаниеСистемный анализа (до направления совершенствования объекта) 3. Внедрение разработанного проекта 4. Эксплуатация и сопровождение проекта Первый цикл Третий цикл Четвертый цикл Пятый цикл Бд: проектирование информационных систем) Методология idef0 Правила интерпретации модели С дугами связываются метки Диаграммы потоков данных Роль методологий в анализе моделируемого объекта Потоки данных Определение модулей и проектирование бд. Проектирование БД. Структуры данных иерархической и сетевой моделей 3.1.Классификация банков данных 3.1.1. Классификация баз данных 3.2. Классификация СУБД ... Курс «Информационные системы» 2 курс фдикт, заочное отделение Объем: 6 часов лекций,, 14.19kb. Системный анализа (до направления совершенствования объекта) К основным целям процесса относится следующее:
СА начинается с описания и анализа функционирования рассматриваемого экономического объекта в соответствии с требованиями (целями), которые к нему предъявляются (блок 1). В результате выявляются основные недостатки существующей ЭИС, на основе которых формулируется потребность в совершенствовании системы управления этим объектом, И ставится задача определения экономически обоснованной необходимости автоматизации определенных функций управления (блок 2), т.е. создается технико-экономическое обоснование проекта. После определения этой потребности возникает проблема выбора направлений совершенствования объекта на основе выбора программно-технических средств (блок 3). Результаты оформляются в виде технического задания на проект, в котором отражаются технические условия и требования к ЭИС, а также ограничения на ресурсы проектирования. Требования определяются в терминах функций, реализуемых системой. И предоставляемой ею информацией.
Процесс предполагает
Этап по составлению функциональной архитектуры (ФА) представляющей собой совокупность функциональных подсистем и связей между ними (блок 4) является наиболее ответственным с точки зрения качества всей последующей разработки Построение системной архитектуры (СА) на основе ФА (блок 5) предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации. Этап конструирования (физического проектирования системы) включает разработку инструкций пользователя и программиста, создание информационного обеспечения, включая наполнение баз данных (блок 6). 3. Внедрение разработанного проекта (блоки 7-10). Процесс предполагает выполнение этапов опытного и промышленного внедрения. Опытное внедрение заключается в проверке работоспособности элементов и модулей проекта, устранения ошибок на уровне элементов и связей между ними. Этап сдачи в промышленную эксплуатацию предполагает организацию проверки проекта на уровне функций и контроля соответствия его требованиям, сформулированным на стадии системного анализа. 4. Эксплуатация и сопровождение проекта. На этой стадии (блоки 11-12) выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС. Рассмотренная схема включает в свой состав только основные процессы, реальный набор которых и их разбиение на этапы и технологические операции в значительной степени зависят от выбираемой технологии проектирования, о чем более подробно будет сказано в последующих разделах данной работы. Важной чертой жизненного цикла ЭИС является его повторяемость. Это соответствует представлению о ней как о развивающейся динамической системе. Другой характерной чертой ЖЦ является наличие нескольких циклов внутри схемы: Первый цикл (1-12) цикл первичного проектирования Второй цикл (7-8, 6-7) – цикл, который возникает после опытного внерения, в результате которого выявляются частные ошибки в элементах проекта, исправляемые, начиная с 6-го блока Третий цикл (9-10, 4-9) возникает после сдачи в промышленную эксплуатацию. Когда выявляются ошибки в функциональной архитектуре системы, связанные с несоответствием проекта требованиям заказчика по составу функциональных подсистем. Составу задач и связям между ними Четвертый цикл (блоки12, 5-12) возникает если требуется модификация системной архитектуры в связи с необходимостью адаптации проекта к новым условиям функционирования системы Пятый цикл (блоки 12, 1-120 возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы. Чтобы исключить пятый цикл и максимально уменьшить необходимость выполнения третьего и четвертого циклов, необходимо выполнять проектирование ЭИС в соответствии с требованиями:
Лекция 8 (БД: ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ)
Любую сложную систему необходимо проектировать. Это связано с нашей физиологией: мы не можем решать одновременно более 7 задач, а разработка и проектирование сопряжены с большим их числом: написанием кода приложения, его отладкой, тестированием, взаимоувязкой модулей приложения, дизайном форм, хранением, обработкой данных и многими другими. Для проектирования ИС необходимо знать регламентирующие этапы проектирования стандарты, определять модули системы и проектировать БД. Основой для проектирования любой сложной системы служит ее концептуальная модель. Определение. Концептуальную модель можно определить как результат абстрагирования части реального мира, которую моделируют ИС. Для обозначения «части реального мира» используют термин «предметная область» Методологии, которые используют для абстрагирования предметной области, отражают специфику применения ИС. Одни из них – OLTP-системы (Online Transaction Processing) предназначены для хранения данных в реальном масштабе времени– OLAP(OnLine Analitical processing)используют в процессе управления бизнесом. Выделяют два типа ИС. Одни из них сопровождают операционные (OLTP), а другие – аналитические (OLAP) базы данных. OLTP – базы хранят данные в реальном масштабе времени, т.е. мгновенно фиксируют события (отгрузку товара со склада). OLAP хранят «историю» изменения БД. Т.е. в них сохраняют данные OLTP – базы с какой-то конкретной периодичностью. Состояние OLTP-базы следующего месяца можно изображать в виде куба. Если провести некий кросстабличный анализ, например, построить график изменения значений какой-то комплектующей по одной позиции, то можно предсказать тенденцию ее сбыта. А значит предсказать прибыль от реализации товара в будущем или принять решение о прекращении его поставок. Это не единственный вариант анализа. Можно сравнивать кривые сбыта разных товаров, чтобы определить. Какой из товаров дает большую прибыль, оптимизировать затраты на рекламу с целью получения максимальной прибыли от реализации товара и т.д. Эти задачи решают с помощью систем поддержки принятия решений (Decision Support System, DSS) на основе данных OLAP-баз. Этот тип ИС ориентирован на решение стратегических вопросов типа прогнозирования сбыта. Поэтому OLAP-системы никогда не оперируют данными реального времени. К системам поддержки принятия решений относят, например, Excel. Большинство средств разработки ИС содержат библиотеки классов или компонентов. Так в Borland Delphi есть компоненты DecisionCube. Системы поддержки решений масштаба предприятия строят на серверных OLAP-средствах: Oracle Express Server, MS SQL Server 2000 Analysis Services, Hyperion Essbase и др. В дальнейшем мы будем рассматривать OLTP-базы данных (OLTP-системы). Кратко охарактеризовать OLTP-базы данных можно так – это большие объемы структурированной информации. Несмотря на упрощенность определения, следует подчеркнуть два аспекта:
Второй аспект определяет область применения БД – относительно развитые бизнес-структуры, или автоматизация бизнеса с небольшим оборотом и узкой номенклатурой товара нецелесообразна. Для моделирования систем и сопровождаемых ими БД используют методологии IDEF0 (Integrated Definition Function Modeling) DFD и (Data Flow Diagrams). Выбор методологии проектирования зависит от степени сложности моделируемого информационной системой объекта. Если это сложный объект, то в начале проектирования ИС желательно использовать IDEF0. В настоящее время эта методология действует в качестве федерального стандарта США. МЕТОДОЛОГИЯ IDEF0 Описывает процессы движения и обработки информации звеньями моделируемого объекта с точки зрения их функционального назначения. IDEF0 – это подмножество SADT (Structured Analysis and Design Technique). Изначально эта методология применялась для проектирования систем общего назначения. Суть методологии IDEF0 на примере производства товара. Для производства используют ингредиенты, инструкции, регламентирующие процесс производства, инструменты, используемые в процессе производства. В терминах IDEF0 моделируемое ИС производство представляется блоком и дугами, как показано на рис.  Рис. 1. Базовые элементы IDEF0 – модели В блоке отображена главная функция моделируемого ИС производства, дуги – множество объектов, участвующих и являющихся результатом производства: информация или действия. Место соединения дуги с блоком определяет тип интерфейса. Правила интерпретации модели: Функциональный блок (функция) преобразует входные объекты в выходные; Управление определяет, когда и как это преобразование может или должно произойти; Исполнитель осуществляет это преобразование. С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом. Выходы одной функции могут быть входами, управлением или исполнителями другой. Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов. Каждый блок IDEF0 – диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами на диаграмме следующего уровня. Эти блоки представляют подфункции исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничено, но рекомендуют на диаграмме использовать от 3 до 6 блоков. Анализ объекта на основе построения его IDEF0- модели является этапом, который должен предварять разработку ИС по следующим причинам:
После этапа моделирования наступает этап физической реализации этой модели в виде ИС. Возникает естественный вопрос об адекватности отображения. Другими словами, как представить в ИС управляющие потоки, хотя потоки данных в ИС будут реализованы как хранилища данных, т.е. файлы. Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, управляющие и информационные приводит разработчиков к необходимости использования диаграммы ПОТОКОВ ДАННЫХ. Это можно делать после этапа составления IDEF0-модели, либо вместо него, в зависимости от сложности моделируемого объекта или предпочтений исполнителя. Лекция 9. После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде ИС. И тут возникает вопрос об адекватности отображения, т.е. как представить в ИС управляющие потоки и др. Хотя понятно, что, например, потоки данных в ИС будут реализованы как хранилища данных, т.е. файлы. Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных. Это можно делать после этапа составления IDEF0-модели, либо вместо него в зависимости от сложности моделируемого объекта или предпочтений исполнителя. ДИАГРАММЫ ПОТОКОВ ДАННЫХ При построении DFD –диаграмм используют следующие элементы:
Внешняя сущность – это объект, который не принадлежит моделируемому объекту и обменивается с ним потоками данных. Это, как правило, потребитель услуг моделируемого объекта. На концептуальной схеме его именуют существительным. В общем случае, сущность – это объект или концепция, которая в рамках конкретной предметной области существует самостоятельно. Процесс описывают глаголом, который обозначает некое действие, связанное с обработкой потока. Построим, используя DFD-методологию, концептуальную модель некоторой риэлтерской конторы, которая специализируется на заключении договоров аренды жилых помещений. При этом будем считать, что круг клиентов конторы относительно стабилен. На рис. 2 внешня сущность обозначена прямоугольником, потоки данных стрелками, процессы – кругами, а хранилища данных – параллельными линиями.  Рис. 2. Концептуальная модель работы риэлтерской конторы Как видно из концептуальной модели заключения договора, внешние сущности – это потенциальные Арендатор и Владелец. Поскольку элементами концептуальной модели являются одноименные хранилища: Арендатор и Владелец, то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть таковыми лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности. Для составления договора используют данные хранилищ Арендатор и Владелец. Эти хранилища необходимы по причине того, что круг клиентов риэлтерской конторы относительно стабилен. Не подвержен значительным изменениями и перечень арендуемых объектов недвижимости, что отражает на концептуальной схеме хранилище Недвижимость. Наличие на диаграмме процесса «Подготовить договор аренды» - это следствие того, что черновик договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом. РОЛЬ МЕТОДОЛОГИЙ В АНАЛИЗЕ МОДЕЛИРУЕМОГО ОБЪЕКТА В результате анализа моделируемого ИС объекта на основе построения IDEF0 и DFD- диаграмм: Определяют главную функцию проектируемой системы: например, сопровождать аренду недвижимости; Описывают происходящие в моделируемом объекте бизнес-процессы. Например: Заключать договора аренды Сопровождать хранение информации об объектах недвижимости Определяют обрабатываемые бизнес процессами информационные потоки. Например, отправка договора менеджеру. Разрабатывают концептуальную модель системы, которая представляет собой описание моделируемого объекта, присущих ему бизнес-правил, потоков и хранилищ данных Примечание: Потоки данных – это прообразы процедур приложения, а хранилища данных – таблиц БД. Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0 и DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой ИС. ОПРЕДЕЛЕНИЕ МОДУЛЕЙ И ПРОЕКТИРОВАНИЕ БД. На данном этапе проектирования ИС:
При разработке ИС немаловажную роль играет выбор среды. Объектно-ориентированная методология позволяет рассматривать разработку прикладных систем, как процесс их конструирования из готовых классов. Модули проектируемого приложения можно определить на основе назначения потоков концептуальной модели. Проектирование БД. Возникновение ситуаций «аномалия удаления» и «аномалия добавления». Необходимость разделения данных. Модель данных должна состоять из совокупности файлов. Разделение данных обеспечивают следующие модели: иерархическая, сетевая, реляционная и объектно-ориентированная. Они по разному связывают данные таблиц данных. Структуры данных иерархической и сетевой моделей В  иерархической модели данные упорядочены как главные (родительские) и подчиненные (дочерние). Достоинством является простота описания предметных областей с иерархической структурой. НО поиск информации возможен только сверху вниз. Почему? Физическое представление логической структуры иерархических моделей в компьютере – это совокупность записей различных типов, каждая из которых ссылается только на следующую Рис. 3. Связь данных в иерархической модели Лекция 3 3.1.Классификация банков данных Банки данных являются сложными системами. и их классификация может быть произведена как для всего банка данных в целом, так и для каждого его компонента отдельно; классификация для каждого компонента может быть проведена по множеству разных признаков. 3.1.1. Классификация баз данных Центральным компонентом банка данных является БД и большинство классификационных признаков относится именно к ней. По форме представления информации различают визуальные и аудиосистемы, а также системы мультимедиа. Эта классификация показывает, в каком виде информация хранится в БД и выдается пользователям. «Изображение» используется в широком смысле: текст, графика, фото, карты, анимационные изображения. Классификация способов представления информации – это самостоятельная проблема. По характеру организации данных БД могут быть разделены на неструктурированные, частично структурированные и структурированные. Этот классификационный признак относится к информации, представленной в символьном виде. К неструктурированным БД могут быть отнесены БД, организованные в виде семантических сетей. Частично структурированными можно считать БД в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры БД. Только тогда БД такого типа могут быть заполнены данными. Структурированные БД по типу использованной модели делятся на иерархические, сетевые, реляционные, смешанные и мультимодельные. Классификация по типу модели распространяется не только на БД, но и на СУБД. В структурированных БД различают несколько уровней информационных единиц, входящих одна в другую. Число уровней может быть различным даже для систем, относящихся к одному и тому же классу. Большинство структурированных систем поддерживают уровень поля, записи и файла. Эти информационные единицы могут называться в разных системах по-разному, но суть остается одной и той же: полю соответствует наименьшая семантическая единица информации; совокупность полей или иных более сложных ИЕ, если они допустимы в конкретной СУБД, образует запись, а множество однотипных записей представляет файл базы данных. В последнее время большинство СУБД поддерживают в явном виде и уровень БД как совокупности взаимосвязанных файлов БД. В иерархических и сетевых моделях между информационными единицами (записями разных файлов) могут задаваться связи. Графическое представление иерархической модели представляет граф типа «дерево». Сетевая модель – граф типа «сеть». Входом в такую структуру может являться любая вершина.. Каждая вершина может иметь несколько порожденных и/или несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т.е. между каждой парой типов записей поддерживается отношение 1 :М. Направление и характер связи в сетевых моделях не являются очевидными. Как в случае иерархической модели, поэтому при изображении структуры БД направление связи должно быть указано. В сетевой модели с однотипными файлами каждый файл может служить входом в структуру. Пара связанных файлов называется набором. В наборе тот файл, от которого идет связь называется владельцем набора, а файл, к которому направлена эта связь – членом набора. Тип файла жестко не зафиксирован. Кроме сетевых моделей с однотипными файлами существуют модели и с разнотипными файлами. В них различают основные (главные) и зависимые файлы. Вход в структуру возможен только через главные файлы. Связываться могут только записи разных типов. Связи в иерархических и сетевых моделях описываются при проектировании БД. Чаще всего эти связи при хранении данных в БД передаются посредством адресных указателей. Иерархические и сетевые модели БД не накладывают ограничений на тип внутризаписной структуры. в принципе она может быть любой: как простой линейной (состоять из простых полей, следующих в записи друг за другом), так и сложной иерархической. включающей различные составные единицы информации (векторы, повторяющиеся группы и т.д.). Конкретные СУБД накладывают ограничения на допустимые в них информационные единицы, характер связей между ними, порядок их расположения в записи, а также часто имеют количественные ограничения.  ИЕ1  СВ1    СВ2 ИЕ3 ИЕ2  СВ3    СВ5 СВ4 ИЕ4  Рис.3.1.Схема сетевой модели с однотипными файлами    З1 З2 Г2 Г1 Рис.3.2. Схема сетевой модели с разнотипными файлами. (Г- главный файл, З- зависимый файл) В реляционных моделях связи между записями разных таблиц БД определяются динамически в момент выполнения запроса. Эти связи устанавливаются по равенству значений соответствующих полей (полей связи), содержащихся в каждом из связанных файлов/таблиц. Другой отличительной чертой реляционных моделей является ограничение на внутризаписную структуру и могут содержать только простые поля. Эти особенности играют решающую роль при проектировании структуры БД. Третьей отличительной особенностью реляционных моделей является использование теоретико-множественных языковых средств: реляционной алгебры или реляционного исчисления. По типу хранимой информации БД делятся на документальные, фактографические и лексикографические. Среди документальных БД различают библиографические, реферативные и полнотекстовые. К лексикографическим БД относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т.п.) В системах фактографического типа в БД хранится информация об интересующих пользователя объектах предметной области в виде фактов; в ответ на запрос пользователя выдается требуемая информация об интересующем его объекте или сообщение о том, что информация отсутствует. В документальных БД единицей хранения является какой либо документ и пользователю в ответ на запрос выдается либо сам документ либо ссылка на него. БД документального типа могут быть организованы по разному: без хранения и с хранением самого исходного документа на машинных носителях. К системам первого типа можно отнести реферативные и библиографические, а также БД – указатели. Специфической разновидностью БД являются БД форм документов. Они обладают некоторыми чертами документальных систем и специфическими особенностями (документ ищется не с целью извлечь информацию, а с целью использовать его в виде шаблона). В последние годы активно развивается объектно-ориентированный подход к созданию ИС. Объектные БД организованы как объекты и ссылки к объектам. Объект представляет собой данные и правила, по которым осуществляется операция с этими данными. Объект включает метод, который является частью определения объекта и запоминается вместе с объектом. В объектных БД данные запоминаются как объекты, классифицированные по типам классов и организованные в иерархическое семейство классов. Класс – коллекция объектов с одинаковыми свойствами. Объекты принадлежат классу. Классы организованы в иерархии. По характеру организации данных и обращения к ним различают локальные (персональные), общие (интегрированные, централизованные) и распределенные БД. Технологии, хотя и кажутся далекими, на самом деле различаются тем, как поддерживается связь между отдельными частями БД. В локальных системах поддержание связи не является централизованным, а в распределенных связь должна поддерживаться СУБД. Совмещать идеи локальной работы и централизованного поддержания единой БД позволяет технология тиражирования, при которой средства СУБД обеспечивают тиражирование отдельных частей общей БД, локальное их использование, а затем согласование отдельных фрагментов БД в рамках единой БД. Концепции централизованной и распределенной обработки данных не сильно различаются между собой. 3.2. Классификация СУБД Классификационные признаки:
СУБД поддерживают разные типы данных. Набор данных в разных СУБД отличается. Некоторые СУБД позволяют разработчику добавлять новые типы данных и новые операции над этими данными. Такие системы называются расширяемыми БД (РСБД). Дальнейшим развитием концепции РСБД являются системы объектно-ориентированных БД.
3.2.1. Общая характеристика проблемы выбора СУБД Сложная проблема, формализовать практически невозможно. Факторы, влияющие на выбор можно разделить на группы: Факторы, характеризующие саму СУБД и средства ее окружения. Факторы, связанные с инфраструктурой, сложившейся вокруг каждого из программных продуктов Факторы, связанные с особенностями предполагаемого использования. СУБД являются сложными языково-программными продуктами. Для обоснованного выбора СУБД необходимо иметь список СУБД - претендентов с описанием их параметров. Характеристики рассматриваются с разной степенью детализации, в зависимости от стоящих задач. Необходимо определить набор свойств, которыми обязательно обладать выбираемая СУБД. Сначала осуществляется предварительный отбор СУБД по качественным параметрам, а уж потом по количественным. При определении временных характеристик СУБД речь обычно идет о тестах на быстродействие. Формальное тестирование заключается в том, что на некотором заданном наборе данных выполняются некоторые операции или наборы операций. Такое тестирование проводят разработчики либо специальные лаборатории. Функциональное тестирование состоит в том. Что исследуются характеристики СУБД при решении определенной прикладной задачи, для реализации которой и выполняется выбор СУБД. Требуется реализовать заданные функции. 3.2.2. Факторы влияния на выбор СУБД
- трудоемкость изучения - трудоемкость создания - гибкость - мощность - наличие языков разного уровня 4. Функциональные возможности 5. Обеспечение безопасности 6. Обеспечение целостности 7. Удобство интерфейса. 8. Требования к техническим средствам, операционной среде 9. Ограничения, накладываемые СУБД 10. Возможность создания «отчуждаемых» приложений 11. Степень универсальности 12. Локализация 13. Качество документации 14. Устойчивость работы, отлаженность системы 15. Наличие средств автоматизации проектирования. Трудоемкость проектирования. 16. Стоимость 17. Мода. Тенденция Сюда же относятся фирма –разработчик, распространенность, условия поддержки. Важную группу составляют факторы, характеризующие предметную область, для которой будет создаваться ИС: масштаб, характер обработки информации, требования к реакции системы, безопасности данных. На выбор СУБД будет влиять квалификация сотрудников и наличие предшествующих наработок. СПИСОК ИНФОРМАЦИОННЫХ СИСТЕМ
|