El diseño de la base de datos es uno de los factores más importantes que contribuyen al rendimiento de una aplicación. En consecuencia, qué tan bien está diseñada la base de datos es de suma importancia. El diseño de la base de datos tiene que ver con la organización eficiente de los datos en función de los flujos de trabajo del producto, la hoja de ruta futura y los patrones de uso esperados.
El resultado de un ejercicio de diseño de base de datos es un modelo de datos. Un modelo de datos representa todos los objetos, entidades, atributos, relaciones y restricciones del sistema. En términos generales, los modelos de datos pueden ser de dos tipos:lógicos o físico . La representación del modelo de datos se realiza mediante la creación de un diagrama ER, también conocido como diagrama entidad-relación, diagrama ERD o diagrama de base de datos.
El modelo de datos físicos se relaciona con los detalles de implementación reales en la base de datos. El modelo de datos lógicos, por otro lado, abstrae los tecnicismos de implementación. Esto hace que el modelo de datos lógicos sea consumible para el negocio. Una diferencia clave entre los dos modelos es que el modelo lógico es independiente de la base de datos, mientras que el modelo físico tiene que ser específico para la base de datos en uso.
El diseño adecuado de la base de datos a menudo se subestima y se descuida durante el desarrollo de la aplicación. El costo de este descuido generalmente se percibe mucho más tarde cuando aparecen nuevas características de la aplicación o cuando las características antiguas requieren un cambio. Aquí es cuando el diseño de la base de datos deja de tener sentido. Si bien no es posible preparar el diseño de una base de datos para el futuro, es muy posible hacer el esfuerzo de comprender mejor los casos de uso comercial y diseñar la base de datos en consecuencia. Lea más sobre consejos para un mejor diseño de base de datos aquí.
Con eso en mente, repasemos los pasos del diseño de la base de datos.
Paso 1:recopilar los requisitos comerciales
El primer paso es hablar con la empresa sobre sus requisitos. Si la conversación es efectiva, debería generar suficiente información para comenzar a trabajar en un modelo de datos conceptual, que es una abstracción del modelo lógico. Hablar con la empresa, en primer lugar, proporciona una imagen completa de los procesos comerciales que, a su vez, brinda información sobre los diversos puntos de datos que es importante que la empresa capture y rastree. Por ejemplo, en un modelo de reserva de taxis, vale la pena hacer las siguientes preguntas:
- ¿La empresa quiere los datos de seguimiento del vehículo en la base de datos, independientemente de si hay un viaje activo o no? Si es así, entonces el campo
vehicle_trip_iden la tablavehicle_tripssería anulable . De lo contrario, no será anulable . - ¿La empresa quiere el historial de cambios en
trip_status? almacenado en la base de datos? En caso afirmativo, cada vez quetrip_statuscambios, habrá otro registro en lostripsmesa. De lo contrario, cada vez quetrip_statuscambios,trip_statusse actualizará en su lugar.
Como se muestra en este ejemplo, según los aportes de la empresa, terminaría eligiendo una opción sobre la otra. Daría como resultado el cambio de las entidades en cuestión y sus relaciones.
La recopilación de requisitos generalmente también implica iniciar una conversación sobre la seguridad de los datos, como qué datos se enmascararán y cifrarán. El ejercicio de recopilación de requisitos da como resultado un documento de requisitos a menudo respaldado por un borrador de trabajo del modelo de datos conceptual.
Paso 2:comprender la hoja de ruta comercial
Las empresas cambian sus procesos todo el tiempo; su capacidad de adaptación los hace menos propensos a fracasar. Cambiar los procesos comerciales significa cambiar los flujos de trabajo y los modelos de datos. Aunque no es posible conocer estos cambios con mucha antelación, sí es posible estar al día con la hoja de ruta empresarial.
Por ejemplo, si una empresa tiene planes de apuntar a una nueva región geográfica, el modelo debería tener en cuenta la compatibilidad con idiomas, monedas, zonas horarias, etc. Los beneficios de comprender la hoja de ruta comercial a largo plazo a menudo se muestran en una transición más fluida a nuevos procesos comerciales.
Permítanme compartir un ejemplo más, que se trata más de prioridades comerciales en constante evolución. El negocio de los taxis se vio gravemente afectado al comienzo de COVID-19. Como empresa de taxis, desea actuar de manera preventiva para asegurar a las personas que está haciendo todo lo posible para asegurarse de que su viaje en el taxi sea lo más seguro posible, que el vehículo se desinfecte todos los días, que el conductor use una máscara en todo veces, y que hay desinfectante para manos disponible en la cabina. Ahora, para capturar toda esta información, cambia a dos entidades, drivers y vehicles , sería necesario. Varios campos de indicadores booleanos deben agregarse a estas entidades para atender este caso de uso empresarial.
Paso 3:identificar entidades y atributos
Una vez que se recopilan los requisitos comerciales, la información se puede utilizar para identificar entidades junto con el conjunto esencial de atributos. Por lo general, una o más entidades se asignan directamente a los procesos comerciales y la relación entre esas entidades también imita el flujo de trabajo del proceso comercial.
Este paso también se utiliza para identificar qué atributos actuarán como identificadores en las entidades. Los identificadores se traducen en claves primarias en el modelo físico. Además, también es común especificar tipos de datos para todos los atributos en este paso.
Por ejemplo, en el modelo de reserva de taxis, deberá identificar los atributos que actuarán como campos obligatorios para el registro de usuarios y conductores desde la aplicación de reservas. El registro de usuario se haría usando user_phone y el registro del conductor se haría usando driver_phone .
De manera similar, otras entidades y atributos se identifican durante este paso, luego de haber sido asignados a los flujos de trabajo del proceso comercial.
Paso 4:Identifique las relaciones
Después de identificar las entidades y sus atributos, el siguiente paso es definir las relaciones entre las entidades en función de los flujos de trabajo comerciales que se documentaron en la fase de recopilación de requisitos. Además de establecer que existe una relación entre dos entidades, también es importante identificar cuál de los siguientes cuatro tipos de relación existe entre ellas. Considere dos entidades arbitrarias, A y B:
- Uno a uno → Un registro en A corresponde como máximo a un registro en B.
- Uno a muchos → Un registro en A corresponde a muchos registros en B.
- Muchos a uno → Muchos registros en A corresponden como máximo a un registro en B.
- Muchos a muchos → Muchos registros en A corresponden a muchos registros en B.
En el modelo de reserva de taxis, solo se ha utilizado un tipo de relación, es decir, uno a muchos. Tomemos la relación entre users y trips como ejemplo. En el modelo, se supone que solo un usuario puede estar relacionado con un viaje, lo que implica que no hay taxis compartidos o compartidos. Pero si hubiera taxis compartidos o agrupados, posiblemente habría habido una relación de muchos a muchos entre users y trips , si muchos usuarios compartieron el mismo trip_id .
Paso 5:Cree un diagrama ER lógico
Con las entidades, los atributos y las relaciones entre entidades definidas, el próximo paso inmediato es dibujar el diagrama ER. Todos los pasos enumerados anteriormente se pueden realizar dentro de Vertabelo. No existen reglas estrictas y rápidas para la forma en que se supone que debe realizarse el modelado lógico, con la posible excepción de la notación de referencia.
Por ejemplo, eche un vistazo al siguiente ejemplo de un diagrama ER lógico. Captura un flujo de trabajo comercial simple de una empresa de taxis, donde un usuario puede reservar un viaje con la capacidad de rastrear el vehículo.
Paso 6:validar el diagrama ER lógico
El modelado lógico es un proceso en el que una gran cantidad de información comercial debe traducirse en un diseño de base de datos. Sin verificaciones exhaustivas, esta fase del desarrollo de la base de datos es propensa a errores que pueden resultar bastante costosos en una etapa posterior.
Para encargarse de esto, Vertabelo tiene una lista completa de comprobaciones que se pueden realizar en un modelo lógico. Las comprobaciones se pueden realizar en todas las granularidades, desde el modelo en su conjunto hasta los atributos individuales, y todo lo demás. Algunas de las comprobaciones simples son:
- Los nombres de entidades, atributos, relaciones, etc., no pueden ser nulos y deben ser únicos.
- Una entidad debe tener al menos 1 atributo.
- Los identificadores (PK) deben definirse para cada entidad.
- El modelo debe usar uno de los tipos de datos enumerados para los atributos.
Todas estas comprobaciones son opcionales y se pueden configurar para omitirlas, si existe otro marco de validación. La validación adecuada de Vertabelo lo ayuda a pasar al siguiente paso con la menor cantidad de fricción posible.
Paso 7:Cree un diagrama ER físico
Una vez que se crea el diagrama ER lógico, el siguiente paso es crear un modelo de datos físicos. El modelo de datos físicos será específico para la base de datos donde desea implementar el modelo de datos. Todas las bases de datos tienen su implementación única de reglas de nomenclatura, tipos de datos y restricciones. Debido a esto, el lenguaje de definición de datos (DDL) a menudo difiere de una base de datos a otra.
Para crear un modelo de datos físicos, siga estos pasos:
- Encuentre el tipo de datos más cercano en la base de datos de destino para reemplazar el tipo de datos genérico seleccionado en el modelo de datos lógicos.
- Siga las reglas de nomenclatura para tablas, columnas y restricciones según lo prescrito por la base de datos de destino.
- Modifique el modelo para alinearlo con los flujos de trabajo de consulta predefinidos. Esto generalmente da como resultado un aumento de la redundancia para guardar uniones.
- Por último, puede crear índices, particiones, claves de distribución y claves de clasificación. Aquí es cuando puede crear cualquier modificación del modelo que mejore el rendimiento.
Estos pasos se pueden realizar con cualquier herramienta de modelado de datos que pueda usar para crear un modelo de datos desde cero. Sin embargo, Vertabelo tiene la opción de convertir un modelo de datos lógicos en un modelo de datos físicos completo para todos los principales sistemas de bases de datos como MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery y más. Una vez que el modelo de datos lógicos se convierte en un modelo de datos físicos, puede continuar con los cuatro pasos que discutimos.
Vertabelo también tiene una opción para agregar secuencias de comandos previas y posteriores a la implementación en el nivel de la tabla junto con cualquier comentario en el nivel muy granular del modelo. Los comentarios resultan útiles cuando se utiliza la función de generación de documentación que ofrece Vertabelo. El documento de la base de datos se puede exportar en cualquiera de los siguientes tres formatos:HTML, PDF o DOCX.
Continuando con el ejemplo de reserva de taxis, echemos un vistazo al modelo de datos físicos generado por Vertabelo.
Paso 8:validar el diagrama ER físico
Al igual que se validó el diagrama de ER lógico, Vertabelo tiene una herramienta para validar los diagramas de ER físicos con varias comprobaciones adicionales, como si existen o no FK y si la longitud del nombre de una tabla o de una columna supera el límite según la base de datos seleccionada.
La validación no necesita ejecutarse explícitamente. Sucede a medida que se modifica el diagrama. Los problemas con el modelo se clasifican en una de tres categorías:errores, advertencias y sugerencias, en orden decreciente de gravedad. Hay un artículo útil y bien escrito que habla sobre los errores comunes que se cometen durante el proceso de diseño de la base de datos.
Paso 9:Solucionar problemas con el diagrama ER físico
Los resultados de la validación pueden identificar problemas que deben corregirse. Algunos de los problemas más comunes son:
- Faltan claves foráneas donde se han definido relaciones entre entidades.
- Faltan claves principales de las tablas.
- Tipos de datos no admitidos para la base de datos seleccionada.
Una vez que se resuelven estos y otros problemas similares, el modelo está listo para exportarse a un script SQL implementable para el sistema de administración de base de datos seleccionado.
Paso 10:Genere los scripts DDL para implementar el modelo
El diseño de bases de datos no se trata solo de crear diagramas ER. Un ejercicio de modelado de datos que utiliza diagramas ER tiene éxito solo si da como resultado algo que se pueda implementar. Vertabelo tiene una opción conveniente para exportar el modelo físico a un script SQL listo para implementar. Una vez que se genera, cualquier problema pendiente se puede resolver directamente en el script SQL.
Sin embargo, no se recomienda cambiar el script SQL generado. Provoca una desviación entre el modelo de datos físicos y el script SQL implementado en la base de datos, lo que también puede significar una desviación entre las tablas reales y la documentación de la base de datos.
Ahora que hemos llegado al final del proceso de diseño de la base de datos, echemos un vistazo al código SQL generado por Vertabelo.
Comparte tus pensamientos
El diseño de bases de datos es una actividad de alto impacto en el desarrollo de software. El campo del diseño de bases de datos ha evolucionado a lo largo de los años con nuevas formas de representar el diseño para la empresa, los ingenieros y los analistas de datos. Esto a menudo ha resultado en nuevos tipos de diagramas, estándares de modelado y notaciones. Gran parte de la evolución se ha cubierto en la sección de fundamentos de diseño.
Estaremos encantados de ver cuáles han sido sus experiencias en el diseño de bases de datos. Escríbenos a [email protected].
