Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  Entity Relationship Diagram
Previous Previous
 
Next Next
New Post 2/10/2008 1:35 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Entity Relationship Diagram 

I have a slightly different view to Adrian.

The job of the ERD is NOT to model the " physical structure of a relational database" - all solutions (computerised or not) consist of a set of requirements for processes and data.

Why? Because processes manipulate data.

Business Analysts model requirements for processes (not SOLUTIONS for processes) using and process modelling tool they like so long as they show processes and process dependency rules.

They model the data that is logically required by the processes (and therefore not - necessarily - what is physically required) using entity relationship diagrams.

Why not class diagrams? Because they do not have the rigour of normalisation that ERDs do and they presuppose an Object Orientated computerised solution. ERDs do not because all they show are data requirements which may or may not be designed by database designers to work in relational databases, OO databases or (of course) no database at all (no computerised solution).


Data modelling for Business Analysts is about modelling REQUIREMENTS for data (not solutions) and to ignore that aspect of requirements is to ignore at least 50% of requirements - which in my professional experience is what most projects and businesses do.

And we wonder why projects fail!

 
New Post 2/14/2008 9:56 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Entity Relationship Diagram 

I agree with Guy here.  Oncve you start looking at the physical youa re looking at the solution.

THat's not to say some BAs can't adress the solution early, but it's not good practice for anyone who is in unfamilair territory.

And hell, logical ERDs are cool.  Same as logical process maps.

You know when workflow projects are running and work is done to document the 475 current business processes?  They are the physcal ones.  Once you've analysed them there are usually 6-8 logical processes.

 
New Post 2/24/2008 12:02 PM
User is offline sonavi
37 posts
9th Level Poster


Re: Entity Relationship Diagram 

Hello All,

This is in regards to the previous question about Entity relationship diagram. As suggested by Adrian, i have reviewed the code and figured out what the process is and also figured the tables which are being used from the database. i am a little bit confused andI would really appreciate if anyone can clarify my doubts.

1. what is the difference between entity relationship diagram and a Class Diagram. Are both one and the same?

2. The databse which is being used in the application is MYSQL. So does it mean that when drawing the class diagram the Classes are nothign  but those Tables which are being used in the application.

Thanks

Sonavi

 

 
New Post 3/26/2008 2:58 AM
User is offline alignba
2 posts
www.alignba.com
No Ranking


Re: Entity Relationship Diagram 

I agree with you totally. but to put a different slant on it I would like to add a quote from my book “Aligning Business Analysis”

 

“Any relationship can have a set of numbers related to it. In the western world the relationship of marriage has numbers attached: A person over the age of 16 can have only one legal spouse at any one point in time. That is the business rule for this relationship. A soccer team can only have a maximum of 11 players on the field at any point in time during a match. In the long-established tradition of the IT industry, IT people use names and words that confuse non-IT people.

So we find that when referring to the numbers of a relationship, it is called cardinality. There is a notation that can be used for this, but I am not here to teach you how to create an ERD (Entity Relationship Diagram or Data Model). There are many courses that will teach this.

 

The point is that the relationships (and the numbers of a relationship) are in the realm of business. So when we, the Business Analysis Professionals, build models to document these relationships, it is not a technology exercise; it is a business-understanding exercise.

I have been told time and again that the user will never understand the data model. That is hogwash. I have built many data models with users who have had a ten-minute explanation about the notation and what it means. By the end of the day they are arguing with me and between themselves about the content of the model.

 

I can tell you now that if the users do not understand the data model, it is the fault of the analyst. The Data Model is one of the most powerful business rules documentation methods we have. When done correctly and at the right level of abstraction, users understand it and will participate in its creation without hesitation. I do have one trick I use to make them understand that we are working only in the realm of the business; I simply call it a “Business Information Rules Diagram”. That way they understand what I am using it for, which is to establish the Business Rules I need to document.”
 

So the ERD is another tool for documenting the Business Rules or Requirement and the analyst it should be used for this purpose.

Robin

 
 
 
New Post 3/26/2008 1:07 PM
User is offline L M Smith
4 posts
No Ranking


Re: Entity Relationship Diagram 
Modified By Adrian M.  on 3/26/2008 3:54:27 PM)

This is an interesting thread, and one that I might be able to provide some input to...

The logical data model (or Entity Relationship Diagram) is supposed to be a model that describes the primary business concepts and relationship between those concepts from a business perspective; it contains entities, attributes, and relationship described in business language.  Because a fully normalized entity relationship model is very similar to a first cut physical model, many people in technology confuse the two. The first cut physical model is a platform specific implementation of a logical model, it contains tables, columns and referential integrity frequently following the naming and abbreviation standards for that database platform.

Typically logical models are created and maintained by data management professionals with the title of Information Architect, Data Architect, Data Modeler or Data Analyst.

The physical model is maintained by a Data Base Administrator in most shops...and then they move into the actual tuning and denormalization that is required for physical implementation.

There are a number of decent online "self-training" courses for data modeling techniques that a Business Analyst can use to develop solid data requirements which are the input to a data model.  In some shops a BA may do some of the modeling; in others the DA is responsible for creating the data model deliverable. 

In a more object oriented environment, you can think of the entity-relationship diagram as the data structure that documents the relationships between persistent data....

I hope this gives you a bit more clarity about the use of an entity-relationship model  as well as different areas of the data management practice.

There is an organization that supports data management professionals  www.dama.org  as well as an online newsletter that typically includes information on data modeling related topics www.tdan.com.  The certifications for this practice include CDMP (Certified Data Management Professional) and CBIP (Certified Business Intelligence Professional) are administered by www.iccp.org.

Best of luck,

Loretta

CCP, CBIP, CDMP - Mastery level.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Entity Relationship Diagram

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC