Database Design Basics - (Part 1)

In this article, you will learn about database design concepts. The database des
ign concepts discussed in this article focus almost exclusively on OLTP requirem
ents. OLAP design is beyond the scope of this article.
In this article, you will learn about table design, entities and attributes and
their relation to the tables and columns. You will also learn how to enforce dat
a integrity through domain integrity, entity integrity, referential integrity, a
nd user-defined integrity, and how to use primary keys, unique constraints and f
oreign keys to maintain data integrity.

Table design

Table design is often the most time-consuming (and perhaps the most important) p
art of the physical design process. When designing tables, you identify:

Entities and attributes
Relationships between entities

Tables

You create tables to store and organize data in the SQL Server database engine.
A table is a collection of columns and rows. For example, each row in employee t
able represents one employee. The columns of employee table contains the informa
tion that describes the employee. Each column has a data type, which defines the
format in which data is stored in that column. Data types can have a fixed leng
th, meaning that they are always the same size, or variable length, changing len
gth to fit the data they hold.

Entities

Entities are the items, or types of items, that your database contains. You use
your entity list to determine the tables you need to create as part of your phys
ical database design. You represent each type of entity (such as employees) in a
separate table in the database. You represent each individual instance of an en
tity (such as one employee) as a row in the table.

You must identify the unique entities for which the database is responsible. For
example, North Bikes warehouses and sells bikes, bikes spare parts, clothing an
d other accessories items. Physical entities might include:

Employees
Customers
Vendors
Bikes
Bikes spare parts
Clothing
Accessories

As you go through the design and analysis process, you identify additional entit
ies that you might not have seen initially. These could include:

Employee time sheets This would be a requirement for hourly employees.
Pay rate information Necessary to calculate employee pay.
Customer orders Tracks orders placed by customers.
Inventory purchase orders Tracks orders placed by Outlander Spices to its vendor
s.

Typically, your entity list continues to grow as you learn more about a company.

Attributes

Attributes are the values that describe entities. Some attributes are unique val
ues, while others are not. You use an entity-unique value as the identifier when
you create a table.

For example, each employee in an employee table must have some sort of unique em
ployee identifier, such as the employees social security number or an internally
generated identifier. Other information you have about the employee, such as the
employees manager, or the city and state where the employee lives, is not necess
arily unique to that employee and cant be used as the identifier.

You create the same number of columns in your table as attributes for the entity
the table holds. Each column contains a single value for each row. In most case
s, there is additional information that you do not need to include in your table
. With employees, you likely track information such as: name, address, telephone
number and social security number.

You can assign each employee an internally generated unique employee ID used as
a tracking number for that employee. The employee attribute list leaves a lot of
information about the employee that you might not include in your table, such a
s: employee hair colour, eye colour, and shoe size.

Whether or not you determine that an attribute is significant depends on a parti
cular businesss practices. You must to determine which attributes you need to inc
lude in your table while gathering and evaluating information about the business
during the conceptual and logical design phases. With employees, you can use ex
isting employee records as your guide. For example, if North Bikes provides its
warehouse workers with steel-toed shoes at no charge, then shoe size is an impor
tant attribute to track.

Relationships

You can treat tables as unrelated objects, or you can define links (relationship
s) between the tables. Relationships identify associations between data stored i
n different tables. Entities relate to other entities in a variety of ways. Stan
dard relational design practices define relationship types as:

One-to-one In one-to-one, each row of a database table is linked to 1 and only 1
other row in another table. For example, each row in the order table is related
to 1 and only 1 other row in the order details table.
One-to-many (many-to-one) In one-to-many (many-to-one) relationship, each row of
a database table is related to 0, 1 or more rows of another database table. For
example, each row in the vendors table is related to 0, 1 or many rows in the b
ikes table.
Many-to-many In a many-to-many relationship, one or more rows in one database ta
ble contains several child rows in the second database table, vice versa. For ex
ample, each bike model can be purchase by 0, 1 or more customers, and one custom
er can have 0, 1 or more bike types.

Data integrity

You begin the table design process by identifying the information you need to tr
ack and designing the physical tables. Then you must ensure data integrity. With
data integrity you use database objects and application logic to ensure that da
ta is reliable and accessible. SQL Server enforces critical integrity areas:

Domain integrity
Entity integrity
Referential integrity
User-defined integrity

Domain integrity

Domain integrity ensures that the values in specified columns are legal, which m
eans that the value meets a specified format and value criteria. For example, to
specify domain integrity for the state attribute, you can specify that a state
column must contain a two-character entry and that the value entered must be a v
alid United States state abbreviation.

Entity integrity

Entity integrity ensures that each row is uniquely identified by requiring a uni
que value in one or more key columns. For example, if you have a table containin
g employee records, it must identify each employee as unique. You can have the d
atabase application generate a unique identifier for each employee or use an exi
sting identifier. In the United States, you might use the employees social securi
ty number.

Referential integrity

Referential integrity ensures that table cross-references remain valid after the
y are established. For example, in an employee database, you might have one tabl
e tracking general information about an employee and another tracking payroll in
formation. You would create a relationship between these tables, relating each e
mployee to his or her payroll information. When adding a new record to the payro
ll table, the database engine verifies that it is related to an existing employe
e record, checking for a valid cross-reference between the tables.

User-defined integrity

User-defined integrity (also called policy integrity) ensures that values stored
in the database remain consistent with established business policies. You maint
ain user-defined integrity through business rules. Examples of user-defined inte
grity are case-specific for each organization. One example is when you have a ta
ble tracking information about employees, including accrued vacation time. You c
an set limits on the maximum allowable amount based on the employees time in his
or her position, or other determining factors.

Enforcing entity and referential integrity

You enforce entity and referential integrity through keys and constraints. To do
this, you use primary keys, unique constraints, and foreign keys. Table columns
used to define these objects are known as key columns.

Primary keys

A primary key enforces entity integrity by ensuring that each row in a table is
unique. You can specify one or more key columns when defining the primary key. M
icrosofts SQL Server does not require you to define a primary key when you create
a table, but you typically want to define a primary key for each table to force
each row to be uniquely identifiable.

Guidelines for primary keys include:

Only one primary key is allowed per table.
The primary key can be based on one or more columns.
The values in a primary key must be unique at all times, so they cannot include
NULL or duplicate values.
Protect primary key values from being modified after initial entry.

Examples of appropriate primary key values include:

Social security number
Drivers license number
User-allocated customer ID or code

Unique constraint

A unique constraint enforces uniqueness on the constraint key column or columns.
Unique constraints are different from the primary key in that:

You can define multiple unique constraints for a table.
The columns used to define a unique constraint can contain NULL values.

For example, customer table includes columns for a unique customer number, a uni
que account number for tracking financial accounting records, and a primary e-ma
il address. If you use the customer number as the primary key, you can create un
ique constraints on the account number and e-mail address columns. This ensures
that the values in each are unique and prevents accidental entry of duplicate da
ta.

Foreign keys

A foreign key consists of one or more columns and joins data in one table to dat
a in other related tables. The foreign key enforces referential integrity by ens
uring that each value is a valid value in the referenced tables primary key or a
unique constraint. In other words, each value used in the referencing table alre
ady exists in the referenced table. Otherwise, the SQL database engine prevents
you from entering the value and generates an error. Foreign key values do not ha
ve to be unique.

You establish one-to-one and one-to-many relationships with a single primary key
(or unique constraint) / foreign key pair between tables or within a table. Man
y-to-many relationships require the use of a third table, called a junction tabl
e, between related the tables.