ERD Getting Started Guide

Transcription

1 Enterprise Studio ERD Getting Started Guide

2 Table of contents 1 About modeling with ERD What are entity-relationship diagrams? Entity-relationship modeling ERD in Enterprise Studio 4 2 ERD modeling levels Conceptual level Logical level 7 3 Creating entity-relationship models Creating a new ER model Adding a new view Adding content to an ER view Concepts for modeling Naming entities and relations Entities Naming an entity Defining an entity Subtyping entities Weak entities Relations Naming a relation Determining the cardinality and optionality of a relation Expressing the nature of a relation in a sentence Defining roles for a relation Specialization relation Attributes and keys Adding attributes to an entity Setting the key for an attribute Setting the optionality of an attribute 23 Index 25 PDF guides 28 2

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 1.2 Entity-relationship modeling In entity-relationship modeling the following components are 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. Relations for displaying the connections between the different entities. Relations know a cardinality (multiplicity), an optionality (participation) and roles. By means of specialization relations entities can be subtyped. Modeling is done in different views within an ER model. 3

4 1.3 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 Enterprise. Notation Different notations are used for ERD. Enterprise Studio uses 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. Modeling levels The entities, attributes and relations can be modeled in three types of models, each of which has a different abstraction level. We distinguish the conceptual (descriptive), logical (analytical), and physical (executive) model. Conceptual models are the simplest and form most high-level overviews. The models increase in complexity as you move to logical and physical models. Enterprise Studio supports creating models on the conceptual and logical level. For that the following views are available: Crows Foot conceptual view and Crows Foot logical view. 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. Template models Enterprise Studio has template models containing the basics for ERD modeling. You can use these templates to start a model. The template 4

5 models can be opened by clicking File > New > ERD, and then clicking one of the available templates. 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. 5

6 2 ERD modeling levels Models can be created at different levels of abstraction, ER 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. 6

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 are 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. 7

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. 8

9 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 ER model Creating an Entity-Relationship 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 always 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, click ERD, and then click 1. Empty model with conceptual view. The model browser shows a new model package with an ER model and a new empty conceptual view is opened in which you can start modeling. Create a logical data model On the File tab, click New, click ERD, and then click 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. 9

10 Start with an empty data model On the File tab, click New, click ERD, and then click 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 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 or Crows Foot logical 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. You can now start modeling. 3.2 Adding content to an ER view Objects and relations that can be drawn in an ER view are based on the concepts available to the open view. Objects and relations can be added in different ways, by using: the Create pane the quick-create pop-up window the model browser object controls the smart connector the context menu Extensive information about the different ways to add objects and relations can be found in the Enterprise Studio User Guide Concepts for modeling For both the conceptual and logical view, the concepts Entity, Relation and Specialization are available for modeling. In addition, in the logical view also has the Attribute concept available. 10

11 The amount of detail that can be put into a model depends on the level at which you are modeling. 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 Naming entities and relations In order to create clear 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 Role Attribute 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. 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. 11

12 3.3 Entities 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 Defining an entity In a 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.1 Adding an entity definition Subtyping entities When modeling, you can use subtypes in entities. You can make specializations or generalizations, depending on whether you are modeling bottom-up or top-down. 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. 12

13 Figure 3.2 Example of subtyping an entity 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.4 Relations A relation in an ER view shows the connection between two entities. The relation usually goes both ways. Relations know a cardinality and an optionality 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. 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: 13

14 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 then point the other way. The name that was entered first is no longer visible. 3. Click on the line and directly 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. 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. 14

15 If you want this name to be on top, click the arrow one more time. 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 relation is visible. If not, first click on the arrow in the line to make it visible. Next, click the name of the relation so that a box appears around it. After that, press F2 and subsequently press Delete. The name is now gone. Figure 3.3 Removing the name of a relation 15

16 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 Determining the cardinality and optionality 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. It has a value of zero, one or 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). The table below shows the possible combinations of multiplicity and participation with its corresponding representation in the relation. Multiplicity Participation 0 1 Many 1 The multiplicity and participation are defined on both ends of the relation. The multiplicity is set at the end of the relation, closest to the entity. The participation just before that, at the vertical line. To define the multiplicity and participation, click on the right place in the line. By repeatedly clicking you change the setting. 16

17 When adding a new relation, the cardinality and optionality are initially set to 1 and 0 on one side and bot to 1 on the other side 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 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. The nature of the relation can be expressed for one direction. Which one, depends on the currently active relation (as can be seen by the direction of the arrow). Below is an example. Regular display of relation and cardinality: Relation and cardinality expressed in a sentence: Before you display the relation and cardinality in a sentence, ensure that the correct relation is the active one. Next, hold down Alt and click on the arrow in the relation. The sentence appears. To turn back to the regular display, do the same: hold down Alt and click the arrow 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. 17

18 Here you can lay down the role names. Double-click a label and type the name of the role 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 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.4 Specialization relation 18

19 3.5 Attributes and keys Attributes are only used in a logical ER model. With attributes you 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 specify whether it is part of the primary key, and set the optionality 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. By means of the 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. Using of the plus sign in the entity: click on an entity in the view and then click the plus sign to the right of the entity name. The attributes are automatically placed below each other in the entity. Moving attributes Attributes that have been added to an entity, do not necessarily have their final place in the attribute list. After adding them, you can easily move the attributes. To do this, click on an attribute and drag it to the desired position in the list. Figure 3.5 Moving attributes within an entity 19

