Реляционная модель данных

Операция УДАЛИТЬ  также требует наименования отношения, а также идентификации кортежа и группы кортежей, подлежащих удалению.

Операция ОБНОВИТЬ выполняется для названного отношения  и может корректировать как один, так и несколько кортежей отношения.

Далее рассмотрим основные операции обработки отношений. Отличительная  особенность этих операций заключается  в том, что единицей обработки  в них являются не кортежи, а отношения. Другими словами, на входе каждой операции используется одно или несколько  отношений, а результат выполнения операций — новое отношение.

Смысл любой обработки  реляционной базы данных состоит  либо в обновлении существующих отношений, либо в создании новых, поскольку  результат всякого запроса к  БД есть не что иное, как построение нового отношения, удовлетворяющего условиям выборки.

Операция ОБЪЕДИНЕНИЕ (С1 = А U В) предполагает, что на входе задано два односхемных отношения А и В. Результат объединения есть построенное по той же схеме отношение С, содержащее все кортежи А и все кортежи отношения В. Операция ПЕРЕСЕЧЕНИЕ (С2=А U В) предполагает на входе два односхемных отношения А и В. На выходе создается отношение по той же схеме, содержащее только те кортежи отношения А, которые есть в отношении В.

Операция ВЫЧИТАНИЕ (С3=А-В). Все три отношения строятся по одной схеме. В результирующее отношение С3 включаются только те кортежи  из А, которых нет в отношении В.

Операция ДЕКАРТОВО  ПРОИЗВЕДЕНИЕ (С4=А X В). Ее важное отличие от предшествующих состоит в том, что отношения А и В могут быть построены по разным схемам, а схема отношения С4 включает все атрибуты отношении А и В.

Операция ВЫБОРКА (горизонтальное подмножество). На входе  операции используется одно отношение. Результат выборки есть новое  отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.

Операция ПРОЕКЦИЯ (вертикальное подмножество). На входе  операции используется одно отношение. Результирующее отношение включает подмножество атрибутов исходного. Каждому кортежу исходного отношения соответствует такой кортеж в результирующем отношении, что значения одинаковых атрибутов этих двух кортежей совпадают. Но при этом в результирующем отношении кортежи-дубликаты устраняются, в связи с чем мощность результирующего отношения может быть меньше мощности исходного.

Операция СОЕДИНЕНИЕ. На входе операции используется два  отношения; обозначим их А и В. В каждом из отношений выделен атрибут, по которому будет осуществляться соединение; предположим, это атрибуты А1 и Б2). Оба атрибута должны быть определены на одном и том же домене. Схема результирующего отношения включает все атрибуты А и все атрибуты отношения В. Допускается, чтобы в схеме результирующего отношения вместо двух атрибутов, по которым выполняется соединение, был представлен только один.

Операция СОЕДИНЕНИЕ похожа на декартово произведение. Отличие состоит в том, что декартово произведение предполагает сцепление, каждого кортежа из А с каждым кортежем из В, а в операции соединения кортеж из отношения А сцепляется только с теми кортежами из В, для которых выполнено условие: В1=А1.

Операция ДЕЛЕНИЕ. На входе операции используется два  отношения А и В. Пусть отношение А, называемое делимым, содержит атрибуты (А1,А2, ...,Аn). Отношение В – делитель -содержит подмножество атрибутов А; положим, (А1,А2, ...,Аk), где (k<n). Результирующее отношение С определено на атрибутах отношения А, которых нет и В, т.е.

Аk+1, Аk+2 , ..., Аn.

Кортеж включается в результирующее отношение только, если его декартово произведение с отношением В содержится в делимом-отношении А.

Операции реляционной  модели данных предоставляют возможность  произвольно манипулировать отношениями, позволяя обновлять БД, а также  выбирать подмножества хранимых данных и представлять их в нужном виде.

Рассмотренные нами операции реляционной алгебры или  алгебры отношений, позволяют пошагово описать процесс получения результирующего  отношения.

Отметим особенности реляционной модели данных:

• множество объектов реляционной модели данных однородно - структура данных определяется только в терминах отношений;

• основная единица  обработки в операциях реляционной  модели данных не запись (как в сетевых  и иерархических моделях данных), а множество записей - отношение.

НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

Одна из важнейших  проблем проектирования схемы БД заключается в выделении типов  записей (отношений), определении состава  их атрибутов. Группировка атрибутов  должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.

Сначала эти вопросы  решались интуитивно. Однако интуиция может подвести даже опытного специалиста, поэтому Коддом был разработан в  рамках реляционной модели данных аппарат, называемый нормализацией отношений. И хотя идеи нормализации сформулированы в терминологии реляционной модели данных, они в равной степени применимы и для других моделей данных.

Коддом выделено три нормальных формы отношений. Самая совершенная из них - третья. Предложен механизм, позволяющий  любое отношение преобразовать  к третьей нормальной форме. В  процессе таких преобразований могут  выделяться новые отношения.

Вначале введем понятие  простого и сложного атрибута. Простым  назовем атрибут, если значения его  атомарны, т. е. неделимы. В противовес ему сложный атрибут может иметь значение, представляющее собой конкатенацию нескольких значений одного или разных доменов. Аналогами сложного атрибута может быть вектор, агрегат данных, повторяющийся агрегат.

Первая нормальная форма. Отношение называется нормализованным  или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые.

Ненормализованное отношение легко сделать нормализованным. Такое преобразование может привести к увеличению мощности отношения и изменению ключа.

Функциональная зависимость. Пусть Х и Y - два атрибута некоторого отношения, Говорят, что Y функционально  зависит от X, если в любой момент времени каждому значению Х соответствует  не более чем одно значение атрибута Y. Функциональную зависимость можно обозначить так: Х>Y.

