Introduction to Relational Databases

Lesson Overview

We start off quickly looking at the notion of "database" and consider the simple relational database model of tables with tuples (rows) and attributes (columns). A popular way to design a database is through ER diagrams, and we look at a sample diagram.

Though it is important to have some basic understanding of the relational algebra, in practice most users take advantage of a higher level language for retrieving information from a database, and we look at SQL (Structured Query Language) as a common example. Finally, I motivate the use of Microsoft Access, a popular relational database system, and follow-on with a detailed tutorial on how to use Access.

Basics

The term database, we mean a logically coherent collection of related data with inherent meaning, built for a certain application, and representing a "mini-world". A database management system (DBMS) is software that allows databases to be defined, constructed, and manipulated. Here we will very briefly consider the relational model with Microsoft Access as an example DBMS, as a background basis in understanding how java can work with databases.

The Relational Database Model

There are three typical implementation models of databases: hierarchical, network, and relational. Each is based on the notion of data stored as a set of records (imagine a set of file cards, for example). Hierarchical (e.g., IMS) and network (e.g., IDMS) models are based on traversing data links to process a database; they are typically used for large mainframe systems and are not considered further here. We focus on relational database management systems (RDBMSs). They have become popular, perhaps largely due to their simple data model:

Data is presented as a collection of relations Each relation is depicted as a table Columns are attributes Rows ("tuples") represent entities Every table has a set of attributes that taken together as a "key" (technically, a

"superkey") uniquely identifies each entity

For example, a company might have an Employee table with a row for each employee. What attributes might be interesting? This, of course, depends on the application and use the data will be put to, and is determined at database design time. In our example, we might have a payroll application and need salary and mailing address information.

Just as a side note, the notion of view can be useful. Imagine that a company maintains a database of its employees -- there might be a lot of attributes like age, salary, emergency contacts, appraisal, etc. There may be needs to look at the database for different applications serving different users. The company may need to make available demographic data, for example, to a governmental agency. Only some of the attributes need be supplied - and others ought not to so as to protect privacy. Different views can be provided into the same data; in a RDBMS, a view can be seen as yet another table.

ER Data Modeling

Just a few words about design. How do you go about designing a database? It is useful to build a high level conceptual data model where we depict the entities that we are dealing with, their various attributes, and their relationships. An entity is some object with a real or conceptual existence in the world -- "tofu", "Advanced Java Class", "Folger Museum", "Elaine", "company", for example. An attribute is a property of an entity -- "address", "size", "mother", "age", for example. As mentioned above, a relational column is an attribute. A relationship defines roles in which entities work together -- "Bill WORKS-FOR Motorola", "jbs TEACHES advanced-java". RDBMSs represent relationships as tables. A side note for those already familiar with normalizing databases - ER design has been shown (Eugene Wong) to give relations in third normal form. Also, ER diagrams can be mapped not just to RDBMS, but also to the network and hierarchical models.

It is relatively straighforward to represent a database design in graphical ER Diagrams, where rectangles represent entity types,

diamonds relationship types, and ovals attributes. Underlined attribute names represent keys. Here is an example ER diagram:

The Relational Algebra vis-a-vis The Relational Calculus

The Relational Algebra

E.F. Codd's work that inspired RDBMSs was based on mathematical notions, so it is no surprise that the theory of database operations are based on set theory. If you are math-averse, don't be "scared" by this section; you can safely skim or skip it, but see if the Select and Project operators make sense, and review the Join diagram. The Relational Algebra provides a collection of operations to manipulate relations. It supports the notion of a query, or request to retrieve information from a database. There are set operations: Union

Given two "union compatible" (having the same tuple types; "UC") relations, it returns a new relation consisting of the set unions. ("Howard is the new president of the merged companies A and B and wants to see the total set of his employees: A.EmployeeTable OR B.EmployeeTable")

Intersection Create a new relation by intersecting two UC relations. ("Amy wants a table of all organizations that are both vegetarian and raw foods in their orientation: A.VegetarianOrganizations AND B.RawFoodOrganizations")

Difference Return the set difference of two UC relations. ("Laurie wants to look at a table of all restaurants in Chapel Hill that serve vegetarian food but not veal")

Cartesian Product Not widely used but typically do a Join operation (see below); takes two relations that are not necessarily UC and creates tuples with combined attributes -- R(AttrR1, AttrR2, ... , AttrRi) x S (AttrS1, AttrS2, ... , AttrSj) results in Q with Ri+Sj attributes, Q (AttrS1, AttrS2, ... , AttrSj, AttrR1, ... , AttrRi).

There are also more widely recognized pure database operations. To be sure symbols show up regardless of browser, I will use O for the sigma operator, P for the pi character, and 8 for a "bowtie" (look at the 8 sideways) join operator character. Select

Ocond (R) applies condition cond to relation R to return a subset of tuples of R. Essentially, you are selecting rows from a table by applying a test based on the relation's attributes. Thus, we can select from our Employee Table all employees where City="Chapel Hill" and (Salary > 100000 OR Salary < 50000). Note that since the entire row is selected, the resulting table still has unique keys.

Project P attrlist (R) selects columns with attributes in attrlist from relation R. We might have a huge employee table with many attributes we don't want to see, so we can look at a more directed projection of, perhaps, just SSN and salary. (If one of the attributes is not a key, potential duplicates are discarded.)

Join This is probably the most complex operation, and it consists of a cartesian product followed by a selection on some formula (F in the diagram below). R1 8cond R2 computes a cartesian product of relations R1 and R2 to give an intermediate table (with attributes from both of the input tables), then it applies condition cond to select a subset of rows from the intermediate table. In the illustration below, we work with an abbreviated version of the Employee Table and a new Department Table to find all records about a particular department. From the intermediate table consisting of the 5 x 5 = 25 entries: jbs 010-00-1111 A32 A09 Multimedia Projects jbs 010-00-1111 A32 A11 Software Reuse jbs 010-00-1111 A32 A21 New Department jbs 010-00-1111 A32 A32 Java Applications jbs 010-00-1111 A32 B01 Accounting wms 033-53-3902 A32 A09 Multimedia Projects ... jbs 505-47-8901 A09 B01 Accounting

we select those records where Dept is A32.

