Mdulo

Manual de Buenas Prcticas para el Modelamiento de Datos

TABLA DE CONTENIDOS

31Introduccin

42Antes de modelar, entender bien el problema

43Buenas prcticas

43.1Cumplimiento de estndar

43.2Nombre de tablas y atributos

53.3Referencias y Foreing Key

54Nmero de registros por tablas

55Uso de tipos de datos

55.1Consideraciones generales

65.2Tipos de datos de uso comn

65.3Uso de Dominios

66Creacin de submodelos

67Documentacin de tablas y atributos.

68Atributos de control

79Consideraciones para realizar combinacin (merge) de modelos de datos

710Documentacin de modificaciones al modelo de datos

711Verificacin de modelo de datos

812Ordenamiento de las columnas en tablas hijas

813nfasis en Modelo relacional

814Lgica de negocios en el modelo

815Uso de constraints

1 Introduccin

El presente documento busca ser una ayuda rpida que permita entregar de forma clara y precisa las buenas prcticas que se deben considerar al momento de realizar el modelamiento de datos relacional a travs de la herramienta CASE PowerDesigner.

Es importante sealar que este documento es un complemento del estndar de estructura de datos, y en ningn caso busca ser un reemplazo de ste.

2 Antes de modelar, entender bien el problema

3 Buenas prcticas

3.1 Cumplimiento de estndar

Se debe cuidar de dar cumplimiento en un 100% al estndar definido para estructuras de datos, que entre sus principales puntos establece las reglas para dar nombre a los distintos objetos de la base de datos, entre los cuales destacan las tablas, atributos y restricciones.

3.2 Nombre de tablas y atributos

En el estndar de estructuras de datos se establece :

