Home/ Questions/Q 6784943
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T17:03:46+00:00

Got three entities – User – Has username/password, contact information, billing information etc. Periodical

  • 0

Got three entities –

  1. User – Has username/password, contact information, billing information etc.
  2. Periodical – Has periodical_name, category, publisher_info, print_cycle, unit_price etc.
  3. Subscription – Has the user-id, periodical-id, subscription start/end date, status etc.

And following relationships –

  • User can have Subscription for multiple Periodicals.
  • Subscription belongs-to a User, and has-a Periodical associated.
  • Periodical has-many Subscriptions associated with it.

s.t.,

  • User–Subscription relation is One-to-Many,
  • Periodical–Subscription relation is One-to-Many,

My questions —

  1. Is this model description correct for the real-world relationships typically found ?

  2. Or, am I better off, collapsing Periodical into Subscription, especially if per Periodical information is not extensive and can be encoded into, say a delimiter separate text field (e.g. “PeriodicalName:Frequency:Publisher:UnitPrice”) ?

  3. Can I say that via associativity User–Periodical relation is Many-to-Many ?

  4. Would appreciate if someone can show how I could put a constraint around either User or Subscription table (assuming that I don’t collapse Subscription & Periodical), s.t. when a User needs to be removed for some reason, all associated Subscriptions are deleted too.

  5. Would like to keep a User record around for sometime (say a year), even after all Subscriptions have expired, so I guess I can assign NULL to the FK subscription_id in User table, right ? This is when no corresponding record exists in Subscription table.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1. Yes.

    2. You are describing “denormalization” which may under rare circumstances be useful but it’s a violation of relational design.

    3. yes.

    4. This type of constraint (1-to-1) is not implemented declaratively in most RDBMS products. Instead we have 1-to-zero-or-one. You can do it with triggers but it’s tricky and subtle. Google for Object-Role Modeling which is a more comprehensive modeling technique that addresses stuff like this (and “either-or” and “at least 2” and many others.)

    5. That would be the standard way to handle it. You could also leave the subscription with an expiration date. But the 1-to-zero-or-one deficiency nicely facilitates your suggestion.

    • 0