logo for asktheoracle.net
leftimage for asktheoracle.net

Expand Your Oracle Knowledge With Our Special Oracle Tutorials For Beginners

This series of Oracle tutorials provides an introduction to Oracle for beginners. This first tutorial explains relational theory, on which all relational databases are built, and provides some examples so you can see how it works in practice. Object-oriented design as it applies to databases is also discussed briefly.

Other articles in this series of Oracle tutorials expand on these concepts, discuss the factors that affect SQL (and therefore database) performance and examine the Oracle database from the point of view of the dba.

What is an Oracle database?

Oracle is an object-relational
hybrid database - a relational database with added object-oriented features - and, since Oracle 10g, a grid-enabled database - the ability to scale across multiple inexpensive servers to provide more processing resources.

Each release of the Oracle database brings new features to improve scalability, reliability, performance and availability. We'll be examining some of these new features in later Oracle tutorials.

Oracle Tips & Tricks to SKYROCKET Your Career!

If you're not already a subscriber to Oracle Tips and Tricks, you're  missing out on a myriad of tips and techniques to help you become a better, faster, smarter developer. Subscribe now and ignite your career.


Lets' start by defining a relational database.

What is a relational database?

A British engineer Ted Codd working for IBM elucidated the theory of relational databases in a paper called "A Relational Model of Data for Large Shared Data Banks" in the 1970s whilst working for IBM. At the core of this relational model is the concept of the separation of the logical and physical data models which enables you to "see" the database in a completely different way to its underlying structure.

The importance of this separation is that it makes relational databases extremely flexible by enabling each layer to be changed without affecting the other. With  earlier database models, such as the hierarchical database model, changes in business requirements requiring new data structures necessitated the complete re-design of the database. With relational databases, new data structures can be added without having to perform a complete re-design.

A relational database, therefore, can be regarded as containing a set of 2-dimensional tables ("relations") with each table comprising rows ("tuples") and columns ("domains"). Relationships between database tables are created when one table has a column with the same meaning as a column in another table. The actual values of the columns are irrelevant but they must refer to/mean the same thing.

Let's take the example of a very simple database with just 2 tables (relations):

  • employees
  • departments

the employees table has just three columns  :

  • employee_id
  • employee_ name
  • department_id

the department table has just two columns :

  • department_id
  • department_name
There is a relationship between these two tables via the department_id column in each table. The department_id column in the employees table  relates to the department_id column in the departments table. This enables you to assign employees to a department and determine which employees work for which department.

Now that we can say that these two tables are related, the other part of relational database model - relational calculus (which is essentially set theory) enables relations (i.e. database tables) to be combined in various ways:
  • the union of 2 relations results in a set of data containing those elements that exist in one or other relation (or both relations);
  • the result of the join (i.e. the intersection) of 2 relations is the set of  elements that exist in both relations;
  • the exclusive "OR" of 2 relations produces the set of items that are in either of the relations but not both
  • an outer-join is the same as the join but also includes elements from one or both relations that are not in the other (depending on whether a full outer-join or a left or right outer join is performed)
  • relations can also be subtracted from each other leaving the set of   elements that were in the first relation but not the 2nd

Let's continue the first of our Oracle tutorials with a few examples, using the following data:

Employees

Employee_Id Employee_Name Department_Id
1 Mike Jones
3
2 Phil Rogers
6
3 Dave Tanner 3
4 Paul Johnson
2
5 Raj Patel
1
6 Qamar Aziz
5

Departments

Department_Id Department_Name
1 Marketing
2 Sales
3 IT

Joining employees and departments with a query like this:

select depeartment_name, employee_name
from employees e, departments d
where e.dept_id=d.dept_id

would produce the following result:

Department_Name Employee_Name
Marketing Raj Patel
Sales Paul Johnson
IT Dave Tanner


The number and data types of the columns must be the same for the union of relations so the departments table requires an extra column. the following query:

Select department_id, department_name, 999 from departments
UNION
Select employee_id, employee_name, department_id from employees

would produce the following results:

Department_Id Department_Name 999
1 Marketing 999
2 Sales 999
3 IT 999
1 Mike Jones
3
2 Phil Rogers 6
3 Dave Tanner 3
4 Paul Johnson 2
5 Raj Patel 1
6 Qamar Aziz 5

Due to the requirement that column types and numbers must match, "union" is not normally used to combine different tables in their entirety but instead to combine sub selections from one or more tables. In fact the results of this particular query are meaningless because we are combining employee ids with department ids and employee names with department names and wouldn't fulfil any sensible business requirement. A more meaningfull business requirement might be for the list of employees in New York and London say (if the employees locations were held) but this example demonstrates the principle of the UNION command.

Also see our Oracle SQL tutorials and our Oracle PL/SQL tutorials.