Database design four or five paradigm

Before defining the fourth normalization form, I'd like to start by mentioning three basic data relationships: one-to-one, One-to-many and Many-to-many. Let's look back through the first normalized users table. If we put the URL field in a separate table, and each time we insert a record in the Users table, we insert a row in the URLs table. We'll get a one-to-one relationship: each row in the user table will find the corresponding row in the URLs table. For our applications, this is neither practical nor standard.
Then take a look at the second normalization example. For each user record, our table allows a record of multiple URLs to be associated with it. This is a one-to-many relationship, which is a very common relationship.
It's a little more complicated for a many-to-many relationship. In our third form of normalization, one of our users is related to a lot of URLs, and we want to change the structure to allow multiple users to relate to multiple URLs so that we can get a many-to-many structure. Before we go into this discussion, let's see what happens to the table structure.
Users
UserId name Relcompid
1 Joe 1
2 Jill 2
Companies
Compid company Company_address
1 ABC 1 Work Lane
2 XYZ 1 Job Street
URLs
Urlid URL
1 abc.com
2 xyz.com
Url_relations
Relationid Relatedurlid Relateduserid
1 1 1
2 1 2
3 2 1
4 2 2
To further reduce the redundancy of the data, we apply the fourth level normalization form. We created a rather strange url_relations table with fields that are either the primary key or the foreign key. With this table, we can eliminate duplicate items from the list of URLs. The following are specific requirements for the fourth formalized form:
Fourth normalization form
1. In a many-to-many relationship, independent entities cannot be stored in the same table
Since it applies only to many-to-many relationships, most developers can ignore this rule. In some cases, however, it is very useful, and this is the case where we have improved the URLs table by separating the same entities and moving the relationships into their own tables.
To make it easier for you to understand, for example, here's a SQL statement that will select all of the URLs that belong to Joe:
SELECT name, URL
From users, URLs, url_relations
Where Url_relations.relateduserid = 1 and Users.userid = 1 and urls.urlid = Url_relations.relatedurlid
If we want to traverse everyone's personal and URL information, we can do this:
SELECT name, URL
From users, URLs, url_relations
Where Users.userid = Url_relations.relateduserid and urls.urlid = Url_relations.relatedurlid