<Company Name>

<Project Name>
Design Guidelines Database

Version <1.0>

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in
square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author
and should be deleted before publishing the document. A paragraph entered following this style will
automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for
this document. After closing the dialog, automatic fields may be updated throughout the document by
selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must
be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the
field contents. See Word help for more information on working with fields.]
<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>

Confidential <Company Name>, Page 2 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Table of Contents
1. Terminología y conceptos básicos 4
1.1 Entidad 4
1.2 Atributos 4
1.3 Clave Primaria 4
1.4 Relaciones 4
1.4.1 Tipo de Relaciones. 4

2. Reglas de Normalización 4
2.1 Primera forma normal: 5
2.2 Segunda forma normal 5
2.3 Tercera forma normal 5

3. Convenciones de denominación. 5
3.1 Reglas Generales : 6
3.2 Convenciones del modelo lógico (modelo de datos) 6
3.2.1 Denominación de esquemas (Schema). 6
3.2.2 Denominación de Entidades. 7
3.2.3 Dominios 9
3.2.4 Atributos 9
3.2.5 Relaciones 10
3.3 Convenciones del modelo físico. 11
3.3.1 Reglas Generales 11
3.3.2 Tablas 12
3.3.3 Columnas 12
3.3.4 Constraints 14
3.3.5 Indices 15
3.3.6 Secuencias 16
3.3.7 Vistas 16
3.3.8 Triggers 17
3.4 Apéndice A – Abreviaturas y Siglas. 17
3.5 Apéndice B - Palabras Reservadas por Oracle 17

Confidential <Company Name>, Page 3 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Guía de diseño de base de datos.

1.Terminología y conceptos básicos
El modelo lógico de datos representa el diseño de la base de datos, mientras que el modelo físico de datos
representa la realización del diseño. Se utilizan términos distintos para comparar el diseño lógico y el
diseño físico.
El siguiente esquema ayuda a clarificar esta terminología:

Lógico Relacional Lógico Objeto Físico

Entidad Clase Tabla
Atributo Atributo Columna, campo
Fila Objeto Registro

1.1Entidad
Se trata de algo que tiene interés para el negocio, tal como un empleado, un departamento, o una venta.
Desde el punto de vista teórico, una entidad puede ser un conjunto de atributos. Es mejor pensar que una
entidad es algo que tiene correspondencia en el mundo real. Por ejemplo cada instancia de la entidad
departamento se corresponde con un departamento específico de la organización. Existe una
correspondencia directa entre entidades e instancias de la teoría relacional con clases y objetos,
respectivamente, en la teoría de objetos. Por ejemplo, para la entidad Departamento podemos hablar de la
clase Departamento, que incluirá el objeto Contabilidad.

1.2Atributos
Se trata de una pieza de información que podemos extraer de un objeto o instancia de una entidad o clase,
tales como los nombres de los departamentos o las edades de los empleados.

1.3Clave Primaria
Son los atributos de una entidad que identifican de manera única a cualquier instancia específica de dicha
entidad. Las claves primarias deben ser únicas. Ningún atributo debe ser nulo y una vez asignadas, no
podrán modificarse. Este requisito final es mas practico que teórico, porque modificar la clave primaria
significaría cambiarla en cualquier lugar que haya sido utilizada como referencia, pudiendo afectar
potencialmente a miles o millones de registros.

1.4Relaciones
La relación es una asociación entre dos entidades que indican alguna conexión significativa e interesante
entre ellas.

1.4.1Tipo de Relaciones.
• Relación 1 a varios.
• Relación 1 a 1.
• Relación varios a varios.

2.Reglas de Normalización
Cuando decimos que una base de datos ha sido normalizada, se está intentando desarrollar un conjunto de
tablas en la base de datos que no se superpongan de manera inapropiada y que nos permitan almacenar toda
la información que pueda contener la base de datos en la misma forma que tres vectores unitarios
ortogonales pueden generar un espacio de tres dimensiones.

Confidential <Company Name>, Page 4 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

El teorema fundamental de la teoría relacional es que si su base de datos se encuentra normalizada, podrá
extraer cualquier subconjunto de datos de ella utilizando operadores básicos de SQL.
Si abandonamos las reglas de normalización para la creación de bases de datos orientadas a objetos,
corremos el riesgo de perder flexibilidad de los sistemas a desarrollar.

2.1Primera forma normal:

se define como aquella que no tiene ningún atributo multivalor. Eliminar atributos Repetitivos.

A B C D E A B E
C D
C D
C D A C D
C D

2.2Segunda forma normal

Eliminar atributos que no dependen en forma completa de la clave principal. ( Dependencia parcial).

A B C D
A B C

A D

2.3Tercera forma normal

Eliminar atributos con dependencias transitivas

A B C A B

B C

