A buscar M!nas: MSAccess - modelo relacional

Buenas!

Entramos de lleno ya en el tema del diseño. Para diseñar una buena base de datos, partiendo del modelo E - R expuesto en la entrada anterior, necesitamos realizar un proceso de "relacionalización".

Y, ¿En qué consiste? Básicamente se trata de "pasar" las tablas a notación relacional (una sintaxis más cercana al SQL).

Pero, sin embargo, debemos (o deberíamos) aplicar una serie de normas y patrones antes y después de hacer la transformación. Aplicarlas sirve para preparar la futura base de datos para que sea más sencilla de comprender, y a la larga que todo sea más fácil e intuitivo.

PRETECAR

A los pasos previos a la creación del modelo relacional las conozco como PRETECAR (es un acrónimo de Previa REgla de Transformación del Esquema Conceptual A Relacional).

De estas reglas hay dos (PRETECAR 1 y PRETECAR 2). A saber:

• Eliminación de atributos múltiples
• Eliminación de atributos compuestos

La primera casi nunca tendremos que aplicarla, mientras que la segunda es más usual tener que aplicarla. Explico más a fondo las reglas:

Un atributo múltiple es aquel que puede tener más de un valor. Es decir, un atributo que pueda ser tomado como lista o array.

Un ejemplo sería el caso en que tenemos la siguiente tabla:

LIBRO

ISBN

Título

Autor

En este caso,  un libro puede estar escrito por varios autores. Así, deberíamos aplicar la PRETECAR 1.

Un atributo compuesto es todo aquel que pueda ser divisible, como por ejemplo "Dirección", "Nombre completo"...

Ahora ya sabemos cuál es el problema que eliminan las PRETACAR 1 y 2. Pero falta saber cómo lo hacen:

• PRETECAR 1: Extrapolamos el atributo múltiple a una entidad débil por existencia, dependiente de la clase de la que se segrega. Ambas clases guardarán una relación "n : n".
• PRETECAR 2: Se crean los atributos que fueren necesarios, y se vuelve a comprobar la PRETECAR 2 (a veces los elementos compuestos tienen "dentro" más elementos compuestos).

Una pequeña aclaración: una entidad débil por existencia es aquella que depende de otra, pero tiene "sentido" que exista de por sí. Una entidad débil por existencia es, en el caso anterior (LIBRO), Autor, ya que es un atributo múltilpe, y por PRETECAR 1 sería una entidad débil por existencia.

Como se ve, el término "Autor" y lo que ello representa tiene significado; pero en este caso está supeditado a la clase LIBRO.

El otro caso de entidad débil (entidad débil por identificación) es aquella que depende de la entidad fuerte para ser un ente. Es el caso de la relación "Factura - Línea". En este caso, "Línea" sería la entidad débil, y no tiene razón de ser si no se relaciona con una factura.

RETECAR

El siguiente paso, tras preparar nuestro modelo E - R para pasar a modelo relacional, es hacerlo mediante las llamadas RETECAR. Son sencillas reglas que permiten que el paso a modelo relacional sea estándar y rápido. Son:

