Основные понятия баз данных и этапы её проектирования

1.

Основные понятия баз
данных и этапы её
проектирования
Работу выполнил
студент группы ПСО-18
Акопян Вануш

2.

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

3.

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

4.

Классификаци
я баз данных

5.

Функции СУБД
• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.
• транзакция

6.

Связи
между
таблицами
Записи в таблице могут зависеть
от одной или нескольких записей
другой таблицы. Такие
отношения между таблицами
называются связями. Связь
определяется следующим
образом: поле или несколько
полей одной таблицы,
называемое внешним
ключом, ссылается на первичный
ключ другой таблицы.

7.

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

8.

Модель данных и ее виды
• Модель данных –
совокупность структур
данных, ограничений
целостности и операций
манипулирования
данными. Модели
используются для
представления данных в
информационных
системах.
иерархическая;
сетевая;
реляционная.

9.

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

10.

Иерархическая
модель данных

11.

Сетева
я
модель
данных
• В сетевой структуре при тех же основных
понятиях (уровень, узел, связь) каждый
элемент может быть связан с любым
другим элементом.
• Примером сложной сетевой структуры
может служить структура базы данных,
содержащей сведения о студентах,
участвующих в научноисследовательских работах (НИРС).
Возможно участие одного студента в
нескольких НИРС, а также участие
нескольких студентов в разработке
одной НИРС. Графическое изображение
описанной в примере сетевой структуры
состоит только из двух типов записей.

12.

Сетевая модель данных

13.

Реляционная модель ориентирована на
организацию данных в виде двумерных таблиц.
Каждая реляционная таблица представляет собой
двумерный массив и обладает следующими
свойствами:
Реляционная
модель
данных
• каждый элемент таблицы – один элемент данных;
• все столбцы в таблице однородные, т.е. все
элементы в столбце имеют одинаковый тип
(числовой, символьный и т.д.) и длину;
• каждый столбец имеет уникальное имя
(заголовки столбцов являются названиями полей
в записях);
• одинаковые строки в таблице отсутствуют;
• порядок следования строк и столбцов может быть
произвольным.

14.

Реляционная
модель данных

15.

Этапы проектирования баз данных
Процесс проектирования БД представляет собой процесс переходов от неформального словесного
описания информационной структуры предметной области к формализованному описанию объектов
предметной области в терминах некоторой модели. Конечной целью проектирования является построение
конкретной БД. Очевидно, что процесс проектирования сложен и поэтому имеет смысл разделить его на
логически завершенные части – этапы. Можно выделить пять основных этапов проектирования БД:
• Сбор сведений и системный анализ предметной области.
• Инфологическое проектирование.
• Выбор СУБД.
• Даталогическое проектирование.
• Физическое проектирование.

16.

Сбор
сведений и
системный
анализ
предметной
области
Первый и важнейший этап при проектировании БД. В нем необходимо
провести подробное словесное описание объектов предметной области и
реальных связей, присутствующих между реальными объектами. Желательно
чтобы в описании определялись взаимосвязи между объектами предметной
области..В общем случае выделяют два подхода к выбору состава и
структуры предметной области:
· Функциональный подход – применяется тогда, когда заранее известны
функции некоторой группы лиц и комплексы задач, для обслуживания
которых создается эта БД, т.е. четко выделяется минимальный
необходимый набор объектов предметной области под описание.
· Предметный подход – когда информационные потребности заказчиков
БД четко не фиксируются и могут быть многоаспектными и динамичными.
В данном случае минимальный набор объектов предметной области
выделить сложно. В описание предметной области включаются такие
объекты и взаимосвязи, которые наиболее характерны и существенны для
нее. При этом БД становится предметной, и подходит для решения
множества задач (что кажется наиболее заманчивым). Однако трудность
всеобщего охвата предметной области и невозможность конкретизации
потребностей пользователей приводит к избыточно сложной схеме БД,
которая для некоторых задач будет неэффективной.
Системный
анализ
должен
заканчиваться
подробным
описанием
информации об объектах предметной области, которая должна храниться в
БД, формулировкой конкретных задач, которые будут решаться с
использованием данной БД с кратким описанием алгоритмов их решения,
описанием выходных и входных документов при работе с БД.

17.

Инфологическое проектирование
Частично формализованное описание объектов предметной области в
терминах некоторой семантической модели.
Процесс проектирования длительный, требует обсуждений с заказчиком и
специалистами в предметной области. Кроме того, при разработке серьезных
корпоративных информационных систем проект базы данных является
фундаментом, на котором строится вся система в целом, и вопрос о
возможности кредитования часто решается экспертами банка на основании
именно грамотно сделанного инфологического проекта БД. Следовательно,
инфологическая модель должна включать такое формализованное описание
предметной области, которое легко будет восприниматься не только
специалистами в области БД. Описание должно быть настолько емким, чтобы
можно было оценить глубину и корректность проработки проекта БД.

18.

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

19.

Физическое проектирование
Заключается в увязке логической структуры БД и физической среды хранения
с целью наиболее эффективного размещения данных, т.е. отображение
логической структуры БД в структуру хранения. Решается вопрос размещения
хранимых данных в пространстве памяти, выбора эффективных методов
доступа к различным компонентам «физической» БД, решаются вопросы
обеспечения безопасности и сохранности данных. Ограничения, имеющиеся в
логической модели данных, реализуются различными средствами СУБД,
например, при помощи индексов, декларативных ограничений целостности,
триггеров, хранимых процедур. При этом опять-таки решения, принятые на
уровне логического моделирования определяют некоторые границы, в
пределах которых можно развивать физическую модель данных. Точно также,
в пределах этих границ можно принимать различные решения.

20.

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

21.

Концептуальное (инфологическое)
проектирование
• Построение семантической (смысловой) модели предметной области. Такая модель создаётся без
ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель»,
«модель базы данных», «модель предметной области», «концептуальная модель», «концептуальная
модель базы данных», «концептуальная модель предметной области» и «инфологическая модель»
являются синонимами.
• Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого
формальным аппаратом. Обычно используются графические нотации, подобные ER(entity-relation)диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
• описание информационных объектов, или понятий предметной области и связей между ними;
• описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между
ними.

22.

Логическое (даталогическое)
проектирование
• Создание схемы базы данных на основе конкретной модели данных, например,
реляционной модели данных. Для реляционной модели данных даталогическая модель
— набор схем отношений, обычно с указанием первичных ключей, а также «связей»
между отношениями, представляющих собой внешние ключи.
• Преобразование концептуальной модели в логическую модель, как правило,
осуществляется по формальным правилам. Этот этап может быть в значительной
степени автоматизирован.
• На этапе логического проектирования учитывается специфика конкретной модели
данных, но может не учитываться специфика конкретной СУБД.

23.

Спасибо за
внимание