Análise e deseño detallado de aplicacións de informática e de xestión/Regras do modelo básico

Análise e deseño detallado de aplicacións de informática e de xestión
← Volver a Transformación do esquema conceptual no lóxico estándar	Regras do modelo básico	Seguir con Regras das extensións do modelo entidade-relación →

Transformación de dominios

No modelo relacional estándar un dominio é un obxecto máis, propio da estrutura do modelo que, como tal, terá a súa definición concreta na linguaxe de definición de datos que se elixa (o estándar SQL neste caso).

Cómpre lembrar que o modelo lóxico estándar admite dominios, aínda que estes non existan nunha parte importante dos sistemas de xestión de bases de datos existentes. Será no paso ao modelo estándar específico cando se buscará unha solución ao problema, tratando de evitar a perda de semántica que orixina a pobreza de moitas aplicacións do modelo relacional.

Transformación de entidades

Cada atributo dunha entidade transfórmase nunha columna da relación á que deu lugar a entidade. Pero tendo en conta que temos atributos "identificador principal", outros que son identificadores alternativos e o resto de atributos que non son identificadores ─atributos secundarios─ subdivídese esta regra en tres:

Atributos identificadores

Os atributos identificadores que son os identificadores principais pasan a ser a clave primaria da relación. A linguaxe lóxica estándar recolle este concepto por medio da cláusula PRIMARY KEY na descrición da táboa, logo a transformación é directa e non se perde semántica.

Atributos identificadores alternativos

Respecto aos atributos identificadores alternativos o modelo lóxico estándar recolle estes obxectos mediante a cláusula UNIQUE, xa que o modelo relacional non os soporta directamente. Ao ser a transformación directa, non se perde semántica. En caso de querermos que os atributos non poidan recibir valores nulos, haberá que especificalo.

Atributos non identificadores

Estes atributos pasan a ser columnas da relación ─coma os anteriores─ que teñen permitido tomar valores nulos a non ser que se sinale o contrario.

Transformación de relacións

Segundo o tipo de correspondencia da relación, e outros aspectos semánticos dela cambiará o xeito de realizar a transformación ao esquema relacional, pos iso se subdivide esta regra en tres:

Relacións N:M

Un tipo de relación N:M transfórmase nunha relación que terá como clave primaria a concatenación dos campos que son clave allea, é dicir, os atributos clave principal dos tipos de entidade que asocia. Vese claramente que dentro dun esquema relacional non hai xeito de diferenciar que relacións veñen dunha entidade e cales dunha transformación de relacións, polo que hai certa perda de semántica neste punto da transformación. Dita semántica só pode salvarse almacenando comentarios sobre a procedencia de cada unha das táboas ou mediante un convenio na denominación destas táboas que veñen de relacións no modelo entidade-relación.

Ademais, cada un dos atributos que forman a clave primaria desta relación son claves alleas que fan referencia ás táboas que se converteron en entidades relacionadas (claves primarias), que se especifica na linguaxes lóxica estándar mediante a cláusula FOREIGN KEY dentro da sentencia de creación da táboa. Haberá que estudar ademais que ocorre nos casos de borrado e modificación da clave primaria á que se fai referencia, tendo en conta que na nosa linguaxe lóxica estándar as opcións permitidas son operación restrinxida (en caso de non especificar a acción ou poñer NO ACTION), posta a punto (SET NULL), posta a valor por defecto (SET DEFAULT) ou operación en cascada (CASCADE).

Tamén sería correcto non dar as opcións de borrado e modificación (é dicir, poñer NO ACTION), en cuxo caso rexeitaranse o borrado ou modificación daqueles campos das táboas ás que se fai reerencia cando o valor da súa clave primaria existise na táboa á que se fai referencia. Pola contra, non se admitirían as opcións de posta a nulos ou a valor por defecto.

Outra característica que cómpre recoller nesta transformación é a cardinalidade mínima de cada unha das entidades que participan na relación, o que se fai mediante a especificación de restricións, asercións o disparadores.

Relacións 1:N

Existen dúas solucións para a transformación dunha relación 1:N.

