25 oct. 2018

Integridad de los datos en SQL Server con CHECKSUM

Uno de los requerimientos importantes son la integridad de los datos, es necesario garantizar que ciertos datos queden fijos después de algún proceso y solo se pueden modificar mediante permisos especiales o un proceso determinado.

Es posible detectar si cambian los datos incluso por un programador que tiene acceso a línea de comandos para escribir sentencias Transact SQL usando la función CHECKSUM de SQL Server. La función CHECKSUM de SQL server devuelve un valor (hash) resultado de aplicar un algoritmo a los datos especificados (columnas). Entonces, basta calcular el CHECKSUM de las columnas que se desea validar que no sean alteradas y posteriormente comparar el valor de esta columna con el nuevo calculo del CHECKSUM, si estos son diferentes significa que fueron alterados.

El video que muestro a continuación da un ejemplo puntual del uso de esta función:





* SQL Server sugiere usar la función HASHBYTES para disminuir la probabilidad de colisión (dos datos distintos dan por resultado el mismo valor hash). En lo particular prefiero CHECKSUM por su facilidad de manejo de valor regresado, el cual es un int, mientras que HASHBYTES regresa un varbinary. Además de que no es importante si existe alguna colisión en los CHECKSUM devueltos. Considerar que el tipo int de Transact es un entero de 4 bytes, el cual tiene un rango de -2^31 a 2^31, esto significa un rango de +4 mil millones de combinaciones, lo cual es bastante bueno.

Optimizando para velocidad con las relaciones uno a uno

Debo aclarar que las relaciones uno a uno, no son una forma 'normal', esto significa que durante un proceso de normalización deberían desaparecer las relaciones uno a uno... excepto cuando se 'desnormaliza' conscientemente por asi convenir, como es este caso.


Problema: Tengo una aplicación de ventas, donde en últimos tiempos el proceso de seleccionar las facturas pendientes de pago se ralentizo considerablemente, llegando hasta un par de minutos. Este proceso consta de una simple consulta de la forma:


Select IDVenta, Fecha, NoDoc, NoDoc, Saldo, Total From TbaVenta Where  (IDCliente=12345) And ((TipoDoc='F') Or (TipoDoc='R') Or (TipoDoc='N') ) And (Afecto<>0) And (Saldo>0)

Esto es, selecciona todas las facturas del cliente 12345 que son Facturas, Remisiones o Notas afectadas y que tiene Saldo.


La columna IDSaldo de la tabla TbaVenta esta indexada, no así las columnas TipoDoc, Afecto y Saldo


En un análisis superficial supuse que si indexaba la columna Saldo el rendimiento mejoraría y asi fue, bajando de 100 hasta 5 segs en mi servidor de pruebas. No conforme con eso busque una alternativa y recurri a un viejo truco... una relación uno a uno, logrando reducir a casi 1/3 del tiempo de ejecución respecto al proceso de indexación anterior, como lo muestro en el video siguiente:






Y aquí tenemos una razón para usar una relación uno a uno!

5 nov. 2014

Bases Distribuidas con SQL Server 2012

Estamos en la recta final de este año 2014 y ha sido de muchas ocupaciones, sin embargo estoy haciendo un esfuerzo por avanzar con el contenido del libro: "Bases de Datos Distribuidas con SQL Server 2012", el cual pretende ser un curso multimedia (Libro+Videos+Certificacion) con el fin de ser el material que acompañe la materia de "Bases de Datos Distribuidas" que se imparte en la mayoria de las universidades para la Carrera de Ing. en Sistemas y afines o para cualquiera que quiera profundizar en la arquitectura distribuida y reafirmar conocimientos generales de bases de datos.


Ya existe un borrador descargable desde hace un año con los primeros 3 capitulos y se puede descargar desde
http://es.slideshare.net/AntonioOrtiz1/curso-bases-de-datos-distribuidas-con-sql-server-2012