3.Convenciones de denominación.
Factores clave del éxito de cualquier sistema son la aplicación consistente y la elección apropiada de
convenciones de denominación.
1) Desde el punto de vista lógico(modelo de datos), se debe nombrar todos los elementos que aparezcan en
el diagrama de clases:
• Esquemas

Confidential <Company Name>, Page 5 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

• Diagrama de clases
• Entidades
• Atributos
• Dominios
• Relaciones
• Operaciones y métodos. ¿?
2) Desde el punto de vista del desarrollo físico, se debe dar nombre a los siguiente elementos:
• Secuencias
• Vistas
• Restricciones (Constraints)
• Índices
• Tipos de Objetos
• Alias (Synonyms)
• Triggers
• Stored Procedures ¿?
3.1Reglas Generales :
La reglas establecidas en esta sección deben ser seguidas al nombrar objetos, a menos que sean
exceptuadas específicamente por estándares individuales del objeto en secciones posteriores. Las
secciones individuales contienen cualquier regla adicional específica a un objeto y a unos o más ejemplos
para ilustrar uso.
Los objetos se deben nombrar usando abreviaturas aprobadas por el comité de arquitectura funcional. El
apéndice A proporciona la lista completa de las abreviaturas aprobadas. Si no existe una abreviatura, debe
ser solicitado al administrador de los datos.
Los nombres no pueden incluir palabras o caracteres reservados por Oracle. Ver apéndice B.
Los nombres del objeto de la base de datos se restringen a no más de veintiséis (26) caracteres e incluyen
entidades, atributos, tablas, columnas, vistas, secuencias, y dominios. Sin embargo, algunos utilitarios
pueden agregar un sufijo de 4 caracteres adicionales por ejemplo " _ EJB". Por esta razón, la longitud
recomendada es veintidós (22) caracteres. Las palabras alias y short name se utilizan para describir una
una etiqueta descriptiva codificada de dos (2) a cuatro (4) caracteres. La palabra nombre significará una
etiqueta descriptiva de tres (3) a veintiséis (26) caracteres. Los nombres deben ser significativos, y deben
describir exactamente el objeto a el cual se asignan. El uso constante de abreviaturas asistirá a este
esfuerzo.
Utilice palabras representativas con un fuerte significado sobre el interes.
No se permite el uso de las palabras quien, que, cuando o donde.
El uso de artículos y las preposiciones (tales como o de ), las palabras o las conjunciones (por ejemplo y u
o ), las palabras calificativas tales como nuevo o viejo , y los números deben utilizarse como excepciones.
Los caracteres especiales, incluyendo los corchetes, los signos de interrogación, preguntas y las barras no
se permiten. Solo se permite como separador de palabras al guión bajo (underscore).
El caracteres de subrayado (underscore) será utilizado solamente cuando sea necesario separar palabras en
la implementación física de los objetos (como ser las tablas y las columnas).

3.2Convenciones del modelo lógico (modelo de datos)

3.2.1Denominación de esquemas (Schema).

Un esquema es un conjunto de tablas que se podrán convertir en una base de datos o en una cuenta de
usuario independiente.

Confidential <Company Name>, Page 6 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Debe haber un esquema por cada área temática dentro del modelo de datos.
Se tomará como nombre de los esquemas una sigla, siempre que sea posible utilizaremos las dos primeras
letras del nombre lógico del esquema. Tal como <<CU>> Custodia, <<FA>> Facturación, <<TR>>
Transferencias.
Como utilizaremos el convenio de NOMBRE_DE_ESQUEMA.NOMBRE_TABLA, es preciso que los
nombres de los esquemas sean cortos.
SQL cuenta con una sentencia llamad CREATE SCHEMA que se utiliza para unir varias instrucciones
DDL (Data definition language) en una única instrucción o transacción. Ninguna instrucción DDL
individual será resuelta hasta validar todos los componentes de la instrucción CREATE SCHEMA. En
esencia, la palabra SCHEMA se refiere a un conjunto de instrucciones DDL que existen en una cuenta de
base de datos.

3.2.2Denominación de Entidades.

