FileMaker: Diseño de bases de datos parte 4

En el artículo anterior concluimos definiendo la estructura de la base de datos que vamos a crear ahora en FileMaker y nos quedaron las tablas de las siguiente manera:


Sin embargo, antes de construir la base de datos en FileMaker, debemos considerar los casos de uso de la aplicación.

Los casos de uso describen que es lo que hará la aplicación y no tanto como lo hará, eso viene después, de momento necesitamos entender que haremos con la aplicación, como vamos a utilizar la aplicación y eso también nos dará una idea de las interfaces de usuario que deberemos diseñar, así como el esquema de operación de la misma.

¿Cuales son los casos de uso de la aplicación?

Catálogos.
Los primero tres casos de uso nos permitirán mantener los catálogos de la aplicación, estos catálogos serán: Nacionalidades, Turistas y Recorridos Turísticos.

Por lo tanto debemos diseñar una presentación, que permita la creación y modificación de registros para las tablas Nacionalidad, Recorrido y Turista, así como una presentanción quizas para listados en cada una de esas tablas.

En la presentación para el Alta de turistas se deberá incorporar un portal que permita la creación de registros relacionados hacia la tabla Teléfono.

Para la tabla Telefono, no es necesario crear una presentación, ya que la navegación en el sistema será desde la tabla Turista, así que podemos eliminar la presentación que el sistema crea por defecto para la tabla Telefono.

Dentro de la presentación de captura en la tabla Turista, adicionalmente a colocar un portal para los teléfonos, creamos una lista de valores para el campo idNacionalidad y a esa lista de valores, le asignamos el campo nacionalidad de la tabla Nacionalidad.

Para las tablas Nacionalidad, Turista y Recorridos, podemos crear presentaciones para captura, consulta y listados.

Funcionalidad de recorridos turísticos.
El último caso de uso lo hemos llamado: "Alta de Recorridos Realizados", esto es completamente distinto a lo que se refiere el caso de uso sobre Alta de Recorridos, este último es el manejo del catálogo de recorridos turísticos que ofrece la empresa y el primero se refiere a los recorridos que realiza un turista.

Estos recorridos realizados serán las visitas realizadas por los turistas dentro de los recorridos turísticos, razón por la cual se creo la tabla Realiza, que en realidad son las visitas llevadas a cabo en una fecha dada y hacia un recorrido determinado.

En esta tabla, "Realiza", se guardará un registro por cada turista que visita un mismo recorrido y en la misma fecha, es decir, Si el recorrido 1 es llevado a cabo por 20 turistas, entonces la tabla Realiza tendrá para este caso 20 registros, uno por cada turista, pero los 20 registros tendrán el mismo recorrido y la misma fecha. Si quisieramos mantener un catálogo de visitas o recorridos realizados, uno por cada recorrido en un fecha determinada, dentro del cual existen varios turistas, entonces debemos hacer un cambio en el diseño.

A estas alturas del diseño y una vez que empezamos a analizar los casos de uso, nos damos cuenta que nos hace falta considerar esta opción, por eso comentamos lineas arriba que aún no era prudente empezar a crear las tablas en FileMaker.

Realiza será una visita, por lo que se requiere descomponer la relación entre Realiza y Turista, la cual es una relación todavía de muchos a muchos, por lo tanto al realizar dicha descomposición creamos una tabla intermedia entre estas dos tablas que llamaremos Turista en Recorrido, a la cual pasamos el idTurista de la tabla Realiza y para lograr la integridad referencial adicionamos un idVisita en la tabla realiza que será autonuérico y que nos permitira establecer la relación con la tabla Turista en Recorrido quedando de la siguiente manera:


Como observamos en la figura, se creo una tabla adicional llamada Turista en Recorrido, la cual contiene dos campos: idVisita e idTurista, adicionalmente se modifcó la tabla Realiza eliminando el campo idTurista y agregando un campo llamado idVisita, el cual será autonumérico, para establecer la relación entre Realiza y Turista en Recorrido, de esta manera podremos colocar un portal en la presentación de Realiza para mostrar los registros relacionados de la tabla Turista en Recorrido, esta relación deberá permitir crear y borrar registros relacionados en la tabla Turista en Recorrido.

