what i ntity relationship diagram › wp-content › ...an entity relationship diagram (erd) is a...

HOW TO CREATE AN

ENTITY RELATIONSHIP DIAGRAM

http://www.mybusinessanalysiscareer.com of 29

By Laura Brandenburg, CBAP

WHAT IS AN ENTITY RELATIONSHIP DIAGRAM? An Entity Relationship Diagram (ERD) is a data model describing how entities (or

concepts or terms we talked about in the lesson on glossaries) relate to one

another. When created by business analysts, ERDs can be used to understand the

business domain, clarify business language, and connect business concepts to

database structures.

An ERD is a technique you can use to capture, analyze, and communicate the big

picture of your domain. They are a visual touchstone that, once created, you’ll

find yourself referring to again and again throughout your project as you are

analyzing business processes, software features, and, yes, the more detailed data

definition requirements that we’ll discuss in the next lesson.

Before we dive into ERDs and relational databases, let me share a bit about the

very first ERD I ever created. I was in my second business analyst role, working in

a new organization with relatively unfamiliar systems and some unfamiliar

domain language. We were building a new product to help our customers

research scientific information, and one of our project goals was to enable

customers to seamlessly order document reproductions of any interesting articles

they found in the scientific literature.

Lesson Objective: After completing this lesson, you will be able to

create an entity relationship diagram that shows how business terms

relate and helps link business concepts to relational database

structures.

http://www.mybusinessanalysiscareer.com/

HOW TO CREATE AN



We had a pre-existing system that contained customer information and article

information. We had gotten a few months into developing the new system

without explicitly exploring how it would be connected to this pre-existing

system.

At this point in the project, the requirements clearly specified the types of

connections that needed to functionally be in place, but I had pretty much left it

at that while I worked on more pressing requirements issues (there were many).

To complicate matters from a project perspective, there were two technical

teams – one for the pre-existing legacy system and a third-party consulting

organization that was responsible for building the new product – and they

weren’t talking to each other. I began to sense that a significant project risk was

being overshadowed by schedule pressures, as no one had considered how these

two systems would integrate.

After expressing my concerns to the consulting organization and offering my

assistance, the technical lead suggested I create a domain model to sort out the

integration issue. I liked a challenge, so I picked up a book on Unified Modeling

Language (UML) and started working my way through the analysis of a class

diagram (which is one way to model an ERD that we’ll talk about in this lesson).

I soon realized we had two different definitions of “customer” that needed to be

reconciled and that even the connections between article information were not

as clear as I originally assumed.

I’ll spare you some of the gory details, mostly because this experience was over

10 years ago and the meetings were fierce and intense, but after several

collaborative sessions we had ironed out how to get the two systems to talk to

one another, and I had a domain model I could use as a touchstone when

analyzing functional requirements related to the integration, such as creating a


HOW TO CREATE AN



new customer account, setting up a customer with access to the new system, and

ordering a scientific article.

It turned out that I needed to understand this level of detail to be effective in

specifying my more detailed functional requirements and helping business

stakeholders understand how their business processes would change. The model

was quickly understood by many stakeholders while also serving to impress some

higher level executives who didn’t want the details, but were happy that someone

was thinking through them.

Since that first ERD, I’ve created business domain models several other times in

my career, turning to this technique whenever we needed to get a handle on how

our data is organized or should be organized. They are particularly useful in

system integration and migration projects. An ERD will often help you and your

project team get unstuck when you have jumped into technical details too fast or

are having trouble getting clear on requirements language.

I hope I’ve sold the value of these models well enough, but let me just make one

more point. From a business analyst perspective, ERDs can look a little tricky and

complex. And they can be. I worked on that first ERD for at least a few weeks

before having the courage to put it in front of my technical stakeholders. I felt a

little bit like a fish out of water.

Part of the reason they seem tricky is because they look like databases, which

makes them feel more technical than they need to be. Rest assured that you are

not necessarily defining a physical database when you put together an ERD. They

