viernes, 27 de noviembre de 2020

Evitar valores nulos en las tablas

Varios autores coinciden con la experiencia de quienes han trabajado con valores nulos: no usar valores nulos ([DAT07], [CEL10], [COR09] y [ELM07], entre otros). Algunos motivos son:

  • Dos valores nulos no son iguales ("nulo" significa realmente "indefinido") por tanto no son comparables.
  • Las bases de datos necesitan espacio adicional para almacenar un valor nulo.
  • Las aplicaciones deben tener lógica extra para trabajar con campos nulos.
  • Puede producir problemas a la hora de calcular, comparar, ordenar y agrupar.
  • Provoca resultados no esperados con las cláusulas NOT EXIST y NOT IN.

Como alternativa, es preferible utilizar valores equivalentes a nulos. Por ejemplo, la cadena vacía puede considerarse, a todos los efectos, como un valor nulo (no suele haber diferencia entre que el usuario no rellene un campo o lo haga con la cadena vacía); si bien el significado no es el mismo, a la larga suele carecer de importancia. De igual modo, -1 puede ser un buen sustituto del nulo cuando se esperan valores naturales.

Sólo es interesante utilizar nulos en tipos de campo sobre los que no se pueda obtener un valor sustituto de aquél. Experimentalmente, los campos de tipo fecha y hora son los posibles candidatos a esto, y sólo debería permitirse cuando realmente deba ser un campo nulo.

viernes, 20 de noviembre de 2020

Principios rectores de la docencia

Propongo lo que para mí deberían ser los principios rectores de un buen docente, y que, en mayor o menor medida, he intentado llevar a cabo durante mis años como profesor.

  1. Atención: el docente debe “enganchar” a los estudiantes y tratar de garantizar su interés. Sin atención, nada de lo que se explique será útil. De esta forma, además, se facilita el siguiente principio.
  2. Interacción: el docente debe conocer a sus alumnos, y éstos deben participar con frecuencia y ser invitados a expresar sus inquietudes. De esta forma, además, se facilita el siguiente principio.
  3. Contenido: basándose en un temario abierto, el docente debe considerar las necesidades detectadas en o referidas por los estudiantes, con objeto de apuntalar contenido específico.

Esto no garantiza el éxito de nuestras clases, pero son un buen punto de partida.

miércoles, 18 de noviembre de 2020

Nombrar campos clave en las tablas

  • Todas las tablas tienen un identificador entero llamado Id, salvo las tablas que representen relación N x N (x N…), cuyo uso es opcional y no necesario.
  • Todas las claves ajenas tiene la forma Id_{Tabla} (por ejemplo, Id_Color o Id_Vehicle) u, opcionalmente, Id_{Tabla}_{semántica} (por ejemplo, Id_Team_local).
  • Para mantener un criterio visual homogéneo, el orden de aparición de los campos es: clave primaria, claves ajenas y todos los demás.
  • Los nombres de las tablas que representan una relación N x N (x N…) son {Tabla 1}_{Tabla 2}(_{Tabla 3}…), como por ejemplo Person_Vehicle.
  • Las claves candidatas deben ser marcadas como campos de tipo índice único en el gestor de bases de datos.

miércoles, 4 de noviembre de 2020

Tamaño de campos de tipo cadena variables

Un criterio práctico es hacer que el tamaño de los campos de tipo carácter variable (nvarchar, por ejemplo) sea 2n, donde n es un valor dependiente de los requisitos de espacio de dicho campo. Además de establecerse un criterio homogéneo, la principal ventaja de esta norma es la de responder automáticamente a la necesidad de mayor capacidad. Así, en lugar de pasar de 100 a 110 o 150 caracteres ante el requerimiento de mayor espacio, el campo se ampliará de 128 a 256 caracteres, de forma que todo incremento solicitado asegurará un crecimiento del 100% el tamaño actual. Debido a que, como se ha dicho, este criterio se toma para cadenas de caracteres variables, no existirán problemas de memoria.

jueves, 24 de septiembre de 2020

Usa patrones de diseño

Es difícil clarificar el concepto de "patrón de diseño". Los patrones de diseño son básicamente construcciones de código que solucionan problemas comunes en el trabajo con y entre objetos. Para ello, utilizan generalmente el tipo Interface de los lenguajes de programación. La ventaja es que son aplicables a cualquier lenguaje que soporte las características de dicho tipo.