Ahora si tenemos el diseño final de la base de datos, por que para crear las tablas en FileMaker solo tenemos que establecer las consideraciones finales para los campos.

El siguiente punto es tomar en cuenta las consideraciones para cada uno de los campos en totas las tablas, así como la creación de las relaciones entre tablas.






Una vez creadas las tablas (Nacionalidad, Telefono, Turista, Recorrido, Realiza y Turista en Recorrido) con estas consideraciones en los campos, establecemos las relaciones entre ellas.

Parra ello, arrastramos desde la tabla Telefono, en esta relación se activarán las casillas para crear registros relacionados y eliminar registros relacionados en la tabla Telefono desde la tabla Turista, para la siguiente relación arrastramos el campo idTurista hacia el campo idTurista en la tabla Turista, el campo idNacionalidad desde la tabla Turista hacia el campo idNacionalidad en la tabla Nacionalidad.

El campo idTurista desde la tabla Realiza hacia el campo idTurista en la tabla Turista en Recorrido, esta relación debe permitir el borrado y la creación de registros relacionados en la tabla Turista en Recorrido desde la tabla Realiza, adicionalmente arrastramos el campo numero desde la tabla Realiza hacia el campo numero en la tabla Recorrido.

Por último arrastramos el campo idTurista de la tabla Turista en Recorrido hacia el campo idTurista en la tabla Turista.

Los valores de los campos idTurista en la tabla turista, así como número en la tabla Recorrido y el campo idNacionalidad de la tabla Nacionalidad serán asignados automáticamente por el sistema.

Finalmente, para dar de alta a los turistas que realizan recorridos, creamos una presentación para la tabla Realiza, en ella establecemos una lista de valores para el campo numero en el que asignamos el campo numerode la tabla Recorrido, de esta forma podemos escoger el recorrido turístico y mostrar en la presentación su nombre, para ello no se requiere un portal, simplemente colocar los campos relacionados de la tabla Recorrido en la presentación de la tabla Realiza.

Posteriormente colocamos un portal con los registro relacionados de la tabla Turista en Recorrido, aunque en este portal colocamos los campos de la tabla Turista.

Adicionalmente, si deseamos visualizar que recorridos ha hecho un turista, entonces, en la presentación de consulta para la tabla Turista podemos colocar un portal asigando a la tabla Realiza, pero en el colocamos campos de la tabla Recorrido, de esa forma podemos tener un historia de los recorridos que ha realizado un turista.

El archivo con el ejemplo que desarrollamos en estos cuatro artículos lo pueden descargar para su revisión en la siguiente dirección:

Turista.fp7

FileMaker: Diseño de bases de datos parte 3

En la segunda parte del artículo finalizamos con la transformación al modelo relacional, es decir, diseñando las tablas para la base de datos. Dichas tablas se obtivieron en base al modelo entidad-relación y de acuerdo con las reglas de transformación descritas en el artículo anterior.

Ahora necesitamos analizar las dependencias que existen entre los atributos o campos de las tablas y de esta forma poder normalizar dichas tablas.

La normalización implica tratar de eliminar al máximo la redundancia de datos que pudiera presentarse al construir las tablas ya transformadas y empezar a almacenar datos en ellas. Algunos grados de redundancia tendrán que ser aceptados en la mayoría de las bases de datos dependiendo de la funcinalidad de la aplicación, la semántica de los datos y las rescricciones de usuario.

El tema de la normalización es un poco más complejo y el objetivo de este artículo no es aburrir incursionando en los detalles técnicos, por lo que trataremos de explicarlo de una forma sencilla y clara.

Dada la sencilles de nuestro ejemplo, al llevar a cabo la transformación al modelo relacional, las tablas resultantes se obtuvieron dentro de la segunda y tercera forma normal y esto es debido a las dependencias entre atributos o campos.

