Está en la página 1de 15

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

uy

nombre_cliente

Estndar de nomenclatura para Base de Datos


tipo_documento
January de 2014 Este documento describe el est ndar de nomenclatura para base de datos utili!ados en el departamento de Desarrollo.Este documento contiene los formatos necesarios para cual"uier documento de ndole #eneral.

$rc%i&o' , #inas' -ec%a' $utor' Contacto' 3ersion

20()*+200.doc 1( +.12.201/ 20'20'00 a+.p+ 0$1' 0rupo $poyo 12cnico #at@infocorop.com.uy 1.0

TABLA DE CONTENIDO
Est ndar de nomenclatura para 4ase de Datos.......................................................................................1 1abla de contenido....................................................................................................................................... 2 5ntroducci6n.................................................................................................................................................. / 7b8eti&o..................................................................................................................................................... / $lcance..................................................................................................................................................... / $udiencia.................................................................................................................................................. / -uentes utili!adas..................................................................................................................................... / Condiciones de uso de este documento................................................................................................... / Con&enciones utili!adas en este documento............................................................................................ 4 1erminolo#a y definiciones...................................................................................................................... 4 0ua r pida................................................................................................................................................... ( Con&enciones de nomenclatura................................................................................................................ ( Con&enciones de 9omenclatura................................................................................................................... + 0uas #en2ricas y buenas pr cticas......................................................................................................... + 9omenclatura para los elementos de una base de datos.........................................................................+ $pendice $................................................................................................................................................. 10 :odelo conceptual.................................................................................................................................. 10 :$; E8emplo........................................................................................................................................... 11 E8emplo su#erido.................................................................................................................................... 11 $pendice 4................................................................................................................................................. 1/ <elaciones 1'9........................................................................................................................................ 1/ <elaciones 9':....................................................................................................................................... 1/ $pendice C................................................................................................................................................. 14 =tored ,rocedure.................................................................................................................................... 14 454;570<$->$........................................................................................................................................... 1(

, #ina 2 de 1(

INTRODUCCIN
El presente documento describe la nomenclatura a utili!ar en el dise?o de base de datos en el departamento de desarrollo de 5nfocorp.

Ob eti!o
El ob8eti&o de este documento es institucionali!ar buenas pr cticas y estandari!ar la nomenclatura de nombres utili!ada en el dise?o y mantenimiento de bases de datos en el departamento de desarrollo de 5nfocorp.

Alcance
Este documento aplica al dise?o y mantenimiento de base de datos en el departamento de desarrollo 5nfocorp %aciendo foco en dos mane8adores de bases de datos en particular' := =@; =er&er y 7racle. ,or defecto todas las indicaciones "ue se presentan aplican a todos los mane8adores a menos "ue se especifi"ue lo contrario. En caso de "uerer aplicar la nomenclatura para otro mane8ador de base de datosA distinto de := =@; =er&er u 7racleA se debe decidir si alinearse a la nomenclatura := =@; =er&er u 7racle definidas en este documento en base a factores como' 1ipo de soporte case sensiti&e "ue ten#a el mane8ador y el cliente utili!ado. ;a eBistencia o no de un est ndar para dic%o mane8ador

Audiencia
Este documento se encuentra diri#ido a pro#ramadoresA analistasA 8efes de proyecto y especialistas t2cnicos del departamento de desarrollo de 5nfocorpA "ue ten#an entre sus tareas reali!ar el dise?o o mantenimiento de una base de datos.

"uentes utili#adas
Entre las fuentes utili!adas para la creaci6n de este documento se encuentran diferentes publicaciones sobre nomenclatura de base de datosA las cuales son referenciadas en la secci6n de biblio#rafaA as como tambi2n se %a intentado se#uir las pr cticas utili!adas por :icrosoft en el dise?o de la base de datos 9ort%wind.

Condiciones de uso de este documento


Cna re#la puede romperse s6lo ante ra!ones 8ustificadasA discutidasA con pre&ia autori!aci6n del responsable del productoA y en caso "ue no pueda aplicarse nin#una alternati&a ra!onable. El autor de la eBcepci6nA obli#atoriamente debe documentar el c6di#o eBplicando la causa de la &iolaci6n de la re#la. ;as preferencias personales no se consideran una ra!6n 8ustificada.

, #ina / de 1(

Con!enciones utili#adas en este documento


$bre&iaciones 74; <EC Negrita =iempre Nunca No hacer Evitar Intentar <a!6n Descripci6n 7bli#atorio <ecomendado 1eBto con 2nfasis adicional "ue debe ser considerado importante. 5ndica "ue esta re#la DE4E ser respetadaA en los t2rminos de este manual. 5ndica "ue esta acci6n 97 DE4E ser reali!adaA en los t2rminos de este manual. 5ndica "ue esta acci6n 97 DE4E ser reali!adaA en los t2rminos de este manual. 5ndica "ue esta pr ctica debe ser e&itada siempre "ue sea posibleA pero pueden eBistir eBcepciones $C17<5D$D$= para su utili!aci6n. 5ndica "ue esta pr ctica debe aplicarse siempre "ue sea posible y apropiado. EBplica el prop6sito y las causas "ue moti&an la re#la o recomendaci6n.

Terminolo$%a & de'iniciones


12rmino Descripci6n Cna palabra con la primera letra en minEsculasA y la primera letra de cada una de las palabras subsecuentes en mayEsculas. E8emplo' customerName :a#ic 9umber Cual"uier literal num2rico utili!ado dentro de una eBpresi6n Fo iniciali!aci6n de &ariableG "ue no posea un si#nificado claro. Csualmente este t2rmino no aplica a los &alores 0 y 1 y cual"uier otra eBpresi6n num2rica e"ui&alente "ue su e&aluaci6n resulte 0. Cna palabra con la primera letra en mayEsculasA y la primera letra de cada palabra subsecuente tambi2n en mayEsculas. E8emplo' CustomerName Hun#arian 9otation Cnderscore =eparated Comien!an con una o mas letras en minEscula "ue denotan el tipo de la &ariable E8emplo' strin# s3ariable 5ndica palabras separadas con infra#ui6n. E8emplo' CC=17:E<_DE1$5;

Camel Case

,ascal Case

, #ina 4 de 1(

(U)A R*+IDA
En esta secci6n se incluye un bre&e resumen de los principales est ndares descriptos a los lar#o de este documento. Estas tablas no son detalladas en sus descripcionesA pero brindan una r pida referencia a los elementos.

Con!enciones de nomenclatura
c , _ I JK L3$<M Camel case ,ascal case ,refi8o con infra#ui6n FunderscoreG 9o aplica ;o se encuentre contenido entre par2ntesis rectos si#nifica "ue es opcional. 5ndica "ue esa posici6n debe sustituirse por el &alor del campo 3$<. En el caso de la &ariable 1$4;E se %ace la si#uente distinci6n' 1$4;E_= representa el nombre de una tabla en sin#ular Fe8' CustomerGA mientras "ue 1$4;E_, indica el nombre de una tabla en plural Fe8' CustomersG. Cnderscore =eparated Cpper Case

C=C

Elemento Base de datos Schema Tablas Vistas Stored Procedures

MS SQL Server

Oracle

LC7C91<NM_LCC=17:E<M_L=7;C1579MJO$CIK LC7C91<NM_LCC=17:E<M_L=7;C1579MJO$CIK , P plural 3Q_L35EQ_,M , C=C C=C P plural

Observaciones Ejemplo: UY_Infocorp_Northwind $plica Enicamente en 7racle Ejemplo: UY_Infocorp_Northwind E&itar espacios en blanco Ejemplo: Customers E&itar espacios en blanco Ejemplo SQL Server: vw_Sales !Countr! Ejemplo "racle: #$_S%LES YC"UN&'Y E&itar el uso de prefi8osA tipo sp_ y espacios en blanco Ejemplos: InsertCustomer( )et"rders !*ate

User defined functions Triggers

, L1$4;E_=M_L7,E<$1579MJ_L$CIMK

C=C Cn tri##er esta siempre asociado con una tabla y una operaci6n y no tiene sentido fuera de ellos. Ejemplos: "rders_Insert_#alidate*ata( Customer_Insert_'eplicateEmail C=C ,ara las cla&es L1$4;E_=M_5D C=C 9o nombrar de forma distinta campos "ue representen lo mismo. Ejemplos: "rderId( +ullName( %ddress( "rder*ate Ejemplo: customerId Ejemplo: ,-_Customers Ejemplo: +-_"rdersCustomerId_CustomersCustomerId Ejemplo: "rder*etails_"rderI*_U_NC En el e8emplo presentado _C correspondera a Cni"ue y _9C correspondera a 9onClustered. c

olumns

, ,ara las cla&es L1$4;E_=M5d

User defined data t!"es Primar! #e!s $oreign #e!s

C ,R_L1$4;E_,M

-R_L1$4;E_,ML-5E;DM_L<E-_1$4;E_,ML<E-_-5E;DM

%nde&es Variables

J5DI_KL1$4;E_,M_L-5E;DMJ_$CIK c

, #ina ( de 1(

CON,ENCIONE- DE NO.ENCLATURA
$ continuaci6n se presentan un con8unto de #uas y buenas pr cticasA as como la nomenclatura para utili!ar en el dise?o de bases de datos.

(u%as $en/ricas & buenas prcticas


1. OBL S Utili'ar nombres en ingl(s "ara todos los elementos de la base de datos A tablasA &istasA camposA etc. 2. )E S Utili'ar nombres descri"tivos "ara los cam"os. Ctili!ar nombres "ue resulten intuiti&os y permitan entender el si#nificado de los campos Fmnemot2cnicosG. E&itar las abre&iacionesA y si esto no es posible documentarlas bien. /. OBLO O)* LE+ utili'ar solo ma!,sculas "ara nombrar los elementos de la base de datos+ schemas+ tablas ! cam"os4. )E S No nombrar cam"os .ue re"resentan lo mismo de forma distinta . ;a forma en "ue se nombran i#uales propiedades debe ser consistente en todo un es"uema. E8emplo' 9ombrar al campo cla&e de la tabla Customers como 5dA y despu2s referenciarlo en otras tablas como Customer5d es 59C7<<EC17. El campo debe ser nombrado Customer5d en todos los casos "ue se "uiera almacenar una cla&e de Customers. (. )E S Evitar tener demasiadas columnas NULL*BLES en una tabla . Esto es indicio de un es"uema poco o nada normali!ado. -alta de normali!aci6n puede conlle&ar problemas de consistencia en los datos en la medida "ue un mismo campo se puede terminar almacenando en &arias tablas. EBcesi&a normali!aci6n puede tener asociada una perdida de performance en ciertas operaciones sobre la base de datos. Es necesario encontrar el e"uilibrio correspondiente a los re"uerimientos de cada proyecto en este punto. Como re#la #eneral la tercera forma normal es un buen punto intermedio. +. )E S Evitar tener tablas sin definici/n de "rimar! #e!s . ). )E S Evitar tener tablas innecesarias en el sistema . Cn buen dise?o es uno simple FTeep it simple UG V. )E S %ntentar evitar el uso de c/digo "ro"ietario en la definici6n de eBpresiones =@;.. 5ntentar utili!ar c6di#o =tandard =@;O*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. La base de datos o sc0ema ;a base de datos =@; =er&er o los sc%emas 7racle deber n nombrarse usando la si#uiente nomenclatura' L,$5=M_LC;5E91EM_L=7;CC579MJO$CIK Donde se reser&a $CI para diferenciar dos bases de datos o sc%emas correspondientes a una misma solucion. E8emplo' CN_5nfocorp_9ort%wind CN_5nfocorp_5CQorTflowO5CC:

, #ina + de 1(

Tablas ;as tablas deben nombrarse' en pluralA en in#l2s sin utili!ar espacios en blanco =i el nombre es compuesto solo la Eltima palabra debe ir en plural. ,or e8emplo' ,roduct=ales es correcto mientras "ue ,roducts=ales NO es correcto. Deben nombrarse usando notaci6n pascal. E8emplo' O)* LE Deben nombrarse con notaci6n Cnderscore =eparatedA en mayEsculas. E8emplos' USTOME)SA O)0E)S En a"uellos escenarios en donde se "uiera a#rupar tablas se#En cierta l6#ica del ne#ocio se puede a#re#ar un prefi8o "ue permita esto. ,or e8emploA si en un mismo es"uema se "uieren almacenar empleados del departamento de recursos %umanos se pueden definir de la si#uiente manera' H<_E:,;7NEE= ,istas ;as &istas deben nombrarse con la misma notaci6n definida para nombrar tablasA pero prefi8adas usando V12. E8emplo' := =@; =er&er' 7racle' &w_=ales4yCountryA 3Q_=$;E=_4N_C7C91<N ustomersA Orders

MS SQL Server

, #ina ) de 1(

Columns ;os campos de una tabla corresponden a los atributos de una entidadA describen propiedades de la misma. ;as columnas deben ser nombradas se#En los lineamientos a continuaci6n' 1. ;os nombres deben ser simplesA representati&os e intuiti&os. 2. ;os nombres de las columnas de una tabla deben estar eBpresados en singular. /. El campo clave de una tabla de nombrarse como el nombre de la tabla mas el sufi8o %d. E8emplo' ,ara una tabla de clientes CustomersA se definiran las cla&es' o o := =@; =er&er' 7racle' Customer5dA CC=17:E<_5D.

4. Campos "ue representen la misma entidad del mundo realA deben estar nombrados de la misma manera en todas las tablas de un es"uema. ,or e8emplo nombrar la cla&e de la tabla Sales en una tabla como SalesId y en otra SalesKey es incorrecto. (. =e desaconse8a prefi8ar sistem ticamente 17D7= los campos de una tabla con el nombre de la tabla o una abre&iaci6n del mismo. Entendemos "ue esto a#re#a un ni&el de redundancia y comple8idad al sistema "ue no es necesario en mane8adores modernos. MS SQL SE)VE) Csar notaci6n ,ascal O)* LE Csar notaci6n Cnderscore =eparated -tored +rocedures ;os stored procedures son un espacio est ndar para incluir l6#ica en la base de datosA eBpresada en un len#ua8e de scriptin# "ue eBtiende =@;. ;os =, pueden ser in&ocados utili!ando =@; est ndar desde una aplicaci6nA mediante la instrucci6n EIEC. ;os stored procedures deben ser nombrados se#En la si#uiente nomenclatura' MS SQL SE)VE) Csar notaci6n ,ascal E8emplo' 5nsertCustomer O)* LE Csar notaci6n Cnderscore =eparated E8emplo' 59=E<1_CC=17:E< El c6di#o =@; eBtendido de un stored procedure debe ir en :ayEsculas. 3er ap2ndice C como e8emplo. "unciones de'inidas por el usuario ;as funciones definidas por el usuario son un mecanismo no totalmente est ndar para incluir l6#ica en la base de datosA eBpresada en un len#ua8e de scriptin# "ue eBtiende =@;. ;a nomenclatura definida es la misma "ue para los stored procedures. Tri$$ers Cn tri##er es l6#ica alo8ada en la base de datos asociada a una determinada acci6n sobre una tabla. ;a l6#ica es disparada cuando ocurre la acci6n correspondiente. Cn tri##er no tiene sentido fuera de una tabla y un tri##er tiene asociada siempre una operaci6nA por lo "ue dic%a informaci6n debe estar asociada al nombre del tri##er. , #ina V de 1(

L1$4;$M_L7,E<$C579MJ_$CIK E8emplo' Customer_5nsert_5nsert5nCsers Tipos de datos de'inidos 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. Cuando un mismo tipo de datos es utili!ado en &arias tablasA en &e! de definirlo cada &e! por separadoA se define un Wuser defined data typeX para lue#o referenciarlo desde todas ellas y mantener as centrali!ada su definici6n. MS SQL SE)VE) Csar notaci6n ,ascal E8emplo' Customer5d O)* LE Csar notaci6n Cnderscore =eparated E8emplo' CC=17:E<_5D +rimar& 1e&s ;a cla&e primaria es un con8unto de campos "ue identifica de forma Enica un re#istro en una tabla. =on un caso particular de un ndice. ;a nomenclatura es la si#uiente' ,R_L1$4;$M E8emplo' ,R_Customers "orei$n 1e&s ;as forei#n Teys son usadas para definir &nculos entre tablas relacionadas. Cna forei#n Tey establece una relaci6n entre una o m s columnas de una tabla y la cla&e primaria de la tabla referenciada. Como patr6n para la nomenclatura de la forei#n Tey ele#imos el si#uiente.
FK_<TABLA_QUE_REFERENCIA>+<CAMPO_QUE_REFERENCIA>_<TABLA_REFERENCIADA>+<CAMPO_REFERENCIADO>

4asado en el patr6n dadoA &oy a nombrar la forei#n Tey "ue referencia el campo CC=17:E<_5D de la tabla CC=17:E<= desde la tabla 7<DE<= y el campo CC=17:E<_5D como ' -R_7<DE<=CC=17:E<5D_CC=17:E<=CC=17:E<5D Inde2es ;os ndices son un mecanismo para aumentar la eficiencia de locali!aci6n y acceso de un re#istro en una tabla en la base de datosA opcionalmente ase#urando unicidad de los &alores del ndice. ;a definici6n de ndices tiene un impacto positi&o en los tiempos de consulta de re#istro y uno ne#ati&o en los de inserci6n y actuali!aci6n de los campos del ndice. ;os ndices est n asociados a una tabla y a un con8unto de campos de la tablaA a su &e! pueden ser Enicos o no y pueden estar definidos en cluster o no. ;a nomenclatura ele#ida para nombrarlos es la si#uiente' J5DI_KL1$4;$M_LC$:,7MJ_$CIK ,refi8ar el ndice es opcionalA pero de %acerlo se debe usar el prefi8o especificado. E8emplo' 7rderDetails_7rder5d_C_9C El e8emplo corresponde a un ndice definido sobre la tabla 7rderDetailsA sobre el campo 7rder5dA unico y nonclustered. ,ariables Cuando las &ariables corresponden columnas de una tablaA deben ser nombrados de la misma manera "ue la columna. ;a notaci6n ele#ida para definir las &ariables es camel. 3er ap2ndice C como e8emplo. , #ina * de 1(

