Системы баз данных

Размещено на http://www.allbest.ru/

Обзор СУБД с точки зрения возможностей пользователя. Требования к СУБД

база данный память

Базой данных является представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) (Гражданский кодекс РФ, ст. 1260).

Другое определение:

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

Наиболее часто используемые отличительные признаки:

· БД хранится и обрабатывается в вычислительной системе. (Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.)

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

· БД включает метаданные, описывающие логическую структуру БД в формальном виде (в соответствии с некоторой метамоделью).

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

Классификации БД

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

Укажем только основные классификации.

Классификация БД по модели данных (примеры):

· иерархические,

· сетевые,

· реляционные,

· объектные,

· объектно-ориентированные,

· объектно-реляционные.

Реляционная модель является простейшей и наиболее привычной формой представления данных в виде таблицы. В теории множеств таблице соответствует термин отношение (реляция), который и дал название модели. Для нее имеется развитый математический аппарат - реляционное исчисление и реляционная алгебра, определены такие операции, как объединение, вычитание, пересечение, соединение и др.

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

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

Указанный недостаток снят в сетевой модели, где, по крайней мере, теоретически, возможны связи «всех со всеми» (на практике прибегают к ограничениям). Чаще всего в качестве сетевой модели называют тезаурусы по областям знаний и каталоги продукции.

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

Классификация БД по среде физического хранения:

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

· БД в оперативной памяти (in-memory databases): все данные находятся в оперативной памяти.

· БД в третичной памяти (tertiary databases): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков. Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кеш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

Классификация БД по содержимому (примеры):

· географические;

· исторические;

· научные;

· мультимедийные.

Классификация БД по степени распределённости:

· централизованные (сосредоточенные);

· распределённые.

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

Основные функции СУБД:

· управление данными во внешней памяти (на дисках);

· управление данными в оперативной памяти с использованием дискового кэша;

· журнализация изменений, резервное копирование и восстановление базы данных после сбоев;

· поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

· ядро, которое отвечает за управление данными во внешней и оперативной памяти, и журнализацию,

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

· подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

Классификации СУБД

По модели данных (примеры):

· Иерархические

· Сетевые

· Реляционные

· Объектно-ориентированные

По степени распределённости:

· Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

· Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД:

· Файл-серверные

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

На данный момент файл-серверная технология считается устаревшей.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

· Клиент-серверные

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Cache, ЛИНТЕР.

· Встраиваемые

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

В наиболее полном варианте СУБД должна иметь следующие компоненты:

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

· Алгоритмический язык для программирования прикладных систем обработки данных.

· Компилятор для придания завершенной программе вида готового коммерческого продукта в форме независимого ЕХЕ-файла.

· Программы-утилиты для быстрого программирования рутинных операций (генераторы отчетов, меню, экранов, кнопочных форм и др.).

Наличие и характер этих компонент во многом определяют технологичность работы программиста с СУБД и возможность ее использования людьми с небольшой компьютерной подготовкой.

Основные требования к готовой прикладной базе данных:

· Безопасное хранение данных, подразумевающее защиту как от сбоев и погрешностей оператора, так и от несанкционированного доступа и переноса.\

· Возможности поиска, сортировки и отбора данных по заданным пользователем признакам.

· Возможность «неквалифицированного» ввода информации в базу персоналом с минимальной компьютерной подготовкой.

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

· При необходимости - конвертация данных из других форматов и прием информации в базу.

Общая характеристика реляционной модели данных. Типы данных. Простые типы данных. Структурированные типы данных. Ссылочные типы данных.

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

Согласно Дейту, реляционная модель состоит из трех частей:

· Структурной части

· Целостной части

· Манипуляционной части

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

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

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями и добавлениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми.

Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы:

· Простые типы данных

· Структурированные типы данных

· Ссылочные типы данных

· Простые типы данных

Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы:

· Логический

· Строковый

· Численный

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

Целый, вещественный, дата, время, денежный, перечислимый, интервальный и т. д.…

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

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

· Массивы

· Записи (Структуры)

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

A={1,2…n}

называемое множеством индексов. Отображение

F:A>R

из множества A во множество вещественных чисел R задает одномерный вещественный массив. Значение этой функции для некоторого значения индекса i называется элементом массива, соответствующим i. Аналогично можно задавать многомерные массивы.

