Hướng dẫn học Microsoft SQL Server 2008 part 10 ppt

Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 52
Part I Laying the Foundation
For some entities, there might be multiple possible primary keys to choose from: employee number,
driver’s license number, national ID number (ssn). In this case, all the potential primary keys are known
as candidate keys. Candidate keys that are not selected as the primary key are then known as alternate
keys. It’s important to document all the candidate keys because later, at the SQL DLL layer, they will
need unique constraints.
At the conceptual diagramming phase, a primary key might be obvious — an employee number, an
automobile VIN number, a state or region name — but often there is no clearly recognizable uniquely
identifying value for each item in reality. That’s OK, as that problem can be solved later during the SQL
DLL layer.
Foreign keys
When two entities (tables) relate to one another, one entity is typically the primary entity and the other
entity is the secondary entity.
The connection between the two entities is made by replicating the primary key from the primary entity
in the secondary entity. The duplicated attributes in the secondary entity are known as a foreign key.
Informally this type of relationship is sometimes called a parent-child relationship.
Enforcing the foreign key is referred to as referential integrity.
The classic example of a primary key and foreign key relationship is the order and order details rela-
tionship. Each order item (primary entity) can have multiple order detail rows (secondary entity). The
order’s primary key is duplicated in the order detail entity, providing the link between the two entities,
as shown in Figure 3-3.
You’ll see several examples of primary keys and foreign keys in the ‘‘Data Design Patterns’’ section later
in this chapter.
Cardinality
The cardinality of the relationship describes the number of tuples (rows) on each side of the relation-
ship. Either side of the relationship may be restricted to allow zero, one, or multiple tuples.
The type of key enforces the restriction of multiple tuples. Primary keys are by definition unique and
enforce the single-tuple restriction, whereas foreign keys permit multiple tuples.
There are several possible cardinality combinations, as shown in Table 3-2. Within this section, each of
the cardinality possibilities is examined in detail.

Optionality
The second property of the relationship is its optionality. The difference between an optional relationship
and a mandatory relationship is critical to the data integrity of the database.
52
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 53
Relational Database Design 3
FIGURE 3-3
A one-to-many relationship consists of a primary entity and a secondary entity. The secondary entity’s
foreign key points to the primary entity’s primary key. In this case, the Sales.SalesOrderDetail’s
SalesOrderID i s the foreign key that relates to Sales.SalesOrderheader’s primary key.
TABLE 3-2
Common Relationship Cardinalities
Relationship Type First Entity’s Key Second Entity’s Key
One-to-one Primary entity–primary key–single
tuple
Primary entity–primary key–single tuple
One-to-many Primary entity–primary key–single
tuple
Secondary entity–foreign key–multiple
tuples
Many-to-many Multiple tuples Multiple tuples
53
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 54
Part I Laying the Foundation
Some relationships are mandatory, or strong. These secondary tuples (rows) require that the foreign key
point to a primary key. The secondary tuple would be incomplete or meaningless without the primary
entity. For the following examples, it’s critical that the relationship be enforced:
■ An order-line item without an order is meaningless.

■ An order without a customer is invalid.
■ In the
Cape Hatteras Adventures database, an event without an associated tour tuple is a
useless event tuple.
Conversely, some relationships are optional, or weak. The secondary tuple can stand alone without the
primary tuple. The object in reality that is represented by the secondary tuple would exist with or with-
out the primary tuple. For example:
■ A customer is valid with or without a discount code.
■ In the
OBXKites sample database, an order may or may not have a priority code. Whether
the order points to a valid tuple in the order priority entity or not, it’s still a valid order.
Some database developers prefer to avoid optional relationships and so they design all relationships as
mandatory and point tuples that wouldn’t need a foreign key value to a surrogate tuple in the primary
table. For example, rather than allow nulls in the discount attribute for customers without discounts, a
‘‘no discount’’ tuple is inserted into the
discount entity and every customer without a discount points
to that tuple.
There are two reasons to avoid surrogate null tuples (pointing to a ‘‘no discount’’ tuple): The design
adds work when work isn’t required (additional inserts and foreign key checks), and it’s easier to locate
a tuple without the relationship by selecting
where column is not null. The null value is a standard
and useful design element. Ignoring the benefits of nullability only creates additional work for both the
developer and the database.
From a purist’s point of view, a benefit of using the surrogate null tuple is that the ‘‘no discount’’ is
explicit and a null value can then actually mean unknown or missing, rather than ‘‘no discount.’’
Some rare situations call for a complex optionality based on a condition. Depending on a rule, the rela-
tionship must be enforced, for example:
■ If an organization sometimes sells ad hoc items that are not in the item entity, then the rela-
tionship may, depending on the item, be considered optional. The
orderdetail entity can

use two attributes for the item. If the
ItemID attribute is used, then it must point to a valid
item entity primary key.
■ However, if the
NonStandardItemDescription attribute is used instead, the ItemID
attribute is left null.
■ A check constraint ensures that for each row, either the
ItemID or
NonStandardItemDescription is null.
How the optionality is implemented is up to the SQL DDL layer. The only purpose of the conceptual
design layer is to model the organization’s objects, their relationships, and their business rules.
Data schema diagrams for the sample databases are in Appendix B. The code to create the
sample database may be downloaded from
www.sqlserverbible.com.
54
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 55
Relational Database Design 3
Data-Model Diagramming
D
ata modelers use several methods to graphically work out their data models. The Chen ER diagramming
method is popular, and Visio Professional includes it and five others. The method I prefer, Information
Engineering — E/R Diagramming, is rather simple and works well on a whiteboard, as shown in Figure 3-4.
The cardinality of the relationship is indicated by a single line or by three lines (crow’s feet). If the r elationship
is optional, a circle is placed near the foreign key.
FIGURE 3-4
A simple method for diagramming logical schemas
Primary Table Secondary Table
Another benefit of this simple diagramming method is that it doesn’t require an advanced version of Visio.
Visio is OK as a starting point, but it doesn’t give you a nice life cycle like a dedicated modeling tool. There

are several more powerful tools, but it’s really a personal preference.
Data Design Patterns
Design is all about building something new by combining existing concepts or items using patterns. The
same is true for database design. The building blocks are tables, rows, and columns, and the patterns are
one-to-many, many-to-many, and others. This section explains these patterns.
Once the entities — nouns and verbs — are organized, the next step is to determine the relationships
among the objects. Each relationship connects two entities using their primary and foreign keys.
Clients or business analysts should be able to describe the common relationships between the objects
using terms such as includes, has,orcontains. For example, a customer may place (has) many orders. An
order may include (contains) many items. An item may be on many orders.
Based on these relationship descriptions, the best data design pattern may be chosen.
One-to-many pattern
By far the most common relationship is a one-to-many relationship; this is the classic parent-child rela-
tionship. Several tuples (rows) in the secondary entity relate to a single tuple in the primary entity. The
relationship is between the primary entity’s primary key and the secondary entity’s foreign key, as illus-
trated in the following examples:
■ In the
Cape Hatteras Adventures database, each base camp may have several tours that
originate from it. Each tour may originate from only one base camp, so the relationship is
55
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 56
Part I Laying the Foundation
modeled as one base camp relating to multiple tours. The relationship is made between the
BaseCamp’s primary key and the Tour entity’s BaseCampID foreign key, as diagrammed in
Figure 3-5. Each
Tour’s foreign key attribute contains a copy of its BaseCamp’s primary key.
FIGURE 3-5
The one-to-many relationship relates zero to many tuples (rows) in the secondary entity to a single
tuple in the primary entity.

Ashville Ashville
Ashville
Appalachian Trail
Blue Ridge
Parkway Hike
Cape Hatteras
Outer Banks
Lighthouses
Cape Hatteras
Base Camp Tour
Primary Key: Base Camp Foreign Key: Base Camp Tour
■ Each customer may place multiple orders. While each order has its own unique OrderID
primary key, the Order entity also has a foreign key attribute that contains the CustomerID
of the customer who placed the order. The Order entity may have several tuples with the
same
CustomerID that defines the relationship as one-to-many.
■ A non-profit organization has an annual pledge drive. As each donor makes an annual pledge,
the pledges go into a secondary entity that can store an infinite number of years’ worth of
pledges — one tuple per year.
One-to-one pattern
At the conceptual diagram layer, one-to-one relationships are quite rare. Typically, one-to-one relation-
ships are used in the SQL ODD or the physical layer to partition the data for some performance or secu-
rity reason.
One-to-one relationships connect two entities with primary keys at both entities. Because a primary key
must be unique, each side of the relationship is restricted to one tuple.
For example, an
Employee entity can store general information about the employee. However, more
sensitive classified information is stored in a separate entity as shown in Figure 3-6. While security can
be applied on a per-attribute basis, or a view can project selected attributes, many organizations choose
to model sensitive information as two one-to-one entities.

