Author
This blog post was authored by Todd Schraml.
Why Are Entity-relationship Diagrams So Important?
One of the IT-only curse words across the world today is “waterfall.” Usually preceding the word “approach” or “methodology” and followed by a snidely sneer or a loogie splatting the floor (at least metaphorically). Behind the angst is a very real desire to distance an organization as much as possible from such evil shades of the past and jump on one of the many variations of the agile train. Often this agile desire causes malicious thoughts towards any and all kinds of documentation. However, agile does not mean “no documentation;” rather, the desire is for the minimum of necessary documentation. There are even regards for model-driven development. Models that are more pictorial, and as we all know, a picture is worth a thousand words. Entity-Relationship Diagrams [ERD] can be one of the models helping to drive development efforts. In an implementation-neutral fashion, the logical data model conveys many of the business rules and requirements for a given solution. Team members may leverage the ERD and related data dictionaries, which contain definitions of both attributes and entities, in order to understand the business and the scope of the related project.
ERDs follow universal standards for expressing data and relationships. This gives us a mechanism to take streams of business language and distill the structure of the information into a rigorous and robust model that can be later converted into more technical forms. Information about deciphering these diagrams is a click-in-a-search-engine away. ERDs are simple symbolic mechanisms, and when crow’s foot notation is used, anyone may learn to read and understand such diagrams within minutes. The logical data model provides a shared perspective of the data within scope for a given project. Textual definitions must always be vetted carefully to ensure they are as precise as possible. But the symbols comprising an ERD are exact; if the relationship is defined as “one-to-one-or-many,” or “one-to-zero-or-many” viewers should expect the data modeler has established that kind of relationship purposefully.
What Are the Benefits of Logical Data Modeling?
As the shared view, the logical data model serves as a starting point for discussions about the “what” of the project. As the “what” is examined, engineers can start considering more explicitly the “how” aspects of the solution, particularly for anticipated “ugly” areas. There is nothing healthier than a group of project team members looking over a data model and engaging in animated discussions over one nuance or another. Such debates are evidence of an involved team working together to build the best possible solution. Bickering over distinctions between co-pays, co-insurance, deductibles and premiums may sound dreary, but it benefits the overall health of the data model. And resolutions, especially if changes are made to a data model, are far less costly to the organization when resolved before everyone has started building. Without the shared data model to be examined, there is no common launching pad upon which the team may build their thought-experiments. Everyone is left to their own devices and may assume problems will not arise. These solution-focused discussions may not happen until development is underway and significant effort needs to be reworked.
Why Can You Not Skip Logical Data Modeling?
Downstream from the application/lake/mart development efforts, those doing analytics, dashboards and reports often live and die based on their understanding of logical and physical ERDs. These artifacts again serve as the main grist for understanding the nature of the data available. The data models provide important pieces of documentation allowing many kinds of individuals across an organization to learn. It is in sharing this information that tools, like Idera’s ER/Studio and the repository it supports, shine by allowing access to data models and reports. Depending on the status of work efforts, the learning may be what is planned to be built, or what is being built, or what was built. But always, the data model provides insights to those who access it. If no data model were to exist, the information available would be limited or completely non-existent. Certainly, if nothing has yet been delivered, no information is likely available to people outside of the immediate development team. As pieces are delivered, if the data store is a relational database, then the bare minimum of information exists — names of tables, columns, and data types. Probably no descriptive information about the meaning or intention of specific tables or columns will be available. This truncated set of accessible knowledge is largely non-communicative and does little to support the enterprise-wide sharing of information. This is why responsible development efforts should always start with a logical data model so that it can open communication among stakeholders.
Next Steps
Enterprise data architecture eliminates time-consuming manual tasks while improving governance and visibility to deliver maximum value from enterprise data. It enables organizations to:
Manage data across complex IT environments by properly understanding metadata.
Gain insights from enterprise-wide data assets.
Enable robust information governance and data stewardship.
Shape future information technology strategy.
ER/Studio has earned its reputation as the best solution for enterprise data architecture because of its comprehensive data modeling, metadata management, built-in data governance, enforcement of standards and best practices, scalability and flexibility, as well as collaboration and teamwork.
Experience for yourself how ER/Studio can help you use data models to be good business partners by scheduling a product demonstration with one of IDERA’s industry experts.
About the Author
Todd Schraml has over fifteen years experience in application development and maintenance. This includes eleven years focused on data warehousing initiatives and five years experience in database administration on massively parallel processing database management systems. Positions held include Project Manager, Data Warehouse Architect, Technical Lead, Database Administrator, Business Analyst, Developer, and Teacher.
Todd’s focus is on data analysis and design; implementing databases for both operational applications and data warehouses; using new and emerging technologies; and seeking ways to integrate formalized quality practices into Information Technology arenas.
Why Data Model? Part 1: We Data Model to be Good Business Partners
Why Data Model? Part 3: We Data Model to be Efficient Developers