But some others, once we reverse-engineer and have that Model within the erwin, we make changes to entity names, table names and capture metadata according to RBC standards. Some of them, we follow the same templates as they are. Other aspect of the requirement can be from the operational systems where the application requirements might come through as DDLs with SQL extension files where we reverse engineer those files and have the models generated within erwin Data Modeler. This is one aspect of the requirement from Data Warehouse perspective.
Once everything is reviewed, then we go on to discuss the physical Data Model.
Erwin data modeler 7.3 download free pdf#
When we have these Data Models built in erwin Data Modeler tool, we generate the PDF Data Model diagrams and take it to the team (DBA, BSAs, QA and others) to explain the model diagram. We understand the requirements and start building the conceptual model and then the logical model. When we take in requirements, it will be through Excel spreadsheet which is a Mapping Document and this contains information about Source and Target and there mapping and transformation rules. We work on different platforms like SQL Sever, Oracle, DB2, Teradata and NOSQL.
It's things that would take us days to make changes in the standard files and do updates in eight different files. It's all automated at the push of a button.
Erwin data modeler 7.3 download free manual#
The way that you manage it today within erwin is very manual and you'll go from a spreadsheet, make changes, and upload, et cetera- but we've created an API application where if we take the main standard file and keep it in the database, make the changes in the database, then we have an application that goes out into the Mart file, deletes the glossary, replaces it with the table from the database. The other use case that's really important is managing the abbreviations file that erwin uses to convert logical terms into physical terms. Another reason we pull all the metadata out of the model is to run it through our model validation application, which telsl us if this model is healthy or not and if it meets our standards or not. One of them is that we automate the pull of metadata from the repository itself, so that we have all the model metadata that we can then put into a centralized hub that we can access with other applications. We have a couple of really important use cases for erwin. They'll usually just send us either a spreadsheet of names and data types and then we build from there. We go back to any new requests, we'll build them in Data Modeler and we'll go back and forth with the requesters, making sure everything looks like what they're expecting it to. Then, we break down that model into individual subject areas and we work through those. We have our entire network, all the databases, and everything in Model Mart and it's over 1,500 different tables, relationships, attributes, and things like that. My office use case is pretty much the same, except with the office, we add in Model Mart. With that PDF, I'll be able to send it off to all the stakeholders, not just the developers and the requesters, so that everybody can see it, even the ones that don't have erwin itself. Unfortunately, I can't do a PDF straight from erwin so I'll copy everything into Word and then save my Word as a PDF. We'll spend a few days making sure everything looks correct. Once we actually get them to be able to view it and understand it, then we'll go back and forth with the developers and the requesters to make sure that it's exactly what they're looking for. Usually, the request comes in with a whole bunch of tables and names so I'll go into the DM and I'll start building out what they're asking for. When I work from home, my use case for erwin is for when I get a request for a database upgrade.
0 kommentar(er)
