Estndar de nomenclatura para

Base de Datos
tipo_documento
July de 2014
Este documento describe el estndar de nomenclatura para base de datos utilizados en el desarrollo del
software.Este documento contiene los formatos necesarios para cualquier documento de ndole general.
rc!i"o# 2$%&'''%4.doc
(ginas# &
)ec!a# 02&*1%*2014 21#2'#00 +&*p&
utor# ,al"ador -. ,alazar )uentes
INTRODUCCIN
El presente documento describe la nomenclatura a utilizar en el dise.o de base de datos en el
departamento de desarrollo de /oteles 0ity.
Objetivo
El ob1eti"o de este documento es institucionalizar buenas prcticas y estandarizar la nomenclatura de
nombres utilizada en el dise.o y mantenimiento de bases de datos en el departamento de desarrollo de
/oteles 0ity.
lcance
Este documento aplica al dise.o y mantenimiento de base de datos en el departamento de desarrollo
/oteles 0ity !aciendo foco en dos mane1adores de bases de datos en particular# 2, ,3- ,er"er.
(or defecto todas las indicaciones que se presentan aplican a todos los mane1adores a menos que se
especifique lo contrario.
udiencia
Este documento se encuentra dirigido a programadores4 analistas4 1efes de proyecto y especialistas
t5cnicos del departamento de desarrollo de /oteles 0ity4 que tengan entre sus tareas realizar el dise.o o
mantenimiento de una base de datos.
!uentes utili"adas
Entre las fuentes utilizadas para la creaci6n de este documento se encuentran diferentes publicaciones
sobre nomenclatura de base de datos4 las cuales son referenciadas en la secci6n de bibliografa4 as
como tambi5n se !a intentado seguir las prcticas utilizadas por 2icrosoft en el dise.o de la base de
datos 7ort!wind y 8eporting ,er"ices.
Condiciones de uso de este documento
9na regla puede romperse s6lo ante razones 1ustificadas4 discutidas4 con pre"ia autorizaci6n del
responsable del producto4 y en caso que no pueda aplicarse ninguna alternati"a razonable. El autor de la
e:cepci6n4 obligatoriamente debe documentar el c6digo e:plicando la causa de la "iolaci6n de la regla.
-as preferencias personales no se consideran una raz6n 1ustificada.
(gina 2 de &
Convenciones utili"adas en este documento
bre"iaciones ;escripci6n
+<- +bligatorio
8E0 8ecomendado
Negrita =e:to con 5nfasis adicional que debe ser considerado importante.
,iempre >ndica que esta regla ;E<E ser respetada4 en los t5rminos de este manual.
Nunca >ndica que esta acci6n 7+ ;E<E ser realizada4 en los t5rminos de este manual.
No hacer >ndica que esta acci6n 7+ ;E<E ser realizada4 en los t5rminos de este manual.
Evitar
>ndica que esta prctica debe ser e"itada siempre que sea posible4 pero pueden e:istir
e:cepciones 9=+8>?;, para su utilizaci6n.
Intentar >ndica que esta prctica debe aplicarse siempre que sea posible y apropiado.
8az6n E:plica el prop6sito y las causas que moti"an la regla o recomendaci6n.
Terminolo#$a % de&niciones
=5rmino ;escripci6n
0amel 0ase
9na palabra con la primera letra en min@sculas4 y la primera letra de cada una de las
palabras subsecuentes en may@sculas.
E1emplo# 0ustomerName
2agic 7umber
0ualquier literal num5rico utilizado dentro de una e:presi6n Ao inicializaci6n de "ariableB
que no posea un significado claro. 9sualmente este t5rmino no aplica a los "alores 0 y 1
y cualquier otra e:presi6n num5rica equi"alente que su e"aluaci6n resulte 0.
(ascal 0ase
9na palabra con la primera letra en may@sculas4 y la primera letra de cada palabra
subsecuente tambi5n en may@sculas.
E1emplo# CustomerName
/ungarian
7otation
0omienzan con una o mas letras en min@scula que denotan el tipo de la "ariable
E1emplo# string sCariable
(gina $ de &
'U( R)*ID
En esta secci6n se incluye un bre"e resumen de los principales estndares descriptos a los largo de este
documento. Estas tablas no son detalladas en sus descripciones4 pero brindan una rpida referencia a los
elementos.
Convenciones de nomenclatura
c 0amel case
( (ascal case
D (refi1o con infragui6n AunderscoreB
E 7o aplica
FG -o se encuentre contenido entre par5ntesis rectos significa que es opcional.
HC8I >ndica que esa posici6n debe sustituirse por el "alor del campo C8. En el caso de la
"ariable =<-E se !ace la siguente distinci6n# =<-ED, representa el nombre de una tabla
en singular Ae1# 0ustomerB4 mientras que =<-ED( indica el nombre de una tabla en plural
Ae1# 0ustomersB.
9,9 9nderscore ,eparated 9pper 0ase
Elemento MS SQL Server
Observaciones
Base de datos H09,=+2E8IH,+-9=>+7IFJ9EG Ejemplo: HotelesCityNorthwind
Schema H09,=+2E8IH,+-9=>+7IFJ9EG Ejemplo: HotelesCityNorthwind
Tablas ( K plural E"itar espacios en blanco
Ejemplo: Customers
Vistas CLDHC>ELD(I E"itar espacios en blanco
Ejemplo SQL Server: vwSalesByCountry
Stored
Procedures
( E"itar el uso de prefi1os4 tipo spD y espacios en
blanco
Ejemplos:
InsCustomer, GetrdersBy!ate
User defined
functions
(
Triggers H=<-ED,IH+(E8=>+7IFDH9EIG 9n trigger est siempre asociado con una tabla y
una operaci6n y no tiene sentido fuera de ellos.
Ejemplos: rdersIns"alidate!ata,
CustomerIns#epli$ateEmail
olumns (
(ara las cla"es H=<-ED,I>d
7o nombrar de forma distinta campos que
representen lo mismo.
Ejemplos:
rderId, %ullName, &ddress, rder!ate
User defined
data t!"es
0 Ejemplo: IdCustomer
Primar! #e!s (MDH=<-ED(I Ejemplo: IdCustomer
$oreign #e!s )MDH=<-ED(IH)>E-;IDH8E)D=<-ED(IH8E)D)>E-;
I

Ejemplo:
%'(rdersCustomerId(CustomersIdCustomer
%nde&es F>;EDGH=<-ED(IDH)>E-;IFD9EG Ejemplo: rder!etailsIdrder
Variables c
(gina 4 de &
CON+ENCIONE, DE NO-ENC.TUR
continuaci6n se presentan un con1unto de guas y buenas prcticas4 as como la nomenclatura para
utilizar en el dise.o de bases de datos.
'u$as #en/ricas % buenas prcticas
1. OBL N Utili'ar nombres en ingl(s "ara todos los elementos de la base de datos4 tablas4
"istas4 campos4 etc.
2. )E N Utili'ar nombres descri"tivos "ara los cam"os. 9tilizar nombres que resulten intuiti"os
y permitan entender el significado de los campos Amnemot5cnicosB. E"itar las abre"iaciones4 y si
esto no es posible documentarlas bien.
$. )E N No nombrar cam"os *ue re"resentan lo mismo de forma distinta. -a forma en que se
nombran iguales propiedades debe ser consistente en todo un esquema. E1emplo# 7ombrar al
campo cla"e de la tabla 0ustomers como >d4 y despu5s referenciarlo en otras tablas como
>d0ustomer es >70+88E0=+. El campo debe ser nombrado >d0ustomer en todos los casos que
se quiera almacenar una cla"e de 0ustomers.
4. )E N Evitar tener demasiadas columnas NULL+BLES en una tabla. Esto es indicio de un
esquema poco o nada normalizado. )alta de normalizaci6n puede conlle"ar problemas de
consistencia en los datos en la medida que un mismo campo se puede terminar almacenando en
"arias tablas. E:cesi"a normalizaci6n 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. 0omo regla general la tercera forma normal
es un buen punto intermedio.
O. )E N Evitar tener tablas sin definici,n de "rimar! #e!s.
P. )E N Evitar tener tablas innecesarias en el sistema. 9n buen dise.o es uno simple AQeep it
simple RB
&. )E N %ntentar evitar el uso de c,digo "ro"ietario en la definici6n de e:presiones ,3-..
>ntentar utilizar c6digo ,tandard ,3-J'2.
Nomenclatura para los elementos de una base de datos
En esta secci6n se presenta la nomenclatura definida para los distintos elementos de una base de datos.
.a base de datos o sc0ema
-a base de datos ,3- ,er"er o los sc!emas debern nombrarse usando el nombre de la base de datos
que estamos creando#
E1emplo# -7 es el nombre de la base de datos de lianzas (ay<acQ4 para el nombre del esquema4 toma
el nombre de aln.
Tablas
-as tablas deben nombrarse#
en plural4
en ingl5s
sin utilizar espacios en blanco
,i el nombre es compuesto solo la @ltima palabra debe ir en plural. (or e1emplo# (roduct,ales es
correcto mientras que (roducts,ales NO es correcto.
MS SQL Server
;eben nombrarse usando notaci6n pascal.
(gina O de &
E1emplo# ustomers4 Orders
+istas
-as "istas deben nombrarse con la misma notaci6n definida para nombrar tablas4 pero prefi1adas usando
V-..
E1emplo#
2, ,3- ,er"er# "wD,ales<y0ountry4
+racle# CLD,-E,D<SD0+97=8S
Columns
-os campos de una tabla corresponden a los atributos de una entidad4 describen propiedades de la
misma.
-as columnas deben ser nombradas seg@n los lineamientos a continuaci6n#
1. -os nombres deben ser simples4 representati"os e intuiti"os.
2. -os nombres de las columnas de una tabla deben estar e:presados en singular.
$. El campo clave de una tabla de nombrarse como el nombre de la tabla ms el prefi1o %d. E1emplo#
(ara una tabla de clientes 0ustomers4 se definiran las cla"es#
o 2, ,3- ,er"er# >d0ustomer
4. 0ampos que representen la misma entidad del mundo real4 deben estar nombrados de la misma
manera en todas las tablas de un esquema. (or e1emplo nombrar la cla"e de la tabla Sales en
una tabla como IdSales y en otra SalesKey es incorrecto.
O. ,e desaconse1a prefi1ar sistemticamente =+;+, los campos de una tabla con el nombre de la
tabla o una abre"iaci6n del mismo. Entendemos que esto agrega un ni"el de redundancia y
comple1idad al sistema que no es necesario en mane1adores modernos.
MS SQL SE)VE)
9sar notaci6n (ascal
O)+LE
En el caso de utilizar este mane1ador de <ase de datos4 usar notaci6n 9nderscore ,eparated.
,tored *rocedures
-os stored procedures son un espacio estndar para incluir l6gica en la base de datos4 e:presada en un
lengua1e de scripting que e:tiende ,3-. -os ,( pueden ser in"ocados utilizando ,3- estndar desde
una aplicaci6n4 mediante la instrucci6n EEE0.
-os stored procedures deben ser nombrados seg@n la siguiente nomenclatura#
MS SQL SE)VE)
9sar notaci6n (ascal
E1emplo# >ns0ustomer
El c6digo ,3- e:tendido de un stored procedure debe ir en 2ay@sculas. Cer ap5ndice 0 como e1emplo.
!unciones de&nidas por el usuario
-as funciones definidas por el usuario son un mecanismo no totalmente estndar para incluir l6gica en la
base de datos4 e:presada en un lengua1e de scripting que e:tiende ,3-.
-a nomenclatura definida es la misma que para los stored procedures.
(gina P de &
Tri##ers
9n trigger es l6gica alo1ada en la base de datos asociada a una determinada acci6n sobre una tabla. -a
l6gica es disparada cuando ocurre la acci6n correspondiente.
9n trigger no tiene sentido fuera de una tabla y un trigger tiene asociada siempre una operaci6n4 por lo
que dic!a informaci6n debe estar asociada al nombre del trigger.
H=<-IDH+(E80>T7I
E1emplo# 0ustomer>ns<innacle
Tipos de datos de&nidos por el usuario
-os tipos de datos definidos por el usuario son un mecanismo para mantener la consistencia de tipos en
la base de datos. 0uando un mismo tipo de datos es utilizado en "arias tablas4 en "ez de definirlo cada
"ez por separado4 se define un Uuser defined data typeV para luego referenciarlo desde todas ellas y
mantener as centralizada su definici6n.
MS SQL SE)VE)
9sar notaci6n (ascal
E1emplo# 0ustomer>d
*rimar% 1e%s
-a cla"e primaria es un con1unto de campos que identifica de forma @nica un registro en una tabla. ,on
un caso particular de un ndice. -a nomenclatura es la siguiente#
(MDH=<-I
E1emplo# (MD0ustomers
!orei#n 1e%s
-as foreign Qeys son usadas para definir "nculos entre tablas relacionadas. 9na foreign Qey establece
una relaci6n entre una o ms columnas de una tabla y la cla"e primaria de la tabla referenciada. 0omo
patr6n para la nomenclatura de la foreign Qey elegimos el siguiente.
FK_<TABLA_QUE_REFERENCIA>+<CAMPO_QUE_REFERENCIA>_<TABLA_REFERENCIADA>+<CAMPO_REFERENCIADO>
<asado en el patr6n dado4 "oy a nombrar la foreign Qey que referencia el campo 09,=+2E8D>; de la
tabla 09,=+2E8, desde la tabla +8;E8, y el campo 09,=+2E8D>; como #
)MD+8;E8,09,=+2E8>;D09,=+2E8,09,=+2E8>;
Inde2es
-os ndices son un mecanismo para aumentar la eficiencia de localizaci6n y acceso de un registro en una
tabla en la base de datos4 opcionalmente asegurando unicidad de los "alores del ndice. -a definici6n de
ndices tiene un impacto positi"o en los tiempos de consulta de registro y uno negati"o en los de inserci6n
y actualizaci6n de los campos del ndice.
-os ndices estn asociados a una tabla y a un con1unto de campos de la tabla4 a su "ez pueden ser
@nicos o no y pueden estar definidos en cluster o no. -a nomenclatura elegida para nombrarlos es la
siguiente#
F>;EDGH=<-IDH02(+I
(refi1ar el ndice es opcional4 pero de !acerlo se debe usar el prefi1o especificado.
E1emplo# +rder;etails+rder>d
El e1emplo corresponde a un ndice definido sobre la tabla +rder;etails4 sobre el campo +rder>d.
+ariables
0uando las "ariables corresponden columnas de una tabla4 deben ser nombrados de la misma manera
que la columna. -a notaci6n elegida para definir las "ariables es camel. Cer ap5ndice 0 como e1emplo.
(gina & de &