Ademas de ser un material de referencia para bases de datos distribuidas, este curso pretende ser una ayuda para reafirmar los conceptos mas importantes del modelo relacional y en general de bases de datos, asi como de alguna funcionalidad de SQL Server.
Anexo el contenido del curso, el cual es possible que cambie mientras se elabora:
BASES DE DATOS DISTRIBUIDAS CON SQL SERVER 2012

Dirigido a: Programadores, Analistas de Sistemas, Administradores de Sistemas, Estudiantes y Profesores que deseen aprender a diseñar e implementar un modelo de base de datos distribuida.
Deseable: Conocimientos de bases de datos, SQL.
Requisitos: Haber cursado o cursar alguna carrera relacionada a la informática o tener conocimientos basicos en bases de datos.
CONTENIDO:
I. Introducción al modelo relacional
  • De Sequel a SQL Server
  • Bases de Datos Relacionales
  • Manejadores de Bases de Datos Relacionales
  •  SQL
  •  Arquitectura Cliente-Servidor
  
II. Instalación y Configuración de SQL Server 
  • Instalación Manual
  • Configuración de Instancias
  • Administrador de Configuración (Configuration Manager)
III. Administración de SQL Server
  • SQL Server Management Studio
  • Separar y Adjuntar bases de datos
  • Respaldos
  • Compactar
  • Importar Datos
IV. Diseño de Bases de Datos
  • Diseño Conceptual
  • Diseño Lógico
  • Diseño Físico
  • Modelo relacional
  • Modelos E-R
  • Normalización
 V. Arquitectura de SQL Server
  • Archivos de datos
  • Archivo de transacciones
  • Grupos de archivos
  • Páginas de Datos
  • Índices Clustered
  • Índices Non clustered
VI. Transact SQL
  • Diagramas
  • DDL
  • Consultas
  • SubConsultas
VII. Vistas
  • Vistas
  • Vistas Indexadas
VIII Bases de Datos Distribuidas
  • Descripción
  • Características de una base de datos distribuidas
  • Ventajas
  • Desventajas
  • Creando un modelo de base de datos distribuidas

IX. Consultas Distribuidas
  • Servidores vinculados
  • Consultas distribuidas
  • Transacciones Distribuidas

X. Procedimientos Almacenados (Stored Procedures) y Funciones
  • Procedimientos del Sistema
  • Procedimientos del Usuario
  • Funciones del Sistema
  • Funciones del Usuario
  • SQL Dinámico vs Procedimientos Almacenados
XI. Desencadenadores (Triggers)

XII. Replicación
  • Publicador
  • Suscriptor
  • Réplica de instantáneas
  • Réplica transaccional
  • Replicación de Mezcla

25 ago. 2014

Relaciones en bases de datos

Cuando aprendemos el modelo relacional, el cual es el mas conocido en teoría de datos; normalmente se nos enseña que existen 4 tipos de relaciones:
  • Uno a uno (1 a 1)
  • Uno a muchos (1 a N)
  • Muchos a muchos (N a M)
  • Muchos a uno (N a 1)
Lo que pocas veces se nos explica claramente es que el modelo relacional solo es válido durante la fase de diseño del modelo conceptual, que nos permite documentar y definir un modelo de datos solo a nivel de concepto, así pues, no todos los tipos de relaciones del modelo relacional son válidos para un modelo de base de datos lógico o físico. Pasamos a explicar lo anterior:


Relación uno a uno (1 a 1)

 Las relaciones uno a uno No deben existir en una base de datos pues eso denota inmediatamente que se hizo un mal trabajo de normalización. Ya que cada tabla representa una entidad de la base de datos. Una relación uno a uno, significaría que cada tabla es 'media' entidad o dos tablas representan un asunto o entidad. Lo correcto seria fusionar las columnas de las dos tablas en una sola.
Siendo poco estrictos es verdad que existen relaciones uno a uno en situaciones especiales (desnormalización planeada) por convenir así; por ejemplo: si un campo de una tabla se actualiza constantemente y queremos disminuir el riesgo de colisión en bloqueos, se puede aislar ese campo en una tabla que lo contenga y esté relacionado con una llave primaria idéntica a la llave primaria de la primera tabla.

