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

СУБД с централизованной архитектурой;

СУБД с архитектурой файл-сервер;

СУБД с архитектурой клиент-сервер;

СУБД с трехуровневой архитектурой: «тонкий клиент» - сервер приложений – сервер базы данных.

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

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

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

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

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

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

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

Большинство современных СУБД реализованы по архитектуре клиент-сервер: Oracle, MS SQL Server, PostgreSQL, MySQL, Informix, DB2 и др.

Однако и архитектура клиент-сервер не лишена недостатков.

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

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

В таких случаях следует переходить к трехуровневой архитектуре: «тонкий клиент» - сервер приложений – сервер базы данных.

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

«Тонкий клиент» находится на компьютере пользователя и чаще всего представляет собой Web-браузер (например, Internet Explorer) с применением соответствующей HTML-странице апплетов Java или компонентов ActiveX.

Сервер приложений находится на сервере и может являться специализированной программой (например, Oracle Forms Server) или обычным Web-сервером, вызывающим для обработки HTTP-запроса внешнюю программу через интерфейс CGI (рис. 33).

Рис. 33. Трехуровневая архитектура БЗ.

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

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

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

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

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

Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру.

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

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

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

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

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

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

архитектура СУБД должна обеспечивать, в первую очередь, разграничение пользовательского и системного уровней;

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

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

Исследовательской группой ANSI-SPARC (ANSI - American National Standard Institute и SPARC - Standards Planning and Requirements Committee) были предложены три уровня абстракции для организации структуры базы данных. Это внешний , концептуальный и внутренний уровни описания данных.

Именно на основе архитектуры ANSI-SPARC базируется архитектура большинства современных СУБД.

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

Определение Концептуальный уровень _ это общее представление БД, описывающее все данные, которые хранятся в ней. Этот уровень содержит логическую структуру всей базы данных. Именно на этом уровне представлены следующие компоненты:

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

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

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

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

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

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

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

О физическом размещении в памяти данных и их описаний;

О механизме поиска запрашиваемых данных;

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

О способах защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

Обобщенная структура связей программ и данных при использовании СУБД показана на рисунке 6.6.

При выполнении основных из этих функций СУБД должна использовать различные описания данных, в которых должны быть учтены:

Сущности интересующей предметно области;

Атрибуты, характеризующие неотъемлемые свойства каждой сущности;

Связи, ассоциирующие выделенные сущности.

Рис. 6.6. Обобщенная структура связей программ и данных в СУБД

Подход к архитектуре и описанию данных предложен комитетом ANSISPARC (Комитет планирования Стандартов и норм

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

Рис. 6.7. Трехуровневая архитектура ANSI-SPARC

Такое отделение по уровням обеспечивает независимость хранимых данных, что необходимо по следующим причинам:

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

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

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

4. Структура БД не должна зависеть от физических аспектов хранения, например, при переключении на новое внешнее устройство памяти.

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

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

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

1) сущности, их атрибуты и связи;

2) ограничения, накладываемые на данные;

3) семантическую информацию о данных;

4) информацию о мерах обеспечения безопасности.

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

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

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

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

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

Карта распределения дискового пространства для хранения данных и индексов;

Описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

Сведения о размещении записей;

Сведения о возможности сжатия данных и выбранных методов шифрования.

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

На внутреннем уровне создается физическая модель.

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

В соответствии с предложениями ANSI-SPARC можно представить соответствующую трехуровневую модель данных (рис. 6.8):

Рис. 6.8. Уровни моделей данных

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

Рис. 6.9. Основные компоненты СУБД

Рассмотрим основные компоненты СУБД.

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

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

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

Препроцессор языка DML преобразует внедренные в прикладные программы DML операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов. Язык манипулирования данными (Data Manipulation Language - DML) - совокупность языковых средств организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД.

Компилятор языка DDL преобразует DDL команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация - в заголовках файлов с данными. Язык определения данных (Data Definition Language - DDL) - формальный закон, используемый в некоторой модели данных для определения структуры данных.

Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

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

