Основы проектирования приложений баз данных

       

Основы проектирования приложений баз данных

Интерфейс ODBC (Open Database Connectivity) был разработан фирмой Microsoft как открытый интерфейс доступа к базам данных. Он предоставляет унифицированные средства взаимодействия прикладной программы, называемой клиентом (или приложением-клиентом), с сервером - базой данных.
В основу интерфейса ODBC были положены спецификация CLI-интерфейса (Call-Level Interface), разработанная X/Open, и ISO/IEC для API баз данных, а также язык SQL (Structured Query Language) как стандарт языка доступа к базам данных.
Интерфейс ODBC проектировался для поддержки максимальной интероперабельности приложений, которая обеспечивает унифицированный доступ любого приложения, использующего ODBC, к различным источникам данных. Так, если приложение, соответствующее стандарту ODBC и SQL, первоначально разрабатывалось для работы с базой данных Microsoft Access, а затем таблицы этой базы были перенесены в базу данных Microsoft SQL Server или базу данных Oracle, то приложение сможет и дальше обрабатывать эти данные без внесения дополнительных изменений.

Основа ODBC
Для взаимодействия с базой данных приложение-клиент вызывает функции интерфейса ODBC, которые реализованы в специальных модулях, называемых ODBC-драйверами. Как правило, ODBC-драйверы - это DLL-библиотеки, при этом одна DLL-библиотека может поддерживать несколько ODBC-драйверов. При установке на компьютер любого SQL-сервера (базы данных, поддерживающей один из стандартов языка SQL, например, SQL-92) автоматически выполняется регистрация в реестре Windows и соответствующего ODBC-драйвера.

Основные функции ODBC
Как уже отмечалось в предыдущей лекции, все функции ODBC API условно можно разделить на четыре группы: основные функции ODBC, обеспечивающие взаимодействие с источником данных; функции установки (setup DLL); функции инсталляции (installer DLL) ODBC и источников данных;функции преобразования данных (translation DLL), вызываемые при передаче данных от драйвера к источнику данных или обратно.

Схема доступа к источнику данных с использованием ODBC API


Первым шагом при реализации доступа к источнику данных посредством ODBC API без применения пула соединений является создание дескриптора окружения. После выделения памяти под дескриптор окружения приложение должно вызвать функцию SQLSetEnvAttr для задания значения атрибуту дескриптора окружения SQL_ATTR_ODBC_VERSION. Если не установить номер версии ODBC API, то при создании дескриптора соединения функция SQLAllocHandle вернет код ответа SQLSTATE равным HY010, что соответствует коду произошедшей ошибки.

Схема извлечения данных с использованием ODBC API
Для извлечения данных с использованием ODBC API сначала следует вызвать функцию, выполняющую SQL-оператор, который определяет формируемый результирующий набор. И только затем можно приступать к выборке данных. ODBC API предоставляет два способа извлечения данных из результирующего набора: с предварительным связыванием полей результирующего набора с переменными основного языка программирования;прямая выборка каждого поля результирующего набора в указываемую переменную основного языка программирования.

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

Курсоры
Применение курсоров позволяет приложению выполнять выборку одной или нескольких строк за одну операцию извлечения данных. Также курсоры поддерживают возможность применения операторов UPDATE, INSERT и DELETE к текущей позиции курсора. Для использования курсора следует установить соединение с базой данных и установить нужные значения атрибутам оператора, контролирующим поведение курсора.

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

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

Объектная модель OLE DB
Можно сказать, что OLE DB - это метод доступа к любым данным через стандартные COM-интерфейсы, вне зависимости от типа данных и места их расположения. В качестве данных могут выступать базы данных, простые документы, таблицы Excel и любые другие источники данных. В отличие от доступа, предоставляемого посредством драйверов OBDC, OLE DB позволяет реализовывать доступ к источникам данных, как с применением языка SQL (к SQL-серверам), так и к любым другим произвольным источникам данных.

Библиотека MFC
Среда Visual Studio.NET предоставляет различные подходы для реализации работы с базами данных: Применение библиотеки MFC (Microsoft Foundation Class Library). Применение ATL (Active Template Library). Использование библиотек Framework. Библиотека MFC реализует поддержку доступа к базам данных, основанную на двух механизмах: через ODBC-драйверы; с применением провайдеров данных OLE DB.

