Nomenclatura de Base de Datos

Índice
1 INTRODUCCIÓN 4
1.1 PROPÓSITO 4
1.2 AUDIENCIA 4
2 GUÍAS GENÉRICAS Y BUENAS PRÁCTICAS 5
3 NOMENCLATURA PARA LOS ELEMENTOS DE UNA BASE DE DATOS 7
3.1 TABLESPACES 7
3.2 TABLAS 7
3.3 VISTAS 7
3.4 SEQUENCIADORES 8
3.5 COLUMNAS 8
3.6 TRIGGERS 10
3.7 TIPOS DE DATOS DEFINIDOS POR EL USUARIO 10
3.8 PRIMARY KEYS 10
3.9 FOREIGN KEYS 11
3.10 ALTERNATE KEYS 11
3.11 INDEXES 11
3.12COLUMNAS LOB (BLOB Y CLOB) 12
3.13 PACKAGES, PROCEDIMIENTOS Y FUNCIONES 12
3.13.1 PAQUETES 12
3.13.2 STORED PROCEDURES 13
3.13.3 FUNCIONES DEFINIDAS POR EL USUARIO 13
3.13.4 VARIABLES 14

Control de Ediciones
Versión Fecha Modificación Autor
v.0.9 04/04/2013 Versión inicial del documento Jorge Casaverde
Laboratorio Web






1 Introducción
1.1 Propósito
La presenteguía presenta la normativa de modelado de Bases de Datos para las aplicaciones desarrolladas para una empresa . En ella se recogen las normas que debe cumplir el modelo de datos, se incluyen dos tipos de indicaciones para el correcto desarrollo de aplicaciones:
• Normas: Son requisitos de obligado cumplimiento (OBL).
• Buenas prácticas: Son recomendaciones. No son de obligado cumplimiento aunquepara uncorrecto funcionamiento se recomienda cumplirlas siempre que sea posible (REC) .
1.2 Audiencia
Este documento va dirigido a jefes de proyecto, analistas y desarrolladores de proyectos que requieran definir y/o modificar modelos de datos para aplicaciones de una empresa.
2 Guías Genéricas y Buenas Prácticas
1. REC – Utilizar nombres descriptivos para los campos. Utilizar nombres queresulten intuitivos y permitan entender el significado de los campos (mnemotécnicos). Evitar las abreviaciones, y si esto no es posible documentarlas bien.
2. OBL – Utilizar solo mayúsculas para nombrar los elementos de la base de datos, schemas, tablas y campos.
3. REC – No nombrar campos que representan lo mismo de forma distinta. La forma en que se nombran iguales propiedades debe ser consistenteen todo un esquema. Ejemplo: Nombrar al campo clave de la tabla Clientes como ID_CLIENTE, y después referenciarlo en otras tablas como CLIENTE_ID es INCORRECTO. El campo debe ser nombrado igual en todos los casos que se quiera almacenar una clave de Cliente, excepto si hay dos ocurrencias del mismo campo (dos claves foránes) en cuyo caso se debe distinguir una de ellas con el concepto querepresenta.
4. REC – Evitar tener demasiadas columnas NULLABLES en una tabla. Esto es indicio de un esquema poco o nada normalizado. Falta de normalización puede conllevar problemas de consistencia en los datos en la medida que un mismo campo se puede terminar almacenando en varias tablas. Excesiva normalización puede tener asociada una perdida de performance en ciertas operaciones sobre la base de datos.Es necesario encontrar el equilibrio correspondiente a los requerimientos de cada proyecto en este punto. Como regla general la tercera forma normal es un buen punto intermedio.
5. REC – Evitar tener tablas sin definición de primary keys.
6. REC – Evitar tener tablas innecesarias en el sistema. Un buen diseño es uno simple (keep it simple ;)
7. REC – Intentar evitar el uso de códigopropietario en la definición de expresiones SQL.. Intentar utilizar código Standard SQL-92.

3 Nomenclatura para los Elementos de una Base de Datos
3.1 Tablespaces
Cada vez que se cree un nuevo objeto de base de datos, se debe asignar al tablespace correcto, según el tipo de objeto.
Todo modelo de datos debe tener definidos lossiguientes tablespaces (en estos tablespaces deberá sustituirse XXXX porel nombre del proyecto):
• TBSBLOB_XXXX_100: Tablespace que se asignará a las columnas de tipo BLOB o CLOB
• TBSDAT_XXXX_100: Tablespace para las tablas
• TBSIND_XXXX_100: Tablespace para los índices
3.2 Tablas
La nomenclatura de las tablas debe ser [XXX]_[NOMBRE_TABLA], donde:
•XXX: Abreviatura del proyecto (Ejemplo: SVE)
•NOMBRE_TABLA: Nombre de la tabla, en mayúsculas. Si contiene...