Синхронизация БД SQL Server из различных источников. Обзор средств синхронизации баз данных MySQL

Синхронизация баз данных MySQL позволяет создать и автоматически поддерживать две или более базы данных с идентичным содержимым. Синхронизациия нужна для создания зеркал, кластеров и т.д. Программа Handy Backup позволяет полностью автоматизировать процесс синхронизации БД MySQL.

Методы синхронизации MySQL баз

В MySQL синхронизация двух баз может быть односторонней или двусторонней.

Односторонняя синхронизация

Содержимое одной базы (master) копируется в другую (slave). В MySQL синхронизация БД на разных серверах используется для репликации таблиц, создания тестовых и резервных баз, бэкапа MySQL и т.д.

Двусторонняя синхронизация

Двусторонняя синхронизация MySQL обеспечивает копирование актуальных изменений из каждой базы данных в другую. Эта техника применяется прежде всего для распределения вычислительных задач, связанных с базами данных – создания кластеров и зеркал БД.

Преимущества Handy Backup для синхронизации БД MySQL

Handy Backup содержит встроенный плагин MySQL, позволяющий копировать состояние баз данных и таблиц MySQL в "горячем" режиме (без остановки сервера), а также в "холодном" (с остановкой). При этом обеспечиваются следующие преимущества:

• Синхронизация данных MySQL (копирование и восстановление) по расписанию;
• Хранение таблиц MySQL в удобочитаемом текстовом формате из списка SQL команд;
• Автоматический останов сервера-приёмника MySQL при восстановлении данных;
• Версионное копирование и создание временных меток на копиях по необходимости;
• Получение доступа к внешним MySQL серверам.

Как выполнить синхронизацию MySQL с помощью Handy Backup?

Синхронизация баз данных MySQL состоит из создания резервной копии базы и последующего восстановления таблиц этой базы на другом сервере с помощью плагина "MySQL". Этот процесс включает в себя 2 последовательных задачи:

Резервное копирование данных исходной таблицы (в случае односторонней синхронизации) или обеих таблиц (при симметричной синхронизации).

Восстановление данных в синхронизируемую таблицу MySQL, полное или дифференциальное, в зависимости от типа синхронизации.

Детальное описание задач копирования и восстановления MySQL имеется в Руководстве Пользователя.

Автоматизация задач синхронизации таблиц MySQL

Чтобы сделать процесс синхронизации баз данных MySQL полностью автоматическим, обратите, пожалуйста, внимание на следующие пункты:

1. Разделите время запуска задач резервного копирования MySQL и их восстановления на достаточно большой промежуток, чтобы запущенная задача резервного копирования базы данных успела завершиться перед началом восстановления.
2. Выбирайте для промежуточных копий MySQL достаточно быстрые по скорости доступа носители: локальные и внешние диски, устройства NAS/SAN и серверы FTP/SFTP/FTPS с широкой пропускной способностью сетевого интерфейса.
3. Пользуйтесь возможностями Шага 7 (установка запуска программ до и/или после выполнения задачи) для автоматического останова и перезапуска сервера MySQL на стороне восстановления, а также на стороне записи – для "холодной" загрузки данных.

1. Поскольку резервные копии хранятся в доступном для чтения текстовом формате, пользуйтесь при необходимости инструментами для внесения исправлений в восстанавливаемые файлы – скажем, для смены механизма хранения данных.

Приобретение лицензии

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

• Если вам нужно работать только с одним сервером СУБД MySQL, Handy Backup Office Expert обеспечит вас всеми необходимыми возможностями для этого и многими дополнительными функциями.
• Если вам необходимо обслуживать несколько серверов и рабочих станций, организуя процессы резервного копирования БД MySQL и любых других данных с общего рабочего места, используйте наше флагманское решение Handy Backup Server Network .

Чтобы сравнить цены на эти и другие продукты, пожалуйста, обратитесь к странице Купить .

Видеоурок

В следующем видеоуроке показано, как осуществлять резервное копирование и восстановление БД MySQL с помощью Windows-версии Handy Backup. В настоящий момент видео доступно только на английском языке.

Скачайте и установите наше программное обеспечение прямо сейчас – первая резервная копия ваших данных будет готова уже через пару минут!

Handy Backup предоставляет надёжный, быстрый и гибко настраиваемый инструмент для синхронизации MySQL на уровне таблиц и баз данных. Попробуйте прямо сейчас, скачав бесплатно полную версию программы на 30 дней!

При использовании ПК Интеллект в системах с распределенной архитектурой необходимо синхронизировать базы данных Серверов и УРМА. Синхронизация баз данных позволяет хранить данные как централизованно (на одном Сервере или УРМА), так и распределенно (репликация данных из баз различных Серверов и УРМА системы видеонаблюдения). Синхронизация баз данных обеспечивает параллельную работу с базами данных Серверов и УРМА и автоматическое обновление при их изменении.

По умолчанию базы данных ПК Интеллект на Серверах и УРМА не синхронизированы между собой. Как правило, ПК Интеллект настраивается таким образом, что синхронизация всех баз данных осуществляется только с одной централизованной базой данных, размещенной на Сервере администрирования.

Примечание.

В том случае, если одна или несколько баз данных хранятся в формате MS Access, необходимо перед настройкой синхронизации конвертировать базы в формат MS SQL server.

Для настройки синхронизации базы данных Конфигурация программного комплекса Интеллект с базой данных сервера администрирования (или другой базой данных), необходимо выполнить следующие действия:

1. Проверить, работает ли ПО MS SQL Server.
2. Запустить утилиту idb.exe, расположенную в корне директории установки ПК Интеллект (например, C:\Program Files (х86) \Интеллект). На экран будет выведено диалоговое окно утилиты idb.exe.
3. Из списка Выберите источник данных: выбрать пункт Synchro source .
4. Установить флажок Использовать.
5. Нажать кнопку Настроить.
6. На экран будет выведено диалоговое окно Свойства связи с данными . В окне Свойства связи с данными необходимо перейти на вкладку Поставщик данных .
   
7. Из списка Поставщики OLE DB необходимо выбрать пункт Microsoft OLE DB Provider for SQL Server .
8. Нажать кнопку Далее.
9. После нажатия кнопки Далее будет выполнен автоматически переход на вкладку Подключение .
   
