ERD Getting Started Guide

Enterprise Studio ERD Getting Started Guide 2017-09-21 Applies to: Enterprise Studio 3.0.0, Team Server 3.0.0

Table of contents 1 About modeling with ERD 4 1.1 What are entity-relationship diagrams? 4 1.2 ERD in Enterprise Studio 4 2 ERD modeling levels 7 2.1 Conceptual level 7 2.2 Logical level 8 2.3 NIAM-inspired modeling 9 3 Creating entity-relationship models 11 3.1 Creating a new entity-relationship model 11 3.1.1 Adding a new view 12 3.2 Adding content to an ERD view 12 3.2.1 Concepts for modeling 13 3.2.2 Separate submodels within the model 14 3.2.3 Available controls 15 3.3 Naming entities and relations in an entity-relationship model 15 3.4 Entities in an entity-relationship model 16 3.4.1 Naming an entity 16 3.4.2 Defining an entity 17 3.4.3 Subtyping entities 17 3.4.4 Weak entities 18 3.5 Relations in an entity-relationship model 18 3.5.1 Naming a relation 18 3.5.2 Setting the multiplicity and participation of a relation 21 3.5.3 Expressing the nature of a relation in a sentence 22 3.5.4 Defining roles for a relation 24 3.5.5 Subtyping entities with the specialization relation 24 3.6 Attributes and keys in an entity-relationship model 25 3.6.1 Adding attributes to an entity 26 3.6.2 Moving and sorting attributes 27 3.6.3 Removing attributes 28 3.6.4 Using keys 29 3.6.5 Setting the foreign key for an attribute 31 2

3.6.6 Setting the optionality of an attribute 33 3.7 Facts in an entity-relationship model 34 3.7.1 Modeling facts 34 3.7.2 Naming the predicates of a fact 36 3.7.3 Changing the orientation of a fact 36 3.8 Constraints in an entity-relationship model 36 3.8.1 Uniquely identifying an entity with uniqueness constraints 37 3.8.2 Setting a sequence number for uniqueness constraints 37 3.8.3 Displaying the name of a constraint relation 38 4 Relations between ERD and other modeling domains 40 4.1 Integration with BPMN models 40 4.2 Integration with DMN models 40 Appendix A - Concepts for ERD modeling 41 Appendix B - Controls for the ERD objects 46 Index 48 PDF guides 51 3

1 About modeling with ERD 1.1 What are entity-relationship diagrams? Entity-relationship diagrams (ERD), or entity-relationship models, are used for describing and defining data models. The data is modeled as components (entities) that are connected to each other by relations that express the dependencies and requirements between them. Figure 1.1 Example of an entity-relationship model An entity-relationship model consists of one or more views with data models. Data models can be modeled on different levels, in different types of views. 1.2 ERD in Enterprise Studio Required tool license The ERD functionality is available to you if your Enterprise Studio license includes one of the following tool packages: Pro EA, Advanced, or 4

Enterprise 1. Notation Different notations can be used for ERD. Enterprise Studio supports the Crow's foot notation. In the Crow's foot notation entities are represented as boxes and relations as lines between the boxes. Different shapes at the ends of these lines represent the cardinality of the relation. Based on the Crow's foot notation there is also the possibility for NIAMinspired modeling (Natural language Information Analysis Method). Modeling levels Generally, entity-relationship modeling can be done on different abstraction levels: on conceptual (descriptive) level, logical (analytical) level, and physical (executive) level. Enterprise Studio supports creating models on the conceptual and logical level. Used terminology Within the ERD terminology we know the terms entity type, entity, relation type and relation. An entity type is regarded as the object on which information is recorded, an entity is regarded to be an instance of this object. For example the entity type Person and the entities John, Jim and Jack. The same applies to relation types and relations. In practice, the terms are often used interchangeably; the entity types and relation types are in fact always modeled, but for convenience they are referred to as entities and relations. That is why this documentation only discusses entities and relations. Model templates Enterprise Studio has model templates containing the basics for ERD modeling. You can use these templates to start a model. 1 Enterprise Studio tool packages "Pro EA" and "Pro BPM" only apply to software purchases before release 3.0.0 (September 2017). Later purchases only have the "Advanced" or "Enterprise" package. 5

Contents of the documentation The ERD documentation focuses on the basics of modeling with ERD in Enterprise Studio. For extended information about entity-relationship modeling and diagrams, please refer to third party documentation. 6

2 ERD modeling levels Models can be created at different levels of abstraction, entity-relationship models too. The following modeling levels can be distinguished: conceptual (descriptive) level logical (analytical) level physical (executive) level A conceptual model captures the business scope of the problem, the logical model the business solution, and the physical model the technical solution. Enterprise Studio supports creating ER models on the conceptual and logical level. 2.1 Conceptual level A model on the conceptual level captures the business scope of the problem. It displays the most important entities in business terms, as well as their interrelationships. In a conceptual view, a definition of the entities can be included, and relations can have a cardinality. The cardinality of a relation describes the entity's involvement in the relation. The cardinality is expressed via a combination of participation (optionality) and multiplicity, and is expressed in terms of one-on-one, one-to-many, many-to-one or many-to-many. Relations are defined by giving them a short description, with an arrow on the line indicating the direction of the relation. At both ends of the relation line, the two roles of the relation can be displayed. 7

