Cómo utilizar SQL2005 para crear una base de datos empresarial sencilla
Cosas a tener en cuenta durante el diseño e implementación de datos (opinión personal):
1 Reglas de nomenclatura:
1) Tabla: prefijo de módulo + palabra en inglés, Such como BBS_UserInfo
2) Campo: prefijo de tabla + palabra en inglés, como U_Name
2. Tres paradigmas principales:
Intente cumplir con los tres principales. Paradigma de requisitos de diseño de bases de datos.
La primera forma normal (1NF) significa que cada columna de la tabla de la base de datos es un elemento de datos básico indivisible. No puede haber múltiples valores en la misma columna, es decir, un atributo en una entidad no puede tener. varios valores. o un atributo no se puede repetir.
Segunda forma normal (2NF): requiere que cada instancia o fila en la tabla de la base de datos se pueda distinguir de manera única y que los campos que no son clave no deben ser parcialmente funcionales de ningún campo clave candidato en la tabla de la base de datos. Dependencias ( Las dependencias funcionales parciales se refieren a la existencia de combinaciones de palabras clave en las que algunos campos determinan campos no clave), es decir, todos los campos no clave dependen completamente de cualquier conjunto de palabras clave candidatas. .
Tercera Forma Normal (3NF): Se requiere que la tabla de la base de datos no contenga información de clave no primaria que ya esté incluida en otras tablas. Basado en la segunda forma normal, si no la hay. -campos clave en la tabla de datos, cualquiera La dependencia funcional transitiva de los campos clave candidatos se ajusta a la tercera forma normal.
3. Estructura de datos:
Establecer las relaciones necesarias de clave primaria y clave externa, establecer consultas conjuntas de múltiples tablas, procedimientos almacenados de consultas de condiciones complejas, etc.
4. Conserve los documentos de diseño de la base de datos (esto es especialmente importante para el desarrollo secundario).
-------------- Línea divisoria de la amistad (la siguiente es una recopilación de información, se ha olvidado la fuente del texto original)------- -------
1 Especificaciones de diseño y denominación de campos y tablas de la base de datos
1.1 Especificaciones de denominación de las tablas de la base de datos: el prefijo de la tabla debe utilizar la abreviatura del nombre en inglés del sistema o módulo (todo en mayúsculas) o la primera letra en mayúscula). Si la función del sistema es simple y no está dividida en módulos, puede utilizar la abreviatura del nombre en inglés del sistema como prefijo de la tabla. De lo contrario, utilice la abreviatura del nombre en inglés de cada módulo como prefijo de la tabla. Por ejemplo, si hay un módulo llamado BBS (abreviado como BBS), entonces los nombres de todos los objetos en la base de datos deben agregarse con este prefijo: BBS_+ nombre del objeto de la base de datos, anotación BBS_CustomerInfo El nombre de la tabla de información del cliente en el módulo del foro debe ser fácil de entender y puede La función de la tabla de expresiones puede ser una palabra completa en inglés o una abreviatura de una palabra en inglés. El nombre de la tabla debe ser una palabra en inglés o una abreviatura en inglés que sea fácil de entender y pueda expresar la función de la tabla. Puede ser una palabra en inglés completa o una abreviatura en inglés. La primera letra debe estar en mayúscula. Si la tabla actual puede representarse con una palabra en inglés, utilice la palabra en inglés completa, por ejemplo: el nombre de la tabla del cliente en la información del sistema puede denominarse: SYS_Customer; más palabras, intente escribirlo en forma completa. Si es demasiado largo, puede utilizar la abreviatura de dos palabras en inglés, por ejemplo: la tabla de materiales del cliente en la información del sistema puede denominarse: SYS_Custoder: SYS_Custoder El nombre de la tabla. No debe ser demasiado largo (generalmente no más de tres palabras en inglés). Al nombrar una tabla, utilice la forma singular del nombre de la tabla. Por ejemplo, utilice Empleado en lugar de Empleados. Por ejemplo, si el nombre de la orden de compra es PO_Order, entonces la tabla de detalles de la orden de compra es PO_OrderDts. Para una tabla con una tabla de detalles maestra, la tabla de detalles debe contener dos campos: la clave principal SN y el campo SN de. escriba int La función del campo SN Es la secuencia que junto con la clave principal constituye la palabra clave de la tabla de detalles, además de identificar la palabra clave de la tabla de detalles, identifica la palabra clave de la tabla de detalles, identifica la palabra clave de la tabla de detalles e identifica el detalle. registro, como 1, 2, 3..... . La tabla debe estar llena de información descriptiva. El nombre de la tabla del backend debe ser el mismo que el nombre de la tabla del frontend en la medida de lo posible, y la única tabla del backend debe tener el sufijo _b. Por ejemplo, r_gggd_b
1.2 Convención de nomenclatura de campos de tabla
La denominación de los campos de la base de datos debe seguir las siguientes convenciones: Utilice nombres de campo significativos.
El nombre del campo debe ser fácil de entender y debe ser una palabra en inglés o una abreviatura de palabra en inglés que pueda expresar la función del campo. La primera letra de la palabra debe estar en mayúscula, generalmente no más de tres palabras en inglés. Por ejemplo: el número de teléfono en la tabla de información de la persona puede denominarse producto y el nombre del producto en los detalles puede ser NombreProducto. (Se recomienda utilizar generalmente palabras completas en inglés). Para cualquier campo de código que pertenezca al sistema (solo se usa para marcar la unicidad y marcar los campos utilizados internamente por el programa), el nombre es "ID", representado por un número entero o un número entero largo según el aumento en la cantidad de datos. que se pueda determinar, se toma el valor máximo en el registro más 1, este campo suele ser la clave principal. Los campos numéricos en el sistema que pertenecen al ámbito comercial representan una cierta cantidad de información comercial, como información de datos y cantidad de documentos. Se recomienda que dicho campo se llame: "código" y su tipo de datos sea varchar. necesita agregar un índice único. Al nombrar columnas en una tabla, no repita el nombre de la tabla, por ejemplo, evite usar un campo llamado ApellidoEmpleado en una tabla llamada Empleado. No incluya tipos de datos en los nombres de las columnas. Especificaciones de diseño Todos los campos deben tener valores predeterminados en el momento del diseño, excepto los siguientes tipos de datos: marca de tiempo, imagen, fecha y hora, pequeña fecha y hora, identificador único, binario, sql_variant, binario y varbinary. El valor predeterminado del tipo de carácter es una cadena vacía''; el valor predeterminado del tipo numérico es el valor 0; el valor predeterminado del tipo lógico es el valor 0;
Donde: el valor del valor 0 de todos los tipos lógicos. en el sistema es "falso" el valor 1 tiene el valor "verdadero".
Los campos de tipo datetime y smalldatetime no tienen valor predeterminado y deben ser NULL.
Se recomienda utilizar varchar en lugar de nvarchar cuando el campo está definido como una cadena. Se recomienda utilizar los siguientes campos en la mayoría de las tablas (como formularios de reembolso, formularios de solicitud):
Nombre de campo Descripción Tipo Valor predeterminado
CreatorID Creator int0
CreatedTime Create Time DatetimeNULL descripción del campo
La descripción (Descripción) de cada campo de la base de datos es la siguiente: Intenta cumplir con los estándares de la tercera forma normal (3NF). Cada valor de la tabla solo se puede expresar una vez. Cada fila de la tabla debe tener una etiqueta única. La información que no sea clave y que dependa de otras claves no debe almacenarse en la tabla si un campo está realmente asociado con una clave en otra tabla. , y no Diseñado para ser referenciado por claves externas, se requiere un índice. Si el campo está relacionado con un campo de otra tabla, indícelo. Si un campo requiere una consulta condicional que no sea una consulta difusa, indícela. Excepto la clave principal, a la que se le permite utilizar un índice agrupado, todos los demás campos deben utilizar un índice no agrupado. Los campos deben completarse con información descriptiva
2 Nomenclatura de procedimientos almacenados y especificaciones de diseño
2.1 Especificaciones de nomenclatura
La denominación de procedimientos almacenados debe seguir las siguientes convenciones de nomenclatura: USP _ + Abreviatura del módulo del sistema (similar al prefijo de la tabla) + _ + Identificador de función + Representa el nombre de la tabla principal (sin prefijo) de la operación del procedimiento almacenado o la palabra en inglés de la función o la abreviatura de la palabra en inglés.
Si el procedimiento almacenado solo opera en una tabla, se recomienda utilizar el nombre del procedimiento almacenado como el nombre de la tabla operada por el procedimiento almacenado (sin el prefijo). Esto hace que sea más fácil encontrar el procedimiento almacenado correspondiente según el nombre de la tabla.
Para encontrar y mantener rápidamente procedimientos almacenados entre muchos procedimientos almacenados, los clasificamos y nombramos de la siguiente manera según sus roles en el sistema: (El siguiente ejemplo supone que el módulo donde se encuentran los procedimientos almacenados se llama ORG )
El primer prefijo del rol y el segundo prefijo del nombre
(Identificador de función) ejemplo
Agregar el procedimiento almacenado de USP_ORGAdUSP_ORG_Add_Employee
Modificar el procedimiento almacenado de USP_ORGUptUSP _ORG_Upt_Employee
Eliminar el procedimiento almacenado de USP_ORGUptUSP _ORG_Upt_Employee Modificado por: Liu Min
Fecha de modificación: 2002.12.22
Motivo de la modificación: (descripción detallada Motivos específicos)
*/
Proceso de creación [dbo].[USP_GetLMSSum]
@ProductionType int= 1, - Tipo de producción (1 - producción interna; 0 - Procesamiento subcontratado)
@DeptID int=0, - Departamento de producción
@ItemID int=0, - Material
@StartDate datetime='2002- 11-26', - Fecha de inicio del intervalo contable
@EndDate datetime='2002-12-25' - Fecha de finalización del intervalo contable
AS
/*
log1 antiguo
-- Garantía casera
INSERT INTO #LMSDts
SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,
dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.ItemName,
ISNULL(dbo.fItem. Model, N'') AS Model, ISNULL (dbo.fUnit.UnitName, N'')
AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,
dbo.mLMS.CreateTime
finalizar registro1 antiguo
*/
--log1 nuevo
-- Garantía casera
INSERTAR EN # LMSDts
SELECCIONAR dbo.iStockBill.DeptID, dbo.fDept.DeptName,
dbo.mLMS.ItemID AS ItemInterID, dbo. fItem.ItemName,
ISNULL(dbo.fItem.Model, N'') AS Modelo, ISNULL(dbo.fUnit.UnitName, N'')
AS UnitName, dbo. mLMS.Qty, dbo.mLMS.TransType, dbo.mLMS.OrderType,
dbo.mLMS.CreateTime
--end log1 new
3 Ver nombres convención
3.1 Convenciones de nomenclatura
Siga la siguiente convención de nomenclatura al nombrar vistas: UV _ + abreviatura del módulo del sistema (similar al prefijo de la tabla) + _ + identificador de función
+ (similar al prefijo de tabla) + _ + identificador de función + representa el nombre de la tabla principal (sin prefijo de tabla) o la palabra en inglés o la abreviatura de la palabra en inglés de la función consultada por la vista.
Si la vista solo consulta una tabla, se recomienda que el nombre de la vista sea el nombre de la tabla consultada por la vista (sin el prefijo). Esto ayuda a encontrar la vista correspondiente según el nombre de la tabla.
Para encontrar y mantener rápidamente vistas entre muchas vistas, clasificamos y nombramos las vistas del sistema de la siguiente manera según sus funciones
: (El siguiente ejemplo supone que el módulo donde se encuentra la vista se encuentra se llama ORG)
Rol primer prefijo segundo nombre de prefijo
Ejemplo (Identificador de función)
Ver UV_ORGQryUV_ORG_Qry_Employee para consulta de documento
La vista UV_ORGRptUV_ORG_Rpt_GetEmployee utilizada para informar estadísticas
La vista UV_ORGOthUV_ORG_Oth_SetSystemMessage utilizada para el procesamiento de algún proceso especial
Si solo hay un nivel de vista en el sistema, si hay varios niveles, se requiere Distinguir su nivel de pertenencia de la siguiente manera: UV + nivel de pertenencia + _ + siguiente parte
Por ejemplo:
UV1_ORG_Add_Subject (no llamar a ninguna otra vista)
UV2_ORG_Upt_Subject (llamada vista Capa 1)
UV3_ORG_Qry_Subject (llamada vista Capa 2)
3.2 Especificaciones de Diseño
Se debe indicar lo siguiente en la vista:
Propósito: Describir la función de esta vista.
Creador: el nombre de la persona que creó esta vista por primera vez. Utilice aquí su nombre completo en chino; no se permiten abreviaturas en inglés.
Modificador, fecha de modificación, motivo de modificación: Si alguien modifica esta vista, se debe agregar el nombre del modificador, fecha de modificación y motivo de modificación delante de esta vista.
Agrega comentarios en chino a cada parámetro y variable de la vista.
El ejemplo es el siguiente:
/*
Propósito: Consultar los objetos a entrenar este mes
Creador: Garfield
Hora: