Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 195 vistas

    Estándares de Diseño de Bases de Datos

    Cargado por

    Azzie Cakes
    A continuación se mostrara una serie de normas para el diseño de base de datos, que permiten que el diseño tenga las siguientes ventajas: • Facilitar la legibilidad del diagrama de entidad-relación de base de datos, tanto entre personal técnico como no técnico. • Mejorar la generación del modelo de clases en el código fuente (en caso de usar una capa de abstracción de base de datos). • Proveer una guía para el desarrollador encargado de codificar los módulos del sistema, agilizando la escritura

    Copyright:

    © All Rights Reserved
    Descargue como DOC, PDF, TXT o lea en línea desde Scribd

    Estándares de Diseño de Bases de Datos

    Cargado por

    Azzie Cakes
    195 vistas4 páginas
    A continuación se mostrara una serie de normas para el diseño de base de datos, que permiten que el diseño tenga las siguientes ventajas: • Facilitar la legibilidad del diagrama de entidad-relación de base de datos, tanto entre personal técnico como no técnico. • Mejorar la generación del modelo de clases en el código fuente (en caso de usar una capa de abstracción de base de datos). • Proveer una guía para el desarrollador encargado de codificar los módulos del sistema, agilizando la escritura

    Título original

    Estándares de diseño de Bases de Datos

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    DOC, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    A continuación se mostrara una serie de normas para el diseño de base de datos, que permiten que el diseño tenga las siguientes ventajas: • Facilitar la legibilidad del diagrama de entidad-relación de base de datos, tanto entre personal técnico como no técnico. • Mejorar la generación del modelo de clases en el código fuente (en caso de usar una capa de abstracción de base de datos). • Proveer una guía para el desarrollador encargado de codificar los módulos del sistema, agilizando la escritura

    Copyright:

    © All Rights Reserved
    Descargue como DOC, PDF, TXT o lea en línea desde Scribd
    Descargar como doc, pdf o txt
    195 vistas4 páginas

    Estándares de Diseño de Bases de Datos

    Cargado por

    Azzie Cakes
    A continuación se mostrara una serie de normas para el diseño de base de datos, que permiten que el diseño tenga las siguientes ventajas: • Facilitar la legibilidad del diagrama de entidad-relación de base de datos, tanto entre personal técnico como no técnico. • Mejorar la generación del modelo de clases en el código fuente (en caso de usar una capa de abstracción de base de datos). • Proveer una guía para el desarrollador encargado de codificar los módulos del sistema, agilizando la escritura

    Copyright:

    © All Rights Reserved
    Descargue como DOC, PDF, TXT o lea en línea desde Scribd
    Descargar como doc, pdf o txt
    Está en la página 1de 4

    Estándares de diseño de Bases de Datos

    Actualmente CVG Alcasa está desarrollando nuevas aplicaciones en ambiente


    Cliente Servidor, dichas aplicaciones son desarrolladas por empleados y pasantes.
    En vista de la naturaleza y evolución del desarrollo de software, y con el objetivo
    de sistematizar el desarrollo de aplicaciones, nace la inquietud de definir un
    estándar de desarrollo de software.

    A continuación se mostrara una serie de normas para el diseño de base de datos,


    que permiten que el diseño tenga las siguientes ventajas:

     Facilitar la legibilidad del diagrama de entidad-relación de base de datos,


    tanto entre personal técnico como no técnico.

     Mejorar la generación del modelo de clases en el código fuente (en caso de


    usar una capa de abstracción de base de datos).

     Proveer una guía para el desarrollador encargado de codificar los módulos


    del sistema, agilizando la escritura de procedimientos de acceso a datos,

    Reglas generales

    1. Los nombres de tablas y campos deben especificarse bajo el estándar


    camelCase. Este estándar especifica escribir las palabras compuestas
    eliminando los espacios y poniendo en mayúscula la primera letra de cada
    palabra. En este ámbito se utilizará la variante lowerCamelCase (la primera
    letra del nombre, en minúscula). Para más información, visite
    http://en.wikipedia.org/wiki/CamelCase.

    2. Únicamente se utilizarán caracteres alfabéticos, salvo que por la naturaleza


    del nombre se necesiten dígitos numéricos. Se prohíbe el uso de caracteres
    de puntuación o símbolos. Como salvedad a esta regla se aceptará el guión
    bajo (_), únicamente en el caso de tablas de relación (ver más adelante).

    Ejemplo: presupuesto2008.

    3. Las letras acentuadas se reemplazarán con las equivalentes no


    acentuadas, y en lugar de la letra eñe (ñ) se utilizará (ni).

    Ejemplos: anioExpediente.

    4. El nombre elegido debe ser lo más descriptivo posible, evitando términos


    ambiguos o que se presten a distintas interpretaciones

    0 Ejemplo: tipoMunicipio=> categoriaMunicipio.


    5. El nombre no debe abreviarse, salvo que por necesidad específica deban
    especificarse más de una palabra en el mismo.

    Ejemplo: ido=> idOrganismo, freg=> fechaRegistro

    6. Agregar comentarios a las bases de datos y los campos, sobre todo a los
    booleanos.

    7. Los objetos de base de datos como store procedure, primary key, foreign
    key y view, deben ser nombrados con los siguientes prefijos:

    sp -> Store Procedure


    vw -> View
    fk -> Foreing Key
    pk -> Primary Key

    1 Tablas - Reglas generales

    8. Los nombres deben especificarse en singular, y de acuerdo a las reglas


    generales. Esto es debido a que una tabla representa un objeto del
    Sistema, mapeado a base.

    Ejemplos: departamento, factura, moneda.

    9. Las tablas de relación (objetos asociativos, representan relaciones de N a


    M) deben nombrarse utilizando los nombres de las tablas relacionadas,
    siguiendo un orden lógico de frase, se utilizarán sólo caracteres minúscula y
    se separarán los nombres de las tablas relacionadas utilizando el guión
    bajo (_).

    Ejemplos: localidad_municipio, factura_nota

    10. Toda tabla debe poseer uno o más campos clave.

    11. Toda relación entre tablas debe implementarse mediante constraints


    (claves foráneas) con integridad referencial, de acuerdo al motor de base
    de datos utilizado.

    12. Los campos clave deben ubicarse al inicio de la definición de la tabla


    (deben ser los primeros).

    13. El nombre del campo clave debe estar compuesto por “id” + nombre de la
    tabla en singular (para claves no compuestas). Dependiendo de la
    naturaleza de la entidad, el nombre de la tabla a usar es el de la misma
    tabla, o el de la relacionada.
    Ejemplos: tabla localidad => idLocalidad.

    14. Las claves compuestas sólo deben utilizarse en casos específicos, por
    ejemplo, tablas de relación o entidades débiles. Si una tabla X con clave
    compuesta necesita ser referenciada desde otra tabla Y, deberá generarse
    un campo clave en X al inicio de la misma como “idX”, y generar un índice
    único en los campos que la identificaban.

    15. Cada base de datos debe contar con su Diagrama de Entidad – Relación
    (DER), y si el manejador de base de datos lo permite debe estar incluido en
    la base de datos, como en el caso de MS SQL Server.

    Otros campos

    16. Todo campo que represente un nombre o descripción, se colocará


    inmediatamente después de los campos clave, y se nombrará como a la
    tabla a la que pertenece, en singular.

    Ejemplos: tabla localidad => idLocalidad, localidad.

    tabla sucursalEmpresa => idEmpresa, idSucursal, sucursal

    17. Algunos campos que representan datos, de acuerdo a su representación


    conceptual en el ámbito del negocio, deberán prefijarse de la siguiente
    manera:

    Números: nro (ejemplo: Número de factura => nroFactura)

    Fechas: fecha (ejemplo: Fecha de inscripción => fechaInscripcion)

    Fecha Hora: tiempo (ejemplo: Tiempo Inicio => tiempoInicio)

    Códigos: cod (ejemplo: Código de producto => codProducto)

    Indicador: ind (ejemplo: Indicador de Estado => indEstado)

    18. Los campos booleanos deberán nombrarse de acuerdo al estado


    correspondiente al valor 1/Verdadero/True del contexto en el que se
    encuentran modelados.

    Ejemplos: autorizado, oculto, vigente.

    19. Los campos de relación (foreign keys, claves foráneas) deben nombrarse
    de la misma manera que los campos clave (usando el nombre de la tabla a
    la que hacen referencia).
    Ejemplos: tabla persona => idTipoDocumento, idEstadoCivil

    Procedimientos

    20. Los procedimientos almacenados deben ser nombrado con el prefijo


    indicado en el punto 7, a continuación la acción que ejecuta, seguido de
    sujeto que representa la información que procesa.

    Ejemplo: spObtenerPersonal, spIngresarPersonal, spProcesarNomina, etc.

    21. Las mayorías de transacciones y eventos de las aplicaciones deben ser


    programadas en la base de datos, mediante el uso de procedimientos
    almacenados. Con el objetivo de dividir las funciones y de esta manera
    acelerar las tareas de diseño, desarrollo, implementación y mantenimiento
    del software.

    22. Deben estar identificados a 4 caracteres y evitar que las líneas superen las
    80 columnas, con el fin de facilitar la lectura y comprensión de los mismos.

    También podría gustarte