guia diseño de base de datos

<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 HistoryDate Version Description Author

<dd/mmm/yy> <x.x> <details> <name>

Confidential <Company Name>, 2023 of 18


Table of Contents

1. Terminología y conceptos básicos 4

1.1 Entidad 41.2 Atributos 41.3 Clave Primaria 41.4 Relaciones 4

1.4.1 Tipo de Relaciones. 4

2. Reglas de Normalización 4

2.1 Primera forma normal: 52.2 Segunda forma normal 52.3 Tercera forma normal 5

3. Convenciones de denominación. 5

3.1 Reglas Generales : 63.2 Convenciones del modelo lógico (modelo de datos) 6

3.2.1 Denominación de esquemas (Schema). 63.2.2 Denominación de Entidades. 73.2.3 Dominios 93.2.4 Atributos 93.2.5 Relaciones 10

3.3 Convenciones del modelo físico. 113.3.1 Reglas Generales 113.3.2 Tablas 123.3.3 Columnas 123.3.4 Constraints 143.3.5 Indices 153.3.6 Secuencias 163.3.7 Vistas 163.3.8 Triggers 17

3.4 Apéndice A – Abreviaturas y Siglas. 183.5 Apéndice B - Palabras Reservadas por Oracle 18



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ísicoEntidad Clase TablaAtributo Atributo Columna, campoFila Objeto Registro

1.1 Entidad

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.2 Atributos

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.3 Clave 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.4 Relaciones

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

1.4.1 Tipo 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.



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.1 Primera forma normal:

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

2.2 Segunda forma normal

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

2.3 Tercera forma normal

Eliminar atributos con dependencias transitivas

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


A B C D E

C DC D

C DC D

A B E

A C D

A B C DA B C

A D

A B C A B

B C


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.1 Reglas 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.2 Convenciones del modelo lógico (modelo de datos)

3.2.1 Denominació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.

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.2 Denominación de Entidades.

3.2.2.1 Nombres 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.2 Alias 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.

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



DETORD puede ser el alias para la entidad Detalle Orden.

3.2.2.3 Entidad 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.4 Entidad 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.5 Entidad 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.6 Cross-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.7 Diagramas 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.8 Usos 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?.

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.3 Dominios

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.4 Atributos

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 SignificadoMonto MT NUMBER Un valor MonetarioCó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 monetarioTexto TX VARCHAR2 Un conjunto de caracteres.

Completar Identificando Nuevos Clases



3.2.4.1 Definiciones

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.5 Relaciones

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.1 Opcionalidad 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 IndicarPosesión tiene pertenece aResponsabilidad esta a cargo de Es responsable deLocalización esta ubicado en Es ubicación deGeneración genera Es generado por



Para IndicarAcción realiza

efectúaEs realizado porEs efectuado por

Elementos Contenidos comprende Es comprendido porAfectación afecta a Es afectado porUtilización utiliza Es utilizado porAsignación está asignado a tiene asignado aDesignación designa a Es designado porSupertipo/Subtipo puede ser Es (subtipo)Acuerdo firma Es firmado porInclusión incluye Es incluido enAdhesión adhiere Es adherido porComercialización comercializa Es comercializado porPresentación presenta Es presentado porRelaciones múltiples con un rol diferenciador

relaciona a Es relacionado con

3.3 Convenciones del modelo físico.

3.3.1 Reglas Generales

3.3.1.1 Database

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.2 Claves

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.3 Otras 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.



3.3.2 Tablas

3.3.2.1 Convenció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.2 Definició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.3 Columnas

3.3.3.1 Convenció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.

(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.2 Definció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

TIPO DE DATO DOMINIO

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

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.4 Constraints

3.3.4.1 Convención para nombrar constraints

Toda constraint creada debe seguir este standard.

Constraint de clave primariaNombrar 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 únicaNombrar 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áneaNombrar 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 ConstraintsNombrar check constraint de la siguiente manera:

<tabla/alias_de_la_vista><número_opcional><_><nombre_columna_constraint_opcional>_CK

ColumnasLos 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.2 Definició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

Constraint de clave únicaLas 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.5 Indices

3.3.5.1 Convención para nombrar índices

Índices de clave primaria o únicaCrear un índice cuando crea las constraints para las claves primarias y únicas. No se deben crear índices de

Índices de clave foráneaNombrar 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 clavesNombrar 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.2 Definició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.

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.6 Secuencias

3.3.6.1 Convenció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.2 Definició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.7 Vistas

3.3.7.1 Convenció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.2 Definició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.

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.8 Triggers

3.3.8.1 Convenció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.2 Definición

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



3.4 Apéndice A – Abreviaturas y Siglas.

A ser completado.

3.5 Apéndice B - Palabras Reservadas por Oracle

ACCESS ADD * ALL * ALTER * AND * ANY * AS * ASC *

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 IMMEDIATE *

IN *

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 *


guia diseño de base de datos

Documents