Let\'s assume a database with three tables: Author, Articles, Comments
Assuming the relationship is as follows:
Tables represent business/application relation(ship)s/associations. As in the relational model & entity-relationship modeling. Every query result holds the rows of values that are related by some business relationship expressed by the query expression.
Your "relationships" [sic] are FKs (foreign keys). Those are constraints--statements true in every business situation & its database state--saying that if some values are related by a certain business relationship then they are also related by a certain other one. But FKs are neither necessary nor sufficient for using the database--for interpreting it or updating it. They constrain the database state, but they don't tell you what's in it.
Your business relationships & corresponding tables are actually like:
Author authored Article
Commenter commented Comment re Article
Such a statement template denoting a business relationship is its (characteristic) predicate. To query using these it does not matter what the constraints are--if you want the authors who commented on articles authored by themselves that's
/* rows where
FOR SOME a.* & cr.*,
Author = a.Author
AND a.Author authored a.Article
AND cr.Commenter commented cr.Comment re cr.Article
AND a.Author = cr.Commenter
*/
select Author
from authored a join commented_re cr on a.Author = cr.Commenter
regardless of whether an author can author multiple articles, or multiple authors can author an article, or multiple authors can author multiple articles, or commenters can comment re multiple comments, etc, or commenters can comment re multiple articles, etc, or a comment can be re multiple articles, etc, or authors can comment, or commenters can author, or commenters can only comment on articles they authored (a FK constraint) or authors named 'henk' can comment re at most 7 articles, or any constraint whatsoever.
Normalization replaces a table by selects of it that join back to it, which is the same as saying it replaces a business relationship that is expressible via an AND by others that are expressible by the expressions that were ANDed. It happens that if an author can only write one article and an article can only be written by one author then the AND/join table above might (depending on other things) be a good design but otherwise it would not be a good design, and should be replaced by the separate tables. FDs & other constraints are the post-design table-based expression of corresponding business rules that follow from the chosen business relationships & what business situations can arise.
So your "scientific approach" is proper relational information modeling and database design, including normalization.