0

All. Forgive me I am not strong in the DB Design.

Is it Cycle Reference for this diagram?

enter image description here

Joe.wang
  • 11,537
  • 25
  • 103
  • 180

1 Answers1

0

Because of the table names you chose, I'm not sure what the context of this is.

To strictly answer your question, which I think should be "Is this diagram normalised?", my answer is: no, it's not normalised.

You don't need and you should remove the relationship between "Registers" and "Reciepes". You can get to the "Registers" table from the "Reciepes" one, through "Bill".

A few naming recommendations:

  • Table names should be singular.

  • As a personal preference, I prefer having the PK of the table named as "TableNameID" (e.g. BillID).

  • I think "Reciepes" actually is "Receipt", but it's just my guess.

Let me know if you have any doubts or if you need an example with a query.

UPDATE:

If you need more information regarding normalisation, please take a look at the following: What is Normalisation (or Normalization)?. There you'll find a very nice explanation of what normalisation is and why you need to consider it.

And that's why you should remove the relationship between "Registers" and "Reciepes": to avoid redundant data and data corruption problems.

Community
  • 1
  • 1
Charmander
  • 276
  • 3
  • 20
  • Why I should remove the relationship between "Registers" and "Reciepes"? What is the rule behind it? Please tell me some more about it. Thanks – Joe.wang Sep 22 '15 at 14:00
  • Sorry . A little typo in the diagram. The Bill should be Bills. – Joe.wang Sep 22 '15 at 14:01
  • I don't think that it *necessarily* follows that the relationship between reciepes and registers need not be there -- bill--reciepes could be an optional value, and if the is no relationship then reciepes might still need to be related to registers. It could also be valid that the direct relationship from reciepes to registers is different to that via bills. – David Aldridge Sep 22 '15 at 15:19
  • @DavidAldridge, sorry, but I'm not sure I understand what you meant. Would you mind rephrasing your comment so it's clearer? Thanks. – Charmander Sep 22 '15 at 15:32
  • Suppose Register, Bills, Receipes are actually Location, Department, and Person. A Location has many departments, and many People. Departments have many People. But maybe a person has a Location, but not a Department. Or they have a Department, but are in a different location to their Department. So the relationships can be optional, or they could lead to a Person effectively having two associated Locations (directly, and through Department). Does that make sense? – David Aldridge Sep 22 '15 at 15:40
  • @DavidAldridge, I agree with you, but let's say we take the example of your last phrase: "they could lead to a Person effectively having two associated Locations (directly, and through Department)". If this was the case, the schema is still not normalised (that doesn't mean there's always a better solution), because you will have data redundancy. As I stated in the begining of my answer, we don't have information of the context, and that's why I assumed the simplest scenario. Joe, if you need a more detailed answer, please, provide more information so we can help you make a better decision. – Charmander Sep 22 '15 at 15:53