Базы данных

Из учебного плана
Лекции
Лабораторные и практические занятия
Экзамен
Курсовая работа

План лекционного курса БД
Общие понятия,
История БД
Состав и архи-
тектура СУБД
Модели
данных
Этапы
проектирования
БД
Инфологическое
моделирование
Переход к
реляционной
модели
Реляционная
алгебра как
основа SQL
SQL
(Structured
Query Language)

План лабораторных работ
№1. Инфологическое
моделирование
Создание концептуальной
модели выбранной
предметной области
№2. Создание реля-
ционной модели БД
Реализация реляционной модели
в среде MS Access
№3. SQL-запросы
Создание запросов
в среде MS Access
№4. Элементы графи-
ческого интерфейса.
Формы в MS Access
№5. Генерация выход-
ной документации.
Отчеты в MS Access.

К. Дж. Дейт.
Введение в системы баз данных (An Introduction to Database Systems)
8-е издание
Вильямс, 2006 г.
Твердый переплет, 1328 стр.

Каролин Бегг, Томас Коннолли.
Базы данных. Проектирование, реализация и сопровождение.
Теория и практика.
Третье издание. 1436 стр.,
2003 г.
Издательство: Вильямс.

Карпова Т.С.
Базы данных: модели, разработка, реализация. –СПб.:Питер,2001.-304с.

Малыхина М.П. Базы данных: Основы, проектирование, использование: БХВ-Петербург, 2004.– 512 с.

Хомоненко А.Д.
Цыганков В.М.
Мальцев М.С.
Базы данных: Учебник для высших учебных заведений/ Под ред.проф.А.Д. Хомоненко – 4-е изд.,доп. и перераб. – СПб.:КОРОНА принт,2004.-736 с.

Мартин Граббер
Введение в SQL
Издательство: Лори, Пер. с англ.,
2008.- 375 с. .

Когаловский М.Р. Энциклопедия технологий баз данных: Эволюция технологий. Технологии и стандарты. Инфраструктура. Терминология. - М.: Финансы и статистика, 2005. - 800 с.

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

Фундаментальные понятия
теории баз данных
Информация – это сведения об окружающем мире, имеющие специфическую интерпретацию или смысл.
Данные (от лат. data) – это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе.
База данных (БД) – организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для решения информационных потребностей пользователей.

Фундаментальные понятия
теории баз данных
Информационная система (ИС) – это комплекс вычислительного и коммуникационного оборудования, программного обеспечения, лингвистических средств и информационных ресурсов, который обеспечивает их сбор, хранение, актуализацию, распространение и обработку в целях поддержки какого-либо вида деятельности.
Система управления базами данных (СУБД) – это комплекс программ, позволяющих создавать и использовать БД, обеспечивая безо­пас­ность, на­дёж­ность хра­не­ния и це­ло­ст­ность дан­ных, а также предоставляя возможности администрирования.

Интересные факты
Реляционная база данных Yahoo > 2 петабайт;
Архив с базой данных OpenStreetMap занимает порядка 70Гб;
Практически ни одно приложение не обходится без БД;
Практически невозможно найти готовые решения;
Установочные .msi файлы для Windows – это БД;
В большинстве вакансий разработчика упоминается SQL, по данным hh.ru

Курс «Базы данных» посвящен решению проблемы рациональной организации информации
График Мэмфорда, отражающий экспоненциальный рост числа значительных изобретений во времени

Рост объема генерируемых данных

Информация
База данных

Структурирование
Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это возможно, только если данные структурированы.
Структурирование – это введение соглашений о способах представления данных.
Неструктурированными называют данные, записанные в произвольной форме, например, в текстовом файле.
Рассмотрим пример…

Неструктурированные данные
«Для того чтобы добраться до села Дудкино, нужно сначала долететь на самолете до Иванова. Далее - на электричке до Орехова. Затем пересесть на паром и переправиться через реку Слоновую в поселок Ольховка, а оттудауже на попутной машине ехать в село Дудкино».

Первый способ cтруктурирования: списочный
Как ехать в село Дудкино?
До Иванова на самолете.
Далее до Орехова на электричке.
До поселка Ольховка на пароме.
До села Дудкино на попутной машине.

Второй способ cтруктурирования: табличный

Третий способ cтруктурирования: графический

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

Пример: неструктурированные данные
На олимпиаду отправлены: студентка НПК 2-5а Кравцова Т.А., зачисленная 31 августа 2020 года, со средней успеваемостью 4,4 балла,
[email protected]
На олимпиаду отправлены: студентка НПК 2-5а Кравцова Т.А., зачисленная 31 августа 2020 года, со средней успеваемостью 4,4 балла,
[email protected]
; староста ФИТУ 4-6 Егоров А.В., круглый отличник,
[email protected]
и его одногруппница Абрамян М.Э. с успеваемостью 4,7 балла; староста ФГГНГД 3-2б Жуков С.Г., зачисленный 31.08.18, с успеваемостью 4,1 балла,
[email protected]
; и т.д.

Пример: структурированные данные

Лектор Георгица И.В.
История и этапы эволюции концепций БД.
Функции СУБД. Поколения СУБД.

Основные этапы эволюции концепций БД
Этап 1. Простые файлы данных (начало 60-х годов).
Этап 2. Совершенствование методов доступа к файлу (конец 60-х годов)
Этап 3. Появление первых систем управления БД (начало 70-х г.) .
Этап 4. Современные системы баз данных

1 этап Простые файлы данных

Проблемы традиционных
систем управления файлами
структура записи файла была известна только программе, которая с ним работала;
при изменении структуры файла требовалось изменять структуру программы (или множества программ);
отсутствие централизованных методов управления доступом к информации
неэффективная параллельная работа многих пользователей с одними и теми же файлами;
сложность восстановления.

2 этап Совершенствование методов доступа к файлу

3 этап Появление первых СУБД

4 этап Современные СУБД

Основные функции СУБД
1. Обеспечивает пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка, названного языком определения данных(DDL).
2. Позволяет "запрашивать" данные и изменять их с помощью подходящего языка. Этот язык называется языком запросов или языком манипулирования данными(DML).
3. Управляет данными во внешней и оперативной памяти, защищая их от случайной порчи или неавторизованного использования.
4. Контролирует доступ к данным сразу множества пользователей, не позволяя запросу одного из них влиять на запрос другого, и не допуская одновременного доступа, который может испортить данные.
5. Журнализация изменений и восстановление БД.

Краткая история развития БД

Поколения СУБД. Их характеристика.
К СУБД первого поколения относят СУБД на основе сетевой модели данных (их иногда называют CODASYL-системы) и системы на основе иерархических подходов.
СУБД второго поколения – реляционные
СУБД третьего поколения – объектно-реляционные и объектно-ориентированные.

Лектор Георгица И.В.
Классификация СУБД. Архитектура СУБД. Основные компоненты СУБД.

Классификация СУБД. Архитектура СУБД. Схема ее работы и характеристика основных компонентов. Роль администраторов баз данных. Уровни представления информации в базах данных. Логическая и физическая независимость данных и средства ее обеспечения.

Критерии классификации СУБД
По степени универсальности:
СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).
По используемой модели данных
иерархические, сетевые, реляционные; объектно-ориентированные СУБД.
По методам организации хранения и обработки данных :
централизованные (локальные, файл – серверные, клиент-серверные) и распределённые СУБД.
По сфере применения
справочные системы и системы обработки данных.
Классификация по масштабу систем:
персональные; уровня группы, отдела, предприятия; корпоративные; географически распределенные.

Локальная СУБД

Файл-серверная СУБД

Клиент-серверная СУБД

Распределенная СУБД
Распределенная СУБД – это СУБД, поддерживающая работу с распределенными базами данных. Одно из определений распределенной БД:
"Распределенная БД - это множество физических баз данных, которые выглядят для пользователя как одна логическая БД". К сожалению на сегодняшний день ни одна СУБД полностью не реализует это определение. Наиболее близко к его реализации подошли следующие СУБД:
- Informix On-Line фирмы Informix Software;
- Ingres Intelligent Database фирмы Ingres Corp;
- Oracle (version 7) фирмы Oracle Corp;
- Sybase System 10 фирмы Sybase Inc.

Упрощенная схема СУБД

Основные компоненты в среде СУБД
Компоненты
в среде СУБД
Данные
Аппаратное
обеспечение
Программное
обеспечение
Пользователи
Данные должны быть интегрированными и общими.
Интегрирование – возможность представлять базу данных как объединение нескольких отдельных файлов данных полностью или частично не перекрывающихся.
Общие – возможность использования отдельных областей данных в БД несколькими различными пользователями, причем даже в одно и тоже время(одновременный доступ).