Phew! Just a few more points. We have described the most general join, called a theta join, where the condition can be complex. Typically, the condition is simply testing if a set of attributes equal a set of values (att1 = val1 & att2 = val2 & ...); then we have an equijoin. (The next sentence is false. The previous sentence is true. Just seeing if you're with me!) Finally, a semijoin, also common in practice, is a subset of tuples of the first relation that participate in the join with the second relation; it is represented with a "bowtie" operator where the right-most vertical line is missing. In our example above, were it a semijoin, the result would just be the subset of Employee Table2 consisting of the first two records. Still with me?! We skipped some additional operators like natural joins (really just a notational shortcut for equijoins), set division (very rarely used and rather awkward!), outer joins, outer unions, and aggregate functions (mathematical functions applied to values in a database - e.g., average age calculated from an age attribute, or count of records). The basic message I hope that you got is that the relational algebra allows one in a set theoretic fashion to retrieve information from a database. As end users we would probably prefer to be less mathematical, and that's where the Relational Calculus comes in!

The Relational Calculus

The Relational Calculus is a formal query language. Instead of having to write a sequence of relational algebra operations, we simply write a single declarative expression, describing the results that we want. This

is somewhat akin to writing a program in C or java instead of assembler, or (in the spirit of real world examples!) telling the babysitter to call with any problems instead of detailing how to pick up the phone, dial numbers, etc. The expressive power is identical to using relational algebra. Many commercial databases use a language like ... like ... (this is the keyword you were waiting for - sorry you had to wade so far!) SQL (finally!) -- Structured Query Language -- or even a language like QBE (Query by Example) or QUEL (similar to SQL and used for the INGRES RDBMS). A specific relational query language is said to be relationally complete if it can be used to express any query that the relational calculus supports. There are two common ways of creating a relational calculus (both are based on First Order Predicate Calculus, or basic logical operators). In a Tuple Relational Calculus, variables range over tuples - i.e., variables can take on values of individual table rows. This is just what we want to do a routine query, such as selecting all food items (tuples) from a grocery store (table) where all the ingredients (specific attribute) are organic (value), say. In a Domain Relational Calculus, variables range over domain values of the attributes. This tends to be more complex, and variables are required for each distinct attribute. But enough theory! In the remainder of the lesson, we'll take a quick look at SQL and then conclude by looking at some Microsoft Access (which uses SQL) screens. Peanut butter and jelly break anybody?

SQL: Data Definition and Data Manipulation Language

SQL is both a Data Definition Language (DDL) and a Data Manipulation Language (DML). As a DDL, it allows a database administrator or database designer to define tables, create views, etc. As a DML, it allows an end user to retrieve information from tables. It came from an IBM Research project entitled "SEQUEL" where the intent was to create a structured English-like query language to interface to the early System R database system. Along with QUEL, SQL was the first high level declarative database language. In this section, we will just give a few examples of SQL syntax to help suggest some familiarity with the style. For further reference, any number of books can be consulted. Also, SQL is widely used, and a quick search on the web came up with an

excellent syntax reference, as well as a pretty good one and one that presents several examples to teach syntax.

Creating and Updating a Database

In this example that follows, we create a table and insert two records. Note that attributes are positional and are specified in the same order in Create Table, unless a specific ordered attribute list is specified in the Insert Into statement (non-specified values are null). Create Table Song (Title varchar(20) not null, Artist varchar(16) not null, Album varchar(20), Time char(5) );

Insert Into Song Values ("Roundabout", "Yes", "Fragile", "9:35");

Insert Into Song (Time, Artist, Title) Values ("19:35", "Yes!", "I'll be the Roundabout");

Update Employee Set Salary = Salary * 1.2 Where Evaluation > .85;

As you can see, SQL statements look a bit like English. The Delete statement (with a Where clause to specify conditions) removes selected tuples from a table.

Querying from a Database

The Select (no relation to the relational algebra operation) statement is probably the most widely used SQL statement, and it is used to retrieve data from a database. It has many options, and we will again just give a few examples to give a flavor. The most basic Select statement on, say, a table called Bike, is Select * From Bike;This just returns all tuples in the Bike table. We can be more selective and ask for, say, just the attributes Color, Serial Number, and Number of Gears: Select Color, Serial Number, Number of Gears From Bike;This essentially applies the select and project relational operators to the table. We can also apply conditions to be more selective. Maybe we want to look at our inventory of blue bikes with at least 10

gears and see which ones (identified by their serial numbers) have which number of gears, as well as their warehouse location: Select Serial Number, Number of Gears, Location From Bike Where Color = "Blue" and Number of Gears >= 10;We can even retrieve from multiple tables. For each blue bike, let's look at its serial number, location, manufacturer's name, and manufacturing date. We assume we have a table Manufacturer which has Serial Number as key and Date and Name as some attributes. To illustrate a point, let's assume that both tables have Name as an attribute; the value in the inventory on-hand Bike table is a vendor-supplied name, while the value of Name in the Manufacturer table is the name of the manufacturer. Select Serial Number, Location, Manufacturer.Name, Date From Bike, Manufacturer Where Color = "Blue" And Bike.Serial Number = Manufacturer.Serial Number;(Note that we disambiguated Name by prefixing it with the table name followed by a period.) This example is like a relational algebra select-project-join with equijoin condition on Color. Let's look at the SQL for the join example we illustrated above. It is fairly straightforward: Select * From Employee Table2, Department Table Where Dept = "A32";If we want to look at the distinct salaries we are paying to people in department A32, we can use the Distinct keyword: Select Distinct Salary From Employee Where Dept = "A32";These are just a few examples, but I hope that they show the power and relative ease of SQL. It's hard to believe all the theory that we very lightly touched on above lies beneath such straightforward declarative syntax.

Introduction to Access

Microsoft Access provides a graphical user interface that makes it very easy to define and manipulate databases. Let's take a quick peek at a real Access database that I maintain for membership records of an organization that I am involved with. Access allows you to define and then store a set of queries and give these queries names that are meaningful to you. Note the Tables and Queries tabs in particular (Reports is useful for

generating hardcopy output, such as mailing labels).

From this screen, if we select the Design button, we can inspect and modify the query. Access makes it very easy to select records from a database; the user doesn't have to write SQL at all.

