Введение

Реляционные базы данных

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

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

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

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

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

Последние несколько десятилетий реляционные базы данных развивались, совершенствовались и, в силу присущих им мощности и гибкости занимали доминирующее положение на рынке. Все наиболее известные СУБД (dBase, FoxPro, Microsoft Access, InterBase, Sybase, Oracle, MS SQL Server, DB2 и другие) оперируют именно с реляционными базами данных. Хотя, следует заметить, что в последнее время (очевидно, в связи с развитием Internet) несколько активизировался интерес к нереляционным базам данных. Не так давно фирмой Microsoft была разработана новая модель доступа к данным, называемая ActiveX Data Objects (ADO). Модель ADO, использующая новую технологию OLE DB, позволяет получить доступ и к нереляционным базам данных. Однако, несмотря на это замечание, реляционные базы данных являются основным средством хранения и обработки информации.

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

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

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

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

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

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

Следующий момент, с которым вы обязательно столкнетесь пятьдесят раз внося информацию об одном и том же клиенте - неизбежное внесение ошибок. Самой распространенной и неприятной ошибкой является ошибка, иногда называемая «размножением клиентов» (в общем случае, «размножением сущностей»). Если, например, одним из ваших клиентов является фирма Microsoft, то, оформив на нее десять заказов, вы через месяц обнаружите, что кроме фирмы Microsoft у вас среди клиентов есть еще фирмы Mirosoft, Micosoft, Microsot и Macrohard. Итак, вместо одного клиента вы получили пять. С другой стороны, готовя в конце месяца отчет о заказах, вы обнаружите, что на фирму Microsoft было оформлено всего три заказа и долго будете ломать голову, куда же делись остальные семь. После того, как вы обнаружите источник ошибок, вам еще придется долго бродить по необъятной, не поддающейся обозрению таблице, исправляя однотипные описки и опечатки.

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

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

Последним шагом в организации структуры данных является создание связей между таблицами Заказы и Клиенты, а также Заказы и Товары. Связь между основной таблицей и таблицей-справочником обычно является связью типа один ко многим (one-to-many relationship). Этот тип связи означает, что в таблице Клиенты может существовать только одна запись о конкретном клиенте, в то время как в таблице Заказы может содержаться много записей, ссылающихся на этого клиента. Другими словами, таблица Заказы содержит некое множество записей (возможно, пустое), соответствующее ровно одной записи из таблицы Клиенты. Более подробно о различных типах связей и способах их создания будет рассказано в главе 3.

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

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

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

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

В заключение приведем классификацию реляционных баз данных по способу доступа к информации:

Локальные базы данных. Предназначены для решения наиболее простых задач обработки информации. Обычно такие базы данных не предназначены для многопользовательского доступа по сети. Хранятся таблицы таких баз данных в виде отдельных файлов на жестком диске того компьютера, с которого к ним осуществляется доступ. Каждой таблице кроме файла с данными может соответствовать один или более индексных файлов. Учитывая этот факт, а также ограничения на количество одновременно открытых файлов, становится понятным, что построение сложных или средней сложности баз данных в рамках локальной модели довольно затруднительно. Типичными примерами локальных баз данных являются dBase, FoxPro, Paradox.

Файл-серверные базы данных. Предназначены для одновременного доступа по сети нескольких пользователей. Вся информация в таких базах хранится в одном файле. Используя файл-серверную модель доступа можно разрабатывать достаточно сложные приложения. Однако, так как при подключении к такой базе данных через сеть, на локальном компьютере создается своя собственная копия данных, то сеть может испытывать значительную нагрузку. Поэтому, файл-серверные базы данных используются, в основном, либо для работы на локальном компьютере, либо для работы в небольшой локальной сети. В качестве примера баз данных этого типа можно привести базы данных Microsoft Access.

Клиент-серверные базы данных. Предназначены для создания сложных, корпоративного уровня, баз данных, предоставляющих доступ как по локальной сети, так и пользователям с удаленных компьютеров. Одновременный доступ к информации могут получить тысячи пользователей. При такой организации база данных хранится на компьютере-сервере и практически вся обработка информации производится именно на этом компьютере программой-сервером. Клиенты посылают серверу только запрос на получение определенной выборки данных или на производство каких-либо действий, а сервер отсылает обратно клиенту уже обработанную информацию. Такой подход значительно снижает сетевой трафик (количество передаваемой по сети в разных направлениях информации), увеличивая надежность и устойчивость всей информационной системы в целом. Еще одной особенностью клиент-серверной архитектуры баз данных является то, что для построения программ-клиентов могут использоваться различные программные средства, так как клиенты с сервером общаются при помощи языка запросов SQL. Базы данных (точнее — СУБД), составляющие серверную часть такой архитектуры называются SQL-серверами. Примеры - MS SQL Server, InterBase, Sybase, Oracle, DB2.

Многоярусные базы данных. Новая и очень перспективная архитектура информационных систем. Наиболее распространенной является трехъярусная модель. При использовании такой модели на самом нижнем ярусе находится так называемый тонкий клиент — программа-клиент, предназначенная в основном для ввода-вывода информации. Кроме того, тонкий клиент может посылать запросы серверу прило­жений, находящемуся на втором ярусе архитектуры, и принимать от него запрошенные сведения. Требования к компьютеру, на котором работает тонкий клиент, минимальны. Сервер приложений производит основные вычисления, формирует запросы к удаленному серверу базы данных (SQL-серверу), находящемуся на третьем ярусе архитектуры, а также обслуживает подключенных к нему клиентов. По сути, такой вариант организации информационной системы является дальнейшим развитием клиент-серверного подхода, который можно было бы назвать двухъярусной архитектурой.


Следующая ]

Начало пособия Начало части Начало главы Следующая глава Следующая часть