1. Контроль прав доступа (пользователь имеет или не имеет права на затребованную операцию).

2. Процессор команд (для выполнения запроса управление передается процессору команд).

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

4. Оптимизатор запросов определяет наилучшую стратегию выполнения запроса.

5. Контроллер транзакций осуществляет требуемую обработку операций, поступающих в процессе выполнения транзакций.

6. Планировщик отвечает за бесконфликтное выполнение параллельных с базой данных операций.

7. Контроллер восстановления обеспечивает восстановление данных до непротиворечивого состояния после сбоя.

8. Контроллер буферов отвечает за перенос данных между ОЗУ и внешними носителями.

Рис. 6.10. Компоненты контроллера базы данных

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

Физическом размещении запрашиваемых данных;

Механизмах поиска запрашиваемых данных;

Проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

Способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

мые СУБД

Рис.5.2. Уровни моделей данных.

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

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

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

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

2.3. Третье поколение: оперативные сетевые базы данных (1965 г.–1980 г.)

Для таких приложений, как ведение операций на фондовой бирже или резервирование билетов, требуется знание текущей информации. Эти приложения не могут использовать вчерашнюю информацию, обеспечиваемую системами пакетной обработки транзакций, - им нужен немедленный доступ к текущим данным. С конца 1950-х годов лидирующие компании из нескольких областей индустрии начали вводить в использование системы баз данных с оперативными транзакциями; транзакции над оперативными базами данных обрабатывались в интерактивном режиме. Аппаратура для подключения к компьютеру интерактивных компьютерных терминалов прошла путь развития от телетайпов к простым алфавитно-цифровым дисплеям и, наконец, к сегодняшним интеллектуальным терминалам, основанным на технологии персональных компьютеров. Мониторы телеобработки представляли собой специализированное программное обеспечение для мультиплексирования тысяч терминалов со скромными серверными компьютерами того времени. Эти мониторы собирали сообщения-запросы, поступающие с терминалов, быстро назначали программы сервера для обработки каждого сообщения и затем направляли ответ на соответствующий терминал. Оперативная обработка транзакций дополняла возможности пакетной обработки транзакций, за которой оставались задачи фонового формирования отчетов.

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

2.3.1. Иерархические СУБД.

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

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

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

Рис.5.3. Иерархическая база данных, содержащая информацию о составных частях.

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

Перейти “вниз” к первому потомку (ручка двери);

Перейти “вверх” к предку (корпус);

Перейти “в сторону” к другому потомку (левая дверь).

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

2.3.2. Сетевые базы данных.

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

Рис.5.4. Множественные отношения предок/потомок.

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

Клиенты Товары

Множество

Рис.5.5. Сетевая база данных, содержащая информацию о заказах.

Сетевые базы данных обладали рядом преимуществ:

- Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии;

- Стандартизация. Появление стандарта CODASYL – популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД;

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

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

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа “Какой товар наиболее часто заказывает компания Acme Manufacturing?Э, программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалось на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

2.4. Четвертое поколение: реляционные базы данных (1980 г. – 1995 г.).

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

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

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

2.4.1. Таблицы.

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

Данные об офисе

в Нью-Йорке

Данные об офисе

в Лос-Анджелесе

Рис. 5.6. Структура реляционной таблицы.

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALTS содержатся объемы продаж, обеспечиваемые офисами.

На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей нью-йоркский офис, в столбце CITY содержится значение “NEW YORK”. В столбце SALES той же строки содержится значение $692’000’00, которое является объемом продаж нью-йоркского офиса с начала года.

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце CITY содержатся только слова, в столбце SALES содержатся денежные суммы, а в столбце MGR содержатся целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца. Доменом столбца CITY является множество названий городов. Доменом столбца SALES является любая денежная сумма. Домен столбца REGION состоит всего из двух значений, ‘Eastern” и “Western”, поскольку у компании всего два торговых региона.

