Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Brainstorm
  4. A SQL composite key with 3 members?
Forum Updated to NodeBB v4.3 + New Features

A SQL composite key with 3 members?

Scheduled Pinned Locked Moved Brainstorm
3 Posts 1 Posters 1.7k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • batman.890825B Offline
    batman.890825B Offline
    batman.890825
    wrote on last edited by
    #1

    Hello everyone, I got stuck trying to normalize my database. I'm putting my client requirements and, in bold, the tables involved so you can see the whole picture:
    Requirements:
    • One Payment Application are linked to only one Contract.
    • One Payment Application has one or more Bills.
    • One Bill’s Payment can be associated to one or more Beneficiaries. This implies a many to many relationship between Bills and Beneficiaries.
    • One Contract has one or more Beneficiaries. A Beneficiary is mostly a bank account.
    • One Contract has one or more Currencies. Since in Cuba we have two currencies, a Contract may have from 1 to 2 Currencies.
    • One Beneficiary has only one Currency.
    • One Paycheck must be made for each Beneficiary used in a Payment Application. This implies a many to many relationship between Beneficiaries and Payment Application. So the Paycheck table should have Beneficiaries.Id and ‘Payment Application’.Id as multiple key and Paycheck.Id as a unique field.
    • Paychecks can be cancelled though they remains persistent as the can be reviewed in a report. Paychecks has 3 status: Delivered, In Transition or Cancelled. This implies that the key from Paychecks table must be changed since there can be several cancelled Paychecks and only one Paycheck either In Transition or Delivered, other possibilities are considered as fraud.
    To solve this it would be necessary to add a third member to the key in the Paycheck table. But I haven’t see this and I think this violates a Codd norm. Does somebody know how to solve this or has encountered with a situation near this one?

    1 Reply Last reply
    0
    • batman.890825B Offline
      batman.890825B Offline
      batman.890825
      wrote on last edited by
      #2

      I found a solution, I'm posting it so you can criticize it:
      I will create a table named Cancelled Paychecks so I can move cancelled checks there. That way I can eliminate any conflicts while I assure that the user won't commit any fraud. This table will be like Paycheck table but it won't have the status field since in here I will only store cancelled checks.

      1 Reply Last reply
      0
      • batman.890825B Offline
        batman.890825B Offline
        batman.890825
        wrote on last edited by
        #3

        Come to think this solution has an issue, if I'm not careful I might end it having the same paycheck in both tables. Moreover, someone may use this to corrupt the logical structure making a check to appear either as cancelled and delivered. I could use a row-level trigger on each INSERT to solve this but I rather find out a more suitable solution.

        1 Reply Last reply
        0

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved