PROFESSOR: Regarding the project, project number one, some people ask questions whether you can integrate both the bonus part and the basic part in one user interface. Of course, that's a very good idea, so certainly you are encouraged to do that as long as you have time to complete it. Secondly, about DBD, database definition, database definition must be input from the outside, so I will not take a program where the DBD is wired in. Because you can imagine if the database definition is wired in, it's really not that useful so your program must be able to read in the database definition. However, the format, if you don't want to use my format, you want to define your own format, that is fine with me. It's that my format is simpler. If you want to use your own, be my guest. I have no problem would that. The second project, it seems that people are just getting started. Then we're able to run the new program now? Did you download the program and try it again, Dan? STUDENT: I didn't ever try? PROFESSOR: Did you send me the E-mail? Someone else then. Another Dan? Okay. Whatever. If you have the need to download the SQL program again, these are all on my web site. So just go to -- because you can easily download again. Now today we'll be talking about object oriented database. Now, there are three chapters in the textbook, object oriented database. My notes start out, object oriented programming is really taking off however object oriented database for one reason or another is still not where it should be. So there are experimental systems and those are the extensions of relational database so that it can support some object oriented features. But it seems that what people predict that ODB will replace relational database, that prediction was made maybe ten years ago. It was not come true. The relational database is surprisingly resilient. Perhaps because first of all oracle is really quite successful and also people tend to like the view of database as tables. Rather than going back to collection of objects with connections. I think that it's generally true, people, I'm talking about end users, do not like network type of approach. They are afraid of pointers. So by the same token, there are a little be wary of the object oriented database. So what we'll do is we will condense that into one lecture and of course, when we review, I'll tell you what sections in the three chapters that I'm going to cover. Okay. Now, the main thing about object oriented approach of course is that we have the concept of class and inheritance. That's just the main thing. So the object oriented language that features -- the features are abstract data type, inheritance, object identity. In terms of the database we are talking about all these features in addition to classes, inheritance and object identity. In the notes I give you some intro to concept of objects but those things we can study yourself. Now, why on earth are we interested in object oriented database? Well, main thing is that if you look at what's happening in the world, what's happening in industry, the key is integration. Network creates the opportunities so that we can enabling technology to share and to integrate. So, if we can have the database which will support that in a way that we can easily export, import objects from the database into spreadsheet, from the spreadsheet into our applications spread sheet into our applications and so on so forth, that will really save a lot of development effort and increase productivity. Even when I say that, you certainly realize that it's not just object oriented database that have these properties. Able to see if we use oracle we can these days also integrate with like spread sheet and other things. So in other words, the work is such that integration is not restricted to object Oriented approach, perhaps that's also part of the reason that ODB has not yet dominated, or becomes the dominated approach. Okay. So here the main concept is Referential sharing. In other words, multiple applications, products, objects programs, they can share sub objects. Because of the clarity using object Oriented approach this will make referential sharing much easier and because of the object identity we can easily refer to individual instances of the objects. Now, analogy is of course in the web. So, every, in the web every document can be regarded as an object although those objects are not strongly, but the web page is unique because we can use URL, universal record locater to uniquely identify object instance, in this case an document in the web environment. But the problem there as we all know is that you can create any web page your heart desires, there is no structure. There is no common structure. Whereas object oriented approach will give you that. Another important thing is that it will solve the so-called semantic gap. And we use impedance mismatch. All these are just beautiful words. What it really means is that supposedly if you use the object Oriented approach since you are naming the objects, you are defining the object in class hierarchies as meaningful concept. It makes it easier for the user and designer to comprehend what's in the database. Now, whether that is true or not, is still IFFY. It's difficult to say because I had experience when one time I did consulting job for a company where we try to come up with using object oriented database come up with design of the company database. Even though the group was very small with only five people, they managed to come up with three different designs. So in other words, although you may think it's natural, I mean how many different ways we can all the student class or something, in realty, it is not so. People will see differences differently, just like the royal mess we are in in Florida, whether a ballot is valid, you if to look at it through the sun light, right? It's really getting to be a farce now, don't you think so? I think gore just wants to be president too much. If he try too hard, it make us feel uneasy. I don't know about you. Actually I won't vote for me, but if he came again, he will come again in another four years. I don't know. Anyway. So, okay. So the object Oriented database basically will help us solve the problem of easy interface because there is less overload. The end user and the designer, we are talking the same language. Supposedly. So, what is it about? Basically this object Orientation plus the database capabilities and main thing, the key point is that the data model will be more complicated. Now if you go back into relational database, the relational database to the day model is very clean, don't you think so? Because everything is tabled. You probably will not say the same for the network database. Right? It's not that clean. For the object Oriented database, it is more toward the complex side, the network side than the relational side. Because basically we have to introduce the notion of class and be able to define classes and object in a hierarchical way. Now let's go a little bit deeper into the data model. Like I said, the key difference is that in a relational database, you have flat tables. Okay? Everything is at a same level. You just have tables and tables. That's it's major attraction. Very easy for us to understand. When we talk about the object Oriented database, we are talking about objects, then a set of objects can become a class then you can have class of classes, right? In other words, this notion is recursive. So we can keep on going to have very complex objects. So, a complex object data model is a well we have to abandon what we talked about normal form because in the normal form, we insist everything is atomic, either a number or a string, right? Nothing else. But if you start defining things recursively, can you do that? No. Because if you open up something it may become a class and inside there may be other classes, right? It's rather complex, so we have to abandon the notion of even the first normal form. So basically what you have then will be some atomic values that you -- and you can group them into tuples. You have a set of tuples. If you start there it's relation, but then we can have more general set of tuples and tuple constructers. So more formally, so you can define it recursively, starting from atomic objects and then group them into tuples and then group them into sets and you just keep on going. Now let me just illustrate that by example. Look at the first example. So that's supposed to be maybe a personnel record. So we have two attributes, name and age. Name is John, age is 30. So far so good. We can handle that. And we can even handle that in the relational database model, right? Okay. Look at a second example. So, this is probably to record information about relationships. So name is Mary, and then I have friends. Look at the value of friends. It's not a singleton. Mary doesn't have one friend only. She has a couple of friends. Question, can we put it into relational database? What did we violate? First normal form. Correct. In other words, even at very basic level, not even talking about second, third, normal form we already violate the first normal form which says that everything must be atomic. Here you have a set. Mark and Vicky. It's not atomic anymore. So if I have a relational data model I cannot have this kind of thing. But, you know, object Oriented data model this should be allowed. And I can even have more complex things, namely once I define Mary, mark and Vicky for that matter, I can plug that into another complex structure and so on, so forth. They can become arbitrarily complex. Which means that in the query language, we must have way to query such a complex structure. Okay. To define complex structure I just show you, it has to be done recursively and there are sections in the textbook which use construct similar to C plus plus to show you how this can be done. And I will ask you later to read the corresponding sections. Okay. So granted, this can be done. Now, the next question is, how can we query this database? Which consists of this objects? Well, one idea is that we take SQL, and try to extend it. One reason is because SQL is almost like industry standard, so it's well accepted and well known. So, you know, for a company developing new product, you should always try to find a path of least resistance. So if people are familiar with SQL, let's extend it to see if people like it. Nowadays a lot of people talk about extending SQL, so that we can deal with objects. In fact, even your oracle 8 has some flavor of this object Orientation, okay? But it's really what we call object based not object Oriented. In other words, you can group things together, talking about this, but you don't have the ability to have arbitrary inheritance in both of them. Let's look at something simple. Let's start with maybe a person. Okay. We create a type called person, with a number of attributes. No problem because this still in the framework of relational database model. Right? So we have a type and then there are the attributes. But now look at a query. Select the name of person, P, and P belongs to this type person and where something is true. Select from where. No problem, right? Okay. So the only trick we have now is that now we can introduce those functions like age of P. It translates into the age of person. And name of P of course means the name of the person. Now, as you recall, in standard SQL we will write P.Name and here we will write P.age. You see that? In other words, in the relational model, you have fixed type called tables and each relation as attributes. But not this. This is now a nested function, so the Tate of the address of P. You see that? So this is nice, right? Really extend our language, the state of the address of the person. Okay. So, generally speaking, in the extended language to deal with object Oriented database, things the database itself will have object Orientation, namely complex objects. Then we deal with functions -- to deal with that we allow functions and should be able to come pose nested buttons. Let me show you an example that is rather nice, rather interesting. Okay. First let's just look at that. Which is basically from application point of view. The user's specification of database. So we have a person and employee is a sub type of person. In other words, if you have a more general person called person then the specialized class will be employee and a sales person is sub type of employee. And address have street names, sales people have sales managers, sales managers have secretaries, and secretaries are employees. Okay. If you want to model that in relational database not that easy. We are going create a whole bunch of small tables to do that. The model is something like this. I will explain it to you because this is really extension of the ER diagram. And these days we can use the UML, the universal model language, to define something like that. Okay. So what we'll talk about, let's start with the general concept which is a person. So the person is a type and has the following attributes, name, age, address, which consists of state and street. Okay. So if it is just like that, we have no problem, this is just an entity and its attributes. But now I introduce a sub type called employee. The employee is a person. So they have the relationship which is called "Is a" which is a relationship which defines employee should inherit all attributes of person plus some more. So whatever it takes to specialize employee we can add more attributes. We can add for example salary. Because the employee must have his salary and they could be other things like employee, maybe they have their ID stuff like that. so these are the attributes that the employee class has but the person class does not. We can go further, so we can have a sales person, so the sales person is a employee who is a person and a secretary is a sub class of employee. Okay. And sales person can manage account and the sales manager is a sales person. So look at that, so this is class hierarchy here and sales person, or sales manager can have a secretary. Okay. Although we have no more exercises, I would like to invite to you think about simple problems and be able to capture that in this extended ER diagram. It's not hard the main thing you should notice is that we have this relationship is a when defiance hierarchy and the rest I still similar to the classical ER diagram. Okay. So now let me go back to my example. Suppose I want to retrieve the street name of the address of the secretary of the manager of each sales person whose salary is more than 50,000. Quite a mouthful now. Look at the query. Select, I have whole bunch here but this easy to read. The street name of the address of the secretary of the manager of P. This is not zero, this should be a P. And for each sales person P, so P is the alias for the type sales person and the where class is salary of P is greater than 50,000. Not bad, right? Okay. In other words, by introducing the notion of function, by introducing the concept class hierarchy, you can very succinctly, a complex query, think about what you have to do in relational framework to do the same kind of thing. I can assure you it can be done, it's just that we have to introduce all these relations and these will by a whole bunch of EQUI join to get stuff done. Basically I try to illustrate the power of the object Oriented approach. So you can see that we need to do two things. Number one, have more complex day model. Number two, to have more complex query language. In fact, oracle has already extended the classical relational approach in Beth sides, so it allows us to define, to a limited extent, classes and also it introduce extend SQL language to do that. Okay. Now in the notes I have more details about the notation, what is extended entity relation diagram. And in fact this can be regarded as specialization of UML location. So like I mentioned, the key point is that we introduce now the relationship and then we can extend basic ER diagram to model complex objects. Okay. So from a practical standpoint, this approach of extending the relational database to be object oriented relational database system and extending SQL does make a lot of sense, so this way we can for example, still stay with relational framework, still use oracle but then just take a next release so we can then extend it and still be able to use that. In fact, the other pure so-called pure object Oriented database products have not greatly caught on, so we have to take attitude of wait and see. If you already have a firm foundation of C plus plus, JAVA, these object oriented languages and you have foundation of relational database, you can see that it won't be too hard to introduce the notion of class into defining database and extending query language. Okay. As far as your reading is concerned, like I said, I will send you E-mail to tell you what sections in these three chapters that I want you to read. You may not believe it, but in 20 minutes we covered three chapters. But don't worry. It's not that bad. We will just identify the part to read. Enjoy yourself of the on Tuesday, we are going to talk about something different. Which is data mining. Again, from a practice tical standpoint, very important area. And then we have a break. Okay.