Лекція

«Основні підходи до проектування

баз даних»

1. Основні положення.
2. Підходи до проектування бази даних.
3. Проектування реляційних баз даних з
використанням моделі «сутність-зв'язок».

Кафедра безпеки інформаційних систем і технологій

 Этапы жизненного цикла системы баз данных

База данных является основным функциональным компонентом

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

Разработка приложений Определение пользовательского интерфейса и прикладных программ, которые

используют и обрабатывают данные в базе данных
Разработка прототипа Создание рабочей модели системы базы данных, которая позволяет
(необязательный этап) разработчикам или пользователям представить и оценить окончательный вид и
способы функционирования системы
Реализация Физическое воплощение разработанной базы данных и прикладных программ
Преобразование и загрузка Преобразование и загрузка данных (и прикладных программ) из старой
данных системы в новую
Тестирование Приложение базы данных тестируется с целью обнаружения ошибок, а также
его проверки на соответствие всем требованиям, выдвинутым пользователями
Эксплуатация и На этом этапе система базы данных считается полностью разработанной и
сопровождение реализованной. Впредь вся система будет находиться под постоянным
наблюдением и соответствующим образом поддерживаться. В случае
необходимости в функционирующую систему могут вноситься изменения,
отвечающие новым требованиям. Реализация этих изменений проводится
посредством повторного выполнения некоторых из перечисленных выше этапов
жизненного цикла.
 Основные положения
Проектирование любой базы данных основано на сборе и анализе
информации, которая потребуется организации для ее эффективного
функционирования.
Существующие методики сбора фактов:
 изучение документации;
 проведение собеседований;
 наблюдение за работой предприятия;
 проведение исследований;
 проведение анкетирования.
Перечень основных требований, предъявляемые к проектируемым БД:
 начальный размер базы данных;
 темп роста базы данных;
 типы информационного поиска и их распределение по частоте
использования;
 требования к работе в сети и совместному доступу;
 производительность;
 защита;
 резервное копирование и восстановление;
 юридические вопросы.
 Основные положения
Пример.
Начальный размер базы данных можно определить, исходя из
следующей информации:
 В компании, состоящей более чем из 100 отделений, работает примерно 2 000
сотрудников (в среднем 20 и максимум 40 сотрудников имеются в каждом
отделении).
 Приблизительно 100 000 объектов недвижимости доступны для аренды во
всех отделениях (в среднем 1 000 и максимум 3 000 объектов недвижимости
имеются в каждом отделении).
 Имеется примерно 60 000 владельцев недвижимости (в среднем 600 и
максимум 1000 владельцев недвижимости зарегистрированы в каждом
отделении).
 Имеется примерно 100 000 клиентов, зарегистрированных во всех отделениях
компании (в среднем 1 000 и максимум 1 500 клиентов состоят на учете в
каждом отделении).
 Всеми отделениями осуществляется примерно 4 000 000 осмотров
недвижимости (в среднем 40 000 и максимум 100 000 осмотров недвижимости
выполняются в каждом отделении).
 Примерно 400 000 договоров аренды заключены по всем отделениям (в
среднем 40 000 и максимум 100 000 договоров аренды ведутся в каждом
отделении).
 Ежемесячно компания (все ее отделения) публикует в 100 газетах (на сайтах)
примерно 50 000 объявлений.
 Основные положения
Темп роста базы данных зависит от следующей информации:
 Каждый месяц к базе данных добавляются примерно 500 новых объектов
недвижимости и 200 новых владельцев недвижимости.
 Как только объект недвижимости становится недоступным для сдачи в аренду,
соответствующая запись удаляется из базы данных. Каждый месяц удаляются
примерно 100 записей об объектах недвижимости.
 Если владелец недвижимости не предоставляет для аренды объект недвижимости в
течение 2 лет, запись о нем удаляется. Каждый месяц удаляются примерно 100
записей о владельцах недвижимости.
 Каждый месяц в компанию поступают на работу и увольняются из нее
приблизительно 20 сотрудников. Запись о сотрудниках удаляется через год после их
увольнения. Каждый месяц удаляются примерно 20 записей о сотрудниках.
 Каждый месяц в отделениях регистрируются примерно 1000 новых клиентов. Если
клиент не осматривает или не арендует объект недвижимости в течение 2 лет,
запись о нем удаляется. Каждый месяц удаляются примерно 100 записей о
клиентах.
 Каждый день по всем отделениям записываются около 5000 новых документов по
осмотру объектов недвижимости. Сведения об осмотре объектов недвижимости
удаляются через год после создания записи.
 Каждый месяц по всем отделениям оформляются приблизительно 1000 новых