• RETECAR 1: Todas las entidades presentes en el esquema conceptual se transforman en relaciones en el esquema relacional, manteniendo el número y tipo de atributos así como el identificador.
• RETECAR 2: Se divide en tres opciones:
• RETECAR 2.1: Si en una relación binaria el grado es "1 : 1" y ambas son obligatorias, entonces, se procede:
• RETECAR 2.1.1: Si ambas tienen el mismo identificador se creará una sola tabla formada por la agregación de los atributos de ambas entidades, siendo la PK el identificador común.
• RETECAR 2.1.2: Si ambas tienen identificadores diferentes, cada entidad se transformará en una tabla, usando la RETECAR 1, y cada tabla tendrá como PK el identificador de la propia entidad, y como FK la PK de la otra tabla.
• RETECAR 2.2: Si en la relación binaria "1 : 1" hay una entidad obligatoria y la otra opcional, cada entidad se transformará en una tabla usando la RETECAR 1, y adicionalmente se procederá por una de estas dos vías:
• RETACAR 2.2.1: El identificador de la opcional pasa como FK a la entidad obligatoria
• RETECAR 2.2.2: Se construye una nueva tabla correspondiente a la relación formada por los atributos identificadores de las dos entidades y siendo la PK el identificador de la entidad opcional.
• RETECAR 2.3: Si ambas entidades son opcionales, se crean sendas tablas por RETECAR 1, añadiendo una de estas dos posibilidades:
• RETECAR 2.3.1: Los id. de cada entidad pasan a formar parte como FK de la otra tabla.
• RETECAR 2.3.2: Se construye una nueva tabla correspondiente a la relación cuyos atributos serán los identificadores de las dos entidades, y la PK será uno de los dos identificadores de la tabla.
• RETECAR 3: Se divide en dos opciones:
• RETECAR 3.1: Si es una relación binaria de grado "1: n" o "n : 1", ambas entidades participan obligatoriamente o la entidad de grado "n" participa de manera opcional, cada entidad se transformará en una tabla por RETECAR 1, y el identificador de la entidad de grado "1" pasará a ser FK de la tabla de grado "n"
• RETECAR 3.2: Si es una relación binaria de grado "1: n" o "n : 1", siendo ambas entidades opcionales o solamente la de grado "1", cada entidad se transforma por RETECAR 1, y se genera una nueva tabla correspondiente a la relación formada por los atributos identificadores de ambas tablas y los atributos de la relación.
• RETECAR 4: En una relación binaria "n : n", o cualquier relación "n-aria", cada entidad pasa a ser una tabla, por RETECAR 1, y adicionalmente se genera una tabla para representar la relación. Esta nueva tabla estará formada por las PK de las entidades y los atributos de la relación, siendo la PK la agregación de las PK de las dos entidades.
• RETECAR 5: En una relación jerárquica, se desestimará la entidad supertipo, transfiriendo todos los atributos de ésta a cada una de las entidades subtipo. Las relaciones que tenía la entidad supertipo pasarán a ser consideradas por cada entidad subtipo.
• RETECAR 6: Se desestimarán las entidades subtipo, transfiriéndose todos los atributos de éstas a la entidad supertipo, así como cada una de las relaciones que las entidades subtipo mantenían
• RETECAR 7: La relación jerárquica se transformará en tantas relaciones "1 : 1" como entidades subtipo estén presente.

Nota: De las tres últimas RETECAR (5, 6, y 7) solo se aplica una por cada relación jerárquica, dependiendo de lo que el analista vea conveniente.

Con esto termina la teoría. Es el momento de aplicar estos pasos a nuestro prototipo de modelo E - R:

Para realizar el proceso, primero aplicaré las dos PRETECAR, y después usaré las reglas para usar las RETECAR.

a) PRETECAR:

 - Cambiamos el atributo "Apellidos" por dos: "apellido1" y "apellido2" -> PRETECAR 2.

Hasta aquí va todo bien. El modelo está preparado para ser transformado. Pero antes una anotación: es muy usual juntar los atributos de apellido (al igual que de nombre) en uno solo, pues hay gente que tiene un apellido, hay gente que tiene dos... y lo mismo con los nombres.

Yo soy partidario de separarlos siempre que sea posible (es decir, que no resulte "molesto"). En este caso irá bien separarlos, pero cuando pidamos los datos tendremos que tener en cuenta que deberemos pedir los apellidos por separado.

Ahora que está todo preparado, aplicamos a ambas entidades la RETECAR 1, quedando así:

usuario(nick, nombre, apellido1, apellido2, email, password)

estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)

En la entrada anterior dejamos ver que la relación era "1 : n", por lo que tenemos que aplicar la RETECAR 3. Del mismo modo, y como hay un atributo de relación (aunque no lo especifiqué), procederemos a usar la RETECAR 3.2.

Entonces, quedaría así:

usuario(nick, nombre, apellido1, apellido2, email, password)
estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)
juego(nick, id_estadistica, fecha)

Leyenda:

• Negrita y cursiva: nombre tabla
• Subrayado: clave primaria (PK)
• Cursiva: clave foránea (FK)
• Negrita y subrayado: clave primaria y clave foránea (PK/FK)

Finalmente, hacer un par de anotaciones: he añadido un atributo (id_estadistica) para poder distinguir todos los registros entre ellos. También, como he dicho antes, olvidé mencionar la fecha, pero es algo que no es obligatorio; sin embargo da mucho más juego y utilidad tenerlo.

Bien, de momento tenemos el modelo relacional. En la próxima entrega lo normalizaremos. Aunque vamos a intentar normalizarlo hasta la quinta forma normal (5FN), lo normal es hacerlo hasta la forma normal de Boyce-Codd (FNBC).

Y, con esta reflexión, os dejo.

¡Hasta la próxima!