Unknown

[AUDIO LOGO] [MUSIC PLAYING] ANNOUNCER: Please welcome to the stage, Juan Loaiza. [APPLAUSE] JUAN LOAIZA: All right. Hi, everyone. Hope you're having a great show. I see a lot of people here this year. It's really getting a lot of attention, talking about a lot of great technologies. So, today, I'm going to talk about some really exciting technologies because there's some big changes happening in the world of data and app dev. And that's what I'm going to talk about today, the future of data and app dev. So what is it? What's the future of data and app

dev? Well, it's all about enabling radical increases in productivity. And I'm going to get into a lot of detail on this. So how's this going to happen? Really, it's going to be about generating data solutions instead of hand-coding them. So that's the big picture, the very, very big picture. So we're going to generate to innovate. And we're going to use three transformational strategies. One is the generate use-centric data. And I'm going to go into a good bit of detail on this. The second is we're going to generate apps altogether. And the third is that we're

going to get a lot of productivity from generative AI. So I'm going to talk about each of these in turn. So first of all, today, all the parties in the world of data need to tell their data systems not just what they want, but also how to do it. And, soon, they'll simply declare their intended outcome. And the data systems will generate them. So where is each of these parties in their transformation to generating solutions based on declarative intent? Well, the critical parties for the first strategy that generate use-centric data are basically data professionals and

developers. So let's start with them. So data professionals are the farthest along in their transformation. Let's take a very quick look at the journey of data professionals. So, initially, when the world started, at the beginning of the world, we had two kinds of databases-- hierarchical databases and network databases. And in both of these, apps accessed data using hand-coded navigation of storage formats. And then EF Codd revolutionized data management with the relational model, which is based on declarative intent. And there's three main benefits. And I'm going to come back to these because it's going to come

back in the developer world. Number one is that apps access data using data values, the values in the database, not by hand-coded navigation. And, actually, the big advantage of that is that changes to the way data is stored or optimized don't break data, because you're not navigating the actual storage format. You're just looking at the data. Number two is there's no more need for inconsistent copies of data, because data values need to be stored only once. That's called normalization. And number three, relational databases generate access based on declarative intent. So using SQL, the data the

user intends to access and the database-- I'm sorry-- using SQL, SQL declares the data the user intends to access. And the database generates an optimal execution plan. And using SQL, you can also get very powerful joins which are a way of composing data. OK, so that's it. That's what I'm going to say about data professionals. Data professionals are very far along. They're the first to generate to innovate. And the huge productivity gains from generating data access using declarative data intent made relational the market leader. All right, so let's move on. What about developers? In the

world of development, things are very different. So the concepts of app storing data as a hierarchy and network have been brought back by developers. So document and key-value databases are a hierarchical database. And graph databases are like network databases. Now, they're not the same. These are different from their predecessors. But they share some of the same drawbacks. So if that's the case, then why have these concepts returned? Well, the reason is that normalized relational data, while it's fantastic from a data management perspective, which is what I just talked about, it's not always convenient for app

developers. And, therefore, they don't like to use it as much. So I'm going to walk through an example of how this works. So imagine we've been asked to build an app that creates a student course schedule. So it would look something like this. You have the student schedule here for Jill. She's a math major. She's taking two classes, Math 201 and Science 102. It's got a time room and a teacher, so very simple app. Now, with relational, the way you build this is you need a schema with four tables. So you've got a student table,

a course schedule, a student courses that maps the student to the courses, and a teacher table. This is great from a data management perspective because you have storage independence, data consistency, declarative queries, all that stuff I just talked about. And the API for the relational model returns data as rows. So the rows for a student schedule can be fetched in a single query by joining all four of these tables. So you write a SQL statement, joins them. You get the schedule. OK, that sounds pretty good. But the rows are not always convenient for data that's

hierarchical. So hierarchical data, when you read it in a join, it repeats the upper levels of the hierarchy. So you can see there, you have the rows with the two classes. But they repeat a bunch of data-- the student ID, the student name, the major. So you get redundancy in the result. And at the application level, you have to sort all that out. So it's not as convenient as it could be. So this is why developers like hierarchical models like JSON when the data is naturally hierarchical, because it provides an easier API for apps that

want hierarchical data. So you can see on the left there, what the JSON document looks like. All the data that's in that screen is in that one document. You get the student name, the major, and then you have the schedule with the two classes. So it's all there. It's all contained in one document. And the nice thing from a developer point of view is that you can simply get the document. You got all the data you need. It's all in one package. You display it. If you want to change anything, you edit the document, and

you just put it back into the database. So from a developer perspective, this is really nice. And we've recognized that in the relational world too. So to support these applications that want this kind of hierarchical format, we've added JSON as a native data type to the Oracle database and to relational databases in general. And the benefit of that is that a single database now has both relational and document data. And that allows it to provide the benefits of both. So that sounds very nice. But there's still a problem, which is when you store data as

JSON documents, there are some downsides. So all hierarchical storage models suffer from data duplication issues. And this is easy to show with this example. So all the students taking a course have a copy of the course schedule and the teacher information, which makes updates expensive and risky. So you see there, we have two students. And each of them is taking Math 201, which means all that data is duplicated across every student, so the time, the course, the teacher. And what it means is let's say I want to change the room for that class. Well, as

a JSON developer, I have to go find every student taking this class. And I've got to go update the document in every student. And I have to do that in some atomic fashion. And if I ever forget to do it, then the data gets out of sync. And the second disadvantage of storing things in JSON is that SQL on relational data is far more powerful because you're composing tables. It's a much more powerful language for querying data. All right, so there's these downsides. And, today, the way app dev works is you have to pick one

storage model for data. So you pick. Do I want tables? Do I want JSON? Do I want graph? And once you've picked, that storage model determines everything about how data is used. So if you pick JSON, you get JSON operations. You get a JSON language. You get JSON APIs. If you pick relational, you get relational operations. You get relational language. You get relational API. So these became separate worlds where everything is different. So you pick one model, and now everything is different, depending on that first choice. OK, so that's not so good. So this is

