Понятие о базах данных и СУБД

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

Общие требования к системам обработки данных

 

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

 

Какую информацию должен хранить справочник по играм? Желательно, например,

чтобы каждая его запись имела следующие поля:

·        название игры;

·        жанр;

·        удалось ли сыграть;

·        фирма-издатель;

·        фирма-разработчик;

·        год выхода;

·        время выхода (сезон);

·        возможность сетевой игры;

·        ссылка на странички в Интернете;

·        ссылка на статьи в журналах;

·        оценка в баллах (по 10-балльной шкале);

·        оценка графики в баллах;

·        оценка звука в баллах;

·        комментарии.

 

 

Требования к программе и справочнику:

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

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

·        возможность хранить временные наборы записей и формировать на их основе отчеты.

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

·        надежность работы.

·        возможность создания ссылок на другие записи аналогичной структуры.

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

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

 

База данных Компьютерные игры

 

 

    FIRMS Справочник фирм разработчиков игр

       ID               Ключевое поле

       Firmname   Название фирмы

 

    GENRES Справочник Жанр игры

       ID                   ключевое поле

       Genrename    название жанра

 

    ARTICLES Ссылка на страницы в интернете

       ID             Ключевое поле

       GameID   Ключ записи из таблицы GEMES

       Info          Адрес страницы в интернете

 

 

          GEMES Основная база

              ID                  Ключевое поле

              Name            Название игры

              GenreID       Ключ записи из таблицы GENRES определяющий жанр игры

              Developer    Ключ записи из таблицы  FIRMS определяющий фирму разработчика

              Gameyear    Год выхода игры

 

Связи между таблицами

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Понятие базы данных

 

База данных — это совокупность записей различного типа, содержащая перекрестные ссылки.

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

Между записями каждой из таблиц устанавливаются ссылки: в записи таблицы игр имеется ссылка на записи таблицы с названиями фирм, таблицы с названиями жанров и так далее.

 

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

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

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

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

 

Модели баз данных

Таблицы, в которых хранятся данные, состоят из наборов записей одинаковой структуры. Можно сказать, что таблица — это двумерный массив, где строки образованы отдельными записями, а столбцы — полями этой записи. Более точно таблица представляется как одномерный массив переменной длины из записей конкретной структуры (тип record Паскаля).

Модель базы данных, состоящей из подобных таблиц, называется реляционной.

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

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

·        В иерархической модели данные организованы в виде деревьев.

·        В сетевой модели каждый узел (набор) базы данных взаимодействует с другими узлами посредством сложной системы связей.

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

 

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

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

Локальная архитектура

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

 

Файл-серверная архитектура

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

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

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

 

 

 

 

 

Клиент-серверная архитектура

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

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

 

Распределенная архитектура

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

 

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

Интернет-архитектура

Доступ к базе данных и СУБД (расположенным на одном компьютере или в сети) осуществляется из браузера по стандартному протоколу. Это предъявляет минимальные требования к клиентскому оборудованию. Такие программы называют «тонкими клиентами», потому что они способны работать даже на ПК с процессором 80386.

 

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

Программные решения.

 

Реализация работы с СУБД в системе Delphi

 

Технология ВDЕ для доступа к данным

