 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor for DataVersity. We would like to thank you for joining today's DataVersity webinar, Big Challenges in Data Modeling, Top Data Modeling Miss. Sponsored today by CA Technologies and Sandhill Makers. This series is moderated by the esteemed Karen Lopez. Just a couple of points to get us started. Due to the number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section. Or if you'd like to tweet, we encourage you to share highlights questions by using hashtag BCDModeling, Big Challenges in Data Modeling. And as always, we will send a follow-up email within two business days containing links to the recording of this session and any additional information requested throughout the webinar. We are very pleased to introduce to you the moderator for this webinar series, Karen Lopez. Karen is Senior Project Manager and Architect at InfoAdvisors. She specializes in the practical application of data management principles and Karen is a frequent speaker, blogger, and in fact she has a blog on DataVersity and is a panelist on professional data issues. She is a Microsoft SQL Server MVP specializing in data modeling and database design. She is an advisor to the Dama International Board and a member of the advisory board of Zachman International. And Karen wants you to love her data. Karen, this month our three esteemed guest panelists, please welcome Terri Moriarty. Terri has spent a third of her career as a developer, third as a data architect, and a third as a business rules architect. She has successfully understand an organization's business information management requirements and the dependence between these three aspects must be exposed, explored, articulated, and balanced. She experiences this through the use of metadata management methodologies and environments. And joining us this month is Dr. Daniel Moody, Dr. Daniel Director of OSMAX, a Sydney-based information management consultancy firm. He holds a doctorate in information systems from the University of Melbourne and has held senior positions in some of Australia's leading corporations and consultancy firms. He has conducted consulting assignments in 12 different countries covering a broad range of industries. He's a developer of Dama and received the 2013 Dama International Achievement Award. Congratulations on that. But certainly not least, please welcome Larry Burns. Larry has worked in IT for more than 25 years as a database administrator, application developer, consultant, and teacher. He holds a BS in mathematics from the University of Washington and a master's degree in software engineering from Seattle University. He works for a global Fortune 500 company as a data architect and teaches a series of data management classes for application developers. He's the author of the book, Building the Agile Database, published by Technics in 2011, and writes a feature column for tdm.com. So please welcome Karen and our panelists. And with that, I will turn it over to Karen to get us started. Hello and welcome. Hi, thanks, Shannon. That's great. Thank you, Shannon. And I should also mention Tony of Data Diversity for making these webinars happen and for doing so in a very open manner where we have the chat where audience members can talk with each other, make some commentary. We can all see that, by the way, as well as the formal Q&A. As Shannon mentioned, make sure that if you have a question or a burning comment, put it in the Q&A. We do try to monitor the chat, but there's a lot going on there. And don't wait till the end to put your question in. Ask them at any time. The next topic is one of my favorite ones, which is MIPS in data modeling. It's very related to one of my oldest and most popular presentations, which is Data Modeling and Contentiousness. And in the last one I talked about, so the same thing that applies here, is why are we talking about these things? Well, in the 30 plus years that we've had data modeling and data architecture around, probably even more than that, we still have a lot of urban legends and myths that are being passed around, especially in the data architecture community and the data modeling community, but also with developers, DDAs, managers, project managers. We should be continuing to discuss. I've tried to pick some questions and topics here that aren't totally logical or totally false or totally true. And the way that I picked them is I wanted to make sure we have a good discussion there. One of the things I'd like for our panelists to do is to tell me and whether or not they think it's totally true or not. Now, for this presentation, there aren't slides. I do have one slide for categorizing things, because we want to categorize things. Audio and panelists for this. Having said that, I'm just going to turn off my webcam so you don't have to watch me multitask. To get to tweet, again, the hashtag is BCDataModeling. But I'm going to do... Oh, and I'm going to bring our sponsors as well for making this happen. And you can see the sponsor there with CA and SAMHSA. So what we're going to do next to do about the myths today are enterprise data modeling, add data modeling, the nitty-gritty details of data modeling, and some presentation and format, and then some other things. We're going to start with the ultimate myth of enterprise data modeling, which is if enterprise data modeling is dead or dying, this is probably one of the most contentious ones. And so I'd like to start with asking you, Daniel, is enterprise data modeling dead or dying? Go. Oh, that's a good question. That was not in the script, Karen. Oh, I mean, I might have... Well, enterprise data modeling, I think, is even more important than it's ever been with more global organizations, more of these issues of acquisition and mergers. And this has become a common way that companies grow. So enterprise data modeling has given itself a bad name in that people tend to not know where to stop. The value in enterprise data modeling is this 80, 20, or even 90, 10, where you don't try to go into too much detail. But I think it's very difficult for people who've been trained as data modelers and come up with normalization and getting defining data to the utmost detail. If you try to apply that at the end, you'll never finish. And now for this paralysis, you have a lot of money and the project gets canned. So the need still is there, but I think it's quite a difficult thing to do. And so there's a contradictory skill for the, you know, kind of traditionally trained data modeler. Okay, good point there. Terry, what do you think about this? Well, they're at a rather large scrimmage agency and they have enterprise data organization. They do have an enterprise data model. They have to do a lot of data sharing across their organizations. And so I'd say that's probably a reason for why they are doing it. And I think it would be great to be working on a very little bit of that big, huge organization. They forgot about us completely and didn't have to include most of our information, and we're trying to get that in there now. But at least understand that there are a lot of enterprise data that shares data. Is that governmental? That's the answer to this question, since it's technically not for profit, or do you think it's because they're large and complex? I don't think it's because they're large and complex. Good answer. Larry, you work for an enterprise company. Is enterprise data modeling data dying? I don't think so at all. Certainly, I think we've gotten past the idea of eating the entire elephant at a single meal. Not only everything that we do has to be informed by some sort of overarching architecture and design, other ways we're just randomly in all directions. But I think that what we do at the enterprise level needs to be done in an iterative fashion, an incremental fashion. We are part of large-scale projects and initiatives. Right now, we're doing EPA Greenhouse Gas Compliance work, and that touches most of our systems and most of our big processes. So we're working our enterprise-level data and process modeling into that initiative, and then later on, as we're doing replacement of legacy applications, we'll be doing more of it. We're still doing enterprise-level data and process modeling, but we're doing it incrementally as part of ongoing projects. We have a three-year project to go out and model every single thing in the company, and then do IT work? No, and it wouldn't be really practical to do it as rapidly as things change in our industry. Okay. So it sounds like all of the panelists have said that no enterprise data modeling is not good, but why do we hear that so much? I hear a lot. I hear that data modeling in general is dead, but definitely that enterprise data modeling is dead. So I'll bring this up to anyone who wants to speak first. All right. I'll take a minute and say that I think a lot of people don't understand or misunderstand what data modeling is, and they don't understand the value that it can contribute. In particular, I don't think people understand its value in bringing together a lot of different stakeholders and collaboration among stakeholders, drawing people towards agreements on important business requirements. People think data modeling as something that's only relevant to data people that the data gnomes do in their little cubicle or their office, and we need to bring data modeling out into the open, bring it to the table with all the stakeholders in a project present, the business analysts, the business users, the project managers, the developers, and use data models as a tool to drive consensus and agreement on critical business requirements. Then people will see the value that data models bring to any sort of initiative or over. Thank you. I think it sounds like that just takes a whole lot of time, and we don't have time for that. So we'll move on to the next myth, is that data modeling just makes projects take longer. Myth or theory? Okay. I was going to jump in. I think it is a myth that data modeling is like data analysis and understanding your data takes a lot of time. And it's a design line, not the problem, usually. So that's still, and that, to me, is actually helpful for people who are visual because trying to understand those relationships through an actual spreadsheet is almost impossible. And therefore, the ability to see something graphically is just that the graphics have to be put together in a right manner, organized correctly, and to the same audience or to the appropriate to the audience. I think when we use the term data modeling in what type of data model? What type of data model? And they're talking about a physical database design. I hear data model and they're talking about relational, normalized, you know, third normal form model, name for quality, all of that type of stuff. And that is data modeling from the business perspective to understand the business requirements, which they are using in a different vocabulary and could care less about normalization. So what does that model mean? It's actually touched upon one of my other myth questions, is how many types of data models are there? And I'm not really referring to conceptual, logical, physical, although those are definitely types of data models. I think a lot of the stuff that I read when people either don't need a data model or they don't need a data model is I always ask them, so what do you mean by a data model? So how many data models are there? Oh, how many data models are there? That's not a question of data models. Well, yeah, I guess I don't really distinguish between types of data models except in terms of their scope. I think that enterprise data models and application data models are completely different animals. I think that it requires people with quite different skills to learn a little bit like, I suppose, the difference between an architect, so someone who is going to design a house for you and a town planner and a town planner and an architect, they come from different disciplines, often different faculties in a university, and require quite different skills. One is very detail-focused on construction. One is looking at the picture and how all things fit together. That's the only distinction I have ever made, is that between application models and enterprise models, and one is like running through the data on data types and lengths and this kind of stuff, and the other one is much higher at a business level and focusing on what are the needs, the information requirements to support business use. So the fact that I keep running into this myth all the time or this misunderstanding it really is, is that data modelers have dropped the ball on in not helping them get that sort of thinking out into the world? Well, I suppose the data models, because our discipline is about classifying things and so I think that encourages people and you will see even in data models that people classify the different types of entities. So sometimes this actually makes it much more complex when you're trying to explain lots to people. I don't think it would be interesting whether the panelists think that there are different species or subspecies of data models. I'd try to keep it simple. Certainly, I make distinction between what I call logical models which concern themselves with describing the business data domain and demanding business data definitions, constraints, requirements, business rules, and then physical models which are the mapping of business data requirements to some appropriate choice of architecture and technology. So the physical models concern themselves with the physical implementation of data requirements. That's about what I call the models. I think that is the thing that I'm confusing if you call it a database design whereas a model is something that you do use to communicate with the business. What I would say is that logical models are what I use to communicate with business users. Physical models or physical designs are what I use to communicate with application developers and other implementers. Sorry, I wouldn't... The word model is meaningless. You have to define the model you're in front to say which type of model you're using and you have to define what you mean because the logic model in my world having come out of the iDev world is completely normalized, possibly generalized. As the name for clarity has added all of your client orders and requirements that keys be inserted and predicated. That's the type of type of business model that I use. Okay. You can define your term. I think... Yeah, that's a good deal. So you're not talking about us, right? Not just developers, but data builders and data architects ourselves. So it sounds like to me, we have to go off the ball. I mean, when we talk and we preach that we are going to model, you know, heaven forbid, a single version of the truth and we need a corporate glossary and we need standardized terminology and when we talk about the business, we need to make sure that we're all in agreement what a customer is and yet the very core thing that we use as our main tool for what we do, for documenting it, for revealing it, for analyzing it is that we don't have single terms for uncommon definitions or a single glossary and we could all wait for hours about what makes for a good data model and what is. Do you agree? The data modeling community is its own worst enemy that really became a parent when I sort of left the data modeling community and went into the business world and who is absolutely dependent on how they're properly defined and understanding what their data is and yet the data that we were producing didn't work. Yeah. I think you can contention that. I love that. I think I like what it is that works. I was just following up on Terry's comment and didn't the data models work or how do you define whether or not they worked that people couldn't understand them or they couldn't implement them? Both. The problem is that I'm not going to say that a normal data model cannot be implemented but I find that most business architects don't want to implement that. I don't think so, but they just want to duplicate data for each of us and use of programming is more important than, in my opinion, data, the database I've encountered is more important than data on a different goal and that's why they don't like the logical, normal data model. These people are willing to put efforts and change the meaning of the business in a logical, what I considered to be a logical normal data model to them. That's a nice point because, well, I guess there's two points there. One is about the physical designers and I think there's a little bit of psychology here because a lot of the database designs are a little bit old-school and I grew up in the days where you really had kind of slow disk drives and everything. You had to optimize these things and there were a lot of optimized models that don't need to be optimized but also their craft and you want to apply your craft and you want to get this database fast so you want to have these denormalized techniques whether it's necessary or not. I think the other point about managing I've seen some absurd cases of this where, for example, I worked in a bank and everyone in the bank from tellers up to the CEO think in terms of banking products and accounts. You know, these terms were not precise enough because they could be used with general ledger accounts and their word, the standard word in the corporate data model for an account was offered a product agreement. You know, when you had to explain this to anyone, you'd say, well, that's an account and they'd all say, well, when you call in an account then we would understand it. So let me make a quick point. What we really want to try to do with our models is to have conversations with stakeholders on a project. We're trying to drive some sort of consensus on requirements and needs and, in so, archs of modeling or modeling paradigms really comes down to what kind of problem are we trying to solve at the moment and what group of stakeholders are we trying to communicate with and collaborate with and get to some sort of consensus on. So that would be a good contentious conversation as well. Because I just want to reveal a bias here. So for the last couple of years, I've been primarily acting in a role as one of these physical element or data models. So half database design, still logical model and mostly the reason I've been doing that is I've been working on troubled projects quite a bit, which means someone has built something with our data architect and they want to get it to work. So I'm coming in definitely at a late-stage development type project, which forces me to work on sort of a number of rows of the Zachman framework where I'm still trying to build logical models, but they're very much project or application models and not nearly as much enterprise models. And as you can all guess, most of these projects exist in the environment with no enterprise model and very few data architects. That's why they got into this position. So I don't know all the statements that are being made, but I'll jump into sort of our next category of nitty-gritty data modeling and the first one is Eric. Sorry, Karen. Sorry, Karen. Can I just direct the slide? I probably should mention that we were talking about all the different types of models and Terry was saying there's a lot of confusion about what a model actually is. Dama has produced this Dama signature of data management and they do define what a data model is, what a enterprise data model is and its logical data model. And I guess if people started to adopt terminology that has the kind of meaning and across the industry that this might clear up a lot of the confusion. That's exactly a good point. So Dama, as we say it in some parts of the world, so dma.org has both a dictionary of data management terms as well as a guide to the data management body of knowledge. So the dmbock. Those are two great resources where the profession is trying to come together to standardize some of these things and it's more of can we get that knowledge out there and get that adopted. So great point. So I want to move on to the nitty-gritty details of data modeling. So one of the things I have which we've touched on is that there's a kind of an understanding that good data modelers never think of performance or implementation issues. So I'm going to let the panelists just tell us in their answers what sort of data modeler they're talking about. But let's start with Terry again. Terry, what do you think? Data modelers? Because you kind of mentioned that in one of your other answers. We shouldn't be constrained thinking about performance. We certainly think that a good long-term understanding that there are requirements and, you know, two considerations. Data base, when you're designing your database, you're looking at a model and I do consider data modeling to be design. So you can take that into consideration, but it's the kiss-off when you're trying to understand a business area. You don't want to care about anything except what the business is trying to say. You don't want to be worrying about keys. You don't want to worry about whether it's a multi-tribute or not. You don't want to understand what the business is, and if you let those considerations creep in to compromise and bias your design, that's like, in my opinion, really bad. Anybody else? Yeah. If you look at the logical, what I call the logical model is business-focused and is implementation-independent and application-neutral. From a business perspective, there isn't any prescription about how or even whether any of the data requirements are going to get physically implemented in some particular way to the myth that I'm always counting is this idea that when you do a data model, you're automatically assuming that it's going to be implemented as a third normal form relational database. It could be implemented as XML or an object database or an OSQL database or whatever. So when you start moving into some conversations and agreements around the physical implementation of data that you're having to worry about performance and keys and indexes and so on, that to me is when you start moving from the logical model, which to me is a business requirements model to a physical design. Thank you. You mentioned a good word for my next question, so I'm going to make this a rapid-fire yes-no answer. Do keys belong to a logical model? And what about some things specifically like the user's surrogate key, so a meaning or this key? So Larry, yes or no? I can't answer that yes or no. Philosophically, I would say... Wait, wait, wait. Go on. Wait, no. Well, I'm sorry, but I... No, I promise. I promise. Yeah. All right. What's your answer? Yes or no answer? I can't give a yes or no answer to that question. Okay. Okay. No. No. Yes or no to other aspects. Okay. And Daniel? No. Again, it depends on where you are. Yes or no. All right. The logical model... No. Keys. No. I'm sorry. I'm sorry. Only one of the keys. I... That's just not to recognize. All right. I have attributes that are identifiers that could be both identifiers. Yes. That are unique, important business information that needs to be included in the logical data model, but I do not have to pick one that the deviants are going to use for their keys. So candidate keys, you can identify, right? That's what you're saying. So it's the proper term. But... So now the reason I was trying to do it to force a rapid answer is I want to come to the other thing, is do your own tools that will kind of force you to choose something, a single candidate key to be a primary key of an entity? That's the point I was trying to get to. Excellent. Philosophically, I agree that surrogate keys don't belong in the logical model. The modeling tool I use pretty much forces me if it's going to be a surrogate key in the physical design, I need to put the surrogate key in the logical model. But then what I do is I create an alternate key of representation in the logical model showing the natural business key of an entity. That gets usually implemented in the physical design as a unique index or a unique constraint. That's the way I was searching for Larry, a natural business key. Natural business keys is what I think belong to the logical model. And one of the nice things actually about the object oriented model is every object or every class has a surrogate key by default. And you don't have to think about it. It's just already there. You can add additional keys or natural business keys, but at the logical level, you just assume everything can be uniquely identified. We do have to struggle with the limitations of our tools. There's no getting around that. My question is because it didn't support optimal modeling on its own, but I create my own diagramming style and I actually use a simplified version of optimal modeling for my business model. That moves to the point that Larry said we needed to define data modeling, but one of the things is the notation of our models. For instance, our S1X. The presentation layer of it and even some of the underlying features assumes or delivers the most sort of present value when there are identifiers and keys because that's what they're called in IDF1X. Identifying attributes might migrate down a relationship into a child entity. Very much the sort of presentation layer we'd like to see in a database diagram of primary keys and foreign keys. Would you agree with that? But I don't want to assume that. The real information engineering notation, you know, you can have relationships with identifiers, not their underlying owned attributes, right? The methodology can be a hindrance or it can be a enabler. In one of my other presentations, the other point I make is as much as I want to have different identifiers in my logical model than I have as primary keys in my physical modeling tools, that's very painful to do. It requires a lot of extra work. Would you agree? Not at all. My tools. What do you use? I use this to protect. I think one of the reasons I mentioned IDF1X is some of the tools, that is their underlying notation and government standard and they can't really degrade from that model uses that notation, right? That really impacts that. So the government standard that's driving that or I'll say a third party standard. It's a third party standard that the US government, at least, has adopted. And then the other tools. So the other point I want to make is tools influence our answers about whether something is a myth or not much more than we realize. Absolutely. Go ahead. The tool is on to a different one. And if you have an interface to the tool that requires that's required by the government, some keys in, I can export it to that tool and that's what I deliver to the enterprise people, the tool in the model. My actual model in the standard model is for another S because we're just going to keep rapid fire through these. And I can use the term third normal form data model. So my guess is if you're in third normal form, fifth normal form, Boyce Codd normal form, made up normal form, have you over modeled it just by definition? Like it's third normal form so holy grail is a good data model, right? It all comes down to what problem are you trying to solve and what sort of an agreement are you trying to reach with what group of stakeholders? Absolutely. You model to whatever extended need to model in order for everybody at the table to understand what the problem is and how the problem needs to be solved. So it's great. So I think that it's important for the characters. So the real reason for this also is that I think it's there's a lot of technology about normalization in normal forms. In fact, I have a series on dataversity.net that I need to add another myth to on normalization myths and one of them is that third normal level is like a great model. What a great model you are because everything's in tenth normal form or what a practical data modeler you are because you never go beyond third normal form. That's the intent of normalization. And as a matter of fact, you could have an entity or table that has value key and just a couple of columns and by definition that would be in the normalization form possible just because it's denormalized and it meets all the tests of the entity for that entity. Is that true, Daniel? Well, I think that normalization is fundamental to data modeling and it's what's bigger to it. So if you compare process models when you can just pretty much draw anything on a wall that's one person's opinion and another that the normalization does provide where it does provide standards that you can apply to any data model but I think more importantly it raises the business questions that you can talk to the business data about so they don't need to understand normalization but by going through these normalization tests you ask the questions that need to get the model right. I think that's a good point, Daniel, that normalization, especially in logical modeling is done for the purpose of understanding the business problem, the business requirements, the business data domain. So you normalize to whatever extent is needed to understand the business problem you're trying to solve or the business area you're working in in full design. You normalize mostly for the purpose of creating reusable structures, reusable data objects. I think the nice thing about normalization is that it's executive to look at every single data and ask the question are there multiple of these, what is the relationship and so on. And that's what I think is so powerful about it and you see a lot of people who have not been classically trained in normal modeling, they've just been given a data modeling tool, they start putting attributes in and think that's tools to it. But it's so fundamental to understand that it's not something that you have to teach to business people, they don't need to know because they just get asked the questions that you use to determine whether your data is in third normal form. I think it's mandatory. You cannot miss it out because your data model cannot possibly be found if you do go through those checks. Go ahead, Gary. I think it's a good aspect of training because quite a few of us have been here for many years. And when we started out in IT, we took courses and seminars and we were trying to figure out how to do data modeling, how to do normalization. I find now that I'm one of these analysts who don't develop a process model and have never been even done class in doing that, that business are now being expected to create a model, whatever you take the model, whatever you're told to do and yet they have no training and I think it's a lot harder to discipline the discipline of being a data modeler than it is to be a process modeler. And yet they're expected to do it and they're expected to do it at a really great rate. And because of that, that there must be a jack of all trades, they are bringing down the quality of what we would have considered a data model. And I developed my business model and I put it in what I call business model form. I put all the steps that you have to go to enter a normalize model. I know what the normalize model doesn't look like, but because you understand if it's a multivalued attribute, you have to understand what the identifiers and what the potential identifiers are. You have to understand if you have a relationship or concepts that are many to many, it's a hidden business concept which I'm there that no one has ever exposed. It is, you're going to bring that into your business model. It's not there for the purpose of resolving the many to many relationship because it's an important business concept because there's a lot that the business knows that they don't know. Normalization is essential, but I wouldn't go to anybody by it. The other thing is that I have a step on my project plan for normalize the model. And that's quite often how modeling is taught is to teach people to produce a first normal form data model within a third normal form data. Even when there is training, it's not a realistic part of... Normalization is a question I ask my entities. I think about interrogating them to see if they've got the right level of... And I don't even use the word normalization when I do the work. For me, it's just a decision. I call it online decisions, but that's just because that's where I'm working because I still think... I personally think of even a logical model of some sort of design. I've made decisions about the data and about its granularity and about what uniquely identifies one. So in my mind, that's either design or architecture. It's just a different type than database design or architecture. So the first time I read the Grand Simpsons in the book, it really makes the point that if you just do your analysis right, you're going to end up automatically in third normal form and possibly fourth without going through the steps. I mean, you're asking the questions, but you're not producing a diagram. And I kind of just sat there as a former developer and said, thank you. Yes. That's amazing. You're using me. It's very important. And the first one that I read is that the logical data model is design. You're making design choices. It's not a representation of the business domain. I highly recommend it. It's not a model of any essentials. Excellent. So we've kind of segwayed into another thing, and I think you mentioned something about it, and this is one that I want to caution you to as you respond to only what type of data model that you're talking about. But it's very contentious within sort of the data network community is that end users should not be shown a data model. They should not be walked through it, and they should never be shown a physical model. So what do you think, Teri? Well, as I work primarily at the business level through a business analysis of a business domain, I absolutely don't agree with that. But that has to be organized properly. I mean, I have had business people halfway through the modeling sessions stay up and say, they're going to start doing the model and start putting boxes in the screen in front of the board, and they're able to figure it out how to do it themselves. The same way they do with process modeling. It's interesting that process models can go all the way around all four walls, and nobody says that's too complicated for business people to understand. But if they don't forbid, we should put up a big data model. It's like, oh my God, it's just too big. There's too much stuff on it. I know it's hard. Well, I would slightly disagree with that. At least, yeah, we're going to start disagreeing with that. What sort of webinar is this? But I would say it applies to any model when it's too complex. I see all the time that people can produce these BPMN models that I don't understand themselves, and they show them to business people in their eyes, whatever. And I think the single greatest barrier to communicating models to business people is excessive complexity. And it's well known that experts, so if you're an expert data model, you're an expert process modeler, you can deal with these incredibly complex diagrams. But business people can't. And we go back to Tom Doe and his data flow diagrams and his 7 plus or minus 2 bubbles per diagram. And the strange thing is, is most people think data flow diagrams are dead. Yes, they did a study of practice in Australia. And that was the second most commonly used modeling technique in practice. And the reason is that they produce nice simple diagrams that business people can understand, and that's why business analysts use them. Thank you, Dr. Innes. Narky comment there. I think the most common data process model diagram is something called Vizio with random notations, random objects, random rules, and no sort of very much ad hoc drawing. And the reason I say that is it all ties around to what Henry said, where there's little training in a lot of these things where people sometimes, and then my take is that people are sometimes so overly constrained by these notation rules, and sometimes they just want to have no outbound flows. And it's because they're focused on just communicating some ideas. So they're really just formalizing an ad hoc whiteboard model. And I think that part of this is that people are constrained, so they're uncomfortable with the rules the constraints of the tools put in, which are there for a good reason, but then just lean to a drawing tool and call that data modeling or process model. Vizio, I think one, Carl made the point on the chance session that you can create a single huge data modeling diagram for a present. People do. Break it down just like you said for the processes. You break it down by subject area. By topic, I call them views. And some rules in that I call the same entity to come up on multiple views so that if it's applicable to the topic. So my data that we have and it's a small project. It has 300 tables in it. So that's pretty small. A lot of standards. And it's broken down into 24 topics. And people look at the topic diagrams not a big piece of paper that would even with 300. And you wouldn't be able to get it all out in a readable fashion. I agree. I make extensive use of subject areas in my data models. Yeah, that's an interesting issue because my doctoral research was actually a representation of large data models. And what I discovered and it's actually done a big thing on this called cognitive fit theory. And adapting representations to the audience. And the other things that non-experts have. So business people even have difficulty with very complex models whether process models whether data models it simply doesn't matter. And it's experts and this is what I found in my research is that if you give a data model that has been modularized into subject areas to database designers they have difficulty with it. All right. It's comfortable using electrical engineers and huge circuit diagrams. So this is called the expert reversal effect. So representation that is useful for communicating with experts is not the representation that is useful for communicating with non-experts or business people. So that's what you actually need kind of both because the big complex one and so the modularized one would be nice if tools do this automatically. I've used tools for a long time that have the ability to take the diagram and the lines that have always been called business rules and translated the lines into English sentences. And I have this business person come to me and said, I'm not a visual person. I don't get that diagram at all. But the report that you gave me and I just put it there. He goes, I can read this and I can tell you this is wrong, this is wrong, this is wrong. So he was a textual oriented person as opposed to a visual oriented person. On the other hand, I'll take this as a story, very, very large bank where what would be equivalent to I guess a conceptual data that covered through a whiteboard never allowed anybody to erase it. It was before tools. And it basically laid out how a whiteboard means to be a bank. It really has an aspect of what it means to be a bank on those three boards. And I had the copy of the reading link with the manager who did understand what it meant at the time to bring up his products when deregulation was going on way back in the 80s. This is when this happened. And he would bring these people, these business people over and have me go through my presentation of that model which told them what it meant to be a bank in a non-regulated environment and had nothing to do with data. It had nothing to do with wanting to become data and a database to them. It was the bank of the future and it was through a data model and they got it. Data people can understand things and that's a really bad thing to do. So we're coming down to the last seven minutes or so. We've been trying to answer some of the Q&A in writing as people are talking. One of the things I wanted to note as we go through those is that there seem to be a lot of requests for getting into the whole data modeling and agile thing which is a huge interest to me. I know to some of our panelists as well all of my projects are a little scrum or some sort of newer development technology and my answer to that is I think that's a whole webinar. I think we have done one in the past maybe even prior to me hosting these but maybe it's time to do another one of those again because there's still lots of questions and myths around those as well and we definitely won't be able to talk about those in the last two minutes that we basically have. But also a lot of conferences where we talk about those things including Enterprise Data World there's usually some things there's also workshops. I know I did do a workshop based on that. I know some other other speakers do about that too so I just wanted to put a plug in for those. There's also been some questions about tools that we use and everything in my answer for that is sort of it depends. The blog post about what's the best data modeling tool and basically the answer for it it depends on what you need just like any other tool. I also wanted to bring up the point that it's one myth that we talked about today. Panelists do you agree that we could have spent the whole hour just talking about that one myth? Thank you. So this is intentionally sort of trying to talk about myths in general but I wanted to ask each of my panelists did you have a theme takeaway or really important point that you wanted in a sentence or two for our audience? So I'll start with Daniel. A sentence or two? The secret to resolving these myths is actually to look at the evidence for and against and sometimes it just comes down to consensus of opinion and I guess that's a little bit what we're doing here and focus over the last in the recent years has been on diagramming and the amount of evidence out there because people have been psychologists have been studying how the human tool system works for hundreds of years but it would be some of the myths that we could actually resolve them by real evidence about what actually works. Evidence based data modeling. That would be good. I think that my takeaway we didn't entirely get into and alluded to it that data modeling is not an isolated activity or an isolated process that if you're trying to understand a business domain with the process analysis and the business rule analysis and balancing the three aspects make sure the business rules use the data terms that business processes know which business rules they're implementing and what data it needs. You're not going to understand that business too. That you need to understand all the things that we grew and you have to understand and they have to be balanced. Oh, that's a very long sentence but good job, Larry. I think of data modeling in terms of model driven development and I talk a lot about this in my book. In model driven development you're trying to do three things. You're trying to achieve collaboration and consensus amongst stakeholders. You're trying to reach a common understanding of what the business problem is and what needs to be done to solve it and you're also trying to create a solution to that problem in the quickest amount of time and our modeling tools allow us to do all three things. If we use them correctly we can bring everybody to the table talk about what the problem is what needs to be done to solve it and then we can actually generate a part of the solution to that problem from our modeling tool. So data modeling is very much a part of model driven application development. Excellent. Okay, great. So we've come down to the last couple of minutes and I want to thank the panelists for sharing final thoughts. There were such great things in the chat and so many questions so what we usually do is work on the formal part of the session end in a couple of minutes as many as possible of us will stay on to try to get through those questions and answer them both in the chat and verbally so I'll welcome you to stay on. What I think we learned from all this is that we as a data management profession need to get our act together and try to establish more sort of calm terminology and vocabulary around these things in a way that contributes back to make less pain for end users developers, BDAs and us and the business and that we need to keep talking about these myths. We should be blogging and writing and speaking about these things but a whole our community doesn't do that and we should be doing that not just in webinars so that's my rant on that. I'd also welcome any comments in the chat about how ideas for how our community solves some of these problems of the myths. That's something that's really important to me and something I work on quite a bit. I want to thank again our sponsors, CA Technologies, the makers of Irwin, their popular tool and Shannon, our editor at Dataversity and our webinar expert and Tony Shaw at Dataversity and all of our palace you guys did a great job. I sent you all kinds of rules and guidance and pretty much you ignored them and still managed to pull off a wonderful webinar and I wanted to thank our audience for these great questions. I hope you stick around. Our next session, our next monthly session on webinar will be on NoSQL and the modeling and so we'll be talking about where things fit in. It's on August 22nd and it's going to take place during the NoSQL Now conference which I'll be attending and I'll be on a panel there talking about data modeling and NoSQL and all kinds of stuff. So check out NoSQL Now which is you can get information on the Dataversity.net website as well. So I'm going to turn it over to Shannon to be the wrap-up part of the conference. That's very certainly. Karen, thank you so much and thank you to our panelists, especially Dan, thank you. Daniel, thank you so much for, again, getting up at this odd hour in the middle of the night for you and thank you so much to our attendees. I just love how engaged you are and just to have the and again just engage in the whole conversation. So Karen, I will turn off the recorder for you.