Figure 2.1 Example of a conceptual model In the example model above two entities are shown: Person and Organization. Between them is the relation works for going from Person to Organization. For the organization the role name employer is included. The following can be read by the cardinality: "Person works for zero or more Organizations" and "Organization employs one or more Persons". 2.2 Logical level A model on a logical level is a further elaboration of the conceptual model. In addition to the information recorded in a conceptual model, other information is recorded. The entities can be further elaborated by adding attributes. For attributes the optionality is indicated; are they mandatory or optional. It is also indicated whether they are part of the primary key of the entity, or that they are a foreign key. 8

Figure 2.2 Example of a logical model In the example model above, an extra entity Employment had been included with respect to the conceptual example model. With this entity, the relation between Person and Organization is further elaborated. Not only the cardinality is more detailed, the properties (attributes) can also recorded in detail by indicating the optionality and key for each attribute. 2.3 NIAM-inspired modeling As an addition to modeling on a logical level, a NIAM-like (Natural language Information Analysis Method) view is available for entity-relationship modeling. It is a variation of the Crow's Foot notation inspired by NIAM (Conceptual Schema and Relational Database Design by Sjir Nijssen & Terry Halpin (1989)). The notion of fact (type) is used to model relationships. A fact consists of two predicates, each defining the role of one of the entities involved in the relationship. 9

Figure 2.3 Example of a NIAM-inspired logical model In the above example model the top most fact defines the role "buys" for the customer in relation to product, and the role "is sold to" for the product in relation to customer. This gives the following predicates "A customer buys 0, one or more product" (displayed below) and "A product is sold to 0, one or more customer". Additionally, different types of constraints (uniqueness, exclusion, completeness) can be modeled to indicate limitations in the model. 10

3 Creating entity-relationship models When modeling it is usually best to start with a conceptual model. That way you can identify the entities at the highest level and can see how they relate to each other. From there, create a logical model. Follow the next steps to create an easy-to-read model: Avoid redundancy. Ensure that each entity only appears once per diagram. Provide simple and accurate names for every entity, relation, and attribute in the diagram. Do not use an entity if you can use an attribute instead. Look closely at the relationships between entities. Make sure that each connection is necessary and unique. Avoid using weak entities. 3.1 Creating a new entity-relationship model Creating an entity-relationship model, or ER model, starts with creating a new model. By choosing a specific model, you can already take into account what you want to register. You can add additional views to the model later if desired. Determine what you want to do and perform the relevant procedure: Create a conceptual data model On the File tab, click New > ERD > 1. Empty model with conceptual view. The model browser shows a new model package with an ER model a new empty conceptual view is opened in which you can start modeling., and 11

Create a logical data model On the File tab, click New > ERD > 2. Empty model with logical view. The model browser shows a new model package with an ER model, and a new empty logical view is opened in which you can start modeling. Create a NIAM-like data model On the File tab, click New > ERD > 4. Empty model with NIAM view. The model browser shows a new model package with an ER model, and a new empty NIAM view is opened in which you can start modeling. Start with an empty data model On the File tab, click New > ERD > 3. Empty model. The model browser now shows a new model package with an empty ER model. After that you can add the desired diagrams to the model package. 3.1.1 Adding a new view 1. In the model browser, right click the ER model, point to New and click the view of your choice: Crows Foot conceptual view, Crows Foot logical view, or NIAM view. The new view appears in the model browser, right below the model. 2. Click the newly added view in the model browser to open it. 3.2 Adding content to an ERD view Objects and relations that can be drawn in an ERD view are based on the concepts available to the open view. Objects and relations can be added in different ways, by using: 12

the Create pane the quick-create pop-up window the model browser the quick-create object controls the smart connector the context menu For detailed information about the possible ways to add objects and relations, please refer to "Creating objects and relations" in the Enterprise Studio User Guide (PDF). 3.2.1 Concepts for modeling Several concepts are available for entity-relationship modeling. Their availability depends on the view your are modeling in; the amount of detail that can be put into a model depends on the level at which you are modeling. Globally, the following concepts can be used: Entities for describing the components/objects in the data model. Entities represent persons, places, items, events, or concepts. Attributes for describing the properties of an entity. Attributes know an optionality and a key. Keys for identifying the uniqueness of attributes. Facts for displaying the relations between entities in a NIAM view. Different types of relations for displaying the connections between elements the different views. Relations may know a cardinality (multiplicity), an optionality (participation) and roles. By means of specialization relations entities can be subtyped. Constraints for describing limitations that can be assigned to roles in a NIAM view. Appendix A contains a detailed overview of the available concepts, with examples and grouped by category. 13

