How do you deal with Recursive Relationships N:M, in Database Relational Schema









up vote
0
down vote

favorite












When we have a N:M Recursive Relationship what is the best way to create the relational schema?



In various books I searched they analyze recursive relationships of 1:1 and 1:N but for N:M there is almost nothing.



Should I treat it like a new Relationship like we do in traditional N:M non-recursive relationships?



For example in this recursive relationship is it better to:



A.Create a new relationship



INVITE(InviterId,InviteeId,AcceptanceDate,InvitationDate) - in bold the Primary Keys . In this case they are also foreign keys.



////



B. Include this relationship in the Person Entity



PERSON(Id,Password,InviterId,InviteeId,AcceptanceDate,InvitationDate).



///



enter image description here










share|improve this question























  • What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
    – philipxy
    Nov 10 at 21:00










  • You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
    – philipxy
    Nov 10 at 21:29














up vote
0
down vote

favorite












When we have a N:M Recursive Relationship what is the best way to create the relational schema?



In various books I searched they analyze recursive relationships of 1:1 and 1:N but for N:M there is almost nothing.



Should I treat it like a new Relationship like we do in traditional N:M non-recursive relationships?



For example in this recursive relationship is it better to:



A.Create a new relationship



INVITE(InviterId,InviteeId,AcceptanceDate,InvitationDate) - in bold the Primary Keys . In this case they are also foreign keys.



////



B. Include this relationship in the Person Entity



PERSON(Id,Password,InviterId,InviteeId,AcceptanceDate,InvitationDate).



///



enter image description here










share|improve this question























  • What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
    – philipxy
    Nov 10 at 21:00










  • You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
    – philipxy
    Nov 10 at 21:29












up vote
0
down vote

favorite









up vote
0
down vote

favorite











When we have a N:M Recursive Relationship what is the best way to create the relational schema?



In various books I searched they analyze recursive relationships of 1:1 and 1:N but for N:M there is almost nothing.



Should I treat it like a new Relationship like we do in traditional N:M non-recursive relationships?



For example in this recursive relationship is it better to:



A.Create a new relationship



INVITE(InviterId,InviteeId,AcceptanceDate,InvitationDate) - in bold the Primary Keys . In this case they are also foreign keys.



////



B. Include this relationship in the Person Entity



PERSON(Id,Password,InviterId,InviteeId,AcceptanceDate,InvitationDate).



///



enter image description here










share|improve this question















When we have a N:M Recursive Relationship what is the best way to create the relational schema?



In various books I searched they analyze recursive relationships of 1:1 and 1:N but for N:M there is almost nothing.



Should I treat it like a new Relationship like we do in traditional N:M non-recursive relationships?



For example in this recursive relationship is it better to:



A.Create a new relationship



INVITE(InviterId,InviteeId,AcceptanceDate,InvitationDate) - in bold the Primary Keys . In this case they are also foreign keys.



////



B. Include this relationship in the Person Entity



PERSON(Id,Password,InviterId,InviteeId,AcceptanceDate,InvitationDate).



///



enter image description here







database database-design relational-database entity-relationship






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 10 at 21:02

























asked Nov 10 at 20:40









baskon1

719




719











  • What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
    – philipxy
    Nov 10 at 21:00










  • You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
    – philipxy
    Nov 10 at 21:29
















  • What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
    – philipxy
    Nov 10 at 21:00










  • You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
    – philipxy
    Nov 10 at 21:29















What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
– philipxy
Nov 10 at 21:00




What exactly do you mean by "recursive relationship"--in terms of the state of a database or DBMS--its DDL & table values?
– philipxy
Nov 10 at 21:00












You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
– philipxy
Nov 10 at 21:29




You mean those 2 columns are the columns of a single composite CK (possibly a PK). And if two people can have more than one commitment then that CK has more columns.
– philipxy
Nov 10 at 21:29












1 Answer
1






active

oldest

votes

















up vote
0
down vote













Definitions are recursive, not relationships/associations. You seem to be talking about FK (foreign key) cycles or the special case of that where a FK references its own table. A FK constraint says values appear elsewhere as PK/UNIQUE. Alternatively, that values that satisfy one relationship satisfy another in just one way. There's nothing special about this from a relational design standpoint. Most SQL DBMSs are needlessly poor when the explicit/declared FK graph is not a tree.



Whether you could or should combine your tables depends on the information modeling & database design method you are using plus relational database design principles. There are many different "traditions". Find & follow a published academic textbook on information modeling, the relational model & database design. (Dozens are free online, also slides & courses.) PS Information & manuals on a tool to manage designs does not constitute an introduction on how to design.



The diagram you give is a Chen original true pure ER (entity relationship) diagram. Under that method you can't combine your entity & relationship into a relationship because an entity needs to have its own box & table. But you could in the relational model & in pseudo-ER methods & products that don't use diamonds in their diagrams & in methods that allow more choice in mapping from Chen diagrams.