Many-to-many pattern
In a many-to-many relationship, both sides may relate to multiple tuples (rows) on the other side
of the relationship. The many-to-many relationship is common in reality, as shown in the following
examples:
56
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 57
Relational Database Design 3
FIGURE 3-6
This one-to-one relationship partitions employee data, segmenting classified information into a
separate entity.
Employee Employee_Classified
John Smith John Smith
Mary Jones
Secret Stuff
Secret Stuff
Mary Jones
Davey Jones
Sue Miller
Primary Key: EmployeeID ClassifiedPrimary Key: EmployeeID
■ The classic example is members and groups. A member may belong to multiple groups, and a
group may have multiple members.
■ In the
OBXKites sample database, an order may have multiple items, and each item may be
sold on multiple orders.
■ In the
Cape Hatteras Adventures sample database, a guide may qualify for several tours,
and each tour may have several qualified guides.
In a conceptual diagram, the many-to-many relationship can be diagramed by signifying multiple cardi-
nality at each side of the relationship, as shown in Figure 3-7.

FIGURE 3-7
The many-to-many logical model shows multiple tuples on both ends of the relationship.
Customer Event
Many-to-many relationships are nearly always optional. For example, the many customers-to-many
events relationship is optional because the customer and the tour/event are each valid without the other.
The one-to-one and the one-to-many relationship can typically be constructed from items within an
organization that users can describe and understand. That’s not always the case with many-to-many
relationships.
To implement a many-to-many relationship in SQL DDL, a third table, called an associative table (some-
times called a junction table) is used, which artificially creates two one-to-many relationships between the
two entities (see Figure 3-8).
Figure 3-9 shows the associative entity with data to illustrate how it has a foreign key to each of the two
many-to-many primary entities. This enables each primary entity to assume a one-to-many relationship
with the other entity.
57
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 58
Part I Laying the Foundation
FIGURE 3-8
The many-to-many implementation adds an associative table to create artificial one-to-many relation-
ships for both tables.
FIGURE 3-9
In the associative entity (Customer_mm_Event), each customer can be represented multiple times,
which creates an artificial one-event-to-many-customers relationship. Likewise, each event can be
listed multiple times in the associative entity, creating a one-customer-to-many-events relationship.
John
Foreign Key: CustomerID Foreign Key: EventID
John
John
Appalachian

Trail
Blue Ridge
Parkway Hike
Customer EventCustomer_mm_Event
Paul
Bob
Paul Appalachian
Trail
Paul Outer Banks
Lighthouses
Appalachian
Trail
Blue Ridge
Parkway Hike
Outer Banks
Lighthouses
Dog House Tour
Primary Key: ContactID
Primary Key: CustomerID
58
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 59
Relational Database Design 3
In some cases the subject-matter experts will readily recognize the associated table:
■ In the case of the many orders to many products example, the associative entity is the
order
details
entity.
■ A class may have many students and each student may attend many classes. The associative
entity would be recognized as the

registration entity.
In other cases an organization might understand that the relationship is a many-to-many relationship,
but there’s no term to describe the relationship. In this case, the associative entity is still required to
resolve the many-to-many relationship — just don’t discuss it with the subject-matter experts.
Typically, additional facts and attributes describe the many-to-many relationship. These attributes belong
in the associative entity. For example:
■ In the case of the many orders to many products example, the associative entity (
order
details
entity) would include the quantity and sales price attributes.
■ In the members and groups example, the
member_groups associative entity might include
the
datejoined and status attributes.
When designing attributes for associative entities, it’s extremely critical that every attribute actually
describe only the many-to-many relationship and not one of the primary entities. For example, including
a product name describes the product entity and not the many orders to many products relationship.
Supertype/subtype pattern
One of my favorite design patterns, that I don’t see used often enough, is the supertype/subtype pattern.
It supports generalization, and I use it extensively in my designs. The supertype/subtype pattern is also
perfectly suited to modeling an object-oriented design in a relational database.
The supertype/subtype relationship leverages the one-to-one relationship to connect one supertype entity
with one or more subtype entities. This extends the supertype entity with what appears to be flexible
attributes.
The textbook example is a database that needs to store multiple types of contacts. All contacts have
basic contact data such as name, location, phone number, and so on. Some contacts are customers
with customer attributes (credit limits, loyalty programs, etc.). Some contacts are vendors with
vendor-specific data.
While it’s possible to use separate entities for customers and vendors, an alternative design is to use a
single

