- •1. Введение в предмет.
- •1.1 Данные и информация.
- •1.2 Предметная область.
- •1.3 Понятие и сущность.
- •1.4 Концептуальная модель объекта.
- •1.5 Связь или отношение.
- •1.6 Логическая модель базы данных.
- •1.7 Физическая модель базы данных.
- •1.8 Введение в работу с базами данных на платформе Microsoft sql Server.
- •1.8.1 Платформа Microsoft sql Server.
- •1.8.2 Среда sql Server Management Studio.
- •2. Основные понятия баз данных.
- •2.3 Типы данных ms sql Server.
- •2.3.1 Типы char и varchar.
- •2.3.2 Типы данных nchar и nvarchar.
- •2.3.3 Типы точных числовых данных.
- •2.3.4 Тип данных даты и времени.
- •2.3.5 Типы данных Decimal, Float и Real.
- •2.3.6 Тип денежных данных.
- •2.3.7 Типы binary и varbinary.
- •2.3.8 Типы данных больших значений.
- •2.4 Индексы.
- •2.4.1 Простой индекс.
- •2.4.2 Уникальный индекс.
- •2.4.3 Первичный ключ.
- •2.4.4 Уточнение определения индексов для ms sql Server.
- •2.4.4.1 Создание кластеризованного индекса.
- •2.4.4.2 Создание некластеризованных индексов.
- •2.5 Ограничения (Constraints).
- •2.5.1 Ограничение первичного ключа (Primary key constraints).
- •2.5.2 Создание или изменение ограничения primary key.
- •2.5.2.1 Свойство identity.
- •2.5.2.2 Глобальные уникальные идентификаторы.
- •2.6 Отношения между таблицами.
- •2.7 Нормализация данных.
- •2.7.1 Функциональные зависимости.
- •2.7.2 Первая нормальная форма таблицы.
- •2.7.3 Вторая нормальная форма таблицы.
- •2.7.4 Третья нормальная форма таблицы.
- •2.8 Ограничение foreign key.
- •2.8.1 Ведение ссылочной целостности.
- •2.8.2 Диалоговое окно "Связи внешнего ключа".
- •2.9 Ограничение unique.
- •2.9.1 Создание ограничения уникальности визуальными средствами.
- •2.9.2 Изменение ограничения уникальности.
- •2.10 Проверочные ограничения check.
- •2.11 Значения по умолчанию (Default).
- •3. Диаграммы базы данных.
- •3.1 Конструктор баз данных.
- •3.1.1 Таблицы и столбцы в диаграмме базы данных.
- •3.2 Редактирование диаграммы.
- •4. Основы Transact-sql.
- •4.1 Введение в sql.
- •4.1.1 Особенности выполнения инструкций Transact-sql.
- •4.2 Запросы.
- •4.2.2 Синтаксис инструкции select.
- •4.2.2.1 Предложение select.
- •4.2.2.2 Предложение select_list.
- •4.2.2.3 Предложение into.
- •4.2.2.4 Предложение from.
- •4.2.2.5 Предложение where.
- •4.2.2.6 Предложение group by.
- •4.2.2.7 Предложение having.
- •4.2.2.8 Предложение order by.
- •4.3 Ввод данных.
- •4.4 Обновление или изменение данных.
- •4.5 Удаление данных.
- •4.6 Представления.
- •4.6.1 Сравнительные характеристики запросов и представлений.
- •4.6.2 Типы представлений.
- •4.6.2.1 Стандартные представления.
- •4.6.2.2 Индексированные представления.
- •4.6.3 Создание представлений.
- •4.6.3.1 Обновляемые представления.
- •4.7.5 Настройка разрешений на объекты базы данных.
- •4.7.5.3 Создание пользователя в базе данных.
- •4.7.5.4 Инструкция grant.
- •4.7.6 Удаление объектов базы данных.
2.7.3 Вторая нормальная форма таблицы.
Вторая нормальная форма требует зависимости каждого не ключевого поля от полного набора полей первичного ключа. Рассмотрим нижеследующую таблицу в первой нормальной форме:
|
Код заказа |
Дата заказа |
Код товара |
Сумма заказа |
|
11 |
08/04/99 |
ПР1 |
60.00 |
|
11 |
08/04/99 |
ПР2 |
60.00 |
|
11 |
08/04/99 |
ПР3 |
60.00 |
Из-за преобразования для соответствия первой нормальной форме, поле Код заказа перестало быть уникальным, поскольку его значение теперь повторяется в нескольких записях. То же самое произошло и с другими одиночными полями. Сочетание же значений полей Код заказа и Код товара ни в одной строке не повторяется, поэтому его можно принять за новый уникальный ключ. После этого необходимо проверить, все ли остальные поля зависят от комбинации Код заказа и Код товара.
Нетрудно заметить, что дата заказа и сумма заказа является свойствами заказа и, следовательно, зависит от кода заказа, и не зависит от кода товара, который может принадлежать различным заказам. Поэтому, согласно правилу второй нормальной формы эти, два поля надо поместить в отдельную таблицу вместе с полем Код заказа, от которого они зависят. Это приведет к образованию двух таблиц: «Заказы» и «Содержание заказов». Таблица «Заказы» использует в качестве индексного поля Код заказа, а таблица «Содержание заказов» использует качестве индекса комбинацию полей Код заказа и Код товара.
|
Таблица «Заказы»
|
Таблица «Содержание заказов 1»
|
Путем соблюдения второго правила нормализации была создана структура, состоящая из двух таблиц, одна из которых содержит информацию о заказе в целом, а другая включает в себя детали по каждому заказу. Обратите внимание на то, что в таблице «Содержание заказов» появилось новое поле Позиция в заказе, играющего роль счетчика товаров для каждого заказа.
Чтобы связать информацию в таблице «Заказы» с таблицей «Содержание заказов», нужно определить отношение между ними. Отношение будет основано на поле Код заказа. Такое отношение называется "один - ко - многим", поскольку каждый заказу, представленному одной строкой в таблице «Заказы», может соответствовать несколько строк в таблице «Содержание заказов». Теперь клиент может заказывать любое количества товаров!
2.7.4 Третья нормальная форма таблицы.
Для получения третьей нормальной формы таблица должна удовлетворять требованиям первой и второй нормальных форм. Далее для каждой таблицы определяют первичный ключ, состоящий из одного поля или комбинации полей. Например, для списка сотрудников предприятия ключевым будет поле личности сотрудника (или поле его личного номера). Для нашего примера в таблице заказов в качестве ключевого поля можно использовать Код заказа.
Таблица с деталями заказов не имеет поля, однозначно определяющего запись. В ней может быть более одной записи с одинаковыми значениями Код заказа, да и значения Код товара может появляться несколько раз - как в одном заказе, так и в разных. Значения поля Позиция в заказе повторяются начиная с 1 для каждого заказа. А вот сочетание полей Код заказа и Позиция в заказе уникально для каждой записи. Даже если один товар повторяется в заказе дважды, то для него значения поля Позиция в заказе все равно будут разными. Поэтому говорят, что таблица «Содержание заказов» имеет составной первичный ключ.
Для иллюстрации третьей нормальной формы добавим к таблице еще одно поле с наименованием товара Наименование товара. Таблица примет следующий вид:
Таблица «Содержание заказов 2»
|
Код заказа |
Код товара |
Позиция в заказе |
Наименование товара |
|
11 |
ПР1 |
001 |
Процессор |
|
11 |
ПР2 |
002 |
Модем |
|
11 |
ПР3 |
003 |
Мышь |
|
22 |
ПР4 |
001 |
Модем |
Для третьей нормальной формы все не ключевые поля должны зависеть только от полного набора ключевых полей. Вначале проверим, зависит ли Код товара от сочетания Код заказа и Позиция в заказе. Ответ будет положительным, поскольку для каждого из сочетаний значений Код заказа и Позиция в заказе может быть только один Код товара.
Зависит ли код товара от названия товара? Лишь в некоторой степени зависит, поскольку один и тот же вид товара может иметь разные размеры, расцветку, и соответственно разные коды. Поэтому одному названию товара может соответствовать несколько кодов, но каждый код однозначно соответствует своему названию.
Зависит ли название товара только от ключевых полей? Нет, вместо них оно однозначно зависит от кода товара Код товара. Поэтому поле Наименование товара не удовлетворяет условию третьей нормальной формы.
В качестве решения можно поместить название товара и его код (и, быть может, ряд других его свойств: цена, количество на складе и т.п.) в отдельную таблицу «Товары», где код товара будет индексным полем. Получится структура, показанная в таблицах «Содержание заказов 4» и «Товары».
|
Таблица «Содержание заказов 4»
|
Таблица «Товары»
|
Проведя подобный анализ для всех таблиц, составляющих базу данных, её можно считать нормализованной. (Хотя имеются ещё два правила нормализации, потребность в них возникает чрезвычайно редко).