1
Лекция №1
Название лекции: Система баз данных.
План:
1. Основные понятия: система баз данных, СУБД, основное назначение СУБД.
2. Основные компоненты системы баз данных:
2.1. Данные;
2.2. Аппаратное обеспечение;
2.3. Программное обеспечение;
2.4. Пользователи.
3. Уровни абстракции в СУБД.
1. Система баз данных, СУБД, основное назначение СУБД, функции СУБД.
Система баз данных - это компьютеризированная система хранения данных, основная
цель, которой содержать информацию и предоставлять её по требованию.
Система управления базами данных (СУБД) - программное обеспечение,
предназначенное для использования и (или) модификации этих данных одним или
несколькими лицами.
Назначение СУБД:
обеспечить пользователя инструментом, позволяющим оперировать данными в
терминах, не связанных с особенностями их хранения в ЭВМ. В этом смысле
СУБД действует как интерпретатор языка высокого уровня, предоставляя
возможность описать данные и их обработку;
обеспечить секретность и разграничение прав доступа к информации;
защита целостности и непротиворечивость данных. Например, контроль, что число
проданных билетов не превышало числа мест в самолете;
синхронизация доступа к информации при одновременном обращении нескольких
пользователей
(проблема
многопользовательского
доступа).
Например,
исключение возможности продажи двух билетов на одно и тоже место в
транспорте;
защита от отказов и восстановления состояния базы данных после отказа. При
этом под отказами подразумеваются отказы оборудования, ошибки в работе
программного обеспечения, технические ошибки персонала и т.д.
2. Основные компоненты системы баз данных.
В системе баз данных выделяют четыре основных компонента:
данные;
аппаратное обеспечение;
программное обеспечение;
пользователи.
Данные. Различают 2 типа СУДБ: однопользовательские и многопользовательские.
Основная задача многопользовательской системы обеспечить работу пользователю как в
однопользовательской системе. Мы будем рассматривать данные только в
многопользовательских системах. Данные в системе БД являются интегрированными и
общими.
Интегрированные данные подразумевают возможность представлять БД как
объединение нескольких файлов данных, полностью или частично не перекрывающихся.
Общие данные подразумевают возможность использования отдельных областей
данных в БД несколькими отдельными пользователями отдельно.
Для упрощения мы будем предполагать, что все данные хранятся в одной БД (но
возможно в нескольких файлах).
2
БД состоят из некоторого набора постоянных данных, которые используются
прикладными программами.
Обычно данные, хранящиеся в БД, называются постоянными (хотя они недолго могут
оставаться такими). «Постоянные» - по отношению к другим данным: промежуточным,
входным, выходным.
Входные данные – это информация, передаваемая системе (обычно с терминала или
рабочей станции). Такая информация может стать причиной изменения постоянных
данных.
Выходные данные – это сообщения и результаты, выдаваемые системой (обычно на
печать или отображается на экране, возможно, записывается на диски). Ясно, что
различие между видами данных нельзя назвать четкими, они определяются на
интуитивном уровне. БД состоят из некоторого набора постоянных данных, которые
используются прикладными программами.
На больших предприятиях в настоящее время все чаще используются два вида БД:
операционная БД - для поддержания повседневной работы предприятия;
база данных, содержащая отчетную информацию - данные для поддержания
принятия решений по управлению предприятием. Эти данные периодически
обновляются (раз в день, раз в неделю и т.д.), получая информацию из оперативной
БД.
Аппаратное обеспечение:
накопители;
сетевое оборудование;
оперативная память
процессор.
Программное обеспечение:
СУБД;
утилиты;
средства разработки приложений (программы конечного пользователя);
средства проектирования;
генераторы счетов и др.
Пользователи:
Прикладные программисты – пользователи, которые отвечают за написания
прикладных программ (приложений), использующих БД.
Конечные пользователи – пользователи, которые работают с базой данных
через рабочую станцию (терминал). Конечный пользователь получает
доступ к БД через приложения или используя интегрированный интерфейс
СУБД. Конечный пользователь часто использует интерфейс, основанный на
меню и различных формах, что облегчает работу.
Администраторы базы данных организуют и отвечают за работу с БД.
3.Уровни абстракции в СУБД
Абстрагирование – отбрасывание лишних элементов в моделях объектов реального
мира с выделением основных объектов и элементов. Цель любой информационной
системы – обработка данных об объектах реального мира. В широком смысле слова база
данных – это совокупность сведений о конкретных объектах реального мира в какой–
либо предметной области. Таким образом, база данных это информационная модель
предметной области. Каждый конечный пользователь должен получать возможность
взаимодействовать с информационной системой на понятном ему языке, в соответствии с
его представлением о предметной области. Представление каждого пользователя
описывает явления и объекты из предметной области лишь с некоторой точностью,
3
необходимой для его деятельности. Получается такое представление путем выделения
основных, с точки зрения пользователя, явлений, объектов, свойств и отбрасыванием
второстепенных. Процесс отвлечения от ряда свойств и отношений изучаемого явления с
одновременным выделением интересующих исследователя свойств называется
абстрагированием. Реализуется представление конечного пользователя в информационной
системе с помощью приложений. Так как обычно имеется несколько пользователей
информационной системы, то в БД должны быть реализованы несколько представлений.
Образы объектов и явлений реального мира, выделенные на основании представлений
пользователей, записываются в памяти ЭВМ в цифровом виде. При этом возникает задача
разработать такую архитектуру баз данных, которая позволила бы весь период
эксплуатации БД обеспечивать стабильное развитие и, при необходимости, простую
модификацию баз данных, разрабатываемых с помощью различных СУБД.
Следовательно, перед разработчиками архитектуры БД стояла задача, аналогичная задаче
стандартизации архитектуры компьютерных сетей. Решения этих задач также
аналогичные – использовать многоуровневую архитектуру, что позволяет развивать и
совершенствовать одни уровни БД достаточно независимо от других.
Самая жизнеспособная архитектура организации базы данных была предложена группой
ANSI/X3/SPARC Study Group, которая была организована в 1972 г. комитетом Standards
Planning and Requirements Committee (SPARC) института American National Standards
Institute on Computers and Information Processing (ANSI/X3). Эта архитектура имеет
трехуровневую систему организации базы данных.
Внешний
уровень
Концептуальный
уровень
Представле
ние 1
Представле
ние 2
Представле
ние n
Обобщенное представление
пользователей
Внутренний
(физический)
уровень
Представление
в памяти
Трехуровневая система организации базы данных
Таким образом, существуют три уровня абстракции в архитектуре базы данных:
представление (внешняя модель базы данных);
концептуальная база данных (КБД);
физическая база данных (ФБД).
При проектировании базы данных процесс перехода
информационной модели происходит в несколько этапов:
от
реальности
к
4
1. Внешняя модель или уровень представления. На этом уровне предметная область
(т.е. та область деятельности, в которой осуществляется разработка данной системы)
описывается будущим пользователем БД. Каждый пользователь описывает свое
представление о предметной области. При этом, описывается: какие объекты важны в
работе пользователя, какими свойствами они обладают, связи между объектами, прочие
правила взаимодействия объектов.
2. Логический или концептуальный уровень. На этом уровне прикладными
программистами разрабатывается обобщенное описание предметной области, которое
опирается на представления пользователей. В логической модели используются один из
формальных языков. Выбор языка определяется моделью, используемой в СУБД. Это
может быть, например:
язык, описывающий деревья (иерархическая модель);
язык сетей, как класса графов (сети, сетевая модель).
язык отношений (реляционная модель);
ER – модели, как вариант языка сетевой модели.
3. Внутренний либо физический уровень. Описание модели (концептуальной) на языке
некоторой СУБД.
СУБД должна поддерживать все три уровня. При этом внешний уровень обычно
поддерживается приложениями, написанными возможно на различных языках
программирования. Этот уровень связан со способами представления данных для
различных
пользователей.
Концептуальный
уровень
является
обобщенным
представлением всех пользователей. Может быть несколько внешних представлений,
каждое из которых состоит из представления определенной части базы данных, но может
быть только одно концептуальное представление, состоящее из абстрактного
представления базы данных в целом. Также есть единственное внутреннее представление,
отражающее базу данных как физически хранимую. При использовании реляционной
модели концептуальный уровень будет определенно реляционным. Внешнее
представление, в этом случае, также будет реляционным или близким к нему. На
внутреннем же уровне используются структуры, которые не должны быть связаны с
используемой в СУБД моделью данных.
Разработка внешних представления и концептуальной модели является ядром
проблемы проектирования базы данных. В процессе проектирования активно
используются языки моделей данных СУБД и понятия из предметной области. Для
реализации базы данных СУБД должна иметь средства как определения и поддержки базы
данных на всех уровнях, так и развитые интерфейсы для обеспечения взаимодействия
всех трех уровней между собой. Последние интерфейсы называют отображениями одного
уровня архитектуры на другой.
5
Лекция №2
Название лекции: Схемы и экземпляры БД.
План:
1. Основные понятия: план, экземпляр БД, хранимое поле, хранимая запись.
2. Схемы уровня представлений.
3. Модели типа объект/отношение. (Понятие ER-модель):
3.1. Особенности модели и ее недостатки;
3.2. Общий подход и проблемы;
3.3. Виды связей;
3.4. Диаграммы объектов / связей.
3.5. Пример диаграммы
1. Основные понятия: план, экземпляр БД, хранимое поле, хранимая запись.
На стадии проектирования БД разработчики имеют дело с планом БД. На стадии
эксплуатации мы имеем дело с содержащимися в базе данных актуальными данными.
Данные в БД при эксплуатации часто изменяются. Планы меняются значительно реже.
План - перечень типов объектов, относящихся к БД и связей между ними. Иногда план
называют схемой.
Речь может идти о концептуальной схеме или физической. Схемы уровня
представлений – обычно являются частями (подсхемами) концептуальной схемы.
Экземпляр БД – это совокупность информации, содержащейся в БД в каждый момент
времени.
Для описания схем и экземпляров используют следующие понятия:
Хранимое поле – это наименьшая единица хранимых данных. БД может содержать
много экземпляров одного из нескольких типов полей (ФИО, №Детали).
Хранимая запись – это набор связанных хранимых полей, рассматриваемых как одно
целое. Экземпляр записи состоит из группы связанных экземпляров хранимых полей.
Пример:
запись о детали (номер, название, вес, цвет и т.д.).
Хранимый файл – это набор записей всех экземпляров хранимых записей одного типа
(предполагаем, что в файле хранятся записи только одного типа).
2. Схемы уровня представлений.
Схемы уровня представлений могут быть частями концептуальной схемы. В
некоторых случаях схемы представления могут быть более “абстрактными” чем
концептуальные.
Пример: для отдела кадров поддерживается представление, которое включает возраст
каждого сотрудника. Поддерживать возраст на концептуальном уровне не целесообразно,
т.к. изменять соответствующее хранимое поле необходимо ежедневно для всех
сотрудников. Гораздо более целесообразно хранить дату рождения, а возраст вычислять
как разность между текущей датой и датой рождения.
Для получения схем представлений используют различные подмножества
(ассоциации) из некоторой схемы, однако в некоторых случаях встречаются исключения.
Пример: в концептуальной схеме БД авиарейсы могут рассматриваться как множество
пассажиров, в тоже время в представлении службы продажи билетов пассажир может
рассматриваться как некоторое множество рейсов, на которые у пассажира есть билеты.
Т.е. представление и концептуальная схема совсем не обязательно должны
определяться с помощью одной и той же модели данных. Но чаще всего в обоих случаях
применяется одна и та же модель.
3. Модели типа объект/отношение. (Понятие ER-модель).
6
Модели БД типа объект/отношение могут быть использованы на всех уровнях
абстракции.
Особенности модели. Ее преимущества и недостатки.
Особенностью модели является тесная логическая связь с предметной областью.
Данная модель относится к так называемым семантическим моделям. Преимущество:
проще описывать условия целостности. Недостаток: сложно проводить формальную
оптимизацию информационной модели, т. к. тесная логическая связь с предметной
областью не дает разработчику отвлечься от ее особенностей.
Общий подход и проблемы. Для того чтобы описать представление предметной области
необходимо задать множество объектов реального мира. Объект – семантическое понятие,
которое может быть полезно при обсуждении устройства реального мира. Т.е. нечто
существенное, полезное для описания предметной области. Можно дать другое
определение: объект это сущность реального мира. Объекты – не обязательно должны
быть материальными. Важным является только существенность и различимость каждого
объекта от других.
Пример: объектами являются: сотрудник, пассажир, самолет, деталь и т.д.
Различают сильные и слабые объекты. Слабый объект подчиняется другому объекту и
не может без него существовать. Объект, не являющийся слабым, называется сильным.
Пример: подчиненный сотрудник основной сотрудник.
Различают тип объекта и экземпляр объекта
Пример: тип – сотрудник; экземпляр – Иванов.
Объект обладает рядом свойств, которые иногда называют атрибутами объекта.
Различают тип атрибута и значение атрибута. В информационной модели объект
представляется значениями своих атрибутов. Совокупность значений атрибутов объекта
является его информационной моделью.
Пример: объект — сотрудник, его атрибуты: ФИО, дата рождения...
Для определения нового типа объекта иногда используют понятие подтипа. Например,
пилот – есть подтип объекта сотрудник. Пилот обладает всеми свойствами сотрудника и,
кроме того, свойством - список разрешенных для управления самолетов. Очевидно, что
механизм подтипов является прообразом наследования из ООП.
Атрибуты или множество атрибутов значения, которых уникальным образом
идентифицируют экземпляр объекта, называют ключом. Иначе говоря: не существует
двух различных объектов, у которых совпадают значения ключей. Т.к. все экземпляры
объекта в реальной жизни различимы, должны быть различимы экземпляры одного типа
объектов. Следовательно, любые два экземпляра объектов одного и того же типа должны
различаться значениями хотя бы одного атрибута. Следовательно, каждый тип объекта
должен иметь ключ.
Пример: объект студент, ключ – номер зачетной книжки.
Виды связей. Между объектами могут возникать связи.
Пример: между объектами деталь и поставщик может возникнуть связь –
деталь_поставляется_поставщиком (для каждого экземпляра поставщика ставится в
соответствие список деталей, которые он поставляет).
Связь является отношением, т.е. подмножеством прямого произведения, но не
обязательно это бинарное отношение (поставщик – детали). Возможна связь (отношение)
связывающая экземпляры одного и того же типа объектов. (Например, между
экземплярами объекта деталь может существовать связь – список деталей,
образующих данную деталь).
Рассмотрим виды связей на примере базы данных «Хирургическое отделение
больницы». Выделим четыре типа объектов: Место_в_палате, Палата, Пациент, Хирург.
Между объектами могут возникать следующие связи:
один к одному 1:1 (Пациент - Место_в_палате);
7
один к многим 1:n, или, как вариант - многие к одному n:1 (Палата Место_в_палате);
многие к многим n:n (Пациент - Хирург).
Диаграммы объектов / связей. Диаграмма – графическое изображение структуры БД
с использованием ER-модели.
Объект -
Связь-
Атрибут -
Пример . ER- диаграмму рассмотрим на примере БД аэропорта.
Связи :
А – пассажир купил билет
В – выполняется
С – есть
D – допущен к
Е – типа
F – назначен на
8
Лекция №3
Название лекции: Концептуальная схема и её модели данных.
План:
1. Значение концептуальной схемы. Язык описания концептуальных схем.
2. Модели, которые используются для описания концептуальных схем:
2.1. Иерархическая модель;
2.2. Сетевая модель;
2.3. Реляционная модель;
2.4. СУБД, использующих другие модели.
1. Значение концептуальной схемы. Язык описания концептуальных схем.
Выбор концептуальной схемы является центральным пунктом в разработке баз
данных. Концептуальные схемы оказывают существенное влияние на способы описания
схем уровня представлений и физических схем.
Для определения базы данных на концептуальном уровне СУБД предоставляет так
называемый язык определения данных (DDL - data definition language). Этот язык
позволяет записать концептуальную схему в терминах некоторой модели данных. В
качестве модели данных может быть выбрана, например, модель объектов/отношений.
Преимущество и недостатки этой модели рассмотрены выше. Основными понятиями этой
модели являются понятия объект, атрибуты (свойства), отношения (связи).
Приведенный выше пример БД аэропорта является фактически концептуальной
схемой БД в терминах модели объекты/отношения.
В нашей стране не распространены СУБД, поддерживающие эту модель. Но
преимущества модели, обусловленные тесной семантической связью с предметной
областью, позволяет с высокой вероятностью построить качественную схему БД. Ясно,
что для реализации такой схемы необходимо отобразить схему объект/отношение на
модели, которые используются в выбранной СУБД.
2. Модели, которые используются для описания концептуальных схем:
В настоящее время хорошо разработаны и описаны три основных модели, которые
используются в системах БД:
Иерархическая модель. Моделью данных здесь является древовидный граф, т.е.
связанный, ориентированный граф без циклов, у которого имеется только одна вершина,
из которой дуги только выходят и ни одна дуга не входит. Эта вершина называется
корнем дерева. Вершина, в которую дуги только входят, называется листом. Все
остальные вершины
- корни. Вершина, для некоторой вершины А, называется
родительской, если из родительской вершины начинается дуга и заканчивается в А.
Братья это множество вершин имеющих одного родителя.
Типичным представителем СУБД, в которой реализована иерархическая модель,
является СУБД IMS фирмы IBM (INFORMATION MANGMENT SYSTEM) середина 60-х
годов. Эта СУБД официально считается вообще первой реализованной СУБД.
Распространение этого типа СУБД объясняется простотой и наглядностью используемой
модели, которая широко распространена в различных областях деятельности человека и в
природе (государство, армия, предприятия, стая и т.д.). Недостатком этой СУБД является
сложность реализация связей n:n(многие к многим).
Сетевая модель. Это модель ориентированных графов, вершинами которых является
множество однородных объектов, а дугами – ассоциации (связи). Ясно, что модель
объект/отношение является примером сетевой модели.
Теоретические основы модели разработаны независимой ассоциацией CODASYL, как
обобщение иерархической модели и опыта эксплуатации информационных систем.
Ассоциация образованна в конце 50–х годов и финансировалась Пентагоном с целью
9
разработки алгоритмического языка, ориентированного на экономические задачи (COBOL
– Common Bisnes Oriented language). Разработчикам этого языка принадлежит ряд
пионерских решений в области разработки алгоритмических языков и в частности языков
для обработки информации. Это:
прозрачность текста программы для неспециалиста (синтаксис близкий к обычному
языку, длинные идентификаторы, выражения и операции типа «умножить
количество на цену получая сумму» {как совокупность разных типов});
понятие структуры (как тип в языке программирования);
стандартизация и упрощение методов доступа к файлу.
Язык COBOL считается прототипом (предшественником) СУБД. В конце 60-х годов в
рамках CODASYL была организованна рабочая группа по базам данных (Data Base Task
Group - DBTG), отчеты которой за 1969...75 годы являются основной теорией БД и в
частности сетевых БД. Так DBTG предложило ввести три уровня абстракции, этот подход
был позже стандартизован институтом стандартов US (ANSI) и известен как архитектура
ANSI/SPARC. Большинство теоретических разработок группы DBTG были
стандартизованы.
Известны несколько СУБД сетевой структуры: CA-IDMS/BD компания Computer
Associates International Inc, в СССР – ИНЕС.
Реляционная модель. Базируется на теоретико - множественном понятии отношения.
Модель разработана американским математиком Коддом (Codd), сотрудником фирмы
IBM и опубликована в 1970 г. В настоящее время является наиболее полно разработанной
основой теории БД. В настоящем курсе будет рассмотрена теория реляционных БД.
Примеры реляционных СУБД: DB/2 фирмы IBM, ORACLE корпорация Oracle,
SYBASE компания Sybase Inc. К реляционным относятся свободно распространяемые
СУБД : MySQL и PostgreSQL.
Из СУБД, использующих другие модели, следует упомянуть, прежде всего, СУБД с
использованием инвертированных файлов (инвертированных списков).
В настоящее время ведутся в направлении так называемых «постреляционных» СУБД.
Назовем некоторые из них:
дедуктивные СУБД;
экспертные СУБД;
расширяемые СУБД;
объектно-ориентированные СУБД;
семантические СУБД;
универсальные реляционные СУБД.
Лекция №4
1
0
Название лекции: Внутренняя (физическая) схема БД.
План:
1. Внутренняя (физическая) схема БД.
2. Соотношение внутреннего и внешнего языка определения данных. Язык SQL. Сильно
связанные и слабо связанные языки.
1. Внутренняя (физическая) схема БД.
Третьим уровнем архитектуры ANSI/SPARC является внутренний уровень.
Внутренний (физический) уровень (внутреннее представление) описывает размещение БД
на устройствах внешней памяти. Сама по себе физическая БД может быть представлена на
нескольких уровнях абстракции от записей и файлов в языках программирования до
уровня цилиндров, дорожек, блоков, байтов и бит, хранимых на внешних устройствах.
Заметим, что физическая организация файлов определена файловой системой OS, под
управлением которой работает СУБД и в настоящем курсе не рассматривается, но полное
игнорирование при проектировании БД физической организации файлов может
существенно снизить производительность и эффективность СУБД. Поэтому мы будем
рассматривать физическую организацию файла на уровне некоторой модели (абстракции)
реальной реализации, предполагая внешнюю память как бесконечное линейное адресное
пространство. Линейное в том смысле, что для указания адреса внешней памяти
достаточно указать одно число (это соответствует понятию кластера файловой системы).
На самом деле адресация памяти на дисках трехмерна: цилиндр, трек, сектор. Итак, мы не
будем исследовать уровни абстракции внутреннего представления. Будем рассматривать
внутреннее представление на уровне, эквивалентном записям и файлам языка
программирования.
Внутреннее представление, в таком случае, описывается внутренней схемой, которая
определяет различные типы хранимых записей, способ представления хранимых полей,
физическую последовательность хранимых записей, способы получения различных
логических последовательностей записей.
2. Соотношение внутреннего и внешнего языка определения данных.
Внешний уровень – это индивидуальный уровень пользователя. К пользователям
относятся конечные пользователи и прикладные программисты. Особую роль играет
администратор БД, который участвует в разработке всех уровней представлений. У
каждого пользователя есть свой язык общения с БД:
для конечного пользователя это, или специальный язык запросов, или язык
специального назначения, возможно основанный на формах и меню, созданный
прикладным программистом с учетом требований пользователя и поддерживаемый
некоторыми приложениями;
для прикладного программиста это либо один из распространенных языков
программирования, такой как С, либо специальный язык рассматриваемой СУБД.
Как для конечного пользователя, так и для прикладного программиста используемые
языки включают подъязыки данных, т.е. подмножество операторов всего языка, связанное
только с объектами и операциями с БД. Т.о. подъязык встроен в базовый язык, который
имеет ещё операторы, не связанные с БД (if, while и т.д.).
СУБД может поддерживать любое количество базовых языков и любое количество
подъязыков данных.
В настоящее время существует один язык, который поддерживается практически
всеми СУБД это язык SQL (Structured Query Language).
Базовый язык и включенный в него подъязык данных могут быть практически
неразличимыми (например, SQL – как самостоятельный язык). Если они неразличимы
1
1
или трудно различимы, их называют сильно связанными. Если они легко различаются, то
говорят, что они слабо связанны.
СУБД с сильно связанными языками сложнее разработать, но очевидна существенная
тенденция продвижения к более сильно связанным системам. Подъязык данных на самом
деле является комбинацией двух языков: языка определения данных (data definition
language - DDL), который поддерживает объявление или определение объектов БД, и
языка обработки данных (data manipulation lаnguage - DML), который поддерживает
операции с такими объектами или их обработку.
Внешние и внутренние языки могут совпадать или не совпадать.
Пример: для прикладного программиста – это язык С + SQL. Внутренняя схема
описана на С, а запросы на SQL. В этом случае внутренний и внешний языки не
совпадают. Если внутренняя схема описана на SQL и запросы на SQL, то
языки совпадают. Для конечного пользователя совпадение языков крайне редко
(продвинутые пользователи). Обычно внешний язык – язык меню, внутренний, или
специальный языки (FoxPro, C), или SQL. Но иногда продвинутые пользователи
общаются с СУБД на языке SQL и, если внутренний язык также SQL, то это соответствует
совпадению языков.
Лекция №5
1
2
Название лекции: Независимость данных. Администратор баз данных.
План:
1. Понятие независимости данных.
2. Уровни абстракции архитектуры СУБД: физическая и логическая независимость
данных.
3. Администратор баз данных. Логическое проектирование БД. Список функций
администратора БД при совмещении им функций системного аналитика.
1. Понятие независимости данных.
Основное, качественное отличие СУБД от предшествующих систем обработки
информации является независимость данных. Для предшествующих систем сведения об
организации данных и способах доступа к ним были встроены в логику и код приложения.
Если, по каким-то причинам, необходимо было изменить структуру записей или способ
доступа к файлу с информацией, то для приложений, не использующих технологию
СУБД, необходимо было переписать приложения (программы).
СУБД построены таким образом, чтобы обеспечивать развитие БД, не оказывая
существенного влияния на приложения.
2. Уровни абстракции архитектуры СУБД.
Три уровня абстракции в структуре СУБД, внешний – концептуальный – внутренний,
обеспечивают два уровня независимости данных.
Первый
уровень
независимости
данных
обеспечивается
отображением
концептуального уровня на внутренний (физический) уровень и называется физической
независимостью данных. Это отображение описывает, как концептуальные записи
представлены на внутреннем уровне. Так как, отображение описывается в файле с
информацией, то при изменении внутренней структуры хранимой базы, изменяется и
отображение концептуальный – внутренний так, чтобы концептуальная схема осталась не
изменой.
Пример: некоторое приложение работает с хранимым файлом, в котором описаны два
поля «А» и «В». Если этот файл заменить на другой, в котором хранимые поля
переставлены местами («В» и «А»), то это изменение структуры записи хранимого файла
не приведет к нарушению работы данного приложения.
Пример: изменение размеров полей не приводит к нарушению работы ранее
написанных приложений.
Второй вид независимости обеспечивается отображением внешний – концептуальный
и называется логической независимостью данных. Отображение внешний –
концептуальный определяет соответствие между некоторым внешним представлением и
концептуальной схемой. По мере использования БД может потребоваться модификация
концептуальной схемы, например, с целью включения информации о новых типах
объектов или дополнительной информации об уже представленных в ней объектах.
Пример: требуется информация об уровнях шума и загрязнении атмосферы на
авиарейсах компании. Если таких сведений в базе данных нет, то возможно включение в
БД сведения о шуме и загрязнении каждого самолета, без перестройки уже разработанных
приложений.
Некоторые модификации концептуальной схемы можно выполнить, не затрагивая
существующих представлений. Другие модификации становятся возможными, если
переопределить отображение схемы уровня представлений на концептуальную схему. При
этом не требуется каких-либо изменений в существующих приложениях (прикладных
программах). Единственный вид изменений в концептуальной схеме, который не может
быть осуществлен путем переопределения соответствия между схемой представления и
1
3
концептуальной схемой, это удаление информации из концептуальной схемы,
соответствующей представленной во внешней схеме (схеме представлений). Такие
изменения обычно требуют переработки приложений или отказ от некоторых программ.
3. Администратор баз данных.
Для реализации большой БД важную роль играют два специалиста: администратор
данных (системный аналитик) и администратор БД. Иногда функции этих специалистов
совмещаются в одном лице.
Администратор данных (системный аналитик) – это специалист, отвечающий за
стратегию и политику принятия решений, связанных с данными предприятия на уровне
представлений. Он определяет, какие именно данные необходимо сохранять в БД.
Определяет объекты, в которых заинтересовано предприятие, а также информацию,
которую необходимо записывать об этих объектах. Этот процесс иногда называют
логическим проектированием БД. При этом осуществляется тесное взаимодействие с
конкретными пользователями и формализация схем уровня представлений. Для
выполнения этой работы необходим специалист знакомый с предметной областью (или
способный освоить любую предметную область) и одновременно знакомый с законами и
принципами программирования. Часто этот специалист уже на уровне разработки
представлений может дать совет по повышению эффективности работы предприятия и на
западе называется системным аналитиком (человек способный проанализировать
систему).
Администратор БД – это специалист, обеспечивающий необходимую техническую
поддержку реализации логического проектирования. Приведём список функций
администратора БД при совмещении им функций системного аналитика:
1) Создание схем представлений.
2) Определение концептуальной схемы с помощью концептуального языка определения
данных. При этом используется одна из 3-х моделей концептуального уровня.
3) Определение внутренней схемы (физическое представление) с использованием
внутреннего языка определения данных. Определение соответствия между внутренней
и концептуальной схемами.
4) Взаимодействие с пользователями:
- предоставления пользователям полномочий на использование БД или её частей;
- помощь пользователям в разработке схем представлений;
- определение соответствия между схемами представления и концептуальной схемой;
- консультации по разработке
приложений (для прикладных программистов)
обеспечение технического образования, помощь в выявлении и решении
возникающих проблем.
5) Определение правил безопасности и целостности. Т.е. описание условий
непротиворечивости и ограничений в доступе к файлам БД.
6) Определение процедур резервного копирования и восстановления информации после
аппаратных или программных сбоев.
7) Управление производительностью и реагирование на изменяющиеся требования:
- модификация реализации концептуальной схемы внутренней (физической), если
сведения об использовании БД показывают, что другая организация была
бы более эффективной;
- модификация концептуальной схемы с целью устранения недостатков
первоначального проекта, или в связи с изменением требований предприятия.
Лекция №6
1
4
Название лекции: Функции СУБД.
План:
1. Этапы работы СУБД.
2. Функции СУБД.
1. Этапы работы СУБД.
СУБД– представляет собой программное обеспечение, которое управляет доступом к
БД. Это происходит следующим образом:
1) Пользователь выдаёт запрос на доступ, применяя определенный подъязык данных,
например SQL.
2) СУБД перехватывает и анализирует запрос.
3) СУБД строит преобразование внутренний – концептуальный и внешний –
концептуальный.
4) СУБД выполняет необходимые операции над хранимой БД.
2.
Функции СУБД
1) Определение данных.
СУБД должна допускать определение данных (внешние схемы, концептуальную
схему, внутреннюю схему, а также все связанные отношения). Описания должны быть
произведены на некотором исходном языке и СУБД должна преобразовать эти
описания в форматы соответствующих компонент БД (т.е. включать обработку
синтаксиса языка определения данных).
2) Обработка данных.
СУБД должна обрабатывать запросы пользователей на выборку, изменение, удаление
существующих данных в БД или на добавление новых данных. Т.е. СУБД должна
включать в себя компонент процессора языка обработки данных.
Замечание: Запросы языка обработки данных бывают планируемые и непланируемые.
Планируемый запрос – это запрос, необходимость которого предусмотрена заранее.
Администратор БД, возможно, должен настроить физический проект БД таким
образом, чтобы гарантировать достаточное быстродействие для таких запросов.
Непланируемый запрос – это специальный запрос, необходимость которого не была
предусмотрена заранее. Возможность эффективной реализации такого запроса может
быть предусмотрена в физической реализации БД.
Получение наибольшей производительности для непланируемых запросов
представляет собой одну из проблем. Планируемые запросы обычно осуществляются
из написанных заранее приложений, а непланируемые формируются интерактивно.
3) Безопасность и целостность данных.
СУБД должна контролировать пользовательские запросы и пресекать попытки
нарушения правил безопасности и целостности, определенных Администратором Базы
Данных.
4) Восстановление данных и дублирование.
СУБД, или другой связанный с ней программный компонент, должен осуществлять
необходимый контроль над восстановлением данных и дублированием.
5) СУБД должна обеспечить функцию словаря данных.
Словарь данных является базой данных, но не пользовательской, а системной. Словарь
данных содержит данные о данных (так называемые метаданные), т.е. определения
других объектов системы. В словаре, например, могут храниться определения
1
5
различных схем (внешней, концептуальной, внутренней), отображения схем и другая
информация.
6) Обеспечение производительности.
Очевидно, что СУБД должна выполнять все указанные функции с максимально
возможной производительностью.
Итак, кратко можно сказать, что назначение СУБД в предоставлении
пользовательского интерфейса с БД. Это интерфейс можно рассматривать как границу в
системе, ниже которой всё невидимо для пользователя. Следовательно, пользовательский
интерфейс находится на внешнем уровне. Хотя встречаются случаи, когда внешнее
представление практически не отличается от относящейся к нему части концептуальной
схемы.
Лекция №7
1
6
Название лекции: Введение в теорию реляционных СУБД.
План:
1. Основные термины и понятия реляционных БД.
2. Основные реляционные операции
3. Правила Кодда
1) Основные термины и понятия реляционных БД.
Перед рассмотрением правил Кодда приведём основные термины и понятия
реляционных БД.
Объект – сущность предметной области.
Атрибут
(имя Атрибута, реквизит) – параметр объекта предметной
области. (Свойство некоторой сущности).
Пример: Фамилия, Возраст – свойства объекта сотрудник.
Домен (атрибута) – множество допустимых значений, которые может
принимать атрибут.
Пример: значение атрибута Возраст должно принадлежат интервалу [18…80]
Схема отношения – конечное множество [имен] атрибутов, определяющих объект.
(Мощность схемы отношения = арности кортежей.)
Отношение – конечное множество кортежей (подмножество прямого произведения),
составленных из допустимых
атрибутов
схемы
Фамилия Должность Возраст Схема отношения значений
отношений.
Иванов
Директор
40
Отношение
Петренко Бухгалтер 35
Кортеж
Петров
Менеджер 36
Значение атрибута
Сидоров Инженер
27
Ключ (первичный ключ) – множество атрибутов,
значение которых
уникальным образом идентифицирует кортеж в отношении. Это означает, что для
любого содержания отношения никакие два различных кортежа не могут иметь одно и
тоже значение атрибутов ключа
Схема реляционной базы – множество используемых в приложениях схем отношений.
Реляционная база данных (РБД) – множество отношений (предполагается, что
отношения логически связаны между собой).
Реляционные операции – операции над отношениями. Результатом любой реляционной
операции является также отношение.
Реляционное выражение – выражение над отношениями, составленное из
реляционных операций. Реляционное выражение – тоже отношение.
Реляционный запрос – описание свойств (условий), которые должны удовлетворять
интересующие пользователя данные.
Эквивалентной формой описания запроса является реляционное выражение.
СУБД – набор программных средств, обеспечивающих хранение и обработку данных в
базе. Взаимодействие прикладной программы с базой данных выполняется через СУБД.
Приложение взаимодействует с СУБД на некотором языке.
Язык описания данных (ЯОД, DDL) – язык, позволяющий описать структуру БД и
создать БД с требуемой структурой.
Язык манипулирования данными (ЯМД, DML) – язык, позволяющий описать действия
по чтению, добавлению, обновлению и удалению данных в БД.
1
7
Язык запросов – часть языка манипулирования данными, предназначенный для
удобного определения сложных реляционных запросов.
Целостность базы данных – свойство БД, при наличии, которой БД содержит полную
и непротиворечивую информацию, необходимую и достаточную для корректного
функционирования приложений.
Ограничения целостности – набор условий, определяющие целостность базы данных.
Различают ограничения диапазонов возможных значений атрибутов и структурные
ограничения (т.е. ограничения на кортежи, имеющиеся в отношениях).
Примером
ограничения
диапазонов
является
определение
доменов
атрибутов. Примером структурного ограничения является определение ключей.
Транзакция – неделимая операция по изменению содержания БД. Выполнение
транзакции завершается двумя способами:
отмена транзакции (возврат в предыдущее состояние);
регистрация транзакции: проверка и, при необходимости, восстановление
целостности БД.
Итак, до и после выполнения транзакции база данных гарантированно находится в
целостном состоянии. В течение выполнения транзакции целостность базы данных
не контролируется.
Защита баз данных – это:
защита БД от физических и логических разрушений;
обеспечение санкционированного доступа к данным.
Разрушенная база данных не обладает целостностью и требует восстановления.
Каждый пользователь может иметь свои санкции для доступа к базе данных (свою
видимую область БД, свои права на выполнение каждой из операций над
данными). Для предотвращения физического доступа к данным используется
хранение закодированных данных. Кодирование и декодирование автоматически
выполняется СУБД незаметно для приложений и пользователей.
2) Основные реляционные операции
Операция объединения (соединения) – объединение множества кортежей двух
отношений в одно общее отношение. Операция определена для двух отношений
одинаковой арности.
Пусть R и S – отношения арности n.
Объединение RS = { (V1,V2 … Vn) │(V1…Vn)R (V1 … Vn)S }
Операция разности отношений – разностью двух отношений арности n называется
отношение (арности n), в которую включены кортежи первого отношения, не
принадлежащие одновременно второму отношению.
Пусть R и S – отношения арности n.
Разность: R – S = { (V1 … Vn) | (V1 … Vn)R (V1 … Vn)S}
Операция декартового произведения – двух отношений R (арности n), и S (арности m)
называется отношение арности m+n, кортежи которого составлены из кортежей R и S.
Пусть R – отношение арности n, S – отношение арности m.
Декартовое произведение для R= {(V1 … Vn)} и S= {(W1 … Wm)} это:
RхS = {(V1…Vn, W1…Wm) │ (V1…Vn)R(W1…Wm)S}
Операция
проекции
–
это
унарная
операция,
заключающаяся
в
проецировании отношения на заданную схему (отношения). Схема проецирования
получается из схемы исходного отношения, удалением ряда атрибутов и (или)
перестановкой атрибутов исходной схемы.
Пусть R – отношение арности n, обозначим πi1,i2…im (R) – проекцию R на атрибуты i1, i2,
…im, где 1 ≤ ij ≤ n, 1 ≤ j ≤ m
Проекция: πi1,i2…im (R) = {(a1 … am) | (b1 … bn) R | aj = bij j = 1 … m }
1
8
Пример: проекция π2,1(R) – составлена из значений второго и первого элемента схемы
отношения R.
Операция селекции – это унарная операция над отношением, заключающаяся в выборе
из этого отношения множества кортежей, удовлетворяющих заданному условию.
Пусть F (предикат на множества атрибутов) – логическая формула, в которую входят:
константы;
имена атрибутов;
функции;
операции арифметических отношений <, >, ≤, ≥≠, =;
логические операции ,,¬.
Селекцией отношения R по формуле F – это отношение: δF(R )={(V1…Vn)R| F≡1}
Естественное соединение.
Пусть отношение А имеет атрибуты{X1, X2…Xm, Y1, Y2…Yn}, а отношение В {Y1,
Y2…Yn, Z1, Z2, …Zk}.
Атрибуты Y1, Y2 … Yn, и только они являются общими для этих отношений. Пусть
атрибуты с одинаковыми именами определены на одних и тех же доменах.
Для простоты множества атрибутов обозначим буквами: X,Y,Z
Естественным соединением А и В (A Join B) называется отношение с атрибутами X,
Y, Z, состоящими из кортежей (x, y, z), таких, для которых в отношении А атрибуты
X=xY=y, при этом в отношении В атрибуты Y=yZ=z.
(A Join B) JoinС = A Join (B Join C)
Пример: А = {код, имя, статус, город} – поставщики, В = {номер, вес, город} – детали
Отношение A:
Код
1
2
3
4
5
Имя
Иванов
Петров
Сидоров
Семенов
Конкин
Статус
20
10
30
20
30
Город
Москва
Казань
Казань
Москва
Новгород
Отношение В:
Номер
1
2
3
4
5
6
Вес
12
17
17
14
12
19
Город
Москва
Казань
Ростов
Москва
Казань
Москва
Отношение A Join B:
Код
1
1
1
2
2
3
Имя
Иванов
Иванов
Иванов
Петров
Петров
Сидоров
Статус
20
20
20
10
10
30
Город
Москва
Москва
Москва
Казань
Казань
Казань
Номер
1
4
6
2
5
2
Вес
12
14
19
17
12
17
Сидоров
Семёнов
Семёнов
Семёнов
3
4
4
4
Казань
Москва
Москва
Москва
30
20
20
20
5
1
4
6
12
12
14
19
Другие примеры операций над отношениями:
R:
A
B
C
a
B
С
d
A
F
c
B
D
S:
D
E
F
b
G
A
d
A
F
R S:
a
d
c
b
С
F
D
F
B
A
B
G
Схему необходимо выбрать дополнительно
R – S:
a
c
B
B
C
D
RS
A
a
d
c
a
d
c
B
B
A
B
B
A
B
C
C
F
D
C
F
D
D
b
b
b
d
d
d
A,C (R):
A
a
d
c
C
с
f
d
E
g
g
g
a
a
a
F
a
a
a
f
f
f
1
9
δB=b (R )
A
a
c
B
B
B
2
0
C
c
d
3) Правила Кодда (требования к реляционным БД)
Большинство СУБД, распространённых на ПК, принято считать реляционными, хотя
они таковыми не являются в полной мере. Кроме представления данных в виде двумерных
таблиц, принадлежность к разряду реляционных систем определяется рядом признаков,
сформулированных Коддом, получивших название правил Кодда.
Перечислим эти правила:
1) Явное представление данных.
Все данные должны быть представлены явно и их значения должны рассчитываться
косвенными алгоритмами (исключение – однозначные отображения).
Пример: если, явно не указан пол, то его нельзя (ошибочно) получать из фамилии, т.к.
различные алгоритмы интерпретации фамилии в различных приложениях могут вызвать
противоречия (нарушить целостность) в БД. Для явного представления нужны типы:
числа, строки, даты, время и т.д.
2) Гарантированный доступ к данным.
Вся информация в БД должна быть доступной для приложения. Выделение любого
значения в РБД выполняется при указании:
а) имени отношения;
б) указателя на кортеж (например, значение первичного ключа кортежа);
в) имени атрибута;
( имя_отношения, первичный ключ, атрибут)
3) Полная обработка неопределенных значений.
Неопределенные значения, отличные от любого определенного значения, должны
поддерживаться для всех типов данных при выполнении всех операций.
4) Доступ к базе данных в терминах реляционной модели.
Описание БД (перечень отношений, определения схем отношений и ключей,
статистическая информация и т.д.) должно быть выполнено на реляционном языке.
Пользователь должен иметь доступ к этой информации с помощью реляционного языка.
Т.е. должна быть возможность администрирования баз данных независимо от
приложений.
5) Полнота подмножества реляционного языка.
Реляционная схема может поддерживать несколько языков, по крайней мере, язык
DDL и DML. Однако хотя бы один из языков должен иметь синтаксис предложений,
поддерживающий следующие понятия:
определение данных (отношения, атрибуты, домены, ключи, ограничения
целостности);
определение виртуальных (мнимых) отношений образованных с помощью
реляционных выражений на основе одного или нескольких отношений
(определение представлений);
манипулирование данными (интерактивное или программное);
ограничение целостности;
санкционированный доступ;
управление транзакциями (начало транзакции, фиксация выполнения, отказ
от выполнения).
6) Обновляемость представлений.
2
1
Все представления (виртуальные отношения) должны автоматически обновляться при
модификации данных в базовых отношениях. Если, например, A= R S, и А – это
представление, то А должно обновляться как только меняется R или S.
7) Наличие высокоуровнего языка манипулирования данными.
Операции вставки, обновления и удаления должны применяться к отношению в целом:
обеспечивая контроль над целостностью базы данных при модификации отношений. При
выполнении вставки над отношением в целом легко проверить уникальность первичного
ключа, ограничения на значения и пр.
8) Физическая независимость данных.
Прикладные программы не должны зависеть от используемых способов хранения
данных на носителях информации и методов доступа к ним.
Физически независимые обеспечивает работоспособность приложений при изменении
расположения данных в сети.
9) Логическая независимость данных.
Прикладные программы не должны зависеть от реализации любого из используемых
представлений (виртуальных отношений).
Определив виртуальные отношение в рамках БД, можно разрабатывать приложения,
использующие это отношение, не беспокоясь о том, что структура БД изменится и
виртуальные отношение будет строиться на основе другого реляционных выражения.
10) Независимость контроля целостности.
Все ограничения целостности и внешнее представления (виртуальные отношения,
отчеты) должны определяться не в приложениях, а должны быть определены с помощью
языка определения данных и сохранения в каталоге (словаре) базы данных.
11) Дистрибутивная независимость.
Реляционная система должна быть распространяема и переносима. Создание
разнородных компьютерных систем требует обеспечения доступа к базам данных в
различных OS и на различных платформах.
Дистрибутивная независимость предполагает полную реализацию СУБД для
различных платформ или реализацию коммуникационных блоков в составе СУБД,
позволяющих обмениваться данными различным СУБД.
12) Согласования языковых уровней.
Если реляционная система имеет низкоуровневый язык доступа (элемент доступа –
запись) и высокоуровневый язык доступ (элемент доступа – отношения). То выполнение
низкоуровневых команд должно производиться с контролем целостности, так же как и при
высокоуровневых командах.
Лекция №8
2
2
Название лекции: Анализ реляционности распространенных СУБД клона
xBase. Отношения и реляционная алгебра.
План:
1. Отношения и реляционная алгебра. Переменная отношения. Свойства отношений.
Алгоритм нормализации отношения до 1 НФ.
1. Отношения и реляционная алгебра. Переменная отношения. Свойства отношений.
Алгоритм нормализации отношения до 1 НФ.
Отношения и реляционная алгебра.
Определив БД как множество отношений и задав на этом множестве операции, мы
получили алгебру, т.е. систему, позволяющую производить вычисления на множестве
отношений. Т.к. операндами и результатом каждой операции является отношение, то
полученная система является замкнутой (операции не выводят из множества
отношений). Т.о. (как и во всякой алгебре) мы приходим к понятиям «переменная» и
«значение переменной» (в нашем случае – переменная отношения и значение отношения,
сравнить переменная целого типа и значение этой переменной).
Переменной отношение – это абстрактное понятие, под которым мы будем понимать
производное отношение (для некоторых операций производное отношение с
определенной схемой (заголовком отношения)).
Для того чтобы задать значение отношения необходимо задать:
1) Схему отношения (заголовок отношения),
как множество атрибутов,
точнее множество пар вида ( < имя_ атрибута >, < имя_ домена >).
2) Множество кортежей (тело отношения).
Каждый кортеж – упорядоченное множество. С каждым значением в кортеже
связано имя атрибута, т.е. кортеж можно понимать как множество пар (< имя _
атрибута>,< значение _атрибута>).
В нашем курсе мы будем рассматривать отношения, обладающие следующими
свойствами:
1) В отношениях нет одинаковых кортежей.
2) Кортежи неупорядочены.
3) Атрибуты неупорядочены (т.е. атрибуты именованы).
4) Все значения атрибутов – атомарные (скалярные).
Пояснения:
атрибут является атомарным, если его невозможно разбить на более простые части,
которые соответствуют каким-то параметром объекта из предметной области.
Очень часто свойства 1…3 в конкретных языках СУБД нарушаются.
Пример: Допускается, чтобы кортежи повторялись, вводится упорядоченность
кортежей и атрибутов в кортеже. Т.е. есть операция перейти на первый кортеж, на
следующий кортеж прочитать атрибут № 5.
Требование упорядоченности обусловлено требованиями базового языка, а не
реляционной модели. Заметим, что для конечного пользования свойство упорядоченности
скрыто.
Примеры неатомарных атрибутов:
1. База данных сотрудников. Есть атрибут дети: список: пар (имя ребенка, год
рождения)
2. Атрибут ФИО можно иногда рассматривать как атомарный атрибут, иногда как
множество их 3-х атрибутов:
Фамилия;
Имя;
2
3
Отчество;
Отношения, у которых все атрибуты атомарные (скалярные), называются
нормализованными (находящимися в 1НФ). Реляционная теория БД рассматривает только
нормализованные отношения. Математическое отношение необязательно нормализовано.
Задача. Дано ненормализованное отношение. Дать определение в терминах теории
множеств, к какому классу объектов относится хотя бы один его атрибут.
Ответ. Отношение нормализовано, если ни один его атрибут не является отношением.
Алгоритм нормализации отношения до 1 НФ.
Рассмотрим на примере: R1: = {A, RA2 } RA2: = {C, D}
1) Найдём А(R1) = {A} = {{ai}}, {ai} – множество значений атрибута А.
2) Найдём RA2(R1) = {RA2} = {{C,D}} - A=ai (R1) – кортеж для аi.
A
A
3) Найдём R 2 (A=ai(R1)) – отношение R 2 для кортежа А=аi
R = А(R1) RA2(A=ai(R1))
Задача: Разработать другой алгоритм.
Пример нормализации отношения
Отношение Сотрудники.
№ Фамилия Должность Оклад
Дети
Оля
1990
1. Иванов
Директор
100
Маша 1992
Сережа 1989
2. Петров Гл. инженер 100
Катя
1991
Коля 1995
№
1
1.
2.
2.
2.
Нормализованная база.
Фамилия Должность
Иванов
Директор
Иванов
Директор
Петров
Гл. инженер
Петров
Гл. инженер
Петров
Гл. инженер
- первичный ключ
Оклад
100
100
100
100
100
Имя
Оля
Маша
Сережа
Катя
Коля
Год рождения
1990
1992
1989
1991
1995
Лекция №9
2
4
Название лекции: Виды отношений, используемых в реляционных системах.
Целостность БД и используемые ключи.
План:
1. Виды отношений, используемых в реляционных системах.
2. Целостность БД и используемые ключи:
2.1. Понятие целостности;
2.2. Потенциальные ключи;
2.3. Внешние ключи;
2.4. Ссылочная целостность.
3. Ключи и Null - значения
3.1.Правило целостности объекта. Предпосылки введения правила.
3.1.Внешние ключи и Null – значения.
1. Виды отношений, используемых в реляционных системах.
Именованное отношение – это переменная типа отношение, у которой есть имя.
Базовое отношение – это именованное отношение, которое не является производным
от других отношений.
Производное отношение – это отношение, определённое через другие именованные
отношения (посредством реляционного выражения), и в конечном итоге через базовые
отношения.
Выражаемое отношение – это отношение, которое можно получить из набора
именованных отношений посредством некоторого реляционного выражения.
Каждое именованное отношение является выражаемым отношением, но
необязательно, что выражаемое отношение имеет имя.
Множество всех выражаемых отношений – это объединение множества всех базовых
отношений и множества всех производных отношений.
Представление - это именованное производное отношение. Представление (как и
базовое явление, переменным отношениями).
Снимки – это именованные производные отношения (являются переменными
отношениями). Создание снимка похоже на выполнение запроса, за исключением того,
что результат такого запроса сохраняется в базе данных под некоторым именем как
отношение, доступное только для чтения. Периодически (например: раз в сутки) снимок
обновляется.
Результаты запроса – неименованное производное отношение, является результатом
вычисления некоторого реляционного выражения. База данных не обеспечивает
постоянное хранение результатов запроса. Для этого результат запроса необходимо
присвоить некоторому именованному отношению.
Промежуточным результатом называется неименованное производное отношение,
являющееся результатом некоторого реляционного выражения.
Хранимое отношение – это отношение, которое поддерживается во внешней памяти.
Реляционная модель и исчисление предикатов
Результатом реляционного выражения является отношение, т.е. множество, которое
может быть задано с помощью предиката R = {{a, b, c,} | P}
Можно показать, что реляционному выражению можно поставить в соответствие
некоторый предикат, который определит некоторое отношение, совпадающее с
результатом вычисления данного реляционного выражения.
Идея использовать исчисление предикатов в качестве основного языка баз данных
принадлежит Кунсу (Кuhns).
2
5
Понятие реляционного исчисления, т.е. специального применения исчисления
предикатов в реляционных базах данных было впервые предложено Коддом.
Ясно, что исчисление предикатов необходимо производить на множестве некоторых
переменных. Первоначально реляционное исчисление было основано на переменных
кортежа.
Переменная кортежа – это переменная, которая изменяется на некотором отношении,
т.е. это переменная, допустимые значения которой – это кортежи данного отношения.
Если переменная кортежа Т изменяется в пределах отношения R, то в любое данное
время значения переменой Т это некоторый кортеж t из отношения R.
Реляционное исчисление, основанное на переменных кортежа, называется исчислением
кортежей.
Позже было предложено альтернативное исчисление, определённое на переменных
доменов, т.е. переменных, которые изменяются не на отношениях, а на доменах. Это
исчисление называется исчислением доменов.
Наиболее известен язык исчисления доменов это Query – By – Example (QBE) - язык,
реализованный в реляционной СУБД PARADOX фирмы BORLAND.
Реляционная алгебра, исчисление кортежей и исчисление доменов являются
эквивалентными вариантами языков реляционных СУБД.
2. Целостность БД и используемые ключи.
Целостность БД – свойство БД, при наличии которого БД содержит полную и
непротиворечивую информацию, необходимую и достаточную для корректного
функционирования приложений.
Некоторые условия целостности проверяются с помощью типов (например, даты). В
сложных случаях целостность проверяется вычислением логических выражений.
Разработка таких выражений существенно опирается на предметную область.
Любое правило целостности является специфическим для данной БД.
Имеется два правила целостности, применимые к любой базе данных. Эти два правила
относятся к так называемым потенциальным и внешним ключам.
Потенциальные ключи.
Потенциальный ключ – это обобщение понятия первичного ключа. Первичный ключ
уникальным образом идентифицирует кортеж в отношении.
Потенциальные ключи также обладают таким свойством, но если первичный ключ в
отношении должен быть выбран только один, (из потенциальных), которых может быть
несколько.
Определение потенциального ключа:
Пусть R – некоторая переменная отношения, тогда потенциальный ключ K для R это
подмножество атрибутов R, всегда обладающее следующими свойствами:
1) Свойство уникальности: нет двух различных кортежей в текущем значении
переменной R с одинаковыми значениями K
2) Свойство не избыточности: никакое из подмножеств K не обладает свойством
уникальности.
На практике чаще всего встречается 1 потенциальный ключ, который выбирается
первичным.
Пример: дана БД элементов таблицы Менделеева: порядковый номер элемента,
атомная масса, название элемента и т.д. – все это потенциальные ключи.
Потенциальный ключ – множество (атрибутов).
Потенциальный ключ из 1-го атрибута – это простой ключ.
Потенциальный ключ из нескольких атрибутов – это составной ключ.
Если потенциальных ключей несколько, то один должен быть выбран в качестве
первичного ключа, а остальные будем называть альтернативными ключами.
2
6
Внешние ключи.
Пусть R2 – базовое отношение, тогда внешний ключ, например, FK в отношении R2 –
это подмножество множества атрибутов R2, такое что:
существует базовое отношение R1 (R1 и R2 не обязательно различны) с
потенциальным ключом СК;
каждое значение FK в текущем значении R2 всегда совпадает со значением СК
некоторого кортежа в текущем значении R1.
Замечания:
внешний ключ – это множество (вводят через {}), но если внешний ключ
простой, то скобки могут опускаться;
каждому значению внешнего ключа соответствует значение потенциального ключа
(обратно не справедливо).
Пример: цвет автомобиля в таблице Auto это указатель на значение цвета, который
храниться в таблице menu.
В теории реляционных баз данных требуется:
Если внешний ключ составной, то соответствующий потенциальный ключ тоже
составной. Если внешний ключ простой, то потенциальный ключ тоже простой.
Каждый атрибут, входящий в данный внешний ключ, должен быть определен
на том же домене, что и соответствующий атрибут, соответствующего
потенциального ключа.
Для внешнего ключа не требуется, чтобы он был компонентой первичного
ключа данного отношения.
Значение внешнего ключа является ссылкой на кортеж, содержащий
соответствующее значение потенциального ключа (так называемый ссылочный или
целевой кортеж). Проблема обеспечения того, что база данных не должна включать
никаких неверных значений внешних ключей называемой проблемой ссылочной
целостности. Ограничение, по которому каждое значение внешнего ключа должно
соответствовать значению потенциального ключа, называется ссылочным
ограничением. Отношение, которое содержит внешнюю ссылку, называется
ссылающимся отношением, а отношение, которое содержит потенциальный ключ –
ссылочным или целевым отношением.
Ссылочные ограничения представляются ссылочными диаграммами. Иногда над
стрелкой пишут внешний ключ.
C_COLOR
AUTO MENU
Отношение (R2) может быть одновременно и ссылочным и ссылающимся
R3 R2R1
Отношение может ссылаться само на себя
R1 R1
Пример: Список сотрудников, у которых есть атрибут – код сотрудника, которому
данный сотрудник подчиняется
Ссылки могут образовывать цикл (ссылочный цикл)
Rn Rn-1 … R1 Rn
Заметим, что атрибут(ы) становится внешним ключом, если имеется отношение с
соответствующим ему потенциальным ключом.
Ссылочная целостность.
База данных обладает ссылочной целостностью, если она не содержит значений
внешних ключей, которым не соответствует значение первичного ключа.
Удаление в ссылающемся отношении никогда не нарушает ссылочную целостность.
Проверить ссылочную целостность в момент добавления или коррекции
ссылающегося отношения не является сложным. Вся сложность лишь в предоставлении
2
7
возможности добавить кортеж в ссылочное отношение из среды работы с ссылающимся
отношением.
Добавление в ссылочное отношение никогда не нарушает ссылочную целостность.
Т.о. проблемы проверки ссылочной целостности возникают лишь при удалении и
корректировки ссылочного отношения.
Если при выполнении этих операций нарушается ссылочная целостность, то
используют две основные стратегии.
операции, нарушающие целостность, отвергнуть;
изменить ссылающееся отношение, чтобы целостность не нарушили. При этом
возможно потребуется откорректировать несколько отношений. Этот процесс
называется каскадированием.
Пример: удалить или изменить кортежи ссылающейся базы.
При этом 2-й вариант реализации возможен при организации диалога с пользователем
(предложить изменить ссылающиеся отношения, удаляемая запись перенести в архив и
т.д.).
Особая сложность возникает при наличии ссылочных циклов. Возможно, проверку
ссылочной целостности следует отложить до момента фиксации транзакции.
3.1.Правило
целостности
объекта.
Первичные
ключи
и
Null
значения.
Предпосылки введения правила.
Вместе с понятием первичного ключа модель включает правило целостности объекта,
которое заключается в следующем:
Ни один элемент первичного ключа базового отношения не может быть Null –
значением.
Предпосылки введения такого правила следующие:
кортежи базового отношения соответствует объектам реального мира;
объекты реального мира различны (т.е. некоторым образом опознаваемы);
значит, должны быть различимы представления реального мира, т.е. кортежи
базового отношения.
Если первичный ключ или его часть имеет Null – значение идентичность объекту
теряется.
В реляционной базе данных мы никогда не записываем информацию о чём – то, чего
мы не можем идентифицировать.
Проблема использования Null – значений до конца ещё не решена. Введение и
поддержка этого правила имеет несколько противоречий.
Пример: допустим, что в базе AUTO мы ввели понятие Null – значение для атрибута
код_ цвета. Составим список цветов автомобилей. В этом списке (отношении) возможно,
будет значение – цвет не определён. Наш запрос не является базовым отношением. И для
него требования целостности объекта может не применяться. Но что возникнет, если
результат запроса мы сохраним как базовое отношение. Такое отношение состоит только
из одного атрибута – цвет, которое должно быть первичным ключом.
Альтернативной стратегией Null – значениям является использование значений по –
умолчанию.
1.2.Внешние ключи и Null – значения.
Не вызывает особых сомнений, что внешние ключи могут принимать Null –
значения.
Пример: если рассмотреть самоссылающееся отношения <сотрудники>, в котором
есть атрибут <код_начальника>, то у президента компании это атрибут содержит Null –
значение. Т.о. понятие внешнего ключа должно быть дополнено возможностью принимать
значение Null.
Следовательно определение внешнего ключа должно быть расширено:
2
8
Пусть R2 – базовое отношение. Тогда внешний ключ FK в отношении R2 – это
подмножество множества атрибутов R2, такое что:
1) Существует базовое отношение R1 (R1 и R2 не обязательно различны) с
потенциальным ключом СК.
2) Всегда каждое значение FK в текущем значении R2 или является Null – значением,
или совпадает со значением СК некоторого кортежа в текущем значении R1
Возможность включения или не включения Null – значений в первичные и внешние
ключи регулируются соответствующими опциями операторов языка определения БД.
Замечание: Допустимость принятия Null – значения для внешнего ключа решает
(каким – то образом) проблему ссылочной целостности.
Пример: при удалении некоторого цвета из справочника цветов достаточно у
автомобилей (база AUTO), у которых был удаляемый цвет, установить цвет в Null.
Лекция №10
2
9
Название лекции: Проектирование баз данных.
План:
1. Введение в теорию проектирования БД.
2. Функциональные зависимости. Основные зависимости:
2.1. Функциональные зависимости первого типа;
2.2. Функциональные зависимости второго типа.
1. Введение в теорию проектирования БД.
Под проектированием будем понимать, прежде всего, проектирование логической
схемы, т.е. схемы концептуального уровня. Чаще всего процесс проектирования
состоит из нескольких циклов: - логическое проектирование; - физическая
реализация; - исправление ошибок – изменение представлений и логического
проектирования.
Под
проектированием
будем
понимать
построение
первоначального проекта схемы концептуального уровня.
Несмотря на то, что имеется теория проектирования только для реляционной
модели, есть средства перехода от реляционной к любой другой модели и наоборот,
т.о. теория проектирования может использоваться в любой модели.
Теория проектирования в полном объеме недостаточно формализована, т.о. процесс
проектирования в большой степени является все-таки искусством.
Проектирование БД – это не единственное условие получения правильной
структуры организации данных. Второе условие – это условие описания и проверки
целостности БД.
При проектировании БД интерес представления организации данных, а не
приложения, т.е. то, как эти данные используются не интересно. Критерием
правильного проекта является то, что схема БД остается стабильной и
работоспособной при возникновении новых требований в приложениях к данным.
Задача логического проектирования – фактически сводится к тому, чтобы решить
какие базовые отношения и с какими атрибутами следует использовать в проекте.
2. Функциональные зависимости.
Определение функциональных зависимостей даётся в двух видах:
1) Для значения элементов отношений в некотором времени.
2) Для всевозможных значений элементов отношения.
Определение функциональных зависимостей первого типа: Пусть R — отношение.
X и Y некоторые подмножество множества его атрибутов. Тогда Y функционально
зависимо от Х. Тогда и только тогда, когда каждому элементу множества Х соответствует
один и только один элемент множества Y. Функциональную зависимость записывают так:
XY. Иначе: Y функционально зависит от X, если два кортежа отношения R совпадают
по множеству атрибутов Х, то они совпадают по множеству атрибутов Y.
Пример:
Рассмотрим отношение R1 с множеством атрибутов
A={Поставщик, Город, Товар, Количество}
Поставщик Город
Товар Кол-во
1
Москва
1
100
1
Москва
2
100
2
Саратов 1
200
2
Саратов 2
200
3
Таганрог 2
300
4
Ростов
2
400
4
Ростов
4
400
4
Ростов
5
400
3
0
Выпишем ФЗ, которые существуют в R1 (при этих значениях)
поставщик→город
(поставщик, товар)→количество
(поставщик, товар)→город
(поставщик, товар)→(город, количество)
(поставщик, товар)→поставщик
(поставщик, товар)→(поставщик, товар, город, количество)
(поставщик)→количество
(количество)→поставщик
В ФЗ левая часть называется детерминантом, а правая – зависимой частью.
Интерес представляют функциональные зависимости второго типа определение,
которых справедливо не только для некоторого значения переменной отношения, но
остается справедливым и для любого значения переменной отношения.
Предположим, что ФЗ поставщик→город справедлива для любого значения
переменной отношения R1, т.е. справедлива в любой момент времени. Фактически это
является ограничением целостности БД. В жизни этому соответствует то, что никакая
компания не имеет филиалов.
Определения функциональных зависимостей второго типа: Пусть R – является
переменной отношения, а X и Y являются произвольными подмножествами множества
атрибутов отношения R. Говорят, что Y функционально зависит от X тогда и только тогда,
когда для любого допустимого значения отношения R каждому значению атрибутов,
имена которых находятся во множестве X, соответствует одно и только одно значение
атрибутов, имена которых находятся во множестве Y. Иначе: для любого допустимого
значения отношения R, если два кортежа отношения R совпадают по значению атрибутов,
имена которых находятся во множестве X, то они совпадают по значениям атрибутов,
имена которых находятся во множестве Y.
Пример: поставщик город . Это означает, в предметной области есть ограничение
«поставщики не имеют филиалов». Если два кортежа совпадают по коду поставщика, то
эти кортежи обязательно совпадут по городу, в котором расположен поставщик.
Наличие функциональной зависимости определяется внешней моделью предметной
области.
Например, если дополнительно предположить, что поставщик не может дважды
поставить один и тот же товар, то функциональные зависимости будут таковыми:
(поставщик, товар)→количество;
(поставщик, товар)→(город, количество);
(поставщик, товар)→поставщик;
(поставщик, товар)→(поставщик, товар, город, количество);
поставщик→город;
Очевидно, что для любого значения отношения не выполняются: поставщик→количество;
количество→поставщик. По определению 2 они не является ФЗ, но выполняются в
примере функциональных зависимостей первого типа.
Лекция №11
3
1
Название лекции: Зависимости и Правила Армстронга.
План:
1. Функциональные зависимости и целостность БД.
2. Тривиальные и нетривиальные зависимости.
3. Замыкание множества зависимостей.
4. Правила АРМСТРОНГА.
1. Функциональные зависимости и целостность БД.
Очевидно, что ФЗ по второму типу существенно меньше, чем по первому. ФЗ
фактически является условиями ограничения целостности. Т.о. их необходимо проверять
при обновлении данных в СУБД. Пусть множество таких ФЗ обозначается S. Если таких
зависимостей много, то их сложно проверить. Т.о. возникает задача получить такое
множество Т, которое было бы гораздо меньшего размера, чем исходное множество S.
Причём каждая ФЗ из S могла бы быть заменена условиями из Т. Поиск такого множества
ФЗ представляет большой практический интерес.
2. Тривиальные и нетривиальные зависимости.
ФЗ тривиальна тогда и только тогда, когда правая часть символической записи данной
зависимости является подмножеством левой части. Исключения тривиальных
зависимостей сокращает множество ФЗ.
3. Замыкание множества зависимостей.
Из некоторых ФЗ могут быть получены другие ФЗ.
Пример: (A, B)(C, D) (A, B)C, (A, B)D.
Пусть дано некоторое множество функциональных зависимостей S.
Определение: Множество всех ФЗ, которые могут быть получены из данного
множества S, называют замыканием множества зависимостей (S+). Чтобы получить
множество S+ используют правила вывода функциональных зависимостей (правила
АМСТРОНГА).
Пусть А,В,С,D – произвольные подмножества некоторого множества реквизитов
отношения R. Запись АВ означает АВ (для краткости).
4. Правила Армстронга.
1) Рефлексивность ВА=>А→В.
2) Дополнение (А→В)=>АС→ВС.
3) Транзитивность (А→В)(В→С)=>(А→С).
4) Самоопределение (А→А).
5) Декомпозиция (А→ВС)=>(А→В)(А→С).
6) Объединение (А→В)(А→С)=>А→ВС.
7) Композиция (А→В)(С→D)=>(АС→ВD)
Доказательство правил выполняется на основании определения функциональной
зависимости. Правила 1..3 называются основными правилами. Они являются
необходимыми и достаточными для получения из множества S замыкание множества S+.
Для удобства используют правила 4..7, которые называются вспомогательными.
Пример: Пусть R={a,b,c,d,e,f}, где а – номер сотрудника, b – номер отдела, c – номер
руководителя, d – номер проекта, e – название отдела, f – доля времени, уделяемая
руководителем данному проекту.
S={{a}→{b,c}, {b}→{e}, {c,d}→{e,f}}
Доказать: {a,d}→{f}
3
2
Доказательство:
{a}→{b,c}=>{a}→{b}٨{a}→{c}=>{a}→{c}=>{a,d}→{c,d}٨{c,d}→{e,f}=>{a,d}→{e,f}
=>{a,d}→{e}٨{a,d}→{f}=>{a,d}→{f}, что и требовалось доказать.
Замечание: Правила Армстронга позволяют получить замыкание множества ФЗ, но не
дают алгоритм как это сделать.
Лекция №12
3
3
Название лекции: Замыкание множества атрибутов.
Неприводимое множество зависимостей.
План:
1. Определение суперключа.
2. Алгоритм построения замыкания множества атрибутов Кi.
+
для множества
3. Приложение (следствие) алгоритма построения замыкания Ki
атрибутов Ki.
4. Алгоритм проверки, следует ли Ф.З. X Y из множества S, т.о. проверки
принадлежности X Y множеству S+.
5. Неприводимое множество зависимостей.
6. Потенциальные ключи и функциональные зависимости.
1. Определение суперключа.
Суперключом отношения R называется множество атрибутов отношения R, которое
содержит как подмножество хотя бы один потенциальный ключ (т.е. ключ, который
обладает свойствами: 1 – уникальности, 2 – не избыточности). Суперключ обладает
свойством уникальности, но является избыточным.
Пусть дано переменная отношения R с множеством атрибутов A. Допустим, что для
некоторого подмножества K множества атрибутов A (KA), выполняется ФЗ K→A. По
определения ФЗ это означает, что если два кортежа отношения R совпадают по значениям
атрибутов из множества K, то эти два кортежа будут совпадать и по значениям атрибутов
A, т.е. по множеству всех атрибутов. Но в этом случае (два кортежа совпадают по K) эти
два кортежа просто совпадают, что не возможно, т.к. в отношении никакие два кортежа не
могут совпадать. Следовательно, никакие два кортежа не могут совпадать по значению
атрибутов из множества K. При условии, что K→A в этом случае K обладает свойством
уникальности и значит, что K– это ключ.
Суперключи – это такие подмножества Кi (KiA) множества атрибутов отношения R,
обладающее свойством уникальности и избыточности. Это значит, что у Кi есть непустое
подмножество, не совпадающее с Кi (например, KКi), обладающее свойством
уникальности, т.е. K→A.
Пусть известно некоторое множество S функциональных зависимостей отношения R.
Требуется найти потенциальные ключи этого отношения. Если построить множество всех
ключей (каждый из элементов этого множества содержит потенциальный ключ) и
исключить из этого множества суперключи (т.е.ключи, обладающие свойством
избыточности), то мы получим множество потенциальных ключей. Чтобы установить
является ли множество атрибутов Кi ключом необходимо выяснить являются ли
функционально зависимыми все атрибуты отношения R от Ki, т.е. если для отношения R, с
множеством атрибутов А, множеством ФЗ S и множеством Ki A удается найти
множество Кi+ А такое, что все элементы Кi+ функционально зависят от Кi и при этом
Кi+ = А, то Кi является ключом. Если при этом ключ не обладает избыточностью, то это
потенциальный ключ.
Множество всех элементов из A, функционально зависимых от Ki A, называется
замыканием множества Ki для отношения R и множества функциональных зависимостей
S и обозначается Ki+ A. Если для Ki построили Ki+ , то выполняется ФЗ Ki→Ki+.
Алгоритм построения замыкания множества атрибутов Кi.
Дано: отношение R с множеством атрибутов A и множеством ФЗ
S={X1→Y1,X2→Y2,...,Xm→Ym}. Кроме того, пусть дано подмножество атрибутов Ki A.
Построим Ki+, замыкание множества ФЗ Ki. Т.е. требуется построить множество всех
2.
3
4
атрибутов из A, которые функционально зависят от Ki (т.е. Ki→Ki+). Алгоритм построения
такого множества является рекуррентным. В качестве начального приближения Ki+
выберем само множество Ki. Это возможно, т.к. имеет место ФЗ Кi → Кi и, следовательно,
Ki Ki+ . Итак:
Ki+ = Ki
Цикл_пока истина
j = 0, f = ложь
Цикл_пока j < m
j++
Если (Xj Ki+ ) ( yy Yj y Ki+ )
Ki+ = Ki+ Yj
f = истинна
Всё_если
Всё_цикл
Если не (f) то
Выход из цикла
Всё_если
Всё_цикл
Пример: Дано: отношение R, А – множество атрибутов, А = {a, b, c, d, e, f},
S = {{a} {b, c}, {e} {c, f}, {b} {e}, {c, d} {e, f}}
Найти: {a, b}+ для {a, b}
{a, b}+ = {a, b}
Бесконечный цикл
Цикл по элементам множества S
а) {a} {b, c}
{a} {a,b}+ => {a, b}+ = {a, b} {b, c} = {a, b, c}
б) {e} {c, f}
{e} {a, b}+ => {a, b}+ = {a, b, c}
в) {b} {e}
{b} {a,b}+ {a, b}+ = {a, b, c} {e} = {a, b, c, e}
г) {c, d} {e, f} {c, d} {a, b}+ => {a, b}+ = {a, b, c, e}
а) {a, b}+ = {a, b, c, e}
б) {e} {c, f} {e} {a, b}+ => {a, b}+ ={a, b, c, e} {c, f}={a, b, c, e, f}
Далее {a, b}+ не изменится и т. о. {a, b}+ = {a, b, c, e, f}. Мы построили такое
множество {a, b}+, которое зависит от {a, b}, т.е. {a, b} {a, b, c, e, f}.
Множество {a, b}+ A и {a, b} не является ключом и, т.о. не является ни
потенциальным ключом, ни суперключом.
+
3. Приложение (следствие из) алгоритма построения замыкания Ki для множества
атрибутов Ki.
Пусть дано:
1) Отношение R с множеством атрибутов A
2) Множество ФЗ S для R и S={X1→Y1,X2→Y2,...,Xm→Ym}.
3) Некоторая ФЗ X Y такая, что X Y S.
Проверить:
{X Y} S+. Т.е. необходимо проверить: следует ли X Y из S или
нет.
Решение:
1) Построим для {R, S, X} замыкание X+ для множества атрибутов X.
2) Каждый элемент (атрибут) множества X+ функционально зависим от X, т.е. XX+.
Следовательно, любое подмножество X+ функционально зависимо от X. И, если
Y X+, то X Y следует из S и, тогда, {X Y} S+ истина.
3
5
Если Y X+ , то функциональная зависимость X Y не следует из S и {X Y} S+.
4. Алгоритм проверки, следует ли Ф.З. XY из множества S, т.е. проверки
принадлежности X Y множеству S+.
1)
Для R, S построить X+
2) Если Y X+ то
{X Y} S+
иначе
{X Y} S+
все - если.
Пример: Дано: A = { a, b, c, d, e, f }
S = {{ a } { b, c }, { b } { e }, { c, d } { e, f }
Найти: истинность высказывания ({ a, d } { f } S+ )
Решение: обозначим x = { a, d } и найдем X+
0) X+ = { a, d }
1) X+ = { a, b, c, d }
2) X+ = { a, b, c, d, e }
3) X+ = { a, b, c, d, e, f }
Следовательно, в ФЗ {a,d}{f} зависима часть {f}{a, d}+, т.о. {{a, d}{f}}S+
5. Неприводимое множество зависимостей.
Пусть S1 и S2 два множества зависимостей отношения R. Если S1+ S2+, то говорят,
что S2 является покрытием S1. Это означает, что, если выполняются накладываемые на
отношение ограничения S2, то будут выполняться и ограничения S1.
Если S1 покрытие S2, а S2 является покрытием S1, т.е. S1+ = S2+, то S1 и S2 называют
эквивалентными множествами ФЗ.
Это означает, что, если выполняются ограничения S1, то выполняются ограничения S2,
и наоборот.
Пусть дано отношение R с множеством ФЗ S. Практически важной является задача
построения множества ФЗ S1, эквивалентного S и при этом имеющего принципиально
более простую структуру. Для эквивалентных множеств ФЗ S и S1 отношения R будем
говорить, что S1 проще, чем S, если при модификации R СУБД может проверить ФЗ S1
быстрее, чем проверить S. В теории реляционных баз данных принято выбирать так
называемые неприводимые множества ФЗ.
Множество ФЗ называется неприводимым тогда и только тогда, когда:
Правая (зависимая) часть каждой ФЗ множества S содержит только один атрибут.
В левой части каждой ФЗ множества S не может быть опущен ни один атрибут без
изменения замыкания S+.
Ни одна ФЗ в S не может быть опущена из S без изменения S+.
Пояснение:
по п.2, т.е. нельзя преобразовать (конвертировать) S путем удаления
некоторых атрибутов из детерминантов S во множество, эквивалентное S.
по п.2, говорят, что множество S в этом случае неприводимое слева.
по п.3, нельзя конвертировать S путем удаления каких-либо Ф.З. из S во
множество эквивалентное S.
Пример: Дано: отношение R с атрибутами A={a, b, c, d}; множество ФЗ: S={ { a }
{ b, c }; { b } { c }; { a } { b }; { a, b } { c }; { a, c } { d }}
Найти неприводимое множество, эквивалентное S.
Определим во всех ФЗ справа только одноэлементное множество атрибутов
S1={{ a } { b }, { a } { c }, { b } { c }, { a,b } { c }, { a,c } { d }}.
3
6
Напомним, что любое множество содержит только различимые объекты. Множество
ФЗ должно содержать только различные функциональные зависимости. Следовательно
{ a } { b } должна встретится только один раз. Мы преобразовали S в S1 , используя
правила Амстронга. Следовательно, S и S1 эквивалентные множества (S+=S1+ и
замыкание S не изменилось от преобразования его в S1).
Ни один атрибут слева не может быть опущен без изменения замыкания множества
зависимостей.
Рассмотрим последние две зависимости:
в { a,c } { d } – в детерминанте атрибут с можно опустить, т.к.
(ac) (ac→d)~(a→ac) (ac→d)~(a→ac) (a→d)~(a→c) (a→d).
S1 преобразовали с помощью правил Амстронга в
S2={{ a } { b }, { a } { c }, { b } { c }, { a,b } { c }, { a } { d }}.
При этом S1+=S2+.
Зависимость { a,b } { c } из S2 может быть исключена, т.к.
(ab)(a→c)~(a→b) (ab→bc)~(ab→b)(ab→c)~ (a→b)(ab→c), следовательно
(a→b)(a→c)~(a→b)(ab→c), но ФЗ (a→b) и (a→c) уже входят в S2 и
Зависимость {a,b} { c } из S2 может быть исключена. Получим
S3={{ a } { b }, { a } { c }, { b } { c }, { a } { d }}.
Ни одна ФЗ не может быть опущена без изменения S+. По третьему правилу
Амстронга (транзитивность) ({a} {b} {b} {c})=>{a} {c}, следовательно,
из S3 можно опустить {a} {c} без изменения замыкания. Окончательно получаем
S4={ a→b, b→c, a→d} – неприводимое множество ФЗ для S.
Пример: Дано отношение – расписание занятий с атрибутами:
D – день недели (1…5), P – номер урока (1…8), C – номер класса, T – имя
учителя, L – название урока.
Кортеж (d,p,c,t,l) является элементом этого отношения тогда и только тогда,
когда урок l проводится учителем t в классе с в момент времени d,p.
Предположим, что каждый урок имеет название, уникальное по отношению
ко всем урокам этой недели.
Ответить на вопросы:
Какие ФЗ выполняются для этого отношения? Какие потенциальные ключи
отношения?
Решение:
L→D,P,C,T
D,P,C→T
D,P,T→C
D,P,C→L
6 Потенциальные ключи и функциональные зависимости.
Если Х является потенциальным ключом отношения R (например, первичным
ключом), то все атрибуты этого отношения функционально зависят от Х.
Если отношение R удовлетворяет функциональной зависимости АB и А не является
потенциальным ключом, то R обладает некоторой избыточностью.
Пример: A={<Поставщик>,<Город>,<Товар>,<Количество>} множество атрибутов с
потенциальным ключом ={<Поставщик>,<Товар>}
Есть ФЗ <Поставщик><Город>, то отношение обладает избыточностью, т.к.
факт: поставщик из данного города повторяется в нескольких кортежах.
3
7
Лекция №13
Название лекции: Нормализация отношений.
План:
Нормализация отношений.
Нормализация отношений.
Нормализацию отношения рассмотрим на примере отношения
R:
Номер детали - (N), Город - (C), Код поставщика - (P), Количество - (Q).
N
1
1
1
1
1
1
2
2
3
4
4
4
C
Москва
Москва
Москва
Москва
Москва
Москва
Ростов
Ростов
Ростов
Москва
Москва
Москва
P
1
2
3
4
5
6
1
2
2
2
4
5
Q
300
200
400
200
100
100
300
400
200
200
300
400
Понятие нормализованной формы ввел Кодд и
определил 3 нормальных формы.
Исходные 3НФ приводит к некоторой
неадекватности, переработано Бойсом и
названо НФБК (нормальная форма БойсаКодда). Позже Фейгин дал определение 4НФ и
5НФ.
Нормализация – преобразование исходного
отношения по определенным правилам и
получение
других
отношений,
которые
эквивалентны исходному отношению. Формы
вложены друг в друга. Нахождение отношения
в более старшей форме, в некотором смысле,
более предпочтительно.
Замечание:
1) Предполагается, что необходимо использовать отношения в 5НФ, однако это не
абсолютно, т. к. возможны ситуации, когда принципами нормализации необходимо
пренебречь. Важно, чтобы база находилась в 1НФ.
2) Изучаемые схемы нормализации не являются естественными. Используются более
эффективные способы проектирования.
3
8
Лекция №14
Название лекции: Декомпозиция без потерь и функциональные зависимости.
Теорема Хеза.
План:
Декомпозиция без потерь и функциональные зависимости.
Теорема Хеза.
Предварительные (перед нормализацией) замечания о ФЗ. ФЗ как семантическое
понятие.
Декомпозиция без потерь и функциональные зависимости.
Основной механизм нормализации – декомпозиция исходного отношения
(проектирование исходного отношения).
Ясно, что получение новых отношений не должно приводить к потере информации
(возникновению противоречий), т. е. соединение полученных проекций должно дать
исходное отношение:
Пример:
S:
Код
Статус
Город
3
30
Казань
5
50
Новгород
1)
S11
Код
3
5
Статус
30
30
S12
Код
3
5
Город
Казань
Новгород
2)
S21
Код
3
5
Статус
30
30
S22
Статус
30
30
Город
Казань
Новгород
S11 JOIN S12: = S1
Код
3
5
Статус
30
50
Город
Казань
Новгород
S21 JOIN S22 S1 и содержит противоречивую информацию (нарушается условие один
город – один поставщик).
Пусть R1 и R2 – проекции некоторого отношения R. Поставим задачу: Какие условия
должны выполняться, чтобы при соединении отношений R1 и R2 получить исходное
отношение R.
Решение поставленной задачи дает теорема Хеза (Heath).
Теорема Хеза.
Пусть R отношение с атрибутами {A, B, C}. Если R удовлетворяет зависимости AR,
т.е. (А В и А С), R = ABAC эквивалентно, т. к. А А по 4 правилу Амстронга ,то
R равно соединению его проекций {A, B} и {A, C}.
Рассмотрим предыдущий пример.
В исходном отношении, очевидно, есть две ФЗ: S={{код статус}{код город}}
Очевидно, что S – неприводимое множество ФЗ и по т. Хеза проекции {код, статус} и
{код, город} дают исходное отношение {код, статус, город}.
3
9
Если рассмотреть проекции: {код, статус} и {статус, город}, то при таком разбиении
утрачивается функциональная зависимость {код, город} и соединение проекций не дадут
исходное отношение (транзитивности нет, т. к. статус город - нет).
Далее рассмотрение нормальных форм будем производить на примере следующего
отношения:
поставщики + товары
Код
1
1
1
1
1
1
2
2
3
4
4
4
Город
Москва
Москва
Москва
Москва
Москва
Москва
Ростов
Ростов
Ростов
Москва
Москва
Москва
Товары
1
2
3
4
5
6
1
2
2
2
4
5
Количество
300
200
400
200
100
100
300
400
200
200
300
400
1. Предварительные (перед нормализацией) замечания о ФЗ. ФЗ как семантическое
понятие.
Зависимости, отвечающие п.2. в определении неприводимых зависимостей,
называются неприводимые слева, т.е. это те зависимости, у которых нельзя слева
опустить ни одного атрибута, чтобы не изменилось замыкание множества
функциональных зависимостей (левая часть каждой ФЗ должна быть предельно
простой). Неприводимые ФЗ и неприводимые слева ФЗ играют важную роль в
нормализации.
Для изображения ФЗ используется графическое изображение ФЗ, так называемая
диаграмма ФЗ (или схема ФЗ).
Пример:
Функциональная зависимость как семантическое понятие.
ФЗ – это особый вид ограничений целостности, т. е. это, несомненно, семантическое
понятие.
Если отношение удовлетворяет ФЗ код_поставщика→город, это значит, что каждый
поставщик находится точно в одном городе. Это ограничение существует в реальном мире
(по крайней мере, в некоторой модели реального мира). Это ограничение является частью
семантики и должно быть представлено в базе данных таким образом, чтобы оно могло
быть приведено в действие СУБД.
Способом задания ограничений в определении базы данных является объявление ФЗ.
Лекция №15
4
0
Название лекции: Первая, вторая и третья нормальные формы.
План:
1. Определение неключевого атрибута и взаимно независимых атрибутов.
2. Неформальное определение 3НФ. Первая, вторая и третья нормальные формы.
1. Определение неключевого атрибута и взаимно независимых атрибутов.
Допущение: Для простоты изложения предполагаем, что каждое отношение имеет
только один потенциальный ключ, который является первичным ключом.
Неключевой атрибут – это атрибут, который не входит в первичный ключ
рассматриваемого отношения.
Два или несколько атрибутов образующих множество А называются взаимно
независимыми, если ни один из них не зависит функционально от какого-либо
подмножества остальных атрибутов множества А.
Физический смысл взаимно независимости: каждый атрибут из множества взаимно
независимых атрибутов А может быть обновлен независимо от остальных атрибутов
множества А.
2. Первая, вторая и третья нормальные формы.
Первая, вторая и третья нормальные формы.
Отношение находится в первой нормальной форме тогда и только тогда, когда все
используемые домены содержат только скалярное значение.
Любое нормализованное отношение находится в 1НФ.
Недостатки 1НФ рассмотрим на примере:
Отношение R1:
Код Статус Город Товар
1
20
Москва
1
1
20
Москва
2
1
20
Москва
3
1
20
Москва
4
1
20
Москва
5
1
20
Москва
6
2
10
Ростов
1
2
10
Ростов
2
3
10
Ростов
2
4
20
Москва
2
4
20
Москва
4
4
20
Москва
5
Кол-во
300
200
400
200
100
100
300
400
200
200
300
400
S={{код, товар} {количество}; {код} {город}; {код} {статус}; {город}
{статус}} множество ФЗ отношения R1.
Первичный ключ в отношении {код, товар} Статус поставщика определяется его
месторасположением.
Данное отношение обладает избыточностью (для каждого поставщика указан город и
статус). Избыточность приводит к различным аномалиям обновления:
аномалия – вставки INSERT. Нельзя добавить информацию о поставщике, который
не поставил ни одного товара.
4
1
аномалия – удаления DELETE. Возможна, что с удалением некоторой строки
таблица (удаление поставки) исчезнет информация о поставщике.
аномалия UPDATE (переписать, обновить) – эта проблема возникает в том случае,
если необходимо переместить поставщика из одного города в другой. Например, 1
из Москвы в Новгород. Необходимо откорректировать все записи о поставках от
этого поставщика.
Для решения этих проблем заменим отношение R1 несколькими проекциями. В одно
включим первичный ключ и все неключевые атрибуты, неприводимо зависимые от
первичного ключа. В остальные проекции включим неключевые атрибуты, приводимо
зависимые от первичного ключа и ту часть первичного ключа, от которой данные
атрибуты неприводимо зависят. Итак, получим 2 отношения:
R2:
R3:
Код Товар Кол-во
Код Статус
Город
1
1
300
1
20
Москва
1
2
200
2
10
Ростов
1
3
400
3
10
Ростов
1
4
200
4
20
Москва
1
5
100
5
30
Новгород
1
6
100
2
1
300
2
2
400
3
2
200
4
2
200
4
4
300
4
5
400
ФЗ для отношения R2:{код, товар}→{кол-во}
ФЗ для отношения R3:{код}→{город}, {код}→{статус}, {город}→{статус}
Такие отношения позволяют преодолеть указанные противоречия: INSERT: Можно
вставить поставщика из Новгорода, который не поставлял товар; DELETE: Можно
удалить товар 2 от поставщика 3, а сведения о поставщике останутся; UPDATE: Для того,
чтобы переместить поставщика 1 из Москвы в Новгород, достаточно поменять запись в
отношении R3.
Физический смысл противоречия в отношении R1 в том, что это отношение описывает
не один объект (поставку товара) а два: поставку и поставщика.
Определение 2ФН (при условии единственности потенциального ключа). Отношение
находится во второй нормальной форме тогда и только тогда, когда оно находится в 1НФ
и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
В общем случае: пусть имеется отношение R: {А, В, С, D} где {А, В} первичный ключ,
кроме того, имеется ФЗ A → D, тогда R заменяем на 2 отношения:
R1: {A, B, C} = ПрA,B,C (R), где первичный ключ {A, B}, А – внешний ключ.
R2: {A, D} → первичный ключ {А}.
Исходное: R = R1 JOIN R2.
Проблемы, возникающие в R3.
INSERT: Нельзя включить город с некоторым статусом, из которого нет ни одного
поставщика.
DELETE: удалив поставщика 5, удалим информацию о том, что Новгороду был
установлен статус 30.
UPDATE: информация о статусе повторяется, т.о. изменив статус Москвы с 20 на 30
необходимо откорректировать несколько записей.
4
2
Физический смысл противоречия тот же: информация о двух объектах предметной
области (город и поставщик) находится в одном отношении.
Формальным признаком проблем в R3 является наличие транзитивной ФЗ. Для этого
отношения неприводимое множество ФЗ: {код} → {город} и {город} → {статус}.
Для решения проблемы найдем от R3 проекции, в которые включим первичный ключ
и атрибут, через который осуществляется транзитивная зависимость. А во второе
отношении, этот же атрибут и атрибут, транзитивно зависящий от первичного ключа
исходного отношения. Получим отношение:
R5:
R6:
Код
Город
Город
Статус
1
Москва
Москва
20
2
Ростов
Ростов
10
3
Ростов
Новгород
30
4
Москва
Казань
40
5 Новгород
ФЗ для отношения R5: {код} →{город}
ФЗ для отношения R6: {город}→ {статус}
Каждое отношение описывает только одну сущность (объект предметной области).
Отношение находится в третьей нормальной форме тогда и только тогда, когда оно
находится в 2НФ и каждый его неключевой атрибут не транзитивно зависим от
первичного ключа.
Не транзитивная зависимость означает, что все неключевые атрибуты взаимно
независимы. Отношение, находящееся в 2НФ, можно получить из отношения
находящегося в 3НФ. Соединение 3НФ дают 2НФ, но в 3НФ может содержаться
информация, которой нет в 2НФ. Итак, переход от 2НФ в 3НФ заключается в исключении
транзитивных зависимостей.
Пример: Отношение R с атрибутами {A, B, C}, где {A} – первичный ключ; есть ФЗ:
B→C (A → B и A → C – очевидно).
R1: {A, B}, где {A} – первичный ключ, В – внешний ключ, А→В.
R2: {B, C}, где {B} – первичный ключ, В→С.
Отношение R может быть восстановлено соединением R1 и R2: R = R1 join R2
Замечание: Уровень нормализации данного отношения определяется семантикой, а не
конкретными значениями данных в некоторый момент времени. Нельзя с первого взгляда
на таблицу с данными для некоторого отношения определить, находится ли оно, например
в 3НФ. Для этого также необходимо проанализировать существующие ФЗ. Даже при
наличии всех ФЗ можно только высказать предположение, что данные не противоречат
гипотезе о принадлежности отношения к 3НФ. Однако этот факт гарантирует, что
предложенная гипотеза верна.
4
3
Лекция №16
Название лекции: Декомпозиции с независимыми проекциями.
План:
1. Сохранение зависимости.
2. Условия декомпозиции с независимыми проекциями.
Сохранение зависимости.
Рассмотрим отношение R с ФЗ код→город и город→статус, и следовательно
транзитивной зависимостью код→статус.
Код Статус
Город
1
20
Москва
2
10
Ростов
3
10
Ростов
4
20
Москва
5
30
Новгород
При нормализации данное отношение может быть подвергнуто декомпозиции
различными способами.
Ранее это отношение (в 2НФ) мы заменили на два отношения 3НФ, чтобы устранить
аномалии 2НФ.
А:
1
RA
R2 A
Код
1
2
3
4
5
Город
Москва
Ростов
Ростов
Москва
Новгород
Город
Москва
Ростов
Ростов
Москва
Новгоро
д
Статус
20
10
10
20
30
B:
1
R2B
RB
Код
Город
Код
Статус
1
Москва
1
20
2
3
4
5
Ростов
Ростов
Москва
Новгород
2
3
4
5
10
10
20
30
При декомпозиции В оба отношения R1B и R2B также находятся в 3НФ, и R1BJoinR2B=R
(нет потери информации).
Пусть ФЗ также сохранены (замыкание ФЗ совпадают). Но декомпозиция В менее
предпочтительна, чем А, т.к., например, по-прежнему нет возможности добавить город со
своим статусом без указания поставщика.
Рассмотрим этот пример подробнее.
4
4
Заметим, что в разбиении А изменять отношения R1A и R2A можно независимо друг от
друга. Единственно, что необходимо проверять уникальность ключей в этих отношениях,
а ФЗ код→статус будет выполняться автоматически.
В разбиении В не достаточно обеспечить уникальность первичных ключей в
отношениях R1B и R2B, т.к. ничего не может указать статус. Например, у поставщика 4
указать статус 10, тогда у Москвы по коду 1 – статус 20, а по коду 4 – 10. Таким образом,
при модификациях отношений R1B и R2B необходимо проверять ФЗ город→статус.
Разбиение А ФЗ: код→город и город→статус – естественно выполняются за счет
уникальности ключей. Ограничения между отношениями код→статус выполняются
автоматически.
Разбиение В ФЗ: код→город и код→статус – выполняются при условии уникальности
ключей. ФЗ между отношениями город→статус необходимо проверять. Заметим, что ФЗ
город→статус не могут быть получены из код→город и код→статус.
Разбиение В пример зависимых проекций.
Разбиения с независимыми проекциями более предпочтительны.
Условия декомпозиции с независимыми проекциями.
Дано отношение R. Проекции R1 и R2 этого отношения являются независимыми (в
указанном выше смысле) тогда и только тогда, когда:
1) Каждая ФЗ в отношении R является логическим следствием функциональных
зависимостей в проекциях R1 и R2.
2) Общие атрибуты проекций R1 и R2 образуют потенциальный ключ, по крайней
мере, для одной из них.
В декомпозиции А: проекции R1A и R2A – являются независимыми, т.к.:
ФЗ код→город и город→статус являются естественными, а ФЗ код→статус
является их логическим следствием.
Общий атрибут (город) является первичным ключом в одной из проекций (в R2A).
Декомпозиция В: проекции R1B и R2B не являются независимыми, т.к.: ФЗ код→город
и код→статус являются естественными, но ФЗ город→статус не является логическим
следствием этих зависимостей. Хотя их общий атрибут (код), является потенциальным
ключом в обеих проекциях (и R1B и R2B).
4
5
Лекция №17
Название лекции: Нормальная форма Бойса – Кодда (НФБК).
План:
1. Определение НФБК.
2. Примеры НФБК.
3. Преимущества НФБК.
1. Определение НФБК.
Рассмотрим более общий случай отношения.
Пусть:
Отношение имеет два (или более) потенциальных ключа.
Два потенциальных ключа является сложными.
Потенциальные ключи перекрываются
Замечание: отношения, у которых имеются условия 1, 2, 3, встречаются редко, если у
отношения нет условий 1, 2, 3, то 3НФ совпадает с НФБК.
Отношение находится в нормальной форме Бойса-Кодда тогда и только тогда, когда
каждая нетривиальная и неприводимая слева ФЗ обладает потенциальным ключом в
качестве детерминанта.
Менее формальное определение имеет формулировку:
Отношение находится в НФБК тогда и только тогда, когда детерминанты являются
потенциальными ключами.
На диаграммах ФЗ стрелки будут начинаться только с потенциальных ключей.
Никакие другие стрелки не допускаются.
2. Примеры НФБК.
Код Статус Город Товар
1
20
Москва
1
1
20
Москва
2
1
20
Москва
3
1
20
Москва
4
1
20
Москва
5
1
20
Москва
6
2
10
Ростов
1
2
10
Ростов
2
3
10
Ростов
2
4
20
Москва
2
4
20
Москва
4
4
20
Москва
5
Кол-во
300
200
400
200
100
100
300
400
200
200
300
400
Рассмотрим отношение R1
Схема ФЗ имеет вид:
Детерминанты:{код}, {город}, {код, товар},
только {код, товар}→ потенциальный ключ.
Таким образом отношение R1 не находится в
НФБК.
Отношение R3, R5 и R6, которые находятся в 3НФ.
R3 :
R5 :
R6 :
4
6
Эти отношения также находятся в НФБК, т.к. единственный потенциальный ключ
является и единственным детерминантом.
Рассмотрим отношение: {код, имя-поставщика, статус, город}.
Допустим, что код и имя-поставщика являются потенциальным ключом (т.е.
поставщик имеет уникальный код и уникальное имя).
Кроме того, пусть ФЗ город→статус не выполняется (ранее введенная такая
зависимость использовалась только для иллюстрации).
Диаграмма ФЗ имеет вид:
Все детерминанты являются потенциальными ключами. Отношение находится в
НФБК.
Рассмотрим отношение: {код, имя-поставщика, товар, кол-во} предположим, что
имена поставщиков и код являются уникальными.
Потенциальные ключи в этом отношении {код, товар} и {имя-поставщика, товар},
ясно, что имеется ФЗ код→имя_поставщика и имя_поставщика→код. Таким образом
данное отношение не находится в НФБК, т.к. есть детерминанты которые не являются
потенциальными ключами.
Пусть часть этого отношения имеет
Код
Имя
Товар Количество вид:
Это
отношения
обладает
1
Иванов
1
300
избыточностью
=>
есть
аномалии
1
Иванов
2
200
обновления,
но
заметим,
что
отношения
1
Иванов
3
400
находятся в ЗНФ т.к. для ЗНФ (в
1
Иванов
4
200
определении Кодда) требуется, чтобы
каждый не ключевой атрибут неприводимо зависел от потенциального ключа, т.е. то, что
атрибут имя_поставщика приводимо зависит от потенциального ключа {код, товар}
игнорируется.
Для решения проблемы разобьем отношение на 2 проекции:
А: {код, имя_поставщика}, {код, товар, количество};
В: {код, имя_поставщика}, {имя_поставщика, товар, количество}.
Обе композиции находятся в НФБК.
Рассмотрим отношение: {студент, курс, преподаватель}.
(кортеж означает, что студент
Студент Курс
Преподаватель
обучается
предмету
некоторым
Иванов Математика Белов
преподавателям).
Иванов Физика
Сидоров
Петров Математика Белов
Петров Физика
Лимонов
Пусть накладываются некоторые ограничения:
Каждый студент, изучая данный предмет, обучается только одним преподавателем.
Каждый преподаватель ведет только один предмет (но каждый предмет может
преподаваться несколькими преподавателями).
Схема ФЗ имеет вид:
4
7
В рассматриваемом примере есть два перекрывающихся потенциальных ключа:
{студент, курс} и {студент, преподаватель}. Отношение находится в ЗНФ, т.к. нет
неключевых полей вообще, но не в НФБК опять есть аномалии удаления: удалив запись о
том, что Петров изучает физику, удаляем сведения о том, что Лимонов преподает физику.
Проблема в том, что {преподаватель} является детерминантом, но не является
потенциальным ключом. Построим разбиение.
А: {студент, преподаватель} и {преподаватель, курс}
СТУДЕНТ
Иванов
Иванов
Петров
Петров
ПРЕПОДАВАТЕЛЬ
Белов
Сидоров
Белов
Лимонов
Потенциальные ключи:
{студент, преподаватель}
ПРЕПОДАВАТЕЛЬ
Белов
Сидоров
Лимонов
КУРС
Математика
Физика
Физика
{преподаватель}
Отношения находятся в НФБК. Имеется естественная ФЗ {преподаватель}→{курс}.
Кроме того, должно иметь место ФЗ связывающая отношения {студент,
курс}→{преподаватель}.
Устранены некоторые противоречия (убрать запись Петров, Лимонов, но сведения о
том, что Лимонов преподает физику останется). Но имеется другие проблемы: добавим
запись Иванов, Лимонов.
Формально это можно сделать, но это противоречит тому, что Иванов уже изучает
физику у Сидорова, т.е. эти два отношения связаны (не являются независимыми): ФЗ
{студент, курс}→{преподаватель} нельзя получить из ФЗ этого разбиения (только одна
ФЗ {преподаватель}→{предмет}, т.е. добавить запись в отношение 1 нельзя без проверки
отношения 2). Таким образом декомпозиция на компоненты в НФБК и композиция на
независимые компоненты может вступить в конфликт.
Рассмотрим отношения R с атрибутами: {студент, предмет, номер_в_списке}
Кортеж: (S,P,N)R, если студент S сдает экзамен по предмету P, если он занесен в
список сдающих под номером N.
Имеют места следующее ограничение: никакие два студента не могут иметь один и тот
же номер по списку по одному и тому же предмету; имеют место следующие ФЗ:
{студент, предмет}→{номер}, {предмет, номер}→{студент}
В отношении имеются два перекрывающихся ключа:{студент, предмет} и {предмет
номер}, т.к. оба потенциальных ключа являются детерминантами и других детерминантов
нет, то отношение находится в НФБК.
4
8
У этого отношения нет аномалий.
3. Преимущества НФБК.
Позволяет избавится от некоторых проблем, присущих (хотя бы теоретически)
форме ЗНФ.
Определение НФБК концептуально проще ЗНФ (нет: 1НФ, 2НФ, первичного
ключа, транзитивной зависимости).
4
9
Лекция №18
Название лекции: Нормальные формы
более
Многозначные зависимости.
высокого
порядка.
План:
1. Примеры составления множества нормализованных отношений и формализованных
ФЗ.
2. Нормальные формы более высокого порядка. Многозначные зависимости.
3. Теорема Фейгина. Четверная нормальная форма.
4. Зависимости соединений и пятая нормальная форма.
Примеры составления множества нормализованных отношений и формализованных
ФЗ.
Имеется иерархическое представление о информации, хранящейся в БД о персонале
некоторой компании.
1) В компании имеется несколько отделов.
2) В каждом отделе есть несколько сотрудников, которые выполняют несколько
проектов, каждый отдел занимает несколько комнат.
3) Каждый сотрудник имеет план работы. Для каждой такой работы служит список
выплат (т.е. перечень делящих сумм, полученным сотрудником за выполнение
данной работы).
4) В каждой комнате есть несколько телефонов.
В базе данных должна хранится следующая информация:
Для каждого отдела: номер отдела (уникальный), бюджет, номер начальника
отдела (уникальный).
Для каждого сотрудника: номер сотрудника (уникальный), номер проекта, номер
комнаты, номер телефона, название выполняемой работы, дата и размер всех
выплат полученных за выполнение данных работ;
Для каждого проекта: номер проекта (уникальный) и бюджет;
Для каждой комнаты: номер комнаты (уникальный) площадь в кв. метрах, номера
(уникальные) всех телефонов установленных в этом кабинете.
Составить множество нормализованных отношений, а также формализованные ФЗ.
Решение:
Выскажем несколько утверждений, исходя из здравого смысла:
1) Ни один сотрудник не является начальником нескольких отделов.
2) Ни один сотрудник не работает одновременно более, чем в одном отделе.
3) Ни один сотрудник не работает одновременно более, чем с одним проектом.
4) Ни один сотрудник не может иметь рабочее место более, чем в одной комнате.
5) Ни один сотрудник не имеет более одного телефона.
6) Единицей измерения времени является день.
5
0
7) Ни один сотрудник не имеет одновременно более одного задания (т.е. не может
получить в один день 2-х сумм).
8) Ни одна комната не может относится более, чем к одному отделу.
Приведем ненормализованное исходное отношение:
Отдел0::={номер-отдела, бюджет-отдела, номер-начальника, сотрудники0::={номерсотрудника, номер-проекта, номер-комнаты, номер-телефона, задание0::={содержаниезадания, список-выплат0::={дата-выплаты, сумма}}}, проект0::={номер-проекта,
бюджет-проекта}, комната0::={номер-комнаты, площадь, список-телефонов0::={номертелефона}}}.
Схема ФЗ.
Этап 1. Для простоты предполагаем, что каждое отношение имеет первичный ключ.
В отношении отдел0 два потенциальных ключа. Выберем один: номер-отдела, а номерначальника - альтернативный ключ.
Выполним приведение к ЗНФ по алгоритму, предложенному Коддом:
начиная с отношения, находящегося на вершине иерархии следует расширить
каждое непосредственно подчиненное отношение с помощью вставки первичного
ключа. Первичным ключом каждого расширенного отношения будет комбинация
атрибута, который является «уникальным» до расширения, с первичным ключом,
скопированным из родительского отношения;
Выделить из родительского отношения корневую вершину, без атрибутовотношений. Для каждой из оставшейся древовидной структуры применять данный
алгоритм.
Получим:
отдел1::= {номер-отдела, бюджет-отдела, номер-начальника}
первичный ключ::=номер-отдела.
сотрудник1::={номер-отдела, номер-сотрудника, номер-проекта, номер-комнаты,
номер-телефона}
первичный ключ::=номер-отдела, номер-сотрудника.
задание1::={номер-отдела, номер-сотрудника, содержание-задания}
первичный ключ::=номер-отдела, номер-сотрудника, задание.
список-выплат1::={номер-отдела, номер-сотрудника, содержание-задания, датавыплаты, сумма}
проект1::={номер-отдела, номер-проекта, бюджет-проекта}
комната1::={номер-отдела, номер-комнаты, площадь}
список-телефонов::={номер-отдела, номер-комнаты, телефон}
Этап 2.
Отдел1 уже в 2НФ (все не ключевых, атрибутов, неприводимо зависимы от первичного
ключа).
5
1
отдел2::={номер-отдела, бюджет-отдела, номер-начальника}
сотрудник1 – номер-отдела – избыточность в первичном ключе, сотрудник только в
одном отделе.
сотрудник2::={номер-сотрудника, номер-отдела, номер-проекта, номер-комнаты,
номер-телефона}
задание1 – номер-отдела – избыточный атрибут, удаляем его из первичного ключа.
После этого в отношении есть первичный атрибут номер-отдела, который приводимо
зависит от первичного ключа. Разобьем на две проекции.
задание2А::={номер-сотрудника, содержание-задания}
задание2В::={номер-сотрудника, номер-отдела}
задание2В является проекцией сотрудник2 и т.е. может не рассматриваться.
Рассмотрим список-выплат1 можно полностью удалить номер-отдела, т.к. номерсотрудника→номер-отдела. И после разбиения на 2 проекции вторую проекцию
исключаем (анологично задание2В), останется:
список-выплат2::={номер-сотрудника, дата, содержание-задания, сумма}
содержание-работы можно исключить из первичного ключа, т.к. есть ФЗ {номерсотрудника, дата} → {содержание-работы}
Но отношение задание2А является проекцией отношения список-выплат2, т.е. его
исключаем.
Проект1. Т.к. есть ФЗ {номер-проекта}→{номер-отдела}, то номер отдела не является
ключевым атрибутом. Тогда проект1 находится в 2НФ.
Проект2::={номер-проекта, номер отдела, бюджет-проекта}.
Для комнаты1 аналогично проект1 получаем.
комната2::={номер-комнаты, номер-отдела, площадь}
Список-телефонов1 – номер-отдела переводим в не ключевой атрибут, далее этот
атрибут остается первичным ключом {номер-комнаты, телефон}, но номер-отдела ФЗ от
части первичного ключа (номер-комнаты проектируем).
список-телефонов2А {номер-комнаты, телефон}
список-телефонов2В {номер-комнаты, номер-отдела}
Последнее является проекцией комнота2 и исключается окончательно
список-телефонов2::={номер-комнаты, телефон}, первичный ключ – номер-телефона,
т.к. есть ФЗ {телефон}→{номер-комнаты}
Внимание последнее отношение не является проекцией отношения сотрудник2, т.к.
комната может существовать без связи с конкретным сотрудником.
Этап 3. Все отношения, кроме сотрудники2, находятся в 3НФ. В отношении
сотрудники2 атрибут номер-комнаты и номер-отдела транзитивно зависимы от
первичного ключа номер-сатрудника. Номер-комнаты через номер-телефона, а номеротдела через номер-проекта и через номер-комнаты, а следовательно через номертелефона.
Номер-сотрудника→номер-телефона→номер-комнаты.
сотрудник3А::={номер-сотрудника, номер-отдела, номер-проекта, номер-телефона}.
сотрудник3В::={номер телефона, номер-комнаты} (совпадает список-телефонов2).
Для сотрудники3А: номер-сотрудника→номер-проекта→номер-отдела.
сотрудник3АА::={номер-сотрудника, телефон, номер-проекта}.
сотрудник3АВ::={номер-проекта, номер-отдела} это проекция проект2.
Итак сотрудник3::{номер-сотрудника, номер-проекта, номер-телефона} все остальные
отношения второго уровня являются отношениями в 3НФ.
Все отношения уже находятся в НФБК. В некоторых случаях найти отношения НФБК
можно по схеме ФЗ (в каждом отношении «стрелки» ФЗ должны выходить только от
потенциальных ключей).
5
2
Нормальные формы более высокого порядка. Многозначные зависимости и четвертая
нормальная форма.
Рассмотрим ненормализованное отношение:
Курс
Физика
Преподаватель
Иванов
Петров
Математика
Иванов
Учебники
Основы механики
Оптика
Основы механики
Векторный анализ
Тригонометрия
Пусть каждый курс может преподаваться любым преподавателем соответствующей
группы с использованием всех указанных учебников. Для заданного курса может
существовать любое количество соответствующих преподавателей и соответствующих
учебников. Допустим, что преподаватели и учебники независимы друг от друга (это не
всегда справедливо), т.е. кто бы ни преподавал данный курс, всегда используется один и
тот же набор учебников. Кроме того, допустим, что каждый преподаватель или каждый
учебник могут быть связаны с любым количеством курсов.
Из этих условий видно, что никаких ФЗ в данном отношении нет.
Проведем нормализацию до 1НФ, получим:
R:
Курс
Преподаватель
Учебники
Физика
Иванов
Основы механики
Физика
Иванов
Оптика
Физика
Петров
Основы механики
Физика
Петров
Оптика
Математика
Иванов
Основы механики
Математика
Иванов
Векторный анализ
Математика
Иванов
Тригонометрия
Кортеж (c, t, b) включается в данное отношение, если курс c, читается преподавателем
t по книге b.
Т.к. встречаются все комбинации преподавателей с учебниками, тогда справедливо
следующее ограничение:
Если есть два кортежа (c, t1, b1) и (c, t2, b2) то есть также кортежи (c, t1, b2) и (c, t2, b1)
((c, t1, b1)R^(c, t2, b2)R) ((c, t1, b2)R^(c, t2, b1)R)
Очевидно, что отношение обладает большой избыточностью, т.е. аномалиями
обновления.
Пример: чтобы добавить в отношение сведения еще об одном преподавателе, который
ведет занятие по математике необходимо добавить два кортежа (для двух книг
соответственно). Очевидно, есть проблемы коррекции, например, фамилия, но отношение
находится в НФБК, т.к. в этом отношении потенциальный ключ единственный –
конкатеназия всех полей. Не ключевых полей нет.
Очевидно, что в базе достаточно хранить два кортежа, что бы показать, что курс
физики читает два преподавателя по двум учебникам (при наличии ограничения (1) см.
выше), другие два кортежа можно построить.
Предположим достаточно два кортежа: (Физика, Иванов, основы механики) и (Физика,
Петров, оптика), чтобы получить: (Физика, Иванов, оптика) и (Физика, Петров, основы
механики).
Но есть проблема: какие два кортежа выбрать и все аномалии обновления существуют.
Интуитивно ясно, что атрибуты преподаватели и учебники совершенно не зависят друг
от друга.
Проблема может быть решена, если отношение R разбить на два отношения:
R1 :
Курс
Преподаватель
Физика
Иванов
Физика
Петров
Математика
Иванов
5
3
R2 :
Курс
Учебники
Физика
Основы механики
Физика
Оптика
Математика Основы механики
Математика Векторный анализ
Математика
Тригонометрия
Каждый из которых является полностью ключевым, т.е. находится в НФБК.
Отношение R может быть получено соединением отношений R1 и R2, т.е. композиция
из R1 и R2 выполняется без потери информации.
Таким образом, если исходное ненормализованное отношение разбить на независимые
группы. Далее эти отношения могут быть нормализованы.
Следует заметить, что декомпозиция R на R1 и R2 не может быть выполнена на основе
функциональных зависимостей, т.к. их нет в этом отношении.
Многозначные зависимости.
Пусть А, В и С являются произвольными подмножествами множества атрибутов
отношения R. Говорить, что В многозначно зависит от А (А–››В или А многозначно
определяет В), тогда и только тогда, когда множество значений (множество атрибутов) В
зависит от множества значений атрибутов А и не зависит от множества значений атрибута
С.
Рассматриваются зависимости, которые выполняются всегда, а не для данного
состояния отношения.
Если в отношении R {А, В, С} выполняется многозначная зависимость А–››В, то
каждому значению атрибутов А соответствует некоторое множество значений атрибутов
В, причем значение атрибутов В не зависит от значения атрибутов С, а зависит только от
значений атрибутов А. Таким образом, если зафиксировать значения А получим (a, b 1, c1),
(a, b2, c2)…( a, bn, cn), но тогда значению а соответствует некоторое множество значений В:
{b1, b2… bn}, но а соответственно множество значений С: {с1, с2… сn}, т.е. существует и
А–››С.
Этот факт имеет место всегда, т.е. многозначные зависимости существуют парами, что
регистрируется как: А–››В|С, для примера КУРС–››ПРЕПОДАВАТЕЛЬ|УЧЕБНИК.
Заметим, что ФЗ является частным случаем многозначной зависимости (МЗ).
Теорема Фейгина.
Пусть А, В и С являются множествами атрибутов отношения R{А, В, С}. Отношение
R будет равно соединению его проекций {A, B} и {A, C} тогда и только тогда, когда для
отношения R выполняется многозначная зависимость А–››В|С.
Эта теорема является обобщенной теоремой ХЕЗА.
Отношение R находится в четвертой нормальной форме (4НФ) тогда и только тогда,
когда если существуют такие подмножества А и В атрибутов отношения R, что
выполняется (нетривиальная) многозначная зависимость А–››В, то все атрибуты
отношения R также функционально зависимы от атрибута А.
В 4НФ могут существовать только нетривиальные зависимости (функциональные или
многозначные) вида K→X, где К – потенциальный ключ, Х – любой атрибут.
Отношение R находится в 4НФ, если оно находится в НФБК и все многозначные
зависимости являются фактически функциональными зависимостями от потенциальных
ключей.
Отношение R не находится в 4НФ, т.к. содержит многозначную зависимость, не говоря
о том, что она должна быть функциональной зависимостью от потенциального ключа.
Отношения R1 и R2находятся в 4НФ.
Фейгин показал, что 4НФ всегда может быть получена без потери информации.
5
4
Алгоритм транзитивной зависимости А→В и В→С можно ввести понятие
многозначной функциональной зависимости А–››В и В–››С. В этом случае (наличие
многозначной транзитивной зависимости) отношение R (A, B, C) следует также разбить на
два отношения {А, В} и {В, С}.
Зависимости соединений и пятая нормальная форма.
Рассмотрим пример:
R
Поставщик
Детали Проекты
Иванов
1
2
Иванов
2
1
Петров
1
1
Иванов
1
1
Пусть данное отношение является полностью ключевым, не содержит нетривиальных
и многозначных зависимостей, т.е. находится в 4НФ.
Рассмотрим три проекции этого отношения:
R1
Поставщик
Детали
Иванов
1
Иванов
2
Петров
1
R2
Детали
Проекты
1
2
2
1
1
1
R3
Проекты
Поставщик
2
Иванов
1
Иванов
1
Петров
Соединим R1 и R2 по атрибуту детали
R4
Поставщик
Детали
Проект
Иванов
1
2
Иванов
Линейный
1
1
кортеж к
Иванов
2
1
отношению R
Петров
1
2
Петров11Соединим R4 и R3 по комбинации атрибутов (проект, поставщик)
R5
Поставщик
Детали
Проект
Иванов
1
2
Иванов
1
1
Иванов
2
1
Петров
1
1
Отношение R5=R
Можно проверить аналогичный результат (появление линейного кортежа) получается,
если первоначально соединить другие две проекции и потом появляется исходное
отношение, после соединения с третьем.
Итак получили свойства отношения R:
5
5
Отношение R нельзя разбить ни на какие два отношения, которые после соединения
будут опять отношения R. Но если разбить R на три отношения, то после их соединения
получим исходное отношение R. Такое отношение называется 3-х декомпозируемым
отношением. Аналогично можно определить n-декомпозируемые отношения.
Для n-декомпозируемого отношения возможна декомпозиция без потери только на n
проекций, а на меньшее число проекций декомпозиция невозможна.
Свойства 3-х – декомпозируемости рассмотрено на конкретном состоянии отношения
(в некоторый момент времени). Это свойство может быть и более фундаментальным и не
зависеть от времени. Обозначим RSPJ {S, P, J}
RSP {S, P}=ПSPRSPJ
RPJ {P, J}=ПPJRSPJ
RJS {J, S}=ПJSRSPJ
(1) (RSPJ =RSP join RPJ join RJS)~
(2) ~((s1, p1) RSP)^ ((p1, j1) RPJ)^ ((j1, s1) RJS)→((s1, p1, j1) RSPJ) – обратное
выполняется всегда!
(s1, p1) RSP) ~(s1, p1, j2) RSPJ
(p1, j1) RPJ)~(s2, p1, j1) RSPJ
(j1, s1) RJS)~ (s1, p2, j1) RSPJ
(3) ((s1, p1, j2) RSPJ)^((s2, p1, j1) RSPJ)^((s1, p1, j2) RSPJ)→ (s1, p1, j1) RSPJ
Смысл (3): если s1 связано с p1 (т.е. находится в одном кортеже (вспомнить прямое
произведение)), p1 связано с j1, и j1 связано опять с s1, то s1, p1 и j1 должны находится в
одном кортеже. Это циклическое ограничение!
Отношение будет n-декомпозируемым для n>2 тогда и только тогда, когда оно
удовлетворяет некоторому циклическому ограничению.
Кратко 3-декомпозируемое ограничение обозначим 3D ограничение. Вернемся к
примеру приведенному выше.
Пусть: деталь 1 – гаечные ключи, деталь 2 – гайки, тогда 3D ограничение для нашего
примера означает:
Если Иванов поставляет гаечные ключи и гаечные ключи поставляются по проекту1, и
Иванов является поставщиком проекта 1, то Иванов поставляет гаечные ключи по проекту
1.
Замечание: Данное утверждение справедливо не для всех отношений, а только для 3декомпозируемых отношений, т.е. 3D ограничение должно присутствовать в предметной
области.
Вывод (замечание):
3D ограничение удовлетворяется тогда и только тогда, когда отношение равносильно
соединению некоторых его проекций, то такие ограничения называют зависимостью
соединений.
Зависимость соединения такое же ограничение, как многозначная и функциональная
зависимость.
Пусть R – отношение A, B, … Z – произвольные подмножества множества атрибутов
отношения R. Отношение R удовлетворяет зависимости соединения (записывают *(A, B,
… Z)) тогда и только тогда, когда оно равносильно соединению своих проекций с
подмножества атрибутами A, B, …Z.
Для отношения {S, P, J} обозначим SP={S, P}, PJ={P, J}, SJ={S, J}.
Пусть отношение обладает зависимостью.
Замечание: пусть дано отношение
R:{A, B, C} и есть две Ф.З. А→В и А→С по т. Хеза R можно разбить на два отношения
R1:{A, B} и R2:{A, С}
R=R1 join R2
Данная декомпозиция определяется (подразумевается) атрибутам(и) А.
5
6
По определению зависимости соединения такое соединение является ограничением,
т.к. R=AB join AC.
Для отношения {S, P, J} имеет место зависимость соединения *(SP, PJ, JS), но нельзя
указать атрибут(ы), которые определяют разбиение на SP, PJ, JS соединения *(SP, PJ, JS).
Аномалии такого отношения: пусть есть состояние:
S
P
J
S1
P1
J2
S1
P2
J1
Добавим кортеж (S2, P1, J1) есть (S1, P1, J2) и (S2, P1, J1) и (S1, P2, J1) тогда должен быть
кортеж (S1, P1, J1) т.е. его так же необходимо вставить. Если вставить (S1, P1, J1), то
добавить (S2, P1, J1) не нужно.
S
P
J
S1
P1
J2
S1
P2
J1
S2
P1
J1
S1
P1
J1
Если удалить (S2, P1, J1) то побочных эффектов нет.
Но если удалить (S1, P1, J1), то необходимо удалить и один из основных 3х кортежей,
чтобы разорвать циклическое ограничение.
Для устранения таких аномалий необходимо разбить отношение на проекции, таким
образом, чтобы только потенциальные ключи определяли зависимость соединения.
{K, X1, X2, …Xn}=>K→X1, K→X2, … K→Xn, где K – потенциальный ключ.
Пусть дано отношение {K, X1, X2, …Xn}, где К – потенциальный ключ, X1, X2, …Xn –
прочие атрибуты.
Очевидно имеет место K→X1, K→X2, … K→Xn (ФЗ)
По т. Хеза имеет место *(КX1, КX2, …КXn).
Фейгин предложил алгоритм, с помощью которого для заданной зависимости
соединения и множества потенциальных ключей проверить, определяется ли данная
зависимость соединения данными потенциальными ключами. Но для этого необходимо
знать зависимое соединение и множество потенциальных ключей. Обнаружить все
зависимости соединения очень сложно. Следовательно, процесс определения находится
отношение в 4НФ или 5НФ до конца не определен, но из практики такие отношения очень
редкие.
5НФ является последней в том смысле, что оно свободно от аномалий, которые можно
устранить с помощью разбиения на проекции.
В отношении {S, P, J} есть зависимость соединения *(SP, PJ, JS), но она не
определяется потенциальными ключами => необходима декомпозиция. Каждая из
проекций
Пример: SP может содержать кроме ключа SP другие атрибуты и т.е. может быть
подвергнута декомпозиции, но смысла в такой декомпозиции нет, т.к. каждое полученное
отношение содержит один и тот же потенциальный ключ (нет ни каких преимуществ).
5
7
Лекция №19
5
8
Название лекции: Итоговая схема процедуры нормализации.
Другие нормальные формы
План:
1. Итоговая схема процедуры нормализации.
2. Другие нормальные формы. Доменно-ключевая нормальная форма (ДКНФ).
3. Нормальная форма «выборка-объединения».
4. Модель типа объект/отношение.
5. Пример семантических понятий.
6. Обзор модели объект/отношения.
7. Подтипы.
Итоговая схема процедуры нормализации.
Дано:
отношение в 1НФ (приведено в нем) ограничения ФЗ, многозначная
зависимость и зависимости соединения.
Основная идея нормализации: состоит в систематическом приведении отношения R к
набору меньших отношений, которые в некотором смысле эквивалентен отношению R, но
более предпочтителен.
Заданные ограничения используются на каждом шаге процедуры нормализации для
выбора проекции на следующем шаге.
Схема нормализации:
Отношение в 1НФ следует разбить на проекции для исключения всех –
функциональных зависимостей, которые не являются неприводимыми. Получим
набор отношений в 2НФ.
Отношение в 2НФ следует разбить на проекции для исключения любых
транзитивных функциональных зависимостей. Получим набор отношений в 3НФ.
Отношение в 3НФ следует разбить на проекции для исключения любых
оставшихся функциональных зависимостей, в которых детерминанты не являются
потенциальными ключами. Получим набор отношений в НФБК.
Замечание: правила 1..3 могут быть сконцентрированы в одном: Исходные отношения
следует разбить на проекции для исключения всех функциональных зависимостей, в
которых детерминанты не являются потенциальными ключами.
Отношение в НФБК следует разбить на проекции для исключения любых
многозначных зависимостей, которые не являются функциональными
зависимостями. Получим набор отношений в 4НФ.
Отношения 4НФ следует разбить на проекции для исключения любых
зависимостей соединения, которые не подразумеваются потенциальными ключами
(если их можно выявить) т.е. получим набор отношений в 5НФ.
Цели нормализации:
1) Исключение некоторых типов избыточности.
2) Устранение некоторых аномалий обновления.
3) Проектирование макета БДЮ который был бы хорошим представлением реального
мира, интуитивно понятен и служил хорошей основой для дальнейшего развития.
4) Упрощение процесса наложения ограничения целостности.
Приведение к 5НФ представляет простой путь наложения важных и
распространенных ограничений. Главное привести в действие условие уникальности
потенциальных ключей.
Рекомендации по поводу нормализации является лишь рекомендацией, и могут быть
соображения, когда не следует проводить нормализацию «до конца».
5
9
Понятия зависимости и нормализация являются семантическими понятиями (т.е.
связаны со смыслом данных), тогда рекомендации по процедуре нормализации являются
некоторым алгоритмом, выполняя который разработчик БД может заключать некую часть
семантики реального мира в простую и понятную форму.
Идеи нормализации являются чрезвычайно полезны для проектирования базы данных,
но они не являются универсальным средством, т.к.:
Кроме Ф.З., многозначных зависимостей и зависимостей соединения могут
существовать другие ограничения целостности.
Декомпозиция может быть не уникальной, а для выбора предпочтительной
декомпозиции может не быть существенных критериев.
Приведение к НФБК и сохранению зависимостей может привести к конфликтной
ситуации.
Не всякую избыточность можно устранить разбиением на проекции.
Другие нормальные формы. Доменно-ключевая нормальная форма (ДКНФ).
Не определяется на основе ФЗ, МЗ и ЗС. Утверждается, что отношение R находится в
ДКНФ, тогда и только тогда, когда каждое ограничение, наложенное на отношение R,
является логическим следствием ограничений доменов и ограничений ключей,
наложенных на отношение R.
Ограничение домена – это ограничение на использование значения для данного
атрибута только из некоторого предметного домена.
Ограничение ключа – это ограничение на то, что некоторый атрибут или комбинация
атрибутов представляет собой потенциальный ключ, т.е. обладает свойствами
потенциальных ключей.
Декларируется, что достаточно выполнить ограничение доменов и ключей и тогда все
остальные ограничения выполняются автоматически. Причем под «другие ограничения»
понимается более явные понятия, чем ФЗ, МЗ или ЗС: понимают некоторый предикат.
Фейгин показал, что отношение, находящееся в ДКНФ находится и в 5НФ, однако не
всегда можно добавить приведение к ДКНФ или показать, как это сделать.
Нормальная форма «выборка-объединения».
Рассмотрим отношение, в котором находятся сведения о поставщиках.
Для нормализации типа «выборка-объединения» предлагает разбивку отношения на
ряд однотипных (с одинаковой структурой) отношений, в каждое из которых включается
запись о поставщиках из одного города. Фактически такое разбиение (не на проекции)
всегда хуже стандартной нормализации, однако классическая теория нормализации не
позволяет ответить на вопрос хуже это или лучше.
Некоторое преимущество для специальных выборок (резкое сокращение
обрабатываемых записей).
Имеются другие направление в исследовании нормализации, основаны на основе
других операций, отличных от проекций.
Модель типа объект/отношение.
Модель типа объект/отношение относится к так называемым семантическим
моделям. Необходимость таких моделей вызвана тем, что СУБД (реляционные или
другие) обладают ограниченными сведениями о смысловом значении данных, хранящейся
в некоторой базе данных. Обычно СУБД позволяют включить простые ограничения
целостности на простые атомарные значения. Ясно, что домены, потенциальные ключи,
внешние ключи являются семантическими понятиями в реляционной модели. В качестве
другого способа реализации семантики были разработаны различные «расширенные»
модели, которые несут большую смысловую нагрузку, чем предлагаемые ранее модели.
6
0
«Семантическая» модель является целой области исследований, повещенных способом
представления смыслового значения.
Общий подход:
Необходимо задать множество семантических понятий, которые могут быть
полезны при неформальном обсуждении реального мира.
Например, можно допустить, что мир состоит из объектов (иногда трудно определить,
что является объектам, а что нет).
Пример: сотрудник, фирмы поставщики, поставки и т.д.
Можно допустить, что образуют типы объектов (все сотрудники являются
экземплярами некоторого типа объекта СОТРУДНИК. Преимущества: все объекты
обладают некоторыми свойствами (получение сотрудником зарплаты).
Возможно ввести некоторое свойства объекта, которое идентифицирует объект.
Можно предположить, что каждый объект связан с другими объектами отношениями.
Необходимо определить множество формальных (символических) объектов,
которые могут быть использованы для представления описанных выше
семантических понятий.
Для описания семантических понятий используют особые отношения E – отношения
описывающие объекты ENTITY – relation и P – отношения (PROPERTY – relation) – для
описания свойств.
Необходимо ввести множество формальных правил целостности для работы с
формальными объектами. Например, для каждого Р – отношения должен
существовать Е – отношения объект.
Необходимо задать множество формальных операторов для манипулирования этими
формальными объектами. (Z.B. оператор выбрать все свойства (все Р – отношения) для
данного объекта (Е – отношения)).
Пример семантических понятий.
Понятия
Неформальное определение
Объект
Различные объекты.
Свойства
Информация описывающая
объект.
Примеры
Поставщик, товар, поставка, сотрудник,
отдел, человек, произведение, концерт,
оркестр, дирижер, заказ, ассортимент
заказов.
Номер поставщика, количество поставок,
отдел сотрудника, рост человека, вид
концерта, дата заказа.
Объект, который служит для
Поставка (поставщик-товар), Назначение
организации взаимодействия
(сотрудник-отдел).
между двумя объектами.
Тип объекта Y является
подтипом объекта X т. и т. т.,
Тип сотрудник является подтипом типа
Подтип
К. Каждый объект типа Y
человек.
обязательно является
объектам типа Х.
Видно, что один и тот же объект реального мира можно рассматривать как объект, как
свойства, как отношение.
Отношения
Обзор модели объект/отношения.
Разработчик модели О/О Чен дает такое определение объекту: объект – это предмет,
который может быть четко идентифицирован.
При этом объекты подразделяются на правильные объекты и слабые объекты. Слабым
объектам называют объект, который находится в зависимости от некоторого другого
6
1
объекта. Слабый объект не может существовать, если не существует объект, которому он
подчиняется.
Объект, не являющейся слабым объектам, называют правильным (или сильным
объектом).
Пример: База данных аэропорта: правильный объект – сотрудник, слабый объект –
пилот. Если удалить экземпляр сотрудника, то удаляется подчиненный ему экземпляр –
пилот.
На диаграммах о/о (объект/связь) объект обозначается прямоугольником.
Свойство объектов:
Объекты обладают некоторыми свойствами. Значения свойств каждого типа
извлекаются из соответствующего множества значений (в реляционной модели называют
доменом).
Виды свойств:
Простое или составное свойство. Например: составное свойство «имя сотрудника»
может складываться из простых свойств «имя», «отчество», «фамилия».
Ключевое свойство - уникальное свойство в некотором смысле.
Базовое и производное свойства. Например, общее количество товара ( производное
свойство) может быть получено на основании суммирования отдельных количеств
поставок данного товара.
Имеются также свойства: однозначные, многозначные, отсутствующие (т.е.
неизвестные или неприменимые).
На диаграммах свойства обозначаются овалом.
Отношения.
Отношение Ченом определяется как ассоциация объектов.
Например: отношение «купил билет» между объектами «пассажир» и «вылет». Так же,
как и для объектов имеется принципиальная разница между типами и экземплярами
отношений.
Объекты, включенные в данное отношение, называют участниками этого отношения.
Количество участников данного отношения называют степенью этого отношения (не
путайте с арностью отношения в реляционной модели). Степень отношения «купил
билет» – два.
Пусть R является типом отношения, которое содержит тип объекта Е в качестве
участника. Если каждый экземпляр объекта типа Е находится по крайне мере с одним
экземпляром отношения R, то участие Е в отношении R называют полным, а в противном
случае частичным.
Пример: есть два объекта «поставщик», «товар» и отношение между ними «поставка».
Если каждый товар должен поставляться как минимум одним поставщиком то, участие
товара в отношении «поставка» является полным. Если допускается, что есть товар,
который не поставляется ни одним из поставщиков, то участие товара в отношении
«поставка» является частичным.
Будем предполагать, что отношение имеет степень 2, хотя концепция и терминология
может быть расширена и на отношения более высокого порядка.
Отношение в модели о/о могут иметь типы: один-к-одному, один-ко-многим, многиек-одному или многие-ко-многим.
Ясно, что единственным истинным отношением является отношение n:n для этого
случая требуется создать отдельный объект, представляющий это отношение.
Пример: Для отношения n:n между товарами и поставщиками необходимо создать
объект «поставка», у которого должны быть свойства «код поставки (ссылка на объект)»,
«поставщик» и «код товара» (ссылка на объект товара).
Отношения типа 1:1 и 1:n всегда могут быть представлены с помощью внешнего
ключа.
6
2
Однако в некоторых случаях их следует рассматривать так же, как и n:n, по крайней
мере, если существует вероятность (возможность) необходимости расширить в будущем
эти отношения до типа n:n.
Подтипы.
Программист автоматически обладает всеми свойствами сотрудников (обратно не
верно). Аналогично программисты автоматически участвуют во всех отношениях, в
которых участвует сотрудник (обратное не верно).
Программисты могут входить в профессиональное общество программистов, а другие
сотрудники нет.
Говорят, что свойства и отношения наследуются.
Внимание! Речь идет о иерархии типов, а не о иерархии данных.
Лекция №20
Название лекции: Архитектура клиент/сервер. Распределенная обработка
6
3
План:
1. Анализ структуры СУБД с точки зрения поддержки приложений БД:
1.1. Понятия сервер и клиент;
1.2. Приложения и типы приложений;
1.3. Понятие распределенной обработки.
2. Распределенная обработка. Простая схема распределенной обработки. Преимущества
такой схемы. Примеры.
1. Анализ структуры СУБД с точки зрения поддержки приложений БД.
Архитектура клиент/сервер. Ранее рассмотрена трехуровневая структура СУБД, в
основу которой положены три уровня абстракции. Рассмотрим структуру СУБД с точки
зрения основной цели, для достижения которой созданы СУБД, а именно поддержка и
разработка приложений БД, через которые осуществляется доступ к информации. С этой
точки зрения система БД состоит из двух частей: непосредственно СУБД (сервер или
машина БД) и внешнего интерфейса (клиенты).
Сервер (машина БД) – это собственно СУБД. Таким
образом, СУБД это, прежде всего, программное
обеспечение. Хотя это программное обеспечение, для
повышения производительности, иногда может быть
реализовано
на
специальной
ЭВМ.
Сервер
поддерживает
все
основные
функции
СУБД:
определение данных, обработку данных, защиту и
целостность и т.д. Обеспечивает поддержку на
внешнем, концептуальном и внутреннем уровне. Таким
образом в данном контексте сервер– это другое имя СУБД.
Клиент – это различные приложения, которые выполняются «над» СУБД.
Типы приложений:
приложения, написанные пользователем;
приложения, поставляемые поставщиками СУБД или другими поставщиками
программного обеспечения.
Общим у всех приложений является то, что все приложения используют один и тот
же интерфейс сервера, а именно интерфейс внешнего уровня.
Исключением являются специальные ''служебные'' приложения, которые работают
на внутреннем уровне системы. Такие приложения (утилиты) скорее относятся к
компонентам СУБД. Рассмотрим подробнее типы приложений:
Приложения, написанные пользователем. Это прикладные программы, написанные
на одном из зыков программирования типа С или специализированном языке. В любом
случае эти языки должны иметь интерфейс с подъязыком данных.
Приложения, поставляемые поставщиками (часто называют инструментальными
средствами). В целом назначение таких средств – содействовать процессу создания и
выполнения других приложений. К таким инструментальным средствам относятся,
прежде всего:
процессоры языков запросов (с помощью которых конечный пользователь
может выдавать незапланированные запросы к системе);
генераторы отчетов, т. е. системы визуализации результатов построенных
запросов;
графические бизнес – системы;
электронные таблицы;
процессоры обычных языков программирования;
6
4
средства управления копированием;
генераторы приложений;
другие средства разработки приложений, включая CASE–продукты
(COMPUTER AIDED SOFTWARE ENGINEERING);
системы автоматизация разработки программного обеспечения.
Количество и качество имеющихся в СУБД клиентских инструментальных средств
должно быть одним из основных факторов при выборе базы данных.
Понятие распределенной обработки. Т.к. СУБД в целом может быть четко разделена
на две части (сервер БД и клиенты), то появляется возможность работы этих двух частей
на разных машинах, т.е. возможность распределенной обработки. Распределенная
обработка предполагает, что отдельные машины можно соединить какой-нибудь
коммуникационной сетью, чтобы определенная задача, обрабатывающая данные, могла
быть выполнена на нескольких машинах в сети. СУБД, которые не позволяют вести
распределенную обработку, могут допускать обработку информации через
коммуникационную сеть только в так называемом файл - серверном режиме. В этом
режиме программное обеспечение СУБД должно быть загружено в компьютер
пользователя и при выборке информации из файла удаленной БД весь файл должен быть
перегружен по сети с файл-сервера в компьютер пользователя. Даже при небольшом
числе пользователей такой дополнительный трафик может практически парализовать сеть.
Термин клиент/сервер часто подразумевает только распределённую обработку, как
дающую максимальную выгоду, хотя такую технологию можно реализовать и на одной
ЭВМ.
2. Распределенная обработка.
Один из простых случаев распределенной обработки – это архитектура, в которой
сервер СУБД запускается на одной машине, а клиентские приложения на другой.
Термин клиент/сервер – фактически синоним такой схемы.
Преимущества такой схемы:
параллельная обработка. Для всей задачи применяется несколько процессоров и
обработка сервера (базы данных) и клиента (приложения) выполняются
параллельно, время ответа уменьшается, производительность обработки растет;
машина сервера может быть изготовлена по специальному заказу и приспособлена
для работы с СУБД, что обеспечит лучшую производительность;
машина клиента может быть персональной станцией, приспособленной к
потребностям конечного пользователя, обеспечивать лучший интерфейс и в целом
дополнительные удобства;
несколько разных машин клиентов могут иметь доступ к одной и той же машине
сервера. Таким образом, одна БД может совместно использоваться несколькими
отдельными клиентами системы. Такая структура соответствует структуре
большинства предприятий.
Пример: работы БД банка:
6
5
В некоторых случаях, например, для банка весьма вероятно, что пользователям одного
отделения банка необходим доступ к данным, сохраняемым в другом отделении. Таким
образом, вообще говоря, каждая машина будет выступать в роли сервера для одних
пользователей и в роли клиента для других. Иначе каждая машина будет поддерживать
полную систему БД.
В
последнем случае
распределение
информации,
более
точно
описывает
структуру предприятия. Доступ
возможен двумя способами:
Клиент может получить доступ
к любому числу серверов, но
лишь к одному в одно и тоже
время. В этом случае нет
возможности за один запрос
получить комбинацию данных
с двух и более серверов, кроме
того, приложение «должно
знать» на какой машине, какая
часть данных содержится. При
втором
способе
клиент
получает доступ к любому числу серверов одновременно (возможны комбинации) в этом
случае все серверы рассматриваются клиентом как один логический сервер и
пользователь «может не знать» на какой именно машине, какая часть данных содержится.
Такая реализация прозрачна для клиента, но сложна в реализации. Именно этот случай
(последний рисунок) называется распределенной системой БД.
Лекция №21
6
6
Название лекции: Двухзвенные и трехзвенные модели распределения
функций.
План:
1. Двухзвенная модель распределение функций в модели клиент/сервер
2. Понятие о трехзвенной архитектуре модели клиент/сервер
3. Физическая организация данных.
4. Модель организации внешней памяти.
5. Закрепленные и не закрепленные записи.
6. Организация файлов в виде «кучи».
1. Двухзвенная модель распределение функций в модели клиент/сервер.
В БД выполняются 3 основные функции: управление данными, обработка и
представление. Если эти 3 функции делятся между 2 ЭВМ, то говорят о двухзвенной
модели клиент/сервер
1. распределенное представление - клиент вырожден. Х – терминал, который может
быть реализован на компьютере с процессором с ограниченным числом команд.
Преимущество: простота обслуживания, т.к все описание на сервере.
Недостаток: уязвимость центрального компьютера
2. удаленное представление. Процедуры обработки хранятся на сервере
Преимущества: хорошее центральное обслуживание приложений (в одном месте правятся
все функции обработки); достаточно эффективное использование ресурсов сети и сервера.
Недостатки: сложность выполнения обработки на сервере параллельно с доступом к
данным; низкая эффективность использования ЭВМ клиента.
3. распределенная функция.
Преимущество: повышение эффективности использования клиент ЭВМ.
Недостаток: сложность поддержки
4. удаленный доступ к данным по отношению к клиенту.
Преимущества: управление и обработка полностью распределены; высокая
эффективность использования клиента и сервера.
Недостатки: более высокая загрузка сети; сложность модификации и сопровождения
(функции обработки установлены на всех клиентах, а из нужно сопровождать).
5. распределенная БД. Возможны два варианта реализации: локальная + удаленная БД
хранимая как одно целое; - локальная БД является копиями удаленных (репрекация БД) –
работа с локальной и синхронизации с удаленной.
Преимущества: гибкость создаваемой информационной системы; высокая живучесть.
Недостатки: затраты на приложения; нужен механизм синхронизации.
Доступ серверам возможен 2-мя способами:
6
7
1)
Клиент может получить доступ к любому числу сервером, но лишь к 1-му в
одно и то же время. Нет возможности за один запрос получить комбинацию
данных с 2-х и более серверов.
2)
Клиент получает доступ к любому числу серверов одновременно. Возможна
комбинация информации. Все серверы клиент рассматривает как 1 логический
сервер. (Доступ прозрачен для клиента). Именно этот вариант называется
Распределенная БД.
2. Понятие о трехзвенной архитектуре модели клиент/сервер.
Если управление данными, обработка и представление делятся между 3 ЭВМ, то говорят о
3-х уровневой модели.
Преимущества:
1.
Более
полно
используются технические возможности
компьютеров, а именно сервер БД
может быть реализован на компьютере
который ориентирован на дисковые
возможности, клиентская машина – на удобный интерфейс. 2. Высокая централизация
(чтобы изменить, достаточно изменить на сервере). 3. Достаточно эффективное
распараллеливание стадий информации (между 3-мя компьютерами).
Недостаток: Повышенное требование к надежности. (Ломается сервер БД - ломается все).
3. Физическая организация данных.
Будем считать, что на физическом уровне информация хранится в файле, который
содержит записи с идентичным форматом.
Формат записи – список имен полей, каждое поле занимает фиксированное число
байт и имеет фиксированный тип. Запись состоит из значений каждого поля.
Над файлом требуется выполнить следующие типичные операции:
включить запись;
удалить запись;
модифицировать запись;
найти запись, удовлетворяющую заданным условиям.
Эффективность физической организации определяется эффективностью реализации
этих 4-х операций.
4. Модель организации внешней памяти.
Под внешней памятью чаще всего понимают магнитные диски, но возможны и другие
устройства (CD–ROM, ленты, барабаны…).
Отвлекаясь от действительной организации и адресации внешней памяти,
предполагаем, что файловая система разделяет внешнюю память на логические блоки
равного размера (кластеры). Файл хранится в одном или нескольких блоках. В каждом
блоке могут храниться несколько записей. Запись может занимать несколько блоков.
Внутри блока может быть пространство, незанятое какими либо записями. Мы
предполагаем, что файловая система устанавливает соответствие между именем файла и
адресами блоков, которые образуют этот файл. Можно считать, что запись так же имеет
адрес, который можно рассматривать либо как абсолютный адрес её первого байта, либо
как адрес блока, содержащего запись, плюс смещение записи внутри блока.
Отвлекаясь от действительной природы адресации, для ссылки на блок или запись
будем использовать понятие «указатель» подразумевая – номер блока в некотором
виртуальном линейном адресном пространстве, занимаемым некоторым файлом. Под
указателем на запись иногда будем так же понимать её линейный адрес в некотором
виртуальном линейном пространстве занимаемым файлом. Под таким адресом можно
понимать, например, номер записи в таблице. Часто под термином «указатель» на запись
6
8
будем понимать «указатель» на блок, в котором находится запись. В этом случае, для
того, чтобы найти нужную запись, необходимо:
прочитать блок, который её содержит;
найти в оперативной памяти запись внутри блока.
При таком подходе запись внутри блока можно перемещать, при этом указатель на
запись (фактически указатель на блок её содержащий) не изменится. Уменьшается
вероятность «зависания указателя» – это когда «указатель» указывает на место, где записи
на самом деле нет.
Основная операция с внешней памятью – это передача блока из внешней памяти в
оперативную память и наоборот. Поэтому, если говорить о быстродействии различных
алгоритмов доступа к данным, то следует подсчитать число блоков, которые должны быть
прочитаны в основную память или записаны из неё. Это число и будет представлять
оценку быстродействия алгоритма.
Мы предполагаем, что записи блока (т.е. файла) имеют фиксированный размер и
состоят из полей фиксированного размера и типа. В этом случае можно легко найти
абсолютный адрес записи в файле.
5. Закрепленные и незакрепленные записи.
Для определения стратегии реализации файлов важно, являются ли записи файла
«закрепленными» по некоторому фиксированному адресу, или нет.
Записи становятся закрепленными, если где-либо в базе данных могут существовать
(хранится) указатели на них.
При закреплении записей мы не можем перемещать записи об этих объектах, иначе
указатели на них «зависнут», т.е. не будут указывать на данные, на которые они
указывали первоначально.
При закреплении записей не может быть реализован общий случай организации файла,
при котором запись удаляется (например, при включении других записей или удалении
записей). В этом случае трудно найти, где именно в полной базе необходимо
откорректировать указатели на перемещаемые записи.
6. Организация файлов в виде «кучи».
Наиболее очевидный подход к хранению записей файлов заключается в
последовательном размещении их в необходимом числе блоков. Часто предполагается,
что запись не может перекрывать границу блока (часть блока теряется). Эту организацию
иногда называют «кучей».
Блоки, используемые для кучи, могут быть связаны в цепочку указателями (в конце
блока указатель на следующий блок). При другой организации выделяют отдельный блок
(блоки) в котором хранят список адресов блоков, образующих кучу.
Чтобы включить запись, её необходимо поместить в последний блок, если в нём
имеется место, или получить новый блок из операционной системы, если места в
последнем блоке больше нет.
Удаление может осуществляться установкой специального бита для каждой записью
(признак удаления) в состояние «удалено».
Пример: в файлах формата .dbf под признак удаления записи отводится целый байт.
Повторное использование пространства удаленных записей опасно, и может быть
осуществлено, если записи не закреплены. Для освобождения пространства с удаленными
записями используют процедуру «сборки мусора», которая освобождает для
использования пространство с удаленными записями.
Для поиска нужной записи (удовлетворяющей заданным условиям, например, при
заданном значении ключа) в общем случае требуется просмотреть все записи файла (в
«среднем» половину записей файла). Если число блоков, образующих файл велико, то
такой поиск требует большого количества доступов к внешней памяти и, следовательно,
приводит к снижению быстродействия БД. В следующих разделах лекций
рассматриваются методы ускорения доступа к информации при организации поиска.
Лекция №22
6
9
Название лекции: Хешированные файлы.
План:
1. Основной принцип организации хешированных файлов.
2. Выбор функции хеширования.
3. Схема организации хешированного файла.
4. Организация поиска в хешированном файле.
5. Модификация в хешированном файле.
6. Включение в хешированном файле.
7. Удаление в хешированном файле.
1. Основной принцип организации хешированных файлов.
Решается задача: по ключу найти запись.
Основная идея, лежащая в основе организации файлов с хешированным доступом,
состоит в разделении записей файла между участками, каждый из которых содержит один
или более блоков памяти. Для любого файла, хранимого таким образом, существует хешфункция (h), которая использует в качестве аргумента значение ключа, и вычисляет целое
число то нуля до некоторого максимального значения N.
Пусть v есть значения ключа. Тогда значение h(v) есть номер участка, в котором
должна находится запись с этим значением ключа, если она вообще присутствует в файле.
При выборе функции h желательно, чтобы h(v) принимала все её возможные значения
(от 0 до N) примерно с равной вероятностью, когда v принимает всевозможные
допустимые значения ключа.
2. Выбор функции хеширования сложная проблема (есть много литературы). Во многих
ситуациях полезна следующая стратегия:
1) Интерпретируем значение ключа как последовательность бит, сформированную
путем конкатенации значений всех полей ключа. Эта последовательность имеет
фиксированную длину, поскольку каждое поле имеет фиксированную длину.
2) Делим последовательность бит на группы, состоящие из фиксированного числа
бит. (из 16 бит). Последнюю группу при необходимости дополняем нулями.
3) Складываем полученные группы бит как целые числа.
4) Делим полученную сумму на число участков и используем остаток от деления как
номер участка.
m
Пример: n →как распределяется остаток от деления. m>n остаток [0, … n-1].
3. Схема
организации
хешированного файла.
Если N (число участков) мало,
то справочная участков может
находиться в основной памяти.
В противном случае он сам
(справочник)
может
быть
разделен между некоторыми
блоками и для организации
поиска блока с нужной частью
справочника
участков
необходим
ещё
один
справочник
(справочник
участков).
Рассмотрим
структуру
блока:
7
0
В каждом блоке предусмотрено место для размещения фиксированного числа
записей. Если запись требует r байт, то для чтения, например, пятой записи внутри блока
требуется сделать смещение 4r байт, от первого байта, следующего за заголовком блока.
Пространство, используемое для хранения одной записи будем называть субблоком.
Во «время жизни» файл может оказаться, что некоторый субблок свободен (запись из
него была удалена) в то время, как следующие за ним субблоки заняты. Для того, чтобы
как-то различать записанные и свободные субблоки возможны два метода:
в освобождаемый субблок помещают последовательность бит, которая никогда не
может появиться в записи (это описано, т.к.…пути господни неисповедимы).
в блоке отводят 1 бит на каждый субблок. Его нулевое значение – субблок свободен,
1– субблок занят.
Иногда отводят ещё один бит (в заголовке или в записи) который показывает была ли
удалена запись, что бы избежать повторное использование субблоков, на которые была
ссылка в случае закреплённых записей.
4. Организация поиска в хешированном файле.
Задача: найти запись с ключом v. (v– одно поле или список полей в фиксированном
порядке– тогда v конкатенация полей).
Вычислим h(v) получая номер участка i. Прочтём справочник участков и найдем адрес
первого блока участка i. Читаем первый блок, анализируем субблоки на совпадение
ключа. Если найдено – поиск успешен – конец. Если нет – читаем следующий блок
данного участка. Если его нет – поиск не успешно.
5. Модификация в хешированном файле.
Задача: изменить одно или несколько полей записи с ключом v.
1) Найти запись с ключом v. Если не найдена – аварийный останов.
2) Найдена запись:
а) среди модифицированных полей есть хотя бы одно, которое входит в ключ,
следовательно, удалить найденную запись из базы и затем добавить
измененную;
б) среди модифицированных полей нет ни одной, входящей в ключ,
следовательно, изменить в ОП и записать модифицированный блок по месту
(туда же).
6. Включение в хешированном файле.
Задача: добавить запись с ключом v.
1) Найти запись с ключом v (вычисляется номер участка, куда надо добавить запись).
Если запись найдена, аварийный останов. Иначе:
2) Найдем первый свободный субблок среди блоков участка h(v) (этот субблок может
быть в середине, если ранее было удаление с освобождением субблока, т.е. записи
не закреплены). Адрес этого субблока можно запомнить при поиски ключа v.
Помещаем запись в данный субблок → записываем блок на место. Если свободного
места нет → получаем свободный блок из OС. Организуем цепочку с последним
блоком участка h(v) → пишем блок на диск.
7. Удаление в хешированном файле.
Задача: удаление записи с ключом v.
1) Найти запись с ключом v. Если не найдена, то аварийный останов. Иначе:
2) Если запись найдена, то:
а) если записи не закреплены →бит свободен/занят в состояние свободен (при
следующем добавлении субблок будет использован);
7
1
б) если записи закреплены →бит свободен/занят не изменяется, а бит удалён
установить в состояние 1– удалён.
Если записи не закреплены, то возможно для удаления использовать следующий
алгоритм → последнюю запись файла переписать на место удаленной, а последний
субблок освободить.
Лекция №23
7
2
Название лекции: Анализ временных характеристик хеширования.
Индексированные файлы.
План:
1. Проблема реорганизации. Анализ временных характеристик хеширования.
2. Индексированные файлы.
3. Поиск в индексе.
1. Проблема реорганизации. Анализ временных характеристик хеширования.
Для каждой операции поиска, модификации, включения, удаления требуется:
обращение для чтения справочной участков (если весь справочник не помещается в
память) + число доступов, которое не превышает число блоков в данном участке. При
поиске в среднем просматривается половина блоков участка. Для всех операций, кроме
поиска, требуется ещё записать блок во внешнюю память.
Если каждый участок состоит ровно из одного блока (т.е. лучший случай) для поиска
требуется 2 обращения, для остальных 3. Чтобы уменьшить число блоков в участках
нужно число участков должно быть ≈ числу записей в файле/ на число записей в блоке.
При росте числа блоков требуется реорганизация. Её достаточно просто провести, если
ввести два ограничения:
1) При вычислении функции хеширования от ключа v получают очень большое число >>
чем число участков. Полученное число делят на число участков, остаток от деления –
номер участка.
2) При реорганизации число участков n умножают на некоторое фиксированное с
(обычно с = 2).
Если мы удвоим число участков, то все записи участка i будут попадать в участки i
или i+n и в эти участки не попадут никакие записи других участков.
Пусть по ключу v построим N=h(v) и N >>n– числа участков (если мы удвоим n то
N
i
получим N >>2n), разделим N на n и получим (1.) n =k+ n ; где: k–целое, i–остаток от
деления, 0 ≤i ≤n-1 номер участка. Из формулы 1: (2.) N= nk+i;
N
j
Удвоив число участков получим: (3.) 2n =m+ 2n ; формулу (1.) разделим на 2 и
k i
j
прировняем с (3.) (4.) 2 2n =m+ 2n ;
Рассмотрим два случая.
2l
i
j
i
j
=m+ ⇒l+
=m+
2 2n
2n
2n
2n ;
в формуле (5.) – равенство двух смешанных чисел, l и m – целые числа, таким образом это
целая часть смешанны числа равны → равны и целые части l = m , и равны и дробные
i
j
части 2n = 2n ⇒ j=i т.о. номер нового участка совпадает с номером старого участка.
1 i
j
2l 1 i
j
=m+
l+
=m+
2) k=2l+1 нечетное; (6.)
;
(7.)
2 2n
2n ; (8.)
2
2n
2n
n+i
j
l+
=m+
2n
2n ;
l=m → j=n+i,т.е. новый участок сдвинут по отношению к старому на n.
Таким образом при удваивании числа участков записи, находившейся в участке i будут
находится или в участке i или в участке i+ n, где n–старое число участков.
1) k=2l четное (5.)
2. Индексированные файлы.
7
3
Решается та же задача: поиск записи по ключу v.
Допустим, что записи в файле отсортированы по значениям этого ключа (обратить
внимание на сортировку дат dtos() и строк – лексикографическая сортировка). Для
нескольких полей: сортировка по первому ключу, при равных первых – сортировка по
второму и т.д.
В этом случае (файл отсортирован) для поиска можно использовать идею поиска в
телефонной книги (словаре), вместо просмотра всех записей. Будем анализировать только
первую запись на каждой странице. Если искомый ключ превышает ключ этой записи, то
возможно, что искомая запись находится на предыдущей странице. Если даже для
последней страницы искомый ключ меньше, чем первый на этой странице, то следует
проанализировать записи этой последней страницы.
Аналогично организован доступ к файлу. Пусть мы имеем отсортированный файл с
информацией, назовем его главным файлом. Создадим для главного файла второй файл–
так называемый разреженный индекс, состоящий из пар (значение_ключа, адрес_блока).
Пара (v,b) появляется в файле индекса, если первая запись в блоке главного файла с
адресом b имеет значение ключа v. Записи файла индекса подобно обыкновенному
(информационному) файлу с двумя полями : ключ и номер блока. Записи файла индекса
отсортированы по значению ключа и не являются закрепленными, т.к. нигде в другом
файле нет ссылки ни на какую запись файла индекса. Вероятно, что с файлом индекса, как
и с обычным (информационным) файлом следует выполнить операции включения,
модификации, удаления и кроме того необходима новая функция (вместо поиска): для
данного ключа v, найти такую запись ((v2 ,b2)| (v2 ≤ v1) ((следующая (v3,b3) | (v3 >v1)
(v2,b2) –последняя в файле)))
В этом случае говорят, что v2 перекрывает v1 (это значит, что если запись с ключом v1,
содержится в файле, то она может содержаться только в блоке b2, у которого первая
запись имеет ключ v2).
3. Поиск в индексе.
Требуется найти запись в основном файле с ключом v1.
Задача (для файла индекса): найти в файле индекса запись (v2,b2) такую, что
v2 покрывает ключ v1.
Решение: В простом случае (мало записей в индексе) – линейный поиск (условия
применения – весь индекс в основной памяти) Внимание! пояснить, что такое линейный
поиск.
Но и в этом случае выигрыш, т.к. если в блоке основного файла записано 'к' записей и
известно 1 запись в индексе организуется на первый блок основного файла, то в файле
индекса в 'к' раз меньше записей. Кроме того, обычно записи индекса короче, чем записи
основного файла и в 1 блок индекса помещается больше записей (появляется вероятность
размещение всего индекса в оперативной памяти).
Лучшая стратегия поиска в файле индекса – использование двоичного поиска. При
данной стратегии на каждом шаге количество блоков (при поиске записи (v 2,b2) –
покрывающих ключ v1) индекса, содержащих запись (v2,b2) сокращается вдвое.
Таким образом если в индексе n блоков, то не боле чем за log2(n+1) чтений будет
прогнан блок индекса, содержащий запись (v2,b2). В практике часто вместо оценки
log2(n+1) используют оценку log2n. С учетом доступов к основному файлу общее число
доступов – 3+ log2n (3 складывается из 1 – чтение справочника индекса, 1 – чтение блока
файла, 1 – запись блока файла).
Пример: Пусть в главном файле есть 106 записей. В блоке помещается 10 записей,
следовательно всего в файле 105 блоков. Пусть в один блок индекса помещается 100
записей, значит для индекса необходимо 1000 блоков. Таким образом, для доступа и
перезаписи блока основного файла требуется 3+ log2100013 обращений (log21024 =
log2210 = 10, т.о. log21024log2100010).
7
4
При исследовании хешированного файла (и условии 1 блок – 1 участок) необходимо 3
доступа, но имеется для индекса дополнительные преимущества возможность
поддерживать отсортированный порядок в файле (как минимум логическую
упорядоченность).
Метод поиска в индексе, который может превосходить по быстродействию двоичный
поиск, известен как интерполяция, или способ с помощью вычисления адреса. Этот метод
основан на значении статистики предполагаемого распределения значений ключа при
условии достаточной надежности этого распределения.
Пример: телефонная книга: известно, сколько необходимо «отступить» от правила,
чтобы найти нужную букву. Т.к. вы знаете алфавит.
Лекция №24
7
5
Название лекции: Операции над сортированным файлом с незакрепленными
и закрепленными записями.
План:
1. Операции над сортированным файлом с незакрепленными записями:
1.1. Поиск;
1.2. Модификация;
1.3. Включение;
1.4. Удаление.
2. Использование цепных файлов при индексной организации.
3. Организация сортированных файлов с закрепленными записями.
3.1. Инициализация;
3.2. Поиск;
3.3. Модификация;
3.4. Включение;
3.5. Удаление.
1. Операции над сортированным файлом с незакрепленными записями.
Операции (модификации, поиска, включения и удаления) над файлом требует таких же
операций над файлами индекса. Записи файла индекса всегда не закреплены, т.о. как
выполняются операции на основном файле (у которого записи не закреплены) так и
выполняются операции над файлом индекса.
Поиск записи: (найти запись с ключом v)
a) в индексе найти запись (v2,b2), где v2 покрывает v1;
b) прочитать блок b2 в оперативную память и искать запись с ключом v1 в
оперативной памяти каким-нибудь методом (двоичным или линейным). Если
найдено, то успешно.
При поиске проверять биты свободен/занят, удален/не удален.
Модифицирование:
a) найти запись с ключом v1, если нет то выход;
b) запись найдена. Если в ключ входит хотя бы одно из модифицированных полей, то
удаление из внешней памяти. Среди модифицированных полей нет ни одной
записи, в которую входит ключ, то изменить и записать на прежнее место.
Включение: (добавить запись с ключом v1)
a) новую запись надо добавить в 1 блок. v1 меньше, чем первая запись первого блока
значит первую запись в индексе надо изменить;
b) если v2≤v1не в первый блок, тогда в начало среднего блока никогда не добавится;
v2<v1 запись не будет первой; если v2=v1, то аварийный останов.
Т.о. если добавляется не в 1 блок, то файл индекса никогда не изменяется. Еще при
добавлении: - есть место в блоке – добавили и все; - если места в блоке нет, тогда
добавление новой записи в ОП в данный блок нужно отсортировать в порядке и дальше
этот блок делят: последнюю запись выталкивают в следующий блок, следовательно,
индекс модифицируется. Обработка последнего блока – выталкивать некуда, тогда надо
взять у OS новый блок.
Удалить: (запись с ключом v1)
a) найти запись с ключом v1, если не найдена, то ошибка;
b) запись найдена, то удаление производится сдвигом влево, начиная с записи
следующей за удаленной. Установка бита свободен/занят в состояние свободен.
Если удаляется первая запись в блоке, то корректируется индекс. Если после
удаления блок полностью пустой, то вернуть блок в OS и удалить запись из
7
6
индекса. Если она последняя и первая, то блок главного файла вернуть в OS и
удалить 1 запись из индекса.
2. Использование цепных файлов при индексной организации.
При выполнении операций включения иногда требуется найти следующий блок
главного файла. Эту процедуру можно упростить, если в заголовок каждого блока
поместить ссылку на следующий блок (цепная организация файла). Аналогично может
быть организованна структура файла индекса. При использовании линейного поиска в
индексе цепная организация позволяет избавится от справочника (таблицы) блоков
индекса (необходим лишь адрес его первого блока).
Организация сортированных файлов с закрепленными записями.
Если записи закреплены (пояснить), то не возможно (вообще говоря) поддерживать их
внутри блока в отсортированном порядке. Нет возможности даже гарантировать, что
записи предыдущего блока предшествуют записям последующего блока (относительно
некоторого ключа).
В этом случае каждый блок главного файла, на который имеется ссылка в индексе, как
первый блок цепочки блоков (участка– аналогично хешированию). При включении
записей в участок добавляется новые блоки, которые объединяются в цепочку. Кроме того
создается еще один пустой участок, в который будут включатся записи, предшествующие
первому участку. В этом случае индекс никогда не изменяется. Первые записи каждого
блока первоначального файла определяют распределение записей по участку, и это
распределение остается неизменным пока файл (участки) не достигнет больших размеров
и потребуется реорганизация файла.
Рассмотрим операции над таким файлом.
Инициализация: процедура формирования файла индекса по первоначальному
главному файлу называется – инициализацией.
Для инициализации отсортируем файл и распределим его записи по блокам. При этом
в каждом блоке выделим некоторое свободное пространство (несколько свободных
субблоков) которые при добавлении записи исключат на некоторое время рост цепочек в
участках главного файла. Кроме того, предусмотрим один пустой блок в участке,
предшествующем первому, куда будем помещать записи при расширении файла, и
которые будут предшествовать записям первоначального файла. Создадим индекс для
полученного файла, в том числе и для пустого блока. Запись в индексе для этого блока
должна содержать номер «пустого» блока и не содержать ключа.
Поиск: найти запись с ключом v1.
Найдем запись индекса, значение ключа которой покрывает требуемое значение ключа
v1. Если v1 меньше, чем первое значение ключа в файле индекса (заметим, что первичный
ключ находится во второй записи индекса), то требуемой записью индекса является
первая запись. По указателю на блок (из индекса) читаем первый блок цепочки (участка).
Чтобы найти ключ v1 просматриваем блоки данного участка, соединенных в цепочку.
Модификация: аналогично предыдущей.
Включение: добавить запись с ключом v1.
Поиск участка по ключу v1 . Просмотрим блоки участка, с целью найти свободное
место. Если свободного субблока нет, то получим из OS пустой блок и добавим его в
конец участка (пояснить). Включим новую запись в новый блок.
Удаление: поиск записи с ключом v1. Если запись найдена, то установка бита удален в
состояние «1» (запись удалена). Если данная запись не закреплена установка бита
свободен/занят в состояние свободен.
Лекция №25
7
7
Название лекции: В– деревья.
План:
1. Иерархия индексов как дерево.
2. Соглашения, принятые для организации В–деревьев.
3. Поиск в B- деревьях.
4. Модификация.
5. Включение.
6. Удаление.
1. Иерархия индексов как дерево.
Дать определение – сбалансированные деревья.
Рассмотрим случай незакрепленных записей главного файла. Индекс – это файл с
незакрепленными записями. Таким образом, для этого файла можно построить индекс
индекса. Далее индекс этого индекса и т.д. пока индекс не поместится в один блок. Такая
схема может быть более эффективна, одноуровневый индекс, и называется иерархией
индексов.
Общая схема для очень больших файлов основана на иерархии индексов,
соответствующей иерархической природе устройств внешней памяти.
Иерархию индексов можно организовать и независимо от иерархии структуры
внешних устройств.
Иерархию индексов можно рассматривать
как дерево (см. рисунок).
Операции
поиска,
модификации,
включения, и удаления над многоуровневыми
индексами являются простым обобщением
ранее рассмотренных методов. Проблема –
если индекс первого уровня превышает размер
1-го блока. Очевидно, что можно добавить ещё
один уровень (что не меняет алгоритмов
доступа). Таким образом, мы получим сбалансированное дерево, с неопределённым
(переменным) числом уровней. Дерево сбалансированное: длина пути от корня до любого
листа одинакова.
Для дальнейших рассуждений предполагаем, что записи главного файла не
закреплены. Хотя если записи закреплены, то можно, как и в предыдущем случае, считать,
что листья в дереве являются первыми блоками участков.
Как и раньше будем считать, что в листе дерева стоит указатель на блок главного
файла (случай, когда в листе стоит ссылка на запись главного файла, а не на блок,
называется плотным индексом, название от того, что в блоках главного файла нет
свободных мест (записи плотно распределены)).
Для операций включения и удаления над В–деревьями можно было бы использовать
туже стратегию, что и в предыдущем разделе, применяя операции включения и удаления к
узлам (блокам) дерева на всех уровнях. Тогда узлы содержали бы от одной записи до
максимально возможного их числа. Для В–деревьев обычно применяется другая стратегия
включения и удаления, которая обеспечивает наполняемость всех узлов (за исключением
корня) не менее чем на половину.
Соглашения, принятые для организации В–деревьев.
Для удобства организации индексных файлов в виде В–деревьев положим:
a) число записей индекса, которые могут содержатся в одном блоке, является числом
нечетным , и равным 2d-1≥3;
7
8
b) максимальное число записей главного файла в одном блоке также нечетное число,
равное 2е-1≥3;
c) для экономии пространства в блоках индекса В–дерева значения ключа в первой
записи опускается. При поиске будем считать, что все значения ключей, меньше
значения ключа во второй записи, покрывается его первым значением.
Рассмотрим функции доступа к главному файлу при использовании В–деревьев.
Поиск.
Задача: найти запись со значением ключа v.
Алгоритм поиска пути от корня В–дерева к некоторому листу, в котором будет
находится требуемая запись, если она существует. (рекурсивный алгоритм).
a) начало поиска от корня дерева. Устанавливаем текущий уровень дерева =1.
b) пусть рассматривается узел дерева с номером «i». Возможны две ситуации:
i – лист (это легко проверяется подсчетом текущего уровня дерева от корня и
сравнением этой величины полной длинной дерева). В этом случае проверим
находится ли запись с ключом v в данном блоке (главного файла). Если да –
успех, если нет – записи нет, конец алгоритма;
i – не лист, следовательно, i → блок индекса. Определим, какое значение ключа
в блоке В покрывает v (учитывая, что первая запись блока не содержит ключа и
первое значение покрывает все значения ключей, меньших значения ключа во
второй записи).
В блоке «i» для значения ключа, которое покрывает ключ v находим указатель на
другой блок.
c) увеличиваем текущий уровень дерева на 1 и повторяем данный алгоритм с пункта
b) для нового блока.
Модификация.
После поиска обработка ситуации:
a) нет записи;
b) хотя бы одно поле входит в ключ (запись удаляется из внешней памяти в
оперативную память, где она модифицируется, а потом снова записывается в
внешнюю память).
Включение.
Включить запись с ключом v.
a) найти блок «i» , к которому эта запись относится, если запись есть в блоке «i», то
аварийный останов;
b) в блоке i нет записи с ключом V:
если в блоке меньше, чем 2е-1 запись, то запись просто включается в блок в
отсортированном порядке. Эта запись некогда не может быть самой левой в
блоке, если только блок «i» не является самым левым листом, т.е. нет
необходимости изменять предшественника блока «i» (в индексе). Но в этом
случае предшественник по уровню не корректируется, т.к. первая запись
блока индекса не имеет ключа;
если в блоке 2е-1 записи (нет места) то создадим новый блок «i1». Разделим
записи этого блока с добавляемой, между двумя блоками «i» и «i1», по «е»
записей (было 2е-1 и добавляем 1 =2е).
Пусть теперь «j» - отец блока «i» (j- известен, т.к. при поиске мы построили путь от
корня к «i»). Применим данную процедуру включения к блоку «j» рекурсивно, но с
константой d (в блок «j» добавлена запись о блоке «i1»). Если многие предки блока
«i» заполнены полностью (по 2d-1 записей), то процедура расширения
распространяется на несколько уровней и может достигнуть корня дерева. Если и
7
9
он заполнен полностью, то его необходимо расщепить на два блока и получив у OS
еще один блок создать новый корень, в котором будет две записи (т.о. размер
дерева увеличится на единицу). При этом в корне в корне может быть меньше d
записей (если 2d-1>3).
Удаление.
Задача: удалить запись со значением ключа v.
a) найдем путь от корня дерева к блоку i, содержащую запись с ключом v;
b) если записи нет, то ошибка. Если запись есть удалим эту запись пересортируем.
Если после удаления в блоке не менее «е» записей, то если эта запись первая, тогда
возможно требуется изменить индексный файл на предыдущих уровнях. Однако
коррекции не будет подвергаться отец блока «i» (т.к. у него первая запись не имеет
ключа). Но возможно другие предки имеют запись с ключом v, которая не является
первой. Т.о. от блока «i» следует двигаться в верх к корню, и в случае, если
обнаружится такая запись, то её следует удалить, применив данную процедуру.
Реверсивно с константой d. (Хотя удалять и не обязательно, всё равно дерево будет
работать как индекс). Если после удаления в блоке «i» менее «е» записей (т.е. е-1
записей), то рассмотрим соседних братьев (в том же уровне) блока «i», имеющих
того же отца, что и блок «i». Если среди братьев есть блок «i», с числом записей
больше чем «е», то распределить записи этих двух блоков (всего каких записей е<
3/2(е-1) < 2е-1) равномерно между двумя блоками «i» и «i1», сохраняя
отсортированный порядок. При этом возможно необходимо откорректировать
предков «i». Если все братья «i» содержат ровно «е» записей, то соединим записи
блоков «i» и любого соседнего блока «i1» (у них всего 2е-1 записей) и т.о. все
записи поместятся в один блок. Такое удаление потребует модификации и
рекурсивного применения процедуры удаления к предкам «i» , заменив константу е
на константу d. При этом, возможно, необходимо удалить корень и объединённые
блоки на предыдущем корню уровне образуют новый корень – размер дерева
уменьшается на единицу.
Пример: d=2, е=2. Дерево содержит квадраты чисел.
Добавим запись с ключом 32.
Ищем блок, в который необходимо добавить – это i7, но в нем нет места значит делим его
на 2:
В i3 надо добавить 36.
В i3 нет места
это вместо 64
Добавляем в i1 64, которое ссылается на i3, добавляем блок i14 и i15
8
0
Удалим запись с ключом 64.
Найти блок, это i8 и удаляем 64. Новый ключ – 81, распределяем вверх изменяем в i15
значение ключа 64 на 81 (всегда изменяем ровно 1 ключ). Но блок i8 содержит 1 запись,
заполнен меньше, чем на половину и имеется блок i9, в котором меньше, чем 2е-1 запись,
т.е. 2 и соединяем его с блоком i8. У i13 единственный сын необходимо удалить запись с
ключом 100 из блока i13 и, следовательно, соединить его с i4, теперь вторая ссылка в этом
блоке должна быть 144. Блок i13 обладает указателями на i10 и i11. Значение ключа,
сопровождающее указатель на i11 находится в i4, тогда как значение ключа 144 для блока
i10 в i14. Вообще, если мы объединяем блоки при удалении, необходимое значение ключей
содержатся либо в объединяемых блоках, либо в блоке, являющемся их общим отцом.
При объединении i13 и i4 оказывается, что у i14 существует единственный сын, поэтому
объединяем i14 с i1. теперь у i15 один сын. Т.к. он корень, то удаляем его.
и т.д.
Лекция №26
8
1
Название лекции: Анализ временных характеристик над В–деревьями.
План:
1. Анализ временных характеристик над В–деревьями.
2. Файлы с плотным индексом.
3. Преимущество плотного индекса.
4. Файлы с записями переменной длины. Основные стратегии решения и методы
реализации.
5. Структуры данных для организации поиска по не ключевым полям:
5.1. Вторичные индексы (инвертированные файлы);
5.2. Поиск по частичному соответствию.
1. Анализ временных характеристик над В–деревьями.
Рассмотрим файл с n записями, организованный в виде В–дерева с параметрами d и e,
где d – параметр файла, e – параметр индекса. Оценка листьев: предположим, что все
блоки заполнены по минимуму. Количество записей в блоке 2е-1, количество в главном
файле n/е листьев, количество блоков в индексе n/dе, на следующем уровне n/d2е. Если
n
n
путь от корня к листу i , то d i− 1 e ≤ 1 ; но корень только один ⇒ d i− 1 e = 1 ; ухудшим эту
n
i− 1
оценку ⇒ d i− 1 e ≥ 1⇒n≥ d e ;
log 2 n≥ i− 1 log 2 d+ log 2 e
i∗ log 2 d− log 2 d+ log 2 e≤ log 2 n
n
i∗ log 2 d − log 2 d ≤ log 2
e
n
log 2
e
i− 1≤
log 2 d
n
log 2
e
n
i≤ 1
= 1 log d
log 2 d
e
n
i≤ 1 log d
e
чтобы выполнить поиск достаточно i операции чтения. Для операции включения,
удаления или модификации необходимо написать лишь один блок лист, содержащий
запись. В сложных случаях требуется еще не более i операции чтения и записи. Такой
анализ сложен. Показано что даже при d=2 и е=2 среднее число дополнительных операций
(сверх i чтений и одной записи) представляет собой правильную дробь, то есть число
меньше единице и ей можно пренебречь. Таким образом, общая оценка числа доступов:
2+logd (n/e)
Пример: если n=106; е=5 и d=50 ожидаемое число операций чтение–запись:
2+log50200000≤6 это хуже, чем у хеширования (около 3-х), но лучше, чем у
одноуровневых индексов.
Файлы с плотным индексом.
Пусть нет необходимости поддерживать файл в отсортированном порядке. Допуская
возможность хранения записей в произвольном порядке, можно избегать появления в
главном файле большого числа частично заполненных блоков. При этом облегчается
8
2
операция включения, для чего необходимо хранить только адрес последнего блока в
файле и добавлять в него новую запись (при его заполнении получить адрес нового блока
из OS). Если удаления производятся часто, то в файле появляются незаполненные места.
Можно просто игнорировать тот факт, что определенные субблоки становятся при
удалении свободными. (Напомнить технологию DELETE–PACK). Другой подход–
использование отдельного файла с записями, содержащими одно поле, которое является
указателем на блок с одним или более свободными субблоками (или хранить указатель на
свободный субблок– кратко о безпаковочной технологии в DBF-файлах (INDEX с
опциейFOR)).
При использовании не сортированного файла проблема заключается в организации
поиска записей по заданному значению ключа.
Для организации такого поиска используют еще один файл, который называется
плотным индексом.
Одна запись плотного индекса соответствует одной записи главного файла. Структура
записи индекса: (v,p); где v–ключ записи главного файла, р – указатель на запись
главного файла с ключом v.
Для плотных индексов возможна многоуровневая организация в виде В–дерева.
Отличие от разреженного индекса в том, что при том же размере дерева в плотном
индексе листья– ссылки на записи главного файла, а в разряженном – блоки главного
файла. Т.о. при модификации, включении и удалении требуется на два доступа больше,
чем в разряженном индексе (после чтения индекса надо читать еще блок главного файла и
+ еще записать при модификации - это недостаток).
Внимание! При использовании плотного индекса записи главного файла закреплены.
Преимущество плотного индекса.
1) Записи главного файла могут быть закреплены, но записи индекса всегда не
закреплены, следовательно, можно использовать более простую организацию и
функции доступа к индексу. Нет понятия «участков» как в разряженном индексе.
2) Если записи главного файла длинные, то общее число блоков меньше, чем у
разряженного индекса, т.к. все блоки (кроме последнего) заполнены плотно.
Файлы с записями переменной длины.
Постановка задачи: В файле одно или несколько полей имеют переменную длину.
Пример: 1) ФИО.
2) Адрес.
3) Название банка.
4) Комментарии к платежному поручению.
5) Список номерных знаков, закрепленных за а/т.
6) Список детей данного сотрудника.
Обозначение записи переменной длины α(β)*= αβ1β2…βn , где α- постоянная часть.
Основные стратегии решения.
1) Запись переменной длины заменяется одной или несколькими записями
фиксированной длинны.
2) Использование принципа – конец записи (конец поля).
Качество стратегии характеризуется двумя показателями:
1) Объемом дискового пространства, которое занимает файл с записями переменной
длинны.
2) Временем доступа к записям файла.
Небольшую экономию дискового пространства предоставляет вторая стратегия, но это
стратегия обычно требует и большого времени доступа.
Файловые системы персональных ЭВМ обычно не содержат функций организации и
доступа к файлам с переменной длинной записи. Такие функции имелись в OS IBM 360.
8
3
Таким образом, реализация второй стратегии возможна только за счет программного
обеспечения самой СУБД.
Пример: Представить, как необходимо переделать функции доступа к файлу формата
DBF, что бы реализовать доступ к файлу с записями переменной длинны.
Варианты реализации первой стратегии значительно и могут быть реализованы
прикладными программистами.
Известны 3 метода реализации 1-й стратегии.
I. Метод зарезервированного пространства.
Рассмотрим методы на примере задачи: за а/т закрепляется несколько номеров гос.
регистрации (оперативная работа уголовного розыска).
1) Резервируется максимально возможное число полей. Заполняется часть полей. В
первое свободное поле записать признак – поле свободно.
Пример: База AUTO.DBF, поля SIGN ,SIGN1, SIGN2.
2) Два поля комментария для платежных поручений.
3) Одно поле большой длинны для адреса.
4) Шаблон для З.П.
Преимущества: скорость доступа ко всей информации.
Недостатки: большие потери в занимаемом на диске пространстве, если вероятность
появления записи с большой длинной мала.
II.
Метод указателей.
В основной записи указатель на начало списка из записей фиксированной длинны (в
том числе возможно и из другого файла) следовательно цепной список.
Пример: 1. Мемо поля Fox.
2. Организация списков с помощью индексов.
DO SCAN WHILE
.
.
.
ENDSCAN
Большое время доступа. Особенно невыгодно, если вероятность появления записи
малой длинны мала.
III.
Комбинированный метод.
Если среднее и максимальное число блоков существенно различаются, то при
резервировании по максимуму больше число блоков не используется.
Методы доступа с указателями экономят место, но повышается время доступа.
Компромисс: резервируют несколько полей (блоков), при их заполнении выделяют
новый блок (организуют список).
Пример: С базой AUTO.DBF: резервируем одно поле SIGN, а для других записей
организуем список в дополнительной базе. Только в основной базе необходимо
предусмотреть: есть информация в списке (например, логического типа).
Операции над записями переменной длины соответствуют операции над списками.
Структуры данных для организации поиска по не ключевым полям.
Гибкая система БД позволяет получать по запросам информацию из полей,
идентифицируемых значениями полей или поля, которые не образуют ключ.
В FoxPro используют LOCATE– недостаток – большое время доступа.
Вторичные индексы (инвертированные файлы).
Пусть имеется файл, записи которого содержат некоторое поле F. Это поле принимает
возможные значения из множества D, домена поля F. F может входить или не входить в
ключ.
Вторичный индекс по полю F представляет собой связь между доменом D и
множеством записей рассматриваемого файла (ранее рассматриваемые индексы
8
4
связывают значение ключа с записями файла – называется первичным индексом). Файл с
вторичным индексом по полю F называется инвертированным по полю F.
В нотации записей переменной длинны вторичные индексы имеют вид:
Значение (запись)*
где «значение»– значение поля F из домена, (запись)*– список ссылок на записи
основного файла.
Если в список входят физические указатели на запись (номера записей) следовательно
запись основного файла закреплена.
Если в список – список уникальных ключей основного файла следовательно запись не
закреплена, но требуется дополнительные операции поиска по ключам.
Пример: цвет (список инв. номеров с данным цветом).
Поиск по частичному соответствию.
Требуется найти запись со значением v1 поля F1, v2 поля F2 … vк поля Fк . Эти поля не
образуют полного первичного ключа. Если Si есть множество записей, для которой Fi
имеет значение vi то требуется найти:
S
S
......
S
1
2
k
Рассмотрим методы решения.
Использование множественного вторичного индекса. Достаточно пересечь
вторичные индексы (возможно в оперативной памяти). Недостаток: поддержка
индексов при включении и удалении. Пример: система «ADABAS».
Функции разделенного хеширования. В хеш – файле число участков 2n. Логический
адрес n бит. Разделим n бит на k групп. Одна i-тая группа соответствует одному
полю Fi . Для каждой группы построим свою хеш – функцию hi (Vi). В качестве
номера участка примем последовательность бит: h1 (V1) h2 (V2)… hk (Vk). Сумма
длин всех участков равна h. Каждое значение Vi переведем в часть ключа hi (Vi),
построим общий ключ →поиск в построенном номере участка.
