Diseño

Partimos de que tenemos un problema de representar una información. Una de las formas más utilizadas para el diseño es el Modelo Entidad-Relación (E/ R). De esta forma se hace una representación de la información que puede luego ser implementada de diferentes formas. 

Pero como vamos a utilizar tablas, lo siguiente a realizar es el paso a tablas para convertir ese modelo E/ R en un modelo relacional. (Para quienes quieran indagar más en el paso de un diseño al modelo relacional se encontrarán con la normalización de bases de datos. Son una serie de reglas para obtener las tablas de forma que se asegure ciertas propiedades de los datos, con el fin de mantener la consistencia y facilitar el manejo de los datos. Un buen modelo E/ R nos ayuda a la consecución de esta normalización.) Una vez que tenemos el modelo relacional, mediante SQL se crean las tablas en el Sistema gestor de bases de datos.

Pasemos a un ejemplo. 

Supongamos que extraemos información de los siguientes puntos: Se desea guardar información de los departamentos: nombre y localidad. 

De los empleados: nombre, salario, trabajo, y el jefe. 

Un empleado está en un departamento.

Un empleado solo tienen un jefe.

Un jefe, puede serlo de varios empleados.

Lo que se conoce debe estar claro. Cualquier pequeño detalle hay que pensar cómo queda en el modelo. Pues la información sería otra o se relacionaría de distinta manera. Y esto a su vez cambiaría el modelo relacional, es decir, las tablas. Para dar una respuesta correcta a las futuras consultas tienen que ser coherentes con el modelo de los datos. Vamos a ir analizando el ejemplo. La primera frase: «Se desea guardar información de los departamentos: nombre y localidad.» Esto quiere decir que vamos a tener varios departamentos. Y de cada uno de ellos su nombre y localidad. Y entendemos que no quieren nada más. No interesa saber dónde queda esa localidad, ni código postal ni otros datos. En la parte del diseño formalmente no se piensa en tablas pues el diseño es independiente. Pero para ir entendiendo hacia dónde se va. Y una fila de una tabla representativa a una entidad. Y tendrá una celda de una columna para almacenar el nombre y otra para la localidad. Cualquier información que se coloque en esta tabla es del departamento en sí. El departamento es la entidad de la que se trata en este punto. Las entidades se representan con rectángulos. Mientras que sus atributos se representan con elipses. Si queremos más datos de la localidad esto da paso a que la localidad sea una entidad independiente con sus atributos. Pues tendrá suficiente peso para ser una entidad.  Ahora nos han dicho que solo quieren el nombre del departamento y la localidad; toda entidad debe tener un identificador. Es decir, que como cada fila va a ser un elemento, un departamento, debemos identificar de alguna forma cada departamento. Esto podría ser con el nombre, pero significa que el nombre tiene que ser único. Sin embargo, muchas veces se opta por un código. Entonces, en este caso se añade un número de departamento que es el que identifica al departamento. Algunos de los argumentos para que un identificador sea numérico puede ser por eficiencia. Al querer optimizar luego las búsquedas por códigos numéricos en vez de códigos alfanuméricos. Ya que los gestores suelen tener tipos de datos numéricos optimizados ya que las máquinas se manejan mejor con los números. Otro argumento puede ser el de la seguridad. Para identificar a los elementos por códigos conocidos a nivel de base de datos. Y la relación con otros datos se realiza por estos códigos conocidos solo internamente. Es decir, que el nombre del departamento fuese conocido públicamente pero el número de departamento no. En otras palabras, ocultar información que no se desea publicitar.

De manera similar al departamento tenemos en este caso la entidad de empleado. De un empleado se necesita saber su nombre, salario, oficio y quién es el jefe. Quién es el jefe es una relación con otro empleado. No es un atributo del empleado. El cómo nombrar a los atributos lo decide quien diseña, el nombre es preferible que sea auto-identificable. Es decir, que sea claro y no toque buscar documentación donde se explique qué es. Además, al igual que se hizo con el departamento, al empleado se le añade un número de empleado, el cual es el atributo clave. Los atributos clave se los identifica porque están subrayados. Ahora pasemos a las frases: «Un empleado está en un departamento.» «En un departamento hay varios empleados.» 

