код репликации access это

Иллюстрированный самоучитель по Microsoft Access 2002

Свойства полей таблицы

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

Кроме того, для большинства типов данных существует свойство Обязательное поле (Required), которое определяет необходимость ввода данных в это поле..

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

Свойство Формат поля (Format) указывает формат отображения данных из поля в режиме Таблицы. Для определения формата полей текстового типа используются специальные символы форматирования. Для числовых полей значение формата можно выбрать из раскрывающегося списка. Для логических полей можно выбрать из списка следующие варианты: Да/Нет (Yes/No), Истина/Ложь (True/False), Вкл/Выкл (On/Off).

(Форматы полей мы будем подробно рассматривать в разд. «Форматы отображения данных» этой главы.)

С помощью свойства Маска ввода (Input Mask) указывается маска, позволяющая автоматизировать проверку ввода символов в поле. Она применяется к таким полям, как номер телефона, дата и т. д. Задавать маску ввода можно вручную или с помощью Мастера.

(К маскам ввода мы еще вернемся в разд. «Форматы отображения данных» этой главы.)

Свойство Индексированное поле (Indexed) определяет, является ли данное поле индексированным, и если является, то в каком режиме. Существуют два режима индексирования: Совпадения допускаются (Duplicates OK) и Совпадения не допускаются (No duplicates). В первом случае поле может содержать повторяющиеся значения, во втором – нет.

Для большинства типов полей определено свойство Значение по умолчанию (Default Value). В этом свойстве указывается значение, автоматически добавляемое в поле для каждой новой записи, если это значение не введено пользователем.

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

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

В табл. 2.2-2.4 приводятся свойства, специфичные для полей определенного типа.

Таблица 2.2. Дополнительные свойства текстового поля и поля Memo.

Таблица 2.3. Дополнительные свойства полей числового и денежного типа.

Таблица 2.4. Дополнительные свойства полей типа Счетчик.

Источник

Введение в использование типов данных и свойств полей

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

В этой статье

Общие сведения

Иногда типы данных могут показаться неочевидными, например в поле с типом данных «Текст» могут храниться данные, состоящие из текста и чисел. Но в поле с типом данных «Число» могут храниться только числовые данные. Поэтому вам нужно знать, какие свойства используются для каждого типа данных.

Тип данных поля определяет много других важных характеристик поля, в частности:

форматы, которые можно использовать в поле;

максимальный размер значения в поле;

способ использования поля в выражениях;

возможность индексирования поля.

В зависимости от способа создания нового поля тип данных поля может быть задан заранее или его можно выбрать. Например, если при создании поля в режиме таблицы вы:

используете существующее поле из другой таблицы, типы данных уже определены в ней или в шаблоне;

вводите данные в пустом столбце (или поле), Access назначает полю тип данных, исходя из вводимых значений, или вы можете назначить тип данных и формат для поля;

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

Когда какой тип данных использовать?

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

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

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

Основные типы

Короткие буквенно-цифровые значения, например фамилия или почтовый адрес. Помните, что начиная с версии Access 2013, текстовый тип данных переименован в Краткий текст.

Числовой, Большое число

Числовые значения, например расстояния. Помните, что для денежных значений есть отдельный тип данных.

Значения «Да» и «Нет», а также поля, содержащие только одно из двух значений.

Date/Time, Date/Time Extended

Дата/время: значения даты и времени для лет от 100 до 9999.

Дата/время с расширением: значения даты и времени для лет с 1 по 9999.

Текст или сочетание текста и чисел, которые отформатированы с помощью элементов управления цветом и шрифтом.

Результаты вычисления. Вычисление может ссылаться на другие поля в той же таблице. Вычисления создаются с помощью построителя выражений. Вычисляемые поля впервые появились в Access 2010.

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

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

Длинные блоки текста. Типичный пример использования поля MEMO — подробное описание продукта. Помните, что начиная с версии Access 2013, тип данных MEMO переименован в «Длинный текст».

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

У полей подстановки есть дополнительный набор свойств, которые находятся на вкладке Подстановка в области Свойства поля.

Примечание: В файлах формата MDB недоступны вложения и вычисляемые данные.

Числовой

Числа без дополнительного форматирования (точно в том виде, в котором хранятся).

Обычные денежные значения.

Обычные денежные значения в формате ЕС.

Числовые данные с десятичными знаками.

Значения в процентах.

Дата и время

Краткий формат даты

Дата в кратком формате. Зависит от региональных параметров даты и времени. Например, 14.03.2001 для России.

Средний формат даты

Дата в среднем формате. Например, 03-апр-09 для России.

Длинный формат даты

Дата в длинном формате. Зависит от региональных параметров даты и времени. Например, 14 марта 2001 г. для России.

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

Средний формат времени

Время в 12-часовом формате, после которого указываются символы AM (до полудня) или PM (после полудня).

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

Логический

Объект OLE Объекты OLE, например документы Word.

Свойство «Размер поля»

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

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

Свойство Размер поля определяет также, сколько места на диске занимает каждое значение числового поля. В зависимости от размера поля число может занимать 1, 2, 4, 8, 12 или 16 байт.

Примечание: В полях MEMO и текстовых полях возможны значения переменных размеров. Для этих типов данных свойство Размер поля задает максимальный размер доступного пространства для одного значения.

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

Типы данных в связях и соединениях

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

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

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

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

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

Справочные сведения о типах данных

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

Источник

Путеводитель по репликации баз данных

Повторяться, но каждый раз по-новому – разве не это есть искусство?

Станислав Ежи Лец, из книги «Непричёсанные мысли»

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

Поддержка репликации баз данных – одна из важнейших задач администратора: почти у каждой сколько-нибудь важной базы данных есть реплика, а то и не одна.

Среди задач, решаемых репликацией, можно назвать как минимум

Блочная репликация

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

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

Дисковые массивы могут быть дополнены опциями, позволяющими включить репликацию. Название опции зависит от производителя массива:

Если дисковый массив не способен реплицировать данные, между хостом и массивом может быть установлен агент, осуществляющей запись на два массива сразу. Агент может быть как отдельным устройством (EMC VPLEX), так и программным компонентом (HPE PeerPersistence, Windows Server Storage Replica, DRBD). В отличие от дискового массива, который может работать только с таким же массивом или, как минимум, с массивом того же производителя, агент может работать с совершенно разными дисковыми устройствами.

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

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

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

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

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

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

Блочная репликация не может использоваться для распределения нагрузки, а для обновления хранилища данных используется похожая схема, когда зеркальный том находится в том же массиве, что и основной. У EMC и HP эта схема называется BCV, только EMC расшифровывает аббревиатуру как Business Continuance Volume, а HP – как Business Copy Volume. У IBM на этот случай нет специальной торговой марки, эта схема так и называется – «mirrored volume».

В массиве создаются два тома, и операции записи синхронно выполняются на обоих (A). В определённое время зеркало разрывается (B), то есть тома становятся независимыми. Зеркальный том монтируется к серверу, выделенному для обновления хранилища, и на этом сервере поднимается экземпляр базы данных. Экземпляр будет подниматься так же долго, как и при восстановлении с помощью блочной репликации, но это время может быть существенно уменьшено за счёт разрыва зеркала в период минимальной нагрузки. Дело в том, что разрыв зеркала по своим последствиям эквивалентен аварийному завершению СУБД, а время восстановление при аварийном завершении существенно зависит от количества активных транзакций в момент аварии. База данных, предназначенная для выгрузки, доступна как на чтение, так и на запись. Идентификаторы всех блоков, изменённых после разрыва зеркала как на основном, так и на зеркальном томе, сохраняются в специальной области Block Change Tracking – BCT.

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

Физическая репликация

Журналы (redo log или write-ahead log) содержат все изменения, которые вносятся в файлы базы данных. Идея физической репликации состоит в том, что изменения из журналов повторно выполняются в другой базе (реплике), и таким образом данные в реплике повторяют данные в основной базе байт-в-байт.

Возможность использовать журналы базы данных для обновления реплики появилась в релизе Oracle 7.3, который вышел в 1996 году, а уже в релизе Oracle 8i доставка журналов с основной базы в реплику была автоматизирована и получила название DataGuard. Технология оказалась настолько востребованной, что сегодня механизм физической репликации есть практически во всех современных СУБД.

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

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

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

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

Физическая репликация базы данных имеет множество преимуществ перед репликацией средствами СХД:

Запись данных в реплику невозможна, поскольку изменения в неё приходят побайтно, и реплика не может обеспечить конкурентное исполнение своих запросов. Oracle Active DataGuard в последних релизах разрешает запись в реплику, но это не более чем «сахар»: на самом деле изменения выполняются на основной базе, а клиент ждёт, пока они докатятся до реплики.

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

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

В PostgreSQL есть возможность сконфигурировать репликацию так, чтобы commit завершался только после применения изменений к данным реплики (опция synchronous_commit = remote_apply ), а в Oracle можно сконфигурировать всю реплику или отдельные сессии, чтобы запросы выполнялись только если реплика не отстаёт от основной базы ( STANDBY_MAX_DATA_DELAY=0 ). Однако всё же лучше проектировать приложение так, чтобы запись в основную базу и чтение из реплик выполнялись в разных модулях.

