 Hello and welcome. My name is Anita Kress, and I am the Webinar Production Assistant for Dataversity. Thank you for joining the latest in the Monthly Webinar Series, Lessons in Data Modeling with Donna Burbank. Today, Donna will discuss UML for data modeling. When does it make sense? A couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the Webinar. And we very much encourage you to chat with us and each other throughout the Webinar. To do so, click the chat icon on the top right corner of the screen to activate that feature. For questions, we will be collecting them via the Q&A section, or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag lessons DM. As always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the Webinar. Now, let me introduce our speaker, Donna Burbank. She is a recognized industry expert in information management with over 20 years of experience in data management, metadata management, and enterprise architecture. She currently is Managing Director of Global Data Strategy and International Data Management Consulting Company. Her background is multifaceted across consulting, product development, product management, brand strategy, marketing, and business leadership. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia, and Africa, and speaks regularly at industry conferences. And Donna is joined today by two guest speakers, Michael Blaha and Norman Dowst. Michael Blaha is a consultant and trainer at Modelsdorf Consulting Corp. He specializes in conceiving, architecting, modeling, designing, and tuning databases. In addition to working with dozens of organizations around the world, he has authored seven U.S. patents, seven books, many articles, and two video courses. His most recent publication is the Agile Data Warehouse Design Video Course from Infinite Scales. He received his doctorate from Washington University in St. Louis and is an alumnus of GE Global Research in Schenectady, New York. Norman Dowst is principal consultant at Dowst Associates. He helps organizations produce better project results by utilizing data modeling and UML modeling, among other techniques. His consulting clients include startups, healthcare providers, healthcare software vendors, large national government organizations, and a large international software company. His book on UML modeling is UML Requirements Modeling for Business Analyst. He was a major contributor to the healthcare industry standard data model, is a frequent speaker at conferences, and has served on the board of directors of the New England chapter of DAMA for more than 10 years. And with that, I turn it over to you, Donna. Thank you. Great. Thank you very much. It's always fun to do these webinars. And I think people know me by now, and you gave us all a great introduction, so a little more to say. Other than I am on Twitter, it's Donna Burbank. If folks want to chime in while we're talking, give us some discussion that, as we already mentioned, here's the hashtag for the event, which is Lessons DM for today's presentation. I've also written a couple of books on data modeling. We'll show an example from one of them, Data Modeling for the Business Today. I think more importantly, and we've had a couple of these so far this year, and normally it's just me chatting, which I know gets old very quickly. So I've invited two of my esteemed colleagues, and I hope it's with friends, who I've worked with for many years. When I think of data modeling and UML, I think of these two guys. So I'll let them introduce themselves. Anyone need to give a great introduction as well. I'll show you what we look like. I'll pass it over to Norman Dowes. Norman, do you want to say a few words? Yeah. I do look like that, or at least I did it at one point in time. I don't consider myself strictly a data modeler. I consider myself a modeler. I do do data modeling in both transactional systems and warehouses, but I also model states and processes and business processes, because I've found those to be really helpful to my clients. Data modeler plus, I guess. And Mike, did you want to introduce yourself as well? Yeah, thanks for the introduction. And in my case, I'm a data modeler plus too, but in a different direction than Norman. I've done some of the other models. I don't do them very often. I prefer other people to do that, but I get in all the kinds of the gory database stuff. Actually, I'm working. I'm just starting work now on a video course on advanced SQL, so like using SQL recursion. So I'm deep in data modeling, database design, SQL, reverse engineering, all that kind of stuff. Great. And that'll be some good background from those different perspectives today. On the agenda, we'll talk about today, which is all these modeling types that we just talked about. Where does UML fit in? We hear a lot about it. When does it actually make sense? Just a little bit about this modeling series. If you haven't seen the series yet this year. So we kicked off on JLi28 when we talked about data modeling as part of your strategy. We went on to big data. Today's UML. And then coming up, we'll have things on other topics. So just metadata management, XML, JSON for data modeling, lots of stuff. And we have a new lineup for next year as well that'll be published soon. So it's kind of where we stand. What we're going to talk about today, and I think you saw the agenda on the web when you registered, but just quickly. We always think of ER with data modeling, or often, how does UML fit? More importantly, I think we're going to show some real world case studies of how it's used and then kind of the different perspectives that we've already kind of hit on, or business audiences versus data-based design and the pros and cons of each. And then kind of some thoughts and discussions on where UML is headed in the industry, where it's been, and what we think. Then we'll open up for questions, as Anita said. I see some of you putting to Q&A in as well. So either view a Twitter or Q&A. We will open it up at the end for questions. So a bit to just, I'll pick it off a bit to start. And then there's pictures from my book, Data Modeling for the Business, where we kind of do some pros and cons of several of the modeling types, not just UML. But just kind of in the industry, I think several of us have been around for a while on this, and when does it make sense? I think often there's this sort of philosophical argument between people sort of live in camps, right? So I often think of when I'm doing a database design, the entity relationship modeling, kind of the boxes and lines. Other folks often use UML, and I've used UML as well myself. So is there a real divide between these two products, or is it more of just sort of a philosophical difference between the two? This is about the boxing gloves in the picture. So just to kick it off, I'll give kind of an example here. The model we show is from the book, Data Modeling for the Business, the exact same model, showing the same information, kind of a super subtype between an employee, could be a full-time staff, part-time staff, subcontractor, and the left is entity relationship modeling, and the right is UML. One of it is very similar, right? It's the UML class diagram. Some differences, you'll see kind of the crow's feet on the left, the one to many. One of the things I actually like about UML on the right, you can actually say one, two, or three. We can have three employees in the department. One of my biases is that one of the things I like about UML, that said, I tend to live on the left side more often. Which is one of the reasons I've got these guest speakers coming in and give their perspective to do UML more and more often. So I'm going to pass it over to you, Mike. Well, what are your thoughts on some of these, when do you use each? Yeah, actually, I live in both worlds. I was actually involved in UML before there even was a UML. We were competing notations. And essentially a tower of Babel, and that's when the UML came into place to unify things. And I was one of the co-authors of one of the leading precursors. I use UML a lot. I use ER a lot. And we'll elaborate as we go further. The UML is really good for the front end, and the ER is really good for the back end. But that's kind of a gross simplification. And there's some caveat to that. We'll talk about it. Yeah, and we will talk more deeply. But Norman, anything you wanted to chime in on kind of the philosophical versus technical camps on this side? Yeah, I agree that it used to be a cultural one where data modelers insisted on using one. But I've found that that divide has been diminishing a lot over time. I did a presentation at a conference recently. I'm going to show my examples in UML. Does anyone have any concerns? And no one raised their hand. And these were all primarily data modelers. And I think organizations sometimes favor one over the other and sometimes it's departments. Sometimes your DBAs will favor ER, but your business analysts and others will favor UML. I switch back and forth depending upon my clients. Yeah, makes a lot of sense. So we'll get a little more detail than those general thoughts just to kind of set the stage. When we're talking about data modeling, as many of us in the column know, there's different types of data modeling. And we'll kind of talk about the benefits and pros of each kind. So just kind of set the stage. I have to use the term and at the very top, this idea of a conceptual data model where you're really just talking about your terms and definitions. What are the key terms that make sense to the business, products, customers, invoices? And then what are their basic definitions? What do we mean by customer, right? We could have a whole webcast just on that. What do we mean by customer? And I might pull out the boxing gloves in this column. I might disagree with Mike that an ER model could work for some of these high level models as well. But that is often a preference. And I've used PowerPoint for these big conceptual models. You know, often it's just whatever, as Norman mentioned, what makes sense for the audience. Well, we get into the logical, let's still a business model. But there you're starting to put in some of those business rules, your cardinality, your attributes. You're really starting to think more of database design when you get into that logical model. Yet the audience often is kind of your business analyst or your data analyst. The physical model, we're actually going to build a database that's the physical model for DBAs or developers. We're actually going to optimize for performance or add your specific data sites and your indexes and that kind of thing. So that's what we're talking about when we talk about the models. Is UML good for all of these? Or is it better at some than others? So that's kind of the topic of the day. We'll go through and discuss in more detail. So there are some pros and cons. We kind of hit on a few already. So Mike, do you want to continue on that thought process you had? If you had to pick, what are some of the pros and cons that you would say? Yeah, it's a more concise model with the UML. And some people may not think that's a big deal, but actually in practice, I think it is. If you're doing a conceptual model, I got to qualify that. If you're doing a conceptual model, I'm not really sure it's much difference at all. But if you're doing a logical model, UML is more concise. And maybe like 20% more concise. So if you can fit more on the slide, more in the page, or have a page not be as compressed with what's on it, that's a big deal in terms of trying to communicate and get people to understand models. One of the problems I have with large models is if it spreads across multiple pages, it's hard for people to get context. But if you cram too much in one page, and it's too much to look at, so being more concise does matter. So that's a point I'd like to emphasize. I'll just make reference to a couple of these bullets here. The good for both abstract and complex models. I think UML is especially helpful if you're doing something like a meta model. With a meta model, you're being really abstract. With database applications, you still got database design to produce. But you have oftentimes with a meta model, you have a more substantive architecture and maybe more programming considerations. So UML model is really nice there when you get to a complex model like a meta model. Yeah. What do you think, Norman? Disagree? Disagree? I don't disagree with them, but I think of things in a different slant. I look first and say, okay, who is my target audience and what do they know and what are they familiar with? And generally for your top two levels in your diagram, Donna, logical and conceptual, I prefer UML because I think it's easier for folks to understand that they don't have any experience in it. And it's easier to kind of ignore physical things. Even when I do logical models, I frequently don't include keys and primary keys and things in that. So I like the fact that UML makes it easier for me to do that. Well, the other thing, of course, is if you're using UML, you can do more than just data modeling. So I've never found a project where I didn't need to do any kind of state modeling to keep track of all your status codes and going back and forth. Plus you can include operations with your data, and that helps to bridge the gap between process modelers and data modelers. Yeah. I think in that last point you made, I think there's a good clarification that we make. When we think of the unified modeling language, there's a lot of different model types. There's new use case diagrams. So I think when we're making this comparison, and we'll see a couple examples, we're generally talking about probably a class diagram, if you'd agree, kind of the UML model when we're talking. But that is a good clarification to make. There's a lot of types of models. I guess my two cents, I would disagree both of you, I think, and I actually did a survey for my data modeling for the business book. And I took a UML model, an ORD model, an ER model, and I actually showed it to a bunch of random people from carpenters to plumbers, teachers. And what I found is, without explaining it to them, that close crossbreed type of diagram seemed to be the most intuitive. That said, you need to hide the detail. So in some tools do that better than others. I generally don't show attributes to a business user and that kind of thing. The other group we haven't really talked about is programmers. I tend to think, especially when you're doing object-oriented programming, they tend to just think of UML. So I think, in addition to business users and database developers, that programmer group is another good audience for UML that I've found. But probably, as they say, a picture is worth a thousand words. I mean, for folks that maybe are not familiar with the UML, we thought it might be helpful to actually show you some examples where it has worked. So I'm going to pass it over to you, Mike, because I think this first model is yours and one you have used for a business audience. Maybe talk us through. Yeah, I had a consulting project for Velo. It's a Velo's UK financial software vendor. This model is about four years old. Velo doesn't exist now because they're acquired by another firm. But this is what we did four years ago when it was a Velo. And this is a conceptual model. You can see we used UML. So an obvious question is, why did we use UML for the conceptual model? And this case was clear-cut. My client, Velo, was a UML shop. They're using UML models real heavily all throughout their database design and everything, which is a little bit unusual, but that's the way they operated. So that's the reason I did this conceptual model using UML. And Velo had an interesting problem-slash opportunity. The company was spun off from a hedge fund. And the hedge fund had bought up like four or five freestanding software companies all with substantial products that were leading in their marketplaces. And they fused them together and sped off the masses of Velo. So Velo had a problem. How do they tie together these applications? They were all SQL server applications. They all use a Microsoft stack, but their abstractions, their architectures were quite different. They were built by completely independent firms. One of the applications dealt with pensions. Another one dealt with mortgages. I don't remember offhand what the others dealt with, but they're all in different financial vertical markets. So not surprisingly, Velo wanted to tie these applications together and integrate them. It was very difficult to do because when you try to do integration and the abstractions are much different, it really becomes confusing. I actually got stuck. I tried at a detail level to try to integrate them. I didn't make any progress. So what I did is, well, I actually made much less progress than I would for the typical company. So what I did is I backed up, cut out detail, abstracted, and finally wound up with this model. And this model cut pretty well across there four or five different products. And the idea is if you got these freestanding products, you want to start to tie them together to integrate them. This is like a master-down management approach where you get some really critical concepts that burn across all the applications and you tie together in these critical concepts. You still don't have full integration, but you've made progress. And this is the model we did at Velo. Yeah, I would agree with that. When things tend to get complex, these type of models at a high level are so valuable, because it really just breaks it down to those core concepts, you know, parties and activities and documents. I think you had another good example, too, that you might want to share. Yeah, this is... I have a friend who's a PhD chemist. He's very knowledgeable about... he's interested in the global warming problem and wants to do something about it. And his forte is vehicle technology, and he's focused on batteries from a chemistry perspective. He's looking at different chemistry for batteries and different technologies. And, well, the bottom line, if you're looking at this chemistry, this science, if you're looking at it from a global warming perspective, one of the bottom lines is economics. You know, you have capital costs for vehicles. You have operating costs. You got costs of energy in terms of gasoline and in terms of electricity. So how do you trade all these things off? And so this is a model of the different cost factors, and I actually wrote a stored procedure for him that did discounted cash flow. So if you got, like, projections of energy costs, cost of money, things like that, you can do a discounted cash flow. And for different fleets scenarios, you see that at the top middle of the model, for different fleets scenarios, you can calculate the economics and get some guidance as to which technologies are more promising and which ones are less promising. So this is another example of a UML model. Why did I use UML here? Well, the purpose was to... I'm a database person, but the purpose here was to communicate with people and not just weirdos like myself. So we're trying to communicate with chemists, with government people, with lay people, and so we're trying to reduce the technology burden as much as we could just to get a simple understanding. Yeah, makes a lot of sense. And this one is from the Virginia Department of Motor Vehicles. Yeah, this is off the Spark Systems website. And the reason we reference Spark Systems here is they're one of the leading vendors for UML tools, and they have lots of examples of applying the UML to various kinds of problems, including database problems. So you can see their URL there if you want to look at their website. And this is an example of a problem from the website. I don't know this problem in any kind of detail. I just pulled off the website. But the interesting thing about it, you can see there's five top-level packages, and a package is just a holder for classes and relationships. And you can see if you look in the top left, credentialing is a package, and there's four packages within it. And you see requirements, business processes, and so forth. So if you look at these five packages on the screen, say there's like 30 packages within, and if you look inside those packages and look at the totality of classes and relationships, I'm guessing maybe got 100 classes or so in this model. So this is a pretty significant UML model if you want an example to dive into. Yeah, it's also a good example that shows something, you know, beyond just the class diagram, because you have a package diagram, which is a good segue into what Norman, who I know you do a lot of work in the healthcare industry, and you've got two good examples, the class diagram, and then you go a little beyond that. So I'm going to give us some background on this one. Sure. This is something I put together for a current client, and it's a healthcare provider network, and we're installing a vendors system for their data warehouse, and it's a dimensional model. So they had a, I looked at the dimensional model, we need to load data to it, and of course it's got everything all bundled up into one thing. So I had to kind of bundle things. So I created this model to say, well, yes, you have a payer who provides, you know, it's the one that's paid to bill, and they offer different healthcare benefit plans. And each benefit plan can be subscribed to by a member or subscriber, and then it turns out that these plans have the same benefits and are sometimes marketed to different employers with an employer put their own name on them. So I needed to kind of create this, but it was still too abstract. People said, well, what's a healthcare benefit plan and all of these things. And so what I had to do is create something out of UML, which is the next diagram here. Then I had to give actual examples. And I said, all right, so you've got a, I call it Green Star is the national payer in there. They've got a state affiliate called Green Star Colorado, and the healthcare benefit plan has a name. So you've best benefits, and it's a platinum plan. That same plan is marketed to on the right barriers. For a group, pickup hotels, and on the left, heavenly hotels, and you've got the policy on the bottom. So I had to put actual data values in these things. And then they said, oh, I see now. Now I see what a member is in a member number. So Sanjay asked the question, is there any business scenarios where you are modeling as not as beneficial as UML? And this is one case. I found that whenever I've got a very abstract model, if I create an object diagram out of that, put actual data in it that resonates with the people that helps them to understand my data model better. Yeah, it's a good point, and a good segue into our next topic of, are there some other, we've got some great examples of this, and a picture is always worth a thousand words, but you guys have been doing this a long time in the market. You have some other good real-world scenarios where both the business and the technical, and then kind of touching on some of that business value that you already have, and whether any industry verticals are better suited than others are at UML. So, Mike, do you have any thoughts on that one? Yeah, one of the techniques I like doing from time to time is I'll go live in front of an audience and construct a UML class model on the fly. And as Norman mentioned earlier, there's multiple UML models. We're emphasizing the class model here, but the other models are also useful too. But my focus usually is on the class model. So I go in front of an audience and just construct it live on the fly. There's a couple of reasons for that. One is, well, you know, I'm a consultant and I'm a techie, and people look at me and say, is this stuff useful? And if you can start doing something live in front of the audience in a fast pace of time, I mean, it's not ponderous. It gets people's attention. So I'll do it for that reason. Another reason is to get people talking. You've got different business camps you want them to communicate. And the third reason is, well, occasionally do it for a demo, just get people's attention. Because if you walk in a room, somebody springs a problem on you you haven't seen before, and you start modeling it on the spot and making progress, it tends to convince people that the technology may have some merit and they should look further. So that's one example. Let me mention a few kinds of application domains we've worked on that we didn't show in the slides. I worked with a company that was based in Thailand and had a lot of developers in India. And we used the UML to develop a data model for food tracing. And we actually got a U.S. patent for the work. And the UML worked fine. The software worked fine for the applications. They actually worked quite well. For another company, a large transportation in the company in U.S., we used the UML for an enterprise model for these people. And it was a very high-level model. It's essentially a conceptual model with maybe some critical attributes added to it. And we use the UML just because we're trying to keep the model as simple as we could because we're trying to communicate for the enterprise model. And another example I'll mention, I met a guy over the Internet. I never knew the guy before. He sent me an email. And he wanted me to help him with modeling an application that he was interested in. As a side business, he bets on horse races. And he wanted a model for capturing horse racing data so he could build a system to predict winners and make money. So I never met this guy face-to-face, but he's a savvy developer. And over the Internet, we modeled this problem and he took off and ran with it. I have no idea if he made money or not. We've covered everything from healthcare to horse racing. So Norman, what do you want to say? Well, I can give you an example of... I was using UML back in... This was a project in 2002 for an automated laboratory system for a pharmaceutical company. And the development methodology they decided on required a UML tool. And so I went in and worked on that. And some requirements would use cases. They basically created a domain model or pretty much down to a logical data model. And I would just use the UML class diagram without any operation. So it was basically just a straight data model in UML. And the developers were getting antsy in this. Well, we need to get something up quick. So one of them just took it and created a database out of it. You know, not following the naming conventions that I had and naming intersection entities kind of weird. And it turns out that no one could understand the database with the exception of kind of a person who created it and somewhat myself. Of course there were no definitions in the database. What I did is I took the UML tool, reverse engineered the database out into a class diagram and then just copy and pasted all my attribute definitions and everything into there. And then forward engineered it. So the database now had all the definitions and people could understand it a little bit better. And so that was the case of using it for both a little bit of physical modeling, reverse engineering, and all the other types of logical models as well. Which is a great segue into our next topic. We've talked a lot about the kind of the business usage and a little bit about the software, but what do you think, Norm Moon, because you just gave a good example of actually, we don't often think of reverse engineering into UML. So what are the pros and cons when you get down to that database design level? Well, the pros are, you know, we can do it. The cons are it. You know, if you each, there is no explicit notation for doing it in UML. So each of the UML tool vendors will do something a bit different. And it generally looked pretty strange. So I tend to not like to use UML for, you know, physical designs. What about you, Mike? Yeah, I agree with what Norman said. I actually agree. I think it looks a little strange too. The only caveat to that is I've worked with a couple organizations where they've used the UML tool for database design and been very happy with it. But these couple of times have come across that they're really dedicated to the UML and they've invested a lot of effort in terms of getting tool to work and maybe writing some of their own software around it. But you can see here we got a short list for pros and a longer list for cons. So generally speaking, you can use UML for database design, but it's much less compelling case. Yeah, I think we'll have some examples here if you want to maybe talk through my help. Yeah, so this one I worked on an application with a friend. We're trying to build software for syndicated loans. These are loans that are like trillions of dollars and you got to split them into tranches and place the tranches with different financial organizations just to bear the risk and to provide the money. This is just a small excerpt of it. But the interesting thing about this is we had many storage procedures for this application. We had several hundred. And the UML diagram becomes a really good way to summarize these storage procedures. You can see in the third part of the boxes, we'll get the loan instrument, the attributes are alighted there, but get with ID, new update, bind, tranche, delete, so forth. Those are all operations. They're all referring to stored procedures. They're doing functionality. So we could manage the stored procedures very well for this application. We gave them a name of the class name followed by operation name. And I was impressed how well they worked for managing all the stored procedures. And then we could fit them in the context of this diagram to try to communicate some understanding. Yeah, that's a good point with the stored procedures. So I'll make one more point about this prior diagram. One more point I'd like to make. So we used it for stored procedures here. You can do a similar thing if you got SOA, if you got SOA services. Yeah. I mean, you had another one from Spark. Yeah, this one's off the Spark system website again. And you can see they're way into design here. There's no relationships between the boxes. So it's like freestanding tables. Some are tables, some aren't like interfaces, maybe like a view, data types, enumerations. They got all these attributes in there. So they're way into design. So Spark system has both things more at the logical level and they got things more at the physical level in terms of what you can do with UML and databases and also non-database things. All right. So, I mean, the UML has been around for many, many years in the industry. So I'm kind of wondering what you both think what the future is. Is this sort of something that you think is going to grow and change and emerge? Is it more of the same? You think it's dying off? You see new applications with some of the new technologies that are coming out? What's that one back to you? What do you think? I don't see it changing very quickly from where it's at now. It's been slowly evolving. I guess I expect to see it slowly evolve some more. And UML is a useful tool, but it's certainly not a panacea. So if I'm doing a day-to-day operating application, I'm interacting with business people, I would favor the UML unless there's cultural reasons to prevent me. If I'm doing a data warehouse, I would favor the UML. I just use ER notation because for a data warehouse, the structure is so simple, and people who are writing the queries need to see the actual structure of the database for the report writers, or they have to write SQL themselves. And UML doesn't really add anything in terms of a data warehouse application. And what do you think, Norman? Well, you know, I agree with Mike. I've seen a massive increase, however, I have seen a considerable increase in use of UML for analysis models. So for instance, six of the 13 UML diagrams are referenced in the business analysis body of knowledge. So all business analysts are effectively the new users of UML. And, you know, as Mike and I both, you know, indicated when you need to do more than just data modeling, the UML is what fits best. You know, I very seldom run into a project where I didn't need to do some state modeling to keep track of all the statuses and the things which move them. And if you're ever, if you're using it for any kind of message exchange organization, you know, you can bind your messages to those state transitions and you can actually derive your messages. So yeah, although it hasn't been, I think it should be used more frequently for people working with SOA as well. Yeah, you both agreed on that one. One of the participants had asked a question. Joe was asking, do you see any new innovations or conventions from the UML community? I'll take a crack at it. I know the standards people are working on new releases of the UML. Candidly, I haven't been all that excited about it. I don't think it's really, from my point of view, coming from a database point of view, I don't think it's been all that important. So from my point of view, I don't think there's that many changes, but there's quite a bit out there that people aren't fully utilizing just yet. So maybe there's an opportunity there. There's fine points of the UML like qualifiers and things like that that people aren't taking full advantage of yet. You think there's things missing that they should be innovating? Well, actually, I would say one of my biggest criticisms of the UML is that it's too big. And if it means putting more in the UML and making it even bigger, I'm not a fan of that. So, you know, there's a trade-off between having a rich expressive power and not being too large and wieldy. So I think the UML, if anything, has aired on the side of being too big and too expressive. Yeah, I can see that. I'm going to take exception with that for one aspect. What's missing from UML is a profile for data modeling. So that there's a standard way of representing primary keys, foreign keys, and those types of things. Scott Ambrer actually proposed one a long time. It was never adopted. So if it were, it would make it a lot easier to do physical modeling with that. The other thing is in terms of what it's been, how it's been changing. In the last, like three or four releases and several releases, all the changes have been focused on its use for generating applications and code. So actually code generation. So that's where all the changes have been focused. And since I'm doing operating that space, I'm not certain exactly how, if the use is increasing or what in that space. We'll see if anyone on the call knows the answer to that. Great. So I mean, I think we're kind of, it sounds like there's some consensus that wasn't as much fighting on the call as I thought. The gloves didn't come out. We're all polite people. I mean, I think the general agreement is if we are the business analyst community or doing business analysis at high level, either as Mike gave a great example of abstracting from complexity, I think the UML is great for that. I mean, Mormon mentioned that the in the business analyst community is now standardizing body of knowledge for some use of UML. I think we all agree that for database design, that's really sort of a weak spot. That's really not what it was signed for. And good point, Norman, that is a great way they could innovate in the future if they want to be the complete, you know, be all end all. There are so many notations. Why not database design? And I think the point that I think we all brought up too is that you do have to consider your audience. And so some people look at the UML, it makes a lot of sense. Some people aren't. So I always would have asked when I'm at my client, you know, some people want to see PowerPoint. You know, there's a high level model, you know, can't be to join them. I think there's some great uses for that too. So I think there's a great summary of some of the pros and cons. We've put together some references. Norman, you mentioned Scott Ambler, who, you know, is prolific in writing. I think all of us on the call have written some good books and references as well. A couple of questions did come up in the chat that I did see about UML tools that we try to be sort of vendor neutral on the use. So if you do, there's a reference there for some of the tools that are used on the market. To the little plug to us, the Global Labor Strategy, which is my company, we do a lot of sort of general data management consulting internationally and do kind of that business driven approach. If you want to contact any of us on the call, here's our contact information, email, Twitter, website, et cetera, from Mike, Norman and myself. And you, I think the question always comes up and Anita mentioned in the beginning, you will get these slides and the recording will be available to within two business days after this event. A little plug for upcoming series. So the next one near and dear to my heart is metadata management. And Shannon was probably kicking me out of the table. I might be pre-releasing. We did do a metadata survey earlier in the year that I think some of you on the call might have been taking part of. We hope to have the results of that published around that time. So hopefully we can share some of those as well. And then good old data modeling for XML and JSON in December. So without further ado, I'd like to open it up for questions. We've got a few minutes available. Anita, do you want to open that up? Yes. Yes, I just want to say that we've had a lot of interaction and chatting between people. So there's been an interesting topic. Some of the questions are, what is there that can be shown on a UML class diagram that cannot be shown on an ER diagram and vice versa? I'll take a crack at that, I guess. So the short answer, if you're at a higher level, the short answer is no difference. I mean, they both show entities. The ER model shows entity. UML model shows classes. They both show relationships. They both show whether it's one to many, many to many, whatever. So in that regard, they're quite similar. But if I was going to say, what's the difference between the two? I would say the UML class model shows more in the way constraints. There's some constraints you can express in UML that individually may not seem important, but put it in the context of a model and how they interact. It adds precision to a model and it adds precision to traversing a model to express queries. So I would say that's the primary difference between the two. I think another thing which I don't think any of our models showed today here is that you can use stereotypes if you want to categorize classes or things like that. It's part of the UML and you can actually adapt those to your own situation. So you're not going to find that in an ER model. And of course, you always have the operations which is technically not part of data modeling. So you can't find those in the ER diagram, but you can in the UML model. Remember, Mike showed a good example where he was displaying the stored procedures right on that. There you go. There it is. Anything else, Nathan? Yes. Have you seen UML used for semantic modeling? I personally don't think I have, but I haven't really gotten involved in those kinds of applications. Yeah, I haven't, but I will give you an answer. I will have an answer next Monday after I hear a superb semantic model or I give a presentation, so I'll ask. I have not as well. Okay. What kind of UML types are there? I'll take that one. I think what they're probably asking is how many different diagram types are there? So we looked at two of those. We looked at the class model which you have up here. We looked at an example of an object model that showed all the attribute values. There's actually 13 different types. There's use case models, state machine models, sequence diagrams showing things going back and forth, timing, and so there's 13 all taught. Yeah, I got nothing to add to what Norman said. I would have guessed 15, but Norman's got a precise number, so. There you go. Can UML notations be leveraged to model no-SQL database components? And if yes, which UML diagram? So, okay, I'll comment on that one. You can certainly use the class diagram for no-SQL to the extent you're doing some data modeling for no-SQL, and in some sense, the UML model might be superior to ER for no-SQL because ER diagram presumes you got a relational database with all the concepts and jargon of relational databases and some of the no-SQL platforms, some of them are close to relational databases and some of them are more of a departure. So, if you got no-SQL language, which is more of a departure from a relational database, UML would be superior to ER just because it's more neutral. Okay, and we had a question. Can I ask if slides 13 and 14 are Norman's own notation or part of a standard tool? Those instance diagrams look like a great communication tool. They're a standard part of the unified modeling language. They're called an object diagram, and most of your tools can generate one from a class diagram. Yep, it's a standard part of UML. Both of those are. Okay, and what new tools are being used? Is that what new tools? Yes, or maybe new applications. I'm not sure. No, I don't. I'll take a crack. I can take a crack. In terms of new tools, both of the Wikipedia site we gave you, there's like maybe at least 50 tools out there that do various kinds of UML diagramming, maybe probably more than 50. So, in terms of new tools, if you mean just like, it's not new techniques, but just new creations of how the new applications to create these diagrams, there's a whole bunch of them out there. They range from freeware to like, they range from freeware. They typically fall into three categories. There's the ones that are free. You get what you pay for. There are the Cadillac options that run between $2,000 and $3,000 per seat, and then there's kind of a middle range that run between $100 and $500. And they all tend to fall into one of those three categories. Let's see. There are still a few more questions. I'm sorting through them. Is there any link to a complete case study illustrating different UML diagrams with code generation? For code generation, I'm not sure. Yeah, I don't recall seeing any. I don't have an example of my own, but I bet if you go to the Spark System website that we cited, they have quite a bit of stuff there. They might have what you want. It looks like me first. I'm looking for any more that might be in the chat section. There's some discussion about JSON, and I've thought that if you guys used it for JSON at all. I haven't, but that's, I mean, when you start thinking about JSON, you're kind of modeling documents, you know, and those are, I tend to think of those as hierarchical. I mean, it's just like XML documents. Right. I think you have to be very careful when you start walking down the path of modeling a document versus just modeling the real-world relationships between the contents of the document. And that person might want to catch our XML and JSON modeling session in December. A little plug for that next one. I mean, otherwise, if it's happening, maybe all of us are open to direct questions via email, and I think, Nina, you'll be doing a summary of the questions as a follow-up. That's correct. Yeah, maybe we can thank everyone for joining, and until next time. Yes, thanks everyone for joining. Thank you for such a great presentation, all of you. There were comments about how clear it was and how nice it was to have a panel for discussion. So thanks everyone for joining, and thank you all for such a great webinar. Take care. Have a great day. Thank you.