CS211 Lecture: Persistence; Introduction to Relational Databaseslast revised October 30, 2006Objectives:1. To understand the need for persistent objects2. To recognize alternative approaches to providing persistence:a. Explicit save/restore (perhaps using serialization)b. The above combined with logging of transactionsc. A database systems3. To understand the fundamentals of the relational model4. To understand the concept of “key” (superkey, candidate, primary, foreign)Materials: 1. Projectable version of simple database + second version of Advises table2. Projectable version of schema diagram for simple database3. Projectable version of schema diagram for lab databaseI. IntroductionA. Thus far, almost everything we have done has involved objects that reside in main memory (RAM) on some computer. This means, of course that those objects "live" only while the program is running, and cease to exist when the program is terminated, either via normal exit or as a result of a system crash, power failure, etc.1. This is a consequence of the fact that the CPU can only directly manipulate information that is stored in main memory. Information stored elsewhere (e.g. on disk) must be brought into main memory before it can be manipulated.2. Note that access times for current main memory technologies is on the order of 60-70 ns. Access time for data on disk is on the order of 10 ms. Since 1 ms is 1 million ns, this is over a 100,000 to 1 ratio!B. Obviously, for many applications this is not sufficient. We need some way to make certain objects PERSISTENT - to preserve them between runs of the program.EXAMPLE: In the registration database example we have used in several labs, there is no persistence mechanism - all courses start out empty when we first run the program, and enroll/drop/grade operations are lost when the program exits. Though we've used the program to illustrate many interesting concepts, as it stands right now it's actually useless! 1EXAMPLE: Which objects in our Video Store system need to be persistent?ASKC. Because this is so important, it turns out there are a number of ways of meeting this need.1. The approach taken by many familiar applications, utilizing a File menu with New, Open, and Save optionsa) This approach is well-supported in Java.(1) If an object is an instance of a serializable class (one that declares that it implements the marker interface Serializable), it can be written to a file opened as an ObjectOutputStream using the stream's writeObject method, and the object can be read back from the same file using the readObject method of ObjectInputStream.(2) You used this approach in the last project in CS112.(3) Your Video store project also uses this approach - except that your "Open" and "Save" operations are done automatically at program startup/shutdown.b) However, this approach has very serious limitations.ASK(1) Data is saved only when the user explicitly uses the Save menu option, or at system shutdown, or - in some cases - automatically at regular intervals by an auto-save facility. If the program crashes or the power is lost, all work done since the last Save is lost.This may be acceptable for applications like a word processor, but is not actually unacceptable for recording transactions in a bank or a video store. (The way your semester project handles this would not be the way a real system would be built.)(2) It the stored database is large, then an “Open” or “Save” operation can take a great deal of time.2. A second approach is to combine the Open/Save approach with some sort of LOGGING of transactions (either to paper or to some nonvolatile storage medium). If the system crashes, the log is used to redo transactions done since the crash.2However, this still doesn't address the problem of the time needed to load or store a large file, and redoing a log can be a problem in its own right.3. A third approach is to make use of objects that reside on disk, with some or all of this information replicated in main memory where the program can use it, and that arrange to update the copy on disk whenever the copy in main memory is changed.This is the approach we will pursue in this series of lectures. Persistence in this sense is typically achieved by making use of some sort of on-disk database management system.a) Accessor operations on such an object actually get the requested information from the on-disk database - (though once it is gotten, a copy may be kept in main memory to avoid repeated trips to disk. (Remember the 100,000 : 1 access time ratio!)b) Mutator operations on such an object actually update the on-disk database.II. Introduction to Relational Database SystemsA. At the outset, we should consider the question of what kind of database system we should use to support an object-oriented program.1. There are database systems known as object-oriented databases, whose structure is object oriented. The entities stored in such databases are objects2. However, most commercial databases use one of several non OO models, of which the most prevalent today is the RELATIONAL model. There are a whole host of good reasons for using a relational database to provide persistence for an OO program, even though the two models are different:a) Wide-scale availability of relational databases.b) Standardization - the relational model and the language most commonly used to access it are standardized.c) Legacy data - many organizations have large quantities of data already stored in relational databases, which it would be nice to be able to access from OO programs.3d) Ad-hoc queries: the relational model allows many operations on a database to be done interactively from a terminal session, without needing to write a specialized program. This facilitates extracting information from such a database as needed, without having to anticipate all possible queries and write software for them.e) Solid mathematical underpinnings: the relational model is grounded in the mathematics of sets and relations, and thus has a sound theoretical basis which we can use to reason about the behavior of relational databases.3. For this reason, we'll devote the rest of this series of lectures toa) Learning about the relational database model b) Learning how to access relational databases from Java programs.4. This is a big topic. (We offer an entire course on DBMS's, and that just scratches the surface.) We will look at only a small subset of it.B. We