Los patrones de diseño resuelven aspectos como, entre otros:

  • Forzar a que una clase tenga una única instancia global para la aplicación.
  • Crear objetos de una clase u otra según el contexto.
  • Clonar objetos.
  • Adaptar los mensajes de salida de un objeto con los de entrada de otro, sin poder modificar el código de uno de ellos o ambos.
  • Comunicar sucesos entre objetos sin conectarlos directamente.
  • Iterar por todos los objetos de una clase.
  • Permitir deshacer y rehacer acciones de un objeto.
  • Delegar responsabilidades a otros objetos.
  • Componer objetos en grupos.
  • Sustituir dinámicamente el comportamiento de un método invocado.
  • Cambiar la interfaz externa de un objeto no modificable.

        La experiencia en el uso de los patrones de diseño es la que nos dice en qué contexto deben ser utilizados: cuanto antes se conozcan y se dominen, mejor.

Un excelente y bien explicado libro de patrones de diseño puede encontrarse en la bibliografía ([FRE04]).

jueves, 10 de septiembre de 2020

Empieza con lápiz y papel

Por más que hasta los últimos diez años se haya intentado constreñir el proceso de desarrollo de software dentro de patrones ordenados, a veces forzados, la programación es un proceso creativo. Hoy en día parece que se está imponiendo la noción de que los equipos de trabajo competentes no necesitan ceñirse a este tipo de modelos [PAL11]. Como parte de un proceso creativo, plasmar conceptos en un papel siempre será más rápido que el uso de un ordenador. Así, a pesar de tecnologías como e-Readers, procesadores de textos y aplicaciones para organizar la información, el modo más eficiente para desarrollar una idea suele pasar por usar papel y lápiz. Entre otras ventajas, el uso de esta alternativa más rudimentaria consigue clarificar aspectos, promover la adquisición de habilidades, y despertar la curiosidad y el interés por resolver nuevas situaciones [MAR99]. Por otro lado, es más barato y no hay que actualizarlo.

Esta acción es independiente y previa al uso de cualquier metodología de software, y el número de veces que tendremos que rehacer código durante la fase de construcción dependerá en gran medida de la claridad de su resultado. Aunque se espera que la actividad no ocupe mucho tiempo, se aconseja no iniciar el proyecto hasta que no pueda reproducirse mentalmente un primer nivel del diagrama de despliegue que sea realista y cumpla los objetivos, y ser capaz realizar un acercamiento en profundidad de cada componente como si de la pantalla de la película Minority Report se tratara. Apoyarse en técnicas ya conocidas de procesos de desarrollo software puede ayudar.

        Principalmente, es necesario poseer una idea clara de los siguientes elementos:

  • Usuarios objetivos.
  • Alternativas de tecnologías (lenguaje de programación, base de datos, y características de los equipos informáticos y redes de comunicaciones).
  • Información a gestionar.
  • Interfaces de usuario.

Además de eso, la filosofía de la empresa y las características del cliente deben tenerse en cuenta.

Con el tiempo se adquiere cierta habilidad para agilizar este proceso, si bien esto no evita que, una vez empezado el proyecto, haya que reestructurar algunos aspectos del planteamiento de "lápiz y papel", pero esta tendencia será cada vez más baja conforme se va alcanzando experiencia en el desarrollo de aplicaciones.

Una última advertencia: no podemos olvidar que el papel lo aguanta todo. Eso significa que las ideas no deben llegar directamente al cliente, so pena de que luego no sean realizables.

viernes, 22 de mayo de 2020

Sumerge la lógica del sistema

Siempre que sea posible, es recomendable que la lógica del sistema [1] esté a la mayor profundidad posible en la arquitectura del sistema. Esto significa que es mejor hacer que las funciones de la lógica se encuentren en una capa intermedia antes que en la capa de presentación, y que es preferible que las ejecute el sistema de gestión de bases de datos (SGBD) antes que la capa intermedia.

Así como la independencia de la capa de presentación es una convención de las arquitecturas a tres capas, el uso del gestor de bases de datos para mantener la lógica del sistema no suele plantearse como alternativa. No obstante, existen ventajas inherentes a la adopción de esta decisión.

En primer lugar, los gestores de bases de datos tienen su propia capa de seguridad, que no es necesario reinventar en capas intermedias; como contrapartida, dependerá del licenciamiento del gestor para que merezca la pena. Por otro lado, se evitan funciones de la lógica que simplemente hacen de interfaces con el SGBD y que podrían implementarse fácilmente mediante un procedimiento almacenado (práctica que sí es recomendable, en cualquier lugar en el que se encuentre la lógica); en muchos proyectos, la mayoría de los métodos no tienen otra función que la de enviar solicitudes al SGBD y devolver el resultado tal cual. Por último, los recursos empleados para el proyecto disminuyen notablemente, al tratar básicamente la capa de interfaz de usuario y el SGBD.

Sin embargo, no siempre es posible sumergir la lógica del sistema. Generalmente esto se debe las limitaciones de los SGBD y de sus lenguajes de programación: los lenguajes script SQL no suelen ser demasiado amigables para un desarrollo complejo [2]. Por otro lado, sumergir la lógica puede requerir publicar la máquina en la que se encuentra el SGBD, siendo necesaria una capa intermedia para evitarlo y cuya función sería simplemente trasladar la solicitud del usuario al gestor de bases de datos y devolver la respuesta.


