Este documento establece estándares para el diseño y nomenclatura de bases de datos. Define reglas para nombrar bases de datos, tablas, campos, constraints y otros objetos de base de datos de manera consistente y descriptiva. El objetivo es asegurar la legibilidad, portabilidad y calidad del modelo de datos.
0 calificaciones0% encontró este documento útil (0 votos)
495 vistas18 páginas
Este documento establece estándares para el diseño y nomenclatura de bases de datos. Define reglas para nombrar bases de datos, tablas, campos, constraints y otros objetos de base de datos de manera consistente y descriptiva. El objetivo es asegurar la legibilidad, portabilidad y calidad del modelo de datos.
Este documento establece estándares para el diseño y nomenclatura de bases de datos. Define reglas para nombrar bases de datos, tablas, campos, constraints y otros objetos de base de datos de manera consistente y descriptiva. El objetivo es asegurar la legibilidad, portabilidad y calidad del modelo de datos.
Este documento establece estándares para el diseño y nomenclatura de bases de datos. Define reglas para nombrar bases de datos, tablas, campos, constraints y otros objetos de base de datos de manera consistente y descriptiva. El objetivo es asegurar la legibilidad, portabilidad y calidad del modelo de datos.
Generacin de Consultas ....................................................................... 15
Fecha de actualizacin:
19/02/14
Pgina:
: 3 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 4 de 18 Fecha:28/04/2014
1. Introduccin A lo largo del ciclo de vida de desarrollo de un software es necesario asegurar la calidad del mismo. Uno de los instrumentos que facilitan esta tarea es la adopcin de estndares de base de datos. Consideramos que la adopcin de estndares en el diseo de bases de datos, tiene muchas ventajas, entre ellas: Asegurar la legibilidad del modelo de datos, inclusive para personas que no estn relacionadas con el ambiente informtico, en etapas de anlisis y diseo. Facilitar la portabilidad entre motores de bases de datos, plataformas y aplicaciones. Facilitar la tarea de los programadores en el desarrollo de sistemas. Es este sentido que los objetos (tablas, campos, procedimientos almacenados, Triggers, etc.) de base de datos a construirse deben cumplir con ciertas caractersticas que detallaremos en el presente documento.
2. Objetivos Establecer el estndar de Base de datos a ser aplicado en todos los desarrollos de Sistemas de TechEra, buscando de esta forma que todos los sistemas que se desarrollen cuenten con caractersticas similares a pesar que sean desarrollados para empresas diferentes. La redaccin de normas para garantizar el acoplamiento de elementos construidos independientemente, garantizando la calidad de los objetos construidos y la seguridad de funcionamiento y que cumplan con: Simplificacin: Se trata de reducir los modelos existentes quedndonos nicamente con nuestro estndar. Unificacin: Para permitir la intercambiabilidad a nivel Empresarial.
Especificacin: Se persigue evitar errores de identificacin creando un lenguaje claro
y preciso.
Fecha de actualizacin:
19/02/14
Pgina:
: 4 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 5 de 18 Fecha:28/04/2014
3. Estndar de Nomenclaturas 3.1 Nombre de Base de Datos El nombre de la base de datos debe representar el propsito de la misma finalizando con el sufijo BD. No necesariamente debe tener el nombre del sistema al que est asociado. Ejemplos: - InventarioBD - VentasBD - SismeBD
3.2 Tablas El nombre de las tablas deben cumplir las siguientes caractersticas:
Se debe eliminar los espacios en blanco y poniendo los nombres en
nomenclatura Pascal Casing. Nota: La nomenclatura Pascal Casing est compuesta por tantas palabras como sean necesarias. La primera letra de cada una de las palabras ir siempre en maysculas. Se obvia el uso de artculos.
nicamente se utilizarn caracteres alfabticos, salvo que por la naturaleza del
nombre se necesiten dgitos numricos. Se prohbe el uso de puntuacin o smbolos.
Los nombres deben de especificarse en singular y completos (evitar en lo posible
abreviaturas, salvo que sea necesario por la naturaleza del nombre de la tabla). Ejemplo de nombres de tablas:
PlanCuenta (plan de cuenta)
Modelo (Modelo)
Familia (Familia)
En el caso de tablas detalle, sta debe llamarse como la tabla padre, seguida de la palabra Detalle. Ejemplo de nombres de tablas detalle:
Fecha de actualizacin:
FacturaDetalle (Detalle de Factura)
TablaMaestraDetalle (Detalle de Tabla Maestra)
19/02/14
Pgina:
: 5 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 6 de 18 Fecha:28/04/2014
Los nombres sern en espaol.
En caso de que alguna tabla se relacione especficamente con otra, esta relacin debe quedar expresada en el nombre y separada con un guin abajo (_). Ejemplo de nombre de tablas de relacin:
Almacen_Servicio (Almacn servicio),
Almacen_Producto (Almacn producto)
Los nombres de las tablas deben ser entendibles y fcil de relacionar con el objeto al que identifican.
Se har uso de esquemas, poniendo el nombre del esquema seguido de un punto
y finalmente el nombre de la tabla. Ejemplo de tablas con esquemas:
COMPRAS.Uit
RRHH.Empleado
Las letras acentuadas se reemplazarn con las equivalentes no acentuadas, y en
lugar de la letra () se utilizar (ni). Ejemplo: -
AnioNacionalidad
Cotizacion.
3.3 Campos
El nombre de los campos debe iniciar con un prefijo (4 caracteres) relacionado al
nombre de la tabla al que pertenece, seguido de un guin abajo (_) y el nombre del campo.
Los nombres de campos deben de especificarse en singular y con nomenclatura
Pascal Casing.
Al igual que en las tablas, los nombres de campos utilizarn caracteres
alfabticos evitando caracteres especiales.
Los nombres deben ser lo ms descriptivos posible para identificar rpidamente el
dato a que hace referencia.
El nombre no debe abreviarse, salvo por algn caso particular, como por ejemplo que el nombre sea demasiado grande.
Fecha de actualizacin:
19/02/14
Pgina:
: 6 de 18
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 7 de 18 Fecha:28/04/2014
Software Factory
Si por alguna razn es necesario separar las palabras del nombre del campo, deber hacerse a travs de un guin bajo (_).
Los nombres debern escribirse en espaol.
Ejemplos de nombre de campos:
Prod_Codigo (Cdigo del producto)
Empr_Descripcion (Descripcin de la empresa)
Vent_TipoPago (tipo de pago de la tabla Venta)
Pers_FechaNacimiento (fecha de nacimiento de la tabla Persona)
Los campos de tipo booleano deben escribirse con una palabra que tenga un significado verdadero o falso o en forma de pregunta. Por ejemplo no se debe usar la palabra estado en un campo booleano. Ejemplos de campos booleanos:
Prod_Estado (incorrecto, estado=true o estado=false no me dice nada)
Prod_Activo (correcto, activo=true o activo=false si se entiende)
Usua_EsAdmin (correcto, EsAdmin=true o EsAdmin=false si tiene sentido)
Para las tablas que requieran campos de auditora se deben considerar los siguientes
campos:
UsuarioCreacion,
UsuarioEdicion,
FechaCreacion,
FechaEdicion. Ejemplos de campos de auditora de la tabla Venta: -
Vent_UsuarioCreacion (NOT NULL)
Vent_UsuarioEdicion
Vent_FechaCreacion (NOT NULL)
Vent_FechaEdicion
3.4 Constraints
Los constraints son las limitaciones o restricciones dadas a los atributos o campos de una tabla. Los ms comunes son: asignar a un campo o atributo la restriccin de ser llave primaria, llave fornea (que proviene de otra tabla relacionada), que el campo no sea nulo, que el campo sea nico, etc. a. Llave Primaria Cuando la llave primaria es un solo campo la sintaxis debe ser la siguiente:
Fecha de actualizacin:
19/02/14
Pgina:
: 7 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 8 de 18 Fecha:28/04/2014
TipoConstraint_NombreTabla Donde: NombreTabla: Nombre de la tabla a la cual es asignado el constraint. TipoConstraint: PK (primarykey)
Ejemplo: -
PK_Area
Cuando la llave est conformada por ms de un campo, la estructura ser la
misma que la anterior. b. Llave Fornea Los campos de relacin como la llave fornea deben de especificarse con la siguiente sintaxis: TipoConstraint_NombreTablaDestino_NombreTablaOrigen Donde: NombreTablaDestino: Nombre de la tabla a la cual es asignado el constraint. NombreTablaOrigen: Nombre de la tabla de donde proviene la llave foranea. TipoConstraint: FK (foreing key)
Ejemplos: -
PK_Provincia_Departamento
c. ndices
El nombre de los ndices deben tener la siguiente sintaxis:
NombreTabla_NombreCampo_ [#] Donde: NombreTabla: Nombre tabla donde se cre el ndice. NombreCampo: Nombre del campo de ncide creado. #: Numero consecutivo de ndice realizado sobre la tabla.
Ejemplos:
Fecha de actualizacin:
Venta_FechaVenta_1
Almacen_Stock_2
19/02/14
Pgina:
: 8 de 18
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 9 de 18 Fecha:28/04/2014
Software Factory
3.5 Funciones El nombre de las funciones debe tener la siguiente sintaxis: UFN_NombreFuncion
Dnde: UFN: indica que el objeto es una funcin. Acrnimo de user function. NombreFuncion: es el nombre de la funcin en Pascal Casing.
Ejemplos: -
UFN_CalcularImpuesto
UFN_DescripcionMes
3.6 Triggers El nombre de los triggers debe tener la siguiente sintaxis: TRG_NombreTabla_NNN Donde: TRG: indica que el objeto es un trigger. Acrnimo de Trigger. NombreTabla: es el nombre de la tabla donde se cre el trigger. NNN: indica que tipo de trigger (INS: Insert, UPD: Update, DEL: Delete).
Ejemplos: -
TRG_Compra_INS
TRG_Producto_DEL
3.7 Procedimientos Almacenados
Para los procedimientos almacenados no se utiliza debe utilizar el prefijo SP, ya que es un error puesto que "SP" significa SystemProcedure y no StoreProcedure por lo que no se debe considerar como prefijo vlido. El nombre de los Procedimientos Almacenados debe tener la siguiente sintaxis: USP_NombreTabla_NNN Dnde: USP: indica que el objeto es un Procedimiento Almacenado. Acrnimo de user stored procedure
Fecha de actualizacin:
19/02/14
Pgina:
: 9 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 10 de 18 Fecha:28/04/2014
NombreTabla: nombre de la tabla que va a trabajar el procedimiento
almacenado. NNN: es el identificativo de la accin del procedimiento almacenado. -
INS: indica que es una insercin.
DEL: indica que es una eliminacin.
UPD: indica que es una actualizacin.
SEL: indica que es una seleccin de un registro por la llave primaria.
LIS: indica que es una consulta de registros.
RPT: indica que es una consulta para un reporte.
Ejemplos: -
USP_ Programacion_INS
USP_ Producto_SEL
USP_ Inventario_RPT
En los casos que el procedimiento almacenado realiza una accin especfica que no necesariamente est asociada a las operaciones bsicas de una tabla se usar la sintaxis: USP_NombreProcedimientoAlmacenado Ejemplos: -
USP_GenerarConsolidado
USP_ProcesarCostos
3.8 Vistas
Los nombres de las vistas siguen las mismas convenciones que los nombres de las tablas. Se recomienda utilizar el prefijo VW. Ejemplos: -
Fecha de actualizacin:
VW_Alumnos
19/02/14
Pgina:
: 10 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 11 de 18 Fecha:28/04/2014
4. Estndar de Diseo En ste apartado se van explicar las principales consideraciones para el diseo de base de datos, estructura de codificacin del transact-SQL y buenas prcticas.
4.1 Collation de Base de Datos
A la hora de generar nuestra Base de datos, vamos a elegir el siguiente collation: SQL_Latin1_General_CP1_CI_AS Salvo que por cuestiones de diseo debamos elegir un collation diferente.
4.2 Encabezado de scripts
Todos los scripts (procedimientos almacenados, funciones, etc.) deben contar con un encabezado, el cual permite conocer de manera clara de que se trata el mismo. Se deben considerar los siguientes datos en la generacin de los encabeczados: -
Autor: Persona que cre el script.
Fecha Creacin: fecha de creacin del script.
Descripcin: descripcin de lo que hace el script
Parmetros de Entrada: En ste punto no es obligatorio comentar todos los
parmetros si no parmetros que sean poco entendibles.
Parmetros de Salida: Detallar los parmetros de salida.
Modificado por: Persona que modific el script
Fecha Modificacin: fecha de modificacin.
Ejemplo de ejecucin:
Ejemplo: ---------------------------------------------------------------Autor: Juan Perez -Fecha Creacin: 20/04/2013 -Descripcin: Consulta de Trabajadores por Area ---------------------------------------------------------------- Parmetros de Entrada -@Area_Codigo char(2): Cdigo del rea del trabajador -- Parmetros de Salida -Listado de Trabajadores ---------------------------------------------------------------- Modificado por: -- Fecha Modificacin: ---------------------------------------------------------------- Ejm. ejecucin: EXEC USP_Trabajador_LIS_PorArea '01' ---------------------------------------------------------------
Fecha de actualizacin:
19/02/14
Pgina:
: 11 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 12 de 18 Fecha:28/04/2014
4.3 Tablas y Campos
Todas las tablas creadas deben tener llave primaria, de preferencia deben ser un nmero entero automtico y en lo posible que dicha llave primaria est conformada por una nica columna.
Se deben definir correctamente los tipos de datos que se van a almacenar. Cabe mencionar que de preferencia no se deben utilizar las columnas del tipo text o ntext, varbinary, etc. Ejemplos de tipo de datos: -
Si el dato es una fecha, no se debe utilizar el tipo DATETIME sino el tipo
DATE.
Si el dato es un nmero ao, mes o da no se debe utilizar el tipo INT sino
el tipo SMALLINT o TINYINT.
Si una tabla contiene una cantidad limitada de registros y la llave principal
es del tipo entero se debe utilizar el tipo SMALLINT o TINYINT segn corresponda.
4.4 Variables de Tipo Tabla y Tablas Temporales
Cuando se desea almacenar temporalmente cierta cantidad de registro (de
preferencia que no excedan de los 50000) se debe utilizar una variable tipo tabla, considerando todos los estndares y buenas prcticas de una tabla normal, a excepcin de la nomenclatura de los constraints. De preferencia siempre debe utilizarse una llave primaria y la cantidad de columnas de una variable tipo tabla debe ser la menor posible, considerando slo campos clave o con tipos de datos de tamao bien restringido. Por Ejemplo: DECLARE @TBL_CREDITOS_CAMPANIA AS TABLE ( NRO_CREDITO INT NOT NULL, COD_CLIENTE VARCHAR(15) NOT NULL, MONTO DECIMAL(16,2) NOT NULL, PRIMARY KEY (NRO_CREDITO) );
Asimismo puede hacer uso del comando WITH para la creacin de tablas en memoria. Recuerde que siempre antes de iniciar el comando WITH debe existir
Fecha de actualizacin:
19/02/14
Pgina:
: 12 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 13 de 18 Fecha:28/04/2014
un punto y coma (;) delante de este, adicionalmente solo es permitido un
comando WITH por consulta o procedimiento.
Por ejemplo: ;WITH TBL_CREDITOS_CAMPANIA AS ( SELECT NRO_CREDITO, COD_CLIENTE, MONTO FROM PR.PR_CREDITOS (NOLOCK) WHERE COD_CAMPANIA = 001 AND IND_ESTADO = A ) SELECT NRO_CREDITO, COD_CLIENTE, MONTO FROM TBL_CREDITOS_CAMPANIA
Cuando se desea almacenar temporalmente una cantidad elevada de registros
(mayor a 50000) se debe utilizar una tabla temporal la cual debe empezar con el prefijo # o ## segn el mbito, asumiendo todas las propiedades y requerimientos de una tabla normal, a excepcin de la nomenclatura de los constraints. Estas tablas siempre estarn almacenadas en la base de datos TEMPDB. Por ejemplo: CREATE TABLE ##TBL_CREDITOS_CAMPANIA ( NRO_CREDITO DECIMAL(10) NOT NULL, COD_CLIENTE VARCHAR(15) NOT NULL, MONTO DECIMAL(16,2) NOT NULL, PRIMARY KEY (NRO_CREDITO) );
SELECT NRO_CREDITO, COD_CLIENTE, MONTO INTO ##TBL_CREDITOS_CAMPANIA FROM PR.PR_CREDITOS (NOLOCK) WHERE COD_CAMPANIA = 001 AND IND_ESTADO = A
Todas las tablas temporales deben ser limpiadas o eliminadas antes de su
creacin, para esto utilizar el siguiente comando previamente a la creacin de la tabla temporal.
Fecha de actualizacin:
19/02/14
Pgina:
: 13 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 14 de 18 Fecha:28/04/2014
Por ejemplo: IF OBJECT_ID(TEMPDB..##TABLA_TEMPORAL) IS NOT NULL DROP TABLE ##TABLA_TEMPORAL
4.5 Procedimientos Almacenados
Los Procedimientos Almacenados, Funciones definidas por el usuario y
Disparadores (triggers) siempre deben empezar con la clusula BEGIN y terminar con la clusula END. Por ejemplo: CREATE PROCEDURE [Nombre_Procedimiento] ( [Nombre_Parametro] [TIPO_DATO] [, ] ) AS BEGIN (Instrucciones T-SQL)
END GO
Las clausulas SET NOCOUNT ON y SET NOCOUNT OFF deben ir establecidas
dentro del procedimiento al inicio y final respectivamente, dentro de las clausulas BEGIN y END, a fin de eliminar la notificacin del Nro. de registros afectados por cada sentencia T-SQL lo cual elimina un trfico innecesario de confirmacin del procedimiento. Por Ejemplo: CREATE PROCEDURE [Nombre_Procedimiento] ( [Nombre_Parametro] [TIPO_DATO] [, ] ) AS BEGIN SET NOCOUNT ON (Instrucciones T-SQL)
SET NOCOUNT OFF
END
El nombre de los parmetros deben ser iguales al nombre de los campos de las tablas que va a manipular. Por ejemplo: Se tiene la siguiente tabla:
Fecha de actualizacin:
19/02/14
Pgina:
: 14 de 18
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 15 de 18 Fecha:28/04/2014
Software Factory
CREATE TABLE Persona (
Pers_Codigo int, Pers_Nombre varchar(100), Pers_Activo bit )
El procedimiento almacenado de insercin sera el siguiente:
CREATE PROCEDURE USP_Persona_INS @Pers_Codigo int, @Pers_Nombre varchar(100), @Pers_Activo bit AS BEGIN SET NOCOUNT ON; INSERT INTO Persona( Pers_Codigo, Pers_Nombre, Pers_Activo ) VALUES ( @Pers_Codigo, @Pers_Nombre, @Pers_Activo ) SET NOCOUNT OFF; END
4.6 Generacin de Consultas
Para la escritura de cdigo SQL utilizar maysculas para las sentencias o
palabras reservadas propias del SQL
Por ejemplo: SELECT Cli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno, Cli_Edad FROM CLIENTE (NOLOCK) ORDER BY Cli_ApellidoPaterno Utilizar el Tabulador para separar los campos de una condicin indentando el cdigo para que sea siempre claro.
Todas las consultas deben contener el hint (NOLOCK) a un lado del nombre de la tabla que se est consultando. A excepcin de cuando las circunstancias ameriten lo contrario.
Fecha de actualizacin:
19/02/14
Pgina:
: 15 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 16 de 18 Fecha:28/04/2014
La declaracin de variables dentro de un procedimiento, funcin o disparador
debe ser consecutiva y se debe separar las variables por comas. Por ejemplo: DECLARE
Para la asignacin de masiva de datos a variables dentro de un procedimiento o
funcin se debe utilizar la instruccin SELECT y se debe separar cada asignacin por comas de variables. Caso contrario cuando sea una asignacin nica puede utilizar el comando SET. Por ejemplo: SELECT
Nunca se deben utilizar funciones dentro de la clusula WHERE relacionados a
una columna debido a que afecta a los ndices asociados a la tabla y disminuye el rendimiento de la consulta. Por ejemplo: Mala prctica SELECT Cli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno FROM CLIENTE (NOLOCK) WHERE YEAR(Cli_FechaRegistro) = 2013 La consulta correcta sera: SELECT Cli_Codigo, Cli_Nombre , Cli_ApellidoPaterno, Cli_ApellidoMaterno, FROM CLIENTE (NOLOCK) WHERE Cli_FechaRegistro BETWEEN 01/01/2013 AND 31/12/2013
Nunca deben utilizarse subconsultas correlacionadas para extraer un valor de
otra tabla, dado que esto tiene el mismo impacto de utilizar una funcin de usuario dentro de la consulta.
Fecha de actualizacin:
19/02/14
Pgina:
: 16 de 18
Software Factory
Cdigo o Nombre del Proyecto
Versin 1.0
Estndar de Base de Datos
Pgina 17 de 18 Fecha:28/04/2014
Por ejemplo: Mala prctica SELECT Nro_Credito Cod_cliente, Nombre = (SELECT nombre FROM CLIENTE WHERE Cod_cliente = CREDITO.Cod_Cliente), Direccion_Casa = (SELECT direccion FROM DIRECCION_CLIENTE WHERE Cod_cliente = CREDITO.Cod_Cliente) AND TipoDireccion = C FROM CREDITO (NOLOCK) La consulta correcta sera: SELECT A.Nro_Credito A.Cod_cliente, B.Nombre, C.Direccion FROM CREDITO A (NOLOCK) INNER JOIN CLIENTE B (NOLOCK) ON A.cod_cliente = B.cod_cliente INNER JOIN DIRECCION_CLIENTE C (NOLOCK) ON A.cod_cliente = C.cod_cliente AND C = C.TipoDireccion
Cuando se desee consultar ms de una tabla siempre se deben utilizar alias para facilitar la escritura de consulta. Todas las columnas deben tener el alias respectivo.
No se debe utilizar el hint TOP y menos en subconsultas correlacionadas, en vez