the thing that we've been working on. How to unify all these things? How do we avoid all these downsides? And the breakthrough idea is to enable developers to declare data usage intent instead of storage format. So tell us what you want. Don't tell us how to store the data. Basically, that's the high-level idea. If you declare the data usage intent, then the database can generate the format and APIs that are best for each app use case. And I'm going to explain how this works. But first of all, the key thing here is that by using

intent, that's all we need to extend Codd's vision of apps being independent of storage to apps that prefer using data as either a hierarchy or a network. All right, so in this new world, the database can generate the app's preferred usage format. While most of the data is stored in the format that's best for query ability and consistency, which we talked about, which is that's a normalized relational format in terms of reducing redundancy, improving consistency, making it queryable, that's generally the best storage format. But it's not perfect for everything. There's also cases where the schema

is dynamic or evolving, where you want to store data as JSON. And we can do that as well. All right, so, today, going back, there's really two languages in a relational database. There's a data definition language. And that specifies how data is organized. And then there's a data manipulation language, which specifies how data is read and written. But it's all about rows. What it's missing today is a language to declare the usage format that best aligns with each app use case. So there's nothing to say, hey, I want to use this as JSON. I want

to use this as a graph. And so that's what we're going to fill in, in our new generation of databases. So a data intent language actually is in SQL. It exists. It's called views. And views declare the intent to use a combination of data from multiple tables. So it basically runs a query that combines multiple tables and produces a single result. However, the relational views are limited to operating on rows and using row APIs. So they don't really get us what we want. They're good for relational, but they don't get us what we want with

these other kinds of formats. Now, what we're doing is we're introducing something new called JSON-relational duality. And to describe how we can extend the data intent language to include JSON documents, I'd like you to welcome Gerald Venzl, who's our Lead Product Manager for Developer Initiatives, who's going to describe this. [MUSIC PLAYING] Hey, Gerald. GERALD VENZL: Thanks, Juan. JUAN LOAIZA: Welcome. GERALD VENZL: Thank you. All right. So as Juan said, JSON-relational duality views, which are new in Oracle Database 23c, enable Oracle databases to generate JSON format and APIs from relational tables so that you get what

you see there. It's like you have a bunch of relational tables. And you would like to get JSON out of the database. How do we do that? Well, the structure of the duality view mirrors the structure of the JSON document that you want, which makes it super easy to define these by using familiar GraphQL syntax. So what you see here, again, on the right-hand side, you have this JSON document for Student Schedule Jill that we have seen before. And on the left-hand side, you see the DDL to define the JSON duality view to give you

that student schedule, looks very similar. Now, the view itself simply specifies the tables that contain the data that we want. So we want the student schedule. So we start with the student table. And then we traverse to the student courses, courses and teachers. So this is how we get the hierarchy of the document. Next, the view specifies the table columns that hold the values that we want exposed as JSON attributes, the actual data that we're going to see in the JSON document. JSON duality views are simple to query using document APIs. Applications can use standard

REST API GET commands or API calls to get a document from the database, or they could use the MongoDB-compatible API that we have or a plain SQL, whatever the application the developer prefers. Likewise, updating these duality views or these JSON documents in the database is also simple. Applications just added the JSON documents that they got and then do a REST PUT API back to the duality view, or write it back with the MongoDB-compatible API or SQL, again, whatever the application or the developer wants to do. The important part of this is that the database, as

part of the update, automatically detects the changes made to the document and only modifies the rows that have changed. So we don't have to write back the entire document or the entire data set. We only change the values that have actually been changed by the application, which gives you, of course, a big performance boost as well. Duality allows JSON documents to include any data that is convenient for the app. So it's an Oracle database. You may have spatial data in it. You may have graph data in it. JSON, as Juan said before-- oh, of course,

relational. You can expose all that data into your JSON documents via JSON duality views. But, again, the important thing here is that the duality views never duplicate data, because underneath, the data is stored in normalized tables. And that in itself is a massive benefit for other applications that share the same data. So we have here, again, the student schedule for Jill and Lucas both going to this Math 201 class. And the data here still looks duplicated because we have these two JSON documents. But they are not in the database. They're coming out of relational tables.

So if we want to update the teacher, as Juan said before, we can just simply do one PUT operation on that teacher information and swap it out for everybody. And every application will see that data change reflected. And because any data can be included in documents, duality provides better JSON to apps than any document database out there that only gives you JSON. The other nice benefit for developers is that JSON duality views allow the same underlying data to be customized to match the needs of each application or the use case of the application. So let's

say we have a student schedule microservice that we have seen before. We give here a student schedule to Jill. But we probably also want the microservice to tell the teacher when and where to show up. Otherwise, the course will be pretty tough. So we can create another duality view to just expose the information that the teacher needs to go to the right room, giving the right class. The teacher doesn't necessarily need the information about all the students. So we can omit that. And, likewise, we probably need somebody who decides which courses the teacher should give,

so like a course curriculum. So we write another microservice for that. And, again, we have another duality view on the same underlying tables or data to expose just that information. Again, the data is never duplicated. We cannot stress this enough because this is the huge downside with the hierarchical format that you don't have here. And, hence, you also have it always consistent. So all of these, the use case flexibility, no data duplication, always consistent are all huge benefits for application development overall. Using duality, developers can also add new document-centric applications on top of an existing

relational data. So you all probably have existing Oracle databases with a lot of data in them. All you need to do to take advantage of JSON duality is upgrade to 23c. And you can start exposing that data via JSON-relational duality views or add these new document-centric APIs and use cases to your existing data as well. A lot of people think that document databases are the fastest and best to process JSON documents. They are purpose-built database, single purpose. They must be the best thing there because that is their use case. That's what they were built for.

Was actually not true. Duality delivers faster JSON than document databases. Duality views give you better latency for OLTP. They give you better and faster analytics. And they provide automatic parallelization and optimization. So yes, it is really true. Duality is much faster than document stores and key-value stores as a matter of fact. And if you don't believe me, please go ahead, download 23c, and try it out yourself. Duality is also vastly superior to object-relational mapping because it provides an architected simplicity that's built into the database rather than it being an ease of use, glued-on layer, like

an object-relational library or framework that you use in your application. Transactional consistency between row updates and document updates are automatically provided by the database using a new lock-free mechanism or lock-free concurrency model. And deep integration of that new mechanism with database queries, replication, and many, many more make this an ultrapowerful new technology as part of JSON-relational duality. The other thing that a duality view allows you to do or as a developer, they are super easy to adopt. So because the transformation to JSON is centralized in the database itself, duality views can be leveraged by any