Tabla normalizada
Producto
* ID
Codigo
Descripcion
Costo
Precio
UltVenta


Tabla desnormalizada con relación uno a uno
Producto
* ID
Codigo
Descripcion
Costo
Precio

Producto2
* ID
UltVenta


Concluimos que una relación uno a uno No es una relación normal y comúnmente no debería existir en una base de datos.



Relaciones uno a muchos (1:N)

Las relaciones uno a muchos son las mas comunes y en realidad es la 'única' relación válida para una base de datos, así; un Cliente puede tener muchas Facturas, una Población tiene muchos Clientes y una Venta puede incluir muchos Productos.


Relaciones muchos a muchos (N:M)
Las relaciones muchos a muchos definitivamente son un tipo de relación que no existen en una base de datos por una simple razón... son imposibles de implementar a menos que se haga un terrible trabajo de diseño y por supuesto de normalización, ya que implicaría que un mismo registro se repitiera para cada relación.
Por ejemplo, para un Producto hay muchos Proveedores y para un Proveedor hay muchos Productos.
Este tipo de relaciones solo se implementa de manera eficiente si se crea una tabla intermedia que relaciona ambas entidades, para este caso crearíamos la tabla ProductoProveedor de la siguiente manera:
ProveedorProducto
* IDProducto
* IDProveedor
A este tipo de Entidades se les conoce como Entidades débiles, ya que no representan un asunto u objeto de la realidad que intentan resolver. Dicho sea de paso, este tipo de Entidades son las únicas que llegan a cuarta o quinta forma normal.
En el modelo físico las relaciones muchos a muchos se descomponen en relaciones uno a muchos a uno.

Relaciones muchos a uno (N:1)
Bueno, este tipo de relaciones solo es importante en el modelo conceptual, ya que en el modelo lógico y físico, normalmente da la misma distancia de ida que de vuelta, es muy sencillo deducir que es la misma relación 1 a muchos vista desde la derecha.
 Las relaciones muchos a uno se tratan de una relación uno a muchos vista desde el otro lado.

* Recomiendo estudiar de manera independiente las 3 etapas del diseño de bases de datos, iniciando por el modelo conceptual, pasando al modelo lógico y finalizando con el diseño físico definido por el manejador de base de datos a utilizar.

Al llegar al modelo físico es importante comprender y utilizar adecuadamente las reglas de normalización, así como hacer un análisis correcto de cuando es conveniente saltarse alguna regla por ser conveniente a la funcionalidad del sistema o manejo de datos.

Conclusión: Siendo estrictos y siguiendo al pie de las letra las reglas de normalización, nos quedamos con la relación uno a muchos, y eliminamos la relación muchos a uno simplemente moviendo la tabla inicial de la relación a la izquierda y cambiando la relación por uno a muchos



22 oct. 2013

Reunion de Comunidad .NET Tepic

Este martes 22 de Octubre tendremos la reunión de Comunidad .NET dentro del marco de la semana de Ciencia y Tecnología; el CETIS 100 ha tenido a bien proporcionarnos el auditorio para nuestra reunión de comunidad. Hay gran entusiasmo entre los miembros de la comunidad, alumnos y profesores que esperan esta serie de conferencias orientadas al tema de la educación.
 
Durante esta serie de conferencias se mostrarán productos Microsoft que facilitan el proceso de aprendizaje relacionado a la programación y las TICs en general, además el material y cursos gratuitos online.

Durante el transcurso de las conferencias se realizaran demostraciones practicas en el uso de los diferentes productos mostrados. Por ejemplo, para el tema de bases de datos se mostrara como realizar consultas aun servidor remoto desde consola o desde el Management Studio, incluso se realizara una consulta distribuida.



La sede es:


CETIS 100
Puerto Rico 39,
Col. Miravalles
Tepic, Nay, Mexico.