Entre los campos de una tabla pueden existir dependencias de varios tipos. Las dependencias son propiedades inherentes al contenido semántico de los datos, formando parte de las restricciones de usuario del modelo relacional.

Existen distintos tipos de dependencias: funcionales, multivaluadas, jerárquicas y en combinación.

Dependencias Funcionales

Dada tabla R formada por los campos A, B Y C, representandola de la forma R(A, B, C). Si B depende funcionalmente de A (entonces A implica o determina a B), si para cada valor de A solamente existe un único valor posible para B.

Notación: A -> B

ejemplo: Para la tabla Recorrido, una dependencia funcional existe entre el campo número y el campo nombre:

numero -> nombre

Si además se cumpliera que no pueden existir dos recorridos con el mismo nombre, esto implicaría que el nombre también puede actual como clave de la tabla Recorrido y por lo tanto también derermina funcionalmente a número:

numero <-> nombre

Dependencias Multivaluadas

De la tabla R(A, B, C), A multidetermina a B si para cada valor de A existe un conjunto bien definido de valores posibles en B, con independencia del resto de los campos de la tabla.

Notación: A ->-> B

ejemplo: Si en la tabla turista también quisieramos guardar el telefono de los turistas y que algunos de ellos indicaran más de un número: celular, casa, oficina, etc. La dependencia multivaluada estaría dada por:

nombre ->-> teléfono

Para cada persona tenemos varios números telefónicos.

Formas normales

Existen seis niveles de normalización de una tabla. Una tabla se encuentra en uno u otro grado de normalización si cumple una serie de propiedades (restricciones) que se explicarán a continuación.

Las tres primeras formas normales las definió Codd y se basan en las dependencias funcionales que existen entre los campos de la tabla. Posteriormente, y basandose en las dependencias multivaluadas y en bombinación se definieron dos niveles más de normalización, la 4a y la 5a respectivamente.

Entre la tercera y la cuarta se definió una que se conoce como la forma normal de Boyce-Codd (FNBC) la cual redefine a la 3ra forma normal debido a algunas anomalías encontradas.

De esta forma las tablas en 1a forma normal tienen más reduncancia de datos que los niveles superiores y por lo tanto, más anomalias de actualización de datos. La 5a forma normal es el grado de normalización máximo que se puede alcanzar para una tabla.

Primera forma normal.

Se dice que una tabla se encuentra en la 1a forma normal cuando cada campo sólo toma un valor del dominio simple subyacente. Es decir que no existen grupos repetitivos.

Un ejemplo lo podemos mostrar con las tablas siguientes, la primer tabla no cumple la restricción de la primer forma normal, sin embargo la segunda si la cumple.

La primera forma normal es una restricción inherente al modelo relacional, por lo que su cumplimiento es obligatorio para todas las tablas.

Segunda forma normal.

Se dice que una tabla se encuentra en la segunda forma normal si:

• Se encuentra en la 1er forma normal
• Cada campo que no forma parte de la clave primaria tiene dependencia funcional completa respecto de alguna de sus claves.

Por ejemplo: Turista(idTurista, nombre, nacionalidad) donde la clave primaria es idTurista, existe:

nombre -> nacionalidad

Por lo tanto la tabla Turista con esos campos se encuentra en la segunda forma normal.

Tercera forma normal.

Se dice que la tabla se encuentra en la 3a forma normal si:

• Se encuentra en la segunda forma normal
• No existe ningun campo que no forma parte de la clave primaria que dependa transitivamente de alguna clave de la tabla.

Por ejemplo: R(A,B,C) si B -> C R se encuentra en la 2a forma normal, ya que no existe dependencia transitiva de B o C con respecto de A

Análisis

El objetivo del análisis es llevar a cabo un proceso de descomposición por medio de proyecciones sucesivas para obtener, de una tabla, una serie de tablas resultantes, las cuales deben cumplir con la conservación de la información (campos y registros), de las dependencias y que exista mínima redundancia de datos.

De esta forma las n tablas resultantes serán equivalentes a la tabla inicial y tendrán menor redundancia de datos debido a que se encuentran en un nivel de normalización mayor.

