Основные понятия реляционной теории баз данных. Формализация отношений. Московский государственный университет печати Список использованной литературы

Прежде чем подробно рассматривать каждый из этих шагов, остановимся на основных концепциях реляционных баз данных. В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n множеств D1,D2,...,Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида< d1,d2,...,dn>, где d1 - элемент из D1, d2 - элемент из D2, ..., dn - элемент из Dn. При этом наборы вида называются кортежами, а множества D1,D2,...,Dn - доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения - значениями атрибутов представляет нам графическое изображение отношения с разных точек зрения.

Рис.

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

• · отношение, таблица, файл (для локальных баз данных)
• · кортеж, строка, запись
• · атрибут, столбец, поле.

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

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

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

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

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

Замечание . Существует два подхода к удалению и изменению записей из главной таблицы:

• 1. Запретить удаление всех записей, а также изменение первичных ключей главной таблицы, на которые имеются ссылки подчиненной таблицы.
• 2. Распространить всякие изменения в первичном ключе главной таблицы на подчиненную таблицу, а именно:
  • o если в главной таблице удалена запись, то в подчиненной таблице должны быть удалены все записи, ссылающиеся на удаляемую;
  • o если в главной таблице изменен первичный ключ записи, то в подчиненной таблице должны быть изменены все внешние ключи записей, ссылающихся на изменяемую.

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

база данные реляционный индексирование

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

Введение

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

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

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

Функциональные зависимости

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

Общие определения

Пусть задана переменная отношения r , и X и Y являются произвольными подмножествами заголовка r ("составными" атрибутами).

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

Для примера будем использовать отношение СЛУЖАЩИЕ_ПРОЕКТЫ {СЛУ_НОМ, СЛУ_ИМЯ, СЛУ_ЗАРП, ПРО_НОМ, ПРОЕКТ_РУК} (рис. 6.1). Очевидно, что если СЛУ_НОМ является первичным ключом отношения СЛУЖАЩИЕ , то для этого отношения справедлива функциональная зависимость (Functional Dependency – FD) СЛУ_НОМ->СЛУ_ИМЯ .

На самом деле, для тела отношения СЛУЖАЩИЕ_ПРОЕКТЫ в том виде, в котором оно показано на рис. 6.1 , выполняются еще и следующие FD (1):

Рис. 6.1.

СЛУ_НОМ->СЛУ_ИМЯ СЛУ_НОМ->СЛУ_ЗАРП СЛУ_НОМ->ПРО_НОМ СЛУ_НОМ->ПРОЕКТ_РУК {СЛУ_НОМ, СЛУ_ИМЯ}->СЛУ_ЗАРП {СЛУ_НОМ, СЛУ_ИМЯ}->ПРО_НОМ {СЛУ_НОМ, СЛУ_ИМЯ}->{СЛУ_ЗАРП, ПРО_НОМ} … ПРО_НОМ->ПРОЕКТ_РУК и т.д.

Поскольку имена всех служащих различны, то выполняются и такие FD (2):

СЛУ_ИМЯ->СЛУ_НОМ СЛУ_ИМЯ->СЛУ_ЗАРП СЛУ_ИМЯ->ПРО_НОМ и т.д.

Более того, для примера на рис. 6.1 выполняется и FD (3):

СЛУ_ЗАРП->ПРО_НОМ

Однако заметим, что природа FD группы (1) отличается от природы FD групп (2) и (3). Логично предположить, что идентификационные номера служащих должны быть всегда различны, а у каждого проекта имеется только один руководитель. Поэтому FD группы (1) должны быть верны для любого допустимого значения переменной отношения СЛУЖАЩИЕ_ПРОЕКТЫ и могут рассматриваться как инварианты , или ограничения целостности этой переменной отношения .

FD группы (2) базируются на менее естественном предположении о том, что имена всех служащих различны. Это соответствует действительности для примера из рис. 6.1 , но возможно, что с течением времени FD группы (2) не будут выполняться для какого-либо значения переменной отношения СЛУЖАЩИЕ_ПРОЕКТЫ .

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

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

Заметим, что если атрибут A отношения r является возможным ключом, то для любого атрибута B этого отношения всегда выполняется

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

Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.

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

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

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