can represent real-world business concepts, and that’s the bulk of what we are

going to cover in this lesson.


HOW TO CREATE AN



That being said, ERDs will make a lot more sense if you understand what a

relational database is and how it’s structured, so let’s take a quick side bar here

and give you a crash course on relational databases.

(If you come from a software or technical background, you may very well be able

to skip this section. Then again, you may want to read it with an eye to thinking

about how you might more clearly explain relational databases to your business

stakeholders without using a lot of technical jargon.)

And if you come from a business background, you might be wondering what you

got yourself into at this point. This is going to be the most technical part of the

course, I promise. What’s more, it’s full of pictures and examples so you can see

what I’m talking about. If you can use a spreadsheet, you will be able to get this,

and it is smooth sailing from here.

CRASH COURSE ON RELATIONAL DATABASES A relational database is a collection of records organized in tables. Each table

defines one or more data elements that can hold information for each record,

typically called fields or attributes.

Let’s take a look at a very simple example, a hypothetical relational database

table for a Shipping Address.

(As an aside, throughout this lesson I will be referring to specific visual elements

that are included in the PDF transcript. If you are listening to the audio, it will be

helpful to have the transcript available for reference.)


HOW TO CREATE AN



In this example, the table name is “Shipping Address.” The field names are: Name,

Street Address 1, Street Address 2, City, State, and Postal Code.

While relational databases are typically created using database software, such as

SQL Server or Oracle, you could create one in a spreadsheet. Since we’re business

analysts and not database developers, let’s look at what a spreadsheet would

look like with three instances of our Shipping Address table.

In a spreadsheet format, each column indicates the name of the field in the table

that’s defined as part of the relational database structure. Each row holds one

record. Each cell holds a specific piece of data for the record that adheres to the

structure defined by the corresponding field.

The Shipping ID field has been added because one of the characteristics of a

relational database is that each and every record has a unique ID. We’ll see why

this is important as we expand our model.


HOW TO CREATE AN



At this point, we’ve created a database with one and only one table, so it’s not yet

relational. To make it relational, we’ll need to create at least two tables that

relate to one another.

Typically, there is a Shipping Address because there is a Customer, so let’s expand

our model to show how the Shipping Address relates to a Customer table.

This model shows how each Customer can have one or more Shipping Addresses.

Now, let’s look at what the corresponding data in our Customer table might look

like.

This table looks very much like the previous one, except there are different fields

and different records.

I want to call your attention to one special element – the unique keys. You’ll

notice that when we specified Shipping Addresses, each record also contained a

field for a Customer ID. As a stand-alone table, this Customer ID field was not


HOW TO CREATE AN



necessary. However, to create and maintain the relationship between records in

different tables, it’s absolutely critical. This one field is the connector that

connects the Customer to its Shipping Addresses. These unique keys are also

referred to as primary keys and they are typically system assigned.

While it’s not uncommon for a business user to be aware of primary keys such as

Customer ID, which may even be used in look-ups or reporting, typically a physical

database will have many primary or unique keys that are not visible to business

users.

And that ends our crash course on relational databases. If this made perfect sense

to you, I probably simply gave you new words to explain something you’ve

intuitively understood for a long time. Like a lot of what we’ll cover about data

modeling, the terminology can make things trickier than they need to be. As a

logical thinker, you’ll pick up these concepts quickly.

If you found yourself furrowing your brow on occasion, you might want to spend

a little time working with Excel or Access to manage some data so you can see

how this plays out and get a better feel for the concepts.

It’s smooth sailing from here.

THE 3 LEVELS OF MODELING Now that we understand relational databases, let’s talk about the different levels

of modeling. While an ERD can be used to model a physical database structure,

this is not the only application of the technique. And as a business analyst, it’s

unlikely that you will be creating models at the level of the physical database

structure, although you might review them from time to time.

Let’s take a quick look at three different levels of modeling.


HOW TO CREATE AN



Conceptual Modeling