share|improve this answer






















    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53243208%2fhow-do-you-deal-with-recursive-relationships-nm-in-database-relational-schema%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    Definitions are recursive, not relationships/associations. You seem to be talking about FK (foreign key) cycles or the special case of that where a FK references its own table. A FK constraint says values appear elsewhere as PK/UNIQUE. Alternatively, that values that satisfy one relationship satisfy another in just one way. There's nothing special about this from a relational design standpoint. Most SQL DBMSs are needlessly poor when the explicit/declared FK graph is not a tree.



    Whether you could or should combine your tables depends on the information modeling & database design method you are using plus relational database design principles. There are many different "traditions". Find & follow a published academic textbook on information modeling, the relational model & database design. (Dozens are free online, also slides & courses.) PS Information & manuals on a tool to manage designs does not constitute an introduction on how to design.



    The diagram you give is a Chen original true pure ER (entity relationship) diagram. Under that method you can't combine your entity & relationship into a relationship because an entity needs to have its own box & table. But you could in the relational model & in pseudo-ER methods & products that don't use diamonds in their diagrams & in methods that allow more choice in mapping from Chen diagrams.






    share|improve this answer


























      up vote
      0
      down vote













      Definitions are recursive, not relationships/associations. You seem to be talking about FK (foreign key) cycles or the special case of that where a FK references its own table. A FK constraint says values appear elsewhere as PK/UNIQUE. Alternatively, that values that satisfy one relationship satisfy another in just one way. There's nothing special about this from a relational design standpoint. Most SQL DBMSs are needlessly poor when the explicit/declared FK graph is not a tree.



      Whether you could or should combine your tables depends on the information modeling & database design method you are using plus relational database design principles. There are many different "traditions". Find & follow a published academic textbook on information modeling, the relational model & database design. (Dozens are free online, also slides & courses.) PS Information & manuals on a tool to manage designs does not constitute an introduction on how to design.



      The diagram you give is a Chen original true pure ER (entity relationship) diagram. Under that method you can't combine your entity & relationship into a relationship because an entity needs to have its own box & table. But you could in the relational model & in pseudo-ER methods & products that don't use diamonds in their diagrams & in methods that allow more choice in mapping from Chen diagrams.






      share|improve this answer
























        up vote
        0
        down vote










        up vote
        0
        down vote









        Definitions are recursive, not relationships/associations. You seem to be talking about FK (foreign key) cycles or the special case of that where a FK references its own table. A FK constraint says values appear elsewhere as PK/UNIQUE. Alternatively, that values that satisfy one relationship satisfy another in just one way. There's nothing special about this from a relational design standpoint. Most SQL DBMSs are needlessly poor when the explicit/declared FK graph is not a tree.



        Whether you could or should combine your tables depends on the information modeling & database design method you are using plus relational database design principles. There are many different "traditions". Find & follow a published academic textbook on information modeling, the relational model & database design. (Dozens are free online, also slides & courses.) PS Information & manuals on a tool to manage designs does not constitute an introduction on how to design.



        The diagram you give is a Chen original true pure ER (entity relationship) diagram. Under that method you can't combine your entity & relationship into a relationship because an entity needs to have its own box & table. But you could in the relational model & in pseudo-ER methods & products that don't use diamonds in their diagrams & in methods that allow more choice in mapping from Chen diagrams.






        share|improve this answer














        Definitions are recursive, not relationships/associations. You seem to be talking about FK (foreign key) cycles or the special case of that where a FK references its own table. A FK constraint says values appear elsewhere as PK/UNIQUE. Alternatively, that values that satisfy one relationship satisfy another in just one way. There's nothing special about this from a relational design standpoint. Most SQL DBMSs are needlessly poor when the explicit/declared FK graph is not a tree.



        Whether you could or should combine your tables depends on the information modeling & database design method you are using plus relational database design principles. There are many different "traditions". Find & follow a published academic textbook on information modeling, the relational model & database design. (Dozens are free online, also slides & courses.) PS Information & manuals on a tool to manage designs does not constitute an introduction on how to design.



        The diagram you give is a Chen original true pure ER (entity relationship) diagram. Under that method you can't combine your entity & relationship into a relationship because an entity needs to have its own box & table. But you could in the relational model & in pseudo-ER methods & products that don't use diamonds in their diagrams & in methods that allow more choice in mapping from Chen diagrams.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 10 at 21:23

























        answered Nov 10 at 21:01









        philipxy

        11.4k42149




        11.4k42149



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53243208%2fhow-do-you-deal-with-recursive-relationships-nm-in-database-relational-schema%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Use pre created SQLite database for Android project in kotlin

            Darth Vader #20

            Ondo