База данных. ЭУМК Базы данных. Пояснительная записка Теоретический раздел Практический раздел Раздел контроля знаний Вспомогательный раздел Пинск
 Скачать 2.33 Mb.
|
|
4. Обеспечение целостности и эффективности работы с базами данных 4.1. Целостность баз данных. Управление транзакциями 4.2. Повышение производительности баз данных 4.3. Администрирование и управление объектами базы данных 4.4. Методы доступа к базам данных из прикладных программ 4.5. Базы данных в клиент-серверной архитектуре. 4.1. Целостность баз данных. Управление транзакциями Выполнение операторов модификации данных в таблицах базы данных INSERT, DELETE и UPDATE может привести к нарушению целостности данных и их корректности, т.е. к потере их достоверности и непротиворечивости. Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия – правила, определяющие возможные значения данных и обеспечивающие логическую основу для поддержания корректных значений. Ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных. В базе данных, построенной на реляционной модели, задается ряд правил целостности, которые, по сути, являются ограничениями для всех допустимых состояний базы данных и гарантируют корректность данных. Рассмотрим следующие типы ограничений целостности данных: обязательные данные; ограничения для доменов полей; корпоративные ограничения; целостность сущностей; ссылочная целостность. Обязательные данные Некоторые поля всегда должны содержать одно из допустимых значений, другими словами, эти поля не могут иметь пустого значения. Ограничения для доменов полей Каждое поле имеет свой домен, представляющий собой набор его допустимых значений. Корпоративные ограничения целостности Существует понятие "корпоративные ограничения целостности " как дополнительные правила поддержки целостности данных, определяемые пользователями, принятые на предприятии или администраторами баз данных. Ограничения предприятия называются бизнес-правилами. Целостность сущностей Это ограничение целостности касается первичных ключей базовых таблиц. По определению, первичный ключ – минимальный идентификатор (одно или несколько полей), который используется для уникальной идентификации записей в таблице. Таким образом, никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации записей. Целостность сущностей определяет, что в базовой таблице ни одно поле первичного ключа не может содержать отсутствующих значений, обозначенных NULL. Если допустить присутствие определителя NULL в любой части первичного ключа, это равносильно утверждению, что не все его поля необходимы для уникальной идентификации записей, и противоречит определению первичного ключа. Ссылочная целостность Указанное ограничение целостности касается внешних ключей. Внешний ключ – это поле (или множество полей) одной таблицы, являющееся ключом другой (или той же самой) таблицы. Внешние ключи используются для установления логических связей между таблицами. Связь устанавливается путем присвоения значений внешнего ключа одной таблицы значениям ключа другой. Между двумя или более таблицами базы данных могут существовать отношения подчиненности, которые определяют, что для каждой записи главной таблицы (называемой еще родительской ) может существовать одна или несколько записей в подчиненной таблице (называемой также дочерней ). Существует три разновидности связи между таблицами базы данных: "один-ко-многим"; "один-к-одному"; "многие-ко-многим". Отношение "один-ко-многим" имеет место, когда одной записи родительской таблицы может соответствовать несколько записей дочерней. Связь "один-ко-многим" иногда называют связью "многие-к-одному". И в том, и в другом случае сущность связи между таблицами остается неизменной. Связь "один-ко-многим" наиболее распространена для реляционных баз данных. Она позволяет моделировать также иерархические структуры данных. Отношение "один-к-одному" имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней. Это отношение встречается намного реже, чем отношение "один-ко-многим". Его используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации. Использование связи "один-к-одному" приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения вместо одной, когда данные хранятся в одной таблице. Отношение "многие-ко-многим" имеет место в следующих случаях: одной записи в родительской таблице соответствует более одной записи в дочерней таблице ; одной записи в дочерней таблице соответствует более одной записи в родительской таблице. Считается, что всякая связь "многие-ко-многим" может быть заменена на связь "один-ко-многим" (одну или несколько). Часто связь между таблицами устанавливается по первичному ключу, т.е. значениям внешнего ключа одной таблицы присваиваются значения первичного ключа другой. Однако это не является обязательным – в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами не требуется непременная уникальность ключа, обеспечивающего установление связи. Поля внешнего ключа не обязаны иметь те же имена, что и имена ключей, которым они соответствуют. Внешний ключ может ссылаться на свою собственную таблицу – в таком случае внешний ключ называется рекурсивным. Ссылочная целостность определяет: если в таблице существует внешний ключ, то его значение должно либо соответствовать значению первичного ключа некоторой записи в базовой таблице, либо задаваться определителем NULL. Существует несколько важных моментов, связанных с внешними ключами. Во-первых, следует проанализировать, допустимо ли использование во внешних ключах пустых значений. В общем случае, если участие дочерней таблицы в связи является обязательным, то рекомендуется запрещать применение пустых значений в соответствующем внешнем ключе. В то же время, если имеет место частичное участие дочерней таблицы в связи, то помещение пустых значений в поле внешнего ключа должно быть разрешено. Например, если в операции фиксации сделок некоторой торговой фирмы необходимо указать покупателя, то поле КодКлиента должно иметь атрибут NOT NULL. Если допускается продажа или покупка товара без указания клиента, то для поля КодКлиента можно указать атрибут NULL. Следующая проблема связана с организацией поддержки ссылочной целостности при выполнении операций модификации данных в базе. Здесь возможны следующие ситуации: Вставка новой строки в дочернюю таблицу. Для обеспечения ссылочной целостности необходимо убедиться, что значение внешнего ключа новой строки дочерней таблицы равно пустому значению либо некоторому конкретному значению, присутствующему в поле первичного ключа одной из строк родительской таблицы. Удаление строки из дочерней таблицы. Никаких нарушений ссылочной целостности не происходит. Обновление внешнего ключа в строке дочерней таблицы. Этот случай подобен описанной выше первой ситуации. Для сохранения ссылочной целостности необходимо убедиться, что значение внешнего ключа в обновленной строке дочерней таблицы равно пустому значению либо некоторому конкретному значению, присутствующему в поле первичного ключа одной из строк родительской таблицы. Вставка строки в родительскую таблицу. Такая вставка не может вызвать нарушения ссылочной целостности. Добавленная строка просто становится родительским объектом, не имеющим дочерних объектов. Удаление строки из родительской таблицы. Ссылочная целостность окажется нарушенной, если в дочерней таблице будут существовать строки, ссылающиеся на удаленную строку родительской таблицы. В этом случае может использоваться одна из следующих стратегий: NO ACTION. Удаление строки из родительской таблицы запрещается, если в дочерней таблице существует хотя бы одна ссылающаяся на нее строка. CASCADE. При удалении строки из родительской таблицы автоматически удаляются все ссылающиеся на нее строки дочерней таблицы. Если любая из удаляемых строк дочерней таблицы выступает в качестве родительской стороны в какой-либо другой связи, то операция удаления применяется ко всем строкам дочерней таблицы этой связи и т.д. Другими словами, удаление строки родительской таблицы автоматически распространяется на любые дочерние таблицы. SET NULL. При удалении строки из родительской таблицы во всех ссылающихся на нее строках дочернего отношения в поле внешнего ключа, соответствующего первичному ключу удаленной строки, записывается пустое значение. Следовательно, удаление строк из родительской таблицы вызовет занесение пустого значения в соответствующее поле дочерней таблицы. Эта стратегия может использоваться, только когда в поле внешнего ключа дочерней таблицы разрешается помещать пустые значения. SET DEFAULT. При удалении строки из родительской таблицы в поле внешнего ключа всех ссылающихся на нее строк дочерней таблицы автоматически помещается значение, указанное для этого поля как значение по умолчанию. Таким образом, удаление строки из родительской таблицы вызывает помещение принимаемого по умолчанию значения в поле внешнего ключа всех строк дочерней таблицы, ссылающихся на удаленную строку. Эта стратегия применима лишь в тех случаях, когда полю внешнего ключа дочерней таблицы назначено некоторое значение, принимаемое по умолчанию. NO CHECK. При удалении строки из родительской таблицы никаких действий по сохранению ссылочной целостности данных не предпринимается. Обновление первичного ключа в строке родительской таблицы. Если значение первичного ключа некоторой строки родительской таблицы будет обновлено, нарушение ссылочной целостности случится при том условии, что в дочернем отношении существуют строки, ссылающиеся на исходное значение первичного ключа. Для сохранения ссылочной целостности может применяться любая из описанных выше стратегий. При использовании стратегии CASCADE обновление значения первичного ключа в строке родительской таблицы будет отображено в любой строке дочерней таблицы, ссылающейся на данную строку. Существует и другой вид целостности – смысловая (семантическая) целостность базы данных. Требование смысловой целостности определяет, что данные в базе данных должны изменяться таким образом, чтобы не нарушалась сложившаяся между ними смысловая связь. Уровень поддержания целостности данных в разных системах существенно варьируется. Идеология архитектуры клиент-сервер требует переноса максимально возможного числа правил целостности данных на сервер. К преимуществам такого подхода относятся: гарантия целостности базы данных, поскольку все правила сосредоточены в одном месте (в базе данных); автоматическое применение определенных на сервере ограничений целостности для любых приложений; отсутствие различных реализаций ограничений в разных клиентских приложениях, работающих с базой данных; быстрое срабатывание ограничений, поскольку они реализованы на сервере и, следовательно, нет необходимости посылать данные клиенту, увеличивая при этом сетевой трафик; доступность внесенных в ограничения на сервере изменений для всех клиентских приложений, работающих с базой данных, и отсутствие необходимости повторного распространения измененных приложений клиентов среди пользователей. К недостаткам хранения ограничений целостности на сервере можно отнести: отсутствие у клиентского приложения возможности реагировать на некоторые ошибочные ситуации, возникающие на сервере при реализации тех или иных правил (например, ошибок при выполнении хранимых процедур на сервере); ограниченность возможностей языка SQL и языка хранимых процедур и триггеров для реализации всех возникающих потребностей определения целостности данных. На практике в клиентских приложениях реализуют лишь такие правила, которые тяжело или невозможно реализовать с применением средств сервера. Все остальные ограничения целостности данных переносятся на сервер. 4.2. Повышение производительности баз данных Чтобы получить от базы данных с открытым кодом максимум производительности, нужны глубокие знания. Вряд ли найдется Web-приложение, которое не опиралось бы на ту или иную базу данных. Если вы не располагаете достаточным бюджетом или просто являетесь приверженцем программных продуктов с открытым кодом, то, по всей вероятности, будете разрабатывать свои приложения на базе гипертекстового процессора PHP (PHP Hypertext Processor) и какой-нибудь базы данных с открытым кодом. В таком случае вам следует ознакомиться с методами, позволяющими выжимать из баз данных все, на что они способны. В этой статье мы рассматриваем некоторые методики повышения производительности, которые подойдут практически для любой базы данных с открытым кодом. Oптимизация на уровне базы данных Самым быстрым способом повышения производительности программного кода базы данных является замена встроенных в него операторов SQL на хранимые процедуры. Использование хранимых процедур Хранимые процедуры -- это подпрограммы, содержащиеся в базе данных. Такие процедуры предварительно компилируются процессором базы данных и существенно повышают производительность последней, исключая многократные обращения вызывающего приложения (как правило, это страница PHP) к ядру базы данных. Кроме того, хранимые процедуры гораздо проще поддерживать и обслуживать. Вся логика размещается в одном месте кода, так что все изменения тоже сосредоточены в одном месте и начинают действовать сразу же после их выполнения. Когда программный код всегда обращается к одной и той же процедуре, гораздо проще удостовериться в том, что бизнес-логика находится в полном соответствии со всеми функциональными требованиями. Если ваши процедуры достаточно универсальны, вы можете использовать их и в других проектах, сократив таким образом сроки разработки. Кроме того, по сравнению с выполнением SQL-кода в таких средах, как PHP, ASP (Active Server Page) и JSP (Java Server Pages), а также в средах некоторых других языков разработки хранимые процедуры позволяют заметно снизить интенсивность сетевого трафика. И наконец, если у вас возникнет необходимость в масштабировании приложения, гораздо проще расширить его код на несколько прикладных серверов, когда большая часть логики доступа к базе данных хранится и выполняется в рамках самой базы данных. Хранение мультимедийных файлов в файловой системе Мультимедийные файлы, будь то статические изображения, звуковые файлы или фильмы, часто рассматривают как двоичные объекты. Для них даже имеется специальный термин: большие двоичные объекты -- BLOB (Binary Large OBject). Поля BLOB можно хранить либо в базе данных, либо в файловой системе. В последнем случае пути к объектам BLOB хранятся в базе данных. Хранение объектов BLOB в файловой системе потребует от вас чуть больше работы, зато позволит добиться гораздо более высокой производительности, чем при хранении их в базе данных. С увеличением числа сохраняемых двоичных объектов производительность процессора базы данных быстро уменьшается. Кроме того, удаление таких объектов может привести к образованию в файлах базы данных большого числа "мертвых зон". Когда вся информация от и до проходит через процессор базы данных, ему труднее поддерживать многозадачный режим работы. Хранение объектов BLOB в файловой системе, напротив, облегчает создание ссылок на загружаемые из Web-страниц объекты. После загрузки информации Web-сервер обслуживает обращение к файлу, а процессор базы данных занимается в это время другими задачами. Дополнительным преимуществом также является и то, что администратор может легко каталогизировать и администрировать мультимедийные файлы, записанные на диск, а также делать их резервные копии. Использование индексации Индексирование -- один из наиболее верных способов наращивания производительности базы данных. Кроме того, он входит в число основных механизмов базы данных, которому обычно уделяется незаслуженно мало внимания. Как правило, строки базы данных хранятся в том порядке, в каком создаются. Для извлечения из записи базы данных некоторой произвольной величины требуется последовательное сканирование соответствующих строк базы данных. Индекс создает отдельное множество строк, упорядоченных в соответствии с выбранным индексом и содержащих указатели на исходные строки. Индексированная база данных просматривается значительно быстрее, чем неиндексированные таблицы. Однако индексирование "съедает" дополнительное дисковое пространство. Кроме того, на модификацию индексированной таблицы требуется больше времени, поскольку все применяемые индексы тоже приходится корректировать. Использование целочисленных ключевых полей Возможно, у вас есть соблазн при создании таблиц обойтись без целочисленного ключевого поля. Например, в таблице записей, содержащих информацию о персонале, вы могли бы использовать символьные поля last_name и first_name, а также поля для адреса и контактной информации, при объединении записей, их просмотре и других операциях с ними использовать имена полей. Мы не советуем вам придерживаться такой практики. Лучше используйте числовое ключевое поле -- к примеру, person_id. Если ваши данные не содержат такого поля, вы должны создать автоинкрементное поле, которое не будет содержать никаких реальных данных и будет лишь выполнять роль ключевого поля. Числовые поля имеют множество преимуществ. Вероятность ошибочного использования числа гораздо меньше вероятности ошибочного использования имени. При изменении имени человека (например, ввиду вступления в брак) вам не потребуется изменять в своем коде все ссылки на него. Кроме того, объединение записей, имеющих числовое ключевое поле, выполняется гораздо эффективнее, чем объединение записей с текстовым ключевым полем. Следует взять за практику создавать числовое поле первичного ключа при формировании каждой новой таблицы. Оптимизация прикладного кода Чтобы добиться максимального повышения производительности базы данных, можно использовать несколько разных стратегий оптимизации программного кода приложения. Ниже мы приводим ряд рекомендаций по оптимизации кода, которые применимы для любого языка разработки Web- приложений. Использование сеансов связи Сеансы связи поддерживаются несколькими средами разработки Web- приложений. Обычно сеансы связи, крайне популярные среди поставщиков прикладного сервиса и программистов PHP, реализуются посредством пересылки маркеров cookies. Поскольку Web не является средой, использующей информацию о состоянии, она не предоставляет программистам никакой информации о том, что мог делать пользователь перед тем, как "зашел" на данную страницу. С помощью сеансов связи программист может отслеживать процесс навигации пользователя. Как побочный эффект многие программисты стремятся сохранить всю информацию о нем в переменных сеанса. Хотя сохранение ссылок на базу данных, таких, как соединения или наборы записей, в переменной сеанса является делом заманчивым, это довольно плохая привычка. Запоминание соединений в ходе сеансов связи препятствует их объединению в пул. Кроме того, такая практика приводит к разбазариванию памяти и вычислительной мощности ЦПУ. Если сеансы связи не завершаются корректно, соединения продолжают существовать в течение всего тайм-аута. Продолжительность тайм-аута может варьироваться, но в большинстве случаев она больше 20 мин. В течение всего этого времени оперативная память и вычислительная мощность ЦПУ растрачиваются вхолостую. Хотя может показаться, что открытие и последующее закрытие соединения на Web-странице приводит к пустой трате ресурсов, на деле это способствует эффективному их сохранению. Достаточно лишь придерживаться "железного" правила: создавать соединение как можно позже и закрывать его как можно раньше. Это же правило применимо и к наборам записей. Использование оптимальных запросов Способ использования операторов SQL может существенно повлиять на производительность вашего Web-приложения. В частности, извлечение из базы данных длинного списка записей для отображения на одной непрерывной Web- странице является нерациональным. Вам следует взять за один раз только часть записей (скажем, 10 или 50), а затем, чтобы отобразить следующую группу записей, использовать кнопку "Следующие 50" (Next 50) или ссылку на Web- странице. При написании такого кода, старайтесь в полной мере использовать все преимущества языка SQL. Например, ключевое слово limit (предельное число) ограничивает число возвращаемых записей. Ключевое слово offset (смещение) пропускает определенное число записей, возвращая следующие за ними записи. Чтобы вернуть третью группу пользовательских записей в количестве 50 штук, вам следует использовать запрос следующего вида: SELECT customer_id, customer_name from customer ORDER BY customer_id LIMIT 50 OFFSET 100. Если таблицы содержат большое число столбцов или вы используете в запросах операции соединения, не следует употреблять оператор select * лишь для того, чтобы оградить себя от необходимости печатать наименования полей. Печатание нужных вам имен полей позволяет сэкономить несколько циклов ЦПУ при каждом запуске кода. Уж коль скоро мы заговорили об операторе select, отметим, что нужно использовать его выражение where с максимальной пользой. Если в разделе where содержатся номера нескольких столбцов, производительность будет зависеть от того, в какой очередности эти номера записаны. На первом месте выражения where должен стоять номер столбца, возвращающего минимальный набор записей, на втором -- номер столбца, возвращающего следующий минимальный набор записей, и так далее для всех оставшихся столбцов. Использование оператора выбора Для формирования запроса, требующего принятия решения на основе результата его выполнения, вы можете использовать один из двух способов. Наиболее очевидный, но и более медленный способ -- выполнить запрос и проверить его результат с помощью своего прикладного кода. Более квалифицированный и более выгодный способ -- использовать продвинутые функции языка SQL. Оператор case языка SQL, как и аналогичные операторы большинства других языков разработки, может делать выбор на основе значения входного параметра. В таком случае результат оператора select можно контролировать, используя оператор case, как это сделано в следующем примере: Select product_name, CASE when price < 5 then 'cheap' when price > 5 and price < 20 then 'OK' else 'too expensive for my taste' END as product_price from Products order by product_name; В результате будем иметь набор записей, состоящий из двух столбцов: первый столбец содержит наименование продукта, второй -- избранную нами интерпретацию цены. 4.3. Администрирование и управление объектами базы данных Администрирование базы данных – это функция управления базой данных (БД). Лицо ответственное за администрирование БД называется “Администратор базы данных” (АБД) или “Database Administrator” (DBA). Администратор базы данных (АБД) или Database Administrator (DBA) – это лицо, отвечающее за выработку требований к базе данных, её проектирование, реализацию, эффективное использование и сопровождение, включая управление учётными записями пользователей БД и защиту от несанкционированного доступа. Не менее важной функцией администратора БД является поддержка целостности базы данных. Руководства для разных СУБД по-разному формулируют функции администратора, но в конечном итоге они сводятся к следующим: · инсталляция СУБД; · управление памятью; · управление разделением данных между пользователями; · копирование и восстановление БД; управление безопасностью в системе; · передача данных между СУБД и другими системами; · управление производительностью. Существенной особенностью языка SQL, появившейся в нем с самого начала, является обеспечение защиты доступа к данным средствами самого языка. Основная идея такого подхода состоит в том, что по отношению к любому отношению БД и любому столбцу отношения вводится предопределенный набор привилегий. С каждой транзакцией неявно связывается идентификатор пользователя, от имени которого она выполняется (способы связи и идентификации пользователей не фиксируются в языке и определяются в реализации). Идентификатором пользователя называется обычный идентификатор языка SQL, применяемый для обозначения некоторого пользователя базы данных. Каждому пользователю должен быть назначен собственный идентификатор, присваиваемый администратором базы данных. Из очевидных соображений безопасности идентификатор пользователя, как правило, связывается с некоторым паролем. Каждый выполняемый СУБД SQL-оператор выполняется от имени какого-либо пользователя. Идентификатор пользователя определяет, на какие объекты базы данных пользователь может ссылаться и какие операции с этими объектами он имеет право выполнять. Привилегиями, или правами, называются действия, которые пользователь имеет право выполнять в отношении данной таблицы базы данных или представления. В стандарте SQL определяется следующий набор привилегий: · SELECT – право выбирать данные из таблицы; · INSERT – право вставлять в таблицу новые строки; · UPDATE – право изменять данные в таблице; · DELETE – право удалять строки из таблицы; · REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных; · USAGE – право использовать домены, проверки и наборы символов 4.4. Методы доступа к базам данных из прикладных программ Рассмотрим некоторые способы создания приложений, работающих с базой данных при помощи языка SQL. Как правило, любой поставщик СУБД предоставляет вместе со своей системой внешнюю утилиту, которая позволяет вводить операторы SQL в режиме командной строки и выдает на консоль результаты их выполнения. Недостатки такого режима работы очевидны: необходимо знать SQL, необходимо помнить схему БД, отсутствует возможность удобного просмотра результатов выполнения запросов. Поэтому, подобные утилиты стали инструментами администраторов баз данных, а для создания пользовательских приложений используются универсальные и специализированные языки программирования. Приложения, написанные таким образом, позволяют пользователю сосредоточиться на решении собственных задач, а не на структурах данных. Почти все способы организации взаимодействия пользователя с базой данных, рассматриваемые ниже, основаны на модели "клиент-сервер". Т.е. предполагается, что каждое приложение обработки данных разбито, как минимум, на две части: клиента, который отвечает за организацию пользовательского интерфейса сервер, который собственно хранит данные, обрабатывает запросы и посылает их результаты клиенту для отображения При этом предполагется, что каждая часть приложения функционирует на отдельном компьютере, т.е. к выделенному серверу БД с помощью локальной сети подключены персональные компьютеры пользователей (клиенты). Это наиболее популярная сегодня схема организации вычислительной среды. Язык SQL позволяет только манипулировать данными, но в нем отсутствуют средства создания экранного интерфейса, что необходимо для пользовательских приложений. Для создания этого интерфейса служат универсальные языки третьего поколения (C, C++, Pascal) или проблемно- ориентированные языки четвертого поколения (xBase, Informix 4Gl, Progress, Jam,...). Эти языки содержат необходимые операторы ввода / вывода на экран, а также операторы структурного программирования (цикла, ветвтеления и т.д.). Также эти языки допускают определение структур, соответствующих записям таблиц обрабатываемой базы данных. В исходный текст программы включаются операторы языка SQL, которые во время исполнения передаются серверу БД, который собственно и производит манипулирование данными. Отношения, полученные в результате выполнения сервером SQL-запросов, возвращаются прикладной программе, которая заполняет строками этих отношений заранее определенные структуры. Дальнейшая работа клиентской программы (отображение, корректировка записей) ведется с этими структурами. Рассмотрим различные способы орагнизации доступа прикладной программы к серверу базы данных. Использование специализированных библиотек и встраиваемого SQL. Каждая СУБД помимо интерактивной SQL-утилиты обязательно имеет библиотеку доступа и набор драйверов для различных операционных систем. Схема взаимодействия клиентского приложения с сервером базы данных в этом случае выглядит так: Библиотека доступа - это, как правило, объектный файл, исходный код которого создан на универсальном языке типа C. Эта библиотека содержит набор функций, позволяющих пользовательскому приложению соединятся с базой данных, передавать запросы серверу и получать ответные данные. Типичный набор функций такой библиотеки (имена функций зависят от используемой библиотеки): DB_connect(char *имя_базы_данных, char *имя_пользователя, char *пароль) - устанавливает соединение с базой данной, возвращает указатель на структуру db, описывающую характеристики этого соединения DB_exec(db, char *запрос) - выполнить запрос к базе данных, определяемой структурой db. Применяется для любых запросов кроме SELECT. Возвращает код выполнения запроса (0 - удачно, либо код ошибки) DB_select(db, char *запрос) - выполнить запрос на извлечение данных (SELECT). Возвращает структуру result, содержащую результаты выполнения запроса (реляционное отношение). DB_fetch(result) - извлечь следующую запись из структуры result. DB_close(db) - закрыть соединение с базой данных. Разумеется это минимальный набор функций для работы с базой данных. Обычно в библиотеке присутствуют также функции, позволяющие определить характеристики структурыresult (число, порядок и имена столбцов, число строк, номер текущей строки), передвигаться по этой структуре не только вперед, но и назад (DB_next, DB_prev) и т.д. Такой способ создания приложений чрезвычайно гибок, позволяет реализовать практически любое приложение, но в то же время имеет явные недостатки: разработка клиентской программы возможна только для той операционной системы и на том языке программирования, который поддерживатеся библиотекой необходим драйвер базы данных, который определяет допустимые типы сетевых интерфейсов большой объем кодирования нестандартизованные библиотечные функции. В результате получаем приложение, которое привязано как к сетевой среде, так и к программно-аппаратной платформе и используемой базе данных. Некоторой модификацией данного способа является использование "встроенного" языка SQL. В этом случае в текст программы на языке третьего поколения включаются не вызовы библиотек, а непосредственно предложения SQL, которые предваряются ключевым выражением "EXEC SQL". Перед компиляцией в машинный код такая программа обрабатывается препроцессором, который транслирует смесь операторов "собственного" языка СУБД и операторов SQL в "чистый" исходный код. Затем коды SQL замещаются вызовами соответствующих процедур из библиотек исполняемых модулей, служащих для поддержки конкретного варианта СУБД. Такой подход позволил несколько снизить степень привязанности к СУБД, например, при переключении прикладной программы на работу с другим сервером базы данных достаточно было заново обработать ее исходный текст новым препроцессором и перекомпилировать. CLI - интерфейс уровня вызовов. Большим достижением явилось появление (1994 г.) в стандарте SQL интерфейса уровня вызова - CLI (Call Level Interface), в котором стандартизован общий набор рабочих процедур, обеспечивающий совместимость со всеми основными серверами баз данных. Ключевой элемент CLI - специальная библиотека для компьютера-клиента, в которой хранятся вызовы процедур и большинство часто используемых сетевых компонентов для организации связи с сервером. Это ПО поставляется разработчиком средств SQL, не является универсальным и поддерживает разнообразные транспортные протоколы. Использование программных вызовов позволяет свести к минимуму операции на компьютере-клиенте. В общем случае клиент формирует оператор языка SQL в виде строки и пересылает ее на сервер посредством процедуры исполнения (execute). Когда же сервер в качестве ответа возвращает несколько строк данных, клиент считывает результат с помощью серии вызовов процедуры выборки данных. Далее информация из столбцов полученной таблицы может быть связана с соответствующими переменными приложения. Вызов специальной процедуры позволяет клиенту определить считанное число строк, столбцов и типы данных в каждом столбце. Интерфейс CLI построен таким образом, что перед передачей запроса серверу клиент не должен заботиться о типе оператора SQL, будь то выборка, обновление, удаление или вставка. ODBC - открытый интерфейс к базам данных на платформе MS WIndows. Очень важный шаг к созданию переносимых приложений обработки данных сделала фирма Microsoft, опубликовавшая в 1992 году спецификацию ODBC (Open Database Connetcivity - открытого интерфейса к базам данных), предназначенную для унификации доступа к данным с персональных компьютеров работающих под управлением операционной системы Windows. (Заметим, что ODBC опирается на спецификации CLI). Структурная схема доступа к данным с использованием ODBC: ODBC представляет из себя программный слой, унифицирующий интерфейс приложений с базами данных. За релизацию особенностей доступа к каждой отдельной СУБД отвечает специальный ODBC-драйвер. Пользовательское приложение этих особенностей не видит, т.к. взаимодействует с универсальным программным слоем более высокого уровня. Таким образом, приложение становится в значительной степени независимым от СУБД. Однако, этот способ также не лишен недостатков: приложения становятся привязанными к платформе MS Windows увеличивается время обработки запросов (как следствие введения дополнительного программного слоя) необходимо предварительная инсталляция ODBC-драйвера и настройка ODBC (указание драйвера, сетевого пути к серверу, базы данных и т.д.) на каждом рабочем месте. Параметры этой настройки являются статическими, т.е. приложение их самостоятельно изменить не может. JDBC - мобильный интерфейс к базам данных на платформе Java. JDBC (Java DataBase Connectivity) - это интерфейс прикладного программирования (API) для выполнения SQL-запросов к базам данных из программ, написанных на языке Java. Напомним, что язык Java, созданный компанией Sun, является платформенно - независимым и позволяет создавать как собственно приложения (standalone application), так и программы (апплеты), встраиваемые в web-страницы. JDBC во многом подобен ODBC (см. рисунок), также построен на основе спецификации CLI, однако имеет ряд замечательных отличий. Во-первых, приложение загружает JDBC-драйвер динамически, следовательно администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места. Во-вторых, JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно проблемы с переносимостью приложений практически снимаются. В-третьих, использование Java- приложений и связанной с ними идеологии "тонких клиентов" обещает снизить требования к оборудованию клиентских рабочих мест. 4.5. Базы данных в клиент-серверной архитектуре. Работа на изолированном компьютере с небольшой базой данных в настоящий момент становится нехарактерной для большинства приложений. БД отражает информационную модель реальной предметной области, хранит большие объемы информации, которая постоянно увеличивается. Соответственно увеличивается количество приложений, работающих с единой базой данных. Компьютеры объединяются в локальные сети и осуществляют доступ к корпоративной базе данных общего пользования, расположенной на сервере. Существует два варианта организации базы данных в локальной сети. Первый вариант – системы распределенной обработки данных. БД расположена на одной машине (сервере). К ней осуществляется параллельный доступ нескольких пользователей. Второй вариант – системы распределенных баз данных. БД распределена на нескольких компьютерах, объединенных в сеть. К БД возможен параллельный доступ нескольких пользователей. Это режим параллельного доступа к распределенной БД. В общем случае режимы использования БД можно представить в следующем виде (рис. .1). Рис. 1 Режимы работы с базой данных Режимы работы с БД Однопользовательский Многопользовательский Последовательный Параллельный С централизованной БД С распределенной БД Модели архитектуры клиент-сервер При построении распределенных ИС, работающих с БД, широко используется архитектура клиент-сервер. Ее основу составляют принципы организации взаимодействия клиента и сервера при управлении БД. Согласно Эталонной модели Архитектуры открытых систем OSI функция управления БД относится к прикладному уровню. СУБД как программа, поддерживающая интерфейс с пользователем, реализует следующие основные функции: управление данными, находящимися в базе; обработка информации с помощью прикладных программ; представление информации в удобном для пользователя виде. При размещении СУБД в сети возможны различные варианты распределения функций по узлам сети. В зависимости от числа узлов сети, между которыми выполняется распределение функций СУБД, можно выделить двухзвенные и трехзвенные модели. Место разрыва функций соединяется коммуникационными элементами (средой передачи информации в сети). Двухзвенные модели соответствуют распределению функций СУБД между двумя узлами сети. Компьютер (узел сети), на котором обязательно присутствует функция управления данными, называют компьютером-сервером. Компьютер, близкий к пользователю и обязательно занимающийся вопросами представления информации, называют компьютером-клиентом. Наиболее типичными вариантами разделения функций между компьютером-сервером и компьютером-клиентом являются следующие. Распределенное представление: компьтер-сервер – управление данными, обработка, представление; компьютер-клиент – представление. Удаленное представление: компьютер-сервер – управление данными, обработка; компьютер-клиент – представление. Распределенная функция: компьютер-сервер – управление данными, обработка; компьютер-клиент – обработка, представление. Удаленный доступ к данным компьютер-сервер – управление данными; компьютер-клиент – обработка, представление. Распределенная БД компьютер-сервер – управление данными; компьютер-клиент – управление данными, обработка, представление. Перечисленные способы распределения функций в системах с архитектурой клиент-сервер иллюстрируют различные варианты: от мощного сервера, когда практически вся работа производится на нем, до мощного клиента, когда большая часть функций выполняется на рабочей станции, а сервер обрабатывает поступившие к нему по сети SQL-вызовы. Трехзвенная модель распределения функций представляет собой типовой вариант, при котором каждая из трех функций приложения (управление данными, обработка, представление) реализуется на отдельном компьютере. Данная модель имеет название – модель сервера приложений, или AS- модель (Application Server) и показана на рис. 2. Согласно трехзвенной AS-модели процесс, отвечающий за организацию диалога с конечным пользователем, реализует функции представления информации и взаимодействует с компонентом приложения. Компонент приложения, располагаясь на отдельном компьютере, в свою очередь, связан с компонентом управления данными. Управление данными Компьютер-сервер БД Приложение Компьютер-сервер приложений Представление Компьютер-клиент Рис. 2 Трехзвенная модель сервера приложений Центральным звеном AS-модели является сервер приложений. На сервере приложений реализуется несколько прикладных функций, каждая из которых оформлена как служба предоставления услуг всем требующим этого программам. Серверов приложений может быть несколько, причем каждый из них предоставляет свой вид сервиса. Любая программа, запрашивающая услугу у сервера приложений, является для него клиентом. Поступающие от клиентов к серверам запросы помещаются в очередь, из которой выбираются в соответствии с некоторыми правилами, например, по приоритетам. Компонент, реализующий функции представления и являющийся клиентом для сервера приложений, в этой модели трактуется более широко. Он может служить для организации интерфейса с конечным пользователем, обеспечивать прием данных от устройств, например, датчиков, или быть произвольной программой. Достоинством AS-модели является гибкость и универсальность вследствие разделения функций приложения на три независимые составляющие. Во многих случаях эта модель оказывается более эффективной по сравнению с двухзвенными. Основной недостаток модели – более высокие затраты ресурсов компьютеров на обмен информацией между компонентами приложения по сравнению с двухзвенными моделями. Модель монитора транзакций. AS-модель описывает взаимодействие трех основных элементов: клиента, сервера приложений и сервера БД, но не затрагивает вопросы организации функционирования программного обеспечения при обработке информации, в частности при выполнения транзакций. Для преодоления этого недостатка предложена модель монитора транзакций. Мониторы обработки транзакций (Transaction Processing Monitor – TPM), или мониторы транзакций, представляют собой программные системы категории промежуточного слоя (Middleware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной вычислительной системе. Основное их назначение – организация гибкой, открытой среды для разработки и управления мобильными приложениями, оперативно обрабатывающими распределенные транзакции. Применение монитора транзакций наиболее эффективно в гетерогенных вычислительных системах. Принципы организации обработки информации с помощью монитора транзакций описываются моделью монитора транзакций X / Open DTP (Distributed Transaction Processing – обработка распределенных транзакций). Эта модель включает в себя три объекта: прикладную программу, менеджер ресурсов (Resource Manager – RM) и монитор, или менеджер транзакций (Transaction Manager – TM). В качестве прикладной программы может выступать произвольная программа-клиент. Менеджер ресурсов RM выполняет функции сервера ресурса некоторого вида. Прикладная программа взаимодействует с RM с помощью набора специальных функций либо посредством операторов SQL (когда сервером является сервер БД). Функции менеджера ресурсов обычно выполняют серверы БД. В задачах организации управления обработкой распределенных транзакций (транзакций, затрагивающих программные объекты вычислительной сети) ТМ взаимодействует с RM, который должен поддерживать протокол двухфазной фиксации транзакций и удовлетворять стандарту X / Open XA. Примерами СУБД, поддерживающих протокол двухфазной фиксации транзакций, являются Oracle 7.0, Open INGRES, Informix- Online 5.0. Понятие транзакции в ТРМ (монитор транзакций) несколько шире, чем в СУБД, где транзакция включает в себя элементарные действия над данными базы. Здесь транзакция может охватывать и другие необходимые действия: передачу сообщения, запись информации в файл, опрос датчиков и т.д. Транзакции, которые поддерживают ТРМ, называют также прикладными или бизнес - транзакциями. Для разработчиков приложений мониторы обработки транзакций ТРМ предоставляют удобства, связанные с возможностью декомпозиции приложений по нескольким функциональным уровням со стандартными интерфейсами, что позволяет создавать легко модифицируемые ИС со стройной архитектурой. Для пользователей распределенных систем ТРМ позволяют улучшить показатели пропускной способности и времени отклика, снизить стоимость обработки данных в оперативном режиме на основе эффективной организации вычислительного процесса. Администраторы распределенных систем, имея ТРМ, получают возможность легкого масштабирования ИС и увеличения производительности обработки информации. Без остановки серверов приложений в любое время может быть добавлен, например, компьютер или менеджер ресурсов. Управление распределенными данными С управлением данными в распределенных системах связаны следующие две группы проблем: поддержка соответствия БД вносимым изменениям и обеспечение совместного доступа нескольких пользователей к общим данным. Поддержка соответствия БД вносимым изменениям. В современных распределенных системах информация может храниться централизовано или децентрализовано. В первом случае проблемы идентичности представления информации для всех пользователей не существует, так как все последние изменения хранятся в одном месте. На практике информация может изменяться одновременно в нескольких узлах распределенной вычислительной системы. В этом случае возникает проблема контроля за всеми изменениями информации и предоставления ее в достоверном виде всем пользователям. Существует две основные технологии децентрализованного управления БД: распределенных БД (Distributed Database) и тиражирования, или репликации, БД (Data Replication). Распределенная БД состоит из нескольких фрагментов, размещенных на разных узлах сети и, возможно, управляемых разными СУБД. С точки зрения программ и пользователей, обращающихся к распределенной БД, последняя воспринимается как единая локальная БД (рис. 3). Информация о местоположении каждой из частей распределенной БД и другая служебная информация хранится в так называемом глобальном словаре данных. В общем случае этот словарь может храниться на одном из узлов или тоже быть распределенным. Рис. 3 Модель распределенной БД Для обеспечения корректного доступа к распределенной БД в современных системах чаще всего применяется протокол (метод) двухфазной фиксации транзакций (two-phase commit). Сущность этого метода состоит в двухэтапной синхронизации выполняемых изменений на всех задействованных узлах. На первом этапе в узлах сети производятся изменения в их БД, о чем посылаются уведомления компоненту системы, управляющему обработкой распределенных транзакций. Часть 1 Б Д Часть 2 Б Д |