Data Modeling for Data Governance

And good day, everybody. Thank you for joining us in this Data Modeling for Data Governance journey. And I wanted to get started by going over the agenda today. First I'll talk a little bit about who I am, for those that do not know me yet. We'll go to the introduction. Then we'll talk about the data-governance practice, data-modeling practice, and data governance supported by a data-modeling practice. And at the end, we will have a demo and, of course, QA as well. So to get started here, just explain it a bit more about how I got here. So I am Andreza Silveira Ruiz. I am a Database Technology specialist. And I've been part of the erwin Sales Engineering team for over six years now. If you haven't noticed, I am not from the US originally. I'm originally from Brazil, and I've been in the US for the past 11 years-- if I haven't noticed my accent. [LAUGH] So, throughout my journey at erwin, I've helped hundred of enterprises and partners to derive value from their modeling solution and also delivered several hours of training on the erwin DM Solution to different enterprises across the world. So I've got a little bit of experience with erwin Data Modeling, and I will go through some of that with you today. So I wanted to do a quick introduction by talking about our first English dictionary that was created in 1604. So, many years ago, we had a schoolteacher named Robert Cawdrey. And he had a very interesting idea, very similar to what we are doing today. New words were being developed for the English language every day. So he noticed that we had a need to start cataloging and documenting those words. So he put together a list of words in a specific format, with a list of abbreviations signifying the word origin along with definition for the word, to help promote understanding and word usage among English-speaking people. Even though I'm not originally an English-speaking person, I do understand the need for us to develop this type of documentation that can help us, from this point forward, understanding better the concepts and the specific words and meanings that we use throughout our life, throughout our language, and also throughout our enterprise, as well. So, just like that, we need to now develop an understanding of the vast amounts of data stored in our numerous business-application system employees still need to rely on. To understand better those application systems, we need to rely on static documentation. So we document something within our environments, and then that documentation gets stale very quickly. As we know, data is growing exponentially today, so we don't have a way to keep up with it. So even though we have documentation of things we do within our environments, that documentation is very static. We rely on time in that position. So your employees will know more as they progress within the position, as they are within that position for a specific length of time. However, whenever they go into a new field or whenever you no longer have that person there, all that experience and all the knowledge they have is gone. And if you don't try to document that in a way that can be passed along to other people, you're going to lose that documentation that was based on the knowledge that that specific person had. Also self-investigation. Some of the documentation we get is from self-investigating how things were created or how things are being done. And that's also something that is not very reliable, because we cannot understand sometimes how things were created, and then we have a hard time now knowing exactly what it means. And of course, peer-to-peer learning, when you learn from other users. And there is a interesting experience with monkeys-- I'm sure everybody has heard of it-- where, if you have a monkey, and you put a group of monkeys within a room, and you put a number of bananas on top of a table within the room, and every time that a specific monkey goes and tries to get that banana then the other ones are going to get showered with very cold water. So for the first times, the monkeys are still able to go there and get that banana. But after some times that the other monkeys get showered with the very cold water, they start beating up or trying to prevent the other monkey to get the bananas. And they continue to do that, until they do not allow that monkey to get the banana at all. But the interesting thing is that, after some time, on the experience, they start switching the monkeys. They switch the monkey that was getting beat up and put in the new one there. And the monkey goes in, tries to do the same thing, tries to pick up the banana, and the same thing happens. They go and they beat up that monkey, and then a new one comes in, a the monkey comes in. And they start replacing the monkeys, but they continue to show the same behavior. Right? They continue to beat up any monkey that tries to get the banana, even though they don't know why they are doing that. They never got showered with the cold water, before, but just because that's the way they did it when they got there, they continue to use that same behavior. So, the same thing with us. When you learn from other people, of course, you're going to learn the way that person learned, and you're going to learn the way things are being done now. You're not going to really know what was the origin or what started that behavior, and if that is still a need in today's date. So that's just an experiment that was done that shows how we start doing things-- or we have behaviors that we get from other people, that we don't even understand why we are having that behavior. So that's what happens when we get into a system that is already in place and we don't understand exactly how things got to that point and how are we going to interpret that, moving forward. So the real challenge is having a system that can provide today a method for us to quickly gain understanding about corporate data assets-- consistently share this understanding with our employees. So even though you have a system to understand that knowledge-- so you might have an IT department that understands exactly why they are creating that database in a specific way. However, if you're not able to share this understanding with other employees or with the whole enterprise, it's going to be very difficult for the other users to understand that and also be very difficult for the IT team to understand the point of view of other employees as well. We need a system that also contributes to the process improvement, so we can improve our process based on the challenges that arise. We also need to increase the quality, identify opportunities to eliminate data redundancy, and produce other great groundbreaking ideas, of course. So if we have a better understanding of the data and how the data is created, or how our data assets are defined-- who has access to our data assets-- then we will have ways to increase the quality. We'll have ways to produce other ideas and to improve the process. So the solution for that is, of course, data governance. Right? So what is data governance? Data governance is a subset of IT governance that will focus on establishing processes and policies around managing data as a corporate asset. So data governance is a framework that will allow the information to be shared and to be documented within your enterprise. So you're going to establish specific processes and policies that will facilitate that. So "data governance" refers to the overall management of the availability, usability, integrity, and security of the data employed in an enterprise. So we will have rules and processes around what type of data is available, and to who who is using that data, where the data comes from, and who has access to the data. So this is all rules that will be important for us to understand who has access to our data and also to make the informed decisions about the data we have. And also data governance provides the structure, resources, and processes necessary to manage data with the big picture in mind. Exactly. So when we are doing data governance, we are not focusing on how one specific department is using the data, but we are focusing on the big picture of the whole enterprise. That's where we take into consideration regulations, specific policies, or a specific type of access we need to provide and who has that access. So the benefits of data governance. So some of the benefits of the data governance is a better business decision-making, due to precise corporate data that is consistent and uniform on all levels of the organization. As I said, we need to have good data, so we can make better business decisions. So, before, data was something that was only important for the IT team. And the IT was worried about metadata and where the data's coming from and what is the quality of the data, and also the IT department would make all the decisions about how we create the data. Today, we need to make that a company-wide responsibility. So everybody needs the data, to make decisions. So when we have a data-governance framework in place, we can make better business decisions, because our data is better. Right? Central control with standards optimize the costs of other data-management processes. Increased compliance with government and industry regulations-- of course, we have heard of millions and millions and billions of fines that some companies have gotten because they are failing with the compliance of specific policies from government and industry regulations. Also, data governance makes it processes more efficient, agile, and easier to scale, because of defined rules for changing procedures and data. Of course, things are changing all the time. So you need some rules and processes around how that data is going to be shared and how it's going to be changed, as well. More efficient synergies through reused data and processes. Of course, we don't need to be reinventing the wheel every time we do something, so we can definitely reuse some standards to help us do it better and quicker. Right? Documentation for data processes results in higher data quality. Of course, when you have good documentation from the beginning, you will understand better when that data gets to the final consumer. And internal and external data are more secure, because of tighter privacy policies monitoring and enforcing that data-governance rule. And transparent roles and responsibilities. So those are all benefits that you get from having a data-governance framework in place that is now something that is good to have, that is actually a need, in order for you to be able to have access to your data and to understand better how your data is being used. So the goals of data governance are-- enable better decision-making. Of course, as I mentioned, we need to understand the data, in order for us to make good decisions. Reduce operational friction. Protect the needs of the stakeholders. So your stakeholders will have better access to the data and will understand exactly what they need from the data. Train management and staff to adopt common approaches to data issues. So whenever something happens, you know exactly what type of measurements or what type of actions need to be taken, because you do have a data-governance framework in place. Also build standard, repeatable processes, so that will help you also not having to redo things and recreate things every time they happen. You have a repeatable processes to go from. And reduce costs and increase effectiveness through coordination of efforts, and ensure transparency of processes. So those are all some of the goals we have, when we put in place a data-governance framework. And in order to achieve some of those goals, that's when the data modeling comes into play. So we use data modeling to help us organize, document, and understand better our data when we are creating it. So data modeling allows an organization to work out a plan before offering it up to users. So when the IT team is creating that database or that specific application, they are able to document. They are able to organize it, define it, and work out any issues before it's actually available to other users to access. When you do this, you're going to have a better-quality data. You're going to understand your business requirements better. You're going to have more robust design elements. You're going to have consistency across projects, because you have documentation that can be used that can pretty much be reused and can be standardized. You have better data quality, as I mentioned. Also, you have lower maintenance, reuse of models-- so you can set up specific models that are going to be reused to promote standardization. And you have improved performance, of course, because you are not going to be recreating things every time. So your users will have a quicker startup on the project. And quality management. You can manage specifically how you want to design that environment, to have better quality. So it's accepted that the right way to design a relational database is to take time for modeling-- do the analysis, understand the challenges and risks, and work out the what-ifs before ever showing that database or offering it up for use. So when we go through all those challenges beforehand, we are able to determine who has access to that data, we are able to determine the type of data we're going to be using, and we are able to design our systems and applications in a way that is the most secure and that promotes better data quality. Getting a little bit more into the data-modeling practice, we have here three types of data models you can create. We have the conceptual data model. That's where you're going to focus on business requirements and business processes and rules. That's the moment that you're going to listen to your business people or your business users or stakeholders that are asking you to create that environment. So that's usually at the beginning phases, when you are focusing on gathering your business requirements and understanding the processes and rules that are going to go around that environment. From there, we can move into the actual, logical data model. That's where you're going to start adding all the data types, and you're going to do the process of normalization. So we take all of those business requirements and all of those processes and rules, and we try to create that within our logical data model. We try to infer those specific requirements and use that as part of our normalized data model. After you create a logical data model with all those normalized business requirements and all the processes and rules being incorporated within that logical data model, we can then create our physical data model from it. So on the physical data model, it's going to be technology-specific. So at this point, you're going to choose which database technology you're going to use or which vendor you're going to use. And then you're going to generate those physical data objects according to that specific database technology. At this point here, you're going to set up your primary- and foreign-key views, indexes-- all of those will be created within the physical data model. That's when you're going to make your more technical choices. So as you can see, on the first two phases here, we are more focused on business requirements and what the business is looking for. So that's the moment that you are going to work out any communication issues with the business side. And that's one of the biggest advantages of doing logical modeling, because you can paint a picture to the business users so they can understand exactly what you're trying to do, and then you can clear out any misunderstandings. Most of the issues that come through when you're not doing data modeling is exactly that you create things that you're not sure if that's exactly what the business user or the stakeholder is looking for. And when you are doing data modeling at the beginning, when you are gathering those business requirements, when you are gathering those business processes and rules, you can definitely paint a picture to your users and show that to them, which will make it much easier for them to understand why you are trying to build and then being able to tell you exactly what else they need, so you have better design on your environments. So when you get to the physical data model, you have something that will attend the needs of the stakeholders and the business users. So let's talk about the role of modeling and data governance. Data and process modeling best practices support the objectives of data governance as well as good modeling techniques. Inadequate documentation and audit practices can result in bad business, definitely, as well as jail sentences. So we need to understand the meaning of critical business data. We need to trust the accuracy of the data, know its source, use it correctly, value and engage the data stores-- both business and technical. So those are some of the rules we need to keep in mind of the goals [INAUDIBLE] that we need to keep in mind when we are doing modeling and data governance as well. So we use data modeling within data governance, to help us achieve those goals of understanding better the data and understanding its source and use it correctly. Now, going more into a practical space, some of the data-modeling practice that we can use to support a data-governance initiative here is, first, a model theme. So we can use themes within erwin Data Modeler that can help you standardize on the way your model looks. So if you go into your Model Properties, you will find the Theme Options. That will allow you to set up how you want your defaults to look like, how you want your names to look like, which color you want on specific primary keys and views, and so on. So that will support developing a standard look and feel for your data-model diagrams, which will include font size, color, object shape, frames, and et cetera. So that will give your model a standardized look. You can set all diagrams to use a default theme, by specifying a theme in the model level in the Model Properties dialog. So you can set this up, and I'll show that within the demo-- how you can set this up to support standardization. The next practice we can use is domains. In erwin Data Modeler, a domain object is used to identify a category name that includes other metadata to support consistency across attributes or columns in the data model. So, with domains, you can set up a set of attributes and properties that you can connect to a concept. So, as an example-- first name, last name, ID. You can set up specific properties that will be used whenever you are using one of those objects. So I'll show you that in a demo, as well, but what you're going to do is assign a domain to an object so the domain can inherit all those properties you set up ahead of time. So, business attributes as well as physical column objects can be associated to a domain object to inherit all the metadata properties defined. Next thing we can use to support a data-governance initiative is user-defined properties. User-defined properties are flexible ways in which a data modeler can add new attributes to virtually any erwin Data Modeler object. So UDPs are properties you can create to store specific metadata. Those UDPs can be created within any level of object within erwin, so you can create that on your table level, entity level, attribute level, model level, or any object. So that will allow you to classify or further or add additional information about any objects. These UDPs can be used to populate pertinent metadata values to a data-modeling object, above and beyond the metadata properties available in the standard out-of-box metadata storage capabilities in erwin Data Modeler. So, besides all the properties we already have for the object, you are able to create additional properties using the UDPs. And next here we have Naming Standards. So Naming Standards is an object in a model that will enable you to translate business names from the logical or business view of a data model into abbreviations to the physical side of the model. So as you can see here, under the Words column, you can find all these spelled-out words. So what erwin does on the Name Standards is look into those words on the logical side of the model. Then, if they find a match, erwin will then abbreviate that same word on the physical side. So, if on the logical side, you type in "customer" to a table name, erwin will automatically translate that into "Cust" on the physical side. OK? So you can manage those options directly through the Naming Standards glossary. So that's a glossary of terms that are added to establish an abbreviation to be used as the corresponding physical-object word in the physical implementation of the data model. From a data-governance perspective, when developing a business-data glossary, data-governance personnel can review the definitions as stated within the context of the application system to formulate the definition of the glossary term. So here we're going to manage the abbreviations, from logical to physical. But it's also important to look into building a glossary that will actually, from a data-governance perspective, you manage the definitions as well of those objects. So that, this way, the data-governance personnel can understand better what each one of those words mean within the data model. And now let's get started with our demo. So I'll be showing you some of the concepts we talked about earlier. And let's start by talking about model themes. So as you can see here, I have a specific theme set up, that I have some of my keys that are in red. Also, erwin has a very cool feature, that you can hover over the relationships and we will highlight the keys on both the parent and the child key. And you can manage the color of that, as well. So in my case, I have it in pink, but you can have it in any color as you like. Within the theme-- So let's go to View, Themes. And here you can create specific colors you want on your primary keys, like I have here are my foreign keys. You can also set up specific font options, fill options, line options. You have all of those options available for you-- entities for your attributes, for your keys, as well. So you can set up a different number of themes here. I would definitely recommend you do this within a template. If I have time, I will talk a little bit about templates as well, because they are very important when we talk about standardizing our set of attributes and our set of properties. So one thing here is to make sure you create those themes within your templates, so everybody can connect to those templates and pick up those themes. So you can set up a set of different themes. So let's say I wanted to change one entity. So you understand, those themes, they are available to all object levels. OK? First you create those themes here. And then you're going to select which specific level we use that. So if you go to your Model Properties, you are going to see here-- if you go under the defaults, you'll find that I'm using the StandardTheme. So that's where you get all those-- the blue color, the back, and the red option-- the red keys, here. And as you can see, I have also the pink color here, as well. However, if I want a specific-- let me go in this one-- see, those are already changed. So if I go into my Entity Properties here, and I go to Style, I can select then a different theme from what I have in the model. So let's say I want to give that one a default theme or a classic theme. So you can see, I'm changing the way that looks like. OK? Same thing here. Let's go to Royalty History, as an example, and see Properties-- Style. Then I can select a different theme. And if I do that, as you can see here, I'm changing this from the theme I had with my StandardTheme to my Classic Theme. So I can do that within each level, as needed. So you can manage the themes and the specific properties, as needed, here. Also, if you change a theme of an object on a table level, here, or an entity level, those themes will be carried over throughout the model. So if I have, as an example-- let me look for the Book object. If I go into the Book object, and I select the Classic Theme for it, even if I go into my Subject Area my Book object will also be following that theme. OK? So that's a question I always get. What is the difference between just having a theme and doing what we call an "override"? So I can override the styles. OK, so if I override the styles for the theme, then I can make a change here, but that change will not be propagated throughout the model. So when you change the theme of the table or the entity, that is propagated when you just override this style and add your own color to this one, then that will not show up on the other places within the model. OK? So let me head back to my logical, here. So that's how we can leverage themes to standardize the look and feel of our models. OK? The next thing I wanted to talk about is Domains. Domains is a set of properties that you can create, that you can predefine. Right? So, whenever you create a new object or either a new attribute or a new column, you can assign the attribute and column to that domain, and then that object will inherit all the properties set up. So let me give an example of the "first name" domain. So the "first name" domain-- I can set up a domain parent-- in this case, a string-- and also a logical data type. So if I create an object or an attribute or column within my model, and I then add the "first name" domain to that object, that column will pick up the name of my domain, according to what I have set up in Attribute Name. And I will show you guys that in a second. It also will pick up the domain parent and the logical data type. OK? So everything I connect to the "first name" domain will be a VARCHAR(20). Another thing we can do here is manage the naming. As I said, I have a macro here, which is Attribute Name, which is "%AttDomain." So this is the name of the attribute domain. So if I create a new field and I assign that "first name" domain to that field, the name of that field will become "first name," according to what I have here. However, we are able to modify this. So let's say I want to add the "%EntityName" placeholder, here-- or macro. What this does is pick up the name of the entity. OK? So, whenever I create an attribute and I connect the attribute to my "first name" domain, the attribute will pick up the name of the entity, followed by the name of the domain. OK? I will show you guys that in the example. Next thing we can do is set up a definition. So when you go to the Domain Definition tab, you can find two places here. The first one is for the definition of the domain. So I can add, here, this is a domain-- "This is a set of properties for first name objects." This is the definition for this domain. However, I'm able to define a definition that will be inherited by my attributes. So this is actually going to be the definition I want to be used by my attributes that will be connected to the "first name" domain. So I can add, here, a definition for "first name"-- "The legal first name of"-- and then I can pick up that same "%EntityName" object. So I can add, here, "The legal first name of"-- or "for"-- better-- OK? So that is the definition I want my attributes that will be connected to my "first name" domain to pick up. I also am able to inherit UDPs. So I can create-- We haven't talked about UDPs yet, but you can create UDPs within your domains, and those will be automatically inherited by the columns or attributes connected to that domain. So again, if you create those UDPs here at the top, those UDPs will only work for the domains. If you create those UDPs at the bottom field, then those will be inherited by your attributes. So I'm going to hit Close, here, so I can save this. So I save those changes to my "first name" domain. So now I'm going to create a new entity. And let me call it "Prospect," actually. So let's say I'm creating a new table here, and it is a Prospect table. I need an ID. So I'm just going to drag and drop the "id" one here. And then I need a first name, of course, so I drag and drop that first name there. As you can see, when I drag and drop that first name-- let me zoom in a little-- as you can see, when I drag and drop that prospect, first name, automatically we can see that it picks up the name. So it picks up the name from how we set it up on the domain. Remember, we set it up that you should pick up entity name and attribute domain. OK? So, by default, we will pick up that entity name, followed by the domain name. So we have "Prospect first name." We also pick up the data type. Right? So I have it there as VARCHAR(20). Here it's going to be VARCHAR(20). Also, if we go into the definition, you can see here that also we picked up the definition for the object. So you have "The legal first name for Prospect." Remember, I was picking up the entity name here. So I have "The legal first name for Prospect." And also we pick up the UDPs, as well. OK? So if I go into my domain-- so let's say I go into my "first name" domain, and I change this from VARCHAR(20) to VARCHAR(25), and hit Close. When I go back to my Prospect first name, it automatically are going to be changed to VARCHAR(25). So we have some inheritance that is set, here. You are able to break that inheritance. So if you want, you can click here, and then you can either Override or Harden. So if you Override, you're no longer going to pick up the name from the domain. Then you're going to break that inheritance, and whatever you type in here, that's what it's going to be. However, keep in mind that, if something changes on the domain side, then you're not going to pick up from the domain any longer. So as I did here, that I changed the data type on the domain, and then everything that is connected to the domain got changed, that won't happen if you break the inheritance. So keep that in mind. If you're coming in and make a change directly here, instead of "25," I type in "30," this one will be "30." But if I change something on the "first name" domain, after that, this object will not pick up that change any longer. So if you want that to pick up again, you have to come here and set it to inherit again. Or you can reset the inheritance as well directly here, either for only for the Prospect first name attribute. You can reset the inheritance for all attributes of Prospect or for all entity attributes in the model. And then you can define, here-- it's a little bit small. Let me see if I can make it bigger. You can define, here, which properties you want to reset the inheritance to. So if you change the name manually, if you change the data type manually or the definition manually, the domain parent manually, make sure you set those properties correctly here, so you can have those reset to start picking up from the domain again. OK? So that's pretty much how we handle the domains. I also highly suggest you add that directly to your templates, so you can pick up directly from the templates. OK? Next thing I wanted to talk about now it's UDPs. I've talked about them a little bit already, but I wanted to go into more details. So if you go into your User-defined Properties menu, here, or User-Defined Properties Editor, you'll be able to see the different classes you can add UDPs to. OK, so right now in the model, I don't have any UDPs for the model. However, I can add UDPs to pretty much any level. So let me go into the entity level. Then you can see that I have here a number of UDPs. You can do UDPs as list, such as the one I have here. I've created a Data Steward UDP. I created that as a list. And then I have a list of data stewards I can select from. Whenever I put this tilde in front of the name, I'm making that name the default. So every time you create a different entity, that entity will have "Stacey" as the default data steward. OK? I can create different types of UDPs, such as integer in case I want to use numbers, text in case I want to just have free-flowing texts, date, commands, real numbers, or lists. So those are the different types of UDPs you can create. And those UDPs will be across all of those objects. So if you go into an entity, you are going to find that UDP. You are going to find the list of data stewards. You can navigate through the entities, to document who is the responsible data steward for that. OK? Also, you can report on those information afterwards. So if you want to run a report that will have those properties in, you can go into-- I'm not going to go over this now, but you can go into the Report Designer and you can build a report that can show you who are the responsible data stewards for all your entities. OK? So keep in mind that all that documentation adding can be reported on. And last, here, I wanted to talk about naming standards. So as you can see, my logical and my physical side is all spelled out. So I don't have any abbreviations in place yet. So in order to fix that, I'm going to go into my Naming Standards. And I will go into my Naming Standard Properties. I can go from the [INAUDIBLE] Explorer, or I can come here-- Tools, then Naming Standards. That's where I have my glossary. So as you can see here, I have my spelled-out words on my left, under Words. And that's where erwin will look for on the logical side. And whenever it matches in the logical, it will automatically abbreviate that on the physical side. So every time we find "customer" on the logical side we will abbreviate that to "Cust" on the physical side. We are also able to do the opposite direction. So when I click on Is Active, I'm actually doing logical to physical. When I click on Physical to Logical, I'm going to do the opposite. So when you are reverse-engineering existing databases, most likely you're going to need to document that on the logical side. So if you want to spell out those on the logical side, or [INAUDIBLE] the opposite, that action here. And then we will look for "Customer," and we'll look for "Cust." And whenever you find "Cust" on the physical side, we will actually spell out "Customer" on the logical side. So you can either go from logical to physical or from physical to logical. This case, here, I'm just going to do logical to physical. So whenever I hit Close, we will search for "Customer" on the logical. And then, if it finds it, it will automatically translate to "Cust" and same thing for all the other ones here. So I hit Close. And as you can see, the whole model got abbreviated accordingly. So I have "Cust," first name, last name, all abbreviated according to my glossary. Another thing you've got to look into is the identification here. This is not on my glossary. OK, and that was on purpose. I left that off on purpose. So you can see that, if something is not on my glossary, that will be left alone, here, as is. We're not going to touch that. However, we are going to touch this [INAUDIBLE] here. OK? Another question I always get about naming standards are the model-naming options. If we are able to leave those underscores, or we can just have them with no space or replace with something else. Yes. You can manage that here, under Model Naming Options, Name Mapping. Then you can see here Special Characters. In my case, I have it on Leave, so that's why you see the underscores there, because I'm leaving the space and then automatically add underscores. I can also remove that space. So if I click on Remove, then we remove all the spaces. So, removing all the spaces, of course, all the underscores also disappear. I also have the option to replace it with something else. So if I want, instead of the underscore-- I would like to have, let's say, a dot anything else in between those-- I can use that. And then we use that dot instead of the underscore. OK? So you are able to manage how you want that to look like. If you leave these spaces, then we will automatically add underscores, to replace that space. OK? Another thing about model naming options I wanted to talk about is the Macro Toolbox. So if you remember, I picked up that "%EntityName," and that's where I picked up from. We have a number of set macros that you can use, to pick up either entity names, entity ID, and a few other things. You can do that actually here. So we have a number of entity macros, relationship macros-- so "%Child" will pick up the name of the child, "%Parent" will pick up the name of the parent, and so on. So you can use those, here, throughout the model, to pick up metadata and to help your documentation. OK? You can also create your own macros, as well. What I wanted to show you here is, as an example, on my relationships, I created this naming standard, here, which is "FK," underscore, "Parent," underscore, "Child." So this is going to create a standard for my physical names, that they are all going to be "FK," underscore, the name of the parent, underscore, the name of the child. So let me take a look on that and show you. So if I go into my relationship, here, you'll see that all my relationships are following that [INAUDIBLE] specific standard I have-- "FK," underscore, the physical name of the parent, underscore, physical name of the child. OK? So that's how we can manage naming standards. You might be asking how you can bring those standards or those glossaries in. There are two ways of doing it. First way is just creating-- Let me create a new one, here. You can create a new one by just creating a word, here. So let me do a test-- "Test"-- and then abbreviation "tst," as an example. OK? Then you're going to save this as a CSV file. You're going to save that as a CSV. You're going to use that as a template, so you can just import all the other words you have into that CSV. And then you can import that, with all the words you have, back in here. So that's one way you can view that specific glossary, if you want to bring it in from CSV. Another way is, in case you have the Workgroup edition-- if you have the Workgroup edition, which is the central repository of erwin data model of the enterprise solution for erwin Data Modeler, you're going to have a central repository. Within the central repository, you are going to have the option to create those glossaries. OK? So instead of creating the glossary within each model, as we did here, you can create the glossary within your central repository admin UI. And then when you create that, the same way you created earlier, you can create a sample one and then download that and then bring that in. OK? Same thing I did there, you can do here. Then you're going to have the words and abbreviations. You can then apply those directly into your models. So you will just select the model you want to apply the naming standards to. And then whenever the user opens up the model here, they'll be able to see that glossary, there, and the glossary will be automatically activated. So that's another way you can manage those glossaries. Another way of managing it is through the templates. So you're going to create those in the templates instead of creating each model. Some people like to keep those and manage those within the Excel, and then just bring in, whenever they need to, directly into the model. Other option is to manage them directly on the template. So you can set up those glossaries within the template, and then the users can go in and bind to specific templates whenever they need to. OK? I won't have time to go over templates today, but I definitely recommend you click on the Help, Help Topics, if you erwin Data Modeling installed. And then you look for templates within our help. You can either type in here, to get the result. And then you click on that template and learn how to do templates. Because that's going to help you a lot with the standardization. So I can click on "Bind a Template to a Model." You're going to find step-by-step instructions, here, of how to do that. And that will help you standardize throughout your modeling practice and through all your different models. Great! Thank you. I thank everybody for the time-- looking forward to hear anything from you guys. If you have any questions or if you have any comments, reach out to us and we'll be glad to help you. Thank you, Andreza. Just a reminder to everyone-- I will send a link to this recording by the end of this week. And then also, if you haven't already registered, the next session in this series will be October 19. I will send a link to that registration page, along with a link to the recording. With that, we are at the end of today's session. Thank you all for joining.