ER diagrams and cardinality
According to Wikipedia: "In software engineering, an Entity Relationship model is commonly formed to represent things that a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model that defines a data or information structure that can be implemented in a database, typically a relational database...
An entity–relationship model is usually the result of systematic analysis to define and describe what is important to processes in an area of a business. It does not define the business processes; it only presents a business data schema in graphical form. It is usually drawn in a graphical form as boxes (entities) that are connected by lines (relationships) which express the associations and dependencies between entities...
Entities may be characterized not only by relationships, but also by additional properties (attributes), which include identifiers called "primary keys"...
There is a tradition for ER/data models to be built at two or three levels of abstraction: conceptual, logical, and physical data model."
Hackolade loosely applies ER principles to the physical data modeling of JSON data stores, which are non-relational in nature. As seen in Relationships and denormalization, relationships are implicit, but there remains a need to document their existence, and to display them visually.
With v4.3.2, Hackolade has introduced the possibility to add separate ER Diagram Views: a subset of entities selected from the main ER diagram, to help manage large models by focusing on a smaller set of entities, by domain or subject. Entities may appear in multiple Diagram Views. Modifications made inside Diagram Views are immediately reflected in the main diagram and other views where present.
Hackolade also loosely applies Information Engineering notation to relationship lines.
|zero or one|
|zero or more|
|one or more|
This page helps understand how to manipulate entities in ER diagrams.