Cómo hacer modelado de datos

Construir una entidad

Esto también es una iteración. Si hay una demanda primero, intente comprender la demanda y comprender qué debe lograr el proyecto o software actual. Si no comprende o no está seguro, comuníquese con el cliente de manera oportuna y confirme dos veces la demanda con el cliente. e implementarlo en el paquete, pero muchas veces primero necesitamos comunicarnos con los clientes, luego implementar los resultados de la comunicación en requisitos y luego especificarlos en entidades. Este artículo puede involucrar alguna terminología de modelado en EA (Enterprise Architect 7.1); cada entidad se considera un paquete. No existe comparabilidad entre varias herramientas de modelado, como Visio, EA, PowerDesigner, ERWin, etc. De hecho, como empleados somos muy exigentes. Utilizaremos cualquiera de los productos de la empresa.

Por ejemplo, en un sitio web de comercio electrónico B2C, esta demanda ya no es común: ¡los clientes pueden comprar libremente en el sitio web! Lo desglosamos con este sencillo ejemplo para explicar todo el proceso de modelado de datos. De la oración anterior, podemos obtener tres entidades: cliente, sitio web y producto, como defiende Scrum (un marco de desarrollo ágil), cada sprint debe producir algo real; Bien, entonces durante la fase de modelado conceptual, deberíamos generar entidades. Clientes y Artículos (desechamos el sitio web como entidad y no lo necesitamos).

Al crear estos dos paquetes, recordamos hablar sobre la comprensión de los requisitos y las reglas comerciales y usarlos como Se añaden anotaciones al paquete, que se convertirán en una parte muy importante del futuro diccionario de datos, los llamados metadatos. Por cierto, EA u otras herramientas de modelado deberían poder generar automáticamente el diccionario de datos, pero el formato final generado puede variar. Por ejemplo, en la nota del cliente, podemos escribir que el usuario debe registrar su cuenta completando su información personal básica y una dirección de correo electrónico, y luego usar esa dirección de correo electrónico como cuenta de inicio de sesión para iniciar sesión en el sistema para realizar transacciones.

En la etapa de modelado conceptual, solo necesitamos centrarnos en las entidades sin prestar atención a ningún detalle de implementación. Mucha gente quiere descubrir la estructura específica de la tabla, los índices, las restricciones e incluso los procedimientos almacenados en esta etapa, ¡pero esto es innecesario! ! Porque estas cosas requieren que las consideremos en la etapa de modelado físico, cuando es demasiado pronto para considerarlas. Algunas personas pueden preocuparse por perder o perder algunas entidades en esta etapa. No se preocupe, en 2013 muchas empresas están adoptando el modelo de desarrollo Scrum. Siempre que las entidades que está abstrayendo actualmente coincidan con la historia de usuario actual o las entidades dentro de la historia de usuario actual, ¡puede abstraerlas! Si dice que nuestras historias de usuario son demasiado grandes, tienen demasiadas entidades y son difíciles de abstraer, entonces realmente no hay manera. Recomiendo que su equipo vuelva a convocar la reunión de planificación del sprint.

Modelado lógico

Etapa de modelado lógico

Refina las entidades en tablas específicas y enriquece la estructura de la tabla. Los productos de esta etapa son tablas específicas y otros objetos de la base de datos (incluidas claves primarias, claves externas, columnas de atributos, índices, restricciones e incluso vistas y procedimientos almacenados) que se pueden generar en la base de datos. En mi proyecto real, excepto las claves primarias y externas, todos los demás objetos de la base de datos se establecen durante la etapa de modelado físico porque otros objetos de la base de datos están más cerca del desarrollo y deben desarrollarse juntos. Por ejemplo, podemos implementar restricciones de JavaScript en páginas web, capas de lógica empresarial o bases de datos. Dónde hacerlo depende de las necesidades prácticas, el rendimiento y la seguridad.

Según la entidad del cliente y nuestra comprensión de las necesidades, podemos dibujar la siguiente estructura de tabla: tabla de información básica del usuario (usuario), tabla de cuenta de inicio de sesión (cuenta) y tabla de comentarios (Commnets). hacer comentarios sobre el producto. Por supuesto, en este caso habría más tablas.

Si los usuarios necesitan cargar su propio avatar (imagen), deberíamos tener una tabla de imágenes.

Para las entidades de productos, necesitamos crear una tabla de información básica del producto (producto). Por lo general, nuestros productos tendrán su propia Categoría de Producto o incluso SubCategoría de Producto, y algunos productos tendrán descuentos debido a días festivos y otros motivos. Porque para obtener un mejor rendimiento, crearemos la tabla ProductDiscount correspondiente y un producto tendrá varias imágenes, por lo que la tabla ProductPicture y la tabla ProductPictureRelationship (por supuesto, también podemos diseñar solo una tabla de imágenes para almacenar todas las imágenes, usuarios, productos y otros). Algunas personas dicen que los productos y las imágenes tienen una relación de uno a muchos y que no es necesario crear una tabla de relaciones. Sí, creo que siempre que no sea una relación uno a uno, me gustaría crear una tabla de relaciones para relacionar las dos entidades. Las ventajas de este enfoque son una mejor legibilidad, una correspondencia uno a uno entre entidades y tablas y un mantenimiento más sencillo. En lugar de mantener una tabla de imágenes, solo necesitamos mantener una tabla relacional con solo dos columnas (ProductID y PictureID).