application written in any language. You need nothing in the application tier. And if you already have existing JSON documents today, we also allow you to take those existing JSON documents. And the database will transform them into relational tables for you so that you get a head start of what a relational structure-- or the best relational structure for the duality view for the JSON document would look like. As a side benefit of the REST APIs, you also get the benefit that data is now accessed in a single round trip, or you go to the database in

a single network round trip. Often, ORM systems, as they compose the JSON documents or the application objects, they need multiple round trips to the student table, to the course table, to the teacher table, and so forth, incurring multiple network hops to the database. Now, I hope you're excited about JSON duality views. I will hand it back now to Juan to continue this amazing journey of innovation at the Oracle database and you as its customers are on. Thank you very much. [MUSIC PLAYING] JUAN LOAIZA: All right. Thanks, Gerald. I think you did a great job describing

what JSON duality is and how it works and how you define it. And it's really simple to define. That's one of the beautiful things about it. Another thing is a lot of developers, they don't want to create a schema. They just want to start coding. And so we also have a mechanism where they can just write JSON documents out. And at some point, if they choose to, we can basically derive the schema from the JSON documents and create tables and create duality. So we can actually convert back and forth the same data from JSON to

relational. And we can automate that whole process. So, really, it provides the best of both worlds. And one thing I want to mention is I've been in the data field for three decades. And this is a big deal. What we're doing here is we're unifying the worlds of documents and relational and graph and also objects. So these have been separate worlds for a long time. And we're putting them all together. So everything works seamlessly together. And you get the best of everything. You get the consistency, the queryability of relational with all the power and simplicity

of JSON. So this is a really big deal. So one thing I would ask you guys, go back and tell everyone else about this. You're going to remember this a few years from now. You say, hey, I was at CloudWorld in 2023 when this was introduced because this is going to be an industry-wide transition that's going to happen. It really is the next generation of data management, of data science. And you can read their IDC. A lot of the industry analysts that have been around for a lot of years also agree. This is a huge

deal. This is a giant transformation that's happening. OK, so we talked about JSON. Let me talk a little bit about graph. So we can also generate graph access. And that's something we've done now with our new property graph views in Database 23c. So graphs are basically a powerful way to query connections and relationships between data. So you can follow links across vertices and edges. And what property graph views do is they allow you to declare intent to treat data as vertices or edges in a graph. And the example here is suppose I'm a bank, and

I want to discover whether anyone transferred money from bank account B to bank account E through multiple hops. So there's a lot of reasons to do that. You might be looking for fraud or something like that. This is actually quite difficult to query in relational, in SQL. You can do it, but it gets complicated. So you can create, instead, what we call a graph view. And the way a graph view works is you define the tables that represent vertices. So in this case, we have bank accounts. Each row is a bank account. And we say,

hey, each of these bank accounts represent a vertex in the graph. And then you can also define a different table that represents edges. So in this case, you have money transfers. Money transfers from account B to C. There's the amount. Those represent the edges in the graph. And then you do this using a view. And the view is a little bit like the JSON view. You say create property graph view. You tell it the bank account table represents vertexes. The money transfer table represents the edges in the graph. So that's the view. It's about eight

lines of SQL. And once you've defined the view, you can run a graph query. And the graph query basically has this MATCH statement that's kind of a pattern that it walks through the graph looking for that pattern. And in this case, the pattern is looking for, is money moving from bank account B to E? So you write that query. And the database understands what you're trying to do. It walks the graph and gives you the answer. So this is much simpler. So you see here it's about a six line-- you have to learn a little

bit about this MATCH thing. But it's a very simple thing to do. Writing the same query for just the three hop would require 12 joins and three unions to write that in SQL. So it's dramatically simpler. Once you pick it up, it's super simple to do. And so you can convert your tables into graphs and vertices. All right, so now that we have this query language, you can use this against all your data. So all your relational data now, you can create these property graph views on top of and then run graph queries. You can

analyze the data, walk through the edges and graphs. It's all available, all the data you have today. It's super simple to do. And that's what Futurum Group says also. All right, so with Oracle Database 23c, you can have an app where one part of the app can treat the data as relational, while other parts treat the exact same data as a document. And others treat it as a graph. So what you're getting here is this grand unification of all these models. You can get the best of all these worlds at the same time against the

same data. So this is another huge benefit for application development. You get all of it, everything you ever wanted. And I've talked about JSON duality and graph, But there's more than that. We've really tried to fill out the whole declarative usage intent. So there's other things we have in the database, also. We have something called analytic views, which we've had actually for a few years, that declare analytic intent. They make writing analytic queries dramatically simpler. We've added something in Database 23c called domains. And those allow you to declare the data value intent. So you can

say this is a credit card. That's a password. This is a user. This is an email. We also have added something called annotations that declare the table or column intent. And we've added something called change notification directives that declare notifications. So, hey, when this changes, notify that person. So there's a lot of different things that we've added for data usage intent. OK, so everything I've described is available in Oracle Database 23c today. It's production in the Oracle public cloud. It's also available on premises with our Oracle Database Free. And coming soon, it'll be available everywhere

on prem, on every cloud, everywhere else you want it. All right, so to summarize this section, the future for developers is really going to be generating outcomes by declaring usage intent. You say what you want. We'll get it for you. If you want JSON, if you want graph, doesn't matter. We'll do whatever you need. And this delivers huge productivity benefits and produces much simpler and more robust apps. This is a really big deal. All right, Wikibon says, "Developing new apps using a pure JSON or graph model is now like committing to using a basic flip

phone for 20 years." So this multimodal-- the ability to do all these different things at once is like a smartphone. It's much more powerful than what existed before. All right, so that's the end of data usage intent. I'm moving on to strategy 2, generate apps. So we're generating things. And you hear Larry talking about this a lot. So it's low-code platforms that are leading the transformation by generating apps instead of hand-coding them. And low-code platforms, they generate app by using visual tools-- so you draw out what you want-- and metadata. And low code, of course,

