Which popular er model diagramming convention for cardinality depicts “many” in a relationship?

A _____________________, also known as a data dictionary or repository, documents additional detail in text format. A glossary includes names, synonyms, and descriptions of entities, relationships, and attributes. For simple databases with few users, a database designer may record the glossary with a text editor. For more complex databases, the designer may use a database or software tool specifically designed for glossaries.
The ER diagram and glossary are complementary and, together, completely describe an entity-relationship model.

Types and instances
In entity-relationship modeling, a type is a set:
An entity type is a set of things. Ex: All employees in a company.
A relationship type is a statement about entity types. Ex: Employee-Manages-Department.
An attribute type is a set of values. Ex: All employee salaries.
Entity, relationship, and attribute types usually become tables, foreign keys, and columns, respectively.

An ___________________ is an element of a set:
An entity instance is an individual thing. Ex: The employee Sam Snead.
A relationship instance is a statement about entity instances. Ex: "Maria Rodriguez manages Sales."
An attribute instance is an individual value. Ex: The salary $35,000.
Entity, relationship, and attribute instances usually become rows, foreign key values, and column values, respectively

Discovery
Entities, relationships, and attributes are discovered in interviews with database users and managers. Users and managers are usually familiar with data requirements from an old database, or perhaps a manual process with paper records. When users are difficult to reach, a database designer may communicate with surrogates. Ex: A sales representative might communicate on behalf of prospective customers.
In addition to interviews, written documents are a good source of data requirements. Ex: The user manual for an older version of the database is a good source of requirements.
In interviews and documents, entities, relationships, and attributes surface as nouns and verbs:
Entities usually appear as nouns, but not all nouns are entities. Designers should ignore nouns that denote specific data or are not relevant to the database.
Relationships are often expressed as verbs. Designers should ignore statements that are not about entities, not relevant to the database, or redundant to other relationships. Designers should look for relationships that are not explicitly stated, since users may overlook important information.
Attributes are usually nouns that denote specific data, such as names, dates, quantities, and monetary values.

Names
Entity names are a singular noun. Ex: Employee rather than Employees. The best names are commonly used and easily understood by database users.
Relationships names have the form Entity-Verb-Entity, such as Division-Contains-Department. When the related entities are obvious, in ER diagrams or informal conversation, Verb is sufficient and entity names can be omitted. The verb should be active rather than passive. Ex: Manages rather than IsManagedBy. Occasionally, the same verb relates different entity pairs. Ex: Order-Contains-LineItem and Division-Contains-Department.
Attribute names have the form EntityQualifierType, such as EmployeeFirstName:
Entity is the name of the entity that the attribute describes. When the entity is obvious, in ER diagrams or informal conversation, QualifierType is sufficient and the entity name can be omitted.
Qualifier describes the meaning of the attribute. Ex: First, Last, and Alternate. Sometimes a qualifier is unnecessary and can be omitted. Ex: StudentNumber.
Type is chosen from a list of standard attribute types such as Name, Number, and Count. Attribute types are not identical to SQL data types. Ex: "Amount" might be an attribute type representing monetary values, implemented as the MONEY data type in SQL. "Count" might be an attribute type representing quantity, implemented as NUMBER in SQL.
Standard attribute types are documented in the glossary and applied uniformly to all attribute names.

Synonyms and descriptions
Often, entity, relationship, and attribute names have synonyms. Ex: Representative may be a synonym for SalesAgent. Synonyms are common in informal communications. To avoid confusion, one official name is selected for each entity, relationship, and attribute. Other names are documented in the glossary as synonyms.
The glossary also contains complete descriptions of entities, relationships, and attributes. The description states the meaning of each entity, relationship, or attribute in complete sentences. The description begins with the name and includes examples and counterexamples to illustrate usage.

Database design
The first step of the analysis phase is discovery of entities, relationships, and attributes in interviews and document review. As discovery proceeds, the designer draws an ER diagram, determines standard attributed types, and documents names, synonyms, and descriptions in the glossary.
Although the step numbers suggest a sequence, database designers commonly move back and forth between steps. As names, synonyms, and descriptions are documented, additional entities, relationships, and attributes are discovered. The ER diagram and glossary are usually developed in parallel.

ER model and diagram conventions
This material uses relatively simple conventions for ER models and diagrams. However, these conventions vary widely. Ex: Some ER models may:
Allow relationships between three or more entities.
Decompose a complex model into a group of related entities, called a subject area.
Refer to independent entities as strong and dependent entities as weak.
Some ER diagrams may:
Depict relationship names inside a diamond.
Depict dependency relationships with a diamond rather than an arrowhead.
Use color, dashed lines, or double lines to convey additional information.
Variations in diagram conventions for cardinality are common. One popular convention depicts cardinality as follows:
Zero — a circle across the end of a relationship
One — a bar across the end of a relationship
Many — three lines, called crow's feet, at the end of a relationship
Several model and diagram conventions are widely used, including:
Unified Modeling Language, or UML, is commonly used for software development. Software data structures are similar to database structures, so UML includes ER conventions.
IDEF1X stands for Information DEFinition version 1X. IDEF1X became popular, in part, due to early adoption by the United States Department of Defense.
Chen notation appeared in an early ER modeling paper by Peter Chen. Chen notation is not standardized but often appears in literature and tools.
By and large, differences between conventions are stylistic rather than substantial. The choice of convention does not usually affect the resulting database design.
The animation below shows one subject area from the Cloud Information Model, an industry model for sales fulfillment databases. The Cloud Information Model illustrates common diagram conventions such as crow's feet, subject areas, and diamond notation for dependency relationships.

How do you show many to many relationship in ER diagram?

What is the cardinality of a relation in an ER diagram?

What ER diagram symbol is normally used for relationships?

What are the correct Cardinalities of relationships in ER model?