- •1) Файловые системы хранения данных: принцыпы построения, область применения, достоинства и недостатки.
- •3)Система управления базой данных (субд) и языковые средства субд.
- •5. Персонал для поддержки БнД
- •6) Трехуровневая архитектура баз данных, назначение отдельных уровней.
- •2)Принципы централизованного управления данными.
- •5) Преимущества и недостатки технологии баз данных.
- •7) Принципы информационного моделирования. Виды моделей данных и требования к ним.
- •8) Концепция реляционной модели данных.
- •9) Структурная организация данных в реляционной модели. Фундаментальные свойства отношения.
- •10) Требования целостности данных в реляционной модели. Поддержка целостности таблиц и целостности по ссылкам.
- •11) Реляционная алгебра и реляционное исчисление. Реляционная алгебра э. Кодда.
- •29) Избыточность и виды аномалий при изменении данных
- •1) Аномалии коррекции (обновления)
- •2) Аномалии удаления
- •3) Аномалии вставки
- •30) Виды функциональных зависимостей между атрибутами.
- •18) Создание таблиц бд с помощью языка sql.
- •17) Возможности современного языка sql.
- •16) Язык запросов по образцу (qbe).
- •19) Выборка данных с помощью языка sql. (Слишком много)
- •20) Общая характеристика модели «сущность-связь».
- •21) Сущность и ее атрибуты. Виды атрибутов. Ключевые атрибуты и виды ключей.
- •23) Пример построения er-моделию
- •25) Методология концептуального проектирования бд.
- •22) Связи между сущностями. Классификация связей по их степени. Типы связей с точки зрения их мощности. Степень участия в связи. Атрибуты связей.
- •24) Этапы проектирования бд: концептуальное, логическое физическое.
- •27) Необходимость проверки таблиц с учетом требований нормализации
- •28) Этапы процесса нормализации и взаимосвязи между разными нормальными формами.
- •1. Исключение элементов, несовместимых с реляционной моделью данных
- •2. Формирование набора таблиц для логической структуры реляционной бд
- •31) Требования нормальных форм 1нф, 2нф, 3нф и нфбк.
29) Избыточность и виды аномалий при изменении данных
Основная цель проектирования реляционной БД — получение некоторого набора таблиц путем группирования атрибутов.
Это нужно сделать так, чтобы минимизировать избыточность данных и тем самым сократить объем физической памяти, которая необходима для хранения таблиц.
При небрежном проектировании БД может возникать и ряд дополнительных проблем.
Суть этих проблем, которые обусловлены избыточностью данных, можно проследить на примере конкретной таблицы.
ПРЕПОДАВАТЕЛИ (Таб_номер, ФИО, Должность, Кафедра, Телефон, Комната)
В этой таблице содержатся избыточные данные, поскольку сведения по кафедре повторяются для каждого сотрудника одной и той же кафедры.
При изменении данных в таких таблицах могут возникать проблемы, которые называют аномалиями.
Различают три вида аномалий:
аномалии коррекции (обновления);
аномалии удаления;
аномалии вставки.
1) Аномалии коррекции (обновления)
При изменении телефона на какой-то кафедре потребуется обновлять этот атрибут сразу для нескольких сотрудников.
Могут возникать противоречия в БД, если такая модификация затрагивает не все требуемые записи или допущены ошибки при вводе данных.
См. закон Мерфи: «Если какая-нибудь неприятность может произойти, то она обязательно случится».
2) Аномалии удаления
Если из таблицы удалить строку с данными о последнем сотруднике некоторой кафедры, то в БД не остается никаких сведений об этой кафедре.
3) Аномалии вставки
При добавлении сведений по новому сотруднику потребуется указать и данные о кафедре, на которой будет работать этот сотрудник. Ошибки при вводе этих данных могут привести к несоответствиям (противоречиям) в БД.
Если новая кафедра еще не укомплектована сотрудниками, то при вводе сведений по этой кафедре придется указывать значение NULL для атрибутов, которые описывают персонал. Однако для атрибута Таб_номер, который является первичным ключом, такое действие противоречит требованиям целостности данных и будет запрещено.
30) Виды функциональных зависимостей между атрибутами.
Наиболее важное значение для процедуры нормализации имеют функциональные зависимости (ФЗ), которые описывают существующие взаимосвязи между атрибутами.
Если в таблице R, содержащей атрибуты А и В, каждое значение атрибута А связано только с одним значением атрибута В, то атрибут В функционально зависит от атрибута А.
Эта ситуация обозначается как А®В.
В общем случае каждый из символов А или В может обозначать некоторую группу атрибутов.
Для функциональной зависимости А®В атрибут или группа атрибутов А называется детерминантом атрибута или группы В.
Например, в таблице ПРЕПОДАВАТЕЛИ по значению атрибута Таб_номер можно определить ФИО сотрудника и его должность.
Следовательно, атрибуты ФИО и Должность функционально зависят от атрибута Таб_номер:
Таб_номер ® ФИО, Должность.
Можно также сказать, что атрибут Таб_номер является детерминантом для атрибутов ФИО и Должность.
Функциональная зависимость А®В будет полной, если удаление какой-либо части из группы атрибутов А приводит к утрате этой зависимости.
Если в этом случае сохраняется некоторая ФЗ, то ее называют частичной.
Если в некоторой таблице R для атрибутов А, В и С существуют зависимости типа А®В и В®С, то говорят о транзитивной зависимости атрибута С от атрибута А через атрибут В.