| Diseño de Base de datos
A partir del Diagrama Entidad-Relación |
El modelo Entidad-Relación
Introducción al diseño de bases de datos
Es sencillo diseñar una base de
datos, pero a menudo hay que reconsiderar posteriormente la estructura de los
datos, lo cual ocasiona retrasos y modificaciones. Es más lento la obtención de
un diseño lo más óptimo posible, pero el tiempo invertido se recupera al no
tener que volver atrás para replantearse el diseño de los datos. Un buen diseño
es la clave para iniciar con buen pie el desarrollo de una aplicación basada en
una base de datos o la implementación de un sistema.
Es de destacar la importancia de un buen diseño. Un diseño apresurado o
simplemente bosquejado puede mostrarse inservible o muy mejorable cuando la
aplicación ya está parcialmente codificado, o el administrador de la base de
datos ya tiene organizados el mantenimiento y el control de acceso a los datos.
Esquema: diseño general de la base de datos a nivel lógico. Incluye el
tipo de datos y las relaciones entre ellos. Es de naturaleza fija y solo se
altera excepcionalmente. El esquema se define y se mantiene utilizando el
lenguaje de definición de datos (DDL).
Instancia: contenido concreto de la base de datos en un momento dado.
Varía con el tiempo, al añadir, eliminar o modificar datos, utilizando el
lenguaje de modificación de datos (DML).
El diseño de una base de datos se realiza a dos niveles. El primero es el
nivel conceptual, en la cual se contempla una estructura abstracta y no
implementable directamente con un SGBD. El segundo es el nivel físico, en
el cual la base de datos es ya implementable. Detalladamente, las fases del
diseño de una base de datos son las siguientes:
- Descripción en lenguaje natural.
- Diagrama Entidad-Relación (E-R). También conocido como "diagrama de
Chen". Estos diagramas modelizan el problema mediante entidades asociadas por
relaciones. Adoptan la forma de grafos donde los datos se relacionan mediante
flechas. El diagrama E-R no depende del modelo de datos.
- Elección del modelo de datos (usualmente el relacional)
- Conversión del diagrama E-R al modelo relacional (tablas)
- Normalización (eliminar diversos defectos de diseño).
- Optimización (según criterios de almacenamiento interno, como el
espacio en disco y el tiempo medio de acceso).
Las tres primeras fases pertenecen al nivel conceptual del diseño de bases de
datos mientras que las tres últimas se relacionan con el nivel físico.
Introducción a los modelos de datos
Modelo de datos: estructura
general de los datos y técnicas de acceso proporcionadas por un SGBD. Un SGBD
usa siempre un único modelo de datos. Hay tres modelos de datos posibles:
- Relacional. Es el más empleado. Todos los datos visibles al usuario
están organizados estrictamente como tablas de valores. Todas las operaciones
sobre la base de datos operan sobre esas tablas. Cada fila de una tabla es una
instancia de los datos. Cada columna de una tabla es un atributo (valor
indivisible que tiene significado por sí solo). Es el modelo de datos más
sencillo y cercano a la forma humana de organizar la información.
- Red. También denominado modelo CODASYL. Fue el primero en aparecer
comercialmente, a principios de los años 70. Se caracteriza por almacenar
direcciones de otros datos junto a la misma información. Es un modelo cercano
al modo de almacenamiento interno del ordenador. Los datos se expresan como
registros y las relaciones entre datos como sets. Dos datos están
unidos por una dirección de memoria almacenada al lado de uno de ellos. Esa
dirección es la del otro dato. Las direcciones son propias del ordenador, y no
tienen sentido lógico para las personas. El tipo de registro es e equivalente
a una tabla en el modelo relacional, y se implementa físicamente mediante un
fichero.
- Jerárquico. Es muy similar al modelo de datos en red, pero con la
salvedad de que los registros se organizan con estructura de árbol.
El modelo Entidad-Relación (E-R)
Propuesto por Chen a mediados de los
años setenta como medio de representación conceptual de los problemas y para
representar la visión de un sistema de forma global. Físicamente adopta la forma
de un grafo escrito en papel al que se denomina diagrama
Entidad-Relación. Sus elementos fundamentales son las entidades y las
relaciones.
Una entidad caracteriza a un tipo de objeto, real o abstracto, del
problema a modelizar. Toda entidad tiene existencia propia, es distinguible del
resto de las entidades, tiene nombre y posee atributos definidos en un
dominio determinado. Una entidad es todo aquello de lo que se desea almacenar
información. En el diagrama E-R las entidades se representan mediante
rectángulos.
Una relación es una asociación o relación matemática entre varias
entidades. Las relaciones también se nombran. Se representan en el diagrama E-R
mediante flechas y rombos. Cada entidad interviene en una relación con una
determinada cardinalidad. La cardinalidad (número de instancias o
elementos de una entidad que pueden asociarse a un elemento de la otra entidad
relacionada) se representa mediante una pareja de datos, en minúsculas, de la
forma (cardinalidad mínima, cardinalidad máxima), asociada a cada uno de
las entidades que intervienen en la relación. Son posibles las siguientes
cardinalidades: (0,1), (1,1), (0,n), (1,n), (m,n). Tambié se informa de
las cardinalidades máximas con las que intervienen las entidades en la relación.
El tipo de relación se define tomando los máximos de las
cardinalidades que intervienen en la relación. Hay cuatro tipos posibles:
- Una a una (1:1). En este tipo de relación, una vez fijado un elemento de
una entidad se conoce la otra. Ejemplo: nación y capital.
- Una a muchas (1:N). Ejemplo: cliente y pedidos.
- Muchas a una (N:1). Simetría respecto al tipo anterior según el punto de
visto de una u otra entidad.
- Muchas a muchas (N:N). Ejemplo: personas y viviendas.
Toda entidad debe ser unívocamente identificada y distinguible mediante un
conjunto de atributos (quizás un solo atributo) denominado identificador
o clave principal o primaria. Puede haber varios posibles identificadores
para una misma entidad, en cuyo caso se ha de escoger uno de ellos como
identificador principal siendo el resto identificadores alternativos. Ejemplo:
dni y número de seguridad social de una persona.
Hay unas normas de sentido común a seguir cuando se dibuja un diagrama E-R.
La primera es emplear preferentemente líneas rectas en las relaciones y evitar
en lo posible que estas líneas se crucen. Se suele usar nombres para describir
las entidades y verbos para las relaciones. Esto es lógico ya que las entidades
se ponen en común cuando se realiza alguna acción. Los verbos empleados no
necesariamente tienen que ser siempre infinitivos.
Ejemplo: Se desea almacenar información sobre personas y los coches que
eventualmente posean. Una misma persona puede poseer varios coches aunque puede
haber personas que no posean ningún coche. Los coches se identifican mediante su
número de matrícula y las personas mediante su documento nacional de identidad.
Todo coche tiene un solo propietario. Se ha de almacener la fecha en que una
determinada persona adquirió un determinado coche.
Problemas de un esquema único que agrupe a todos los atributos de la entidad
coche (matrícula, marca, modelo, etc.), de la entidad persona (dni, nombre,
direccion, etc) y de la relación entre ambas entidades (fecha de compra).
- Personas sin coche (valores nulos y gasto de espacio de almacenamiento).
- Multiplicidad de almacenamiento (redundancia) de los atributos de una
persona si ésta es propietaria de más de un coche.
- Modificación del valor de un atributo de una persona en una sola de sus
apariciones en la instancia de la base de datos (inconsistencia).
Para
evitar estos problemas se separa el esquema único de la base de datos en tres
separados para coche, persona y la relación entre ambos, lo que ocasiona otra
serie de problemas:
- Toda matrícula en una instancia concreta del esquema de la relación entre
coches y personas debe aparecer en la instancia del esquema de la entidad
coche.
- Todo dni en una instancia concreta del esquema de la relación entre coches
y personas debe aparecer en la instancia del esquema de la entidad persona.
- Problemas con la modificación del valor de una matrícula en la instancia
del esquema de la entidad coche.
- Problemas con la modificación del valor de un dni en la instancia del
esquema de la entidad persona.
- Problemas con el borrado de varios coches en la instancia concreta del
esquema de la entidad coche.
- Problemas con el borrado de varias personas en la instancia concreta del
esquema de la entidad persona.
Una entidad del modelo E-R puede ser fuerte o débil. Una entidad
fuerte existe por sí misma sin depender la existencia de alguna otra
entidad. Por el contrario la existencia de una instancia de una entidad
débil depende de la existencia previa de otra entidad. Si la entidad
débil puede ser identificada sin necesidad de identificar previamente la entidad
de cuya existencia depende, diremos que la entidad débil lo es por
existencia únicamente. Si la entidad débil no puede ser identificada
independientemente, sino que previamente es necesario identificar a la entidad
de cuya existencia depende, diremos que la entidad débil lo es por
identificación.
Por extensión se considera que una relación en la hay entidades débiles
también se dice débil por existencia o por identificación según sea el tipo de
debilidad de las entidades que intervengan en la relación. Ejemplos:
- Se desea almacenar información sobre buques petroleros y las refinerías
donde éstos realizan operaciones de descarga de crudo. Un buque puede
descargar combustible en cierta cantidad y en una determinada fecha en una de
varias refinerías. En una misma refinería pueden descargar varios buques. Los
buques se identifican mediante una matrícula naval y las refinerías mediante
un código.
- Se desea almacenar información sobre empresas y sucursales de empresas.
Una empresa puede tener varias sucursales repartidas geográficamente. Una
sucursal determinada debe pertenecer a una y solo una empresa. Las sucursales
se numeran correlativamente para cada empresa.
- Se desea almacenar información sobre personas y sus viviendas en
propiedad. Supondremos que una vivienda tan solo puede pertenecer a una
persona y que no toda persona debe ser obligatoriamente propietaria de al
menos una vivienda.
Idea para el reconocimiento de entidades débiles: Pensar qué
sucede cuando se borra una instancia concreta de la entidad fuerte.
Ejemplo: se desea diseñar una pequen˜a base de datos para almacenar
información relativa a los estudios universitarios de un colectivo de alumnos
pertenecientes a una misma facultad. Un alumno puede cursar a la vez varias
asignaturas pertenecientes a cursos distintos. Cada curso se compone de una
serie de asignaturas que se imparten en aulas. Las asignaturas se agrupan en
áreas de conocimiento y los profesores que las imparten se agrupan en
departamentos que supondremos no guardan relación con las áreas de conocimiento.
No hay asignaturas sin alumnos. Todo profesor debe estar adscrito a un único
departamento. Una asignatura puede ser impartida por varios profesores siempre
que éstos pertenezcan al mismo departamento. Puede haber profesores que no
impartan docencia.
Observar que la restricción de que una asignatura no pueda ser enseñada por
profesores de departamentos distintos no es expresable en el diagrama E-R. En la
realidad deberá ser indicada utilizando el DDL cuando se cree la base de datos.
El aspecto básico para elaborar un diagrama E-R es la determinación de
entidades para lo cual se extraen de la descripción verbal del sistema los
nombres comunes y entre ellos se escogen los que claramente aporten información
valiosa. Con el resto de nombres se utiliza el sentido común descartando los
inútiles. En caso de duda, es mejor incluir una entidad que posteriormente se
revele como innecesaria que perder información relevante al problema.
Un atributo que lógicamente pueda estar en varias entidades se ubicará
finalmente en la entidad en la que sea más fijo, es decir, en la que esté más
ligado al resto de atributos de esa entidad. Por sentido común pueden añadirse
atributos que no aparezcan citados expresamente en la descripción verbal del
problema.
Muchas veces es posible simplificar el diagrama E-R eliminando entidades
innecesarias. Por ejemplo, si una entidad que interviene únicamente en una
relación del tipo una a una (1:1) no tiene como atributo más que su código, este
atributo puede incluirse en la entidad con la que está relacionada elimianar
tanto la relación como la entidad.
Tipos especiales de relación
- Relación reflexiva o recursiva. Relaciona una entidad
consigo misma. Ejemplo: empleados que pueden ser jefes de otros empleados.
- Dos relaciones entre las mismas dos entidades. Muy útil en el caso
de necesitar almacenar información histórica completa. Ejemplo: proyectos en
los que trabaja actualmente un empleado y proyectos en los que ha trabajado
anteriormente.
- Relación ternaria. Asociación de tres entidades. La forma de hallar
cardinalidades en las relaciones ternarias es fijar una combinación de
elementos en dos de los extremos de la relación y obtener lógicamente las
cardinalidades mínima y máxima en el otro extremo libre. Ejemplo: el título de
un libro, un autor y una editorial se relacionan las tres mediante la acción
de publicar el libro (en un año concreto, con un ISBN y con un determinado
número de páginas en la edición). Para determinar las cardinalidades hay que
preguntarse por:
- Cuántos autores puede tener un determinado libro publicado en una
determinada editorial(cardinalidd en el extremo de la entidad autor).
- Cuántos libros puede tener un determinado autor publicados en una
determinada editorial (cardinalidad en el extremo de la entidad libro).
- En cuántas editoriales puede un determinado autor publicar un mismo
libro (cardinalidad en el extremo de la entidad editorial).
- Relación de especialización (ES-UN). Tipificación de una entidad en
en subtipos en número finito y conocido. Cada subtipo puede poseer atributos
propios que. Los subtipos heredan los atributos que pudiera tener la entidad
general. Este tipo de relación puede clasificarse de dos maneras distintas. La
primera se según si una instancia o elemento concreto de la entidad puede ser
de más de un subtipo a la vez. En caso afirmativo se dice que la relación es
inclusiva o con solapamiento mientras que en caso contrario será
exclusiva o sin solapamiento. La segunda clasificación se basa
en si obligatoriamente cada instancia o elemento concreto debe ser
obligatoriamente de alguno de los subtipos especificados, es decir, si no
pueden existir elementos de la entidad que no pertenezcan a ninguno de los
subtipos. Si es así la relación se dice total y en caso contario
parcial. La situación más corriente en una relación de especialización
es que sea exclusiva y total. Ejemplos:
- Una entidad persona tiene los subtipos hombre y mujer. Una misma persona
no puede ser hombre y mujer a la vez por lo que la relación es exclusiva. No
puede existir una persona que no sea hombre ni mujer, por lo que también es
total.
- Se conviene en que un vehículo puede ser un coche, un camión o una moto.
La relación es claramente exclusiva (un vehículo no puede ser coche y camión
a la vez, ni camión y moto, etc) y parcial pues puede haber vehículos que no
sean ni coche ni camión ni moto.
- La entidad que representa a un universitario tiene los subtipos profesor
y estudiante. Un mismo universitario puede ser ambas cosas a la vez (p.e. un
profesor puede estar matriculado como alumno en alguna facultad) por lo que
la relación es inclusiva. No puede existir un universitario que no sea ni
profesor ni estudiante, por lo que también es total.
- Expresamos mediante una relación de especialización el que una función
matemática tiene asociados los subtipos continua y derivable. La relación es
inclusiva pues una misma función puede ser ambas cosas a la vez, y parcial
porque existen funciones que no son continuas ni derivables.
Supongamos una entidad A que se especializa en dos subtipos
A1 y A2. La identificación del tipo de relación (exclusiva, total, etc) puede
hacerse atendiendo a la siguiente tabla de verdad:
| A1 |
A2 |
Caso posible? |
| No |
No |
Sí -> Parcial No -> Total |
| No |
Sí |
Sí |
| Sí |
No |
Sí |
| Sí |
Sí |
Sí -> Inclusiva No ->
Exclusiva |
La cardinalidad en las relaciones de especialización es siempre (1,1) en el
extremo de la entidad que se especializa en subtipos y (0,1) en el extremo de
los subtipos si la relación es exclusiva o ({0,1},1) si es inclusiva.
Una relación de especialización parcial puede fácilmente convertirse en
total añadiendo un nuevo subtipo "otros".
Ejemplo: Una empresa desea almacenar información sobre sus clientes y
los pedidos que éstos realizan. Un pedido consta de un número variable de
artículos deseados en una determinada cantidad. La empresa guarda un determinado
número de unidades de cada artículo en su almacén. Puede ser que la cantidad
realmente servida de un artículo en un pedido sea inferior a la cantidad pedida
si no hay suficiente stock. Los pedidos pueden ser urgentes, en cuyo caso
se especifica además un número máximo de días que el cliente está dispuesto a
esperar el servicio del pedido.
| Bases de Datos - Vladimir Ventura Ventura
|