Cuando un cliente realiza una transacción, es decir, cuando un cliente tiene una relación con un producto, necesitamos una tabla de transacciones. Un cliente comprará uno o más artículos porque una transacción involucrará uno o más productos. Por tanto, es necesario crear una relación entre transacciones y descuentos de productos (los descuentos de productos y los productos tienen una correspondencia uno a uno). Lo llamamos tabla de proyecto, que almacena el TransactionID y el ProductDiscountID involucrados. Por cierto, muchos sistemas necesitan tener capacidades de auditoría, como descuentos en un producto a lo largo de los años y las ventas correspondientes. No consideraremos realizar una auditoría aquí por ahora.

De esta forma, en función de los requisitos, determinamos qué tablas son necesarias específicamente para enriquecer aún más las columnas de cada tabla. Por supuesto, esto implicará la selección de claves primarias, o el uso de claves sustitutas, asociación de claves externas, establecimiento de restricciones y otros detalles. Aquí, creo que está bien siempre que se puedan implementar las columnas de cada entidad, porque a medida que el proyecto crece, muchas columnas de la tabla cambiarán en consecuencia. En cuanto a otros detalles, los diferentes proveedores de bases de datos tienen diferentes detalles de implementación. Hay otro punto sobre la elección de la clave principal. A algunas personas les gusta usar la ID de crecimiento automático como la clave principal de todas las tablas, mientras que otras esperan encontrar uno o más atributos que solo puedan identificar el registro actual como la clave principal; ID de crecimiento automático como clave primaria sustituta. Esto será un problema en el futuro cuando se construya un almacén de datos con múltiples sistemas comerciales actuales similares como fuentes de datos (en múltiples sistemas, hay una gran cantidad de claves primarias duplicadas en la misma tabla ); utilizando uno o varios atributos como clave principal, independientemente de si la clave principal es editable o no, se debe considerar la eficiencia de lectura y escritura. Por lo tanto, no existen principios únicos y los autores simplemente recomiendan algunos factores a considerar.

Modelado físico

Fase de modelado físico

EA puede generar los códigos SQL correspondientes a partir de varios objetos de base de datos creados en la fase de modelado lógico y ejecutarlos para crear la base de datos concreta correspondiente. objetos (la mayoría de las herramientas de modelado pueden generar automáticamente código DDL SQL). Pero en esta etapa, no solo necesitamos crear objetos de base de datos, sino también dividir los datos (división horizontal o vertical) según las necesidades comerciales, como un sitio web B2B. Podemos colocar a los comerciantes y a los usuarios generales en la misma tabla, pero por motivos de rendimiento, podemos dividirlos en dos tablas a medida que aumenta el volumen de negocios, la tabla de transacciones se vuelve cada vez más grande y todo el sistema se vuelve cada vez más lento; En este momento, puede considerar la división de datos, o incluso la separación de lectura y escritura (es decir, para implementar el modo maestro-esclavo, MYSQL/SQLSERVER puede usar la replicación, por supuesto, diferentes motores de almacenamiento usan diferentes soluciones), esta etapa también implican agrupamiento. Si es arquitecto o modelador de datos, puede decirle al DBA, está bien, ya terminé, ahora es el momento de que lo muestre.

Creo que todo el mundo conoce el paradigma y mucha gente considera 3NF como un clásico. 3NF es realmente bueno, pero se lanzó hace décadas. La cantidad de datos y la frecuencia de acceso en ese momento no era de un orden de magnitud en comparación con 2012. Por lo tanto, no podemos adherirnos ciegamente a 3NF en todo el proceso de modelado de datos, bajo la premisa de garantizar que la estructura de datos sea clara y mejorar el rendimiento tanto como sea posible es nuestro enfoque, por lo que el autor aboga firmemente por la redundancia de datos adecuada.

Arriba, el autor expresó sus puntos de vista sobre el modelado de datos con algunos ejemplos prácticos, esperando que sea útil para la lectura.

En el proceso de modelado de datos, no queremos completar el diseño de la base de datos en un solo paso. El autor nunca ha tenido experiencia exitosa en el diseño de un almacén de datos o una base de datos transaccional. A medida que avanzaba el proyecto, el cliente y el equipo de desarrollo agregaron conocimientos comerciales, por lo que el diseño original siguió mejorando. Después de todo, el modelado de datos o el diseño de bases de datos no es nuestro objetivo final. ¡Lo que necesitamos es un software que sea potente, que funcione bien, que sea fácilmente escalable y fácil de usar!