Основные преимущества такого решения - повышение надежности системы (за счет контролируемого дублированмя данных) и увеличение ее производительности из-за существенного снижения сетевого трафика. Причем для уменьшения объема передаваемых данных обычно реплицируется не полный образ таблицы (или ее подмножества), а только информация об изменениях, происшедших с момента последней репликации.
Надо отметить, что асинхронная репликация не делает линии связи более надежными или скоростными. Она лишь перекладывает задачи трансляции данных и обеспечения их целостности «с плеч» прикладной программы и пользователя на системный уровень.
Асинхронная репликация, в отличие от 2РС, не гарантирует полной синхронности информации на всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно небольшой интервал времени, величина которого определяется быстродействием соответствующего канала связи. Для большинства задач кратковременное наличие устаревших данных в удаленных узлах не критично и вполне допустимо.
Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность информации, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.
Все современные серверы БД используют блокировки, чтобы обеспечить параллелизм в многопользовательской среде. Речь может идти о блокировках на уровне страниц, строк или таблиц, причем характер используемой блокировки чаще всего определяется в момент описания таблиц. Действительно, пользователи и разработчики корпоративных информационных систем все больше внимания уделяют эффективности базовой СУБД. В частности, речь идет о способах реализации систем блокировки, которые в значительной степени влияют на качество исполнения проектов. Система блокировок синхронизирует доступ пользователей к базе данных, а в идеале гарантирует непротиворечивость данных и истинность результатов выполнения запросов. В то время как один пользователь блокирует область базы данных, например, для просмотра и·возможной модификации данных, последние должны быть защищены от воздействия со стороны других пользователей, возможно пытающихся вносить изменения в той же области данных.
Задача масштабирования рано или поздно встает в любой организации, и это вполне объяснимо. Никто и никогда не покупает аппаратуру про запас, с большими резервами по вычислительной мощности. В то же время объемы хранимых данных и количество реально работающих приложений имеют тенденцию к неуклонному увеличению. Поэтому лучше всего изначально остановить свой выбор на такой аппаратной конфигурации, которая в дальнейшем будет легко наращиваться и развиваться.
В настоящее время этому требованию в наибольшей степени отвечают компьютеры с симметричной многопроцессорной (SMP) или массивно-параллельной (МРР) архитектурой, на которых при увеличении количества процессоров обеспечивается практически линейный рост производительности. Обработка нескольких запросов, вложенных циклов внутри одного запроса, загрузка и сортировка данных, создание индексов и т.д. - все это выполняется параллельно на различных процессорах. Более того, одновременно реализуется эффективная динамическая балансировка загрузки системных ресурсов (процессоров, оперативной и дисковой памяти).
Виртуальным-процессором (ВП) называется процесс сервера баз данных. ВП можно сравнить с операционной системой - поток по отношению к нему выступает как процесс, подобно тому как сам ВП является процессом с точки зрения операционной системы.
В отличие от операционной системы, которая должна обеспечивать выполнение произвольных процессов, ВП подразделяются на несколько классов, каждый из которых спроектирован для наиболее оптимального выполнения задач определенного вида. Например, ВП CPU работают на потоки обслуживания клиентов, реализующие оптимизацию и логику выполнения запросов; ВП АIO выполняют операции асинхронного обмена с диском; ВП TLI контролируют сетевое взаимодействие.
Сервер поддерживает очереди потоков для каждого класса ВП. Как только ВП освобождается, он выбирает из очереди следующий поток, тем самым достигается равномерная загрузка. Переключение же ВП с одного потока на другой выполняется значительно быстрее, чем переключение ОС с одного процесса на другой. Кроме того, многопотоковая архитектура способствует более рациональному использованию ресурсов ОС, поскольку потоки разделяют ресурсы ВП, на котором они выполняются, - память, коммуникационные порты, файлы.
Начальное число ВП каждого класса задается в конфигурационном файле. Но если потребности в каких-то видах увеличиваются, то инструменты администрирования позволяют динамически, не останавливая сервер, запустить дополнительные ВП. Например, если растет очередь потоков к ВП CPU, то можно увеличить их число. Точно так же возможно добавление виртуальных процессоров обмена с дисками, сетевых процессоров.
Разделение данных между виртуальными процессорами и потоками сервера реализовано на основе разделяемой памяти - механизма, обеспечиваемого операционной системой. Разделение данных позволяет:
- снизить общее потребление памяти, поскольку участвующим в разделении процессам, то есть виртуальным процессорам, нет нужды поддерживать свои копии информации, находящейся в разделяемой памяти;
- сократить число обменов с дисками, потому что буферы ввода-вывода сбрасываются на диск не для каждого процесса в отдельности, а образуют один общий для всего сервера баз данных пул; виртуальный процессор зачастую избегает выполнения операций ввода с диска, поскольку нужная таблица уже прочитана другим процессором;
- организовать быстрое взаимодействие между процессами; через разделяемую память, в частности, обмениваются данными потоки, участвующие в параллельной обработке сложного запроса; разделяемая память используется также для организации взаимодействия между локальным клиентом и сервером.
Программное обеспечение для работы с базами данных используется на персональных компьютерах уже довольно давно. К сожалению, эти программы либо были элементарными диспетчерами хранения данных и не имели средств разработки приложений, либо были настолько сложны и трудны, что даже хорошо разбирающиеся в компьютерах люди избегали работать с ними до тех пор, пока не получали полных, ориентированных на пользователя приложений.
Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.
Система управления базами данных предоставляет вам возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в Microsoft Access. В практике, как правило, необходимо решать и задачи с использованием электронных таблиц и текстовых процессоров. Например, после подсчета или анализа данных необходимо их представить в виде определенной формы или шаблоны. В итоге пользователю приходится комбинировать программные продукты для получения необходимого результата. В этом смысле все существенно упростят возможности, предоставляемые Microsoft Access.
СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.
При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.
Данная СУБД была выбрана по следующим причинам:
- простота средств реализации,
- легкость освоения инструментарием разработчика (VBA),
- наглядность визуализации информации.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
- загрузка модулей по требованию;
- оптимизация дерева вызовов;
- использование файлов MDE;
- автоматическая поддержка компилированного состояния;
- использование библиотек Windows API;
- индивидуальная настройка системы;
- эффективное использование индексов;
- встроенный оптимизатор запросов.
Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:
- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);
- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);
- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);
- много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).
Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.