10. В строке 1. Выберите или введите имя сервера: данного окна необходимо выбрать из списка или ввести вручную наименование MS SQL сервера, на котором хранится база данных, с которой требуется синхронизировать текущую.
11. В группе 2. Для входа в сервер использовать: необходимо указать тип и указать параметры аутентификации для подключения к MS SQL серверу. Аутентификация на MS SQL сервере осуществляется по учетной записи пользователя, авторизированного в ОС Windows, или по имени пользователя (логину) и паролю, которыми защищено подключение к MS SQL серверу.
    Метод и параметры, используемые для аутентификации на MS SQL сервере, задаются при установке MS SQL сервера.
    В зависимости от метода аутентификации, который требуется использовать для подключения к MS SQL серверу, необходимо указать следующие параметры:
    1. В том случае, если аутентификация на MS SQL сервере осуществляется по учетной записи пользователя в ОС Windows, необходимо установить переключатель в положение учетные сведения Windows NT . При этом необходимо, чтобы в ОС Windows на компьютере, на котором установлен MS SQL сервер и хранится база данных, с которой требуется настроить синхронизацию, была зарегистрирована учетная запись, под которой в текущий момент авторизирован пользователь в ОС Windows на компьютере, с которого выполняется настройка синхронизации.
    2. В том случае, если аутентификация на MS SQL сервере осуществляется по имени пользователя (логину) и паролю необходимо выполнить следующие действия:
       1. Установить переключатель в положение следующие имя и пароль пользователя: .
       2. В поле Пользователь: ввести имя пользователя (логин) для подключения к MS SQL серверу.
       3. В том случае, если доступ к MS SQL серверу защищен паролем, необходимо снять флажок Пустой пароль и в поле Пароль ввести пароль для доступа к базе данных.
12. Нажать кнопку Проверить подключение .
13. При успешном подключении к MS SQL серверу на экран будет выведено окно с сообщением Проверка подключения выполнена .
    
    Необходимо нажать кнопку ОК в окне сообщения, в результате чего окно автоматически будет закрыто.
14. В том случае, если наименование MS SQL сервера и/или параметры аутентификации, используемые для подключения к MS SQL серверу, были указаны неправильно, на экран будет выведено соответствующее сообщение.
    
    Для закрытия окна с сообщением необходимо нажать кнопку ОК . Далее требуется изменить введенные данные и повторно проверить подключение к MS SQL серверу.
15. Из списка Выберите базу данных на сервере выбрать название базы данных, с которой требуется синхронизировать текущую.
16. Нажать кнопку ОК в диалоговом окне Свойства связи с данными. В результате выполнения данного действия окно будет закрыто.
17. Нажать кнопку ОК , расположенную в нижнем правом углу окна утилиты idb.exe.

На этом настройка синхронизации баз данных завершена.

Друзья, всем привет! Рад всех вас видеть у себя в гостях 😉 Сегодня я расскажу, как синхронизировать базы данных WordPress. А так же о том, какие таблицы в базе наиболее важные и как с ними работать.

Эту тему я освещаю не просто так. Как вы помните, я рассказывал о том, как . Очень удобная возможность при разработке сайтов.

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

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

И вот тут-то и нужна синхронизация базы данных. Именно так можно объединить в базе данных и новый дизайн, и новые записи. А уже после, без проблем, перенести готовый сайт обратно на хостинг.

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

Структура базы данных WordPress

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

По большому счёту досконально разбираться во всех таблицах необязательно. Достаточно знать, в каких таблицах находится информация о статьях, комментариях и так далее. Именно эти таблицы имеют ключевое значение при синхронизации.

Итак, рассмотрим ключевые таблицы в базе данных WordPress.

wp_options – содержит все настройки сайта;

wp_posts – все статьи и записи на сайте;

wp_postmeta – вспомогательные данные о статьях и записях на сайте;

wp_comments – комментарии;

wp_commentmeta – вспомогательная информация о комментариях;

wp_term_relationships – связи статей и записей с категориями и тегами;

wp_terms – связи категорий (рубрик) со ссылками;

wp_term_taxonomy – связи категорий, тегов, ссылок;

wp_usermeta – информация обо всех зарегистрированных пользователях;

wp_users – информация об администраторе.

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

Вот теперь, когда общее представление о базе данных WordPress у вас сложилось, можно приступать к цели нашего урока – синхронизации баз данных.

Подготовка к процессу синхронизации

Прежде чем приступить к работе с базой данных, — обязательно сделайте резервную копию. Так как если вы сделаете, что-то не так. То сможете всё восстановить из копии.

Так, вы и процесс поймёте, и сможете создать нужную базу данных на своём компьютере и перенести на хостинг уже готовую БД.

Самое главное не забудьте про резервную копию.

Сравнение баз данных в phpMyAdmin

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

Использовать для этого будем утилиту phpMyAdmin, которая доступна и на хостинге и на локальном сервере.

В качестве сравнения будем использовать базу данных на локальном сервере, которую я использовал в работе над . И базу данных, которая используется у меня на моём блоге.

Для сравнения возьмём одну цифру – количество статей. Так как для таких сайтов, как мой, – это самое ценное. Ну и комментарии, конечно. К тому же эти цифры всегда у вас на виду.

Анализируем тестовый сайт и базу данных:

Для начала посмотрим на количество статей. Сделать это можно в административной панели Вордпресс. Достаточно открыть консоль.

Как видно, на скриншоте, статей на тестовом сайте – 136.

После обновления темы оформления, я успел написать ещё пару статей. И сейчас их уже 138.

Количество статей должно соответствовать количеству записей в таблице wp_posts . Но, если открыть эту таблицу, то записей вы увидите гораздо больше.

Как видите на скриншоте – всего записей 2,245. И среди них и статьи и отдельные записи. А ещё это куча черновиков и прочих записей о картинках и так далее.

Поэтому сразу определить количество статей нереально. Для этого потребуется сделать небольшой запрос с параметрами сортировки.

Открываете базу данных – таблицу wp_posts – переходите на закладку SQL – вводите запрос:

SELECT * FROM `wp_posts` WHERE `post_status` = "publish" AND `post_type` = "post"

Этот запрос говорить о том, что в таблице wp_posts нужно выбрать все записи (* ), где статус – опубликовано (publish ) и это статья (post ).

В итоге получаем 136 записей. Вот теперь эта цифра соответствует количеству статей.

Точно так же сверяется и другая база данных. В моём случае – реальная база с моего блога.

Эти знания помогут вам не потерять ничего важного. И проверить после синхронизации, всё ли прошло успешно.

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

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

Синхронизация баз данных WordPress

Все действия будем делать на локальном сервере. А после готовую базу данных можно импортировать на хостинг.

Шаг 1. Создание двух пустых баз данных