A+ENDICE A
En esta secci6n se presenta un modelo conceptual para el cual se desarrollan dos es"uemas relacionalesA el primero como e8emplo de lo "ue 97 se debe %acerA mientras "ue el se#undo se#En las pr cticas su#eridas.

.odelo conceptual
El dia#rama a continuaci6n representa una realidad %ipot2tica cuya informaci6n se "uiere almacenar en base de datos.. En esta realidad e&isten com"a34as .ue tienen "roductos- Los "roductos son vendidos a clientes+ mediante ordenes de com"raUna misma orden de com"ra "uede utili'arse "ara com"rar varios "roductos de una com"a34a El "recio de los "roductos "uede variar con el tiem"o+ "ero se debe almacenar con el "recio .ue fue vendido en cada ocasi/n)estricci/n no estructural5 Una com"a34a solo emite ordenes de com"ra de los a.uellos "roductos .ue "osee-

, #ina 10 de 1(

.AL E emplo
El si#uiente es un mal dise?o de es"uema relacional para la realidad anteriormente planteada. 67 Me'cla idiomas 87 Tablas en singular 97 Un mismo cam"o recibe distintos nombres :7 No define $; <7 No define P; =7 Las entidades Orders ! Order%tems residen en una misma tabla+ cam"os redundantes >no es 9N$? @7 *breviaciones A7 Pascal case no res"etado

