Даровой inscription html. Фундаментальная уязвимость HTML при встраивании скриптов. Почему это происходит

Реляционные базы данных и объектно-ориентированные среды

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

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

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

Реляционная модель

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

Реляционная модель

У объекта есть столбцы. У каждого столбца есть имя и тип. На рисунке выше у объекта LINEITEM есть столбцы LineItem_Id (основной ключ), Description, Price, Quantity, Product_Id и Order_Id (последние два столбца - внешние ключи, привязывающие объект LINEITEM к объектам ORDER и PRODUCT).

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

У каждого объекта есть один или несколько основных ключей. LineItem_Id - основной ключ объекта LINEITEM.

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

У взаимосвязей есть понятие множественности. Типичные примеры множественности - один к одному (1:1), один ко многим (1:m), многие к одному(m:1) и многие ко многим (m:n). В данном примере у LINEITEM взаимосвязь 1:1 с PRODUCT, а у PRODUCT взаимосвязь 0:m с LINEITEM.

Объектная модель

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

Объектная модель (диаграмма класса)

У атрибута Order есть атрибут number (номер заказа) и связь с одним или несколькими атрибутами Line. У каждого атрибута Line есть атрибут quantity (количество заказанных единиц товара).

Объектная модель поддерживает наследование. Класс может наследовать данные и поведение у другого класса (например, продукты SoftwareProduct и HardwareProduct могут наследовать атрибуты и методы у класса Product).

Среды хранения

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

Существует несколько стандартных интерфейсов (API) для работы с базами данных, например Microsoft Open Data Base Connectivity (ODBC). Все эти интерфейсы закрыты (взаимодействуют с конкретными реализациями СУБД). Интерфейсы API поддерживают язык управления данными (DML), применяемый приложениями для работы с реляционными базами данных. Для применения реляционных данных в объектно-ориентированных приложениях требуется преобразование этих данных в объектно-ориентированный формат. Для преобразования выборки данных в объекты приложения требуется довольно весомый программный код. Цель объектно-реляционной среды заключается в инкапсуляции физического хранилища данных и предоставлении функции преобразования данных в объектный формат.

Назначение среды хранения

Около 30% времени разработчики приложений тратят на организацию доступа к реляционным базам данных из объектно-ориентированных приложений. Если объектно-ориентированный интерфейс реализован неправильно, это время можно считать потерянным. Создание объектно-реляционной среды позволяет избежать таких потерь. Применение объектно-реляционной среды в приложениях позволяет сократить стоимость организации доступа к реляционным базам данных до менее чем 10% общей стоимости реализации. Важнейший компонент стоимости, который следует принимать во внимание при реализации, - обслуживание. Свыше 60% общей стоимости системы на протяжении ее жизненного цикла составляет обслуживание. Плохо реализованная объектно-реляционная система может стать настоящим кошмаром при обслуживании системы как с технической, так и с финансовой точек зрения.

Основные характеристики объектно-реляционной среды

• Производительность . Необходимо уделить пристальное внимание преобразованию объектов в данные и данных в объекты. В системах с интенсивной обработкой данных этот элемент зачастую представляет собой ахиллесову пяту всей системы доступа к данным.
• Технические решения . Типичный подход специалистов по объектным системам при работе с реляционными базами данных заключается в подгонке объектной модели под структуру базы данных или подгонке структуры реляционной базы данных под объектную модель для упрощения хранения объектов. Хотя зачастую требуется минимальная коррекция, эффективная система доступа минимизирует отрицательное влияние такой коррекции на эффективность как реляционной, так и объектной модели.
• Расширяемость . Система доступа к данным должна быть расширяемой на случай, если в будущем понадобится адаптировать ее к новым потребностям. Как правило, система доступа к данным без расширений должна поддерживать 65-85% требований приложения к хранению данных. Если система доступа не допускает расширения, реализация оставшихся 35-15% требований может стать очень сложной и дорогостоящей.
• Документация . Система доступа - это одновременно и закрытая система, и открытая среда. Интерфейсы закрытой системы должны быть четко определены, задокументированы и ясно описаны. Как указано выше, система доступа должна быть легко расширяемой. Для этого она должна быть снабжена подробной документацией. Необходимо определить множество классов, для которых предполагается создание подклассов. Необходимо задать характеристики всех соответствующих протоколов классов (например, public, private, protected, final, ...). Кроме того, для упрощения расширения системы в будущем рекомендуется открыть и задокументировать как можно больше ее компонентов.
• Поддержка общих объектно-реляционных преобразований . Система доступа должна поддерживать базовые объектно-реляционные преобразования без дополнительных расширений. Эти преобразования подробно обсуждаются в следующих разделах данного документа.
• Интерфейсы хранения : модель бизнеса для объектного приложения в объектно-ориентированной среде должна охватывать смысл предметной области. Разработчики должны оперировать объектами и обеспечивать взаимодействие между ними без необходимости задумываться над особенностями считывания и записи данных. В распоряжении разработчиков приложений должен быть хороший набор хранимых интерфейсов (сохранение, удаление, поиск данных).