Conceptual modeling is the highest level and represents an abstract view. This

model is typically captured in business terminology and represents business

concepts. When creating a conceptual data model, you will not be worried about

primary keys or any but the most important attributes. Your goal is to get the

primary business concepts down on paper and visually show how they relate to

one another.

Because conceptual modeling is high-level, you have the ability to show a wide

range of concepts that may touch several information technology systems,

without worrying about the details of how these relationships or databases would

actually be designed and implemented.

Logical Modeling

The best way to think about logical modeling is that it takes the concepts and

makes them theoretically implementable. To create a logical model, you must

resolve the kinds of issues I faced with my first ERD, such as how the different

definitions of customer might actually be resolved through integrating the two

systems.

Logical modeling gives a database developer the information they need to design

and implement a physical database model, but it may not include all of the

details, such as each primary key or the tables that are used to map primary keys

together. In scenarios where you are working from a pre-existing database design,

a logical model may draw from table names and field names from the physical

database for clarity.

Physical Modeling

Physical data modeling specifies the actual database tables that are created and

maintained as part of the database structure. The entities are the names of

tables. The attribute names are names of actual database fields.


HOW TO CREATE AN



In our Customer and Shipping Address example, the physical model would show

the fields for the primary keys or if there was a separate table that mapped one

set of keys to another. Most database software will automatically create an ERD

model of the physical database structure, so it’s a common way for a database

engineer to walk you through the database.

Before starting a diagram, it’s important to know what level of information you

are looking at and also communicate the level clearly to anyone reviewing the

document. As a business analyst, you will most often start at either the

conceptual or logical model. It’s also not uncommon for a conceptual model to

evolve into a logical model as clarity emerges about the key concepts.

KEY ENTITY RELATIONSHIP DIAGRAM CONCEPTS With an understanding of relational database concepts and the three different

levels of modeling, we are ready to discuss the specific elements that go into an

entity relationship diagram – entities, relationships, and attributes.

Entities

The most important concept in an Entity Relationship Diagram is the entity. An

entity is a thing. In business domain terms, it’s a concept or glossary-level term. In

relational database terms, it’s the table.

For example, here are some entities we might model in a commonly understood

process – search for a job.

Job Posting

Employer

Recruiter

Applicant

Application


HOW TO CREATE AN



Each of these terms is a container for more detailed information. Each of these

terms is a noun, representing an item that is part of the job search process. Each

of these terms exists as a stand-alone thing, but also exists in relation to the other

items on the list.

And in the world of job search systems and processes, there will be multiple

instances, or records, of each item – multiple job postings from multiple

employers, and multiple (sometimes too many) applicants and applications. And

so on and so on.

Your glossary will be your primary source for business terms to include in an ERD,

so start by evaluating any terms you’ve defined already. If you haven’t yet created

a glossary, you can still create an ERD. Simply use any of the techniques discussed

in the glossary lesson to find terms to model on your ERD, such as analyzing

documents, listening for terms in requirements discussions, and evaluating user

interfaces and forms.

One nice thing about an ERD is that if you are having trouble getting your

stakeholders to consider the terms and definitions in your glossary, sometimes

simply redrawing the problematic terms in an ERD format will spark the right

discussion. An ERD looks a lot more formal and necessary than a simple glossary,

so it does double-duty as an analysis tool and a terminology-clarifying tool.

In general, the number of terms you include in an ERD will be more limited than a

glossary. When starting, stick to the highest level and most critical concepts that

need to be understood in relation to one another. For the time being, leave out

any unrelated concepts or less important terms.

At the conceptual or logical level, an ERD would include a box for each of these

concepts or terms with the entity name listed inside the box, as follows.


HOW TO CREATE AN



Relationships

Entities are interesting, but the real insight comes when we see how entities

relate to one another, hence the name entity relationship diagram. Relationships

can be thought of as verbs that link two or more nouns.

For example:

A Hiring Manager posts a Job Posting.