3.2.2.1Nombres de Entidad
Todos los nuevos nombres de la entidad serán definidos de acuerdo con los estándares y las abreviaturas
que existen a la hora de su definición.
Los nombres de la entidad deben ser sustantivos singulares o frases nominativas. Deben estar relacionados
con el negocio, y contendrán un espacio en blanco entre cada término. Los nombres de la entidad no
pueden contener ningunos de los caracteres especiales, preposiciones o artículos. Utilice la lista de
abreviatura y siglas fijada por comité de arquitectura funcional (CAF) para determinar la abreviatura o las
siglas aprobadas que se utilizarán en el nombre de la entidad. En la descripción de las entidades se be
completar las palabras del texto o el texto completo para las siglas usadas.
Los nombres de la entidad no pueden contener los nombres de construcciones físicas tales como "archivo"
o " tabla" como calificado. Ejemplo: Utilice “cliente”, no “archivo cliente” o “tabla cliente”.
Las entidades no deben exceder 22 caracteres incluyendo espacios. Para construir los nombres de la
entidad, se deben utilizar las abreviaturas y las siglas de las listas aprobadas por el CAF. Ejemplo:
CABECERA ORD, MEDIDA UND.
Los nombres de la entidad del no pueden contener ningunos de los caracteres especial por ejemplo: @, #, $,
%, *, o /.
Los nombres de la entidad del no puede contener ninguna preposición por ejemplo: en, cerca, para, adentro,
de, a
Los nombre de la entidad no puede contener ningún artículo por ejemplo: el, la, los, las, un, una.

3.2.2.2Alias de Entidad
Los nombres cortos de la entidad son creados por el diseñador. Lo que sigue se aplica a los nombres cortos
creados por el diseñador. Un alias de la entidad se compone de una palabra o palabras distintas (6 caracteres
o menos) o una concatenación de los fragmentos de la palabra de la entidad. El diseñador utiliza el nombre
corto para la generación de los nombres de las constraints, foreign keys, y secuencias. Un usuario debe
saber a partir de un alias de la entidad y saber a qué entidad se refiere. Desde alias de la entidad el nombre
se puede utilizar para crear cualquier nombre de la columna perteneciente a una foreign key, es importante
destacar que el alias indica la entidad de la cual vino. Utilice una abreviatura estándar si existe una. Como
guía de consulta, los nombres cortos deben ser un mínimo de 3 caracteres y un máximo de 6. Si un nombre
de la entidad consiste en una palabra, el nombre corto debe ser los primeros 3 a 6 caracteres, o puede ser
siglas o una abreviatura aprobadas. Si el nombre de la entidad consiste en dos o más palabras, el alias debe
ser la primera letra de cada una de las palabras del nombre para no exceder 6 caracteres, o cada palabra
puede ser siglas o una abreviatura aprobadas sin espacio entre ellos.

Confidential <Company Name>, Page 7 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Ejemplo: ESP puede ser el alias para la entidad Especie.

DETORD puede ser el alias para la entidad Detalle Orden.

3.2.2.3Entidad de intersección.
Una entidad de intersección asocia dos diversas entidades y resuelve una relación múltiple. Se nombra
según su la funcionalidad del negocio, si es posible.
Ejemplo: Si la entidad una se nombra ORDEN (ORD) y la entidad dos se nombra PRODUCTO (PRODT),
una entidad de intersección se puede crear como el ARTÍCULO de la ORDEN (ART ORD). Si no hay
términos del negocio apropiados , el nombre se forma simplemente de los nombres de las entidades que son
asociadas. Ejemplo: La DIRECCIÓN del CLIENTE (DIR CLI) describe la intersección de las entidades del
CLIENTE (CLI) y de la DIRECCIÓN (DIR).

3.2.2.4Entidad de asociación.
Una entidad de asociación se utiliza para resolver una relación muchos a muchos recursiva. Se crea un lazo
recursivo cuando los casos de una entidad se pueden relacionar con otros casos de esa misma entidad. Se
nombra con la entidad del padre añadida la palabra ASOCIACIÓN al final.
Ejemplo: La ASOCIACIÓN del CLIENTE (CLI ASOC)

3.2.2.5Entidad de validación
Una entidad de validación (también conocida como una entidad de tipos) es una que contiene el lookup. o
información del código. Las entidades de validación deben añadir como sufijo un espacio en blanco y la
palabra "TIPO " para distinguirlos de otros tipos de entidades.
Ejemplo: TIPO DEL CLIENTE DEL TIPO DE LA ORDEN (ORD TY) (CLI TY).

3.2.2.6Cross-checking del modelo

Si se están produciendo unos o más diagramas de entidad, para la funcionalidad es crítico que estén
desarrollados conjuntamente con el modelo funcional para asegurarse de que todas las funciones
identificadas son representadas por la información contenida en el ERD(s). Utilizar una matriz que
proporcione un mecanismo de cross-checking entre las entidades del ERD y la funcionalidad..

3.2.2.7Diagramas de Entidad
Como guía para los ERDs:
Todos los atributos deben estar listados.
Los identificadores de la clave primaria debe estar listado.

3.2.2.8Usos de la entidad
Utilizado por funciones de negocios - cada entidad se debe asociar a unos o más función del negocio a un
nivel más bajo. Para utilizar cualquiera de las entidades, deben estar asociadas a una función elemental del
negocio que sea responsable de crear, extraer, actulizar, o de borrar (CRUD, siglas del ingles creating,
retriving, updating, deleting) instancias de esa entidad. Como guía de consulta, cada entidad debe tener el
uso de por lo menos una función elemental. Por lo menos un crear?, Extraiga?, Actualización?, y
cancelación?.

