"Проектирование реляционных баз данных." - читать интересную книгу автора (Джен Л. Харрингтон)

Часть первая • Теория
в реляционной базе данных. С точки зрения пользователя реляционной базы данных, кроме связанных между собой столбцов, не существует структур, демонстрирующих различные взаимоотношения.
Именно поэтому столь абсурдна мысль о том, что в реляционных базах данных устанавливаются "взаимоотношения между файлами". Взаимоотношения в реляционной базе данных существуют между логическими конструкциями — таблицами — и ничем больше. Подобные структуры не имеют абсолютно никакой связи с методами физического хранения файлов.
Внешние ключи могут быть частью составного первичного ключа или вообще не входить в состав первичного ключа своей таблицы. Рассмотрим для примера пару простых отношений, установленных между клиентами и заказами в Lasers Only:
customers (customer number, first name, last name, phone) orders (order number, customer number, order date)
Столбец customer number таблицы orders является внешним ключом, соответствующим первичному ключу таблицы customers. Этой связью представляется взаимоотношение типа "один-ко-многим" между клиентами и теми заказами, которые они делают. Однако столбец customer number не входит в состав первичного ключа своей таблицы; это неключевой атрибут, который, тем не менее, является внешним ключом.
В принципе, внешним ключам, не являющимся частью составного первичного ключа, совсем не обязательно присваивать какие бы то ни было значения; они могут быть и null-значениями. Однако в конкретной базе данных — Lasers Only — могут возникнуть серьезные проблемы, если номер клиента будет null-значением, так как не удастся выяснить, какой именно из клиентов сделал заказ.
Реляционная СУБД применяет взаимоотношения, указанные соответствием данных между первичными и внешними ключами. Предположим, что служащий Lasers Only хочет узнать, какие из наименований запрошены в заказе под номером 11102. Сначала СУБД определяет строки таблицы order_lines, содержащие номер заказа 11102. Затем система выбирает в этих строках номера пунктов и устанавливает соответствие между ними и номерами пунктов таблицы items. Из тех строк, для которых соответствие установлено, СУБД в конце концов считывает нужные наименования.
Ссылочная целостность
Процедура, описанная в предыдущем параграфе, работает хорошо, если по какой-то причине в таблице orders не существует номера заказа, для которого не установлено соответствие с некоторой строкой таблицы order_lines. Это крайне нежелательная ситуация, потому что отправить заказанный товар не удастся; все дело в том, что невозможно узнать, какой из клиентов сделал данный заказ.
Плава 3 • Реляционная модель данных
43
Именно поэтому в реляционной модели данных устанавливается ограничение, называемое ссылочной целостностью (referential integrity), согласно которому каждому значению внешнего ключа, не являющемуся null-значением, должно соответствовать значение существующего первичного ключа. Это, наверное, самое важное из всех ограничений, поскольку оно обеспечивает непротиворечивость перекрестных ссылок между таблицами.
Ограничения ссылочной целостности хранятся в базе данных и проверяются автоматически средствами СУБД. Как и в случае других ограничений, каждый раз при вводе или модификации данных СУБД проверяет ограничения и убеждается в их соблюдении. Если ограничения нарушаются, модификация данных запрещается.
Внешние и первичные ключи в одной таблице
Совсем не обязательно, чтобы внешние ключи ссылались на первичный ключ другой таблицы; нужно лишь, чтобы они ссылались на некоторый первичный ключ. В качестве примера рассмотрим следующее отношение служащих (employee):
employee (employee ID, first name, last name, department, manager ID)
Руководитель (manager) тоже служащий, поэтому идентификатор руководителя (manager ID), хотя и называется не так, как идентификатор служащего (employee ID), фактически является внешним ключом, ссылающимся на первичный ключ своей собственной таблицы. Поэтому СУБД будет всегда следить за тем, чтобы каждый раз при вводе пользователем идентификатора руководителя сведения об этом руководителе уже присутствовали в таблице как о некоем служащем.
Представления
Те, кто отвечает за разработку схемы базы данных и кто пишет прикладные программы для их применения технически неквалифицированными пользователями, обычно имеют представление обо всей схеме и могут к ней обращаться, в том числе и напрямую к базовым таблицам базы данных. Однако чаще всего нежелательно, чтобы конечные пользователи работали непосредственно с базовыми таблицами, в первую очередь из-за возможных проблем с безопасностью информации.
Именно поэтому в реляционной модели данных предусмотрен способ обеспечения онечных пользователей собственными окнами в базу данных, посредством которых врываются подробности общей структуры базы данных и запрещается прямой доступ 15 базовым таблицам.
44 Часть первая • Теория
Механизм представлений
Представление (view) не хранится с данными. Оно сохраняется под некоторым именем в словаре данных вместе с запросом, обращенным к базе данных, с помощью которого считывается нужная информация. Таким образом, в представлении могут содержаться данные нескольких таблиц, выбранных строк и выбранных столбцов.
Положительной стороной хранения представлений подобным образом является то, что всякий раз, когда пользователь включает имя представления в оператор языка программирования, применяемый для манипулирования данными, СУБД исполняет запрос, связанный с именем этого представления, и еще раз создает его таблицу. Это значит, что данные в представлении всегда будут самыми свежими.
Таблица представления остается в оперативной памяти только на время выполнения того оператора манипулирования данными, в котором она применяется. Когда пользователь выдает другой запрос, таблица представления сразу же удаляется из памяти, и ее заменяют результаты нового запроса.
В некоторых СУБД конечным пользователям дается возможность сохранять содержимое представлений в качестве базовых таблиц. Это крайне нежелательно, так как невозможно автоматически обновлять данные в таблице сохраняемого представления при изменении таблиц, на которых та была основана. В результате данные такой таблицы представления быстро устаревают и становятся неточными.
Использование представлений
Для включения представлений в структуру базы данных есть три важные причины:
¦ Как было отмечено выше, с помощью представлений реализуется алгоритм безопасности, запрещающий пользователям просматривать те части схемы, к которым они не должны иметь доступа.
¦ Применение представлений может упростить структуру базы данных для технически неквалифицированных пользователей.
¦ Поскольку представления хранятся как именованные запросы, их можно использовать для хранения часто выдаваемых сложных запросов. Затем такие запросы можно выполнять, указывая имя представления
в простом запросе.
Подобно другим структурным элементам реляционной базы данных, представлю ния можно создавать и уничтожать в любое время. В представлениях содержатся н хранимые данные, а лишь спецификация запроса, с помощью которого будет генерир0' ваться виртуальная таблица, поэтому добавление или удаление описаний представле'
Глава 3 • Реляционная модель данных
45
нИИ не оказывает никакого влияния на базовые таблицы и находящиеся в них данные. При удалении представления проблемы возникают только тогда, когда оно используется в прикладной программе, а программа не модифицируется для работы с другим представлением или с другой базовой таблицей.
Словарь данных
Сведения о структуре реляционной базы данных хранятся в словаре данных (data dictionary), или каталоге (catalog), базы. Словарь данных состоит из набора отношений, идентичных по свойствам отношениям, используемым для хранения данных. К отношениям словаря можно обращаться с запросами при помощи тех же самых инструментальных средств, что и к отношениям, содержащим данные. Напрямую ни один из пользователей не может модифицировать таблицы словаря данных. Однако команды языка манипулирования данными для создания и уничтожения структурных элементов базы данных действуют, изменяя строки в таблицах словаря данных.
Обычно в словаре данных содержится следующая информация:
¦ Описания столбцов, составляющих каждую таблицу
¦ Ограничения целостности, наложенные на отношения
¦ Сведения о безопасности данных (какой пользователь на выполнение какой операции над какой таблицей имеет право)
¦ Описания других структурных элементов базы данных, например представлений (см. главу 7), и доменов, определяемых пользователями
При попытке пользователя каким-то образом обратиться к данным реляционная ^УБД вначале просматривает словарь данных, определяя, являются ли на самом деле элементы базы данных, которые запросил пользователь, частью схемы. Помимо этого, v-УБД проверяет, имеет ли пользователь права на доступ к объекту запроса.
Когда пользователь пытается модифицировать данные, СУБД также обращается К словарю данных и ищет там ограничения целостности, которые могли быть установлены для отношения. Если данные соответствуют ограничениям, модификация разрешается. В противном случае СУБД возвращает сообщение об ошибке и не вносит 3аг'рошенное изменение.
1 юскольку все операции обращения к реляционной базе данных проходят через °варь, говорят, что реляционная СУБД управляется словарем данных.
46
Часть первая • Теория
Примеры таблиц словаря данных