Aquí ya identificamos una relación. La relación entre la entidad empleado y la entidad departamento. Las relaciones se las representa con rombos. Y dentro se utiliza algún verbo de la forma: es, está, trabaja. Lo de que un empleado está en un departamento hay que aclarar si es obligatorio que esté en uno y solo en uno. Y en la notación de diseño eso se expresa con dos números que indican el valor mínimo y el máximo (mínimo, máximo). (1,1) indica que el empleado al menos está en un departamento y como máximo en uno.

Por otro lado, el departamento podrá relacionarse con varios empleados. Esto se indica con la letra ene (n). Los valores máximos son uno o ene. Mientras que los valores mínimos son cero o uno. Si como valor mínimo tenemos un uno, indicamos que al menos debe relacionarse con uno, como es el caso del empleado. Este diseño nos dice que todo empleado debe indicar en qué departamento está. 

Y respecto a las últimas dos frases: «Un empleado solo tienen un jefe.» «Un jefe, puede serlo de varios empleados.» Esta es una relación entre un empleado y otro empleado. O dicho de otro modo, una relación de la entidad empleado consigo misma. En este diseño se expresa información tal que podemos tener empleados sin jefe. Claro está existirá al menos uno que es quien no tenga a nadie como jefe. También, con el otro valor mínimo se expresa que se puede no ser jefe de alguien. Si en el futuro nos quieren preguntar cuántos jefes tiene un empleado la respuesta es clara: solo uno. Nuestro modelo de datos solo permite tener como máximo un jefe. Otra cosa es un historial de los distintos jefes que ha tenido un empleado. Pero ese historial también tiene que estar en el diseño. El punto que quiero destacar es que si no está modelado no podremos dar respuesta a ciertas preguntas.

Hasta aquí vemos con este ejemplo sencillo parte de lo que es el diseño del modelo de datos. No se pretende entrar en este tema más allá de dar una idea. Con estas pautas básicas se pretende mostrar parte del contexto previo al empezar a trabajar con el lenguaje SQL. Una vez se tiene el modelo E/ R el cual representa los datos y su relación . Y como se ha decidido utilizar una estructura basado en tablas para almacenarlos, se realiza el paso a tablas. Algunas de las reglas son: Cada entidad pasa a ser una tabla. Y el atributo clave pasa a ser el campo clave. Una relación 1-n genera un campo de clave foránea en la tabla del lado ene (n). Una relación n-n genera una tabla. Tendrá un campo de clave foránea por cada tabla que relaciona. Vamos paso a paso. En el ejemplo tenemos dos entidades: empleados y departamentos. Así que cada una de estas entidades será una tabla. Y los atributos de las entidades serán los campos de las tablas. Estos campos son las cabeceras de las columnas. La relación entre empleado y departamento es una relación 1-n. Esto lo sabemos porque son los valores máximos. No existe relación n-1. Solo hay 1-1, 1-n. Esto es así en la notación básica. Entonces, se genera en la tabla de empleados un campo: número de departamento. Este campo es clave foránea. Otro nombre que se utiliza es el de «clave ajena». O el inglés: foreign key. Lo que quiere decir es que este campo es clave en otra tabla. Y así lo es. El número de departamento es clave principal, o primary key, en la tabla de departamentos. La relación que indica que un empleado es jefe de otro empleado también es una relación 1-n. Por lo tanto , genera un campo que identifica al jefe del empleado. Algo a recordar es: «Una foreign key siempre hace referencia a una primary key.» Por lo general una clave principal va a ser un solo campo. Aunque podría ser dos o más campos. Pero nunca una tabla va a tener más de una primary key. ¿Podríamos tener tablas sin campos clave? Claro que sí. Un sistema gestor de base de datos lo permite. Lo que debemos recordar es para qué nos sirven. Y más adelante lo repetiré para incidir en esto.