Развитие распределенных информационных систем в России
Распределенные базы данных являются неотъемлемой частью распределенных информационных систем, которые находятся в фокусе интереса во многих странах мира, включая Россию. В силу географического положения и размеров страны, Россия представляет большой потенциал для использования таких систем.
Однако успешное развитие распределенных информационных систем возможно только при условии адекватного развития глобальной сетевой инфраструктуры и применении реальных технологий создания таких систем. Для достижения этого, важно иметь правильное представление о необходимых технологиях и их характеристиках.
Хотя Россия уже преодолела начальный этап локальной компьютеризации и достигла высокого уровня автоматизации в различных сферах, создание корпоративных информационных систем все еще представляет вызов. Классический подход к автоматизации не всегда соответствует требованиям распределенных систем, и поэтому нужно переосмыслить и проанализировать технологии, применимые в этом решении.
Однако, на данный момент, большинство организаций все еще стремятся использовать знакомые и привычные инструменты и методы для решения новых задач, которые существенно отличаются от предыдущих. Недостаточное понимание современных технологий и их применимости в распределенных системах может препятствовать эффективному развитию таких систем и использованию их потенциала в полной мере.
Для успешного развития распределенных информационных систем в России, необходимо активно участвовать в исследованиях и разработках новых технологий, а также обмениваться опытом с другими странами, которые имеют уже значительный опыт в этой области. Кроме того, необходима образовательная программа, которая будет способствовать глубокому пониманию особенностей и требований распределенных систем среди специалистов в этой сфере.
В завершение, развитие распределенных информационных систем является важным фактором для современной России, и для достижения успеха в этой области необходимо преодолеть инерцию мышления и принять современные технологии, соответствующие требованиям распределенных систем.
Поведение и мотивация разработчиков вполне понятны и оправданы. Ставится задача — построить информационную систему «клиент-сервер» на базе локальной сети с централизованной базой данных. Выбирается одна из популярных многопользовательских СУБД и какие-либо средства для быстрой разработки приложений. Наконец, создается сама система, представляющая собой комбинацию базы данных и обращающихся к ней приложений, в которых и реализована вся прикладная логика. Пока все это работает в ограниченном масштабе, все идет великолепно. Предположим, что организация, для которой выполнялась разработка, настолько выросла, что вновь возникшие задачи потребовали децентрализации хранения и обработки данных и, соответственно, развития информационной системы. Здесь и совершается ошибка. Подходы, хорошо зарекомендовавшие себя во вполне определенных условиях, автоматически переносятся в совершенно иную среду, с иными правилами жизнедеятельности. В результате система становится неработоспособной и должна быть создана заново, но уже с применением адекватных средств.
Распределённые базы данных
... систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах. Дадим следующее определение: распределенная база данных — это набор файлов (отношений), хранящихся в разных узлах информационной ... таких систем, с развитием технологий обработки и хранения информации, а также качественным изменением ситуации с развитием технологий передачи данных, в ...
Сжато затронуты смежные темы, в частности, программное обеспечение промежуточного слоя. Предполагается, что читатель знаком с основами реляционных баз данных и языка SQL. Статья носит скорее обзорный характер; рассматривая распределенные базы данных как отправную точку, я не удержался некоторых обобщений и высказал собственную точку зрения на архитектуру распределенных систем (с которой, возможно, многие не согласятся — но так интересней).
1. Распределенные базы данных
Под распределенной (Distributed DataBase — DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово «распределенная» отражает способ организации базы данных, но не внешнюю ее характеристику. («распределенность» базы данных невидима извне).
Определение Дэйта.
Лучшее, на мой взгляд, определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date) в. Он установил 12 свойств или качеств идеальной DDB:
Локальная автономия
Независимость узлов, Непрерывные операции, Прозрачность расположения, Прозрачная фрагментация, Прозрачное тиражирование, Обработка распределенных запросов, Обработка распределенных транзакций,
Независимость от оборудования, Независимость от операционных систем, Прозрачность сети, Независимость от баз данных
Локальная автономия является одним из важнейших качеств распределенных баз данных. Она обеспечивает независимость каждого узла системы от центрального узла и выполняет управление данными на каждом узле локально. База данных на каждом узле является неотъемлемой частью системы и полноценно функционирует в качестве локальной базы данных, самостоятельно обрабатывая запросы и не завися от других узлов. Важными характеристиками локальной автономии являются непрерывные операции и прозрачность расположения данных.
Независимость от центрального узла
Идеальная распределенная система предполагает равноправность каждого узла и равноправность распределенных баз данных. База данных на каждом узле самодостаточна, она хранит полный собственный словарь данных и защищена от несанкционированного доступа. Независимость каждого узла от центрального узла обеспечивает эффективную и удобную работу со всеми данными в системе.
Реферат база данных основа информационной системы
... баз данных (БД), системы управления базами данных (СУБД) и пакетов прикладных программ (ППП). 2. Классификация БД По технологии обработки данных БД подразделяются на централизованные и распределенные. ... функционирования ИС. Успешно решаются эти задачи, если данные в информационной системе структурированы. Структурирование данных рассмотрим на примере студенческой группы. Каждый член группы во ...
Непрерывные операции
Непрерывные операции обеспечивают доступ к данным из любой точки системы в любое время суток, независимо от местонахождения данных и операций, выполняемых на других узлах системы. Обеспечивается полная непрерывность работы с данными.
Прозрачность расположения
Прозрачность расположения данных является важным свойством распределенной системы. Пользователь, обращающийся к базе данных, не должен знать о местонахождении данных и выполнять операций с ними без учета этого фактора. Запросы к базе данных транспортируются встроенными системными средствами системы без учета расположения данных.
Прозрачная фрагментация
Прозрачная фрагментация — это свойство распределенных баз данных, которое позволяет хранить логически связанные данные на различных узлах. Фрагментация может быть горизонтальной или вертикальной. Горизонтальная фрагментация предполагает размещение строк одной таблицы на разных узлах, а вертикальная фрагментация — распределение столбцов таблицы по нескольким узлам.
Для наглядного примера рассмотрим таблицу «employee» с колонками «emp_id», «emp_name» и «phone». Предположим, что данная таблица определена на двух узлах — Фениксе и Денвере. Оба узла содержат информацию о сотрудниках компании. Кроме того, на узле в Далласе определена таблица «emp_salary» с колонками «emp_id» и «salary».
Для запроса «получить информацию о сотрудниках компании» мы можем использовать следующий SQL-запрос:
SELECT * FROM employee@phoenix, employee@denver ORDER BY emp_idА для запроса «получить информацию о заработной плате сотрудников компании» мы можем использовать следующий SQL-запрос:
SELECT employee.emp_id, emp_name, salary FROM employee@denver, employee@phoenix, emp_salary@dallas ORDER BY emp_idПрозрачность тиражирования
Тиражирование данных — это процесс переноса изменений между базами данных, расположенными на разных узлах распределенной системы. Прозрачность тиражирования означает, что этот процесс является асинхронным и невидимым для пользователей распределенной системы. Это свойство позволяет переносить изменения между базами данных с помощью внутрисистемных средств без вмешательства пользователей.
Обработка распределенных запросов
Обработка распределенных запросов — это возможность выполнения операций выборки над распределенной базой данных с использованием языка SQL. То есть запросы к распределенной базе данных формулируются так же, как и запросы к локальной базе данных.
Например, запрос «получить информацию о клиентах компании и их заказах» может быть сформулирован следующим образом:
SELECT customer.name, customer.address, order.number, order.date FROM customer@london, order@paris WHERE customer.cust_number = order.cust_numberОбработка распределенных транзакций
Обработка распределенных транзакций (Distributed Transaction Processing) является важным качеством распределенных баз данных. Это свойство позволяет выполнять операции обновления данных (INSERT, UPDATE, DELETE) в распределенных базах данных, не нарушая их целостность и согласованность. Для обеспечения этой цели применяется двухфазный или двухфазный протокол фиксации транзакций (two-phase commit protocol), который является стандартом обработки распределенных транзакций. Этот протокол гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной транзакции.
Проектирование и разработка реляционной базы данных для информационной ...
... хранению и анализу информации. Целью данной курсовой работы является создание реляционной базы данных зоомагазина и разработка приложения для работы с данной базой. В совокупности данная система должна обеспечивать возможности по накоплению ...
Независимость от оборудования
Распределенная система баз данных обладает свойством независимости от оборудования. Это означает, что в ее состав могут входить компьютеры различных моделей и производителей — от мэйнфреймов до персональных компьютеров. Такая гибкость позволяет использовать различные типы оборудования в распределенной системе и обеспечивает ее эффективную работу.
Независимость от операционных систем
Еще одно важное качество распределенных баз данных — их независимость от операционных систем. Это означает, что система может быть построена на базе различных операционных систем, управляющих узлами распределенной системы. Такая гибкость позволяет использовать различные операционные системы и обеспечивает совместимость между ними.
Прозрачность сети
Распределенная система баз данных обладает свойством прозрачности сети. Это означает, что доступ к базам данных в системе может осуществляться по сети. Наличие различных сетевых протоколов не должно быть ограничением для системы с распределенными базами данных. Возможность использования любых сетевых протоколов позволяет эффективно обмениваться данными между узлами системы.
Независимость от баз данных
Распределенная система баз данных обладает свойством независимости от баз данных. Это означает, что в системе могут сосуществовать базы данных различных производителей, использующие различные модели и форматы данных. Такая гибкость позволяет выполнять операции поиска и обновления данных в различных базах данных в рамках распределенной системы.
Исходя из определения распределенной базы данных, можно считать ее слабо связанной сетевой структурой, где узлы представляют собой локальные базы данных. Локальные базы данных являются автономными, независимыми и самоопределенными, их доступ обеспечивается системами управления базами данных различных поставщиков. Связи между узлами представляют собой потоки тиражируемых данных. Топология распределенной базы данных может быть разнообразной, включая иерархическую структуру, структуру типа «звезда» и другие. Определение топологии зависит от географии информационной системы и направления потоков данных.
Исследование свойств DDB в контексте практического применения
Целостность данных
В распределенных базах данных (DDB) обеспечение целостности и согласованности данных представляет собой сложную проблему. Для решения этой проблемы применяется протокол двухфазной фиксации транзакций, который обеспечивает синхронное и согласованное изменение данных в нескольких локальных базах данных.
Если DDB является однородной, то используется механизм двухфазной фиксации транзакций, предоставляемый одной и той же СУБД на всех узлах. В случае неоднородности DDB используются менеджеры распределенных транзакций, если СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open.
База данных. Понятие базы данных. Виды баз данных. Объекты для ...
... данных. Для разработки программ, систем программ, работающих с базами данных, используются специальные средства – системы управления базами данных (СУБД). СУБД ... база данных, разные части которой хранятся на различных компьютерах, объединённых в сеть; 4.Централизованная – база данных, хранящихся на одном компьютере; 5.Реляционная – база данных с табличной организацией данных. ... таблицы и тем самым, ...
Если в DDB предусмотрено тиражирование данных, то это создает дополнительные трудности в поддержке целостности данных на узлах, куда направлены потоки тиражируемых данных. Необходимо следить за конфликтами, которые могут возникать из-за параллельных изменений в данных.
Прозрачность расположения
Для обеспечения прозрачности расположения данных в DDB используются различные механизмы. Например, в Oracle создаются ссылки на базы данных, которые могут содержаться на удаленных узлах. Такие ссылки позволяют явно обращаться к удаленным базам данных, используя оператор SELECT или другие операторы языка SQL.
В зависимости от разработчиков СУБД, могут применяться и другие подходы к обеспечению прозрачности расположения данных в DDB.
Обработка распределенных запросов
В процессе работы с распределенными базами данных (DDB) возникает необходимость в обработке распределенных запросов, которые могут включать таблицы, находящиеся в различных базах данных или на разных компьютерах. Одним из подходов к решению этой задачи является использование оператора SQL CREATE SYNONYM, который позволяет создавать новые имена для существующих таблиц.
Например, при работе с базой данных, расположенной в Лондоне, мы можем создать синоним customer для таблицы [email protected]. Это позволит нам написать запрос, который будет независим от расположения базы данных:
CREATE SYNONYM customer FOR [email protected];
SELECT customer.cust_name, order.order_date
FROM customer, order
WHERE customer.cust_number = order.cust_number;
Таким образом, мы можем обращаться к таблице customer, независимо от того, на каком компьютере она физически находится.
В некоторых случаях, оператор CREATE SYNONYM позволяет обращаться к таблицам, расположенным в других базах данных и на других компьютерах. Например, в СУБД Informix, запись CREATE SYNONYM customer FOR client@central:smith.customer означает, что любое обращение к таблице customer в текущей базе данных будет автоматически переадресовано на компьютер central в базу данных client к таблице customer.
Это дает возможность перемещать таблицы между базами данных, оставляя ссылку на их новое местонахождение. При этом все необходимые действия для доступа к содержимому таблицы будут сделаны автоматически.
В случае иерархической организации DDB, где на каждом узле содержится подмножество записей таблицы customer, можно использовать оператор CREATE SYNONYM для определения таблицы структуры customer, находящейся в Японии:
CREATE SYNONYM japan_customer FOR [email protected];
Таким образом, мы можем обращаться к таблице japan_customer и получать записи о клиентах компании, находящихся в Японии.
В большинстве СУБД управление именами объектов DDB осуществляется через глобальный словарь данных, который содержит информацию о расположении данных, возможностях других СУБД (если используются шлюзы), сведения о скорости передачи по сети и другую информацию. Это позволяет эффективно обрабатывать распределенные запросы и обеспечивать доступ к данным, находящимся на различных компьютерах и базах данных.
Качество обработки распределенных запросов (Distributed Query — DQ) является одним из ключевых аспектов в системах распределенных баз данных (DDB).
Реферат локальные базы данных
... и неоднородные распределенные базы данных. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных - это ...
DQ представляет собой более сложную задачу, чем обработка локальных запросов, и требует интеллектуального решения с помощью оптимизатора DQ.
Предположим, что у нас есть DDB, состоящая из двух узлов сети. На одном узле хранится таблица «detail» размером 10000 строк, а на другом узле — таблица «supplier» размером 100 строк. Задачей является выполнение запроса:
SELECT detail_name, supplier_name, supplier_address
FROM detail, supplier
WHERE detail.supplier_number = supplier.supplier_number;
Результатом выполнения данного запроса является объединение таблиц «detail» и «supplier» по столбцу «supplier_number». Однако, так как таблицы находятся на разных узлах, для выполнения запроса необходимо передавать данные по сети. Из-за этого оптимизатор DQ должен учитывать различные параметры, такие как размер таблиц, статистику распределения данных, объем передаваемых данных, скорость коммуникационных линий и другие факторы. Интеллект оптимизатора DQ напрямую влияет на скорость выполнения распределенных запросов.
Межоперабельность
В контексте DDB межоперабельность имеет два значения. Во-первых, это качество, позволяющее обмениваться данными между базами данных разных поставщиков. Например, как передавать данные из базы данных Informix в Oracle и наоборот? Стандартные средства тиражирования в рамках одной СУБД позволяют переносить данные только в однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из Ingres в Ingres. Однако, в случае неоднородной DDB появляется необходимость использования продуктов, способных выполнять тиражирование между разнородными базами данных.
Во-первых, распределенные базы данных (DDB) предоставляют возможность хранения и обработки данных на различных узлах сети. Это позволяет улучшить производительность и надежность системы, а также обеспечить отказоустойчивость и масштабируемость. В DDB данные могут быть разделены на фрагменты и распределены между узлами сети в зависимости от их локации или требований к производительности. Каждый узел может обрабатывать только свои локальные данные, что уменьшает нагрузку на сеть и повышает скорость доступа к данным.
Во-вторых, это возможность некоторого унифицированного доступа к данным в DDB из приложения. Возможны как универсальные решения (стандарт ODBC), так и специализированные подходы. Очевидный недостаток ODBC — недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения не поддерживаются.
Специальные подходы — это, например, использование шлюзов, позволяющее приложениям оперировать над базами данных в «чужом» формате так, как будто это собственные базы данных. Вообще, цель шлюза — организация доступа к унаследованным (legacy) базам данных и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так, если компания долгое время работала на СУБД IMS и затем решила перейти на Oracle, то ей очевидно потребуется шлюз в IMS. Следовательно, шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует — все определяется конкретной ситуацией, историей информационной системы и массой других факторов. DDB конструирует архитектор, имеющий в своем арсенале отработанные интеграционные средства, которых на рынке сейчас очень много.
Базы данных и системы управления базами данных
... банка данных, базы данных и СУБД: Банк данных (БнД) База данных (БД) Система управления базами данных (СУБД) Глава1. Базы данных 1. 1 Основные понятия баз данных В современных базах данных хранятся не только данные, но и информация. База данных ( ... на устройство вывода или передача по каналам связи. Существует много систем управления базами данных. Они могут по-разному работать с разными объектами и ...
Технология тиражирования данных
Принципиальная характеристика тиражирования данных (Data Replication — DR) заключается в отказе от физического распределения данных. Суть DR состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репликатором (так устроены СУБД CA-OpenIngres и Sybase).
В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к Oracle7 DBMS опцию Replication Option.
Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR — использование «моментальных снимков» (snapshot).
Рассмотрим пример из Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE (‘DD-MON-YY HH23:MI:55’)
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = «N»;
- «Моментальный снимок» в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторяться каждые 7 дней. Каждый раз будут выбираться только завершенные заказы.
Реальные схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для тиражирования выступает транзакция к базе данных. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей базы на определенный момент времени.
Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависит от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит качество 6 в определении Дэйта.
Синхронное обновление DDB и DR-технология — в определенном смысле антиподы. Краеугольный камень первой — синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в DDB. Ее «Ахиллесова пята» — жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
Реляционная модель данных в системах управления базами данных
... Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key). Рассмотрим пример, в котором база данных хранит информацию о рядовых служащих ... наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными системах баз данных, основанных на языке SQL, в действительности нарушаются некоторые важные принципы ...
DR-технология предлагает резервное копирование и восстановление данных в распределенной среде, где база данных разбита на несколько узлов. Она отличается от других методов резервного копирования тем, что не требует синхронной фиксации изменений, что является ее сильной стороной. В некоторых задачах нет необходимости в обеспечении идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных только в определенные критические моменты времени. Это достигается путем накопления изменений в виде транзакций на одном узле и периодической их копии на другие узлы.
DR-технология обладает рядом преимуществ. Во-первых, данные всегда находятся там, где они обрабатываются, что существенно увеличивает скорость доступа к ним. Во-вторых, передача только операций, изменяющих данные, а не всех операций доступа к удаленным данным, и асинхронный режим работы снижают объем трафика. В-третьих, репликатор выступает со стороны исходной базы данных как однопользовательский процесс, тогда как в распределенной среде каждый локальный сервер обслуживает всех пользователей и конкурирует с ними за ресурсы. Наконец, репликация данных позволяет избежать проблем при обрыве связи, так как поток изменений буферизуется и передача возобновляется с точки обрыва.
Однако DR-технология не лишена недостатков. Один из таких недостатков — невозможность полностью исключить конфликты между версиями одной и той же записи. Это может возникнуть при асинхронной работе, когда два пользователя на разных узлах вносят изменения в одну и ту же запись одновременно, до того как изменения из первой базы данных были скопированы во вторую базу данных. При проектировании распределенной среды с использованием DR-технологии необходимо учитывать возможность конфликтных ситуаций и разработать механизм их разрешения.
Эффективное применение DR-технологии требует внимательного анализа и осторожной разработки схемы, включающей алгоритм разрешения конфликтов. Она должна применяться только для решения задач с жесткими ограничениями и в тщательно продуманной среде.
2. Архитектура «клиент-сервер»
В архитектуре «клиент-сервер» база данных разделяется на две части: клиентскую и серверную. Клиентская часть отвечает за создание и выполнение программных запросов, а серверная часть выполняет эти запросы и возвращает результаты клиенту.
Распределенные системы представляют собой системы «клиент-сервер», которые могут быть организованы по различным моделям. В данном исследовании рассматриваются три основные модели «клиент-сервер»: модель доступа к удаленным данным (RDA-модель), модель сервера базы данных (DBS-модель) и модель сервера приложений (AS-модель).
Первые две модели являются двухзвенными и не могут рассматриваться в качестве базовой модели распределенной системы. Трехзвенная модель представляет собой наиболее удобную архитектуру, в которой интерфейс с пользователем полностью независим от компонента обработки данных. В этой модели выделяются следующие компоненты: компонент интерфейса с пользователем и компонент управления данными, включая базы данных. Между ними располагается программное обеспечение промежуточного слоя (middleware), которое выполняет функции управления транзакциями, коммуникациями, транспортировки запросов, управления именами и другие.
Администрирование базы данных
... и эффективной работы базы данных. Актуальность исследования «Администрирование базы данных» несомненна. Можно провести аналогию между администратором баз данных и ревизором ... данные. Проблеме администрирования баз данных внимание уделяется сравнительно недавно – с появлением и развитием современных баз данных. Однако в связи с тем, что совершенствование баз данных и систем управления данных ...
Middleware является главным компонентом распределенных систем, включая системы с распределенными базами данных (DDB-системы).
Однако, на данный момент существует ошибка в подходе, которая заключается в полном игнорировании middleware и использовании двухзвенных моделей «клиент-сервер» для реализации распределенных систем.
Необходимо отметить фундаментальное различие между технологией «SQL-клиент — SQL-сервер» и технологией продуктов класса middleware, например, менеджера распределенных транзакций Tuxedo System. В случае SQL-клиента, клиент явно запрашивает данные, зная структуру базы данных. Здесь применяется так называемый data shipping, то есть «поставка данных» клиенту. Клиент отправляет SQL-запрос в СУБД и получает данные в ответ. В этом случае существует жесткая связь типа «точка-точка», для реализации которой используется закрытый SQL-канал, например, Oracle SQL*Net.
Однако, middleware представляет собой более сложную и гибкую технологию. Оно выполняет функции управления транзакциями и коммуникациями, обеспечивает транспортировку запросов, управление именами и другие функции. Middleware является ключевым компонентом распределенных систем и DDB-систем. Таким образом, игнорирование middleware и применение двухзвенных моделей «клиент-сервер» является ошибкой на данном этапе развития распределенных систем.
В заключение, следует отметить важность использования трехзвенной модели «клиент-сервер» и учета middleware при разработке и реализации распределенных систем, особенно систем с распределенными базами данных. Middleware является главным компонентом, обеспечивающим эффективное управление транзакциями и коммуникациями в распределенных системах.
В данном исследовании рассматривается сравнение двух подходов к построению информационных систем «клиент-сервер». Первый подход основан на жесткой схеме связи «точка-точка», где клиент явно запрашивает один из сервисов, передавая ему сообщение и получая ответ в виде сообщения. Этот подход работает только в синхронном режиме «запрос-ответ» и не предоставляет возможность модификации.
Второй подход предлагает гибкий механизм передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие многочисленными способами. В этом случае клиент направляет запрос в информационную шину, не зная о месте расположения сервиса. Этот подход называется «function shipping» и позволяет клиенту получать функции от сервисов.
Один из важных аспектов второго подхода заключается в том, что для клиента база данных закрыта слоем сервисов. Клиент не знает о существовании базы данных и все операции над ней выполняются внутри сервисов. Это обеспечивает безопасность и удобство использования для клиента.
Первый подход, основанный на передаче открытых SQL-запросов и данных, работает только в синхронном режиме и не предоставляет возможности модификации. Он устарел и явно уходит в прошлое. SQL был задуман и реализован как декларативный язык запросов, а не как средство взаимодействия «клиент-сервер». Он был «притянут за уши» разработчиками СУБД в качестве такого средства. Для создания корпоративных распределенных информационных систем этот подход абсолютно непригоден.
Для создания таких систем необходимо применение гибких систем класса middleware, таких как Tuxedo System и Teknekron. Они предоставляют базовый инструментарий при реализации больших проектов и позволяют организовывать взаимодействие между клиентами и серверами различными способами.
В заключение можно сказать, что второй подход к построению информационных систем «клиент-сервер» является более современным и гибким. Он позволяет организовывать взаимодействие между клиентами и серверами различными способами и обеспечивает безопасность и удобство использования для клиента.
Распределенные базы данных (DDB) являются важной темой в информатике. Однако, в последние годы наблюдается относительное затишье в развитии этой технологии, за исключением, возможно, новых методов тиражирования данных. В то же время, архитектура распределенных систем остается актуальной и интересной темой для исследований.
Особый интерес представляют системы с трехзвенной архитектурой, которые являются частью распределенных информационных систем. Также важными являются продукты класса middleware и объектно-ориентированные средства разработки распределенных приложений в стандарте CORBA. Эти технологии будут играть ведущую роль в отечественной информатике в ближайшие 3-5 лет и станут основой для реализации интеграционных проектов.
Однако, наиболее значимые изменения ожидаются в архитектуре корпоративных информационных систем. Технологический взрыв в интернете, развитие Всемирной паутины и использование технологии Java неизбежно повлияют на организацию инфраструктуры корпораций. Гипертекстовая организация данных, предлагающая гибкость, открытость и простоту развития, будет предпочтительной по сравнению с жесткими структурами реляционных баз данных, которые сложно расширять. HTML, как основное средство создания информационного пространства компании, легко интегрируется с уже существующими базами данных. Так называемый Intranet является предвестником будущих корпоративных информационных систем.
Список использованной литературы
[Электронный ресурс]//URL: https://liarte.ru/referat/tehnologii-raspredelennoy-obrabotki-dannyih/
1. Date C.J. 1987. What is distributed database? InfoDB, 2:7