договоров аренды. Сведения о договорах аренды объектов недвижимости
удаляются через год после создания записи.
 Каждую неделю в газетах (на сайтах) публикуются около 1000 объявлений. Сведения
об объявлениях в газетах (на сайтах) удаляются через год после создания записи.
 Основные положения
Типы информационного поиска и их распределение по частоте
использования
 Поиск сведений об отделении  приблизительно 10 раз в день.
 Поиск сведений о сотруднике отделения  приблизительно 20 раз в день.
 Поиск сведений о конкретном объекте недвижимости  приблизительно 5000 раз в
день (с понедельника по четверг), приблизительно 10 000 раз в день (с пятницы по
субботу). Пик нагрузки  с 12.00 до 14.00 и с 17.00 до 19.00 ежедневно.
 Поиск сведений о владельце недвижимости — приблизительно 100 раз в день.
 Поиск сведений о клиенте  приблизительно 1000 раз в день (с понедельника по
четверг), приблизительно 2000 раз в день (с пятницы по субботу). Пик нагрузки  с
12.00 до 14.00 и с 17.00 до 19.00 ежедневно.
 Поиск сведений об осмотре объекта недвижимости  приблизительно 2000 раз в
день (с понедельника по четверг), приблизительно 5000 раз в день (с пятницы по
субботу). Пик нагрузки  с 12.00 до 14.00 и с 17.00 до 19.00 ежедневно.
 Поиск сведений о договорах аренды  приблизительно 1000 раз в день (с
понедельника по четверг), приблизительно 2000 раз в день (с пятницы по субботу).
Пик нагрузки  с 12.00 до 14.00 и с 17.00 до 19.00 ежедневно.
Требования к работе в сети и совместному доступу
Все отделения должны быть объединены в сеть с централизованной базой данных,
находящейся в головном офисе компании, с соблюдением мер защиты. Система
должна предоставлять возможность одновременного доступа к ней хотя бы 2 или 3
сотрудникам из каждого отделения. Необходимо предусмотреть приобретение
определенного количества пользовательских лицензий для обеспечения
одновременного доступа к СУБД такому числу пользователей.
 Основные положения
Производительность
 В утренние часы, но не в часы максимальной нагрузки, время ожидания
ответа на поиск одной записи  менее 1 секунды. В часы максимальной
загрузки время ожидания ответа на один поиск  менее 5 секунд.
 В утренние часы, но не в часы максимальной загрузки, время ожидания
ответа на поиск множества записей  менее 5 секунд. В часы
максимальной загрузки время ожидания ответа на один поиск нескольких
записей  менее 10 секунд.
 В утренние часы, но не в часы максимальной загрузки, время выполнения
операции обновления/сохранения  менее 1 секунды. В часы
максимальной загрузки время выполнения операции
обновления/сохранения  менее 5 секунд.

Защита
 База данных должна быть защищена паролем.
 Каждому сотруднику должны быть присвоены привилегии (полномочия)
доступа к базе данных согласно его пользовательскому представлению.
Например: руководитель, помощник руководителя, менеджер, сотрудник и
т.д.
 Сотруднику можно видеть только данные, необходимые для его работы, и
в удобном для этого виде.
 Основные положения
Копирование и восстановление
База данных должна копироваться ежедневно в полночь.

Юридические вопросы
В каждой стране имеются свои законы, регулирующие способ
компьютеризированного хранения личных данных. Так как база данных содержит
данные о персонале, клиентах и владельцах недвижимости, необходимо изучить и
учитывать любые правовые нормы, которым она должна удовлетворять.
Например, такими как:
 закон Украины «Про захист персональних даних»;
 Общий регламент защиты персональных данных Европейского Союза (General
Data Protection Regulation – GDPR)
и другими.
 Подходы к проектированию базы данных
