Newletter Sign Up
Posts on the
Design Decomposition Blog
Iridium Satellite Collision in Space
You might have seen the recent news reports about the collision between U.S. and Russian communication satellites. The U.S. satellite was one of the Iridium satellites. What wasn’t reported and you probably don’t know is that an object database management system (ODBMS) is an important part of the Iridium system. Even though ODBMSs are a [...]
February 13, 2009
(The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services
I am now also posting on the Cutter Blog. My initial posting is (The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services. It is a response to Anne Thomas Manes’ SOA is Dead; Long Live Services on her blog at the Burton Group.
January 9, 2009
Atomicity
The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition: A task (for business process diagrams) or a process (for data flow diagrams) is atomic if every input relates to every output [...]
December 3, 2008
Well-Formed Business Process Diagrams
My last posting referenced the criteria for a well-formed business process diagram mentioned in Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. I am going to expand on their criteria to create a more comprehensive definition of a well-formed business process diagram. To start, here are three criteria from [...]
November 18, 2008
Recent Business Process Modeling Books
I recently received two new books on business process modeling. Both books looked interesting because they had great titles. As it turns out, one book is great and the other not so good. The not so good book is Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. There are [...]
October 9, 2008
The Design Decomposition Blog
is written by Doug Barry.
INCITS

SQL:1999 was developed by the INCITS Technical Committee H2 on Database. This committee develops standards for the syntax and semantics of database languages.

SQL:1999¹ specifies the SQL:1999 object model. It adds User Defined Types (UDTs) to SQL. There are two types of UDTs: distinct types and structured types. A distinct type is based on a built-in data type, such as INTEGER, but whose values cannot be directly mixed in operation with that built-in type. A structured type has an internal structure such as an address type that might have street, state, and postal code attributes as part of the structure. Structured types can be given specific user-defined functions and participate in type hierarchies with other structured types. Single inheritance is supported. Multiple inheritance of interfaces (as in Java) is not supported. Both distinct and structured types can be used as the data type for columns, SQL variables, a field of a row type, or as attribute of another UDT. Java objects can be either stored in a serialized byte stream as an SQL BLOB (Binary Large OBject) or mapped to a row in typed tables. With the SQL BLOB approach, an object is stored in a cell of a table or stored as a UDT in a cell of a table. It is possible to define methods that operate on the object using either approach.

The SQL:1999 object model also allows you to declare that a UDT is the type of an entire table. Each row is an instance of the type. Each attribute of the type is transformed into a column of the table. The methods associated with the type are also associated with the table. Typed tables can have an additional self-referencing column. This is similar to the object identification (OID) used in classical object models. See object identification (new window). The self-referencing column holds a value that uniquely identifies that row of the table. In SQL:1999, instead of using the term OID, it uses REF value with a special data type called REF type. One type can contain a REF to another type, similar to the way OIDs are used in object models. REFs can only reference rows in typed tables and cannot reference type instances in cells of a table, in variables, or anywhere else.

The SQL:1999 object model also provides for table hierarchies in addition to type hierarchies. The relationships of the table hierarchy and the type hierarchy are not necessarily one-to-one. Basically, table hierarchies allow you to modify the behavior and appearance of the default behavior for typed tables. For example, most object models assume that if you query a super type, you will also get results from any of its subtypes. Table hierarchies allow you to modify that behavior so that when you query on the super type, you do not get results from any of its subtypes.

With SQL:1999 you have multiple ways to model your data:

  1. Regular SQL tables and columns of built-in types
  2. Regular SQL tables with some columns of built-in types and some of UDTs
  3. Regular SQL tables with one column whose data type is a UDT
  4. Typed tables

SQL:1999 is also used by SQLJ Part 2. See SQLJ (new window).

Because of backward compatibility to SQL-92, SQL:1999 supports a database sublanguage. This results in a programming style illustrated by the embedded SQL statements in the following diagram. 

Embedded database sublanguage

An example of an embedded SQL statement that creates a new Person instance would be:

EXEC SQL BEGIN DECLARE SECTION;
    char SQLSTATE[6];
    char ssan[9];
    char name[30];
EXEC SQL END DECLARE SECTION

EXEC SQL
INSERT INTO person VALUES (:ssan, :name);

This code would be in addition to any host programming code. The variables :ssan and :name would need to be set by the host program using the host programming language before execution. If you also wanted to manipulate this new Person instance in the host program, you would need programming code in addition to this code fragment that populates the instance in the programming language along with the instance in the database. 

>>
Also see the INCITS H2 website (new window).

¹ SQL:1999 is also known as SQL3 and SQL-99. SQL:1999 is the proper term. SQL3 was the working term before the specification became a standard.

Related content for: SQL:1999

More on the general topic: DBMS standards

Read more free articles on this site

There are nearly 400 pages of articles on this site with over 40 pages on database concepts and standards.

Search this site for more articles

Custom Search

Browse this site for more articles

Click on the topics below to browse the articles on this site. You can see more detail by clicking on the arrows. This highlights the location of the current article: SQL:1999.

Related recent articles from Google News

ShmooCon: Web App Storage Open to Attack
PC World
"I don't need a vulnerability in the way a traditional SQL injection would work," Sutton said. Instead, the attacker can just issue standard SQL queries to ...
and more »
PCI compliance: What it is and why it matters (Q&A)
CNET
What happened at Heartland was a SQL injection attack [in which an attacker injects commands to a back end database using input fields on a Web site]. ...
and more »
Windows Azure Drive Hits Beta
InformationWeek
For instance, HP will reengineer some of its hardware to improve its ability to run Microsoft's SQL Server database and Hyper-V virtualization server ...
Commercial Windows Azure is now live, along with cloud-based storage BetaNews
Windows Azure Drive: A Sign of Things to Come for Microsoft ReadWriteWeb (blog)
Microsoft Windows Azure Drive Beta Released eWeek
all 204 news articles »
Microsoft Focused on Azure, Zune Smartphone Rumors This Week
eWeek
The business edition of the SQL Azure database will cost a flat $99.99. Those customers who opted not to upgrade their Windows Azure Community Technology ...
and more »
Sybase Joins In-memory Database Fray
PC World
Most in-memory databases require a specialized calls, where ASE can be accessed through the standard T-SQL (Transact-SQL) language used to access ASE ...
and more »
More related news on: SQL database standard

Related books at Amazon.com

SQL: 1999 - Understanding Relational Language Components (The Morgan Kaufmann Series in Data Management Systems)
SQL: 1999 - Understanding Relational Language Components (The Morgan Kaufmann Series in Data Management Systems)
by Jim Melton, Alan R. Simon
Average Customer Review: 4.5 stars based on 4 reviews.
Customer Review: This is an important book. Most books on SQL cover simple SQL statements, and/or focus on a particular vendor's SQL implementation. Very few books attempt to cover the SQL standard in any depth, if at all. This one does. Furthermore, because one of the authors (Jim Melton) is the editor of the ISO SQL Standards Committee, the book is...
SQL-99 Complete, Really
SQL-99 Complete, Really
by Peter Gulutzan, Trudy Pelzer
Average Customer Review: 4.5 stars based on 8 reviews.
Customer Review: SQL-99 book has been a great help to me. It is the best technical manual i've read over the last years. Without it i could not have done my coding.
Einführung in den Sprachkern von SQL-99 (German Edition)
Einführung in den Sprachkern von SQL-99 (German Edition)
by Wolfgang Panny, Alfred Taudes
Publisher: Springer
Publication Date: July 2000
Advanced SQL:1999: Understanding Object-Relational and Other Advanced Features (The Morgan Kaufmann Series in Data Management Systems)
Advanced SQL:1999: Understanding Object-Relational and Other Advanced Features (The Morgan Kaufmann Series in Data Management Systems)
by Jim Melton
Publisher: Morgan Kaufmann
Publication Date: September 2002
More related books: Search Amazon.com for SQL 1999