Confidential <Company Name>, Page 8 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Cada uno de los atributos de la entidad también se debe asociar a cada una de las funciones elementales del
negocio donde la entidad es el padre en la asociación. Como guía, cada atributo, debe tener una o más
función elemental del negocio que será responsable de insertar, extraer, modificar, y anulando (IRUN)
atributos.

3.2.3Dominios
Los Dominios son usados para mantener características en común.
Un dominio puede definir un conjunto de reglas de validación, restricciones de formato y otras
propiedades que aplican a un grupo entidades, atributos, columnas, Oracle object Type. Si realiza un
cambio a un dominio, se propaga la actualización de la información asociada. Todos los dominios se
pueden considerar globales. Cierta aplicación puede necesitar crear dominios del específico de la
aplicación.

3.2.4Atributos
Un atributo es cualquier detalle, que sirva para identificar, calificar, cuantificar, clasificar, expresar el
estado de, o describir de otra manera características de una entidad. Cada ocurrencia de un atributo dentro
de una entidad tiene un y solamente un valor. Los atributos son clasificados en el repositorio por las
funciones y representados en diagramas de entidad con siguientes los símbolos:
Símbolo Descripción
# Identificador Clave Primaria (UID)
* Atributo obligatorio (not null)
O Atributo opcional (null)

Los nombres del atributo no pueden exceder 22 caracteres en longitud.

Definir nombres del atributo en singular.
Como los atributos se muestran siempre en el contexto de una entidad, no repetir el nombre de la entidad
como parte del nombre del atributo.
Los atributos pueden tener nombres de varias palabras, con las palabras separadas por un espacio. Los
nombres del atributo deben ser descriptivo como sea posible. Como sea posible se debe usar términos que
un usuario final reconocerá. Las abreviaturas y las siglas se deben utilizar para crear el nombre del atributo.
Las abreviaturas en el nombre del atributo se deben seleccionar de la lista aprobada por CAF que reside en
Armar link donde se encuentra el documento de abreviaturas.
Ejemplos: DT INI (Fecha Inicio), DT FIN (Fecha Fin), DESC TX (Descripción Texto)
Los nombres de los atributos deben terminar en un clase de dato que indique el tipo de dato que el atributo
representa. Las clases de datos deben ser aprobadas por el administrador de datos.
Clase Sigla Tipo Significado
Monto MT NUMBER Un valor Monetario
Código CD VARCHAR2 Una combinación de uno o mas números, letras, caracteres especiales.
Fecha DT DATE Día determinado de Un dia del calendario anual, identificado
por su número ordinal dentro de un mes civil dentro de ese
año.
Identificador ID Number Una combinación de unos o más números que señalen un
objeto específico, pero que no tenga ningún significado.
Nombre NM VARCHAR2 Identificador de un objeto expresado por una palabra o frase.
Cantidad QY NUMBER Un valor no monetario
Texto TX VARCHAR2 Un conjunto de caracteres.

Confidential <Company Name>, Page 9 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Completar Identificando Nuevos Clases

3.2.4.1Definiciones
Los atributos opcionales, deben explicar el significado del valor nulo para ese atributo, esto significa si es
diferente a un VALOR DESCONOCIDO.

Definir todos los atributos VARCHAR2 como UPPERCASE en los casos “NO SENSITIVOS”.

Definir el propósito del atributo en la propiedad de descripción.

3.2.5Relaciones
Generalmente, las entidades deben tener por lo menos una relación, aunque habrá entidades ocasionales
que son independientes. Las relaciones deben ser nombrados siempre puesto que puede haber varias
relaciones entre dos entidades, y sus propósitos deben ser sabidos. Hay muchos diversas relaciones posibles
entre dos entidades; por ejemplo, entre las Entidades PERSONA y COMPANIA la relación “esta
actualmente trabajando para” puede ser de interés, pero también es una relación “es dueña de” . Se debe dar
a cada relación un nombre, un opcional y un cardinal (uno o muchos).

3.2.5.1Opcionalidad y Cardinalidad.
Es una buena práctica convertir en lo posible relaciones muchos a muchos en muchos a uno. Las
relaciones muchos a muchos y uno a uno deben ser investigadas cuidadosamente para cerciorarse de
realizar lo correcto.
Los nombres de las relaciones deben encajar en el siguiente modelo: Cada DESDE-ENTIDAD {debe ser,
puede ser} Nombre de Relación { UNO Y SOLO UNO HASTA-ENTIDAD(singular), UNO O MUCHOS
HASTA-ENTITIDAD(plural)}.
Las relaciones deben ser nombradas para poder leer fácilmente el diagrama. Para leer cualquier relación se
utiliza la siguiente sintaxis:
Donde DESDE-ENTIDAD es la entidad fuente en la relación, HASTA-ENTITY es el destino extremo de la
relación, y el nombre de la relación es el nombre que indica la dirección donde la relación se comienza a
leer. Observe las siguientes reglas:
La elección de DEBE SER y PUEDE SER es determinada por la opcionalidad de la relación que emana la
entidad fuente. Una línea llena representa debe ser (obligatoria) y una línea discontinua representa puede
ser (opcional).
La elección entre UNO Y SOLO UNO HASTA-ENTIDAD (singular) y UNO O MUCHOS HASTA-
ENTIDAD (plural) es determinada por la cardinalidad de la relación.
Siendo las relaciones siempre bi-direccionales, entonces, se debe proveer dos nombres para la relación
según su dirección. De esta manera la relación es comprensible desde ambas direcciones.
Ejemplos:
CADA Persona PUEDE SER ubicada en UNA o MUCHAS Direcciones.
CADA Dirección DEBE SER la ubicación para UNA y SOLO UNA PERSONA
El siguiente cuadro muestra los posibles nombres de las relaciones:
Para Indicar
Posesión tiene pertenece a

Confidential <Company Name>, Page 10 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Para Indicar
Responsabilidad esta a cargo de Es responsable de
Localización esta ubicado en Es ubicación de
Generación genera Es generado por
Acción realiza Es realizado por
efectúa Es efectuado por
Elementos Contenidos comprende Es comprendido por
Afectación afecta a Es afectado por
Utilización utiliza Es utilizado por
Asignación está asignado a tiene asignado a
Designación designa a Es designado por
Supertipo/Subtipo puede ser Es (subtipo)
Acuerdo firma Es firmado por
Inclusión incluye Es incluido en
Adhesión adhiere Es adherido por
Comercialización comercializa Es comercializado por
Presentación presenta Es presentado por
Relaciones múltiples relaciona a Es relacionado con
con un rol diferenciador

3.3Convenciones del modelo físico.

3.3.1Reglas Generales

3.3.1.1Database
El nombre de la base seleccionado es “<none>”. Esto significa que los parámetros de la base y tablespace
en debe estar en blanco. La definición de las tablas son generadas inicialmente sin
definición/implementación con respecto a la base, tablespace o condiciones de almacenamiento. Esto es así
también para la generación de índices a partir de la definición de las tablas.

3.3.1.2Claves
Las reglas en cascada para las definiciones de las nuevas claves foráneas deben tener por default, el valor
“restringido” (“RESTRICTED”). Estas reglas dependerán de las reglas del negocio, y deberá analizarse si
en algún caso no el valor por default no corresponde. Deberá documentarse en la descripción del modelo de
entidad, si el valor RESTRICTED no es usado.
Las claves substitutas se definen usando una secuencia. Se nombran por convención: SEQ_ID / SEQ_Vn
Las claves deberán tener una longitud máxima de 30.

3.3.1.3Otras reglas
El orden de las columnas deberá ser:
Columnas de clave primaria (de mayor a menor)
Columnas obligatorias (incluyendo columnas de auditoría a usuarios)
Columnas de clave foránea antes de las columnas de atributos
Columnas agrupadas por su entidad fuente
Tipo de datos LOBs
Nota: No Utilizar las columnas del tipo LONG y LONG RAW. Reemplazar LONG por los tipos LOBs.

Confidential <Company Name>, Page 11 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

3.3.2Tablas

3.3.2.1Convención para nombrar tablas

Los nombres deben ser en singular. Las tablas derivadas de entidades deberán nombrarse:
<prefijo_aplicación>_<nombre_entidad_en_singular>
Si la tabla está basada en una entidad, deberá nombrarse con el nombre de dicha entidad, representando a
los espacios con guiones bajos ( _ ). Si no está basada en una entidad, deberá nombrarse usando los
standards de abreviación, utilizando guiones bajos ( _ ) entre los segmentos.
Los primeros 19 caracteres de los nombres de las tablas deberán ser unívocos. Esta convención ayudará
cuando un prefijo de 2 caracteres se anteponga a los nombres de las tablas. Si los nombres de las tablas
llegaran a tener más de 26 caracteres, se recomienda reducirlos.