Компоненты
в среде СУБД
Данные
Аппаратное
обеспечение
Программное
обеспечение
Пользователи
Накопители для хранения информации (обычно диски с перемещаемыми головками) вместе с подсоединенными устройствами ввода-вывода, контроллерами устройств, каналами ввода-вывода и т.д.
Процессор или процессоры вместе с основной памятью, которая используется для поддержки работы программного обеспечения системы
Основные компоненты в среде СУБД

Компоненты
в среде СУБД
Данные
Аппаратное
обеспечение
Программное
обеспечение
Пользователи
Диспетчер базы данных (database manager),или система управления базами данных СУБД (database management system(DBMS)). СУБД предоставляет пользователю возможность рассматривать БД как объект более высокого уровня по сравнению с аппаратным обеспечением, а также поддерживает выражаемые в терминах высокого уровня пользовательские запросы(SQL).Кроме СУБД, в программном обеспечении – утилиты, средства разработки приложений, средства проектирования, генераторы отчетов и другие.
Основные компоненты в среде СУБД

Компоненты
в среде СУБД
Данные
Аппаратное
обеспечение
Программное
обеспечение
Пользователи
Работающие с базами данных пользователи обладают различными знаниями, навыками и сталкиваются с решением различных задач:
- конечные пользователи;
- разработчики баз данных;
- разработчики приложений;
- администраторы баз данных.
Основные компоненты в среде СУБД

Схема трехуровневой архитектуры ANSI для СУБД

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

Определение схемы и подсхемы БД.
С понятием «трехуровневая архитектура баз данных» связаны понятия «схема» и «подсхема».
Описание общей логической структуры базы данных называют схемой. Ее называют иногда общей моделью данных. На основе одной схемы можно составить много различных подсхем (в зависимости от требований пользователей к БД).

Процесс прохождения пользовательского запроса

Процесс прохождения пользовательского запроса
2
3
1
4
5
6
7
8

Лектор Георгица И.В.
Модель данных. Классификация моделей данных. Этапы проектирования баз даных

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

Определение понятия
«модель данных»
Модель данных — это некоторая интерпретация данных, связанная с этапом проектирования БД, которая трактуется как сведения, имеющие определенную структуру.
Модель данных – это логическое определение объектов, связанное с этапом проектирования БД.
К этому понятию примыкает понятие МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

Из «Энциклопедии технологий баз данных» М.Р. Когаловского

Модели данных
Инфологические
модели
Даталогические
модели
Физические
модели
Диаграммы
Бахмана
Модель
«СУЩНОСТЬ-СВЯЗЬ»
(ER-модель)
Основанные
на файловых
структурах
Основанные
на странично-
сегментной
организации
Документальные
Фактографические
Теоретико-
графовые
Дескрипторные
Тезаурусные
Ориентированные
на формат
документа
Теоретико-
множественные
Объектно-
ориентированные
Иерархическая
Сетевая
Реляционная
Бинарных
ассоциаций

Модели данных
Инфологические
модели
Даталогические
модели
Физические
модели
Модель
«СУЩНОСТЬ-СВЯЗЬ»
(ER-модель)
Объектно-
ориентированные
Иерархическая
Сетевая
Реляционная
Объектно-
ориентированные

Модели данных
Инфологические
модели
Даталогические
модели
Физические
модели
Модель
«СУЩНОСТЬ-СВЯЗЬ»
(ER-модель)
Иерархическая
Сетевая
Реляционная
Объектно-
ориентированная
Инфологическое моде-
лирование связано со
2-м этапом проектиро-
вания БД: созданием
формализованного
описания предметной
области
Логическое (или дата-
логическое) моделиро-
вание осуществляет-
ся после этапа выбора
СУБД. Этот тип модели
полностью зависит от
типа модели, поддержи-
ваемой выбранной
системой.
Физическое моделиро-
вание заключается в
выборе эффективного
размещения БД на
внешних носителях для
обеспечения наиболее
эффективной работы.

