Departamento de Desarrollo y Consultora www.infocorp.com.uy desarrollo@infocorp.com.

uy

nombre_cliente

Estndar de nomenclatura para Base de Datos

tipo_documento
July de 2013 Este documento describe el estndar 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: Pginas: Fecha: Autor: Contacto: Version

155992076.doc 15 3/8/2013 21:10:00 a3/p3 GAT: Grupo Apoyo Tcnico gat@infocorop.com.uy 1.0

TABLA DE CONTENIDO
Estndar de nomenclatura para Base de Datos.......................................................................................1 Tabla de contenido....................................................................................................................................... 2 Introduccin.................................................................................................................................................. 3 Objetivo..................................................................................................................................................... 3 Alcance..................................................................................................................................................... 3 Audiencia.................................................................................................................................................. 3 Fuentes utilizadas..................................................................................................................................... 3 Condiciones de uso de este documento................................................................................................... 3 Convenciones utilizadas en este documento............................................................................................ 4 Terminologa y definiciones...................................................................................................................... 4 Gua rpida................................................................................................................................................... 5 Convenciones de nomenclatura................................................................................................................ 5 Convenciones de Nomenclatura................................................................................................................... 6 Guas genricas y buenas prcticas......................................................................................................... 6 Nomenclatura para los elementos de una base de datos.........................................................................6 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 BIBLIOGRAFA........................................................................................................................................... 15

Pgina 2 de 15

INTRODUCCIN
El presente documento describe la nomenclatura a utilizar en el diseo de base de datos en el departamento de desarrollo de Infocorp.

Objetivo
El objetivo de este documento es institucionalizar buenas prcticas y estandarizar la nomenclatura de nombres utilizada en el diseo y mantenimiento de bases de datos en el departamento de desarrollo de Infocorp.

Alcance
Este documento aplica al diseo 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 estndar para dicho manejador

Audiencia
Este documento se encuentra dirigido a programadores, analistas, jefes de proyecto y especialistas tcnicos del departamento de desarrollo de Infocorp, que tengan entre sus tareas realizar el diseo o mantenimiento de una base de datos.

Fuentes utilizadas
Entre las fuentes utilizadas para la creacin de este documento se encuentran diferentes publicaciones sobre nomenclatura de base de datos, las cuales son referenciadas en la seccin de bibliografa, as como tambin se ha intentado seguir las prcticas utilizadas por Microsoft en el diseo de la base de datos Northwind.

Condiciones de uso de este documento

Una regla puede romperse slo ante razones justificadas, discutidas, con previa autorizacin del responsable del producto, y en caso que no pueda aplicarse ninguna alternativa razonable. El autor de la excepcin, obligatoriamente debe documentar el cdigo explicando la causa de la violacin de la regla. Las preferencias personales no se consideran una razn justificada.

Pgina 3 de 15

Convenciones utilizadas en este documento

Abreviaciones OBL REC Negrita Siempre Nunca No hacer Evitar Intentar Razn Descripcin Obligatorio Recomendado Texto con nfasis adicional que debe ser considerado importante. Indica que esta regla DEBE ser respetada, en los trminos de este manual. Indica que esta accin NO DEBE ser realizada, en los trminos de este manual. Indica que esta accin NO DEBE ser realizada, en los trminos de este manual. Indica que esta prctica debe ser evitada siempre que sea posible, pero pueden existir excepciones AUTORIZADAS para su utilizacin. Indica que esta prctica debe aplicarse siempre que sea posible y apropiado. Explica el propsito y las causas que motivan la regla o recomendacin.

Terminologa y definiciones
Trmino Descripcin Una palabra con la primera letra en minsculas, y la primera letra de cada una de las palabras subsecuentes en maysculas. Ejemplo: customerName Magic Number Cualquier literal numrico utilizado dentro de una expresin (o inicializacin de variable) que no posea un significado claro. Usualmente este trmino no aplica a los valores 0 y 1 y cualquier otra expresin numrica equivalente que su evaluacin resulte 0. Una palabra con la primera letra en maysculas, y la primera letra de cada palabra subsecuente tambin en maysculas. Ejemplo: CustomerName Hungarian Notation Underscore Separated Comienzan con una o mas letras en minscula que denotan el tipo de la variable Ejemplo: string sVariable Indica palabras separadas con infraguin. Ejemplo: CUSTOMER_DETAIL

Camel Case

Pascal Case

Pgina 4 de 15

GUA RPIDA
En esta seccin se incluye un breve resumen de los principales estndares descriptos a los largo de este documento. Estas tablas no son detalladas en sus descripciones, pero brindan una rpida referencia a los elementos.

