Estándar SQL v1.0

ESTNDAR DE PROGRAMACION PARA SQL
Actualizacin: 1.0
Autor: Centro Experto WEB
Direccin de Servicios de Desarrollo
Estndar SQL v1.0
Pg. 1 de 31
Contenido
1. REVISIONES.............................................................................................................................. 4
2. INTRODUCCIN........................................................................................................................ 5
2.1.
RESUMEN .......................................................................................................................................... 5
2.2.
PROPSITO ....................................................................................................................................... 5
2.3.
ORGANIZACIN DE ESTE DOCUMENTO ....................................................................................... 5
2.4.
DOCUMENTOS RELACIONADOS..................................................................................................... 5
3. ESTANDAR SQL ....................................................................................................................... 6

3.1. CONCEPTOS PREVIOS: FORMAS NORMALES.............................................................................. 6
3.1.1
PRIMERA FORMA NORMAL ...................................................................................................... 6
3.1.2
SEGUNDA FORMA NORMAL ..................................................................................................... 7
3.1.3
TERCERA FORMA NORMAL...................................................................................................... 8
3.1.4
CUARTA FORMA NORMAL ........................................................................................................ 8
3.1.5
QUINTA FORMA NORMAL ......................................................................................................... 9
3.2. NOMENCLATURA ............................................................................................................................ 10
3.2.1
GENERALIDADES..................................................................................................................... 10
3.2.2
NOMBRES DE TABLAS ............................................................................................................ 10
3.2.3
NOMBRES DE VISTAS ............................................................................................................. 10
3.2.4
NOMBRES DE CAMPOS .......................................................................................................... 11
3.2.5
NOMBRES DE CLAVES PRIMARIAS....................................................................................... 11
3.2.6
NOMBRES DE NDICES ........................................................................................................... 11
3.2.7
NOMBRES DE CLAVES FORNEAS....................................................................................... 12
3.2.8
NOMBRES DE PROCEDIMIENTOS ALMACENADOS ............................................................ 12
3.2.9
NOMBRES DE DESENCADENADORES.................................................................................. 13
3.2.10 NOMBRES DE VARIABLES...................................................................................................... 13
3.2.11 NOMBRES DE RESTRICCIONES ............................................................................................ 13
3.2.12 NOMBRES DE TIPOS DE DATOS............................................................................................ 13
3.2.13 NOMBRES DE PARMETROS DE PROCEDIMIENTOS ALMACENADOS ............................ 13
3.3. CONVENCIONES PARA LA PROGRAMACIN DE T-SQL ............................................................ 14
3.3.1
DOCUMENTACIN ................................................................................................................... 14
3.3.2
INDENTACIN .......................................................................................................................... 15
3.3.3
DECLARACIN DE VARIABLES .............................................................................................. 16
3.3.4
MANEJO DE TRANSACCIONES Y ERRORES........................................................................ 16
3.4. NORMAS DE DISEO Y PROGRAMACIN ................................................................................... 17
3.4.1
NORMALIZACIN DEL MODELO............................................................................................. 17
3.4.2
CLAVE PRIMARIA ..................................................................................................................... 17
3.4.3
CLAVES CANDIDATAS............................................................................................................. 17
3.4.4
TABLAS ASOCIATIVAS ............................................................................................................ 18
3.4.5
USO DE INTEGRIDAD REFERENCIAL.................................................................................... 18
3.4.6
SEGURIDAD Y PERMISOS ...................................................................................................... 18
3.5. DISEO DE MODELOS DE DATOS ................................................................................................ 19
3.5.1
MAPEO DE CLASES A TABLAS............................................................................................... 20
3.5.1.1
MAPEO DE RELACIONES 1 A 1 ....................................................................................... 20
3.5.1.2
MAPEO DE RELACIONES 1 A N....................................................................................... 21
3.5.1.3
MAPEO DE RELACIONES N A N ...................................................................................... 21
3.5.1.4
MAPEO DE RELACIONES N-ARIAS ................................................................................. 22
Estndar SQL v1.0
Pg. 2 de 31
3.5.1.5
3.5.1.6
3.5.1.7
3.5.1.8
3.5.1.9
3.5.1.10
3.6.
MAPEO DE CLASES ASOCIATIVAS................................................................................. 23

MAPEO DE AGREGACIN ............................................................................................... 23
MAPEO DE COMPOSICIN.............................................................................................. 24
MAPEO DE HERENCIA ..................................................................................................... 24
MAPEO DE ENUMERACIONES ........................................................................................ 25
MAPEO DE TIPOS DE DATOS (ESTRUCTURAS) ........................................................... 26
APNDICE 1: CONVERSIN DE TIPOS DE DATOS SQL A .NET................................................. 27
3.7. APNDICE 2: MODELO DE EJEMPLO ........................................................................................... 28

3.7.1
MODELO CONCEPTUAL .......................................................................................................... 29
3.7.2
MODELO DE DATOS ................................................................................................................ 30
3.8.
REFERENCIAS Y RECURSOS ........................................................................................................ 31
Estndar SQL v1.0
Pg. 3 de 31
1.
REVISIONES
Versin
Responsable
Fecha
Descripcin del cambio
1.0
Centro Experto Web
10-10-2005
Primera versin del documento.
Estndar SQL v1.0
Pg. 4 de 31
2.
INTRODUCCIN
2.1.
RESUMEN
Se desarrolla la gua de estilo para el modelado de bases de datos y programacin en SQL de aplicaciones
dentro del mbito de proyectos de Repsol YPF.
Incluye normas de programacin y recomendaciones para el buen desarrollo de aplicaciones.
Salvo los aspectos generales y que se especifique lo contrario, este documento aplica a bases de datos
sobre Microsoft SQL Server.
2.2.
PROPSITO
Establecer un marco general para el desarrollo y mantenimiento de software que facilite la incorporacin de
las personas a los proyectos y que consiga homogeneizar nuestros desarrollos as como promover y difundir
el uso de las mejores prcticas.
Simplificar el mantenimiento de bases de datos y artefactos relacionados - procedimientos almacenados,
desencadenadores, etc.
Facilitar la comunicacin entre analistas y desarrolladores, ya que ocasionalmente se utilizan diagramas de
entidad-relacin (DER) como parte de la documentacin de un sistema.
2.3.
ORGANIZACIN DE ESTE DOCUMENTO
El documento est organizado de la siguiente manera:
Esta introduccin, donde se establece el propsito del documento, su organizacin y documentos

relacionados.
Un captulo sobre las formas normales. Este captulo contiene aspectos tericos, pero cuya
aplicacin tiene gran impacto prctico en la calidad de las bases de datos.
Nomenclatura establece la normativa para nombres de los distintos elementos que se pueden
encontrar en la base de datos. El contenido de este captulo es de aplicacin obligatoria.
El captulo 4, Convenciones para la programacin de T-SQL, establece lineamientos para la