Запись (или структура) представляет собой кортеж из некоторого декартового произведения множеств. Действительно, запись представляет собой именованный упорядоченный набор элементов r_i, каждый из которых принадлежит типу T_i. Таким образом, запись r=(r₁,r₂…r_n) есть элемент множества T=T₁?T₂?…?T_n. Объявляя новые типы записей на основе уже имеющихся типов, пользователь может конструировать сколь угодно сложные типы данных.

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

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

Работая же с простыми типами данных, например с числовыми, мы манипулируем ими как неделимыми целыми объектами. Чтобы "увидеть", что числовой тип данных на самом деле сложен (является набором битов), нужно перейти на более низкий уровень абстракции. На уровне программного кода это будет выглядеть как ассемблерные вставки в код на языке высокого уровня или использование специальных побитных операций.

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

Типы данных, используемые в реляционной модели

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

С этой точки зрения, если рассматривать массив, например, как единое целое и не использовать поэлементных операций, то массив можно считать простым типом данных. Более того, можно создать свой, сколь угодно сложный тип данных, описать возможные действия с этим типом данных, и, если в операциях не требуется знание внутренней структуры данных, то такой тип данных также будет простым с точки зрения реляционной теории. Например, можно создать новый тип - комплексные числа как запись вида z=(x,y), где x ? R, y ? R. Можно описать функции сложения, умножения, вычитания и деления, и все действия с компонентами и выполнять только внутри этих операций. Тогда, если в действиях с этим типом использовать только описанные операции, то внутренняя структура не играет роли, и тип данных извне выглядит как атомарный.

Именно так в некоторых пост-реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.

Манипулирование реляционными данными

Поскольку в реляционной модели данных заголовок и тело любого отношения представляют собой множества, к отношениям, вообще говоря, применимы обычные теоретико-множественные операции: объединение, пересечение, вычитание, взятие декартова произведения. Напомним, что для двух множеств S₁ {s₁} и S₂ {s₂}результатом операции объединения этих двух множеств S₁ UNION S₂ является множество S {s} такое, что s S₁ или s S₂. Результатом операции пересечения S₁INTERSECT S₂ является множество S {s} такое, что s S₁ и s S₂. Результатом операции вычитания S₁ MINUS S₂ является множество S {s} такое, что s S₁ и s S₂³⁾. На рис. 1 эти операции проиллюстрированы в интуитивной графической форме.



Рис.1 Иллюстрация результатов теоретико-множественных операций

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

В алгебре Кодда имеется деcять операций: объединение (UNION), пересечение (INTERSECT), вычитание (MINUS), взятие расширенного декартова произведения (TIMES), переименование атрибутов (RENAME), проекция (PROJECT), ограничение (WHERE), соединение (-JOIN), деление (DIVIDE BY) и присваивание. Если не вдаваться в некоторые тонкости, которые мы рассмотрим в лекции 4, то почти все операции предложенного выше набора обладают очевидной и простой интерпретацией.

· При выполнении операции объединения (UNION) двух отношений с одинаковыми заголовками производится отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов.

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

· Отношение, являющееся разностью (MINUS) двух отношений с одинаковыми заголовками, включает все кортежи, входящие в отношение-первый операнд, такие, что ни один из них не входит в отношение, являющееся вторым операндом.

· При выполнении декартова произведения (TIMES) двух отношений, пересечение заголовков которых пусто, производится отношение, кортежи которого производятся путем объединения кортежей первого и второго операндов.

· Операция переименования (RENAME) производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены; эта операция позволяет выполнять первые три операции над отношениями с «почти» совпадающими заголовками (совпадающими во всем, кроме имен атрибутов) и выполнять операцию TIMES над отношениями, пересечение заголовков которых не является пустым.

· Результатом ограничения (WHERE) отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.

· При выполнении проекции (PROJECT) отношения на заданное подмножество множества его атрибутов производится отношение, кортежи которого являются соответствующими подмножествами кортежей отношения-операнда.

· При -соединении (-JOIN) двух отношений по некоторому условию ()образуется результирующее отношение, кортежи которого производятся путем объединения кортежей первого и второго отношений и удовлетворяют этому условию.

· У операции реляционного деления (DIVIDE BY) два операнда - бинарное и унарное отношения. Результирующее отношение состоит из унарных кортежей, включающих значения первого атрибута кортежей первого операнда таких, что множество значений второго атрибута (при фиксированном значении первого атрибута) включает множество значений второго операнда.

· Операция присваивания (:=) позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

Потенциальные (первичные) ключи. Целостность сущностей. Внешние ключи. Целостность внешних ключей