Этапы проектирования БД
1. Системный анализ и словесное описание информационных объектов предметной области.
2. Информационно-логическое (инфологическое) проектирование - создание инфологической модели предметной области – частично формализованного описания объектов предметной области в терминах некоторой семантической модели. Наиболее традиционная из них называется моделью сущности – связи (E/R- модель, entity-relationship), имеет графическую природу (прямоугольники, стрелки, ромбы).
3. Выбор СУБД и других инструментальных программных средств.
4. Даталогическое (или логическое) проектирование, т.е. описание БД в терминах принятой даталогической модели данных (наиболее распространена реляционная, т.е. E/R-модель преобразуем в реляционную).
5. Физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Подходы к выбору состава и структуры предметной области
1. Функциональный подход – он реализует принцип движения “ от задач ” и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить необходимый минимальный набор объектов предметной области, которые должны быть описаны.
2. Предметный подход – когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и динамичными. БД, конструируемая при этом, называется предметной.

Лектор Георгица И.В.
Инфологическое моделирование.
Модель «сущность – связь» в нотации Мартина.

Инфологическая модель предметной области – это частично формализованное описание объектов предметной области в терминах некоторой семантической модели. Более традиционная из них называется моделью сущность – связь (E/R- модель, entity-relationship), имеет графическую природу (прямоугольники, стрелки, ромбы).

E/R-модель (или модель сущность – связь) создана Питером Ченом в 1976 году. E/R-модель стала фактическим стандартом при инфологическом моделировании БД по следующим причинам.
1) большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели;
2) разработаны методы автоматического преобразования проекта БД из E/R-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД.
Модель «сущность – связь»

Компоненты E/R-модели:
Сущность – это реальный или представляемый набор однотипных объектов, информация о котором характеризует предметную область. В системе существует множество экземпляров данной сущности ( если проводить аналогию с ООП, то множества сущностей – класс, каждая сущность – объект (экземпляр класса).
2. Атрибуты – значения, описывающие свойства сущности. Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называется ключевым.
3. Связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой. Если есть связь между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.

Типы связей в ER-модели
С точки зрения множественности:
Один к одному (1:1),
один ко многим (1:М),
многие ко многим (М:М).
С точки зрения обязательности:
Обязательная ( экземпляр первой сущности ДОЛЖЕН быть связан с экземпляром второй сущности)
Необязательная ( экземпляр первой сущности МОЖЕТ быть связан с экземпляром второй сущности)

Нотация Мартина
Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет кардинальность связи.

Нотация Мартина
Имя связи указывается на линии ее обозначающей. Пример:

Пример описания предметной области «Библиотека»
Пусть требуется разработать информационную систему для автоматизации учета получения и выдачи книг в библиотеке. Система должна предусматривать режимы ведения систематического каталога, отражающего перечень областей знаний, по которым имеются книги в библиотеке. Области знаний в систематическом каталоге могут иметь уникальный внутренний номер и полное наименование. Каждая книга может содержать сведения из нескольких областей знаний. Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Книга, хранящаяся в библиотеке, характеризуется следующими параметрами:
уникальный шифр (ISBN);
название;
фамилии авторов (могут отсутствовать);
место издания (город);
издательство;
год издания;
количество страниц;
стоимость книги;
количество экземпляров книги в библиотеке.
Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).
В библиотеке ведется картотека читателей.
На каждого читателя в картотеку заносятся следующие сведения:
фамилия, имя, отчество;
домашний адрес;
телефон (будем считать, что у нас два телефона — рабочий и домашний);
дата рождения.
Каждому читателю присваивается уникальный номер читательского билета.
Каждый читатель может одновременно держать на руках не более 5 книг. Читатель не должен одновременно держать более одного экземпляра книги одного названия.

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

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:
Принимать новые книги и регистрировать их в библиотеке.
Относить книги к одной или к нескольким областям знаний.
………..
Читатель должен иметь возможность решать следующие задачи:
Просматривать системный каталог, то есть перечень всех областей знаний, книги по которым есть в библиотеке.
По выбранной области знаний получить полный перечень книг, которые числятся в библиотеке.
Этот пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в нашей системе, какие пользователи в ней будут работать, какие задачи будет решать каждый пользователь. И это правильно, ведь когда мы строим здание, мы тоже заранее предполагаем: для каких целей оно предназначено, в каком климате оно будет стоять, на какой почве, и в зависимости от этого проектировщики могут предложить нам тот или иной проект. Но, к сожалению, очень часто по отношению к базам данных считается, что все можно определить потом, когда проект системы уже создан. Отсутствие четких целей создания БД может свести на нет все усилия разработчиков, и проект БД получится «плохим», неудобным, не соответствующим ни реально моделируемому объекту, ни задачам, которые должны решаться с использованием данной БД.

