Трехуровневая архитектура ANSI-SPARC

1.

Карагандинский технический университет
Кафедра ИВС
Дисциплина «Проектирование баз данных»
Специальность 5В070300 «Информационные системы»
Тема: «Трехуровневая архитектура ANSI-SPARC»
Лектор: старший преподаватель
кафедры ИВС Саданова Б.М.

2.

План лекции:
1. Понятие предметной области
2. Архитектура ANSI-Sparc. Уровни архитектуры
3.Концептуальный этап проектирования БД.
сущность, атрибут, связь.
4. Этапы концептуального проектирования БД
5. Логический этап проектирования БД
6. Этапы логического проектирования БД
7. Физический этап проектирования БД
8. Этапы физического проектирования БД
Понятия
Цель лекции: дать представление об архитектуре ANSI-Sparc, этапах
проектирования баз данных, а также конкретном содержании каждого из
этапов.

3.

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

4.

В теории проектирования информационных систем
предметную область принято рассматривать в виде трех
представлений:

5.

Предметную область представляют
называемой архитектуры ANSI-Sparc.
на
базе
так
Наиболее важным аспектом этой архитектуры является
определение трех различных уровней описания
предметной области.
Цель такого трехуровневого представления предметной
области заключается в отделении пользовательского
представления о БД от ее физического представления.

6.

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

7. Архитектура ANSI-SPARC

8. Архитектура ANSI-SPARC

1. Внешний уровень
•верхний уровень архитектуры ANSI-Sparc
•состоит
из
нескольких
различных
внешний
представлений БД.
•Например, каждый пользователь имеет дело с
представлением «реального мира», выраженным в
наиболее удобной для него форме (например, один
пользователь может просматривать даты в формате
ДД.ММ.ГГ, а другой – ГГ.ММ.ДД).

9. Архитектура ANSI-SPARC

2. Концептуальный уровень :
• это обобщающее представление БД, включающее все
внешние представления.
• описывает то, какие данные хранятся в БД, а также связи,
существующие между ними, то есть логическую структуру
БД (с точки зрения администратора БД).
• не содержит никаких сведений о методах хранения данных
3. Внутренний уровень :
• нижний уровень архитектуры ANSI-Sparc
• физическое представление БД в компьютере.
• описывает, как информация хранится в БД.

10. Этапы, на которые разбивается процесс проектирования базы данных:

Концептуальное проектирование
Логическое проектирование
Физическое проектирование

11.

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

12. Различие уровней представления данных на каждом этапе проектирования

13. Этапы концептуального проектирования БД

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

14. На концептуальном уровне оперируют понятиями: сущность, атрибут, связь

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

15. На концептуальном уровне оперируют понятиями: сущность, атрибут, связь

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

16. На концептуальном уровне оперируют понятиями: сущность, атрибут, связь

Атрибуты
Простые и
составные
Однозначные
и
многозначные
Производные

17.

Простой (элементарный) атрибут – атрибут,
состоящий из одного компонента с независимым
существованием, они не могут быть разделены на
более мелкие компоненты. Пример : пол, цвет.
Составной атрибут – атрибут, состоящий из
нескольких
компонентов,
каждый
из
которых
характеризуется
независимым
существованием.
Например, атрибут адрес может быть разбит на более
мелкие компоненты – город, улица, номер дома, номер
квартиры.
Решение о моделировании атрибута в виде простого
или составного зависит от того, как рассматривается
атрибут в пользовательских представлениях.

18.

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

19.

Наименование атрибута должно быть уникальным для
конкретного типа сущности, но может быть одинаковым
для различных типов сущностей.
Пример: ЦВЕТ может быть определен для сущностей
СОБАКА, АВТОМОБИЛЬ, ТКАНЬ .
Атрибуты используются для определения того, какая
информация должна быть собрана о сущности.
Примеры атрибутов для сущности АВТОМОБИЛЬ: ТИП,
МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.

20.

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

21.

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

22.

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

23.