У каждого столбца в таблице есть свое имя , которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. На практике такие имена столбцов, как NAME, ADDRESS, QTY, PRICE и SALES, часто встречаются в различных таблицах одной базы данных.

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

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

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

2.4.2. Первичные ключи.

Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет “первой”, “последней” или “тринадцатой” строки. Тогда каким же образом можно указать в таблице конкретную строку, например, строку для офиса, расположенного в Дунвере?

В правильно построенной реляционной базе данных в каждой таблице есть один или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы. Давайте вновь посмотрим на базу данных, показанную на рис.5.6. На первый взгляд. Первичным ключом таблицы OFFICES могут служить и столбец OFFICE, и столбец CITY. Однако в случае, если компания будет расширяться и откроет в каком-либо городе второй офис, столбец CITY больше не сможет выполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса (OFFICE в таблице OFFICES), служащего (EMPL_NUM в таблице SALESREPS) и клиента (CUST_NUM в таблице CUSTOMES). А в случае с таблицей ORDERS выбора нет – единственным столбцом, содержащим уникальные значения, является номер заказа (ORDER_NUM).

Таблица PRODUCTS, фрагмент которой показан на рис.5.7, является примером таблицы, в которой первичный ключ представляет собой комбинацию столбцов. Такой первичный ключ называется составным . Столбец MRF_ID содержит идентификаторы производителей всех товаров, перечисленных в таблице, а столбец PRODUCT_ID содержит номера, присвоенные товарам производителями. Может показаться, что столбец PRODUCT_ID мог бы и один выполнять роль первичного ключа, однако ничто не мешает двум различным производителям присвоить своим изделиям одинаковые номера. Таким образом, в качестве первичного ключа таблицы PRODUCTS необходимо использовать комбинацию столбцов MRF_ID и PRODUCT_ID. Для каждого из товаров, содержащихся в таблице, комбинация значений в этих столбцах будет уникальной.

Первичный ключ

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, Oracle и другие) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

2.4.3. Отношения предок/потомок.

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

Как следует из рис.5.8, ответ на этот вопрос должен быть отрицательным. На рисунке изображено несколько строк из таблицы OFFICES и SALESREPS. Обратим внимание на то, что в столбце REP_OFFICE таблицы SALESREPS содержится идентификатор офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце OFFICE таблицы OFFICES. То, в каком офисе работает Мэри Джонс (Mary Jones), можно узнать, определив значение столбца REP_OFFICE в строке таблицы SALESREPS для Мэри Джонс (число 11) и затем отыскав в таблице OFFICES строку с таким же значением в столбце OFFICE (это для офиса в Нью-Йорке). Таким образом, чтобы найти всех служащих нью-йоркского офиса, следует запомнить значение столбца OFFICE для Нью-Йорка (число 11), а потом просмотреть таблицу SALESREPS и найти все строки, в столбце REP_OFFICE которых содержится число 11 (это строки для Мэри Джонс и Сэма Кларка (Sam Clark)).

Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом . На рис.5.9 столбец REP_OFFICE представляет собой внешний ключ для таблицы OFFICES. Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов. Эти значения соответствуют значениям в столбце OFFICE, который является первичным ключом таблицы OFFICES. Совокупно первичный и внешний ключи создают между таблицами, в которых они содержатся, такое же отношение предок/потомок, как и в иерархической базе данных.

Таблица ORDERS

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

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

Столбец REP является внешним ключом для таблицы SALESREPS и связывает каждый заказ со служащим, принявшим его;

Столбец CUST является внешним ключом для таблицы CUSTOMES и связывает каждый заказ с клиентом, разместившим его;

Столбцы MRF и PRODUCT совокупно представляют собой внешний ключ для таблицы PRODUCTS, который связывает каждый заказ с заказанным товаром.

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

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

Лекция 6.2 . Язык AQL как стандартный язык базы данных.

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