Lek 3 IS

ЛЕКЦИЯ
Принципы построения управленческих информационных систем
Обобщенная структурная схема УИС
База данных – ядро УИС
Общие сведения о проектировании БД
Трехуровневое представление данных.
Инфологическая модель данных "Сущность-связь"
Обобщенная структурная схема УИС
Эволюция информационных систем прошла путь длиной в 35 лет. С развитием компьютерной техники, программных средств, методов управления информацией менялся и смысл, вкладываемый в это понятие – теперь уже никто не назовет электронную таблицу с калькулятором таким громким именем. Современные информационные системы являются сложными интегрированными комплексами, которые включают в себя модули, отвечающие практически за все механизмы работы современного предприятия. Информационная система – это набор механизмов, методов и алгоритмов, направленных на поддержку жизненного цикла информации и включающих три основных процесса: обработку данных, управление информацией и управление знаниями. С точки зрения программных технологий информационная система – это не один, и даже не несколько программных комплексов. Можно построить структурную модель информационной системы (см. рис.11), выделив ее основные компоненты, которые содержат программные модули определенного класса.














Рис. 11. Структурная схема современной информационной системы
Самым нижним уровнем информационной системы является хранилище, в котором содержится вся интеллектуальная собственность предприятия. Это могут быть документы, справочники, структурные таблицы, деловые правила, описание процессов. Прямого доступа к хранилищу быть не должно, как для пользователей, так и для различных систем предприятия. Прямой доступ имеет лишь система управления знаниями, которая служит своего рода шлюзом для остальных систем и формирует информационное окружение предприятия. Система управления знаниями объединяет идеи, знания, содержание документов и деловые правила, автоматизируя процессы, базирующиеся на знаниях, как внутри предприятия, так и между разными организациями. Для этого нужен шлюз, позволяющий производить обмен данными с внешними системами. Это необходимое условие, так как современные процессы направлены на объединение предприятий в крупные концерны и очевидно, что передача знаний очень важна. Например, системы планирования ресурсов предприятия (ERP – enterprise resource planning) не могут работать независимо – процессы, связанные с управлением финансами, складами, человеческими ресурсами, используют уже накопленные знания и приносят новые.
Также важно выделить класс систем анализа и принятия решений (DSS–decision support system), без которого жизненный цикл информации не будет завершен. В современных организациях интеллектуальный анализ данных становится все более важной задачей. Связано это с необходимостью аналитической обработки больших объемов информации, накопившейся в хранилищах. Такие системы помогают найти новые знания, выявить недостатки и слабые места информационной системы, оценить эффективность тех или иных процессов, установить новые информационные взаимосвязи.
Очень часто говорят, что такой класс систем должен работать непосредственно с хранилищем, поскольку обработке подлежат содержащиеся в нем данные. Теоретически это верно, но на практике такое невозможно – любые изменения в содержимом хранилища, процессах, правилах и взаимосвязях могут и должны производиться системой управления знаниями. Тогда DSS – системам не придется задумываться над тем, в каком формате хранятся данные, и главное, что любое изменение информации будет немедленно влиять на взаимосвязи и процессы, в которых она принимает участие.
База данных – ядро УИС
В информационной системе с использованием технологии баз данных решается задача информационного моделирования какой-либо предметной области (ПО) или её фрагмента. Основа УИС, объект ее обработки – база данных.
Что такое база данных (БД)? В широком смысле слова можно сказать, что БД – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области.
Основные черты концепции БД:
данные отделяются от программ, появляется специальная программная надстройка для управления данными, называемая системой управления базами данных (СУБД); СУБД управляет данными и служит посредником между ними и программами, они упрощаются, освобождаются от функций структуризации, хранения и поиска данных;
появляются стандартизированные данные о фактографических данных – метаданные, управляемые СУБД; метаданные описывают информационные параметры и взаимосвязи фактографических данных о ПО;
СУБД совместно с метаданными представляет собой стандартизированное инструментальное средство для моделирования ПО различной природы;
происходит централизация (интеграция) данных, их многоаспектное использование для различных приложений, что сокращает избыточность данных, позволяет обеспечить более высокий уровень достоверности данных и оптимизировать различные процедуры ведения и использования БД.
Основными функциями СУБД являются:
управление данными во внешней памяти;
управление буферами оперативной памяти;
управление транзакциями;
журнализация;
поддержка языков БД.
Общие сведения о проектировании БД
Процесс проектирования базы данных выполняется поэтапно, а этапы в основном соответствуют разновидностям моделей программного обеспечения при движении от более абстрактных к более конкретным с датологической точки зрения: концептуальной инфологической модели и двух датологических, логического уровня и внутреннего уровня. Построению этих моделей предшествует изучение предметной области.
Таким образом, выделяются следующие четыре этапа проектирования:
обследование ПО, формирование и анализ требований;
инфологическое проектирование;
логическое проектирование;
внутреннее (физическое) проектирование.
Каждому из этапов соответствуют свои принципы, методы, приемы.
Основное содержание первого этапа: сбор сведений о сущностях, их свойствах и взаимоотношениях в ПО; о процедурах, связанных с объектами ПО; о требованиях по объемам информации в БД, быстродействию, пользователях и т.п.
Для специальных ПО приходится общаться со специалистами и экспертами, может использоваться методология проведения экспертных оценок и обработки их результатов. Для обследования и описания ПО существует целый ряд подробно разработанных методик, которые предлагают виды проработанных таблиц для заполнения, вопросники и т.п. вспомогательные средства. Это облегчает и стандартизирует работу по обследованию ПО, позволяет сократить время изучения.
На этапе концептуального, инфологического проектирования разрабатывается концептуальная схема БД. Главные проблемы заключаются в структуризации информационной анархии, полученной в результате сбора информации о ПО, в решении вопросов:
объединения информации из различных фрагментов ПО;
выделения объектов группировкой атрибутов (при этом семантические связи разделяются на внутренние, между атрибутами в составе объектов, и внешние – между сущностями);
выбора ключей;
учета и отображения в составе связей структурных и запросных связей.
Все это решается неоднозначно, но от рационального решения этих вопросов сильно зависит качество БД. Чаще всего при решении указанных вопросов используется терминология и приемы, разработанные в рамках реляционной модели данных (терминология отношений, методы нормализации отношений). Делаются попытки создать в этой сфере автоматизированные системы, подобие САПР.
Существуют два подхода к ПО:
исторически первый (как более простой и быстрый) основан на интегрировании представлений о ПО пользователей информации;
второй базируется на представлениях об объективно (независимо от пользователей) существующей ПО, с присущей ей семантикой.
Современная точка зрения требует сочетания обоих представлений. Без учета второго подхода не будет достаточной гибкости и способности к адаптации при корректировке пользовательских потребностей.
На первом и втором этапах используются такие общеметодологические принципы, как приемы классификационного анализа, принципы системного анализа, принципы анализа и синтеза.
При объединении локальных представлений о фрагментах ПО в единое концептуальное представление используются три основных принципа: идентичности, агрегации, обобщения.
На третьем этапе, этапе логического проектирования, выбирается логический тип модели данных (например из классических: сетевой, иерархический, реляционный) и конкретная СУБД этого типа. Производится отображение концептуальной схемы на выбранную модель с учетом ограничений конкретной СУБД.
На четвертом этапе, при физическом проектировании, решаются вопросы конкретного использования выбранной СУБД для наиболее эффективного выполнения запросов. Здесь выбирается способ организации файлов, методы доступа, способы организации и размеры буферов и блоков, способы индексирования и прочее. Обычно СУБД решает эти вопросы автоматически, по умолчанию, но эти решения могут быть изменены с помощью настроек и специальных процедур.
Трехуровневое представление данных
Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 12).
[ Cкачайте файл, чтобы посмотреть картинку ]
Рис. 12. Уровни моделей данных
Такая человеко - ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, показанные на рис. 12, являются компьютер-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Инфологическая модель данных "Сущность-связь"
Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. [ Cкачайте файл, чтобы посмотреть ссылку ]) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.












13PAGE 15


13PAGE 14615



Автоматизированные системы управления технологическими процессами

Системы планирования ресурсов предприятия (ERP)

Системы анализа и принятия решений (DSS)

Система управления знаниями

Хранилище данных,
документов, приказов, справочников

Шлюз для обмена с внешними информационными системами

Внешняя информационная система



Заголовок 215

Приложенные файлы

  • doc 18814032
    Размер файла: 86 kB Загрузок: 0

Добавить комментарий