базе данных

РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ,
ВЫСОКОПРОИЗВОДИТЕЛЬНЫЕ ВЫЧИСЛЕНИЯ, ГРИД И
ОБЛАЧНЫЕ ТЕХНОЛОГИИ
СУБД
РАЗРАБОТКА БАЗЫ ДАННЫХ.
РЕЛЯЦИОННАЯ МОДЕЛЬ
Лекция 2
Контакты и литература
Желенкова Ольга Петровна
[email protected], http://www.sao.ru/hq/zhe/miscRU.html

Дейт К.Дж., Введение в системы баз данных, 2001

Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных.
Полный курс, 2003

Кузнецов С.Д. Основы баз данных. Учебное пособие, 2007

Бурлаков П.В., Петров В.Ю. Введение в системы баз данных. Учебное
пособие, 2010.

Зеленков Ю.А. Введение в базы данных, 1997
http://www.mstu.edu.ru/study/materials/zelenkov/toc.html

ERD https://www.lucidchart.com/users/login
Базы данных: термины
Предметная область – информация о части реального мира, подлежащая изучению с
целью организации управления и автоматизации.
Информация – сведения, воспринимаемые человеком или специальными устройствами
как отражение фактов материального мира в процессе коммуникации.
Данные – поддающееся многократной интерпретации представление информации в
формализованном виде, пригодном для передачи, связи или обработки.
Информация должна быть представлена в некоторой форме (т.е. превратиться
в данные), чтобы ей можно было обмениваться. Информация есть в первую
очередь интерпретация (смысл) такого представления.
База данных (data base) – поименованная совокупность взаимосвязанных
структурированных данных, которая отражает актуальное состояние объектов и их
отношений в рассматриваемой предметной области, причем они организованы так,
чтобы обеспечить независимость данных от программ обработки.
Система управления базами данных (data base management system) – это
совокупность программ и языковых средств, предназначенных для управления
данными в базе данных, ведения базы данных и обеспечения взаимодействия её с
прикладными программами .
Этапы проектирования БД
I. Информационно-логическое (инфологическое)
проектирование
• анализ и построение модели предметной области.
II. Определение требований к платформе:
• выбор аппаратной платформы и операционной
системы.
• выбор СУБД и архитектуры, в которой она будет
работать.
III. Логическое проектирование БД
(даталогическое):
• преобразование схемы предметной области в
схему базы данных;
• создание схем отношений;
• нормализация отношений.
IV. Физическое проектирование БД:
• реализация схемы БД на DDL-языке выбранной
СУБД;
• создание дополнительных объектов БД (индексов,
представлений, триггеров и др.).
Инфологическое проектирование
Инфологическая модель ПрО включает описание структуры и динамики ПрО, а
также характера информационных потребностей пользователей. Описание
выполняется в терминах, понятных пользователю и независимых от реализации
системы.
Инфологическая модель ПрО не должна зависеть от модели данных, которая
будет использована при создании БД.
1. Определение границ предметной
области (ПрО).
2. Анализ ПрО.
Методы анализа:
•функциональный,
•предметный;
•метод сущность-связь
(entity-relation method, ER-метод)
Модель "сущность-связь" была
предложена в 1976 г. Питером ПинШэн Ченом
Метод сущность-связь
сущность (entity) – объект ПрО, сведения о котором необходимо хранить в БД.
Сущность фактически представляет из себя множество атрибутов, которые
описывают свойства всех членов данного набора сущностей.;
атрибут – характеристика сущности (свойство сущности);
связь – устойчивая ассоциация между сущностями.
Сущности:
базовые (сильная) - наличие не зависит от наличия или отсутствия других
сущностей
зависимые (слабая) - наличие зависит от наличия или отсутствия других
сущностей
Выделяют понятия тип сущности и экземпляр сущности.
Тип позволяет выделить из всего множества сущностей ПрО группу сущностей,
однородных по структуре и поведению (относительно рамок рассматриваемой
ПрО).
Данные в БД представлены экземплярами сущностей.
Атрибуты сущностей:
Идентифицирующие и описательные атрибуты.
Идентифицирующие позволяют отличить один экземпляр сущности от другого;
Описательные заключают в себе интересующие нас свойства сущности.
Составные и простые атрибуты.
Простой атрибут имеет неделимое значение.
Составной атрибут является комбинацией нескольких элементов, возможно,
принадлежащих разным типам данных
Однозначные и многозначные атрибуты
могут иметь соответственно одно или много значений для каждого экземпляра
сущности.
Основные и производные атрибуты.
Значение основного атрибута не зависит от других атрибутов;
значение производного атрибута вычисляется на основе значений других атрибутов.
Обязательные и необязательные
первые должны быть указаны при размещении данных в БД, вторые могут не
указываться.
Для каждого атрибута необходимо определить название, тип данных и описать
ограничения целостности – множество значений, которые может принимать данный
атрибут. Множество значений (область определения) атрибута называется доменом.
Связи между сущностями
Связи между сущностями
Построение ERD
В процессе построения диаграммы можно выделить следующие этапы:
1. Идентификация представляющих интерес сущностей и связей.
2. Идентификация семантической информации в наборах связей (например,
является ли некоторый набор связей отображением 1:n).
3. Определение кардинальности связей.
4. Определение атрибутов и наборов их значений (доменов).
5. Организация данных в виде отношений "сущность-связь".
Модель предметной области
Совокупность типов сущностей и типов связей между ними характеризует
структуру предметной области. Собственно данные представлены
экземплярами сущностей и связей между ними. Данные экземпляров
сущностей и связей хранятся в БД информационной системы, включая
метаданные - описание типов сущностей и связей.
Модель данных должна содержать три компоненты:
• структура данных - точка зрения пользователя на представление данных.
• набор допустимых операций
• ограничения целостности - механизм поддержания соответствия данных
предметной области на основе формально описанных правил.
В базе данных ограничения целостности накладываются на атрибуты
сущностей, типы сущностей, типы связей и/или их экземпляры.
Имеется три типа ограничений на значения:
• ограничения на допустимые значения в наборе значений (домене).
• ограничения на разрешенные значения для каждого атрибута.
• ограничения на существующие значения в базе данных
Результаты инфологического проектирования
Определение требований к платформе
Выбор платформы:
оценка требований к вычислительным ресурсам, необходимым для
функционирования системы, выбор типа и конфигурации ЭВМ, выбор типа и
версии операционной системы (ОС). Выбор зависит от таких показателей, как:
примерный объём данных в БД, динамика их роста;
характер и интенсивность запросов к данным (извлечение и обновление
отдельных записей, обработка групп записей, обработка отдельных отношений
или соединение отношений);
режим работы (интерактивный, пакетный или режим реального
времени).
Выбор СУБД:
тип модели данных, которую поддерживает данная СУБД характеристики
производительности СУБД;
степень оснащённости СУБД инструментарием для персонала
администрирования данными, возможность развития ИС
удобство и надежность СУБД в эксплуатации;
наличие специалистов по работе с конкретной СУБД;
стоимость СУБД и дополнительного программного обеспечения.
Модели данных

Иерархическая модель данных (ИМД).

Сетевая модель данных (СМД).

Реляционная модель данных (РМД).

Объектно-реляционная модель данных (ОРМД).
}I поколение
- II поколение
- III поколение
Стандарт SQL-3 (SQL-2003). Oracle (с версии 8.0), DB2, Informix,
PostgreSQL, SQL Server 2008 и др.)

Объектно-ориентированная модель данных (ООМД). O2, GemStone, Iris
и др.
Стандарт ODMG 3.0 (Object Database Management Group).

Многомерные базы данных.

Потоковые базы данных.

...
Иерархическая модель данных
Графическая диаграмма концептуальной схемы базы данных называется
деревом определения. Пример иерархической базы данных:
ФАКУЛЬТЕТ
Шифр_факультета, Название_факультета
КУРС
Номер_курса
ГРУППА
Номер_группы, Год_образования
СТУДЕНТ
Номер_зачетной_книжки,
ФИО_студента, Паспортные_данные
ИМД не поддерживает:
КАФЕДРА
Шифр_кафедры,
Название_кафедры
ПРЕПОДАВАТЕЛЬ
ФИО_преподавателя,
Должность,
Паспортные_данные
необязательный класс членства и ручной
режим включения записей.
Основной недостаток: дублирование данных
Сетевая модель данных
Сетевая модель позволяет организовывать БД, структура которых
представляется графом общего вида. Организация данных в сетевой
модели соответствует структуризации данных по версии CODASYL.
Связи между записями в СМД выполняются в виде указателей, т.е.
каждая запись хранит ссылку на другую однотипную запись (или
признак конца списка) и ссылки на списки подчинённых записей,
связанных с ней групповыми отношениями.
ПОЛИКЛИНИКИ
диспансеризация
ОРГАНИЗАЦИИ
работают
ЖИТЕЛИ
проживают
КВАРТИРЫ
РЭУ (Ремонтноэксплуатационные управления)
обслуживают
Сетевая модель данных
Наиболее распространенной и стандартизованной из реализаций СМД
является модель CODASYL. В соответствии с ней описание схемы БД
осуществляется на языке COBOL, а манипулирование данными – с
помощью включающего языка программирования высокого уровня.
Примером сетевой СУБД является система Integrated Database
Management System (IDMS).
СМД является наиболее полной с точки зрения реализации различных
типов связей и ограничений целостности, но она является достаточно
сложной для проектирования и поддержки. В этой модели не
обеспечивается физическая независимость данных, т.к. наборы
организованы с помощью физических ссылок. Также в СМД не
обеспечивается независимость данных от программ. Из-за этих
недостатков эта модель не получила широкого распространения.
Реляционная модель данных
Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в
1970 г. В настоящее время эта модель является фактическим стандартом,
на который ориентируются практически все современные коммерческие
СУБД.
В реляционной модели достигается гораздо более высокий уровень
абстракции данных, чем в иерархической или сетевой. В упомянутой статье
Е.Ф.Кодда утверждается, что "реляционная модель предоставляет
средства описания данных на основе только их естественной
структуры, т.е. без потребности введения какой-либо дополнительной
структуры для целей машинного представления". Другими словами,
представление данных не зависит от способа их физической организации.
Это обеспечивается за счет использования математической теории
отношений (само название "реляционная" происходит от английского
relation - "отношение").
Реляционная модель данных
Отношение обладает двумя основными свойствами:
1. В отношении не должно быть одинаковых кортежей, т.к. это множество.
2. Порядок кортежей в отношении несущественен.
Ключи отношения

