Documentos de Académico
Documentos de Profesional
Documentos de Cultura
DES MAN EstandarBaseDatos v1.0
DES MAN EstandarBaseDatos v1.0
u y
nombre_cliente
tipo_documento
junio de 2019
Este documento describe el estándar de nomenclatura para base de datos utilizados en el departamento
de Desarrollo.Este documento contiene los formatos necesarios para cualquier documento de índole
general.
Archivo: 423034707.doc
Páginas: 15
Contacto: gat@infocorop.com.uy
Version 1.0
TABLA DE CONTENIDO
Introducción.................................................................................................................................................. 3
Objetivo..................................................................................................................................................... 3
Alcance..................................................................................................................................................... 3
Audiencia.................................................................................................................................................. 3
Fuentes utilizadas..................................................................................................................................... 3
Condiciones de uso de este documento................................................................................................... 3
Convenciones utilizadas en este documento............................................................................................ 4
Terminología y definiciones....................................................................................................................... 4
Guía rápida................................................................................................................................................... 5
Convenciones de nomenclatura................................................................................................................ 5
Convenciones de Nomenclatura.................................................................................................................. 6
Guías genéricas y buenas prácticas......................................................................................................... 6
Nomenclatura para los elementos de una base de datos.........................................................................6
La base de datos o schema.................................................................................................................. 6
Tablas.................................................................................................................................................... 7
Vistas.................................................................................................................................................... 7
Columns................................................................................................................................................ 8
Stored Procedures................................................................................................................................ 8
Funciones definidas por el usuario........................................................................................................ 8
Triggers................................................................................................................................................. 8
Tipos de datos definidos por el usuario................................................................................................. 9
Primary keys.......................................................................................................................................... 9
Foreign keys.......................................................................................................................................... 9
Indexes.................................................................................................................................................. 9
Variables................................................................................................................................................ 9
Apendice A................................................................................................................................................. 10
Modelo conceptual.................................................................................................................................. 10
MAL Ejemplo........................................................................................................................................... 11
Ejemplo sugerido.................................................................................................................................... 11
Apendice B................................................................................................................................................. 13
Relaciones 1:N........................................................................................................................................ 13
Relaciones N:M....................................................................................................................................... 13
Apendice C................................................................................................................................................. 14
Stored Procedure.................................................................................................................................... 14
BIBLIOGRAFÍA........................................................................................................................................... 15
Página 2 de 15
INTRODUCCIÓN
El presente documento describe la nomenclatura a utilizar en el diseño de base de datos en el
departamento de desarrollo de Infocorp.
Objetivo
El objetivo de este documento es institucionalizar buenas prácticas y estandarizar la nomenclatura de
nombres utilizada en el diseño y mantenimiento de bases de datos en el departamento de desarrollo de
Infocorp.
Alcance
Este documento aplica al diseño y mantenimiento de base de datos en el departamento de desarrollo
Infocorp haciendo foco en dos manejadores de bases de datos en particular: MS SQL Server y Oracle.
Por defecto todas las indicaciones que se presentan aplican a todos los manejadores a menos que se
especifique lo contrario.
En caso de querer aplicar la nomenclatura para otro manejador de base de datos, distinto de MS SQL
Server u Oracle, se debe decidir si alinearse a la nomenclatura MS SQL Server u Oracle definidas en
este documento en base a factores como:
Tipo de soporte case sensitive que tenga el manejador y el cliente utilizado.
La existencia o no de un estándar para dicho manejador
Audiencia
Este documento se encuentra dirigido a programadores, analistas, jefes de proyecto y especialistas
técnicos del departamento de desarrollo de Infocorp, que tengan entre sus tareas realizar el diseño o
mantenimiento de una base de datos.
Fuentes utilizadas
Entre las fuentes utilizadas para la creación de este documento se encuentran diferentes publicaciones
sobre nomenclatura de base de datos, las cuales son referenciadas en la sección de bibliografía, así
como también se ha intentado seguir las prácticas utilizadas por Microsoft en el diseño de la base de
datos Northwind.
Página 3 de 15
Convenciones utilizadas en este documento
Abreviaciones Descripción
OBL Obligatorio
REC Recomendado
Negrita Texto con énfasis adicional que debe ser considerado importante.
Siempre Indica que esta regla DEBE ser respetada, en los términos de este manual.
Nunca Indica que esta acción NO DEBE ser realizada, en los términos de este manual.
No hacer Indica que esta acción NO DEBE ser realizada, en los términos de este manual.
Indica que esta práctica debe ser evitada siempre que sea posible, pero pueden existir
Evitar
excepciones AUTORIZADAS para su utilización.
Intentar Indica que esta práctica debe aplicarse siempre que sea posible y apropiado.
Terminología y definiciones
Término Descripción
Una palabra con la primera letra en minúsculas, y la primera letra de cada una de las
Camel Case palabras subsecuentes en mayúsculas.
Ejemplo: customerName
Una palabra con la primera letra en mayúsculas, y la primera letra de cada palabra
Pascal Case subsecuente también en mayúsculas.
Ejemplo: CustomerName
Hungarian Comienzan con una o mas letras en minúscula que denotan el tipo de la variable
Notation Ejemplo: string sVariable
Underscore
Indica palabras separadas con infraguión. Ejemplo: CUSTOMER_DETAIL
Separated
Página 4 de 15
GUÍA RÁPIDA
En esta sección se incluye un breve resumen de los principales estándares descriptos a los largo de este
documento. Estas tablas no son detalladas en sus descripciones, pero brindan una rápida referencia a los
elementos.
Convenciones de nomenclatura
c Camel case
P Pascal case
X No aplica
<VAR> Indica que esa posición debe sustituirse por el valor del campo VAR. En el caso de la
variable TABLE se hace la siguente distinción: TABLE_S representa el nombre de una tabla
en singular (ej: Customer), mientras que TABLE_P indica el nombre de una tabla en plural
(ej: Customers).
Página 5 de 15
CONVENCIONES DE NOMENCLATURA
A continuación se presentan un conjunto de guías y buenas prácticas, así como la nomenclatura para
utilizar en el diseño de bases de datos.
Página 6 de 15
Tablas
Las tablas deben nombrarse:
en plural,
en inglés
sin utilizar espacios en blanco
Si el nombre es compuesto solo la última palabra debe ir en plural. Por ejemplo: ProductSales es
correcto mientras que ProductsSales NO es correcto.
MS SQL Server
Deben nombrarse usando notación pascal.
Ejemplo: Customers, Orders
ORACLE
Deben nombrarse con notación Underscore Separated, en mayúsculas.
Ejemplos: CUSTOMERS, ORDERS
En aquellos escenarios en donde se quiera agrupar tablas según cierta lógica del negocio se
puede agregar un prefijo que permita esto. Por ejemplo, si en un mismo esquema se quieren
almacenar empleados del departamento de recursos humanos se pueden definir de la siguiente
manera:
HR_EMPLOYEES
Vistas
Las vistas deben nombrarse con la misma notación definida para nombrar tablas, pero prefijadas usando
VW_.
Ejemplo:
MS SQL Server: vw_SalesByCountry,
Oracle: VW_SALES_BY_COUNTRY
Página 7 de 15
Columns
Los campos de una tabla corresponden a los atributos de una entidad, describen propiedades de la
misma.
Las columnas deben ser nombradas según los lineamientos a continuación:
1. Los nombres deben ser simples, representativos e intuitivos.
2. Los nombres de las columnas de una tabla deben estar expresados en singular.
3. El campo clave de una tabla de nombrarse como el nombre de la tabla mas el sufijo Id. Ejemplo:
Para una tabla de clientes Customers, se definirían las claves:
o MS SQL Server: CustomerId,
o Oracle: CUSTOMER_ID.
4. Campos que representen la misma entidad del mundo real, deben estar nombrados de la misma
manera en todas las tablas de un esquema. Por ejemplo nombrar la clave de la tabla Sales en
una tabla como SalesId y en otra SalesKey es incorrecto.
5. Se desaconseja prefijar sistemáticamente TODOS los campos de una tabla con el nombre de la
tabla o una abreviación del mismo. Entendemos que esto agrega un nivel de redundancia y
complejidad al sistema que no es necesario en manejadores modernos.
MS SQL SERVER
Usar notación Pascal
ORACLE
Usar notación Underscore Separated
Stored Procedures
Los stored procedures son un espacio estándar para incluir lógica en la base de datos, expresada en un
lenguaje de scripting que extiende SQL. Los SP pueden ser invocados utilizando SQL estándar desde
una aplicación, mediante la instrucción EXEC.
Los stored procedures deben ser nombrados según la siguiente nomenclatura:
MS SQL SERVER
Usar notación Pascal
Ejemplo: InsertCustomer
ORACLE
Usar notación Underscore Separated
Ejemplo: INSERT_CUSTOMER
El código SQL extendido de un stored procedure debe ir en Mayúsculas. Ver apéndice C como ejemplo.
Funciones definidas por el usuario
Las funciones definidas por el usuario son un mecanismo no totalmente estándar para incluir lógica en la
base de datos, expresada en un lenguaje de scripting que extiende SQL.
La nomenclatura definida es la misma que para los stored procedures.
Triggers
Un trigger es lógica alojada en la base de datos asociada a una determinada acción sobre una tabla. La
lógica es disparada cuando ocurre la acción correspondiente.
Un trigger no tiene sentido fuera de una tabla y un trigger tiene asociada siempre una operación, por lo
que dicha información debe estar asociada al nombre del trigger.
Página 8 de 15
<TABLA>_<OPERACION>[_AUX]
Ejemplo: Customer_Insert_InsertInUsers
Tipos de datos definidos por el usuario
Los tipos de datos definidos por el usuario son un mecanismo para mantener la consistencia de tipos en
la base de datos. Cuando un mismo tipo de datos es utilizado en varias tablas, en vez de definirlo cada
vez por separado, se define un “user defined data type” para luego referenciarlo desde todas ellas y
mantener así centralizada su definición.
MS SQL SERVER
Usar notación Pascal
Ejemplo: CustomerId
ORACLE
Usar notación Underscore Separated
Ejemplo: CUSTOMER_ID
Primary keys
La clave primaria es un conjunto de campos que identifica de forma única un registro en una tabla. Son
un caso particular de un índice. La nomenclatura es la siguiente:
PK_<TABLA>
Ejemplo: PK_Customers
Foreign keys
Las foreign keys son usadas para definir vínculos entre tablas relacionadas. Una foreign key establece
una relación entre una o más columnas de una tabla y la clave primaria de la tabla referenciada. Como
patrón para la nomenclatura de la foreign key elegimos el siguiente.
FK_<TABLA_QUE_REFERENCIA>+<CAMPO_QUE_REFERENCIA>_<TABLA_REFERENCIADA>+<CAMPO_REFERENCI
ADO>
Basado en el patrón dado, voy a nombrar la foreign key que referencia el campo CUSTOMER_ID de la
tabla CUSTOMERS desde la tabla ORDERS y el campo CUSTOMER_ID como :
FK_ORDERSCUSTOMERID_CUSTOMERSCUSTOMERID
Indexes
Los índices son un mecanismo para aumentar la eficiencia de localización y acceso de un registro en una
tabla en la base de datos, opcionalmente asegurando unicidad de los valores del índice. La definición de
índices tiene un impacto positivo en los tiempos de consulta de registro y uno negativo en los de inserción
y actualización de los campos del índice.
Los índices están asociados a una tabla y a un conjunto de campos de la tabla, a su vez pueden ser
únicos o no y pueden estar definidos en cluster o no. La nomenclatura elegida para nombrarlos es la
siguiente:
[IDX_]<TABLA>_<CAMPO>[_AUX]
Prefijar el índice es opcional, pero de hacerlo se debe usar el prefijo especificado.
Ejemplo: OrderDetails_OrderId_U_NC
El ejemplo corresponde a un índice definido sobre la tabla OrderDetails, sobre el campo OrderId, unico y
nonclustered.
Variables
Cuando las variables corresponden columnas de una tabla, deben ser nombrados de la misma manera
que la columna. La notación elegida para definir las variables es camel. Ver apéndice C como ejemplo.
Página 9 de 15
APENDICE A
En esta sección se presenta un modelo conceptual para el cual se desarrollan dos esquemas
relacionales, el primero como ejemplo de lo que NO se debe hacer, mientras que el segundo según las
prácticas sugeridas.
Modelo conceptual
El diagrama a continuación representa una realidad hipotética cuya información se quiere almacenar en
base de datos..
Página 10 de 15
MAL Ejemplo
El siguiente es un mal diseño de esquema relacional para la realidad anteriormente planteada.
1- Mezcla idiomas
2- Tablas en singular
3- Un mismo campo
recibe distintos
nombres
4- No define FK
5- No define PK
6- Las entidades Orders
y OrderItems residen
en una misma tabla,
campos redundantes
(no es 3NF)
7- Abreviaciones
8- Pascal case no
respetado
Ejemplo sugerido
El siguiente es el ejemplo sugerido de diseño para la realidad anteriormente planteada:
Página 11 de 15
Observaciones:
Como criterio se prefijaron con el
nombre de la tabla aquellas columnas
cuyos nombres se encuentran
repetidos en varias tablas, para evitar
problemas de ambigüedad en las
consultas
En la tabla Orders se define una clave
de un solo campo para evitar incluir
el campo CompanyId en la clave de
OrderItems
Página 12 de 15
APENDICE B
En esta sección se presentan guías para la definición de esquemas relacionales según un modelo
conceptual.
Relaciones 1:N
Para la definición de tablas que correspondan a una relación 1:N como puede ser la siguiente:
Relaciones N:M
Para la definición de tablas que correspondan a relaciones N:M com puede ser la siguiente:
Página 13 de 15
APENDICE C
En esta sección se presenta un ejemplo de stored procedure MS SQL Server que sigue la nomenclatura
propuesta:
Stored Procedure
CREATE PROCEDURE dbo.DeleteRoleByName
@name nvarchar(256)
AS
DECLARE @roleID int, @firstOpError tinyint
EXEC GetRoleIdByName @name, @roleID OUT
IF (@roleID IS NULL) RAISERROR('No Role with that name', 16, 99)
BEGIN
BEGIN TRANSACTION
DELETE FROM UserRoles
WHERE RoleID = @roleID
SELECT @firstOpError = @@ERROR
Página 14 de 15
BIBLIOGRAFÍA
1. Data Object Naming conventions by Kondreddi, Narayana Vyas
(http://vyaskn.tripod.com/object_naming.htm)
2. Ten Things I hate about you by Celko, Joe
(http://www.intelligententerprise.com/001205/celko1_1.jhtml )
3. Estándar de nomenclatura para bases de datos Oracle, Infocorp
Página 15 de 15