Информационное обеспечение систем управления
Скачать 3.02 Mb.
|
ПОСТАВКИ[ №П, №Д ], содержащую номера поставщиков и номера поставляемых ими деталей:
В качестве делителя возьмем проекцию Y=ДЕТАЛИ[№Д], содержащую список номеров всех деталей:
Деление отношения X на Y дает список номеров поставщиков, поставляющих все детали:
Оказалось, что только поставщик с номером П1 поставляет все детали. В табл. 3.1 приведен список реляционных операций и соответствующий ему набор синтаксических выражений, элементы которого формально определяют каждую операцию из списка. Таблица 3.1
Приведем примеры использования реляционных операций. Пример 1. Получить имена поставщиков, поставляющих деталь Д2. ((ПОСТАВКИ join ПОСТАВЩИКИ) where №Д=Д2)[ФИО]. Пример 2. Получить имена всех поставщиков, реализовавших поставку хотя бы одной гайки. (((ДЕТАЛИ where Наимен="Гайка") join ПОСТАВКИ) join ПОСТАВЩИКИ) [ФИО] Ответ на этот запрос можно получить и иначе: (((ДЕТАЛИ join ПОСТАВКИ) join ПОСТАВЩИКИ) where Наимен="Гайка") [ФИО] Пример 3. Получить имена поставщиков, поставляющих все детали. ((ПОСТАВКИ[№П, №Д] devidby ДЕТАЛИ[№Д]) join ПОСТАВЩИКИ)[ФИО]. Пример 4. Получить имена поставщиков, не поставляющих деталь Д2. ((ПОСТАВЩИКИ[№П] minus ((ПОСТАВЩИКИ join ПОСТАВКИ) where №Д=2) [№П]) join ПОСТАВЩИКИ) [ФИО]. Ответ на данный запрос можно также получить по шагам.
Как было сказано в начале данного подраздела, не все операции реляционной алгебры являются независимыми – часть из них выражаются через другие. Прокомментируем данное утверждение. Операция соединения. Она определяется через операции декартового произведения и выборки. Для операции естественного соединения добавляется операция проекции. Операция пересечения. Она выражается через вычитание как А intersect В = А minus (А minus В). Операция деления. Она выражается через операцию вычитания, декартового произведения и проекции как А devidby В = A[X] minus ((A[X] times B) minus A) [X]. Таким образом, показано, что операции соединения, пересечения и деления можно выразить через другие реляционные операции, т.е. они не являются примитивными. Оставшиеся реляционные операции (объединение, вычитание, декартово произведение, выборка, проекция) являются примитивными операциями их нельзя выразить друг через друга. Операция декартового произведения. Она одна увеличивает количество атрибутов, поэтому ее нельзя выразить через другие. Операция проекции. Она одна уменьшает количество атрибутов, поэтому ее нельзя выразить через другие. Операция выборки. Она одна позволяет проводить сравнения по атрибутам отношения, поэтому ее нельзя выразить через другие. Операции объединения и вычитания. Доказательства их примитивности более сложны и мы их здесь не приводим. Несмотря на мощь языка реляционной алгебры, имеется ряд типов запросов, которые принципиально нельзя выразить только при помощи операторов реляционной алгебры. Это вовсе не означает, что ответы на эти запросы нельзя получить вообще. Просто, для получения ответов на подобные запросы приходится применять базовые языки СУБД. Приведем три примера. Пример 1. Пусть имеется отношение, в котором хранятся данные о заработной плате сотрудников по месяцам года. Рассмотрим запрос "Найти все месяцы, в которых заработная плата какого-либо сотрудника превышает заданный уровень (скажем, 10000 руб.)". С алгоритмической точки зрения этот запрос выполняется элементарно, а именно: просматриваются все столбцы таблицы, если в столбце присутствует хотя бы одно значение, большее 10000, то запоминается заголовок этого столбца. Набор наименований запомненных столбцов и является ответом на запрос. Формально невозможно выразить этот запрос в рамках реляционной алгебры, т.к. ответом на этот запрос должен быть список атрибутов отношений, удовлетворяющих определенному условию. В реляционной алгебре нет операторов, манипулирующих с наименованиями атрибутов. На самом деле, этот пример показывает, что таблица плохо нормализована (нормализация отношений рассматривается в разделе 4). В таблице есть набор однотипных атрибутов. Пример 2. Невыразимость транзитивного замыкания реляционными операторами. Рассмотрим отношение, описывающее сотрудников некоего предприятия. Отношение содержит данные о табельном номере сотрудника, фамилии, должности и табельном номере руководителя сотрудника.
Рассмотрим запрос "Перечислить всех руководителей (прямых и непрямых) данного сотрудника". Ответом на запрос может быть получен при помощи понятия транзитивного замыкания. Однако транзитивное замыкание не может быть выражено операторами реляционной алгебры. Пример 3. Кросс-таблицы. Пусть имеется отношение с тремя атрибутами и потенциальным ключом, включающим первые два атрибута. Примером такого отношения могут быть данные с объемами продаж различных товаров за некоторые промежутки времени:
Требуется представить эти данные в виде таблицы, по строкам которой идут наименования товаров, по столбцам месяцы, а в ячейках содержатся объемы продаж. Это и будет кросс-таблицей.
Построение кросс-таблицы средствами реляционной алгебры невозможно, т.к. для этого требуется превратить данные в ячейках таблицы в наименования новых столбцов таблицы. Подведем итоги. Доступ к данным в реляционной модели возможен при помощи операций реляционной алгебры, которая представляет собой набор операций, использующих отношения в качестве аргументов, и возвращающие отношения в качестве результата. Она замкнута таким образом, что результаты одних реляционных выражений можно использовать в других выражениях. Традиционно определяют восемь реляционных операций, объединенных в две группы. Теоретико-множественные операции объединение, пересечение, вычитание, декартово произведение и специальные реляционные операции выборка, проекция, соединение, деление. Для выполнения некоторых реляционных операций требуется, чтобы отношения были совместимы. Не все операции реляционной алгебры являются независимыми некоторые из них выражаются через другие. Операции соединения, пересечения и деления можно выразить через другие реляционные операции, т.е. они не являются примитивными. Остальные (объединение, вычитание, декартово произведение, выборка, проекция) являются примитивными. Имеется несколько типов запросов, которые нельзя выразить средствами реляционной алгебры. К ним относятся запросы, требующие дать в ответе список атрибутов, удовлетворяющих определенным условиям, построения транзитивного замыкания отношений и построения кросс-таблиц. Для получения ответов на подобные запросы приходится использовать процедурные расширения реляционных языков. 4. ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ 4.1. Содержание работ по проектированию АИС В ИС реализуется определенная технология по сбору, систематизации, контролю, обработке, хранению, передаче и использованию информации. Если говорят о современной информационной технологии, то, как правило, подразумевают в составе ИС наличие ВС и такие ИС называют автоматизированными информационными системами (АИС). В класс АИС обычно включают следующие разновидности систем: 1. Автоматизированные системы управления (АСУ) различного назначения. Они предназначены для непрерывного отражения изменений в предметной области с целью обеспечения лиц принимающих решение объективной информацией. Основная функция – сбор и систематизация информации о предметной области. 2. Автоматизированные рабочие места (АРМ) различного назначения. Например, АРМ бухгалтера по начислению заработной платы. АРМ экономиста по калькуляции себестоимости. АРМ «Квартплата». АРМ «Ведения реестра акционеров». АРМ «Диспетчер АТП». АРМ «Складское хозяйство» и т.п. Основная функция – сложная обработка информации. 3. Информационно-справочные системы различного назначения. Например, ИСС для диагностики болезней, ИСС продажи авиабилетов, ИСС расписания движения поездов и т.п. Основная функция – использование информации по назначению. 4. Автоматизированные системы контроля (АСК) различного назначения. Например, автоматизированная система контроля ритмичности движения городского автотранспорта, АСК технологических параметров в определенном производстве. Основные функции – это получение и контроль информации. В перечисленных системах наиболее ярко выделяются одна из составных частей информационной технологии. Однако проектирование таких систем имеет много общих моментов, которым и будет уделено основное внимание. Рассмотрим общесистемные принципы проектирования сложных объектов. В учебной литературе обычно анализируют четыре таких принципа. 1. Принцип декомпозиции. Описание сложного объекта должно быть согласовано с физиологическими возможностями восприятия человека. Это требование можно выполнить в рамках некоторого единого описания, не расчленяя его на простые составные части, только для простых объектов. Например, разработать единую принципиальную электрическую схему ЭВМ практически не возможно, или составить блок-схему сложного программного комплекса. Эти схемы будут просто необозримы. Данным принципом пользуются подсознательно, называя его принципом модульности (структурное программирование, модульность и магистральность в микропроцессорной технике). Разбить проектируемый объект на простые составляющие различными разными способами. Например, случайным образом, или так, чтобы части содержали одинаковое число элементов, или – имели бы одинаковый вес и т.п. В проектировании при декомпозиции чаще других применяют два следующих критерия. Степень детализации отображаемых свойств; на основе этого критерия объект разбивают на несколько иерархических уровней, чем ниже уровень, тем более детально описаны его части. В учебной литературе можно найти многочисленные примеры декомпозиции по данному критерию программных комплексов, механических или электронных объектов. Критерий характер отображаемых свойств позволяет различить три стороны в описании объекта: функциональную, конструкторскую и технологическую. Соответственно, различают три аспекта в процессе проектирования. При функциональном проектировании основное внимание уделяют принципам функционирования, характеру физических и информационных процессов. В результате имеют принципиальные, функциональные, кинематические и т.п. схемы и сопровождающие их документы. Конструкторский проект реализует функциональный проект в виде конкретных геометрических форм элементов и их взаимного расположения в пространстве. Технологический проект реализует конструкторский в виде описания методов и средств изготовления объекта. Все три стороны процесса проектирования органически взаимосвязаны между собой. В проектировании АИС этот принцип, как правило, реализуется в виде расчленение предметной области на подсистемы и параллельной разработки этих подсистем (подсистема продаж, складская подсистема, подсистема планированья, бухгалтерия и т.д.). Кроме того, выделяются два аспекта в рассмотрении информационных технологий – инфологический и датологический. 2. Принцип многоэтапности и итерационности. Проектирование как процесс, развивающийся во времени, распадается на стадии, этапы, проектные процедуры и операции. Перечень этих фрагментов и их взаимосвязь регламентируется соответствующими стандартами. Например, в ГОСТ 19.102-77 “Стадии разработки” ЕСПД различают следующие стадии разработки: техническое задание, эскизный проект, технический проект, рабочий проект, внедрение. В любой момент времени разработчик может оказаться в “тупиковой ситуации” (невозможность реализовать то, или иное решение), тогда возникает необходимость вернуться к более ранней стадии или этапу. Итерационность процесса проектирования и определяется такими возвратами. На данном принципе реализуются практически любая проектная процедура. Ниже в данном подразделе приводится рекомендуемая последовательность этапов разработки АИС. 3. Принцип нисходящего и восходящего проектирование. Если решение задач высоких иерархических уровней предшествует решению задач более низких уровней, то такой подход к проектированию называется нисходящим, в противном случае восходящим. Кто знаком с идеями структурного программирования, то помнит, что в основе его лежит принцип нисходящего программирования. Специалисты-программисты убедительно доказывают, что только такая технология проектирования программных средств обеспечивая качественное выполнение проектов в течение заданного временного отрезка. У каждого из подходов есть свои преимущества и недостатки. При нисходящем подходе существует неопределенность относительно фрагментов системы более низких уровней иерархии. При восходящем подходе нет полной информации о системе в целом. На практике обычно сочетают оба подхода. Например, восходящее проектирование используют в тех случаях, когда применяют унифицированные элементы на нижних уровнях (разработка программного комплекса только из стандартных подпрограмм, разработка цифрового устройства из готовых блоков). 4. Принцип стандартизация проектных процедур и решений. Стандартизация объектов и их элементов ведет к улучшению технико-экономических показателей производства и эксплуатации. Этот вывод справедлив и для фрагментов процесса проектирования. Использование типовых и унифицированных проектных решений приводит к упрощению и ускорению процесса проектирования (типовые элементы разрабатываются однократно, но используются в различных проектах многократно). Путь использования типовых проектов не всегда доступен (например, для принципиально новых объектов или новых технологий). Разработчик часто вынужден прибегать к многоуровнему итерационному проектированию. В такой ситуации актуален вопрос не об унификации изделий, а об унификации проектных процедур в рамках САПР. Наличие средств автоматизации проектирования позволяет в короткие сроки изготовить качественные проекты. Содержание работ по проектированию АИС условно можно разбить на четыре обобщенных этапа.
В настоящем подразделе будут обсуждены первые два этапа разработки. Формальных методик выполнения работ по перечисленным этапам не существует, как их не существует для любых проектных работ, хотя отдельные проектные процедуры хорошо формализуются. В современной литературе проектирование примерно в равной степени относят как к области науки, так и области искусства. Тем не менее, содержание работ и направления для их выполнения можно обсудить. Содержание работ по первому этапу можно в общем виде определить, как исследование количественных характеристик информационных потоков в ПО и на этой основе обоснование аппаратных и системных программных средств. Проще говоря, нужно выявить объемы информации в байтах, предназначенной для хранения и скоростные показатели на ее обработку. Исходя из этого, обосновать требования к ВС, операционную систему и под нее, с учетом всех критериев, выбрать из класса наличных товарных СУБД одну конкретную. Как правило реальная ситуация выглядит проще, ВС уже фиксирована, есть в наличии и заказчик, который в техническом задании указывает конкретную ВС. И все же анализ объемных и скоростных показателей следует провести, чтобы на одном из последующих этапов не оказаться в тупиковой ситуации. Если речь идет о дипломном проектировании ИС, то результаты этого этапа отражаются в первой главе пояснительной записки. Рекомендуемое ее содержание: 1. Системотехническая проработка проекта. 1.1. Анализ существующих (традиционных) технологических процессов в данной предметной области. 1.2. Мероприятия по совершенствованию системы или предложения по использованию современных информационных технологий. 1.3. Оценка объемных и скоростных показателей информационных потоков в данной предметной области. 1.4. Обоснование аппаратных и системных программных средств вычислительной системы. 1.5.Оценка эффекта (экономического, технического, социального и др.) от внедрения мероприятий по совершенствованию системы. Второй этап разработка логической структуры базы данных или информационной модели предметной области. Среди множества задач, стоящих перед разработчиком информационной модели, следующие являются наиболее важными. 1. Обеспечить возможность хранения всех необходимых в настоящее время и возможно в будущем данных о предметной области. 2. Исключить избыточность данных. Повторение данных в таблицах может явиться причиной ошибок при вводе, их противоречивости и нерационального использования дисковой памяти. 3. Свести число хранимых в базе данных отношений к минимуму этого требует обеспечение быстрого и простого доступа к данным. 4. Обеспечить целостности данных. Обеспечить такие условия, чтобы при изменении одних данных автоматически происходило соответствующее изменение связанных с ними других данных. Для упрощения проблем, связанных с модификацией, добавлением и удалением данных следует нормализовать все отношения базы данных. Нормализация также способствует исключению избыточности. Третья и четвертая задачи, очевидно, являются противоречивыми. Нормализация требует разбиения таблиц на части, но при этом их число возрастает. По существу разработка логической структуры базы данных преследует цель поиска ответов на два следующих вопроса.
Для ответа на первый вопрос существует два подхода, а именно: подход «от предметной области» и подход «от запроса». При формировании перечня полей в будущей базе данных по первому подходу «от предметной области» ставят цель задать такое множество полей, которое в будущем не пришлось бы дополнять даже при изменении функций АИС. Например, при проектировании АРМ «Кадры» учитывают всю информацию о сотруднике, даже такую, которая не нужна отделу кадров, но в будущем, возможно, она пригодится, например, при автоматизации работ по начислению заработной платы и т.д. Обычно, чтобы качественно решить такую сложную задачу, исследуется документооборот в данной предметной области. Формы документов (приказы, отчеты, карточки) как правило, содержат полные сведения об исследуемой предметной области т.к. они существуют на длительном отрезке времени и в них отражается вся необходимая информация. Документооборот исследуется с позиции системного подхода. С функциональной точки зрения выявляется множество входных и выходных документов в данной предметной области, т.е. фиксируется внешнее поведение системы. Внутреннее движение документов (структурный подход) – это обмен документами между составными частями данной предметной области. Технология от «запроса» предполагает исследование потребностей в информации каждого будущего конечного пользователя. Как правило, это исследование ведется разработчиком базы данных, которому необходимо максимально полно выяснить какие запросы к базе данных интересуют всех потенциальных пользователей. Опросив таких пользователей, разработчик может задать перечень полей проектируемой базы данных. В этой технологии вероятность пропустить нужную информацию значительно больше, чем в первой технологии, т.к. пользователи чаще всего сами четко не представляют, что бы они хотели получить от будущей АИС. Реально процесс проектирование базы данных, обычно сочетает в себе идеи обоих подходов но, как правило, в нем приоритетное место отводится подходу от запроса. Результат решения второй задачи – назначение перечня отношений и задание полей в каждом из них. Это наиболее сложная часть процесса проектирования. База данных, содержащая аномалии, может при ее использовании привести к негативным явлениям. Таким, как неверные ответы на запросы, потеря информации т.д. Приведем два примера. Пользователю требуется удалить информацию о поставках деталей от некоторых поставщиков. Команда на удаление этой информации завершается также удалением имени и адреса поставщика, помимо информации о поставке. Пользователь пытается исправить имена клиентов. Однако он забывает, что имя хранится в трех различных отношениях. В результате только одно из трех имен изменяется. Тогда правильное написание имени клиента вызывает сомнение и противоречие. В учебной литературе обсуждаются обычно также две технологии назначения перечня отношений и состава полей в них. Это метод декомпозиции и метод «сущность-связь». Идея метода декомпозиции заключается в том, что на первом этапе строится универсальное отношение (одна большая таблица) и далее, анализируя функциональные зависимости в этой таблице, ее разбивают на ряд подтаблиц так, чтобы каждая из них содержала только одну функциональную зависимость (однозначное отображение). Идея второго метода заключается в том, что в предметной области выделяются характерные объекты и анализируются их семантические взаимосвязи. Информация о каждом таком объекте вместе с его атрибутами и о каждой возможной связи хранится в отдельной таблице. В дипломных проектах, как правило, этап разработки информационной модели предметной области описывается во второй главе пояснительной записки. Ниже приведено рекомендуемое содержание этой главы. 2. Проект АИС данной предметной области. 2.1. Разработка информационной модели. 2.1.1. Разработка инфологической модели. 2.1.2. Разработка датологической модели. 2.2. Обеспечение целостности данных.
Выбор технологии разработки информационной модели во многом определяется типом проектируемой АИС. Обычно при проектировании ИСС используется технология «от запроса» с нормализацией; при разработке АРМов анализ документооборота с нормализацией; при разработке АСУ – технология "сущность-связь". 4.2. Нормализация данных При создании АИС важно разработать хорошую структуру таблиц. Плохая структура приведёт, в лучшем случае, к неэффективности приложения, а в худшем – к невозможности реализации некоторых функций. Хорошо продуманный набор таблиц не только решит все текущие задачи, но поможет их решать в будущем, и, что ещё важнее, значительно сократит время разработки. Реляционная модель базы данных основана на математических принципах теории множеств. Это теория утверждает, что управление данными становится очень простым, если данные организованы согласно всего нескольким правилам. Эти правила стали известными как правила нормализации. Нормализация позволяет полностью избежать избыточности данных и применять стандартные алгоритмы обеспечения их ссылочной целостности. В теории нормализации разработаны подходы к разбиению сложных отношений на несколько более простых. Эта теория лежит в основе метода проектирования логической структуры БД, который принято называть “методом универсального отношения”. Теория детально освещается в специальной литературе, мы рассмотрим лишь практические аспекты нормализации без их теоретического обоснования. Теория нормализации рассматривает семь нормальных форм отношений. Каждая нормальная форма удовлетворяет требованиям предыдущей формы и некоторым дополнительным условиям. На практике, как правило, используются три первых нормальных формы. Поскольку формализм теории нормализации рассмотреть сложно, поэтому выход здесь такой излагать материал на примере из всем понятной предметной области. Рассмотрим упрощенную технологию оформления заказа на товары в фирме по мелкооптовой торговле. В такую фирму приходит представитель другой фирмы (агент) и обращается к менеджеру по продажам. Менеджер в диалоге с агентом оформляет документально заказ на бланке установленной формы. Неопытный разработчик логической структуры базы данных на основе анализа совокупности уже заполненных бланков заказов может все данные из них разместить в одной таблице. Предложим два варианта схемы такой таблицы.
В этом варианте в поле Состав_заказа разработчик предлагает размещать все данные о покупаемых товарах независимо от того, сколько различных товаров предполагается купить. Такой подход очевиден постольку, поскольку реальная практика такова, что независимо от числа покупаемых товаров, данные о всех товарах заносят на один бланк, форма которого специально к этому приспособлена. В поле Состав_заказа в соответствии с бланком предлагается хранить следующие данные: каталожный номер, название товара, количество заказанного и цену за единицу. Анализируя результаты своей работы (таблицу ЗАКАЗ_1), разработчик, вероятно, прейдет к выводу о том, что поле Состав_заказа сильно перегружено и имеет смысл его разделить. Повторно просмотрев выборку бланков заказанных товаров, он обнаруживает, что реальная практика такова, что агенты за один раз не заказывают более трех разновидностей товаров. Приняв за основу этот вывод, разработчик предлагает второй вариант схемы таблицы. ЗАКАЗ_2
При этом объем данных в полях Товар_1 Товар_3 конечно уменьшился, но они по-прежнему включают составные данные. Предложенные варианты таблиц содержат много избыточных данных. Например, сведения о каждом покупателе повторяются многократно, а именно: для каждого сделанного ими заказа. При работе с такой базой данных обязательно возникнут две сложные проблемы.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие:
 | «Учебно-методический комплекс дисциплины «Информационное обеспечение систем управления» | | Пояснительная записка «Современная организация и технология документационного обеспечения управления». Он связан с курсами «Документоведение», «Информационное... |
