Associative entities can have many different names such as composite entity, bridge entity, or linking tables. They all refer to the same concept of being a solution for a many-to-many (M:N) relationship between two (or more in some cases) entities in creating multiple one-to-many (1:M) relationships. Since this entity is used to link all of the tables that were originally related in an M:N relationship, this associative entity will at the very least contain the primary keys from those entities as foreign keys.
When such an entity is created, the database designer will either set the primary key as the combination of the foreign keys or create a whole new primary key. In part, it will depend if the table will be referenced from other tables. If it is, creating a new primary key will make more sense. Otherwise, the table that refers to the associative entity would need to link all of the foreign keys which can be redundant. An associative entity models pure relationships rather than entities.
At a conceptual level, as we currently are with our movie rating database model, it is valid to have the many-to-many relationships and they are frequently used in the ER modeling process. During the implementation into a logical model, it will require us to create our associative entity. Note that we may also add associative relationship attributes in this table that would be an attribute that only exists because of the many-to-many relationship.
For example, if we took our movie rating database and looked at the movie and actor relationship, it is currently a many-to-many relationship. We could create an associative entity that would have the MovieID and ActorID (both of which do not currently exist in the conceptual model) as foreign keys. We could call this associative entity “Role” to indicate the role that the actor plays in the movie. As part of the Role entity, we could add in the RoleName as an attribute that only exists due to the many-to-many relationship as the RoleName is based on the actor and the movie. In our case, we could simply use the composite key of the MovieID and ActorID for the primary key rather than create a new primary key since no other entity is dependent on the Role entity.