For instance, if the ???Student??? table includes the attributes
of name, address, and social security number (SSN), in addition to other attributes, one could probably choose
the combination name??“address, or the single attribute SSN, to uniquely identify students. Choosing SSN would
be wiser, because SSN will be more efficient to process, due to its numeric type, and it will change even less
frequently than a name or an address.
Sometimes there is no obviously good key attribute among the attributes of the table. One choice is to
concatenate the values of several fields to achieve an identifier that will be unique for each row. If this approach
leads to long, alphanumeric keys, it can be better to use a surrogate key. A surrogate key is simply a number,
generated by the DBMS, which is assigned to each tuple. In the case of the ???Student??? table, if SSN were not
one of the attributes to be stored for each student, one might decide to generate a surrogate key for the Student
table and call it ???StudentID???.
The second step is to create a relation for each weak and ID-dependent entity type. As with strong entities,
each attribute of the entity type in the data model becomes a column in the new relation.
Pages:
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401