Базы данных

Определение схемы и образец таблицы для класса Customer с атрибутом otherUser, остальные значения атрибутов дублируются


Нетрудно заметить, что поиск и модификация таблицы Customer весьма осложняются при использовании этой схемы, нарушающей два основных принципа информационных систем. Первый принцип гласит, что все модели данных должны как можно полнее соответствовать представляемым ими реальным ситуациям. В этой схеме три сущности отображают одного и того же клиента. Второй принцип утверждает, что следует минимизировать дублирование значений. Здесь же практически вся информация дублируется. Если Carrol Breaux переезжает по новому адресу, каждая запись о ней также должна быть изменена. По этим причинам выбранную схему нельзя считать удовлетворительной.

Замечание об использовании фиксированного количества значений для многозначных атрибутов

Еще одна стратегия, которую можно использовать для представления многозначных атрибутов, состоит в том, чтобы добавить нужное количество атрибутов для представления нескольких значений. Например, можно добавить следующие атрибуты: otherUserl, otherUser2 и otherUser3. Очевидно, что такой подход ограничивает максимальное количество других пользователей и усложняет операции поиска. Чтобы определить, имеет ли право кто-либо пользоваться счетом, придется просмотреть все три атрибута. В некоторых случаях подобная стратегия работает, однако в большинстве случаев она совершенно неприемлема.

Если многозначные атрибуты нельзя представить атрибутами в рамках содержащей их схемы, их следует поместить в отдельную схему. Рассмотрим подобную модификацию как изменение концептуальной схемы, а затем как изменение реляционной модели. В ER-модели создается класс сущностей OtherUser и связывается с классом Customer, как показано на 4.4. Класс OtherUser имеет единственный атрибут otherUser. Показатель кардинальности между классами Customer и OtherUser — “один ко многим”. Один клиент может иметь нескольких других пользователей своего счета, но каждый такой пользователь счета должен иметь только одного связанного клиента. OtherUser является слабой сущностью по той причине, что не имеет собственного ключа. Так многозначный атрибут стал многозначной связью.

Комментарии закрыты