In addition to the concepts that are specific for the modeling language or method, there are several graphic shapes that can be included in a diagram or view. These graphic shapes are generic and available in each modeling language and method in Enterprise Studio. The graphic shapes are discussed in the Enterprise Studio User Guide (PDF). 3.2.2 Separate submodels within the model Within an entity-relationship model, Crows Foot views and NIAM views can be modeled next to each other, but they are considered separate submodels. It means that elements modeled in a Crows Foot view cannot be used in a NIAM view, and reverse. The entities in both types of views also have different colors. In the model browser, the elements of both submodels are located in separate containers called "Crows Foot model" and "NIAM model", as is shown in the following figure. It is possible to use elements in multiple views of the same type, so in different Crows Foot views, or in different NIAM views. 14

3.2.3 Available controls The entities and attributes in an ER logical view and NIAM view have controls that can be used to characterize and mark them, or provide them with specific information. The conceptual view does not have any ERD-specific controls. Some of the controls appear when you click an entity or attribute, and some are always visible. Example: Figure 3.1 Example of object controls on an entity Click the control to perform the operation. Appendix B shows an overview of the available controls. 3.3 Naming entities and relations in an entityrelationship model In order to create clear entity-relationship models, it is important that you also have a clear naming of entities, relations, attributes and roles used in the model. That is why there are some guidelines for defining these objects and relations. Element Entity Relation Naming Use a general, singular noun. Example: Person, Organization, Customer, Invoice. Use a verb that connects two nouns (the entities). The two entities between which the relation is placed, form, depending on the direction of the relationship, the subject and object. 15

Element Role Attribute Naming Example: Person works for Organization, Invoice is sent to Customer. The corresponding relation in the opposite direction will get an opposite formulation. The reversed relation between the two examples may be: Organization employs Person, Customer receives Invoice. Use a noun for the roles of a relation. Example: In a relation between Person and Organization, the relation on Person's side can have the employee role, and on Organization's side the role of employer. Use a noun to name an attribute. Example: Attributes of Person may be Social security number, Name, Birth date, Marital status. Attributes of Organization may be Tax number, Name, Industry. 3.4 Entities in an entity-relationship model Entities can be modeled in all types of views available within an ER model. However, entities created for a Crows Foot view cannot be used in NIAM views, and reverse. The entities also have different colors: in Crows Foot views and in NIAM views. Figure 3.2 Entity in a Crows Foot view (left) and NIAM view (right) 3.4.1 Naming an entity When adding an entity to a conceptual or logical view, it is named "Entity" by default. You can immediately name an entity by typing its name (over the blue highlighted name) directly after inserting it. 16

3.4.2 Defining an entity In the Crows Foot conceptual model it is not possible to set properties for an entity. Instead an entity can be further explained by using a definition. To set a definition, click in the white area of the entity and type the desired text. Figure 3.3 Adding an entity definition 3.4.3 Subtyping entities When modeling, you can subtype entities. You can create specializations or generalizations, depending on whether you are modeling bottom-up or topdown. When attributes are added to an entity that only apply to a part of the population, it may be useful to make specializations. In that case you link sub-entities to the main entity using specialization relations (see Relations). The attributes that apply to all sub-entities, can be defined in the main entity. The attributes that are specific to the sub-entities, can be defined in these entities. The sub-entities inherit all attributes of the main entity. Figure 3.4 Example of subtyping an entity 17

3.4.4 Weak entities A weak entity is an entity whose existence is dependent on another entity. A weak entity does not have its own set of attributes that uniquely identify him. The entity needs a foreign key for it, which together with its own attributes, forms the entity's primary key. The foreign key usually is the primary key of another entity the weak entity is related to. 3.5 Relations in an entity-relationship model Relations in an entity-relationship model show different types of connections between various elements: Relation for connecting entities in a Crows Foot view. Specialization for subtyping entities in a Crows Foot or NIAM view. Link for connecting attributes and keys in a Crows Foot view, entities and facts or constraints in a NIAM view, or attributes and constraints in a NIAM view. Fact for connecting entities in a NIAM view. Relations between entities usually go both ways. Relations also know a cardinality and an optionality. A fact is a special type of element. It can be modeled as relation, but also as object, with the same result. See Facts in an entity-relationship model. 3.5.1 Naming a relation By default, a relation does not have a name when drawing it between two entities. It only has a default cardinality and optionality. 18

To define both sides of the relation, you define two names in the relation, one for each direction. To name the relations, do as follows: 1. Click on the line and directly type the name of the relation. Which relation you define first, depends on the direction in which the relation was drawn. After typing the name, the direction is shown by an arrow or on the line. 2. To define the relation in the opposite direction, click the arrow that will now point the other way. 3. Click on the line, press F2, and type the name of the relation in the other direction. You have now named both sides of the relation. By repeatedly clicking on the arrow you will see the relation alternating in both directions. You can only see one relation at a time. 19