Convenciones de nomenclatura
c P _ X [] <VAR> Camel case Pascal case Prefijo con infraguin (underscore) No aplica Lo se encuentre contenido entre parntesis rectos significa que es opcional. Indica que esa posicin debe sustituirse por el valor del campo VAR. En el caso de la variable TABLE se hace la siguente distincin: 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). Underscore Separated Upper Case

USU

Elemento Base de datos Schema Tablas Vistas Stored Procedures

MS SQL Server

Oracle

<COUNTRY>_<CUSTOMER>_<SOLUTION>[-AUX] <COUNTRY>_<CUSTOMER>_<SOLUTION>[-AUX] P & plural VW_<VIEW_P> P USU USU & plural

Observaciones Ejemplo: UY_Infocorp_Northwind Aplica nicamente en Oracle Ejemplo: UY_Infocorp_Northwind Evitar espacios en blanco Ejemplo: Customers Evitar espacios en blanco Ejemplo SQL Server: vw_SalesByCountry Ejemplo Oracle: VW_SALESBYCOUNTRY Evitar el uso de prefijos, tipo sp_ y espacios en blanco Ejemplos: InsertCustomer, GetOrdersByDate

User defined functions Triggers

P <TABLE_S>_<OPERATION>[_<AUX>]

USU Un trigger esta siempre asociado con una tabla y una operacin y no tiene sentido fuera de ellos. Ejemplos: Orders_Insert_ValidateData, Customer_Insert_ReplicateEmail USU Para las claves <TABLE_S>_ID USU No nombrar de forma distinta campos que representen lo mismo. Ejemplos: OrderId, FullName, Address, OrderDate Ejemplo: customerId Ejemplo: PK_Customers Ejemplo: FK_OrdersCustomerId_CustomersCustomerId Ejemplo: OrderDetails_OrderID_U_NC En el ejemplo presentado _U correspondera a Unique y _NC correspondera a NonClustered. c

Columns

P Para las claves <TABLE_S>Id

User defined data types Primary keys Foreign keys

C PK_<TABLE_P>

FK_<TABLE_P><FIELD>_<REF_TABLE_P><REF_FIELD>

Indexes Variables

[IDX_]<TABLE_P>_<FIELD>[_AUX] c

Pgina 5 de 15

CONVENCIONES DE NOMENCLATURA
A continuacin se presentan un conjunto de guas y buenas prcticas, as como la nomenclatura para utilizar en el diseo de bases de datos.

Guas genricas y buenas prcticas

1. OBL Utilizar nombres en ingls para todos los elementos de la base de datos , tablas, vistas, campos, etc. 2. REC Utilizar nombres descriptivos para los campos. Utilizar nombres que resulten intuitivos y permitan entender el significado de los campos (mnemotcnicos). Evitar las abreviaciones, y si esto no es posible documentarlas bien. 3. OBL- ORACLE, utilizar solo maysculas para nombrar los elementos de la base de datos, schemas, tablas y campos. 4. REC No nombrar campos que representan lo mismo de forma distinta . La forma en que se nombran iguales propiedades debe ser consistente en todo un esquema. Ejemplo: Nombrar al campo clave de la tabla Customers como Id, y despus referenciarlo en otras tablas como CustomerId es INCORRECTO. El campo debe ser nombrado CustomerId en todos los casos que se quiera almacenar una clave de Customers. 5. REC Evitar tener demasiadas columnas NULLABLES en una tabla . Esto es indicio de un esquema poco o nada normalizado. Falta de normalizacin puede conllevar problemas de consistencia en los datos en la medida que un mismo campo se puede terminar almacenando en varias tablas. Excesiva normalizacin puede tener asociada una perdida de performance en ciertas operaciones sobre la base de datos. Es necesario encontrar el equilibrio correspondiente a los requerimientos de cada proyecto en este punto. Como regla general la tercera forma normal es un buen punto intermedio. 6. REC Evitar tener tablas sin definicin de primary keys . 7. REC Evitar tener tablas innecesarias en el sistema . Un buen diseo es uno simple (keep it simple ;) 8. REC Intentar evitar el uso de cdigo propietario en la definicin de expresiones SQL.. Intentar utilizar cdigo Standard SQL-92.

Nomenclatura para los elementos de una base de datos

En esta seccin se presenta la nomenclatura definida para los distintos elementos de una base de datos. La base de datos o schema La base de datos SQL Server o los schemas Oracle debern nombrarse usando la siguiente nomenclatura: <PAIS>_<CLIENTE>_<SOLUCION>[-AUX] Donde se reserva AUX para diferenciar dos bases de datos o schemas correspondientes a una misma solucion. Ejemplo: UY_Infocorp_Northwind UY_Infocorp_ICWorkflow-ICCM

Pgina 6 de 15

Tablas Las tablas deben nombrarse: en plural, en ingls 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. Deben nombrarse usando notacin pascal. Ejemplo: Customers, Orders ORACLE Deben nombrarse con notacin Underscore Separated, en maysculas. Ejemplos: CUSTOMERS, ORDERS En aquellos escenarios en donde se quiera agrupar tablas segn cierta lgica 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 notacin definida para nombrar tablas, pero prefijadas usando VW_. Ejemplo: MS SQL Server: Oracle: vw_SalesByCountry, VW_SALES_BY_COUNTRY

MS SQL Server

Pgina 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 segn los lineamientos a continuacin: 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 definiran las claves: o o MS SQL Server: Oracle: CustomerId, 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 sistemticamente TODOS los campos de una tabla con el nombre de la tabla o una abreviacin 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 notacin Pascal ORACLE Usar notacin Underscore Separated Stored Procedures Los stored procedures son un espacio estndar para incluir lgica en la base de datos, expresada en un lenguaje de scripting que extiende SQL. Los SP pueden ser invocados utilizando SQL estndar desde una aplicacin, mediante la instruccin EXEC. Los stored procedures deben ser nombrados segn la siguiente nomenclatura: MS SQL SERVER Usar notacin Pascal Ejemplo: InsertCustomer ORACLE Usar notacin Underscore Separated Ejemplo: INSERT_CUSTOMER El cdigo SQL extendido de un stored procedure debe ir en Maysculas. Ver apndice C como ejemplo. Funciones definidas por el usuario Las funciones definidas por el usuario son un mecanismo no totalmente estndar para incluir lgica 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 lgica alojada en la base de datos asociada a una determinada accin sobre una tabla. La lgica es disparada cuando ocurre la accin correspondiente. Un trigger no tiene sentido fuera de una tabla y un trigger tiene asociada siempre una operacin, por lo que dicha informacin debe estar asociada al nombre del trigger. Pgina 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 definicin. MS SQL SERVER Usar notacin Pascal Ejemplo: CustomerId ORACLE Usar notacin 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 vnculos entre tablas relacionadas. Una foreign key establece una relacin entre una o ms columnas de una tabla y la clave primaria de la tabla referenciada. Como patrn para la nomenclatura de la foreign key elegimos el siguiente.
FK_<TABLA_QUE_REFERENCIA>+<CAMPO_QUE_REFERENCIA>_<TABLA_REFERENCIADA>+<CAMPO_REFERENCIADO>

Basado en el patrn 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 localizacin y acceso de un registro en una tabla en la base de datos, opcionalmente asegurando unicidad de los valores del ndice. La definicin de ndices tiene un impacto positivo en los tiempos de consulta de registro y uno negativo en los de insercin y actualizacin de los campos del ndice. Los ndices estn 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 notacin elegida para definir las variables es camel. Ver apndice C como ejemplo. Pgina 9 de 15

APENDICE A
En esta seccin 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 segn las prcticas sugeridas.

Modelo conceptual
El diagrama a continuacin representa una realidad hipottica cuya informacin se quiere almacenar en base de datos.. En esta realidad existen compaas que tienen productos. Los productos son vendidos a clientes, mediante ordenes de compra. Una misma orden de compra puede utilizarse para comprar varios productos de una compaa El precio de los productos puede variar con el tiempo, pero se debe almacenar con el precio que fue vendido en cada ocasin. Restriccin no estructural: Una compaa solo emite ordenes de compra de los aquellos productos que posee.

Pgina 10 de 15

MAL Ejemplo
El siguiente es un mal diseo 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 diseo para la realidad anteriormente planteada:

Pgina 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 ambigedad 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

Pgina 12 de 15

APENDICE B
En esta seccin se presentan guas para la definicin de esquemas relacionales segn un modelo conceptual.

Relaciones 1:N
Para la definicin de tablas que correspondan a una relacin 1:N como puede ser la siguiente: Una compaa emplea 1..N empleados

Se sugiere utilizar una estructura de tablas como la siguiente:

Relaciones N:M
Para la definicin de tablas que correspondan a relaciones N:M com puede ser la siguiente: Un doctor atiende N pacientes, y un paciente es atendido por M doctores.

Se sugiere utilizar una estructura de tablas como la siguiente:

Pgina 13 de 15

APENDICE C
En esta seccin 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 DELETE FROM Roles WHERE RoleID = @roleID IF (@@ERROR = 0) AND (@firstOpError = 0) COMMIT ELSE ROLLBACK END RETURN

Pgina 14 de 15

BIBLIOGRAFA
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. Estndar de nomenclatura para bases de datos Oracle, Infocorp

Pgina 15 de 15