- •1. Форматирование выходных данных запросов. 39
- •Тема 1.
- •1. Введение. История развития баз данных.
- •1. Введение. История развития баз данных
- •2. Основные понятия и определения
- •Тема 2.
- •1. Архитектура базы данных. Физическая и логическая независимость.
- •1. Архитектура базы данных. Физическая и логическая независимость
- •2. Разработка приложений в среде Microsoft Windows. Системы быстрой разработки приложений. Субд. Модели данных.
- •3. Основные этапы проектирование базы данных.
- •Тема 3.
- •1. Дополнительные общие рекомендации по проектированию базы данных.
- •2. Разработка приложений в среде Microsoft Windows.
- •1. Дополнительные общие рекомендации по проектированию базы данных.
- •2. Разработка приложений в среде Microsoft Windows.
- •Тема 4.
- •1. Построение таблиц.
- •2. Запросы в Microsoft Access. Параметры запросов на выборку данных.
- •3. Операции реляционной алгебры.
- •1. Построение таблиц
- •2. Запросы в Microsoft Access. Параметры запросов на выборку данных.
- •3. Операции реляционной алгебры.
- •Тема 5.
- •1. Понятие технологии «Клиент-сервер». Общие сведения о языке запросов sql.
- •2. Структура sql.
- •1. Понятие технологии «Клиент-сервер». Общие сведения о языке запросов sql.
- •2. Структура sql.
- •Тема 6.
- •1. Запрос выборки в языке sql. Выборка из одной таблицы.
- •2. Суммирование данных с помощью функций агрегирования (групповых функций).
- •1. Запрос выборки в языке sql. Выборка из одной таблицы.
- •2.Суммирование данных с помощью функций агрегирования (групповых функций).
- •Тема 7.
- •1. Форматирование выходных данных запросов.
- •2.Соединение таблиц
- •3.Вложенные подзапросы
- •4.Связанные подзапросы. Оператор exists
- •5.Вложенные и связанные подзапросы. Операторы any, all, come
- •Тема 8.
- •1. Форматирование выходных данных запросов.
- •1. Форматирование выходных данных запросов.
- •Тема 9.
- •1. Запросы обновления таблиц.
- •2. Создание, модификация и уничтожение таблиц. Ограничение на множество допустимых значений данных. Значение по умолчанию.
- •3. Создание и уничтожение индексов. Поддержка ссылочной целостности.
- •1. Запросы обновления таблиц.
- •2. Создание, модификация и уничтожение таблиц. Ограничение на множество допустимых значений данных. Значение по умолчанию.
- •3. Создание и уничтожение индексов. Поддержка ссылочной целостности.
- •Тема 10.
- •1. Создание представлений .
- •2. Определение правд доступа к данным.
- •1. Создание представлений.
- •2. Определение правд доступа к данным.
- •Тема 11.
- •1. Определение синонимов объектов. Понятие транзакций. Управление параллелизмом.
- •Тема 12.
- •1. Встроенный sql, основные понятия
- •1. Встроенный sql, основные понятия.
3. Основные этапы проектирование базы данных.
Под проектированием понимают процесс создания описания новой системы, которая способна функционировать при постоянном совершенствовании её технических, программных и информационных составляющих.
Проектирование состоит из трёх основных этапов:
Концептуальное проектирование
Логическое проектирование
Физическое проектирование
Целью концептуального проектирования является разработка базы данных на основе предметной области. Это описание должно содержать совокупность документов и данных, необходимых для загрузки базы данных, а также сведения о процессах и объектах, которые характеризуют предметную область.
Целью логического проектирования является выбор конкретной СУБД и преобразование концептуальной модели в логическую. Для реляционной модели это означает разработку структуры таблиц, связей между ними и определение ключевых атрибутов.
Этап физического проектирования дополняет логическую модель характеристиками, которые необходимы для определения способов хранения данных и использования базы данных.
В реляционной модели любая таблица рассматривается как отношения между ключом и остальными элементами данных в строке. Т.о. процесс проектирования – это определение состава отношений.
Этот процесс состоит из следующих этапов:
Определение объектов, сведения о которых отображаются в базе данных.
Определение связей между объектами.
Определение атрибутов объектов.
Нормализация отношений.
Рассмотрим процесс проектирования базы данных на примере базы данных об учебном процессе в университете. В этой базе данных имеются следующие таблицы: «факультет», «кафедра», «преподаватель», «группа» и «студент».
Различают 3 типа связей между объектами таблицы:
В заимосвязь «один к одному» ( ) - каждому экземпляру одного типа объектов соответствует один и только один экземпляр другого объекта (такой тип встречается крайне редко).
В заимосвязь «один ко многим» ( ) - одному экземпляру родительского объекта соответствует несколько экземпляра второго (дочернего) объекта. Такой тип экземпляров является основным в реляционных моделях баз данных.
Факультет
Кафедра
Преподаватель
Группа
Студент
В заимосвязь «многие ко многим» ( ) - одному экземпляру одного объекта соответствует множество экземпляров второго объекта и наоборот. Такой тип взаимосвязи не допускается в реляционных базах данных и непосредственно реализуется путём введения дополнительного объекта.
Преподаватель
Студент
Преподаватель
Курсовая
работа
Студент
Третий этап проектирования – определение атрибутов объекта. В состав атрибутов объекта должны быть включены:
Ключевые атрибуты, однозначно определяющие экземпляр объекта.
Ключи связанных объектов.
Не ключевые атрибуты, которые характеризуют объект.
Объект |
Атрибуты |
Факультет |
Код, наименование, ФИО декана, телефон… |
Кафедра |
Код, Код факультета, Наименование, ФИО зав. … |
Преподаватель |
Код, Код кафедры, ФИО, Должность … |
Группа |
Код, Код факультета, ФИО старосты, … |
Студент |
Код, Код группы, ФИО |
Курсовая работа |
Код преподавателя, код студента, тема |
Четвёртый этап проектирования БД – определение отношений и группировка атрибутов по отношению к базам данных – самый главный этап. Для этого используется нормализация отношений. Рассмотрим на примере. Пусть у нас имеются следующие отношения:
Нагрузка преподавателя по дисциплине |
||||||
Код преподавателя |
ФИО |
Должность |
Кафедра |
Факультет |
Дисциплина |
Количество часов |
001 |
Иванов |
доцент |
К1 |
Ф1 |
Д1 |
20 |
001 |
Иванов |
доцент |
К1 |
Ф1 |
Д2 |
10 |
002 |
Петров |
профессор |
К1 |
Ф1 |
Д3 |
30 |
003 |
Сидоров |
доцент |
К2 |
Ф2 |
Д4 |
22 |
004 |
Сидоров |
доцент |
К2 |
Ф2 |
Д5 |
24 |
Ключом в данном отношении является совокупность атрибутов «Код преподавателя» и «Дисциплина».
Говорят, что отношение задано в первой нормальной форме, если все входящие в него атрибуты имеют атомарные (неделимые) значения, т.е. каждая ячейка таблицы содержит одно, а не несколько значений. Т.о. про любую таблицу с уникальным ключом в строке можно сказать, что она задаёт отношение в первой нормальной форме.
И в приведённой таблице можно получить различные дополнительные сведения (списки кафедр, списки факультетов или дисциплин и т.д.). Для этого необходимо выбрать неповторяющееся значение какого-либо атрибута. Однако представленная модель имеет ряд существенных недостатков. Качество любой модели определяется с точки зрения возможности и удобства выполнения типовых операций «Добавить», «Удалить», «Изменить».
Основными недостатками этой модели являются:
Невозможно добавить информацию о новом преподавателе, если за ним не закреплена нагрузка. Это связано с тем, что первичный ключ должен иметь значение.
При удалении информации о нагрузке, удаляется и вся информация из строки.
При изменении не ключевых атрибутов требуется просмотр всего отношения, т.е. всей таблицы.
Причина указанных недостатков в том, что не все не ключевые атрибуты зависят от ключевых атрибутов. В этом примере атрибуты преподавателя «Фамилия», «Должность» не зависят от преподаваемой дисциплины и в таблице смешаны 2 типа информации: «Преподаватель» и «Дисциплина».
Говорят, что отношение задано во второй нормальной форме, если оно задано в первой нормальной форме и каждый не ключевой атрибут зависит от ключевого. Иначе говоря, если ключ содержит один атрибут, то отношение задано во второй нормальной форме, если несколько, то необходимо перевести во вторую нормальную форму, путём разбиения на несколько отношений. Для нашего примера таблица преобразуется в следующую:
Преподаватель |
||||
Код преподавателя |
Фио |
Должность |
Кафедра |
Факультет |
001 |
Иванов |
доцент |
К1 |
Ф1 |
002 |
Петров |
профессор |
К1 |
Ф1 |
003 |
Сидоров |
доцент |
К2 |
Ф2 |
Нагрузка по дисциплине |
||
Код преподавателя |
Дисциплина |
Количество часов |
001 |
Д1 |
20 |
001 |
Д2 |
10 |
002 |
Д3 |
30 |
003 |
Д4 |
22 |
004 |
Д5 |
24 |
При таком представлении данных указанные выше недостатки ликвидируются, т.е. можно добавить нового преподавателя независимо от дисциплине, удалить сведения о нагрузке или дисциплине без потери сведений о преподавателе, т.е. изменение не ключевого параметра делается в одной строке.
Однако и эта модель данных имеет ряд недостатков:
Невозможно добавить информацию о новой кафедре, пока в её штат не будет принят хотя бы один преподаватель.
При удалении сведений о преподавателе удаляются сведения о принадлежности кафедры к факультету. Т.е. удалив все сведения обо всех преподавателях, мы потеряем сведения о кафедре вообще.
При изменении зависимости «кафедра-факультет», т.е. преподаватель, например, перешёл работать на другой факультет, требуется просмотр всего отношения. А при переводя преподавателя на другую кафедру требуется обновить поле «Факультет».
Причина указанных недостатков в транзитивной зависимости атрибутов «Код преподавателя», «Кафедра» и «Факультет».
Если A, B, C – некоторые атрибуты отношения и A зависит от B, а B зависит от C? То говорят, что A транзитивно зависит от C.
Говорят, что отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждый не ключевой атрибут не транзитивно зависит от ключа отношений. Для нашего примера, чтобы перейти к третьей нормальной форме, это отношение («Факультет-Преподаватель») необходимо разбить надвое:
Преподаватель |
|||
Код преподавателя |
Фио |
Должность |
Кафедра |
001 |
Иванов |
доцент |
К1 |
002 |
Петров |
профессор |
К1 |
003 |
Сидоров |
доцент |
К2 |
Кафедра |
|
Кафедра |
Факультет |
К1 |
Ф1 |
К1 |
Ф1 |
К2 |
Ф2 |
Существуют и более высокие формы нормализации, но при проектировании баз данных они используются достаточно редко.
Следует отметить, что в процессе нормализации отношений кроме устранения трудностей в реализации функций обработки данных, ликвидируется избыточность данных, т.е. дублирование определённого значения атрибута в различных экземплярах объектов базы данных. Так, например, если в первой нормальной форме сведения о принадлежности кафедры факультету указывалась в трёх строках, то после перевода в третью нормальную форму – только в одной строке.
Устранение избыточности сокращает объём базы данных и повышает эффективность работы системы, т.е. исключает не синхронный ввод данных.