Классификация типов сущностей
Каждый
экземпляр
этой
сущности
невозможно
идентифицировать только с помощью атрибутов этой
сущности, так как однозначно идентифицировать каждое
пожелание клиента можно, только если учитывать связь
конкретного пожелания с некоторым клиентом, который
однозначно идентифицируется первичным ключом сущности
клиент (Код, ФИО).
В данном примере сущность Пожелания рассматривается как
зависимая в своем существовании от сущности клиент – в нее
нужно ввести дополнительное поле (Код арендатора, Тип
объекта, Условия ренты).
Сущности слабого типа принято называть дочерними,
зависимыми, подчиненными.
Сущности сильного типа – родительскими, владельцами,
доминантными.

24.

Описание сущностей
Способы
описания
сущностей
Текстовое
описание
Кошка
(Кличка, пол,
вес, окрас,
темперамент)
Схематичное
описание
Модель
«сущность-связь»
(Entity-Relation
model, ERмодель).
Язык
"Таблицасвязь.

25.

Описание сущностей
В диаграммах ER-модели тип сущности представляется в
виде прямоугольника, содержащего имя типа сущности,
атрибуты – овалами, содержащими имя атрибута. При этом
имя сущности - это имя типа, а не некоторого конкретного
экземпляра этого типа.
Язык "Таблица-связь. В нем все сущности изображаются
одностолбцовыми таблицами с заголовками, состоящими из
имени
типа сущности. Строки таблицы – это перечень
атрибутов сущности. Атрибут первичного ключа обозначается
как (РК). За сложным атрибутом принято приводить список
простых составляющих его атрибутов, обозначенный
отступом справа. Производные атрибуты отмечаются
префиксом в виде косой черты (/).

26.

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

27.

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

28.

Кратность связи – количество возможных экземпляров
сущности некоторого типа, которые могут быть связаны с
одним экземпляром сущности другого типа с помощью
определенной связи.
Среди
бинарных
связей
фундаментальных вида связи:
один к одному (1:1),
один ко многим (1:M),
многие ко многим (M:N).
существуют
три

29.

Связь один к одному (1:1) существует, когда один
экземпляр одной сущности связан с единственным
экземпляром другой сущности.
В каждый момент времени каждому представителю
(экземпляру) сущности А соответствует 1 или 0
представителей сущности В
Пример: СТУДЕНТ может не "заработать" СТИПЕНДИЮ,
получить обычную или одну из повышенных СТИПЕНДИЙ.

30.

Связь один ко многим (1:M) существует, когда один
экземпляр одной сущности связан с одним или более
экземпляром другой сущности и каждый экземпляр второй
сущности связан только с одним экземпляром первой
сущности.
Одному представителю сущности А соответствуют 0, 1
или несколько представителей сущности В.
Пример : КВАРТИРА может пустовать, в ней может жить
один или несколько жильцов; СТУДЕНТ может изучать
одну или несколько ДИСЦИПЛИН.

31.

Связь многие ко многим (М:N) существует, когда один
экземпляр одной сущности связан с одним или более
экземпляром другой сущности и каждый экземпляр второй
сущности связан с одним или более экземпляром первой
сущности.
Пример: СТУДЕНТ может изучать много ДИСЦИПЛИН и
одна
ДИСЦИПЛИНА
может
изучаться
многими
СТУДЕНТАМИ

32.

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

33. Этапы логического проектирования БД

1. Устранение особенностей локальной логической
модели, несовместимых с реляционной моделью
(необязательный этап)
2. Проверка отношений с помощью правил нормализации
3. Проверка
соответствия отношений требованиям
пользовательских транзакций
4. СУБД ориентированное описание модели данных
5. Определение
требований поддержки целостности
данных

34.

1. Устранение особенностей локальной логической
модели, несовместимых с реляционной моделью
(необязательный этап)
Назначение этапа : удаление двухсторонних связей «многиеко-многим»; удаление многозначных атрибутов.
Если в концептуальной модели присутствует связь (*:*), то
лучше выполнить декомпозицию этой связи для выявления
промежуточной сущности. Связь *:* заменяется двумя
связями 1:*, в которых участвует выявленная сущность.
Многозначный
атрибут
хранит
несколько
значений,
соответствующих одной сущности. Можно выполнить
декомпозицию атрибута. (Если человек может иметь
несколько телефонов, то можно ввести новую сущность
Телефон, убрав атрибут Телефон из сущности Работник)