Существуют два основных подхода к проектированию систем баз данных: нисходящий и
восходящий.
При восходящем подходе работа начинается с самого нижнего уровня атрибутов (т.е.
свойств сущностей и связей), которые на основе анализа существующих между ними
связей группируются в отношения, представляющие типы сущностей и связи между ними.
Процесс нормализации представляет собой вариант восходящего подхода при
проектировании баз данных.
Восходящий подход в наибольшей степени приемлем для проектирования простых баз
данных с относительно небольшим количеством атрибутов. Однако использование этого
подхода существенно усложняется при проектировании баз данных с большим
количеством атрибутов (некоторые БД могут содержать от сотен до тысяч атрибутов),
установить среди которых все существующие функциональные зависимости довольно
затруднительно.
Более подходящей стратегией проектирования сложных баз данных является
использование нисходящего подхода.
Начинается этот подход с разработки модели предметной области (ПрО), которая
содержит несколько высокоуровневых сущностей и связей, затем работа продолжается в
виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к
ним атрибутов.
Нисходящий подход демонстрируется в концепции модели "сущность-связь".
В этом случае работа начинается с выявления сущностей и связей между ними,
интересующих данную организацию в наибольшей степени.
Проектирование реляционных баз данных с использованием
модели «сущность-связь»
Необходимость семантического моделирования:
Во-первых, построение мощной и наглядной концептуальной схемы предметной
области (ПрО) позволяет более полно оценить специфику моделируемой ПрО и
избежать возможных ошибок на стадии логического проектирования, например,
разработки схемы реляционной базы данных.
Во-вторых, на этапе семантического моделирования производится важная
документация (даже если она сделана вручную в виде нарисованных диаграмм и комментариев к
ним), которая может оказаться очень полезной не только при проектировании схемы
БД, но и при эксплуатации, сопровождении и развитии уже заполненной БД.
Без семантического моделирования можно обойтись, если число таблиц реляционной
БД не превышает десяти, но оно совершенно необходимо, если БД включает более
сотни таблиц.
Процедура создания концептуальной схемы вручную с ее последующим
преобразованием, например, в реляционную схему БД, если последняя содержит
несколько сотен таблиц, затруднительна. В этом случае используют различные
средства автоматизации проектирования (CASE-средств  Computer Aided Software
Engineering). Однако, на завершающем этапе проектирования, например, реляционной
схемы потребуется ручная работа проектировщика, так как невозможно сгенерировать
автоматически на основе концептуальной схемы многие объекты БД (такие, например,
как триггеры, роли, политики, хранимые процедуры и т. д.).
Проектирование реляционных баз данных с использованием
модели «сущность-связь»
 Модель "сущность-связь" была предложена Питером Ченом (Peter Chen) в 1976 г.
Она основывается на некоторой важной семантической информации о реальном
мире.
 ER-моделирование представляет собой нисходящий подход к проектированию
базы данных, который начинается с выявления наиболее важных данных,
называемых сущностями, и связей между данными, которые должны быть
представлены в модели. Затем в модель вносятся дополнительные сведения,
такие как атрибуты (сущностей, связей), а также ограничения, относящиеся к
сущностям, связям и атрибутам.
 ER-моделирование  это важный метод, которым должен владеть любой
проектировщик базы данных.
 Моделирование предметной области базируется на использовании графических
диаграмм, включающих небольшое число разнородных компонентов. Простота и
наглядность представления концептуальных схем баз данных в ER-модели
привели к ее широкому распространению в CASE-системах, поддерживающих
автоматизированное проектирование реляционных баз данных.
 Для графического представления схем модели сущность-связь используется
несколько нотаций (нотация Мартина, нотация IDEF1X, нотация Баркера,
обозначения, предложенные Ченом и др.).
По сути, все варианты диаграмм сущность-связь исходят из одной идеи  рисунок всегда
нагляднее текстового описания. Все такие диаграммы используют графическое изображение
сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Нотация Чена

Идентифицирующая связь  это

такая связь, при которой экземпляр
дочерней сущности
идентифицируется через свою
ассоциацию с родительской
сущностью. Атрибуты первичного
ключа родительской сущности
становятся атрибутами первичного
ключа дочерней.
Неидентифицирующая связь  это
такая связь, при которой экземпляр
дочерней сущности не
идентифицируется через свою
ассоциацию с родительсой
сущностью.

Пример:
 Нотация Crow’s Feet (Мартина)

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

атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид
линии в месте соединения с сущностью определяет кратность связи:
 Нотация Crow’s Feet (Мартина)
Кратность связи – это количество возможных экземпляров сущности
некоторого типа, которые могут быть связаны с одним экземпляром
сущности другого типа с помощью определенной связи (может задаваться
в виде одного значения или как диапазон значений).
Имя связи указывается на линии ее обозначающей.
Пример:
 Нотация IDEF1X
Обозначения сущностей:

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

Атрибуты, составляющие ключ сущности, группируются в верхней части прямоугольника и
отделяются горизонтальной чертой.
Обозначения связей:

Обозначение кратности связей: Пример:

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

Дискриминатор  атрибут родового предка, который показывает, как отличить одну

категориальную сущность от другой.
Также может существовать отношение неполной категоризации (сущности-категории
составляют неполное множество потомков общей сущности):

Например:
 Нотация Баркера

Сущности обозначаются прямоугольниками, внутри которых приводится список атрибутов.

Ключевые атрибуты отмечаются символом # (решетка). Связи обозначаются линиями с
именами, место соединения связи и сущности определяет кратность связи:

Пример:

Для обозначения отношения

