This chapter considers the relational algebra operators materialize, sort, groupby, and mergejoin. These operators materialize their input records by saving them in temporary tables. This materialization allows the operators to access their records multiple times without recomputation, which can result in query implementations that are much more efficient than could be achieved using only pipelined operators.

This chapter studies two components of the database engine: the log manager and the buffer manager. Each of these components is responsible for certain files: The log manager is responsible for the log file, and the buffer manager is responsible for the data files. Both components face the problem of how to efficiently manage the reading and writing of disk blocks with main memory. This chapter examines their memory needs and the memory-management algorithms they use.

The next three chapters examine how database engines execute SQL queries. The issue is that an SQL query specifies what data to return but not how to get it. The solution is for the engine to implement a set of data-retrieval operators, known as relational algebra. The engine can translate an SQL query to a relational algebra query which can then be executed. This chapter introduces relational algebra queries and their implementation. The following two chapters will examine the translation of SQL into relational algebra.

In this book, you have seen many examples of pages that are customized by session state values. For example, the SQL source query of a report is a good candidate for customization, as is an SQL statement in a process that accesses the database. A large portion of this customization comes from bound references in SQL statements.

P.O. Box 47877 Olympia, WA 98504-7877 360-236-4700 Credential Verification To be completed by the applicant: Please complete the top section of this form and send it to the state(s) and/or jurisdiction(s) where you are or have been licensed, certified, or registered as a healthcare provider. Instruct them to send the form directly to the address listed above. Note: Credentialing agencies may require a fee to verify a license, registration, or certification. Check in advance to help expedite the process. Applicant Demographics: First Name Middle Last Name

* Covering the traditional database system concepts from a systems perspective, this book addresses the functionality that database systems provide as well as what algorithms and design decisions will best implement their functionality* Describes what Java tools and techniques will best help developers build an application that uses a database system* Contains a fully functional database system that allows readers to examine and modify the code

In this paper we examine the probl of how to give hands-on assignments in a database syst internals course. We argue that current approaches are inadequate, either because they are not sufficiently comprehensive or because they require using software that has a steep learning curve. We then describe SimpleDB, which is software written expressly for such a course. SimpleDB is a database syst in the spirit of Minibase. Unlike Minibase, however, it supports multiple users and transactions via JDBC, and its code is easy to read and modify. We then describe a course that we teach using SimpleDB, and discuss the educational benefits resulting from it.

In this paper we examine the probl of how to give hands-on assignments in a database syst internals course. We argue that current approaches are inadequate, either because they are not sufficiently comprehensive or because they require using software that has a steep learning curve. We then describe SimpleDB , which is software written expressly for such a course. SimpleDB is a database syst in the spirit of Minibase. Unlike Minibase, however, it supports multiple users and transactions via JDBC, and its code is easy to read and modify. We then describe a course that we teach using SimpleDB, and discuss the educational benefits resulting from it.

Many database applications require the storage and manipulation of different versions of data objects. However, current database systems do not support versioning well. Each application area treats versions in its own way, and these ways are usually incompatible with each other. We show how this incompatibility can be resolved by separating the physical, conceptual, and logical levels of versioning. We develop a version specification language at the conceptual level, and a multidimensional specification language at the logical level. By encoding the logical versioning semantics of an application into orthogonal dimensions, we generalize the ideas of historical and temporal databases to arbitrary object-oriented databases. The result is a unified, application-independent treatment of versioning.

An access policy has many aspects, concerning both information and physical execution. Agglomerating them into a single SQL grant makes policies much harder to administer, especially at enterprise scale where administrators need to collaborate. We present a way to specify policies as a conjunction of factors, in a simple, regular way. Each factor decision poses a simple question, and when a circumstance changes, only the relevant factor needs to be revisited. Factors are also help for establishing “safety fences” on an administrator’s work, and for separating (global) information privileges to enable more powerful inference rules. To ease integration into existing systems, factor privileges employ the same interfaces and rules as ordinary SQL privileges, rather than multiple new top-level, awkwardly-interacting constructs (such as “autonomy” and “prohibition”).

The SQL standard specifies authorization via a large set of rather opaque rules, which are difficult to understand and dangerous to change. To make the model easier to work with, we formalize the implicit principles behind SQL authorization. We then discuss two extensions, for explicit metadata privileges and general privilege inference on derived objects. Although these are quite simple and easily implemented, we show how together, they help solve several administrative problems with existing SQL security. This sort of abstraction is also an important step towards having DBMSs that simultaneously support security policies over SQL, XML, RDF, and other forms of data.

Access-control mechanisms in distributed systems can differ greatly. For example , a data warehouse materializes a separate database; the underlying source administrators then grant full privileges on their contributed data to the warehouse administrator, trusting that he will grant appropriate privileges on the warehouse data. On the other hand, federated database researchers have source and federation administrators collaborating to specify the rights of federation users. Research papers have proposed access-control models specifically for federations, distributed-object systems, XML systems, etc.

We extend SQL's grant/revoke model to handle all administration of permissions in a distributed database. The key idea is to "factor" permissions into simpler decisions that can be administered separately, and for which we can devise sound inference rules. The model enables us to simplify administration via separation of concerns (between technical DBAs and domain experts), and to justify fully automated inference for some permission factors. We show how this approach would coexist with current practices based on SQL permissions.

Privileges in standard SQL are unconditional, forcing the grantor to trust the recipient's discretion completely. We propose an extension to the SQL grant/revoke security model that allows a grantor to impose limitations on how the received privilege may be used. This extension also has a non-traditional implication for view security. Although our examples are from DBMSs, most results apply to arbitrary sets of privileges, in non-database software.