Dado que la normalización parece un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos mas elementales de la normalizción.

Una de las formas más fáciles de entender esto, es pensar en nuestras tablas como hojas de cálclulo. Por ejemplo para el caso de los teléfonos de los turistas, si agregaramos un campo a la tabla por cada numero telefónico que podríamos capturar para un turista tendríamos algo asi:

Algunos turistas turistas tienen uno, dos o tres números, no todos tienen los tres números para los cuales tenemos capacidad en la tabla.

Así como hemos mencionado que el objetivo de la normalización es eliminar la redundancia de datos, también lo es eliminar el número de celdas vacías.

El darnos cuenta de que la tabla turista tiene un conjunto fijo de campos (nombre, sexo, edad, nacionalidad) y un conjunto variable de campos (telefono1, telefono2, telefono3), nos da una idea de como dividir los datos en multiples tablas que estarán relacionadas entre sí.

Cuando hablamos del proceso de descomposición para obtener n tablas resultantes, lo vemos en el ejemplo de los teléfonos y el proceso se describe con la siguiente figura:

Al aplicar las reglas de normalización a la tabla original R, esta la descomponemos en dos tablas R1 y R2, después, dada la redundancia de R2, le aplicamos las reglas y la descomponemos en R3 y R4. Todas las tablas resultantes: R1, R2, R3, y R4 conservan el atributo A, que es la clave primaria y con la cual estableceremos la relación entre ellas, sin embargo para cada tabla resultante, la clave primaria será una combinación de entre la clave primaria de la tabla original y algún otro campo de cada tabla resultante, dependiendo de las restricciones.

Si aplicamos la regla de la primer forma normal para la tabla de datos del ejemplo, la cual nos indica separar los grupos repetitivos. En este caso el grupo repetitivo es el conjunto de campos para teléfono, los cuales dependen del id del turista, por lo que los separamos juntos.

Separando en dos grupos los campos tendríamos:

1er Grupo (idTurista, nombre, sexo, edad, nacionalidad)

2o Grupo(idTurista, telefono1, telefono2, telefono3)

Ahora para la segunda forma normal, en esta analizamos sólo aquellos grupos que tengan claves combinadas, dado que no hay claves combinadas, ignoramos este paso.

Para la tercera forma normal examinamos las interdependencias entre campos no claves.

Todos los campos o atributos en cada grupo que no sean claves, deben ser examinados para verificar que no existan interdependencias entre ellos. Si se encuentran algunas, tales dependencias deben ser separadas en distintos grupos cuya clave debe ser el campo del cual son dependientes, dejando este campo clave también en el grupo original.

Para el primer grupo analizamos que nombre, sexo, edad y nacionalidad son dependientes de idTurista y no hay interdependencia entre ellos, por lo tanto, ingnoramos al prier grupo.

En el segundo grupo sucede lo mismo, cada campo teléfono es dependiente del idTurista. Pero ahora no todos los turistas tendrán tres teléfonos, por lo que modificamos el segundo grupo y dejamos que cada registro identifique un teéfono único para cada turista, de esta forma el segundo grupo quedará:

2o Grupo (idTurista, telefono)

En el hacemos que la clave primaria y única sea la combinación de ambos campos, es decir, la clave primaria estará formada por idTurista y telefono. Asi podremos evitar también que se capture dos veces el mismo número para el mismo turista, pero podemos tener el mismo número para turistas distintos.

Ahora bien, sabemos que para el campo sexo, sólo pueden existir dos valores (H o M), por lo que podremos utilizar una lista de valores para este campo y evitar errores en la captura del mismo.

Para el caso del campo nacionalidad, la cantidad de valores que se pueden tener es grande, sin embargo para evitar errores en la captura con los posibles datos podriamos separarlo de grupo 1 y crear un nuevo grupo, al cual le tendremos que asignar una clave única:

3er grupo (idNacionalidad, nacionalidad)

El primer grupo quedaría modificado de la siguiente forma:

1er Grupo (idTurista, nombre, sexo, edad, idNacionalidad)