Потенциальные ключи

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

Определение 1. Пусть дано отношение . Подмножество атрибутов отношения будем называть потенциальным ключом, если обладает следующими свойствами:

1. Свойством уникальности - в отношении не может быть двух различных кортежей, с одинаковым значением .

2. Свойством неизбыточности - никакое подмножество в не обладает свойством уникальности.

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

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

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

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

Замечание. Потенциальные ключи служат единственным средством адресации на уровне кортежей в отношении. Точно указать какой-нибудь кортеж можно только зная значение его потенциального ключа.

Целостность сущностей

Т.к. потенциальные ключи фактически служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов), то значения этих идентификаторов не могут содержать неизвестные значения. Действительно, если бы идентификаторы могли содержать null-значения, то мы не могли бы дать ответ "да" или "нет" на вопрос, совпадают или нет два идентификатора.

Это определяет следующее правило целостности сущностей:

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

Внешние ключи

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

Таблица

Номер детали	Наименование детали
1	Болт
2	Гайка
3	Винт

Пример с поставщиками и поставляемыми деталями должен выглядеть следующим образом:

Таблица 1 Отношение "Поставщики"

Номер поставщика	Наименование поставщика
1	Иванов
2	Петров
3	Сидоров

Таблица 2 Отношение "Детали"

Номер поставщика	Номер детали	Поставляемое количество
1	1	100
1	2	200
1	3	300
2	1	150
2	2	250
3	3	1000

В отношении "Поставки" атрибуты "Номер поставщика" и "Номер детали" являются ссылками на ключевые атрибуты отношений "Поставщики" и "Детали", и, следовательно, являются внешними ключами. Заметим, что данные отношения свободны от недостатков, когда все данные предлагалось хранить в одном отношении. Действительно, при изменении наименования поставщика или детали, это изменение происходит только в одном месте. Если поставщик прекратил поставки всех деталей, то удаляются соответствующие кортежи в отношении "Поставки", данные же о самом поставщике остаются без изменений.

Определение 2. Пусть дано отношение . Подмножество атрибутов отношения будем называть внешним ключом, если:

Существует отношение ( и не обязательно различны) с потенциальным ключом .

Каждое значение в отношении всегда совпадает со значением для некоторого кортежа из , либо является null-значением.

Отношение называется родительским отношением, отношение называется дочерним отношением.

Внешний ключ, также как и потенциальный, может быть простым и составным.

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

Замечание. Внешний ключ, как правило, не обладает свойством уникальности. Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".

Замечание. Если внешний ключ все-таки обладает свойством уникальности, то связь между отношениями имеет тип "один-к-одному". Чаще всего такие отношения объединяются в одно отношение, хотя это и не обязательно.

Замечание. Хотя каждое значение внешнего ключа обязано совпадать со значениями потенциального ключа в некотором кортеже родительского отношения, то обратное, вообще говоря, неверно. Например, могут существовать поставщики, не поставляющие никаких деталей.

Замечание. Для внешнего ключа не требуется, чтобы он был компонентом некоторого потенциального ключа (как получилось в примере с поставщиками и деталями). Замечание. Null-значения для атрибутов внешнего ключа допустимы только в том случае, когда атрибуты внешнего ключа не входят в состав никакого потенциального ключа

Целостность внешних ключей

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

В большинстве серьезных СУБД за выполнением этих ограничений следит сама СУБД, если, конечно, пользователь явно объявил потенциальные и внешние ключи. Но, во-первых, для некоторых систем можно допустить, чтобы эти ограничения не выполнялись, а во-вторых, некоторые системы просто не поддерживают понятия целостности, например, некоторые "настольные" СУБД типа FoxPro 2.5. В этих случаях за целостностью данных должен следить сам пользователь, или программист, разрабатывающий приложение для пользователя.

Операции, могущие нарушить ссылочную целостность

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

Ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций:

· Обновление кортежа в родительском отношении.

· Удаление кортежа в родительском отношении.

· Вставка кортежа в дочернее отношение.

· Обновление кортежа в дочернем отношении.

Стратегии поддержания ссылочной целостности

Существуют две основные стратегии поддержания ссылочной целостности:

RESTRICT (ОГРАНИЧИТЬ)- не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.

CASCADE (КАСКАДИРОВАТЬ)- разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочернее отношение само может быть родительским для некоторого третьего отношения. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между кортежами родительского и дочернего отношений.

Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.

Можно рассмотреть дополнительные стратегии поддержания ссылочной целостности:

