Although data modeling techniques can look technical, you don’t need to know database programming to complete useful versions of the models from a business-facing perspective. 
Instead, business analysts create data models that describe the what (of business requirements), which can be expanded by database designers to cover the how (of technical design).
In this article, we’ll look at the 3 different levels of modeling, describe how detailed business analysts typically get in data modeling, and look how relevant technical details get filled in.
(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)
The 3 Different Levels of Data Modeling
Data models can look very complex, but they can also be completed at different levels of abstraction.
Let’s take a quick look at the 3 different levels of modeling:
- Conceptual Models – Represent business concepts and ideas with no consideration for the technical design. Conceptual models definitely fall under the umbrella of what the business wants.
- Logical Models – Make the business concepts theoretically implementable in a database design, but still may not include all of the details of the physical database structure. Logical models fall right in the intersection of what the business wants and how the solution team will implement it.
- Physical Models – Specify the actual database tables and fields that are created as part of the database. Physical models are under the umbrella of how the database will be designed and implemented.
Business Analysts Stick to Conceptual and Logical Models
Any of the data modeling techniques can be completed at different levels of abstraction. As business analysts, we’re most likely going to stick to conceptual and logical models. And when creating logical models, we’re most likely collaborating with more technical professionals.
For example, while ERDs can be created to model physical database structures and indicate exactly what tables to create, what primary keys to validate, and what attributes belong to each table, those details typically fall to a database architect or developer. However, a business analyst may indeed create a conceptual level ERD to visually show how business terminology, the set of terms that would be included in a glossary, relate to one another.
Similarly, when creating data dictionaries, business analysts commonly create logical models, not physical ones. A logical data dictionary would leave out many attributes and attribute details required by the database design that have no relevance to the business. (We’ll look at exactly how this works in the next section.)
How the Technical Details Get Filled Into a Data Model
While you as the business analyst may not be responsible for technical details, or the how, the project team definitely needs them. Let’s look at how a project team might evolve a conceptual or logical model into a physical database model, using the example of a data dictionary.
First, the business analyst could identify the following types of information:
- Attribute names for attributes required by the business. These are likely to surface in your  functional requirements
- Attribute types, assigned at a high level, which may or may not be the exact type assigned in the physical database
- Whether each attribute is required or optional
- And finally, any notes or additional information important to the business stakeholders that could influence the database design
At this level of detail, it doesn’t really matter if your data requirements will be built in Oracle, SQL, or some other database or data structure.
After reviewing this level of a data dictionary collaboratively with the business analyst, a database developer might identify the following types of information:
- Primary keys and unique IDs required to create a structurally-sound relational database
- Database field names that meet organizational and best-practice technical standards
- Specific attribute types, given the type of database system in place in your organization
- And perhaps a whole lot more that is rather invisible to us as business analysts
A similar process can be followed for any type of data modeling technique, with the business analyst discovering, analyzing, and validating the higher level details and a technical stakeholder fleshing out the complete design.
Let the Business Perspective Guide You
While it’s possible that the tool or technique you are using could theoretically be used to create a physical data model, that does not mean you are responsible for capturing all of the physical level, or technical how details. Whether you create conceptual what models or logical what-how models, you’ll be helping your business make better data-related requirements decisions and smoothing out the technical design process.
At the end of the day, as a business analyst the most important thing you can do is ensure the business perspective informs critical technical decisions. You are responsible for discovering the what and collaborating to help define the what-how, whether we are talking about data modeling or any other technique.
>>Learn More About Data Modeling (Free Training)
Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.
