Как смоделировать этот и эквивалентный SQL - Пользователь, Подписка, Журнал - PullRequest
Новая
       1

Как смоделировать этот и эквивалентный SQL - Пользователь, Подписка, Журнал

1 голос
/ 05 ноября 2011

Получил три сущности -

  1. Пользователь - имеет имя пользователя / пароль, контактную информацию, информацию для выставления счетов и т. Д.
  2. Периодический - Имеет имя_периода, категорию, publisher_info, print_cycle, unit_price и т. д.
  3. Подписка - имеет идентификатор пользователя, идентификатор периодического издания, дату начала / окончания подписки, статус и т. д.

и следующие отношения -

  • Пользователь может иметь подписку на несколько периодических изданий.
  • Подписка принадлежит пользователю и связана с периодическим изданием.
  • Периодическое имеет много подписок

st,

  • Пользователь - отношение подписки - один-ко-многим,
  • Периодическое - отношение подписки - одно-to-Many,

Мои вопросы -

  1. Является ли описание этой модели правильным для реальных отношений, обычно встречающихся?

  2. Или, мне лучше, свернуть Периодические подписки, особенноесли для Периодической информации не много и ее можно закодировать, скажем, в отдельное текстовое поле разделителя (например, «PeriodicalName: Frequency: Publisher: UnitPrice»)?

  3. Могу ли я сказать это через ассоциативность Пользователь - периодическое отношение «многие ко многим»?

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

  5. Хотелось бы хранить пользовательскую запись некоторое время (скажем, год), даже после истечения срока действия всех подписок, поэтому я предполагаю, что я могу назначить NULL для FK subscription_id в таблице пользователей,право ?Это когда соответствующая запись не существует в таблице подписки.

Ответы [ 2 ]

2 голосов
/ 05 ноября 2011

  1. Да.

  2. Вы описываете «денормализацию», которая в редких случаях может быть полезной, но это нарушение реляционного дизайна.

  3. да.

  4. Этот тип ограничения (1-к-1) не реализован декларативно в большинстве продуктов РСУБД. Вместо этого мы имеем 1 к нулю или один. Вы можете сделать это с помощью триггеров, но это сложно и тонко. Google для Object-Role Modeling, которая является более всеобъемлющей техникой моделирования, которая обращается к таким вещам (и "или-или" и "по крайней мере 2" и многие другие.)

  5. Это был бы стандартный способ справиться с этим. Вы также можете оставить подписку с датой истечения срока действия. Но дефицит 1 к нулю или 1 хорошо облегчает ваше предложение.

1 голос
/ 05 ноября 2011

  1. Ваша модель верна. Я бы реализовал это как 3 таблицы Пользователь, Период, Подписка.

  2. Вы не должны свернуть журнал в подписку. Если периодическое издание или некоторая часть периодического издания одинаковы для всех пользователей, оно заносится в эту таблицу. Все, что изменяется по подписке, попадает в таблицу подписок.

  3. Да.

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

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

...