124040 (Разработка системы автоматизации управления фермой СХПК "Алматы"), страница 4

«Теплая» связь. Данный тип связи между объектами может использоваться, если для объекта важен сам факт изменения данных. В этом случае объект-клиент знает, что информация, которой он обладает, устарела и может инициировать процесс обновления через определенный промежуток времени, либо запросив подтверждение у оператора. При установлении «теплой» связи у объекта сервера вызывается метод D Advise и ему передается формат представления данных, в котором клиент хочет получить информацию, способ связи - только уведомление и интерфейс приема данных для того, чтобы можно было организовать обмен данными позднее.

«Горячая» связь. Метод соединения по способу «горячей» связи предполагает уведомление клиента об изменениях информации путем посылки ему обновленной информации. Этот метод необходимо использовать при изменениях курсов валют, биржевых котировок и другой информации, характер изменения которой является критической для бизнеса.

При «горячей» и «теплой» связи существует возможность использования разового уведомления, когда после первой посылки информации связь между объектами разрывается. [3]

2.3 Управление объектами

После определения характера взаимодействия между объектами системы встает вопрос о необходимости описания с их помощью конкретной структуры кооператива. Как отмечалось, такая операция является завершающей и может выполняться на этапе внедрения системы в кооперативе. Очевидно, что данная операция должна выполняться сравнительно легко и позволять гибко модифицировать связи между компонентами системы. В этом случае можно использовать такие средства, предоставляемые OLE, как OLE Automation и автоматные контроллеры. Если до этого момента рассматривался обмен данными между объектами, то с использованием Automation объекты получают возможность управлять действиями друг друга. Обмен информацией происходит через интерфейс IDispatch посредством вызова метода Invoke для активизации действий, выполняемых данным объектом. В системе управления кооперативом имеет смысл определить, например, расдача корма животным, ленточным способом, посредством компьютера, который будет инициатором создания документов для отражения в документообороте движения материальных ценностей. Список поддерживаемых объектом методов возвращается путем вызова метода Get Type lnfo интерфейса I Dispatch аналогично тому, как запрашивается список поддерживаемых форматов через интерфейс I Data Object. Благодаря этому существует возможность добавления на этапе функционирования системы новых объектов, отражающих изменения в реальной жизни и их интеграции в систему. Необходимо заметить, что это не требует изменений в уже существующих объектах.

2.4 Распределенная обработка данных

Перед системой управления кооператива встает задача определения рабочих мест пользователей информации и обмена информацией между ними. Одним из преимуществ технологии OLE является то, что факт запроса объекта с другой машины проходит «прозрачно» для локальных объектов. Это позволяет масштабировать существующее приложение в рамках всего предприятия без изменения характера взаимодействия между объектами.

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

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

2.5 Требования к интерфейсу

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

Поскольку наша система разрабатывается для работы в графической системе Windows 9x, то имеет смысл рассмотреть коммерческий стандарт на приложения, предложенный Microsoft, который дает право ставить на программный продукт логотип “Designed for Windows 9x/NT”.

Этот логотип требует соблюдения следующих принципов при разработке программ:

Командует пользователь:

• пользователь должен быть инициатором всех операций;

• он всегда должен иметь возможность вмешаться в автоматический процесс;

• следует учесть возможность “персонификации” приложения;

• быстрое реагирование приложения на команды пользователя;

• интерактивность.

Наглядность:

• образное представление операций, действий – “рисунок стоит тысячи слов”;

• манипулирование объектами в среде приложения;

• “метафоры” для объектов действий.

Единообразие:

• Единообразие методов работы с операционной системой;

• единообразие внутри приложения;

• единообразие метафор.

Терпимость к пользователю:

• Обратимость или исправимость всех действий.

Обратная связь:

• обратная информация о ходе процесса или режиме работы.

Эстетика:

• приятный внешний вид;

• системная палитра цветов;

• принцип “72 вариантов выбора”.

Простота:

• легкость освоения и применения;

• баланс между простотой и доступностью функций и данных.

Проектирование с ориентацией на данные:

• выбор объекта действий обеспечивает доступ к средствам управления объектом, изменения объекта.

Проектирование с ориентацией на документы:

• концепция блока данных как документа (а не как файла).

2.6 Сравнение SQL-серверов ведущих фирм-производителей

SQL-сервер на совеременном этапе развития объединяет все новейшие технологии хранения данных и обеспечения доступа к ним. Важным качеством инженера является способность разбираться во всем многообразии современных продуктов данной категории и выделять преимущества и недостатки каждого из них: Motorola, Nokia, MCI, Northern Telecom, Philadelphia Stock Exchange, Bear Stearns, First National Bank of Chicago, the Money Store, the US Army, NASA, Boeing.. Приложения подобного рода имеют много общих требований: легкость использования и управления, производительность, масштабируемость, переносимость, использование ресурсов и восстановление после сбоя. Borland InterBase разработан именно с целью удовлетворять всем этим требованиям.

Даже если большинство систем не требуют экзотических возможностей, на вышеперечисленные, они все равно желают от РСУБД тех же характеристик для реальных задач и решения реальных проблем. Перечисленные характеристики Borland InterBase также очень хорошо подходят для рабочих групп, отделов, и приложений уровня кооператива. Borland Interbase выбран нами для реализации информационной базы автоматизированной системы управления. [8]

2.7 Механизмы блокировок

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

2.8 Страничные блокировки

Для того, чтобы гарантировать целостность данных, архитектура SQL Server использует механизм блокировок страниц данных. Страница данных это набор записей, хранимых в некоторой области жесткого диска на сервере. Все страницы имеют один и тот же размер, который определяется конфигурацией сервера и базы данных. В зависимости от длины записей и размера страницы, страница может содержать определенное количество записей. Записи в большинстве случаев добавляются в конец таблицы. Базовый размер страницы в SQL Server равен 2K, и это является минимальной единицей блокировки.

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

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

Индексы SQL Server блокируются точно так же, как и страницы данных соответствующих таблиц, однако эффект блокировки страницы индекса значительно шире. Записи в таблице хранятся в большинстве случаев в случайном порядке, исключение составляют кластерные индексы. Когда обновляется страница данных, то должен обновиться соответствующий индекс. Как и у таблиц, данные индексов хранятся на страницах. Для обновления страницы индекса, эта страница должна быть сначала заблокирована. В приложениях, работающих с большими объемами данных, это может сильно снизить производительность системы.

