Разработчики систем клиент-сервер могут научиться многому, просматривая интерфейсы различных сайтов, даже если их приложения не разрабатываются для работы в Интернете, потому что браузер является очень тонким клиентом.
Короткие быстрые запросы держат пользователя в курсе о состоянии базы данных и уменьшают загрузку сети. Эффективные клиенты базы данных предоставляют детализированный интерфейс поиска, а не браузер таблиц, и ограничивают набор строк в количестве не более чем 200.
Реляционные базы данных используют надежные структуры данных с высоким уровнем абстракции для эффективного получения предсказуемых корректных результатов операций. Полный анализ сущностей и процессов вашей системы является основной деятельностью, таким образом вы приходите к логической модели, которая свободна от избыточности и представляет любое отношение.
В процессе логического анализа первичный ключ (primary key) устанавливается для всех сгруппированных данных. Логический первичный ключ помогает определить, какой элемент (или группа элементов) способен однозначно идентифицировать группу связанных данных. Физическое проектирование таблиц будет отображать логическую группировку и уникальность характеристик модели данных, хотя структуры таблиц и ключевые столбцы, созданные в черновом варианте, не часто в точности соответствуют модели. Например, в таблице Employee уникальный ключ состоит из полей имени и фамилии и др. Поскольку составной уникальный ключ в модели данных включает элементы большого размера, которые могут приводить человека к ошибкам, в таблицу должен быть добавлен столбец в качестве суррогатного первичного ключа.
Реляционные СУБД предполагают, что каждая строка в каждой таблице имеет уникальный столбец для однозначной идентификации строк, для проверки соответствия условиям поиска и для связи элементов данных и потоков[7].
Отношения в модели представлены ключами в таблицах. Теоретически каждое отношение в модели должно быть реализовано в виде пары связанных между собой ключей. Когда ключи связаны между собой через ограничение внешнего ключа, таблицы становятся связанными в сеть зависимостей, которые отображают взаимодействие групп данных независимо от контекста. Основные правила логики сервера ссылаются на эти зависимости для поддержания ссылочной целостности базы данных. Стандарты SQL формулируют правила, описывая как зависимости целостности должны работать. От разработчика реляционной СУБД зависит решение, каким образом будут реализовываться и поддерживаться эти зависимости.
В зависимости от реализации конкретного сервера могут быть технические причины для отмены некоторых ограничений ключа без формального объявления и реализации таких ограничений альтернативными способами. Например, большинство реляционных СУБД обязательно требуют неуникальных индексов для элементов колонок внешнего ключа. При некоторых условиях распределения данных могут быть нежелательны индексы для таких колонок, если может быть использован другой способ защиты целостности.
Реляционная СУБД может реализовать отношения, которые не используют ключей. Например, она может получать наборы данных, основываясь на сравнении значений или на выражениях, включающих значения различных столбцов одной таблицы или столбцов из нескольких таблиц.
Язык запросов SQL, структуры хранимых данных и логические умения разработчика приложения объединяются, чтобы уменьшить сетевой трафик в системе клиент- сервер и отобразить точные результаты пользовательских запросов.
"Руки прочь" от доступа к данным
Реляционные СУБД, разработанные для архитектуры клиент-сервер, не предоставляют пользователям прямой доступ к данным. Когда пользовательское приложение хочет выполнить операции над набором данных, оно сообщает клиентскому модулю, чего оно хочет, и клиентский модуль "договаривается" с сервером об удовлетворении этой потребности. Если запрос отвергается по какой-то причине, то именно клиентский модуль сообщает "плохую новость" приложению.
Если приложение запрашивает набор данных для чтения, то клиентский модуль берет результат выполнения сервером операции и передает его приложению. Данные, видимые приложению, являются образом состояния исходных данных в базе данных на момент начала "переговоров" между клиентом и сервером. Этот образ, который видят пользователи, отключен - или изолирован - от базы данных. "Момент изоляции" может не совпадать с тем моментом, когда сервер получает запрос. В окружении клиент-сервер, где предполагается, что более чем один пользователь читает и пишет данные, каждый запрос имеет контекст.
Множество пользователей и параллельность
СУБД разработана для того, чтобы обеспечить работу множества пользователей с образами хранимых данных и, чтобы можно было использовать изменяющие запросы, которые могут влиять на работу других пользователей. В этой ситуации нужны способы управления параллельностью. Параллельность - это набор условий, в которых предусмотрена ситуация, когда запросы двух или более пользователей изменяют одну и ту же строку таблицы в одно и то же время (т. е. параллельно). Развитые СУБД, такие как Firebird, реализуют некую схему, при которой каждый запрос выполняется в параллельном контексте. Стандартный термин для такого параллельного контекста транзакция- не путайте с "бизнес-транзакциями", которые часто реализуются в приложениях баз данных.
Для бывших пользователей настольных баз данных транзакция является одной из наиболее запутанных абстракций в реляционных СУБД архитектуры клиент-сервер. В настольных базах данных и программах электронных таблиц это понятие используется для гарантии того, что если пользователь щелкнет по кнопке Сохранить и кнопка станет серого цвета, то значит операция выполнена. Также факт, что как только до разработчика дойдет, что такое транзакция, они склоняются к отказу от "идеологии электронных таблиц", которая была у них все те годы, когда старая модель баз данных казалась совершенной.
В Firebird все общение между клиентом и сервером происходит в контексте транзакций. Даже чтение небольшого количества строк таблицы не может быть выполнено, если не запущена транзакция. Транзакция стартует, когда приложение запрашивает об этом клиента. С момента, когда транзакция начинается и пока она не закончится - опять же по запросу приложения, - общение клиента и сервера открыто, приложение может просить клиента выполнять запросы. В этот период выполняются операции по изменению состояния базы данных, и осуществляется запись на диск. Однако они не изменяют состояния базы данных и являются обратимыми.
Транзакции завершаются, когда приложение обращается к клиенту, чтобы он запросил сервер подтвердить (commit) всю работу, выполненную с момента старта транзакции (даже если ничего не выполнялось, кроме чтения), или в случае ошибок отменить всю работу (rollback). Правило атомарности гласит: "Если одно из изменений оканчивается неудачей и требует отмены по причине невозможности подтверждения, то все ожидающие завершения изменения в этой транзакции также должны быть отменены". Отмена включает любые изменения, которые были сделаны триггерами и хранимыми процедурами в процессе выполнения этой транзакции.
! ! !
СОВЕТ. Для разработчика приложения очень полезно делать видимой каждую единицу работы с базой данных в виде задачи или группы задач, которые были завершены в контексте транзакции. Условия выполнения транзакций могут быть сконфигурированы различными способами. Например, один уровень изоляции выдаст иной вид сообщения о конфликте, чем другой уровень. Большинство эффективных программ приложений знает об этих вариантах и учитывает их в такой мере, что контекст каждой транзакции распространяется до рамок рабочей области приложения, окружающей действительную физическую транзакцию.
7
Строго говоря, наличие уникального ключа в таблице не является обязательным для реляционных баз данных, хотя его наличие весьма желательно. - Прим. перев.