
- •Конспект лекций
- •Раздел «бд. Субд. Основные понятия» 8
- •2. Жизненный цикл баз данных
- •3 Эксплуатационные характеристики базы данных
- •Раздел «бд. Субд. Основные понятия»
- •4. Управление параллельным доступом.
- •Раздел «бд. Субд. Основные понятия» Лекция №3 Место баз данных в архитектуре ис
- •1 Локальные ис
- •2 Ис в файл-серверной архитектуре
- •3 Ис в клиент-серверной архитектуре
- •4 Двухзвенные модели архитектуры
- •5 Трехзвенные модели
- •6 Монитор транзакций
- •7 Ис в Internet и intranet
- •Раздел «Концептуальный уровень проектирования бд» Лекция №4 Концептуальная модель данных. Сущности, атрибуты, ключи
- •1 Основные понятия
- •2 Задачи моделирования данных
- •3 Сущности
- •4 Атрибуты
- •5 Ключи
- •Раздел «Концептуальный уровень проектирования бд» Лекция №5 Концептуальная модель данных. Связи. Классы и подклассы. Концептуальная схема
- •1 Связи
- •2 Классы и подклассы
- •3 Источники данных для концептуального проектирования
- •4 Построение концептуальной схемы
- •5 Анализ концептуальной модели
- •Раздел «Логический уровень проектирования бд»
- •3.3 Реляционная модель
- •3.4 Объектно-реляционная модель
- •3.5 Объектно-ориентированная модель данных
- •3.6 Модель данных на основе xml
- •Раздел «Реляционная теория бд» Лекция №7 Реляционная модель данных. Основные понятия
- •1 Словарь терминов
- •2 Целостность реляционной модели
- •3 Математическое описание реляционной модели
- •Раздел «Реляционная теория бд» Лекция №8 Реляционная алгебра и реляционное исчисление
- •1 Реляционная алгебра. Теоретико-множественные операции
- •2 Реляционная алгебра. Специальные реляционные операции
- •3 Дополнительные реляционные операции
- •4 Примеры записи запросов
- •5 Реляционное исчисление
- •Раздел «Реляционная теория бд» Лекция №9 Нормализация реляционной модели. Функциональные зависимости
- •1 Что такое нормализация?
- •2 Функциональная зависимость
- •3 Теоремы о функциональных зависимостях
- •5 Алгоритм нормализации отношений. Метод декомпозиции
- •6 Другие нормальные формы
- •Раздел «Реляционная теория бд»
- •1.2 Связь частичная для одной из сущностей
- •1.3 Связь частичная для обеих сущностей
- •2 Реализация бинарной связи 1:m («один-ко-многим»)
- •2.1 Связь обязательная для m-связной сущности
- •2.2 Связь частичная для m-связной сущности
- •3 Бинарная связь n:m («многие-ко-многим»)
- •4 Связи более высокого порядка (n-арные)
- •5 Классы и подклассы
- •Раздел «Реляционная теория бд» Лекция №12 Стандарт idef1x
- •1 Стандарты моделирования данных
- •2 Основные понятия стандарта idef1x
- •3 Графический язык idef1x
- •Раздел «Физический уровень проектирования бд» Лекция №13 Физическая модель данных
- •1 Исходные данные для физического проектирования
- •2 Возможная методика перехода к физической модели на примере реляционной модели
- •2.1 Преобразование отношений в таблицы
- •2.2 Преобразование атрибутов в поля (столбцы) таблиц
- •2.3 Преобразование доменов в типы данных
- •2.4 Первичные ключи
- •2.5 Порядок расположения столбцов
- •2.6 Создание ссылочных ограничений
- •3 Факторы, влияющие на производительность бд
- •3.1 Индексы
- •3.2 Денормализация
- •Раздел «Язык sql» Лекция №14 Введение в язык sql. Команда Select
- •1 Стандарты
- •2 Возможности sql
- •3 Запросы на выборку данных
- •4 Примеры запросов
- •Раздел «Язык sql» Лекция №15 Команды определения данных
- •1 Команда create table
- •2 Команда alter table
- •3 Поддержка ограничений целостности
- •4. Редактирование записей в таблице
- •Раздел «Язык sql» Лекция №16 Дополнительные аспекты реляционной технологии
- •1 Проблемы, требующие решения
- •2 Запросы
- •3 Представления
- •4 Курсоры
- •5 Хранимые процедуры
- •6 Триггеры
- •7 Функции, определяемые пользователем
- •8 Транзакции
4 Атрибуты
Атрибут – это характеристика или свойство сущности.
Рассмотрим возможные критерии определения атрибутов сущности:
атрибут, как правило, отвечает на вопрос: «Какую информацию о сущности необходимо хранить в базе данных?»;
атрибут не имеет состава, или его составные части никогда не рассматриваются отдельно в рамках моделируемой предметной области;
атрибут не имеет собственных атрибутов.
Например, для сущности СТУДЕНТ получен следующий список атрибутов: Фамилия, Имя, Отчество, Дата рождения, Адрес проживания, Шифр направления обучения и др. Удалим из этого списка атрибут, который, скорее всего, принадлежит другой сущности, – Шифр направления обучения. Проверим, есть ли среди оставшихся атрибутов такие, которые имеют состав и, следовательно, могут быть перенесены в список сущностей. Таких атрибутов два: Дата рождения и Адрес проживания. Принять решение по этим атрибутам можно путём исследования возможных запросов к базе данных. Например, если установлено, что Дата рождения во всех запросах рассматривается как единое целое (число, месяц, год), то такой атрибут является собственным атрибутом сущности СТУДЕНТ. Если установлено, что существуют задачи, в которых требуется узнать, кто из студентов проживает на конкретной улице, в конкретном районе или городе, то есть поиск ведётся по структурным частям адреса, то Адрес проживания удаляется из списка атрибутов и переносится в список сущностей.
При формировании списка собственных атрибутов каждой сущности необходимо задавать и/или выбирать уникальные имена атрибутов, избегать использования для этих целей омонимов (ключ, замок и т.п.) и синонимов. Имена атрибутов должны быть понятны специалистам предметной области. Не рекомендуется использовать сложные сокращения, редко используемые аббревиатуры и приёмы, характерные для выбора идентификаторов переменных и других объектов в программировании.
После уточнения имен атрибутов необходимо определить множество допустимых значений каждого атрибута, используя для этих целей любые известные способы:
- указание типа данных, например, число, текст и т.д.;
- тип данных и диапазон, например, число < 1000;
- использование классификаторов и кодификаторов, например, справочник почтовых индексов;
- список допустимых значений, например, {Очная, Заочная} и т.д.
Для каждого атрибута необходимо оценить возможность принимать неизвестное значение (NULL - значение). Например, для сущности СТУДЕНТ атрибут № домашнего телефона может быть неизвестным.
5 Ключи
Ключ состоит из одного или более атрибутов, значения которых однозначно идентифицируют экземпляр сущности, например, № паспорта – ключ личности, по нему один экземпляр сущности ЛИЧНОСТЬ отличается от другого экземпляра.
Каждая сущность может иметь несколько ключей, но должна иметь, по крайней мере, один ключ. Такие ключи называются потенциальными ключами.
У каждой сущности есть один и только один первичный ключ, который выбирается из потенциальных ключей.
Критерии выбора первичного ключа:
- ключ должен гарантировать уникальность каждого экземпляра сущности;
- атрибуты, входящие в первичный ключ, не могут принимать NULL – значения;
- ключ должен быть неизменным, то есть неспособным и невосприимчивым к изменениям;
- значения первичных ключей должны задаваться внутри организации и не должны зависеть от внешних структур.
Например, сущность СЛУЖАЩИЙ. Атрибут № паспорта является плохим кандидатом на роль первичного ключа, так как его значение зависит от внешних организаций и может быть изменено ими. Его значения находятся вне зоны внутреннего контроля. Лучшим решением является Табельный номер, т.к. его значение присваивается внутри организации.
Вернуться в содержание