Если возникает вопрос почему две базы, то объясняю, — это нужно для того, чтобы не трогать рабочие базы данных и показать пример с чистого листа.

Первым делом запускаете Денвер и в браузере набираете localhost/tools/ , а далее жмёте на ссылке phpmyadmin .

Шаг 2. Импортируем данные в базу

Итак, я сделал резервные копии баз данных. Одну с тестового сайта, другую с моего блога в интернете. Они понадобятся для импорта содержимого во вновь созданные базы. А далее будут страховкой.

У вас должно быть тоже две базы, которые вы будете синхронизировать.

Теперь нужно импортировать данные из резервных копий в новые базы данных. Для этого выбираете новую базу – откройте закладку «Импорт» — выбираете «файл резервной копии» — нажимаете кнопку «Ок» .

Шаг 3. Синхронизация баз данных

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

Для этого нужно перейти на главную страницу phpMyAdmin и выбрать раздел «Синхронизировать» .

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

После того как пройдёт сравнение. На выбор будет предложено синхронизировать отдельные таблицы, в которых есть изменения, или провести полную синхронизацию.

Если вы хотите синхронизировать отдельные таблицы, то необходимо нажать на буквы S или D . Эти буковки станут серыми, а в окошке ниже вы увидите добавленные таблицы на синхронизацию. После чего вы можете синхронизировать эти таблицы, нажав на кнопку «Применить выбранные изменения» .

В нашем случае подходит именно этот способ, так как нам нужно синхронизировать только статьи, комментарии и метаданные.

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

Вот, и всё. На этом процесс синхронизации окончен. Можно проверять результат. Для наглядного примера, я сменил базу данных на локальном сайте. Если кто забыл, делается это в файле wp-config.php. И теперь можно сравнить количество статей, записей и комментариев. Правда, комментариев на блоге стало немного больше, пока я писал статью.

Статистика по тестовому блогу:

Статистика по рабочему блогу:

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

А теперь советую посмотреть видеоурок, в котором весь процесс синхронизации баз данных я показываю шаг за шагом.

Сегодня на этом всё. Всем желаю хорошего настроения. До встречи в новых материалах. И конечно же, жду ваших комментариев 😉 А полученные знания пригодятся вам при .

Подписывайтесь на новые статьи!

Понятие базы данных. Классификация баз данных (по форме представления информации; по характеру организации данных; по типу используемой модели; по типу хранимой информации; по характеру организации хранения данных и обращения к ним).

База данных (БД) представляет собой совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы и отражающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.

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

Базы данных создаются обычно не для решения какой-либо одной задачи для одного пользователя, а для многоцелевого использования.

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

Базы данных – это специальным образом организованные данные, т.е. системы взаимосвязанных данных, единство и целостность которых поддерживается специальными программными средствами.

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

1.Конечные пользователи. От конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.

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

3. Администраторы БнД – лица, ответственные за создание БнД и его надежное функционирование, за соблюдение регламента доступа к хранимым данным, за развитие БнД (администраторы предметной области, администраторы БД, администраторы приложений).

Классификация БД.

1.По форме представления информации. Центральной компонентой банка данных является база данных, и большинство классификационных признаков относятся именно к ней. По форме представления информации различают визуальные и аудио системы, а также системы мультимедиа . Эта классификация показывает, в каком виде информация хранится в БД и выдается из баз данных пользователям: в виде изображения, звука или имеется возможность использования разных форм отображения информации. Понятие «изображение» здесь используется в широком смысле – это может быть символьный текст, неподвижное графическое изображение (рисунки, чертежи и т.п.), фотографии, географические карты, движущие изображения.

2.По характеру организации данных БД могут быть разделены на неструктурированные, частично структурированные и структурированные . Этот классификационный признак относится к информации, представленной в символьном виде. К неструктурированным БД могут быть отнесены базы, организованные в виде семантических сетей. Частично структурированными можно считать базы данных в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры БД. Только после этого базы данных такого типа могут быть заполнены данными.

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

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

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

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

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

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

Графическое представление сетевой модели представляет собой граф типа «сеть». Входом в такую структуру может являться любая вершина. Каждая вершина может иметь как несколько порожденных, так и несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т. е. между каждой парой типов записей поддерживается отношение 1:М.

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

Особое место среди структурированных систем занимают системы, построенные на использовании инвертированных файлов . Особенность организации данных в них состоит в том, что собственно хранимые данные и информация о связях логически и физически отделены друг от друга. Основные данные в этих системах хранятся в файлах, записи которых могут иметь сложную структуру. Вся управляющая информация сосредоточена в ассоциаторе. Логическая связь между файлами устанавливается посредством компонента ассоциатора, называемого сетью связи. На рис. схематически представлен принцип установления связей в таких системах. Реально, связи устанавливаются не непосредственно с элементами связи, как это изображено на рисунке, а через преобразователь адреса. В системах, построенных на инвертированных файлах, можно передавать связь типа М:М между записями файлов (что не позволяют никакие другие системы). Отделение ассоциативной информации от собственно хранимых данных позволяет изменять связи, не изменяя при этом самих файлов.

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

В системах фактографического типа в БД хранится информация об интересующих пользователя объектах предметной области в виде «фактов» (например, биографические данные о сотрудниках, данные о выпуске продукции производителями и п. т.). В ответ на запрос пользователя выдается требуемая ему информация об интересующем его объекте/объектах или сообщение о том, что искомая информация отсутствует в БД.

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

БД документального типа могут быть организованы по-разному: без хранения и с хранением самого исходного документа на машинных носителях. К системам первого типа можно отнести библиографические и реферативные БД, а также БД-указатели, «отсылающие» к источнику информации. Системы, в которых предусмотрено хранение полного текста документа, так и называются полнотекстовыми.

5. По характеру организации хранения данных и обращения к ним различают локальные (персональные), общие (интегрированные, централизованные) и распределенные базы данных.

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

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

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

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

Различают экстенсиональные (ЭБД) и интенсиональные БД. Интенсиональная база данных (ИБД) строится с помощью правил, определяющих ее содержание, а не с помощью явного хранения данных в БД, как в экстенсиональных БД.

Понятие системы управления базами данных (СУБД). Классификация систем управления базами данных. Классификационные группировки, относящиеся к банку данных в целом.

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

По языкам общения СУБД делятся наоткрытые ,замкнутые исмешанные .

Открытые системы – это системы, в которых для обращения к БД используются универсальные языки программирования. Замкнутые системы имеют собственные языки общения с пользователями БнД.

