16. Понятие ключей и ссылочной целостности данных в реляционных моделях

Любая таблица реляционной базы данных состоит из строк (называемых также записями) и столбцов (называемых также полями).

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

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

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

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

17. Нормализация данных в процессе проектирования реляционных бд

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

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

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

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

Чтобы перейти от 1й нормальной формы ко 2й, нужно выполнить следующие шаги:

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

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

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

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

Чтобы перейти от 2й нормальной формы к 3й, нужно выполнить следующие шаги:

1) Определить все поля (или группы полей), от которых зависят другие поля.

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

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

18. Объекты реляционных баз данных

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

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

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

4) Представления (запросы). Этот объект представляет собой виртуальную таблицу, предоставляющую данные из одной или нескольких реальных таблиц. Реально он не содержит никаких данных, а только описывает их источник. Предназначены для отбора и отображения записей из таблиц.

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

6) Объекты для генерации первичных ключей. В разных СУБД для генерации ключей используются разные объекты. Некоторые СУБД поддерживают специальные типы полей для первичных ключей. При добавлении записей такие поля заполняются автоматически последовательными значениями.

7) Пользователи и роли служат для авторизованного доступа к данным. Роль – набор функций, кот. может исполнить пользователь.

8) Системный каталог предназнач. для хранения и описания объектов БД

. 19. Запросы к базам данных (SQL, QBE, UDF, транзакции)

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

3 мех-ма создания запросов:

1) SQL - стуктурированный язык запросов;

2) QBE - запрос по образцу;

3) UDF - функции, определенные пользователем.

SQL - непроцедурный язык, кот. исп-ся для формулировки запросов к БД.

QBE – средство для визуального связывания таблиц и выбора полей, которые след. отобразить в рез-те запроса.

UDF - программы, созданные для вып-ния требуемых операций над данными.

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

Есть 2 состояния транзакций:

1) Завершение - все операции, входящие в состав транзакции, успешно завершены, и рез-т их работы сохранён в БД;

2) Откат - выполненные операции отменяются, все об-ты БД, затронутые этими операциями, возвращены в исходное состояние.

20. Защита данных в системах управления базами данных

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

Эти два подхода отличаются следующими свойствами:

1) В случае избирательного управления некоторый пользователь обладает различными правами при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту.

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

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

4) Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC, для которой должен быть определен минимальный стандартный набор прав.

5) Привилегии (полномочия) пользователей или групп - это набор действий (операций), которые они могут выполнять над объектами БД.

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

7) Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД.

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

21. Перспективы развития систем управления базами данных

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

Для работы с «Хранилищами данных» наиб. значимым становится интеллектуальный анализ данных (ИАД) — это процесс выявления значимых образцов и тенденций в больших объемах данных.

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

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

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

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

Темпоральные БД - БД, чувствительные ко времени. Фактически БД моделирует сост. объектов предметной области в некотор. текущий момент времени. Однако в ряде прикладных областей необходимо исследовать именно изменение состояний объектов во времени. Основной тезис темпоральных систем сост. в том, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются все его состояния во временном интервале t1- t2.

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

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