Con ello podríamos crear una lista de valores para nacionalidad y evitar errores en la captura.

Dado los pocos campos que tenemos en las tablas Recorrido y Realiza, no existen independencias o dependencia funcionales y multivaluadas en estas tablas, por lo que no hay necesidad de llevar a cabo una normalización adicional, dischas tablas se encuentran en la 3er forma normal.

Finalmente las tablas a construir en la base de datos son las siguientes:

Estas ya son las tablas normalizadas hasta la tercer forma normal que se construiran en la base de datos. Para ello el sigueinte paso es analizar los tipos de datos que se requieren para cada uno de los campos.

En la cuarta y última parte de este artículo hablaremos sobre los detalles para la construcción de estas tablas, los tipos de datos para los campos, restricciones y validaciones, así como las cosideraciones necesarias para la creación de presentaciones (layouts) para la aplicación: captura, consulta, reportes, etc.

FileMaker: Diseño de bases de datos parte 2

Diseño de tablas y sus relaciones
En la primer parte de este artículo habiamos creado el modelo entidad relación del ejemplo de recorridos turísticos y teníamos lo siguiente:

En donde mencionabamos que un turista puede realizar varios recorridos turísticos, y que un recorrido turístico es realizado por varios turistas, por lo que tenemos una relación de muchos a muchos entre ambas entidades: Turistas y Recorridos. En este modelo tenemos sólo dos entidades: Turista y Recorrido. "Realiza" es la relación que existe entre las dos entidades.

Ahora bien, si sabemos que para cada turista necesitamos registrar su nombre, edad, nacionalidad y sexo y que además los recorridos están identificados con un número de recorrido, un nombre y una descripción de la ruta y los atractivos turísticos que se visitan, así como, la fecha en que cada turísta realiza un recorrido, el modelo lo podemos completar con dicha información de la siguiente manera:

La fecha no la colocamos en el recorrido, ya que la entidad Recorrido es un catálogos de los recorridos turísticos que se ofrecen y que se realizan en distintas fechas por distintos turistas, así que la fecha la colocamos en la relación entre ambas entidades.

Con esta información, ahora podemos describir algo similar a esto: "John Smith, hombre británico de 30 años de edad, realizó el 20 de enero de 2008, el recorrido número 1 - Teotihuacan, Recorrido a la zona arqueológica, con escalada a la pirámide del sol, comida en reataurante xxx,.... etc. etc."

Cuando tenemos entidades con muchisimos datos, no se vuelve práctico colocarlos todos en el modelo entidad-relación, sin embargo, podemos colocar los datos más relvantes para darle sentido al modelo.

En la entidad Recorrido, el número de recorrido, será el valor que nos identifique de manera única a cada registro, es decir, a cada recorrido, por lo tanto no habrá dos recorridos con el mismo número.

Para el caso de la entidad Turista, no tenemos hasta el momento un atributo que identifique de manera única a cada turista, no podemos utilizar el nombre, ya que varias personas pueden llamarse igual, lo mismo sucedería con la edad, el sexo y la nacionalidad, por lo que agregaremos un atributo que sea un identificador único para cada registro o turista, este identificador lo llamaremos idTurista y tendrá valores numéricos consecutivos.

Nuestro siguiente paso ahora es realizar la transformación del modelo entindad-relación al modelo relacional, es decir, diseñar las tablas de la base de datos en donde almacenaremos la información de este sistema.

Reglas de transformación.

Las tres reglas básicas para realizar la tranformación del modelo entidad-relación al modelo relacional son:

• Toda entidad se transforma en una tabla.


• Las relaciones de muchos a muchos (N:M) se transforman en tablas.


• Las relaciones uno a muchos (1:N) dan lugar o bien a una propagación de identificador único o bien a una tabla.

Tomando en cuenta la primer regla, tranformamos las dos entidades del modelo en dos tablas correspondientes:

Como se mencionó anteriormente y podemos observar en la figura de la tablas, la tabla Turista contiene un atributo adicional (campo) llamado idTurista, el cual se convierte en la clave primaria de esta tabla, es el atributo que nos permite establecer un identificador único para cada turista. Para el caso de la tabla Recorrido, el identificador único (clave primaria) será el número del recorrido.

