.

El Espacio-Tiempo en el Diseño de Base de Datos Transaccionales

El Espacio-Tiempo en el Diseño de Base de Datos Transaccionales

Si estás leyendo este articulo te felicito, pues mis amigos me dijeron Enrique, con ese título la probabilidad que lo leyera primero un astro físico que un ingeniero informático es un 50%, por otro lado escribir sobre el espacio-tiempo a los informáticos haría perder su interés a un 25%, por lo que estadísticamente ya a este momento quedarían 25% de los posibles lectores leyendo, si sigues hasta aquí me alegro, porque formas parte de un pequeño grupo,  también me indicaron, no vayas a poner datos estadísticos, porque estos son aburridos y haría perder un 15% de los lectores, por lo que a estas alturas ya quedarían solo un 10%. Sé que la calidad es escaza y está bien tener este porcentaje, sin embargo a costas de quedarme con solo con el 5% de los posibles lectores, te pondré este ultima estadísticas, en mis más de 22 años en el mundo de TI y de haber participado en innumerables servicios para empresas nacionales e internaciones, sabes ¿cuantas veces he visto una base de datos bien diseñada o que al menos se haya introducido el concepto del espacio-tiempo en sus aplicaciones transaccionales de Base de Datos?, pues ya conocerás la respuesta, claro es 0% (cero). Sé que aun estás allí y me siento satisfecho con este 5%, por lo que te prometo no hablarte de cosas astro físicas ni ponerte más estadísticas.

Este articulo habla del espacio-tiempo, no desde el punto de vista astrofísico o físico, sino desde la perspectiva de los sistemas transaccionales desarrollados en Base de Datos. Desde la primera vez que entre a este mundo de TI, por aquellos tiempos en que aún se escriba código fuente en las tarjetas perforadas (en la década de finales de los 80), recuerdo que en mis clases los profesores enseñaban y me decían que escribir código para computadores era medio ciencia y medio arte o peor aún, más arte que ciencia (este sería un buen título para mi próximo articulo J), a la par cuando analizaba las teorías de Einstein o leía los libros Steven Hawking siempre pensé,  que así como hay principios que rigen las leyes de la física,  también deberíamos tener principios en la ciencia de la computación e informática, pero hasta ahora no he leído algún artículo que hable sobre estos principios, por lo que me dedique a organizar y recopilar algunos principios y llevarlos conmigo en mi experiencia laboral, gracias a estos principios que fueron aplicados a los sistemas transaccionales, a la disciplina y la constancia he podido ser muy asertivo en la solución de problemas complejos.

Uno de los primeros principios que interiorice es que “El sistema debe reflejar la realidad”. Y la realidad indica que casi todos los eventos u hechos suceden en el espacio-tiempo, así por ejemplo cuando nos querremos reunir siempre surgen dos (2) preguntas obvias, la primera es  ¿Cuándo? (Tiempo) y la segunda ¿Donde? (Espacio) estas 2 dimensiones como dice Einstein están entrelazadas y si estos es verdad ¿porque los sistemas transaccionales no tienen estas 2 dimensiones dentro de sus aplicaciones?, mi única respuesta es que es tan obvia que se pasa inadvertido por muchas personas, incluyendo a la mayoría de los ingenieros. En este punto alguien me dirá, pero yo si pongo el tiempo y el espacio es mi sistemas, como por ejemplo en una factura esta la fecha y la dirección en donde se vendió el bien o servicio, ¿con esto estoy reflejando la realidad?, pues le respondo rotundamente que NO. Nos equivocamos en pensar que la fecha (Cuando) de la transacción y la dirección (espacio) son atributos del evento llamado factura, pues está relacionado, pero no le pertenece a la factura, así como el cliente (una entidad) no le pertenece a la factura, sino que se relaciona con esta en un momento determinado en el espacio-tiempo.

 Hablemos del Espacio.

El espacio, representa un lugar físico, que es como se ha dividido políticamente el globo terrestre y depende en función de cada país, en algunos de ellos la tiene la municipalidad, en otros el ayuntamiento o el gobierno local, son ellos quienes tienen la jurisdicción del espacio, por lo que los nombres de los departamentos, provincias, distritos, calles, vías y accesos cambian más a menudo de  lo que uno cree y no dependen de los hechos u eventos de los sistemas informáticos, se relacionan a ellos, pero no como atributos de estos eventos, sino como entidades relacionadas.

