|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|News||Recommended books||Recommended Links|
For good or bad relational databases are very common. The relational model of databases provides a rather primitive way of looking at data structured as tables.
There is a set of operations defined called relational algebra, but it does not bring anything non-trivial. All this pseudo-theoretical crap about normalization should be treated with a grain of salt; do not go into it further that is needed to pass the exam, if any ;-). All those Cood inspired normalization rules proved to be infertile.
Relational database model presuppose tables with of identically structured tuples (rows). Each tuple consists of value of certain attributes (columns).
SQL - Wikipedia, the free encyclopedia
SQL was developed at IBM by Donald D. Chamberlin and Raymond F. Boyce in the early 1970s. This version, initially called SEQUEL (Structured English Query Language), was designed to manipulate and retrieve data stored in IBM's original quasi-relational database management system, System R, which a group at IBM San Jose Research Laboratory had developed during the 1970s. The acronym SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company.
The first Relational Database Management System (RDBMS) was RDMS, developed at MIT in the early 1970s, soon followed by Ingres, developed in 1974 at U.C. Berkeley. Ingres implemented a query language known as QUEL, which was later supplanted in the marketplace by SQL.
In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the potential of the concepts described by Codd, Chamberlin, and Boyce and developed their own SQL-based RDBMS with aspirations of selling it to the U.S. Navy, Central Intelligence Agency, and other U.S. government agencies. In June 1979, Relational Software, Inc. introduced the first commercially available implementation of SQL, Oracle V2 (Version 2) for VAX computers. Oracle V2 beat IBM's August release of the System/38 RDBMS to market by a few weeks.
After testing SQL at customer test sites to determine the usefulness and practicality of the system, IBM began developing commercial products based on their System R prototype including System/38, SQL/DS, and DB2, which were commercially available in 1979, 1981, and 1983, respectively.
Through the years, the Ingres code base found its way into many other products, including Postgres (Post Ingres) SQL. A small group from Berkeley, known as Britton-Lee, formed a company and product called Sybase, which became the number 2 database product throughout much of the 1980's and early 1990's.
In 1992, Microsoft licensed the Sybase technology and developed the Microsoft SQL Server for the Windows operating system. This partnership dissolved in the late 1990's, where since Microsoft SQL has dominated the SQL market.... ... ...
Modern SQL Standards
Today, the relational market is huge, with experts placing its value between $12 - $18 billion. Banks, airlines, governments, schools, and many, many other organizations, large and small, all benefit from the solid relational database theory Codd published. Codd's ideas led to the development of several query languages. While perhaps not judged to be the best choice of standards to enact Codd's rules of relational data management, SQL has emerged as the de facto standard. The influence of Codd's rules are certainly evident in the SQL language of today.
SQL was first standardized by the American National Standards Institute (ANSI) in 1986 as X3.135. The International Standards Organization (ISO) followed suit in 1987. This was adopted by the United States in 1989 via FIPS (Federal Information Processing Standard). These standards were revised in 1989, under the working term of SQL1, and became published as SQL89.
SQL89 was strengthened in 1992 and SQL92 (SQL2) was published. This revision addressed many of the implementation issues of the time, and proposed many new conceptual features. To assist implementers with this new voluminous work, three levels of conformance were defined: Entry-level (SQL89 plus basic improvements), intermediate- level (core functionality), and full conformance (complete SQL92 feature set).
Continuing standardization resulted in SQL99 (SQL3) published in 1999. This brought forth even more advanced features such as object- relational database concepts and integrity management. Two degrees of conformance replace the SQL92 conformance levels, Core SQL99 and Enhanced SQL99.
This process has been continued with the latest incarnation being the SQL:2003 standard. This massive collection can now be purchased from the ANSI/ISO organization.
A PDF/Adobe Acrobat version of the tutorial is available directly from Matthew Kelly at Highcroft Communications (www.highcroft.com).
Copyright 1996-2001, James Hoffman. This document can be used for free by any Internet user, but cannot be included in another document, another web site or server, published in any other form, or mass produced in any way.
Last updated: 5-14-2001; added relational algebra material.
About: SQLite is a C library that implements an SQL database engine. A large subset of SQL92 is supported. A complete database is stored in a single disk file. The API is designed for convenience and ease of use. Applications that link against SQLite can enjoy the power and flexibility of an SQL database without the administrative hassles of supporting a separate database server. Because it omits the client-server interaction overhead and writes directly to disk, SQLite is also faster than the big database servers for most operations. In addition to the C library, the SQLite distribution includes a command-line tool for interacting with SQLite databases and SQLite bindings for Tcl/Tk.
Version 184.108.40.206 of SQLite is recommended for all new development. Upgrading from version 220.127.116.11 or 3.7.7 is optional. Upgrading from all other SQLite versions is recommended.
About: Reverse Snowflake Joins is a tool that parses SQL Select statements and generates a diagram. In addition to joins, the diagram shows parts of the underlying SQL directly in the diagram. For example x=30, GROUP BY (year), SUM(profit), HAVING MIN(age) > 18.
Changes: The ability to use "select *" and "table.*" were added. The "like" operator was added. Sometimes text was clipped in Graphviz. This was fixed by specifying textsize.
Google matched content
DATABASE LEARNING MODULE
web.blazonry Server-side Web Database Tutorial
Databases from Scratch
A good introduction to simple and relational databases design, and to databases in general.
Introduction to Relational Database Design
A slightly more technical look at relational databases and how they are used. mSQL used as example, also knowledge of SQL would be a plus for reading this one.
SQLCourse - Lesson 1 What is SQL
|O'Reilly Network: AboutSQL: Filtering SELECTed Data with WHERE|
(Nov 11, 2000, 17:33 UTC) (5 reads) (0 talkbacks) (Posted by
"One of the most powerful SQL clauses is the WHERE clause, which is used to filter results on a specific set of criteria. The syntax is trivial."
Pal's Linux RDBMS Library - SQL
SQL Tutorial 4.3
Database Design - Introduction
This site is an outgrowth of the now-abandoned book project, Practical Relational Database Design, by Wayne Dick and Tom Jewett. Although much of the material here is adapted from that work, two new teaching approaches accompany the move online:
• Discussions are condensed, and a large number of concepts are introduced very early in these pages. Our goal is to present an integrated view of the concepts and skills needed to design and implement real database systems.
• Modeling is shown with the Unified Modeling Language (UML) class diagram, and both UML and traditional relational database (RDB) entity-relationship (ER) modeling terms are presented together-along with the Structured Query Language (SQL) statements needed to begin working with actual data.
This site is also intended to be an ever-growing repository of database design materials. Ideas, suggestions, and especially new examples are always welcome, and will be acknowledged (email address below). Readers should be aware of at least three known limitations here:
• The UML language, even the class diagram portion of it, is vastly richer than the small subset of concepts covered here. Many excellent books on UML are readily available; readers should consult these for more information.
• SQL examples and code are designed for use with Oracle® version 9i; older versions of Oracle don't support the same join syntax, and other products will need various modifications to the code.
• As much as I hate web sites that "require" the user to download plugins, there just isn't any reasonable way to provide scalable graphics other than to use the Adobe® SVG viewer, available at http://www.adobe.com/svg/viewer/install/main.html.
In building this project, I owe a huge debt of gratitude to Prof. Wayne Dick, lead author of the PRDD book. You'll see him specifically credited where he is clearly the originator of any material here (for example, the "Indoor Plant Service" model). In other places, he and I have worked together for so long that it's hard to identify separate authorship-I hope that this general acknowledgement will suffice. Prof. Alvaro Monge will also be working on this site; look for his name to appear frequently on specific pages. As always with teaching materials, my students are the main source of inspiration and motivation to develop the site.
Department of Computer Engineering and Computer Science
California State University, Long Beach
Copyright © 2002, by Tom Jewett and other authors where noted. Links to this site are welcome and encouraged; however, this material may not be reposted to other web sites or newsgroups, or included in any printed or electronic publication, whether modified or not, without specific permi
We assume that most people have some notion of "database". We see databases in everyday life - collections of CDs we can order from a company, a phonebook of phone number and name entries, parts stocked by a supplier to be supplied to a project, records to be processed by a program, a general repository that a program acts upon (like a cgi-bin program acting on a web client's behalf to read and write data to disk).
With a bit more precision, when we use 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. For further details, there are any number of good database textbooks. When I first studied databases about ten years ago, I used perhaps the classic text, C.J. Date's An Introduction to Database Systems (Addison-Wesley). (Date was responsible for popularizing the now widely accepted relational database model, based on E.F. Codd's 1968 defining work.) I have also used Fundamentals of Database Systems by Ramez Elmasri and Shamkant B. Navathe (Benjamins/Cummings) and M.Tamer Ozsu and Patrick Valduriez's Principles of Distributed Database Systems (Prentice Hall).
SQL Help and Tutorial
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:
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
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.
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:
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:
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.
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 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 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.
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.
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.
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
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.
This should give you a general idea of what Access looks like. For more details, I have put together a detailed Access tutorial. It steps you through creating the Employee Table we have been discussing, as well as retrieving data from that table.
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified:March 12, 2019