when you just draw it out, it's much more productive than coding. And in the past, it's been mostly for generating simple apps. So you have something that looks like a spreadsheet or an order entry form. That's been easy to generate. The challenge for low code has really been generating complex enterprise-grade apps. That's really been the challenge. And Oracle APEX, our low-code tool, has been the leader in addressing this challenge. APEX is really unique in the industry in that it delivers simplicity, the simplicity of low code without limits, which enables using low code to generate enterprise-grade

apps. So you can write an application at any level of sophistication using APEX, even the most complex apps. There is no limit on the scale of users, the mission criticality, interoperability, no limits on anything. And, today, over 2 million APEX apps have been written. And there's about 3,000 new APEX apps written every single day. When IDC surveyed which tools enterprises predominantly prefer for low-code app dev, the results were that Oracle APEX was the most preferred tool. It's more preferred, higher than Power Apps or Salesforce. So it's very popular. It's very powerful. And many of you

here are probably already using it. OK, so with Oracle APEX, we're extending low-code to handle many more app use cases. So this is the work that we've been doing over the last few years. We've added workflows, low-code workflows into APEX. We've done a lot of work on low code for mission-critical SaaS. And what that means is that it'll generate apps that are then configurable by the user. We've added low-code for mobile. So the same app that you use on a browser also can be used on a mobile device, and it's seamless. And we've also added

a lot of work to make the low-code app interoperate with all the rest of the apps with things like GraphQL and JavaScript. So we think, in the near future, the large majority of enterprise apps will be able to be generated using low-code APEX. Now, I've talked about the data usage intent. Data usage intent comes together with APEX. So low-code apps like coded apps often want to use hierarchical and graph formats. So JSON and Graph Duality make it much easier for low-code to generate these apps. And I talked about annotations and domain. Those enable low-code to

generate GUIs that are data value specific. So if you declare something with a domain or an annotation, they declare a credit card, then the GUI will automatically be generated. It says, oh, I know it's a credit card. There's certain pattern to these numbers. There's certain validation I can do. There's certain input forms I can do. Or if you say, oh, it's a password, it knows not to echo the characters. So you declare it in the database that every app that uses that data knows that that's what it is and can generate the appropriate GUIs. With

the right validation, the right certification, it makes it easy to use. All right, here's an interesting quote. It says, "Health care systems are among the most complex systems ever built." And, of course, Oracle now has Cerner. And, of course, health care record system, we're rebuilding Cerner using APEX. And this is one of the most complex apps in the world. And the fact that we can do this is a major validation of productivity and power of APEX. So if we can do life-critical supercomplex apps in APEX, we can do just about anything with APEX. All right,

so I've talked about APEX primarily in the context of OLTP applications. But we're also introducing low-code into analytics. So the Oracle Autonomous Data Warehouse brings low-code to data warehousing. So it includes something called the low-code data studio that uniquely simplifies the full analytic workflow. So we have low-code data modeling with things like semantic modeling, machine learning modeling, graph modeling. We've added low-code data motion. So we have a very open data sharing that can be configured using low-code data integration, GoldenGate, data catalog, all the REST services, low-code data analysis with things like SQL worksheet, notebooks. So

we've added low-code to our data warehouse to make it dramatically simpler and easier to use and more productive for users. OK, so that's generating apps. So we talked about generating data based on usage intent, bringing all the worlds of data together. We've talked about generating entire applications. So those are two giant transformations that are happening right now. There's a third that you might have heard about. And it's called AI. So let's talk about that. So we've seen that declaring intent provides revolutionary benefits for app professionals. Now, AI search and generative AI are creating another revolution

of declarative intent. So using AI, all these different parties are going to be able to search unstructured data and query using natural language. And this is something we're adding to our database right now. Now let's start with searches on unstructured data. So there's a new way to search unstructured data. And it's called AI vectors. And I'm going to talk about what an AI vector is and how it works. So vectors are used to represent the content, the semantic content, the meaning of things like documents, videos, and images. And, physically, what a vector is, is a

sequence of numbers. Those numbers are called dimensions. And they're meant to capture the important features of data. OK, so that's physically what it is. But I'm going to give you an example that's going to make it a lot clearer. So here's an example. I have a picture. I have a picture of a house. How do I represent that as a vector? Well, the numbers represent features that are specific. So, for example, one number in a vector might represent the type of roof. Another one might represent the decorations. Another one might represent the number of stories.

Another might represent the building materials. Like, this is a wood house. So that's the kind of conceptual idea behind vectors. It has a bunch of numbers, usually, a few hundred to a couple of thousand. And they represent the features of the thing that you're trying to represent. Now, what I showed you here is conceptually correct. But it's actually not correct. The world has moved on beyond this. Those features are now not hand-coded. They used to be that people would do, oh, this is the roof. This is the decoration. Those days are gone. The features are

now generated by machine learning algorithms. So it's not quite as simple to say what the numbers represent because those are generated using neural nets. But the concept is still the same. OK, so if I take house vectors and I collapse them into two dimensions instead of hundreds, they might look something like this on a two-dimensional plane. And the key thing to understand about vectors is that the distance between the vectors, when I say how different is this vector from that, that represents the semantic similarity of the underlying objects. So you see here on the upper

left, we have two pictures of houses that are pretty similar. They're the same roof, same kind of roofs, same kind of building materials, same kind of windows. So their vectors would be very close together. On the other hand, in the bottom right, I have that other wooden house, which is quite different from those. So that vector would be very far away from those other two vectors. So the distance between the vectors represents their semantic similarity, not that similarity of the pixels, but what the house actually looks like. And the same thing applies to other kind

of data. So word similarity works the same way. So when you create vectors for words, you'll see that the words that represent fruits, those vectors are close together. Words that represent animals are close together. Words that represent states are close together. But they're farther apart from the different kinds of objects. Now, that's a simple example. What we really use is vectors that represent entire documents. So what is in the document? What's the meaning of the document? What is this document about? Is it about the keynote in CloudWorld 2023? That information is in the vector. And,

again, the vector that represents a document, the ones that are similar are closer together. The ones that are farther apart are distant. So if you have a meeting at some other thing, it's going to be very different from the keynote. The vectors are going to be very separate. All right, so that's the key attributes of vectors and what vectors are. So now that we know what vectors are, let's talk about how they're used. So vector search on unstructured data is normally combined with relational search on business data to solve business problems. Now, here's a few

use cases you can use this technology for. So one use case is semantic document search, search by the content, the actual meaning of the document. So examples like that are, I have a user question. Find me documents that are relevant to this user question. Another use case is a product or catalog search. I describe an object, and it finds it in the catalog. Another one is sentiment analysis. What is that person saying? Is it positive? Is it negative? How do you describe what they're seeing? Another use case for vectors is semantic image search. So face

recognition, is this person the same? It doesn't matter. They have glasses on, not glasses on, different clothes taken from different angles. It can identify that it's the same person because it's not comparing the pixels. It's comparing the actual object. Finding matching objects, finding flaws in objects-- is there a crack in this car? Is there a crack in this window? That's the kind of stuff you can find using these semantic image searches. You can also find similar patterns. So this is useful for things like anomaly and fraud detection. There's a sequence of events. That's fraud. We

look for that sequence of events. Product recommendations-- people that bought this also bought that. People that browse this also did that. That's all represented using a vector that you can find. And trading patterns is another one. OK, so let's go through an example of how this works. So first of all, imagine a house hunting app that helps customers find houses for sale that are similar to a picture the customer uploads. So you're driving around town. That was the video at the very beginning. You see a house you like, take a picture of it. And you're

like, hey, I want a house that's similar to this one. It looks similar to this one that's for sale. So that's the example we're going to work through. Now, to find a match that matters to me, I have to combine that semantic search-- hey, I want a house that looks like this-- with business data. So in this case, the business data is things like product data. The house has to be for sale. What houses are for sale? Where are they for sale? What's their price? And it has to match my preference. I'm only looking for

houses in Las Vegas. I'm not looking for houses in Berlin. That's way too far. I can't commute from Berlin to Las Vegas. And it has to match my budget. I don't care about houses that are double my budget. I don't even want to see them, even if they match the picture. So you need to combine the semantic search, the look of the house, with this business data search. Now, when you're searching on a combination of business and semantic data, it's much more effective if they're stored in the same database together. So one solution is you

take all your business data. And you have a separate vector database. And you just feed your business data into the vector database, so it's available. So they can combine them. Now, that has an obvious problem, which is you're constantly sending all your business data. You have to keep it up to date. You have to keep these two databases going. And the business data that's relevant varies widely. So you have to send a lot of business data. And when you get it to the vector database, they're really not that good at searching business data. So that

has problems. And so we think the best solution is to add vector search to the business database. The business data is already there. You just add the vectors. And then you can do queries against the combination of business data and vectors. And there's no need to move, synchronize data, manage multiple products, all that stuff. And that's something that we're announcing here at CloudWorld this year, which is we're announcing AI vector search built into the Oracle Database 23c. And you can see this in our tech hub. You can get a demo. You can see it in

action. You can also sign up for the preview using that QR code. So I'm going to describe how this works in Oracle. OK, so we're doing the house hunting app. First thing you got to need is a table with all the available houses, with the houses that are for sale. So that's simple. Here's a simple CREATE TABLE statement. You say, create the table of houses for sale. What do you want in there? You want a house ID. You want the price of the house. Where is the house? What city is that house in? You want

a photo of the house. And then that last thing is the key thing. You want a house vector. And that house vector is going to contain the look of the house, basically, the semantic look of the house. What does this house look like? Now you have your table. I want to find houses that are similar to this picture. So I write a three-line query. It's super simple. So I say, select from my houses for sale, all the pictures, all the houses, but order them by the vector distance between the house and the database and the

house I'm looking for. So find me the closest matching houses, the ones that look the most similar to this one. That's it. That's three lines of SQL. You don't have to know anything about machine learning to write that SQL. A DBA or a developer that has minimal experience with a database can learn to use this in a few minutes. I've just taught you how to do it. This is it. This is the full SQL. OK, so that's finding the closest match. But remember, we didn't want the closest match in house because that house might be

thousands of miles away. And I'm not interested in it. So what you really want to do is combine that image search with the business data search. So here's how you do that. In here, we show a five-line SQL statement. You're selecting from houses for sale. But I only want to see ones whose price is in my budget. So I'm getting that budget information from the customer table. And I only want to see houses that are for sale that are in the city that I'm trying to find a house in. So, again, I'm going to search.

I'm going to compare the city that the house for sale is in to the city that the customer is interested in. And then I'm going to order those results, the ones that pass those queries by the most similar houses. So now what this returns is houses in my budget, in my city that look the most like this. So I've combined business data and AI vector data in one query, five lines of SQL, a single integrated solution that's fully consistent. And that's the big win in putting it all together. And it's really important. This is really

important, which is you don't have to be an AI expert. Anybody who knows anything about databases can write this query. It's super simple, which is very different from in the past. And Oracle have had a lot of machine learning algorithms in the Oracle database. But you had to know a lot about AI. You had to know how to create a model. You had to know all the different kinds of models you can create it from. You had to have training data. You had to train the model. You had to set the hyperparameters. There's a whole

bunch of work that you had to do, and you had to know a lot of knowledge about to create that. Now, with this AI vector search, you don't have to know any of that stuff. You just write simple SQL, and you're done. Any developer can do this. Any DBA can do this. It's ultra simple. It's actually much more powerful than what we had in the past, but also a thousand times simpler. Anybody can do this. OK, so that's a key concept. So what did we do in Oracle Database with vectors? I showed you the vector

data type. So what do we have? All you need to know is there's a new type of data. It's just like date, character, number. There's another data type. It's called vector. You put your vectors in there. It's just the column type. I showed you there's a comparison function. There's only one operation on vectors. Compare these two vectors. Compare the distance of the two vectors. That's it. That's the only operation. There's no point in looking at the numbers or doing anything else. It's about a thousand times simpler than implementing JSON or something like that, super simple.

Store the vector. Compare the vectors. Those are the only two operations. And then the third thing that's specific to vectors is we're adding very fast vector indexes. So when you compare these things, you don't want to compare to get every house in the world. You want a vector index that is a new type of index that does very fast comparisons across the vectors. But, again, you don't have to know how this works. You just say, create vector index on this column. You got the vector index, super simple. OK, and then because we've built a relational

database over the last 45 years, we have a lot of technology that we can bring into the vector space. So, for example, you can partition your vector index. So in the example I'm using, you can partition your vector index by the city. So, essentially, that creates a separate vector index for each city. So you're not looking at vectors at all that aren't even in the city that I mentioned. There's no point in looking at vectors for houses in Berlin when I'm looking for Las Vegas. So that happens automatically. It's a standard database technology. Partition your

index by relational column. The whole thing works transparently on Real Application Clusters. So we have our scale-out solution. It's like every other data type. It automatically works across all the nodes of a cluster. The data is fully consistent. Something that's interesting is these vector searches, like that house search that I was showing you, this is an OLTP operation. It happens in real time. So when you say, find me houses, immediately, you get a response. And a vector query will typically respond in a few milliseconds. So it's real time. This is an OLTP operation. It's not

a report. It's not an analytic operation. And one thing you can do with RAC for many years is you can isolate nodes. So if you have your OLTP system and you're worried about, hey, I don't want to add all this weird vector stuff because it might mess up my OLTP, you can just run it on a separate set of nodes. But it can access all the data in the database, something we've been able to do in RAC for years. We can transparently offload vector searches to Exadata storage. So we've had this smart storage. If you're

searching through a lot of data, you send the search to the data. You don't bring the data to the search. This is something we've been doing for years. We're doing it with vectors. You can shard your vectors. So if you have regulations that say, hey, the data for Europe needs to stay in Europe, the data for India needs to stay in India, you can do that. You can use sharding to spread out your vectors to where you need them. You can use it for distributed databases, for higher scalability, for anything like that. And there's all

these other features that come to bear with vectors also. So everything that we've built-- we built parallel SQL, transactions, analytics, disaster recovery, security-- all that stuff applies, which it doesn't really apply when you have a new vector database. They haven't built any of this stuff. All right, so that's what it is, what we've built. What are the benefits of it? Now, adding semantic search to relational, which is what I've been talking about, that's great. But we can take it a step further. What happens if we add generative AI on top of that? Then things get

even more interesting. So vector search plus generative AI enables end users to declare their intent by simply using natural language questions. So you can ask the database things in natural language. And the way this works is that AI vector search maps the natural language question to the relevant data in the database. So depending on the question, it finds the relevant data in the database. And then the user question plus the relevant data is handed over to the generative AI to answer your question. So that's kind of the big picture of how it works. But I'm

going to go through the details now of exactly how this works because this is a big deal. This is a big transformation in how data and databases are going to get used. And we've all used things like ChatGPT, and we've tried it out. My analogy is like a smart college grad. It has a lot of general knowledge about the world. But it doesn't necessarily know anything or a whole lot about your specific products, your specific business. But it's very smart about the general world. So the analogy is imagine you hire a smart college grad to

answer support calls, to answer your company's support calls. Well, it knows a lot about stuff, but it doesn't know anything about your products. It doesn't know what kind of failures other customers have seen, what kind of solutions we've provided them. So it's not going to be very good at answering questions. So when a user asks a question, it's going to say, what happened to my phone? It started beeping, and the battery started going, and I got this error. If you ask generative AI, it's going to be like, I don't know. I don't know anything about

that specific product. But now if you could augment that generative AI's knowledge with all the support information that you've accumulated, all the previous kind of errors that customers have reported, then it could provide much better answers. And that's basically what retrieval-augmented generation does. And that's where the vector databases come in. So the vector database can augment the generative AI by retrieving detailed content that's often private to you that you need to answer questions. And this is called retrieval-augmented generation. So you retrieve business-specific content. And you augment the AI using that content. And the word R-A-G,

RAG, you're going to hear a lot. If you haven't heard a lot already, you're going to hear it a lot going forward, Retrieval-Augmented Generation. That's how the world of data basically meets the world of AI through retrieval-augmented generation. So remember that one. All right, so how does this work? So the end user asks the question. Hey, whatever it is I just said. My phone is overheating. It's beeping, and I get this error. So the first thing that happens is that question gets encoded into a vector. So let's turn into a vector. Now once it's a

vector, I use that vector to search my vector database, to search the vectors in my Oracle database, to match documents that closely match it. So I'm looking at my support documents, past customer issues, past problems that I know about. I'm searching through all that stuff to find the most relevant content for that specific question. Once I find it, I pull it out from the database. And I put it together with the question and hand it to the generative AI. So now generative AI, it's got general knowledge. It has the specific knowledge of past incidents that

are related to this. And it can provide a natural language answer to the question. So that's how this whole process works and how it all fits together. So that's retrieval-augmented generation. And that's how databases work with AI. Now, I'm delighted now to be joined by one of the world's top experts in generative AI. This expert coauthored the paper "Attention Is All You Need," which introduced the Transformers. And those of you that follow generative AI know that Transformers is the groundbreaking neural net architecture that is the foundation of all the generative AI that's out there. So

please welcome Aidan Gomez, the CEO of Cohere, to the stage. [APPLAUSE] Hi, Aidan. AIDAN GOMEZ: Hey, Juan. JUAN LOAIZA: Thanks for joining us. AIDAN GOMEZ: Great to be here. JUAN LOAIZA: So, Aidan, sometimes I talk about this generative AI. It's kind of like magic. You ask questions, then it answers. And he's the magician. He's the guy that does this. He's the guy that invented the magic behind generative AI or one of the people that invented the magic behind. So it's a great pleasure to have you here, Aidan. Can you tell us a little bit about

your company Cohere and a little bit about your background also? AIDAN GOMEZ: Yeah, of course. So my cofounders and I, Nick and Ivan and myself, we started the company about four years ago. And before that, I had been at Google Brain, which is Google's AI research lab. And I was part of the team that created the Transformer, which is the backbone of this latest revolution in AI. And what Cohere does is we build two different types of models. So the first type you might be familiar with, thanks to the chat bots that are on the

internet and available to consumers, it's called generative models. The second type, which was just introduced, are embedding models. And what these do are they transform text into vectors, which can then be fed into a vector database. And yeah, that's us. JUAN LOAIZA: Yeah, so you're the guy-- so he's the guy that takes the image, takes the document, and does the magic to convert it into a vector, which is a bunch of numbers, but not just any numbers, the numbers that represent the semantic content of the object. So OK. So that's great. So that's how you