Si tuviéramos una entidad (Varias tablas que representaría esta entidad) que almacene el espacio, así por ejemplo podríamos identificar claramente lo siguiente:

En un lugar determinado, se puede ubicar una sucursal de una empresa, en donde viva también un personal  (vigilante permanente o dueño de la empresa) y donde laboren colaboradores que deseen que sus comprobantes les sean entregados en el lugar donde laboren. ¿Que ganamos con esto? Que cuando el ayuntamiento decida cambiarle el nombre de una calle, con solo cambiar el nombre en la entidad del espacio, esta de manera automática cambiaria para todas las entidades que tienen relacionada esta entidad (espacio), asimismo si querremos representar geo-referencialmente la información solo bastaría poner los valores X (longitud) e Y (latitud) en esta entidad para que se pueda representar en un mapa la información que desearemos de manera sencilla.

Por otro lado podríamos aplicar varias funciones de tipo espacial a las direcciones que tenemos como por ejemplo:

- ¿Si está contenido en un área?

- ¿Qué tan cerca estamos de algún local u oferta?

- ¿Cuánta distancia existe entre un punto u otro?

- ¿Qué tanta área se está abarcando en la influencia de compra?

Entre otros ejemplos que podemos hacer a partir de esta información.

 Hablemos del Tiempo.

El tiempo es inalterable y no depende al igual que el espacio de un hecho u evento, avanza, y existe con o sin transacción informática, pues no depende de ella, por lo que se debe representar en los sistemas con una entidad al mismo nivel que un cliente, productos, entre otros (lógicamente y el espacio también).

Por lo que surge la siguiente pregunta ¿Por qué podemos identificar claramente que el cliente es una entidad y el tiempo no?

Base de Datos

¿Qué ventajas ganamos con esto?

1.   Como sabemos, los sistemas permiten guardar datos en las transacciones. no para guardarlos per se, sino principalmente para explotarlos, es aquí donde los sistemas de Inteligencia de Negocio, Business Intelligence, Analytics o Big Data entran en el escenario empresarial, para ello se necesita llevar los mismos datos a un sistema paralelo, mientras que el primero es especializado en transacciones, el segundo especializado en consultas analíticas, la cual llamaremos Data Analytics. En estas soluciones siempre hay un  modelo y en este modelo es fundamental tener una entidad tiempo y otra para el espacio, si en el sistema transaccional existen ambas entidades espacio-tiempo de manera natural, solo nos quedaría crear en el modelo de  Inteligencia de Negocio dichas entidades, esto debido a que ya tendríamos las entidades tiempo y espacio creados de manera transparente. 

2.   Con respecto al espacio, igualmente se pueden hacer consultas muy complejas e interesantes ¿en dónde están nuestros cliente?, ¿en dónde debería poner una sucursal nueva?,  ¿Cuál es el mapa de calor de la deuda?, entre otras. 

Aquí les dejo las funciones existentes en donde se pueden hacer mucho tipo de consultas en SQL Server.

https://msdn.microsoft.com/en-us/library/bb964711.aspx 

• Point 

• LineString 

• CircularString 

• CompoundCurve 

• Polygon 

• CurvePolygon 

• MultiPoint 

• MultiLineString 

• MultiPolygon 

• GeometryCollection 

3.       Se podrían hacer consultas de fechas con filtros extraídos de la entidad Tiempo y de estos a las tablas de hechos de manera sencilla y transparente. Por ejemplo si quisiéramos saber cómo se comportaron las ventas en los fines de semana durante los últimos 6 meses, sería muy sencillo resolver esta consulta con solo ir a la entidad tiempo, la cual tendría un flag activado si ya fecha es fin de semana y extraer los registros para relacionarlos con las transacciones. Sé que los informáticos volamos, por lo que siempre me preguntan ¿Se podrá sacar las ventas de los feriados, seria sencillo poner un flag en la tabla Fecha que tenga el estado feriado y con eso resolveríamos este tipo de consulta?, la respuesta es NO, ya hemos indicado que el sistema debe reflejar la realidad, y la realidad es que no solamente existen feriados nacionales, sino feriados locales y regionales, por lo que para ello se tendrían que elaborar una entidad feriados, la cual represente los distintos feriados que existen y desde aquí extraer las ventas de los respectivos feriados basados en las respectivas zonas (espacio). 

