| Artículos | 01 JUL 1998

Diseño de bases de datos

Tags: Histórico
Javier Nieto.

El diseño de bases de datos es, en la mayoría de los casos, un aspecto fundamental, al que se da menos importancia de la que realmente tiene . Antes de comenzar a realizar un desarrollo de bases de datos es fundamental apoyarse en un diseño de datos apropiado .

Hoy en día, las bases de datos constituyen una de las aplicaciones más utilizadas en todos los entornos informáticos . Desde los sistemas de grandes corporaciones hasta el ordenador personal, pasando por el entorno ofimático, las bases de datos se han consolidado como las herramientas más útiles para el tratamiento masivo de información .

La aparición de programas como Access, FileMaker y otros han facilitado la utilización y mantenimiento de bases de datos a todo tipo de usuarios, no siendo necesaria la presencia de un administrador experto en estos sistemas . De este modo, los usuarios van creando sus tablas de datos a medida que surge la necesidad de utilizarlos y, con el tiempo se convierten en verdaderos expertos en el manejo del programa que tienen instalado . Cuando los datos manejados son sencillos, basta la intuición a la hora de definir las tablas a utilizar, pero cuando la estructura de datos se complica surgen numerosas dudas a la hora de elegir el diseño a emplear . ¿ Qué tablas se deben crear para gestionar, por ejemplo, una biblioteca ? , ¿ y para gestionar una editorial con sus redactores, artículos y revistas ? . Existen varias alternativas y, probablemente, la mayoría funcionen pero, ¿ cuál es la más idónea ? , ¿ hay algún modo de discernir cual de entre todas las opciones es mejor ? . La respuesta es SÍ .

Un conocimiento profundo del programa de base de datos que se maneje no implica, desgraciadamente, lo mismo respecto del diseño de datos que se utilice . De hecho, el diseño de datos es independiente de cualquier base de datos sobre la que se implemente y sigue una normas perfectamente definidas sobre cuántas tablas se deben crear y qué tipo de relaciones se deben establecer entre ellas para solucionar cualquier tipo de situación . Este artículo trata sobre cómo realizar diseños de datos óptimos e independientes del programa, que luego puedan implementarse en cualquier base de datos, sea Access, FileMaker, dBASE o incluso servidores como SQL Server, DB2, SQLBase, etc .

Cuando un usuario utiliza una base de datos para gestionar cualquier tipo de información, está plasmando una parte del mundo real en una serie de tablas y campos, creando un modelo parcial de la realidad . La fase previa a la creación física de las tablas es el diseño de un modelo de datos, aunque, equivocadamente, la mayoría de las veces estos dos pasos se mezclan, de modo que los usuarios van creando tablas a medida que surgen nuevas necesidades . El resultado final suele ser un pequeño caos en el que los datos están dispersos o no cumplen con los requisitos que necesitamos . Hay que tener presente que en el diseño del modelo de datos es donde residen, realmente, las propiedades y características de la base de datos que se desea crear y un mal modelo conduce, inequívocamente, a una mala base de datos .

Entidades y relaciones

Los modelos de datos que se describen en este artículo se denominan Modelos Entidad/Relación y son los idóneos para trabajar con bases de datos relacionales, que actualmente son la mayoría, como Access, FileMaker, FoxPro, Dbase, Paradox, SQL Server, DB2, Informix, Oracle, etcétera . En los modelos E/R se parte de la situación real que se desea gestionar y se definen, sobre ésta, entidades y relaciones entre entidades . Una entidad es un objeto real sobre el que se desea recoger información, por ejemplo una persona, una empresa o, en general, cualquier objeto con relevancia en el modelo . Las entidades están compuestas de atributos que son los datos que definen el objeto, como puedan ser el nombre, NIF, dirección, teléfono, etcétera, en una persona, o el CIF, nombre, actividad, etcétera en una empresa . Entre los atributos de una entidad existe uno ( o un grupo ) que identifica plenamente una ocurrencia de entidad de entre un conjunto de ellas . Por ejemplo, el NIF de una persona, que permite diferenciar a cada una de ellas del resto; pero no su dirección, dado que pueden existir varias personas en un mismo domicilio . A ese atributo, o conjunto de atributos se le denomina clave de la entidad . Puede darse el caso de que existan varias alternativas a la hora de escoger una clave, como en el caso de las personas, en las que el nombre completo también puede identificarlas plenamente . Señalar que en toda entidad siempre existe una clave que será, en el peor de los casos, la formada por todos los atributos que la constituyen .

De entre todas las posibles claves se escogerá como principal aquella que mejor cumpla con los tres requisitos siguientes . En primer lugar, que sea única, es decir, que para todos los posibles valores que pueda tomar en las distintas ocurrencias de entidad, nunca existan dos iguales ( recuérdese el ejemplo anterior con NIF y dirección ) . En segundo lugar, que se tenga pleno conocimiento de ella, pues no puede darse el caso de que tomemos como clave principal, por ejemplo, el NIF y a la hora de trabajar descubramos que no tenemos ese dato para algunas personas . Y, en tercer lugar, que sea mínima, es decir, lo más simple posible dado que la clave es un atributo que el gestor de base de datos usa con frecuencia para crear índices, definir relaciones, comprobar integridades, etcétera, e interesa que sea lo más sencilla de manejar para el sistema .

Las relaciones son asociaciones entre entidades, propias del modelo y sin existencia propia, como, por ejemplo, el hecho de que una persona trabaje en una empresa . La clave de una relación se define mediante las claves de las entidades que relaciona, en el ejemplo propuesto, la clave de la relación Trabajo será el NIF de la persona y el CIF de la empresa . La cardinalidad de la relación es el número potencial de entidades que relaciona pudiendo ser, básicamente, de tres tipos

1 ) Relación 1-1, que implicaría que en cada empresa sólo puede trabajar una persona, y que una persona sólo puede trabajar en una empresa .

2 ) Relación 1-n, dependiendo de a qué entidad se asocie el 1 o la n, implicaría que una persona sólo puede trabajar en una empresa, pero en una empresa pueden trabajar n personas,

3 ) Relación n-n, que indica que en una empresa pueden trabajar varias personas y que una persona puede trabajar en varias empresas .

Por otro lado, las relaciones pueden tener atributos propios, como puedan ser, el sueldo de la persona en la empresa, la fecha de alta, etcétera . A las relaciones con atributos propios se las denomina entidades asociativas . Los modelos se pueden plasmar sobre papel mediante gráficos denominados diagramas E/R, en los que las entidades se representan mediante un rectángulo con el nombre de la entidad dentro, las relaciones mediante un rombo, unido por líneas a las entidades que relaciona indicando en cada caso la cardinalidad de la relación, y las entidades asociativas mediante un rectángulo con un rombo inscrito y unido, al igual que las relaciones, con las entidades asociadas .

Una vez construido el modelo, queda el paso final, que es la creación de las tablas . Cada entidad se refleja mediante una tabla en la que los campos son los distintos atributos que tiene, definiendo como clave de la tabla la de la entidad . Las relaciones se pueden plasmar según diferentes métodos dependiendo de la cardinalidad que tengan y pueden afectar a las entidades ya definidas . Los criterios de creación de las tablas según el tipo de relación son los siguientes .

Relaciones 1-1 . Al tratarse de una relación directa 1-1, se crea una tabla con todos los campos correspondientes a

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información