Таблица PRODUCTS

ID	NAME	COMPANY	PRICE
123	Печеньки	ООО ”Темная сторона”	190
156	Чай	ООО ”Темная сторона”	60
235	Ананасы	ОАО ”Фрукты”	100
623	Томаты	ООО ”Овощи”	130

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

Для ясности, теперь введем строгое определение отношения.

Пусть даны N множеств D1,D2, …. Dn (домены), отношением R над этими множествами называется множество упорядоченных N-кортежей вида , где d1 принадлежит D1 и тд. Множества D1,D2,..Dn называются доменами отношения R.
Каждый элемент кортежа представляет собой значение одного из атрибутов, соответствующего одному из доменов.

Ключи в отношениях

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

Таблица DRIVERS

Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.

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

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

Операции реляционной алгебры

Основные восемь операций реляционной алгебры были предложены Э.Коддом .

• Объединение
• Пересечение
• Вычитание
• Декартово произведение
• Выборка
• Проекция
• Соединение
• Деление

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

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

Таблица SELLERS

ID	SELLER
123	OOO “Дарт”
156	ОАО ”Ведро”
235	ЗАО “Овоще База”
623	ОАО ”Фирма”

Условимся, что в этой таблице ID это внешний ключ, связанный с первичным ключом таблицы PRODUCTS.

Для начала рассмотрим самую простую операцию - имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.

Проекция

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

Синтаксис операции:
π (ID, PRICE) PRODUCTS

В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:

σ (PRICE>90 ^ ID<300) PRODUCTS

Умножение

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

Получим декартово произведения таблиц PRODUCTS и SELLERS.
Синтаксис операции:

PRODUCTS × SELLERS
Можно заметить, что у двух этих таблиц есть одинаковый домен ID. В подобной ситуации домены с одинаковыми названиями получают префикс в виде названия соответствующего отношения, как показано ниже.
Для краткости перемножим не полные отношения, а выборки с условием ID<235

(цветом выделены одни и те же кортежи)

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLERS.ID	SELLER
123	Печеньки	ООО ”Темная сторона”	190	123	OOO “Дарт”
156	Чай	ООО ”Темная сторона”	60	156	ОАО ”Ведро”
123	Печеньки	ООО ”Темная сторона”	190	156	ОАО ”Ведро”
156	Чай	ООО ”Темная сторона”	60	123	OOO “Дарт”

Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:

π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS

В результате этой операции получим отношение:

SELLER

ОАО ”Ведро”

Соединение и естественное соединение

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

Также для понятности можно представить соеднинение как результат двух операций. Сначала берется произведение исходных таблиц, а потом из полученного отношения мы делаем выборку с условием равенства атрибутов из одинаковых доменов. В данном случае условием явлется равенство PRODUCTS.ID и SELLERS.ID.

Попробуем соединить отношения PRODUCTS и SELLERS и получим отношение.

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLERS.ID	SELLER
123	Печеньки	ООО ”Темная сторона”	190	123	OOO “Дарт”
156	Чай	ООО ”Темная сторона”	60	156	ОАО ”Ведро”
235	Ананасы	ОАО ”Фрукты”	100	235	ЗАО “Овоще База”
623	Томаты	ООО ”Овощи”	130	623	ОАО ”Фирма”

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

Синтаксис операции:
PRODUCTS ⋈ SELLERS;

Получится такое отношение:

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLER
123	Печеньки	ООО ”Темная сторона”	190	OOO “Дарт”
156	Чай	ООО ”Темная сторона”	60	ОАО ”Ведро”
235	Ананасы	ОАО ”Фрукты”	100	ЗАО “Овоще База”
623	Томаты	ООО ”Овощи”	130	ОАО ”Фирма”

Пересечение и вычитание.

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

Источники информации

• Основы использования и проектирования баз данных - В. М. Илюшечкин
• курс лекций Introduction to Databases - Jennifer Widom, Stanford University

Буду благодарен за аргументированные замечания

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

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

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

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

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

• все данные концептуально представляются как упорядоченное набор строк и столбцов, называемых отношением;
• все данные являются скалярными;
• строка данных называется кортежем, количество кортежей называется кардинальным числом;
• каждый столбец в кортеже называется атрибутом, количество атрибутов называется степенью отношения;
• отсутствие информации описывается значением NULL;
• потенциальный ключ K для отношения R - это подмножество множества атрибутов R, всегда обладающее свойством уникальности (т.е. нет двух кортежей в отношении R с одинаковым значение K) и свойством не избыточности (т.е. никакое из подмножеств K не обладает свойством уникальности). Потенциальный ключ, состоящий из более чем одного атрибута, называется составным, а из одного - простым. Первичный ключ - это потенциальный ключ, по которому физически упорядочены кортежи в отношении.
• внешний ключ определяется следующим образом. Пусть R2 - некоторое отношение. Тогда внешний ключ FK в отношении R2 - это такое подмножество множества атрибутов R2, что существует отношение R1 с потенциальным ключом K и значение FK в любом кортеже R2 всегда совпадает со значением K некоторого кортежа в R1. Ограничение, по которому значения внешнего ключа должны быть адекватны значениям соответствующего потенциального ключа, называют ссылочным ограничением. Соответственно, под ссылочной целостностью понимают требование того, чтобы в базе данных не было нарушений ссылочных ограничений.

Следующие операции допустимыми над данными в реляционной модели:

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

Жизненный цикл информационных систем

Анализ ситуации (сложность разработки ИС, не эффективное использование ИС), проведенный учеными, показал, что такое положение было вызвано тем, что при разработке программного обеспечения не соблюдались очень важными требования:

· Отсутствие полной спецификации всех требований;

· Отсутствие приемлемой методологии (системы методов) разработки ИС;

· Отсутствие разделения общего глобального проекта на отдельные компоненты, поддающиеся эффективному контролю и управлению.

Жизненный цикл (ЖЦ) информационных систем – это структурный подход к разработке программного обеспечения.

(некая схема) за 26.09.12

1. Планирование разработки ИС. Подготовительные действия, позволяющие с максимальной эффективностью реализовывать этапы ЖЦ ИС. Три основных компонента: оценка объема работ; оценка необходимых ресурсов; оценка общей стоимости проекта.

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

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

4. Проектирование базы данных. Создание проекта базы данных. Два основных подхода к проектированию систем баз данных: «нисходящий » и «восходящий ».

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

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

7. Создание прототипа. Создание рабочей модели приложения баз данных.

8. Реализация. Физическая реализация базы данных и разработанных приложений.

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

10. Тестирование. Процесс выполнения прикладных программ с целью поиска ошибок. Стратегии тестирования: нисходящее тестирование; восходящее тестирование; тестирование потоков; интенсивное тестирование.

11. Эксплуатация и сопровождение. Наблюдение за системой и поддержка её нормального функционирования: контроль производительности; сопровождение и модернизация приложений.

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

Терминология

В 1970 г. Реляционная модель впервые была предложена Э.Ф. Коддом.

В реляционной СУБД предполагается, что пользователь воспринимает БД как набор таблиц (и не как иначе).

Математические отношения.

Теория реляционных БД основана на математической теории отношений.

Пусть D1, D2, … Dn некоторые множества.

Декартовым произведение D1 D2 … Dn = {(X1,X2,…,Xn) | X1 D1, X2 D2, … Xn Dn}

Отношение – подмножество R D1*D2*…*Dn

Например, n=2, D1={2,4} и D2={1,3,5}, D1 * D2 = {(2,1),(2,3),(2,5),(4,1),(4,3),(4,5)}, R={(2,1),(4,1)}

Подмножество м. б. задано условием, например:

R={(x1,x2) |x1 D1, x2 D2, X2=1}, A1, A2, … An – имена атрибутов с доменами D1, D2, … Втб тогда отношение будем записывать в виде:

R(A1:D1,A2:D2,…An:Dn)

Свойства отношений:

· Отношение имеет уникальное имя;

· Каждый атрибут имеет уникальное имя (в отношении);

· Каждая ячейка отношения содержит только атомарное значение и нет повторяющихся групп (отношение нормализовано);