An Applicant creates an Application and submits it to a Job Posting.

A Recruiter reviews an Application.

Relationships tell us how two concepts exist relative to one another. While a

glossary can do a great job of listing and defining terms, a glossary is flat. The

power of an ERD is in showing the relationships and how the different terms

connect.


HOW TO CREATE AN



Relationships answer questions such as whether or not a hiring manager is the

only person to post a job posting or whether or not a job posting can exist

independently without being connected to a hiring manager. They let us know if

it’s possible for an applicant to have more than one resume or submit more than

one application to the same job.

Relationships put constraints around what’s possible in an information system

and they are the starting point for modeling a relational database that will

actually store and maintain data for the business.

Relationships are modeled as a line connecting two entities.

There are three different ways to define the type of relationship that exists

between entities. First, there is the verb-line model and we’ll start here because

it’s the most intuitive to consider. When a verb is used to define a relationship,

it’s also preferable to include an arrow on the line to show which direction the

noun-verb statement reads.

For example, here’s how we would model Hiring Manager posts Job Posting.

A relationship may also define how the concepts exist in relationship to one

another numerically. For example:

A Hiring Manager posts one or more Job Postings. (But each Job Posting

may have only one Hiring Manager.)


HOW TO CREATE AN



One Applicant applies to one or more Job Postings. (And each Job Posting

can receive zero or many Applicants.)

A Recruiter receives anywhere from zero to many Applications to a Job

Posting. (But to many Applicants’ chagrin, not every Application is

necessarily reviewed by a Recruiter.)

Numeric relationships are more commonly referred to using the terms multiplicity

or cardinality, which are the second and third ways of modeling relationships.

Multiplicity is the term used by Unified Modeling Language (UML) in the

context of class diagrams.

Cardinality is the term used by the Crows Foot Notation, the more standard

way of modeling Entity Relationship Diagrams.

While these terms read like technical jargon, both are simply ways of indicating a

numeric relationship.

When modeling the numerical aspect of a relationship, each connection between

the line and the entity has a numeric value.

Now let’s take a deeper look at the second way of modeling a relationship. Here’s

the same example as above, now with multiplicity added. You’ll see that the “1” is

included next to the Hiring Manager entity box, because each Job Posting can be

tied to 1 and only 1 Hiring Manager. In contrast, the multiplicity “0…*” (the

asterisk represents many) is listed next to the Job Posting box because each Hiring

Manager can be associated with anywhere from zero to infinitely many job

postings.


HOW TO CREATE AN



There are 4 different multiplicities that can be specified on an ERD using the

multiplicity notation from Unified Modeling Language (UML) that would be part

of a class diagram. (We’re starting here because they are the simplest to

understand, even if it would be considered a less standard way of putting

together an ERD.)

Multiplicity Description

1 One and only one

1…* Any number from one to many

0…1 Zero to one

0…* Any number (zero to many)

Now that we’ve looked at the multiplicity way of specifying relationships, let’s

take a look at our third option and see how relationships look when they are

modeled using the Crows Foot Notation to represent cardinality. Here is a table

identifying how these same numeric relationships would be modeled using the

Crows Foot Notation.

Cardinality Description

One and only one

Any number from one to many

Zero to one

Any number (zero to many)


HOW TO CREATE AN



Here’s the same ERD example above, with the cardinality modeled using Crows

Foot Notation.

In essence, there are three different notations to choose from when modeling

relationships – verb/arrow, multiplicity, and cardinality. Choose the notation that

will best represent the types of relationships between the concepts in your

diagram and will be most easily understood by your stakeholders. No matter how

you choose to model the relationships between concepts in your entity

relationship diagram, the most important thing is to be consistent and clearly

explain the relationships to anyone who might review your diagram.

To find relationships, pick any two entities you’ve defined and ask if and how they

relate. Another way to ask this question is to consider if one entity could exist

without the other. When two entities are related in a way that is important to the

business, decide what verb describes the connection. Then evaluate how the

