Книга I - Обзор системы Miracle
(Общие сведения, часть №03)

Miracle - среда по разработке и управлению базой данных

  Современная информационная система обязана предоставить пользователю доступ ко всей необходимой информации для его бизнеса. Обеспечение этого требования зависит от выбранного механизма подготовки и предоставления данных. Основа информационной системы, строящаяся с использованием Miracle - это информация. Приложения не играют первостепенной роли - главное содержание. В рамках системы Miracle отдел информационных технологий становится главным концентратором корпоративной информации. Предоставляя пользователям данные в необходимом виде, осуществляя поддержку методов доступа к информации, правила ее обработки и хранения. Главное отличие современного информационного отдела - это изменение его сути как центра по обслуживанию приложения (программ), на центр для удовлетворения информационной нужды предприятия. Такой подход делает не целесообразным приобретение подготовленного решения и требует использования новой технологии по созданию и поддержки информационных систем. Основа нового подхода - масштабное мышление, когда разработчикам необходимо выходить за рамки приложения, и проектировать программы для работы в едином информационном пространстве.

Что такое базы данных

  В самом общем смысле БД (база данных) - это набор таблиц, записей или файлов, которые организованы специальным образом. Используя свой компьютер, Вы, например, могли бы хранить адреса и фамилии всех своих друзей, или все письма, или иные деловые бумаги. При этом, все эти данные, могли бы быть сгруппированы по каким либо признакам, например, по адресам.
Как правило все файлы группируются в специализированной структуре каталогов и подкаталогов. Те, кто из вас часто используют, например, текстовый редактор, знают, как порой бывает сложно отыскать нужный файл среди уже имеющихся в структуре. Пока вы это делаете без применения каких либо специализированных средств, вы являетесь диспетчером БД.

Рисунок 10 Пример организации каталогов в файловой системе

  Но, что делать, когда решаемая вами задача должна обрабатывать большое количество разнообразной информации? Как собрать данные по отдельным критериям, разбросанным по различным файлам и имеющим различную структуру? Как сохранить связь между информацией в различных файлах, при вводе новых значений их модификации или удалении? При этом, необходимо иметь гарантию, что все значения вводятся правильно, согласно единым принципам обработки. Следует так же не забывать, что одна и та же информация может быть необходима одновременно нескольким пользователям. При этом вы должны быть уверены в однозначности всех данных, редактируемых одновременно ими. Как только у вас возникли такие проблемы, вам необходимо применять специализированные системы управления базами данных (СУБД).
  Основа этих систем - организация хранения информации. Для работы с данными так же необходим специализированный пользовательский интерфейс, а для обработки значений в этих БД - механизм для описания математических действий над данными. Поэтому в свою очередь СУБД - это организованное специальным образом хранилище данных, а также минимальные механизмы для ввода, вывода и обработки информации. Методология организации хранения данных может быть различной, одна из них - реляционный метод хранения.

Реляционные базы данных

  В настоящее время почти все системы управления базами данных основаны на реляционной модели (relational). Название “реляционная” связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся (related) только к одному объекту. Кроме того, с данными двух различных типов (например, фамилия и зарплата), можно работать как с единым целым, основанным на значениях между собой данных. Например, если включить фамилию и сумму зарплаты в каждую ведомость, то это привело бы к хранению повторяющейся информации. Поэтому в реляционной системе, информация о зарплате содержит поле данных, куда вводится код фамилии сотрудника, по которому эти данные объединяются в единое целое.

Рисунок 11 - Пример реляционной модели

  Учетный объект (таблица) - основной элемент реляционной модели данных. Каждая таблица фактически является частным случаем понятия, известного в математике как отношение.

Нормализация баз данных

  При разработке структуры базы данных важным процессом является нормализация. Под этим понимается правильное распределение подлежащих хранению данных по различным таблицам, из которых будет состоять БД. Существуют строгие математические определения того, что такое, когда набор таблиц находится в той или иной нормальной форме. Но дело в том, что при определенном навыке, человек чисто интуитивно способен создавать нормализованные базы данных.
  Главной проблемой, которую необходимо решать при нормализации БД - это избыточность спроектированного набора таблиц. Например, если в БД предполагается хранить информацию о клиентах вашей фирмы и о выписываемых им счетах, то если разместить информацию о клиенте и о счете в одной таблице, получится избыточность значений.

Рисунок 12 - Пример таблицы имеющей избыточные значения

  Дело в том, что если на одного клиента может быть выписано несколько счетов, тогда в таблице придется завести несколько строчек, в каждой из которых занести информацию о счете, но кроме того, в каждую строчку придется занести информацию и о клиенте. (см. Рисунок 12 - Пример таблицы имеющей избыточные значения). Таким образом одна и та же информация (о клиенте) присутствует в таблице несколько раз. Это в свою очередь вызывает ряд проблем:

  • Во-первых, так называемая аномалия вставки. То есть вы не сможете ввести в БД информацию о клиенте, если на него не выписано ни одного счета. Если вы все же введете в таблицу строчку с информацией о клиенте, а те поля таблицы, которые предназначены для хранения информации о счете оставите пустыми, то при обработке такой таблицы могут возникнуть определенные проблемы.

Рисунок 13 - Таблица с "аномальной" вставкой

  Например, на запрос распечатать все счета этого клиента вам будет выдана одна пустая запись. Таким образом, Вы будете обмануты, поскольку счетов на данного клиента не было выписано, Вам выдали в качестве результата одну запись, хотя и пустую. (см. Рисунок 13 - Таблица с "аномальной" вставкой).

  • Во-вторых, аномалия редактирования. Если у вас в таблице заведено на одного клиента несколько счетов, то и информация о клиенте введена в таблицу несколько раз - по одному разу на каждый счет. Если понадобится изменить какую то информацию о клиенте, например, его реквизиты, то это придется делать во всех записях, в которых введена информация об этом клиенте.

Рисунок 14 Таблица с “аномалией редактирования”

  Если сделать это только в одной записи, то возникнет неоднозначность хранимой в БД информации - нарушится ее целостность.

Рисунок 15

  • В-третьих, аномалия удаления. При удалении информации о выписанных счетах, когда удаляется запись о последнем счете, выписанном на какого-то клиента, то одновременно с этим удаляется и упоминание о самом клиенте - информация о нем перестает существовать в данной таблице.

Рисунок 16

  Все эти проблемы надо иметь ввиду, когда проектируется БД. База данных, в той или иной степени избавленная от этих проблем, называется нормализованной, то есть находится в той или иной нормальной форме. Математики определяют 5 разных нормальных форм. Для большинства реальных применений вполне подходит третья нормальная форма. Условно говоря, это такое распределение информации по таблицам, при котором не возникает вышеперечисленных проблем.
  В приведенном примере от всех проблем можно легко избавиться, если разнести информацию о клиентах и счетах в разные таблицы.

