Шпоры по базам данных (госэкзамен) / БД 1,2,3,4

1. БД. Принципы построения. Жизненный цикл БД.

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

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

Требования к базам данных

К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования.

1. Высокое быстродействие (малое время отклика на запрос).

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

2. Простота обновления данных.

3. Независимость данных.

4. Совместное использование данных многими пользователями.

5. Безопасность данных - защита данных от преднамеренного или

непреднамеренного нарушения секретности, искажения или разрушения.

6. Стандартизация построения и эксплуатации БД (фактически СУБД).

7. Адекватность отображения данных соответствующей предметной области.

8. Дружелюбный интерфейс пользователя.

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

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

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

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

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

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

2. Модели БД. Основные понятия.

Иерархические базы данных. В этой модели имеется один главный объект (корень) и остальные - подчиненные - объекты, находящиеся на разных уровнях иерархии. Взаимосвязи объектов образуют иерархическое дерево с одним корневым объектом.

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

Рис.   Схема иерархической модели данных

«+»

• Эффективное использование памяти ЭВМ

• Неплохие показатели времени выполнения операций над данными

«-»

• Громоздкость для обработки информации с достаточно сложными логическими связями.

• Сложность понимания для обычного пользователя

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

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

Рис. Схема сетевой модели

«+»

• Возможность эффективной реализации по затратам памяти и оперативности обработки

«-»

• Сложность и жесткость БД

• Понижен контроль целостности данных

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

«+»

• простота работы и отражение представлений пользователя

• гибкость (соединение, разделение файлов)

• простота внедрения плоских файлов

• отделение от физической реализации (независимость)

• произвольная структура запросов

• хорошее теоретическое обоснование

«-»

• низкая производительность

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

• линейность структуры таблиц

Многомерные СУБД являются узкоспециализированными СУБД. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решений. Их называют OLAP – системы (Online Analitical Processing – оперативная аналитическая обработка)

Основные понятия, используемые в этих СУБД: агрегируемость, ис­торичность и прогнозируемость данных. По сравнению с реляционной моделью (OLTP – системы оперативной обработки) многомерная организация данных обладает более высокой наглядностью и информативностью

Пример 3-х мерной модели.

N – мерные модели представляются в виде поликуба или гиперкуба. Примером поликубической схемы данных является Oracle Express Server

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

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

Объектно- ориентированные модели данных

В объектно-ориентированной модели используются понятия класса, объекта, метода.

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

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

«+» ООБД

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

«-» ООБД Низкая скорость выполнения запросов, понятийная сложность.

3. Признаки эффективности структуры БД. Понятие целостности. Критерии целостности.

Эффективность структуры БД

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

1. Обеспечение быстрого доступа к данным в таблицах.

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

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

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

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

Важнейшими ограничениями целостности данных являются:

• категорийная целостность

• ссылочная целостность.

Ограничение категорийной целостности заключается в следующем.

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

Ссылочная целостность:

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

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

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

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

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

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

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

Критерии целостности:

• Каждой записи основной (главной, родительской) таблицы соответствует нуль или более записей дополнительной (подчинённой, дочерней) таблицы.

• В дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице.

• Каждая запись дополнительной таблицы имеет только одну родительскую запись основной таблицы.

4. Нормализация данных. Первая, вторая, третья нормальные формы.

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

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

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

Рассмотрим проблемы, которые возникают при работе с ненормализованными данными. Рассмотрим таблицу СОТРУДНИКИ, которая имеет следующие атрибуты:

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

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

Нормальные формы

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

• Первая нормальная форма

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

• Вторая нормальная форма

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

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

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

для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.

• Третья нормальная форма

Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко-второй нормальной форме. Для этой таблицы существует функциональная зависимость между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной.

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

Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две таблицы: СОТРУДНИКИ и ДОЛЖНОСТИ.

Новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными.

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