Datasheet

5
Chapter 1: Introducing T-SQL and Data Management Systems
Because ODBMS applications store objects instead of related entities, they make the system very
efficient when dealing with complex data objects and object - oriented programming (OOP)
languages such as the .NET languages from Microsoft as well as C and Java. When ODBMS
solutions were first released, they were quickly touted as the ultimate database system and
predicted to make all other database systems obsolete. However, they never achieved the wide
acceptance that was predicted. They do have a very valid position in the database market, but it
is a niche market held mostly within the Computer - Aided Design (CAD) and
telecommunications industries.
Object - relational database management system (ORDBMS) — The ORDBMS emerged from
existing RDBMS solutions when the vendors who produced the relational systems realized that
the ability to store objects was becoming more important. They incorporated mechanisms to be
able to store classes and objects in the relational model. ORDBMS implementations have, for the
most part, usurped the market that the ODBMS vendors were targeting for a variety of reasons
that I won ’ t expound on here. However, Microsoft ’ s SQL Server, with its
xml data type, the
incorporation of the .NET Framework, and the new
filestream data type introduced with SQL
Server 2008, could arguably be labeled an ORDBMS. The
filestream data type is discussed in
more detail later in this chapter and in Appendix E .
SQL Server as a Relational Database
Management System
This section introduces you to the concepts behind relational databases and how they are implemented
from a Microsoft viewpoint. This will, by necessity, skirt the edges of database object creation, which is
covered in great detail in Chapter 13 , so for the purpose of this discussion I will avoid the exact
mechanics and focus on the final results.
As I mentioned earlier, a relational database stores all its data inside tables. Ideally, each table will
represent a single entity or object. You would not want to create one table that contained data about both
dogs and cars. That isn ’ t to say you couldn ’ t do this, but it wouldn ’ t be very efficient or easy to maintain
if you did.
Tables
Tables are divided up into rows and columns. Each row must be able to stand on its own, without a
dependency to other rows in the table. The row must represent a single, complete instance of the entity
the table was created to represent. Each column in the row contains specific attributes that help define the
instance. This may sound a bit complex, but it is actually very simple. To help illustrate, consider a
real - world entity, such as an employee. If you want to store data about an employee, you would need to
create a table that has the properties you need to record data about your employee. For simplicity ’ s sake,
call your table Employee.
When you create your employee table, you also need to decide which attributes of the employee you
want to store. For the purposes of this example, suppose that you have decided to store the employee ’ s
last name, first name, Social Security number, department, extension, and hire date. The resulting table
would look something like that shown in Figure 1 - 1 .
❑
CH001.indd 5CH001.indd 5 3/26/10 11:35:34 AM3/26/10 11:35:34 AM