Лекция 3

1. Классификация сущностей. Двенадцать правил Кодда для определения концепции реляционной модели

Лекция №3

2. Сущность

Сущность - некоторый обособленный объект или
событие, информацию о котором необходимо сохранять в базе
данных, имеющий определенный набор свойств атрибутов.
Сущности могут быть:
Физические (СТУДЕНТ, атрибуты - № зачетной книжки,
фамилия, его факультет, специальность, № группы и т.д.)
Абстрактные (ЭКЗАМЕН, атрибуты - дисциплина, дата,
преподаватель, аудитория и пр.)
Для сущностей различают ее тип и экземпляр. Тип
характеризуется именем и списком свойств, а экземпляр конкретными значениями свойств.

3. Набор сущностей

Набор сущностей — это набор похожих
типов
сущностей,
которые
совместно
используют одни и те же атрибуты. Например:
Все учащиеся школы представляют собой набор
сущностей УЧАЩИЕСЯ.

4.

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

5.

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

6. Слабый набор сущностей

Слабая
сущность
не
может
существовать сама по себе; она зависит
от
сильной
сущности,
которая
ее
идентифицирует. У слабой сущности нет
единственного первичного ключа, который
бы
ее
однозначно
идентифицировал;
вместо этого у нее есть частичный ключ.
Пример набора слабых сущностей
включает:
• Цвет ноутбука
• ОЗУ и т.д.

7. Виды сущностей

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

8. Типы сущностей в СУБД

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

9. Двенадцать правил Кодда для определения концепции реляционной модели

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

10.

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

11.

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

12.

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

13.

10. Правило независимости условий целостности.
Должна существовать возможность определять
условия целостности, специфические для конкретной
реляционной базы данных, на подъязыке реляционной
базы данных и хранить их в каталоге, а не в
прикладной программе.
11. Правило независимости распространения.
Реляционная СУБД не должна зависеть от
потребностей конкретного клиента.
12. Правило единственности. Если в реляционной
системе есть низкоуровневый язык (обрабатывающий
одну запись за один раз), то должна отсутствовать
возможность использования его для того, чтобы
обойти правила и условия целостности, выраженные
на реляционном языке высокого уровня
(обрабатывающем несколько записей за один раз).