Лекция 3. Концептуальная модель данных

**1-ый учебный вопрос: Сущности, атрибуты и экземпляры сущностей.** Сущность, это объект реального мира, явно отличимый от других объектов. Например – игрушка-паззл в магазине, отдел игрушек в магазине, продавец отдела игрушек, домашний адрес продавца магазина игрушек, и т.д. Чаще всего сущность идентифицирует набор экземпляров сущностей. При этом, следует отметить, что один и тот же экземпляр сущности может встречаться в базе данных в нескольких сущностях. Каждая сущность описывается с помощью набора атрибутов сущности. При этом, каждому экземпляру сущности соответствует один и тот же набор атрибутов, что и остальным экземплярам этой сущности. Именно этим обстоятельством подчеркивается похожесть экземпляров одной сущности. При построении сущности, набор ее атрибутов может отличаться в зависимости от желаемого уровня детализации описываемой сущности. Так, например, при низкой детализации набором атрибутов для сущности Сотрудник могут быть ФИО и Фото, тогда как при высокой детализации, помимо перечисленных атрибутов могут быть использованы Номер_парковочного_места, Номер_страховки и т.д... Для каждого атрибута, пользователем определяется домен допустимых значений. Так, например, для атрибута Сотрудник.Фамилия доменом может быть набор символьных значений с ограничением в 20 символов, каждое значение которого должно начинаться с большой буквы. В большинстве существующих моделей данных, для каждого экземпляра сущности должен быть определен ключ. Ключ – минимальный набор атрибутов, однозначно характеризующий каждый отдельный экземпляр сущности. **2-ый учебный вопрос: Связи и наборы связей.** Связь – это ассоциация между двумя или большим количеством сущностей (исключением является рекурсивная связь). С точки зрения теории множеств, связь можно описать, как пересечение переменных, входящих в два или несколько множеств по определенным правилам. Так, например, экземпляры сущности Сотрудники связаны с экземплярами сущности Отделы. Связи, если это необходимо, могут иметь описательные атрибуты. Так, если в связь необходимо включить лишь тех сотрудников, которые работали в Отделах 15.02.2020, к связи между сущностями необходимо добавить описательный атрибут Датаработы. Связи между сущностями могут быть представлены как в общем виде, так и в виде экземпляра связи. Пример нескольких экземпляров связи показан на рис. 1.  Необычная ситуация показанная на рис. 1 связана с тем, что, в сущности Сотрудники могут находиться сотрудники разных ролей, например Руководитель и Подчиненный. В зависимости от того, какой экземпляр сущности участвует в связи, логика связи будет разной, что и показано на рисунке. **3-ий учебный вопрос: Дополнительные элементы концептуальной модели данных.** Переменные ключа – свойства ключей сущностей, управляющие типами связей между сущностями. Обычно выделяют три основных типа возможных связей: один-к-одному (один экземпляр одной сущности связан с одним и только одним экземпляром другой сущности), один-ко-многим (один экземпляр одной сущности связан с одним или несколькими экземплярами другой сущности) и многие-ко-многим (множество экземпляров одной сущности связано с множеством экземпляров другой сущности). В графическом виде, перечисленные выше типы связей показаны на рис. 2.  Приведем несколько примеров типов связей между сущностями. Один-к-одному, связь между сущностями Сотрудник использует СлужебныйАвтомобиль. За каждым сотрудником закреплен свой служебный автомобиль и его и только его он и использует. Один-ко-многим, связь между сущностями Студент посещает СтудКружок. По своему желанию, каждый студент может посещать один, а, если позволяет успеваемость и свободное время, еще и несколько кружков. Многие-ко-многим. Связь между сущностями Музыкант играет в Оркестре. Разные музыканты регулярно собираются в разные коллективы, что, очевидно, описывается связью много Музыкантов играет в множестве Оркестров. Слабая сущность – сущность, для идентификации которой необходимо наличие собственного идентифицирующего атрибута в паре с первичным ключом другой сущности (идентифицирующего владельца). Пример слабой сущности Дети (dependents) показан на рис. 3.  Сотрудник обеспечивает МедицинскийПолис Ребенку. Предположим, что сотрудники приобретают полисы медицинского страхования для своих детей. В базе, информация о детях хранится в виде экземпляров сущности с двумя атрибутами – Имяребенка (pname) и Возраст (Age). Очевидно, что ни один из приведенных атрибутов не обеспечивает уникальность каждого отдельного экземпляра сущности. Но, если в качестве ключа будет использована пара атрибутов ssn, pname, необходимое условие идентификации будет выполнено. На связи со слабой сущностью накладываются два ограничения: - связь между идентифицирующим владельцем и слабой сущностью всегда будет один-ко-многим; - каждый экземпляр слабой сущности должен быть связан с соответствующим экземпляром идентифицирующего владельца. Иерархия классов сущностей. Структура наследования атрибутов общего класса сущностей всеми их подклассами. Несмотря на общую с языками программирования логику наследования свойств классов, есть существенная разница – при запросе к данным общего класса, каждый подкласс учитывается отдельно. Приведем пример случая, когда декомпозиция класса на подклассы будет весьма удобна. Предположим, что группа сотрудников нашей организации работает по контракту, тогда как другая группа сотрудников работает в рамках почасовой оплаты их труда. В этом случае будет разумно разделить общий класс сущностей Сотрудники на два подкласса – Сотрудники_Почасовая (Hourly_Emps) и Сотрудники_Контракт (Contract_Emps). И тот и другой подкласс унаследуют атрибуты общего класса (например, Номер_Сотрудника (ssn), ФИО (name) и т.д..), и, вместе с этим, будут иметь каждый свой уникальный атрибут (Зарплата_Час (hourly_wages) и Часов_Работы (hours_worked) для сущности Сотрудники_Почасовая и Номер_Контракта (contractid) для сущности Сотрудники_Контракт соответственно). На схеме связи случаи с разделением общей сущности на подсущности визуализируется элементом ISA (is-a). Пример показан на рис. 4.  Помимо указания на присущие подклассу атрибуты, следует обратить внимание на два дополнительных условия, сопутствующих иерархии ISA – это ограничение перекрытия (overlap constraints) и ограничение покрытия (cover constraints). Ограничение перекрытия определяет – могут ли два подкласса содержать одинаковый экземпляр сущности, а ограничение перекрытия определяют – могут ли все экземпляры общей сущности находиться в одном из подклассов. Агрегация. Агрегация – способ реализации связи одной сущности с несколькими сущностями для тех случаев, когда организация тернарной (тройной) связи нецелесообразно. Пример агрегации приведен на рис. 5.  Предположим, что в рамках организации, группа реализуемых Проектов (Projects) финансируется Отделами (Departments). С целью мониторинга реализуемых проектов, в каждом случае Отдел выделяет специального сотрудника (employees). Структура данных, где сущность связана с набором связей установленых между двумя другими сущностями (на рис. 5 выделено прямоугольником) называется агрегацией. Отметим тот факт, что логически набор связей финансирует (sponsors) не связан с набором связей мониторит (monitors), поскольку это совершенно разные процедуры (скорее всего с разными используемыми наборами атрибутов), что не позволяет нам реализовать эту структуру хранения в виде тернарной связи. **4-ий учебный вопрос: Некоторые вопросы концептуального проектирования.** Вопрос выбора элемента хранения модели (сущность или атрибут). Одна из наиболее часто встречающихся проблем моделирования. Практически, любая сущность, в зависимости от обстоятельств и структуры модели, может выступать и в качестве атрибута другой сущности. Выбор между этими двумя элементами баз данных зачастую осуществляется при проведении нормализации таблиц баз данных в ходе их проектирования. Приведем пример, когда одна и та же логическая единица данных может выступать как сущностью, так и атрибутом сущности. Предположим, что осуществляется наблюдение за объектом Сотрудник. Разумно предположить, что организация хочет в базе данных для каждого сотрудника хранить его домашний адрес. В данном случае, Домашний_Адрес будет выступать атрибутом сущности Сотрудник. Но что, если у сотрудника теоретически может быть несколько экземпляров Домашнего_Адреса (адрес родителей, собственный дом, и т.д.). Очевидно, что в этом случае Домашний_Адрес будет выступать отдельной сущностью с несколькими экземплярами внутри. Также, упомянем тот случай, когда нам необходимо использовать разные элементы Домашнего_Адреса (дом, квартира, город) отдельно, для различных приложений или иных целей. В данном случае Домашний_Адрес также будет создан как сущность с Атрибутами: дом, квартира, город и т.д... На рис. 6 приведен еще один пример вариации с выбором “сущность или атрибут”. Сотрудники работают в Отделе с момента найма до момента увольнения (промежуток времени один). Промежуток времени работы описан дополнительными атрибутами к связи Работает.  На рис. 7 приведен пример тоже же схемы данных, но для случая, когда по какой-то причине (например - сезонная работа) сотрудники работают в Отделе в рамках нескольких временных промежутков. В этом случае будет создана сущность Длительность, и каждый временной интервал будет сохранен, как отдельный экземпляр этой сущности.  Также, при принятии решения по вопросу определения “сущность-атрибут” обязательно необходимо обращать внимание на то, к какой логической модели данных планируется обратиться в ходе процесса проектирования базы данных. Вопрос использования бинарных связей или тернарных связей между сущностями. Как правило, основным элементом построения баз данных являются сущности, связанные друг с другом попарно, бинарными связями. Однако, бывают ситуации, когда применение более сложных и разветвленных связей (как правило, тернарных) более рационально и эффективно с точки зрения решения определенных задач, связанных с хранением данных. Представим ситуацию, когда объектами наблюдения являются сущности Отделы (departments), Поставщики (suppliers), Детали (parts). Отделы через контрактные обязательства закупают у поставщиков детали. На рис. 8 показаны традиционная схема отношений, построенная на трех бинарных связях и схема отношений, построенная на одной тернарной связи.  В случае, когда приложение БД использует хранимые данные в процессе создания договоров на поставку деталей, данные будут собираться со всех трех сущностей, приведенных в схеме. В случае трех бинарных связей, данные сперва должны быть агрегированы в один массив, после чего они будут переданы на обработку на уровень приложения, тогда как в случае тернарной связи данные сразу будут готовы к обработке. **5-ий учебный вопрос: Концептуальный словарь данных.** Концептуальный словарь данных – таблица, сопровождающая концептуальную ER-модель базы данных. Основной задачей этой таблицы является фиксация имен элементов создаваемой модели для дальнейшего проектирования, типизация каждого элемента (сущность, атрибут (ключевой/не ключевой), связь (сильная/слабая)) и описание атрибута для возможности оперативного согласования работ связанных с проектированием базы данных в коллективе. Фрагмент концептуального словаря данных приведен на рис. 9.  На приведенном фрагменте отмечено наличие ключевого атрибута сущности id_work. В столбце Описание дано максимально подробное и понятное описание выбранного атрибута, приведенное с целью однозначной трактовки смысла атрибута любым человеком, который будет иметь дело с этой схемой данных. Также имеется описание идентификационной-зависимой (слабой) связи с именем produces. Для этой связи тоже дано максимально подробное описание. ***Вопросы для самостоятельного изучения по итогам лекции.*** 1. Что такое кардинальное число? Максимальная кардинальность? Минимальная кардинальность? 2. Приведите примеры, содержащие концептуальную модель со слабыми сущностями. Почему они в этой модели слабые? Как называется связь, в которой участвует слабая сущность? 3. В чем разница между связью типа ”имеет” и связью типа ”есть”? Для каждой связи привести пример. Тестовые задания для самопроверки. 1. Какой из вариантов не является функцией СУБД? А) обеспечение пользователя языковыми средствами манипулирования данными Б) координация проектирования, реализации и ведения БД В) реализация языков определения и манипулирования данными Г) поддержка моделей пользователя защита и целостность данных 2. Система управления базами данных (СУБД) — это… А) совокупность программных средств, для создания файлов в БД Б) совокупность баз данных В) совокупность нескольких программ предназначенных для совместного использования БД многими пользователями Г) совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями Д) состоит из совокупности файлов, расположенных на одной машине 3. Чем или кем регулируется отсутствие кортежей-дубликатов: А) ресурсом СУБД Б) проектировщиком В) схемой данных 4. Что не относится к основным функциям СУБД: А) обеспечение целостности и согласованности данных Б) анализ массивов данных В) интерпретация инструкций, отправляемых пользователем или приложением 5. База данных – это… А) специальным образом организованная и хранящаяся на внешнем носителе совокупность взаимосвязанных данных о некотором объекте произвольный набор информации Б) совокупность программ для хранения и обработки больших массивов информации В) интерфейс, поддерживающий наполнение и манипулирование данными компьютерная программа, позволяющая в некоторой предметной области делать выводы, сопоставимые с выводами человека-эксперта 6. В реляционной модели данных схема характеризует? А) базу данных Б) набор экземпляров отношения В) отношение 7. Какой из вариантов связи IS-A характеризует поведение одного экземпляра сущности? А) перекрывающий IS-A Б) покрывающий IS-A В) описание подходит обоим вариантам 8. Какой из вариантов связи IS-A характеризует поведение всех экземпляров сущности? А) покрывающий IS-A Б) перекрывающий IS-A В) описание подходит обоим вариантам