1. Propagar os atributos que son identificadores primarios do tipo de entidade que ten de cardinalidade máxima 1 á que ten N, é dicir, no sentido da frecha, desaparecendo o nome da relación, co que xeralmente se perde a semántica.
2. Transformalo nunha relación, coma se se tratase dunha relación N:M. Porén, neste caso a clave primaria da relación creada é só a clave primaria da táboa á que corresponde a cardinalidade N.

Aínda que depende do criterio do deseñador, e inflúe ademais da semántica a eficiencia, os casos nos que pode resultar apropiado deixar a relación como tal son os seguintes:

1. Cando o número de exemplares relacionados da entidade que propaga a súa clave é moi pequeno e, por tanto, existirían moitos valores nulos na clave propagada.
2. Cando se prevé que dita relación podería convertese nun futuro nunha relación de tipo N:M.
3. Cando a relación ten atributos de seu e non queremos propagalos (por conservar a semántica).

Por outra banda, a propagación de clave causa a aparición de claves alleas, cos seus mecanismos de borrado e actualización correspondentes, segundo a semántica do problema.

Se a relación se deixa como tal, o control das regras de borrado e modificación realízase de forma análoga á regra para relacións de moitos a moitos. Se se utiliza o mecanismo de propagación de clave, a cardinalidade mínima da entidade para a que a cardinalidade máxima é un (entidade de nivel superior) pódese controlar impedindo ou permitindo a existencia de nulos na clave allea propagada. Por isto é importante rexistrar as cardinalidades mínimas no modelado conceptual.

Relacións 1:1

Unha relación de tipo 1:1 é un caso particular dunha N:M, ou tamén dunha 1:N, polo que non hai nunha regra xeral fixa para a transformación deste tipo de relacións ao modelo relacional estándar, podéndose aplicar a regra para relacións de moitos a moitos (co que crearíamos unha relación) ou aplicar a regra para relacións de un a moitos (é dicir, propagar a clave correspondente). Neste último caso hai que observar que nunha relación dun a un, a propagación da clave pode facerse en ambos os dous sentidos.

Os criterios para aplicar unha ou outra regra e para propagar a clave baséanse nas cardinalidades mínimas, en recoller a meirande cantidade de semántica posible, evitar os valores nulos ou en motivos de eficiencia. As seguintes pautas deberías servir de orientación, pero non están pensadas para ser regras estritas:

• Se as entidades asociadas posúen cardinalidades (0,1), pode que cumpra deixar a relación como tal.
• Se unha das entidades que participa na relación posúe cardinalidades (0,1), mentres que na outra son (1,1), cómpre propagar a clave da entidade con cardinalidades (1,1) á táboa resultante da entidade de cardinalidades (0,1).
• No caso de que ambas as dúas entidades presenten cardinalidades (1,1), pódese propagar a clave de calquera delas á táboa resultante da outra, tendo en conta neste caso os accesos máis frecuentes e prioritarios aos datos das táboas. Pódense ter en conta (tamén por motivos de eficiencia) a propagación das dúas claves, o que introduce redundancias que deben controlarse por medio de restricións.

Transformación de atributos de relacións

Se a relación queda como tal, todos os seus atributos pasan a ser columnas da relación. A transformación é directa e non hai perda de semántica.

En caso de que a relación se transforme mediante propagación de clave, os seus atributos migran xunto coa clave á relación que corresponda, aínda que neste caso pode ser preferible crear unha nova relación no deseño lóxico estándar para representar as relacións con atributos.

Transformación de restricións

No que respecta ás restricións do usuario, existen certas cláusulas na linguaxe lóxica estándar que poden recollelas.

Outra posibilidade é utilizar a cláusula CHECK dentro da descrición da táboa para expresar unha condición que deben cumprir un conxunto de atributos da táboa, ou a cláusula aserción se a comprobación afecta a atributos de máis dunha táboa.

Tamén existe a posibilidade de utilizar disparadores.

Notas

Análise e deseño detallado de aplicacións de informática e de xestión
← Volver a Transformación do esquema conceptual no lóxico estándar	Regras do modelo básico	Seguir con Regras das extensións do modelo entidade-relación →