Полная функциональная зависимость. Говорят, что неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.

Вторая нормальная форма. Отношение находится во второй нормальной форме, если оно находится  в первой нормальной форме и каждый неключевой атрибут функционально полно зависит от составного ключа.

Чтобы отношение  привести ко второй нормальной форме, необходимо:

а) построить его  проекцию, исключив атрибуты, которые  не находятся в полной функциональной зависимости от составного ключа;

б) построить дополнительно  одну или несколько проекций на часть  составного ключа и атрибуты, функционально зависящие от этой части ключа.

Транзитивная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом Х>Y и Y>Z, но обратное соответствие отсутствует, т. е. Z не> или Y не>Х. Тогда говорят, что Z транзитивно зависит от X.

Третья нормальная форма. Отношение находится в  третьей нормальной форме, если оно  находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Основное достоинство  реляционного подхода - его простота и доступность. Пользователи абстрагированы от физической структуры памяти. Это  позволяет эксплуатировать БД без  знания методов и способов ее построения. Основные достоинства РМД следующие: простота, независимость данных; гибкость; непроцедурные запросы, теоретическое  обоснование на основе теории отношений. Это дает возможность пользователям  формировать их запросы более  компактно, в терминах более крупных агрегатов.

Как уже говорилось выше, в реляционной модели данных есть возможность определения одного атрибута или их множества в качестве ключа отношения. Это свойство позволяет  формировать запросы к базе данных очень компактно с использованием терминов реляционной алгебры и  реляционного счисления, что делает реляционную модель очень простой  для разработчика прикладного программного обеспечения.

С другой стороны, вся  информация, которая будет храниться  и использоваться в ИИСОД представляется в табличной форме, что является характерной чертой представления  информации в реляционных базах  данных, а в частности, в их разновидности табличных базах данных.

ЦЕЛИ  И ЗАДАЧИ ПРОЕКТИРОВАНИЯ

Основная цель процесса проектирования БД состоит: в получении  такого проекта, который удовлетворяет следующим требованиям:

• корректности схемы  БД, т. е. база данных должна быть гомоморфным  образом моделируемой предметной области, где каждому объекту предметной области соответствуют данные в  памяти ЭВМ, а каждому процессу предметной области - адекватные процедуры обработки  данных. При этом результаты выполнения процесса и соответствующих ему  процедур обработки данных должны совпадать  в любой момент функционирования, если это предусмотрено проектом;

• обеспечение ограничений  на конфигурацию вычислительной системы, в первую очередь, на ресурсы внешней и оперативной памяти;

•эффективность  функционирования, т. е. Обеспечение  требований ко времени реакции системы на запросы и обновления БД;

• защита данных от разрушений при сбоях оборудования от некорректных обновлений и, если необходимо, от несанкционированного доступа.

•простота и удобство эксплуатации информационной системы;

• гибкость, т. е. возможность  развития и последующей адаптации  системы к изменениям в предметной области и к новым потребностям пользователей.

Удовлетворение первых четырех требований обязательно  для принятия проекта. Последние  два требования необязательны, так  как большая или меньшая простота и удобство эксплуатации выступают  только факторами оценки альтернативных вариантов проекта.

СТРУКТУРА ПРОЦЕССА ПРОЕКТИРОВАНИЯ

Обследование предметной области. На этом этапе, после первоначального знакомства с предметной областью следует детальное изучение всех ее фрагментов, каждый из которых характеризуется локальным пользовательским представлением. Для каждого фрагмента определяются информационные объекты, анализируются процессы, их использующие, и устанавливаются явные ассоциации между информационными объектами.

Фрагменты предметной области исследуются последовательно. Причем сведения об очередном фрагменте  интегрируются с полученными при изучении предшествующих фрагментов.

 Система управления  БД – важнейший программный  компонент информационной системы,  оказывающий существенное влияние  на многие параметры системы, в том числе:

• пользовательские интерфейсы;

• эффективность функционирования;

• стоимость разработки приложений;

• стоимость эксплуатации;

• гибкость системы.

Выявление внешних  ограничений. Под внешними ограничениями  здесь понимаются ограничения среды  реализации информационной системы. Каждая среда реализации отлична от идеальной. Она содержит множество ограничений, среди которых наиболее важные для нас: технические, программные и организационные.

Технические ограничения  определяются конфигурацией вычислительной системы, параметрами функционирования её компонентов, надёжностью их работы и др.

Программные ограничения  в первую очередь подразумевают  операционную систему и языки прикладного программирования.

К организационным  ограничениям можно отнести требования к срокам разработки, имеющиеся трудовые ресурсы. Возможности по подготовке специалистов и т.п

Выделение СУБД-претендентов. Проектировщику информационной системы  в настоящее время предоставляется  достаточно большой выбор СУБД, разработанных  для разных конфигураций и типов ЭВМ.

Анализ основных параметров этих систем позволяет сразу  же отвергнуть ряд СУБД, заведомо непригодных  к использованию в разрабатываемой  информационной системе, оставив для  последующего рассмотрения несколько (не более двух-трех) систем претендентов.

На выбор СУБД-претендентов наибольшее влияние оказывает согласование ряда параметров среды реализации и  СУБД. К таким параметрам в первую очередь относятся:

• тип ЭВМ;

• операционная система;

• объемы оперативной  памяти;

• конфигурация вычислительной системы и наличие реализаций СУБД для нескольких типов ЭВМ.

Моделирование базы данных. Для каждой из выделенных СУБД моделируется база данных. Кроме определения  структуры данных и стратегии  их хранения в памяти машины, проектировщик  оценивает также затраты на разработку программного окружения базы данных и в целом на реализацию и эксплуатацию информационной системы.