3.3.2.2Definición
Crear alias para cada tabla y su longitud varía entre 3 y 6 caracteres de longitud. Es recomendable mantener
la longitud en 3 caracteres.
En cada tabla o vista se deberá ingresar el nombre completo de la tabla o de la vista en la descripción. Estos
serán los nombres que visualizarán los usuarios finales.
No es conveniente modificar el valor por default de “Init Trans”, a pesar de presumir que la tabla será
actualizada por muchos usuarios simultáneamente. Se deberá documentar el cambio de este valor en la
“Descripción” en la definición de la tabla, utilizando la palabra INIT TRANS.
No deberán especificarse valores para PCTFREE y PCTUSED. Para tablas extensas, se deberá indicar en
“Descripción” de la definición de la tabla, utilizando las palabras PCTFREE / PCTUSED e incluyendo un
ejemplo de tamaño de la tabla. (Basarse en los valores para PCTFREE y PCTUSED en ORACLE9 Server
Administrator’s Guide)
Extender la descripción de la tabla para incluir cualquier requerimiento a nivel de diseño. La descripción
inicial se origina a partir de la definición de la entidad.
Definir el propósito y la utilidad en detalle de aquellas tablas que no deriven de entidades.
Todas las definiciones de las tablas se generarán a partir de sus entidades o de las entidades del modelo
lógico de datos, y no serán creadas en forma manual. Esto no es aplicable a tablas creadas específicamente
para facilitar la implementación física de una función.
Cada tabla deberá tener un alias. Este alias deberá seguir el standard dispuesto para el alias de entidades. Si
una tabla está basada en una entidad, deberá tener el mismo alias de su entidad.

3.3.3Columnas

3.3.3.1Convención para nombrar columnas

Los nombres deben ser en singular.
No utilizar el alias de la tabla como prefijo en el nombre de las columnas, a excepción de las columnas de
claves foráneas.
Si los nombres contienen más de 30 caracteres, utilice las siglas y abreviaturas aprobadas en los apéndices,
para acortarlos.
Si una columna está basada en un atributo, deberá llevar su mismo nombre reemplazando los espacios por
guiones bajos ( _ ). Si no está basada en un atributo, deberá nombrarse usando los standards dispuestos
para los atributos, utilizando guiones bajos ( _ ) entre los segmentos.
Crear nombres cortos, lógicos y autodescriptivos. No repetir el nombre de la tabla en el nombre de la
columna. Las abreviaciones en el nombre de las columnas deberán basarse en las convenciones.

Confidential <Company Name>, Page 12 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

(Apendice A)
Definir columnas para claves primarias generadas por el sistema, usando el nombre ID.
Nombrar a las columnas de las claves foráneas, utilizando la convención:
<alias_tabla_referenciada>_<nombre_columna_clave_primaria_tabla_referenciada>
Para múltiples claves foráneas en una tabla:
<alias_tabla_referenciada>_<identificador_de_la_relación>

3.3.3.2Definción
Asignar el mismo nombre a las columnas de una vista, que tienen las columnas de la tabla asociada a dicha
vista. Para columnas no basadas directamente en las columnas de la base de datos, referirse a las
convenciones para nombrar columnas. Para columnas con el mismo nombre en diferentes tablas, anteceder
al nombre del alias de la tabla correspondiente.
Cualquier columna que contenga rangos superiores a un juego de valores predefinidos que es menor a 21
valores, deberá asociarse a un dominio estático que describa ese juego de valores.
Cualquier columna que contenga rangos superiores a un juego de valores dinámico, menor a 21 valores,
deberá asociarse a un dominio dinámico que describa ese juego de valores.
Cualquier columna que contenga un rango mayor a 20 valores, deberá tener una tabla de referencia.
Definir columnas de indicadores que se usarán para seleccionar un juego pequeño en una tabla como
opcional, y del tipo VARCHAR2(1) con valores permitidos “Y” y “N”. Si fueran necesarios 3 valores
lógicos, deberá describirse el por qué.
Para las columnas del tipo LOBs, especificar en la Descripción de la columna el formato interno que se
almacenará en la columna referenciando su standard, si existiera. Usar la palabra DATATYPE RAW en la
“Descripción”.
Las columnas opcionales deberán tener una nota en columna explicando el significado de un valor nulo, si
su significado fuera diferente al de un valor desconocido.
Definir el volumen inicial para cada columna (100% para columnas obligatorias). Especificar la fuente del
estimativo para las columnas opcionales, si existieran, en la “Descripción” de la columna con la palabra
VOLUME.
Definir el volumen final para cada columna (100% para columnas obligatorias). Especificar la fuente del
estimativo para las columnas opcionales, si existieran, en la “Descripción” de la columna con la palabra
VOLUME.
Todas las tablas referenciales y transaccionales requieren de columnas standard de auditoría:

NOMBRE DE TIPO DE DATO DOMINIO

COLUMNA
CREATED_BY VARCHAR2(30) TXT030
DATE_CREATED DATE
MODIFIED_BY VARCHAR2(30) TXT030
DATE_MODIFIED DATE

Las columnas de claves foráneas, deben mostrarse en la misma secuencia de sus claves primarias

Confidential <Company Name>, Page 13 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Sólo utillizar “Low Value” para ingresar un límite menor para la columna
Sólo utilizar “High Value” para ingresar un límite mayor para la columna.
Describir el propósito de la columna si no surge claramente de su nombre.