Строим инфологическую модель сущность-связь в нотации Crow’s Foot
Книга
ISBN
Название
Автор
Издательство
Место издания
Год издания
Количество страниц
…
Классификация
Относится
Включает
Уникальный шифр (ISBN);
Название;
Фамилии авторов (могут отсутствовать);
Место издания (город);
Издательство;
Год издания;
Количество страниц;
Стоимсть книги;
Количество экземпляров книги в библиотеке.

Инфологическая модель БД «Библиотека»

Лектор Георгица И.В.
Модель «сущность – связь» в нотации Питера Чена.
Расширенная ER-модель.

Рассмотрим трактовку инфологической модели ее создателем, Питером Ченом.

Лектор Георгица И.В.

Фрагмент ER-модели «Библиотека»

Пример «слабой» сущности

Пример нескольких связей между сущностями

Понятие дискриминатора
Чтобы уникальным образом определить сущность «Архивная запись», следует добавить к ключу этой сущности дополнительный атрибут «Дата возврата». Этот атрибут, называемый дискриминатором, или частичным ключом, должен уникальным образом идентифицировать слабую сущность.
Дискриминатор – атрибут слабого класса сущностей, идентифицирующий экземпляр этой сущности, которая должна быть обязательно связана с конкретным экземпляром сущности сильного класса.

Пример рекурсивной связи

Элементы расширенной ER-модели
Специализация – создание одного или более подклассов некоторого класса сущностей, причем подклассы должны иметь собственные атрибуты.
Специализация является одним из видов образования иерархии классов.

Пример специализации

Пример нескольких специализирующих иерархий

Элементы расширенной ER-модели
Генерализация – создание суперкласса из общих атрибутов коллекции подклассов.
Множественное наследование – ситуация, в которой класс сущностей участвует более чем в одной специализирующей иерархии, и следовательно, относится более чем к одному суперклассу.

Пример множественного наследования

Лектор Георгица И.В.
Автоматизированная ER-модель
с использованием нотации П. Чена

Лектор Георгица И.В.
Ранние даталогические модели данных: иерархическая и сетевая

Иерархическая модель данных
Модель данных иерархическая (Hierarchical Data Model)
– это модель данных, в основе которой используется иерархическая древовидная структура данных.
Эта модель появилась первой среди всех даталогических моделей, именно ее поддерживает первая из зарегистрированных промышленных СУБД IMS фирмы IBM

Графическое изображение иерархической структуры
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, подчиненные. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим».
Узлы и ветви модели образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях.

СУБД, поддерживающая иерархическую модель данных.
Иерархическая модель данных активно использовалась во многих СУБД на платформе мейнфреймов до появления реляционных систем.
Наиболее известным ее представителем является СУБД I(D)MS (Information DataBase Management System) компании IBM Corp., первая версия которой была разработана в конце 60-х гг. Система IMS эксплуатируется до настоящего времени.

Пример иерархической структуры базы данных

Основные элементы иерархической модели данных
1) поле;
2) сегмент;
3) физическая запись БД;
4) база данных.

Поле - это минимальная неделимая единица данных, доступная пользователю в среде иерархической СУБД
Сегмент (необходимо различать тип сегмента и экземпляр сегмента) – поименованная совокупность полей в иерархической модели (т.е. тип записи, а экземпляр сегмента – это запись с конкретными значениями)

Понятие физической записи БД:
Сегменты объединены в ориентированный древовидный граф:
Физической записью БД называют каждое дерево в рамках модели,
а совокупность всех деревьев является БАЗОЙ ДАННЫХ

Пример иерархической структуры базы данных
ПОЛЕ
СЕГМЕНТ

а1 b1 b2 b3 c1 d1 d2 e1
a2 b4 b5 c2 c3 d3 d4 e2 e3 e4

Модель данных сетевая
( Network Data Model )
– это модель, допустимые структуры данных в которой могут быть представлены в виде графа общего вида.
Вершинами такого графа могут являться данные различных типов — от атомарных элементов данных до записей сложной структуры. Дуги графа представляют связи между этими данными.
Сетевую модель данных обычно ассоциируют с деятельностью организации CODASYL (Conference of Data System Languages) и именем Чарльза Бахмана.

Графическое изображение сетевой структуры

Пример сетевой структуры базы данных

Основные элементы сетевой модели данных
Элемент данных
Агрегат данных
Запись
Набор данных

Элемент данных в сетевой модели- минимальная единица информации (соответствует полю в иерархической модели).
Агрегат данных – следующий уровень обобщения в сетевой модели:
- агрегат типа «вектор», соответствует линейному набору данных;
- агрегат типа «повторяющаяся группа»

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

Пример сетевой структуры базы данных

Реляционная модель данных
( РМД )
– логическая модель данных, которая представляет множество взаимосвязанных отношений и включает следующие компоненты:
Структурный аспект — данные в базе данных представляют собой набор отношений.
Аспект целостности — отношения отвечают определённым условиям целостности.
Аспект обработки — поддерживаются операторы манипулирования отношениями (реляционная алгебра, реляционные исчисления).

ПРИМЕРЫ

Иерархическая модель БД «Фильмотека»

Сетевая модель БД «Фильмотека»

Реляционная модель БД «Фильмотека»

Заполненные таблицы в реляционной модели БД «Фильмотека»

Ранжирование моделей данных по эффективности выполнения практических задач

Лектор Георгица И.В.
Общие понятия реляционного подхода к организации БД. Реляционная модель данных.

Пример реляционной БД

Автор реляционной модели данных - доктор университета штата Мичиган (США) Эдгар Фрэнк Кодд (Codd E.F.)
(1923 г.- 2003 г)
Первая публикация - 1970 г.
Теоретическим базисом является
теория множеств

Основные понятия реляционной модели
1) отношение (таблица);
2) схема отношения (таблицы);
2) атрибут;
3) первичный ключ;
4) кортеж;
5) тип данных;
6) домен (domain).

Пример отношения «Film»

Пример схемы отношения:
Film (Title, Year, Length, Filmtype)

Пример схемы БД:
Film (Title, Year, Length, Filmtype);
Studio (Name, Address, presN);
Produсer (Name, Address, Sert, NetWorth);

Фундаментальные свойства отношений (таблиц)
1. Атомарность значений атрибутов (каждый атрибут в отношении имеет уникальное имя и простой тип)
Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения).
Принято говорить, что в реляционных базах данных допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме.

Фундаментальные свойства отношений
2. Отсутствие кортежей-дубликатов ( в таблице нет двух одинаковых строк)
Это свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения (таблицы) как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов.

Фундаментальные свойства отношений
3. Отсутствие упорядоченности кортежей (порядок строк в таблице произвольный)
Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных.

Фундаментальные свойства отношений
4. Отсутствие упорядоченности атрибутов (таблица имеет столбцы, соответствующие атрибутам отношения, и порядок следования атрибутов при обращении к таблице не принципиален)
Атрибуты отношений (таблиц) не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута.
Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов.

Фундаментальные свойства отношений
4. Изменяемость отношений.
Реляционная модель данных рассматривает отношение как структурный тип. Тип определяется схемой отношения.
Все кортежи – знаки типа – удовлетворяют одной и той же схеме.
Тело отношения может изменяться во времени:
Отдельные кортежи могут добавляться или удаляться.
Могут изменяться значения атрибутов в существующих кортежах.
Поэтому можно говорить об экземпляре (текущем значении) отношения с заданной схемой

Необходимо знать определения следующих понятий реляционной модели:
отношение;
атрибут;
первичный ключ;
кортеж;
домен;
тип данных;
схема отношения;
схема базы данных;
степень отношения;
мощность отношения (кардинальное число).

Необходимо знать фундаментальные свойства отношений и их трактовку:
1.Атомарность значений атрибутов
2.Отсутствие кортежей-дубликатов
3.Отсутствие упорядоченности кортежей
4.Отсутствие упорядоченности атрибутов
5. Изменяемость отношений (таблиц)

Соответствие компонентов модели «сущность-связь» и реляционной модели

Правила перехода от ER-модели к реляционной модели данных
1. Каждой сущности ставится в соответствие отношение (таблица) реляционной модели данных.
2. Каждый атрибут сущности становится атрибутом отношения. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (допустимость Null-значений).
3. Ключевой атрибут (набор атрибутов) сущности становится первичным ключом (primary key) соответствующего отношения. Атрибуты, входящие в первичный ключ, получают автоматически свойство обязательности (Not Null).

