бд полный курс. Информация, данные, информационные системы Информация как социальный ресурс
 Скачать 1.56 Mb.
|
|
Информация, данные, информационные системы Понятие функциональной зависимости в данных Оставим пока в стороне ответ на вопрос, почему проекты реляционных баз данных бывают плохими, т.е. зачем нужно проектировать реляционную базу данных. Попытаемся сначала ответить на вопросы "В чем заключается проектирование реляционных баз данных? и "Что лежит в основе процедур проектирования реляционных баз данных?" Как известно, основной единицей представления данных в реляционной модели является отношение, которое математически задается списком имен атрибутов, иначе - схемой отношения. На стадии логического проектирования реляционной базы данных проектировщик определяет и выстраивает схемы отношений в рамках некоторой предметной области, а именно - представляет сущности, группирует их атрибуты, выявляет основные связи между сущностями. Так, в самом общем смысле проектирование реляционной базы данных заключается в обоснованном выборе конкретных схем отношений из множества различных альтернативных вариантов схем. На практике построение логической модели базы данных, независимо от используемой модели данных, выполняется с учетом двух основных требований: исключить избыточность и максимально повысить надежность данных. Эти требования вытекают из требования коллективного использования данных группой пользователей. Формальных средств описания данных, необходимых для проверки правильности заполнения конструкций моделей, явно недостаточно. Выбор сущностей, атрибутов и фиксация взаимосвязей между сущностями зависит от семантики предметной области и выполняется системным аналитиком субъективно в соответствии с его личным пониманием специфики прикладной задачи. Разные люди определяют и представляют данные по-разному. Поэтому любое априорное знание об ограничениях предметной области, накладываемых на взаимосвязи между данными и значения данных, и знания об их свойствах и взаимоотношениях между ними может сыграть определенную роль в соблюдении указанных выше требований. Формализация таких априорных знаний о свойствах данных предметной области базы данных нашла свое отражение в концепции функциональной зависимости данных, т.е. ограничений на возможные взаимосвязи между данными, которые могут быть текущими значениями схемы отношений. Кортежи отношений могут представлять экземпляры сущности предметной области или фиксировать их взаимосвязь. Но даже если эти кортежи определены правильно, т.е. отвечают схеме отношения и выбраны из допустимых доменов, не всякий из них может быть текущим значением некоторого отношения. Например, возраст человека редко бывает более 120 лет, или один и тот же пилот не может одновременно выполнять два различных рейса. Такие ограничения семантики домена практически не влияют на выбор той или иной схемы отношений. Они представляют собой ограничения на типы данных. Априорные ограничения предметной области на взаимосвязь значений отдельных атрибутов оказывают наибольшее влияние на процесс проектирования схем реляционных баз данных. Соответствие по значению определенных атрибутов различных отношений базы данных, т.е. зависимость их значений друг от друга, определяет показатели надежности и корректности сохраняемых данных при их коллективном и согласованном использовании. Вспомним определение функции как соответствия множества аргументов определенным значениям из множества определения функции и способы задания функций: формула, график и перечисление (таблица). Нетрудно понять, что функциональную зависимость (ФЗ) можно определить на довольно широком классе объектов. Определение функции не накладывает никаких ограничений на множество аргументов и множество значений функции, кроме их существования и наличия соответствия между их элементами. Поскольку ФЗ можно задать таблично, а таблица есть форма представления отношения, то становится очевидной связь между ФЗ и отношением. Отношение может задавать ФЗ. Это утверждение является первой (1) конструктивной идеей, которая положена в основу теории проектирования реляционных баз данных. Определение 1. Пусть r (A1, A2, ..., An) - схема отношения R, a X и Y - подмножества r. Говорят, что Х функционально определяет Y, если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y. Такая ФЗ обозначается как  .Как видно из определения, функциональная зависимость инвариантна к изменению состояний базы данных во времени. Пример. Понятие функциональной зависимости Продемонстрируем понятие функциональной зависимости на примере графика полетов аэропорта. ГРАФИК_ПОЛЕТОВ (Пилот, Рейс, Дата_вылета, Время_вылета)
Известно, что: каждому рейсу соответствует определенное время вылета; для каждого пилота, даты и времени вылета возможен только один рейс; на определенный день и рейс назначается определенный пилот. Следовательно: "Время_вылета" функционально зависим от "Рейс": "Рейс" -> "Время_{} вылета" ; "Рейс" функционально зависим от {"Пилот", "Дата_вылета", "Время_вылета"}: {"Пилот", "Дата_вылета", "Время_вылета"} -> "Рейс" ; "Пилот" функционально зависим от {"Рейс", "Дата_вылета"}: {"Рейс", "Дата_вылета"} -> "Пилот". Важной задачей при выявлении функциональных зависимостей на атрибутах отношения, которое по определению является множеством, является выяснение, какой из атрибутов выступает как аргумент, а какой - как значение ФЗ. Наиболее подходящими кандидатами в аргументы ФЗ являются возможные ключи, так как кортежи представляют экземпляры сущности, которые идентифицируются значениями атрибутов своего ключа. Нестрого говоря, функциональная зависимость имеет место на отношении, когда значения кортежа на одном множестве атрибутов однозначным образом определяют значения кортежа на другом множестве атрибутов. Это рабочее определение ФЗ не содержит в себе тех формальных элементов, которые позволяют ответить на вопрос "А как проверить наличие ФЗ между атрибутами отношения?" Необходимый для этого формализм дает нам использование реляционных операций. Для получения формального (строгого) определения наличия ФЗ в отношении обратимся к реляционным операциям. Определение 2. Пусть имеется отношение R со схемой r, X и Y - два подмножества R. ФЗ  имеет место на R, если множество  имеет не более одного кортежа для каждого значения х. Такая ФЗ называется также F -зависимостью.Как видно из определения, формальная проверка наличия ФЗ в отношении R состоит в выборе (селекции) отношения по значениям возможного ключа и установлении наличия однозначности между его значением и значениями других атрибутов.Алгоритм, который проверяет, удовлетворяет ли отношение R ФЗ , состоит в сортировке отношения по значениям возможного ключа и установления факта однозначности между его значением и значениями других атрибутов. Этот алгоритм полезен, но он носит вспомогательный характер.Ясно, что если семантика предметной области базы данных сложна, то проверить кортежи на принадлежность к ФЗ достаточно сложно. Сложно вообще установить наличие самой функциональной зависимости, отвечающей природе рассматриваемых данных. С помощью такого формального метода можно выявить ФЗ, которые не являются реальными и носят случайный характер. Проектировщику реляционных баз данных следует знать о таком методе проверки наличия ФЗ, но при проектировании новой базы данных его применение малоэффективно. Он может быть полезен при реинжиниринге существующей базы данных. Функциональные зависимости фактически представляют собой утверждения обо всех отношениях предметной области. Эти отношения могут являться значениями схемы r и, в сущности, не могут быть получены формальными методами. Единственный способ установления функциональных зависимостей для схемы отношения r - это исследование семантики атрибутов сущностей предметной области. Являясь высказываниями о сущностях предметной области, они не могут быть доказаны. Это обстоятельство по существу порождает неединственность представления предметной области отношениями реляционной БД. Здесь уместно высказать гипотезу о том, почему бывают хорошие и плохие проекты баз данных. Во-первых, в силу субъективности подходов к анализу предметной области аналитики могут упустить важные ФЗ. Это может привести к тому, что, работая на множестве заведомо неэквивалентных схем, проектировщик создаст неудовлетворительный проект базы данных. Во-вторых, неединственность представления предметной области отношениями приводит к проблеме выбора из множества альтернатив. При этом схема базы данных, выбранная из набора эквивалентных схем, является правильной, но может организовывать данные для пользователя непривычным образом. В-третьих, можно определить ("накроить") схемы баз данных таким образом, что в результате операций с ФЗ будут потеряны и ФЗ, и сами данные. Понятие о логической модели реляционной базы данных Теперь, когда определены понятия отношения и операции над отношениями, уточним интуитивно используемое определение реляционной базы данных и ее схемы. Определение 1. Под реляционной базой данных принято понимать совокупность экземпляров конечных отношений. Совокупность схем отношений образует схему реляционной базы данных. Схема реляционной базы данных является логической моделью реляционной базы данных. Как уже было сказано в "Предметная область базы данных и ее модели" - "Предметная область базы данных и ее модели", - на основе информационной модели в процессе проектирования создаются логическая и физическая модели данных. Информационная модель данных отражает потребности системы в данных и связи между данными с точки зрения их потребителей - пользователей; логическая модель данных является независимым логическим представлением данных; физическая модель данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД. На практике часто рассматривают только две модели - логическую и физическую модели данных. При этом информационная и логическая модели данных не различаются и считаются синонимами. В рамках такого подхода некоторые специалисты в области баз данных считают, что информационная модель данных должна быть нормализована. Это означает, что проектировщики баз данных должны требовать от аналитиков, чтобы они приводили информационную модель данных к третьей нормальной форме! Такой подход имеет ряд недостатков. Во-первых, аналитики, являясь экспертами в предметной области, как правило, не представляют, что такое нормализация данных. Во-вторых, информационная модель данных должна быть независимой от физической модели данных, в рамках которой она будет реализовываться. Для реализации информационной модели данных может быть выбрана не реляционная, а, например, сетевая (СУБД ADABAS ) или многомерная (СУБД Teradata ) модели данных, тогда нормализация отношений модели не столь актуальна. В-третьих, проектировщики базы данных должны иметь логическое представление данных, посредством которого, с одной стороны, общаться с аналитиками и пользователями в понятных для них терминах, и, с другой стороны, превращать полученные логические отношения в физические объекты базы данных. Поэтому в настоящем курсе рассматривается три уровня моделей данных, а процесс нормализации информационной модели данных считается составной частью процесса создания логической модели данных, которую предполагается реализовать на реляционной СУБД. На практике при построении логической модели реляционной базы данных особое значение для решения задачи формирования отношений базы данных имеет понятие функциональной зависимости (ФЗ). Установление ФЗ и получение наилучшего с точки зрения минимальности представления множества ФЗ позволят построить наиболее оптимальный вариант базы данных, обеспечивающий надежность хранения и обработки данных на основе методов эквивалентных преобразований схем отношений реляционной базы данных. Процесс решения такой задачи называется нормализацией отношений информационной модели предметной области и заключается в превращении ее объектов в логические таблицы базы данных. Нормализация отношений Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных. Заметим, что с математической точки зрения задача построения как информационной модели предметной области, так и логической модели реляционной базы данных является результатом решения следующих комбинаторных задач: группировка атрибутов в отношении предметной области; распределение атрибутов по отношениям базы данных. Такие задачи имеют решения, допускающие большое число вариантов, и приводят к проблеме выбора рационального варианта из множества альтернативных вариантов схем отношений. Выбор наиболее рационального варианта обусловлен соблюдением различного рода соглашений и требований. Перечень наиболее важных требований приведен ниже. Первичные ключи отношений должны быть минимальными (требование минимальности первичных ключей). Число отношений базы данных должно по возможности давать наименьшую избыточность данных (требование надежности данных). Число отношений базы данных не должно приводить к потере производительности системы (требование производительности системы). Данные не должны быть противоречивыми, т.е. при выполнении операций включения, удаления и обновления данных их потенциальная противоречивость должна быть сведена к минимуму (требования непротиворечивости данных). Схема отношений базы данных должна быть устойчивой, способной адаптироваться к изменениям при ее расширении дополнительными атрибутами (требование гибкости структуры базы данных). Разброс времени реакции на различные запросы к базе данных не должен быть большим (требование производительности системы). Данные должны правильно отражать состояние предметной области базы данных в каждый конкретный момент времени (требование актуальности данных). Создание системы, одновременно удовлетворяющей всем вышеназванным требованиям, представляет собой сложную оптимизационную задачу, которая подчас не имеет однозначного решения. Многие из требований находятся в противоречии друг к другу. Так, например, требование производительности находится в противоречии к требованию гибкости. Требование минимизировать число отношений в базе данных находится в противоречии к требованию надежности данных. В процессе эксплуатации реляционной базы данных происходит модификация данных: в отношениях добавляются или удаляются кортежи, в результате определенных событий изменяются значения некоторых атрибутов кортежей и т.п. После манипулирования данными значения некоторых атрибутов могут дублироваться, порождая избыточность данных, значения некоторых атрибутов могут удаляться, исчезая из базы данных, хотя потребность в этих значениях остается, некоторые значения атрибутов не могут быть добавлены, поскольку их значения неизвестны, т.е. данные в базе данных с течением времени становятся несогласованными и противоречивыми. Потенциальная противоречивость (или аномалии) при выполнении операций манипулирования данными в базе данных зависит как от типа ФЗ между атрибутами, так и от группировки этих атрибутов по отношениям. Рассмотрим типичные примеры аномалий, возникающих при выполнении операций включения, удаления и модификации данных. Пример. Аномалии операций над базой данных ПОСТАВКИ (Поставщик, Адрес, Товар, Количество, Стоимость) Обновление. Если Поставщик поставляет несколько видов товара, то значение атрибута Адрес повторяется для каждого кортежа и, следовательно, при изменении адреса поставщика необходимо изменить значение этого атрибута во всех этих кортежах. Иначе будет нарушена целостность данных базы данных. Удаление. Если Поставщик прекращает поставку товаров на некоторое время, то кортежи со всеми его поставками удаляются. При этом происходит потеря реквизитов поставщика - Адреса и Наименования. Вставка. Если договор на поставку уже заключен, а поставка еще не произведена, то невозможно включить в рассматриваемое отношение значения атрибутов Поставщик и Адрес, поскольку нет сведений о поставках (проблема интерпретации нуль-значений). Подобные аномалии в данных лишь отчасти дают ответ на вопрос, почему логическая структура реляционной БД может быть неудовлетворительной. Некоторые проблемы избыточности данных можно разрешить, заменив, например, исходное отношение ПОСТАВКИ на два новых отношения - отношение ПОСТАВЩИК (Поставщик, Адрес) и отношение ПОСТАВКА (Поставщик, Товар, Количество, Стоимость). Однако в целом остается ряд вопросов, на которые теория реляционных баз данных не дает удовлетворительных ответов: "Как найти хорошую замену для плохой схемы отношений? Как определить, является ли выбранная замена выгодной? Как создать схему, обеспечивающую наилучшую производительность?" Например, для того чтобы выполнить запрос, использующий данные из двух таблиц, необходимо построить соединение этих таблиц, которое является дорогостоящей операцией с физической базой данных с точки зрения числа выполняемых операций ввода/вывода. Теория функциональных зависимостей позволяет установить определенные требования к схемам отношений в реляционной базе данных. Эти требования формулируются в терминах свойств отношений и называются нормальными формами схем отношений. Каждая нормальная форма отношений связана с определенным классом ФЗ, которые представлены в отношениях. Понятно, что одним из очевидных способов устранения потенциальной противоречивости данных в отношениях логической модели реляционной базы данных является их разбиение на два или более отношений, в каждом из которых присутствует только одна ФЗ. Это возможно, поскольку теория ФЗ утверждает, что существует минимальное покрытие множества ФЗ базы данных, т.е. минимальный набор ФЗ, из которых можно вывести все остальные. Каждой ФЗ из минимального покрытия можно отвести по самостоятельному отношению. Однако, во-первых, для заданного множества ФЗ может существовать несколько минимальных покрытий (выбор среди возможных альтернатив), и, во-вторых, для практики важно иметь наглядный способ построения минимального покрытия. Процесс устранения потенциальной противоречивости и избыточности данных в отношениях реляционной базы данных называется нормализацией исходных схем отношений. Нормализация отношений заключается в выполнении декомпозиции или синтеза отношений, назначении ключей отношений в соответствии с определенными правилами, гарантирующими целостность отношений базы данных. Требование минимальности числа отношений, т.е. построения минимального покрытия ФЗ обычно является опциональным. На минимальном покрытии, как правило, не может быть достигнута высокая производительность обработки запросов. Почему нормализация схем отношений важна для проектирования реляционных баз данных? Многочисленные испытания показали, что нормализация схем отношений дает наилучший результат при моделировании предметной области с использованием реляционной модели данных; при этом не вводится большого числа ограничений, не искажаются данные. Таким образом, нормализация отношений является методом удаления из отношения ФЗ, которые приводят к аномалиям модификации данных. Иными словами, нормализация отношений помогает проектировать реляционную базу данных, которая не содержит избыточных данных и гарантирует их целостность. Язык нормальных форм констатирует наличие или отсутствие определенных ФЗ в отношениях реляционной базы данных и указывает на уровень избыточности и надежности данных в нормализованных отношениях. Методы нормализации отношений основываются на применении понятия ФЗ и способов манипулирования ими. При выполнении реляционных операций над отношениями в базе данных каждый тип ФЗ может порождать определенный тип аномалий, который будет нарушать целостность данных в базе данных. Нормальная форма (НФ) представляет собой ограничение на схему базы данных, вводимое с целью устранения определенных нежелательных свойств при выполнении реляционных операций. Различают несколько типов нормальных форм. Каждая из них ограничивает присутствие определенного класса ФЗ в отношении и устраняет присущие этому классу ФЗ аномалии в выполнении реляционных операций. Примечание. Глагол quot;ограничиваетquot; в терминологии баз данных означает набор процедур, направленных на достижение определенных свойств объекта путем сужения области его действия. |