Download primary key

Introduction to Domains
A line manager asks, “If a domain is a kingdom in the
middle ages; what do our consultants mean when they
say it’s the domain of this or that in the database – by
the way do you think a domain is like that Abott &
Costello comedy routine, who’s on first base.”
1
Introduction to Domains




Domains & domain analysis
Using domains
Importance of domains
Domain of models
Copyright @2006, Michael McLaughlin
2
Domains & domain analysis





Domain
Domain
Domain
Domain
Domain
of
of
of
of
of
a column data type
a structure or row
a set of structures (rows)
sets of structures (rows)
position & signature
Copyright @2006, Michael McLaughlin
3
Domain of a column data type






Defining domain ranges
Assigning data types to columns
Defining strong data types
ANSI SQL:2003 data types
Defining user-defined data types
Managing physical sizes
Copyright @2006, Michael McLaughlin
4
Defining domain ranges

Rule #1:


Rule #2:


A domain range can be a set of values or a subset of values, like a
NUMBER data type is a type while its derived specialization a FLOAT
data type is a subtype of NUMBER, at least in an Oracle database.
Rule #3:


A domain range sets the lowest and highest values for some data types,
like an int, double, or float.
A domain range can set both maximum length and character set limits,
like variable length strings.
Rule #4:

A domain range can statically define or dynamically allot a physical
length and/or range of character values, like ASCII character values that
map to English alphabetical characters.
Copyright @2006, Michael McLaughlin
5
Assigning data types to columns

Rule #1:


Rule #2:


A column can sometimes have its data type changed by using the ALTER
command on an existing table, provided the database knows how to implicitly
cast from one data type to another.
Rule #4:


A column can have its data type changed by using the ALTER command on an
existing table, provided it doesn’t contain data.
Rule #3:


A column can have only one data type at any moment in time, and the data type
is assigned when you create the column in a table.
A column can only contain values consistent with its assigned data type, or it is
considered a multiple-part value, like a comma-separated-file.
Rule #5:

A column Can contain a null or not null value for numeric types and a null, empty
and populated value for strings and large object types, like how a string column
can have a null, zero length string, or non-zero length string.
Copyright @2006, Michael McLaughlin
6
Defining strong data types

Rule #1:


Rule #2:


A data type is only one thing, or a collection of things, but the thing or
collection of things must be defined.
Rule #4:


A data type id assigned to a column, and the database disallows entry
of anything not conforming to the data type.
Rule #3:


A data type has a defined domain, or range of values.
A data type does not change at runtime but can be altered by routine
database maintenance using an ALTER DDL statement.
Rule #5:

A data type is cataloged by the database and rules are enforced as
operational constraints.
Copyright @2006, Michael McLaughlin
7
Defining ANSI SQL:2003 data types

Rule #1:


Rule #2:


Column values of scalar data types are null by default unless you have designated a not null
database constraint.
Rule #5:


Strings, collections and large object files can hold more than one value at any point in time,
they are compound or composite variables dependent on various labeling approaches.
Rule #4:


Boolean, number, date and timestamp data types are scalar variables, which means they can
only hold one thing at any point in time; they are also known as primitive variables in the
Java programming language.
Rule #3:


Generic data types can have implementation specific names, and these differ between
commercial products.
Column values of compound data types are null by default but can be initialized as empty or
populated values, unless you have designated a not null database constraint that makes
them empty or populated.
Rule #6:

Column values can have a default value assigned when the tables is created or altered but
you can only use scalar values or string literals as default values typically.
Copyright @2006, Michael McLaughlin
8
Defining user-defined data types

Rule #1:


Rule #2:


Define incomplete types, object types, structures, or repeating
structures according to the ANSI SQL:2003 specification. Incomplete
data types are like using forward referencing in a single pass compiler
or interpreter.
Rule #3:


Define compound data types that are product specific and vary greatly
as to implementation details.
Support compound structures, like varrays and nested tables introduced
in the ANSI SQL:1999 specification.
Rule #4:

Support compound structures, like objects written in external
languages, like Java, C++ and C#, or proprietary languages like Oracle
PL/SQL.
Copyright @2006, Michael McLaughlin
9
Physical size management

