 And welcome. My name is Shannon Kemp, and I'm the Chief Digital Manager for DataVercity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss the rise of the graph database. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. And we very much encourage you to chat with us and with each other throughout the webinar to do so. Just click the chat icon in the upper right-hand corner of your screen to activate that feature. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share our highlights or questions via Twitter using hashtag DA Strategies. As always, we will send a follow-up email within two business days, containing links to the recording of the session and additional information requested throughout the webinar. Now let me introduce to you our speaker of the series, Donna Burbank. She is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategies Limited, where she assists organizations around the globe in driving value from their data. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia, and Africa, and speaks regularly at industry conferences. She was just here at Enterprise Theater World. And with that, let me get the floor to Donna to get today's webinar started. Hello and welcome. Hello, Shannon. Good to be on these again. So yeah, as Shannon mentioned, today's topic is on the rise of the graph database. And we've got a lot of interest in this session, and partly because there is a rise in interest in graph databases. Those of you who have missed, as you know, we have a series. So each month we have a different topic as it relates to data architecture. I often get the question, you know, can we catch the ones we missed? Because I know we always register with the best intents and we have other things come up at work. So yes, they are all on demand. And Shannon generally sends out, if you register, she will send out the link to be on demand, but they are all out on the Data Diversity Web site. And next month we'll be on best practices and data architecture for the today's rapidly changing landscape, one of which is graph. So just wanted to let folks know that this is part of a series, and please do join us in the future. And if you've missed any of the past, you can always catch them on demand. Today we are talking about this rise in popularity of graph databases, and sort of why some of these key use cases are going for that increase in demand. We'll do a basic overview of graph databases. This is not a training in any particular technology. But we're going with the assumption that a lot of you are new to this and should give you kind of that primer on, you know, what is a graph, why do I need it, and what can it be used for, and some of the business values. We'll also have some industry surveys and kind of showing the rise in this graph database. So just to start off, what is a graph database? Great way to start. So at it's simplest core, it's the set of basically linking the relationships between data points. So we'll talk a lot more about this, but one of the benefits of a graph database is you're really able to see these key relationships from data points and get new insights from your data. So there's sort of a balance between the data itself and then also making the relationships between that data, a high level relationship point in and of itself. And we'll talk more about that if that made no sense because I feel like it just didn't. It's one of those days. It doesn't always make sense. But at it's easiest. We have a lot of things in our head and next month we'll talk about it as well of how fast and all the new technology. So I always like to have a mnemonic in my head of how do I remember graph from key value store from relational to all of the different types. So if you're the type that does that, I like to think of the graph database as thing relates to thing. And if you're familiar with the Dr. Seuss cartoons, there is thing one and thing two. But we'll talk more about that. That sort of line between thing one and thing two are kind of those nodes and edges. So this is kind of the more technical way of that thing relates to thing. So you could call it nodes and edges or vertices and relationships or whatever. Every technology has their slight take on that. But basically it's thing relates to thing. And the difference as I mentioned is that you track the relationships as much as you do the nodes themselves because that's often where you get the insights of not necessarily the data itself, but how does that data relate to other things? One of the reasons I am a fan of graph databases and other people are and why they can be helpful is that in a lot of ways it mimics sort of how we think. And we'll talk to them a lot more about this is that we sort of have a thought in our head. I'm going to go visit Mary. And that sort of links to a lot of other things in my head. Oh, Mary has a brother, John. I wonder how he's doing. Oh, is he still dating Stephanie? And then maybe, oh, I remember, Tonya, when we were young, we crossed a boat. In that boat, we were out in the lake. They still have that house at the lake. And then you think of boats and then you think of your toy boat. Or if your brain's like mine, then it comes squirrel. Random things. Just like data. So if that made no sense, sort of where we're trying to head is that there's certain patterns here. You go from Mary to sort of family relationships around Mary to human relationships, friends and family and human patterns. It might link to activities that happened with those people. It can come into sort of things and objects that relate to those people. So you can kind of group them and the picture's kind of trying to group an organization. So it isn't just this random thing relates to things, although my brain sometimes feels that way. But that is the case. Sometimes you will get these squirrel outliers of just this popped into my head for no reason. But in general, yes, there's some linkages and those things link to things, but there is sort of an overlay of pattern that you can apply to this. But the thing is, just like your brain, you don't really know necessarily where the data is going or in what way you want to look at that data until it happens or until you actually link those sets together. So what do I want to think about with Mary? Is it the people she's related to? Is it the things we've done together? Is it the object she owns? That she has a boat, et cetera, et cetera. So that's, in a way, that's sort of how graph databases work at a very obviously high level. That's a little different from those folks in the relational database world or the way of thinking about the world and more of a sort of a Texan or a hierarchy. So I've used this slide in other presentations, but when you think of it, there's sort of a different way of thinking. Way back, and if you had to remember this in school, back in 1735, Linnea has kind of created this hierarchy and the idea was, you know, if you had to remember kingdom, phylum, class, order, family, genus, species. So you have a frog that's in a certain genus, you know, it's all of that, trying to organize the world or a plant can be organized in a certain way. But the thought back then, and it still has a good place now, is if we could just classify everything, you know, we're smart enough that everything has its place in the world and everything is in an organized bucket and I can order it. In my want mind, that's a bit like a relational database where I'm going to define the things I want to order. I want customers and products and invoices and I order them a certain way and if I could just do that, I can understand the whole organization. So there's definitely a place for that. We're still using this hierarchy that they have put together, but it's also a bit naive in the sense that we cannot. The more we learn about the universe, we just know it's sort of, wow, chaotic and thing relates to things. So it's a bit like the organization's data that some things we can put in a warehouse and you should organize. If I'm trying to organize species on the planet and do scientific discoveries on it, you know, think of the periodic table of elements. There's a lot of order and there's a lot of structure. But then there's not, right? The fancier way. So the more I have kind of a nerd and a lot of things and I can't say I'm a scientist, but I'd like to read up about things and the more you look at the world, there is this sort of theory of emergence. And so in philosophy or systems theory or science and art, it's the idea that there's complex systems, complex patterns that they sort of result out of very simple interactions. So it's a bit like chaos theory in a way. Things just happen. So think of a snowflake and without getting religious or is there one person or God or creature that created a snowflake? You can't necessarily say that there's a person up in the clouds printing out snowflakes. But there is this snowflake-ness. No two snowflakes are the same. They're all very different. There's really no, it's very chaotic, but it sort of comes together that there is this snowflake-ness. There are patterns that come out to it. There are some practical applications to this. The picture in the middle, things of when they're doing city planning, I remember in my university I've told this story before, I know, but they sort of made the pathways getting to the different buildings. And they were all nice or I grew up in New England, so they're all very organized and squares and we're going to make it very clean. But nobody did that. You walked across the lawn because that was the fastest way to go. So often now in city design, they will do that. They'll look at traffic patterns and then they sort of design the cities around that. So again, stuff is happening and trying to add that that's not, no one designed what snowflake was going to be built or how the city people are actually going to walk. You sort of look at that chaos and emergence comes out of it, these sort of patterns emerge, which in a way is sort of how the brain works. Yes, there's patterns in my brain that I can't begin to understand, but there are patterns that you can put on top of that. And that's a bit like graph theory. So in a way, that sort of graph databases can have the best of both worlds and that there is some sort of random connection. I'm just linking thing to thing, but it isn't chaotic. There are these idea of ontologies or patterns you can put upon it. So I want to look at family relationships on this data. I want to look at patterns of people who Mary has met. So it's a bit of the best of both worlds. It isn't a structured, I'm going to design the database and I know how it's structured, but it's not just chaos either. And it is all about the relationships. That's one of the sort of characteristics of a graph database that makes them wonderful and makes them unique, where relationship really is a first-class construct. Kind of ironically, we talk about relational database, but they're really not about relationships at all. So a friend of mine, Karen Lopez, had a great quote that I have down there at the bottom. A relationship isn't really about relationships. It's about constraints. And when you think of it, if you look on the right, if you're a relational data model, that'll look familiar to you. It's basically about keys and foreign keys and basically creating the... They are great for what relational databases do. They're right. I want to have... I want to have data quality. I want to have referential integrity. I'm building an accounting system and I want to make sure all the accounts link to that customer correctly. You really actually are creating constraints. I don't want data put willy-nilly. I want to make sure this customer correctly links to this account. That's kind of that Kingdom File and Class order. I am creating a construct and a structure on top of it for a very good reason. It's not going away. Relational databases are a wonderful, a big fan. But it's a different use case to try to discover patterns and relationships, which you can do in a relational database. A lot of the use cases, when we go through use cases in graph, you might say cynically, oh, we can do that in relational. You can. You can do a lot of things and a lot of different things. But the power of graph is in these relationships. You have these sort of key, these, you know, thing relates to thing. Customer is the owner of an account on the left. That's more of a graph database data model. Whereas on the right is your more traditional relational database. So there's, this is one way to model graph databases. This is not necessarily particularly talking about the pros and cons of different ones. I'll just kind of say generic. So two that are out there, you have the RDF, which is kind of the triples. And some of the sample query language or that would be Sparkle. One of the vendors that supports that is StarDog, they spoke last year on this topic. There's also kind of the labeled property graph, which I think that might be Neo4j with different, you know, but they have different ways of doing it, but they're basically without getting detailed into each one of these, there's plenty of, actually the vendors themselves, if you are trying to learn graph, actually have some very good training out there. Obviously, particularly around their solution, but there's actually some great materials out there. So I don't want to re-do that, but wanted to kind of point out. The other thing is there's sort of a nice close affinity between logical and physical, if you think of relational, which there's also a link between logical and physical, but you should have the logical design that matches the business. And then you may change that drastically when you actually go to the physical database for performance or whatever, because the graph kind of does make the way the data is and the way the world works, there's less of a, you know, there's more of a connect between that kind of logical and physical model. Again, you have this idea of an ontology that can help define these queries. So again, you're going to just thing-relate-the-thing, that's just random. But I might say, you know, something like, well, people have names and people can own kinds of things and pets can be owned and a dog is a pet and dogs also have names, but a dog is clearly different than a person. So it's kind of these basically logical constructs and you might want to write a query, show me all the people who own dogs, right? So there's sort of a link between that and someone wrote, this is kind of like the conceptual model where a triple, you know, subject, predicate, object, yes, it's actually very similar to that, very similar on construct and it's also dynamic. So you might say, I want to show all the people who own dogs, you know, so thing-relates-the-thing. You could also say, show me all the people who have been bitten by dogs, show me all the people who love dogs and the people who, you know, again, there's different relationships in that data and that's where some of these ontologies are how I want to look at the data can come into play. So we sort of, we called this series, this webinar, the rise of the graph database. What does that mean? Who's actually using this? Is this nice theoretical? Is it actually being used? What do you think? So I've called out this trend paper that we've done, Data Diversity and I and my colleague, Charles Rowe, at Data Diversity. And I put this together late last year on kind of trends in data architecture in general and one of the questions was, who actually today is using a graph database? You know, we talk about it, we hear about it. And so still a fairly small percentage, about 12.7%, a little under 13%, are currently using a graph database. So when you compare that to relational databases at the bottom there, whether they're in the cloud or on-prem, there's still clearly the leader and unfortunately the ubiquitous spreadsheet is still out there. You want to call that a database. So, you know, we still do have some of those other systems, but I will say in the comments, in that paper we'll show a link at the end. There's a lot of more information in that paper beyond what we can show in this webinar. Many, many comments where people investigate getting graph, talking about graph, looking to explore graph. So if you looked at the qualitative and not the quantitative, there was a lot of interest in graph. So the other slice of this is, what am I using today? So it could be that I'm using relational and I hate relational, I want to go to something else, right? I'm not saying that's the case, it's just an example. So we did ask the question, who's using it in the future? And you'll see that that's a lot higher. More 22.6% of folks are looking or planning actually, not just looking to, but actually planning and implementing graph databases. And that's a big jump. To be fair, and I find this graph itself very interesting. So when you look at the one before, what are people using today? It's the big players, unfortunately, spreadsheets and relational databases, some XML, JSON, that kind of thing. And those just jump out as being huge leaders. When you look at what people are looking at in the future, it's a lot more kind of evenly spread, which I think that makes a lot of sense. In the past, we just didn't have as many tools that we do today. And they probably heard me vent about this if you've heard me speak, right? I'm upset when vendors are saying crazy things. Like, you know, relational databases are going away and it's all going to be big data. We don't need big data. We're all going to use no SQL. We're not going to use, you know, it was horses for courses, I guess, is that one of the, you know, the beauty of the environment right now in data architecture is that we do have so many choices. And depending on your use case, there's a lot more technology that can more act. We don't have to put everything in relational database and make it try to fit your use case. I am using real-time treating data. I mean, I want to put that in the big end of things data, put that out on a S3 bucket or a big data platform, right? So the fact that this is 20% is actually a higher percentage in a way because it isn't as all or nothing, if that made any sense. You will see a leader here is big data. A lot of people are looking at that. But that is not exclusive. These are check all that apply. Another thing I thought was interesting is just a thought. As we were looking, I always love to look at the past and what people said were going to be the predictions and we'll rewrite. So it was back several years ago. Forster has predicted that graph databases would have about a 25% adoption rate by 2017. So they didn't quite get it, according to this particular survey we did and the fact that if you looked at 2017, which is when we did the survey, it was about 12.7. But they're about right if you were looking at what people are actually actively planning to do. So that's actually pretty close. I just find that sort of interesting to see, we predicted something how close our rates. So go for it or you weren't too far off. Just to be equal across the different analysts, if they have no favorite or an unfavorite, if you're familiar with Gartner's type cycle, we sort of labeled this, the rise of the graph database. Is it rising? Is it falling? Who knows? So if you're familiar with, they sort of have sort of a cynical view of the world, perhaps, but the, you know, we're trying to have the peak expectations are we in the trough of disillusionment? What a great phrase. Or in the slope of enlightenment. So where are we? Are we, you know, totally overplaying the value of graphs or we're not there? But I think what they're kind of thinking, their call is, well, we're a little bit inflated expectations on what graph databases can do. We're not yet disillusioned. Hopefully we can skip the disillusionment phase and go into enlightenment. I think the cynicism of this whole idea of this graph is similar to what I was just sort of venting about, in that we have this new technology and then we say, oh my gosh, it's going to boil water and also be a floor cleaner. You know, it is what it is, and it's very good at what it does. And hopefully webinars like these help clarify what these things are good for, what they could be interesting about, but they're not going to solve world peace and they can just do certain things. So I would probably agree with Gartner's take there. I think people are using it. There's some interest in a little bit into past the peak of thinking it's, you know, the best thing since sliced bread, but it is awfully interesting and a lot of interesting things to think about it. So what I'd like to do next is your opinion. So we have 185 people currently on this webinar. I want to hear what you think. I have a few surveys and I'm going to pass it over to Shannon to ask her to do similar questions that we just saw in the industry. So Shannon, we can line up this first survey. And we have a bit of a challenge. So if you heard us before you joined, Shannon was cynical and she thinks you're not going to answer these surveys because you're multitasking and you're not listening to me. So stop multitasking. And I'm going to ask you on the right, you'll see a little poll question. Are you currently using a graph database in your organization? So hit the yes or no, and then you'll need to hit submit at the bottom. And we have a time limit. So we have about 17 seconds left. And then once everybody is submitted, we'll get to see the answers. And I'll just be curious, are we going to be more like the 17% adoption that was in the survey, or are we going to be more close to far as 25% or are you going to match Shannon's cynicism when she's listening to me and you're all multitasking on the spreadsheet somewhere? So we'll give it a minute for the polls to come through. This is where we play the music. All right. So 44% of you actually proved Shannon right, but most of you did answer. So that's good. So we will see here that the majority of folks are not using a relational database. My math is not good enough to put that in the percentage. Anyone in the polls who's better at math than me on the fly can see what that percentage is, folks. So that's about right from my gut feel of this. Probably, you know, if you look at the blue line, I think most folks are not using it today, but there is a certain percentage that are. So that's good. Probably about the same as our initial survey from my gut of what that number is. So Shannon, if we can line up the next one, the next question is going to be drum roll, please. Are you looking to do a graph database in the future? So yes, it's of interest to me up and playing around with the technology, you know, whether you have approved budget or is it of a high interest, but we'll put both of those in the same category. So I'm going to ask folks who is this could be there. You're using one today and you're all going to continue using it. So those who answered yes can also answer yes to this one. Just so that we get an accurate number and we're clear on what that says. So we'll give that a minute and we'll see. I'll be curious. The poll has ended and I think we will see the results soon. I'm not sure if we have to show it or if it just comes. I think you said it just came. All right. So that's probably around in line as well. There's a good percentage of folks kind of looking for it, probably a little higher from my limited math skills than what was on the R survey at the university and the Forrester survey. Probably not too surprising given the topic of this webinar, which is on the future of graph databases. So probably some interest there. So Shannon, let's load up the last question, which will be sort of a good segue into the next section that we'll be talking about, which is use cases. So this is one of those select all that apply. And we haven't really talked about them, but I'll be curious. What are people sort of looking at using graph databases for? If any of these kind of, and if you're not using it, just say, I'm not just and we'll have an answer. And then let us know what you think, which one of these, or if I missed one that you're looking for, I'd be curious. That would be the other. So we'll hit submit. And I'm really curious about this one because kind of shows the why, not just the weather of what people are doing. We will give it a moment. I need some Japanese music, Donna. I was gonna sing it, but if you've ever done this, I didn't want to punish people. They'll never come back to the webinar. It'll be worth it. I'm just curious, you know, when people never get a voice on these things. And we don't want to just hear what the industry pundit said. We want to hear it. There you go. All right. So drum roll please. A lot of folks didn't answer or they're not using. So those, which is fine. That's probably why you're joining this to kind of learn more. So I think you'll see here kind of the ones that are, it's either master data management and a price knowledge graph and meta data management, which is interesting. So a few kind of things like social networks, fraud detection and use space. I'll see your own answers there if you did. So all right. That's good. So the next section, this is a perfect segue into the next. Oh, I actually, before we go. So someone put other five people put other anyone in the chat. Want to put what they did as other. I'd be curious, which ones we sort of missed. Some people said they were interested in what this idea of enterprise knowledge graph. And we definitely will be talking about that, but anyone want to put out what the ones we missed. If not, you're shy. That's fine. I won't belabor this point. Okay. So I'm going to move on just to, I thought that was a good segue. Some of you might have been curious about some of those topics or how that even fits. Oh, someone put that they put, use their operational data for graph databases. That's interesting. Yeah. So, all right. So we'll go through some of these use cases for graph databases, why this technology could be cool in your organization. And one of the bigger ones is this idea of social networks. So when you think about relationships, almost the classic relationship is social relationships. So again, you may have a group of individuals and the, you know, people individually are interesting. Hopefully Donna is an interesting person. But what can be more interesting is who Donna hangs out with, right? And who she doesn't hang out with. So this is used often for things like terrorist groups. It could be used for things like grouping your customers by like customers of who you might want to sell through. And in this case, we want to hear who the cool kids are. So the cool kids are the ones to hang out with Donna, of course. And the people who don't, those who don't like data up in the group, up in the right, you'll see they don't really have many friends. Because data is cool. And the people in the middle really at this point, we don't know. It doesn't mean they're not interesting, but I remember with graph, you can sort of ask the, they're not interesting in this particular, this particular use case. Actually, one of the folks that said the other use case, but it was classified, sorry, we can't share. This may have something to do with this type of use case. There's a lot of kind of intel with patterns of people. Metadata was big in the new a while back with people using phone logs, right? And so, you know, people would say, why would metadata be interesting? Well, it's not what I may said on the call, it might be who I call, right? And someone blew up building and I made five calls to that person. That's kind of the link between that person and the metadata about it. So again, it's making the relationship itself kind of that interest. So this is a large great use case. And we're trying to kind of query that back. Great use for a graph database. Kind of a fun example if you want to be nerdy, and maybe we're dating our, my age, but there's this idea of, you know, degrees of separation. You know, one of them is what's your, this is the thing, right? You're, if everyone was familiar with the actor Kevin Bacon, you know, what's your Bacon number? Basically, how many degrees of separation if you need anyone on the planet, do you have? It's basically the idea of relationships between two people. There actually is a Bacon number generator on a website. I just picked randomly an actress, right? So Audrey Hepburn has a Bacon number of three. So it will say what movies they may have been in, and then actors or actresses that were in other movies to link. And there's also an idea of quality, right? Which Audrey Hepburn, right? So there's an Audrey Hepburn with Bacon number of three, and there's also one of two. Could it be a different Audrey Hepburn, right? So graph databases are cool. You can see patterns, but just like anything, the data itself has to be correct and interesting, or you'll get funny numbers. So, but this is a huge big use case for graph databases, and that was sort of a fun result. So it isn't just people that we want to see relationships to another use case. It's the fraud detection. So again, you're looking at patterns between data and between data elements. And that's where these graph patterns can really have some good interest. So one of them might be an example of maybe it's credit card usage, right? So if I have a certain IP address, you would think that from my IP address, I'm going to buy books on data management online, and I would tend to use the same credit card from my computer. Well, maybe I have a work business card and a personal business card, and they'll say that's fine. Or maybe my family shares my computer, and they all have their own credit card. So there's like two or maybe three. But when you start to see one IP address with one of their seven different credit cards coming from it, that seems fishy, right? Did I just steal a bunch of credit cards? And I'm just now buying all data management books, because of course that's what people would buy when you say credit card. And so that's just, again, I don't know who IPI is. I don't know what transactions they're doing. I don't particularly care at this moment. It's not the data itself. It's the patterns and the data. And some of that, you know, the relationships between them. So again, that's another example where it's the relationships between the data that are interesting, not necessarily the data itself. That said, once I find out that this is fraud, I probably do care who and what IP address one is and what it is they purchased and all that kind of thing. So it's not one or the other. But this is a nice way to see those patterns. Another common use case is this idea of a recommendation engine. So we've all seen that. Like this, purchase this, right? So again, that's just patterns. When you compare these online organizations that can do that, have a huge data set of customer interactions and can kind of base patterns. So if you look at customer three there in the green and the left, they bought product two twice. They really liked it. And I'm customer one and I brought product one and customer three also brought product one, if that made any sense at all. So let me bring out my handy-dandy little pen. So okay, I'm customer one, I brought product one. Customer three also bought product one. But look, customer three also really likes this product two. So that's where their recommendation says, based on your relationship with customer three who bought the same product, you might also like product two. So that's one very simplistic way of showing that. But again, it's the relationships between people and the relationships between buying patterns of other customers. Again, back to the theme of this insight and these findings are only as good as the data itself. It's not only the quality of the data. If I really didn't buy this product, then the whole thing is moot, right? But also the volume of the data. These patterns are only interesting when you have enough data, just like any survey. If you only survey two people, it's not of this value as if you surveyed thousands of people, you get a better result, right? So I am a big old nerd and I actually was giving a presentation on how to use data for... Other than use W, I think I've said this before, it's my favorite conference I ever went to. It was the European Outdoor Sporting Goods Society and they wanted to know how they can use data better for selling more outdoor products. And I'm a big outdoor enthusiast, so that was a lot of fun. So I wanted to pick an example that had to do with how I might buy an outdoor product online and show this example. So I sort of had a camping axe there on the left, if you're wondering. So I went into one of the big search engines and I said, you know, I want to check out the price of this. What came up was if you like this axe, you'll also like these coffee filters. And to me, that just seemed really weird. Like, you know, I get, I bought a book on data management. There's another book by a similar author in data management. That makes sense to me. But yeah, you bought an axe, you'd also like coffee filters. It seems to make no sense. It does make sense in the sense that they probably had very few people. This isn't the most popular product, perhaps. But there's some guy up in Canada that was going camping and those type of coffee filters are actually often are the ones for the coffee pots you use when you're camping. So this person probably bought their axe and they're camping and they probably also bought a tent and some other things. So it's not that this was wrong. It's just there was such a small data set. It just seemed kind of weird. It's not like there were other types of axe or an axe cleaner or an axe, whatever. The other funny thing, which will be on the scope of this, is that we're also familiar with content targeting, right? So you look at something once in the Internet and it follows you around for weeks. So for weeks I sort of had this axe coming up and showing I'm looking for something online and the axe is following me. It was sort of like a bad horror movie. So I should probably sort of fix a better example. But again, it's a cool technology, but only as good as the data itself that you have. And that's why some of these big online vendors are actually good at this because they just have so many customers to take the answers from. Okay, so another use case is, and I'm going to do a comparison here. It's this idea of the enterprise knowledge graph and there's other ways to call it. Some vendors have kind of come up with this or have heard this a lot. There's nothing to call it with everyone. We're trying to get information about all the data across the organization. One way on the left, and it's a very valid way. We're building one now in a customer mind and it's fine. It's an idea of a data warehouse. I want to know, in my warehouse, this is kind of that the, what do you call it, the taxonomy, the kingdom phylum, class order, family genus species, or the periodic table of elements. I'm adding a structure onto the data. So I have all this data across the organization. I know that I want to have total sales by region, by customer, by month. And if you're familiar with this, you need to create a, there was a model about how customers are stored. I want to create a domain. It's a model to say, read sales by month. And then I create a nice report. And that's valuable, it's wonderful, but it's very structured and you should have know the answer. Another way to do it is if I do have a knowledge graph. Maybe I just want to know who my influential customers are. And that might be, I have the most connections. You know, those are the example I showed before. Or I just want to see linkages between my data. There's a link between customers and regions, but it's not that structured. It really is just that thing that relates to the thing. And in many ways, this can be equally or more valuable. Not everything has the structure of, I just want to say, report by or have these strong linkages. It's just linking the different things across my organization in a more fluid way and seeing the more relationships between them and getting fast performance back from it. So one example of sort of a thought of that. So I'm coming back to Audrey Hepburn, right? So your data quality, I'll keep saying that, of semantics, those are very important. You want to get that right. So I have Audrey Hepburn. I want to know that her birthday was a certain date, whether she's a current customer. Super interesting, right? But it may be more interesting. I don't know if anyone's a movie fan. I'm not particularly not. I just used this as an example. Audrey Hepburn had a son named Luca Dotti, and he was born in 1970. So he's actually a current customer. And he actually, because he's really wealthy, because his mother was a famous actress, he has yacht insurance from you. He has home insurance. He's filed a claim. There's all this great information about the relationship. So it could be, do you know that some of your customers are related? Maybe I have three people who work at the same company who have a certain corporate insurance with this. So the relationships between the data patterns can also be much more interesting than the data itself. So it's interesting that we have this information about a customer, but the fact that she's related to this other customer that actually has bought a lot of stuff and is very wealthy is probably a lot of interest to us. So sometimes it's that pattern across it. Another use case is this idea of master data management. So there's a lot of MDM tools on the market that are powered by a graph database behind them, rather than a relational database. And that can work well. Often that can be sort of a virtualized way of doing it, linking thing to thing. The data which stays where it is. That can be very, when you're thinking of more of that knowledge graph approach, that can be a very interesting way to do your master data management because you can link your master data to thing to thing. So that can be sort of nice. I will say though that as you look at tools, both of these approaches doesn't obviate the need that you still need all some of the hard stuff of MDM. You still need data quality. You still need to do the matching, the meeting behind it, the survivorship and all of that stuff are sort of similar between both. I mean, you still need to know, is this the same Audrey Hepburn that was born in 1929 or Audrey Hepburn, my neighbor, who was born 10 years ago and lives next door. So that part doesn't go away whether you store it in an MDM or a graph because those just, I mean, or MDM, play it again, graph or relational because that's just sort of how you link things together. Another use case of graph, folks might have heard of this magic web in the city of RV, already have triples, I think someone had a customer comment and some of the comments. The idea behind this, if you're familiar with the internet in a way that's a thing that relates to thing at its core, the internet is just computer, you link the computer in different IP addresses, right? But the goal of this whole semantic web was to move from a web of documents, which is the internet, just thing relates to thing in terms of machine, to a web of data, that thing relates to thing in terms of data. So you still have this subject predicate object, but you could say that this ACME Publishing is a publisher of a certain book, RDF is easy, et cetera. So this is very similar in this idea of thing relates to thing with a certain syntax. There are sort of schemas and vocabularies for certain areas. You can look up a few, double and core, schema.org, to kind of have some of these schemas on, how do I relate a publisher with books, for example. Example I've used, given that it is enterprise data world week. This is EDW from a couple years ago, but still in the current location, which is San Diego, which is beautiful. Here's an example of kind of a use case of that, which again, instead of a web of documents, you have a web of data. So I could be, if you look at, this is an old enterprise data world web page. This is the web page text behind it. We can sort of tag that with the fact that this is a place. So enterprise data world was at a place, which happened to be in San Diego in San Diego. That year I took a picture, don't dance my skills, I'm not the best photographer, but I could have tagged that with the same idea that this place was uncertain. So if I want to know all the things around this place, it's sort of doing that to this idea of these kind of triples and you can link the data together. Okay, so in summary, the idea of the very simplistic, given that there's a lot of technology and you want to sort of get your brain around graph. One of the simplest ways to think about it is this idea of a thing in relation to thing. Your relationships are first class contract extracts, and there is importance to data itself. We are seeing that usage of databases, graph databases are on the rise. I think your feedback was similar to our survey and some of the analyst surveys were about the same. People are just starting to look at this and adoption is on the rise. As with any technology, there is a risk of inflated expectations. Pick some of the use cases we mentioned that are good. I wouldn't necessarily, if someone there is saying they're using it for operational, but there is also a very good use case for some of these relational databases that we have been using or XML for data transfer and things like that. There are certain use cases for each one. I think I've mentioned this before. This is my company. We do it for a living. If you wanted more about other trends in data architecture, you can download this white paper we did put together. It does show the graph data questions we had. And then also a reminder, if you wanted to join us next month, we'll be talking about more just broadly data architecture best practices with some of a lot of those technologies that were in that survey. Without further ado, I wanted to open it up for Q&A. I know there's been some comments, but I have not been keeping track of all the questions. Shannon, if you wanted to open it up for questions. Yes, we have a lot of great questions coming in already. Just to answer the most commonly asked questions, just a reminder, I will be sending a follow-up email by end of Monday for this webinar with links to the slides and links to the recording of the presentation. So Donna, diving right in here. So this sounds like a conceptual model. This is from the beginning of the presentation. It sounds like a conceptual model where templates are used to subject predicate objects, yes? Yes, and I think I sort of touched on that, but it also relates back to the comment. It is sort of a conceptual model, but the beauty is it's not so far away from the actual logical model. I mean physical model, sorry, because you actually are kind of linking a thing with a thing with a layer. So it's sort of a nice layer you put upon the actual physical data, so yes. So what are the big differences between a graph and a relational database? Yeah, I think we covered that. Let me go back to that slide. I think we covered it, but just in case. So this is probably a good summary. We're on the right. You have a relational database and you have things like keys and attributes and sort of defined linkages, which are really constraints, right? So I have a customer ID. I want to link this customer ID to this particular account. You've designed the schema up front, and it's as much about the kind of, you know, the keys and the traversal mechanisms between. I think a lot of folks understand relational, so they won't go so deep there. But here it really is more of these triples, although, you know, there are triples, and we all learn that with relational. But part of it is we do make the relationship itself a first order construct, and it's more about I have a customer linking to account, and it really is those triples where the relationship itself is this sort of layer you can add on top with your sort of ontology to really understand how this data links together. So I think this question is a bit rhetorical, but let me just throw it at you. The CIA perhaps is using social network graph notation to identify relationships around a single person of interest. Is that true? Can you speculate on that? Yeah, I won't speculate on particular agencies or whatever, but yes, that is a usage that I think I covered sort of here. It could be a social networking site of, you know, I want to see who my friends are. It could be a gaming application, and I want to see who has similar gaming patterns to me, and you know, it isn't always an affairious use. It could be someone's making phone calls to some people, and that person just did something bad, you know, that sort of thing. So yes, for both good or bad, you can also use this for customer profiling. I have this customer that buys a lot, and I have these other customers that this person interacts with. Maybe we should target market with them or whatever. So yeah, for good or bad, this is almost a prime use case of kind of thing relates to thing or person relates to person. Oops, sorry, having issues with any buttons. All right, so the use of the total borrower exposure calculation is based on the relationships of a single individual when he or she wants to borrow money. I believe this is another statement if you want to comment on it. I'm not sure I followed that. I might have to read that one. The total borrower equation is, and I can't even read my own. Yeah, total borrower would, yeah, I'm not following. Yeah, I'm sorry, I'm not following that one. That's okay. Yeah, I do believe it's more of a statement, but maybe if the questioner can clarify that I'll get back to that. I'll just say one quick comment on that, in case I'm, I mean, often you can find, I mean, it could be that you can, you could find out, say, the credit score of that person. You can see who that person is related to. Sometimes the total borrowing could be that there's other activity, you know, what activity is that person doing. So it's not just the transaction you saw with that person. It could be linked transactions, you know, they loan to other places. So that was sort of my comment on that, but they may have been trying to thinking of that. And this questioner just said, hey, can you throw up page 22? Again, they lost their screen for a moment. So while I go on to the next question, if you would mind, awesome. Hey, Peter. So what tools exist to support GDPR, right to be forgotten to remove information from graph databases that include PEII about European citizens? Oh, there's a good one. So, yeah, I mean, this is a good use case for kind of detecting that, because you can definitely see patterns. You can see links between, as with anything, the deletion can, you know, one of the use cases that we mentioned, and I was pleased to see that several people on the call were, is this idea of metadata management, because that's sort of the linkage, where you can see that this, you know, that it almost is your classic lineage, that this person was linked to this and all these different transactions. When you get into the deletion, that's where things get tricky. I think that is a harder question. I think that's what great, great use of the relational database in that, you know, you can kind of do some of those cascade deletes. But yeah, delete is always, it's a great way to detect, and then deletion will have the same issues that you would have with deletion with anything. It doesn't magically unbreak things that may have been linked. So that's part of the problem. Even with GDPR, is it true deletion? Is it, you know, I, who's working with one customer, and there's also conflicting rules. You know, it may be you need to delete this, but if there is ever a police record of this information, it needs to be kept somewhere. So delete isn't always delete. Sometimes it's delete and store off sites so only certain people have access, but you know, because it does just delete me and I see it in the website. But you know, so, you know, deletion is always a hard part, but it can certainly help with detection. So when developing a graph database relationship, your depiction of representation of one person may be different relationship from another person's representation. So how do you deal with that? I think that's partly where some of these ontologies come in. So the person itself, you know, the thing is still defined as the thing. Sometimes it's this overlay. If you go back to that example of, you know, it's the relationship. What are we looking at? How do we want to add that ontology? Is it a person loves a dog or owns a dog? So it's less about how you define that thing where you still certain have attributes and information on that thing. A lot of it is that relationship and how you want to add that overlay or the linkage between that. So when would I use a triple store versus a labeled property graph? Oh, gosh. There's almost a religion. So this kind of gets back to that. I think everyone, I would say, from my experience, I would say the sort of labeled property graph in many has been sort of the more popular and the easier to look at and easier to use, but that's, you know, everyone has their own. I think in the last, we did one last year, I sort of went on the RDF partly because there's some of the industry bodies use that. You notice a semantic web sort of use that as well. So I will leave that to your preference as some of it. But yeah, I would say in terms of what I see in terms of usage, it seems to be more towards that label property graph. Anything else, Shannon? Are we kind of... Oh, yeah. So here, I'm just talking the new button again. You know, so we've got a lot of questions coming in and so on. So how well do graph databases scale horizontally? I'm not sure what they mean by that question. Maybe they could put more context in that of a use case of what they're asking. Yeah, so maybe if the questioner could throw something in there to help explain, I will look for that and come back to that. So what modeling tools are used for graph database design? Also, how do you operationalize this? So often the... Sometimes it is a text-based kind of layer on top of it. Some of the tools themselves have their own kind of UI to do this. And so operational is fairly... I wouldn't be scared of it. I think this is a fairly, you know, especially with some of these tools that have been on the market, they make it easier. Some are more code-ish based than I would like. So I think partly because these are new, I would take a good way for the industry to improve. Like just think of relational databases, right? Since we're all... Many of us are familiar with that. In the old days, you had to code, you know, DDL and kind of code the information, both from the, you know, things like data modeling tools like Erwin and ER Studio and those sort of things can do a lot of that graphically, as well as some of the querying tools are now more graphical. I think graph is a little bit behind. I think StarDog is one. I think they're very text-based. But some of the others have a bit better user interfaces, but it's still probably more text-y than I would like. And partly it's just adoption. Things get easier. You know, think of SQL. It was always written. And now there's a lot of great tools that can do joins for you and things like that. So it's an evolution. Well, thank you. So I'm waiting for a couple of clarifications. But a big part of DWH is sourcing the data, the ETL. When using graph databases for analysis, surely you'll need something similar. I need to read these because I... So sorry, big part of data warehousing is sourcing the data, right? So the ETL. So when using graph databases for analysis, surely you need something similar to that. Yeah, you do, although it's a bit of a different paradigm, at least in the use cases that I mentioned. So let's go back to one of those pictures where we sort of had this idea of, you know, part of what you're doing in ETL is really making that transformation. So I want this in a certain format. You know, in the sense that some of what you're doing is data cleansing in a warehouse, which hopefully you don't have to because eventually your source systems will be great, then yes. But here, you know, you're actually trying to translate and put in a certain structured format before your report. With some of these, you know, the graph layer, a lot of it can be, especially if you say we're looking at some of this, you know, social network pattern analysis, I'm not defining the link between that as closely. So it's a bit of a loose link. It really is more of a thing-lace-to-thing versus I'm taking field X, transforming it a certain way, popping it into field Y with this particular lineage transform. It's more just links between, which is kind of it can be a pro and con because this is sort of that the flexibility of this is sort of the beauty of it. So again, you can use a lot of things for a lot of things. The beauty of this is, I would think if you're going ETL, sort of the ETL and relational database tools are fine. I think when you're trying to do those more loose connections or just more flexible and dynamic connections, that's where the graphs can come in nicely. So what strategies do you use to populate a graph database? It sort of depends on how they're being used. I'm going to use it for an operational. So I guess the range of population is sometimes it's putting a graph on top of existing data, maybe. So it really sort of depends on how you're using it. But whether it's sitting on an operational store or you're putting your data into a graph to do the analysis, which is a lot of the use cases I'm using are sort of some of that post-processing where you're just saying, this data for the social network existed. I'm porting that into the graph and then doing the analysis on that, which is very different than I'm actually typing this into a graph, which I probably wouldn't have in an operational system. Although I'd be curious for the person who did say that they used it operationally, kind of how they were doing that. I'd be curious. Yeah, and there's a question here related to the paper that you did. And I'll include a link to the paper as well for everybody. Can you comment on the use case of metadata management with graph DBs, which has the highest percentage used as per the poll? Yeah, so just to clear, when we did the white paper, we just asked, it was more of a binary, are you using it or are you not? We'll be doing another one this year. And given the popularity of graph, we may ask that question to see why. So the feedback we had was just from this group, metadata. So anyone who kind of wants to talk that through can talk, but I can talk to it in general. So when you think of metadata management, a lot of that is thing related to things. So I want to see, and again, it's not just a thing related to things. I can say here's a piece of information and metadata is so fluid. Who's the steward of this? What is linked to it in terms of storage? So one of my colleagues actually built their metadata repository. It was on Neo4j. And what she liked about it was that she could just, because metadata, there's so many types of metadata linked to a thing. I have a table. Who's the steward? Who is the owner? What other fields are related to? Where's the documentation? It's not as formal constructs as you may have in a relational. And that could be a pro and con. So some metadata repositories have that formal construct. Here's a table and here's all the columns. Here's all the definitions of the columns. There's a place for that. But as core, sometimes metadata is much more fluid. And these are all of the sort of tagged things around it. So in that case, a graph database is very handy that way, because you can just sort of add things in a more dynamic way, which as metadata evolves, that can be very nice. So you don't have, you know, a lot of, there's industry standard metamodels. And if you may, my metadata repository, it has kind of data warehouse metamodel. With graph, you can still get, you know, the ontology on there and some structure, but it's a bit more fluid. I think that's kind of a neat use case for graph, because of its flexibility there. So I think we have time for one more question here, Donna. And kind of going back to one of the original questions that we, the questioner had, defined it a bit more for us. The use of the total borrower exposure calculation is based on the relationships of a single individual when he or she wants to borrow money. So that was the original pose. And then total borrow being an individual borrowed in the U.K., then in U.S., then in Iran, and then in Afghanistan, and then Pakistan, et cetera. Should this raise a red flag? Oh, and then I'm more familiar with total borrower exposure, then that just sounds like a great use case, right? Because it's not just that I have a particular rating, or I can see this too when folks do something like a security clearance, right? It's just as me, but if I'm in debt and I have a relationship to people that may have influence over me or the fact that I do have a relationship or I have a company, and that company's gone to bankruptcy and all of that. So yeah, that's a great use case to kind of see these patterns, not just the pieces of debt you have that I took out, this loan with this particular organization, and I know this limited information is more the connections between it. So yeah, thank you for that clarification, because I think from what it sounds like, that's a great use case for this type of technology. All right, well, that does bring it up. Are there some additional great questions here, Donna? Maybe I can send them to you and we can get some... Yeah. Just for the follow-up, that'd be great. Yeah. So thanks everybody for being so engaged in everything we do and for all the great questions. And Donna, thank you for another fantastic presentation. That is all the time we have for today. Again, I will send a follow-up email by end of day Monday with links to the slides, links to the recording of the session, as well as information with the link to the demo and the white paper or the research paper that Donna was talking about and additional ways you can reach out to Donna. And we hope to see you next month in May, as Donna's highlighting there. And I hope everyone has a great day. Thanks so much. Thanks, Donna. Thank you. Bye-bye. Bye.