категоризации вводится элемент "дуга":
Нотация UML
Сущность – это реальный или представляемый определенным образом
идентифицированный объект, информация о котором должна сохраняться и быть
доступной.
При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра
этого типа. Для большей выразительности и лучшего понимания имя сущности
может сопровождаться примерами конкретных экземпляров этого типа.
Типы сущностей могут также подразделяться на сильные и слабые.
Сущность сильного типа  тип сущности, существование которого не зависит от
какого-то иного типа сущности.
Сущность слабого типа  тип сущности, существование которого зависит от
какого-то другого типа сущности.
Сущности слабого типа иногда называют дочерними, зависимыми или
подчиненными, а сущности сильного типа – родительскими, сущностями
владельцами или доминантными.
Тип связи является набором ассоциаций между одним (или несколькими) типами
сущностей, участвующими в этой связи.

Пример бинарной связи между сущностями Владелец_Недвижимости и

Объекты_Недвижимости
Степень связи – количество сущностей, которые охвачены данной связью. Связь со
степенью два называется бинарной, со степенью три – тернарной, со степенью четыре –
кватернарной. Наиболее распространенной степенью связи является бинарная.
Экземпляр связи обозначает все конкретные экземпляры сущности, участвующие в этой
связи.
Семантическая сеть  это информационная модель предметной области, имеющая вид
ориентированного графа, вершины которого соответствуют объектам предметной области,
а дуги (рёбра) задают отношения между ними.
Семантическая сеть с изображением отдельных экземпляров связи, типа 'Включает'
Рекурсивная связь  связь, в которой одни и те же сущности участвуют
несколько раз в разных ролях.

Пример рекурсивной связи 'Руководит' с ролевыми именами 'Руководитель' и

'Контролируемый сотрудник'
Пример сущностей, связанных двумя различными связями 'Руководит' и
'Включает' с указанием ролевых имен
 Ограничения, которые могут накладываться на сущности, участвующие в связях

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

каждой сущности, участвующей в связи конкретного типа. Понятие кардинальности бинарной
связи является обобщением понятия кратности, которое рассматривается как связь "один к
одному" (1:1), "один ко многим" (1:*; 1:N; 1:∞) и "многие ко многим" (*:*; ∞:∞; M:N).
Степень участия определяет, участвуют ли в связи все или только некоторые экземпляры
сущности.

Связь «один к одному»

 Связь «один к одному»

Кратность взаимно-однозначной (1:1) связи 'Руководит' между

сущностями Персонал и Отделение
 Связь «один ко многим»

Семантическая сеть, поясняющая связь 'Отвечает' между сущностями

Персонал и Объекты_Недвижимости
 Связь «один ко многим»

Кратность связи "один ко многим" (1:*) между

сущностями Персонал и Объекты_Недвижимости
 Связь «многие ко многим»

Семантическая сеть, поясняющая связь 'Рекламирует' между

сущностями Газета и Объекты_Недвижимости
 Связь «многие ко многим»

Кратность связи "многие ко многим" (*:*) между

сущностями Газета и Объекты_Недвижимости
Кратность сложной связи  количество экземпляров сущности
определенного типа в n-арной связи, определяемое после фиксации
остальных (n-1) значений (может задаться в виде одного значения или как
диапазон значений).
Семантическая сеть, поясняющая трехстороннюю связь 'Регистрация' с
постоянными значениями сущностей Персонал и Отделение
 Кратность трехсторонней связи 'Регистрация'

Способы представления ограничений кратности

Варианты записи Описание
0..1 Нуль или один экземпляр сущности
1..1 (или просто 1) Точно один экземпляр сущности
0..* (или просто *) От нуля и больше экземпляров сущности
1..* От одного и больше экземпляров сущности
5..10 От пяти до десяти экземпляров сущности включительно
0, 3, 6-8 Нуль, три, шесть, семь или восемь экземпляров сущности
Атрибут  свойство типа сущности или типа связи.
Домен атрибута  набор допустимых значений одного или нескольких атрибутов.
Простой атрибут  это атрибут, состоящий из одного компонента с независимым
существованием.
Составной атрибут  это атрибут, состоящий из нескольких компонентов, каждый из
которых характеризуется независимым существованием.
Однозначный атрибут  это атрибут, который содержит одно значение для каждого
экземпляра сущности определенного типа.
Многозначный атрибут  атрибут, который содержит несколько значений для каждого
экземпляра сущности определенного типа.
Производный атрибут  атрибут, который представляет значение, производное от значения
связанного с ним атрибута или некоторого множества атрибутов, принадлежащих некоторому
(не обязательно данному) типу сущности.

Пример связи 'Рекламирует' с атрибутами date и cost