SQL Basics - 1

SQL – It is divided into three parts, which are three sublanguages:

• DDL: Data Declaration Language

• DML: Data Manipulation Language

• DCL: Data Control Language

DDL: Data Declaration Language

The Data Declaration Language (DDL) is what defines the database content and maintains the

integrity of that data. Data in files have no integrity constraints, default values, or relationships;

if one program scrabbles the data, then the next program is screwed. Talk to an older

programmer about reading a COBOL file with a FORTRAN program and getting output instead of

errors. The more effort and care you put into the DDL, the better your RDBMS will work. The

DDL works with the DML and the DCL; SQL is an integrated whole and not a bunch of

disconnected parts.

DML: Data Manipulation LanguageThe Data Manipulation Language (DML) is where most of my readers will earn a living doing

queries, inserts, updates, and deletes. If you have normalized data and build a good schema,

then your job is much easier and the results are good. Procedural code will compile the same

way every time. SQL does not work that way. Each time a query or other statement is processed,

the execution plan can change based on the current state of the database

Data Control Language (DCL)The Data Control Language (DCL) is not a data security language, it is an access control language.

It does not encrypt the data; encryption is not in the SQL Standards, but vendors have such

options. It is not generally stressed in most SQL books and I am not going to do much with it.

Tables as EntitiesAn entity is a physical or conceptual “thing” that has meaning by itself. A person, a sale, or a product would be an example. In a relational database, an entity is defined by its attributes. Each occurrence of an entity is a single row in the table. Each attribute is a column in the row. The value of the attribute is a scalar. To remind users that tables are sets of entities, I like to use

collective or plural nouns that describe the function of the entities within the system for the names of tables. Thus, “Employee” is a bad name because it is singular; “Employees” is a better

name because it is plural; “Personnel” is best because it is collective and does not summon up a mental picture of individual persons.

Tables as RelationshipsA relationship is shown in a table by columns that reference one or more entity tables.

Without the entities, the relationship has no meaning, but the relationship can have attributes

of its own. For example, a show business contract might have an agent, an employer, and

a talent. The method of payment is an attribute of the contract itself, and not of any of the three

parties. This means that a column can have REFERENCES to other tables. Files and fields

do not do that.

Rows versus RecordsRows are not records. A record is defined in the application program that reads it; a row is

defined in the database schema and not by a program at all. The name of the field is in the

READ or INPUT statements of the application; a row is named in the database schema. Likewise,

the PHYSICAL order of the field names in the READ statement is vital (READ a, b, c is not

the same as READ c, a, b; but SELECT a, b, c is the same data as SELECT c, a, b).

All empty files look alike; they are a directory entry in the operating system with a name and a

length of zero bytes of storage. Empty tables still have columns, constraints, security privileges,

and other structures, even though they have no rows.

Columns versus FieldsA field within a record is defined by the application program that reads it. A column in a row in a

table is defined by the database schema. The data types in a column are always scalar. The order

of the application program variables in the READ or INPUT statements is important because the

values are read into the program variables in that order. In SQL, columns are referenced

only by their names. Yes, there are shorthands like the SELECT * clause and INSERT INTO <table

name> statements, which expand into a list of column names in the physical order in which the

column names appear within their table declaration, but these are shorthands that resolve to

named lists.

Schema Objects

A database is not just a bunch of tables, even though that is where most of the work is done.

There are stored procedures, user-defined functions, and cursors that the users create. Then

there are indexes and other access methods that the user cannot access directly.

This chapter is a very quick overview of some of the schema objects that a user can create.

Standard SQL divides the database users into USER and ADMIN roles. These objects require

ADMIN privileges to be created, altered, or dropped. Those with USER privileges can invoke

them and access the results.

CREATE SCHEMA StatementThe CREATE SCHEMA statement defined in the standards brings an entire schema into existence

all at once. In practice, each product has very different utility programs to allocate physical

storage and define a schema. Much of the proprietary syntax is concerned with physical storage

allocations.