По числу уровней в архитектуре различают одноуровневые, двухуровневые, трехуровневые системы.

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

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

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

По сфере возможного применения различаютуниверсальные испециализированные , обычно проблемно-ориентированные СУБД.

По «мощности» СУБД делятся на«настольные» и«корпоративные» . Характерными чертами настольных СУБД являются сравнительно невысокие требования к техническим средствам, ориентация на конечного пользователя, низкая стоимость.

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

Наиболее известными из корпоративных СУБД являются Oracle , Informix , Sybase , MS SQL Server, Progress и некоторые другие.

Существует разделение СУБД по поколениям:

1 поколение – основано на иерархической и сетевой модели.

2 поколение – Реляционные системы.

3 поколение – СУБД должны поддерживать сложные структуры данных и более развитые средства обеспечения целостности данных, отвечать требованиям, предъявляемым к открытым системам.

Классификационные группировки, относящиеся к БнД в целом.

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

Основной целью создания коммерческих банков данных является получение прибыли от информационной деятельности.

OLTP- и OLAP-системы: сравнительная характеристика.

Информационные системы различаются по характеру преобладающей обработки информации . В одних, в основном, реализуется большое число достаточно простых запросов (такие системы получили название OLTP (On-Line Transaction Processing) –системы оперативной обработки транзакций . В других, напротив, требуется сложная аналитическая обработка данных (для такого класса систем стал использоваться термин OLAP (On-line Analytical Processing)). Термин OLAP

часто отождествляют с поддержкой принятия решений (DSS (Decision Support Systems) – системы поддержки принятия решения). А в качестве синонима для последнего термина используют Data Warehousing – хранилища (склады) данных, понимая под этим набор организационных решений, программных и аппаратных средств для обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников.

«OLAP в узком смысле» – это системы, которые обеспечивают только выборку данных в различных разрезах, и «OLAP в широком смысле», или просто OLAP, включающей в себя:

поддержку нескольких пользователей, редактирующих БД;

функции моделирования, в том числе вычислительные механизмы получения производных результатов, а также агрегирования и объединения данных;

прогнозирование, выявление тенденций и статистический анализ.

Хранилища данных могут быть разбиты на два типа: корпоративные хранилища данных (enterprise data warehouses) и киоски данных (data marts). Корпоративные хранилища данных содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Киоски данных содержат подмножество корпоративных данных и строятся для отделов или подразделений внутри организации. Киоски данных часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела.

Сравнительные характеристики систем OLTP и OLAP:

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

Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволя­ет хранить данные об объектах предметной области и моделировать связи между ними.

Отношение является важнейшим понятием и представляет собой двумер­ную таблицу, содержащую некоторые данные.

Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.

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

Математически отношение можно описать следующим образом. Пусть даны n множеств D1, D2, D3,..., Dn, тогда отношение R есть множество упорядоченных кортежей , где dk Dk, dk – атрибут, a Dk – домен отношения R.

Рис. Представление отношения СОТРУДНИК

Домен представляет собой множество вcex возможных значений опреде­ленного атрибута отношения. Отношение СОТРУДНИ К включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 – номера всех отделов фирмы, домен 3 – названия всех должностей, домен 4 – даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, напри­мер, числовые или символьные.

Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматривае­мого отношения состоит из 4 элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка табли­цы.

Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения). Мно­жество собственно кортежей отношения часто называют содержимым (телом) отношения.

Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут «ФИО». Ключ может быть состав­ным (сложным), то есть состоять из нескольких атрибутов. Возможны случаи, когда отношение имеет несколько комбинаций ат­рибутов, каждая из которых однозначно определяет все кортежи отно­шения. Все эти комбинации атрибутов являются возможными ключа­ми отношения. Любой из возможных ключей может быть выбран как первичный.

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

Ключи обычно используют для достижения следующих целей:

1)исключения дублирования значений в ключевых атрибутах;

2)упорядочения кортежей;

3)ускорения работы с кортежами отношения;

4)организации связывания таблиц.

Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ .

С помощью внешних ключей устанавливаются связи между отношения­ми. Например, имеются два отношения СТУДЕНТ (ФИО,Группа, Специальность) и ПРЕДМЕТ (Назв.Пр,Часы), которые связаны отношением СТУДЕНТ_ ПРЕДМЕТ(ФИО, Назв.Пр,Оценка) (рис.). В связующем отношении атрибуты ФИО и Назв.Пр образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключа­ми других отношений.

Рис. Связь отношений

Условия, выполнение которых позволяет таблицу считать отношением.

1. Вce строки таблицы должны быть уникальны, то есть не может быть строк с одинаковыми первичными ключами.

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

3. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.

4. Порядок размещения строк в таблице может быть произвольным. Наиболее часто таблица с отношением размещается в отдельном файле.

Если задаваемое таблицей отношение имеет ключ, то считается, что таб­лица тоже имеет ключ, и ее называют ключевой или таблицей с ключевы­ми полями.

Основные виды связей между отношениями и их характеристика. Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные свя­зи. Рассмотрим наиболее часто встречающиеся бинарные связи.

При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помо­щьюключа связи . Ключ связи состоит из одного или нескольких полей, которые в данном случае называют полями связи (ПС).

Суть связывания состоит в установлении соответствия полей связи основ­ной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.

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

один – один (1:1);

один – много (1:М);

много – один (М:1);

много – много (М:М или M:N).

Табл. Характеристика видов связей таблиц

Связь вида 1:1. Связь вида 1:1 образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми. Поскольку значения в ключевых полях обеих таблиц не повторяются, обеспечивается взаимнооднознач­ное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными.

Связь вида 1:М. Связь 1:М имеет место в случае, когда одной записи основной таблицы соответствует несколько записей вспомогательной таблицы.

Связь вида М:1. Связь М:1 имеет место в случае, когда одной или нескольким записям основ­ной таблицы ставится в соответствие одна запись дополнительной таблицы.

Связь вида М: М. Самый общий вид связи М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.

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

Теоретико-множественные и специальные операции реляционной алгебры.

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

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

Объединением двух отношении называется отношение, содержащее множество кортежей, принадлежащих либо первому, либо второму исходным отношениям, либо обоим отношениям одновременно.

Пусть заданы два отношения R 1 = { r 1 } , R 2 = { r 2 }, где r 1 и r 2 – соответственно кортежи отношений R 1 и R 2 , то объединение R 1 R 2 = { r | r R 1 Vr R 2 }. Здесь r – кортеж нового отношения, V – операция логического сложения «ИЛИ».

