The document discusses using surrogate keys for database entities. It notes that natural keys may not always exist or be suitable as primary keys. A surrogate key is a primary key created by the database designer that has no intrinsic meaning. The document uses an event booking database as an example, where a composite natural key of date, time, and room is proposed. It also discusses a many-to-many relationship between events and resources used, with a composite surrogate key proposed for the linking table to avoid complexity from a lengthy natural key. Surrogate keys are accepted practice when no natural key exists or one is too complex, at the cost of ensuring data integrity through other constraints.

2. INTRODUCTION
There are some instances when a
primary key doesn’t exist in the
real world or when the existing
natural key might not be a suitable
primary key.

3. SURROGATE KEY:
Is a primary key created by
the database designer to
simplify the identification of
entity instances.

5. ADVANTAGE
Since it has no intrinsic meaning,
values for it can be generated by
the DBMS to ensure that unique
values are always provided.

7. TABLE 5.4
DATE TIME_START TIME_END ROOM EVENT_NAME PARTY_OF
6/17/2010 11:00AM 2:00PM Allure Burton 60
Wedding
6/17/2010 11:00AM 2:00PM Bonanza Adams Office 12
6/17/2010 3:00PM 5:30PM Allure Smith Family 15
6/17/2010 3:30PM 5:30PM Bonanza Adam’s Office 12
6/18/2010 1:00PM 3:00PM Bonanza Boy Scouts 33
6/18/2010 11:00AM 2:00PM Allure March of 25
Dines
6/18/2010 11:00AM 12:30PM Bonanza Smith Family 12

8.  Given the data shown in table 5.4 you would
model the EVENT entity as:
EVENT(DATE, TIME_START, TIME_END,ROOM
,EVENT_NAME,PARTY_OF)

9. DATE TIME_ TIME ROOM EVENT_ PART
START _EN NAME Y_OF What primary key would you
D suggest? In this case , there is no
6/17 11:00 2:00 Allure Burton 60 simple natural key that could be
/10 AM PM Wedding
used as a primary key in the
6/17/ 11:00 2:00 Bonanza Adams 12 model. Based on the primary key
10 AM PM Office concepts you learned about in
previous chapters, you might
6/17/ 3:00 5:30 Allure Smith 15 suggest one of these options.
10 PM PM Family
6/17/ 3:30 5:30 Bonanza Adam’s 12
10 PM PM Office
(DATE, TIME_START, ROOM)
6/18/ 1:00 3:00 Bonanza Boy 33 Or
10 PM PM Scouts (DATE, TIME_END, ROOM)
6/18/ 11:00 2:00 Allure March of 25
10 AM PM Dines
6/18/ 11:00 12:3 Bonanza Smith 12
10 AM 0PM Family

10. DAT TIME_ TIME_ ROO EVENT_ PART
E START END M NAME Y_OF Assume you select the
composite primary key (DATE,
TIME_START,ROOM) for the
6/17 11:00 2:00P Allure Burton 60 EVENT entity. Next ,you
/10 AM M Wedding
determine that one EVENT may
6/17 11:00 2:00P Bonan Adams 12 use many RESOURCES such as
/10 AM M za Office tables, projectors, pc and
stands, and that the same
6/17 3:00 5:30P Allure Smith 15 RESOURCE may be use for
/10 PM M Family many EVENTS. The RESOURCE
entity would be represented by
6/17 3:30 5:30P Bonan Adam’s 12 the ff. attributes:
/10 PM M za Office
6/18 1:00 3:00P Bonan Boy 33 RESOURCE (RSC_ID,
/10 PM M za Scouts RSC_DESCRIPTION,RSC_T
6/18 11:00 2:00P Allure March of 25 YPE, RSC_QTY,RSC_PRICE)
/10 AM M Dines
6/18 11:00 12:30 Bonan Smith 12
/10 AM PM za Family

11. DATE TIME_ TIME ROOM EVENT PART
START _EN _NAME Y_OF Given the business rules, the M:N
D relationship between RESOURCE
and EVENT would be represented
6/17 11:00 2:00P Allure Burton 60
via the EVNTRSC composite entity
/10 AM M Wedding
with a composite primary key as
6/17 11:00 2:00P Bonan Adams 12 follows:
/10 AM M za Office
EVNTRSC (DATE, TIME _START,
6/17 3:00 5:30P Allure Smith 15 ROOM, RSC_ID, QTY _USED
/10 PM M Family
You now have a lengthy four-
6/17 3:30 5:30P Bonan Adam’s 12 attribute composite primary key.
/10 PM M za Office What would happen if the
EVNTRSC entity’s primary key
were inherited by another
6/18 1:00 3:00P Bonan Boy 33 existence dependent entity? At
/10 PM M za Scouts this point, you can see that the
6/18 11:00 2:00P Allure March of 25 composite primary key could
/10 AM M Dines make the implementation of the
database and program coding
6/18 11:00 12:30 Bonan Smith 12
unnecessarily complex.
/10 AM PM za Family

12. Surrogate primary keys are accepted
practice in today's complex data
environments.

13. They are especially helpful when there
is no natural key, when the selected
candidate key has embedded semantic
contents or when the selected
candidate key is too long or
cumbersome.

14. However , there is a trade-off; if you use
a surrogate key, you must ensure that
the candidate key of the entity in
question performs properly through the
use of “unique index” and “not null”
constraints.

15. PREPARED BY:
ROSELYN P. CEA
ALLYSA JANE CATALLA
BLIS -III