Ключ – атрибут (группа атрибутов), которые позволяют
классифицировать кортеж (запись таблицы).

Потенциальный ключ (уникальный ключ) – атрибут (группа
атрибутов), которые позволяют идентифицировать кортеж (запись
таблицы).

Первичный ключ – обязательный уникальный ключ. Для каждой
таблицы может быть определен только один первичный ключ.

Вторичный ключ – любой другой ключ, кроме первичного. Может
быть необязательным и неуникальным.

Внешний ключ – служит для организации связей между таблицами.
Организация связей между таблицами
Связь один-ко-многим: Отделы – Сотрудники
Таблица
«Сотрудники»
Табельный
номер
Таблица «Отделы»
ФИО
сотрудника
Отдел
023
Волкова Елена
Павловна
2
113
Белов Сергей
Юрьевич
1
101
Рогов Сергей
Михайлович
Панина Анна
Алексеевна
2
056
...
098
...
Фролов Юрий
Вадимович
1
Название отдела
Номер
отдела
1
Информационный отдел
2
Администрация
3
Отдел кадров
...
...
9
Проектный отдел
«Номер отдела» - первичный
ключ в таблице «Отделы»
...
9
«Отдел» – внешний ключ в таблице «Сотрудники»
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Логическое проектирование реляционной БД
Физическое проектирование реляционной БД
Физическое проектирование реляционной БД