Rule #1:


Rule #2:


Data type physical size is product implementation specific.
Rule #3:


Data type physical size is operating system specific and platform
dependent.
Data type physical size is encapsulated from the SQL developer
and not alterable.
Rule #4:

Data type physical size is defined and stored in the database
catalog, that contains metadata (or, data about data).
Copyright @2006, Michael McLaughlin
10
Domains of a structure or row






Defining
Defining
Defining
Defining
Defining
Defining
structures or rows
key and non-key columns
primary keys
superkeys
foreign keys
integrity constraints
Copyright @2006, Michael McLaughlin
11
Defining a structure or row

Rule #1:


Rule #2:


A row is a 1-Dimensional array indexed by a column name, which actually maps
in the catalog to a positional number and name.
Rule #4:


A row is a compound variable, which is variable that contains more than one
thing at any moment in time.
Rule #3:


A row is a record structure, defined by a list of fields that are described by data
types, like a structure in traditional programming languages.
A collection of rows, or record structures, is known as an array of structures, a
collection or a database table.
Rule #5:

A row is interchangeably described by fields, attributes or columns because
they’re synonymous in database vocabulary. These descriptors are 1-Dimensional
array indexes, and they are used to project through fields in a collection of
records, which is a longhand way of describing a table.
Copyright @2006, Michael McLaughlin
12
Defining key and non-key columns

Rule #1:


Rule #2:


A column can contain a sequence value to identify unique rows in a
table, which is called a surrogate key and otherwise not descriptive of
the problem.
Rule #4:


A column describes something about a row of information.
Rule #3:


A column should only contain a descriptive element of a record.
A key column can be used alone or together with one or more columns
to find a specific row, or set of rows through selection or projection.
Rule #5:

A non-key column cannot be used alone or together with one or more
columns to find a specific row.
Copyright @2006, Michael McLaughlin
13
Defining primary keys

Rule #1:


Rule #2:


A primary key is both unique and not null constrained by definition, this can
apply to one column or a group columns that act collectively as a primary key.
Rule #4:


A primary key can contain one to many columns but it must define uniqueness
for any row in a table.
Rule #3:


A primary key column should identify a unique row in a collection or a
database table.
A primary-key can be borrowed by dependent tables as a foreign key value,
which enables you to define a relationship between tables.
Rule #5:

A primary-key can be borrowed by the same table as a foreign key value to
support a recursive relationship, which enables you to define an internal
relationship between rows in the same table.
Copyright @2006, Michael McLaughlin
14
Definig superkeys

Rule #1:


Rule #2:


A superkey can contain one to many columns but it must define
uniqueness for any row in a table in the context of a relationship.
Rule #3:


A superkey column should identify a unique row in a collection or a
database table through an internal or external relationship.
A superkey is not necessarily unique or not null constrained by
definition, the constraints for a multiple column superkey can vary
between columns.
Rule #4:

A superkey can be borrowed by the same table or a dependent tables
as a filtering column value (typically deployed in a WHERE clause), like a
GENDER column.
Copyright @2006, Michael McLaughlin
15
Defining foreign key

Rule #1:


Rule #2:


A foreign key can be unique or non-unique but should be not null constrained
by definition because primary keys are so constrained.
Rule #4:


A foreign key can contain one to many columns but must map to a valid
primary key in the same or another table.
Rule #3:


A foreign key column points to a primary key in the same or another table.
A foreign key supports a join between the table by mapping the foreign key
value to a primary key value in the same or another table.
Rule #5:

When Foreign key columns are borrowed from the same table, you have a
recursive relationship, which enables you to define an internal relationship
between rows in the same table.
Copyright @2006, Michael McLaughlin
16
Defining integrity constraints

Unique:
A unique constraint tells the database to disallow a column to hold two or more equal
values, and typically made using “out-of-line” constraint syntax.
Not null:

A not null constraint tells the database to disallow entry of a null value into the column from
an INSERT or UPDATE statement, a not null constraint must be made using “inline” syntax
or it is a check constraint.



Check:


Primary key:


A check constraint tells the database to disallow entry or update of a column value that fails
to meet the expression governing the constraint, and typically made using “out of line”
constraint syntax.
A primary key tells the database to allow entry or update of a column value that is only both
unique and not null, and it enables a foreign key constraint to reference the column or set of
columns defined as the primary key, and typically made using “out-of-line” constraint syntax.
Foreign key:

A foreign key constraint tells the database to disallow entry or update of a column value that
is not found in the referenced primary key column list of values, and typically made using
“out-of-line” constraint syntax.
Copyright @2006, Michael McLaughlin
17
Domains of a set of structures (rows)





Defining
Defining
Defining
Defining
Defining
relational algebraic selections
relational algebraic projections
multiple-valued columns
natural keys
surrogate keys
Copyright @2006, Michael McLaughlin
18
Defining relational algebraic selections

Rule #1:


Rule #2:


The physical selection process is typically hidden and uses an internal key that typically
maps through the database catalog to a physical disk block address, which in Oracle
databases is the pseudo column ROWID.
Rule #4:


The selection process uses a primary key value as the index, which can be either a natural
key (composed of descriptive attributes), or a surrogate key (composed of an artificial
numeric index).
Rule #3:


The process of accessing a row as a structure or unit from a 2-dimensional structure is
known as selection, and it uses the index of the outermost array.
The selection process occur as a row-by-row fetch, unless a database implementation
supports bulk fetches, like Oracle 9i forward, and returns a 2-dimensional array result set.
Rule #5:

The selection process filters a result set by using the WHERE clause in DQL and DML
statements, filtering is an example of relational algebraic projection.
Copyright @2006, Michael McLaughlin
19
Defining relational algebraic projections

Rule #1:


Rule #2:


The physical projection process depends on the outermost array, or row,
selection process, and there is no bulk fetch process to avoid a row-by-row
fetching of records into the result set.
Rule #4:


The projection process relies on a column name as a key value, which works in
databases because all rows are symmetrical, or clones of the same structure,
with null values substituted for missing values.
Rule #3:


The process of accessing a set of rows by a column name in a 2-dimensional
structure like a table is known as projection because you project across rows
using an inner array column name.
The projection process works concurrently against multiple columns.
Rule #5:

The projection process filters by using the WHERE clause in DQL and DML
statements.
Copyright @2006, Michael McLaughlin
20
Defining multiple valued columns

Rule #1:


Rule #2:


Multiple valued columns are helpful to support projection operations looking for
common subsets in a set of data, like all males or females in a table with a
GENDER column.
Rule #4:


Multiple valued columns are typically non-unique values in a column.
Rule #3:


Multiple valued columns are typically not included in a natural key because they
compromise the efficiency of the selection process.
Multiple valued columns in a natural key indicate the domain of the table is
poorly defined.
Rule #5:

Multiple valued columns in a natural key seriously degrade the efficiency of all
join operations when they exceed 15% of all rows and may require a full table
read after a full index read.
Copyright @2006, Michael McLaughlin
21
Defining natural keys

Rule #1:


Rule #2:


A natural key represents the model of uniqueness at the time of design
and can change as more knowledge is developed about the business
problem.
Rule #3:


A natural key is defined by one or more columns that are both unique
and not null in the data set stored in a table.
A natural key composed of more than one column is an ideal index,
which speeds the selection process because you can project through
the index hash.
Rule #4:

A natural key does modify occasionally and should not be used as a
primary key because when it changes, you will have to rewrite all SQL
statement joins – prohibitively risky and expensive.
Copyright @2006, Michael McLaughlin
22
Defining surrogate keys

Rule #1:


Rule #2:


A surrogate key is supported by a database SEQUENCE structure, which
is accessible in some database products and not accessible in others.
Rule #4:


A surrogate key is also known in some products as automatic
numbering.
Rule #3:


A surrogate key is defined as a unique numeric index value, like the
index in a standard programming array.
A surrogate key defines nothing in the domain of the data.
Rule #5:

A surrogate key defines unique rows in the domain of the table.
Copyright @2006, Michael McLaughlin
23
Domains of sets of structures (rows)

Defining sets of structures