D1 – студенты
D2 – дисциплины: Математика, Информатика

· Порядок следования атрибутов не имеет никакого значения;

· Порядок следования кортежей произвольный;

· Каждый кортеж является уникальным.

Реляционные ключи

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

Реляционная целостность.

Реляционная алгебра

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

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

Пять основных операций:

· Выборка,

· Проекция,

· Декартово произведение,

· Объединение,

· Разность.

На основе этих операций могут быть получены другие:

· Соединения,

· Пересечения,

· Деления.

В предикате могут использоваться знаки логических операций ^(And), v(Or), ~(not).

Пример. Получить список всех сотрудником с окладом свыше 300.

Проекция.

Определяет отношение, атрибутами которого являются атр1, …, атрn и содержит только уникальные кортежи.

Декартово произведение

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

Объединение

Разность

Операции соединения.

Тета-соединение

Естественное соединение

Внешнее соединение

То при левом внешнем соединении сохраняется вся исходная информация из отношения R. Аналогично также можно определить правое внешнее соединение.

Полусоединение

Операцию полусоединения можно определить с помощью операторов проекции и соединения.

Пересечение

Представления

Назначение представлений:

· Предоставляет гибкий механизм защиты БД за счет сокрытия некоторой её части от определенных пользователей;

· Позволяет организовать доступ пользователей к данным наиболее удобным для них способом;

· Позволяет упрощать сложные операции с базовыми отношениями.

Правила, которые должны удовлетворить
реляционные СУБД

Для определения того, является ли СУБО реляционной Кодд (1985 г.) предложил 13 правил, которым они должны удовлетворять.

№		Правило
		Фундаментальное правило. Реляционная СУБД должна быть способна управлять базами данных исключительно с помощь её реляционных функций
		Представление информации. Вся информация в реляционной БД представляется в явном виде на логическом уровне только одним способом – в виде значений в таблицах. В том числе, метаданные.
		Гарантированный доступ. Для каждого элемента данных реляционной БД должен быть гарантирован логический доступ на основе комбинации имени таблицы, значения первичного ключа и имени столбца.
		Поддержка неопределенных значений. СУБД поддерживает неопределенные значения (Null).
		Реляционный системный каталог. Описание БД должно представляться на логическом уровне таким образом, как и обычные данные, что позволяет пользователям использовать для обращения к ним тот же реляционный язык.
		Исчерпывающий подъязык данных. реляционная СУБД может поддерживать несколько языков. Однако должен существовать по крайней мерее один язык, операторы которого позволяли бы выполнить следующие функции: 1. Определение данных; 2. Определение представлений; 3. Команды манипулирования данными; 4. Ограничения целостности; 5. Авторизации пользователей; 6. Организации транзакций
		Высокоуровневые операции извлечения, вставки, удаления, обновления. Способность СУБД выполнять операции извлечения данных команд вставки, удаления и обновления как единой операции.
		Физическая независимость от данных. От способа хранения
		Логическая независимость от данных. Независимость приложений от изменения базовых таблиц.
		Независимость ограничений целостности. Ограничения целостности должны определяться на подъязыке реляционных данных и храниться в системном каталоге, а не в прикладных программах.
		Независимость от распределения данных.
		Правило запрета обходных путей. Если СУБД имеет низкоуровневый язык (с последовательной построчной обработкой), он не должен позволять обходить правила и ограничения целостности, описанных на реляционном языке высокого уровня.

Моделирование данных на основе процесса нормализации

Цель нормализации.

Процесс нормализации был предложен в 1972 году Э. Ф. Коддом – три нормальные формы (НФ): первая (1НФ), вторая (2НФ) и третья (3НФ).

Более строгое определение третьей НФ (Р. Бойс и Э. Ф. Кодд, 1974) – нормальная форма Бойса-Кодда (НФБК).

Избыточность данных и аномалии обработки.

Отсутствие нормализации приводит:

· Избыточность данных

· Аномалии вставки (невозможно добавлять записи)

· Аномалии удаления (при удалении информации теряется другая информация)

· Аномалии обновления (требуется обновление многих записей)

· Свойства сохранения без потерь и сохранения зависимости.

Функциональные зависимости