Juan Carlos Erazo M. Universidad de San Buenaventura 2012

LOS BUENOS Y LOS NO TAN BUENOS DISEOS DE BASES DE DATOS

BUENOS Y MALOS DISEOSTodo nio es un diseador en potencia, por lo que siempre es mejor mostrarles lo que no se debe hacer que lo que se debe hacer. He aqu una pequea recopilacin de lo que no se debera hacer en diseo de bases de datos. Sin embargo, no olvide que a veces hacer lo que a los ojos de otros no se debe es tan bien una posicin vlida.

10 ERRORES COMUNES1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Diseo/Planeacin pobres. Ignorar normalizacin. Estndares de nomenclatura pobres. Falta de documentacin. Una sola tabla que contenga todos los valores de dominios. Usar columnas GUID como la llave nica. No usar facilidades de SQL para proteger la integridad de los datos. No usar procedimientos almacenados para acceder a los datos. Tratar de construir objetos genricos. Falta de pruebas.

1. DISEO/PLANEACIN POBRES

"If you don't know where you are going, any road will take you there" George Harrison Si no se toma el tiempo suficiente al inicio para obtener el diseo correcto de la BD, entonces encontrar que cualquier cambio sustancial en las estructuras necesita an ms tiempo del proyecto. Hay que reconocer que es imposible predecir cada necesidad que el diseo tendr que cumplir y todos los problemas que probablemente surjan, pero es importante para mitigar los problemas potenciales tanto como sea posible, mediante una planificacin cuidadosa.

2. IGNORAR NORMALIZACIN

La normalizacin se define como un conjunto de mtodos para romper las tablas en sus partes constituyentes hasta que cada una representa una y slo una "cosa", y sus columnas sirven para describir completamente slo la "cosa" que la tabla representa. SQL fue creado para trabajar con estructuras de datos normalizados. La normalizacin no es slo un complot de los diseadores de bases de datos para molestar a los programadores de aplicaciones (que no es ms que un efecto secundario satisfactorio!). La normalizacin de los datos es esencial para un buen rendimiento, y facilidad de desarrollo, pero la pregunta siempre surge: "Qu tanta normalizacin es suficiente?. Si usted ha ledo algn libro sobre la normalizacin, entonces usted habr odo muchas veces que 3era forma normal es esencial, pero las formas normales 4 y 5 son realmente tiles y, una vez que se consigue manejarlas, son muy fciles de seguir y bien vale la pena ponerlas en prctica.

CONTINUACIN

En realidad, es muy comn encontrar que ni siquiera la 1ra forma normal se utiliza bien. Considere este ejemplo:

Existen 12 pagos. El orden es importante? Si alguno es NULL significa que no se pag? Que no se sabe si se pag? Y cmo saber cundo se hizo ese pago? El pago no describe al Customer por lo que no debera estar en la misma tabla! Quizs este diseo sea mucho ms eficiente:

3. ESTNDARES DE NOMENCLATURA POBRES

Los nombres, aunque son de escogencia personal, son la primer y ms importante lnea de documentacin para su aplicacin. Ms all del nombre lo que se debe recalcar es la necesidad de coherencia. Los nombres que eligen no son slo para que usted pueda identificar el propsito de un objeto, sino para que todos, los futuros programadores, usuarios, etc., en forma rpida puedan entender cmo un componente de su base de datos fue diseado para ser utilizado, y que datos almacena. Una prctica no recomendada es el uso de identificadores con comillas o espacios o cualquier otro carcter, como: "Part Number" o [Part Number]. Defina y use su propio estndar, y para mantener la consistencia COMUNQUELO!

4. FALTA DE DOCUMENTACIN

Nombrando cuidadosamente los objetos, columnas y dems, se puede dejar claro para cualquiera, lo que su BD est modelando. En muchos casos quisiera incluir informacin suficiente e incluso ejemplos de la informacin que contienen las tablas y por qu se llego a ese diseo, en caso que en unos aos requiera volver atrs. No es necesario llenar bibliotecas con la documentacin impresa. Las BD permiten almacenar toda la documentacin con cada objeto de la misma.

5. UNA TABLA.. TODOS LOS DOMINIOS

El fundamento de una base de datos relacional es que cada objeto represente una nica cosa. Un gran mito de los arquitectos que no conocen bien las bases de datos relacionales es que entre ms tablas haya ms complejo ser el diseo. Entonces por qu no tener una tabla que lo tenga todo? Considere el siguiente diseo, donde se necesitan dominios para Customer CreditStatus, Customer Type, Invoice Status, Invoice Line Item BackOrder Status, Invoice Line Item Ship Via Carrier

