Posts on the
Design Decomposition Blog
Cloud Users’ View of Security
Two recent surveys (details below) support the driving and restraining forces related to security shown in the Force Field Analysis for Using a Public Cloud instead of an In-House Private Cloud posted a couple weeks ago. Participants in both surveys were Cloud users. Data supporting the driving forces: The TechInsights Report 2013: Cloud Succeeds stated [...]
June 19, 2013
Changes for IT and Regulatory Requirements
This post picks up on two ideas in my last post. The first  idea is that IT will have significant change, in part, from the adoption of Cloud Computing. Take a look at IT Departments Won’t Exist in Five Years at Computerworld.com. It states that: Consumerization of IT and self-service trends will lead to a [...]
June 12, 2013
Using a Public Cloud instead of an In-House Private Cloud
Last April, Jason Bloomberg of ZapThink issued a ZapFlash titled Cloud Computing: Rethinking Control of IT. I thought it would be useful to organize his arguments into a Force Field Analysis as described in Web Services, Service-Oriented Architectures, and Cloud Computing. The following analysis also includes information from two other ZapFlash entries that Jason referenced [...]
June 5, 2013
Five Principles for the Incremental SOA Analysis
After last week’s posting, I thought I should say more about incremental SOA analysis. The following is from Chapter 10 in Web Services, Service-Oriented Architectures, and Cloud Computing. Service-oriented architecture (SOA) projects are no different from other IT projects in that larger projects tend to fail and issues regarding change can scuttle projects. This chapter [...]
May 29, 2013
Incremental SOA and Change
Computerworld had an article last January that discussed American Airlines’ approach to using Web Services and multiple enterprise service buses (ESBs) as part of their service-oriented architecture (SOA). The authors emphasized a change from build vs. buy and from using mainframes. That, however, is not the part I found interesting. (Also, several comments to the [...]
May 22, 2013
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. 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.

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 DM32.2 Task Group on Database website.

¹ 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 Articles

More on the general topic: DBMS Standards

Douglas K Barry

Read More Free Articles on This Site

There are over 450 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.

Loading...

The Savvy Manager's Guide

Douglas K Barry has prepared the material on this site. He is also the author of a book that explains Web Services, service-oriented architecture, and Cloud Computing in an easy-to-understand, non-technical manner.

Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide

Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (Second Edition)

by with David Dick

This is a guide for the savvy manager who wants to capitalize on the wave of change that is occurring with Web Services, service-oriented architecture, and—more recently—cloud computing. The changes wrought by these technologies will require both a basic grasp of the technologies and an effective way to deal with how these changes will affect the people who build and use the systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of both the changes that we are now seeing and ways to deal with issues created by those changes.

The intent of this book is to give you an opportunity to consider some ideas and advice that just might make it easier for your organization to realize the potential benefits in Web Services, service-oriented architectures, and cloud computing. No crystal ball exists to tell us the services that will be available tomorrow. Undoubtedly, there will many innovative services that we cannot envision at this time. For that reason, this book presents a straightforward approach that will help you get your organization ready to take advantage of a service-oriented architecture—in whatever form it takes.

"Web Services, Service-Oriented Architectures, and Cloud Computing by Douglas Barry provides easy-to-follow guidance around the proper use of web services, how they exist within SOA, and how the emerging use of cloud computing correctly fits into the mix. This is something that most in this industry can neither define nor implement, and getting it right the first time is critical to success. If you're looking to understand the true nature of web services, SOA, and cloud computing—including the underlying details—then you should begin by reading this book."


Author, Founder and CTO of Blue Mountain Labs