35.

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

36.

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

37.

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

38.

5. Определение требований поддержки целостности
данных
Ограничения целостности данных вводятся с целью
предотвратить появление в БД противоречивых данных.
Существуют пять типов ограничений целостности данных:
1. обязательные данные (некоторые атрибуты не могут
иметь
пустого
значения,
например,
являющиеся
первичными ключами);
2. ограничения для доменов, которые устанавливаются при
определении доменов атрибутов;
3. целостность сущностей;
4. ссылочная целостность;
5. ограничения предметной области.

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45. Этапы физического проектирования БД

1. Проектирование базовых отношений в среде СУБД
2. Проектирование отношений, содержащих производные
данные
3. Реализация ограничений предметной области
4. Проектирование физического представления БД
5. Выбор файловой структуры
6. Определение индексов
7. Разработка механизмов защиты

46.

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

47.

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

48.

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

49.

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

50.

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

51.

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

52.

4. Проектирование физического представления БД
Наибольшее влияние на производительность системы
имеют 4 компонента аппаратных средств:
1. оперативная память;
2. процессор;
3. дисковый ввод/вывод;
4. сеть.
Каждый из этих ресурсов оказывает влияние на
остальные системные ресурсы. Поэтому улучшение
показателей использования одного ресурса может
положительно сказаться на состоянии других ресурсов.

53.

4. Проектирование физического представления БД
Например, увеличение объема оперативной памяти
вызывает снижение интенсивности страничного обмена и
как следствие уменьшение нагрузки на процессор; более
эффективное
использование
ОЗУ
приводит
к
уменьшению
количества
операций
дискового
ввода/вывода.
К основным принципам распределения данных по
дисковым
устройствам
можно
отнести:
файлы
операционной системы должны быть отделены от
файлов базы данных; основные файлы базы данных
должны быть отделены от индексных файлов; журнал
восстановления должен быть отделен от основной части
БД.

54.

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

55.

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

56.

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

57.

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

58.

6. Определение индексов
Файл, содержащий логические записи, называется
файлом данных, а файл, содержащий индексные записи,
- индексным файлом. Значения в индексном файле
упорядочены по полю индексирования, которое обычно
строится на базе одного атрибута.
Типы индексов:
1) Первичный индекс. Файл данных последовательно
упорядочивается по полю ключа упорядочения, а на
основе поля ключа упорядочения создается поле
индексации, которое гарантированно имеет уникальное
значение в каждой записи.

59.

6. Определение индексов
2) Индекс кластеризации. Файл данных последовательно
упорядочивается по неключевому полю и на основе этого
неключевого поля формируется поле
индексации,
поэтому в файле может быть несколько записей,
соответствующих значению этого поля индексации.
Неключевое поле называется атрибутом кластеризации.
3) Вторичный индекс. Индекс, который определен на поле
файла данных, отличном от поля, по которому
выполняется упорядочение.

60.

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

61.

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

62.

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

63. Контрольные вопросы:

1. Что такое предметная область? Приведите примеры
2. Что такое архитектура ANSI-Sparc?
3. Уровни архитектуры ANSI-Sparc? Опишите назначение
каждого уровня
4.Этапы проектирования баз данных
5.Назначение концептуального этапа проектирования БД
6.Назначение логического этапа проектирования БД
7.Назначение физического этапа проектирования БД

64. Список литературы:

1. Т.
Конноли.
Базы
данных.
Проектирование,
реализация и сопровождение. Теория и практика.:
Пер.с англ. – М.: Изд.дом «Вильямс», 2012. – 1440 с.
2. К.Дейт. Введение в системы БД. изд.6-е. :Пер.с англ.
- М.: Изд.дом "Вильямс", 2014. – 1200с.
3. Д.Ульман. Введение в системы баз данных. – М.:
Издательство «Лори», 2015. – 853с.