interact with vector databases. So what high-value AI use cases is Cohere used for? AIDAN GOMEZ: So one of the most popular use cases is knowledge augmentation. So for instance, when you have knowledge workers, oftentimes they have to conduct this really laborious research process, which can take weeks or months. They get a question that needs an answer. They need to read 100 documents to get an answer to that question. With knowledge assistance, what we can do is have the model do that for them. And so they can ask that question to the model. The model has

access to the entirety of the internet. And now thanks to vector databases and RAG, they can also have proprietary information, do that research for you, synthesize it, distill, summarize, and then come back with a verifiable answer. JUAN LOAIZA: Wow, that's amazing stuff. But are there any challenges that organizations are seeing with generative AI? AIDAN GOMEZ: Definitely. So generative AI is amazing. And the progress is staggering. But there definitely are challenges. For instance, the major one that I'm sure a lot of you know about is hallucination. So these models can make up stuff. They can just

dream up facts which aren't actually accurate. And that's a huge issue in terms of being able to trust and rely on the underlying technology. JUAN LOAIZA: Yeah, yeah, I mean, that comes up a lot. And we talked a little bit about RAG. Tell us how RAG helps with that. AIDAN GOMEZ: Yeah, so RAG is the most promising solution to the issue of hallucinations. It gives you two different things. The first is reliability. So now, instead of just needing to take the language model's output on its word, what you can do is because the model is

going out querying, pulling back documents, and using that as part of an answer, it can cite. It can cite exactly where it drew that information from. And so the humans can verify. They can trust this model. The second major benefit is the fact that these models, when they're initially trained, they're trained on the open web. So they only know what's publicly available out on the internet. That's not really relevant for a lot of enterprises. You want to be able to leverage your internal IP, your own data and do that in a way that's completely secure.

And so by being able to use RAG to sit these models down next to your internal databases, your data stores, what that model is now able to do is know everything that your organization knows. And that creates a much more useful user experience. JUAN LOAIZA: Yeah, definitely. I compare it to cramming before a test. You get the relevant information. And, suddenly, it's fresh in your brain. I have another question for you, which is, what's the difference between training on all your documents versus using RAG? Like, why would you do one or the other? AIDAN GOMEZ:

Yeah, so training is very good at changing the personality of the model, making the model speak in your brand voice. But it's not so great at adding knowledge. If you want to add knowledge and you want to keep it up to date on a daily, hourly, millisecond basis, you can't do that with training. You can't retrain every millisecond. But what you can do is you can update your databases every millisecond. And so this keeps your models fresh, always up to date. And you can constantly change their knowledge base. You can pull out things if you

don't want it to know that. You can add new things in. And so the model is always up to date. JUAN LOAIZA: Yeah, that's a great point. And in that house hunting model we talked about, if a new house comes on the market, boom, it's instantly available. If a house gets sold, you can take it off instantly. You don't have to retrain a model and wait a week, a month, or something for that to happen and spend millions of dollars on the training. So yeah, that's a big deal, which is why retrieval-augmented generation is going

to be a big deal for the database world. So a super amount of cool stuff, it's very transformative. What are you looking at for the future? What's your next thing that you're going to do? AIDAN GOMEZ: Yeah, so there's a lot that's coming down the pike. But the thing I'm most excited about today is the introduction of our new embeddings models. And so, hopefully, as you can see on the screen, we've just introduced our latest embeddings, which, frankly, blow the competition out of the water, specifically on data sets that are more heterogeneous that include multiple

different sources of data. They might be a little bit noisy. In that case, we perform about twice as well as the competition. And it's not just accuracy. It's also speed, scalability, and efficiency. So during the training of this model, we specifically focused on being able to compress them. And we can do that 32-fold. And so compressing these models 32 times over preserves 96% of the accuracy. Yeah, super excited to have that in there. JUAN LOAIZA: Yeah, that lowers the costs, gives you faster results. AIDAN GOMEZ: Yeah. JUAN LOAIZA: And as we mentioned, this is a

world where people want results immediately. So you do the search. You want the result right now. You don't want it five minutes from now. You're driving around the town. You need the result right now. So that's very cool. And the noisy data, maybe describe a little bit-- what does it mean noisy data? AIDAN GOMEZ: Yeah, so oftentimes your data sets aren't necessarily clean. They contain perhaps different sources of knowledge coming in from PDFs scrapes, which have their own particular formatting errors from the scraping process, and also maybe some emails in there which look entirely different.

With embedding mechanisms of the past, those would be treated as quite separate. And so the results that you would get for a query would be missing parts of the information because they'd focus over here. What we've done as part of our training is bring that together, unify it. And so no matter how noisy or different the structure and formatting of these databases are, you're able to get extremely, extremely accurate results. JUAN LOAIZA: It's real-world problems, solving real-world problems, which we love. We love solving real-world problems. So, hey, thanks for joining me. We're really excited about

our partnership with Cohere. AIDAN GOMEZ: Likewise. JUAN LOAIZA: And we wish you great success. AIDAN GOMEZ: Thank you so much. [MUSIC PLAYING] JUAN LOAIZA: Yeah, we call this embedding. Converting things into vectors, doing these generative AI, this is real magic. And it's great to meet a real magician. All right, so we talked a little bit about RAG this Retrieval-Augmented Generation. But generative AI can be used for a lot of other things also. And we're working on a number of different projects to improve productivity using generative AI. So one of those is to enable developers to

declare intent using natural language. So with generative AI, developers are going to be able to generate SQL queries using natural language. And the process conceptually is pretty simple. The developer, instead of writing a SQL statement, he states what his desired data is. Hey, give me the sum of the sales for this product over the last quarter and compare it to the quarter before, something like that. The database then takes that and retrieves the schema and metadata that are needed to answer that query. And then we take that schema and metadata along with the user's question

and hand it to the generative AI. And then the generative AI uses that bundle of content plus the description to generate the SQL query. So this is something we're very actively working on at Oracle. And we already have it. We're demoing it in the tech hub. And we're going to continue to make it better. Another thing is that with generative AI, developers are also going to be able to generate the intended usage format. The stuff that I talked about, the duality views, that kind of stuff will use generative AI to generate those things for you

