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:
- Part 1: Consolidate Some Databases with ER/Studio Data Architect
- Part 2: Document a Database with ER/Studio Data Architect
- Part 3: Reverse Engineering a Database with ER/Studio Data Architect
- Part 4: Document a Database with a Logical Model with ER/Studio Data Architect
- Part 5: Compare Models and Make Decisions with ER/Studio Data Architect
- Part 6: Create New Target Database with ER/Studio Data Architect
- Part 7: Design Data Movement (ETL) with ER/Studio Data Architect
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.
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.
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.
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.
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,