5. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Современные ИС функционируют в различных информационных сетях. Это обстоятельство, а также ряд других оснований вызывают потребность использования распределённых систем. Построение современных распределённых информационных систем на прямую связано с реляционными и объектно-ориентированными СУБД.
Проектирование информационных систем охватывает три основные области:
Существует множество электронных (автоматизированных) информационных систем (баз данных), ориентированных на использование систем управления базами данных (СУБД) и других программ, выполняющих сходные функции.
База данных (БД) – электронное хранилище информации, доступ к которому осуществляется с помощью одного или нескольких компьютеров.
Любая база данных должна обладать способностью к расширению и возможностью обеспечения изменяющихся требований к данным. При этом изменения некоторых параметров проектирования (размер БД, физическое размещение индексов, правила включения, удаления и изменения сегментов и др.) не должны приводить к изменению прикладных программ и реорганизации баз данных. Функционирование такой системной среды осуществляется с помощью СУБД, предназначенной для поиска, обновления, реорганизации, загрузки, сортировки данных и т.п. СУБД работают под управлением операционных систем.
СУБД – программные средства для создания, наполнения, обновления и удаления баз данных.
Концепция баз данных сформировалась к 1960-м годам в процессе автоматизированной обработки информации. БД можно рассматривать как информационную модель объекта. Основное назначение БД заключается в том, чтобы одну и ту же совокупность данных можно использовать для максимального числа приложений.
Процесс проектирования БД включает три самостоятельных этапа: концептуального, логического и физического проектирования (Рис. 5.1).
Рис. 5.1. Этапы процесса проектирования БД.
Задачей концептуального проектирования является определение информационных потребностей организации, а также тех процессов и данных, которые необходимы для обеспечения этих потребностей. Процесс концептуального проектирования начинается с изучения деятельности организации (предпроектное исследование). Вначале определяются цели и задачи организации, анализируются существующие функциональные процессы (планирование, управление, контроль), обеспечивающие достижение этих целей и выполнение поставленных задач. Затем осуществляется разбиение этих процессов на подпроцессы более низкого уровня (административное управление, расчёт заработной платы, сбыт, транспорт и т.д.) до тех пор, пока в результате декомпозиции не будет достигнут уровень приложений и функций, выполнение которых возможно без дальнейшего разбиения. Далее определяются информационные потребности каждого приложения, которые будут автоматизированы, определяются требования к данным. Для достижения этих целей проектировщик должен хорошо представлять характер деятельности организации и производственные процессы, которые необходимо моделировать.
СУБД в зависимости от архитектуры делятся на локальные и распределённые. В локальной СУБД её компоненты размещаются на одном компьютере, а в распределённой – на нескольких, которые могут находиться на любом удалении друг от друга. Основные типы СУБД используют три базовые модели данных: иерархические, сетевые и реляционные.
Первые иерархические и сетевые СУБД появились в начале 1960-х годов в качестве среды и системы управления миллионами записей (связанных друг с другом иерархическим образом).
В иерархической модели отношения данных организованы в виде совокупностей деревьев, где дерево – структура данных, в которой тип сегмента потомка связан только с одним типом сегмента предка. Графически: Предок – точка на конце стрелки, а Потомок – точка на острие стрелки.
В базах данных определено, что точки – это типы записей, а стрелки представляют отношения “один-к-одному” или “один-ко-многим”. Отношение “один-к-одному” возникает, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.
Родительская реляция (таблица) – таблица, поля которой входят в другую таблицу. Дочерняя реляция (таблица) – таблица, поля которой используют информацию из полей другой таблицы, являющейся по отношению к данной родительской.
Рассмотрим пример установки в АИС отношения “один-к-одному” между клиентом и его счётом (рис. 5.2).
Рис. 5.2. Отношение “один-к-одному”.
Отношение “Имеет текущий счёт” представляет связь “один-к-одному”, означающую, что клиент имеет не более одного текущего счёта и что каждым текущим счётом пользуется только один клиент.
Отношение “один-ко-многим” возникает, когда одной записи в родительской таблицы соответствует несколько записей в дочерней таблице. Рассмотрим этот же пример для случая, когда у клиента несколько текущих счетов. Тогда используется отношение “один-ко-многим” (рис. 5.3.).
Рис. 5.3. Отношение “один-ко-многим”.
В этом случае отношение “Имеет текущий счёт” обладает свойством “много”. Это означает, что клиент имеет несколько текущих счетов, при этом каждым текущим счётом по-прежнему пользуется только один клиент.
К недостаткам иерархической модели данных относят:
Сети – естественный способ представления отношений между объектами. Они широко применяются в математике, исследованиях операций, химии, физике, социологии и других областях знаний. Сети можно представить математической структурой, которая называется направленным графом. Направленный граф имеет простую структуру. Он состоит из точек или узлов, соединённых стрелками или ребрами. Моделирование с помощью графов рассмотрено в третьей главе.
В контексте моделей данных узлы можно представить как типы записей данных, а ребра – как отношения “один-к-одному” или “один-ко-многим”. Структура графа делает возможными простые представления иерархических отношений (таких, например, как генеалогические данные).
Сетевая модель данных – это представление данных сетевыми структурами типов записей и связанных отношениями со свойствами “один-к-одному” или “один-ко-многим”.
В сетевой модели существует две основные структуры данных: типы записей и наборы (Табл. 1).
Таблица 1.
Тип записей | Совокупность логически связанных элементов данных |
Набор | отношение “один-ко-многим” между двумя типами записей. |
Простая сеть | Структура данных, в которой все бинарные отношения имеют мощность “один-ко-многим”. |
Сложная сеть | Структура данных, в которой одно или несколько бинарных отношений имеют мощность “многие-ко-многим”. |
Тип записи связи | Формальная запись, созданная для того, чтобы преобразовать сложную сеть в эквивалентную ей простую сеть. |
Отношение “многие-ко-многим” возникает, когда многим записям в родительской таблицы соответствуют несколько записей в дочерней таблице. Для рассматриваемого случая отношение “Имеет текущий счёт” обладающее свойством “многие-ко-многим” (рис. 5.4) означает, что у одного клиента может быть несколько текущих счетов, и что каждым из них могут пользоваться несколько клиентов.
Рис. 5.4. Отношение “многие ко многим”.
Для преобразования отношения “многие-ко-многим” целесообразно создать таблицу пересечения, представляющую элементы двух других таблиц, находящихся в отношении “многие-ко-многим”.
Концептуальная модель данных преобразуется в реляционную модель данных (данных, связанных между собой определёнными отношениями).
Реляция (таблица – элементарная информационная единица) – двумерная таблица, содержащая строки и столбцы данных. Реляционная модель данных организует и представляет данные в виде таблиц или отношений между ними.
Существует два подхода к проектированию реляционной базы данных.
Первый подход заключается в том, что на этапе концептуального проектирования создаётся не концептуальная модель данных, а непосредственно реляционная схема базы данных, состоящая из определений реляционных таблиц, подвергающихся нормализации.
Второй подход основан на механическом преобразовании функциональной модели, созданной ранее, в нормализованную реляционную модель. Он часто используется при проектировании больших, сложных схем баз данных, необходимых для корпоративных информационных систем.
На первом этапе разработки базы данных необходимо определить её назначение и как она будет использоваться. Разработчики должны провести эту работу совместно с будущими пользователями БД. Вместе с ними сформулировать вопросы, ответы на которые пользователи хотят получать с помощью БД, создать формы для ввода данных, запросов и эскизы отчётов, которые пользователи хотели бы получать. Одновременно следует выявить перечень необходимых данных и их характеристики. Зная это, можно определить, какие фактические данные следует сохранять в БД, по каким темам распределять эти данные и др.
Темам должны соответствовать таблицы, а данным – поля (столбцы) в этих таблицах.
Данные в реляционных СУБД сохраняют в таблицах, причём каждая таблица должна содержать информацию одного типа, например, сведения о заказчиках. Тогда достаточно будет обновить конкретные данные, такие как адрес, только в одном месте, чтобы обновленная информация отображалась во всей базе данных. Широкое распространение получила СУБД, Access, разработанная корпорацией Microsoft и входящая обычно в состав пакета прикладных программ Microsoft Office.