- •Конспект лекций
- •8 Физическая модель данных 50
- •8.1 Исходные данные для физического проектирования 50
- •10 Введение в sql 59
- •Базы данных. Вводный курс 62
- •11.Рекомендуемая литература 71
- •1 Введение
- •1.1 Базы данных и информационные системы. Основные понятия
- •1.2 Жизненный цикл баз данных
- •2 Обзор субд
- •2.1 Функции субд
- •2.2 Состояние рынка субд
- •2.3 Современные подходы к проектированию архитектуры ис
- •2.3.1 Локальные ис
- •2.3.2 Ис в локальных сетях
- •2.3.3 Двухзвенные модели
- •2.3.4 Трехзвенные модели
- •2.5 Монитор транзакций
- •3 Проектирование базы данных на концептуальном уровне
- •3.1 Основные понятия
- •3.2 Задачи моделирования данных
- •3.3 Сущности
- •3.4 Атрибуты
- •3.5 Ключи
- •3.6 Связи
- •3.7 Классы и подклассы
- •3.8 Источники данных для концептуального проектирования
- •3.9 Построение концептуальной схемы
- •3.4 Особенности учета требований при проектировании бд
- •3.5 Модели данных логического уровня
- •3.6 Иерархическая модель
- •3.7 Сетевая модель
- •5 Реляционная модель данных
- •5.1 Основные понятия
- •5.2 Целостность реляционной модели
- •5.3 Математическое описание реляционной модели
- •5.4 Реляционная алгебра. Теоретико-множественные операции
- •5.5 Реляционная алгебра. Специальные реляционные операции
- •5.6 Дополнительные реляционные операции
- •5.7 Примеры записи запросов
- •5.8 Реляционное исчисление
- •6 Проектирование реляционной модели
- •6.1 Нормализация модели
- •6.2 Функциональная зависимость
- •6.3 Теоремы о функциональных зависимостях
- •6.4 Нормальные формы отношений
- •6.5 Алгоритм нормализации отношений. Метод декомпозиции
- •7 Проектирование реляционной модели на основе концептуальной модели
- •7.1 Реализация бинарной связи 1:1
- •7.1.1 Связь всюду определённая
- •7.1.2 Связь частичная для одной из сущностей
- •7.1.3 Связь частичная для обеих сущностей
- •7.2 Реализация бинарной связи 1:m
- •7.2.1 Связь всюду определённая для m-связной сущности
- •7.2.2 Связь частичная для m-связной сущности
- •7.3 Бинарная связь n:m
- •7.4 Связи более высокого порядка
- •7.5 Классы и подклассы
- •8 Физическая модель данных
- •8.1 Исходные данные для физического проектирования
- •8.2 Возможная методика перехода к физической модели на примере реляционной модели
- •8.2.1 Преобразование отношений в таблицы
- •8.2.2 Преобразование атрибутов в поля (столбцы) таблиц
- •8.2.3 Преобразование доменов в типы данных
- •8.2.4 Первичные ключи
- •8.2.5 Порядок расположения столбцов
- •8.2.6 Создание ссылочных ограничений
- •8.3 Факторы, влияющие на производительность бд
- •8.3.1 Индексы
- •8.3.2 Денормализация
- •9 Дополнительные аспекты реляционной технологии
- •9.1 Проблемы, требующие решения
- •9.2 Запросы
- •9.3 Представления
- •9.4 Курсоры
- •9.5 Хранимые процедуры
- •9.6 Триггеры
- •9.7 Функции, определяемые пользователем
- •9.8 Транзакции
- •10 Введение в sql
- •10.1 Стандарты
- •10.2 Возможности sql
- •10.3 Запросы на выборку данных
- •10.4 Примеры запросов
- •Базы данных. Вводный курс
- •Содержание
- •11.Рекомендуемая литература
3.4 Атрибуты
Атрибут – это характеристика или свойство сущности.
Можно выделить следующие разновидности атрибутов:
1) идентифицирующие, то есть те, которые позволяют отличить один экземпляр сущности от другого, например, № студенческого билета; такие атрибуты являются потенциальными ключами сущности и должны быть неизменными;
2) связывающие, то есть те, которые позволяют создать связи между сущностями;
3) описывающие, то есть те, которые не относятся к первым двум разновидностям, например, Дата рождения.
Не существует точного правила, позволяющего отличить атрибут от сущности и наоборот.
Можно использовать следующие рекомендации:
1) на основании знания бизнес – процессов выявить роли атрибутов (идентификация, связывание, описание);
2) экземпляры атрибутов, как правило, элементарны по своей природе, то есть атрибут представляет собой единичный факт, который в бизнес – процессах не раскладывается на составные части; например, ФИО как атрибут сущности СТУДЕНТ является не лучшим решением, т.к. раскладывается на составные части, которые в бизнес – процессах могут рассматриваются отдельно, например, поздравление всех Татьян с Татьяниным днем.
Соглашения для имен атрибутов могут быть разными в разных организациях, например, ИмяСтудента или имя_студента и т.п.
Существуют общепринятые сокращения для имен атрибутов, например, ID - идентификатор или ADDR – адрес и т.д.
При задании имен атрибутам необходимо избегать использования омонимов (ключ, замок и т.п.) и синонимов.
После уточнения имен атрибутов необходимо определить множество допустимых значений каждого атрибута, используя для этих целей любые известные способы:
- указание типа данных;
- тип данных и диапазон;
- использование классификаторов и кодификаторов;
- список допустимых значений и т.д.
Для каждого атрибута необходимо оценить возможность принимать неизвестное значение (NULL - значение). Например, сущность СТУДЕНТ, атрибут ЦветВолос. Как задать значение этого атрибута для студентки с неизвестным цветом волос или для лысого студента?
3.5 Ключи
Ключ состоит из одного или более атрибутов, значения которых однозначно идентифицируют экземпляр сущности, например, №Паспорта – ключ личности, по нему один экземпляр сущности ЛИЧНОСТЬ отличается от другого экземпляра.
Каждая сущность может иметь несколько ключей, но должна иметь по крайней мере один ключ. Такие ключи называются потенциальными ключами.
У каждой сущности есть один и только один первичный ключ, который выбирается из потенциальных ключей.
Критерии выбора первичного ключа:
- ключ должен гарантировать уникальность каждого экземпляра сущности;
- атрибуты, входящие в первичный ключ, не могут принимать NULL – значения;
- ключ должен быть неизменным, то есть неспособным и невосприимчивым к изменениям;
- значения первичных ключей должны задаваться внутри организации и не должны зависеть от внешних структур.
Например, сущность СЛУЖАЩИЙ. Атрибут №Паспорта является плохим кандидатом на роль первичного ключа, так как его значение зависит от внешних организаций и может быть изменено ими. Его значения находятся вне зоны внутреннего контроля. Лучшим решением является ТабельныйНомер, т.к. его значение присваивается внутри организации.
