Lecturas: Educación Física y Deportes, Revista Digital


Organizando datos deportivos con bases de datos
Departamento de Informática. Universidad de Extremadura. Facultad de Ciencias del Deporte Los autores trabajan en la docencia de Bases de Datos para la carrera de Ingeniería Informática. En la actualidad se encuentran impartiendo su docencia en la Facultad de Ciencias de la Actividad Física y el Deporte de la Universidad de Extremadura, en asignaturas de Informática.	Mercedes Macías García mmaciasg@unex.es Miguel Ángel Pérez Toledano toledano@unex.es
Resumen Las Bases de Datos constituyen una poderosa herramienta para la organización de datos deportivos, así como una importante ayuda en el proceso de los mismos o en la elaboración de informes automatizados con la información obtenida a partir de ellos. En el mercado existen numerosas empresas de software que han puesto en circulación distintas modalidades de Bases de Datos. La gama es muy amplia, mientras unas ofrecen más prestaciones, otras proporcionan una mayor potencia en los tratamientos, o mayor fiabilidad en los mecanismos de seguridad o una mejora en los requerimientos de memoria. Hoy en día, casi todos los paquetes de ofimática incluyen una herramienta de Base de Datos. A menudo, por lo atractivo de la herramienta informática, se acomete la empresa de creación de una base de datos sin ninguna previsión anterior, sin siquiera un esbozo de lo que se desea obtener después y esto hace que los resultados en la mayor parte de los casos sean decepcionantes. En la primera parte de este artículo, se hará hincapié en la importancia que tiene un buen diseño previo que recoja fielmente todas las necesidades de cálculo o de extracción de información que desea obtener el usuario. Y en la segunda parte se indicará una de las posibles formas de llevar a la práctica el diseño anterior. Palabras clave: Diseño de Bases de Datos. Base de Datos. Informes. Consultas.
http://www.efdeportes.com/ Revista Digital - Buenos Aires - Año 6 - N° 29 - Enero de 2001

1 / 4

1. Introducción
    Existe un gran número de libros en el mercado sobre Bases de Datos. En unos casos estos libros están orientados a los profesionales de la Informática que se dedican a gestionar y administrar Bases de Datos de gran volumen. Las técnicas de diseño que se exponen en este tipo de libros son excesivamente complejas y especializadas especialmente para aquellos usuarios que únicamente pretenden hacerse una base de datos simple que les solucione un problema sencillo o no muy complejo. En otros casos, los libros exponen todos los trucos y entresijos de una marca de Base de Datos concreta, pero no suelen hablar de para qué hacer la Base de Datos y de su utilidad. Se limitan a exponer en sus páginas una enorme cantidad de información técnica sobre posibilidades que éstas tienen y en muy pocas ocasiones se siguen casos prácticos de principio a fin, de modo que los lectores comprendan perfectamente qué pueden esperar de tales herramientas.
     Los autores de este trabajo imparten docencia de Informática en la Facultad de Ciencias de la Actividad Física y el Deporte. A lo largo del tiempo dedicado a ello, han ido elaborando una gran cantidad de casos prácticos que han servido de ejemplo a los alumnos de distintas asignaturas relacionadas con la informática aplicada a la organización de datos deportivos. En este trabajo se expondrá un caso práctico que ilustrará algunas de las posibilidades que ofrecen las Bases de Datos en la organización y catalogación de datos de tipo deportivo de forma simple.

2. Creación de una base de datos
     Una Base de Datos es una herramienta software creada con el fin de facilitar al usuario la tarea de organizar adecuadamente datos de cualquier tipo. El principal objetivo de tener datos bien organizados consiste en la posibilidad de extraer conclusiones, realizar consultas y confeccionar informes a partir de ellos de forma automatizada. En definitiva, las Bases de Datos son herramientas que permiten obtener información de interés, a partir de un conjunto de datos de entrada.
     A lo largo de este artículo se seguirá el proceso de creación de una Base de Datos deportiva y para ello, consideraremos dos grandes fases:

Fase de Diseño: Durante esta etapa de la creación de una base de datos, se decide qué datos son interesantes en función de los resultados que se pretende obtener. Es decir, se dice qué datos hacen falta para obtener qué información. Una vez tomada esta decisión, se organizan los datos y para ello se construye un modelo teórico que recogerá todas las necesidades y requerimientos del usuario.

Fase de Implementación: Esta segunda etapa consiste en llevar el modelo teórico propuesto en la fase de diseño al mundo real. Hay que escoger una herramienta comercial de las muchas que existen. Sin querer entrar en polémica sobre su bondad o no, en este caso se llevará a cabo la implementación de la Base de Datos en la herramienta software Microsoft Access.

     A continuación exponemos el enunciado de un ejercicio que nos servirá de guía en todas las fases de diseño e implementación.