If we View the SQL instead of the Query Design, we get something less friendly looking: SELECT DISTINCTROW [TVS Membership].LAST_NAME, [TVS Membership].FIRST_NAME, [TVS Membership].MEMBER_TYP, [TVS Membership].ADDRESS1, [TVS Membership].ADDRESS2, [TVS Membership].CITY,

[TVS Membership].STATE, [TVS Membership].ZIP, [TVS Membership].EXPIRATION FROM [TVS Membership] WHERE ( ( ([TVS Membership].MEMBER_TYP)<>"C" And ([TVS Membership].MEMBER_TYP)<>"1") AND ( ([TVS Membership].EXPIRATION)>Date()-60 And ([TVS Membership].EXPIRATION)< Date() ) ) ORDER BY [TVS Membership].ZIP;Finally, here we see how we can enter new records in the database. We simply double click the name of our table and go to the last entry, a pseudo- placeholder entry for a new record marked with an asterisk in the left column. We just start typing in the field values, tabbing field-to-field. Here you can see a new record being created for Victor the Vegetarian.

Summary

Databases are very commonly used in everyday life. The relational model of databases provides a very simple way of looking at data structured into tables, and there are straightforward techniques, such as ER modeling (though we didn't map the ER to the relational model) to represent a world view from which to build a relational database. We looked at the set theoretic relational algebra that relational databases are based on, and considered the high-level SQL language for users to declaratively specify queries to retrieve information from databases. We looked at a particular relational database system, Microsoft Access, through examples from a real database and a tutorial.

Relational model

The relational model for database management is a database model based on predicate logic and set theory. It was first formulated and proposed in 1969 by Edgar Codd with aims that included avoiding, without loss of completeness, the need to write computer programs to express database queries and enforce database integrity constraints. "Relation" is a mathematical term for "table", and thus "relational" roughly means "based on tables". It did not originally refer to the links or "keys" between tables, contrary to popular interpretation of the name.Codd's original description of the relational model, "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", was published in an IBM Research Report in 1969. A revised version of this paper, the highly acclaimed "A Relational Model of Data for Large Shared Data Banks", was published in Communications of the ACM the following year.[1]

The term Relational Model is widely used by practitioners to refer to the model of tables and columns implemented by SQL. Although this was based on Codd's theoretical model, it differs from it in many details, and Codd fought fiercely against what he saw as deviation from the original principles.[citation needed]

[] The model

The fundamental assumption of the relational model is that all data is represented as mathematical n -ary relations , an n-ary relation being a subset of the Cartesian product of n domains. In the mathematical model, reasoning about such data is done in two-valued predicate logic, meaning there are two possible evaluations for each proposition: either true or false (and in particular no third value such as unknown, or not applicable, either of which are often associated with the concept of NULL). Some think two-valued logic is an important part of the relational model, where others think a system that uses a form of three-valued logic can still be considered relational.[citation needed][attribution

needed]

Data are operated upon by means of a relational calculus or relational algebra, these being equivalent in expressive power.The relational model of data permits the database designer to create a consistent, logical representation of information. Consistency is achieved by including declared constraints in the database design, which is usually referred to as the logical schema. The theory includes a process of database normalization whereby a design with certain desirable properties can be selected from a set of logically equivalent alternatives. The access plans and other implementation and operation details are handled by the DBMS engine, and are not reflected in the

logical model. This contrasts with common practice for SQL DBMSs in which performance tuning often requires changes to the logical model.The basic relational building block is the domain or data type, usually abbreviated nowadays to type. A tuple is an unordered set of attribute values. An attribute is an ordered pair of attribute name and type name. An attribute value is a specific valid value for the type of the attribute. This can be either a scalar value or a more complex type.A relation consists of a heading and a body. A heading is a set of attributes. A body (of an n-ary relation) is a set of n-tuples. The heading of the relation is also the heading of each of its tuples.A relation is defined as a set of n-tuples. In both mathematics and the relational database model, a set is an unordered collection of items, although some DBMSs impose an order to their data. In mathematics, a tuple has an order, and allows for duplication. E.F. Codd originally defined tuples using this mathematical definition.[2] Later, it was one of E.F. Codd's great insights that using attribute names instead of an ordering would be so much more convenient (in general) in a computer language based on relations[citation needed]. This insight is still being used today. Though the concept has changed, the name "tuple" has not. An immediate and important consequence of this distinguishing feature is that in the relational model the Cartesian product becomes commutative.A table is an accepted visual representation of a relation; a tuple is similar to the concept of row, but note that in the database language SQL the columns and the rows of a table are ordered.A relvar is a named variable of some specific relation type, to which at all times some relation of that type is assigned, though the relation may contain zero tuples.The basic principle of the relational model is the Information Principle: all information is represented by data values in relations. In accordance with this Principle, a relational database is a set of relvars and the result of every query is presented as a relation.The consistency of a relational database is enforced, not by rules built into the applications that use it, but rather by constraints, declared as part of the logical schema and enforced by the DBMS for all applications. In general, constraints are expressed using relational comparison operators, of which just one, "is subset of" (⊆), is theoretically sufficient. In practice, several useful shorthands are expected to be available, of which the most important are candidate key (really, superkey) and foreign key constraints.

[] Interpretation

To fully appreciate the relational model of data it is essential to understand the intended interpretation of a relation.

The body of a relation is sometimes called its extension. This is because it is to be interpreted as a representation of the extension of some predicate, this being the set of true propositions that can be formed by replacing each free variable in that predicate by a name (a term that designates something).There is a one-to-one correspondence between the free variables of the predicate and the attribute names of the relation heading. Each tuple of the relation body provides attribute values to instantiate the predicate by substituting each of its free variables. The result is a proposition that is deemed, on account of the appearance of the tuple in the relation body, to be true. Contrariwise, every tuple whose heading conforms to that of the relation but which does not appear in the body is deemed to be false. This assumption is known as the closed world assumption.For a formal exposition of these ideas, see the section Set Theory Formulation, below.

[] Application to databases

A type as used in a typical relational database might be the set of integers, the set of character strings, the set of dates, or the two boolean values true and false, and so on. The corresponding type names for these types might be the strings "int", "char", "date", "boolean", etc. It is important to understand, though, that relational theory does not dictate what types are to be supported; indeed, nowadays provisions are expected to be available for user-defined types in addition to the built-in ones provided by the system.Attribute is the term used in the theory for what is commonly referred to as a column. Similarly, table is commonly used in place of the theoretical term relation (though in SQL the term is by no means synonymous with relation). A table data structure is specified as a list of column definitions, each of which specifies a unique column name and the type of the values that are permitted for that column. An attribute value is the entry in a specific column and row, such as "John Doe" or "35".A tuple is basically the same thing as a row, except in an SQL DBMS, where the column values in a row are ordered. (Tuples are not ordered; instead, each attribute value is identified solely by the attribute name and never by its ordinal position within the tuple.) An attribute name might be "name" or "age".A relation is a table structure definition (a set of column definitions) along with the data appearing in that structure. The structure definition is the heading and the data appearing in it is the body, a set of rows. A database relvar (relation variable) is commonly known as a base table. The heading of its assigned value at any time is as specified in the table declaration and its body is that most recently assigned to it

by invoking some update operator (typically, INSERT, UPDATE, or DELETE). The heading and body of the table resulting from evaluation of some query are determined by the definitions of the operators used in the expression of that query. (Note that in SQL the heading is not always a set of column definitions as described above, because it is possible for a column to have no name and also for two or more columns to have the same name. Also, the body is not always a set of rows because in SQL it is possible for the same row to appear more than once in the same body.)

[] Competition

Other models are the hierarchical model and network model. Some systems using these older architectures are still in use today in data centers with high data volume needs or where existing systems are so complex and abstract it would be cost prohibitive to migrate to systems employing the relational model; also of note are newer object-oriented databases, even though many of them are DBMS-construction kits, rather than proper DBMSs.A recent development is the Object-Relation type-Object model, which is based on the assumption that any fact can be expressed in the form of one or more binary relationships. The model is used in Object Role Modeling (ORM), RDF/Notation 3 (N3) and in Gellish English.The relational model was the first formal database model. After it was defined, informal models were made to describe hierarchical databases (the hierarchical model) and network databases (the network model). Hierarchical and network databases existed before relational databases, but were only described as models after the relational model was defined, in order to establish a basis for comparison.

[] History

The relational model was invented by E.F. (Ted) Codd as a general model of data, and subsequently maintained and developed by Chris Date and Hugh Darwen among others. In The Third Manifesto (first published in 1995) Date and Darwen show how the relational model can accommodate certain desired object-oriented features.

[] SQL standard

SQL, initially pushed as the standard language for relational databases, deviates from the relational model in several places. The current ISO SQL standard doesn't mention the relational model or use relational terms or concepts. However, it is possible to create a database conforming to the relational model using SQL if one does not use certain SQL features.

The following deviations from the relational model have been noted in SQL. Note that few database servers implement the entire SQL standard and in particular do not allow some of these deviations. Whereas NULL is nearly ubiquitous, for example, allowing duplicate column names within a table or anonymous columns is uncommon.Duplicate rows

The same row can appear more than once in an SQL table. The same tuple cannot appear more than once in a relation.

Anonymous columns A column in an SQL table can be unnamed and thus unable to be referenced in expressions. The relational model requires every attribute to be named and referenceable.

Duplicate column names Two or more columns of the same SQL table can have the same name and therefore cannot be referenced, on account of the obvious ambiguity. The relational model requires every attribute to be referenceable.

Column order significance The order of columns in an SQL table is defined and significant, one consequence being that SQL's implementations of Cartesian product and union are both noncommutative. The relational model requires there to be no significance to any ordering of the attributes of a relation.

Views without CHECK OPTION Updates to a view defined without CHECK OPTION can be accepted but the resulting update to the database does not necessarily have the expressed effect on its target. For example, an invocation of INSERT can be accepted but the inserted rows might not all appear in the view, or an invocation of UPDATE can result in rows disappearing from the view. The relational model requires updates to a view to have the same effect as if the view were a base relvar.

Columnless tables unrecognized SQL requires every table to have at least one column, but there are two relations of degree zero (of cardinality one and zero) and they are needed to represent extensions of predicates that contain no free variables.

NULL This special mark can appear instead of a value wherever a value can appear in SQL, in particular in place of a column value in some row. The deviation from the relational model arises from the fact that the implementation of this ad hoc concept in SQL involves the use of three-valued logic, under which the comparison of NULL with itself does not yield true but instead yields the third truth value, unknown; similarly the comparison NULL with something other than itself does not yield false but instead yields unknown. It is because of this behaviour in comparisons that NULL is described as a mark rather than a value. The relational model depends on the law of excluded middle under which anything that is not true is false and anything that is not false is true; it also requires every tuple in a relation body to have a value for every attribute of that relation. This particular deviation is disputed by some if only because E.F. Codd himself eventually advocated the use of special marks and a 4-valued logic, but

this was based on his observation that there are two distinct reasons why one might want to use a special mark in place of a value, which led opponents of the use of such logics to discover more distinct reasons and at least as many as 19 have been noted, which would require a 21-valued logic. SQL itself uses NULL for several purposes other than to represent "value unknown". For example, the sum of the empty set is NULL, meaning zero, the average of the empty set is NULL, meaning undefined, and NULL appearing in the result of a LEFT JOIN can mean "no value because there is no matching row in the right-hand operand".

Concepts SQL uses concepts "table", "column", "row" instead of "relvar", "attribute", "tuple". These are not merely differences in terminology. For example, a "table" may contain duplicate rows, whereas the same tuple cannot appear more than once in a relation.

[] Implementation

There have been several attempts to produce a true implementation of the relational database model as originally defined by Codd and explained by Date, Darwen and others, but none have been popular successes so far. Rel is one of the more recent attempts to do this.

[] Controversies

Codd himself, some years after publication of his 1970 model, proposed a three-valued logic (True, False, Missing or NULL) version of it in order to deal with missing information, and in his The Relational Model for Database Management Version 2 (1990) he went a step further with a four-valued logic (True, False, Missing but Applicable, Missing but Inapplicable) version. But these have never been implemented, presumably because of attending complexity. SQL's NULL construct was intended to be part of a three-valued logic system, but fell short of that due to logical errors in the standard and in its implementations. See the section "SQL standard", above.

[] Design

Database normalization is usually performed when designing a relational database, to improve the logical consistency of the database design and the transactional performance.There are two commonly used systems of diagramming to aid in the visual representation of the relational model: the entity-relationship diagram (ERD), and the related IDEF diagram used in the IDEF1X method created by the U.S. Air Force based on ERDs.The tree structure of data may enforce hierarchical model organization, with parent-child relationship table.

[] Example database

An idealized, very simple example of a description of some relvars and their attributes:

Customer(Customer ID, Tax ID, Name, Address, City, State, Zip, Phone) Order(Order No, Customer ID, Invoice No, Date Placed, Date Promised, Terms,

Status) Order Line(Order No, Order Line No, Product Code, Qty) Invoice(Invoice No, Customer ID, Order No, Date, Status) Invoice Line(Invoice No, Line No, Product Code, Qty Shipped) Product(Product Code, Product Description)

In this design we have six relvars: Customer, Order, Order Line, Invoice, Invoice Line and Product. The bold, underlined attributes are candidate keys. The non-bold, underlined attributes are foreign keys.Usually one candidate key is arbitrarily chosen to be called the primary key and used in preference over the other candidate keys, which are then called alternate keys.A candidate key is a unique identifier enforcing that no tuple will be duplicated; this would make the relation into something else, namely a bag, by violating the basic definition of a set. Both foreign keys and superkeys (which includes candidate keys) can be composite, that is, can be composed of several attributes. Below is a tabular depiction of a relation of our example Customer relvar; a relation can be thought of as a value that can be attributed to a relvar.

[] Example: customer relation

Customer ID Tax ID Name Address [More fields....]==================================================================================================1234567890 555-5512222 Munmun 323 Broadway ...2223344556 555-5523232 Vijeta 1200 Main Street ...3334445563 555-5533323 Ekta 871 1st Street ...4232342432 555-5325523 E. F. Codd 123 It Way ...If we attempted to insert a new customer with the ID 1234567890, this would violate the design of the relvar since Customer ID is a primary key and we already have a customer 1234567890. The DBMS must reject a transaction such as this that would render the database inconsistent by a violation of an integrity constraint.Foreign keys are integrity constraints enforcing that the value of the attribute set is drawn from a candidate key in another relation. For example in the Order relation the attribute Customer ID is a foreign key. A join is the operation that draws on information from several relations at once. By joining relvars from the example above we could query the database for all of the Customers, Orders, and Invoices. If we

only wanted the tuples for a specific customer, we would specify this using a restriction condition.If we wanted to retrieve all of the Orders for Customer 1234567890, we could query the database to return every row in the Order table with Customer ID 1234567890 and join the Order table to the Order Line table based on Order No.There is a flaw in our database design above. The Invoice relvar contains an Order No attribute. So, each tuple in the Invoice relvar will have one Order No, which implies that there is precisely one Order for each Invoice. But in reality an invoice can be created against many orders, or indeed for no particular order. Additionally the Order relvar contains an Invoice No attribute, implying that each Order has a corresponding Invoice. But again this is not always true in the real world. An order is sometimes paid through several invoices, and sometimes paid without an invoice. In other words there can be many Invoices per Order and many Orders per Invoice. This is a many-to-many relationship between Order and Invoice (also called a non-specific relationship). To represent this relationship in the database a new relvar should be introduced whose role is to specify the correspondence between Orders and Invoices:OrderInvoice(Order No,Invoice No)Now, the Order relvar has a one-to-many relationship to the OrderInvoice table, as does the Invoice relvar. If we want to retrieve every Invoice for a particular Order, we can query for all orders where Order No in the Order relation equals the Order No in OrderInvoice, and where Invoice No in OrderInvoice equals the Invoice No in Invoice.

[] Set-theoretic formulation

Basic notions in the relational model are relation names and attribute names. We will represent these as strings such as "Person" and "name" and we will usually use the variables and a,b,c to range over them. Another basic notion is the set of atomic values that contains values such as numbers and strings.Our first definition concerns the notion of tuple, which formalizes the notion of row or record in a table:Tuple

A tuple is a partial function from attribute names to atomic values. Header

A header is a finite set of attribute names. Projection

The projection of a tuple t on a finite set of attributes A is . The next definition defines relation which formalizes the contents of a table as it is defined in the relational model.Relation

A relation is a tuple (H,B) with H, the header, and B, the body, a set of tuples that all have the domain H.

Such a relation closely corresponds to what is usually called the extension of a predicate in first-order logic except that here we identify the places in the predicate with attribute names. Usually in the relational model a database schema is said to consist of a set of relation names, the headers that are associated with these names and the constraints that should hold for every instance of the database schema.Relation universe

A relation universe U over a header H is a non-empty set of relations with header H.

Relation schema A relation schema (H,C) consists of a header H and a predicate C(R) that is defined for all relations R with header H. A relation satisfies a relation schema (H,C) if it has header H and satisfies C.

[] Key constraints and functional dependencies

One of the simplest and most important types of relation constraints is the key constraint. It tells us that in every instance of a certain relational schema the tuples can be identified by their values for certain attributes.Superkey

A superkey is written as a finite set of attribute names. A superkey K holds in a relation (H,B) if:

and there exist no two distinct tuples such that t1[K] = t2[K].

A superkey holds in a relation universe U if it holds in all relations in U. Theorem: A superkey K holds in a relation universe U over H if and only if and <img class="tex" alt="K \rightarrow H" src="http://upload.wikimedia.org/math/b/f/b/bfb219d24dcd9b45ba8b7740a1adcf9b.png"

The Relational Algebra

1. The relational algebra is a procedural query language. o Six fundamental operations:

select (unary) project (unary) rename (unary) cartesian product (binary) union (binary) set-difference (binary)

o Several other operations, defined in terms of the fundamental operations: set-intersection natural join division assignment

o Operations produce a new relation as a result.

What? Why?

Similar to normal algebra (as in 2+3*x-y), except we use relations as values instead of numbers.

Not used as a query language in actual DBMSs. (SQL instead.) The inner, lower-level operations of a relational DBMS are, or are similar to,

relational algebra operations. We need to know about relational algebra to understand query execution and optimization in a relational DBMS.

Some advanced SQL queries requires explicit relational algebra operations, most commonly outer join.

Relations are seen as sets of tuples, which means that no duplicates are allowed. SQL behaves differently in some cases. Remember the SQL keyword distinct.

SQL is declarative, which means that you tell the DBMS what you want, but not how it is to be calculated. A C++ or Java program is procedural, which means that you have to state, step by step, exactly how the result should be calculated. Relational algebra is (more) procedural than SQL. (Actually, relational algebra is mathematical expressions.)

Set operations

Relations in relational algebra are seen as sets of tuples, so we can use basic set operations.

Review of concepts and operations from set theory

set element no duplicate elements (but: multiset = bag) no order among the elements (but: ordered set) subset proper subset (with fewer elements) superset union intersection set difference cartesian product

Projection

Example: The table E (for EMPLOYEE) nr name salary1 John 1005 Sarah 3007 Tom 100

SQL Result Relational algebra

select salaryfrom E

salary100300

PROJECTsalary(E)

select nr, salaryfrom E

nr salary1 1005 3007 100

PROJECTnr, salary(E)

Note that there are no duplicate rows in the result.

Selection

The same table E (for EMPLOYEE) as above. SQL Result Relational algebra

select *from Ewhere salary < 200

nr name salary1 John 1007 Tom 100

SELECTsalary < 200(E)

select *from Ewhere salary < 200and nr >= 7

nr name salary7 Tom 100

SELECTsalary < 200 and nr >= 7(E)

Note that the select operation in relational algebra has nothing to do with the SQL keyword select. Selection in relational algebra returns those tuples in a relation that fulfil a condition, while the SQL keyword select means "here comes an SQL statement".

Relational algebra expressions

SQL Result Relational algebraselect name, salaryfrom Ewhere salary <

name salaryJohn 100

PROJECTname, salary (SELECTsalary < 200(E)) or, step by step, using an intermediate resultTemp <- SELECTsalary < 200(E)

200 Tom 100 Result <- PROJECTname, salary(Temp)

Notation

The operations have their own symbols. The symbols are hard to write in HTML that works with all browsers, so I'm writing PROJECT etc here. The real symbols: Operation My HTML Symbol

Projection PROJECT

Selection SELECT

Renaming RENAME

Union UNION

Intersection INTERSECTION

Assignment <-

    Operation My HTML SymbolCartesian product X

Join JOIN

Left outer join LEFT OUTER JOIN

Right outer join

RIGHT OUTER JOIN

Full outer join FULL OUTER JOIN

Semijoin SEMIJOIN

Example: The relational algebra expression which I would here write as PROJECTNamn ( SELECTMedlemsnummer < 3 ( Medlem ) ) should actually be written

Cartesian product

The cartesian product of two tables combines each row in one table with each row in the other table. Example: The table E (for EMPLOYEE) enr ename dept1 Bill A2 Sarah C3 John AExample: The table D (for DEPARTMENT) dnr dnameA MarketingB SalesC Legal

SQL Result Relational algebra

select *from E, D

enr ename dept dnr dname1 Bill A A Marketing1 Bill A B Sales1 Bill A C Legal2 Sarah C A Marketing2 Sarah C B Sales2 Sarah C C Legal3 John A A Marketing3 John A B Sales3 John A C Legal

E X D

Seldom useful in practice. Usually an error. Can give a huge result.

Join (sometimes called "inner join")

The cartesian product example above combined each employee with each department. If we only keep those lines where the dept attribute for the employee is equal to the dnr (the department number) of the department, we get a nice list of the employees, and the department that each employee works for:

SQL Result Relational algebra

select *from E, Dwhere dept = dnr

enr ename dept dnr dname1 Bill A A Marketing2 Sarah C C Legal3 John A A Marketing

SELECTdept = dnr (E X D) or, using the equivalent join operationE JOINdept = dnr D

A very common and useful operation. Equivalent to a cartesian product followed by a select. Inside a relational DBMS, it is usually much more efficient to calculate a join

directly, instead of calculating a cartesian product and then throwing away most of the lines.

Note that the same SQL query can be translated to several different relational algebra expressions, which all give the same result.

If we assume that these relational algebra expressions are executed, inside a relational DBMS which uses relational algebra operations as its lower-level internal operations, different relational algebra expressions can take very different time (and memory) to execute.

Natural join

A normal inner join, but using the join condition that columns with the same names should be equal. Duplicate columns are removed.

Renaming tables and columns

Example: The table E (for EMPLOYEE) nr name dept1 Bill A2 Sarah C3 John AExample: The table D (for DEPARTMENT) nr nameA MarketingB SalesC LegalWe want to join these tables, but:

Several columns in the result will have the same name (nr and name). How do we express the join condition, when there are two columns called nr?

Solutions: Rename the attributes, using the rename operator. Keep the names, and prefix them with the table name, as is done in SQL. (This is

somewhat unorthodox.)

SQL Result Relational algebraselect *from E as E(enr, ename, dept), D as D(dnr, dname)where dept = dnr

enr ename dept dnr dname1 Bill A A Marketing2 Sarah C C Legal3 John A A Marketing

(RENAME(enr, ename, dept)(E)) JOINdept =

dnr (RENAME(dnr, dname)(D))

select *from E, Dwhere dept = D.nr

nr name dept nr name1 Bill A A Marketing2 Sarah C C Legal3 John A A Marketing

E JOINdept = D.nr D

You can use another variant of the renaming operator to change the name of a table, for example to change the name of E to R. This is necessary when joining a table with itself (see below).

RENAMER(E)

A third variant lets you rename both the table and the columns:

RENAMER(enr, ename, dept)(E)

Aggregate functions

Example: The table E (for EMPLOYEE) nr name salary dept1 John 100 A5 Sarah 300 C7 Tom 100 A12 Anne null C

SQL Result Relational algebraselect sum(salary)from E

sum500

Fsum(salary)(E)

Note: Duplicates are not eliminated. Null values are ignored.

SQL Result Relational algebra

select count(salary)from E

Result: count3

Fcount(salary)(E)

select count(distinct salary)from E

Result: count2

Fcount(salary)(PROJECTsalary(E))

You can calculate aggregates "grouped by" something: SQL Result Relational algebra

select sum(salary)from Egroup by dept

dept sumA 200C 300

deptFsum(salary)(E)

Several aggregates simultaneously: SQL Result Relational algebra

select sum(salary), count(*)from Egroup by dept

dept sum countA 200 2C 300 1

deptFsum(salary), count(*)(E)

Standard aggregate functions: sum, count, avg, min, max

Hierarchies

Example: The table E (for EMPLOYEE) nr name mgr1 Gretchen null2 Bob 15 Anne 26 John 23 Hulda 14 Hjalmar 17 Usama 4Going up in the hierarchy one level: What's the name of John's boss?

SQL Result Relational algebra

select b.namefrom E p, E bwhere p.mgr = b.nrand p.name = "John"

nameBob

PROJECTbname ([SELECTpname = "John"(RENAMEP(pnr, pname, pmgr)(E))] JOINpmgr = bnr [RENAMEB(bnr, bname, bmgr)(E)])

or, in a less wide-spread notationPROJECTb.name ([SELECTname = "John"(RENAMEP(E))] JOINp.mgr = b.nr [RENAMEB(E)])

or, step by stepP <- RENAMEP(pnr, pname, pmgr)(E) B <- RENAMEB(bnr, bname, bmgr)(E) J <- SELECTname = "John"(P) C <- J JOINpmgr = bnr B R <- PROJECTbname(C)

Notes about renaming: We are joining E with itself, both in the SQL query and in the relational algebra

expression: it's like joining two tables with the same name and the same attribute names.

Therefore, some renaming is required. RENAMEP(E) JOIN... RENAMEB(E) is a start, but then we still have the same

attribute names.

Going up in the hierarchy two levels: What's the name of John's boss' boss?

SQL Result Relational algebraselect ob.namefrom E p, E b, E obwhere b.mgr = ob.nr

nameGretchen

PROJECTob.name (([SELECTname = "John"(RENAMEP(E))] JOINp.mgr = b.nr [RENAMEB(E)]) JOINb.mgr = ob.nr [RENAMEOB(E)])

or, step by stepP <- RENAMEP(pnr, pname, pmgr)(E)

where p.mgr = b.nrand p.name = "John"

B <- RENAMEB(bnr, bname, bmgr)(E) OB <- RENAMEOB(obnr, obname, obmgr)(E) J <- SELECTname = "John"(P) C1 <- J JOINpmgr = bnr B C2 <- C1 JOINbmgr = bbnr OB R <- PROJECTobname(C2)

Recursive closure

Both one and two levels up: What's the name of John's boss, and of John's boss' boss? SQL Result Relational algebra

(select b.name ...)union(select ob.name ...)

nameBobGretchen

(...) UNION (...)

Recursively: What's the name of all John's bosses? (One, two, three, four or more levels.)

Not possible in (conventional) relational algebra, but a special operation called transitive closure has been proposed.

Not possible in (standard) SQL (SQL2), but in SQL3, and using SQL + a host language with loops or recursion.

Outer join

Example: The table E (for EMPLOYEE) enr ename dept1 Bill A2 Sarah C3 John AExample: The table D (for DEPARTMENT) dnr dnameA MarketingB SalesC LegalList each employee together with the department he or she works at:

SQL Result Relational algebraselect *from E, Dwhere edept = dnr

or, using an explicit joinselect *

enr ename dept dnr dname1 Bill A A Marketing2 Sarah C B Sales

E JOINedept = dnr D

from (E join D on edept = dnr) 3 John A A Marketing

No employee works at department C, Legal, so it is not present in the result. This is probably not a problem in this case. But what if we want to know the number of employees at each department?

SQL Result Relational algebraselect dnr, dname, count(*)from E, Dwhere edept = dnrgroup by dnr, dname

or, using an explicit joinselect dnr, dname, count(*)from (E join D on edept = dnr)group by dnr, dname

dnr dname countA Marketing 2B Sales 1

dnr, dnameFcount(*)(E JOINedept = dnr D)

No employee works at department C, Legal, so it is not present in the result. It disappeared already in the join, so the aggregate function never sees it. But what if we want it in the result, with the right number of employees (zero)? Use a right outer join, which keeps all the rows from the right table. If a row can't be connected to any of the rows from the left table according to the join condition, null values are used:

SQL Result Relational algebra

select *from (E right outer join D on edept = dnr)

enr ename dept dnr dname1 Bill A A Marketing2 Sarah C B Sales3 John A A Marketingnull null null C Legal

E RIGHT OUTER JOINedept =

dnr D

select dnr, dname, count(*)from (E right outer join D on edept = dnr)group by dnr, dname

dnr dname countA Marketing 2B Sales 1C Legal 1

dnr, dnameFcount(*)(E RIGHT OUTER JOINedept = dnr D)

select dnr, dname, count(enr)from (E right outer join D on edept = dnr)group by dnr, dname

dnr dname countA Marketing 2B Sales 1C Legal 0

dnr, dnameFcount(enr)(E RIGHT OUTER JOINedept = dnr D)

Join types: JOIN = "normal" join = inner join

LEFT OUTER JOIN = left outer join RIGHT OUTER JOIN = right outer join FULL OUTER JOIN = full outer join

Outer union

Outer union can be used to calculate the union of two relations that are partially union compatible. Not very common. Example: The table R A B1 23 4Example: The table S B C4 56 7The result of an outer union between R and S: A B C

1 2 null3 4 5null 6 7

Division

Who works on (at least) all the projects that Bob works on?

Semijoin

A join where the result only contains the columns from one of the joined tables. Useful in distributed databases.

Update

To update a named relation, just give the variable a new value. To add all the rows in relation N to the relation R: R <- R UNION N

Fun with Relational Algebra - Cheatsheet

Create a relational algebra cheatsheet. The cheatsheet should include each of the following operations: selection, projection, Cartesian product, union, intersection, difference, theta-join, equi-join, and natural join. For each operation you should

list the operator symbol, give a three or four word intuitive, English description, whether the operation is unary or binary (takes one or two relations as arguments), give an example of how the operation is used, state the relationship (if any) of the degree of the result to the degree of the

operands, state the relationship (if any) of the cardinality of the result to the cardinality of

the operands, and state any restrictions on the use of the operator.

For the example of the use of the operation, use one or more of the following relations.

student(id, name, address) JCUsubjects(code, lecturer) TAFEsubjects(code, lecturer) enrolledIn(id, code)You may break the cheatsheet into two (or more) tables if the rows get too big. Here is an example to get you started.

English operation arity description

selection θ(R) = T unary select rows that satisfy θ

union R S = T binary create set of tuples from relations R and S

A Relational Algebra cheatsheet - Part 1

English example restrictions

selection code=CP1500 OR code=cp3010(JCUsubjects) none

union JCUsubjects TAFEsubjects R and S must be union-compatible

A Relational Algebra cheatsheet - Part 2

English degree cardinality

selection degree(R) = degree(T) card(R) >= card(T)

union degree(R) = degree(S) = degree(T)

card(R) + card(S) >= card(T) >= max(card(R),card(S))

A Relational Algebra cheatsheet - Part 3

Solution:

English operation arity description

selection θ(R) = T unary select rows that satisfy θ

projection A1, A2, ...,

An(R) unary project named columns from R

Cartesian product R X S binary glue together all possible

combinations of tuples from R and S

union R S = T binary everything in R plus everything in S

intersection R S = T binary only tuples in both R and S

difference R - S = T binary everying in R take away everything in S

theta-join R θ S = T binary do Cartesian product then selection using θ

equi-join R θ S = T binary do Cartesian product then selection using θ

natural join R S = T binary equi-join on common attributes, but project only one copy of attribute values!

A Relational Algebra cheatsheet - Part 1

English example restrictions

selection code=CP1500 OR

code=cp3010(JCUsubjects) none

projection code(JCUsubjects) none

Cartesian JCUsubjects X none

product TAFEsubjects

union JCUsubjects TAFEsubjects

R and S must be union-compatible

intersection JCUsubjects TAFEsubjects

R and S must be union-compatible

difference JCUsubjects - TAFEsubjects

R and S must be union-compatible

theta-join student id <> id enrolledIn none

equi-join student id = id enrolledIn join condition can only involve AND and equality comparisons

natural join student enrolledIn is a kind of equi-join

A Relational Algebra cheatsheet - Part 2

English degree cardinality

selection degree(R) = degree(T) card(R) >= card(T)

projection degree(R) >= degree(T) card(R) >= card(T)

Cartesian product

degree(R) + degree(S) = degree(T) card(R) * card(S) = card(T)

union degree(R) = degree(S) = degree(T)

card(R) + card(S) >= card(T) >= max(card(R),card(S))

intersection degree(R) = degree(S) = degree(T) min(card(R),card(S)) >= card(T)

difference degree(R) = degree(S) = degree(T) card(R) >= card(T)

theta-join degree(R) + degree(S) = degree(T) card(R) * card(S) >= card(T)

equi-join degree(R) + degree(S) = degree(T) card(R) * card(S) >= card(T)

natural join degree(R) + degree(S) >= degree(T) card(R) * card(S) >= card(T)

A Relational Algebra cheatsheet - Part 3

Formulating Queries in the Relational Algebra

Give the following queries in the relational algebra using the relational schema given above, that is

student(id, name) enrolledIn(id, code) subject(code, lecturer)

1. What are the names of students enrolled in cp3020?

Solution: name( cp3020=code(student enrolledIn))

2. Which subjects is Hector taking?

Solution: code( name=Hector(student enrolledIn))

3. Who teaches cp1500?

Solution: lecturer( code=cp1500(subject))

4. Who teaches cp1500 or cp3020?

Solution: lecturer( code=cp1500 OR code=cp3020(subject))

5. Who teaches at least two different subjects?

Solution: For this query we have to relate subject to itself. To disambiguate the relation, we will call the subject relation R or S.

lecturer( R.lecturer = S.lecturer AND R.code <> S.code(R S)) 6. What are the names of students in cp1500 or cp3010?

Solution: name( code=cp1500(student enrolledIn)) name(code=cp3010(student enrolledIn))

7. What are the names of students in both cp1500 and cp1200?

Solution: name( code=cp1500(student enrolledIn)) name(code=cp3010(student enrolledIn))

8. What are the names of students in at least two different subjects?

Solution: For this query we have to relate enrolledIn to itself. To disambiguate the relation, we will call the enrolledIn relation R or S.

name(student ( R.id = S.id AND R.code <> S.code(R S))) 9. What are the codes of all the subjects taught?

Solution: code(subject)

10. What are the names of all the students?

Solution: name(student)

11. What are the names of all the students in cp1500?

Solution: name( code=cp1500(student enrolledIn))

12. What are the names of students taking a subject taught by Roger.

Solution: name( lecturer=Roger(student enrolledIn subject))

13. What are the names of students who are taking a subject not taught by Roger?

Solution: name( lecturer <> Roger(student enrolledIn subject))

More Formulating Queries in the Relational Algebra

Relational schemas for five relations in a movie database are depicted below.

movie(movieName, whenMade) star(starName, age) studio(studioName, where) produces(studioName, movieName) starsIn(starName, movieName)Your first mission, should you decide to accept it, is to formulate the following queries in relational algebra.

1. When was the movie Sneakers made?

Solution: whenMade( movieName = Sneakers(movie))

2. Who stars in Sneakers?

Solution: starName( movieName = Sneakers(starsIn))

3. Which stars that are over 40 appear in Sneakers?

Solution: starName( age > 40 AND movieName = Sneakers(star starsIn))

4. Which stars do not appear in Sneakers?

Solution: starName(star) - starName( movieName = Sneakers(starsIn)))

5. Which studio produces Sneakers?

Solution: studioName( movieName = Sneakers(produces))

6. What are the names of stars who star in movies produced by studios located in Burbank?

Solution: starName( where = Burbank(studio produces starsIn))

Your second mission is to formulate the following queries in English. 1. movieName = Sneakers((starsIn) movie)

Solution: Who stars in Sneakers?

2. movieName ( starName = 'Robert Redford'(star starsIn movie))

Solution: Which movies star Robert Redford?

3. movieName (stars ( starName = 'Robert Redford'(starsIn movie)))

Solution: Which movies star Robert Redford?

4. starName ( movieName = Sneakers(starsIn) age < 20(stars)) Solution: Which Sneakers stars are under 20?

5. studioName, starName( movieName = Sneakers (star starsIn produces studio))

Solution: Give me the stars and the studios they work for who starred in Sneakers.