При поиске ответа на вопрос, какой режим выбрать, синхронный или асинхронный, нам на помощь приходят маркетологи Oracle. DataGuard предусматривает три режима, каждый из которых максимизирует один из параметров – сохранность данных, производительность, доступность – за счёт остальных:

Во-первых, в случае репликации средствами дискового массива трафик идёт не по сети передачи данных (LAN), а по сети хранения данных (Storage Area Network). Зачастую в инфраструктурах, построенных давно, SAN гораздо надёжнее и производительнее, чем сеть передачи данных.

Во-вторых, синхронная репликация средствами СУБД стала надёжной относительно недавно. В Oracle прорыв произошёл в релизе 11g, который вышел в 2007 году, а в других СУБД синхронная репликация появилась ещё позже. Конечно, 10 лет по меркам сферы информационных технологий – срок не такой уж маленький, но когда речь идёт о сохранности данных, некоторые администраторы до сих пор руководствуются принципом «как бы чего не вышло»…

Логическая репликация

Все изменения в базе данных происходят в результате вызовов её API – например, в результате выполнения SQL-запросов. Очень заманчивой кажется идея выполнять одну и ту же последовательность запросов на двух разных базах. Для репликации необходимо придерживаться двух правил:

Во-первых, не все API детерминированы. Например, если в SQL-запросе встречается функция now() или sysdate(), возвращающая текущее время, то на разных серверах она вернёт разный результат – из-за того, что запросы выполняются не одновременно. Кроме того, к различиям могут привести разные состояния триггеров и хранимых функций, разные национальные настройки, влияющие на порядок сортировки, и многое другое.

Во-вторых, репликацию, основанную на параллельном исполнении команд, невозможно корректно приостановить и перезапустить.

Если репликация остановлена в момент T1 транзакция B должна быть прервана и откачена. При перезапуске репликации исполнение транзакции B может привести реплику к состоянию, отличному от состояния базы-источника: на источнике транзакция B началась до того, как закончилась транзакция A, а значит, она не видела изменений, сделанных транзакцией A.
Репликация запросов может быть остановлена и перезапущена только в момент T2, когда в базе нет ни одной активной транзакции. Разумеется, на сколько-нибудь нагруженной промышленной базе таких моментов не бывает.

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

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

Над этой таблицей была выполнена следующая операция:

Для того, чтобы корректно реплицировать данные, в реплике будут выполнены такие запросы:

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

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

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

Логическая репликация предоставляет ряд возможностей, отсутствующих в других видах репликации:

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

Репликация триггерами

Триггер – хранимая процедура, которая исполняется автоматически при каком-либо действии по модификации данных. Триггеру, который вызывается при изменении каждой записи, доступны ключ этой записи, а также старые и новые значения полей. При необходимости триггер может сохранять новые значения строк в специальную таблицу, откуда специальный процесс на стороне реплики будет их вычитывать. Объём кода в триггерах велик, поэтому существуют специальное программное обеспечение, генерирующее такие триггеры, например, «Репликация слиянием» (merge replication) – компонент Microsoft SQL Server или Slony-I – отдельный продукт для репликации PostgreSQL.

Сильные стороны репликации триггерами:

Использование журналов СУБД

Сами СУБД также могут предоставлять возможности логической репликации. Источником данных, как и для физической репликации, являются журналы. К информации о побайтовом изменении добавляется также информация об изменённых полях (supplemental logging в Oracle, wal_level = logical в PostgreSQL), а также значение уникального ключа, даже если он не меняется. В результате объём журналов БД увеличивается – по разным оценкам от 10 до 15%.

Возможности репликации зависят от реализации в конкретной СУБД – если в Oracle можно построить logical standby, то в PostgreSQL или Microsoft SQL Server встроенными средствами платформы можно развернуть сложную систему взаимных подписок и публикаций. Кроме того, СУБД предоставляет встроенные средства мониторинга и управления репликацией.

К недостаткам данного подхода можно отнести увеличение объёма журналов и возможное увеличение трафика между узлами.

Использование CDC

Существует целый класс программного обеспечения, предназначенного для организации логической репликации. Это ПО называется CDC, change data capture. Вот список наиболее известных платформ этого класса:

Прикладная репликация

Наконец, ещё один способ репликации – формирование векторов изменений непосредственно на стороне клиента. Клиент должен формировать детерминированные запросы, затрагивающие единственную запись. Добиться этого можно, используя специальную библиотеку работы с базой данных, например, Borland Database Engine (BDE) или Hibernate ORM.

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

Традиционно – сильные и слабые стороны данного подхода:

Так что же лучше?

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

Источник