При создании программ, работающих с базами данных, в системе Delphi традиционно используется механизм Borland Database Engine (BDE). В состав Delphi 7 входит версия BDE52., которую, впрочем, можно бесплатно обновлять разными способами (например, обратившись к Web-узлу http://www.borland.com/).

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

 

 

Утилиты для работы с СУБД

Создание базы данных Структура базы данных

Теперь, когда мы познакомились с понятием СУБД и принципами работы механизма BDE, перейдем к практической реализации справочника игр.

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

В первой таблице (назовем ее Firms) будут храниться названия фирм, во второй -жанры (Genres), в

третьей — ссылки на Wefc-страницы Интернета и статьи в журналах (Articles). Одной игре может быть посвящено несколько Web-страниц и статей.Четвертая таблица (Games) будет основной.

 

 

Создание таблиц

Для создания таблиц в системе Delphi 7 имеется приложение Database Desktop (Работа с автономной СУБД). Оно вызывается командой Tools > Database Desktop (Сервис >Работа с автономной СУБД) .

Новая таблица создается командой File > New > Table (Файл >• Создать > Таблица).

В открывшемся диалоговом окне надо выбрать формат таблицы (каждая СУБД хранит данные в собственном формате). Укажите в раскрывающемся списке Table type (Формат таблицы) пункт Paradox 7 (формат СУБД Paradox версии 7) и щелкните на кнопке ОК.

 

 

Ключевое поле

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

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

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

 

ВНИМАНИЕ Если в таблице имеется ключевое поле, это означает, что все значения в нем уникальны и неповторимы. Содержимое ключевого поля в одной таблице повторяться не может. То есть, в таблице Gomes не может быть двух описаний (записей), посвященных одной игре,

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

 

Индексация

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

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

В СУБД Paradox 7 ключевое поле всегда индексировано. Такой индекс называется первичным и всегда один. Для увеличения скорости сортировки и поиска данных в других полях можно добавить неограниченное число вторичных индексов.

 

 

Создание таблицы Genres

 

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

Ключевое поле, как правило, указывается первым. Некоторые СУБД требуют этого в обязательном порядке. Например, таков используемый сейчас формат СУБД Paradox 7. Отступать от этого порядка не рекомендуется. Название ключевого поля обычно тоже стандартно — ID (от английского Identifier — идентификатор).

 

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

Щелкните правой кнопкой мыши над областью поля Туре (Тип поля) и выберите в контекстном меню значение Autoincrement (Автоприращение). Теперь при добавлении в таблицу новой записи значение данного поля будет автоматически увеличиваться и разработчику не придется отслеживать уникальность первичных ключей.

Пункт столбца Size (размер поля записи) заполняется автоматически, а вот в столбце Key надо указать, что данное поле записи ключевое. Нажатие клавиши ПРОБЕЛ приведет к появлению в этом столбце звездочки — признака ключевого поля. Убрать этот признак можно повторным нажатием той же клавиши.

 

Тип Alpha- хранит текстовые значения

флажок Required Field (Обязательное поле)

 

Создание вторичных ключей

раскрывающейся список Table properties (Свойства таблицы).

выберем строку Secondary Indexes (Вторичные ключи) и щелкнем на кнопке Define (Определить).

В появившемся диалоговом окне переместим с помощью кнопки со стрелкой поле GenreName в список Indexed fields (Индексированные поля). Поле ID уже используется в качестве первичного индекса. Укажем также, что все значения в поле GenreName уникальные, установив флажок Unique (Уникальное).

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

 

Перекрестные ссылки

Важный заключительный этап формирования базы данных состоит в создании перекрестных ссылок между таблицами. На этом этапе надо явно указать, например,что ключевое поле таблицы Genres связано с полем GenrelD таблицы Games. Это выполняется так: в раскрывающемся списке Table Properties выбирается пункт Referential Integrity (Целостность ссылок). С помощью кнопки Define (Определить) определяются все связи данной таблицы с ключевыми полями других таблиц.

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

Зададим связь поля GenrelD с ключевым полем таблицы Genres, которая считается родительской. Выберите поле в левом списке и щелкните на кнопке со стрелкой вправо. В центральной области окна в колонке Chield field (Подчиненное поле) появляется название GenrelD [I]. Обозначение [I] указывает на тип этого поля.

В правом списке надо выбрать таблицу Genres.db и щелкнуть на кнопке со стрелкой влево. В столбце Parent's key (Ключевое поле родительской таблицы) появится надпись ID [+]. Знак «плюс» означает признак ключевого поля (рис. 5.5).

 

После этого можно щелкнуть на кнопке ОК и в небольшом диалоговом окне ввести произвольное название созданной связи, предположим Genrelnt. После этого снова щелкните на кнопке ОК. В списке ниже кнопки Define (Определить) возникнет новая связь Genrelnt. Таким же способом надо создать связи Devlnt (поле Developer и ключ таблицы Firms) и Publnt (поле Publisher ц ключ таблицы Firms).

 

Отношения между таблицами

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

 

Тип отношения Способ связи

Один и одному Каждой записи соответствует роено одна запись другой таблицы. В принципе,

можно вообще обойтись одной таблицей

Один ко многим Примером может служить связь таблиц Games и Genres. В таблице Genres

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

Многие ко многим Это отношение не всегда поддерживается в реляционных СУБД, и для его

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

 

Добавление базы данных в ВDЕ

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

При регистрации в системе Воссозданной группы таблиц как целостной базы данных поможет приложение SQL Explorer (Проводник SQL), запускаемое командой Database >> Explore (База данных > Проводник). В левой части окна приводится список всех зарегистрированных в системе BDE баз данных, в правой — свойства текущей базы, выбранной в этом списке.

Создадим новую базу данных. Для этого выполняется команда Object >• New (Объект > Создать) и в диалоговом окне выбора драйвера указывается значение STANDARD.

 

После щелчка на кнопке ОК в списке появится новый элемент, помеченный зеленым треугольником. Это означает, что регистрация базы данных не завершена. По умолчанию формируется имя базы STANOARD1, изменим его на MyBase. Убедимся, что в свойстве DEFAULT DRIVER (Драйвер по умолчанию) стоит значение PARADOX. В свойстве PATH (Путь поиска для каталога, в котором хранятся таблицы) укажем рабочий каталог (для которого создан псевдоним :WORK:). Этот каталог, как правило, отображается первым при щелчке на кнопке выбора.

Теперь зарегистрированную в системе ВОЕ базу надо сохранить. Для этого в контекстном меню объекта MyBase выберем пункт Apply (Применить настройки). На вопрос о необходимости сохранения изменений ответим Yes (Да). Теперь наши таблицы доступны из среды BDE под именем базы данных MyBase. Если раскрыть объект MyBase, щелкнув на значке «+»перед его именем, па правой панели SQL Explorer будут показаны все четыре таблицы, а значок базы помечается зеленой рамкой, указывающей, что база данных MyBase открыта.