сделать стартовой | в избранное | реклама на сайте
Логин: Пароль: Войти Регистрация?/Забыли пароль?
Поиск по сайту: Поиск
IT DAY
НОВОСТИ
НАУКА
АНАЛИТИКА
ТЕХНИКА
ИГРЫ
СОФТ
ТЕХНОБЛОК

Сравнительный анализ сущностей и связей

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

С одной стороны, очевидно, что браком называется некоторая связь между двумя людьми. В качестве примера можно привести запрос "С кем вступила в брак Элизабет Тейлор в 1975 году?".

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

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

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

Но что произойдет, если атрибут станет внешним ключом позже, т.е. если база данных будет изменена уже после того, как она использовалась в течение некоторого времени? Если эту идею логически развивать, то можно прийти к выводу, что макет базы данных должен содержать связи и совсем не содержать атрибутов. (На самом деле эта позиция обладает некоторыми достоинствами..)
 
Читайте также:

  • Связи
  • Связи типа "многие к одному"
  • Свойства любой сущности
  • Связи на ER-диаграмме в виде ромба
  • Краткий анализ ER-модели


  • главноепопулярное

     Энья записала рождественский альбом

     Samsung сообщила о разработке самого тонкого ЖК-монитора

     Новый сверхлегкий ноутбук Fujitsu работает от батареи более 10 часов
    IT Day | Реклама | Форум | Контакты | Архив Подписаться на RSS
    тел.: (312) xx-xx-xx
    тел./факс: (312) xx-xx-xx
    моб.: (555) xx-xx-xx
    адрес: г.Бишкек, 720001
    ул.xxxx xx/x кв.x
    e-mail: just@love.kg
    Разработка NE, ©-2008.
    При использовании материалов с сайта гиперссылка на источник обязательна.
    Отзывы о фотографах: свадебный фотограф на свадьбу, фотосессия свадьбы 1000 руб/час. . www.butik.ru mustang купить . создание и поддержка сайтов.