Video : ER/Studio Data Architect

Document Databases. Part 4: Document Databases with Logical Models

The documentation of a database with a logical model is an important step in the database development process for several reasons:

Communication: A logical model serves as a visual representation of the database structure, making it easier for developers, stakeholders, and end-users to understand how organization of the data and how distinct entities relate to each other. This can improve communication and reduce misunderstandings, which can lead to a more successful project.
Consistency: A logical model serves as a blueprint for the database, ensuring that one design it. This is important because consistency can improve the maintainability and reliability of the database. By documenting the database with a logical model, developers can ensure everyone involved in the project is working towards the same goal.
Scalability: A logical model can help ensure that one designed the database in a way that is scalable. This means that one can expand the database as the amount of data grows. By documenting the database with a logical model, developers can ensure one can extend the database without requiring a complete redesign.
Documentation: A logical model can serve as documentation for the database, providing a record of how one designed the database and how distinct entities relate to each other. This can be useful for future developers who need to understand the structure of the database. It can also be useful for compliance, as it provides a record of how one designed and built the database.

Watch this video to discover the steps to documenting a database with a logical model using IDERA’s ER/Studio Data Architect.

Learn the steps on how to use IDERA’s ER/Studio Data Architect to document databases in this video series:

Transcript

Expand

00:07

Database Documentation with Logical Data Models

Today’s video is document a database with a logical model. Today we will be documenting the database with a logical model. We will start with reverse engineering a database, implement some business friendly names to the logical model, and add some additional business terminology markup to the model.

Reverse Engineering

We’re going to start with reverse engineering a database. I’m doing my SQL Server database, going to leave everything as is. Here we have a logical and a physical model generated from my North Wind source database. You’ll see the physical model and the logical model look identical. What I would like to change is I would like to implement some more business-friendly naming conventions on the logical model side. What I’m going to do is I’m going to go over here to the data dictionary. I’m going to create a naming standards template. I have one created, so I’m going to import that here.

01:34

Entity Naming Standards

I’m going to go over to the mapping tab so that you can see we have mapped the logical to the physical side. I’ve got one more that I want to do just to demonstrate how this works. I am going to click OK. Now we’ve got the naming standards template in place. I am going to go back to my logical model. I’m going to right-click here and run the naming standards utility. I’m going to select my template. My logical model is the target here. I’m going to select my entity names because that’s what I will be changing. I’m going to run the translation and you’ll see the output here in the utility window. As I select okay, it’s going to run that utility and implement those changes. Here you’ll see a more user-friendly naming convention in the entity names. We’re going to also open up an entity here and show you some examples of some documentation of an entity within your logical model.

02:55

Entity-Level Documentation

You have the ability to documentation at the entity level as well as the attribute level. As this opens up here, we’re going to go to the Attributes tab again. You’ll see the different types of data here. I’m going to edit this ID field. I’m going to select definition. You’ll see that we have installed a business definition for this particular field indicating that this does relate back to the customer type in another entity. In addition, we have an overall description of this particular entity that this is all customers across the company and products, which makes that customer ID important that it relates back to the type of customer. In addition, we have some security information from our data dictionary that we have implemented and assigned to the entity and then also a data owner here that we have assigned. As we select okay and I enlarge this, you will now see that those things will show in the diagram.

04:07

Reverse Engineered Database

By selecting the diagram and object display options, you have the ability to show the data dictionary items here in the diagram and that is document a database with a logical model. In review of today’s video we documented a database with a logical model we reverse engineered an existing database we implemented a naming standards template to address the logical model entity names and added some additional business terminology markup to the model. If you would like more information you can go to idea. Comcontactsales.

Topics : Data Modeling,Enterprise Architecture,

Products : ER/Studio Data Architect,

ER/Studio Data Architect provides numerous modeling capabilities including naming standards, business data objects, and flexible macros that help data professionals create and document their data models. With an extensive feature set, ER/Studio Data Architect offers superior data modeling for single- and multi-platform environments.

Start a FREE Trial of ER/Studio Data Architect

Contact IDERA:

Contact Sales