БД

2. Виды баз данных: реляционные, сетевые, иерархические. Примеры.

Иерархическая БД

Между записями существуют отношения «предок – потомок». Для получения доступа к данным в иерархической БД можно указать номер записи,

атакже выполнить ряд действий:

1)найти дерево по признаку;

2)перейти «вниз» к первому потомку;

3)перейти «в сторону» к следующему потомку;

4)перейти «вверх» к предку;

5)вставлять и удалять записи.

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

Иерархические БД имеют следующие достоинства:

1)структура БД проста для понимания;

2)отношения «предок – потомок» позволяют моделировать высказывания типа «А часть В» или «А владеет В»;

3)записи можно оптимально размещать на носителе информации, т. е. предки возле потомков, тем самым сокращается время доступа.

Пример иерархической БД

Автомобиль

Каждому прямоугольнику соответствует запись в БД.

Сетевые БД

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

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

1)найти запись по ее номеру (признаку);

2)перейти к первому потомку в конкретном множестве;

3)перейти «в сторону» от потомка к потомку в конкретном множестве;

4)перейти «вверх» от потомка к предку в другом множестве;

5)вставлять и удалять записи.

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

Пример сетевой БД

Реляционные БД

При математическом описании понятию «таблицы» соответствует понятие «отношение», столбцу – атрибут и строке – кортеж.

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

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

По отношению к пользователю реляционные БД поддерживают два основных принципа:

1)данные для пользователя представляются в виде таблиц;

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

Пример реляционной БД

3. Понятие транзитивной зависимости. Приведение к 3 нормальной форме. Если для атрибутов А, В и С некоторого отношения существуют

зависимости вида А → В и В → С , это означает , что атрибут С транзитивно зависит от атрибута А, через атрибут В (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).

3 НФ свободна от транзитивных зависимостей.

Алгоритм перехода от 2 НФ к 3 НФ

Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.

Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится во 2НФ и все неключевые атрибуты взаимно независимы.

Шаг 1. Обнаруживаем зависимость некоторых неключевых атрибутов от других неключевых атрибутов.

Шаг 2. Проводим декомпозицию этих отношений следующим образом:

•те неключевые атрибуты, которые зависят от других неключевых атрибутов, выносятся в отдельное отношение

•в новом отношении ключом становится детерминант функциональной зависимости

Исходное отношение: ( , 1, … , , 1, … , )

Ключ: K

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

→ ( 1, … , , 1, … , ) – зависимость всех атрибутов от ключа отношения. ( 1, … , ) → ( 1, … , ) – зависимость некоторых неключевых атрибутов от других неключевых атрибутов.

Декомпозированные отношения:

1( , 1, … , ) – остаток от исходного отношения. Ключ K.

2( 1, … , , 1, … , ) – атрибуты, вынесенные из исходного отношения вместе с детерминантом функциональной зависимости. Ключ ( 1, … , ).

4. Понятие функциональной зависимости. Приведение ко 2 нормальной форме.

Множество атрибутов Y функционально зависимо от множества атрибутов X (X функционально определяет Y) тогда и только тогда, когда для любого состояния отношения R для любых кортежей 1, 2 из того, что 1 =2 следует что 1 = 2 (т.е. во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R).

Символическая запись функциональной зависимости: →

Множество атрибутов X называется детерминантом функциональной зависимости, а множество атрибутов Y называется зависимой частью.

Если атрибуты X составляют потенциальный ключ отношения R, то любой атрибут отношения R функционально зависит от X.

Приведение ко 2 нормальной форме:

Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа.

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

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

Шаг 1. Обнаруживаем в отношениях зависимость атрибутов от части сложного ключа.

Шаг 2. Проводим декомпозицию этих отношений на несколько отношений:

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

•в исходном отношении остаются все ключевые атрибуты.

Исходное отношение: (1, 2, 1, … , , 1, … , ) Ключ: (1, 2)

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

( 1, 2) → ( 1, … , , 1, … , ) – зависимость всех атрибутов от ключа отношения.

(1) → (1, … , ) зависимость некоторых атрибутов от части сложного ключа. Декомпозированные отношения:

1( 1, 2, 1, … , ) – остаток от исходного отношения. Ключ (1, 2),.

2(1, 1, … , ) – атрибуты, вынесенные из исходного отношения вместе с частью сложного ключа. Ключ 1.

5.Проблемы аномалии модификации БД (вставки, удаления, обновление).

Аномалии вставки (INSERT)

Вотношение СТУДЕНТ_КАФЕДРА_СЕКЦИЯ нельзя вставить данные о студенте, который пока не посещает никакую из перечисленных секций. Поскольку атрибут Секция входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.

Причина аномалии – хранение в одном отношении разнородной информации.

Вывод – логическая модель данных неадекватна модели предметной области.

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

Аномалии обновления (UPDATE)

Вотношении СТУДЕНТ_КАФЕДРА_СЕКЦИЯ присутствует повторения данных в некоторых кортежах. Изменения этих данных должны одновременно выполняться во всех местах, иначе отношение станет некорректным. Таким образом, обновление базы данных одним действием реализовать невозможно.

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

Вывод – увеличивается сложность разработки базы данных.

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

Аномалии удаления (DELETE)

При удалении некоторых данных может произойти потеря другой информации.

Причина аномалии – хранение в одном отношении разнородной информации.

Вывод – логическая модель данных неадекватна модели предметной области.

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

7. Проектирование БД: концептуальное, логическое, физическое. Примеры.

Концептуальное

Предметная область – это часть реального мира, данные о которой мы хотим отразить в базе данных.

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

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

Пример:

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

Логическое

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

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

Пример:

Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

Физическое

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

Пример: любая таблица базы данных.

8. Физическая организация данных: индексно-прямые файлы и индекснопоследовательные. Примеры Индексы обеспечивают механизм быстрого доступа к данным в таблицах.

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

При индексно-прямом доступе каждый индекс ассоциируется с определённым указателем на запись.

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

Пример:

Структура индексов по каждому из четырех полей показана в «Отпуск товара».

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

Отпуск товара

Индексированные поля таблицы