concepts exist numerically in relation to one another.

This is a great task to complete in collaboration with business and technical

stakeholders. Ask them to describe the relationship between two terms. As the

team agrees on a relationship, update the relationship line to capture what was

discussed. Move on to another two concepts until all of the possibilities have

been exhausted.


HOW TO CREATE AN



Be careful not to make each and every entity relate to every other entity on the

diagram. Often entities connect to one another through another entity, in which

case it is simpler and preferable to model only the primary relationship.

For example, there could be a direct relationship between a Recruiter and a Job

Posting, but it might also be accurate to show that a Recruiter works for a Hiring

Manager who posts a job. Logically, a Recruiter is then related to a Job Posting by

way of the Hiring Manager. In contrast, if a Recruiter could actually post their own

jobs in the business domain you are modeling, then you may want to include an

additional relationship between Recruiter and Job Posting as well.

Attributes

Now that we’ve discussed entities and how we can model relationships between

entities, let’s look at how we can provide more detail about each individual entity

or what information we might want to include about individual concepts in our

entity relationship diagram.

Within each entity, there can be more than one attribute. Attributes provide

detailed information about the concept. In a relational database, attributes are

represented by the fields where the information inside a record is held.

For example, a Job Posting entity might have the following attributes:

Job Title

Job Description

Hiring Organization

Salary

Required Qualification

In the model, the box for each entity contains a list of fields. The Job Posting

entity would look like this:


HOW TO CREATE AN



You can specify a lot of information about the fields in an ERD format, but this can

make your model very difficult to read and consume. When you see ERDs

complete with lists of fields, they most often represent the physical database

structure and are automated output from the actual database, not manually

created using a visual modeling tool.

When creating a conceptual or logical ERD to be used to design a new database or

update an existing one, you will most often simply list the fields, perhaps with a

small amount of additional information about each field.

For example, you may indicate whether each field is optional or required. To

continue our example, a Job Title is most likely a required field, while the Salary

might be optional.

You may also elect to include the attribute type information. Attribute Type

essentially indicates what kind of information is allowable in the field. Common

examples include text, numeric, or selections from a list. For example, Job Title

would most likely be text, Salary would most likely be numeric, and the

Qualifications may be selected from a list. Attribute types are explored in a lot

more detail in the lesson on data definition matrices.


HOW TO CREATE AN



Here is an example of how our Job Posting entity would look if it also included the

attribute type and whether each field was required or optional.

As you can see, this is starting to look complicated. Envision a model with several

entities, each with several fields, and relationships between those entities

modeled, and your diagram might be very accurate and detailed, but it will be

difficult for a normal business user to understand.

When specifying ERDs as a business analyst, which will either be conceptual or

logical, it’s typical to leave information about each field off entirely. In fact, you

may even prefer to truncate the number of fields listed, at least in your initial

drafts, and only list the most important fields that will have the most impact on

the model. Or, in a conceptual model, not list any fields at all.

There are no hard and fast rules here about what’s right and what’s wrong. You

can play around with the level of detail until you get a model that is the most

useful for your purpose. I’m emphasizing this point because when we read a lot of

the technical literature about data modeling, the emphasis is on the nuances of

field information and the different kinds of relationships. These details can be

important, but as a business analyst you may not need to worry about them yet.


HOW TO CREATE AN



If you haven’t yet figured out how a Job Posting relates to an Applicant or, say,

what criteria determines that any given Candidate is an Applicant to a Job Posting,

then getting into the nitty gritty details about the fields inside a Job Posting will

only distract you from creating clarity on the fundamental concepts to be

represented in your processes and systems.

Bringing it All Together

Up to this point, we’ve been looking at small components of an entity relationship

diagram in order to emphasize each aspect of the diagram in turn. Now, let’s look

at an example of a conceptual ERD that shows how all five of the concepts we’ve

introduced in this lesson – Hiring Manager, Recruiter, Job Posting, Applicant, and

Application – relate to one another.

This is the type of diagram a business analyst might create during a first pass, and

it would likely be reviewed with stakeholders to ensure that all important

business concepts have been covered, and that the relationships between each

concept are correct.

I’ve included both verbs and multiplicity assignments so you can see how those

can work together. However, verbs along the lines are purely optional.


HOW TO CREATE AN



What would a business analyst do with a model like this? Once they have

confirmed that this level of modeling is correct from a stakeholder perspective,

the business analyst may start including all or selected attributes inside each

concept, or they may shift their attention to a data definition spreadsheet, which

is what we will cover in the next lesson.

Before we get to that lesson, we have two more aspects of entity relationship

diagrams to cover. Let’s look at the tools you can use to create these diagrams

and then the analysis process you’ll go through to review and validate them.

TOOLS AND TEMPLATES So far, we’ve covered the levels of modeling, along with the three key ERD

concepts (entities, relationships, and attributes). I’ve also given my little lecture

on why it’s important to stay out of some of the details when you start modeling.

We’ll revisit this concept again, as it’s extremely important when doing effective


HOW TO CREATE AN



business analysis and so easy to forget when doing any kind of modeling, but

especially data modeling.

When we finish this lesson, I’ll be challenging you to create your own Entity

Relationship Diagram to practice applying these concepts and techniques. To

complete this challenge, you’ll need to select a tool set to work with. Your choice

is not final and there are a lot of options, even if you have little to no budget.

Start With the Basics

First, let’s consider a set of tools that are so ubiquitous that we no longer think of

them as tools. These are great starting points because they are readily available

and, since you already know how to use them, you will be able to focus more on

your modeling and less on the technology system.

Paper and Pencil

Whiteboard Marker and Whiteboard

Index Cards and Pencil, perhaps with bulletin board, thumb tacks, and

string.

Yes, my lead-up to these suggestions was a little tongue in cheek, but only

because I wanted to give them the validity they deserve. I nearly always create my

first, and often my second, draft of any sort of complex model on paper or a

whiteboard. Because drawing is an intuitive activity, it frees up my mental

capacity to focus on the content of the model.

Index cards can be particularly useful as they would allow you to rearrange the

concepts. The challenge is that there is not a simple way to connect them

together to represent the relationships, since even string takes a bit of time to get

onto a bulletin board and that will slow down your thinking.

Once you have completed your first and perhaps second draft using one of these

mediums, it is likely that you’ll need to create your model in a digital format for


HOW TO CREATE AN



preservation, sharing, and ongoing updates. At that point, it is advisable to use a

modeling tool. Let’s look at some of those options next.

Graduate to More Formal Tools

There are many, many modeling and diagraming tools on the market today. In

this section, we’ll look at how to use Microsoft® Visio and Gliffy to create entity

relationship diagrams.

Microsoft® Visio

By far, the most commonly used tool is Microsoft® Visio. If you can acquire a

license inside your organization or already have this software, it’s a logical starting

point for creating an ERD.

If you do not have access to Visio, you can download a free trial. That’s not a bad

idea if you will be applying to jobs in the near future, as experience with Visio

could be viewed favorably.

There are a lot of stencil options in Visio. To create an ERD, start with either

Crows Foot Database notation or the UML Class notation, depending on the way

you plan on modeling.

A few notes on using the Crows Foot Database notation:

It is designed to model physical database structures. By default, each entity

has a placeholder for the Primary Key (PK).

To add attributes to an entity, you either need to drag and drop them from

the stencil set or right click on the entity.

To update a relationship, right click on the relationship line and choose the

Set Begin Symbol and Set End Symbol separately.

You can indicate an attribute is required, and Visio will automatically bold

the text of the attribute name.


HOW TO CREATE AN



You can also choose to set and show attribute types in the individual entity

settings.

And here are a few notes on using the UML Class Diagram notation:

Use the “Class” stencil to represent an entity.

You can add new attributes directly by adding new lines inside the entity

box, however there is no part of the stencil to specify attribute types or

whether an attribute is required or optional.

Alternatively, while unnecessary for a conceptual or logical diagram, you

can add a separate member for each attribute.

To model a verb-driven relationship, use the directed association line as

this contains the arrow on one end.

You may need to choose to show multiplicity to expose the multiplicities on

each end of the line. The multiplicities can be manually edited using text of

your choosing.

(These notes are relevant if you are using Microsoft® Visio 2013. If you are using

an earlier version, your experience should be similar but may be slightly

different.)

Included with the course materials are two swipe files, one created using each of

the stencil sets. To use the swipe file as a starting point for your ERD, simply save

the file to your computer and open it using Visio. The swipe files are saved to be

usable in any version of Visio from 2003 forward.

Gliffy

If you don’t have access to Visio or would prefer a simpler, web-based tool, one

option is Gliffy. Gliffy offers a free trial that allows you to create and save up to

five different models indefinitely. Or, you can upgrade to unlimited models for a

modest monthly or annual fee.


HOW TO CREATE AN



(There are many other web-based modeling tools out there that have been well-

received by the business analyst community. I personally use Gliffy for most of my

modeling, which is why I’ve included swipe files and how to information.)

In Gliffy, choose to Create a New Diagram, then choose the Software Design &

UML template to get started. The items in the UML Class library will provide what

you need to model an ERD and capture relationships using a multiplicity notation.

There are actually many more choices than you need.

Stick with the basic entity box called “class” and the basic line called

“association.” To each class (entity), you can add multiple attributes, or fields. You

can delete and ignore the Method section unless you are extending on to more

elaborate and formal UML class modeling. Then, to each end of the association,

you can specify the multiplicity.

Within this same template set, there is also a collection of stencils under the

heading Entity-Relationship, which includes lines to model relationships using

Crows Foot Notation.

With the course materials, you have two Gliffy swipe files to start from as you

create your own diagrams. The first includes the more detailed example we talked

through in this lesson created using the UML class stencil set. The above edits are

already made, so you can begin typing in your own entity names, attributes, and

updating the associations. The second set includes the same example, created

using the Entity-Relationship stencil set and Crows Foot Notation.

To use the swipe files, save the files to your local drive. Once you have Gliffy open

in your web browser, choose File / Import and select the swipe file you want to

start with. Gliffy will open the file and you can edit it as you wish and save a new

copy of your diagram.


HOW TO CREATE AN



Or, Choose Your Own Tool

Microsoft® Visio and Gliffy are certainly not the only tools available. We’ve

discussed them in detail here because Visio is the most commonly used tool and

Gliffy is a tool I personally use and trust, and it’s available for free.

If your organization uses a different visual modeling tool and you have or can

acquire a license, use that tool. If you have your own favorite modeling tool, there

is no reason to change. Just about any decent modeling tool will provide stencils

for you to create a class diagram or an entity relationship diagram, so you will be

able to create models like what we talked about in this lesson.

REVIEWING AND VALIDATING YOUR ENTITY RELATIONSHIP

DIAGRAM Before we close this lesson, let’s consider how to go from a first draft of an ERD to

a reviewed and validated model that is useful to the project team.

When you go through the above steps, you are likely to have a very rough draft of

an ERD and have raised a lot of questions. You might be wondering if you have

identified all of the important concepts, if you’ve identified all of the

relationships, and if the relationships you’ve modeled are correct. Once you

answer these questions, you’ll be wondering if you’ve identified the most

important attributes, if any attributes should be elevated to entities, and if any

new relationships surface now that you understand these lower level details.

Unless you are working on a well-understood business domain, expect this to be

an iterative process. ERDs go right to the heart of a business and they create an

immense amount of clarity about the information that is stored by collection of

business processes and software features. But they do so at the cost of a lot of

collaboration, deliberation, and analysis work.


HOW TO CREATE AN



As an analyst, you are not expected to magically know all of the answers to these