When you merge columns from multiple tables you create rows
of a merged set of structures, two or more tables.
The full set of columns from one table is a result set of a
structure, while the combination of two or more partial or full
sets of structures is a merged result set and a new structure.
Result sets are composed of a superset of data drawn from all or
part of columns from two or more tables.
The common column value between structures is the primary
key in one table and foreign key in other, generally it is excluded
from a merged result set or only one copy is found.
Primary and foreign key values typically only serve to merge
tables and are not used in merged result sets when they are
surrogate primary keys.
Copyright @2006, Michael McLaughlin
24
Domains of position and signature

Defining signatures





A signature is often described as a prototype for a function or
method in programming languages.
Database tables are defined at their creation with column names
that have column types, and the columns are stored in the
database catalog in the order that they are listed in the CREATE
statement.
SQL has always supported both positional and named INSERT
statements, the default signature is by position.
You override positional signatures by providing an overriding
signature, which uses the column names to replace the
positional ordering.
All UPDATE statements use column names to set values,
therefore, only the INSERT statement imposes a default
signature.
Copyright @2006, Michael McLaughlin
25
Using domains

Data types



Data structures



A data structure, or table definition, requires a definition, and the definition sets
the list of scalar variables, which then set their field element data types and
respective ranges.
A data structure, or table definition, can contain a compound variable like a
collection of scalar or compound data types, examples of nesting tables.
User account or schema



A data type must have an understood range of values.
A data type must be scalar or compound, the latter are data structures or objects
in an Object Relational Database Management System like Oracle.
A work area that contains delegated rights and privileges.
A work area that contains user database objects.
Database Catalog


A set of structures, or tables, that contain the operating definitions of the
database management system, like data types.
A set of structures that are dynamic as users work in the database.
Copyright @2006, Michael McLaughlin
26
Importance of domains

Defining the operating norms




The domain of data types provide a context to what is defined, how it
works, and whether a data type can be extended.
The domain of data types must be known for a database management
system to work with a data type because it must know how to work
with the type in memory and disk storage.
The domain of data types determines how you access types using SQL.
Defining the operating environment




The domain of a data structure qualifies how data elements are
organized, and what defines the field data types.
The domain of accounts defines how accounts work.
The domain of grants and privileges defines how user accounts work
with each other.
The domain of the database catalog keeps track of everything and
makes sure it conforms to the database management system rules.
Copyright @2006, Michael McLaughlin
27
Domains & domain analysis





Domain
Domain
Domain
Domain
Domain
as
as
as
as
as
a
a
a
a
a
column
table
relation
user/schema
model
Copyright @2006, Michael McLaughlin
28
Domain as a column



A column has only one data type, which
can be a scalar or compound type.
A column with a scalar type can hold only
one thing at any moment in time..
A column with a compound type can
require special handling in SQL and may
contain a list of like things, or a structure
or nested table.
Copyright @2006, Michael McLaughlin
29
Domain as a table



A table contains a list of column names
identified by data type, Oracle supports
999 columns in a table.
A table contains rows of data that contain
values for some or all defining columns.
A table contains zero to many rows, there
is virtually no limit on the number of rows.
Copyright @2006, Michael McLaughlin
30
Domain as a relation




A relation can be between two rows in one
table.
A relation can be between one row in one table
and one row in another table.
A relation can be between one row in one table
and many rows in another table.
A relation is only stored in the catalog when it is
defined as a foreign key constraint.
Copyright @2006, Michael McLaughlin
31
Domain as a user/schema





Domain as a user/schema
A user domain contains a set of user-defined
constraints, types, structures and tables.
A user domain can grant privileges to other
user/schema domains.
A user domain can hold privileges to other
user/schema components.
A user domain can assign aliases in the catalog
to point to its own components or another
user/schema components.
Copyright @2006, Michael McLaughlin
32
Domain as a model



The domain is modeled by visual drawings
or representational semantics.
The domain is modeled to support
understanding what is stored where and
how it all ties together.
The domain is defined visually and by
annotation of drawings.
Copyright @2006, Michael McLaughlin
33
Summary




Domains & domain analysis
Using domains
Importance of domains
Domain of models
Copyright @2006, Michael McLaughlin
34