SQL Server Keys

In this part, I will be briefing about different kind of keys available in database systems. Base example I will be using the following table to explain about database keys EMPLOYEE [EMPLOYEE_ID, EMPLOYEE_SSN_ID, EMPLOYEE_DEPT_ID, EMPLOYEE_FIRST_NAME, EMPLOYEE_LAST_NAME, and EMPLOYEE_ADDRESS] Candidate Key A candidate key is a combination of attributes that can be uniquely used to identify a database record without any extraneous data. Each table may have one or more candidate keys. In general, one of these candidate keys is selected as the table primary key. Example - From the above table EMPLOYEE_ID, EMPLOYEE_SSN_ID, and EMPLOYEE_DEPT_ID can be considered as candidate keys Primary Key a primary key is a single column or combination of columns that uniquely defines a record. None of the columns that are part of the primary key can contain a null value. A table can have only one primary key. Example - EMPLOYEE_ID or EMPLOYEE_SSN_ID can be considered as primary keys Unique Key A unique key or primary key [is a candidate key] to uniquely identify each row in a table. It is comprised of either a single column or multiple columns. The major difference is that for unique keys the implicit NOT NULL constraint is not automatically enforced, while for primary keys it is enforced. Thus, the values in unique key columns may or may not be NULL. Differences between Primary Key and Unique Key Primary Keys 1. It will not accept null values. 2. There will be only one primary key in a table. 3. Clustered index is created in Primary key. 4. Primary key allows each row in a table to be uniquely identified and ensures that no duplicate rows exist. Unique Keys 1. Null values are accepted. 2. More than one unique key will be there in a table. 3. Non-Clustered index is created in unique key. 4. Unique key constraint is used to prevent the duplication of key values within the rows of a table and allow null values. Alternate Key A candidate key that is not the primary key is called an alternate key. Example - If EMPLOYEE_ID is considered as primary keys then EMPLOYEE_SSN_ID is an alternate key. Super key A super key is a combination of attributes that can be uniquely used to identify a database record. A table might have many super keys. Candidate keys are a special subset of super keys that do not have any extraneous information in them. Gayatri Tandle Page 1 of 3

SQL Server Keys

A primary key is therefore a minimum super key. Examples - Any combination of the following can be considered as a Super key - EMPLOYEE_ID - Minimal Super Key - EMPLOYEE_ID and EMPLOYEE_SSN_ID - EMPLOYEE_ID, EMPLOYEE_SSN_ID and EMPLOYEE_DEPT_ID - EMPLOYEE_ID, EMPLOYEE_SSN_ID, EMPLOYEE_DEPT_ID, EMPLOYEE_FIRST_NAME - EMPLOYEE_SSN_ID, EMPLOYEE_FIRST_NAME, EMPLOYEE_LAST_NAME Foreign Key The foreign key identifies a column or a set of columns in one (referencing) table that refers to a column or set of columns in another (referenced) table.

Composite Key A primary key that made up of more than one attribute is known as a composite key. Example - [EMPLOYEE_ID and EMPLOYEE_SSN_ID] can together be treated as (one of) composite keys. Another combination can be [EMPLOYEE_ID, EMPLOYEE_SSN_ID and EMPLOYEE_DEPT_ID] Surrogate Key Surrogate keys are keys that have no business meaning and are solely used to identify a record in the table. Such keys are either database generated (example: Identity in SQL Server, Sequence in Oracle, Sequence/Identity in DB2 UDB etc.) or system generated values (like generated via a table in the schema). Surrogate key is a substitution for the natural primary key. It is just a unique identifier or number for each row that can be used for the primary key to the table. The only requirement for a surrogate primary key is that it is unique for each row in the table. Data warehouses typically use a surrogate (also known as artificial or identity key) key for the dimension tables primary keys. They can use Infa sequence generator or Oracle sequence or SQL Server Identity values for the surrogate key. It is useful because the natural primary key (i.e. Customer Number in Customer table) can change and this makes updates more difficult. Some tables have columns such as AIRPORT_NAME or CITY_NAME which are stated as the primary keys (according to the business users) but not only can these change indexing on a numerical value is probably better and you could consider creating a surrogate key called say AIRPORT_ID. This would be internal to the system and as far as the client is concerned you may display only the AIRPORT_NAME. 2. Adapted from response by Vincent on Thursday March 13 2003 another benefit you can get from surrogate keys (SID) is: Gayatri Tandle Page 2 of 3

SQL Server Keys

Tracking the SCD - Slowly Changing Dimension. Let me give you a simple classical example: On the 1st of January 2002 Employee 'E1' belongs to Business Unit 'BU1' (that's what would be in your Employee Dimension). This employee has a turnover allocated to him on the Business Unit 'BU1' but on the 2nd of June the Employee 'E1' is muted from Business Unit 'BU1' to Business Unit 'BU2.' All the new turnover has to belong to the new Business Unit 'BU2' but the old one should Belong to the Business Unit 'BU1.' If you used the natural business key 'E1' for your employee within your data warehouse everything would be allocated to Business Unit 'BU2' even what actually belongs to 'BU1.' If you use surrogate keys you could create on the 2nd of June a new record for the Employee 'E1' in your Employee Dimension with a new surrogate key. This way in your fact table you have your old data (before 2nd of June) with the SID of the Employee 'E1' + 'BU1.' All new data (after 2nd of June) would take the SID of the employee 'E1' + 'BU2.' You could consider Slowly Changing Dimension as an enlargement of your natural key: natural key of the Employee was Employee Code 'E1' but for you it becomes Employee Code + Business Unit - 'E1' + 'BU1' or 'E1' + 'BU2.' But the difference with the natural key enlargement process is that you might not have all part of your new key within your fact table so you might not be able to do the join on the new enlarge key -> so you need another id.

Gayatri Tandle

Page 3 of 3