- •Оглавление
- •1. Основные понятия информационных систем
- •1.1. История возникновения информационных систем
- •1.2. Современное понятие информационной системы
- •2. Автоматизированные информационные системы
- •2.1. Преимущества автоматизированных информационных систем
- •2.2. Классификация аис
- •2.2.1. Классификация по типу хранимых данных.
- •2.2.2. Классификация по характеру обработки данных.
- •2.2.3. Классификация по степени интеграции данных и автоматизации управления.
- •2.2.4. Классификация по степени распределенности.
- •2.2.5 Классификация аис по другим признакам
- •3. Банки данных
- •3.1. Понятие банка данных
- •3.2. Преимущества банков данных
- •3.3. Предпосылки широкого использования банков данных
- •3.4. Общие требования к банкам данных
- •3.5. Компоненты банка данных
- •3.5.1. Информационная компонента
- •3.5.2. Программные средства банков данных
- •3.5.3. Языковые средства БнД
- •3.5.4. Технические средства банков данных
- •3.5.5. Организационно-методические средства.
- •4. Виды банков данных
- •4.1. Банки документов
- •4.2. Банки знаний
- •4.3. Экспертные системы
- •4.4. Хранилища данных
- •5. Системы управления базами данных (субд)
- •5.1. Назначение и состав субд
- •5.2. Классификация субд
- •5.3. Архитектура субд
- •5.4. Функции субд
- •5.5. Основные распространенные субд
- •6. Основы проектирования баз данных
- •6.1. Основные понятия в теории баз данных
- •6.2. Связи между сущностями
- •6.3. Этапы проектирования базы данных
- •6.3.1. Инфологическое моделирование
- •6.3.2. Даталогическое моделирование
- •6.3.3. Физическое моделирование
- •7. Модели данных
- •7.1. Иерархическая модель данных
- •7.2. Сетевая модель данных
- •7.3. Понятие реляционной модели данных
- •7.3. Постреляционная модель данных
- •7.4. Объектно-ориентированная модель данных
- •7.5. Объектно-реляционная модель данных
- •8. Реляционная модель данных
- •8.1. Понятие «отношения» в реляционной модели данных
- •8.2. Свойства отношений
- •8.3. Требования к реляционным базам данных
- •8.4. Основные математические понятия
- •9. Нормализация баз данных
- •9.1. Первая нормальная форма
- •9.2. Вторая нормальная форма
- •9.3. Третья нормальная форма
- •9.4. Нормальная форма Бойса – Кодда
- •9.5. Многозначные зависимости
- •9.6. Четвертая нормальная форма
- •9.7. Пятая нормальная форма
- •9.8. Принципы выбора нормальной формы для проектируемой базы данных
- •10. Введение в язык запросов sql
- •10.1. Назначение языка sql
- •10.2. Достоинства языка sql
- •10.3. Состав языка sql
- •10.4. Трехзначная логика
- •10.5. Основные типы данных языка sql
- •11. Sql. Некоторые Операторы языка определения данных
- •11.1. Оператор create table
- •11.2. Оператор alter table
- •11.3. Оператор drop table
- •12. Sql. Операторы изменения данных
- •12.1. Оператор insert into
- •12.2. Оператор update
- •12.3. Оператор delete from
- •13. Sql. Выбор информации из базы данных
- •13.1. Общее описание оператора select
- •13.1.1. Назначение оператора select
- •13.1.2. Синтаксическая диаграмма оператора select
- •13.2. Обязательные предложения оператора select
- •13.2.1. Предложение select.
- •13.2.2. Предложение from.
- •13.2.3. Примеры простейших запросов на выборку.
- •13.3. Отбор строк (предложение where)
- •13.3.1. Сравнение
- •13.3.2. Проверка на принадлежность диапазону значений (between)
- •13.3.3. Проверка на членство во множестве (in)
- •13.3.4. Проверка на соответствие шаблону (like)
- •13.3.5. Отслеживание отсутствия значений (null)
- •13.3.6. Составные условия отбора строк
- •13.4. Сортировка результатов запроса (предложение order by)
- •13.5 Примерный порядок выполнения простых однотабличных запросов
- •13.6. Многотабличные запросы
- •13.6.1. Полные имена столбцов.
- •13.6.2. Псевдонимы таблиц.
- •13.6.3. Особенности многотабличных запросов.
- •13.6.4. Примеры многотабличных запросов.
- •13.6.5. Соединение таблиц в предложении from.
- •13.6.6. Примерный порядок выполнения многотабличных запросов
- •13.7. Итоговые запросы на чтение
- •13.7.1. Агрегатные функции.
- •13.7.2. Группировка строк (предложение group by)
- •13.7.3. Отбор групп строк (предложение having)
- •13.7.4. Примерный порядок выполнения итоговых запросов
- •13.8. Вложенные запросы на чтение (подзапросы)
- •13.8.1. Использование вложенных запросов
- •13.8.2. Сравнение с результатом вложенного запроса
- •13.8.3. Проверка на принадлежность результатам вложенного запроса
- •13.8.4. Проверка на существование (exists)
- •13.8.5. Многократное сравнение (any, all)
- •13.9. Объединение результатов нескольких запросов
6.2. Связи между сущностями
Объекты реального мира могут находиться друг с другом в сложных взаимоотношениях. Следовательно, в базе данных должны моделироваться такие взаимоотношения, существующие в реальном мире. Такие взаимоотношения представляются как связи между сущностями. Каждая связь может быть отнесена к одному из трех типов.
Пусть имеются сущности А и В.
6.2.1 Связь «один-к-одному» (краткое обозначение «1:1»), означает, что каждому экземпляру сущности А может соответствовать только один экземпляр сущности В, а каждому экземпляру сущности В может соответствовать только один экземпляр сущности А.
Для пояснения данного определения рассмотрим следующий пример. Пусть имеются две сущности – «гражданин РФ» и «паспорт гражданина РФ». У одного гражданина может быть только один паспорт (имеются в виду внутренние паспорта, загранпаспорта не рассматриваются). В то же время, каждый паспорт может быть выдан только одному гражданину.
В приведенном определении следует обратить внимание на словосочетание «может соответствовать». Это означает, что в обеих сущностях могут быть экземпляры, не связанные с экземплярами другой сущности. Например, гражданин не достиг возраста, при котором выдается паспорт. Так же и бланки паспортов могут существовать, находиться в уполномоченном органе, выдающем паспорта, но пока не быть выданными какому-либо гражданину.
Следует отметить, что тип связи 1:1 достаточно редко реализуется в базе данных с использованием двух сущностей. В рассмотренном примере такая реализация может иметь место, если база данных разрабатывается для паспортного стола или какой-либо другой службы, в которой необходимо учитывать отдельно граждан и бланки паспортов. Если же база данных будет функционировать на предприятии и использоваться для учета сотрудников, то необходимости выделять бланки паспортов в отдельную сущность отсутствует. В этом случае оптимальным решением было бы включение паспортных данных сотрудника в набор свойств сущности «сотрудник», наряду с такими атрибутами, как фамилия, имя, отчество, дата рождения и т.п.
6.2.2 Связь «один-ко-многим» (краткое обозначение «1:М»), означает, что каждому экземпляру сущности А может соответствовать несколько экземпляров сущности В, а каждому экземпляру сущности В может соответствовать только один экземпляр сущности А.
Для пояснения данного определения рассмотрим следующий пример. Пусть имеются две сущности – «Корпус ВУЗа» и «Аудитория». В одном корпусе может находиться несколько аудиторий, одна аудитория или ни одной, например, если корпус административный или хозяйственный. В то же время каждая аудитория может физически располагаться только в одном корпусе .
6.2.3 Связь «многие-ко-многим» (краткое обозначение «М:N»), означает, что каждому экземпляру сущности А может соответствовать несколько экземпляров сущности В, а каждому экземпляру сущности В может соответствовать несколько экземпляров сущности А.
Для пояснения данного определения рассмотрим следующий пример. Пусть имеются две сущности – «Студент» и «Изучаемая дисциплина». Студент может изучать несколько дисциплин, в то же время каждую дисциплину может изучать несколько.
Таким образом, при проектировании базы данных необходимо определить не только наличие взаимосвязей между сущностями, но и тип этих связей.