No Image

Что такое идентифицирующая связь

0 просмотров
22 января 2020

Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены в любую схему баз данных.

Наиболее распространенным средством моделирования данных являются диаграммы “сущность — связь” (ERD), нотация которых была впервые введена П.Ченом. Базовыми понятиями ERD являются:

Сущность (Entity) — реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.

Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:

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

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

    Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между двумя сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

    Связь (отношение) между сущностями обладает свойством, именуемым мощность — количество экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя.

    • заказчик может иметь 0,1 или много заказов — связь “0,1 или много”;
    • заказ содержит 1 или много наименований товаров — связь “1 или много”;
    • у автомобиля ровно 4 колеса — связь “ровно n”;
    • билет резервируется для 0 или 1 пассажира — связь “ 0 или 1”.

    Наиболее типичной является связь “0, 1 или много” ( в теории реляционных баз данных — связь “1:М” или “один-ко-многим”).

    Атрибут — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.

    При проектировании данных рекомендуется создавать атомарные атрибуты, например, страна город — отдельные атрибуты при описании адреса.

    Для обеспечения связи между сущностями используются понятия ключей :

    • первичный ключ:
    • альтернативный ключ;
    • внешний ключ.

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

    Первичный (главный) ключ должен обладать следующими свойствами:

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

    Альтернативный ключ — заменитель главного ключа. Используется для организации поиска данных. Выбирается из числа ключей-кандидатов на роль главного ключа.

    Внешний ключ — существует только для дочерней сущности и является ссылкой на значение ключа родительской сущности. При создании связей (отношений) между сущностями в дочернюю сущность передаются атрибуты, составляющие первичный ключ родительской сущности. Эти атрибуты и составляют внешний ключ.

    Под методологией понимают дисциплину проектирования:

    • критерии и правила, используемые привыполнении работы;
    • графические и текстовые средства, используемые для описания проектируемой системы.
    Читайте также:  Чернила для принтера какие подойдут

    Методология информационного моделирования IDEF1X основана на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.

    В методологии IDEF1X принята следующая терминология:

    независимая сущность (независимая от идентификатора) — если каждый экземпляр может быть однозначно идентифицирован без определения его отношения с другими сущностями;

    зависимая (зависимая от идентификатора) — если однозначная идентификация экземпляра сущности зависит от его отношения с другой сущностью (рис. П.1.1).

    В методологии принята система простых графических символов для отражения понятий:

      • прямоугольник — для обозначения независимой сущности;
      • прямоугольник со скругленными углами — для обозначения зависимой сущности;
      • линия с точкой на конце — для обозначения связи.

      Рис. П.1.1 Обозначения для a) независимой и b) зависимой сущностей модели

      Каждой сущности присваивается уникальное имя (существительное в единственном числе) и номер, разделенные косой чертой “/” и помещаемые над блоком.

      Для описания связи указываются следующие элементы:

      • утверждение связи — “выполняет”, “состоит из” и т.д. (глагол, глагольная форма;
      • мощность связи;
      • тип связи.

      В IDEF1X могут быть выражены следующие мощности связей:

        • N — принята по умолчанию — каждый экземпляр сущности-родителя может иметь 0, 1 или более связанного с ним экземпляра сущности-потомка;
        • Z — каждый экземпляр сущности-родителя должен иметь не более 1 связанного с ним экземпляра сущности-потомка:
        • P — каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

        Тип связи — если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей , в противном случае — неидентифицирующей .

        Связь изображается линией, проводимой между сущностями, с точкой но конце линии у сущности-потомка (рис. П.2).

        Рис. П.2.2. Графическое изображение мощности связи

        Идентифицирующая связь изображается сплошной линией . Сущность-потомок в идентифицирующей связи является зависимой сущностью. Сущность- родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью ( это определяется ее связями с другими сущностями).

        Неидентифицирующая связь изображается пунктирной линией . Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

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

        Сущности могут иметь также внешние ключи (Foreign Key) , которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. П.1.3.).

        Рис. П.1.3. Пример, показывающий неидентифицирующую связь

        Как видно из примера на рис. П.1.3., главный ключ сущности 2 — “СЛУЖАЩИЙ” перешел в качестве FK в сущность 4 — “ПРОЕКТНОЕ-ЗАДАНИЕ” в область неключевых атрибутов.

        Пример идентифицирующей связи показан на рис. П.1.1.

        В идентифицирующей связи первичный ключ сущности/1 переходит в качестве FK в сущность /3 и размещается в области главного ключа.

        Ниже на рис. П.1.4. показан пример построения ER-модели по стандарту IDEF1X.

        Рис.П.1.4. Пример построения ERD

        Сущности — “клиент”, “модель”, “продавец” — независимые (представляются прямоугольником), сущность “заказ” — зависимая (представляется прямоугольником со скругленными углами). Все связи между сущностями — идентифицирующие (показаны сплошной линией, главные ключи родительской сущности становятся внешними ключами дочерней сущности).

        В конрольном задании должны быть представлены описания концептуальной модели данных и диаграмма отношения сущностей предметной области. Отношения ER — диаграммы должны быть представлены в нормализованной форме.

        На этапе проектирования физическая модель данных определяет сущности, атрибуты, связи, ограничения целостности в терминах конкретной СУБД. На этапе реализации физическая модель — совокупность файлов определенного формата (.dbf для FoxPro). На этапе проектирования физической модели составляется описание реляционных таблиц, которые далее должны быть реализованы в среде конкретной СУБД (FoxPro for Windows, Access, Clarion ).

        Читайте также:  Современные игры про вторую мировую войну

        Ниже, в табл.1 приведен пример описания физической модели данных на основе диаграммы отношения сущностей, представленной на рис. П.1.4.

        Объясняю на примере Ответов. Есть две сущности — ВОПРОС и ОТВЕТ. Связь ВОПРОС-ОТВЕТ является идентифицирующей, поскольку сущность ОТВЕТ не может быть однозначно определена, если не задана сущность ВОПРОС (просто ответов без вопроса нет) . Или там, сущности ДОМ и КВАРТИРА. Сущность КВАРТИРА не может быть однозначно определена, если не задана сущность ДОМ.

        Неидентифицирующая связь изображается пунктирной линией. Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

        Нам понадобится понятие аномалии — несоответствия между ограничениями целостности концептуальной и логической (а также физической) схем данных. Цель нормализации — это как раз устранение аномалий, проявляющихся при включении, обновлении и удалении данных.

        Четыре первые нормальные формы (точнее первая, вторая, третья и Бойса-Кодда) объединяются в одну группу потому, что их определения основаны на классическом понятии функции, заданной на схеме отношения, и на теореме Хиса.

        Еще две нормальные формы (четвертая и пятая) используют модифицированные функциональные зависимости . Последняя нормальная форма — домен- ключ — знаменует возвращение к истокам — логическому подходу к реляционной теории.

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

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

        мы воспользуемся уже известным вам отображением реляционной модели в модель " сущность-связь " и в ER-модели будем изучать нормализацию. Это позволит привлечь семантику, необходимую для работы с аномалиями.

        Давайте еще раз вспомним о связях между отношениями, о соединении отношений и о внешних ключах.

        5.1 Связи и внешние ключи

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

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

        Связи между отношениями/сущностями и в реляционной модели и в ER-диаграммах образуются ссылочным ограничением целостности, которое называется "внешний ключ" ("Foreign Key" — сокращенно FK).

        Чтобы не создавать ложного представления о бедности реляционной модели как невозможности реализации чего-то, вспомним, что в ней связь п : т представляется через две связи 1 : n, что сложные связи можно моделировать различными способами. Даже агрегаты можно как-то представить, вводя сущности, описывающие их состав. Такие модели могут эффективно реализоваться в программе, но, скорее всего, они будут неудобными для человека. Возможности моделирования структур данных в рамках реляционной модели достаточно широки но, конечно, не безграничны.

        Читайте также:  Что качает интернет как узнать

        Обговорим общий подход к анализу структур, которые будут разбираться в дальнейшем на примере двух связанных сущностей "Сотрудник" и "Отдел", проиллюстрированном на рисунке 5.1. Слева вариант с идентифицирующей связью, справа с неидентифицирующей.

        Хочу еще раз напомнить о том, что примеры мы договорились рассматривать такими, как они описаны в тексте, а не так, как бывает или может быть в жизни. Это ограничение необходимо, чтобы информация воспринималась всеми и всегда одинаково.

        В обоих вариантах схемы каждый сотрудник причисляется к одному из отделов. Имеем связь ("ко-многим" на стороне отношения "Сотрудник"). В отношении "Сотрудник" нельзя выбрать номер отдела deptno, несуществующий в списке отделов (сущность "Отдел"). В одном отделе может быть ни одного, один, два и более сотрудников.

        Мы отметили по поводу похожего примера (раздел 2.2.7), что образуется парадоксальная ситуация. Директор причислен к какому-то отделу, а начальник этого отдела и подчинен директору и одновременно будет его же начальником. Но может быть отделы — это центры затрат, и зарплату директора решили относить на расходы одного из отделов. В наших учебных примерах не стоит заниматься такими деталями, если, конечно, не оговорено противное. Вы должны с самого начала привыкать в числе прочего думать о стороне бизнеса, но при решении учебных задач не следует расширять задания до анализа возможных вариантов.

        В чем же разница между схемами на рисунке 5.1? Идентифицирующая связь заставляет думать о сотруднике в первую очередь как о работнике отдела. Неидентифицирующая связь означает, что принадлежность к отделу отмечается как нечто второстепенное.

        5.2 Типы связи. Идентифицирующие и неидентифицирующие, обязательные и необязательные связи

        Типы связи идентифицирующая и неидентифицирующая (см. рисунок 5.1) относится не к теории реляционных баз данных, а к стандарту моделирования IDEF1X, на котором основан ERwin (он же AllFusion Data Modeller).

        Если внешний ключ создает зависимую (слабую) сущность, то он передается в группу атрибутов, образующих первичный ключ этой сущности. В этом случае образуется идентифицирующая связь. Она всегда обязательная.

        Неидентифицирующая связь используется для соединения двух сильных сущностей. Она передает ключ в область неключевых атрибутов.

        Для неидентифицирующей связи можно указать обязательность (всей связи, а не ее конца). Если связь обязательна (в ERwin это задание признака No Nulls), то атрибуты внешнего ключа получат признак NOT NULL, означающий недопустимость неопределенных значений. Для необязательной связи (признак Nulls Allowed) внешний ключ может принимать значение NULL .

        После того, как в "Язык SQL" мы познакомимся с языком SQL, используя прямой инжиниринг, можно будет генерировать скрипт SQL создающий фрагмент схемы базы. Но и сейчас, если вы уже хотя бы немного знакомы с SQL, то, пройдя путь Tools > Forward Engineer/Schema Generation, а затем нажав кнопку Preview, просмотрите сгенерированный текст.

        Зачем при рассмотрении нормализации мы собираемся использовать более сложную модель "сущность-связь", а не ограничиваемся классическим подходом в рамках реляционной модели? Ведь добавление понятий сильной и слабой сущностей, идентифицирующей связи, обязательной и необязательной неидентифицирующей связей существенно усложняет семантику модели данных.

        Введение перечисленных пяти понятий более высокого уровня дает язык, лучше отражающий особенности задачи и потому более понятный разработчику. Это позволит быстро и без формальных преобразований получить исходную схему реляционной базы почти в законченном виде (позже мы эту мысль выразим точнее: "в третьей нормальной форме или нормальной форме Бойса-Кодда").

        Комментировать
        0 просмотров
        Комментариев нет, будьте первым кто его оставит

        Это интересно
        No Image Компьютеры
        0 комментариев
        No Image Компьютеры
        0 комментариев
        No Image Компьютеры
        0 комментариев
        No Image Компьютеры
        0 комментариев
        Adblock detector