Общие службы объектно-реляционной среды

В разработке объектно-реляционных приложений намечаются общие тенденции. Специалисты, неоднократно занимавшиеся интеграцией подобных систем, начинают понимать и выявлять определенные структуры и свойства удачных объектно-реляционных приложений. Эти структуры и свойства были формализованы в высокоуровневых спецификациях CORBA (которые относятся и к системам на основе COM/DCOM).

При разработке объектно-реляционных систем следует принять во внимание следующие спецификации служб CORBA:

В следующих разделах обсуждение объектно-реляционных служб структурировано по этим категориям. Настоятельно рекомендуется ознакомиться с соответствующими спецификациями CORBA.

Хранение

Термин "хранение" применяется для описания механизма, который используется для сохранения состояния объектов в промежутках между сеансами. Среда хранения позволяет пользователю сохранять объекты в конце сеанса работы, а затем обращаться к ним из следующего сеанса. При обращении к объектам из следующего сеанса их состояние (например, набор атрибутов) будет точно соответствовать их состоянию на момент сохранения в предыдущем сеансе. В многопользовательских системах это правило может не выполняться, поскольку разные пользователи могут изменять одни и те же объекты. Хранение взаимосвязано с другими службами, обсуждаемыми в этом разделе. В частности, взаимосвязь с параллелизмом и другими категориями намеренна и соответствует структуре классификации служб CORBA.

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

• Управление соединением с источником данных : объектно-реляционные приложения должны устанавливать соединение с физическим источником данных. Как правило, реляционные СУБД представляют собой комплекс из сервера и базы данных. Особенности управления соединениями зависят от разновидности СУБД, и среда должна быть достаточно гибкой для поддержки различных систем.
• Извлечение объектов : извлечение объектов из базы данных заключается в том, что данные считываются из базы данных и преобразуются в объекты. Данный процесс предполагает извлечение данных из структур базы данных, маршализацию данных в соответствующие классы и типы объектов и формирование необходимых атрибутов объектов.
• Сохранение объектов : процесс сохранения объектов обратен процессу их извлечения. Значения атрибутов извлекаются из объекта, затем создается структура базы данных со значениями атрибутов (строка SQL, хранимая процедура или особый вызов RPC), а затем полученная структура заносится в базу данных.
• Удаление объектов : объекты удаляются из системы, а соответствующие им данные - из базы данных. Для удаления объектов необходимо извлечь из них соответствующую информацию, создать запрос на удаление (это может быть строка SQL, хранимая процедура или особый вызов RPC), а затем передать запрос в базу данных. Учтите, что в некоторых языках (например, Smalltalk и Java) явное удаление не поддерживается. Вместо этого там применяется стратегия сбора мусора . В системах хранения, поддерживающих эти языки, должен быть предусмотрен альтернативный способ удаления данных из базы после того, как приложения перестают пользоваться ими. Один из распространенных способов заключается в учете количества ссылок на объект из других объектов. Как только количество ссылок падает до нуля, на этот объект больше не ссылаются другие объекты, и возможно , этот объект больше не нужен. В некоторых случаях можно удалять объекты с нулевым количеством ссылок, поскольку даже если на объект нет ссылок, он может использоваться. В любом случае нужна централизованная стратегия удаления объектов, действующая в масштабах всей базы данных.

Запрос

От системы хранения мало пользы в отсутствие механизма поиска и извлечения нужных объектов. Средства поиска применяются для нахождения объектов, удовлетворяющих определенным условиям. Стандартные операции поиска в объектно-реляционных средах - find и find unique. Операция find unique возвращает конкретный объект, а операция find - набор объектов, соответствующих заданным критериям.

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

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

Транзакции

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

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

Параллелизм

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

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

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

Взаимосвязи

У объектов есть взаимосвязи с другими объектами. У объекта Order есть несколько объектов Line Item. У объекта Book есть много объектов Chapter. Объект Employee принадлежит ровно одному объекту Company. В реляционных системах взаимосвязи между объектами реализованы с помощью ссылок на основные и внешние ключи. В объектно-ориентированных системах такие взаимосвязи обычно явно заданы с помощью атрибутов. Если у объекта Order есть объекты LineItems, объект Order будет содержать атрибуты lineItems. Атрибут lineItems объекта Order может содержать произвольное количество объектов LineItem.

Аспекты взаимосвязей в объектно-реляционной среде тесно связаны с вопросами реализации хранения, транзакций и выполнения запросов. При сохранении и выборке объектов, выполнении транзакций и запросов необходимо учитывать следующие факторы:

• Нужно ли вместе с объектом извлекать из базы данных объекты, с которыми он связан? Простой ответ на этот вопрос - "да", но цена извлечения ненужных объектов может быть очень большой. В хорошей среде могут поддерживаться несколько стратегий на этот счет.
• Нужно ли при сохранении объекта заодно сохранять и связанные с ним объекты, которые также были изменены? Ответ на этот вопрос тоже зависит от контекста.

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

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

К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).

В большинстве реализаций ОРМД объектами признаются агрегат и таблица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, которые являются процедурными объектами базы данных, и связаны с таблицами. На концептуальном уровне все данные объектно-реляционной БД представлены в виде отношений, и ОРСУБД поддерживают язык SQL.

Объектно-ориентированная модель данных

Ещё один подход к построению БД – использование объектно-ориентированной модели данных (ООМД) . Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

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

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

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

В 2000 г. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.

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

Обзор современных систем управления базами данных (СУБД)

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

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

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

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

Классификация СУБД

По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).

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

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

• не достигается требуемого быстродействия обработки данных;
• необходима работа СУБД в условиях жёстких аппаратных ограничений;
• требуется поддержка специфических функций обработки данных.

СпСУБД предназначены для решения конкретной задачи, а приемлемые параметры этого решения достигаются следующим образом:

1. за счёт знания особенностей конкретной предметной области,
2. путём сокращения функциональной полноты системы.

Создание СпСУБД – дело весьма трудоёмкое, поэтому для того, чтобы выбрать этот путь, надо иметь действительно веские основания. В дальнейшем будут рассматриваться только СУБД общего назначения.

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

Информационная система, построенная по принципу клиент/сервер, состоит обычно из трех основных компонентов:

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

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

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

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

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

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

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

Основные преимущества клиент/сервер по сравнению с аналогичными информационными системами заключаются в следующем.

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

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

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

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

По модели данных различают иерархические, сетевые, реляционные, объектно-реляционные и объектно-ориентированные СУБД.

Для реляционных СУБД Э.Ф. Кодд предложил и обосновал 12 правил, которым должна удовлетворять реляционная СУБД данных (РСУБД).

Правила Кодда для реляционной СУБД (РСУБД)