programacin de cdigo T-SQL: procedimientos almacenados, desencadenadores, funciones, etc.
Aunque las indicaciones mencionadas en este captulo no son fcilmente comprobables, ya que
interviene mucho el sentido comn y el criterio de cada uno, deben considerarse obligatorias.
Las Normas de diseo y programacin establecen la estructura de la base de datos, y es de

aplicacin obligatoria.
Diseo de modelos de datos explica como trabajar con modelos de datos desde un punto de vista
orientado a objetos, ya que hoy en da el anlisis se realiza mayormente utilizando tcnicas de
orientacin a objetos. Esta seccin es obligatoria para todo aquel proyecto con orientacin a objetos.
Finalmente, una serie de apndices centralizan informacin de referencia.
2.4.
DOCUMENTOS RELACIONADOS
Gua general de estndares de programacin.
Estndar SQL v1.0
Pg. 5 de 31
3.
ESTANDAR SQL
3.1.
CONCEPTOS PREVIOS: FORMAS NORMALES
Una correcta normalizacin del modelo de datos minimiza la posibilidad de inconsistencias, lo cual simplifica
el desarrollo y facilita el mantenimiento.
En este captulo se describen las 5 formas normales, que se deben tener en cuenta al momento de disear
un modelo de datos.
3.1.1 PRIMERA FORMA NORMAL
Un modelo de datos en primera forma normal no tiene atributos multi-valor ni grupos de repeticin (conjunto
de columnas al mismo efecto).
El documento est organizado de la siguiente manera:
Ejemplo:
Tabla con campo multi-valor:
Proveedor
CP IdProveedor
234
IdRepresentantes
567,235,678
Tabla con grupo de repeticin (IdRepresentante1, IdRepresentante2,

IdRepresentante3:
Proveedor
IdRepresentante2
235
IdRepresentante3
678
Al aplicar los requisitos de la primer forma normal a estos ejemplos, se obtiene:
RepresentanteProveedor
CP IdProveedor CP IdRepresentante
234
567
234
235
234
678
Estndar SQL v1.0
Pg. 6 de 31
3.1.2 SEGUNDA FORMA NORMAL

Un modelo de datos est en segunda forma normal cuando est en primera forma normal y adems, para
todas sus tablas, todos los campos no integrantes de la clave primaria son totalmente dependientes de la
clave.
Ejemplo:
En la tabla ValoracionCompetencia, IdEmpleado y IdCompetencia componen la clave
primaria
ValoracionCompetencia
CP IdEmpleado
CP IdCompetencia
78
34
Nombre
Prez
Competencia
Progr. TSQL
Valor
8
El campo Nombre del empleado no depende de toda la clave primaria, sino solo de
IdEmpleado. Competencia es un campo que solo depende de IdCompetencia.
Al aplicar los requisitos de la segunda forma normal, se obtienen 3 tablas
separadas, a saber:
Empleado
CP IdEmpleado
78
Competencia
CP IdCompetencia
34
Nombre
Prez
Competencia
Progr. TSQL
CP IdCompetencia
34
Estndar SQL v1.0
Valor
8
Pg. 7 de 31
3.1.3 TERCERA FORMA NORMAL

Un modelo de datos est en tercera forma normal cuando est en segunda forma normal y adems, para
cada una de sus tablas, no existen dependencias transitivas entre sus campos.
La tercera forma normal prohbe las dependencias transitivas. Una dependencia transitiva existe cuando
cualquier atributo en una tabla es dependiente de otro campo y ste es quien depende de la clave primaria.
Ejemplo:
La tabla Provincia no est en tercera forma normal.
Provincia
CP IdProvincia
336
CE IdPais
78
Nombre
Buenos Aires
NombrePais
Argentina
El campo NombrePais depende de IdPais, el cual es el campo que realmente depende

de la clave primaria. Por ello, el campo NombrePais debe ser quitado y colocado en
otra tabla:
Pais
CP IdPais
78
Provincia
CP IdProvincia
336
Nombre
Argentina
CE IdPais
78
Nombre
Buenos Aires
Dividiendo los datos en 2 tablas, la dependencia transitiva es removida.
3.1.4 CUARTA FORMA NORMAL

Una tabla est en cuarta forma normal cuando est en tercera forma normal y no representa dos o ms
relaciones de tipo muchos a muchos independientes entre s.
La cuarta forma normal es violada generalmente cuando se utiliza una tabla de tres columnas para
representar dos relaciones independientes entre s.
Ejemplo:
Supongamos que necesitemos implementar el ABM de Puestos:
Puesto
CPCE IdEmpleado
78
CPCE IdUnidadOrganizativa
12
CPCE IdFuncion
34
En este caso, necesitamos poder listar los empleados que pueden trabajar en una
unidad organizativa y tambin las funciones que pueden ser desempeadas en una
unidad, a fin de crear una relacin para expresar que un empleado ejecuta una
funcin en cierta unidad organizativa. Esta informacin debera estar almacenada
en la base de datos.
Si eligisemos una estructura similar a la tabla Puesto para almacenar los datos
mencionados en el prrafo anterior, estaramos incumpliendo la cuarta forma
normal, ya que esta nueva tabla representara dos relaciones: Empleado Unidad
Organizativa y Funcion Unidad Organizativa.
Estndar SQL v1.0
Pg. 8 de 31
3.1.5 QUINTA FORMA NORMAL

Una tabla est en quinta forma normal cuando est en cuarta forma normal y no es posible reconstruir su
informacin mediante un conjunto de tablas con menos columnas.
Ejemplo:
Continuando con el ejemplo anterior, si adems de las relaciones mencionadas
deberamos representar una ms, entre Empleado y Funcion, la nueva tabla estara
en cuarta forma normal, ya que todas las relaciones ya no son independientes entre
s. Sin embargo, la tabla puede descomponerse en tres tablas, una por cada
combinacin de entidades: Empleado Unidad Organizativa, Funcion Unidad
Organizativa y Empleado Funcion.
Estndar SQL v1.0
Pg. 9 de 31
3.2.
NOMENCLATURA
Se describen los criterios generales relacionados con la forma de nombrar los distintos elementos de SQL.
3.2.1 GENERALIDADES
A continuacin se describen pautas bsicas de nomenclatura de los objetos posibles de encontrar dentro de
una base de datos (procedimientos almacenados, tablas, vistas, etc.).
Algunos puntos a tener en cuenta:
Los nombres de las entidades, procedimientos, etc. deben de perdurar a lo largo de la vida del
software, esto es, desde la etapa de concepcin hasta la de implementacin y mantenimiento.
Los nombres deben ser mnemotcnicos y relacionados con los nombres de las entidades del mundo
real, siempre que las restricciones tcnicas no nos lo impidan. Es necesario mantener un balance
entre la expresividad del nombre y su longitud; en general, no deber superar los 30 caracteres.
Los nicos caracteres permitidos son los comprendidos en los rangos 0-9, A-Z, a-z, _ (guin bajo).
Por ende no pueden utilizarse vocales acentuadas, ni espacios.
3.2.2 NOMBRES DE TABLAS

Siempre se debern designar las tablas con nombres hagan referencia a la entidad del diagrama conceptual
que le dio origen.
El nombre de la tabla deber ser en lo posible un sustantivo en singular, y se emplear la notacin Pascal.
Ejemplo:
La implementacin una tabla que permite almacenar las competencias en un sistema
empresaria tendra como nombre Competencia.
En el caso de las tablas asociativas (tablas cuya finalidad es vincular otras tablas), el nombre deber hacer
referencia a la naturaleza de la relacin. Tambin es aceptable concatenar los nombres de las tablas
asociadas separndolas por un guin bajo, siempre y cuando la naturaleza de la asociacin sea evidente.
Ejemplo:
Considerando que un proveedor puede tener varios representantes y que una persona
puede ser representante de varios proveedores, la relacin entre Proveedor y
Persona se llamara RepresentanteProveedor.
3.2.3 NOMBRES DE VISTAS

La misma nomenclatura aplicada para los nombres de tablas, aplica para los nombres de las vistas, pero se
plantean algunas excepciones:
1. Las vistas no siempre representan una entidad simple. Una vista puede ser la unin de varias tablas
por una operacin de JOIN, por lo que representa los datos de dos o ms entidades. En este caso es
viable considerar la concatenacin de nombres de las entidades, aunque se recomienda utilizar un
nombre representativo del resultado de la vista. Por ejemplo, si una vista combina los datos de las
tablas Persona y Competencia, la vista podra denominarse PersonaCompetencia, o tal vez
CompetenciasDePersona.
2. Las vistas pueden totalizar informacin de tablas en forma de reportes de datos. En este caso, el
nombre de la vista deber reflejar la situacin para hacer comprensible su funcin. Un ejemplo de
esto, podra ser una vista que totalice las ventas de un ao determinado. Un nombre de ejemplo para
esta vista podra ser VentaDeProductosTotalizada2003.
Estndar SQL v1.0
Pg. 10 de 31
3.2.4 NOMBRES DE CAMPOS

Los nombres de los campos de una tabla deben ser representativos de lo que contienen, sin ser
extremadamente largos, pero aprovechando la facilidad que brindan los motores de bases de datos actuales
de dar a los objetos nombres significativos.
Todos los campos sern nombrados usando capitalizacin Pascal, sin guiones bajos ni separadores de
ningn tipo.
El nombre de los campos ID se obtendr, para el caso de las claves primarias, concatenado el prefijo Id
con el nombre de la tabla siempre que sea posible1. En el caso de claves forneas, el nombre deber ser
representativo de la naturaleza de la relacin, y tambin deber estar prefijado por la cadena Id. Esta regla
se aplica tanto para tablas que representan entidades como para tablas que representan relaciones.
Ejemplo:
Entre los campos de la tabla que registra los equipos de la compaa podemos
encontrar un campo que implementa la relacin entre un equipo y su propietario:
Equipo
Columna
IdPropietario
Descripcin
ID del empleado responsable por el equipo.
Nota: Estos nombres debern ser iguales a los nombres de variables que se usen en
el cdigo durante la construccin de las aplicaciones. En lenguajes no-tipados, al
declarar las variables, se seguir las normas de nomenclatura especficas de cada
lenguaje, anteponiendo el prefijo de tipo si es necesario.
3.2.5 NOMBRES DE CLAVES PRIMARIAS

La nomenclatura para las restricciones de clave primaria es:
PK_NombreDeTabla_NombreDeCampoID
Ejemplo:
La restriccin de clave primaria que se aplica a la columna IdProvincia de la
tabla Provincia se llama PK_Provincia_IdProvincia.
3.2.6 NOMBRES DE NDICES

Los nombres de los ndices deben representar como mnimo:
el nombre de la tabla sobre la que se crea,
los campos involucrados,
si son unique o no.

La nomenclatura a usar es:
[IX|UX]_NombreDeTabla_NombresDeCampos
Ejemplo:
El nombre del ndice unique de la tabla Pais sobre el campo Nombre sera:
UX_Pais_Nombre
1 Se permiten excepciones a esta regla siempre que sea razonable, por ejemplo la convencin del nombre
de campo clave primaria en el caso de la implementacin de la herencia (ver Mapeo de Herencia).
Estndar SQL v1.0
Pg. 11 de 31
3.2.7 NOMBRES DE CLAVES FORNEAS

Las claves forneas (Foreign Keys) son utilizadas para representar relaciones entre tablas. Una clave
fornea puede ser considerada como un vnculo entre la columna de una tabla y la clave primaria de una
tabla referida.
FK_TablaReferente_CampoTablaReferente_TablaReferida_CampoTablaReferida
Ejemplo:
La relacin entre Equipo y Empleado debe llamarse
FK_Equipo_IdPropietario_Empleado_IdEmpleado.
Las claves forneas pueden ser compuestas. En estos casos, se incluirn los nombres de las sucesivas
columnas en el nombre de la clave. Esto puede generar un nombre de clave muy extenso, pero esto no es
preocupante, ya que nunca se har referencia a este nombre desde cdigo fuente.
3.2.8 NOMBRES DE PROCEDIMIENTOS ALMACENADOS
Los procedimientos almacenados se utilizan como punto de acceso a la informacin, ya sea para realizar
consultas o para manipular los datos.
Los nombres de procedimientos deben describir la accin que realizan, por lo cual se utilizar un verbo
representativo de la accin en cuestin.
La nomenclatura general a usar es:
PrefijoDeSistemaOModulo_NombreRepresentativo
donde PrefijoDeSistemaOModulo es una cadena de pocos caracteres (en lo posible no ms de cuatro)

representativa del sistema, subsistema o mdulo al cual el procedimiento pertenece. En particular, debe
evitarse el uso del prefijo sp, ya que SQL Server trata a los procedimientos almacenados que comienzan
con este prefijo de manera especial; al ejecutarse una llamada, si el nombre del procedimiento almacenado
comienza con sp, SQL Server busca primero en la lista de procedimientos almacenados predefinidos, lo
cual impacta en el desempeo.
Hay una enorme variedad en las posibles acciones, pero hay algunas que se utilizan con mucha frecuencia y
afectan a entidades puntuales: insercin, seleccin, modificacin y borrado. En este caso, el
NombreRepresentativo del procedimiento se compondr de la siguiente manera:
NombreEntidad_Accin
donde Accin es una de las siguientes: Select, Delete, Update, Insert.

Ejemplo:
Se necesita escribir un procedimiento almacenado para el Sistema Empresarial que
retorne la lista de empleados que tienen tres o ms equipos a cargo. En este caso,
un nombre de procedimiento sugerido sera:
se_ListadoEmpleadosSobreequipados
Ejemplo:
Debe escribirse un procedimiento almacenado que permita insertar nuevas funciones
a la base de datos. El nombre debe ser:
se_Funcion_Insert
En el caso de los procedimientos que seleccionan datos de las tablas con algn criterio, es conveniente que
por se indiquen los campos que se utilizaran en la seleccin, siempre que estos no sean demasiados.
Ejemplo:
Obtencin de datos de un equipo a partir de su nmero de serie:
se_EquipoPorNumeroSerie_Select
Estndar SQL v1.0
Pg. 12 de 31
3.2.9 NOMBRES DE DESENCADENADORES

Los nombres de los desencadenadores (triggers) deben representar las operaciones ante las cuales se
activan.
TR_NombreDeTabla_Propsito_[INS|UPD|DEL]
Ejemplo:
El nombre del trigger para evitar insertar una fecha de pedido errnea en la tabla
Pedido sera:
TR_Pedido_FechaPedido_INS
Esto es a modo ilustrativo, ya que dicho trigger podra representarse como una
restriccin (ver seccin 3.11).
3.2.10 NOMBRES DE VARIABLES

La declaracin de variables dentro de los SP deber seguir en reglas generales la nomenclatura establecida
para los nombres de los campos de las tablas. Por restricciones del lenguaje deber tener como prefijo el
smbolo @.
3.2.11 NOMBRES DE RESTRICCIONES
Se aplica la siguiente convencin:
CK_NombreDeTabla_Propsito
Si la restriccin se aplica a una sola columna, en lugar del propsito debe indicarse el nombre de la columna:
CK_NombreDeTabla_NombreDeColumna
3.2.12 NOMBRES DE TIPOS DE DATOS

Se aplica la siguiente convencin:
dtNombre
3.2.13 NOMBRES DE PARMETROS DE PROCEDIMIENTOS ALMACENADOS

Se aplica la misma convencin que para las variables. Adicionalmente, si el parmetro se corresponde a una
columna de una tabla, debe tener exactamente el mismo nombre, tipo de datos y longitud.
Estndar SQL v1.0
Pg. 13 de 31
3.3.
CONVENCIONES PARA LA PROGRAMACIN DE T-SQL
A continuacin se describen aspectos convenidos para una comunicacin eficiente, las cuales van ms all
de buenas prcticas, las cuales se describen en su propio documento.
3.3.1 DOCUMENTACIN
Para un buen control de los Stored Procedures y Triggers, y a fin de registrar la resolucin de problemas en
los fuentes se ha establecido que todos los Stored Procedures y Triggers debern tener asociado un
encabezado que documente su utilidad y parmetros, excepto que la utilidad sea obvia (esto es muy claro en
los casos Insert, Update y Delete). El formato del encabezado es el siguiente:
/*
* (C) REPSOL YPF 2005
* Proyecto:
XXXXXXXXXX
* Descripcin: XXXXXXXX
*
* (resto de encabezados)
* (opcional: parmetros)
* (opcional: historial de versiones)
*/
Aquellos Stored Procedures y Triggers generados por aplicativos debern inclur obligatoriamente el
encabezado (este no agrega costo alguno para el desarrollador y el impacto es casi nulo), indicando la
versin del generador y fecha de generacin, de la siguiente manera:
Generado por NOMBRESISTEMA (vN.N) el DD/MM/YYYY
Esta documentacin obligatoria est acompaada de buenas prcticas, para lo cual se deber consultar el
documento respectivo.
Estndar SQL v1.0
Pg. 14 de 31
3.3.2 INDENTACIN
A fin de establecer un estndar de legibilidad se opt por fijar el estilo de indentacin, el cual es resultado del
anlisis de buenas prcticas de cdigo y experiencias. Como estndar es obligatorio salvo que se posea una
justificacin que impida su aplicacin, la cual deber ser oportunamente comunicada y documentada.
Bloques de cdigo
Cada bloque de cdigo deber estar indentado del anterior en una tabulacin
IF a>b
SELECT A, B FROM C
IF (a>b) THEN
BEGIN
SELECT A, B FROM C
END
ELSE
BEGIN
SELECT D, E FROM F
END
WHILE (a>b)
BEGIN
//instrucciones
END
Cuando una instruccin ocupa ms de una lnea, las lneas siguientes debern estar indentadas de
la primera en al menos una tabulacin. Aquellas instrucciones (como Select, Insert, Update o Delete)
que poseen varias clusulas o partes las cuales no pueden ser utilizadas fuera de estas
instrucciones debern ir a la misma altura que la instruccin original. En estos casos deber dejarse
la lnea con la palabra clave (SELECT, FROM, WHERE, HAVING, GROUP BY, VALUES) sla en la
lnea. Ej:
SELECT
Persona.IdPersona
Persona.Nombre,
Persona.Apellido
FROM
Persona
WHERE
Persona.Edad > 15
La regla tambin es de aplicacin obligatoria en las declaraciones de Stored Procedures

CREATE PROCEDURE nnnnnn
(@Param1 tipoDato1,
@Param2 tipoDato2,
@ParamN tipoDatoN)
AS
//...Cuerpo Del Stored Procedure...
Estndar SQL v1.0
Pg. 15 de 31
3.3.3 DECLARACIN DE VARIABLES

Las variables locales debern estar declaradas como primeras instrucciones en el Stored Procedure.
3.3.4 MANEJO DE TRANSACCIONES Y ERRORES
Para cada operacin o Stored Procedure que deba ser ejecutado en forma atmica (es decir, todo o nada) y
posea ms de una instruccin, el mismo deber utilizar indefectiblemente transacciones. Adems deber
verificarse indefectiblemente en las operaciones que modifiquen datos el estado de la variable de sistema
@@ERROR, la cual deber ser asignada a una variable local previo a su verificacin, para evitar la prdida
del nmero de error. Ej:
INSERT INTO NombreTabla
//...resto del Insert
SELECT @Error = @@Error
IF (@Error <> 0) GOTO ErrorHandler
Estndar SQL v1.0
Pg. 16 de 31
3.4.
NORMAS DE DISEO Y PROGRAMACIN
En este captulo se detalla una serie de puntos que deben cumplirse de manera obligatoria en todo diseo e
implementacin realizado por la DSD o bajo su supervisin.
3.4.1 NORMALIZACIN DEL MODELO
Toda base de datos debe estar en quinta forma normal.
Si fuese necesario desnormalizar algunas tablas a fin de solucionar problemas de desempeo, debern
documentarse las mediciones realizadas para probar que el problema de desempeo existe y que la
desnormalizacin propuesta realmente soluciona dicho problema.
3.4.2 CLAVE PRIMARIA
Toda tabla debe tener definida una clave primaria.
Toda tabla que no sea puramente asociativa debe definir su clave primaria sobre una y solo una columna de
tipo INTEGER (lo cual permite identificar 2147483647 registros de utilizarse slo los nmeros positivos o el
doble incluyendo los negativos). Esta columna no debe tener ningn significado desde el punto de vista del
negocio. El nombre de esta columna se compone concatenando el prefijo Id con el nombre de la tabla en
cuestin. La excepcin a esta regla son aquellas tablas en una relacin IS-A cuya clave primaria podr ser
la clave primaria de la tabla padre.
Las justificaciones son las siguientes:
Las claves candidatas son voltiles. Las claves candidatas se definen de acuerdo a criterios de
negocio, los cuales siempre estn sujetos a modificaciones. Si las relaciones de integridad
referencial entre tablas se realizan entre claves candidatas (de negocio), cualquier cambio a la clave
primaria tiene impacto en la estructura y los datos de las dems tablas relacionadas. El costo de este
cambio puede ser muy alto.
Los datos son voltiles. Si el valor de los campos de la clave candidata es ingresado por personas,
existe la posibilidad de introducir errores. Si un error de datos que afecta a la clave primaria se
detecta cuando ya hay registros asociados, la actualizacin puede ser un proceso complejo.
Las claves candidatas pueden tener varias columnas. Esto implica que las operaciones de JOIN son
ms complejas de escribir y entender, y tambin que su desempeo es inferior. Adems produce un
efecto de arrastre en cascada de campos de clave, lo que puede derivar en tablas con ms campos
de clave primaria que de dato propiamente dicho.
Existen otras consideraciones, tales como redundancia de datos, mayor complejidad de las
aplicaciones que utilizan la base de datos, etc.
Debe tenerse en cuenta la recomendacin explicada en Campos Autonumricos (Identity).
3.4.3 CLAVES CANDIDATAS
Para el conjunto de campos que de otra forma hubiera sido elegido para conformar la clave primaria (as
como para todas las claves candidatas) debe crearse un ndice nico (unique index). Esto garantiza que sea
posible identificar unvocamente un registro a partir de la clave candidata definida por el negocio.
Ejemplo:
En la tabla Empleado debe crearse un ndice nico sobre el campo Legajo.
Estndar SQL v1.0
Pg. 17 de 31
3.4.4 TABLAS ASOCIATIVAS

Una tabla es puramente asociativa cuando:
su propsito es implementar una relacin N a N o una asociacin N-aria,
no contiene ningn campo aparte de las claves primarias de las tablas relacionadas,
no existen relaciones entre la tabla asociativa y otras entidades (aparte de las involucradas en la
asociacin).
En este caso, la clave primaria est compuesta por todas las claves forneas involucradas, o sea que abarca
todas las columnas de la tabla asociativa.
3.4.5 USO DE INTEGRIDAD REFERENCIAL
Toda relacin entre entidades en el modelo conceptual debe estar representada como una restriccin de
integridad referencial en el modelo de datos.
Esto protege la integridad de los datos almacenados en la base.
3.4.6 SEGURIDAD Y PERMISOS
La aplicacin que hace uso de la base de datos deber acceder mediante un usuario con las siguientes
caractersticas:
Poseer los mnimos privilegios necesarios para acceder a la base de datos.
No tendr permiso de escritura ni de lectura sobre las tablas.
No tendr permiso de alteracin de la estructura de la base.
Solo contar con permiso de ejecucin de los procedimientos almacenados y acceso de solo lectura
a las vistas que conforman la capa de acceso a los datos de la aplicacin. Esto implica que toda
modificacin a los datos desde el exterior de la base de datos debe hacerse a travs de
procedimientos almacenados.
Las premisas expuestas anteriormente tienen incidencia en las aplicaciones transaccionales. Aquellas
aplicaciones que deban hacer un uso extensivo de consultas ad hoc (por ejemplo, aquellas aplicaciones que
provean un servicio de tablas pivot), y dichas consultas no puedan ser representadas mediante
procedimientos almacenados (por su carcter dinmico) debern utilizar un usuario con los mnimos
permisos para garantizar la funcionalidad de lectura, y realizar las actualizaciones a travs de
procedimientos almacenados, utilizando otro usuario slo con permisos de ejecucin de dichos
procedimientos.
Estndar SQL v1.0
Pg. 18 de 31
3.5.
DISEO DE MODELOS DE DATOS
Existen numerosas metodologas para realizar el anlisis y diseo de sistemas. Cada una de ellas
ayuda a determinar, de una forma u otra, el modelo de datos correspondiente a la implementacin.
Cuando la metodologa est basada en casos de uso y es orientada a objetos, se utiliza UML como
notacin en los diagramas que presentan el modelo del problema y/o solucin desde distintos puntos de
vista. En particular, el diagrama de clases presenta la vista estructural o esttica del sistema (en el sentido
de que no se modela el comportamiento), mostrando las distintas entidades con sus atributos y relaciones.
Uno de los primeros productos que se obtiene en la etapa de anlisis es el modelo de dominio2 UML de
anlisis, es decir, un modelo donde aparecen las entidades de negocio junto a sus atributos y relaciones.
Este modelo, junto un glosario, definen las entidades que forman parte de los procesos de negocio. En este
modelo no se consideran aspectos de diseo de objetos de negocio ni implementacin, es decir, no se
definen mtodos ni clases de soporte.
El modelo de dominio contiene una parte importante de la informacin requerida para definir el modelo de
datos, ya que determina las tablas necesarias y sus relaciones.
Dependiendo del detalle del modelo conceptual, puede que estn definidos todos los atributos de cada clase,
aunque es frecuente que solo se encuentren aquellos arquitecturalmente importantes; los atributos de las
clases determinan los campos de las tablas. Muy frecuentemente, ser necesario determinar el tipo de datos
de cada campo, y en todos los casos ser necesario especificar su tamao. Como parte del diseo debern
completarse estos datos faltantes.
Si bien hay mucha informacin til en el diagrama de clases UML, es necesario realizar una adaptacin de
impedancia ya que ciertos conceptos existentes en UML no tienen una contraparte directa en DER.
Siguiendo esta lnea de pensamiento, tambin es posible realizar la operacin inversa: inferir el modelo UML
que dio origen a un DER.
Este captulo explica como realizar esta adaptacin a fin de disear un modelo de datos a partir de un
modelo de dominio UML (o en sentido contrario).
2 El modelo de dominio en UML es el producto del anlisis de las entidades de negocios y sus respectivos
atributos. Contiene slo informacin al negocio (es decir, no contiene informacin de implementacin).
Estndar SQL v1.0
Pg. 19 de 31
3.5.1 MAPEO DE CLASES A TABLAS

En el caso ms general, por cada clase persistente del modelo conceptual se obtiene una tabla con el mismo
nombre, que tiene una columna ID de acuerdo a lo explicado en el captulo de normativas.
Adicionalmente, por cada atributo de la clase que no sea derivado (calculado a partir de otros) se obtiene
un3 campo en la tabla.
Deber tenerse en cuenta la conversin de tipos de datos, prestando atencin al tamao de los mismos
(INTEGER no es lo mismo que TINYINT). En el apndice 1 hay referencias a tablas de conversin de tipos
de datos SQL a .NET.
Ejemplo:
Implementacin de la clase Persona.
Persona
Persona
Nombre
DNI
CP
IdPersona
Nombre
DNI
3.5.1.1 MAPEO DE RELACIONES 1 A 1

Las relaciones 1 a 1 pueden representarse de dos maneras:
Haciendo que la clave primaria de una tabla sea tambin clave fornea de la otra.
Configurando en una de las dos tablas una columna que sea clave fornea, apuntando a la otra
tabla, y creando un ndice nico sobre ese campo.
De estas dos maneras, se prefiere la segunda, ya que se utiliza la primera para representar la herencia.
Ejemplo:
Cada persona tiene a lo sumo una Ficha Mdica. En este caso se ilustra la segunda
variante de implementacin.
Empleado
1
FichaMedica
Legajo
CP
IdFichaMedica
Paciente
0..1
Ficha Mdica
Ficha Mdica
Sangre : Tipo Sanguneo
Sangre de Madre : Tipo Sanguneo
Sangre de Padre : Tipo Sanguneo
CE1,U1 IdEmpleado
Grupo
Factor
GrupoPadre
FactorPadre
GrupoMadre
FactorMadre
Empleado
CP,CE2 IdPersona
CE1
IdJefe
Legajo
3 En algunos casos se puede obtener ms de un campo, por ejemplo cuando se representan tipos de datos
definidos por el usuario (estructuras).
Estndar SQL v1.0
Pg. 20 de 31
3.5.1.2 MAPEO DE RELACIONES 1 A N

Las relaciones 1 a N se implementan mediante una columna en la tabla correspondiente al extremo N. Esta
columna es una clave fornea que hace referencia a la tabla del extremo 1.
Ejemplo:
Un proveedor tiene ubicada su casa central en una provincia. Por otra parte, en
una provincia puede haber varias casas centrales de proveedores.
Proveedor
Provincia Casa Central
Proveedor
Razn social
Provincia
Nombre
CP
IdProveedor
CE1 IdProvinciaCasaCentral
RazonSocial
Provincia
CP
IdProvincia
CE1 IdPais
Nombre
3.5.1.3 MAPEO DE RELACIONES N A N

Estas relaciones se implementan mediante una tabla con dos campos, que son claves forneas de las tablas
relacionadas. Estos dos campos conforman la clave primaria de la tabla.
Ejemplo:
Un proveedor puede tener varios representantes, y a su vez una persona puede ser
representante de varias empresas.
Persona
Proveedor
Proveedor
CP
IdProveedor
CP
IdPersona
Razn social
RazonSocial
Nombre
DNI
*
Persona
Representantes
Nombre
DNI
CP,CE1 IdRepresentante
CP,CE2 IdProveedor
Estndar SQL v1.0
Pg. 21 de 31
3.5.1.4 MAPEO DE RELACIONES N-ARIAS

De manera similar a las relaciones N a N, las asociaciones N-arias se implementan usando una tabla de
relacin donde cada columna es una clave fornea de una tabla relacionada, y adems todas las columnas
conforman la clave primaria de la tabla.
Ejemplo:
En una empresa hay empleados y funciones. Un ejemplo de funcin podra ser
Gerente de recursos humanos. A su vez, la empresa est organizada
jerrquicamente en unidades organizativas, tal vez presentando una estructura
basada en la geografa (un nivel para continentes, otro para pases, otro para
provincias, etc). La siguiente estructura permite indicar que un empleado
determinado cumple una funcin en cierto nodo de la jerarqua, ejemplo: Juan Prez
es Gerente de RRHH de Latinoamrica.
Empleado
Empleado
CP,CE2 IdPersona
Legajo
Puesto
CE1
Puesto
CP,CE1 IdEmpleado
CP,CE3 IdUnidadOrganizativa
CP,CE2 IdFuncion
Funcin
Nombre
IdJefe
Legajo
Funcion
CP
IdFuncion
Nombre
UnidadOrganizativa
Unidad Organizativa
CP
IdUnidadOrganizativa
CE1
IdUnidadSuperior
Nombre
Nombre
Digresin:
Este caso se plante de esta manera a fin de ilustrar una asociacin ternaria. En
realidad, lo mejor hubiera sido modelar al Puesto como una clase asociativa entre
Funcin y Unidad Organizativa; de esta manera, el Puesto podra existir aunque no
haya ningn empleado ocupndolo.
Estndar SQL v1.0
Pg. 22 de 31
3.5.1.5 MAPEO DE CLASES ASOCIATIVAS

Una clase asociativa es distinta de una asociacin porque cada instancia tiene identidad y tambin puede
tener datos propios. Es decir que es posible hacer referencia a un vnculo entre dos objetos, o asociarle
datos.
Una clase asociativa se diferencia de una clase simple con relaciones en que introduce una restriccin: por
cada combinacin de instancias de las clases asociadas puede haber a lo sumo una instancia de la clase
asociativa que las relacione.
Las clases asociativas se implementan en modelos relacionales de manera similar a las clases: una tabla
con una clave primaria de un nico campo. La relacin propiamente dicha se implementa mediante un
conjunto de claves forneas (una por cada clase asociada) y un ndice nico sobre este junto de columnas.
El resto de los datos de la asociacin se implementan como columnas, y si existe alguna relacin entre la
clase asociacin y otra clase se implementa como corresponda segn la multiplicidad (1 a 1, 1 a N, N a N),
utilizando el ID de la tabla asociacin donde corresponda.
Ejemplo:
Los empleados de la compaa tienen distintas habilidades, que son niveles de
competencia en ciertas reas de conocimiento. Por ejemplo, Juan Prez es bueno
programando HTML y Javascript, y tiene conocimientos bsicos de Visual Basic.
Para modelar este tipo de relaciones se utilizan clases asociativas.
CP
IdValoracionCompetencia
Valoracin Competencia
Valor
Competencia
Nombre
Empleado
CE2,U1 IdEmpleado
CE1,U1 IdCompetencia
Valor
Empleado
Legajo
CP,CE2 IdPersona
CE1
IdJefe
Legajo
Competencia
CP
IdCompetencia
Nombre
Por un lado existen los empleados, y por otro las competencias. El rasgo
distintivo de este caso es que por cada combinacin de Empleado y Competencia
puede haber a lo sumo una Valoracin Competencia, porque no tiene sentido decir
simultneamente que Juan Prez es excelente programando HTML y que Juan Prez es
regular programando HTML. En la base de datos del ejemplo, esta restriccin se
implement mediante el ndice nico indicado como U1 en el diagrama, que se aplica
a IdEmpleado y IdCompetencia en la tabla ValoracionCompetencia.
3.5.1.6 MAPEO DE AGREGACIN

La agregacin se considera como una relacin, generalmente 1 a 1 1 a N, y se implementa de la manera
explicada en cada caso. Segn la especificacin actual, no existe diferencia semntica entre una simple
relacin y una asociacin.
Estndar SQL v1.0
Pg. 23 de 31
3.5.1.7 MAPEO DE COMPOSICIN

La composicin se interpreta en este contexto como una relacin 1 a 1 1 a N, donde en la tabla que
representa el extremo parte se agrega una restriccin de no nulidad al campo de clave fornea.
Dependiendo del problema, para la eliminacin del registro del la tabla con menores instancias (el lado 1 de
la relacin) deber realizarse una eliminacin en cascada o impedir la eliminacin del registro si existen
registros asociados por dicha relacin. Esto permitir una validacin adicional.
Ejemplo:
Un pas est compuesto por provincias; una provincia no puede existir fuera del
contexto de un pas.
Provincias
Pais
Nombre
Nombre
1
Provincia
Pais
Provincia
CP
IdPais
CP
IdProvincia
Nombre
CE1 IdPais
Nombre
3.5.1.8 MAPEO DE HERENCIA

La herencia es til cuando se quieren abstraer conceptos que tienen aspectos en comn; en el caso de
sistemas de informacin orientados a gestin de datos, se le encuentra utilidad porque permite mantener de
manera centralizada conjuntos de datos que de otra forma estaran replicados.
La herencia se representa haciendo que la clave primaria de la tabla correspondiente a la clase derivada
sea, adems de clave primaria, clave fornea de la tabla que representa la clase base.
Adicionalmente se establece, por convencin, que el nombre del campo ID de la tabla derivada sea el
nombre del campo ID de la tabla base.
Ejemplo:
A la empresa le interesa mantener datos de empleados y de representantes de
proveedores. Sin embargo, los empleados y representantes de proveedores tienen
datos en comn, ya que ambos son personas. En este caso, se modela esta situacin
mediante dos clases, Empleado y Persona, indicando que Empleado deriva de Persona.
Persona
Persona
CP
Nombre
DNI
IdPersona
Nombre
DNI
Empleado
Empleado
CP,CE2 IdPersona
Legajo
CE1
Estndar SQL v1.0
IdJefe
Legajo
Pg. 24 de 31
3.5.1.9 MAPEO DE ENUMERACIONES

Una enumeracin consiste en un conjunto de literales predefinidos, cuya modificacin no est prevista por la
aplicacin.
Hay dos maneras de implementar enumeraciones en un modelo de datos:
Utilizando restricciones (constraints)
Utilizando tablas auxiliares
La primer alternativa establece directamente una restriccin sobre los valores que puede tomar un campo;
los valores en cuestin son los literales de la enumeracin.
La otra alternativa consiste en crear una tabla auxiliar donde se listen los valores vlidos de la enumeracin.
Los campos de tipo enumeracin deben tener integridad referencial hacia el campo ID de la tabla
enumeracin.
Cada una de estas alternativas tiene ventajas y desventajas:
Mtodo
Restriccin
Ventajas
Simple
Tabla auxiliar
Auto descriptiva
Descripcin de literales
centralizada (permite consultar
los literales de la enumeracin)
Desventajas
Incmodo para enumeraciones
grandes.
La restriccin no es visible en los
diagramas.
La modificacin o actualizacin
puede hacerse slo con acceso a la
estructura de la base.
La tabla no se distingue de las
dems tablas de entidades.
El valor del campo no es visible
directamente (solo se ve el ID de la
tabla auxiliar).
Ejemplo:
Las enumeraciones Grupo Sanguneo y Factor se implementan como restricciones.
enumeracin
Grupo Sanguneo
A
B
AB
O
enumeracin
Factor
Positivo
Negativo
Las restricciones sobre los campos Factor y Grupo de la tabla FichaMedica son:
CK_FichaMedica_Factor:
([Factor] = '-' or [Factor] = '+')
CK_FichaMedica_Grupo:
([Grupo] = 'A' or [Grupo] = 'B' or [Grupo] = 'AB' or [Grupo] = 'O')
Se deja a criterio del analista la eleccin entre estas alternativas segn sea cada caso en su proyecto.
Estndar SQL v1.0
Pg. 25 de 31
3.5.1.10 MAPEO DE TIPOS DE DATOS (ESTRUCTURAS)

Hay dos maneras de implementar los tipos de datos o estructuras:
Mediante una tabla aparte.
Empotrando un conjunto de campos en representacin del atributo que tiene el tipo de dato de
estructura.
En la primera alternativa, la implementacin es similar a la de una clase.

En la segunda alternativa, lo que se hace es implementar cada atributo de tipo estructura como un conjunto
de campos, con un campo por cada atributo de la enumeracin, concatenando un prefijo o postfijo a cada
nombre de campo. El prefijo o postfijo es el nombre del atributo de la clase que usa la estructura.
Ejemplo:
Se desean implementar en la base de datos los campos Sangre , Sangre de Madre
y Sangre de Padre perteneciente a la clase Ficha Mdica y de tipo Tipo
Sanguneo.
FichaMedica
Ficha Mdica
CP

estructura
Tipo Sanguneo
Grupo : Grupo Sanguneo
Factor : Factor
IdFichaMedica
CE1,U1 IdEmpleado
Grupo
Factor
GrupoPadre
FactorPadre
GrupoMadre
FactorMadre
Estndar SQL v1.0
Pg. 26 de 31
3.6.
APNDICE 1: CONVERSIN DE TIPOS DE DATOS SQL A .NET

Conversin de Tipos de Datos SQL a .NET
Mapeo de tipos de datos OleDB a .NET Framework 1.1
(Internet)
(Local)
Mapeo de tipos de datos de SQL Server a .NET Framework 1.1
(Internet)
(Local)
Mapeo de tipos de datos ODBC a .NET Framework 1.1
(Internet)
(Local)
Estndar SQL v1.0
Pg. 27 de 31
3.7.
APNDICE 2: MODELO DE EJEMPLO
En este apndice se presenta un ejemplo completo donde se ilustran varios de los aspectos normados por
este estndar. Se trata de un sistema empresarial para gestionar empleados y proveedores. En el apartado
9.1 se encuentra el modelo conceptual de clases UML, en base al cual se dise el modelo de datos del
apartado 9.2.
El ejemplo no pretende ser realista; su objetivo es ilustrar de la manera ms compacta posible las distintas
construcciones del UML modelando un dominio ampliamente conocido. Entre las imprecisiones existentes
podemos mencionar la relacin entre Proveedor y Provincia, donde se omiti modelar el concepto de
sucursal; lo mejor hubiera sido introducir la clase Sucursal, y relacionar por un lado Sucursal con Provincia y
por otro Proveedor con Sucursales, y crear otra asociacin que sirva para indicar cual de las distintas
sucursales es la casa central. Otra imprecisin se encuentra en el modelado del Puesto, que se discute en
Mapeo de Relaciones N-Arias.
A modo de ayuda memoria de UML, recordamos:
El diamante negro representa composicin. Se dibuja en el extremo opuesto a la clase que tiene el
rol de parte.
La punta de flecha abierta es navegabilidad, y significa que es posible acceder a objetos de la clase
donde est la punta de flecha (a partir del otro extremo) pero no en sentido contrario. Cuando no hay
puntas de flecha, se considera que la navegabilidad es bidireccional.
La punta de flecha cerrada (tringulo blanco) representa herencia, y se dibuja en el extremo

correspondiente a la clase base.
Los nmeros en los extremos de las asociaciones indican la multiplicidad, es decir, las cantidades
permitidas de instancias relacionadas. Son dos nmeros, que indican la cantidad mnima y mxima
(en ese orden). As, 0..1 quiere decir opcional, 1 (que es equivalente a 1..1) quiere decir
obligatorio, y * (asterisco, o su forma equivalente 0..*) quiere decir ilimitado.
El texto en los extremos de asociacin indica el rol que juega la clase en su relacin con el otro
extremo. Por ejemplo, una persona en su relacin con un proveedor es un representante.
El diamante blanco grande es una asociacin N-aria.
La lnea de puntos que va de una clase hasta una asociacin sirve para indicar que la asociacin y la
clase son la misma cosa, es decir que se trata de una clase asociacin.
Estndar SQL v1.0
Pg. 28 de 31
3.7.1
MODELO CONCEPTUAL
Provincia Casa Central
Proveedor
Provincia
Razn social
Nombre
*
Pais
Nombre
Provincias
*
Persona
Representantes
Nombre
DNI
*
Valoracin Competencia
Valor
Competencia
Empleados a cargo
Empleado
1
Nombre
Jefe
Legajo
0..1
Paciente
0..1
enumeracin
Factor
Positivo
Negativo
Propietario
Equipos
Equipo
Nmero de Serie
Ficha Mdica
estructura
Tipo Sanguneo
Grupo : Grupo Sanguneo
Factor : Factor
Funcin
Puesto
enumeracin
Grupo Sanguneo
A
B
AB
O
Ficha Mdica
Nombre
Unidad Organizativa
Unidad Superior
Nombre
0..1
Unidades Inferiores
Estndar SQL v1.0
Pg. 29 de 31
3.7.2
MODELO DE DATOS
Proveedor
CP
Provincia
IdProveedor
CP
RazonSocial
Pais
IdProvincia
CP
IdPais
CE1 IdPais
Nombre
Nombre
Persona
CP,CE1 IdRepresentante
CP,CE2 IdProveedor
CP
IdPersona
Nombre
DNI
FichaMedica
CP
Equipo
IdFichaMedica
CE1,U1 IdEmpleado
Grupo
Factor
GrupoPadre
FactorPadre
GrupoMadre
FactorMadre
Empleado
CP
IdEquipo
CP,CE2 IdPersona
CE1
IdPropietario
Nombre
CE1
IdJefe
Legajo
Competencia
CP
IdCompetencia
Nombre
Puesto
CP,CE1 IdEmpleado
CP,CE3 IdUnidadOrganizativa
CP,CE2 IdFuncion
CP
Funcion
UnidadOrganizativa
CP
IdUnidadOrganizativa
CE1
IdUnidadSuperior
Nombre
CP
IdValoracionCompetencia
CE2,U1 IdEmpleado
CE1,U1 IdCompetencia
Valor
IdFuncion
Nombre
Estndar SQL v1.0
Pg. 30 de 31
3.8.
REFERENCIAS Y RECURSOS
1. Practical database design, Part 2.

Philipp K. Janert.
http://www-106.ibm.com/developerworks/web/library/wa-dbdsgn2.html
2. SQL Server Database Coding Conventions, Best Practices, and Programming Guidelines.
Vyas Kondreddi.
http://www.sql-server-performance.com/vk_sql_best_practices.asp
3. Speed Up SQL Server Apps.
Roman Rehaz.
http://www.ftponline.com/vsm/2004_07/magazine/columns/databasedesign/
Estndar SQL v1.0
Pg. 31 de 31

Estándar SQL v1.0

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Estándar SQL v1.0

Caricato da

Copyright:

Formati disponibili

ESTNDAR DE PROGRAMACION PARA SQL

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

ORGANIZACIN DE ESTE DOCUMENTO ....................................................................................... 5

3. ESTANDAR SQL ....................................................................................................................... 6

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

MAPEO DE CLASES ASOCIATIVAS................................................................................. 23

APNDICE 1: CONVERSIN DE TIPOS DE DATOS SQL A .NET................................................. 27

3.7. APNDICE 2: MODELO DE EJEMPLO ........................................................................................... 28

REFERENCIAS Y RECURSOS ........................................................................................................ 31

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

Descripcin del cambio

Centro Experto Web

Primera versin del documento.

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

ORGANIZACIN DE ESTE DOCUMENTO

El documento est organizado de la siguiente manera:

Esta introduccin, donde se establece el propsito del documento, su organizacin y documentos

El captulo 4, Convenciones para la programacin de T-SQL, establece lineamientos para la

Las Normas de diseo y programacin establecen la estructura de la base de datos, y es de

Finalmente, una serie de apndices centralizan informacin de referencia.

Gua general de estndares de programacin.

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

CONCEPTOS PREVIOS: FORMAS NORMALES

Tabla con grupo de repeticin (IdRepresentante1, IdRepresentante2,

Al aplicar los requisitos de la primer forma normal a estos ejemplos, se obtiene:

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.1.2 SEGUNDA FORMA NORMAL

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.1.3 TERCERA FORMA NORMAL

El campo NombrePais depende de IdPais, el cual es el campo que realmente depende

Dividiendo los datos en 2 tablas, la dependencia transitiva es removida.

3.1.4 CUARTA FORMA NORMAL

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.1.5 QUINTA FORMA NORMAL

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.2.2 NOMBRES DE TABLAS

3.2.3 NOMBRES DE VISTAS

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.2.4 NOMBRES DE CAMPOS

3.2.5 NOMBRES DE CLAVES PRIMARIAS

3.2.6 NOMBRES DE NDICES

el nombre de la tabla sobre la que se crea,

los campos involucrados,

si son unique o no.

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.2.7 NOMBRES DE CLAVES FORNEAS

donde PrefijoDeSistemaOModulo es una cadena de pocos caracteres (en lo posible no ms de cuatro)

donde Accin es una de las siguientes: Select, Delete, Update, Insert.

Direccin de Servicios de Desarrollo

Estndar SQL v1.0

3.2.9 NOMBRES DE DESENCADENADORES

3.2.10 NOMBRES DE VARIABLES

3.2.12 NOMBRES DE TIPOS DE DATOS