Paso a tablas

Introducción

La finalidad del diseño conceptual de una base de datos mediante el modelo Entidad-Relación, es ser transformado en un modelo lógico, es decir, en un conjunto de tablas que puedan ser implantadas en un Sistema Gestor de Bases de Datos. Existen un conjunto de normas básicas para definir dichas tablas a partir del diagrama Entidad-Relación. Utilizaremos la solución de la práctica guiada del tema de cardinalidades, añadiendo algunos atributos.

Entidades

Una entidad se transforma en una tabla cuyas columnas serán los atributos de dicha entidad, siendo la clave de la tabla el descriptor clave de la entidad, que puede estar formado por uno o más atributos de la entidad.

tbl-e.jpg

Relaciones

En principio, en el modelo Entidad-Relación las relaciones deben ser transformadas en tablas, pero hay casos en los que no generan tablas. Siempre que una relación tenga atributos genera una tabla cuyas columnas son dichos atributos, además de las claves primarias de las entidades que asocian, siendo éstas la clave primaria de la tabla generada.

Suponiendo una relación compra con un atributo fecha que asocia las entidades persona con clave primaria dni y coche con clave primaria matrícula, generamos la tabla correspondiente a la relación, mostrada a la derecha.

Cuando la relación no tenga atributos, para la generación de la tabla correspondiente a la relación, se seguirán los siguientes criterios basados en la clase de pertenencia y el grado de las entidades asociadas mediante dicha relación.

tbl-rel1.jpg

Relaciones unarias con cardinalidad 1:1

Sólo se genera la tabla de la entidad. Una entidad unaria, al estar asociada consigo misma, es siempre totalmente opcional o totalmente obligatoria. Por lo tanto, la clave primaria de la entidad aparecerá en una columna como clave primaria de la tabla y en otra columna como clave foránea, además del resto de los atributos de la entidad.

Si la clase de pertenencia es opcional, la clave foránea admitirá valores nulos, ya que una ocurrencia de entidad pude estar o no relacionada con otra ocurrencia de entidad. Si la clase de pertenencia es obligatoria, la clave foránea no admitirá valores nulos, ya que una ocurrencia de entidad deberá estar asociada con otra.

Relaciones unarias con cardinalidad 1:N

En este caso la generación de la tabla es exáctamente igual que el caso anterior de una relación unaria con cardinalidad 1:1.

Relaciones unarias con cardinalidad N:N

Sea cual sea la clase de pertenencia se generan tanto la tabla de la entidad como la tabla de la relación, teniendo esta última una columna con la clave de la entidad y otra también con la clave, pero con distinto nombre, ya que pertenece a otra ocurrencia de entidad, además de los atributos de la relación, si es que los tiene.

Relaciones binarias con cardinalidad 1:1

Hay 3 casos diferentes dependiendo de la cardinalidad de las entidades:

  • Las 2 entidades tienen clase de pertenencia obligatoria: Se generan las tablas de cada entidad y se pasa la clave primaria de una a la tabla de la otra como clave foránea, que no admite valores nulos.
  • Una entidad tiene clase de pertenencia opcional y la otra obligatoria: Se generan las tablas de cada entidad y se pasa la clave primaria de la entidad con clase de pertenencia opcional a la tabla de la otra entidad como clave foránea, que no admitirá valores nulos.
  • Las 2 entidades tienen clase de pertenencia opcional: Se generan las tablas de cada entidad y se pasa la clave primaria de una entidad a la tabla de la otra como clave foránea, que admitirá valores nulos.

Relaciones binarias con cardinalidad 1:N

Hay 2 posibilidades dependiendo de la cardinalidad de las entidades:

  • Las 2 entidades tienen clase de pertenencia obligatoria: Se generan las tablas de cada entidad y se pasa la clave primaria de la entidad con cardinalidad 1 a la tabla de la otra entidad como clave foránea, que no admitirá valores nulos.
  • La entidad con cardinalidad N tiene clase de pertenencia opcional: Se hace igual que el caso anterior de una relación binaria con cardinalidad 1:N, sólo que la clave foránea admite valores nulos.

Relaciones binarias con cardinalidad N:N

Sea cual sea la clase de pertenencia de las entidades, se generan las tablas correspondientes a las entidades y a la relación. Las claves primarias de las entidades aparecen en la tabla de la relación como clave primaria de ésta.

Relaciones n-arias

Sean cuales sean las cardinalidades de las entidades asociadas se crea una tabla para cada una de ellas y otra para la relación, con las claves primarias de las entidades que asocia. Si alguna de las entidades tiene clase de pertenencia opcional, la clave primaria de dicha entidad perteneciente a la tabla de la relación como clave foránea, admite valores nulos, siempre y cuando no forme parte de la clave primaria de la relación.

Práctica Paso a tablas

Ejemplo

Vamos a empezar a diseñar una base de datos para nuestra aplicación de comercio electrónico, que será utilizable pero no excesivamente complicada. Estas son las funcionalidades escogidas:

  • Los productos estarán divididos en categorías, que tendrán nombre y descripción y un solo nivel de profundidad (esto es, no podrán anidarse).
  • Mostraremos algunos productos en la portada de la tienda, aquellos que consideremos más importantes o apetecibles para el cliente.
  • Los productos tendrán un precio que podrá variar a lo largo del tiempo, un nombre y una descripción.
  • Para completar el proceso de pago el cliente debe dar ciertos datos: el nombre, los apellidos y el email. La tienda recordará esos datos para que no tenga que introducirlos cada vez que quiera comprar algo, reduciendo el número de "clicks" necesarios para la compra. El cliente podrá acceder a esos datos introduciendo usuario y contraseña.
  • El administrador podrá consultar los pedidos que han hecho los clientes, entrando con un usuario y contraseña propios. Los pedidos tendrán la información del cliente y de cada uno de los productos, el precio al que se vendieron y el número de unidades de cada producto.

Habrá que realizar el modelo entidad - relación que corresponda a este diseño y su paso a tablas.

El siguiente diagrama presenta una posible solución, aunque no necesariamente la única, claro:

diagrama.jpg

Y este sería el resultado de pasarlo a tablas:

Tabla Campos
categorias id
nombre
descripcion
productos id
idcategoria
nombre
descripcion
precio
enportada
importancia
usuarios id
password
nombre
apellidos
email
esadmin
pedidos id
idusuario
fecha
total
productos_pedido idpedido
idproducto
precio
cantidad

« MySQL 4 | Paso a tablas y MySQL

Si no se indica lo contrario, el contenido de esta página se ofrece bajo Creative Commons Attribution-ShareAlike 3.0 License