Доступ к записям базы данных

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

Ключ является идентификатором, уникально определяющим запись об объекте.

Операции реляционной алгебры (объединение, пересечение, разность, произведение)

Объединение – отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих или A, или B, или обоим отношениям. (A UNION B).

Пересечение - отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B. (A INTERSECT B).

Вычитание - отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению B. (A MINUS B)

Декартово произведение отношение (A1, A2, …, Am, B1, B2, …, Bm), заголовок которого является сцеплением заголовков отношений A(A1, A2, …, Am) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся сцеплением кортежей отношений A и B: (a1, a2, …, am, b1, b2, …, bm), таких, что (a1, a2, …, am)∈ A, (b1, b2, …, bm)∈ B. Т.е. каждый кортеж первого отношения объединяется с каждым кортежем второго отношения. (A TIMES B).

Операции реляционной алгебры(выборка, создание проекций, деление)

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

Проекция – отношение, кортежи которого являются соответствующими подмножествами отношения операнда.

A[X, Y, …, Z] или PROJECT A {x, y, …, z}

Соединение – отношение, кортежи которого производятся путем объединения кортежей первого и второго отношения и удовлетворяют некому условию. ((A TIMES B) WHERE С = A JOIN B WHERE С

Реляционное деление - отношение с заголовком (X1, X2, …, Xn) и телом, содержащим множество кортежей (x1, x2, …, xn), таких, что для всех кортежей (y1, y2, …, ym) ∈ B в отношении A(X1, X2, …, Xn, Y1, Y2, …, Ym) найдется кортеж (x1, x2, …, xn, y1, y2, …, ym). (A DIVIDEBY B)

Функции администрирования БД

Администрирование базы данных – это функция управления базой данных (БД). Лицо ответственное за администрирование БД называется “Администратор базы данных” (АБД) или “Database Administrator” (DBA).

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

Жизненный цикл БД

1.планирование разработки БД. Рассмотрение с какой целью разрабатывается. Определение объема работ и ресурсов.

2.определение требований к системе, определение диапазон действий, состав пользователей, область применения.

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

4.проектирование БД:

- потенциальное проектирование (создание подробной модели)

- логическое(слияние отдельных моделей в глобальную логическую модель)

- физическое(описание реляционных таблиц и ограничений, разработка ср-в защиты)

5. разработка приложений - проектирование транзакций и пользовательского интерфейса

Реализация

Загрузка данных

Тестирование

Эксплуатация и сопровождение

Нормализация отношений

Нормализация- это процесс последовательной замены таблицы ее полными декомпозициями до тех пор пока все они не будут находится в 5НФ.

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

1. состав пользователей базы данных,

2. обеспечение целостности информации (особенно важно в многопользовательских информационных системах),

3. обеспечение наименьшего объем требуемой памяти и минимального времени обработки данных.

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

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

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

• первая нормальная форма (First Normal Form — INF);

• вторая нормальная форма (Second Normal Form — 2NF);

• третья нормальная форма (Third Normal Form — 3NF);

• нормальная форма Бойса—Кодда (Brice—Codd Normal Form — BCNF);

• четвертая нормальная форма (Fourth Normal Form — 4NF);

• пятая нормальная форма, или нормальная форма проекции-соединения (Fifth Normal Form — 5NF, или PJ/NF).

Примеры нормализации

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

Пример. В таблице «Поставки товаров» есть сведения о товарах, их цене, количестве и стоимости, а также о поставщиках, их адресах и расчетных счетах:

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

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

Процесс создания оптимальной схемы отношений для реляционной БД строго формализован и называется нормализацией БД.

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

Цели нормализации следующие:

• исключить дублирование информации;

• исключить избыточность информации;

• обеспечить возможность проведения непротиворечивых и корректных изменений данных в таблицах;

• упростить и ускорить поиск информации в БД.

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

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

Чтобы таблица соответствовала второй нормальной форме, необходимо, чтобы она уже находилась в первой нормальной форме и все неключевые поля полностью зависели от ключевого. В данной таблице на роль ключевого поля может претендовать только поле (атрибут-признак) «Товар», значения которого в таблице не повторяются. Из других полей только поле «Поставщик» непосредственно связано с поставляемым товаром (полем «Товар»), а поля «Индекс», «Область», «Город» и «Счет» характеризуют только самого поставщика. Поэтому, удовлетворяя второму правилу нормализации, необходимо разбить (или разложить) исходную таблицу на две – соответственно «Товары» и «Поставщики».

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

Заметим, что на роль ключевого поля таблицы «Поставщики» подходит поле «Поставщик», значения которого в этой таблице уже не повторяются. Можно отметить, что на эту роль вполне подходит и поле «Счет», значения которого также не будут повторяться, а само поле, хотя и выглядит как набор цифр, все же является не количественной, а качественной характеристикой объекта, т. е. является атрибутом-признаком, что необходимо для ключевого поля.

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

Анализируя таблицу «Поставщики», можно заметить, что поля «Область» и «Город» являются зависимыми от поля «Индекс», и поэтому эта таблица не находится в третьей нормальной форме.

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

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