<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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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

Confidential

©<Company Name>,

Page 2 of 18

<Project Name> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Table of Contents
1. Terminología y conceptos básicos 1.1 Entidad 1.2 Atributos 1.3 Clave Primaria 1.4 Relaciones 1.4.1 Tipo de Relaciones. 2. Reglas de Normalización 2.1 Primera forma normal: 2.2 Segunda forma normal 2.3 Tercera forma normal 3. Convenciones de denominación. 3.1 Reglas Generales : 3.2 Convenciones del modelo lógico (modelo de datos) 3.2.1 Denominación de esquemas (Schema). 3.2.2 Denominación de Entidades. 3.2.3 Dominios 3.2.4 Atributos 3.2.5 Relaciones 3.3 Convenciones del modelo físico. 3.3.1 Reglas Generales 3.3.2 Tablas 3.3.3 Columnas 3.3.4 Constraints 3.3.5 Indices 3.3.6 Secuencias 3.3.7 Vistas 3.3.8 Triggers 3.4 Apéndice A – Abreviaturas y Siglas. 3.5 Apéndice B - Palabras Reservadas por Oracle 4 4 4 4 4 4 4 5 5 5 5 6 6 6 7 9 9 10 11 11 12 12 14 15 16 16 17 17 17

Confidential

©<Company Name>,

Page 3 of 18

<Project Name> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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 Entidad Atributo Fila Lógico Objeto Clase Atributo Objeto Físico Tabla Columna, campo 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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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 C C

D D D C C

E

A

B

E

D D

A

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 A

B D

C

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: • Confidential Esquemas ©<Company Name>, Page 5 of 18

<Project Name> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

• 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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier> Ejemplo: ESP puede ser el alias para la entidad Especie. DETORD puede ser el alias para la entidad Detalle Orden.

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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 # * O Descripción Identificador Clave Primaria (UID) Atributo obligatorio (not null) 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 Monto Código Fecha Sigla MT CD DT Tipo NUMBER VARCHAR2 DATE Number VARCHAR2 NUMBER VARCHAR2 Significado Un valor Monetario Una combinación de uno o mas números, letras, caracteres especiales. 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. Una combinación de unos o más números que señalen un objeto específico, pero que no tenga ningún significado. Identificador de un objeto expresado por una palabra o frase. Un valor no monetario Un conjunto de caracteres. ©<Company Name>, Page 9 of 18

Identificador ID Nombre Cantidad Texto Confidential NM QY TX

<Project Name> Design Guidelines Database <document identifier> Completar Identificando Nuevos Clases

Version: <1.0> Date: <dd/mmm/yy>

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 HASTAENTIDAD (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 Confidential tiene ©<Company Name>, pertenece a Page 10 of 18

<Project Name> Design Guidelines Database <document identifier> Para Indicar Responsabilidad Localización Generación Acción Elementos Contenidos Afectación Utilización Asignación Designación Supertipo/Subtipo Acuerdo Inclusión Adhesión Comercialización Presentación Relaciones múltiples con un rol diferenciador

Version: <1.0> Date: <dd/mmm/yy>

esta a cargo de esta ubicado en genera realiza efectúa comprende afecta a utiliza está asignado a designa a puede ser firma incluye adhiere comercializa presenta relaciona a

Es responsable de Es ubicación de Es generado por Es realizado por Es efectuado por Es comprendido por Es afectado por Es utilizado por tiene asignado a Es designado por Es (subtipo) Es firmado por Es incluido en Es adherido por Es comercializado por Es presentado por Es relacionado con

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> Design Guidelines Database <document identifier> 3.3.2Tablas

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier> (Apendice A)

Version: <1.0> Date: <dd/mmm/yy>

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 COLUMNA CREATED_BY DATE_CREATED MODIFIED_BY DATE_MODIFIED

TIPO DE DATO VARCHAR2(30) DATE VARCHAR2(30) DATE

DOMINIO TXT030

TXT030

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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier> Definir el propósito y uso de la vista.

Version: <1.0> Date: <dd/mmm/yy>

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> Design Guidelines Database <document identifier> AUDIT COMPRESS DESC * FOR * BETWEEN * CONNECT * DISTINCT * FROM * BY * CREATE * DROP * GRANT * INITIAL LOCK CHAR * CHECK *

Version: <1.0> Date: <dd/mmm/yy>

CLUSTER DECIMAL * EXISTS

COLUMN DEFAULT * FILE

COMMENT DELETE * FLOAT * IN * IS * MODE OF * PRIOR * ROWID SMALLINT * TRIGGER VARCHAR *

CURRENT DATE * * ELSE * GROUP * INSERT * LONG EXCLUSIVE HAVING * INTEGER *

IDENTIFIED IMMEDIAT E* INTERSECT INTO * * MLSLABEL NUMBER PCTFREE ROW SIZE * TO * VALUES *

INCREMENT INDEX LEVEL * MODIFY OFFLINE LIKE * NOAUDIT ON *

MAXEXTENTS MINUS NOWAIT NULL * ORDER * REVOKE * SHARE THEN * VALIDATE

NOCOMPRESS NOT * ONLINE RAW SELECT *

OPTION * OR * RENAME SESSION * SYSDATE RESOURCE SET * TABLE *

PRIVILEGES PUBLIC * * ROWNUM START UID VARCHAR2 ROWS *

SUCCESSFUL SYNONYM UNION * VIEW * UNIQUE * WHENEVER *

UPDATE * USER * WHERE WITH *

Confidential

©<Company Name>,

Page 18 of 18