Los nombres de objetos (tablas, atributos y referencias) deben estar en singular, siempre usando maysculas, excluyendo caracteres especiales (#,$,%,&, /, etc.) y evitando el uso de abreviaciones.

Las tablas paramtricas de estados deben comenzar con el prefijo E_ y las de tipos con el prefijo T_, por ejemplo:

ParaEl nombre ser

Tipo de AdmisinT_ADMISIN

Estado del curso inscritoE_CURSO_INSCRITO

Estado de la postulacinE_POSTULACIN

Tipo de PersonaT_PERSONA

Los nombres de tablas asociativas (creadas a partir de una relacin M:N entre dos tablas) estarn formados por el nombre de la tabla de mayor relevancia seguido del nombre de la segunda tabla. Ser criterio del diseador de la Base de Datos establecer cual tabla tiene mayor relevancia. Los nombres de tablas deben ser representativos de la informacin que contienen, por ello es relevante tener definido de forma clara el concepto de la entidad que se desea modelar como tal. Cada nombre de atributo deber comenzar con un prefijo de 4 caracteres que identifique la tabla a la cual pertenece. En aquellos casos de nombres compuestos se utilizarn a lo ms dos caracteres por cada palabra hasta completar un mximo de seis, de ser mayor se utilizar slo la inicial de cada palabra. Los atributos que referencian tablas paramtricas de tipos o estados deben tener por nombre el prefijo de la tabla seguido del nombre de la tabla a la cual referencian, por ejemplo:

ParaEl nombre ser

Estado de curso inscritoCUIN_E_INSCRICION

Tipo de carreraCARR_T_CARRERA

3.3 Referencias y Foreing Key

Las referencias son las relaciones lgicas entre tablas, las cuales se implementan a nivel fsico de base de datos en restricciones de tipo Foreign Key (clave fornea).

Por defecto el CASE asigna el nombre de la referencia segn el siguiente formato Reference_[NUMEROCORRELATIVO] y para el nombre de la Foreing Key como FK_[TABLAHIJA]_REFERENCE_[TABLAPADRE].

Estos nombres asignados por defecto deben ser modificados segn se indica a continuacin.

Para las referencias:

REF_[TABLAHIJA]_[TABLAPADRE] Y el nombre de la restriccin de y Foreing Key segn lo indica el estndar de estructuras de datos:

FK_[TABLAHIJA]_[TABLAPADRE]

Para ambos casos si el nombre excede los 22 caracteres, se deber considerar 6 caracteres por cada nombre de tabla.

4 Nmero de registros por tablas

Se debe indicar para cada tabla la cantidad de registros que se estima contendr, con el objetivo de posteriormente poder realizar una estimacin del espacio requerido en el almacenamiento para datos para la creacin de los dispositivos fsicos. Los criterios a considerar para indicar la cantidad de registro son:

Contemplar si la tabla contendr informacin histrica que ser migrada.

Proyectar el incremento de registros con una proyeccin de 5 aos como mnimo.

5 Uso de tipos de datos

5.1 Consideraciones generales

Algunas consideraciones importantes de tener en cuanto al momento de definir el tipo de datos de los atributos son:

Para los atributos de cdigo automticos y nmeros correlativos no se utilizar la propiedad IDENTITY de Sybase, la cual ser reemplazada por un atributo del tipo INT, siempre y cuando el nmero mximo del correlativo no supere el valor 2.147.483.647, en cuyo caso se deber optar por ele tipo de dato NUMERIC sin decimales.

Al definir un tipo de datos BIT deber siempre indicarse la condicin de requerido (mandatory) ya que los nicos valores permitidos es 0 o 1, no existiendo la posibilidad del nulo.

Se debe evitar el uso del tipo de dato TEXT y en su reemplazo se debe optar por VARCHAR(255), esto para evitar degradar el rendimiento de las consultas de recuperacin y actualizacin. Slo en aquellos casos en que sea estrictamente necesario por condiciones de diseo se debe usar este tipo de dato.

5.2 Tipos de datos de uso comn

Los tipos de datos que se deben usar en los modelos son los siguientes

5.3 Uso de Dominios

5.4 Consistencia en definicin de atributos idnticos en distintas tablas 6 Creacin de submodelos

Para facilitar la comprensin del modelo de datos, que para algunos sistemas puede contener centenares de tablas, es recomendable la creacin de submodelos, los cuales corresponden a agrupaciones lgicas de tablas (no tienen una correspondencia a nivel fsico en la base de datos).La idea del submodelo es agrupar todas las tablas que son relevantes para un mbito particular del sistema, como por ejemplo CUENTA CORRIENTE, CERTIFICADOS, etc. No existen limitaciones para la creacin de submodelos y es completamente factible que una tabla est presente en ms de un submodelo.

7 Documentacin de tablas y atributos.

Se debe documentar el modelo de datos completo, o sea cada tabla y atributo, en la herramienta CASE completando el campo de descripcin. Adems para aquellos atributos que es relevante conocer con mayor precisin el concepto al cual hacen referencia es importante acompaar la descripcin con ejemplos con el objetivo de clarificar de mejor forma su finalidad. Por ejemplo en la tabla FORMA_MOVIMIENTO de UNIVERSIS est la siguiente descripcin:

FORMA EN LA QUE SE PUEDE EFECTUAR EL MOVIMIENTO, POR EJEMPLO, EFECTIVO, DOCUMENTOS, ELECTRNICA.Para conocer de forma fcil aquellos atributos o tablas que no estn documentados se puede ordenar por el atributo comment en el listado de tablas o atributos que se despliega al seleccionar la opcin Model - Tables o Model Columns del men.

8 Atributos de control

A cada tabla se deber incorpora tres atributos de control para registrar la fecha en que se creo el registro, el usuario y fecha de la ltima actualizacin realizada al registro. Los nombres de estos atributos debern dar cumplimiento a las reglas de nombres de atributos establecidas en el estndar en relacin a incluir el prefijo de la tabla a la cual pertenecen. Los nombres de los campos sern:

XXXX_R_FECHA_CREACION

XXXX_R_USUARIO

XXXX_R_FECHA_MODIFICACION

Donde XXXX corresponde al prefijo que hace referencia al nombre de la tabla.

La fecha de creacin y la identificacin del usuario deben definirse como mandatory, para forzar que siempre se registren.

El tipo de dato asociado al usuario es varchar(20).

9 Consideraciones para realizar combinacin (merge) de modelos de datos

La combinacin de dos modelos de datos habitualmente se requiere cuando se ha terminado de trabajar con la copia local del modelo y es necesario incorporar los cambios dentro del modelo de datos oficial. El trabajar con una copia local tiene como desventaja que los cambios aplicados al modelo de datos oficial no se vern reflejados en la copia local por lo que se estar trabajando con una versin no actualizada. Lo anterior plantea un desafo al momento de realizar la combinacin ya que se debe tener especial cuidado de perder algn cambio vlido del modelo oficial.

Para evitar errores al momento de realizar la integracin es importante tener en cuenta las siguientes consideraciones:

Es conveniente antes de realizar la combinacin generar un respaldo de la versin oficial del modelo de datos que sirva en caso de ser necesario de volver a tras.

Al momento de realizar la combinacin se deben seleccionar en la ventana que muestra las diferencias entre los modelo de datos, slo aquellos cambios que corresponda llevar desde el modelo local al modelo oficial.

Finalizada la combinacin se puede realizar una comparacin contra el respaldo generado previamente y como diferencias deben aparecer slo los cambios que se han aceptado. La lista de cambios debe coincidir completamente con el detalle registrado en el documento Modificaciones al modelo de datos.

10 Documentacin de modificaciones al modelo de datos

Cada vez que se realice una modificacin al modelo de datos se debe incluir el detalle de los cambios en el documento Word modificaciones al modelos de datos en el cual se detallar para cada tabla el cambio realizado de acuerdo a la nomenclatura definida. Las modificaciones deben ser agrupadas asignndole una fecha de cambio que debe corresponder a la fecha en que se validaron o se incluyeron en el modelo de datos oficial.

11 Verificacin de modelo de datos

La herramienta CASE provee la funcionalidad de revisin del modelo de datos (check model) para determinar si cumple con las reglas establecidas por el modelamiento relacional. Esta verificacin entregar como resultado los errores o advertencias detectadas por el CASE, las cuales deben ser evaluadas para determinar su corresponde efectuar correcciones.

En Sybase se debe excluir como un problema del modelo de dato la advertencia de existencia de ndice, pues en la prctica la clave primaria se crea como tal.

12 Ordenamiento de las columnas en tablas hijas13 nfasis en Modelo relacional14 Lgica de negocios en el modelo15 Uso de constraints16 Definicin de estados excluyentes

17 Almacenamiento de Archivos a travs del modelo

18 Control de Acceso: Usuarios y perfiles

19 Generalizacin de conceptos y reutilizacin de entidades20 Uso de redundancia controlada21 Uso de tablas auxiliares22 Dimensionar el impacto de las modificaciones sobre entidades existentesrea de Desarrollo de Sistemas7Direccin de Servicios de Informtica y ComunicacionesAv. Brasil 2950

Pontificia Universidad Catlica de Valparaso

32 273050