[1] Entendemos "lógica del sistema" como la parte de éste donde se encuentran las funciones que resuelven las solicitudes de envío y transformación de datos, y que no son tareas propias de las interfaces de usuario ni de datos.

[2] Microsoft® permite programar su SGDB SQL Server® en lenguajes .NET (C#, por ejemplo). Es una alternativa interesante para sumergir la lógica, aunque supone la dependencia de los sistemas de la empresa.

jueves, 27 de febrero de 2020

Nombrando tablas en singular

No se entrará aquí en describir las diversas batallas sobre el número, singular o plural, que debe ser atribuido al nombre de la tabla, sino que se sugiere aplicar los criterios de representatividad, simplicidad y homogeneidad. ¿De qué sirve que una tabla se declare en plural? ¿Qué aporta que esté en singular? 

Una tabla comprende un conjunto de registros: si almacenamos manzanas, serán múltiples instancias de una manzana; si almacenamos vehículos, contendrá varios vehículos.

Para llegar a una decisión, imaginemos que nuestro sistema gestor de bases de datos guarda información sobre vehículos de cuatro ruedas (y repuesto), de los cuales se pretende almacenar la presión de cada una de las cinco ruedas. Se proponen dos posibles implementaciones: la primera implementación utiliza una tabla para almacenar las ruedas, de manera que cada rueda se corresponde a un registro; en la segunda implementación, se utiliza un registro con cinco campos, uno por cada rueda, más el campo correspondiente para referenciar el al vehículo.

Supongamos ahora que utilizamos el criterio plural para denominar ambas tablas: la primera se denominaría Ruedas, al igual que la segunda, lo cual, a primera vista, no sugeriría diferencia alguna. No obstante, puede plantearse otro criterio, más cercano a las fases de análisis estructurado en el paradigma de orientación a objetivos, en el cual la singularidad o pluralidad se refiere a cuántos componentes del elemento representado contiene una única instancia de éste. En ese caso y en la primera implementación, dado que cada registro (instancia) representa una única rueda, la tabla (o clase equivalente) se llama Rueda; en la segunda implementación, cada registro (instancia) representa a varias ruedas, por lo que la tabla sí se denominaría Ruedas. De esta forma, las consultas de la primera y segunda implementación serían respectivamente de la forma:

SELECT Rueda.Presion [...]

SELECT Ruedas.Rueda1Presion, Ruedas.Rueda2Presion, [...]

Esto resulta más natural y es lo que se recomienda [ROB04], ya que en el primer caso queremos saber la presión de la única rueda del registro (y de ahí el singular), y en el segundo caso tenemos un conjunto de ruedas por registro.

Concluimos diciendo que la justificación del uso del plural bajo el prisma de que una tabla contiene más de un registro no es irrazonable, pero este uso del plural no aporta nada: también podría sostenerse que una clase es una bolsa que contiene a todas sus instancias, teniendo en cuenta que una tabla es a un registro lo que una clase es a un objeto y, en consecuencia, las clases también debería llamarse en plural. El uso del singular, como se ha aconsejado, es más ilustrativo y homogéneo con el paradigma de orientación a objetos y el análisis del dominio del problema.

jueves, 20 de febrero de 2020

Designación de nombres en las bases de datos

La designación de nombres en las bases de datos debe seguir una filosofía similar a la de cualquier denominación que realicemos en el campo de la ingeniería de la información: representatividad, simplicidad y homogeneidad. Partiendo de estas tres premisas y del hecho de que el diseño debe ser comprendido no sólo por su desarrollador, concluir la nomenclatura más óptima para los criterios de nuestra base de datos no es tarea complicada.

Se aconseja:

  •  Para nombrar los campos y las tablas se usará la notación Pascal: palabras directamente unidas y primera letra de cada una en mayúsculas, obviando tildes, determinantes y preposiciones; por ejemplo: Cliente, Valor, TipoDocumento.
  • Asimismo y por claridad, los campos y tablas se nombrarán mediante términos representativos y completos. No se eliminarán vocales ni se recortarán palabras; así, nombres como Vehic, Nmbr, FchNcm no se aconsejan, y sí se hará con Vehiculo, Nombre, FechaNacimiento.
  • Para evitar redundancia, los campos no contendrán ninguna referencia la tabla; esto es, si la tabla se llama Persona y debe contener el DNI, nombre y apellidos, los campos serán Dni, Nombre y Apellidos, pero no campos con aspecto PersonaDNI, NombrePersona o similar.
  • Los nombres de las tablas se escribirán en singular salvo que cada registro comprenda múltiples representaciones del elemento denominado.