Pruebas de Atletismo
     En las pruebas de atletismo celebradas en la ciudad de XX durante el mes de YY, había una gran cantidad de datos a manejar. La organización necesitaba saber en todo momento a qué hora se celebra cada uno de los eventos y quiénes participan en los mismos, sin olvidar que es posible que un mismo atleta participe en varias pruebas diferentes. La organización desea tener una relación de atletas por orden alfabético para facilitar la elaboración de diplomas. También quiere saber cuántos atletas han participado en total, y cuántos hay de cada continente. Al final del campeonato publicará la clasificación general por pruebas.

2.1. Diseño de la base de datos
     La etapa de diseño es una fase de estudio incremental en la cual, sobre un diseño inicial se irán añadiendo nuevas necesidades y se irán detectando fallos que habrá que subsanar de forma continua, hasta que finalmente se obtenga el modelo definitivo.
     La construcción del modelo teórico de la Base de Datos, lleva dos fases:

Elaboración de un diseño teórico, independiente del tipo de Base de Datos en el que se va a llevar a la práctica, que denominaremos modelo conceptual.

Traducción de este diseño teórico al tipo de Base de Datos que se utilizará para implementarla. En este caso, se utilizará un modelo relacional ya que Microsoft Access es una Base de datos de tipo relacional. Si bien existen otros tipos de Base de Datos, las relacionales son las más populares y difundidas en la actualidad.

2.1.1. Modelo conceptual
    El primer paso en el diseño, consiste en localizar y decidir qué datos se van a considerar necesarios en la Base de Datos. Comenzaremos por decidir las Entidades. Una entidad es un objeto del mundo real distinguible de otro objeto. Para obtener las entidades, es conveniente elaborar una lista inicial con todos los datos que consideramos necesarios según el problema que tenemos y después agruparlos.
     En el ejemplo propuesto, una la lista inicial de datos podría ser:

Nombre de un atleta,
Fecha de nacimiento,
Continente al que pertenece el atleta,
Pruebas disputadas,
Resultado obtenido por un atleta en una prueba,
Hora de celebración de cada prueba,
Día de celebración de cada prueba

     Las entidades que englobarían esos datos serían:

ATLETAS O PARTICIPANTES
PRUEBAS

     La mayoría de datos relacionados en la lista inicial podrían encajar fácilmente en una de estas entidades. Por ejemplo, el nombre de un atleta encajaría en la entidad ATLETA.
     El segundo paso consiste en decidir qué atributos tendrán estas entidades. Los atributos son las propiedades de una entidad que la caracterizan. El conjunto de atributos no es arbitrario, debe describir perfectamente a la entidad y adaptarse a las necesidades de información previstas.

PRUEBAS:
Nombre de prueba,
hora de celebración,
día de celebración.

ATLETAS:
Nombre del atleta,
edad o fecha de nacimiento
continente de procedencia
     En ocasiones resulta difícil determinar estas características de forma que sean propias exclusivamente de cada entidad, ya que tendremos la tentación de poner algunas propiedades que en realidad, son relaciones entre entidades. Por ejemplo, en los datos de los ATLETAS podríamos incluir el resultado obtenido en una prueba, pero no lo haremos por el momento, ya que no se trata de un atributo de la entidad ATLETAS exclusivamente y depende también de la PRUEBA, es decir se trata de un atributo de la relación entre las dos entidades.
     Una vez decididas las entidades y los datos de cada una de ellas, se habrá de decidir qué asociaciones son posibles o son interesantes entre las entidades definidas. Es decir se definirán las relaciones entre entidades. Entre dos entidades asociadas, puede haber muchos tipos de relación, por eso hay que especificar de cuál de todas las posibles se trata. Puede interesarnos guardar información de la propia relación, es decir, las relaciones también pueden tener atributos.

     Estas dos entidades están claramente relacionadas. La relación existente entre un atleta y una prueba será la de su participación en la misma y la del resultado obtenido en ella.

     Una vez decidida la relación existente entre las entidades, hay que determinar su cardinalidad, es decir, cuántos elementos de una entidad se relacionan con cuántos elementos de otra entidad.
     Por ejemplo, una cardinalidad del siguiente tipo:

     Representaría que un atleta puede participar en varias pruebas. La cardinalidad de la relación sería de 1 a N. También indicaría que en el sentido contrario no ocurre lo mismo, es decir que en una prueba únicamente puede participar un atleta.
     Mientras que una cardinalidad del siguiente tipo:

     Representaría que en una prueba pueden participar varios atletas. La cardinalidad sería también de 1 a N. En este caso, indicaría además que un atleta únicamente puede participar en una prueba.
     Por último, una cardinalidad del tipo:

     Representaría los dos tipos vistos anteriormente, es decir, un atleta puede participar en varias pruebas y a su vez, en una prueba pueden participar varios atletas. La cardinalidad adecuada por tanto en este ejemplo sería M:N.
     Finalmente, con todo ello se obtiene el modelo teórico, en el que se han de especificar claramente las entidades, los atributos de cada entidad, las relaciones y los atributos de cada relación. En este caso sería:

Nombre, fecha de nacimiento, continente
Resultado (posición)
Nombre, día de celebración, hora de celebración

2.1.2. Modelo relacional
     Una vez finalizado el diseño inicial, hemos de saber qué tipo de base de datos vamos a utilizar. Una gran parte de las Bases de Datos comerciales son relacionales, como Access. Hemos de traducir pues, el modelo anterior a un modelo relacional.
     En primer lugar se decidirá cuál es la clave principal o primaria de cada relación. La clave primaria es aquel atributo de una entidad que identifica a la entidad. En nuestro ejemplo:

PRUEBAS:        Nombre de la prueba
ATLETAS:        Nombre del atleta, ó DNI.
     A continuación se realiza el proceso de traducción. La traducción de una entidad es una tabla. Una tabla consta de:

Filas: que contendrán los datos (a una fila también se la llama registro),
Columnas: contendrán los atributos o campos.
     En el ejemplo que nos ocupa, las entidades PRUEBAS y ATLETAS, se traducirían en sendas tablas:
PRUEBAS

NOMBRE DE LA PRUEBA

DIA DE CELEBRACIÓN

HORA DE CELEBRACIÓN

ATLETAS

NOMBRE ATLETA

FECHA NACIMIENTO

CONTINENTE

     Sin embargo, aunque esto es correcto, es mucho más práctico tomar como clave primaria un código. Es decir, añadimos un campo código a cada una de las tablas, en el que se codifiquen los distintos registros:
PRUEBAS

CÓDIGO DE LA PRUEBA

NOMBRE DE LA PRUEBA

DÍA DE CELEBRACIÓN

HORA DE CELEBRACIÓN

ATLETAS

CÓDIGO DE ATLETA

NOMBRE ATLETA

FECHA NACIMIENTO

CONTINENTE

     También hay que traducir las relaciones. Los distintos tipos de relación se traducen de distinta forma:

Relación 1:N    ------------------->
     En la tabla destino, se incluye la clave primaria de la tabla origen, como clave extranjera.

Relación N:M    <------------------->

     Se crea una tabla nueva, cuyos campos serán las claves primarias de las tablas que forman esa relación, y los atributos de la relación:
RESULTADO

CÓDIGO DE ATLETA

NOMBRE ATLETA

FECHA NACIMIENTO

     El diseño relacional completo constaría de las tres tablas: PRUEBAS, ATLETAS y RESULTADOS.

2.2. Implementación de una base de datos
     En Windows podemos abrir la aplicación de ACCESS por menú, localizando en el botón Inicio, la opción Programas, subopción Microsoft Access. La aplicación nos preguntará si deseamos abrir una base de datos en blanco o utilizar una ya existente. En la versión de Office 97 el aspecto sería este:

     A continuación se nos pedirá el nombre de la Base de Datos. La llamaremos Primer Ejercicio. Una vez hecho esto, la aplicación presenta el siguiente aspecto en Access 97:

     En Access 2000 es similar. Si bien aparentemente son distintos, todas las opciones que se van a llevar a cabo en este ejercicio se realizan de igual modo en ambas versiones. Las opciones de manejo básico son similares a las de cualquier aplicación de Windows tanto para Abrir, Cerrar, Salir o Guardar y no insistiremos en ellas.
     Vemos que tenemos una serie de fichas, con las que iremos confeccionando poco a poco la Base de Datos.

2.2.1. Tablas
     La primera ficha es la de Tablas. Aquí crearemos las tablas que hemos decidido tener previamente diseñadas. Para ello pulsaremos el botón Nuevo, de la ficha Tablas.
     A continuación, de las opciones presentadas, escogeremos la Vista Diseño.

     En la pantalla que se nos presenta, iremos rellenando los campos de la tabla de PRUEBAS.

     Especificaremos los tipos de datos, según sean de texto, numéricos, etc. Para las claves primarias se suele utilizar el tipo Autonumérico, que es un tipo de dato que crea un número y lo va incrementando automáticamente.

     Una vez completa la tabla, seleccionamos qué campo va a ser clave primaria, y pulsamos el botón que tiene forma de llave:

     Al cerrar la ventana de la tabla, se nos preguntará el nombre de la misma:

Lecturas: Educación Física y Deportes · http://www.efdeportes.com · Año 6 · Nº 29 sigue Ü