Компьютерные технологии подготовки текстовых документов, обработки экономической информации на основе табличных процессоров, использования систем управления базами данных (СУБД), интегрированных программных пакетов.
Технологии разработки и использования баз данных
1. Современные технологии баз и банков данных
2. Управление информационными ресурсами в АИС
3. Методика проектирования логической модели базы данных
1. Современные технологии баз и банков данных
К современным технологиям обработки данных относится:
распределенная обработка;
системы Клиент-Сервер;
интегрированные (федеративные) системы;
мультибазы данных;
объектно-ориентированные базы данных.
Распределенная обработка предполагает, что определенная задача, обрабатывающая данные может быть распределена на нескольких участках сети. Необходимо понимать разницу между распределенной и параллельной обработкой. При параллельной обработке характерно когда машины с физической точки зрения расположены близко друг к другу. А при распределенной обработке это совсем необязательно и зачастую бывает, что машины удалены на значительные расстояния. Связь между машинами осуществляется с помощью сети и специального программного обеспечения управления сетью (СЛАЙД 9).
Чаще всего бывает, что узлы при распределенной обработке распределены физически, а также географически, хотя в действительности достаточно, чтобы они были распределены логически.
Необходимость распределенной обработки объясняется тем, что крупные предприятия как правило имеют распределенную структуру, по крайней мере они распределены логически (по видам деятельности: на бухгалтерию, склад и т.д.) и физически (на отделы, группы, лаборатории и т.д.). Из этого следует, что данные в них также распределены, поскольку на каждом уровне ведется работа с данными, относятся к этому уровню. Таким образом, в распределенной системе можно отобразить структуру предприятия с помощью соответствующей структуры БД, т.е. данные локального значения могут храниться локально, что в наибольшей мере отвечает логической структуре системы, тогда как доступ к удаленным данным осуществляется по мере необходимости.
Системы типа «Клиент-Сервер» могут рассматриваться как особый случай распределенной обработки. Точнее, система К-С сама является распределенной, в которой одни узлы являются клиентами, а другие серверами. Все данные хранятся на серверах, все приложения исполняются клиентами, а места их соединения скрыты от пользователя (СЛАЙД 10, 11).
Интегрированные (федеративные) системы и мультибазы данных.
Направление интегрированных или федеративных систем неоднородных БД и мульти-БД появилось в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление пользователям интегрированной системы глобальной схемы БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД. В теоретическом плане проблемы преобразования решены, имеются реализации.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая тем не менее иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, развивается направление мульти-БД. В системах мульти-БД не поддерживается глобальная схема интегрированной БД и применяются специальные способы именования для доступа к объектам локальных БД. Как правило, в таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно к собственным проблемам интеграции приходится решать все проблемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно добиться эффективности.
Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель данных. В последнее время все чаще предлагается использовать объектно-ориентированные модели, но на практике пока основой является реляционная модель. Поэтому, в частности, включение в интегрированную систему локальной реляционной СУБД существенно проще и эффективнее, чем включение СУБД, основанной на другой модели данных.
Объектно-ориентированные базы данных.
Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно (середине 1980-х). Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:
· объекта и идентификатора объекта;
· атрибутов и методов;
· классов;
· иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.
Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
Наиболее важным новым качеством ООБД, которого позволяет достичь объектно-ориентированный подход, является поведенческий аспект объектов. В прикладных информационных системах, основанных на БД с традиционной организации (вплоть до тех, которые базировались на семантических моделях данных), существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать и т.д., а поведенческая часть создавалась изолированно. В частности, отсутствовали формальный аппарат и системная поддержка совместного моделирования и гарантирования согласованности этих структурной (статической) и поведенческой (динамической) частей. В среде ООБД проектирование, разработка и сопровождение прикладной системы становится процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему.
2. Управление информационными ресурсами в АИС
Стремительный рост популярности SQL является одной из самых важных тенденций в современной компьютерной промышленности. Сегодня SQL поддерживает более ста СУБД, работающих как на мэйнфреймах, так и на ПК. SQL единственный стандартный язык БД. Был принят, а затем дважды дополнен официальный стандарт на SQL.
SQL является инструментом, предназначенным для выборки и обработки информации, содержащейся в компьютерной БД. SQL является языком программирования, который применяется для организации взаимодействия пользователя с БД. SQL работает только с реляционными БД.
Следующая схема иллюстрирует работу SQL при доступе к БД (СЛАЙД 12).
В вычислительной системе имеется БД, в которой хранится информация. В компьютерной системе устанавливается специальная программа, называемая СУБД. Если пользователю необходимо получить информацию из БД, он запрашивает ее у СУБД с помощью SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю. Этот процесс носит название «запрос к БД».
SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляет пользователю. К ним относятся:
· организация данных. SQL позволяет изменять структуру представления данных, а также устанавливать отношения между элементами БД;
· выборка данных. SQL позволяет извлекать информацию из БД;
· обработка данных. SQL позволяет изменять БД, т.е. добавлять в нее новые данные, а также удалять или обновлять уже имеющиеся в ней данные;
· управление доступом;
· совместное использование данных. SQL координирует совместное использование данных пользователями, чтобы они не мешали друг другу;
· целостность данных. SQL обеспечивает защиту БД от разрушения из-за несогласованных изменений или отказе системы.
SQL представляет собой неотъемлемую часть СУБД, инструмент, с помощью которого осуществляется связь с пользователя с ней. Следующая схема показывает структуру типичной СУБД. Компоненты которой соединяются в единое целое с помощью SQL (СЛАЙД 13).
Шлюз БД представляет собой программу, которая позволяет СУБД одного типа связываться с СУБД другого типа.
SQL стандартизован Американским национальным институтом стандартов (ANSI) и Международной организацией по стандартизации (ISO) в 1989 г. – SQL 1, 1992 – SQL 2.
В технологии БД существует важная область, которую не затрагивают официальные стандарты. Это способность к взаимодействию с другими БД – методы, с помощью которых различные БД могут обмениваться информацией. В Windows эта функция реализуется с помощью протокола ODBC (открытый доступ к базам данных). ODBC является стандартом межплатформенного доступа к БД, поддерживаемыми всеми ведущими СУБД.
Рост популярности компьютерных сетей оказал большое влияние на управление БД и придал SQL новые возможности. По мере распространения сетей приложения, которые раньше работали на центральном мини-компьютере или мэейнфрейме, переводятся на серверы и рабочие станции ЛВС. В таких сетях SQL связывает приложения, выполняющиеся на рабочей станции, и СУБД, управляющую совместно используемыми данными на сервере. С появлением трехуровневой архитектуры Internet язык SQL стал связующим звеном между управляющим приложением (второй уровень – сервер приложений или Web-сервер) и сервером БД (третий уровень).
Централизованная архитектура (СЛАЙД 14).
Использовалась в первоначальных СУБД для мини-компьютеров. При подобной архитектуре и СУБД, и сами данные размещаются на центральном мини-компьютере или мэйнфрейме вместе с приложением, принимающим входную информацию с пользовательского терминала и отражающим на нем же данные. Характерным является то, что при увеличении числа пользователей возрастает нагрузка на систему.
Архитектура файл/сервер (СЛАЙД 15).
При такой архитектуре приложение, выполняемое на ПК, может получить «прозрачный» доступ к файловому серверу, на котором хранятся совместно используемые файлы. Когда приложению, работающему на ПК, требуется получить данные из такого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. Эта архитектура поддерживалась первыми версиями СУБД. При выполнении обычных запросов она обеспечивала приемлемую производительность. Однако, при последовательном просмотре БД, СУБД постоянно запрашивает новые записи из БД, которая физически расположена на сервере. В этом случае сильно возрастает нагрузка на сеть, что приводит к снижению производительности системы в целом.
Архитектура клиент-сервер (рассматривалась ранее, во 2-м вопросе).
Трехуровневая архитектура Internet (СЛАЙД 16).
В начале своего развития WWW являлась средой просмотра статических документов и развивалась независимо от рынка СУБД. Однако, по мере развития оказалось, что это очень удобный способ доступа к корпоративным БД.
Методы связывания Web-серверов и СУБД в ходе своего развития вылились в трехуровневую архитектуру.
I. – информационный уровень
II. – прикладной уровень
III. – клиентский уровень
OLTP – оперативная
обработка транзакций
Интерфейсом пользователя является Web-броузер, выполняющийся на ПК. Броузер взаимодействует с Web-сервером, уровень которого можно оценить как прикладной. Если пользователь запрашивает нечто большее чем просто Web-страницы, Web-сервер адресует запрос серверу приложений, чья роль заключается в анализе запроса. Запрос может включать обращение к унаследованной системе, выполняющейся на мэйнфрейме (OLTP-системе), либо к корпоративной БД. Это уже информационный уровень. В этой архитектуре SQL закрепился как стандартное средство взаимодействия между вторым и третьим уровнями.
Хранилище данных.
В настоящее время реляционные БД заняли абсолютно доминирующую позиция на рынке БД. До тех пор, пока такая БД используется в пределах малой или средней корпорации проблем не возникает. Однако, даже для них при возникновении запроса, связанного с принятием решения (например, нахождение средней стоимости заказа, или поиск прироста продаж за определенный период времени), могут требовать сканирования огромных таблиц и выполняться минутами или даже часами. Если выполнять подобные операции в период пика деловых транзакций, это может вызвать серьезное снижение производительности всей системы. Еще одну проблему составляет размещение данных, необходимых для получения ответов на вопросы из области делового анализа: они могут быть распределены между многими БД, причем, как правило, еще и поддерживаемыми разними СУБД и на разных компьютерных платформах.
Необходимость в полноценном использовании информационного потенциала предприятия, т.е. накопленных данных, а также практические проблемы, связанные с производительностью, породили новое техническое решение, получившее название «хранилище данных» (СДАЙД 17).
Деловые данные извлекаются из OLTP-системы предприятия, форматируются и проверяются, а затем помещаются в отдельную БД, предназначенную исключительно для делового анализа («хранилище»). Извлечение и форматирование данных можно выполнять периодически, в пакетном режиме во время наименьшей загрузки системы. Долго выполняющиеся запросы, связанные с деловым анализом, адресуются только к хранилищу данных и не требуют систем оперативной обработки транзакций.
Для удовлетворения специфических потребностей приложений, работающих с хранилищами данных и часто называемыми приложениями оперативной аналитической обработки (OLAP), стали появляться специальные СУБД. Ведущую роль в таких СУБД занимает SQL.
3. Методика проектирования логической модели базы данных
Проектирование логической модели БД целесообразно проводить с помощью ER-диаграммами (диаграмм Сущность-Связь). В данном вопросе рассматривается нотация ER-диаграмм и основные методы семантического моделирования данных.
Основные понятия ER-диаграмм
Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".
Каждая сущность в модели изображается в виде прямоугольника с наименованием (СЛАЙД 2):
Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности (СЛАЙД 3).
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Определение 4. Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность (СЛАЙД 4).
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Определение 5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою (СЛАЙД 5)
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".
Графически связь изображается линией, соединяющей две сущности:
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи (СЛАЙД5):
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности. Мощность связей может подписываться у концов связи (например, 1-к-5).
Каждая связь может иметь одну из двух модальностей связи (СЛАЙД5):
Модальность "может" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность "должен" означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Пример разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной области:
1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:
· Хранить информацию о покупателях.
· Печатать накладные на отпущенные товары.
· Следить за наличием товаров на складе.
Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):
· Покупатель - явный кандидат на сущность.
· Накладная - явный кандидат на сущность.
· Товар - явный кандидат на сущность
· (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
· (?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так (СЛАЙД 6):
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом (СЛАЙД 7):
Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:
· Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
· Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
· Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
· Каждый склад имеет свое наименование.
· Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
· Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
· Наименование покупателя - явная характеристика покупателя.
· Адрес - явная характеристика покупателя.
· Банковские реквизиты - явная характеристика покупателя.
· Наименование товара - явная характеристика товара.
· (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
· Единица измерения - явная характеристика товара.
· Номер накладной - явная уникальная характеристика накладной.
· Дата накладной - явная характеристика накладной.
· (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
· (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
· (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
· Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
· Наименование склада - явная характеристика склада.
В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.
С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".
Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму (СЛАЙД 8):
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант только что рассмотренной диаграммы, будет выглядеть следующим образом (СЛАЙД 9):
На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Нормализация данных в БД
Нормализация – это разбиение сущности на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого вида базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Всякая нормализованная сущность автоматически считается сущностью в первой нормальной форме (1НФ). Помимо 1НФ существуют следующие уровни нормализации – вторая нормальная форма (2НФ), третья нормальная форма (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже.
Сущность находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д. Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая.
Теория нормализации основывается на наличии той или иной зависимости между экземплярами сущностей. Определены два вида таких зависимостей: функциональные и многозначные.
Функциональная зависимость. Экземпляр В таблицы функционально зависит от экземпляра А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений экземпляра А обязательно существует только одно из различных значений экземпляра В. При этом здесь допускается, что экземпляры А и В могут быть составными.
Полная функциональная зависимость. Экземпляр В находится в полной функциональной зависимости от составного экземпляра А, если оно функционально зависит от А и не зависит функционально от любого подмножества экземпляра А.
Многозначная зависимость. Экземпляр А многозначно определяет экземпляр В той же сущности, если для каждого значения экземпляра А существует хорошо определенное множество соответствующих значений В.
Сущность находится в первой нормальной форме (1НФ) тогда и только тогда, когда все ее экземпляры просты, т.е. неделимы.
Сущность находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее экземпляры, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Сущность находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не один из ее неключевых экземпляров не зависит функционально от любого другого неключевого экземпляра. Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.
В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между экземплярами сущностей. Для их описания используется понятие полной декомпозиции сущности.
Полной декомпозицией сущности называют такую совокупность произвольного числа ее проекций, соединение которых полностью совпадает с содержимым сущности.
Сущность находится в пятой нормальной форме (5НФ) тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Сущность, не имеющая ни одной полной декомпозиции, также находится в 5НФ.
Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций.
Как отмечалось ранее, нормализация – это разбиение сущности на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Теперь можно дать и другое определение: нормализация – это процесс последовательной замены сущности ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ. На практике же достаточно привести таблицы к 3НФ.
Эта процедура основывается на том, что единственными функциональными зависимостями в любой сущности должны быть зависимости вида K→F, где K – первичный ключ, а F – некоторый экземпляр этой сущности. При этом, как следует из определения первичного ключа сущности, в соответствии с которым K→F всегда имеет место для всех экземпляров данной сущности. «Один факт в одном месте» говорит о том, что не имеют силы никакие другие функциональные зависимости.
Цель нормализации состоит именно в том, чтобы избавиться от всех «других» функциональных зависимостей, т.е. таких, которые имеют иной вид, чем K→F.