Class_model.md

Class model

The concept class model refers to the set of classes of an object-oriented programming language. This page will cover how ERDiagram converts the input entity-relationship model into a class model.

Table of contents

• Entities
  • Property modifiers
    • Optional modifier
    • Unique modifier
  • Property's length
  • Entity identifier property
• Relationships
  • Cardinalities
  • Directions
  • Aliases
  • Relationship's name

Entities

Each entity defined in the input entity-relationship model will be converted into a class in the class model. In the same way, every entity property will be modeled as a field of that class.

Property modifiers

Optional modifier

ERDiagram considers all properties as mandatory by default. However, properties defined using the optional modifier will be modeled as nullable fields.

Unique modifier

The unique modifier is intended for database code generation, and it's not used in class model generation.

This means that defining unique class fields is currently an unsupported feature. This may change in the future, so you can create an issue to discuss this if you need it 🙂

Property's length

As some OOP languages allow to define the max size of its fields (i.e. Java via validation constraints), the length of the entity properties is used for this purpose.

Currently, only text and blob property types are taking into account. For example, a property name text(50) will be modelled as a property with maxSize: 50.

Entity identifier property

The identifier property of the entity will be modeled just like any other field. Contrary to the database model, the identifier field of the class model must be nullable, so a null value can be used to represent an unsaved instance of an entity.

Relationships

Relationships are modeled by adding new fields to the entity classes. In the following sections, we will explain in deep how the cardinalities, direction, and aliases of the relationship affect the final class model.

Cardinalities

ERDiagram supports different types of relationships regarding the cardinality of its members. We recommend reading Cardinalities before continue for a better understanding.

Each member of a relationship can have 2 different cardinalities:

• one (1): members with this cardinality are modeled by using a field whose type is the entity of that member.
• many (*): members with this cardinality are modeled by using a list or array.

Also, there is a special zero-or-one cardinality (represented in ERDiagram using a question mark ?), which is modeled in the same way as the one (1) cardinality, with the only difference that its corresponding field will be nullable.

Directions

ERDiagram supports 3 different directions for a relationship (see Directions for more detail):

• left-to-right (->)
• right-to-left (<-)
• bidirectional (<->)

The direction of the relationship is used to indicate how the data can be accessed from one side of the relationship to the other one. Let's see some examples in order to learn how the direction affects the class model:

User ->* Address

As you can see, the relationship defined in the example above is defined as left-to-right. This makes the User entity have a list of addresses, but it doesn't make the Address entity have a reference to the user.

If we want to have a reference from the Address entity to its user, we can define the relationship as bidirectional:

User <->* Address

Finally, if we don't want the User entity to have a reference to its addresses, we can define the relationship as right-to-left:

User <-* Address

Aliases

Defining aliases for the members of a relationship is useful not only for semantic purposes but also for customizing the name of its corresponding fields.

For example, imagine you want to model a Travel entity that has 2 relationships to the same City entity, one for the origin city and the other for the destination city. If you define those relationships without specifying an alias for the City member, you will end up with two identical City city fields in your Travel class.

The way to handle this situation is by adding an alias to the City member of both relationships:

Travel *-> City originCity
Travel *-> City destinationCity

By doing this, ERDiagram will name the fields City originCity and City destinationCity.

You can also use aliases in self-referencing classes:

Employee subordinates *<-> Employee boss

This will be modeled by creating the Employee boss and Employee[] subordinates fields in the Employee class. If you don't use aliases, the fields would be Employee employee and Employee[] employees respectively, which are much less semantic.

Relationship's name

The name of the relationship is intended for database code generation, and it's not used in class model generation.

This means that defining a relationship's name has doesn't produce any effect on the class model.