Для обеспечения целостного представления данных в Sybase или Microsoft SQL Server разработчик должен использовать блокировки таблиц. Блокировка таблицы вызывает полную блокировку, разделяемую, для обновления или исключительную [Shared, Update, or Exclusive. Представьте себе свод баланса бухгалтером - пока свод не закончен, архитектура SQL Server требует чтобы разработчик полностью заблокировал таблицу на время свода. Кроме этого может потребоваться полное блокирование связанных таблиц.

В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все равно требует табличных или страничных блокировок для обеспечения целостности данных. [8]

2.9 Архитектура многоверсионности записей

InterBase обеспечивает оптимистические блокировки при помощи Архитектуры Многоверсионности Записей (Multi-Generational Architecture – [MGA]. Этот механизм создает оптимизированные версии для новых, удаленных или обновляемых записей, которые видны только в контексте конкретной транзакции, изменяющей данные. Реально, InterBase версионирует только изменяемые столбцы (поля) путем создания deltas. Это обеспечивает максимальную производительность и минимальные требования к дисковому пространству.

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

Страничные и табличные блокировки SQL серверов Microsoft и Sybase могут сильно влиять на производительность, когда многим пользователям требуется доступ к одним и тем-же данным (или находящимся на близлежащих страницах). Например, в реальных ситуациях, страничные блокировки в SQL Server могут замедлять доступ к данным (ожидание освобождения блокировок страниц, индексов или таблиц). Этот эффект может быть заметен в системах с большим объемом данных или когда пользователи выполняют создание длительных отчетов по данным в тот момент, когда другие пользователи модифицируют данные. Архитектура Многоверсионности записей InterBase гарантирует доступность данных на чтение для любых пользователей и в любое время. Клиентское приложение никогда не ждет доступности таблиц, записей или индексов, независимо от числа пользователей в системе или длительности и сложности какой-либо транзакции. Разработчики, использующие InterBase, автоматически получают максимум производительности приложений, безотносительно сложности обработки данных.

2.10 Двухфазное подтверждение транзакций

Слово "транзакция" произошло от слияния слов "акция трансформации". Транзакция это действие или группа действий, которые переводят систему из одного целостного состояния в другое. Например, при переводе денег с одного счета на другой, должна быть изменена сумма либо обоих счетов, либо ни одного в случае ошибки.

Транзакции характеризуются свойствами ACID:

• Atomicity (атомарность) - "все или ничего". Либо вся транзакция завершается, либо ни одна из ее частей. Если транзакция не может быть завершена, то все операции, произведенные внутри транзакции, отменяются;

• Consistency (целостность) - транзакция должна переводить базу данных из одного целостного состояния в другое. Целостность определяется бизнес-правилами (логикой базы данных) и вводится в действие приложением;

• Isolation (изоляция, изолированность) - Поскольку может возникать множество конкурентных транзакций, каждая транзакция должна быть изолирована от действий, производимых другими транзакциями. Т.е. транзакции должно "казаться", что она является единственной, выполняемой над базой данных;

• Durability (прочность)- Изменения, подтвержденные транзакцией, обязаны вступить в силу.

Если использовать в качестве примера снятие средств с расчетного счета, то все ACID-свойства должны иметь место. Представим что информация о получении товара хранится в одной БД, а информация о счете поставщика – в другой. В этом случае при регистрации счет-фактуры на полученные ТМЦ соответственно должен измениться счет поставщика, и выполняться это должно в одной транзакции. Такие ситуации обрабатываются при помощи двухфазного подтверждения транзакций (Two Phase Commit - 2PC). Это механизм, который применяет к изменениям в обоих базах данных свойства ACID.Двухфазное подтверждение транзакций имеет две отдельные фазы: подготовка и подтверждение. Если по какой-то причине процесс не может быть выполнен в течение фазы подготовки, например после регистрации счет-фактуры, но до изменения суммы счета поставщика, то транзакция должна быть отменена (rollback). Это гарантирует что на дебиторская задолженность поставщика будет соответствовать нашей кредиторской.

Microsoft SQL Server и Sybase SQL Server требуют от разработчика программной обработки 2PC. InterBase обеспечивает автоматическую обработку 2PC в соответствии со всеми требованиями ACID без дополнительного программирования на любых платформах (Windows NT, DEC UNIX, HP-UX, Irix и т.д.). Это обеспечивает максимум легкости сопровождения при отсутствии дополнительных затрат.

2.11 Многоразмерные массивы

InterBase обеспечивает уникальный тип данных называемый Многоразменый Массив (Multi Dimensional Array [MDA]). Тип MDA не реализован ни в одной другой РСУБД. Тип MDA позволяет разработчику зранить массивы любой длины и до 16 измерений. Массивы предоставляют возможность хранения и представления данных в случаях, в большинстве невозможных для архитектуры SQL Server. Ключевой особенностью является производительность массивов. Дополнительно, если элемент массива содержит значение NULL, то Inter Base не выделяет для него дисковое пространство. В реляционных терминах, доступ к набору данных с одной стороны отношения, не имеющего соответствующего значения, потребует использования outer joun в любом запросе, использующем такое отношение. В большинстве РСУБД, производительность запросов с outer join невелика. Доступ к массивам Inter Base осуществляется другим способом, и поэтому не ухудшает скорость доступа к данным.