- •1. Понятие базы данных и банка данных.
- •1.1 Основные определения.
- •1.2 Составляющие банка данных.
- •1.3 Цели использования банков данных.
- •1.4 Трехуровневая архитектура базы данных.
- •1.5 Основные функции субд.
- •1.5.1 Управление данными во внешней памяти.
- •1.5.2 Управление оперативной памятью.
- •1.5.3 Управление транзакциями
- •1.5.4 Журнализация
- •1.5.5. Поддержка языков бд
- •2. Модели данных.
- •2.1 Ранние модели данных.
- •2.1.1 Иерархическая модель данных.
- •2.1.2 Сетевая модель данных.
- •2.2 Реляционная модель данных.
- •2.4 Объектная модель данных.
- •2.5 Нереляционные субд.
- •3. Реляционная модель данных.
- •3.1 Структура и основные понятия реляционной модели данных.
- •3.2 Правила Кодда для реляционных субд.
- •3.3 Реляционная алгебра и реляционное исчисление.
- •3.3.1 Реляционная алгебра.
- •3.3.2 Реляционное исчисление.
- •4. Проектирование баз данных.
- •4.1 Проектирование при помощи нормализации.
- •4.1.1 Первая нормальная форма.
- •4.1.2 Вторая нормальная форма.
- •4.1.3 Третья нормальная форма и нормальная форма Бойса-Кодда.
- •4.1.4 Четвертая нормальная форма.
- •4.1.5 Пятая нормальная форма.
- •4.2 Модель «сущность-связь».
- •4.2.1 Появление и развитие метода. Современное состояние.
- •4.2.2 Метод Баркера.
- •4.2.3 Метод idef1x.
- •4.2.4 Получение схемы базы данных из модели «сущность-связь».
- •4.3 Денормализация базы данных.
- •5. Язык sql.
- •5.1 Появление и развитие языка.
- •5.2 Современная структура языка.
- •5.3 Язык определения данных.
- •5.4 Язык манипулирования данными.
- •5.4.1 Запросы insert, update, delete.
- •5.4.2 Запрос select.
- •6. Управление транзакциями.
- •6.1 Понятие транзакции. Основные свойства транзакций.
- •7.2 Восстановление.
- •6.3 Параллельность.
- •6.3.1 Проблемы параллельных транзакций и уровни изолированности.
- •6.3.2 Блокировки данных.
- •6.4 Поддержка транзакции в языке sql и библиотеках ado.Net.
- •Рекомендуемая литература
4.3 Денормализация базы данных.
Как уже было сказано, в процессе проектирования БД мы стараемся добиться того, чтобы все отношения находились в максимально возможной нормальной форме. Если мы проектируем при помощи последовательной нормализации, мы достигаем этого в явном виде, если мы используем подход «сущность-связь», мы достигаем этого опосредованно. Выше отмечалось, что при аккуратном использовании этого подхода полученные таблицы будут находиться, как минимум, в 3НФ.
Однако во многих случаях требования нормализации могут входить в противоречие с требованиями производительности. При нормализации мы разделяем более крупные отношения на все более мелкие, но тем самым мы снижаем производительность запросов к данным. Каждое соединение двух таблиц – затратная операция, а если таблиц в запросе десяток, его выполнение может стать неоправданно долгим.
Поэтому, очень часто после нормализации структуры БД следует ее денормализация – мы сознательно нарушаем требования нормализации для достижения большей производительности. Да, в этом случае мы можем столкнуться с аномалиями, да, размер БД может вырасти за счет дублирования, но мы сможем формулировать более простые запросы, которые будут быстрее выполняться.
Иногда такие оптимизации нельзя сделать на пустой базе данных, и требуется некоторое время реального использования, чтобы выявить узкие места и наметить возможные оптимизации. Как следствие, давать рекомендации по денормализации «вообще» не представляется возможным, поэтому, мы ограничимся тем, что отметим ее, как возможный этап развития базы данных.
Контрольные вопросы.
Опишите основные подходы к проектированию баз данных.
Дайте понятие нормализации.
Перечислите аномалии, возникающие в ненормализованной БД.
Перечислите существующие нормальные формы.
Опишите этапы создания базы данных через моделирование.
Дайте основные понятия метода «сущность-связь».
Поясните необходимость денормализации базы данных.
5. Язык sql.
5.1 Появление и развитие языка.
С появлением первых реляционных СУБД возникла и необходимость разработки языка, который позволил бы работать с данными в них. Исследовательские работы начались в компании IBM в рамках проекта по разработке одной из первых реляционных СУБД System/R. Результатом этих работ явился язык SEQUEL, что расшифровывалось как Structured English QUEry Language. Одновременно работы по разработке подобных языков велись и другими компаниями, но популярности они не снискали.
Позже SEQUEL был переименован в SQL (Structured Query Language, язык структурированных запросов) и начались работы по его стандартизации. Этим занялись Международная организация по стандартизации (ISO) и Американский национальный институт стандартов (ANSI). В 1986 году вышла первая версия стандарта, которую чаще всего называют по году выпуска – SQL86. Вслед за ней выпустили SQL89, затем в 1992 году вышла следующая версия стандарта, SQL92. В настоящее время последней версией является стандарт 2003 года с дополнениями, сделанными в 2006 и 2008 годах.
Поддержка стандарта в существующих СУБД находится на различном уровне. Вряд ли найдется СУБД, поддерживающая все конструкции языка, предусмотренные стандартом. Во многом, это связано с тем, что развитие языка идет эволюционно, и новые возможности появляются из практики, после того, как они будут реализованы в какой-то из СУБД. Соответственно, остальные СУБД в такой ситуации оказываются в положении догоняющих, и на внедрение новых возможностей требуется некоторое время, если оно вообще случается.
Для упорядочения вопросов совместимости уже в первой версии стандарта SQL86 было введено два уровня, первый, включавший только часть конструкций языка, и второй – полный. В дальнейшем, в стандарте SQL92 количество уровней было расширено до трех: Базовый (Entry), Промежуточный (Intermediate) и Полный (Full). Каждый следующий уровень включает в себя предыдущий. Наконец, в версии 1999 года в стандарте были выделены отдельные модули, поддержку которых производители могли обеспечивать по своему усмотрению. Уровень совместимости остался один – Core (англ. Ядро), означающий поддержку модуля SQL/Foundation, то есть, основных конструкций языка. Этот подход сохранился и в следующих версиях стандарта.