Diagramar las tablas en MySQL

A lo largo de este tutorial, crearemos las tablas necesarios para la base de datos sampdb. Primero, veremos qué tablas se necesitan para la organización Historical League. Es la parte en que otros tutoriales hablan de análisis y diseño, diagramas de relaciones de entidades, procedimientos de normalización y demás. Ya habrá tiempo para eso, pero prefiero pensar en el aspecto que tendrá la base de datos: qué tablas debe incluir, los contenidos de cada tabla y los aspectos implicados en la representación de los datos.

Tablas para la organización U.S. Historical League

El diseño de las tablas de la organización Historical League es muy sencillo:

  • Una tabla president que contien un registro de todos los presidentes norteamericanos. La necesitaremos para el concurso en línea del sitio Web.
  • Una tabla member que se utiliza para mantener información actualizada sobre los miembros de la asociación. La utilizaremos para crear versiones electrónicas e impresa del directorio, enviar recordatorios automatizados, etc.

La tabla president

La tabla president es la más sencilla, motivo por el que la analizaremos en primer lugar. Contiene información biográfica básica sobre los presidentes de Estados Unidos.

  • Nombre: Los nombres se pueden representar de varias formas. Por ejemplo, podríamos tener una columna con el nombre completo o columnas independientes para el nombre y el apellido. Es más sencillo utilizar una sola columna, pero resulta limitado:
    – Si primero introduce el nombre, no puede ordenar por apellidos.
    – Si primero introduce el apellido, no puede mostrar el nombre primero.
    – Es más complicado buscar nombres. Por ejemplo, para buscar un apellido concreto, debe utilizar un patrón y buscar nombres que coincidan con el mismo. Es menos eficaz y más lento que buscar el apellido exacto.

    Para evitar estas limitaciones, utilizaremos columnas independientes para nombres y apellidos.

    La columna del nombre también incluirá la inicial. No afectará al orden ya que es poco probable que necesitemos ordenar por inicial (incluso por nombre). El nombre se mostrará correctamente ya que la inicial aparece justo después del nombre, independientemente de que se escriba como «Bush, George W.» o «George W. Bush».

    Existe otra complicación. Un presidente (Jimmy Carter) incluye «Jr.» al final del nombre. ¿Dónde lo incluimos? En función del formato de impresion de los nombres, el nombre se mostrrará como «James E. Carter, Jr.» o «Carter, James E., Jr».
    «Jr.» no se asocia al nombre ni al apellido, por lo que crearemos otra columna para los sufijos. Esto demuestra que un solo valor puede causar problemas al intentar conocer los valores de datos con los que va a trabajar antes de añadirlos a la base de datos. Si desconoce los valores, puede que tenga que modficiar la estructura de las tablas después de haber empezado a utilizarlas. No es el fin del mundo, pero debería evitarlo.
  • Lugar de nacimiento (ciudad y estado): Como el nombre, también se puede representar en una columna o en varias. Es más sencillo utilizar una sola columna pero las columnas independientes le permiten realizar otras operaciones. Por ejemplo, es más sencillo encontrar filas de presidentes nacidos en un determinado lugar si la ciudad y el estado se muestran de forma separada. Utilizaremos columnas independientes para los dos valores.
  • Fecha de nacimiento y defunción: El único problema es que la fecha de fallecimiento no es obligatoria ya que algunos presidentes siguen vivos. El valor especial NULL equivale a «sin valor», por lo que podemos utilizarlo en este ejemplo.

La tabla member

La tabla member es similar a la anterior ya que cada fila contiene información descriptiva básica de una persona. Pero cada fila member contiene más columnas:

  • Nombre: Utilizaremos una representación en tres columnas como en la tabla president: apellido, nombre e inicial.
  • Número de ID: Un valor exclusivo asignado a cada miembro al inscribirse. La organización no ha utilizado números de ID antes pero ahora que los registros son más sistemáticos, lo aplicaremos.
  • Fecha de vencimiento: Los miembros deben renovar periódicamente su suscripción.
    En algunas aplicaciones, podría almacenar la fecha inicial pero no en este caso. La suscripción se puede renovar por varios años (uno, dos, tres o cinco) y la fecha de la última renovación no indicaría cuando se va a producir la siguiente. Por ello, almacenaremos la fecha final de la suscripción. Además, la organización permite suscripciones vitalicias que podríamos representar con una fecha lejana en el futuro pero NULL parece más adecuado.
  • Dirección de correo electrónico: La publicación de direcciones de correo facilitará la comunicación entre los miembros. Como secretario de la organización, estas direcciones le permitirán enviar avisos de renovación de suscripción, lo que resultará mas rápido y económico. También puede enviar los contenidos actuales de las entradas del directorio y solicitar la actualización de los datos.
  • Dirección postal: Necesaria para miembros sin correo electrónico. Utilizaremos columnas para la calle, ciudad, estado y código postal.

    En nuestro ejemplo, asumimos que la organización tiene su sede en Estados Unidos. Si tiene que utilizar direcciones de varios países, tendrá problemas con los formatos de dirección. Por ejemplo, el código postal no es un estándar internacional y algunos países tienen provincias y no estados.
  • Número de telefóno: Como las columnas de dirección, un dato muy útil para contactar con los miembros.
  • Palabras clave: Se supone que cada uno de los miembros tiene un interés general por la historia estadounidense, pero también tendrá intereses concretos, que registraremos en esta columna. Los miembos pueden utilizarla para localizar otros miembros con interes afines.

Comparte