Классы, используемые для доступа к БД
ATL предоставляет OLE DB шаблоны как С++ шаблоны для реализации клиентов и серверов OLE DB. Для реализации клиента OLE DB провайдера можно использовать следующие классы: CDataConnection - класс, управляющий соединением с источником данных и инкапсулирующий поведение объектов OLE DB "источник данных" (DataSource) и "сеанс" (Session). CDataSource - класс, соответствующий объекту OLE DB источник данных, предоставляющий соединение с источником данных через OLE DB провайдера. Для одного соединения можно создать несколько объектов сеансов (CSession).

Механизмы доступа к БД
Основными механизмами доступа к данным, поддерживаемым в Delphi, являются: ODBC - доступ через ODBC-драйверы БД или BDE-драйверы; OLE DB - доступ с использованием провайдеров данных (OLE DB - это метод доступа к любым данным через стандартный COM-интерфейс); средства dbExpress, использующие легковесные драйверы БД; средства доступа к распределенным наборам данных в многозвенной архитектуре.

Работа с базами данных
При реализации доступа через SQLJ SQL-операторы встраиваются непосредственно в код на языке Java, а затем обрабатываются SQLJ-предкомпилятором. Обычный SQLJ-предкомпилятор ограничивает синтаксис встраиваемых SQL-операторов стандартом SQL-92. Однако при применении SQLJ-предкомпиляторов, ориентированных на конкретные СУБД, допускается использование конструкций языка SQL, реализуемых в этих СУБД. Так, SQLJ-предкомпилятор для Oracle 9i позволяет не только статическое, но и динамическое встраивание SQL-операторов.

Создание сервлета, используемого для публикации данных
Создание нового проекта и размещение в нем Web-приложения. Добавление в Web-приложение нового сервлета (используя команду меню File|New и выбирая на вкладке Web пиктограмму Servlet). Для возможности обработки GET и POST HTTP-запросов в мастере Servlet Wizard на панели Implement methods следует установить флажки для методов doGet и doPost. Создание модуля данных и определение подключаемого источника данных. Создание HTML-файла, отображающего форму для публикации данных.

Три манифеста баз данных ретроспектива и перспективы

В период с 1989 по 1995 гг. авторские группы, включающие известных специалистов в области баз данных, подготовили и опубликовали три документа [1-3], которые отражали точки зрения авторов относительно перспектив развития технологии баз данных. С легкой руки авторов хронологически первого документа эти документы получили название манифестов, что, в общем-то, отражало их суть: в каждом из документов провозглашался набор идей и требований, на которых, по мнению авторов, должны были базироваться системы баз данных следующего поколения.
Интересно отметить различия между коллективами авторов каждого из манифестов. “Манифест систем объектно-ориентированных баз данных” [1] (далее в этой статье для краткости мы будем называть его Первым манифестом) написан академическими исследователями; почти все они являются профессорами различных университетов. Конечно, это нашло свое отражение в стиле Первого манифеста – очень мягком и умеренно рекомендательном (хотя по своему духу предложения этого манифеста были весьма радикальными).

Введение
Интересно отметить различия между коллективами авторов каждого из манифестов. “Манифест систем объектно-ориентированных баз данных” (далее в этой статье для краткости мы будем называть его Первым манифестом) написан академическими исследователями; почти все они являются профессорами различных университетов. Конечно, это нашло свое отражение в стиле Первого манифеста – очень мягком и умеренно рекомендательном (хотя по своему духу предложения этого манифеста были весьма радикальными).

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

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

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

Введение в системы управления базами данных

Основное назначение данного учебного пособия - дать систематическое введение в основы реляционной модели данных и принципы функционирования реляционных баз данных.
Реляционная модель описывает, какие данные могут храниться в реляционных базах данных, а также способы манипулирования такими данными. В упрощенном виде основная идея реляционной модели состоит в том, что данные должны храниться в таблицах и только в таблицах. Эта, кажущаяся тривиальной, идея оказывается вовсе не простой при рассмотрении вопроса, а что, собственно, представляет собой таблица? В данный момент существуем много различных систем обработки данных, оперирующих понятием "таблица", например, всем известные, электронные таблицы, таблицы текстового редактора MS Word, и т.п. Ячейки электронной таблицы могут хранить разнотипные данные, например, числа, строки текста, формулы, ссылающиеся на другие ячейки. Собственно, на одном листе электронной таблицы можно разместить несколько совершенно независимых таблиц, если под таблицей понимать прямоугольную область, расчерченную на клеточки и заполненную данными.

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

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

Оптимизация запросов в системах баз данных

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

Цели оптимизации

Основы проектирования реляционных баз данных

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

Архитектура СУБД