En un post anterior vaig posar un esquema sobre disseny de bases de dades a partir del model conceptual de l’anàlisi. En aquell post s’hi mencionen un patró en el que voldria aprofundir: Surrogate o Substitut.

Fowler menciona a [FOW] un patró anomenat Identify Field consistent a representar la clau primària d’un registre d’una Base de Dades en forma d’atributs (en un Domain Model). El cas és que inclou una dissertació força bona a l’hora de triar una clau primària a la base de dades. Bona part d’aquesta dissertació és independent del fet d’aplicar o no Domain Model i, en general, independent del fet de desenvolupar o no aplicacions sobre la base de dades en qüestió.

Clau natural vs artificial

Una dels primers punts a discutir és si es farà servir una clau natural (és a dir, que té significat en el nostre domini, Fowler les anomena meaningful) o una clau artificial (sense significat propi, anomenades meaningless per Fowler). Si tenim una taula de persones, per exemple, una clau natural seria el DNI de la persona, mentre que una clau artificial seria un identificador numèric generat per la base de dades.

Per a que una clau funcioni correctament ha de ser única (evidentment) i immutable. Com comenta Fowler, les claus naturals no són immutables degut, principalment, als errors humans. Com que una clau natural té significat en el domini, és important que el seu valor sigui el que ha de ser. I per tant, en cas d’error, caldrà corregir-la.

Per tant, com a norma general, cal utilitzar claus artificials.

Clau composta vs clau simple

Una clau composta està formada per una combinació de camps que han de ser únics, mentre que una clau simple només té un camp.

Les claus simples són més senzilles de fer servir i manipular. En particular, des d’un punt de vista de bases de dades, és més senzill establir claus foranes cap a una clau primària si aquesta és simple. Les claus artificials són simples per la seva pròpia naturalesa, però les claus naturals poden ser tant simples com compostes.

Aleshores: Quan usar un substitut?

Resposta ràpida: Sempre.

Excepcions a la norma: Associacions M:N, o N-àries on N>2 sense classe associativa

Les taules que, des d’un punt de vista d’anàlisi, no es corresponen a cap classe no mereixen, sota el meu punt de vista, un substitut de la clau primària. Aquestes taules només es consultaran per a veure les relacions entre altres taules i no tenen altra informació que aquesta relació. Per tant, cada fila d’una d’aquestes taules es correspon amb una associació entre files d’altres taules. No té sentit que cada una d’aquestes associacions tingui un identificador propi, ja que mai les recuperarem per identificador.

Si l’associació té una classe associativa, però, l’analista està indicant que hi ha informació addicional. En tal cas, és possible que interessi identificar aquestes instàncies i, per tant, si que recomanaria usar substitut de la clau primària.

En aquesta excepció, la clau primària serà composta, però continuarà sent artificial si les taules a les que refereix l’associació tenen, al seu torn, claus artificials. I per tant, continuarà sent immutable.

Unicitat del substitut de la clau primària

Fowler menciona també un punt a tenir en compte. Un substitut de la clau primària es pot dissenyar de tal forma que sigui:

• Únic a la taula: No poden haver-hi, a la mateixa taula, dues files amb el mateix identificador. Però podria ser que hi hagi en alguna altra taula una altra fila amb el mateix identificador.
• Únic a tota la base de dades: No poden haver-hi en tota la base de dades dues files amb el mateix identificador. Però podria ser que en alguna altra base de dades existeixi alguna fila que fagi servir el mateix identificador.
• Únic globalment: No pot haver-hi en tot el món una altra fila amb aquest identificador

Resumint-ho ràpidament, els identificadors únics globalment són difícils de dissenyar i aporten aventatges relatius en la majoria de casos. Entre les claus úniques a la taula o a la base de dades, els avantatges i inconvenients sorgeixen en manipular aquestes files fora de la base de dades (per exemple, quan cal fer URLs per identificar recursos en una aplicació web o quan cal fer servir un data mapper). En aquests casos la meva experiència és que un identificador únic a la taula sol ser suficient.

Per a una discussió detallada de quina és la millor opció recomano llegir Fowler.

Referències

• [FOW] Fowler, M (2005). Patterns of Enterprise Application Architecture. Boston, US: Addison-Wesley
• [DBD] Sistach et al. (?) , Disseny de Bases de Dades. Barcelona: UOC