Convenciones de nomenclatura de Base de Datos¶
¿Por qué son importantes las Convenciones de nomenclatura?¶
Contexto General¶
Debido a que la División de Sistemas y Tic’s no posee un estándar de nomenclatura para nombrar bases de datos, tablas, campos, vistas, procedimientos almacenados y funciones, se hace necesario contar con un estándar único que permita normalizar la asignación de nombres de dichos elementos. Es importante mencionar que en la actualidad no existe una norma general y que las distintas empresas del rubro poseen y crean su propio estándar, es por esta razón que este documento propone un estándar propio el cual recoge las sugerencias de las distintas recomendaciones y buenas prácticas que hasta hoy se conocen.
Conceptos Generales¶
A continuación se describen los conceptos generales que se deben considerar al momento de nombrar una base de datos, tablas, campos, procedimientos almacenados, vistas y funciones.
- Los nombres de las tablas deben estar compuestos solo por números y letras
- Los nombres de campos solo deben contener letras a excepción de las llaves primarias de las tablas que contengan número.
- Se deben utilizar nombres descriptivos.
- Utilizar solo palabras en minúsculas.
- Utilizar palabras en singular.
- En el caso de que el nombre este compuesto por más de una palabra se debe utilizar underscore ( underscore = “_” ) Ejemplo: palabra1_palabra2
- Para las vistas, procedimientos, funciones se debe utilizar un prefijo seguido de underscore “_”, v para una vista, p para procedimientos y f para una función Ejemplo: v_nombrevista p_nombreprocedimiento f_nombrefuncion
Bases de Datos.¶
Para nombrar una base de datos se debe utilizar su nombre descriptivo en minúsculas y singular.
Ejemplo: emergencia, suelos.
Los diagramas entidad relación construidos deben siempre poseer el siguiente listado:
- Autor.
- Fecha creación.
- Modificado por.
- Fecha última modificación.
- Versión.
- Nombre de la base de datos.
- Nombre del diagrama.
Convenciones de nomenclatura¶
Minúsculas. Los identificadores deben ser escritos totalmente en minúsculas y sin tildes, esto incluye bases de datos, tablas, campos, vistas, procedimientos almacenados y funciones.
apellido_paterno , no "Apellido_Paterno" .
Singular NO plural. Todos los nombres de objetos de base de datos se debe crear en singular NO en plural. Se debe evitar el uso de palabras que son sólo tipos de datos tales como texto o marca de tiempo.
agricultor, NO agricultores.
Palabras separadas con guion bajo. Los nombre del objeto que se compone de varias palabras deben estar separados por guiones bajos.
contador_palabra o id_contador_palabra, NO ContadorPalabra.
Palabras completas, NO abreviaturas. Los nombres de objetos deben ser palabras completas en español. En general evitar las abreviaturas, sobre todo si son justo el tipo que elimina las vocales.
apellido_paterno , NO ap_ptrno
Evite palabras reservadas. Se debe evitar el uso de cualquier palabra reservada en la base de datos, un ejemplo concreto es el uso de la palabra reservada "sp" para nombrar los procedimientos almacenados, esto produce que el motor de base de datos busque dicho procedimiento dentro del listado "System Stored Procedures", en circunstancias que el procedimiento nos es de sistema.
s_cambia_estado, NO sp_cambia_estado
A continuación se presenta las palabras reservadas para PostgreSQL , MySQL , Oracle y MSSQL .
Relaciones Singulares¶
Tablas, vistas y otras relaciones que mantienen datos, deben tener nombres singulares, no plurales. Los nombres singulares permiten traducir directamente las relaciones de base de datos a 4GL.
auto_deportivo se convierte sin ambigüedad a la clase AutoDeportivo en Java o la variable auto_deportivo en Python.
Los campos clave¶
Claves Primarias¶
Los campos de clave principal de las columnas individuales deben ser nombrados con id_nombre tabla, por ejemplo id_agricultor. Es corto, simple y sin ambigüedades.
CREATE TABLE persona (
id_persona bigint PRIMARY KEY,
nombre_completo text NOT NULL,
fecha_nacimiento date NOT NULL);
Las claves externas¶
Los campos de clave externa deben ser una combinación del nombre de la tabla de referencia y el nombre de los campos mencionados. Para las claves externas de una sola columna esto será algo así como id_algo.
CREATE TABLE miembro_equipo ( id_equipo bigint NOT NULL REFERENCES equipo(id_equipo), id_persona bigint NOT NULL REFERENCES persona(id_persona), CONSTRAINT pk_miembro_equipo PRIMARY KEY (id_equipo, id_persona));
Los prefijos¶
Prefijos¶
Como regla general no se debe utilizar prefijos a excepción de los procedimientos, vistas y funciones, los cuales deben ser nombrados de la siguiente manera.- Utilizar p cuando se trata de un procedimiento almacenado, ejemplo: p_nombreprocedimiento
- Utilizar v cuando se trata de una vista, ejemplo: v_nombrevista
- Utilizar f cuando se trata de una función, ejemplo: f_nombrefuncion
Índices¶
Los índices deben ser nombrados de manera explícita e incluyen tanto el nombre de la tabla y el nombre de columna indexada. Incluyendo los nombres de columna que sea mucho más fácil de leer a través de SQL, se debe utilizar los caracteres ix para representar que es un índice.
CREATE TABLE persona ( id_persona bigserial PRIMARY KEY , email text NOT NULL , apellido_paterno text NOT NULL , apellido_materno text NOT NULL , CONSTRAINT persona_ck_email_lower_case CHECK ( email = LOWER ( email ))); CREATE INDEX persona_ix_apellido_paterno_apellido_materno ON persona ( apellido_paterno , apellido_materno );
Constraints¶
De manera similar a los índices, las limitaciones deben ser dadas por nombres descriptivos. Esto es especialmente cierto para las restricciones de comprobación.
CREATE TABLE equipo ( id_equipo BIGSERIAL PRIMARY KEY , nombre text NO NULL ); CREATE TABLE miembro_equipo ( id_miembro_equipo bigint REFERENCES team ( id ), id_persona bigint REFERENCES person ( id ), CONSTRAINT pk_miembro_equipo PRIMARY KEY ( id_equipo , id_persona ));
Fuente: https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/