Пересечением

R 3 = R 1 R 2 ={ r | r R 1 ^ r R 2 }, здесь ^ – операция логического умножения (логическое «И»).

Разностью

Пересечением отношений называется отношение, которое содержит множество кортежей, принадлежащих одновременно и первому и второму отношениям R 1 и R 2:

R 3 = R 1 R 2 ={ r | r R 1 ^ r R 2 }, здесь ^ – операция логического умножения («И»).

Разностью отношений R 1 и R 2 называется отношение, содержащее множество кортежей, принадлежащих R 1 и не принадлежащих R 2:

R 5 = R 1 \ R 2 = { r | r R 1 ^ r R 2 }

Сцеплением, пликонкатенацией, кортежей с = и q = .., q m > называется кортеж, полученный добавлением значений второго в конец первого. Сцепление с и q обозначается как (с, q).

(с, q) = <с 1 с 2 , ... , с n , q 1 , q 2 , .... q m >

Здесь n – число элементов в первом кортеже с, m – число элементов во втором кортеже q.

Все предыдущие операции не меняли степени или арности отношений – это следует из определения эквивалентности схем отношений. Операция декартова произведения меняет степень результирующего отношения.

Расширенным декартовым произведением отношения R, степени n со схемой S R1 =(А 1 ,А 2 ...,А n) и отношения R 2 степени m со схемой S R2 =(В 1 ,В 2 , ... , В m) называется отношение R 3 степени n+m со схемой

S R3 = (А 1 , А 2 , ... , А n , В 1 , В 2 , ..., В m), содержащее кортежи, полученные сцеплением каждого кортежа r отношения R 1 с каждым кортежем q отношения R 2 .

То есть если R 1 = { r }, R 2 = { q }

R 1 R 2 = {(r, q) | r R 1 ^ q R 2 }.

Специальные операции реляционной алгебры.

Первой специальной операцией реляционной алгебры является горизонтальный выбор, илиоперация фильтрации, илиоперация ограничения отношений.

Пусть а – булевское выражение, составленное из термов сравнения с помощью связок И (^), ИЛИ (V), НЕ (–) и, возможно, скобок. В качестве термов сравнения допускаются:

а) терм А ос а, где А – имя некоторого атрибута, принимающего значения из домена D; а – константа, взятая из того же домена D, a D; ос – одна из допустимых для данного домена D операций сравнения;

б) терм А ос В, где А, В – имена некоторых Q-сравнимых атрибутов, то есть атрибутов, принимающих значения из одного и то же домена D.

Тогда результатом операции выбора, или фильтрации, заданной на отношении R в виде булевского выражения, определенного на атрибутах отношения R, называется отношение R[G], включающее те кортежи из исходного отношения, для которых истинно условие выбора или фильтрации:

R = {r | r R ^ G(r) = "Истина"}

Следующей специальной операцией является операция проектирования . Пусть R – отношение, S R = (А 1 , ... , А n) – схема отношения R. Обозначим через В подмножество [ Аi]; В { Аi } При этом пусть В 1 – множество атрибутов из { Ai }, не вошедших в В. Если В = {A 1 j.A 2 j .....A k j}, В 1 = {А 1 j,А 2 j,...,А k j}и r = <а 1 j, а 2 j,...,а k j >, а k j А k ji, то r [В], s= < a 1 j, а 2 j, ... , а m , > ; а m , А m j

Проекцией отношения R на набор атрибутов В, обозначаемой R[B], называется отношение со схемой, соответствующей набору атрибутов В S R | B | = В, содержащему кортежи, получаемые из кортежей исходного отношения R путем удаления из них значений, не принадлежащих атрибутам из набора В.

По определению отношений все дублирующие кортежи удаляются из результирующего отношения.

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

Следующей специальной операцией реляционной алгебры является операция условного соединения.

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

Пусть R = {r}, Q = { q } – исходные отношения, S R , S Q – схемы отношений R и Q соответственно.

S R = (А 1 , А 2 , ... , A k): S Q = (В 1 В 2 , ... , B m), где А, В, – имена атрибутов в схемах отношений R и Q соответственно. При этом полагаем, что заданы наборы атрибутов А и В

А { А i } , j=1,k ; В { B j } j=1,m , и эти наборы состоят из Q-сравнимых атрибутов.

Тогда соединением отношений R и Q при условии р будет подмножество декартова произведения отношений R и Q, кортежи которого удовлетворяют условию р, рассматриваемому как одновременное выполнение условий:

r.A j Q j В i , : i=l,k, где k – число атрибутов, входящих в наборы А и В, а Q j – конкретная операция сравнения.

A j Q j В i D i Qi – i-й предикат сравнения, определяемый из множества допустимых на домене D i операций сравнения.

R [ Р ] Q = { r.q) | (r. q) | r.A Q j q.B j - «Истина», i=l,k}

Последней операцией, включаемой в набор операций реляционной алгебры, является операция деления.

Для определения операции деления рассмотрим сначала понятие множества образов.

Пусть R – отношение со схемой S R = (A1, A 2 ,..., A k);

Пусть А – некоторый набор атрибутов А { А i } i=l,k , А 1 –набор атрибутов, не входящих в множество А.

Пересечение множеств А и А 1 пусто: А А 1 = 0; объединение множеств равно множеству всех атрибутов исходного отношения: A А 1 = S R .

Тогда множеством образов элемента у проекции R[А] называется множество таких элементов у проекции R , для которых сцепление (х, у) является кортежами отношения R, то есть

QA(x) = {у | у R ^ (х, у) R} – множество образов.

Дадим теперь определение операции деления. Пусть даны два отношения R и Т соответственно со схемами: S R = (А 1 , А 2 , ... , A k); S T =-(В 1 , В 2 , ... , В m);

А и В – наборы атрибутов этих отношений, одинаковой длины (без повторений);

А S R ; В S T . Атрибуты А 1 – это атрибуты из R, не вошедшие в множество А.

Пересечение множеств А А 1 = – пусто и A А 1 = S R . Проекции R[A] и Т[В] совместимы по объединению, то есть имеют эквивалентные схемы: S R | A |~ S T [B].

Тогда операция деления ставит в соответствие отношениям R и Т отношение

Q = RT, кортежи которого являются теми элементами проекции R, для которых Т[В] входит в построенные для них множество образов:

RT = {r | r R ^ Т[В] (у | у R [А] ^ (r, у) R } }.