Show both relation names at the same time If you want to see the names of both directions of the relation, hold down Shift and click on the arrow in the line. The name of the currently visible direction (as indicated by the arrow) is shown above the line. The name of the reverse relation is shown below the line between brackets. If you want this name to be on top, click the arrow. The names are now reversed. To return to displaying only one relation, hold down Shift and click the arrow. If you want the relation names to be shown only above or below the line, then click the name label and drag it to the desired location. Removing the name of a relation To remove the name of a relation, ensure that the correct relation is visible. If not, first click on the arrow in the line to make it visible. Click the name of the relation, press F2, and subsequently press Delete. The name is now gone. 20

Figure 3.5 Removing the name of a relation If you want to remove the names of both directions, click the arrow once again after removing the first name in order to make the other name visible. Next, perform the same actions as done with the first name. 3.5.2 Setting the multiplicity and participation of a relation The combination of cardinality and optionality defines the relation between two entities. The cardinality is the number of times a relation can or may occur. This is determined by setting the multiplicity of a relation. The multiplicity can have a value of one or many. There are four types of multiplicity: one-to-one one-to-many many-to-one many-to-many The optionality represents the participation of the relation; it is mandatory or optional. The participation can have a value of zero (optional) or one (mandatory). mandatory-optional 21

optional-mandatory optional-optional mandatory-mandatory When adding a new relation, the multiplicity and participation are initially set to 1 and 0 on the from-side and both to 1 on the to-side of the relation. The following table shows the possible combinations of multiplicity and participation on one end of a relation. Multiplicity Participation 0 1 1 Many The multiplicity and participation are set at both ends of a relation. The multiplicity is set at the end of the relation, closest to the entity. The participation just before that. To set the multiplicity and participation, click on the right place in the line. By repeatedly clicking you can change the setting. 3.5.3 Expressing the nature of a relation in a sentence After you have defined a relation between two entities and have set the cardinality, the nature of the relation can be formulated in a sentence and be 22

displayed in the view. The name of the relation and the cardinality, which together form the nature of the relation, are expressed in a sentence. How to show the nature of the relation in a sentence is little different for the Crows Foot logical view and the NIAM view. Crows Foot logical view Regular display of relation and cardinality: Relation and cardinality expressed in a sentence: To display the relation and cardinality in a sentence, hold down Alt and click on the arrow in the relation. The description appears. To view the description for the other side of the relation, click the arrow on the line. To turn back to the regular display, hold down Alt and click the arrow. NIAM view Regular display of relation and cardinality: 23

Relation and cardinality expressed in a sentence: To display the relation and cardinality in a sentence, click just outside the border of the fact, and then click the control next to the fact. The description appears. To view the description for the other side of the relation, click the control once again. To turn back to the regular display, click the control a third time. 3.5.4 Defining roles for a relation A relation always has two roles. These roles are defined at both ends of the relation. When clicking the line, the label "undefined" appears. Here you can lay down the role names. Double-click a label and type the name of the role. 3.5.5 Subtyping entities with the specialization relation In addition to the regular relation that can be drawn between entities, the Crow's Foot notation knows the specialization relation. This type of relation can be used to subtype the entities. Depending on the direction you 24

are modeling, we speak about specialization (top-down), or generalization (bottom-up). When subtyping, there is inheritance of attributes. This is particularly reflected in a logical view where attributes are used. The sub-entities inherit the attributes of the main entity they belong to. Conversely, this does not apply. Attributes of a sub-entity do not need to apply to the main entity. Figure 3.6 Specialization relation 3.6 Attributes and keys in an entity-relationship model Attributes Attributes can be used in the Crows Foot logical view and in the NIAM view. With attributes you can define the properties of an entity. Basically each entity must have a minimal set of uniquely identifying attributes, unless it is a weak entity. Together, these attributes form the primary key of the entity. For each attribute you can specify whether it is part of the primary key, and set the optionality. Keys Keys can be used in the Crows Foot logical view. A key is used for uniquely identifying an entity and can be linked to attributes in an entity. A key consists of one or more attributes. When a single key is linked to an entity, it is the primary key. The primary key may be used in other entities to refer 25