El modelo relacional impone una serie de restricciones inherentes:

1. En una tabla no puede haber dos registros iguales (obligatoriedad de clave primaria).


2. El orden de los registros y de los atributos no es relevante.


3. Cada atributo sólo puede tomar un único valor del dominio sobre el cual está definido, a excepción del caso de los campos repetitivos que si se permiten en FileMaker.


4. Ningún atributo que forme parte de la clave primaria puede tener valores nulos o vacíos (integridad de entidades).

Las restricciones con respecto a los atributos, las veremos más adelante.

Mientras tanto, para la segunda regla de transformación tenemos que: Las relaciones N:M dan lugar a una tabla cuya clave primaria o identificador único será la concatenación de los identificadores principales de las entidades que se enlazan con esta relación. De esta forma, los campos que forma la clave primaria de esta nueva tabla son claves ajenas o foraneas respecto a las tablas en las que estos campos son clave primaria.

La relación "Realiza", da lugar a una tabla que llamaremos Realiza, (el nombre puede ser distinto), que contiene ademas de los atributos que forma la clave primaria, el campo fecha.

idTurista se refiere al identificador único de la tabla turista, pero en esta tabla se convierte en una clave foranea que forma parte de la clave primaria de la tabla Realiza. número es la clave primaria en la tabla Recorrido, pero se convierte en clave foranea en esta tabla y forma parte también, de la clave primaria de la tabla Realiza.

La tabla realiza enlaza a las tablas Turista y Recorrido, por lo tanto su clave primaria o identificador único está formado por dos campos, es decir, es una clave primaria compuesta.

Ahora bien, ¿Que sucede si un mismo turista realiza dos veces un mismo recorrido?, ya sea por que le gustó, por que quiso repetir la experiencia, etc. por lo que sea, pero si el mismo turista lo realiza dos veces, es obvio que no puede hacerlo el mismo día si tomamos en cuenta que son recorridos de todo un día.

Tomando en cuenta las reglas y restricciones mencionadas anteriormente, en la que deciamos que en una tabla no puede haber dos registros iguales, el valor que diferenciaría a estos dos registros es precisamente la fecha. Por lo tanto, para la tabla Realiza, incorporamos a la clave primaria el campo fecha. De esta forma la clave primaria de la tabla Realiza estará compuesta por los campos: idTurista, numero y fecha.

Finalmente, al diseñar las tres tablas resultantes y enlazarlas para establecer la relación entre ellas, el diagrama relacional nos queda de la siguiente forma:

Aún no podemos decir que las tablas quedarán construidas de esta forma en FileMaker, antes de construirlas necesitamos tomar encuenta algunas consideraciones sobre el dominio de los atributos, valores multivaluados, depencencias funcionales y restricciones en cuanto a la información que será almacenada en la base de datos.

Todos estos puntos los trataremos en la siguiente parte de este artículo, en donde veremos los esquemas de normalización para reducir al máximo la redundancia de datos.

FileMaker: Diseño de Bases de Datos Parte 1

El Modelo Relacional


Desde el lanzamiento de la versión 7 de FileMaker Pro y ahora con las nuevas funcionalidades de la versión 9 (Conexión a fuentes de datos SQL Externas), se vuelve importante tener ciertos conocimientos en temas acordes al modelo relacional, ya que FileMaker, de alguna forma, en estas versiones se apega más al concepto de una base de datos relacional, que lo fué en sus versiones anteriores.



Cuando hablamos de temas acordes al modelo relacional, nos referimos principalmente al conocimiento, al menos básico, de los siguientes temas:

• Diseño y Modelado de la base de datos.
  
• Diseño de tablas y sus relaciones.


• Normalización.


• Construcción de tablas relacionadas normalizadas.

Diseño y Modelado de bases de datos
Uno de los pasos importantes en la construcción de una aplicación que maneja una base de datos, es precisamente, el diseño de la base de datos. Si las tablas no son definidas correctamente, podemos tener problemas al momento de ejecutar consultas que nos permitan obtener la información que deseamos.