SET NULL (УСТАНОВИТЬ В NULL) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на null-значения. Эта стратегия имеет два недостатка. Во-первых, для нее требуется допустить использование null-значений. Во-вторых, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. Достоинство этой стратегии по сравнению с предыдущей в том, что она позволяет не пользоваться null-значеними. Недостатки: Во-первых, в родительском отношении должен быть некий кортеж, потенциальный ключ которого принят как значение по умолчанию для внешних ключей. В качестве такого "кортежа по умолчанию" обычно принимают специальный кортеж, заполненный нулевыми значениями (не null-значениями!). Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение потенциального ключа. Таким образом, не все кортежи родительского отношения становятся равнозначными, поэтому приходится прилагать дополнительные усилия для отслеживания этой неравнозначности. Во-вторых, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

В некоторых реализация СУБД рассматривается еще одна стратегия поддержания ссылочной целостности:

IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.

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

Базы данных. Нормализация отношений. Нормальные формы

Нормализация отношений.

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

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

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

Процесс нормализации это последовательное преобразование исходной БД к НФ, при этом каждая следующая НФ обязательно включает в себя предыдущую (что, собственно, и позволяет разбить процесс на этапы и производить его однократно, не возвращаясь к предыдущим этапам). Всего в реляционной теории насчитывается 6 НФ:

· 1-я НФ (обычно обозначается также 1НФ).

· 2НФ.

· 3НФ.

· НФ Бойса-Кодда (НФБК).

· 4НФ.

· 5НФ.

В билете я рассматриваю первые три формы.

Нормальные формы: 6 штук.

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

Первая нормальная форма (1NF)

Основные критерии:

· Все строки должны быть различными.

· Все элементы внутри ячеек должны быть атомарными (не списками). Другими словами, элемент является атомарным, если его нельзя разделить на части, которые могут использовать в таблице независимо друг от друга.

Таблица. Пример не 1NF таблицы:

Категория	Товары
Книги	Война и Мир, Азбука
Игрушки	Юла

Таблица. Исправить можно так:

Категория	Товары
Книги	Война и Мир
Книги	Азбука
Игрушки	Юла

В этом примере в одной из ячеек содержится список из двух элементов: Война и Мир, Азбука, т.е. он является не атомарным.

Методы приведения к 1NF:

· Устраните повторяющиеся группы в отдельных таблицах (одинаковые строки).

· Создайте отдельную таблицу для каждого набора связанных данных.

· Идентифицируйте каждый набор связанных данных с помощью первичного ключа (добавить уникальный id для каждой строки)

Вторая нормальная форма (2NF)

Основные критерии:

· Таблица должна находиться в первой нормальной форме.

· Любое её поле, не входящее в состав первичного ключа, функционально полно зависит от первичного ключа.

Если таблица приведена к первой нормальной форме и у нее установлен уникальный id для каждой строки, то она находится и во второй нормальной форме.

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

Например. Эта таблица находится в первой нормальной форме, но не во второй.

Таблица

Категория	Дата	Скидка	Товар
Книги	10.10.08	10,00%	PHP for dummies
Ноутбуки	11.10.08	20,00%	Acer
Книги	10.10.08	10,00%	Windows XP

В этой таблице первичный ключ составляют первые два столбца (Категория и Дата).

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

Исправляется это разделением этой таблицы на две другие:

Таблица

Категория	Дата	Скидка
Книги	10.10.08	10,00%
Ноутбуки	11.10.08	20,00%
Книги	10.10.08	10,00%

Таблица

Категория	Товар
Книги	PHP for dummies
Ноутбуки	Acer
Книги	Windows XP

Теперь эти таблицы находятся во второй нормальной форме.

Методы приведения к 2NF:

· Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям (Выше это сделано).

· Свяжите эти таблицы с помощью внешнего ключа (В примере это поле Категория).

Третья нормальная форма (3NF)

Основные критерии:

· Таблица находится во второй нормальной форме.

· Любой её не ключевой атрибут функционально зависит только от первичного ключа.

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

Таблица. Например, есть у нас таблица:

Имя шпиона	Государство
Джеймс Бонд	Великобритания
Ким Филби	СССР
Штирлиц	СССР

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

Таблица.

ID	Государство
1	Великобритания
2	СССР

Таблица.

Имя шпиона	Государство
Джеймс Бонд	1
Ким Филби	2
Штирлиц	2

Благодаря этому правилу, при удалении какого-то государства, имена шпионов не будут утеряны