1. Явное представление данных (The Information Rule). Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, храня-щиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.
2. Гарантированный доступ к данным (Guaranteed Access Rule). К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.
3. Обработка неизвестных значений (Systematic Treatment of Null Values). Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных – как пустые строки.
4. Динамический каталог данных, основанный на реляционной модели (Dynamic On-Line Catalog Based on the Relational Model). Каталог (или словарь-справочник) данных должен сохраняться в форме реляционных таблиц, и РСУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
5. Полнота подмножества языка (Comprehensive Data Sublanguage Rule). РСУБД должна поддерживать единственный язык, который позволяет выполнять все операции над данными: определение данных (DDL, Data Definition Language), манипулирование данными (DML, Data Manipulation Language), управление доступом пользователей к данным, управление транзакциями.
6. Поддержка обновляемых представлений (View Updating Rule). Представление (view) – это хранимый запрос к таблицам базы данных. (Подробнее о представлениях рассказано в ). Обновляемое представление должно поддерживать все операции манипулирования дан-ными, которые поддерживают реляционные таблицы: операции вставки, модификации и удаления данных.
7. Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete). Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке таблицы, но по отношению к любому множеству строк произвольной таблицы.
8. Физическая независимость данных (Physical Data Independence). Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютера, на котором находится БД. РСУБД должна предоставлять некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения изменений в логическое представление данных. Это позволяет оптимизировать среду хранения данных с целью повышения эффективности системы, не затрагивая созданных прикладных программ, работающих с БД.
9. Логическая независимость данных (Logical Data Independence). Это свойство позволяет сконструировать несколько различных логических взглядов (представлений) на одни и те же данные для разных групп пользователей. При этом пользовательское представление данных может сильно отличаться не только от физической структуры их хранения, но и от концептуальной (логической) схемы данных. Оно может синтезироваться динамически на основе хранимых объектов БД в процессе обработки запросов.
10. Независимость контроля целостности (Integrity Independence). Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных. Это реализуется с помощью ограничений целостности и механизма транзакций (см. разделы 5.2 и 6.1).
11. Независимость от распределённости (Distribution Independence). База данных может быть распределённой (может находиться на нескольких компьютерах), и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияние на приложения.
12. Согласование языковых уровней (Non-Subversion Rule). Не должно быть иного средства доступа к данным, отличного от стандартного языка для работы с данными. Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и целостности, которые поддерживаются языком более высокого уровня.

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

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

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

Виды структур

"Промежуточной" моделью данных между реляционными и объектно-ориентированными базами данных является объектно-реляционная модель (ОРБД).

Ее появление вызвано двумя причинами.

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

Различают, как отмечалось ранее, две разновидности ОРБД – гибридные и расширенные.

• 1. В гибридных ОРБД интерфейс пользователя и алгоритм приложения выполнены с учетом объектно-ориентированного подхода, тогда как собственно БД является реляционной. Примерами могут служить СУБД Paradox и InterBase в рамках программного продукта Delphi. В каком-то смысле гибридной можно считать СУБД Access при использовании языка программирования Visual Basic for Application (VBA).
• 2. В расширенных (постреляционных) ОРБД предполагается объектно-ориентированное построение собственно базы данных путем использования известных и введения новых типов данных, связанных между собой. Эта связь чаще всего осуществляется созданием методов с помощью триггеров и хранимых процедур. В расширенной объектно-реляционной модели допускается, в отличие от реляционной модели данных, неатомарность данных в поле. В таких полях может располагаться другая таблица или массив. К подобным СУБД относятся Informix Universal Server, Oracle 8, UniSQL. В таких СУБД широко используется язык SQL3.

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

Рассмотрим более подробно обе разновидности.

Гибридные ОРБД

Эта разновидность ОРБД рассмотрена на примере программного продукта Delphi.

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

В дальнейшем выяснилось, что примененный в Delphi объектно-ориентированный подход может быть использован при проектировании баз данных. В рамках Delphi применение объектно-ориентированного проектирования (см. рис. 7.2) и программирования не вызывает затруднений в интерфейсе пользователя и алгоритме приложения. Покажем это.

При работе Delphi на экране монитора появляется "картинка" (рис. 8.1). Компоненты-классы разделены на группы, определяемые соответствующими закладками (страницами).

Форма Delphii, сама являясь объектом, служит "коллектором" для объектов. Как только компонент помещается в форму (и получает порядковый номер), он становится объектом.

Заметим, что компоненты TPanel, TBevel также являются контейнерами (в форме), используемыми для форматирования, дизайна (разделения объектов и их выравнивания). Другими "миниконтейнерами" служат компоненты DataModule и TQuickRep (отчет).

Рис. 8.1. Экран для работы с приложением Delphi

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

Все компоненты разделены на следующие основные группы: Standard, Additional, Dialogs, Win32, System, VCL, Internet, DataAccess, DataControl, QReport, Decision Cube, ActiveX. В процессе автоматизированного программирования чаще всего используют первые четыре страницы.

С позиций собственно баз знаний и баз данных следует обратить особое внимание на страницы DataAccess и DataControI. К ним примыкают страницы QReport, Decision Cube.

Состав компонентов некоторых закладок DataAccess и DataControI показан на рис 8.2. На рис. 8.3 и 8.4 показаны свойства и события компонента ТТаblе.

Рассмотрим описание программных возможностей Delphi.

