Трехуровневая архитектура базы данных. Архитектура базы данных: понятие, определение, уровни

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

Архитектура баз данных предложенная исследовательской группой ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

Внешний уровень

Внешний уровень - это индивидуальный уровень пользователя. У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования.

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

Концептуальный уровень

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

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

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

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

Внутренний уровень

Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к базе данных и СУБД (распространенных на одном компьютере или в сети) осуществляется из браузера по стандартному протоколу. Это предъявляет

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

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

Рис. 1.11.

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

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

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

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

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

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

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

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

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

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

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

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

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

Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют информационной моделью данных (рис.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 сегодня широко известен и в качестве мощного рыночного фактора.

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

Внешний - наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей.

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

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

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

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

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

9. Реляционная модель базы данных.

Теоретической основой этой модели стала теория отношений, основу которой заложили два логика - американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер (1841-1902). В руководствах по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными, связанного с исходной алгеброй. Американский математик Э. Ф. Кодд в 1970 году впервые сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией.

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

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

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

Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы:

Простые типы данных.

Структурированные типы данных.

Ссылочные типы данных.

Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы: Логический, Строковый, Численный .

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

Вещественный.

Денежный.

Перечислимый.

Интервальный.

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

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

Массивы

Записи (Структуры)

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

называемое множеством индексов. Отображение

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

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

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

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

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

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

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

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

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

Домены

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

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

Домен имеет уникальное имя (в пределах базы данных).

Домен определен на некотором простом типе данных или на другом домене.

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

Домен несет определенную смысловую нагрузку.

Например, домен, имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

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

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

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

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