E emplo su$erido
El si#uiente es el e8emplo su#erido de dise?o para la realidad anteriormente planteada'

, #ina 11 de 1(

Observaciones5 omo criterio se "refiBaron con el nombre de la tabla a.uellas columnas cu!os nombres se encuentran re"etidos en varias tablas+ "ara evitar "roblemas de ambigCedad en las consultas En la tabla Orders se define una clave de un solo cam"o "ara evitar incluir el cam"o om"an!%d en la clave de Order%tems

, #ina 12 de 1(

A+ENDICE B
En esta secci6n se presentan #uas para la definici6n de es"uemas relacionales se#En un modelo conceptual.

Relaciones 34N
,ara la definici6n de tablas "ue correspondan a una relaci6n 1'9 como puede ser la si#uiente' Una com"a34a em"lea 6--N em"leados

=e su#iere utili!ar una estructura de tablas como la si#uiente'

Relaciones N4.
,ara la definici6n de tablas "ue correspondan a relaciones 9': com puede ser la si#uiente' Un doctor atiende N "acientes+ ! un "aciente es atendido "or M doctores-

=e su#iere utili!ar una estructura de tablas como la si#uiente'

, #ina 1/ de 1(

A+ENDICE C
En esta secci6n se presenta un e8emplo de stored procedure := =@; =er&er "ue si#ue la nomenclatura propuesta'

-tored +rocedure
CREATE PROCEDURE dbo.DeleteRoleByName @name nvarchar( !"# A$ DEC%ARE @role&D 'nt( @)'rstO*Error t'ny'nt E+EC ,etRole&dByName @name( @role&D OUT &- (@role&D &$ NU%%# RA&$ERROR(.No Role /'th that name.( 0"( 11# BE,&N BE,&N TRAN$ACT&ON DE%ETE -RO2 UserRoles 34ERE Role&D 5 @role&D $E%ECT @)'rstO*Error 5 @@ERROR DE%ETE -RO2 Roles 34ERE Role&D 5 @role&D &- (@@ERROR 5 6# AND (@)'rstO*Error 5 6# CO22&T E%$E RO%%BAC7 END RETURN

, #ina 14 de 1(

BIBLIO(RA")A
1. Data 7b8ect 9amin# con&entions by RondreddiA 9arayana 3yas F%ttp'..&yasTn.tripod.com.ob8ect_namin#.%tmG 2. 1en 1%in#s 5 %ate about you by CelToA Joe F%ttp'..www.intelli#ententerprise.com.00120(.celTo1_1.8%tml G /. Est ndar de nomenclatura para bases de datos 7racleA 5nfocorp

, #ina 1( de 1(