1. Proceso de diseño de bases de datos
La tecnología de bases de datos es el medio más eficaz para la gestión de recursos de información. El diseño de bases de datos se refiere a la construcción de un modelo de base de datos óptimo, el establecimiento de una base de datos y su sistema de aplicación para un entorno de aplicación determinado, el almacenamiento eficaz de datos y la satisfacción de los requisitos de información y procesamiento del usuario.
En la etapa de diseño de la base de datos, se integran las necesidades de la aplicación del usuario (necesidades del mundo real). En la etapa de diseño conceptual, se forma un modelo conceptual (modelo del mundo de la información) independiente de las características de la máquina y los productos DBMS, que. se describe con un diagrama E-R. En la etapa de diseño lógico, el diagrama E-R se convierte en un modelo de datos respaldado por un producto de base de datos específico, como un modelo relacional, para formar un modelo lógico de base de datos. Luego, en función de las necesidades de procesamiento del usuario y las consideraciones de seguridad, se establecen las vistas necesarias con base en las tablas básicas para formar un esquema externo de los datos. En la etapa de diseño físico, de acuerdo con las características del DBMS y las necesidades de procesamiento, se organiza el almacenamiento físico, se diseñan los índices y se forma el esquema en la base de datos.
1. Etapa de análisis de requisitos
La recopilación y el análisis de requisitos generan requisitos de datos descritos por el diccionario de datos (y requisitos de procesamiento descritos por el diagrama de flujo de datos).
El objetivo del análisis de requisitos es investigar, recopilar y analizar las necesidades de información de los usuarios, las necesidades de procesamiento y las necesidades de seguridad e integridad en la gestión de datos.
Métodos de análisis de la demanda: investigar la organización, investigar las actividades comerciales de cada departamento, ayudar a los usuarios a aclarar sus necesidades para el nuevo sistema y determinar los límites del nuevo sistema.
Los métodos de encuesta más utilizados incluyen: hacer la tarea, celebrar reuniones de encuesta, pedir a las personas que se presenten, hacer preguntas, diseñar cuestionarios para que los usuarios los completen y revisar registros.
Existen dos métodos principales para analizar y expresar las necesidades del usuario: de arriba hacia abajo y de abajo hacia arriba. El enfoque estructurado de arriba hacia abajo (SA) comienza desde la organización del sistema de nivel superior, analiza el sistema mediante la descomposición capa por capa y utiliza diagramas de flujo de datos y diccionarios de datos para describir cada capa.
El diagrama de flujo de datos expresa la relación entre datos y procesamiento. Los datos del sistema se describen a través de un diccionario de datos (DD).
El diccionario de datos es una colección de varias descripciones de datos. Es una descripción de los datos en la base de datos, es decir, metadatos, no los datos en sí. Un diccionario de datos generalmente incluye cinco partes: elementos de datos, estructura de datos, flujo de datos, almacenamiento y procesamiento de datos (al menos debe incluir el tipo de datos de cada campo y la clave primaria y externa en cada tabla).
Descripción del elemento de datos = {nombre del elemento de datos, descripción del significado del elemento de datos, alias, tipo de datos, longitud,
rango de valores, significado del valor y relación lógica con otros elementos de datos}
Descripción de la estructura de datos = {nombre de la estructura de datos, descripción del significado, composición: {elemento de datos o estructura de datos}}
Descripción del flujo de datos = {nombre del flujo de datos, descripción, fuente del flujo de datos, datos destino del flujo,
Composición: {estructura de datos}, flujo promedio, flujo máximo}
Descripción del almacenamiento de datos = {nombre del almacenamiento de datos, descripción, número, flujo de datos entrante, flujo de datos de salida ,
Composición: {estructura de datos}, volumen de datos, método de acceso}
Descripción del proceso = {nombre del proceso, descripción, entrada: {flujo de datos}, salida: {flujo de datos} ,
Procesamiento: {Breve descripción}}
2. Etapa de diseño de la estructura conceptual
A través de la síntesis, inducción y abstracción de las necesidades del usuario, formar un modelo conceptual. que es independiente del DBMS específico y puede representarse mediante un diagrama E-R.
Los modelos conceptuales se utilizan para modelar el mundo de la información. El modelo conceptual no depende del modelo de datos soportado por el DBMS. El modelo conceptual se puede convertir en un modelo de datos específico respaldado por el DBMS en la computadora.
Características del modelo conceptual:
(1) Tiene una fuerte capacidad de expresión semántica y puede expresar diversos conocimientos semánticos en aplicaciones de manera conveniente y directa.
(2) Debe ser simple y claro, fácil de entender para los usuarios y debe ser el lenguaje para que los usuarios se comuniquen con los diseñadores de bases de datos.
Un método común para el diseño de modelos conceptuales es el método IDEF1X, que es una tecnología de modelado semántico que aplica el método entidad-relación al modelo de datos semántico para establecer el modelo de información del sistema.
Los pasos para crear un modelo E-R utilizando el método IDEF1X son los siguientes:
Paso 2.1 Proyecto de inicialización cero
La tarea en esta etapa es determinar el objetivos de modelado y formular el plan de modelado, organizar el equipo de modelado, reunir materiales de origen y desarrollar restricciones y especificaciones a partir de una descripción del propósito y alcance. La recolección de materiales es el foco de esta etapa. Recopile datos originales a través de resultados de investigación y observación, procesos comerciales, entradas y salidas del sistema original y varios informes para formar una tabla de datos básicos.
2.2 Paso 1: Definir entidades
Todos los miembros del conjunto de entidades tienen el mismo conjunto de características y atributos entre sí, y la mayoría de las entidades se pueden obtener a partir del material fuente recopilado. la tabla de datos básicos identificados directa o indirectamente. Con base en los términos que representan objetos en la lista de nombres de materiales de origen y los términos que terminan en "código", como códigos de clientes, códigos de agentes, códigos de productos, etc., identifique las entidades representadas por sus sustantivos, identifique inicialmente entidades potenciales y forme preliminarmente lista de entidades.
2.3 Paso 2: Definir conexiones
Solo se permiten conexiones binarias en el modelo IDEF1X, y las conexiones n-arias deben definirse como n conexiones binarias. De acuerdo con las necesidades y reglas comerciales reales, utilice la matriz de contactos de entidades para identificar relaciones binarias entre entidades y luego determine el potencial, el nombre de la relación y la descripción de la relación de conexión de acuerdo con la situación real, y determine el tipo de relación, si es una relación identificada, una relación no marcada (obligatoria u opcional Seleccionar) o relación incierta o relación clasificada. Si cada instancia de la entidad secundaria necesita ser identificada por una relación con la entidad matriz, es una relación de identificación; de lo contrario, es una relación de no identificación. En una relación no identificable, cada instancia de una entidad secundaria es obligatoria si está asociada con una sola entidad principal; de lo contrario, no es obligatoria. Las entidades padre e hijo se clasifican si representan el mismo objeto real.
2.4 Paso 3: Definir el código
Elimine la relación incierta generada en la etapa anterior mediante la introducción de entidades cruzadas y luego identifique los atributos de los códigos candidatos de entidades no cruzadas y entidades independientes. , se identifican instancias únicas de cada entidad y el código primario se determina a partir de los códigos candidatos. Para determinar la validez del código de asunto y la relación, está garantizada por reglas no vacías y reglas sin valores múltiples, es decir, un atributo de una instancia de entidad no puede estar vacío ni puede tener múltiples valores. al mismo tiempo. Descubra la relación definitiva de identificación errónea, descomponga aún más las entidades y finalmente cree la vista básica clave (diagrama KB) del modelo IDEF1X.
2.5 Paso 4: Definir atributos
Extraiga los sustantivos descriptivos de la tabla de datos de origen, desarrolle la tabla de atributos y determine el propietario del atributo. Defina atributos de clave no principal y verifique los atributos para valores que no sean nulos ni múltiples. Además, es necesario verificar las reglas para funciones totalmente dependientes y dependencias no transitivas para garantizar que una propiedad del código no principal deba depender del código principal, de todo el código principal y solo del código principal. Esto da como resultado una vista completa de atributos del modelo IDEF1X mejorado, que es al menos consistente con la tercera forma normal de teoría relacional.
2.6 Paso 5: Definir otros objetos y reglas
Definir tipo de datos, longitud, precisión, valor no nulo, valor predeterminado, reglas de restricción, etc. atributo. Defina información de objetos como desencadenadores, procedimientos almacenados, vistas, roles, sinónimos y secuencias.
3. Etapa de diseño de la estructura lógica
Convertir la estructura conceptual en un modelo de datos soportado por DBMS (como un modelo relacional) y optimizarlo. Al diseñar la estructura lógica, es necesario seleccionar el modelo de datos que sea más adecuado para describir y expresar la estructura conceptual correspondiente, y luego seleccionar el DBMS más adecuado.
Convertir el diagrama E-R en un modelo relacional en realidad convierte las entidades, sus atributos y las relaciones entre entidades en un modelo relacional. Esta conversión suele seguir los siguientes principios:
1) Convertir tipos de entidades en modelos relacionales. Los atributos de las entidades son los atributos de las relaciones. El código de la entidad es el código de la relación.
2) Una conexión m:n se convierte en un esquema relacional. Los códigos de las entidades asociadas a la conexión y las propiedades de la propia conexión se convierten en propiedades de la relación. Los códigos de relación son combinaciones de códigos de entidad.
3) La conexión 1:n se puede convertir en un modelo de relación independiente o se puede fusionar con el modelo de relación correspondiente en el extremo n. Si se convierte a un modo de relación independiente, el código de la entidad conectada a la relación y los atributos de la relación misma se convierten en atributos de la relación, y el código de la relación es el código de la entidad N-terminal.
4) Una conexión 1:1 se puede convertir en un esquema de relación independiente o fusionarse con el esquema de relación correspondiente en cualquiera de los extremos.
5) Múltiples relaciones entre tres o más entidades se convierten en modelos relacionales. Los códigos de las entidades conectadas por una conexión multivariante y los atributos de la conexión misma se convierten en atributos de la relación. Los códigos de relación son combinaciones de códigos de entidad.
6) La conexión entre entidades en el mismo conjunto de entidades, es decir, la autoconexión, también se puede procesar de acuerdo con las tres situaciones anteriores: 1:1, 1:n, m:n.
7) Se pueden fusionar patrones de relación con el mismo código.
Para mejorar aún más el rendimiento del sistema de aplicación de base de datos, generalmente es necesario modificar y ajustar adecuadamente la estructura del modelo de datos bajo la guía de la teoría de la estandarización. Esta es la optimización del modelo de datos. . Determinar las dependencias de datos. Eliminar conexiones redundantes. Determinar a qué paradigma pertenece cada modelo relacional. Decide si fusionarlos o dividirlos. En términos generales, esta relación se descompone en criterios 3NF, es decir:
Cada valor de la tabla solo se puede representar una vez.
Cada fila de la tabla debe estar identificada de forma única (con una clave única).
La información que no es clave y que depende de otras claves no debe almacenarse en la tabla.
4. Etapa de diseño físico de la base de datos
Elija la estructura física (incluida la estructura de almacenamiento y el método de acceso) que sea más adecuada para el entorno de aplicación del modelo de datos lógico. De acuerdo con las características del sistema de gestión de la base de datos y las necesidades de procesamiento, se llevan a cabo disposiciones de almacenamiento físico y diseño de índices para formar un patrón en la base de datos.
5. Etapa de implementación de la base de datos
Utilice el lenguaje de datos (como SQL) y su lenguaje host (como C) proporcionado por el DBMS para establecer una base de datos basada en los resultados de diseño lógico y diseño físico, y compilar, depurar la aplicación, almacenar los datos y ponerla en funcionamiento de prueba. La implementación de la base de datos incluye principalmente las siguientes tareas: usar DDL para definir la estructura de la base de datos, organizar el almacenamiento de datos, compilar y depurar aplicaciones y ejecutar pruebas de la base de datos. 6. Fase de operación y mantenimiento de la base de datos.
El sistema de aplicación de base de datos se puede poner en funcionamiento formal después de una operación de prueba. Los sistemas de bases de datos deben evaluarse, ajustarse y modificarse continuamente durante su funcionamiento. Incluyendo: volcado y recuperación de bases de datos, seguridad de bases de datos, control de integridad, supervisión, análisis y mejora del rendimiento de bases de datos, reorganización y reconstrucción de bases de datos.
Uso de herramientas de modelado
Actualmente existen muchas herramientas auxiliares de bases de datos (herramientas CASE) que aceleran el diseño de bases de datos, como Rational Rose de Rational Company, Erwin y Bpwin de CA Company, y Sybase Company PowerDesigner, Oracle Designer de Oracle Corporation.
ERwin se utiliza principalmente para establecer el modelo conceptual y el modelo físico de la base de datos. Puede describir gráficamente entidades, relaciones y atributos de entidades. ERwin admite el método IDEF1X. Al utilizar la herramienta de modelado ERwin para generar, cambiar y analizar automáticamente el modelo IDEF1X, no solo puede obtener excelentes modelos de funciones comerciales y requisitos de datos, sino también realizar la conversión del modelo IDEF1X al diseño físico de la base de datos. El modelo dibujado por la herramienta ERwin corresponde al modelo lógico y al modelo físico. En el modelo lógico, la caja de herramientas IDEF1X puede establecer y dibujar fácilmente relaciones de entidades y atributos de entidades gráficamente. En el modelo físico, ERwin puede definir las tablas y columnas correspondientes y convertirlas automáticamente en tipos adecuados para varios sistemas de gestión de bases de datos.
Los diseñadores pueden elegir la herramienta de modelado de diseño de base de datos correspondiente según sus necesidades. Por ejemplo, una vez completado el análisis de requisitos, los diseñadores pueden utilizar Erwin para dibujar diagramas ER, convertir los diagramas ER en modelos de datos relacionales y generar estructuras de bases de datos. Dibujar el diagrama de flujo de datos y generar la aplicación.
2. Habilidades de diseño de bases de datos
1. Antes de diseñar la base de datos (etapa de análisis de la demanda)
1) Comprender las necesidades del cliente y preguntar a los usuarios cómo ven la demanda futura. cambios . Deje que el cliente explique sus necesidades y, a medida que continúe el desarrollo, pregúntele con frecuencia para asegurarse de que sus necesidades aún estén dentro del propósito del desarrollo.
2) Comprender el negocio de la empresa puede ahorrar mucho tiempo en las etapas posteriores de desarrollo.
3) Presta atención a la entrada y salida.
Al definir los requisitos de campos y tablas de la base de datos (entradas), primero debe examinar los informes, consultas y vistas (salidas) existentes o diseñados para determinar qué tablas y campos son necesarios para admitir estas salidas.
Por ejemplo, si un cliente requiere un informe que ordene, desglose y resuma por código postal, debe asegurarse de que contenga un campo de código postal separado en lugar de colocar el código postal en un campo de dirección.
4) Crear diccionario de datos y diagrama ER.
Los diagramas ER y los diccionarios de datos pueden dejar claro a cualquiera que conozca las bases de datos cómo obtener datos de la base de datos. Los diagramas ER son útiles para mostrar las relaciones entre tablas, mientras que el diccionario de datos muestra el propósito de cada campo y los posibles alias. Esto es absolutamente necesario para la documentación de expresiones SQL.
5) Definir convenciones estándar de nomenclatura de objetos.
Se debe estandarizar la denominación de los distintos objetos de la base de datos.
2. Diseño de tablas y campos (diseño lógico de base de datos)
Principios de diseño de tablas
1) Estandarización y estandarización
Estandarización de datos Ayuda a eliminar la redundancia de datos en la base de datos. La normalización se presenta en varias formas, pero la Tercera Forma Normal (3NF) generalmente se considera el mejor equilibrio entre rendimiento, escalabilidad e integridad de los datos. En pocas palabras, el principio de diseño de tablas de una base de datos que cumple con el estándar 3NF es: "Un hecho en un solo lugar", es decir, una tabla solo contiene sus propios atributos básicos y debe descomponerse cuando no son sus propios atributos. . Las relaciones entre tablas están conectadas por claves foráneas. Tiene las siguientes características: Existe un conjunto de tablas dedicadas a almacenar datos relacionados, conectadas por claves.
Por ejemplo, una base de datos 3NF que almacena clientes y sus pedidos relacionados podría tener dos tablas: cliente y pedido. La tabla Pedido no contiene ninguna información sobre el cliente asociado con el pedido, pero se almacena un valor clave en la tabla que apunta a la fila de la tabla Cliente que contiene la información del cliente.
De hecho, en aras de la eficiencia, a veces es necesario no estandarizar la forma.
2) Basado en datos
El uso de datos basados en lugar de codificación hará que sea mucho más fácil modificar y mantener muchas políticas, mejorando en gran medida la flexibilidad y escalabilidad del sistema.
Por ejemplo, si la interfaz de usuario quiere acceder a fuentes de datos externas (archivos, documentos XML, otras bases de datos, etc.). ), se recomienda almacenar la información de ruta y conexión correspondiente en la tabla de soporte de la interfaz de usuario. Además, si la interfaz de usuario realiza tareas como el flujo de trabajo (enviar correos electrónicos, imprimir papelería, modificar el estado de los registros, etc.). ), entonces los datos que generan el flujo de trabajo también se pueden almacenar en la base de datos. La gestión de permisos de roles también se puede completar a través de la unidad de datos. De hecho, si el proceso se basa en datos, puede asignar una responsabilidad considerable a los usuarios, quienes mantendrán sus propios flujos de trabajo.
3) Considere varios cambios
Al diseñar una base de datos, considere qué campos de datos pueden cambiar en el futuro. Por ejemplo, el apellido es así (preste atención a los apellidos occidentales, como las mujeres que toman el apellido de su marido después del matrimonio, etc.). Por lo tanto, al configurar un sistema para almacenar información del cliente, almacene el campo de apellido en una tabla de datos separada. y agregue los campos de fecha de inicio y fecha de finalización, como fechas, para que se puedan realizar un seguimiento de los cambios en ese elemento de datos.
Principios de diseño de campos
4) Tres campos útiles que deben agregarse a cada tabla.
DRecordCreationDate tiene como valor predeterminado Now() en VB y GETDATE() en SQL Server.
SRecordCreator, por defecto es el usuario predeterminado NOT NULL en SQL Server.
NRecordVersion, el sello de versión del registro; útil para explicar exactamente por qué aparecen datos nulos o faltantes en un registro.
5) Utilice múltiples campos para direcciones y números de teléfono.
Una sola línea que describa una dirección postal no es suficiente. Address_Line1, Address_Line2 y Address_Line3 proporcionan mayor flexibilidad. Además, los números de teléfono y las direcciones de correo electrónico deben tener su propia tabla de datos, con sus propias categorías de tipo y etiqueta.
6) Utilice entidades de rol para definir columnas que pertenecen a una determinada categoría.
Cuando necesites definir cosas que pertenecen a una categoría específica o que tienen un rol específico, puedes usar entidades de rol para crear asociaciones de tiempo específicas para lograr la autodocumentación.
Por ejemplo, utilice la entidad PERSON y la entidad PERSON_TYPE para describir personas.
Por ejemplo, cuando John Smith, ingeniero, fue ascendido a John Smith, director, y finalmente ascendió al alto puesto de John Smith, CIO, todo lo que tuvo que hacer fue cambiar el valor clave de la relación entre las dos tablas PERSON y PERSON_TYPE y agregue un campo de fecha/hora para saber cuándo ocurrió el cambio. De esta forma, la tabla PERSON_TYPE contiene todos los tipos de personal posibles, como asistente, ingeniero, supervisor, CIO o CEO. Otra alternativa sería cambiar el registro de personal para reflejar el cambio en el nuevo título, pero no hay forma de rastrear el momento específico en el que se ubicó al individuo.
7) Seleccione tantos tipos de números y tipos de texto como sea posible.
Tenga especial cuidado al utilizar los tipos smallint y tinyint en SQL. Por ejemplo, si desea ver el total de ventas mensuales y el tipo de campo Total es pequeño, no podrá calcularlo si el total supera los $32 767.
Los campos de texto de tipo ID, como el ID del cliente o el número de pedido, deben ser más grandes de lo habitual. Supongamos que el ID del cliente tiene 10 dígitos. Luego debe establecer la longitud del campo de la tabla de la base de datos en 12 o 13 caracteres. Sin embargo, este espacio adicional no requiere reconstruir toda la base de datos en el futuro para permitir el crecimiento de la base de datos.
8) Agregue un campo de marca de eliminación.
Incluya un campo de marca de eliminación en la tabla para que las filas puedan marcarse para su eliminación. No elimine ninguna fila en la base de datos relacional; es mejor utilizar un programa de limpieza de datos y mantener cuidadosamente la integridad del índice.
3. Seleccionar claves e índices (diseño lógico de base de datos)
Principios de selección de claves:
1) 4 principios de diseño de claves
Cree claves externas para campos relacionados.
Todas las claves deben ser únicas.
Evita utilizar combinaciones de teclas.
Las claves externas siempre están asociadas a un campo clave único.
2) Utilice la clave principal generada por el sistema
Al diseñar la base de datos, utilice la clave generada por el sistema como clave principal, de modo que realmente controle la integridad del índice de la base de datos. De esta manera, la base de datos y los mecanismos no manuales controlan eficazmente el acceso a cada fila de los datos almacenados. Otra ventaja de utilizar claves generadas por el sistema como claves principales es que las fallas lógicas se descubren fácilmente cuando se tiene una estructura de claves consistente.
3) No utilice la clave del usuario (no haga que la clave principal sea actualizable)
Al decidir qué campo usar como clave para la tabla, debe tener cuidado con el campos que el usuario editará. En general, no seleccione campos que los usuarios puedan editar como palabras clave.
4) Las claves opcionales a veces se pueden utilizar como claves principales.
Al utilizar más claves opcionales como claves principales, puede crear un índice potente.
Principios para el uso de índices:
Los índices son una de las formas más efectivas de obtener datos de la base de datos. El 95% de los problemas de rendimiento de las bases de datos se pueden resolver mediante tecnología de indexación.
1) Utilice índices agrupados únicos para claves primarias lógicas, índices no agrupados únicos para claves del sistema (como procedimientos almacenados) e índices desagrupados para cualquier columna de clave externa. Considere cuánto espacio tiene la base de datos, cómo se accede a las tablas y si esos accesos son principalmente para lectura y escritura.
2) La mayoría de las bases de datos indexarán los campos de clave principal creados automáticamente, pero no olvide indexar las claves externas, que también son claves de uso común, como ejecutar una consulta para mostrar un registro en la tabla principal y todas las tablas relacionadas.
3) No indexe campos de notas/notas ni campos grandes (con muchos caracteres). Esto hará que el índice ocupe demasiado espacio de almacenamiento.
4) No indexar tablas pequeñas de uso común.
No establezcas ninguna clave para tablas de datos pequeñas, especialmente si tienen inserciones y eliminaciones frecuentes. El mantenimiento del índice para estas operaciones de inserción y eliminación puede llevar más tiempo que escanear el espacio de la tabla.
4. Diseño de integridad de datos (diseño lógico de base de datos)
1) Mecanismo de implementación de integridad:
Integridad de la entidad: clave primaria
Referencial integridad:
Eliminar datos en la tabla principal: eliminación en cascada; eliminación restringida; valor nulo
Insertar datos en la tabla principal: inserción recursiva
p>Actualizar datos en la tabla principal: actualización en cascada; actualización restringida; valor nulo
El DBMS puede lograr la integridad referencial de dos maneras: mecanismo de implementación de clave externa (reglas de restricción) y mecanismo de implementación de activación.
Integridad definida por el usuario:
No nulo; verificar; aumentar
2) Hacer cumplir la integridad de los datos mediante restricciones en lugar de reglas comerciales.
Utilizar sistemas de bases de datos para lograr la integridad de los datos. Esto incluye no sólo la integridad lograda mediante la estandarización, sino también la funcionalidad de los datos. También puede agregar activadores al escribir datos para garantizar la exactitud de los datos. No depende de la capa empresarial para garantizar la integridad de los datos; no puede garantizar la integridad entre tablas (claves externas), por lo que no se puede imponer a otras reglas de integridad.
3) Integridad de instrucciones obligatorias
Elimina datos dañinos antes de que ingresen a la base de datos. Activa la función de integridad indicada por el sistema de base de datos. Esto mantiene los datos ordenados y obliga a los desarrolladores a dedicar más tiempo a manejar las condiciones de error.
4) Utilice búsquedas para controlar la integridad de los datos.
La mejor manera de controlar la integridad de los datos es limitar las opciones del usuario. Siempre que sea posible, los usuarios deben recibir una lista clara de valores para elegir. Esto reducirá errores y malentendidos al escribir código y proporcionará coherencia en los datos. Algunos datos públicos son especialmente adecuados para la búsqueda: códigos de país, códigos de estado, etc.
5) Adoptar un punto de vista
Para proporcionar otra capa de abstracción entre la base de datos y el código de la aplicación, se puede establecer una vista especial para la aplicación sin necesidad de que la aplicación acceda al datos directamente. Hacerlo también le brinda más libertad a la hora de manejar cambios en la base de datos.
5. Otras habilidades de diseño
1) Evite el uso de disparadores.
La funcionalidad de un disparador a menudo se puede lograr de otras maneras. Los desencadenantes pueden convertirse en una distracción al depurar un programa. Si realmente necesita utilizar un disparador, es mejor que se concentre en registrarlo.
2) Utilice inglés común (o cualquier otro idioma) en lugar de codificación.
Al crear menús desplegables, listas e informes, es mejor ordenarlos por nombre en inglés. Si se requiere codificación, el inglés que el usuario conoce se puede adjuntar a la codificación.
3) Guardar información de uso común
Es muy útil tener una tabla dedicada a la información general de la base de datos. En esta tabla se almacena la versión actual de la base de datos, la última inspección/reparación (para acceso), el nombre del documento de diseño relevante, el cliente y otra información. Esto habilita un mecanismo simple para rastrear la base de datos, lo cual es especialmente útil en entornos que no son de cliente/servidor cuando un cliente se queja de que su base de datos no cumple con las expectativas y se comunica con usted.
4) Incluyendo el mecanismo de versión
El mecanismo de control de versiones se introduce en la base de datos para determinar la versión de la base de datos que se está utilizando. Las necesidades del usuario siempre cambian con el tiempo. Es posible que eventualmente necesite modificar la estructura de la base de datos. Es más conveniente almacenar la información de la versión directamente en la base de datos.
5) Preparación de archivos
Documente todos los accesos directos, convenciones de nomenclatura, restricciones y funcionalidades.
Utilice herramientas de bases de datos para anotar tablas, columnas, activadores y más. Útil para desarrollo, soporte y seguimiento de cambios.
Documentar la base de datos, ya sea dentro de la base de datos o por separado. De esta forma, cuando busques la segunda versión más de un año después, las posibilidades de cometer un error se reducirán considerablemente.
6) Probar, experimentar y repetir pruebas
Después de establecer o modificar la base de datos, los campos de datos deben probarse con los datos recién ingresados por el usuario. Lo más importante es permitir que los usuarios prueben y trabajen con los usuarios para garantizar que los tipos de datos elegidos satisfagan las necesidades comerciales. Es necesario completar las pruebas antes de que la nueva base de datos entre en servicio real.
7) Verificar el diseño
Una técnica común para verificar el diseño de la base de datos durante el desarrollo es verificar la base de datos a través de un prototipo de aplicación respaldado por una base de datos. En otras palabras, para cada prototipo de aplicación que termine expresando datos, asegúrese de examinar el modelo de datos y comprender cómo extraer los datos.
Tercero, especificaciones de nomenclatura de bases de datos
1. Nombramiento de entidades (tablas)
1) Las tablas se nombran con sustantivos o frases nominales, asegúrese de que el nombre de la tabla sea el mismo. es plural Sigue siendo extraño. Además, se definen reglas simples para los alias de la tabla (por ejemplo, si el nombre de la tabla es una palabra, el alias toma las primeras cuatro letras de la palabra; si el nombre de la tabla es dos palabras, toma las dos primeras letras de cada palabra para forme un alias de cuatro letras; si el nombre de la tabla consta de tres palabras, tome una de las dos primeras palabras, luego dos letras de la última palabra, el resultado seguirá siendo un alias de cuatro letras, y así sucesivamente)
Para la hoja de trabajo, el nombre de la tabla puede tener el prefijo WORK_, seguido del nombre de la aplicación que utiliza la tabla. Durante el proceso de denominación, las abreviaturas se pueden unir según la semántica. Tenga en cuenta que, dado que ORCLE unificará los nombres de los campos en mayúsculas o minúsculas, es necesario subrayarlos.
Por ejemplo:
Definición de abreviatura Ventas:Sal Ventas;
Pedido:Ord order;
Detalles: Detalles Dtl;
p>
Luego nombre la lista de pedidos de ventas: Sal_Ord_Dtl;
2) Si el nombre de la tabla o campo tiene solo una palabra, se recomienda usar la palabra completa y no la abreviatura.
Por ejemplo:
Definición de la abreviatura Material Ma para artículos;
La lista de artículos se llama Material, no Ma.
Pero el código del artículo del campo es: Ma_ID no es el ID del material.
3) Prefijo Z delante de todas las tablas que almacenan listas de valores.
El propósito es ordenar estas categorías de lista de valores al final de la base de datos.
4) Agregue el prefijo X antes de nombrar todas las clases redundantes (principalmente tablas acumulativas).
Las clases redundantes son campos o tablas que se agregan cuando la base de datos se desnormaliza con el propósito de mejorar la eficiencia de la base de datos.
5) Asigne un nombre a la clase asociada conectando las dos clases base con un guión bajo, luego agregue el prefijo R y luego enumere los dos nombres de tablas o abreviaturas de los nombres de las tablas en orden alfabético.
Las tablas de asociación se utilizan para almacenar relaciones de muchos a muchos.
Si el nombre de la tabla asociada supera las 10 letras, el nombre de la tabla original debe abreviarse. Si no es por otro motivo, se recomienda utilizar abreviaturas.
Por ejemplo, si existe una relación de muchos a muchos entre el objeto de la tabla y él mismo, la tabla que contiene la relación de muchos a muchos se denomina: r_object
Departamento de tabla y Empleado; existe una relación de muchos a muchos; el nombre de la tabla asociada es R_Dept_Emp.
2. Nomenclatura de atributos (columnas)
1) Utilice nombres de columnas significativos. Las columnas de la tabla deben adoptar un conjunto de reglas de diseño clave. Cada tabla tendrá una identificación automática como clave principal y la clave primaria lógica se definirá como el primer conjunto de claves primarias candidatas. Si el código es generado automáticamente por la base de datos, se denominará ID; si es un código lógico personalizado, se denominará con la abreviatura y "ID". Si la clave es un número, puede usar _NO como sufijo; si es un carácter, puede usar el sufijo _CODE. Los nombres de las columnas deben utilizar prefijos y sufijos estándar.
Por ejemplo, el campo numérico de un pedido de venta se llama SAL_ORD_ID. Si todavía hay un número generado automáticamente por la base de datos, asígnele el nombre: ID.
2) Todos los atributos deben tener el sufijo del tipo correspondiente. Tenga en cuenta que si se requieren otros sufijos, deben colocarse antes del sufijo de tipo.
Nota: El tipo de datos es un campo de texto y el sufijo de tipo TX se puede omitir. Para algunos campos con tipos obvios, no es necesario escribir un sufijo de tipo.
3) Utilice nombres de prefijos
El uso de un prefijo unificado para los nombres de las columnas de cada tabla simplificará enormemente la escritura de expresiones SQL. Tiene desventajas, como romper la funcionalidad de la herramienta de unión automática de tablas que vincula nombres de columnas comunes con algunas bases de datos.
3. Nomenclatura de vistas
1) Las vistas tienen el prefijo V y otras reglas de nomenclatura son similares a las tablas.
2) La nomenclatura debe reflejar cada vista; función.
4. Nombramiento de los activadores
El prefijo del activador es TR y el nombre del activador es el nombre de la tabla correspondiente con un sufijo. y para eliminar un disparador, agregue '_D', agregue '_U' al disparador de actualización, como: TR_Customer_I, TR_Customer_D, tr_customer_u.
5. Nombre del procedimiento almacenado
El procedimiento almacenado debe comenzar con 'UP_', que es diferente del procedimiento almacenado del sistema. Las siguientes partes tienen principalmente la forma de verbos y objetos, y cada componente está separado por un guión bajo. Por ejemplo, el procedimiento almacenado para agregar una cuenta de agente es 'UP_Ins_Agent_Account'.
6. Nombres de variables
Los nombres de las variables están en minúsculas. Si tienen forma de frase, separe cada palabra con un guión bajo, como @my_err_no.
7. Otras consideraciones al nombrar
1) El nombre anterior no debe exceder el límite del sistema de 30 caracteres. La longitud de los nombres de las variables está limitada a 29 caracteres (sin incluir el carácter de identificación @).
2) Los objetos de datos y las variables deben nombrarse con caracteres en inglés y los nombres en chino están prohibidos. Nunca deje espacios entre caracteres en los nombres de objetos.
3) Utilice palabras reservadas con cuidado para asegurarse de que los nombres de sus campos no entren en conflicto con palabras reservadas, sistemas de bases de datos o métodos de acceso comunes.
5) Mantenga la coherencia en los nombres y tipos de campos. Al nombrar campos y especificar tipos de datos, asegúrese de garantizar la coherencia. Si el tipo de datos en una tabla es un número entero, no lo cambie al tipo de carácter en otra tabla.