Lección 3
Diseño Conceptual
___________________
Introducción
Como ya se ha visto en el tema anterior, el diseño conceptual, que constituye la primera etapa en el diseño de una base de datos, consiste en obtener una buena representación de los recursos de información de la empresa, con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador. Puesto que no se corresponde con ningún nivel de la arquitectura ANSI/X3/SPARC, sino que es un paso previo, tiende a ser no tenido en cuenta a la hora de proceder al diseño de una base de datos. Esto no es aconsejable, ya que el diseño lógico parte del esquema conceptual y, si éste no es correcto, o no representa fielmente la información del mundo real, el esquema de la base de datos no será estable, viéndonos obligados a reajustarlo constantemente debido a las deficiencias arrastradas desde esta etapa de diseño. De ahí la importancia de realizar un buen esquema conceptual, que represente fielmente las características del mundo real.
Otro error que se suele cometer en esta etapa de diseño es el de considerar aspectos tales como la eficiencia del equipo hardware en el que se vaya a montar la base de datos, o SGBD's concretos. Como ya se ha dicho, el esquema conceptual debe representar la información fuera de consideraciones sobre hardware y sobre el SGBD sobre el que se implementará. Por lo tanto, se pueden establecer las siguientes características que debe cumplir un buen esquema conceptual:
Debe representar fielmente la información del mundo real
• Es independiente del SGBD
Conviene no olvidar, por lo tanto, que un buen diseño del esquema conceptual, influirá positivamente
en el resto de etapas.
Etapas del diseño conceptual
La fase de diseño conceptual, puede subdividirse a su vez en dos etapas:
1. Etapa de análisis de requisitos: En esta etapa se debe responder a la pregunta
"¿Qué representar?". El objetivo es elaborar un esquema descriptivo de la realidad, en el que se provean detalles de los datos a representar. Dicho esquema se obtiene mediante el estudio u observación del mundo real (estudio de las reglas de la empresa, entrevista a los usuarios, etc.). Aunque existen muchas respuestas sobre el modo de recoger dicha información, la más utilizada es el lenguaje natural que, aunque carece del formalismo que pueden infligir otros métodos, permite una mejor y más fácil comprensión de la información por parte del usuario, y le permite especificar los requisitos sin la intervención de formalismos. Este primer esquema percibido bruto (como lo llaman Benci y Rolland), se ira refinando sucesivamente, hasta llegar al esquema conceptual.
2. Etapa de conceptualización: En esta etapa se debe responder a la pregunta
"¿Cómo representar?". En ella se transforma el esquema obtenido en la primera, mediante refinaciones sucesivas. Se deberá obtener el esquema conceptual mediante una representación normalizada, que se apoye en un modelo de datos que cumpla determinadas propiedades (según Piattini y De Miguel):
coherencia, plenitud, no redundancia, simplicidad, fidelidad, etc. El modelo que se
El modelo entidad / relación
El modelo E/R fue propuesto por Peter P. Chen en dos artículos que publicó en los años 1976 y 1977. En ellos define dicho modelo como una vista unificada de los datos, centrándose en la estructura lógica y abstracta de los datos, como representación del mundo real, con independencia de consideraciones de tipo físico. Posteriormente se fueron proponiendo nuevas aportaciones al modelo, lo cual explica que no exista uno sólo, sino distintos modelos según los autores.
Los objetivos que debe cumplir un esquema conceptual son los siguientes (Piattini y De Miguel):
1. Captar y almacenar el universo del discurso mediante una descripción rigurosa.
2. Aislar la representación de la información de los requisitos de máquina y exigencias de cada usuario en particular
3. Independizar la definición de la información de los SGBD en concreto.
A continuación se describirá el proceso de creación de un esquema conceptual, siguiendo el modelo E/R. Éste se basa en una representación gráfica de una serie de entidades relacionadas entre sí. Al utilizar una representación de este tipo, el modelo E/R permite distinguir fácilmente y a simple vista, las relaciones existentes entre las distintas entidades.
Existen muchas formas de representarlo, como ya se ha comentado; la que se utilizará aquí no es, por supuesto, la única forma de hacerlo. Los elementos de los que se componen son los siguientes:
1. Entidades: Una entidad es "una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para la empresa" (ANSI 1977). En el modelo E/R, se representa por un rectángulo, con el nombre de dicha entidad escrito en la parte superior. Por ejemplo, la Figura 8 representa la entidad automóvil.
Figura 8
2. Atributos: Un atributo es cualquier característica que describe a una entidad. Los atributos de una entidad se colocan dentro del rectángulo que representa dicha entidad, justo debajo del nombre de ésta. Por ejemplo, se puede decir que un automóvil tiene las siguientes características: nº de matricula, marca, modelo y color, lo cual se muestra en la Figura 9.
Figura 9
3. Clave: La clave de una entidad es un atributo o conjunto de atributos de dicha entidad, que son capaces de identificar unívocamente una ocurrencia de una entidad. Es decir, si conocemos el valor de dichos atributos, seremos capaces de conocer a que ocurrencia de entidad, entre todas las posibles, hace referencia. Esto implica que los valores de los atributos clave no se pueden repetir para dos ocurrencias de la misma entidad. En nuestro ejemplo, seremos capaces de identificar de que automóvil estamos hablando, con sólo conocer el valor del atributo matrícula, ya que no existe una misma matrícula para dos automóviles distintos. Los atributos marca, modelo o color no identifican unívocamente una ocurrencia de la entidad, ya que pueden existir dos automóviles distintos de la misma marca, modelo o color. En el modelo E/R, un atributo clave se representa subrayando dicho atributo.
Figura 10
4. Relación: Una relación representa, como su propio nombre indica, una correspondencia entre dos entidades. Si tenemos dos entidades automóvil y persona, podemos tener una relación entre ellas. Dicha relación se puede establecer en ambos sentidos:
e una persona posee un automóvil, y e Un automóvil pertenece a una persona.
5. Cardinalidad de una relación: La cardinalidad de una relación representa el número de ocurrencias que se pueden dar de una relación. Puede ser de tres tipos:
e Cardinalidad 1-1: cada ocurrencia de una entidad se relaciona con una ocurrencia de otra entidad. Ej.: una persona posee un automóvil. Se representa como indica la Figura
11.
Figura 11
e Cardinalidad 1-N: también llamada uno a muchos. Cada ocurrencia de una entidad puede relacionarse con varias ocurrencias de otra entidad. Ej.: una persona posee varios automóviles. Se representa como muestra la Figura 12.
Figura 12
e Cardinalidad N-M: también llamada muchos a muchos. Cada ocurrencia de una entidad puede relacionarse con varias ocurrencias de otra entidad y viceversa. Ej.: una persona posee varios automóviles y un automóvil puede pertenecer a varias personas.
Se representa como aparece en la Figura 13.
Figura 13
6. Cardinalidad máxima de una relación: representa el número máximo de ocurrencias de una entidad con las que se puede relacionarse otra entidad. Ej.: una persona puede tener como máximo tres automóviles.
7. Cardinalidad mínima de una relación: representa el número mínimo de ocurrencias de una entidad con las que se puede relacionarse otra entidad. Ej.: un automóvil debe pertenecer como mínimo a una persona.
8. Entidad débil: se dice que una entidad es débil, o es dependiente de otra, cuando no somos capaces de conocer a que ocurrencia de entidad nos estamos refiriendo, ni siquiera conociendo su clave, sino que debemos conocer el valor de algún otro atributo de otra entidad. Por ejemplo, si tenemos las entidades edificio (con el atributo clave codigo_edificio) y planta (con el atributo codigo_planta), ésta última es una entidad débil, ya que no somos capaces de identificar una planta con sólo conocer el código de la planta, sino que además se necesita conocer el código del edificio al que se hace referencia, para determinar la planta dentro del edificio.
Figura 14
En general, en una relación se suele representar conjuntamente las cardinalidades máxima y mínima. En los anteriores casos no se han considerado las cardinalidades mínimas. Éstas vienen a representar la opcionalidad de la ocurrencia de una entidad en una relación, es decir, si dicha ocurrencia se debe dar obligatoriamente, o si por el contrario se puede obviar.
Los tipos de cardinalidades son los que aparecen en la Figura 15, (nos fijaremos sólo en un sentido de la relación, el de la izquierda).
Veamos a continuación unos ejemplos para comprender mejor las cardinalidades máxima y mínima. Como se podrá comprobar, las cardinalidades de una relación se ponen en la última relación a la que se hace referencia, por ejemplo, si se tienen las entidades alumno y asignatura, la cardinalidad de la relación un alumno cursa asignaturas, se pondrá al lado de la entidad asignatura.
En el siguiente ejemplo(Figura 16), se tiene una relación 1-1 en la que un automóvil pertenece a una única persona (cardinalidad máxima 1), sin la posibilidad de que exista un automóvil que no tenga dueño (cardinalidad mínima 1). Esto significa que en el modelo no interesa tener información de aquellas personas que no tengan automóvil.
Figura 16
En la Figura 17, se tiene una relación 1-1 en la que una persona puede tener un automóvil como mucho (cardinalidad máxima 1), o puede no tener ninguno (cardinalidad mínima 0). Esto significa que el modelo interesa tener información de todas las personas, aunque no tengan automóvil.
Figura 17
En el siguiente ejemplo (Figura 18), se tiene una relación 1-N, en la que un profesor puede dar clase a muchos alumnos (cardinalidad máxima N), pero como mínimo debe hacerlo a uno (cardinalidad mínima 1). Esto significa que en el modelo no interesa tener información de aquellos profesores que no dan clase.
Figura 18
En el siguiente ejemplo, se tiene una relación N-N, en la que una persona puede tener varios automóviles (cardinalidad máxima N), pero puede que no tenga ninguno (cardinalidad mínima 0). Esto significa que en el modelo interesa tener información de todas las personas, aunque no tengan automóvil.
Figura 19
Para concluir esta sección se verá un ejemplo completo que representará todos los conceptos vistos hasta ahora. Supongamos que se desea establecer un modelo conceptual para la gestión de una biblioteca. Se desean tener almacenados todos los libros que la componen.
Para cada libro interesa conocer el ISBN, el título, el autor o autores, la editorial, el año de publicación y la materia. De cada autor se quiere conocer su nombre, apellidos y nacionalidad.
Un autor podrá haber escrito varios libros, de la misma forma que en un libro pueden participar varios autores. De la editorial se desea conocer el nombre y la ciudad.
A dicha biblioteca podrán estar suscritos varios usuarios. De ellos se quiere saber su DNI, número de socio, nombre, apellidos, dirección y teléfono. Por cuestiones directivas, se limita el número de ejemplares prestados a cada usuario a uno.
Se dispone, a su vez, de un único ejemplar de cada libro, por lo que un libro prestado a un usuario, no podrá ser prestado a otro hasta que se devuelva. Deberá quedar constancia de la fecha de préstamo de cada ejemplar.
Figura 20
Lo más destacable del anterior ejemplo es la entidad préstamo. Es una entidad débil que depende de libro y de socio, ya que para diferenciar un préstamo de otro, se necesita saber no sólo el libro, sino el socio al cual se ha prestado. También se pueden observar que las cardinalidades mínimas son 1. Esto quiere decir que sólo se guardará información de las entidades cuando exista, al menos, una ocurrencia de la entidad. Las únicas relaciones que tienen cardinalidad opcional, son las que tienen como origen o destino a la entidad préstamo, lo cual es lógico, ya que tendremos información de todas las entidades, aunque todavía no se haya realizado ningún préstamo.
Ejemplos prácticos de diseño conceptual
A continuación resolveremos unos problemas de diseño conceptual, para ir familiarizando al lector con los conceptos vistos hasta ahora. Para realizarlos se utilizará la S- Designor, que es una herramienta CASE que abarca gran parte del ciclo de vida de las aplicaciones, incluyendo el diseño de esquemas conceptuales. No se preocupe si no conoce la herramienta, ya que se verá en detalle en próximos temas, simplemente quédese con la idea general de la construcción del esquema.
El problema que nos planteamos es el siguiente. Supóngase que se desea informatizar una tienda de discos. Para ello se desean tener almacenados los nombres de todos los discos disponibles, además de sus cantantes y canciones. Así mismo se desean almacenar los clientes que han comprado en dicha tienda. Pues bien, empezaremos identificando las entidades, entendiendo por entidad un grupo de características que tienen entidad propia.
Como primera entidad, podemos establecer los discos que se venden, ya que se desea conocer información de ellos, como puede ser un código que lo identifique dentro de la estantería.
Por otro lado se desea almacenar todos los artistas que intervienen en los discos de nuestra tienda, y para cada uno de ellos se desea conocer su nombre y apellidos, por lo tanto ya tenemos identificada una segunda entidad. Además, se desea conocer todas las canciones que están disponibles en los discos, identificada cada una de ellas por un código de canción, y que además tendrán sus propias letras. Pues ya tenemos la tercera entidad. La cuarta estará formada por los clientes, de los cuales se desea almacenar su nombre, apellidos, dirección y teléfono, y que podrán estar identificados internamente por un código de cliente.
Figura 21
Una vez establecidas las entidades, sólo nos queda relacionarlas. Podemos observar las siguientes relaciones:
1. Entre disco y canción: en un disco pueden aparecer varias canciones, y cada canción puede estar en varios discos (N-M).
2. Entre cantante y canción: un cantante puede componer varias canciones, y una canción puede estar compuesta por varios cantantes (N-M).
3. Entre cliente y disco: un cliente puede comprar varios discos, pero un disco sólo puede ser comprado por un cliente 1-N.
Por lo tanto, el esquema conceptual es que muestra la Figura 22
Figura 22
Vamos a plantearnos otro problema. Supongamos que se desea tener almacenados todos los datos de los profesores de una empresa dedicada a impartir cursos, así como una breve descripción de éstos, y los alumnos a los cuales se les ha impartido. Empezamos identificando entidades.
De un profesor se desea conocer su nombre y apellidos, dirección y despacho, por lo tanto establece una entidad. Otra entidad podría ser el alumno, del cual se desea conocer su nombre, apellidos, dirección y teléfono.
Ni que decir tiene que el curso describe otra entidad, de la cual se desea conocer su descripción. Sin embargo, podemos recurrir a un procedimiento muy usual, denominado tipificación de estados, muy usado en el diseño conceptual, y que consiste en tener una entidad que tipifique los posibles estados que puede tomar un atributo.
La principal ventaja de este procedimiento radica en que muchas veces supone un ahorro de espacio de almacenamiento (por ejemplo al identificar nombres de ciudades largas con un solo número) además de una estandarización de los datos almacenados (el estado sólo se almacena una vez).
Por ejemplo podemos tipificar las ciudades, para lo cual creamos una nueva entidad ciudad,
donde se almacenará un código y la descripción de la ciudad. Cuando almacenemos la ciudad de un alumno, sólo deberemos especificar el código de la ciudad.
Figura 23
Una vez establecidas las entidades, vamos a definir las relaciones entre ellas.
1. Profesor y Curso: un profesor puede impartir varios cursos, pero un curso sólo puede ser impartido por un profesor (1-N).
2. Alumno y Curso: un alumno puede asistir a varios cursos, y a un curso pueden asistir varios alumnos (N-M).
3. Alumno y Ciudad: un alumno vive en una ciudad, y una ciudad puede tener varios alumnos (1-N).
Por lo tanto, el esquema conceptual es el mostrado en la Figura 24.
Figura 24
Vamos a ver un último ejemplo. Supóngase un banco que desea almacenar todos sus clientes, además de los productos que puede ofrecer a éstos. Cada cliente podrá escoger entre todos estos productos el o los que más le plazcan (créditos, fondos de inversión, libretas de ahorro, etc.).
De la misma forma, dicho banco tiene intereses en otras empresas, por lo que desea conocer en todo momento la situación de dichas empresas, para poder mejorar su política de inversiones.
Puesto que dicho banco esta constituido como sociedad anónima, desea almacenar todos los componentes de su consejo de administración (actuales y ex-miembros) así como todas las actas de las reuniones ordinarias y extraordinarias.
Las decisiones de inversión en estas empresas saldrán como resultado de dichas reuniones, así como la oferta de nuevos productos.
Como habrá podido observar, este ejemplo es un poco más complejo, pero no desespere, el proceso es similar al de los demás ejemplos. Empezaremos definiendo entidades y las veremos representadas en la Figura 25.
1. Cliente: se desea conocer su nombre, apellidos, dirección y NIF, y estará identificado por un código interno cod_cliente.
2. Producto: del cual queremos saber su descripción y estará identificado por un código interno cod_producto.
3. Empresa: identifica las empresas en las cuales el banco ha invertido. De ellas se desea conocer su código, nombre y CIF.
4. Consejo: establece los componentes del consejo de administración. Para ello se almacenará el nombre, apellidos y código de cargo de cada uno de sus componentes, y si el cargo es vigente o no. Podremos utilizar una nueva entidad que tipifique los tipos de cargo.
5. Tipo_cargo: describe los posibles cargos que puede tomar una persona en el consejo de administración, y esta compuesto por un código de tipo de cargo, y una descripción del mismo (secretario, presidente, etc.).
6. Reunión: entidad encargada de describir la información de las actas de las reuniones. Sus atributos son cod_reunión, fecha, extraordinaria, que especifica si la reunión ha sido ordinaria o extraordinaria y una descripción.
Figura 25
Identifiquemos ahora las relaciones. Su representación gráfica aparece en la Figura 23.
1. Cliente y producto: cada cliente puede escoger varios productos, y cada producto puede ser ofrecido a varios clientes.
2. Consejo y cargo: un miembro del consejo sólo tiene un cargo, y cada cargo puede pertenecer a más de un miembro.
3. Reunión y consejo: a cada reunión pueden asistir varios miembros del consejo de administración, y cada miembro puede asistir a más de una reunión.
4. Reunión y producto: de cada reunión puede salir la oferta de mas de un nuevo producto pero cada producto nuevo sólo puede salir de una reunión.
5. Reunión y empresa: de cada reunión pueden salir decisiones de invertir en más de una empresa, y cada decisión de inversión sólo sale de una reunión.