back to. To refer from one entity to the primary key of another entity, you can set a foreign key. That way, you can define the relationship between different entities. In a NIAM view an entity can be uniquely identified by using uniqueness constraints. Good primary keys have different characteristics. Firstly, they are unique for each instance of an entity. Secondly, they are never empty or zero: they always contain a value. Thirdly, they rarely, preferably never, change. 3.6.1 Adding attributes to an entity Attributes can be added to an entity in different ways: Via the Create window pane: Click the Attribute concept and then click in an entity in the view. Using the entity control for adding attributes: click on an entity in the view, and then click on its control. Using the quick-create pop-up window: Click in the white area of an entity in the view, and briefly hold down the mouse button. Next, click the attribute concept in the appearing pop-up window. Attributes cannot be added by first creating them in the model browser, and then dragging them onto a view. However, when created in a view, they can be dragged from the model browser onto another view to use there. Attribute sorting In the Crows Foot view attributes are automatically sorted ascending on name when added to the entity. When the (by default mandatory) attributes are also marked as optional (-) or as part of the primary key (#), the list is also automatically sorted by the marking. Default order is: primary key(s) first, then mandatory attributes, and then optional attributes. Within each marking type, the name sorting order is used, so the primary keys are sorted, then the mandatory attributes, and finally the optional attributes. 26

In the NIAM view the attributes are sorted in the order they are added to the entity, and they are also not sorted on their marking. If they need to be sorted otherwise, you need to manually move them within the entity. 3.6.2 Moving and sorting attributes To change their position in the list in the entity, attributes can be moved manually and sorted. If you manually rearrange the default order of the attributes in the entity, then this becomes the new default order. When the entity is dragged on another view, the manually set order is used for the attributes. If on this view, the order is rearranged again, then that becomes the new default order. Moving an attribute You can easily move the individual attributes to put them on the right position in the list. To move an attribute, do as follows: Click on the attribute, and drag it to the desired position in the list. Figure 3.7 Moving an attribute within an entity Sorting attributes Attributes in an entity can be sorted ascending (alphabetically), descending (alphabetically), or can be set to no sorting. Sorting attributes is only possible in the Crows Foot logical view. To sort the attributes in an entity, follow these steps: 27

1. Select the entity in the view, and click the sorting control at the border of the entity. If you select multiple entities, the chosen sorting order is applied to all selected entities. 2. In the Sorting order window, select the desired sorting order, and click OK. Ascending (alphabetically): The attributes are automatically sorted by name from a to z, and ascending by number. Names with a number come first. If the attributes have been assigned different markings, the sorting is done within each type of marking. Descending (alphabetically): The attributes are automatically sorted by name from z to a, and descending by number. Names with a number come last. If the attributes have been assigned different markings, the sorting is done within each type of marking. No sorting: When set to no sorting, the attributes remain at their current position, but when moving the attributes manually afterward, they can be positioned anywhere in the entity. There will be no automatic sorting on name or marking. Example: 3.6.3 Removing attributes Removing an attribute can be done in two ways: 28

Remove from the entity: Click on the attribute in the entity, and then click the red cross control to right of the attribute, or press Delete. Remove from the model browser: In the model browser, right click the attribute, and then click Delete. In both situations the attribute is removed from the model (as opposed to what is common behavior in most of the other modeling languages when removing elements from a view). Figure 3.8 Removing attributes from an entity 3.6.4 Using keys There are two ways of using keys in your entity-relationship model: Defining the key by making attributes part of the primary key. In this situation the key is not physically modeled, its existence is determined by the fact that it has attributes assigned. Only one key can be defined for an entity. By modeling keys as objects and making attributes part of the (primary) key. In this situation an entity can have multiple keys attached. In that case, they are no longer considered a primary key, but just a key. Making an attribute part of the primary key To make an attribute part of the primary key, follow these steps: 29

1. Click on the attribute in the entity, and then click the in front of the attribute. 2. Click on the. Modeling a key as object To model a key as object, just add it to the view like any other object. After that, connect the key to the attributes in an entity you want to make part of this key using a Link relation. Figure 3.9 Entity with one primary key (left) and with two keys (right) If you add an existing key to another view, and this view already contains the attributes that have been linked to the key, then the links are automatically added too. 30

Key indicator in attributes When an attribute is attached to a key, it is shown in different ways in the view. When an attribute is made part of a primary key (via a link or not), it is marked with a in front of the attributes name. In case you connect more than one key to attributes in an entity, the attributes will not be marked as part of the primary key because there is no primary key. If the (primary) key the attribute is linked to, has been modeled as an object in your model, then the attribute also has a light gray border to indicate the connection. This also applies to attributes in a NIAM view when they are linked to a uniqueness constraint. The key does not necessarily have to be present in the same view as the attribute. Figure 3.10 Attributes attached to a primary key modeled as object 3.6.5 Setting the foreign key for an attribute If you want to refer from one entity to the primary key of another entity in a Crows Foot logical view, then set a foreign key. When an entity has a foreign key, it is indicated by the letter in front of the attribute name. Figure 3.11 Foreign keys in an entity 31

When you click the, the entity with the attribute or attributes referenced, is highlighted in the open view. Because the primary key of an entity may consist of a single attribute or set of attributes, it is possible to select a single attribute or an entity when setting the foreign key. The entity represents the set of attributes that form the primary key. An attribute can have a foreign key that is also part of the primary key of its entity. The attribute with the foreign key then forms along with other attributes the primary key. The attribute then has an as well as a in front of its name, as can be seen in the above figure. To set a foreign key, follow these steps: 1. Click on the attribute in the entity for which you want to set the key. 2. Click the blue appearing in front of the attribute name. 3. In the appearing window, in the Crows Foot model element of an ER model, select the attribute or entity you want to refer to and click OK. If you want to refer to an entity, you can also drag an entity from the model browser onto the attribute in the view, instead of selecting one. 4. Name the attribute. Removing the foreign key To remove a foreign key, do as follows: 32

Click on the attribute of the entity, and then click the red cross control next to the. Deleting the last reference to an object that is referenced as a foreign key will not automatically delete this object. If you want to delete unused objects, locate them with the Unused objects function and delete them. When deleting an object that is still referenced as a foreign key, the references will properly be reset. 3.6.6 Setting the optionality of an attribute Not all entities have a value for each attribute, but some attributes must have a value for all entities. This can be set with the attribute's optionality. Make an attribute optional if it is not required that an entity has a value associated with the attribute. Make an attribute mandatory if an entity must have a value that is associated with this attribute. The optionality can be set for attributes in the Crows Foot logical view as well as the NIAM view. Example: The entity Employee has attributes Hire date and Termination date. The Hire date can be regarded as a mandatory attribute, because if an employee does not have a hire date, he would not be employed. The Termination date is optional. One can expect that employees that are still active do not have a termination date. Former employees on the other hand will have a termination date. 33

When adding a new attribute, it is mandatory by default. To make an attribute optional, click the in front of the attribute. In the NIAM view, it directly turns into a to indicate it is optional. In the Crows Foot view, click the to make the attribute optional. Figure 3.12 Mandatory and optional attribute To make an optional attribute mandatory again, click again until the appears again. 3.7 Facts in an entity-relationship model Facts are only available in the NIAM view, and they are used for modeling relations between the entities. A fact consists of two predicates, each defining the role of one of the entities involved in the relationship. 3.7.1 Modeling facts A fact can be modeled in two ways, by adding it as an object or as a relation. Both ways have the same end result in the view: a modeled relation between entities. Adding a fact as relation The quickest way to model a fact is by adding it as relation. Just connect two entities using the Fact relation. Next, a fact object is added with two Link relations connecting the fact to the entities. 34

Adding a fact as object If you add a fact as object, you first add the object. Next, connect the fact to the two entities using a Link relation. Tip: If you want to move a fact or resize it, click just outside the border of the object to select it. If you click on the border or in the object, you select a predicate of the fact, not the fact itself. 35

3.7.2 Naming the predicates of a fact The predicates of a fact represent both sides of the relation between two entities. They describe how the two entities relate to each other. To name a predicate for one of the sides of the relation, do as follows: Click on one side of the fact, and directly type the name. 3.7.3 Changing the orientation of a fact By default, a fact is positioned horizontally when added to a NIAM view. If your model prefers this, you can change the fact to a vertical orientation. To do this, do as follows: Click just outside the fact, and then click the control next to the fact. To change it back to a horizontal position, click the control. 3.8 Constraints in an entity-relationship model Constraints are only available in the NIAM view, and they are used for modeling limitations on the relations between entities. There are three types of constraints: Uniqueness constraint for indicating the key of an entity for uniquely identifying the entity. Is linked to attributes of an entity. 36

Exclusion constraint for indicating that each of the entities excludes the other. Is linked to predicates of a fact. Completeness constraint for indicating that two entities together complete the collection. Is linked to predicates of a fact. 3.8.1 Uniquely identifying an entity with uniqueness constraints Like keys in a Crows Foot logical view, uniqueness constraints can be used for uniquely identifying an entity by linking it to one or more attributes in the entity. A single entity can have multiple uniqueness constraints. To model the key, add a Uniqueness constraint object to the view. After that connect the key to the attributes in the entity you want to make part of this key by using a Link relation. 3.8.2 Setting a sequence number for uniqueness constraints If multiple uniqueness constraints are used, it is possible to assign them a sequence number. To assign a sequel number, follow these steps: 1. In the view, click on the uniqueness constraint, and then click its control. 37

2. In the Enter sequence number window, enter the number and click OK. The sequence number is now displayed in the constraint: 3.8.3 Displaying the name of a constraint relation When a constraint is linked to an attribute in an entity or to a fact, only the constraint is shown with a relation to the other element. To explicitly show which element the constraint is linked to, you can display the name of the relation. To display the name, do as follows: In the view, click on the constraint, and then click on the name that appears below the constraint. 38

The name is now displayed below the constraint: You can hide the name again by clicking it. 39

4 Relations between ERD and other modeling domains Entity-relationship models can be integrated with models from other domains, like BPMN models and DMN models by linking entities from your ER model to data objects in BPMN processes and collaborations, or linking entities and attributes to information items from the decision model. To be able to link entities and attributes to elements from BPMN or DMN models, these other models must be in the same model package as the ER model. Linking the elements is done in the other models, not in the ER model. 4.1 Integration with BPMN models Linking ERD entities to BPMN data objects is done in the BPMN process diagram or collaboration diagram containing the data object you want to link. For more information about linking BPMN data objects to ERD entities, please refer to the BPMN Getting Started Guide (PDF). 4.2 Integration with DMN models Linking ERD entities and attributes to DMN information items is done in the glossary from a decision model containing the information items you want to link. For more information about linking DMN information items to ERD entities and attributes, please refer to the DMN Getting Started Guide (PDF). 40

Appendix A - Concepts for ERD modeling The following table shows the concepts that can be used to create entityrelationship models. For a more detailed description of ERD concepts and their use, please refer to existing third party ERD documentation. In the table below each concept is visualized in an example, using the default color of the object. Other objects and relations in the example are faded in order to place them in the background. OBJECTS Symbol Name + description, Entity An entity represents a component or an object. It is a concrete or abstract "thing" that can be identified. Examples are a specific person, item, event, or company. Attribute An attribute represents information about an entity, it is a property of the entity. An entity can have multiple attributes. Examples of attributes of an entity "Customer" are phone number, customer number, name, and address. Attributes know a domain, optionality, key, name and description. The domain limits the allowed values, for example 41

Symbol Name + description only allowing "Yes" or "No", or only positive monetary values. Key Only available in the Crows Foot logical view. A key is used for uniquely identifying an entity and can be linked to attributes in an entity. A key consists of one or more attributes. When a single key is linked to an entity, it is the primary key. Fact Only available in the NIAM view. A fact describes the relation between two entities, and consists of two predicates, each defining the role of one of the entities involved in the relationship. A fact can be modeled by adding it as an object, or as relation. 42

Symbol Name + description Uniqueness constraint Only available in the NIAM view. A uniqueness constraint is used to indicate the key of an entity for uniquely identifying the entity. (In the logical view the Key concept can be used for this.) Exclusion constraint Only available in the NIAM view. An exclusion constraint is used to indicate that each of the entities excludes the other. Completeness constraint Only available in the NIAM view. A completeness constraint is used to indicate that two entities together complete the collection. 43

Symbol Name + description RELATIONS Symbol Name + description Relation A relation is an association among entities. An example is the relation between a customer and a product. Relations know a cardinality, an optionality, and roles. Specialization A specialization is a relation between entities that can be used to subtype entities. By using specializations you can create different levels of entity generalization. Link 44

Symbol Name + description A link is used to connect attributes to keys (logical view), entities via facts (NIAM view), attributes to uniqueness constraints (NIAM view), exclusion constraints to facts (NIAM view), or completenes constraints to facts (NIAM view). Fact Only available in the NIAM view. A fact describes the relation between two entities, and consists of two predicates, each defining the role of one of the entities involved in the relationship. A fact can be modeled by adding it as a relation, or as object. 45

Appendix B - Controls for the ERD objects The list below shows the controls that are available for the objects in an ER logical view. The conceptual view does not have any ERD-specific controls. In addition to the controls mentioned in the list there may be object controls available that can be used in modeling, like the navigator, smart connector and arrow controls for adding new elements. These controls are generic and available in almost every modeling language and method in Enterprise Studio. The generic controls are discussed in the Enterprise Studio User Guide (PDF). CONTROLS Symbol Name + function Add attribute Available on an entity. Adds a new attribute to the entity. Select sorting order Available on an entity in a Crows Foot logical view. Opens a selection window for choosing the desired sorting for the attributes in the entity. Toggle between primary key (#), mandatory (+) and optional (-) Available on an attribute in an entity. Default setting is mandatory. Clicking the control once sets the attribute to optional. Clicking one more time makes the attribute part of the primary key. The primary key option is not available on attributes in a NIAM view. Set foreign key Available on an attribute in an entity in a Crows Foot logical view. Sets the foreign key for an attribute. After clicking the control, an entity can be selected from the model to refer to the primary key of this other entity. 46

Symbol Name + function <entity name> Available on an attribute in an entity in a Crows Foot logical view. Jumps to the entity that has been selected for setting the foreign key. Remove foreign key Available on an attribute in an entity in a Crows Foot logical view with a foreign key ( ) attached. Removes the foreign key from the attribute. Remove attribute Available on an attribute in an entity. Removes the attribute from the entity. Change to vertical orientation Available on a fact in a NIAM view. By default, facts in a NIAM view are positioned horizontally. Switches the fact positioning from horizontal to vertical. Change to horizontal orientation Available on a fact in a NIAM view. Switches the fact positioning from vertical to horizontal. Toggle fact description/change direction of fact Available on a fact in a NIAM view. Toggles between hiding the description of the fact (default situation), displaying the fact description, and changing its direction when displayed. Set order Available on a uniqueness constraint in a NIAM view. Opens a window for entering the sequence number of the uniqueness constraint. 47

Index A add attribute (control) 46 adding attributes to entity 26 attributes to primary key 29 objects and relations to ERD view 12 view to ER model 12 attribute 41 attributes adding to entity 26 adding to primary key 29 in entity-relationship model 25 moving 27 remove 28 remove foreign key 32 setting foreign key 31 setting optionality 33 sorting 27 C cardinality of relation 21 changing fact orientation 36 completeness constraint 37, 43 concepts for ERD modeling 13, 41 conceptual level ER models 7 conceptual view 5, 12 constraints displaying relation name 38 in entity-relationship model 36 controls ERD objects 46 creating entity-relationship model 11 Crow's foot notation 5 D defining definition of an entity 17 optionality of an attribute 33 roles of relation 24 definition of an entity 17 displaying name of constraint relation 38 E elements for ERD modeling 41 entities adding attributes 26 in entity-relationship model 16 naming 15-16 setting a definition 17 subtyping 17 uniquely identifying 37 weak entities 18 entity 41 Entity-Relationship Diagram See ERD entity-relationship models adding view 12 attributes and keys 25 constraints 36 creating 11 entities 16 facts 34 naming entities and relations 15 relations 18 submodels 14 entity-relationship views naming relations 18 NIAM view 9 removing relation name 20 showing both relation names 20 ER models integration with BPMN models 40 integration with DMN models 40 48

F J ERD adding attribute to primary key 29 attribute optionality 33 concepts for modeling 13, 41 conceptual model 7 logical model 8 model templates 5 modeling 4 modeling levels 5, 7 moving attributes 27 naming entities and relations 15 NIAM-inspired modeling 9 notation 5 object controls 46 relation to other modeling domains 40 remove attributes 28 setting the foreign key 31 sorting attributes 27 used terminology 5 ERD objects controls 46 ERD views adding content 12 exclusion constraint 37, 43 fact 42, 45 facts changing orientation 36 in entity-relationship model 34 modeling 34 naming predicates 36 foreign key 8, 18 remove 32 setting for an attribute 31 jump to called entity (control) 47 K key 42 keys in entity-relationship model 25 setting the foreign key 31 L link 44 logical level ER models 8 logical view 5, 12 M model templates ERD 5 modeling facts in NIAM view 34 modeling domains relation to ERD 40 modeling levels ERD 7 modeling with ERD 4 available concepts 13, 41 moving attributes in entity 27 multiplicity of relation, setting 21 N naming ERD entities and relations 15 of entities 16 predicates of fact 36 relations in entityrelationship view 18 NIAM method 9 NIAM view 5, 12 notation ERD 5 O objects adding to ERD view 12 optionality of attributes 33 of relation 21 49

orientation of fact, changing 36 P participation of relation, setting 21 predicates of fact, naming 36 primary key 8, 18, 25 adding an attribute 29 sorting attributes in entity 27 specialization 44 specialization relation, ERD 24 submodels in entity-relationship model 14 subtyping entities 17 R T relation 44 relations adding to ERD view 12 between ERD and other modeling domains 40 defining roles 24 in entity-relationship model 18 naming 15, 18 showing both names 20 relations ER model expressing nature of relation in a sentence 22 setting multiplicity and participation 21 specialization relation 24 remove attribute (control) 47 remove foreign key (control) 47 removing attributes from an entity 28 foreign key from an attribute 32 relation name in entityrelationship view 20 roles defining for relation 24 terminology, ERD 5 toggle attribute (control) 46 U uniquely identifying entitiey 37 uniqueness constraint 36-37, 43 setting sequence number 37 V view conceptual 5 logical 5 NIAM 5 views adding to ER model 12 W weak entities 18 S select sorting order (control) 46 sequence number uniqueness constraint 37 set foreign key (control) 46 setting multiplicity and participation 21 sequence number 37 50

PDF guides The following PDF guides are available for download from the BiZZdesign community: HoriZZon HoriZZon Web Portal Guide Enterprise Studio Advanced Modeling Guide Amber Getting Started Guide ArchiMate Getting Started Guide Analysis Guide BPMN Getting Started Guide BiZZdesign Connect Guide DMN Getting Started Guide Enterprise Analytics Guide Enterprise Portfolio Management Guide Enterprise Studio Options Guide Enterprise Studio User Guide ERD Getting Started Guide ERSM Getting Started Guide License Management Guide Metamodeler Guide Reporting and Printing Guide Scripting Reference TDM Getting Started Guide Team Platform Guide Time Modeling and Analysis Guide 51

Contact BiZZdesign Service desk Academy Inside sales Head office Website Customer portal For questions and information regarding service and support. Phone: +31-53 - 4 878 171 E-mail: servicedesk@bizzdesign.com For questions and information regarding training and education. Phone: +31-33 - 7 600 284 E-mail: academy@bizzdesign.com For questions and information regarding commercial conditions, new modules, and prices for use. E-mail: sales@bizzdesign.com For general questions and information. Phone: +31-53 - 4 878 151 E-mail: info@bizzdesign.com http://www.bizzdesign.com http://community.bizzdesign.com