Рисунок 17 Пример декомпозиции таблиц БД

  Процесс разделения одной таблицы на две и более, называется декомпозицией. В одну таблицу теперь вводится вся информация о клиентах, в другую - о счетах. Это позволит вводить информацию о клиентах, не вводя информацию о счетах, и удалять счета, не боясь удалить информацию о клиенте. Осталось придумать способ, при помощи которого можно бы было узнать, на какого клиента выписан конкретный счет из таблицы счетов.
  Для этого в таблицу с клиентами надо добавить поле-идентификатор клиента. Это может быть некое числовое поле. Некоторые системы поддерживают такие поля автоматически (то есть придумывают и заносят уникальное значение в это поле каждый раз, когда вы добавляете в таблицу новую запись. Конструктор базы данных системы Miracle делает эту работу с использованием специальных полей, и Вам надо лишь указать поле - ссылку на необходимую таблицу, проектируя объекты (таблицы).

Рисунок 18 Пример таблицы содержащей дополнительное поле-идентификатор отношений.

  В таблицу со счетами добавляется поле, в котором будет храниться идентификатор клиента, на которого выписан конкретный счет. Таким образом, информация о клиенте заносится в таблицу клиентов один раз, а во все счета, которые заносятся в таблицу счетов, в поле, идентифицирующее клиента, на которого выписан счет, все время заносится одно и то же значение, если счета действительно выписываются на одного и того же клиента.

Рисунок 19 Пример отношений информации из различных таблиц.

  И если понадобится изменить какую-либо информацию о клиенте, то это необходимо произвести только в одной записи в таблице клиентов. Поскольку идентификатор клиента останется неизменным, то все счета, ссылающиеся на этого клиента, продолжат на него ссылаться и после изменения каких-либо деталей информации о клиенте.

Рисунок 20 Пример демонстрирующий не нарушение целостности при модификации данных.

  Принцип, позволяющий строить правильные БД, называется сущность - связь. При таком подходе важно выделить сущности, требующие учета в вашей БД, и каждой из этих сущностей выделить одну таблицу. Затем, при помощи полей - идентификаторов и полей, обеспечивающих ссылки из одной таблицы к записям в других таблицах, наладить связи между выявленными сущностями.

Рисунок 21 Пример физической модели сущностей

  Сущность - это как правило реальный документ, или часть документа, реальное лицо, предмет или действие, которое требует учета в вашей БД. Отдельной сущностью может быть платежное поручение, выписка из банка, ваш клиент, товар на складе, акт отгрузки товара, факт приема товара на склад, факт снятия денег с расчетного счета, ваша встреча с партнером, сам партнер. То есть все то, информацию о чем можно выписать в одну строчку (или занести в одну запись одной таблицы), и при этом что бы можно было сразу и единовременно заполнить все поля записи о конкретном экземпляре данной сущности.
  Другими словами, сущность должна быть неделимой. Необходимо, чтобы любое подмножество полей из всего набора полей, описывающих сущность, было бессмысленно в отрыве от остальных полей. Разумеется “бессмысленность” эта весьма условна и должна оцениваться с точки зрения конечной цели проектирования конкретной БД. Например, для Вас информация о номере расчетного счета вашего клиента и то, в каком банке открыт этот расчетный счет, может оказаться неделимой. Действительно, Вы не сможете отправить деньги на расчетный счет, если не знаете банк, где этот расчетный счет открыт, и не можете отправить деньги просто в банк, не указав номера расчетного счета.
  Если же у Вас с одной стороны много клиентов, многие из которых имеют расчетные счета в одних и тех же банках, и, кроме того, Вам необходимо хранить в БД расширенный набор информации о банках ваших клиентов (не только название и адрес, а, например, еще и подробную информацию об истории открытия и развития банка), то информация о расчетном счете клиента и банка требует разделения. То есть вместо одной сущности клиент - расчетный_счет-банк появляется две сущности: клиент - расчетный_счет и банк. И между этими сущностями устанавливается связь.
  Связи между сущностями бывают различных типов. Различаются связи прежде всего по тому, сколько экземпляров может быть вовлечено в одну конкретную связь с каждой стороны. Например, продавая клиенту товар или оказывая ему услуги, Вы можете выписать одному клиенту несколько счетов. Но при этом, Вы не можете выписать один счет на несколько клиентов. Такая связь называется 1-n, то есть 1 клиент - n счетов.

Рисунок 22 Пример связи 1-n

  Бывают также связи типа 1-1 и m-n. Если вы разделите информацию о клиенте и информацию о его расчетном счете в две разные сущности, то связь между этими сущностями будет типа 1-1. А если вы учитываете продаваемый вами товар и клиентов, которым вы его продали, то связь между сущностями товар и клиент будет m-n, так как один и тот же товар может быть продан нескольким клиентам, а один и тот же клиент может купить много разных товаров.

Рисунок 23 Пример связи m-n

  В случае связей типа 1-1 и 1-n, физически их реализацию можно осуществить при помощи полей - идентификаторов и полей - ссылок, как это было описано выше. Связь типа m-n в такую конструкцию не укладывается. Дело в том, что сама связь такого рода представляет из себя отдельную сущность. В случае с клиентом и проданным товаром имеет место сущность - акт_продажи. То есть вам необходимо завести отдельную таблицу с двумя полями: идентификатор проданного товара и идентификатор клиента, которому этот товар был продан. В принципе можно добавить еще и поля о дате и времени совершения продажи, и даже о том, кто из ваших сотрудников был продавцом в данном конкретном случае. Сущность акт_продажи в результате будет иметь две основных связи типа n-1: одну связь с клиентами и одну связь с товарами.

Рисунок 24 Пример разрешения связи m-n

  Кроме количественных характеристик, связи отличаются еще и по тому, насколько обязательно каждая из сторон обязана быть вовлечена в связь. В случае с клиентом и выписываемыми ему счетами, счета обязаны быть связаны с клиентами, но могут существовать клиенты, которые не имеют связи со счетами (точнее - может не быть счетов, связанных с кем-то из клиентов). Таким образом принадлежность счета связи - обязательная, а принадлежность клиента связи - необязательная.
  Если связь типа 1-1 и принадлежность обеих сторон обязательная, то это говорит о том, что сущности неразделимы и их существование друг без друга бессмысленно. Таким образом, это на самом деле одна сущность и для их хранения нужна одна таблица.
  Если связь типа 1-1 и принадлежность одной из сторон обязательная, а другой необязательная, то необходимо две таблицы и в той таблице, где принадлежность обязательная, нужно завести поле - ссылку на записи в другой таблице.
  Если связь типа 1-1 и принадлежность обеих сторон необязательная, то в принципе необходимо заводить отдельные таблицы для каждой из сущностей и отдельную таблицу для наведения связи. Необходимость в третьей таблице возникает исходя из принципа недопущения возможности наличия в таблице полей, незаполненных информацией. То есть, если реализовать связь, заведя поле - ссылку в одной из таблиц, соответствующей сущностям, вовлеченным в связь, то эта сущность будет обязана быть всегда вовлечена в связь, так как внося запись об экземпляре этой сущности, мы будем вынуждены заполнить поле - ссылку некоторым значением. Но, поскольку третья таблица вызывает значительные неудобства при использовании такой БД, то часто разрешают заносить в поля - ссылки специальные “пустые” значения, говорящие об отсутствии связи в конкретном случае.
  В случае связи типа 1-n, поле - ссылку необходимо заводить в таблице, которая соответствует сущности, которая может быть многократно вовлечена в связь. Если принадлежность этой сущности необязательная, то, по идее, информацию о связи надо выносить в третью таблицу, но часто этого не делают по причинам, описанным выше. Связь типа m-n можно реализовать только при помощи третьей таблицы.
  Подводя итог, надо отметить, что процесс нормализации - процесс в основном творческий, хотя и есть ряд рекомендаций, принципов и идей, которые нужно учитывать, определяя количество и содержание таблиц вашей БД. Если описать все вышеизложенное в двух словах, то две основных идеи - это избежать дублирования, и избежать пустот. И, естественно, преследуя любую из этих целей, необходимо знать меру и следить за тем, чтобы сложность полученной структуры БД не начала превышать выгоды, получаемые от достигнутой “правильности” разработанной структуры.

Возможности СУБД

  Система управления базами данных позволяет контролировать задание структуры и описание свойств данных, работу и организацию коллективного пользования ими.
  СУБД включает в себя три основных функции:

  1. Задание структуры хранения информации и описание ее характеристик.
  2. Обработка данных.
  3. Управление данных.

  Применение системы Miracle, позволяет значительно повысить эффективность СУБД, за счет дополнительных свойств, предоставленных в различных компонентах системы.
  В качестве СУБД, система Miracle может использовать SQL - сервера:

  1. InterBase v.4.0 (Borland);
  2. SQL Server (Microsoft);
  3. Informix (Informix); (планируется)
  4. SyBase (SyBase);
  5. Oracle (Oracle); (планируется)
  6. Эти и иные БД, подключаемые через драйвер ODBC;

Что такое SQL

  SQL - это стандартный язык запросов к базе данных. Язык SQL появился в середине 70-х годов. Исходное название языка SEQUEL (Structured English Query Language), отражает тот факт, что язык был ориентирован главным образом на удобные и понятные пользователю формулировки запроса к реляционным базам данных. Подъязык запросов SQL предоставляет возможность простого формулирования запросов к соединениям нескольких таблиц и использование вложенных подзапросов. Существенная особенность SQL - это возможность указания группирования таблицы - результата по заданным полям с поддержкой условий выборки всей группы целиком. Такие условия выборки могут содержать агрегатные функции, вычисляемые на группе. Самый общий вид запроса на языке SQL представляет собой теоретико-множественное алгебраическое выражение, составленное из элементарных запросов. SQL сервер баз данных управляет запросами в логических единицах так называемыми транзакциями. Транзакция - группа реляционных связанных операций, которые должны выполняться полностью перед тем, как СУБД окончательно внесет изменения в базу данных. В SQL все транзакции должны быть явно законченные, либо с совершением заданных изменений, либо их отмена. Первоначально SQL было разработано для проекта разработки экспериментальной реляционной СУБД с индексом Р. Сейчас он реализован практически во всех реляционных СУБД. Одновременно с появлением коммерческой реализации SQL, началась деятельность по его стандартизации. Было последовательно разработано несколько стандартов SQL.
  SQL имеет много преимуществ как средство для управления реляционными базами данных, и поддерживается многими производителями. Программа SQL применима почти для всех серверов Вашей сети. Единственное требование состоит в том, что коммуникационное оборудование любого конечного пользователя использовало один диалект SQL.
  Система Miracle - предоставляет оригинальный и удобный механизм построения SQL-предложений, позволяющий неподготовленному пользователю самостоятельно и просто указывать критерии выборки и т.д.

Что такое инструменты быстрой разработки приложений

  Разработку программного обеспечения возможно вести различными способами. Один из них - “каскадный” метод. В его рамках производят последовательное выполнение определенных этапов, итоги каждого из которых являются основой для удачного решения на последующих этапах. Первый (основной этап), это формализация задачи. В его рамках необходимо четко предусмотреть все нужные функции и свойства будущей системы, с тем, чтобы на последующих этапах разработки не возникло бы проблем, связанных с неполной формализацией получаемых решений. Последующие же этапы включают в себя этапы непосредственного кодирования, тестирования и эксплуатации. Использование каскадного метода позволяет получать достаточно удачные и оптимальные решения при первичной (идеальной) формализации задачи. Такой подход сложно применять к задачам, формализация которых затруднена на первый момент, или решения которых могут меняться с течением времени, даже в период пробной эксплуатации задачи. Использование “каскадного” метода для решения слабо формализованных задач, приводит к лишним затратам, так как вынуждает производить перепрограммирование всей системы в целом или отдельных ее крупных компонентов, что служит дополнительным фактором увеличения затрат на разработку, модификацию и поддержку информационной системы.
  Альтернативный метод проектирования приложений - метод быстрой разработки. Область применения этой методики - это как правило автоматизация делопроизводства, финансово-экономические задачи, учет, контроль производства. Т.е. те области человеческой деятельности, где решения явны на уровне интерфейса, “экранных форм”.
  Как правило RAD инструмент используют для разработки ИС, когда заказчик не в состоянии четко и полно определить все требования к разрабатываемой системе, или предусмотреть все необходимые функции просто не возможно. Еще раз повторим, что логика работы информационной системы, разрабатываемой в рамках данного метода, должна четко просматриваться на уровне интерфейса.

Рекомендации по организации работы группы разработчиков

  Разработка информационной системы требует определенного времени. Так сроки выполнения достаточно сложных информационных систем не должны превышать 3-х - 6-ти месяцев. При разработке системы, требующей большего времени, необходимо перепланировать функции по срокам выполнения в несколько блоков, реализация каждого из которых не должна превышать 2-3 месяца. Рабочая группа, занимающаяся разработкой системы, должна включать в себя 4-6 человек, среди которых 2-3 человека - это представители заказчика (эксперты), являющиеся будущими пользователями. Часть группы людей заказчика должны являться постоянными участниками группы, а часть людей привлекаться только на определенный момент разработки. На фирме, для которой разрабатывается информационная система, необходимо определить группу пользователей и организовать их участие в разработке (на уровне консультации, тестирования, анализа функций и т.д). При этом надо заметить, что рабочей группе должны быть предоставлены права для самостоятельного принятия решений по разрешению ситуаций выбора порядка реализации компонентов системы и сроков их выполнения, с тем, чтобы уложиться в установленный график работ.
  Примерные этапы разработки системы с использованием RAD инструмента:

  1. Разработка первой версии решений (приложений) согласно установленных сроков;
  2. Работа с приложениями, тестирование;
  3. Доработка (в интерактивном режиме);
  4. Передача в эксплуатацию доработанных приложений.

Структура системы Miracle, принципы

  Основной принцип работы системы Miracle - полное визуальное управление всеми процессами, от проектировки оконных форм, отчетов компоновки приложения, управления свойствами и событиями компонентов, моделирование математических алгоритмов обработки информации, управление уровнем доступа пользователей к информации и программным решениям. Разработка ресурсов информационной системы производится различными инструментальными средствами:
  проектировка ресурсов, отладка приложений:

  1. Конструктор базы данных - Miracle dBase Constructor,
  2. Генератор оконных форм - Miracle Form Generator,
  3. Генератор приложений (решений) - Miracle Task Generator,
  4. Конструктор алгоритмов - Miracle Mathimatic;
  5. Конструктор отчетов - Miracle Report.

  предоставление решений пользователям:

  1. Сервер управления - Miracle Base Program,
  2. Miracle Web сервер - Miracle WEB Server

  доступ к решениям:

  1. Менеджер приложений - Miracle Manager,

  тиражирование Miracle - решений:

  1. Экспорт, импорт пользовательских решений (приложений) - Miracle Migration;

  сервер доступа к базе данных:

  1. монитор транзакций - Miracle Monitor Transaction.

  Система Miracle состоит из самостоятельных компонентов, которые могут быть неоднократно использованы для различных целей. Каждый компонент является целостным, т.е. не изменяемый во времени, и может быть использован как для установки отношения с другими компонентами системы так и для организации информационного обмена. Допуск к приложениям, ресурсам системы основывается на структурной схеме допусков, (иерархической модели).

Обозначения

  Структура допусков - организация допуска пользователей к ресурсам ИС. (Сервер управления)
  Алгоритм - ресурс информационной системы, выступающий вспомогательным компонентом по организации необходимых математических расчетов. Алгоритм может быть включен в приложение, либо в объект базы данных, как один из элементов.
  Объект базы данных - ресурс информационной системы, выступающий как механизм по организации и хранению информации. Объект базы данных может быть использован в приложении, как один из его элементов.
  Отчет - ресурс информационной системы, выступает как механизм по организации отчетного документа. Отчет может быть использован в приложении, как один из элементов.
  Приложение - Miracle-программа - это организация необходимых компонентов в единую структуру. Именно приложение содержит управляющую логику. Само приложение может состоять из одного и более “окон” (пользовательского интерфейса). А также может использовать объекты базы данных, отчеты, алгоритмы. Дополнительный тип компонентов, используемых в приложении - это специализированные объекты, штатный набор которых может быть пополнен собственными разработками, основанными на предоставленном API. При этом, приложение также является ресурсом информационной системы, предоставленное пользователю в виде программы. Приложение может быть распределенным или общедоступным. Статус приложения устанавливается разработчиком в момент его регистрации на Сервере управления, в качестве ресурса ИС.

Пример конфигурирования ИС

  В общих чертах, построение вашей информационной системы, может вестись в следующей последовательности:

  1. Определение объема хранимой информации и выбор SQL-сервера.
  2. Постановка задачи.
  3. Организация группы разработчиков, в обязанности которых будет входить:
    • формирование структуры базы данных,
    • разработка форм предоставления информации,
    • Разработка алгоритмов,
    • Сборка этих частей в единое решение, тестирование и передача их в эксплуатацию.
  4. Определение пользователей и их права в информационной системе, менеджером ИС.
  5. Эксплуатация приложений пользователям.

  Система Miracle - это трехуровневая архитектура эксплуатации приложений, позволяющая более эффективно строить и модифицировать структуру эксплуатируемых приложений. А наличие специализированных серверов позволяет оптимально перераспределять нагрузку в локальной сети.

Заглянем внутрь Miracle™

  В системе Miracle данные и правила их обработки являются самостоятельными объектами. Вид предоставления одной и той же информации может быть совершенно отличный для разных групп пользователей. Модификация любого компонента в системе не приводит к противоречивости, а методы распределения данных позволяют организовывать необходимый доступ к корпоративным данным.
  Всю систему можно разделить на три части, каждая из которых рассчитана для разных групп пользователей. Самый большой отряд - конечные пользователи, получающие готовые Miracle - приложения. При этом каждое решение может быть воспринято ими как “законченная” программа. Пользователи могут быть совершенно далеки от того, как это работает. Их основная задача - работать в системе согласно “бизнес-правилам” в предоставленных решениях. Авторизация пользователей в систему и предоставление им ресурсов производится через программный модуль Miracle Manager (Менеджер приложений).
  Следует отметить, что совершенно не имеет значения, на каком именно компьютере в локальной вычислительной сети, пользователь получает авторизацию. В любом случае он получит только те методы обработки данных, которые ему предоставил администратор системы.
  Основная программа по администрированию информационной системой - Cервер управления (Miracle Base Program). Использование данного сервера позволяет более эффективно управлять данными, организовать схемы предоставления ресурсов пользователям. Наличие дополнительного сервера является основным отличием от многих других методов построения информационных систем. Специализированный сервер является связующим звеном между предоставляемыми данными, способом их отображения, и едиными правилами обработки информации. Данная программа является основным инструментом администратора информационной системы предприятия.

Рисунок 25 Схема авторизации в системе и получение необходимого "приложения", либо инструментов разработки

  Система Miracle содержит полный набор инструментальных средств по созданию пользовательских приложений, содержащих мощные средства визуального проектирования и отладки. Что позволяет как легко создавать новые приложения, так и производить их модификацию.
  В полный комплект поставки системы Miracle также входят средства для тиражирования информационных систем или отдельных приложений, в другие Miracle-среды.
Общая схема информационной системы:

Продукт системы Miracle Ресурс в ИС Назначение
Сервер управления Иерархическая модель (структура) Регистрация участников ИС, приложений, отчетов, математических алгоритмов, распределение доступов к ресурсам
Менеджер приложений Список доступа к:
  • инструментам проектирования;
  • распределенным приложениям;
  • общедоступные приложения.
Подключение к структуре на Сервере управления. Получение допуска к ресурсам ИС, запуск приложений и инструментов разработки.

Архитектура системы Miracle

  Система Miracle использует клиент-серверную технологию, и может быть развернута в различных сочетаниях специализированных серверов.
  Серверная часть:

  1. Сервер управления;
  2. SQL-сервер;
  3. Web-сервер;
  4. Монитор транзакций.

  Клиентская часть:
  Менеджер приложений;

Схема взаимодействия

SQL-сервер

IDAPI

Сервер управления

Менеджер приложений

Инструментальные средства

Приложения
 
Данные
IDAPI
Монитор транзакций
Инструментальные средства
Приложения (Miracle-программа)

Пояснение схемы взаимодействия

  Система начинает функционировать только при активном Сервере управления, который в свою очередь содержит правила для установки связи с SQL-сервером (Установка связи осуществляется согласно параметров файла IDAPI.CFG.) Для подключения пользователей необходимо, чтобы в рамках Сервера управления функционировала иерархическая модель (структура). Где описывается уровень и объем прав для каждого участника ИС.
  Используя клиентскую часть, пользователь авторизуется в систему через программу - Менеджер приложений. Данная программа позволяет получать авторизацию с любого компьютера, где она установлена. Это обеспечивает легкую миграцию служащих с поддержкой единого предоставления всех ресурсов ИС на любом компьютере. Получив доступ к системе, Менеджер приложений предоставляет списки доступных инструментальных средств, и Miracle-программ. Запуск выбранной программы приводит к пересылке выбранного ресурса по локальной сети к клиенту.
  Предоставленные инструментальные средства начинают работу сразу, в тоже время, приложения (Miracle-программы) при запуске устанавливают связь с сервером баз данных. Связь может быть установлена в следующих режимах:
  - Прямое подключение к SQL-серверу, согласно настройкам IDAPI.
  - Подключение через Монитор транзакций.
  Первый вариант обеспечивает полноценное подключение каждого приложения.
  Второй вариант обеспечивает перераспределение нагрузки общения с СУБД, с клиента на выделенный сервер - Монитор транзакций, имеющего собственную связь с Сервером Баз Данных.
  После запуска приложения, его работу обеспечивают вычислительные ресурсы клиентского компьютера. (Режим “толстого” клиента). Выполнение приложений основано на использовании ядра системы Miracle, доступ к которому должен быть организован либо в качестве общего ресурса на File-сервере, либо организован через режим получения копии ядра в момент авторизации.
  Первый способ обеспечивает однозначность ядра системы для всех участников ИС, и позволяет хранить на клиентских местах минимум программного обеспечения, обеспечивающего начальную авторизацию в систему.
  Второй способ позволяет снизить нагрузку на локальную сеть, а установленный режим синхронизации обеспечивает целостность ядра системы на клиентской машине, обеспечивающего работоспособность приложений (Miracle-программ).


Предыдущий раздел На начал документауции На оглавление Следующий раздел

©1995,1997,2000 НПФ ”И.В.А.”. Все права сохранены.
Название фирм и торговых марок используются только в качестве пояснения.