Что определяет степень связи между сущностями
BestProg
ER-модель. Понятие связи. Мощность связи. Типы связей. Примеры
Рекомендуется перед изучением данной темы ознакомиться с следующими темами:
Содержание
Поиск на других ресурсах:
1. Что такое связь в ER-модели? Пример
Между двумя сущностями может быть установлена связь. Отношения между сущностями характеризуются глаголом, который можно применить для взаимодействия между ними. Связь – это некое отношение между двумя типами сущностей.
2. Как связи обозначаются в ER-модели?
В ER-модели связи обозначаются в виде ромба. Внутри ромба указывается глагол, который определяет характер взаимодействия между типами сущностей.
3. Какие типы связей различают в ER-модели?
Между типами сущностей различают следующих 3 типа связей:
4. Пример связи типа «один ко многим» – 1:М
На рисунке 1 изображен фрагмент ER-модели, которая демонстрирует связь между типами сущностей Студент и Группа.
Рис. 1. Связь между типами сущностей Студент и Группа
5. Что такое мощность связи? Пример
Мощность связи – это значение максимального количества конкретных экземпляров сущностей, которые могут использоваться для данной связи. Мощность связи 5 говорит о том, что в данной связи может быть использовано не более 5 разных экземпляров сущностей. Или, иными словами, не более 5 отличных между собой значений.
Например. Студент учится в группе. Между типами сущностей Студент и Группа можно установить связь 1:30, как показано на рисунке 2. Число 30 означает, что в группе может учиться не более 30 студентов.
Рисунок 2. Связь между сущностями Студент и Группа
Если количество значений экземпляров сущностей произвольно, то мощность связи наиболее часто представляется символом M или знаком ∝ (бесконечность).
Использование конкретных числовых значений в мощности связи есть удобным при разработке программного обеспечения, поскольку можно более качественно реализовать структуры данных зная их максимальный размер.
6. Пример связи типа «много ко многим»
Рисунок 3. Отображение связи типа «много ко многим»
На рисунке 3 символами M и N обозначен тип связи «много ко многим». Этот тип связи выбран, так как один студент может изучать несколько (много) дисциплин, и, наоборот, одну дисциплину может изучать несколько студентов.
7. Какое характерное отличие типа связи «один к одному» 1:1 в сравнении с другими типами?
Связь «много ко многим» сложно реализовать программно, так как реляционные базы данных поддерживают связь «один ко многим». Чтобы решить эту проблему, разработчик базы данных создает искусственный тип сущности, которая выполняет функции коммутатора между двумя основными сущностями.
Пример. Для двух типов сущностей Студент и Дисциплина можно реализовать искусственный тип сущности, как показано на рисунке 4.
Рис. 4. Реализация связи «много ко многим» или M:N
Для обеспечения лучшей наглядности вышеприведенной схемы, часто реализуется упрощенный вариант, который изображен на рисунке 5. В этом случае, искусственный тип сущности изображают в виде ромба, вписанного в прямоугольник.
Рис. 5. Реализация упрощенного варианта искусственного типа сущности на ER-диаграмме
Что определяет степень связи между сущностями
Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей. Данная глава является скорее иллюстрацией методов семантического моделирования, чем полноценным введением в эту область.
Основные понятия ER-диаграмм
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная».
Каждая сущность в модели изображается в виде прямоугольника с наименованием:
Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Графически связь изображается линией, соединяющей две сущности:
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи:
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи:
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на Рис. 4).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».
Пример разработки простой ER-модели
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями «Покупатель» и «Товар»? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму:
Концептуальные и физические ER-модели
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом:
Легко заметить, что полученные таблицы сразу находятся в 3НФ.
Выводы
Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование.
Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.
Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.
При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.
В данной главе, являющейся иллюстрацией к методам ER-моделирования, не рассмотрены более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.
Метод моделирования «сущность-связь»
Изучив материал настоящей лекции, вы будете знать:
Введение
Для логического проектирования реляционных ХД применяются следующие методики.
В настоящей лекции мы рассмотрим метод моделирования » сущность-связь «.
Понятие предметной области и архитектура данных
Понятие предметной области
Важно понимать, что логическая модель предметной области создается на этапе анализа требований к ИС и не содержит предположений о технологии реализации хранилища или базы данных.
Оперируя терминами «данные» и «вопросы», вопросно-ответное отношение можно представить в виде таблицы, столбцами которой являются элементы данных, а строками — вопросы. Каждая ячейка такой таблицы имеет логическое значение 1, если вопрос использует этот элемент данных, или 0 — в противном случае.
Понятие предметной области является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение понятия предметной области ограничивает и делает обозримым пространство информационного поиска в ИС, и позволяет выполнять запросы за конечное время.
Примерами сущностей (с точки зрения логической модели предметной области ) или объектов (с точки зрения внешнего мира по отношению к ИС) являются: студент, группа студентов, аудитория для занятий, время занятий и. т. д.
С объектами связано две проблемы — идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя — это прямой способ идентификации объекта. К косвенным способам идентификации объекта относят его свойства в их понимании как характеристики или признака.
Объекты взаимодействуют между собой через свои свойства, что порождает ситуации. Ситуации – это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание «Программист, менеджер есть служащие компании» описывает отношение включения. Таким образом, вся информация об объектах и сущностях предметной области описывается с помощью утверждений на естественном языке.
Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодном для анализа.
Рассмотрим высказывание: «Студент Иванов А.А, родился в 1992 году». Оно выражает следующие свойства объекта «Иванов А.А.»:
Первое свойство устанавливает связь между парами объектов «Иванов А.А.» и «год рождения», а второе свойство устанавливает связь между парами объектов «Иванов А.А.» и «множество студентов». Формализация этого высказывания представляется как результат присваивания значений переменных, входящих в следующие предикаты:
Различают статические и динамические ситуации. Примерами статических ситуаций являются такие ситуации, как «иметь цвет», «иметь возраст» и т.д. Примерами динамических ситуаций являются такие ситуации, как «создать механизм», «выпечь хлеб» и т.д.
Приведенная выше классификация вводит в предметную область два важных аспекта – пространство и время, причем время понимается и как момент события, и как интервал между событиями. Предметная область существует в пространстве и во времени, т.е. ей присущи, как и реальному миру, временные и пространственные отношения и связи. Следует отличать реальное время внешнего мира и его отражение в ИС и в источниках информации. В ИС взаимосвязи, зависящие от времени, фиксируются только после их регистрации. Таким образом, предметная область в каждый конкретный момент времени представляет собой выделенную совокупность определенных объектов и ситуаций, называемую состоянием предметной области (или снимком).
Таким образом, предметная область — это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической модели фрагмента действительности.
Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же, как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.
Примером классической предметной области для создания систем складирования данных и, следовательно, для ХД является задача анализа продаж компании. В качестве объектов этой предметной области можно выделить следующие: «менеджер продаж», «товар», «склад», «офис продаж», «покупатель». В качестве ситуаций – «продать товар», «купить товар», «отгрузить товар со склада», «доставить товар».
Архитектура данных предметной области
ХД является предметно-ориентированной, интегрированной, постоянной во времени коллекцией исторических данных, используемой различными группами пользователей для поддержки принятия решений или анализа данных. Информация в компьютерных системах, в том числе и в ХД, представляется в виде элементов данных (items). Одно из основных положений концепции ХД состоит в очистке, фильтрации, преобразовании, суммировании и агрегации данных, а затем размещении их в некоторой структуре для обеспечения информационных потребностей пользователей. Определение такой структуры является одной из основных задач логического моделирования ХД.
Одной из первых задач проектировщика ХД является определение архитектуры данных. Архитектура данных — это принципы субъективного представления информации в виде данных в рамках модели предметной области. При построении архитектуры данных проектировщик ХД определяет элементы данных, их свойства и взаимосвязи между ними. Одним из ключевых моментов построения архитектуры данных является степень детализации информации при преобразовании ее в элементы данных. Процесс такого преобразования называют структуризацией данных.
Для данных OLTP-систем решение вопросов, связанных с уровнем детализации данных, не является столь важным, как в системах складирования данных. В БД OLTP-систем данные обычно детально структурированы. Для представления данных в ХД проектировщик должен специально решить вопрос об уровне структуризации данных, исходя из требований к системе складирования данных. Решение этого вопроса весьма важно, поскольку при агрегации и суммировании данных некоторые диапазоны данных из подающей OLTP-системы могут быть не представлены в ХД. Например, ХД телекоммуникационной компании может содержать оплату за пользование телефоном, просуммированную по минутам, а подающая система хранит такие данные по секундам.
Уровень структуризации (детализации или гранулированности) данных (Data granularity ) является одной из самых важных характеристик ХД. Уровень структуризации данных — это степень детализации хранимых данных, оптимальная с точки зрения решения информационно-аналитических задач в рамках предметной области ХД.
Грубо говоря, уровень структуризации данных определяет количество запросов, на которые можно получить ответы в системе складирования данных. Если в ХД поддерживается высокий уровень структуризации данных, то система поддерживает практически любой запрос в рамках предметной области ХД. В примере, приведенном выше, невозможно получить ответ на вопрос: сколько абонент Иванов А.А. заплатил за пять секунд разговора первого января 2009 года.
Структуризация данных предполагает разбиение всего набора данных на определенные классы с целью дальнейшей детализации внутри выделенного класса. Для ХД характерны три основных вида данных (класса).
Понятие предметной области и хранилища данных
Понятие предметной области используется практически при проектировании и разработке всех классов информационных систем с базами и хранилищами данных. Предметная область определяет ту часть реального мира, которая будет моделироваться и реализоваться в системе. Предметная область определяет наиболее общие вытекающие из ее семантики критерии и требования к системе.
Вопросы, с которыми пользователи обращаются к ХД, носят, как правило, стратегический и более обобщенный характер, чем в OLTP-системах. Ответы на них предполагают агрегацию и суммирование данных по различным направлениям деятельности организации. Это требует от систем с ХД ориентации на конкретные предметные области деятельности организации.
Предметные области в системах с ХД формируются в соответствии с направлениями деятельности организации. Чтобы определить список предметных областей для таких систем, необходимо определить основные виды деятельности организации — например, продажи, производство, клиенты и т.д.
Для выделения предметных областей в ХД часто используется так называемая методика «правило SW1», а именно ответы на вопросы: когда (when), где (where), кто (who), что (what), почему (why) и как (how) – по отношению к видам деятельности организации (интересы бизнеса). Например, при ответе на вопрос «кто» интересы бизнеса могут охватывать следующие объекты: «покупатели», «сотрудники», «поставщики», «менеджеры», «партнеры по бизнесу» и т. д.
Отметим, что при решении задач анализа и, следовательно, при разработке BI-систем наиболее перспективным подходом для определения предметной области является изучение бизнес-процессов организации, а не функции, как в случае OLTP-систем.
Моделирование методом «сущность-связь»
Основные понятия модели «сущность-связь»
Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Таким образом, сущность представляет класс объектов, который является результатом абстрагирования реального объекта. Обычно они обозначаются именем существительным естественного языка.
Сущность описывается с помощью данных, именуемых свойствами или атрибутами (attributes) сущности. Как правило, атрибуты являются определениями в высказывании о сущности и обозначаются именами существительными естественного языка.
Сущности вступают в связи друг с другом через свои атрибуты. Каждая группа атрибутов, описывающих одно реальное проявление сущности, представляет собой экземпляр сущности (instance). Иными словами, экземпляр сущности – это реализации сущности, отличающиеся друг от друга и допускающие однозначную идентификацию. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически, имя сущности дается по имени ее экземпляра.
Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.
Различают однозначные и многозначные атрибуты. Однозначными являются атрибуты, которые в пределах конкретного экземпляра сущности имеют только одно значение. В противном случае они считаются многозначными.
В реляционной модели отношения реализуются только через ограничение целостности по внешнему ключу. Поэтому проектировщик реляционного ХД должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые будут определять уникальный ключ связи. Выбор ключей сущностей — одно из важнейших проектных решений, которое предстоит сделать проектировщику при переходе к физической модели базы данных.
Выявление слабых сущностей и связанных с ними обязательных отношений необходимо для обеспечения целостности и согласованности данных. Так, например, неизвестному клиенту невозможно приписать заказ.
Супертип с порожденными им подтипами является примером так называемой составной сущности. Составная сущность является логической конструкцией модели для представления набора сущностей и связей между ними как единого целого.
Пример. Сущность «автомобиль» можно разбить на следующие подтипы : автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.
Для этого необходимо предпринять следующие действия: