1. SQL Basics - 1

2. SQL – It is divided into three parts, which are three sublanguages:
• DDL: Data Declaration Language
• DML: Data Manipulation Language
• DCL: Data Control Language

3. 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.

4. DML: Data Manipulation Language
The 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

5. 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.

6. Tables as Entities
An 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.

7. Tables as Relationships
A 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.

8. Rows versus Records
Rows 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.

9. Columns versus Fields
A 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.

10. 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.

11. CREATE SCHEMA Statement
The 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.