3.3.4Constraints

3.3.4.1Convención para nombrar constraints

Toda constraint creada debe seguir este standard.
Constraint de clave primaria
Nombrar la constraint de clave primaria de la siguiente manera:
<tabla_fuente/alias_de_la_vista>_PK
Ejemplo: para la tabla CLIENTE con alias CLI la clave primaria será CLI_PK
Constraint de clave única
Nombrar la constraint de clave única de la siguiente manera:
<alias_de_la_tabla>_<nombre UID>_UK
donde nombre UID es el nombre del identificador unívoco secundario de la entidad
Ejemplo: para la tabla ORDEN con alias ORD, que tiene 2 identificadores unívocos: ORD2 y ORD3, las
constraints serán:
ORD_ORD2_UK
ORD_ORD3_UK
Constraint de clave foránea
Nombrar la constraint de clave foránea de la siguiente manera:
Si existe sólo una constraint para la clave foránea:
<tabla_fuente/alias_de_la_vista>_<tabla_referida/alias_de_la_vista>_FK
Si existen múltiples constraints para clave foránea para la tabla referenciada, el identificador de la relación
debe identificar el propósito de dicha constraint:
<tabla_fuente/alias_de_la_vista>_<identificador_de_la relación>_FK
Check Constraints
Nombrar check constraint de la siguiente manera:
<tabla/alias_de_la_vista><número_opcional><_><nombre_columna_constraint_opcional>_CK
Columnas
Los columnas que son claves unívocas o primarias deben estar en mayúsculas. Si la información o el
negocio requieren minúsculas o ambas, agregar “Mixed case required” a las notas de las propiedades de
dicha columna.

3.3.4.2Definición
Constraint de clave primaria
Definir todas las columnas que son parte de la clave primaria como no actualizables. Si alguna de estas
columnas deben ser actualizables, crear una clave alternativa generada por el sistema para preservar la
clave primaria.
Definir todas las columnas que son parte de la clave primaria con NOT NULL.
Para las tablas, documentar la causa de las constraints de claves primarias no habilitadas

Confidential <Company Name>, Page 14 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Constraint de clave única

Las columnas de una constraint de clave única deben ser definidas todas como NULL o todas como NOT
NULL. Si debieran utilizarse ambos, deberá documentarse en la sección de notas de la constraint de clave
única.
Si las columnas se definen como NULL, el código de aplicación deberá forzar para cada registro de la tabla
alguna de estas condiciones:
Todas las columnas de clave única son NULL
Todas las columnas de clave única tienen un valor.
Las claves únicas pueden ser actualizadas si están protegidas por un índice.

3.3.5Indices

3.3.5.1Convención para nombrar índices

Índices de clave primaria o única
Crear un índice cuando crea las constraints para las claves primarias y únicas. No se deben crear índices de
Índices de clave foránea
Nombrar los índices de clave foránea de la siguiente manera:
<nombre_constraint_clave_foránea>_I
Si varias claves foráneas fueron creadas, y una de ellas fue modificada después, será necesario modificar
manualmente el nombre del índice asociado para que se corresponda con la constraint renombrada.
Ejemplo:
FND_ACT_FK con su índice FND_ACT_FK_I
La constraint fue modificada como FND_ACT_FROM_FK; por lo tanto el índice deberá ser:
FND_ACT_FROM_FK_I
Indices de columnas no claves
Nombrar los índices de columnas no clave de la siguiente manera:
<alias_de_la_tabla>_<nombre_columna>_NU_I
Nombrar los índices de tipo bit-mapped de la siguiente manera:
<alias_de_la_tabla>_<nombre_columna>_BM_I
Si el índice es sobre varias columnas, <nombre_de_la_columna> será el nombre de la primera columna de
dicho índice.

3.3.5.2Definición
Crear índices para todas las claves foráneas, al menos que no se considere necesario por performance o
mantenimiento . Esto deberá documentarse en “Description” de la definición de la clave foránea, utilizando
la palabra NO FK INDEX.
Crear índices para aquellas columnas que generalmente forman parte de la condición de WHERE.
No definir índices unívocos, conviene definir constraints de claves primarias.

Confidential <Company Name>, Page 15 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

No es conveniente modificar el valor por default de “Init Trans”, a pesar de presumir que el índice será
utilizado por muchos usuarios simultáneamente. Se deberá documentar el cambio de este valor en
“Description” en la definición del índice, utilizando la palabra INIT TRANS.
No modificar el valor por default para “Max Trans”.
Documentar cualquier decisión de diseño en “Description” en la definición del índice, usando la palabra
FREE SPACE.
En “Description” en la definición del índice, documentar las razones de las diferencias entre la definición
de la secuencia de columna del índice y la secuencia de columna de la constraint, utilizando la palabra
COLUMN SEQUENCE.