Операция деления удобна тогда, когда требуется сравнить некоторое множество характеристик отдельных атрибутов.

Различные архитектурные решения, используемые при реализации многопользовательских СУБД. Централизованная архитектура.

Понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. Важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием ПО.

Централизованная архитектура. При использовании этой технологии база данных, СУБД и прикладная программа (приложение) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.1). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске компьютера.

На том же компьютере установлены СУБД и приложение для работы с БД.

Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.

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

Рис. 1. Централизованная архитектура

Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle. Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.

Технология с сетью и файловым сервером (архитектура «файл-сервер»). Технология «клиент – сервер». Трехзвенная (многозвенная) архитектура «клиент – сервер».

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

Рис. 2. Архитектура "файл-сервер".

Работа построена следующим образом:

БД в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).

Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.

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

При необходимости данные отправляются назад на файловый сервер с целью обновления БД.

Результат СУБД возвращает в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

В рамках архитектуры "файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access. Основные недостатки данной архитектуры:

При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает.

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

Используется навигационный подход, ориентированный на работу с отдельными записями.

Низкий уровень безопасности – хищение и нанесение вреда, внесение ошибочных изменений.

Недостаточно развитый аппарат транзакций служит источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений.

Технология "клиент – сервер". Использование технологии "клиент - сервер " предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).

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

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

Рис. 3. Архитектура "клиент – сервер".

БД в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.

СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Функции приложения-клиента: посылка запросов; интерпретация запросов; представление результатов.

Функции серверной части: прием запросов; обеспечение системы безопасности и разграничение доступа; управление целостностью БД; реализация стабильности многопользовательского режима работы.

В архитектуре "клиент - сервер " работают так называемые "промышленные" СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу ИС масштаба среднего и крупного предприятия, организации, банка (MS SQL Server, Oracle, InterBase и т.д.).

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

Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой "файл-сервер":

Существенно уменьшается сетевой трафик.

Уменьшается сложность клиентских приложений (большая часть нагрузки ложится на серверную часть), а, следовательно, снижаются требования к аппаратным мощностям клиентских компьютеров.

Наличие специального программного средства – SQL-сервера – приводит к тому, что существенная часть проектных и программистских задач становится уже решенной.

Существенно повышается целостность и безопасность БД.

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

Трехзвенная (многозвенная) архитектура "клиент – сервер". Трехзвенная (в некоторых случаяхмногозвенная )архитектура представляет собой дальнейшее совершенствование технологии "клиент - сервер ". Рассмотрев архитектуру "клиент - сервер ", можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. Втрехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер.Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей.

Итак, в результате работа построена следующим образом:

БД ввиде набора файлов нах-ся на жестком диске специально выделенного компьютера(сервера сети).

СУБД располагается также на сервере сети.

Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика).

Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.

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

Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.

СУБД инкапсулирует внутри себя все сведения о физической структуре БД.

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

Сервер приложений возвращает результат в клиентское приложение (пользователю).

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Понятие целостности базы данных. Логическая и физическая целостность базы данных. Классификация ограничений целостности.

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

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

Целостность данных – неотъемлемое свойство базы данных, и ее обеспечение является важнейшей задачей проектирования БнД. Це­лостность данных описывается набором специальных предложений, называемых ограничениями целостности. Ограничения целостнос­ти представляют собой утверждения о допустимых значениях отдель­ных информационных единиц и связях между ними. Эти ограничения определяются в большинстве случаев особенностями предметной области. При выполнении операций над БД проверяется выполнение огра­ничений целостности. Ограничения целостности могут классифицироваться по разным признакам (рис.).

Логи­ческая целостность – состояние БД, характеризующееся отсутстви­ем нарушений ограничений целостности, присущих логической мо­дели данных (т.е. неявных ограничений), и явных ограничений, за­данных декларативным или процедурным путем.Физическая целостность – от­сутствие нарушений спецификаций схемы хранения, а также физических разрушений данных на носителе.

Для контроля целостности БД применяется также механизм триг­геров. Триггер – это действие, которое активизируется при наступле­нии указанного события (вставки, удаления, обновления записи). Триггеры специфицируются в схеме базы данных. Более широким понятием по отношению ктриггеру является по­нятиехранимая процедура. Хранимые процедуры описывают фраг­менты логики приложения, хранятся и исполняются на сервере, что позволяет улучшать характеристики производительности.

Целостность данных – неотъемлемое свойство базы данных, и ее обеспечение является важнейшей задачей проектирования БД. Целостность данных описывается набором специальных предложений, называемых ограничениями целостности. Ограничения целостности представляют собой утверждения о допустимых значениях отдельных информационных единиц и связях между ними. Эти ограничения определяются в большинстве случаев особенностями предметной области. При выполнении операций над БД проверяется выполнение ограничений целостности. Ограничения целостности могут классифицироваться по разным признакам (рис. ниже).

Различают логическую и физическую целостность БД. Логическая целостность – состояние БД, характеризующееся отсутствием нарушений ограничений целостности, присущих логической модели данных (т.е. неявных ограничений), и явных ограничений, заданных декларативным или процедурным путем. Физическая целостность – отсутствие нарушений спецификаций схемы хранения, а также физических разрушений данных на носителе.

9. Проблема целостности базы данных. Транзакции и блокировки. Синхронизация работы пользователей.

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

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

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

Транзакции. Транзакция представляет собой законченную совокупность действий над БД, которая переводит ее из одного целостного в логичес­ком смысле состояния в другое. К транзакциям предъявляется набор требований, известный под названием ACID (Atomicity, Consistency, Isolation, Durability). Эти требования вытекают из определения транзакции.

Атомарность (atomicity). Транзакция представляет собой некоторый набор законченных действий. Система обеспечивает их выполнение по принципу «все или ничего» - либо выполняются все действия, тогда транзакция «фиксируется»; либо, если возможность выполнить все действия отсутствует, например, в случае сбоев, транзакция «отка­тывается» назад, а БД остается в исходном состоянии.

Согласованность (consistency). Предполагается, что в результате выполнения транзакции система переходит из одного корректного состояния в другое.

Изолированность (isolation). При выполнении транзакции данные могут временно находиться в несогласованном состоянии. Такие данные не должны быть видны другим транзакциям, пока изменения не будут завершены (т.е. пока вес модификации не будут формально зафиксированы).

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

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

Блокировки накладываются в соответствии с правилами совмес­тимости блокировок, исключающими конфликты чтение-запись, за­пись-чтение и запись-запись.

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

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