so you don't even have to write them. And then a third thing is that we're going to use generative AI to enable low-code developers to use natural language to create applications. So using that, our low-code APEX and generative AI, you'll generate application blueprints. So APEX has something called a blueprint, which is basically a description of the app that you want. And so what the generative AI has to do is take your natural language query and just translate it into this language, which is basically an app description language. And, again, it's pretty simple conceptually. The developer

provides a description of the app. We gather up all the schema and metadata that's needed. We take all that, hand it to the generative AI along with the question. And then we especially train the generative AI on this language, this blueprint language for generating apps so it can generate the blueprint for the new app, so very cool stuff. And then, finally, data professionals are also going to use generative AI. They're also using AI today. We've introduced a lot of AI technology. And the main thing we're using AI today for is to free data professionals to

pursue intent. So, for example, we have our Autonomous Database that uses AI to eliminate things like routine management, like patching, security scaling. We've done a lot of work on using AI to find and fix workload issues, find and identify any kind of slowdowns, any kind of, looking forward, things that we think might break or might exhaust. So we're using the AI technology internally to free database professionals to go do work with application developers to develop applications faster because that's where the real productivity is coming from. OK, so we've talked a lot about these benefits of

AI. Are there limits to this? How far can it really go? How far can you get with generative AI? Can generative AI actually replace experts? Do you need experts anymore? Well, you really do still need experts because generative AI can't really generate a complete solution. What it really does is generate a first draft. And then an expert has to come in and understand that first draft, whether it's the SQL statement, the app. And then they have to validate that it's correct. They have to correct it if it's not. And they have to evolve it as

the future goes on. And to get a little more specific, will generative AI be able to generate the application code that businesses use to solve their data needs. So you hear a lot about code generation. Can you generate the code for an app? Well, there's really two answers to this. First of all, it can't. And second of all-- so to generate a full app might require hundreds of thousands of lines of code. So first of all, I really can't do that. And the second thing is, even if it could-- let's say it could generate 200,000

lines of Java to implement your app. If it generates 200,000 lines of Java, that's going to be handed to an expert. And they have to understand that, verify it, maintain it, and extend it. And that's really not a fun process. That's a lot of code. And they didn't develop it. So it's not a good idea to generate hundreds of thousands of lines of code. So what we see the future as is the AI is going to generate declarative intent. Is that same thing? Tell me what you want, not how to do it. So it will

generate, take your description, and generate a blueprint, like an APEX blueprint that says, here is what you want in the specific language of implementing an app. And, of course, generated apps will be simpler, more reliable and extensible if they generate app blueprints instead of trying to generate 200,000 lines of code that then some developer has to deal with. So let's back up and talk about all the things that we discussed today. What is the future of data and app dev? So first of all, we started by saying that the relational model provides the most solid

foundation for building apps. Why? Because it has very clean logical model. You've got normalized tables. You ensure data consistency. It also has a SQL language, which allows you to declare declarative intent, which is much more productive than writing code. Those little lines of SQL that I showed you would take hundreds of thousands of lines of code to implement. Also, relational database separates the logical model from the storage model. So this enables all sorts of transparent application optimization. So because of that, underneath the covers, we can implement indexes, parallel SQL, denormalization, partitioning, Exadata, all these things.

And the application is completely not affected. So this is the beauty of the relational model. Now, what's happened is some apps and developers say, hey, this relational thing is inconvenient. I don't really like it. What I really want to work in is in terms of JSON or in terms of graph. And that's created a mismatch between what developers want and what the relational databases provide, which complicates the app dev. So to satisfy these preferences, what the developers want, what's happened is the world of data has split into pieces. So we've created a world in which

there's JSON apps and JSON databases with JSON storage and another world in which there's graph apps and graph databases and graph storage. And then we have the traditional relational database. So the world of data is split into these worlds that don't talk to each other and are completely separated. And what we're doing with duality views is we're bringing all this back together. We're bringing back app dev together. We're bringing back data together. So the idea is that the JSON duality and graph views generate the app's preferred format. And, of course, we've built this. This isn't

just some layer on top of the database. It's built into the core of the database. We've built special transaction processing models, special optimization models. All right. And what this allows is much more flexibility. It's much more powerful for developers, because they can choose the preferred format by use case, and we'll generate. So if you have a single app, that app can choose to write part of it's data access using JSON, part of it using relational, part of it using graph. You don't have to pick one storage format. And that determines everything. So you get the

ultimate in flexibility. You get use-centric data. And use-centric data enables simpler application development. And on top of that, we're generating apps using low-code to accelerate productivity. So the APEX low-code builds on top of these duality views. And it delivers simplicity without limits for enterprise apps. So that's the low-code on top of that. And then on top of that, we add AI to further accelerate productivity. So there's a number of things we've done for AI. I've talked about we've added AI vectors as a native data type, first class data type into the Oracle database. You can

combine the vector search, the semantic context search with business data search to get true business results. And then you can layer the generative AI on top to allow things like natural language questions, generating JSON duality, generating SQL, generating APEX blueprints. So all these things that I've talked about work together. Those three transformational changes can all be layered on top of each other to create a massive improvement in productivity. All right, so these are the key takeaways for today. Number one, we're entering a new age where we're getting more and more declarative intent up the stack.

And it's accelerated by AI. Number two, all these different kinds of users will generate solutions instead of hand-coding them. Hand coding will become rarer and rarer. And number three, all this together is going to enable radical improvements in app dev productivity. These are huge changes that are happening in the world of data. And they're all coming together. And over the next few years, we're going to see the world completely change in terms of data and app dev. All right, so thanks for coming today. I encourage you to embrace these changes to reap the rewards. And

there's a lot happening here at CloudWorld. You can go to our database world lounge on the third floor. And you can talk to our experts in person. You can go over to the tech hub. And you'll see a lot of this technology that I've talked about being demoed. How do you use generative AI, vector databases, duality views? You can see all that in action, ask questions, get familiar with it. Or you can use this QR code to get a lot more information. All right, hope you enjoyed this today. And thanks for coming. [APPLAUSE]