4.       Sacar consultas relacionadas a la en fecha es vital para los sistemas, pero las fechas se pueden expresar de distintas maneras como Semestre, Cuatrimestre, Trimestre, Bimestre, mes del día, día del año,  día del mes, día de la semana, día, cada uno de estos valores con sus respectivas descripciones y además de indicar si es sábado, domingo o fin de semana, entre otros. Y ¿Para qué necesitaríamos descomponer una fecha de esta manera? la respuesta es simple para organizar la información presente en diferentes aspectos de la información correspondiente a la fecha, pero sobre todo para hacer predicciones a futuro, por ejemplo se podría saber cuál será la demanda de este fin de semana de una manera sencilla. 

5.       Reducir el espacio de almacenamiento.

Si analizamos los distintos tamaños que son necesarios para almacenar la información de un dato, podríamos concluir que es más costoso identificar una fecha con un campo de tipo fecha que con un campo de tipo entero (int). Por lo que me permito poner la tabla de las dimensiones de los tipos de datos que existen en el motor de Base de Datos SQL Server, expresados en la siguiente tabla:

 

Tipo de Dato

Capacidad Numérica

Nro. Bytes Utilizados

Numérico

–2^31 (–2.147.483.648) a 2^31–1 (2.147.483.647)

4 Bytes

Date

El tipo de datos dateadmite las fechas en el intervalo del 1 de enero de 01 al 31 de diciembre de 9999 con una precisión de 1 día. El valor predeterminado es el 1 de enero de 1900. El tamaño de almacenamiento es de 3 bytes.

 

4 Bytes

Time

Para los hechos que necesiten almacenar solo la hora se tendría la siguiente tabla para analizar los resultados.

 

Escala especificada

Resultado (precisión, escala)

Longitud de la columna (bytes)

Fracciones

segundos

precisión

time

(16,7)

5

7

time(0)

(8,0)

3

0-2

time(1)

(10,1)

3

0-2

time(2)

(11,2)

3

0-2

time(3)

(12,3)

4

3-4

time(4)

(13,4)

4

3-4

time(5)

(14,5)

5

5-7

time(6)

(15,6)

5

5-7

time(7)

(16,7)

5

5-7

 

 

 

DateTime

1 de enero de 1753 hasta el 31 de diciembre de 9999.

El tipo de datos datetime2 combina el intervalo y la precisión de los tipos de datos date y time en un único tipo de datos.  

 

Los valores predeterminados y los formatos de literal de cadena son los mismos que los definidos en los tipos de datos date y time.

 

8 Bytes

 

Como vemos usar datos de tipo entero tienen un menor espacio que usar datos de tipo DateTime (la mitad). Y usar los campos de tipo date tiene la misma capacidad que el Int, pero con menores posibilidades al ser una entidad contra un atributo.

6.       Problema del fin del año 9999.

Sé que quien lee este articulo y sobre todo quien lo escribe no llegaremos a estar cuando  la humanidad supere el año 9999, (ya vamos por el 2015) por lo que alguna persona me diría, Enrique ¿Por qué te preocupa el fin del año 9999?, a lo cual le respondería que al igual como sucedió el problema informático del año 2000 (PIA2000) en todos los sistemas informáticos del siglo anterior en donde se expresaba la fecha de la siguiente forma AÑO/MES/DIA en el formato 99/99/99, hoy se expresa con 9999/99/99, pero como hemos visto el sistema debe reflejar la realidad, y la realidad será que la humanidad superará el año 9999 (si no se extermina primero de alguna manera, sin embargo es mi firme deseo que lo superaremos) y cuando lo hagamos tendremos un caos informático como lo tuvimos hace 15 años. Por lo que si ponemos poner un identificar a las fechas en lugar de un campo de tipo fecha y que estas se relacionen con la entidad tiempo, seria sencillo que el atributo que contiene la fecha en esta entidad se extienda a 99999/99/99 y todo seguiría continuando sin problema alguno. No dejemos problemas a nuestras futuras generaciones de manera innecesaria, dado que estas últimas se preguntaran ¿en que estuvieron pensando nuestros antecesores cuando diseñaban los sistemas que aparte de no ver las entidades espacio-tiempo, visualizaban sus vidas de manera tan corta? ¿Qué pensaban que la humanidad terminaría antes de llegar al año 9999?

 

Licencia Creative Commons
Esta obra está bajo una Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.