questions, but it often is your responsibility to discover the answers to these

questions. Along the way, you will create a shared understanding of the business

and technical domain among all relevant stakeholders, which will create a solid

foundation for the more detailed data modeling techniques and decisions that

come next.

You can use any elicitation or validation technique to review an ERD, but one

extremely beneficial approach is to distribute your draft (which must be clearly

marked draft) to your most knowledgeable stakeholders, ideally with one person

who can represent each aspect of the business and technical domain. Then, walk-

through the model entity by entity, redrawing it on a whiteboard so that

adjustments are easily captured. This way, your draft becomes a reference tool,

and the team’s collective understanding is clearly documented as you go.

If you’ve included technical stakeholders, it will be important to ask them to first

hold back from wanting the model to represent the database design exactly,

while you first explore how the business-level concepts relate to one another.

Once the business-level, or conceptual ERD, is well understood, you can evolve

your model to a logical model that resolves any conflicts between business

concepts and pre-existing database design decisions. At this point, you can be

sure that the most critical database design constraints are reflected in your

model, but you still will not be modeling the entire physical database in detail.

As you redraw your ERD, expect to add new entities, delete entities (perhaps

making them an attribute of another entity), add relationships, delete

relationships, and adjust the numerical definition of the relationships.

In a complex domain, you might need a few cycles of review to evolve your

conceptual model to a logical model that resolves any inconsistencies between


HOW TO CREATE AN



business terminology and clears a pathway for how the information systems can

support business stakeholder needs.

While this can take a fair amount of time, your work here will pay dividends as

you progress through your project.

For a new information system with a new database, you’ll have a model

that clearly describes how business concepts relate, meaning that the

resulting relational database will meet stakeholder expectations.

For a data migration project, you’ll have a model that clearly describes your

current state and perhaps also your future state, so you can make good

decisions about how to move data from one system to another.

For a system integration project, you will have resolved inconsistencies

between the two systems so it will be clear how they need to manage data

in an integrated way.

YOUR NEXT STEPS Now that we’ve covered the tools you can use to create your own ERD and how

to review and validate your model, let’s talk about next steps.

As you know, real learning comes with practice. Your next step from this lesson is

to practice creating an ERD.

Be sure to practice the following aspects of this technique:

Create at least 5 different entities that are part of one business domain. (A

logical starting point will be to model an entity for each business term you

defined in your glossary.)

Add lines to show the relationships between these entities.

Add detail about the relationships, either by including verbs along each line

or by adding multiplicity information.


HOW TO CREATE AN



Practice listing a few attributes in each entity.

If you are going for a Certificate of Completion, copy your Entity Relationship

Diagram into your workbook to show you’ve worked your way through this

lesson. You don’t necessarily have to use a tool. A picture of a whiteboard

diagram or paper drawing is also suitable. Between 5 and 10 related entities are

required.

Ideally you’ll apply this technique to a collection of concepts you are modeling at

work. But if you cannot think of a suitable real-world example, then you may want

to expand on the job search example we used as an illustration above, or alter it

to represent a specific job board or hiring organization. For example, you may

want to add the concepts of Resume, Employer, Job Board, and at least two more

you think up.

If you are a database developer, you may be tempted to generate an output from

your favorite physical database and call it a day, but you’d be missing the point. A

business user is going to have a hard time understanding a physical-level ERD and

you won’t really be stretching your business analyst muscles to create a

meaningful abstraction. See if you can consolidate your physical model into a

logical model that illustrates the key relationships without actually showing all of

the physical details.

While there is no grading as part of this course, give yourself a bonus point if you

walk a business user through your ERD and use it to explain how a few critical

business concepts relate to one another. Give yourself two bonus points for

presenting an ERD in a requirements discussion and three for drawing one

impromptu on a whiteboard the next time your stakeholders are confused about

terminology.

Now, it’s time to get modeling!


what i ntity relationship diagram › wp-content › ...an entity relationship diagram (erd) is a...

Documents