No importa si la base de datos contiene solo unos cuantos registros o miles de ellos, es importante asegurar que la base de datos está correctamente diseñada para obtener la máxima eficiencia y que podamos utilizarla por mucho tiempo.

Dependiendo de los requeriminetos de la base de datos, el diseño puede ser complejo, pero tomando en cuenta algunas de las reglas simples será mucho más fácil crear una base de datos para cada uno de nuestros proyectos.

Algunas de las consideraciones que debemos tomar en cuanta al realizar el diseño de la base de datos son:

1. Velocidad de acceso


2. Tamaño de la información


3. Tipo de información


4. Facilidad de acceso


5. Importación y exportación de información


6. Presentación de la información

No importa que tan buenas sean las aplicaciones que hemos desarrollado con anterioridad, siempre es recomendable seguir algunos estándares de diseño para garantizar la máxima eficiencia en lo que se refiere al almacenamiento y recuperación de la información.

Al igual que un arquitecto crea los planos para la construcción de un edificio, nosotros debemos crear el modelo para la construcción de una aplicación. Ningún arquitecto se avienta a iniciar la construcción de un edificio sin antes tener una idea clara de lo que quiere construir, y esta idea se modela con el desarrollo de los planos, ahí es donde se plasman las dimensiones, características y alcances de lo que se requiere construir. Pues en el desarrollo de software sucede lo mismo, antes de iniciar la programación y/o la construcción como tal es importante crear un modelo que nos permita visualizar las características y los alcances de nuestra aplicación.

El modelo es una abstracción de la realidad, que nos permite simular el producto final y entender claramente el objetivo que perseguimos.

El modelo Entidad-Relación es uno de principales estándares que nos permiten plasmar la funcionalidad de la aplicación en terminos de entidades y la forma en que se relacionan unas con otras. Las entidades representan los datos del dominio de nuestra aplicación. Por ejemplo, si deseamos desarrollar una aplicación para llevar el control de los recorridos turísticos que realiza un turista. Las principales entidades que encontramos aquí son: Turistas y Recorridos, estas entidades son los datos que serán almacenados en la base de datos. La relación que guardan estas dos entidades una con otra, se podría describir de la siguiente forma: Los turistas realizan recorridos. La relación entre las dos entidades es una acción, es decir, un verbo que describe la acción que se lleva a cabo de una entidad a otra, lo cual se modela como se muestra en la siguiente figura:

La figura nos decribe dos entidades relacionadas entre sí de acuerdo con el modelo entidad-relación. La simbología adicional utilizada en el modelo, nos permite describir con más detalle la forma en que estas dos entidades se encuentran relacionadas y lo podemos leer de la siguiente forma:

1 Turista realiza N Recorridos, 1 Recorrido es realizado por N Turistas, lo cual nos resulta en una relación de muchos a muchos (N:M) entre las dos entidades.

De esta manera podemos entender también como quedarán las tablas que construiremos en la base de datos. Adicionalmente en el modelo entidad-relación podemos especificar los atributos necesarios para cada una de las entidades, es decir, los datos que se requieren para procesar e identificar cada uno de ellos, por ejemplo para turista podríamos requerir su nombre, su nacionalidad, su edad, etc. Para la entidad Recorrido, quizas la ruta que lo identifica, el nombre del recorrido o algún otro dato que la empresa para esta entidad.

Los atributos de las entidades se convertiran en los campos de las tablas correspondientes.

Ahora bien, si para la relación "realiza" es necesario identificar cuando y a que hora se realiza el recorrido, entonces la relación se convierte en una relación identificada, la cual especificaría dos atributos: fecha y hora, de cuerdo con el ejemplo que estamos tratando.

Diseño de tablas y sus relaciones

Esta sección la cubriremos en la segunda parte de este artículo y basicamente consiste de la transformación del modelo entidad-relación al modelo relacional, en el cual, concretamente convertimos las entidades, así como las relaciones identificadas en tablas.