Chapter 3: Working with Tables and Views Creating and Altering Tables
Total Page:16
File Type:pdf, Size:1020Kb
Chapter 3: Working with Tables and Views Page 1 of 23 Chapter 3: Working with Tables and Views A table is the basic unit of storage in a relational database. Tables and relationships (elements that link tables) are the most important elements of the relational model, which was designed by E. F. Codd in 1970. A table is composed of columns and a set of rows. First, a column represents an attribute of the entity described by the table. For example, an employee table might have these columns: Social Security number (SSN), first name, and last name. Second, a row, or a tuple, contains the actual data that is stored in a table. In the employee’s example, if there are 10 employees in the company, this table will contain 10 rows. A database object similar to tables in the way it is queried is a view. A view, also called a virtual table, is basically a predefined query stored in a database; every time the view is queried, SQL Server reads its definition and uses this definition to access the underlying table. Views add a layer between applications and tables because, through views, applications don’t have to query tables directly. In previous versions of SQL Server, a view never stored data. Now, using a new feature of SQL Server 2000 called indexed views, you can create indexes on views (with some restrictions), and this translates into permanent storage of the result set produced by the view. This chapter teaches you the following: l How to create and modify tables l The types of tables available in SQL Server l The advantages and usage of views l How to use extended properties to store metadata (information that describes objects) in a database Creating and Altering Tables The first step in the database design process is creating the entity relationship model, which is a conceptual representation of the database. The entity relationship model is comprised of entities, attributes, and relationships. An entity represents a real-world object, such as cars, employees, orders, students, courses, and teachers. Each entity has characteristics, which are called attributes. For example, the entity called employee has these attributes: Social Security number (SSN), last name, and first name. The last piece is the relationship, which is a link between two or more tables. There are three types of relationships: one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N). For example, there’s a one-to-many relationship between employees and orders because one employee can place many orders, and an order can be placed by just one employee. The study of entity-relationship models is out of the scope of this book. However, it’s important that you understand that entity-relationship modeling is the core of database design, and that good applications cannot be developed without a good database design. After the entity-relationship model is finished, the next step is to convert it into the database file://J:\Que\chapters\KB087.html 5/16/01 Chapter 3: Working with Tables and Views Page 2 of 23 structure. Specifically, a new table is created to represent each entity, and the table will have as many columns as attributes in the entity. Also, a table is created to represent each many-to-many relationship. The columns of this table will be the primary keys of the tables involved in the many-to- many relationship. Some CASE (computer-aided software engineering) tools out there transform an entity-relationship model into a script that you can run against a database server to create the database schema. Caution - Be careful when using the terms "relation" and "relationship," because they can lead to confusion. A relationship links two or more tables in a database, whereas relation is a synonym of table in the relational theory. Caution - By definition, a set has no ordering. Thus, in a table, rows have no specific order because a table contains a set of rows. For this reason, there is no concept of first or last row in a table. In SQL Server, the smallest unit of storage is the page. A page is 8KB in size and can store one or more rows; however, a row cannot span pages. For this reason, a single row can store up to 8,060 bytes, unless you use TEXT, NTEXT, or IMAGE data types, which are stored separately in their own pages. Each group of eight pages forms an extent, which is the unit of storage of tables and indexes. There are two types of extents: uniform and mixed. A uniform extent stores data for only a single object, whereas a mixed extent stores multiple objects’ data. In other words, a uniform extent is a set of eight pages (64KB) that stores a single object’s (table or index) data (see Figure 3.1). Refer to Chapter 6, "Optimizing Access to Data: Indexes," for more information on data storage. Figure 3.1 Data storage in SQL Server: pages and extents. Types of Tables In versions of SQL Server prior to SQL Server 2000, there were only two types of tables: permanent and temporary. The TABLE data type is a new feature of SQL Server 2000 that we can add to our set of tools. Note - Generally, for simplicity, permanent tables are just called tables. In contrast, when referring to temporary tables, the whole term is used (temporary table). Permanent Tables file://J:\Que\chapters\KB087.html 5/16/01 Chapter 3: Working with Tables and Views Page 3 of 23 Permanent tables store the actual data in a database. These are the tables you create as a result of the conversion of the entity relationship model to a database structure. Permanent tables are stored in the database where they are created. There are system tables (sysobjects, syscolumns, and sysconstraints) that keep track of the configuration information of tables such as owner, creation date, name and type of each column, and constraints defined on the table, among others. System tables are permanent tables that are created automatically by SQL Server at installation time. Their name begins with sys—for example, sysobjects. The purpose of system tables is to store metadata of databases, such as objects in the database (tables, views, stored procedures, extended stored procedures, and user-defined functions), users, roles, permissions, data and log files, and so on. By default, users cannot insert or modify the data in system tables. If you want to modify the data in system tables—which is not recommended—use the sp_configure system stored procedure to enable the ’allow updates’ configuration option. Listing 3.1 shows how to enable this option. Listing 3.1 Using sp_configure to Allow Modifications to System Tables sp_configure ’allow updates’, 1 GO RECONFIGURE WITH OVERRIDE GO One of the most important system tables in every database is sysobjects, which stores information of every object in a database. The object type is stored in the type column of sysobjects. Table 3.1 lists the possible values of the type column of the sysobjects system table. Table 3.1 Types of Objects in SQL Server Value in theType Type of Object Column C Check constraint D Default constraint F Foreign key constraint FN Scalar function IF Inline table function K Primary key or Unique constraint P Stored procedure R Rule S System table TF Multistatement table function TR Trigger U file://J:\Que\chapters\KB087.html 5/16/01 Chapter 3: Working with Tables and Views Page 4 of 23 User table V View X Extended stored procedure For example, if you want to list all system tables in the Northwind database, you can query sysobjects and filter by the ’S’ type, as shown in Listing 3.2. Listing 3.2 Listing System Tables in the Northwind Database USE Northwind SELECT name,crdate FROM sysobjects WHERE type = ’S’ name crdate -------------------- --------------------------- sysobjects 2000-04-18 01:51:58.910 sysindexes 2000-04-18 01:51:58.910 syscolumns 2000-04-18 01:51:58.910 systypes 2000-04-18 01:51:58.910 syscomments 2000-04-18 01:51:58.910 sysfiles1 2000-04-18 01:51:58.910 syspermissions 2000-04-18 01:51:58.910 sysusers 2000-04-18 01:51:58.910 sysproperties 2000-04-18 01:51:58.910 sysdepends 2000-04-18 01:51:58.910 sysreferences 2000-04-18 01:51:58.910 sysfulltextcatalogs 2000-04-18 01:51:58.910 sysindexkeys 2000-04-18 01:51:58.910 sysforeignkeys 2000-04-18 01:51:58.910 sysmembers 2000-04-18 01:51:58.910 sysprotects 2000-04-18 01:51:58.910 sysfulltextnotify 2000-04-18 01:51:58.910 sysfiles 2000-04-18 01:51:58.910 sysfilegroups 2000-04-18 01:51:58.910 (19 row(s) affected) Temporary Tables Temporary tables, like any other temporary object in SQL Server, are stored in tempdb and dropped automatically by SQL Server if they are not dropped explicitly. This type of table is used as a temporary working area for many purposes, such as multistep calculations and, also, to split up large queries. There are two types of temporary tables: local and global. The name of local temporary tables begins with #, whereas the name of global temporary tables begins with ##. Local temporary tables are available only in the connection that created them, and when the connection is finished, the table is automatically dropped by SQL Server, unless it is dropped explicitly using DROP TABLE. This type of table is very useful for applications that run more than one instance of a process simultaneously, because each connection can have its own copy of the temporary table, without interfering with the other connections executing the same code.