20 Removing attributes To remove an attribute from an entity, click on the attribute and then click the red cross sign next to the attribute, or press Delete. Figure 3.6 Removing attributes from an entity Setting the key for an attribute The primary key forms the unique identification of an entity and may consist of one or more attributes. The primary key may be used in other entities to refer back to. To refer from one entity to the primary key of another entity, set a foreign key. That way, you define the relationship between different entities. Good primary keys have different characteristics. Firstly, they uniquely identify each row. Secondly, they are never empty or zero: they always contain a value. Thirdly, they rarely, preferably never, change. Making an attribute part of the primary key When adding a new attribute to an entity, it is by default not part of the entity's primary key. You still need to set it. To make an attribute part of the primary key, click the attribute in the entity and then click the plus sign in front of the attribute name twice. When the sign has changed into a #, it is part of the primary key. 20

21 Note: The plus sign in front of the attribute name is an alternating sign. A plus sign + indicates that the attribute is mandatory. After the first click the sign turns into a minus sign -. This indicates that the attribute is optional. Clicking one more time turns the sign into a #. This indicates that the attribute is part of the primary key. If you click once more, the plus sign will appear again. Figure 3.7 Setting the primary key for an attribute Setting the foreign key for an attribute If you want to refer from one entity to the primary key of another entity, then set a foreign key. When an entity has a foreign key, you can tell this by the letter F in front of the attribute name. Figure 3.8 Foreign keys in an entity When you click the F, 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 21

22 setting the foreign key. The entity represents the set of attributes that form the primary key. To set a foreign key, first click on the attribute in the entity for which you want to set the key. Next, click the blue F appearing in front of the attribute name. Figure 3.9 Setting the foreign key for an attribute 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. Finally, name the attribute. 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. 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 F as well as a # in front of its name, as can also be seen in the image above. Removing the foreign key To remove a foreign key, click the attribute of the entity and then click the red cross sign next to the F. 22

23 Figure 3.10 Removing the foreign key from an attribute 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 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. 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. When adding a new attribute, it is mandatory by default. This is indicated by the plus sign in front of the name. To make an attribute optional, click the plus sign in front of the attribute name. The sign turns into a minus sign. 23

24 Figure 3.11 Mandatory and optional attribute To turn an optional attribute into a mandatory one, click the minus sign and then click the # sign. The # sign indicates that the attribute is part of the primary key (see Making an attribute part of the primary key). 24

25 Index A adding attributes to entity 19 attributes to primary key 20 entities and relations to ER view 10 view to ER model 10 attributes adding to an entity 19 adding to the primary key 20 in ER views 19 moving 19 remove 20 remove foreign key 22 setting the foreign key 21 setting the key 20 setting the optionality 23 C cardinality defining 16 concepts for ERD modeling 10 conceptual level ER models 6 conceptual view 4, 10 creating entity-relationship model 9 Crow's foot notation 4 D defining cardinality and optionality of a relation 16 definition of an entity 12 optionality of an attribute 23 roles with a relation 17 definition of an entity 12 E entities adding attributes 19 adding to an ER view 10 in ER view 12 naming setting a definition 12 subtyping 12 weak entities 13 Entity-Relationship Diagram See ERD entity-relationship models adding view 10 creating 9 ER views adding entities and relations 10 attributes 19 entities 12 keys 19 relations 13 ERD adding attribute to primary key 20 attribute optionality 23 concepts for modeling 10 conceptual model 6 logical model 7 modeling 3 modeling levels 4, 6 moving attributes 19 notation 4 remove attributes 20 setting the foreign key 21 25

26 setting the key for an attribute 20 template models 4 used terminology 4 F foreign key 7, 13 remove 22 setting for an attribute 21 K keys in ER view 19 setting for an attribute 20 setting the foreign key 21 L logical level ER models 7 logical view 4, 10 M modeling levels ERD 6 modeling with ERD 3 available concepts 10 moving attributes in an entity 19 N naming of entities 12 of entities and relations 11 of relations 13 notation ERD 4 O optionality of a relation 16 of attributes 23 P primary key 7, 13, 19 adding an attribute 20 R relations adding to ER view 10 in ER view 13 naming 11, 13 relations ER model defining roles 17 determining the cardinality and optionality 16 expressing nature of relation in a sentence 17 showing both names 14 specialization relation 18 remove attributes from an entity 20 foreign key from an attribute 22 roles defining for a relation 17 S setting key for an attribute 20 specialization relation, ERD 18 subtyping entities 12 T template models ERD 4 terminology, ERD 4 26

27 V view conceptual 4 logical 4 views adding to ER model 10 W weak entities 13 27

28 PDF guides The following PDF guides are available for download from the BiZZdesign community: Analysis Guide BPMN Getting Started Guide DMN Getting Started Guide Enterprise Analytics Guide Enterprise Portfolio Management Guide ERD Getting Started Guide ERSM Getting Started Guide InSite Guide License Management Guide Options Guide Reporting and Printing Guide TDM Getting Started Guide Team Platform Guide User Guide 28

29 Contact BiZZdesign Service desk Academy Inside sales Head office Website Customer portal For questions and information regarding service and support. Phone: servicedesk@bizzdesign.com For questions and information regarding training and education. Phone: academy@bizzdesign.com For questions and information regarding commercial conditions, new modules, and prices for use. sales@bizzdesign.com For general questions and information. Phone: info@bizzdesign.com