Содержание
I. Понятие информационной системы
II. Понятие распределенных системIII. Информационная база проекта
IV. Моделирование потоков данных
I. Понятие информационной системы
Система – это сложный объект, состоящий из взаимосвязанных частей (элементов) и существующий как единое целое.
Подсистема – это часть системы, выделенная по какому-либо признаку.
Информационная система - взаимосвязанная совокупность средств, методов и персонала, используемая для сбора, сохранения, обработки и выдачи информации с целью решения конкретной задачи.
Современное понимание информационной системы предполагает использование в качестве основного технического средства переработки информации персонального компьютера (сервера, периферийного оборудования и т.д.).
Необходимо понимать разницу между компьютерами и информационными системами. Компьютеры, оснащенные специализированными программными средствами, являются технической базой и инструментом для информационных систем. Информационная система немыслима без персонала, взаимодействующего с компьютерами и телекоммуникациями.
Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами.
Итак, подсистема – это часть системы, выделенная по какому-либо признаку.
Общую структуру информационной системы можно рассматривать как совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации, а подсистемы называют обеспечивающими. Таким образом, структура любой информационной системы может быть представлена совокупностью обеспечивающих подсистем.
Информационное обеспечение – совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем информационных потоков, циркулирующих в организации, а также методология построения баз данных.
Техническое обеспечение – комплекс технических средств, предназначенных для работы информационной системы, а также соответствующая документация на эти средства и технологические процессы.
Математическое и программное обеспечение – совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач информационной системы, а также нормального функционирования комплекса технических средств.
Организационное обеспечение – совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации информационной системы.
Правовое обеспечение – совокупность правовых норм, определяющих создание, юридический статус и функционирование информационных систем, регламентирующих порядок получения, преобразования и использования информации.
В зависимости от степени автоматизации информационных процессов ИС определяются как: ручные, автоматические, автоматизированные.
Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.
Автоматические ИС выполняют все операции по переработке информации без участия человека.
Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль отводится компьютеру. В современном толковании в термин «информационная система» вкладывается обязательно понятие автоматизируемой системы.
ИС по характеру использования информации
Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. Например, информационно-поисковая система в библиотеке, в железнодорожных и авиакассах продажи билетов.
Информационно-решающие системы осуществляют все операции переработки информации по определенному алгоритму. Среди них можно провести классификацию по степени воздействия выработанной результатной информации на процесс принятия решений и выделить два класса: управляющие и советующие.
Управляющие ИС вырабатывают информацию, на основании которой человек принимает решение. Для этих систем характерны тип задач расчетного характера и обработка больших объемов данных. Примером может служить система бухгалтерского учета.
Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и не превращается немедленно в серию конкретных действий. Эти системы обладают более высокой степенью интеллекта, так как для них характерна обработка знаний, а не данных.
Например. Существуют медицинские информационные системы для постановки диагноза больного и определения предполагаемой процедуры лечения. Врач при работе с подобной системой может принять к сведению полученную информацию, но предложить иное по сравнению с рекомендуемым решение.
ИС по сфере применения
ИС управления технологическими процессами (ТП) служат для автоматизации функций производственного персонала.
ИС автоматизированного проектирования (САПР) предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов.
Интегрированные (корпоративные) ИС используются для автоматизации всех функций организации и охватывают весь цикл работ.
ИС по архитектуре
Локальные ИС - это системы, работающие на отдельном компьютере без взаимодействия с сервером.
Распределенные ИС - совокупность взаимодействующих друг с другом программных компонент. Каждая из них может рассматриваться как программный модуль (приложение), исполняемый в рамках отдельного процесса.
Информационная база (ИБ) - это определенным способом организованная совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач.
Существуют следующие способы организации ИБ:
- совокупность локальных файлов, поддерживаемых функциональными пакетами прикладных программ;
- интегрированная база данных, основывающаяся на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, то есть системы управления базами данных (СУБД).
Локальные файлы вследствие специализации структуры данных под задачи обеспечивают, как правило, более быстрое время обработки данных. Однако недостатки организации локальных файлов, связанные с большим дублированием данных в информационной системе и, как следствие, несогласованностью данных в разных приложениях, а также негибкостью доступа к информации, перекрывают указанные преимущества. Поэтому организация локальных файлов может применяться только в специализированных приложениях, требующих очень высокую скорость реакции, при импорте необходимых данных их интегрированной ИБ.
База данных (БД) — это совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы и отражающих состояние и взаимодействие объектов в определенной предметной области.
База данных является компьютерной информационной моделью некоторой реальной системы. Например, книжного фонда библиотеки, кадрового состава предприятия, учебного процесса в школе и т. д. Такую систему называют предметной областью базы данных и информационной системы, в которую БД входит.
Описание структуры данных, хранимых в БД, называется моделью представления данных или короче — моделью данных. В теории БД известны три классические модели данных: иерархическая, сетевая и реляционная (табличная).
Иерархическая модель данных — это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами (в программировании применительно к структуре данных дерево устоялось название братья).
Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента — это поименованная совокупность входящих в него типов полей данных.
Иерархическая модель представляет собой связный неориентированный граф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев.
(из лекций Проф. Дубова И.Р. Базы данных)
Сетевая модель данных — логическая модель данных, являющаяся расширением иерархического подхода, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в сетевых базах данных.
Разница между иерархической моделью данных и сетевой состоит в том, что в иерархических структурах запись-потомок должна иметь в точности одного предка, а в сетевой структуре данных у потомка может иметься любое число предков.
Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная база данных – это набор данных с предопределенными связями между ними. Эти данные организованны в виде набора таблиц, состоящих из столбцов и строк. В таблицах хранится информация об объектах, представленных в базе данных. В каждом столбце таблицы хранится определенный тип данных, в каждой ячейке – значение атрибута. Каждая стока таблицы представляет собой набор связанных значений, относящихся к одному объекту или сущности. Каждая строка в таблице может быть помечена уникальным идентификатором, называемым первичным ключом, а строки из нескольких таблиц могут быть связаны с помощью внешних ключей. К этим данным можно получить доступ многими способами, и при этом реорганизовывать таблицы БД не требуется.
Основные этапы проектирования баз данных
1. Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов или понятий предметной области и связей между ними.
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
2. Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
3. Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
4. Нормализация – приведение базы данных к нормальной форме. Обязательна для реляционных баз данных.
Включает в себя:
- исключение некоторых типов избыточности;
- устранение некоторых аномалий обновления;
- разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
- упрощение процедуры применения необходимых ограничений целостности.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с указанным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации.
Состав диаграмм потоков данных
Основными компонентами диаграмм потоков данных являются:
- внешние сущности;
- системы и подсистемы;
- процессы;
- накопители данных;
- потоки данных.
Внешняя сущность представляет собой материальный объект или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой системы.
Внешняя сущность обозначается прямоугольником, расположенным над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Процесс на диаграмме потоков данных изображается, как показано на рисунке ниже.
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: «Ввести данные», «Вывод отчета», «Проверить поступление денег».
Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рисунке ниже.
Накопитель данных идентифицируется номером. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей БД, и описание хранящихся в нем данных должно соответствовать модели данных.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока.
Каждый поток данных имеет имя, отражающее его содержание.
Построение иерархии диаграмм потоков данных
Главная цель построения иерархии DFD состоит в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
- Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
- Не загромождать диаграммы несущественными на данном уровне деталями.
- Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой.
- Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Число потоков на контекстной диаграмме должно быть, по возможности, небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы.
Для проверки контекстной диаграммы можно составить список событий. Этот список должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному или более потокам данных: входные потоки интерпретируются как воздействия, а выходные потоки — как реакции системы на входные потоки.
Для сложных систем (признаками сложности могут быть наличие большого числа внешних сущностей (10 и более), распределенная природа системы или ее многофункциональность) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать построением диаграммы для каждого события. Оно представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации.
Пример построения диаграммы потоков данных
Перед тем, как приступить к построению DFD-диаграммы, вспомним пример построения декомпозиции диаграммы IDEF0, рассмотренной в п. 2.4. (смотри рис. ниже).
В данном примере показана декомпозиция процесса "Продать товар". В качестве предметной области рассматривается склад оптовой торговли.
Диаграмма IDEF0 показывает комплексное видение всего глобального процесса, который в себя включает подпроцессы, которые связаны с информационно системой напрямую и которые не связаны с ней. Информационные процессы, связанные с информационной системой напрямую, полезно декомпозировать в нотации DFD.
Выполним декомпозицию процесса "Оформить товарно-транспортную накладную" в нотации DFD.
Данная диаграмма показывает множество операций для выполнения глобальной операции "Оформить товарно-транспортную накладную". Каждая операция пронумерована, указывая на последовательность выполняемых действий. Также на диаграмме показаны накопители данных, указывающие с какими информационными хранилищами связан процесс.
Логическая модель данных разрабатывается на основе существующих моделей данных (например, реляционной), но никак не связана с конкретной реализацией системы управления базы данных (СУБД) и прочих физических условий реализации. Она может быть построена на основе другой логической модели, например, на основе модели потоков данных или процессов.
Логическая модель данных является источником информации для фазы физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения.
Физическая модель данных, напротив, зависит от конкретной СУБД фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
- диаграмма сущность-связь (Entity Relationship Diagram, ERD);
- модель данных, основанная на ключах (Key Based model, KB);
- полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к информационным системам (ИС).Диаграмма ERD может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Основные компоненты диаграммы ERD – это сущности, атрибуты и связи. Сущность можно определить как объект, событие или концепцию, информация о которой должна сохраняться.
Сущности должны иметь наименование с четким смысловым значением, фактически это имя ее экземпляра. Например, сущность Заказчик с атрибутами Номер заказчика, Фамилия заказчика, Адрес заказчика.
Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Каждый атрибут должен быть определен, при этом следует избегать циклических определений и производных атрибутов. Для атрибутов первичного ключа (это атрибут или группа атрибутов, идентифицирующая сущность) необходимо сделать пометку PK (Primary Key).
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи облегчает чтение диаграммы.
На логическом уровне можно установить идентифицирующую связь один-комногим, связь многие-ко-многим и неидентифицирующую связь один-комногим. Тип сущности определяется ее связью с другими сущностями. Различают зависимые и независимые сущности. Зависимая сущность изображается прямоугольником со скругленными углами. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.
При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности и помечается в дочерней сущности как внешний ключ (FK).
Нотация "сущность-связь" Баркера
Свою нотацию для изображения структур данных Ричард Баркер (RichardBarker) предложил в 1986г., работая в собственной консалтинговой фирме, которая позднее присоединилась к корпорации Oracle. Его нотация диаграмм «сущность-связь» до сих пор является основной нотацией для разработки баз данных в СУБД Oracle с помощью специального пакета Designer.
Сущность в нотации Баркера изображается в виде прямоугольника со скругленными углами, внутри которого указывается имя сущности и атрибуты. Наряду с основным именем для сущности могут использоваться синонимы, отделяемые от основного имени наклонной чертой. Ниже имени в столбик перечисляются атрибуты. Название каждого атрибута сопровождается специальным символом:
- буквой О (optional, необязательный) – для атрибутов, значения которых могут отсутствовать (т.е. быть равными NULL);
- символом «*»для атрибутов, значения которых обязательно должны быть указаны;
- символом «#»для атрибутов, входящих в состав первичного ключа.
Рисунок. Диаграмма «сущность-связь» в нотации Баркера
Связи в нотации Баркера показываются линией, имеющей две метки-названия. Так, в показанном примере студент изучает дисциплину, а дисциплина преподается для студента. Мощность связи изображается с помощью символов на конце линии:
« ––– » – одинарная прямая линия означает, что связь с этой стороны имеет мощность «один»;
«
» – символ «воронья лапка» означает мощность «много» (линия связи как бы разветвляется в месте соприкосновения с сущностью).
» – символ «воронья лапка» означает мощность «много» (линия связи как бы разветвляется в месте соприкосновения с сущностью).Полнота связи указывается начертанием линии: сплошная линия означает, что связь с противоположной стороны является полной, а пунктирная линия обозначает неполную связь.
Для изображения отношения категорий в нотации Баркера предусмотрено вложение сущностей друг в друга. При этом сущности-категории наследуют атрибуты обобщенной сущности, а каждая из этих трех сущностей может быть участником связи.
Рисунок. Категориальное отношение
B нотации Баркера имеется одна интересная возможность – так называемая «исключающая связь». Эта связь используется, когда необходимо реализовать отношение «либо …,либо …» между основной сущностью и сущностями-категориями. B примере на рисунке каждый счет в банке открывается только одному клиенту – либо физическому, либо юридическому лицу. При этом человек или организация могут иметь несколько счетов в этом банке, а могут вообще не иметь их. Категориальная связь является частным случаем исключающей связи при условии, что отношения имеют мощность 1:1 и являются полными со стороны сущностей-категорий.
Рисунок. Исключающая связь
Источники:
- Классификация ИС
- Локальные ИС
- Моделирование потоков данных
- Пример диаграммы потоков данных
- Алонцева Е.Н., Анохин А.Н., Саакян С.П. Структурное моделирование процессов и систем. Учебное пособие по курсу «CASEи CALS технология».–Обнинск: ИАТЭ НИЯУ МИФИ,2015.–72c.