CONTINUACIN

Si se quiere un SQL para obtener los valores del dominio de la tabla Customer.SELECT * FROM Customer JOIN GenericDomain as CustomerType ON Customer.CustomerTypeId = CustomerType.GenericDomainId and CustomerType.RelatedToTable = 'Customer' and CustomerType.RelatedToColumn = 'CustomerTypeId' JOIN GenericDomain as CreditStatus ON Customer.CreditStatusId = CreditStatus.GenericDomainId and CreditStatus.RelatedToTable = 'Customer' and CreditStatus.RelatedToColumn = ' CreditStatusId'

CONTINUACIN..

En vez de eso podramos tener un diseo como este, con su SQL:SELECT * FROM Customer JOIN CustomerType ON Customer.CustomerTypeId = CustomerType.CustomerTypeId JOIN CreditStatus ON Customer.CreditStatusId = CreditStatus.CreditStatusId

Donde los datos pueden validarse de forma natural a travs de las llaves forneas! Ocupan un sola pgina en disco, etc.

6. USAR COLUMNAS GUID COMO LLAVE NICA

La 1ra FN dicta que todas las columnas en una tabla deben ser identificables de forma nica. Por lo que cada tabla debe tener una llave primaria. Algunas BD permiten generar otro tipo de identificadores de forma automtica que pueden convertirse en llaves suplentes (surrogated) y que facilitan la vida al diseador y al programador. Considere la tabla Part, donde PartID es la llave:PartID 1 2 3 PartNumber XXXXXXXX XXXXXXXX YYYYYYYY Description The X part The X part The Y part

CONTINUACINLa tabla tiene 3 filas, pero parece que la 1 y la 2 son la misma. O acaso podran estar incorrectamente identificadas? La regla es la siguiente: si una persona no es capaz de identificar el dato que quiere, sin mirar la llave suplente tendr que reconsiderarse el diseo. Debe haber una nica forma de identificar un registro. Las llaves suplentes solo deben utilizarse en el extrao caso en que no se encuentre una forma de identificar naturalmente un registro.

7. USAR SQL PARA MANTENER LA INTEGRIDAD

Todas las reglas de negocio, que sean fundamentales y que no varen deberan implementarse en el motor relacional. Las reglas que sean opcionales son buenas candidatas para ser implementadas en la capa de aplicacin. Sin importar la ubicacin de la regla de negocio, las tablas que almacenan la informacin de cada regla irn en la base de datos y es posible usar facilidades de SQL o del motor relacional para mantener la integridad. Ej.: CHECK CONSTRAINTS, TRIGGERS, etc.

8. NO USAR PROCEDIMIENTOS ALMACENADOS PARA ACCEDER A LOS DATOSSiempre que sea posible utilice procedimientos almacenados para que los usuarios accedan a los datos almacenados. Los procedimientos almacenados hacen el desarrollo ms limpio y permiten la colaboracin entre los desarrolladores de la base de datos y los de la aplicacin. Los procedimientos deberan utilizarse en general por: mantenibilidad, encapsulacin, seguridad, desempeo.

9. CONSTRUIR OBJETOS GENRICOS

Qu programador no ha soado con hacer un procedimiento que haga lo que sea sobre una tabla cuyo nombre se recibe como parmetro? Sin embargo esto debe ser evitado pues va en detrimento del desempeo. Todos los motores funcionan mejor si usted minimiza el uso de desconocidos y trabajan la mayor parte del tiempo con los mismos planes de ejecucin. Los SQL Dinmicos son una excelente herramienta siempre y cuando no se usen siempre. Preferiblemente cuando haya procedimientos que no sean fciles de optimizar.

10. FALTA DE PRUEBAS

Como profesionales de bases de datos sabemos que lo primero a lo que echan la culpa cuando un sistema est funcionando lento es a la base de datos. Por qu? En primer lugar porque es la pieza central de la mayora sistema empresarial, y en segundo lugar, porque muy a menudo es verdad. Como siempre, el enemigo de las pruebas en el tiempo. Si alguien insistiera en un estricto plan de pruebas del diseo de una BD, muy seguramente algn da, cuando el sistema falle, no mirarn su base de datos como la culpable. Pruebas de poblamiento masivo, pruebas de desempeo de consultas, pruebas de desempeo de inserciones.