Некоторые системы предусматривают динамическую схему бло­кировки, заключающуюся в том, что сначала транзакция блокирует большую информационную единицу, например страницу.

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

Синхронизация работы пользователей. Тиражирование – используемая в РБД (распред. базы данных) технология, предусмат­ривающая поддержку копий всей БД или ее фрагментов в нескольких узлах сети. Копия базы данных, являющаяся членом набора других копий, которые могут быть синхронизированы между собой, называ­ется репликой. Копии БД обычно приближены к местам использования информации. Как синоним понятию «тиражирование» использу­ется термин «репликация». Процесс обновления реплик, при котором происходит передача обновляемых записей и других объектов и согласование дублирую­щихся данных, называется синхронизацией . Обмен данными между репликами может быть как односторонним, так и двусторонним. Кро­ме того, возможна синхронизация реплик под управлением синхро­низатора. В отличие от собственно распределенных систем, в которых, при выполнении распределенных запросов реализуется протокол двухфазной фиксации, в системах с реплицированными базами данных обычно использует­ся инструментарий асинхронной репликации.

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

Начало

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

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

Два дня поисков подходящих средств в Internet ни к чему не привели. Много рекламы, мало информации, бешеные цены и, что уже просто надоело, "очень удобные средства для администратора с помощью которых очень легко исправлять коллизии". Ну нет у меня администратора, который мог бы следить за каждой синхронизацией (проходящей пару раз в день) и исправлять коллизии! Что же делать?

Ладно, попытка - не пытка, я решил поискать что-нибудь по алгоритмам, используемым при репликации баз данных.
НИЧЕГО.
Абсолютно ничего!
Если я плохо искал и кто-то мне покажет интересные в этом плане и свободно доступные материалы, я буду рад! Но по-видимому это khow-how фирм-производителей или до сих пор не разработано каких-то общеизвестных алгоритмов на эту тему. Лезу в Дейта. Ничего. Так, рассуждения на тему распределенных БД, но того, что мне нужно, нет.

Так или иначе, но, помолясь, я решил обмозговать это все сами посмотреть, что получится. Обмозговал. Помучился. Написал. Исправил. Исправил. Еще раз исправил. Заработало. Сглючило. Исправил - перестало глючить. Пока работает. Мне нравится. Работает! Проблемы, конечно, есть. И некоторые весьма приличные. Но... но все таки оно работает!

Так что я решил рассказать, кому интересно, то что я думал и что делал.

Варианты, терминология

Все термины самопальные, так что не обижайтесь, если что-то покажется глупым. :)

Синхронизация - процесс при котором базы данных приводятся в идентичное состояние. Если кто-то придумает определение получше я его выслушаю.

Сначала расклассифицируем синхронизацию по направленности и времени проведения.

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

Если синхронизация должна проводиться немедленно после внесения изменений в БД, то такую синхронизацию назовем синхронизацией в реальном времени . А если изменения из одних баз должны вноситься в другие базы ПОЗЖЕ, по команде/событию/etc - то это будет отложенная синхронизация .

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

Далее. Если при проведении синхронизации изменения могут выявляться и производиться отдельными полями записей, то это синхронизация по полям . Если же "единицей" проведения синхронизации является запись - то это синхронизация по записям .

Это вроде бы все понятно интуитивно, но хочется строгости и не хочется размолвок из-за различий в терминологии.

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

Отсекаем лишнее

Итак, я упомянул несколько вариантов синхронизации и теперь от "лишних" следует избавиться. :) Мы не будем рассматривать синхронизацию в реальном времени это все-таки довольно экзотическая задача. Мы рассмотрим одностороннюю синхронизацию, но очень коротко - это довольно простая задача, ее можно решить без коллизий (по крайней мере, мне так кажется, хотя я могу и ошибаться). Ясно, что односторонняя синхронизация легко реализуется любым методом двухсторонней (по журналу или по текущему состоянию), но без множества проблем, присущих двусторонней синхронизации. И конечно, основная наша цель - это двусторонняя отложенная синхронизация.

Идентификация записей

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

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

1. Можно ввести в каждую таблицу дополнительное поле - номер БД, в которой эта запись была создана впервые (DBID). При этом, очевидно, ID уже не будет являться первичным ключом, вместо этого первичным ключом будет пара (DBID, ID). Следует заметить, что из-за этого данное решение не слишком привлекательно
2. Можно сделать первичным ключом строку специального формата, например XXXX-YYYY-ZZZZZZZZ, где XXXX - это идентификатор базы данных, где запись была создана впервые, YYYY - идентификатор таблицы, ZZZZZZZZ - идентификатор записи внутри конкретной таблицы конкретной БД. Такое решение является хорошо масштабируемым, позволяет "запихать" в ID много дополнительной информации, но у него тоже есть минусы. Во-первых, некоторая избыточность информации. Во-вторых, более сложный механизм генерации таких ID. И еще, неплохо было бы ограничить возможные значения ID данным форматом. Это тоже заботы.
3. На мой взгляд, для InterBase лучшим вариантом является следующий - ID для всех таблиц генерируется обычным триггером, выбирающим значения из генератора. При этом начальное значение генератора различно для разных БД, за счет чего обеспечится уникальность ID по всем БД. Данный подход характерен для InterBase. Применение его для других СУБД может быть ограничено невозможностью задать начальное значение для счетчика автоинкрементных полей.

Ясно, что я выбрал третий вариант. :) Остается еще один вопрос - тип данных для ID. Ясно, что есть для ID использовать INT64 (NUMERIC(18)), то вопрос с доступным диапазоном номеров не встает - диапазон огромен. Но к сожалению, есть некоторые проблемы, мешающие это сделать. Дело в том, что до сих пор в Delphi поддержка полей Int64 несколько хромает. Это связано как с недоработками компонент доступа к данным (IBX, FIBPlus), так и с изначальным отсутствием в классе TField поддержки полей Int64.

В то же время, если мы внимательно посмотрим на диапазон INTEGER, то обнаружим, что при

• использовании только положительных значений
• использовании единственного генератора на все таблицы БД
• ежедневном создании в системе 10000 записей

нам хватит диапазона INTEGER на 27 лет работы системы из 21 БД. При этом начальные значения генераторов разных БД будут определяться как DBID * 100000000. Для большинства систем это вполне нормальные показатели.

Коллизии

В этом разделе мы рассмотрим возможные варианты изменений в базе данных и отметим, в каких случаях вероятно возникновение коллизий. Разделим все вносимые изменения на два класса - изменения, вносимые в одиночные независимые таблицы и вносимые в таблицы, связанные отношениями FOREIGN KEY.

