- •Введение
- •Часть 2. Общая классификация архитектур информационных приложений
- •2.1. Файл-серверные приложения
- •2.2. Клиент-серверные приложения
- •2.2. Клиент-серверные приложения
- •2.3. Intranet-приложения
- •2.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных
- •2.5. Интегрированные распределенные приложения
- •Часть 3. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений
- •3.1. Традиционные средства и методологии разработки файл-серверных приложений
- •3.1.1. Системы программирования и библиотеки
- •3.1.2. Средства и методы разработки приложений на основе субд на персональных компьютерах
- •3.2. Новые средства разработки файл-серверных приложений
- •3.2.1. Общая характеристика современных средств
- •3.2.2. Примеры новых подходов
- •3.2.2.1. Пакет ms Access
- •3.2.2.2. Система Visual FoxPro
- •3.2.2.3. Среда программирования ca-Visual Objects
- •3.3. Перенос файл-серверных приложений в среду клиент-сервер
- •3.3.1. Библиотеки доступа к базам данных
- •3.3.2. Протокол odbc и его реализации
- •3.3.3. Укрупнение приложений (Upsigsing)
- •3.4. Рекомендации по использованию инструментальных средств разработки файл-серверных приложений
- •4.4. Классический подход к проектированию реляционных баз данных
- •4.4.1. Функциональные и прочие зависимости
- •4.4.2. Проектирование реляционных баз данных на основе принципов нормализации
- •4.4.2.1. Вторая нормальная форма
- •4.4.2.2. Третья нормальная форма
- •4.4.2.3. Нормальная форма Бойса-Кодда
- •4.4.2.4. Четвертая нормальная форма
- •4.4.2.5. Пятая нормальная форма
- •4.5. Концептуальные модели и схемы баз данных
- •4.5.1. Диаграммное представление
- •4.5.1.1. Основные понятия модели Entity-Relationship (Сущность-Связи)
- •4.5.1.2. Нормальные формы er-схем
- •4.5.1.3. Более сложные элементы er-модели
- •4.5.1.4. Получение реляционной схемы из er-схемы
- •4.5.2. Виды нотаций
- •4.5.2.1. Case-метод Баркера
- •4.5.2.2. Методология idef1
- •4.5.2.3. Подход, используемый в case-средстве Vantage Team Builder
- •4.6. Case-системы для проектирования информационных систем
- •4.6.1. Назначение и разновидности case-систем
- •4.6.2. Примеры и различия распространенных case-систем
- •4.6.2.4. Локальные средства (eRwin, bPwin, s-Designor, case.Аналитик)
- •4.6.2.5. Объектно-ориентированные case-средства (Rational Rose)
- •4.7. Физическое проектирование баз данных
- •4.7.1. Противоречия теории и практики
- •4.7.2. Денормализация для оптимизации
- •Часть 6. Информационные приложения, основанные на использовании "складов данных" (DataWarehousing)
- •6.1. Проблема интеграции данных
- •6.2. Подходы и имеющиеся решения
- •6.2.1. Компания ibm
4.4.2. Проектирование реляционных баз данных на основе принципов нормализации
Итак, классический подход к проектированию реляционных баз данных основывается на декомпозиции отношений с целью их нормализации.
4.4.2.1. Вторая нормальная форма
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР,
ПРО_НОМЕР, СОТР_ЗАДАН)
Это отношение связывает уникальный номер сотрудника с размером его заработной платы, номером отдела, в котором работает сотрудник, номером проекта, в котором участвует сотрудник, и номером задания, выполняемого сотрудником в рамках этого проекта.
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР --> СОТР_ЗАРП
СОТР_НОМЕР --> ОТД_НОМЕР
ОТД_НОМЕР --> СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР --> СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.
Определение 6: Вторая нормальная форма (В этом определении предполагается, что единственным ключом отношения является первичный ключ.)
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР --> СОТР_ЗАРП
СОТР_НОМЕР --> ОТД_НОМЕР
ОТД_НОМЕР --> СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР --> CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).
Если допустить наличие нескольких ключей, то определение 6 примет следующий вид:
Определение 6: Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF и каждый неключевой атрибут полностью зависит от каждого ключа R.
Здесь и далее мы не будем приводить примеры для отношений с несколькими ключами. Они слишком громоздки и относятся к ситуациям, редко встречающимся на практике.