Методы приведения к 3NF

· Удаление (или перенос в другие таблицы) полей не зависящих от ключа

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

Реализация реляционной алгебры средствами оператора языка SQL -- SELECT (реляционная полнота SQL)

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

Таблица.

Реляционная алгебра	Оператор SQL
· Оператор декартового произведения
	SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, … FROM A, B; или SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, … FROM A CROSS JOIN B;
· Оператор проекции
	SELECT DISTINCT X, Y, …, Z FROM A;
· Оператор выборки
	SELECT * FROM A WHERE c;
· Оператор объединения
	SELECT * FROM A UNION SELECT * FROM B;
· Оператор вычитания
	Оператор SQL: SELECT * FROM A EXCEPT SELECT * FROM B

Реляционный оператор переименования RENAME выражается при помощи ключевого слова AS в списке отбираемых полей оператора SELECT. Таким образом, язык SQL является реляционно полным.

Остальные операторы реляционной алгебры (соединение, пересечение, деление) выражаются через примитивные, следовательно, могут быть выражены операторами SQL. Остальное приведено ниже.

· Оператор соединения

Реляционная алгебра:

Оператор SQL:

SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, …

FROM A, B

WHERE c;

SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, …

FROM A CROSS JOIN B

WHERE c;

· Оператор пересечения

Реляционная алгебра:

Оператор SQL:

SELECT *

FROM A

INTERSECT

SELECT *

FROM B;

· Оператор деления

При защите этого вопроса лучше сказать, что операция деления используется редко, но её тоже можно реализовать.

Реляционная алгебра:

Оператор SQL:

SELECT DISTINCT A.X

FROM A

WHERE NOT EXIST

(SELECT *

FROM B

WHERE NOT EXIST

(SELECT *

FROM A A1

WHERE

A1.X = A.X AND

A1.Y = B.Y));

Ниже идут пояснения про деление. Как получилось вышенаписанное выражение

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

Пусть отношение A содержит данные о поставках деталей, отношение B содержит список всех деталей, которые могут поставляться. Атрибут X является номером поставщика, атрибут Y является номером детали.

Разделить отношение A на отношение B означает в данном примере "отобрать номера поставщиков, которые поставляют все детали".

Преобразуем текст выражения:

? "Отобрать номера поставщиков, которые поставляют все детали" эквивалентно

? "Отобрать те номера поставщиков из таблицы A, для которых не существует непоставляемых деталей в таблице B" эквивалентно

? "Отобрать те номера поставщиков из таблицы A, для которых не существует тех номеров деталей из таблицы B, которые не поставляются этим поставщиком" эквивалентно

? "Отобрать те номера поставщиков из таблицы A, для которых не существует тех номеров деталей из таблицы B, для которых не существует записей о поставках в таблице A для этого поставщика и этой детали".

Последнее выражение дословно переводится на язык SQL. При переводе выражения на язык SQL нужно учесть, что во внутреннем подзапросе таблица A должна быть переименована, для того чтобы отличать ее от экземпляра этой же таблицы, используемой во внешнем запросе.

Ещё о делении:

Эта операция наименее очевидна из всех операций реляционной алгебры и поэтому нуждается в более подробном объяснении. Пусть заданы два отношения - A с заголовком {a1, a2, ..., an, b1, b2, ..., bm} и B с заголовком {b1, b2, ..., bm}. Будем считать, что атрибут bi отношения A и атрибут bi отношения B не только обладают одним и тем же именем, но и определены на одном и том же домене. Назовем множество атрибутов {aj} составным атрибутом a, а множество атрибутов {bj} - составным атрибутом b. После этого будем говорить о реляционном делении бинарного отношения A(a,b) на унарное отношение B(b).

Результатом деления A на B является унарное отношение C(a), состоящее из кортежей v таких, что в отношении A имеются кортежи <v, w> такие, что множество значений {w} включает множество значений атрибута b в отношении B.

Предположим, что в базе данных сотрудников поддерживаются два отношения: СОТРУДНИКИ ( ИМЯ, ОТД_НОМЕР ) и ИМЕНА ( ИМЯ ), причем унарное отношение ИМЕНА содержит все фамилии, которыми обладают сотрудники организации. Тогда после выполнения операции реляционного деления отношения СОТРУДНИКИ на отношение ИМЕНА будет получено унарное отношение, содержащее номера отделов, сотрудники которых обладают всеми возможными в этой организации именами.

Размещено на Allbest.ru