Кроме того, коллизии могут быть вызваны за счет работы триггеров и ограничений прикладного характера.

Изменения в одиночных таблицах

В таблицу добавляется новая запись

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

Ну, может еще стоит отметить, что если сразу после синхронизации эти записи были удалены из исходной БД, то при следующей синхронизации они НЕ должны восстановиться. :) Впрочем, это скорее, относится к следующему подразделу:

Причиной коллизии могут стать ограничения типа UNIQUE. Поясняю. Пусть есть 2 БД: A и B. На таблицу (Table1) наложено ограничение UNIQUE(Field1). Пусть в начальный момент времени в обоих базах НЕТ записей, у которых Field1 = Value1. Добавим такую запись сначала в A, а затем в B. Ошибок не возникает - ограничение UNIQUE не нарушено. Теперь пытаемся синхронизировать эти БД. По логике вещей, мы должны создать в каждой БД по 1й записи. Но не можем, так как это вызовет нарушение ограничения. Конечно, при условии того, что данные были введены верно и модель построена правильно, это должны быть ОДИНАКОВЫЕ (по предметным полям) записи, они должны описывать одну сущность. Но нам от этого не легче - коллизия возникла и ее надо разрешать. Разрешить ее можно удалением записи из одной базы и повторным проведением синхронизации.

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

В общем, подобные "логические" коллизии практически неотслеживаемы. И это очень печально.

Из таблицы удаляется запись

После проведения синхронизации эта запись должна удалиться, если она там есть, из других БД. Опять-таки, возможны "логические" коллизии - допустим, триггер проверяет наличие хотя бы одной записи, у которой Field1 = Value1.Сначала в обоих БД было по две такие записи. В обоих базах удалим по одной записи. При этом ошибок не будет, так как остается вторая. Но если мы удалили в разных базах разные записи, то после синхронизации возникнет ошибка, так как в итоге в базах не окажется ни одной записи Field1 = Value1. В случае такого рода ограничений, опять-таки, по-видимому, без администратора, хорошо знакомого со структурой БД и способного исправить такие коллизии ничего не выйдет:(.

В таблице изменяются некоторые поля записи

После проведения синхронизации в других базах эта запись должна измениться аналогичным образом.

Первая и очень вероятная коллизия заключается в одновременном изменении записи в разных БД. Эта коллизия имеет два варианта - если изменяются одни и те же поля и если изменяются разные поля.

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

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

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

Изменения в связанных таблицах

Будем рассматривать коллизии при синхронизации таблиц TableA и TableB. TableB имеет внешний ключ (FOREIGN KEY), ссылающийся на TableA. Тогда записи таблицы A будут родительскими, а соответствующие записи таблицы B - дочерними.

Создается новая родительская запись или новая дочерняя запись к существующей родительской

Создается новая родительская запись и дочерние к ней

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

Удаляется дочерняя запись

Никаких особенностей нет, дополнительных проблем из-за связанности таблиц не возникает.

Удаляется родительская запись и дочерние

В результирующей БД должны удалиться сначала дочерние записи, затем родительская.

1. В базе А создается дочерняя запись, в базе В удаляется родительская
2. В базе А дочерняя запись передается от родительской записи 1 к родительской записи 2, в базе В удаляется родительская запись 2

Циклы FOREIGN KEY

Влияние триггеров

Синхронизация по журналу - общие принципы

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

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

Для синхронизации двух БД на каждой из них повторяют все действия, произведенные в другой БД, извлекая их по очереди из журнала. Отсюда следует одно из преимуществ синхронизации по журналу - нет необходимости в установлении соединения с БД - журнал, выведенный в отдельный файл можно передать по "floppynet" :) Необходимо только тщательно отмечать, какие записи журнала еще не передавались. Эта проблема усложняется при наличии нескольких синхронизируемых БД - нужно запоминать, какая последняя запись журнала была передана в каждую из БД.

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

Если одна и та же запись изменялась несколько раз подряд, то можно либо хранить все промежуточные изменения, либо "склеить" эти изменения в одно. Это снизит размер журнала, но может привести к лишним коллизиям.

Для синхронизации по журналу характерно увеличение хранимых данных пропорционально количеству изменений в цикле синхронизации, и скорость синхронизации также пропорциональна количеству изменений в цикле синхронизации.

Следует также упомянуть, что на базе журнала можно построить службу отката состояния БД практически на любой момент (если только соответствующие данные не были удалены из журнала).

Синхронизация по журналу реализуется достаточно просто, но очевидно, что коллизии при этом неизбежны. Для иллюстрации этого предлагаю вам следующую аналогию. Представьте себе, что у вас есть 2 комнаты, в которых расположены ящики. У вас есть робот, который можно запрограммировать на перемещение ящиков. В начальный момент ящики в комнате расположены одинаково. Вы подаете роботу команды и он перемещает ящики. Ваш напарник подает команды другому роботу во второй комнате. После этого вы приказываете роботам поменяться местами и повторить все действия, начиная с начального момента. Очевидно, что это может привести к неприятностям - в первой комнате робот передвигал ящик №5, но во второй комнате его не оказалось на месте, в первой он подвинул ящик №54 в угол, но во второй угол оказался занят.

При этом следует отметить, что удачное приложение журнала 2 в БД 1 еще не означает, что без ошибок отработает журнал 1 в БД 2.

Преимущества

• Нет необходимости в установке соединения
• Можно вернуть БД на любой момент в прошлом
• Сравнительная простота реализации
• Высокая скорость синхронизации - пропорциональна кол-ву изменений за цикл

Недостатки

• Большие объемы хранимых данных - пропорциональны кол-ву изменений за цикл
• Коллизии практически неизбежны

Синхронизация по текущему состоянию - общие принципы

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

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

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

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

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

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

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

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

Сведем рассмотренные нами преимущества и недостатки в единый список.

Преимущества

• Хорошие возможности по исправлению коллизий

Недостатки

• Низкая скорость синхронизации - пропорциональна кол-ву всех записей
• Необходимо соединение с обоими БД
• Для всех записей вводятся дополнительные поля - сравнить с журнальной синхронизацией толком нельзя

Синхронизация независимых наборов таблиц

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

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

В такой схеме коллизии практически исключены - потоки обновлений базы не пересекаются. Реализовывать такую схему можно практически любым способом без особых проблем.

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

Продолжение следует...

Во второй части мы перейдем собственно к моему решению - реализации двусторонней синхронизации по текущему состоянию БД.