Правила перехода от ER-модели к реляционной модели данных
4. В каждое отношение, соответствующее подчиненной сущности, добавляются атрибуты основной сущности, являющийся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (foreign key)
5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак Null). При обязательном типе связей атрибуты, входящие во внешний ключ, получают свойство запрета неопределенных значений (Not Null).

Правила перехода от ER-модели к реляционной модели данных
6. Разрешение связей типа многие-ко-многим (в реляционной модели допустимо использование только 1:М и 1:1) производится введением дополнительного связующего отношения, которое связано с каждым исходным отношением связью один-ко-многим, атрибутами этого отношения являются первичные ключи связываемых отношений.
7. Для отражения иерархии классов сущностей при переходе к реляционной модели возможны несколько вариантов представления:
1) можно создать одно отношение для всех подклассов одного суперкласса. В него включают все атрибуты всех классов.
2) для каждого класса и для суперкласса создаются свои отдельные отношения.

Инфологическая модель БД «Библиотека»

Реляционная модель БД «Библиотека»

Лектор Георгица И.В.
Язык запросов SQL. Команда SELECT

Реляционная алгебра

Реляционная алгебра – теоретический базис SQL

SQL – это гибкий язык, который можно использовать самыми разными способами.
Он является самым распространенным инструментом, используемым для связи с реляционной базой данных.

Этот язык не является процедурным, как FORTRAN, Basic, С, COBOL, Pascal и Java. Чтобы решить задачу с помощью одного из этих процедурных языков, приходится писать процедуру, которая выполняет одну за другой указанные операции, пока выполнение задачи не будет закончено. Процедура может быть линейной последовательностью или содержать ветвление, но в любом случае программист указывает порядок выполнения.
Иными словами, SQL является непроцедурным языком. Чтобы с его помощью решить задачу, сообщите, что именно вам нужно, как если бы вы говорили с джином из лампы Аладдина. И при этом не надо говорить, каким образом получить для вас то, что вы хотите. Система управления базами данных (СУБД) сама решит, как лучше всего выполнить ваш запрос.

ПРИМЕР (ЧТО НАМ НУЖНО – запрашиваем у БД)
SELECT * FROM EMPLOYEE WHERE AGE >40 OR SALARY >60000;
Этот оператор выбирает из таблицы EMPLOYEE все строки, в которых или значение столбца AGE (возраст) больше 40 или значение в столбце SALARY (зарплата) больше 60000. SQL сам знает, каким образом надо выбирать информацию. Ядро базы данных проверяет базу и принимает для себя решение, каким образом следует выполнять запрос. Все, что от вас требуется, – указать, какие данные вам нужны.
Помните:
Запрос – это вопрос, который вы задаете базе данных. Если какие-либо ее данные удовлетворяют условиям вашего запроса, то SQL передает их вам.

в последние годы оказывалось немалое давление, чтобы дополнить SQL некоторыми процедурными возможностями.
Поэтому теперь в составе новой версии спецификации SQL, SQL:2003, имеются такие средства процедурного языка, как блоки BEGIN, условные операторы IF, функции и процедуры.
Благодаря этим новым средствам, можно хранить программы на сервере с тем, чтобы их могли повторно использовать многие пользователи.

И всё же …
В современных реализациях SQL отсутствуют многие простые программные конструкции, которые являются фундаментальными для большинства других языков программирования.
В приложениях для повседневной жизни, как правило, требуются хотя бы некоторые из этих конструкций, поэтому SQL на самом деле представляет собой подъязык данных. Даже имея дополнения, появившиеся в SQL вместе со стандартом SQL: 1999 и дополнительные расширения, добавленные в SQL:2003, все равно для создания законченного приложения необходимо использовать вместе с SQL один из программных языков, такой, например, как С.

Формы SQL

Формы SQL

Формы SQL