Contact entity (the supertype) to hold every contact, regardless of their type, and the attributes
common to every type (probably just the name and contact attributes). Separate entities (the subtypes)
hold the attributes unique to customers and vendors.Acustomerwouldhaveatuple(row)inthecon-
tact and the customer entities. A vendor would have tuples in both the contact and vendor entities. All
three entities share the same primary key, as shown in Figure 3-10.
Sometime data modelers who use the supertype/subtype pattern add a
type attribute in the supertype
entity so it’s easy to quickly determine the type by searching the subtypes. This works well but it
restricts the tuples to a single subtype.
59
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 60
Part I Laying the Foundation
FIGURE 3-10
The supertype/subtype pattern uses an optional one-to-one relationship t hat relates a primary key to a
primary key.
John
John
Paul
10 Points
3 Points
Contact
Customer
Vendor
Paul
Earnest Baked
Good
Frank’s General
Store
Earnest Baked Good

Nulls-R-Us
Always fresh
Never know when he’ll show up
Nulls-R-Us
Frank’s General Store Dependable
Primary Key: ContactID
Primary Key: ContactID Customer Loyality data
Primary Key: ContactID Vendor Status
Without the type attribute, it’s possible to allow tuples to belong to multiple subtypes. Sometimes this
is referred to as allowing the supertype to have multiple roles. In the contact example, multiple roles
(e.g. a contact who is both an employee and customer) could mean the tuple has data in the supertype
entity (e.g. contact entity) and each role subtype entity (e.g. employee and customer entities.)
Nordic O/R DBMS
N
ordic (New Object/Relational Design) is my open-source experiment to transform SQL Server into an
object-oriented database.
Nordic builds on the supertype/subtype pattern and uses T-SQL code generation to create a T-SQL API
fac¸ade that supports classes with multiple inheritance, attribute inheritance, polymorphism, inheritable class
roles, object morphing, and inheritable class-defined workflow state. If you want to play with Nordic, go to
www.CodePlex.com/nordic.
60
www.getcoolebook.com
Nielsen c03.tex V4 - 07/21/2009 12:07pm Page 61
Relational Database Design 3
Domain integrity lookup pattern
The domain integrity lookup pattern, informally called the lookup table pattern, is very common in pro-
duction databases. This pattern only serves to limit the valid options for an attribute, as illustrated in
Figure 3-11.
FIGURE 3-11
The domain integrity lookup pattern uses a foreign key to ensure that only valid data is entered into

the attribute.
Primary Key: ContactID Foreign Key: RegionID
Contact
North CarolinaNC
Region
CO Colorado
NY New York
John NC
Paul
CO
Earnest Baked Good
CO
Primary Key: RegionID
Region Description
Nulls-R-Us
NY
Frank’s General
Store
NC
The classic example is the state, or region, lookup entity. Unless the organization regularly deals with
several states as clients, the state lookup entity only serves to ensure that the state attributes in other
entities are entered correctly. Its only purpose is data consistency.
Recursive pattern
A recursive relationship pattern (sometimes called a self-referencing, unary,orself-join relationship) is one
that relates back to itself. In reality, these relationships are quite common:
■ An organizational chart represents a person reporting to another person.
■ A bill of materials details how a material is constructed from other materials.
■ Within the
Family sample database, a person relates to his or her mother and father.
Chapter 17, ‘‘Traversing Hierarchies,’’ deals specifically with modeling and querying recur-

sive relationships within SQL Server 2008.
61
www.getcoolebook.com