3.3.6Secuencias

3.3.6.1Convención para nombrar secuencias

Nombrar la única secuencia para una tabla o vista de la siguiente manera:
<prefijo_de_la_aplicación>_<alias_de_la_tabla/vista>_SEQ
Nombrar múltiples secuencias para una misma tabla o vista de la siguiente manera:
<prefijo_de_la_aplicación>_<nombre_lógico>_SEQ
Este <nombre_lógico> puede ser el nombre de una columna o cualquier nombre que represente el propósito
de la secuencia.

3.3.6.2Definición
Describir brevemente el propósito y utilización de cada secuencia.
Utilizar secuencias ascendentes. De no ser así, detallarlo en “Description” en la definición de la secuencia.
Incrementar las secuencias de a 1. De no ser así, detallarlo en “Description” en la definición de la
secuencia.
No tener secuencias generadas en el orden exacto de su requerimiento. Si fuera necesario lo contrario,
deberá documentarse en “Description” de la definición de la secuencia. Una buena excepción es el uso de
un generador de secuencia que funcione como un reloj interno, para indicar el orden exacto en que ciertos
eventos ocurren, especificando un nuevo valor de secuencia. “Minimum” o “Maximum”.
No utilizar valores máximos y mínimos más extensos que la longitud de la columna en donde se aplica la
secuencia.

3.3.7Vistas

3.3.7.1Convención para nombrar vistas

Nombrar una vista de la siguiente manera:
<nombre_de_la_tabla>_V

El largo máximo para el nombre de una vista es de 26 caracteres. Si excede esta cantidad, utilizar el alias de
la tabla, abreviaciones o siglas. Las vistas deben tener nombres en singular como las tablas.

3.3.7.2Definición
Definir un alias para cada vista. Debe tener una longitud exacta de 3 caracteres y debe ser único.
No utilizar un prefijo de columna para las columnas de las vistas.

Confidential <Company Name>, Page 16 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

Definir el propósito y uso de la vista.

Utilizar el mismo alias que para la tabla de referencias. Si la tabla es usada más de una vez en la definición
de la vista, agregarle un número de secuencia.
Las columnas de las vistas deben tener el mismo nombre de las columnas de la tabla de referencia. Para
columnas de una vista no referidas a tablas, asignarle los nombres en base a los standards de nombres.
Si la columna de la tabla referida pertenece a un dominio, la columna de la vista deberá pertenecer al
mismo dominio.

3.3.8Triggers

3.3.8.1Convención para nombrar triggers

Nombrar un trigger de base de la siguiente manera:
<prefijo_de_la_aplicación>_T<alias_de_la_tabla>_<when><tipo>_<nivel>
<when> debe abreviarse así:
B = Before
A = After
<tipo> debe abreviarse así:
I = Insert
U = Update
D = Delete
<nivel> debe abreviarse así:
R = Row
S = Statement

3.3.8.2Definición
Definir las condiciones que aplican a todas las reglas del negocio, en la condición del trigger (Trigger
When condition).

3.4Apéndice A – Abreviaturas y Siglas.

A ser completado.
3.5Apéndice B - Palabras Reservadas por Oracle
ACCESS ADD * ALL * ALTER * AND * ANY * AS * ASC *

Confidential <Company Name>, Page 17 of 18

<Project Name> Version: <1.0>
Design Guidelines Database Date: <dd/mmm/yy>
<document identifier>

AUDIT BETWEEN * BY * CHAR * CHECK * CLUSTER COLUMN COMMENT

COMPRESS CONNECT * CREATE * CURRENT DATE * DECIMAL * DEFAULT * DELETE *

*

DESC * DISTINCT * DROP * ELSE * EXCLUSIVE EXISTS FILE FLOAT *

FOR * FROM * GRANT * GROUP * HAVING * IDENTIFIED IMMEDIAT IN *

E*

INCREMENT INDEX INITIAL INSERT * INTEGER * INTERSECT INTO * IS *

*

LEVEL * LIKE * LOCK LONG MAXEXTENTS MINUS MLSLABEL MODE

MODIFY NOAUDIT NOCOMPRESS NOT * NOWAIT NULL * NUMBER OF *

OFFLINE ON * ONLINE OPTION * OR * ORDER * PCTFREE PRIOR *

PRIVILEGES PUBLIC * RAW RENAME RESOURCE REVOKE * ROW ROWID

*

ROWNUM ROWS * SELECT * SESSION SET * SHARE SIZE * SMALLINT

* *

START SUCCESSFUL SYNONYM SYSDATE TABLE * THEN * TO * TRIGGER

UID UNION * UNIQUE * UPDATE * USER * VALIDATE VALUES * VARCHAR

*

VARCHAR2 VIEW * WHENEVER * WHERE WITH *

Confidential <Company Name>, Page 18 of 18