КАК SQL «экономит силы» программиста
SQL устраняет много работы которую вы должны были бы сделать если бы вы использовали универсальный язык программирования, например C. Чтобы сформировать реляционную базу данных на C, вам необходимо было бы начать с самого начала. Вы должны были бы определить объект - называемый таблицей, которая могла бы расти чтобы иметь любое число строк, а затем создавать постепенно процедуры для помещения значений в нее и извлечения из них.
Если бы вы захотели найти некоторые определенные строки, вам необходимо было бы выполнить по шагам процедуру, подобную следующей :
1. Рассмотрите строку таблицы.
2. Выполните проверку - является ли эта строка одной из строк которая вам нужна.
3. Если это так, сохраните ее где-нибудь пока вся таблица не будет проверена.
4. Проверьте имеются ли другие строки в таблице.
5. Если имеются, возвратитесь на шаг 1.
6. Если строк больше нет, вывести все значения сохраненные в шаге 3.
SQL сэкономит вам все это. Команды в SQL могут работать со всеми группами таблиц как с единым объектом и могут обрабатывать любое количество информации извлеченной или полученной из их, в виде единого модуля.

Команды SQL
Язык SQL состоит из ограниченного числа команд, специально предназначенных для управления данными.
Одни из этих команд служат для определения данных, другие – для их обработки, а остальные – для администрирования данных.

Зарезервированные слова
Кроме команд, специальное значение в SQL имеют и некоторые другие слова.
Вместе с командами они зарезервированы для специального использования, поэтому эти слова нельзя применять в качестве имен переменных или любым другим способом, для которого они не предназначены.
Легко увидеть, почему таблицам, столбцам и переменным нельзя давать имена из списка зарезервированных слов. Представьте себе, какая путаница возникнет из-за такого оператора:
SELECT SELECT FROM SELECT WHERE SELECT = WHERE;

Типы данных
В разных реализациях SQL поддерживаются различные исторически сложившиеся типы данных. В спецификации SQL:2003 признаны только пять заранее определенных общих типов:
числовой;
строковый;
логический;
даты-времени;
интервальный.
Внутри каждого из этих типов может быть несколько подтипов (точный числовой; приблизительный числовой; символьный строковый; битовый строковый; строковый для больших объектов).
Кроме встроенных, заранее определенных типов также поддерживаются сконструированные и определяемые пользователем типы.
Сейчас в базах данных хранятся данные многих разных типов, в том числе графические изображения звуки и анимация.

Неопределенные значения
Если в поле базы данных находятся какие-то данные, то в этом поле имеется определенное значение. А если поле не содержит никаких данных, то говорят, что у него неопределенное значение.
Неопределенное значение (null) в числовом поле – это не одно и то же, что нуль.
А в символьном поле неопределенное значение – это не одно и то же, что пустая строка.
И нуль и пустая строка являются определенными значениями. Неопределенное же значение указывает на то, что имеющееся в поле значение неизвестно.
Совет:
Поле может иметь неопределенное значение по самым разным причинам. Так что не торопитесь с выводами относительно того, что означает конкретное неопределенное значение.

В следующем списке приведены некоторые из этих случаев и даны примеры каждого из них.
Значение существует, но вам оно пока что неизвестно. До того, как была точно вычислена масса кварка, вы в самой верхней строке таблицы QUARM (кварк) установили в поле MASS (масса) неопределенное значение.
Значение пока что не существует. В строке SQL For Dummies, 5th Edition таблицы BOOKS (книги) вы установили в поле TOTAL_SOLD (всего продано) неопределенное значение, так как первые данные о продажах за квартал еще не поступили.
Поле для данной строки неприменимо. В строке С-ЗРО таблицы EMPLOYEE (наемный работник) вы установили в поле SEX (пол) неопределенное значение, так как С-ЗРО – это андроид, у которого пола нет.
Значение выходит за пределы установленного диапазона. В строке Oprah Winfrey (Опра Уинфри) таблицы EMPLOYEE вы установили в поле SALARY (зарплата) неопределенное значение, так как для этого поля вы задали тип NUMERIC (8.2), а оклад, предусмотренный в контракте Опра, превышает 999999.99 доллара.

Подразделы SQL

Примеры

Пример 12. Образцы WHERE-фразы:
WHERE title = ‘LONDON’;
WHERE netWorth >= 100 000;
WHERE year >1970 and not color;
WHERE name BETWEEN 'A' AND 'B';
WHERE name LIKE 'А% А% А%';
WHERE title LIKE 'Star _ _ _ _'

Пример 16а.
Группировка по нескольким полям.

Пример 19.
ORDER BY при использовании с предложением GROUP BY служит для упорядочения групп.