Приложение Delphi может работать с тремя реляционными СУБД: dBase, Paradox – в локальном режиме (рис. 8.3); InterBase, который инсталлируется отдельно, – в режиме клиент-сервер.

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

Рис. 8.2. Состав некоторых страниц компонента Delphi

Независимо от используемой СУБД интерфейс пользователя и алгоритм приложения строится с использованием объектно-ориентированного подхода. Подтвердим кратко это утверждение.

А. Речь первоначально пойдет о реализации собственно базы данных.

А1. Первоначально задается имя БД. С помощью этого имени осуществляется ссылка на БД. Однако при этом требуется указывать порой длинный путь (адрес) доступа, что неудобно при многократном обращении к БД. В силу этого чаще используется али- ас (синоним ) БД – имя, заменяющее длинный путь. Построение алиаса ведется с помощью Delphi-утилит BDE Administrator и SQL Explorer.

А2. Создание таблиц БД для СУБД Paradox (локальный режим) и InterBase (режим "клиент-сервер"), равно как и заполнение БД данными, специфично для каждого случая. Нетрудно видеть, что при создании собственно базы данных не используется объектно- ориентированный подход.

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

Интерфейс составляется с учетом пожеланий пользователя. Вид интерфейса зависит от инструментария, предоставляемого СУБД или программным приложением.

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

Рис. 8.3. Свойства компонента Table

Для Delphi исходным инструментом чаще является система форм, вызываемая из головного меню или с помощью системы элементов управления и меню в главной форме.

Б1. Формы Delphi.

Рис. 8.4. События компонента Table

Б1.1. Формы Delphi часто называют окнами. Окно называют модальным (М), если доступ к предыдущему открытому окну возможен только после закрытия М-окна. В противном случае окно называют немодальным.

Пусть имеются две формы – Form1 и Form2, при этом Form2 вызывается из Form1.

В случае немодального окна для формы Forml пишется программный модуль uniti

procedure TForml .Button 1 Click(Senser: Tobject);

Чтобы можно было работать со вторым окном (формой), в программе uniti (раздел implementation) добавляется ссылка на программный модуль unit2 (формы Form2)

Теперь из uniti можно запускать немодальное окно Form2.

Чтобы сделать Form2 модальным окном, следует установить ее свойство BorderStyle=bsDialog. При этом надо внести изменения в uniti: вместо Forml.Show написать Form2.ShowModal.

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

• многодокументный интерфейс (Multiple Document Interface – М DI);
• однодокументный интерфейс (Simple Document Interface – SDI).

При использовании MDI дочерние окна не превышают по размерам родительское окно и могут располагаться мозаикой (Title) или каскадом (Cascade). В родительском окне содержится главное меню приложения. MDI организуется так же, как модальное окно, при этом свойство FormStyle=fsMDIFomi для родительского окна и FormStyle=fsMDIChild – для дочерних окон. При создании MDI возможно использование шаблона или построение MD1 с "нуля".

В последнем случае выбирается File/New головного меню Delphi и в диалоговом окне New Items на странице New выделяют значок Application, вводя по очереди родительское и дочерние окна.

В программный модуль unit главного окна включаются ссылки на все дочерние unit-модули:

В unit-программах дочерних окон должны быть ссылки на unit- программу главного окна:

Перед сворачиванием главного окна первоначально сворачиваются дочерние окна.

Лучше использовать шаблоны SOI (MDI). Для этого обращаются к головному меню Delphi (File/New), входят в диалоговое окно New Items и на вкладке (странице) Projects выбирают необходимый шаблон: SDI (одна форма и один программный модуль) или MDI (две формы и три модуля).

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

Б2.1. Формирование меню достаточно просто и потому подробно здесь не рассматривается. Упорядочение элементов меню (фактически – объектов), написание программ для них не отличаются от "привязывания" программ к таким элементам управления, как кнопка, поле со списком и т. д. Заметим лишь, что есть две разновидности меню – главное (TMainMenu страницы Standard) и всплывающее меню (TPopuMenu), вызываемое нажатием правой кнопки мыши.

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

Свойствами меню, равно как и системы кнопок, наиболее часто используемыми, являются Enabled и Visible.

Б3 . Гибкость меню обеспечивается использованием элементов управления.

Б3.1 . Универсальные элементы управления размещены на страницах Standard, Additional, Dialog палитры компонент. К таким элементам относятся TLabel, TEdit, TMemo, TComboBox. TButton, TBitBtn.

