- •Содержание
- •Тема 1. Введение в базы данных. Автоматизированный банк данных. 9
- •Тема 2. Основные компоненты банка данных и их взаимодействие. 14
- •Тема 3. Классификация банков данных, баз данных и субд. Недостатки и преимущества банков данных. Этапы развития баз данных. 24
- •Тема 4. Модели данных. 31
- •Тема 5. Технология проектирования баз данных. Уровни проектирования. 41
- •Тема 6. Жизненный цикл баз данных. 48
- •Тема 7. Модель предметной области 52
- •Тема 8. Этапы проектирования баз данных. 61
- •Тема 9. Нормализация. 67
- •Тема 10. Сохранение секретности информации и безопасность данных. 76
- •Тема 11. Типология баз данных. Основные платформы баз данных. 82
- •Тема 12. Тенденции развития современных баз данных. 89
- •Тема 1. Введение в базы данных. Автоматизированный банк данных.
- •Введение в базы данных
- •Управление - это процесс переработки информации состояния в информацию командную для достижения определенных целей.
- •Структура экономической информационной системы (эис)
- •Понятие банка данных, его роль в системе обработки экономической информации. Предметная область.
- •Форматированный вариант сообщения
- •Вопросы для самоконтроля
- •Тема 2. Основные компоненты банка данных и их взаимодействие.
- •Основные компоненты банка данных.
- •Функциональное назначение компонентов аБнД.
- •База данных.
- •Функции субд
- •Транзакции
- •Словарь данных.
- •Персонал банка данных.
- •Организационно-методические, правовые, математические, информационные, программные, технические и лингвистические составляющие банка данных
- •Взаимодействие компонентов банка данных
- •Вопросы для самоконтроля
- •Тема 3. Классификация банков данных, баз данных и субд. Недостатки и преимущества банков данных. Этапы развития баз данных.
- •Классификация банков данных
- •Классификация баз данных
- •Классификация субд
- •Преимущества банков данных
- •Недостатки банков данных
- •Этапы развития бд
- •Вопросы для самоконтроля
- •Тема 4. Модели данных.
- •Модели данных
- •1.1. Объектные модели данных
- •1.2. Модели данных на основе записей
- •1.3. Физические модели данных
- •Структуры данных
- •Иерархическая модель данных
- •Недостатки иерархической модели данных:
- •Сетевые модели данных
- •Недостатки сетевой модели данных:
- •Реляционная модель данных
- •5.1. Основные понятия реляционной модели данных
- •Сравнение моделей данных
- •Вопросы для самоконтроля
- •Тема 5. Технология проектирования баз данных. Уровни проектирования.
- •Трехуровневая архитектураAnsi/sparc
- •Уровни проектирования бд
- •Вопросы для самоконтроля.
- •Вопросы для самоконтроля.
- •1.1. Разновидности сущностей
- •1.2. Основные виды свойств
- •1.3. Классификация связей
- •1.4. Свойства связей
- •Er-диаграмма
- •Особенности отображения er-модели
- •Системный анализ
- •Формирование из объектов предметной области сущностей и их характеристик
- •Установка соответствия между сущностями и таблицами, характеристиками сущностей и столбцами таблиц
- •Получение реляционной схемы из er-диаграммы:
- •Определение первичных ключей
- •Определение правил целостности данных
- •Установка связей между объектами
- •Нормализация
- •Универсальное отношение
- •Функциональная и многозначная зависимости
- •Процесс нормализации
- •Приведение к первой нормальной форме
- •Приведение ко второй нормальной форме
- •Приведение к третьей нормальной форме
- •Нормальная форма Бойса – Кодда (нфбк)
- •Типы опасностей
- •Примеры возможных опасностей
- •Компьютерные средства контроля
- •Перечень прав доступа
- •Вопросы для самоконтроля
- •Серверные субд
- •Характерные черты современных серверных субд
- •Сервисы, предоставляемые серверными субд
- •Реализация для нескольких платформ.
- •Административные утилиты.
- •Резервное копирование данных.
- •Обслуживание репликаций.
- •Параллельная обработка данных в многопроцессорных системах.
- •Поддержка olap и создания хранилищ данных.
- •Распределенные запросы и транзакции.
- •Средства проектирования данных.
- •Поддержка собственных и «чужих» средств разработки и генераторов отчетов.
- •Поддержка доступа к данным с помощью Internet.
- •Недостатки реляционных субд
- •Вопросы для самоконтроля
- •Постреляционная модель
- •Объектно-ориентированные бд
- •Технология «Хранилищ данных»
- •Интеграция с Internet-технологиями
- •Темпоральные бд
- •Дедуктивные бд
- •Многомерные бд
- •Вопросы для самоконтроля
- •Расскажите о перспективах развития баз данных.
- •Какие новые технологии, применяемые в теории баз данных, Вам известны?
1.4. Свойства связей
Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным), в противном случае – неполным (или необязательным, частичным). Например, связь между сущностями СОТРУДНИК и ИНОСТРАННЫЙ ЯЗЫК. Некоторые СОТРУДНИКИ знают ИНОСТРАННЫЙ ЯЗЫК, но ни один из них не владеет более, чем одним ИНОСТРАННЫМ ЯЗЫКОМ. Есть некоторые СОТРУДНИКИ, которые не владеют ни одним ИНОСТРАННЫМ ЯЗЫКОМ. Естественно, что имеется много ИНОСТРАННЫХ ЯЗЫКОВ, которыми не владеет ни один из СОТРУДНИКОВ, а также, что некоторые из СОТРУДНИКОВ владеют одним и тем же ИНОСТРАННЫМ ЯЗЫКОМ. В данном случае участие обеих сущностей в связи является неполным.
Возможны ситуации, когда в связи участвует один из нескольких возможных типов сущности. Такие связи называются альтернативными. Например, если организация имеет центральный офис и филиалы, то служащий может работать либо в центре, либо в филиале, но не там и там одновременно.
Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Тип связи есть агрегат двух или более типов сущностей. Возможны следующие типы бинарных связей:
«один – к – одному» (1:1) (one-to-one relationship);
«один – ко – многим» (1:N) (one-to-many relationship);
«многие – к – одному» (N:1) (many-to-one relationship);
«многие – ко – многим» (N:N) (many – to – many relationship).
Связь "один – к - одному" представляет собой простейший вид связи данных, когда первичный ключ сущности является в то же время внешним ключом, ссылающимся на первичный ключ другой сущности. Такую связь бывает удобно устанавливать тогда, когда невыгодно держать разные по размеру (или по другим критериям) данные в одной таблице. Например, можно выделить данные с подробным описанием изделия в отдельную таблицу с установлением связи "один – к - одному" для того чтобы не занимать оперативную память, если эти данные используются сравнительно редко.
Следующий классический пример отношения "один - к – одному" - это реализация подтипа данных. Допустим, вы делаете БД для магазина, торгующего автомобилями. У вас будет сущность с общими характеристиками автомобиля, например: цвет, стоимость, дата выпуска и тип (иномарка или отечественная). При описании реального проекта характеристик будет значительно больше. А теперь представьте, что поскольку машины могут быть отечественного производства и иномарки, то у машин отечественного производства есть свои параметры, которых нет у иномарок, например, гарантия завода изготовителя. В то же время и у иномарок есть свои параметры, которых нет у отечественных машин, например, из какой страны импортирована, пошлина, размещение руля (слева или справа). Здесь приходит на выручку отношение "один - к – одному", т.е. мы реализуем своего рода подтипы (см. рис. 1.).
На рис. 7.1 любой записи в таблице Автомобили в зависимости от значения поля тип соответствует запись либо в таблице Иномарки, либо в таблице Отечественные.
Связь "один – ко - многим" в большинстве случаев отражает реальную взаимосвязь сущностей в предметной области. Она реализуется уже описанной парой "внешний ключ - первичный ключ", т.е. когда определен внешний ключ, ссылающийся на первичный ключ другой сущности. Например, район – город. В одном районе находится много городов.
Или, например, если есть 2 сущности "Студент" и "Преподаватель" и связь между ними – руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить несколькими студентами-дипломниками (рис. 7.2).
рис. 7.1. Схема связи «один-к-одному».
рис. 7.2. Схема связи «один-ко-многим».
Связь "многие - к - одному" симметрична связи "один - ко - многим". Эти связи различаются только в том случае, когда учитывается их направление и одна из сущностей считается главной, а вторая подчиненной.
Связь "многие – ко - многим" в явном виде в реляционных БД не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной сущности, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух сущностей. Такая сущность, предназначенная для представления взаимоотношений между двумя другими сущностями, называется составной. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ. Один человек может быть включен в различные группы, в то время как группа может объединять различных людей. Для реализации такой связи "многие – ко - многим" вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строка которой будет иметь два внешних ключа: один будет ссылаться на первичный ключ в таблице КЛИЕНТ, а другой - на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таким образом, в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать любое количество людей и любое количество групп.
Другим примером связи "многие – ко - многим" является следующий: имеются две таблицы: СТУДЕНТ и ПРЕПОДАВАТЕЛЬ и между ними установлена связь - лекции (рис. 7.3).Один студент слушает лекции разных преподавателей, а преподаватель читает лекции многим студентам.
рис. 7.3. Схема связи «многие-ко-многим».
Для реализации такой связи введем дополнительную сущность ЛЕКЦИИ (рис. 7.4).
рис. 7.4. Реализация связи «многие-ко-многим» в реляционной модели данных.
Инструмент связей – это средство представления сложных объектов, каждый из которых может рассматриваться как множество взаимосвязанных простых объектов. Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностями анализа предметной области, т. е. характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения ПОСТАВЩИКА – простым.