Disseny de bases de dades: Value Object i Embedded Value

En aquest petit article vull comentar què hem de fer a l’hora de dissenyar una base de dades quan ens trobem un Value Object, una classe d’objectes amb semàntica de valor i no d’objecte. Fowler, a [FOW], documenta aquest patró (que revisaré) i documenta un patró per a tractar-lo en fer el disseny de la base de dades: Embedded Value.

Value Object

En un anàlisi UML hi poden aparèixer classificadors (diguem-ne classes, si es vol) que no tenen semàntica d’objectes. Fowler diu que tenen semàntica de valor per oposició a la semàntica d’objectes amb referència.

Els valors (objectes amb semàntica de valor, segons Fowler) es comparen pel seu contingut, però no tenen identitat. Això fa que no tingui sentit pensar en termes de quina és la llista d’instàncies d’un tipus de valor en un sistema. Els objectes, en canvi, es comparen per la seva identitat, no pel seu contingut, i ens interessa saber quines instàncies en tenim al sistema.

Exemple

Vegem un exemple. Suposem que disposem d’un model conceptual molt senzill format per les dues classes següents:

Associació * - * entre Person i Department amb atributs id i name a totes dues classes i atribut dateOfBirth de tipus Date a Person

En aquest cas, les classes Person i Department tenen semàntica de referència, ja que, efectivament, ens interessa distingir cada un de les instàncies que en tenim i distingim entre aquestes per la seva identitat.

Les “classes” String i Date (que podrien haver aparegut com a classificadors explícitament, en forma de caixa al diagrama) tenen semàntica de valor, ja que no ens interessa saber quines instàncies de Date o d’String hi ha al sistema i les comparem pel seu contingut (una data és igual que una altra si tenen el mateix dia, mens, any, etc).

Value Objects típics

Tots els tipus primitius es poden considerar objectes per valor. Des d’un punt de vista d’anàlisi m’agrada utilitzar tipus independents de llenguatges de programació, com ara, natural, enter, real, String, data, hora, etc. UML proposa una sèrie de tipus primitius que podem usar des del punt de vista d’anàlisi.

Altres Vaule Object són menys obvis i poden tenir, inclús, atributs:

Quantitats: Un cas paradigmàtic és el resultat d'aplicar el patró Quantity de Larman \[LAR\], on indiquem una magnitud (com el preu d'un producte, per exemple) mitjançant valor i unitats (ex 12 €). Es dóna le cas que aquest cas particular del patró Quantity aplicat a diners és anomenat, per Fowler, patró Money.
Intervals de temps: Resultat d'aplicar el patró Range, també de Larman
Enumeracions: Com, per exemple, els mesos de l'any

Embedded Value

Fowler resumeix molt bé com tractar els Value Objects a l’hora de dissenyar bases de dades amb un bon exemple. Cito textualment (en traducció lliure de de l’anglès): “Cap persona amb dos dits de seny voldria una taula de valors monetaris”. El cas de les dates és més flagrant.

La solució que proposa en forma de patró Embedded Value és mapejar els camps del Value Object com camps de la taula que conté una referència cap a aquest Value Object. Això implica, evidentment, no crear taules per a aquests valors.

Així, per exemple, si una persona té una data de naixement, a la taula persona hi posarem una columna dataNaixement de tipus Date (com a primer exemple obvi). Si la persona tingués, a més, una associació cap a un Diner (quantiat i moneda) anomenada limitCrèdit, posaríem a la taula persona, dues columnes: quantitatLimitCredit i monedaLimitCredit.

Per si a algú li preocupa, en el cas que sobre aquesta base de dades estiguem desenvolupant una aplicació orientada a objectes amb Domain Model i Data Mapper, els bastiments de Data Mapper actuals solucionen prou bé aquesta solució. Hibernate, per exemple, permet mantenir aquesta estructura de base de dades però utilitzant una classe Java per a representar el tipus de dades (per exemple, la classe Diner). Per a més detalls, vegeu [HIB].