| Исследование систем управления процесс определения организационной... Место исследований систем управления в комплексе дисциплин по теории и практке управления |  | Программное обеспечение для отладки систем управления упругими объектами Целью данной работы является разработка программного обеспечения для лабораторного стенда для изучения систем управления упругими... |
| Рабочая программа дисциплины «Информационное обеспечение, базы данных» Факультет информационных систем и технологий Кафедра Прикладной математики и вычислительной техники | | Учебная программа по дисциплине " информационное обеспечение управления " Изучение теоретических, методических и практических вопросов разработки, внедрения и совершенствования информационного обеспечения... |
| Российской Федерации Самарский государственный архитектурно-строительный... Информационные системы” являются информационные системы и сети, их математическое, информационное и программное обеспечение, способы... | | Рабочая программа дисциплины «Архитектура ЭВМ и вычислительных систем»... «Автоматизированные системы обработки информации и управления» (по отраслям) и 230105 «Программное обеспечение вычислительной техники... |
| Исследование систем управления Целью работы является рассмотрение частных методов исследования систем управления, а именно эксперимент, наблюдение и опрос | | Примерная тематика рефератов по курсу «Исследование систем управления» Современный менеджмент и необходимость исследования систем управления социально-экономической организацией |
| Организационно-правовое обеспечение правовой деятельности Информационное обеспечение организации и проведения внеучебной работы | | Исследование систем управления Специальности: «Менеджмент организации» «Исследование систем управления» является ведущей,в учебном процессе среди смежных дисциплин |
| Реферат по дисциплине "Избирательное право" тема: Информационное... Информационное обеспечение выборов. Правовое регулирование предвыборной агитации в РФ | | Информационное обеспечение управления В настоящее время классификационные схемы (классификаторы) строятся не только на основе соподчинения понятий (метод иерархии), но... |
| Курсовая работа По дисциплине «Базы данных» Программное обеспечение для создания систем управления базами данных | | Рабочая программа учебной дисциплины «исследование систем управления» Студенты научатся методам планирования эксперимента и организации исследования систем управления и научатся использовать приобретенные... |