Специфично использование TLabel. Свойство Caption применяют для задания заголовков таблиц БД, названий к таким компонентам, как TEdit, TMemo.

В свою очередь свойства Editl.Text и Memol.Line применяют для задания параметров (одно- и многострочных), например, в запросах. Пожалуй чаще всего перечисленные элементы управления используют свойства Enabled, Visible.

Б3.2 . Специализированными элементами управления, связанными непосредственно с БД, являются компоненты страницы DataControl. К ним следует отнести прежде всего DBGrid, DBEEdit, DBNavigator, DBMemo.

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

Б4 . Сообщение. Его можно сделать обычным, используя, например,

MessageDlg(Query1["Name"], mtlnformation, , О);

Однако предпочтительнее применить схему исключительной ситуации try ... except

Query1["Plan"]< Queryl ["Fakt"]

ShowMessage("Число вакансий меньше числа принимаемых. Измените правила или должности принимаемых");

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

В. Алгоритм приложения. Программы приложений могут быть написаны на одном или сочетании трех языков: интерфейсный SQL, вложенный SQL, Object Pascal (OP) .

B.l . Возможны три "цепочки" доступа (рис. 8.5):

TTable – TDataSource – TDBGrid (чаще используется в СУБД Paradox);

TQuery – TDataSource – TDBGrid (чаще применяются для СУБД InterBase);

TStoredProc – TDataSource – TDBGrid (ислользуют только для СУБД InterBase).

Рис. 8.5. Объектно-ориентированный интерфейс пользователя (приложение Delphi):

BDE – Borland Database Engine (ядро Delphi)

В этих "цепочках" компонент TDBGrid является визуальным, а остальные – невизуальны. Компоненты TTable, TQuery, TStoredProc обеспечивают непосредственный доступ к БД (по алиасу), тогда как компонента TDataSource играет роль "размножителя": к нему могут подключаться визуальные компоненты TDBNavigator, TDBText, TDBEdit, TDBMemo, TDBListBox, TDBComboBox и другие. Эти подключаемые компоненты (если "спрятать" компонент TDBGrid с помощью свойства Visible или, лучше, Enabled) могут образовывать "аналог" форм Access (для заполнения БД). Понятие "форма" в смысле Access в Delphi отсутствует.

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

"Цепочка" StoredProc специфична и используется только в режиме клиент-сервер, да и то редко.

В.2 . Наряду с перечисленными "цепочками" могут использоваться и "укороченные цепочки", составленные из невизуальных объектов, контейнером для которых служит модуль (объектов) DataModule.

Такой контейнер организуется через меню Delphi (File/ NewDataModule). Связь между компонентами TTable – TDataSource и TQuery – TDataSource устанавливается так же, как это делается в форме при использовании ее в качестве контейнера для рассмотренных ранее "цепочек".

DataModule сохраняется под каким-либо именем, и для него создается программный модуль unit, имя которого добавляется в тексты программных модулей других форм приложения (File/Use Unit). При ссылках на такой модуль (объектов) следует сначала указать его имя, например DataModulel.DataSourcel.

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

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

В3 . Вложенный SQL используется только в режиме клиент- сервер.

В4 . Интерфейсный SQL используется в локальном режиме и режиме клиент-сервер.

Заметим, что интерфейсный язык SQL достаточно гибок при работе с БД, однако в нем нет понятия циклов и переходов. Кроме того, в свойстве SQL компоненты TQuery (или свойстве любой компоненты, например Memo.Text, из которой заимствуется SQL-oпeратор) может быть записан и запущен только один оператор , после выполнения которого его следует удалить и ввести новый. Таким образом, для выполнения нескольких операторов их следует вводить по одному, для чего требуется непростое программное решение, или "встраивать" в операторы Object Pascal.

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

В локальном режиме чаще используют язык Object Pascal, составляющими операторами которого могут быть SQL-операторы.

В5 . Основную роль в локальном режиме играет язык программирования Object Pascal. В режиме клиент-сервер он, совместно с интерфейсным языком SQL, используется в клиентской части.

Следует отметить, что в Object Pascal существуют две разновидности программ:

• 1) "привязанные" непосредственно к событиям;
• 2) не связанные напрямую с событием (обычно "привязанные к форме") и вызываемые из других программ.

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

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

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