Cómo diseñar una base de datos

Answer 1

Ya no dibujo modelos de bases de datos en papel. Abandoné esto hace unos 3 años cuando conseguí un nuevo trabajo y comencé a trabajar con SAS PowerDesigner. Esta es una aplicación de escritorio que le permite dibujar sus modelos y visualizar la estructura de su base de datos. Pero es extremadamente caro: los precios varían de $ 3,300 a $ 29,250, dependiendo de la versión. Por lo tanto, en la práctica, es una herramienta principalmente para corporaciones prósperas que pueden permitirse comprarlo.
Ahora estoy trabajando como profesional independiente y como no podía permitirme comprar PowerDesigner, tuve que encontrar otra solución o volver a dibujar modelos en papel y codificarlos, lo que quería evitar porque es una pérdida de tiempo.
Al principio encontré Sea Quail, que me impresionó porque funciona en línea en el navegador (Sea Quail Database Diagram Tool). Pero con el tiempo resultó ser demasiado simple e insuficiente para mis necesidades. Así que investigué un poco en la web y encontré Vertabelo (Vertabelo – Diseñe su base de datos en línea) que también funciona en línea, pero a diferencia de Sea Quail, es una herramienta realmente poderosa para el diseño de bases de datos y ofrece casi todo lo que PowerDesigner tiene, en cuanto a la creación de bases de datos. modelos se refiere. Paradójicamente, la gran ventaja de Vertabelo sobre PowerDesigner es que Vertabelo es más simple. PowerDesigner está dramáticamente sobrecargado con cientos de características, la mayoría de las cuales utilicé muy raramente o no utilicé en absoluto. Vertabelo ofrece muchas menos funciones, pero sigue siendo muy poderoso. Tiene todo lo que el arquitecto o desarrollador de información necesita para diseñar sus bases de datos. Puedo decir honestamente que esta es una aplicación moderna para el siglo XXI. Está disponible en línea, es muy simple e intuitivo, y al mismo tiempo es potente y está destinado a profesionales.
Lo más importante es que Vertabelo es completamente gratuito cuando se usa dentro de ciertos límites. Y si excede el límite, el precio es muy asequible.
Como estoy desarrollando aplicaciones en PHP, uso Vertabelo para crear o rediseñar mis modelos de base de datos, luego exporto el modelo al formato XML de Vertabelo y finalmente convierto este archivo en el esquema schema.xml de Propel. Vertabelo ofrece un script PHP especial que convierte sus archivos XML a XML destinados a Propel ORM.
Como puede ver, prácticamente no tengo que dibujar ni codificar nada a mano. En Vertabelo veo toda la estructura de mi base de datos: todas las tablas y relaciones entre ellas, y puedo hacer cambios en ese modelo utilizando herramientas gráficas (ya que también manejo algunos gráficos de computadora, trabajar en un modelo de base de datos en Vertabelo me recuerda trabajar en gráficos vectoriales en Adobe Illustrator). Al final, convierto mi modelo automáticamente para utilizarlo con Propel ORM.

Answer 2

El primer paso para diseñar una base de datos es comprender cuál será el resultado deseado. Qué informes, consultas, impresiones, formularios se requerirán.
Luego debe comprender cómo se relacionan entre sí los diferentes elementos de datos de estas salidas.
Luego debe comprender la estructura de los datos. Qué elementos dependen de otros, qué piezas son únicas y qué piezas están relacionadas o dependen de otros.
Entonces debe averiguar de dónde vendrán estos datos. ¿Es todo nuevo? ¿Ya hay alguno en otro lugar? ¿Los usuarios necesitan ingresar?
Luego puede ver la definición de “registros” o tuplas de datos, definiendo qué campos se utilizarán para acceder al registro. (Definición de índices)
Luego debe definir el tamaño preferido de cada elemento de datos. Cuántos caracteres para el texto, cuántos dígitos, datos lógicos, datos brutos o no estructurados.

Ahora tiene la información necesaria para definir la base de datos. Cree una base de datos inicial y llénela con datos de prueba para que pueda definir las entradas y salidas (es posible que necesite búsquedas, verificaciones de integridad de datos, elementos de datos requeridos y elementos de datos opcionales).

Pruebe su base de datos para ver si cumple con los requisitos especificados en los primeros pasos. Luego arregle lo que no funciona como se esperaba.

Answer 3

Este es uno de los problemas más complejos en la programación actual.

La mayoría de los diseñadores nunca aprenden a hacer esto bien.

Teóricamente, simplemente coloca los datos en tablas y luego realiza la normalización.

Esto, sin embargo, ni siquiera comienza a describir el problema.

En primer lugar, debe saber qué datos necesitará almacenar y recuperar. Al comienzo del proyecto (cuando está diseñando el esquema de la base de datos al principio) generalmente no conoce lo suficiente sobre los requisitos de datos para poder especificar todos los elementos de datos de la manera correcta.

En segundo lugar, debe seleccionar el nivel correcto de normalización. Pasar a la tercera forma normal puede complicar la programación, a veces en un grado que no es conveniente. Parar en la segunda forma normal a veces puede resultar en redundancia y duplicación de datos, con otras complicaciones en el futuro.

Entonces, en la práctica, lo que a menudo tiene que hacer es hacer un diseño de esquema de primera puñalada, utilizando el mejor conocimiento de los requisitos de datos que tiene en ese momento, y muy a menudo solo pasa a la segunda forma normal, porque probablemente va a ir tener que revisarlo de todos modos.

Luego, a medida que el proyecto avanza y su comprensión del requisito de datos mejora, usted rediseña iterativamente el esquema una y otra vez, tomando algunas tablas a la tercera forma normal a medida que ve el requisito para esto, tal vez dejando otras en el segundo lugar o en algún lugar intermedio porque eso funciona para ser el mejor compromiso, y todo el tiempo mejorar la coincidencia entre el diseño del esquema y el problema del mundo real hasta que tenga una solución que sea razonablemente cercana a la óptima.

Una cuestión importante es no apegarse emocionalmente a ninguna parte del diseño del esquema en ningún momento. Incluso las ideas más lindas pueden probar que no son óptimas, y debe estar preparado para abandonarlas para obtener una mejor solución en cualquier momento. Este es uno de los aspectos más difíciles del diseño de esquemas, y uno de los fallos más comunes con la mayoría de los diseñadores.

Muy pocos diseñadores hacen esto bien. La mayoría de los esquemas de bases de datos son horriblemente malos.

Answer 4

Un buen diseño de base de datos comienza con una lista de los datos que desea incluir en su base de datos y lo que desea poder hacer con la base de datos más adelante. Todo esto se puede escribir en su propio idioma, sin ningún SQL. En esta etapa, debe intentar no pensar en tablas o columnas, sino simplemente pensar: “¿Qué necesito saber?” No tome esto demasiado a la ligera, porque si descubre más tarde que olvidó algo, por lo general, debe comenzar de nuevo. Agregar cosas a su base de datos es principalmente mucho trabajo.

Existen muchas herramientas en línea que pueden ayudarlo:

SQLDbm

SqlDBM inicialmente comenzó con soporte incorporado para el servidor SQL de Microsoft solamente.

Pero, por supuesto, debido a la gran cantidad de solicitudes de soporte de MySQL de nuestros usuarios, hemos estado trabajando duro para expandir nuestro producto.

Y ahora, estamos muy orgullosos de anunciar que SqlDBM ofrece soporte para MySQL , una de las bases de datos de código abierto más populares del mundo.

Ahora puede modelar y diseñar su / s base de datos MySQL directamente en SqlDBM. Y, por supuesto, puede aprovechar y adaptar las funciones de SqlDBM en su base de datos MySQL, como áreas temáticas, relaciones, diagramas, modos de visualización, etc.

• Precio: gratis
• Ingeniería avanzada: use SQLDBM para crear un modelo físico o ERD de su base de datos
• Ingeniería inversa: use la función de ingeniería inversa para exportar su esquema de base de datos como un script SQL

caracteristicas:

• Cree objetos de bases de datos como tablas, objetos, relaciones, índices, de forma rápida e intuitiva.
• Modifique y edite objetos de base de datos en línea en su diagrama
• Copiar o mover columnas a través de tablas
• Acercar y alejar diagramas
• Diseño sobre el terreno en cualquier lugar en cualquier navegador [1]

DbDesigner.net

• Precios: versión básica gratuita; versión de pago a partir de $ 50 / año
• Productos de base de datos compatibles: modele y genere SQL para MySQL, SQLite, SQL Server, PostgreSQL, Oracle
• Navegadores compatibles: no especificado
• Ingeniería inversa: Importar SQL desde MySQL (característica descrita como “experimental”)

Vertabelo

• Precios: versión básica gratuita; versión académica gratuita; versión avanzada disponible para una suscripción mensual a partir de $ 9 / mes o por uso a partir de aproximadamente $ 1 / día; instalación interna a partir de $ 1399 por una tarifa de licencia única
• Productos de base de datos compatibles: modele y genere SQL para PostgreSQL 9.x, Oracle Database 11g, MySQL 5.5, SQLite 3.7.x, DB2 9.7, SQL Server 2012, HSQLDB 2.3; también exportar modelo como XML
• Navegadores compatibles: Chrome, Safari (beta)
• Ingeniería inversa: herramienta gratuita disponible; También puede importar directamente desde un archivo SQL o XML

GenMyModel

• Precios: versión básica gratuita; versión más avanzada a partir de $ 4 / mes; versión profesional que incluye todas las funciones desde $ 19.20 / mes para usuarios de uno a cinco
• Productos DB admitidos: modelado neutral del producto; generador genérico de SQL que requiere personalización; generador de SQL de muestra para PostgreSQL; exportar como intercambio de metadatos XML (XMI)
• Navegadores compatibles: Internet Explorer, Chrome, Firefox, Safari, Opera
• Ingeniería inversa: parece no haber forma de importar SQL, pero puede importar modelos de Visio 2013 [2]

También debe seguir estas reglas que he encontrado en CodeProject:

1. ¿Cuál es la naturaleza de la aplicación (OLTP u OLAP)?
2. Divide tus datos en piezas lógicas, simplifica la vida
3. No se sobredosifique con la regla 2
4. Trate los datos no uniformes duplicados como su mayor enemigo
5. Esté atento a los datos separados por separadores
6. Esté atento a dependencias parciales
7. Elija columnas derivadas preciosamente
8. No sea difícil evitar la redundancia, si el rendimiento es la clave
9. Los datos multidimensionales son una bestia completamente diferente
10. Centralizar el diseño de la tabla de valores de nombre
11. Para datos de referencia jerárquica ilimitados PK y FK [3]

Notas al pie

[1] SqlDbm – Modelador de bases de datos SQL

[2] Cinco servicios de modelado de bases de datos en línea: conversación simple

[3] 11 reglas importantes de diseño de bases de datos que sigo

Answer 5

Últimamente estoy usando mucho ORM elocuente en Laravel 4, así que antes de comenzar a crear cualquier tabla de base de datos, esbozo los Modelos (objetos) que contendrán mis datos, definiendo propiedades y métodos que se utilizarán en la aplicación.
Por lo general, empiezo con una hoja de papel grande y escribo “datos reales”, para poder concentrarme en lo que trabajaré, en lugar de hacer un resumen. Dibujar las relaciones entre todos estos espacios de datos me dará el mapa de las relaciones entre los Modelos, que luego se convertirán en tablas DB.
A veces, varios campos en un DB pueden reemplazarse por uno único que contenga una matriz json_encoded, por ejemplo, como contenedor de “configuración de usuario”, por lo que prefiero hacer todo el trabajo de diseño de antemano para evitar demasiadas reescrituras de estructuras de db, un método Modelo puede tenga cuidado de codificar / decodificar los datos.
Una vez hecho esto, escribo las migraciones de DB, ejecútelas y escriba los métodos en los Modelos (prefiero tener modelos gordos y controladores ajustados). El toque final viene con las pruebas de la Unidad, por lo que si modifico algo en la estructura de DB, sabré de inmediato si rompo algo.

Campo de golf:
Documentación ORM elocuente: http://laravel.com/docs/eloquent
Migraciones: http://laravel.com/docs/migrations

Answer 6

Realmente estoy de acuerdo con usar papel como lo primero. En segundo lugar, comprenda la naturaleza del negocio, su proceso. Qué valor agregado aporta la empresa a la comunidad o las razones por las que necesitan mantener el software DBMS.

Ponga su flujo de proceso en papel para que el arquitecto de datos tenga una buena idea de lo que realmente está sucediendo. Clasifique / identifique datos maestros y datos transaccionales, con ese proceso sabrá qué es la entidad clave y sus atributos que realmente los hacen importantes para el negocio.

Si hay múltiples fuentes o dominios, prepare una imagen de alto nivel y sus puntos de integración, y reduzca cada dominio o área temática. Puedo agregarle más como un enfoque paso a paso. Aquí puede ser abrumador …

Gracias,

VK

Answer 7

Bueno, es iterativo y mucho depende de si es probable que bajemos por un enfoque relacional o uno de los no relacionales.

Realmente se trata de descubrir cuáles son las reglas de negocio y luego diseñarlas en torno a ellas. Si la base de datos no refleja las reglas comerciales, probablemente tendrá problemas con el tiempo.

Inevitablemente, la base de datos tiene un propósito que impulsa las respuestas a muchas preguntas.

Digamos que íbamos a construir una base de datos que modele la huella de una persona dentro de la empresa. Identifico contra lo que voy a almacenar y consultar. Me gustaría ver qué tiene una relación automática uno a uno y luego cuestiono esas suposiciones.

En mi base de datos, podría pensar por adelantado que una persona solo tiene una dirección a la vez. Solo viven en un lugar, ¿verdad? Luego determino qué desafía esa suposición.

Una persona puede tener muchas direcciones al mismo tiempo. Pueden tener múltiples residencias si son ricos, pueden tener una dirección de correo diferente a su hogar en muchas circunstancias, etc. Pueden tener múltiplos durante un movimiento. También es posible que necesitemos incluir su dirección de trabajo si tenemos varias oficinas y dependiendo del propósito de conducción de nuestra base de datos.

La persona tiene un matrimonio, tal vez. Quizás más de uno. Quizás ninguno. Tal vez nos importa, tal vez no.

Puedo decidir que obtenga un número de teléfono celular y si cambia ese número, reemplazaremos el número de teléfono actual. O puedo decidir que necesito mantener sus viejos números de celular. Si mis reglas comerciales incluyen detalles sobre su teléfono celular, es posible que necesite saber qué números tenía para qué meses y años.

Ese es un ejemplo sobre hacer suposiciones a partir de las reglas comerciales. Si esto estuviera asociado con algo en el que rastreamos el uso del teléfono celular de una persona, nos importaría. Como una compañía de teléfonos celulares o una compañía que emite teléfonos celulares a los miembros de su personal.

Si voy por un camino relacional, me normalizo en torno a todo lo anterior. Por lo general, en mi cabeza, luego en papel o pizarra o con una aplicación. Dependiendo de los deseos de mi cliente o la necesidad de documentación.

Si va a ser un documento db, considero cómo se verá el documento JSON y cómo se verán las colecciones. Y sobre qué indexaremos. Posiblemente intente descubrir una clave de fragmentación sensible.

Si va a ser una familia de columnas, voy a averiguar las consultas y qué elementos deben exponerse al motor de consultas. En este punto, tengo que determinar qué tan lleno se basará un registro en diferentes claves de partición e intentar equilibrar demasiado lleno con demasiado vacío. Intento combinar las consultas en grupos y ver si puedo hacer que usen las mismas tablas.

Si va a ser una base de datos gráfica, considero las relaciones como mi controlador principal.

Si va a ser un almacén de valores clave, se tratará principalmente del contenido del valor y de cuál será la clave.

Una ronda de diseño nos da una versión abstracta de la base de datos, y ese suele ser un paso bastante importante.

Muchas pruebas contra los supuestos. Tratando de pensar en formas de romper el diseño. Muchos de ellos provienen de la experiencia personal. por ejemplo, conozco personas que tienen varios teléfonos celulares al mismo tiempo.

En todos los casos, las consultas conocidas serán los principales impulsores del éxito. Si se trata de una pequeña base de datos para una tienda de un pequeño cliente y no tiene millones de registros, puedo tomar todo tipo de libertades con los datos y no preocuparme. Cuanto más grande sea esto, más tendré que pensar sobre lo que causará un problema para el sistema en términos de actividades.

Si no conocemos las consultas, tenemos que hacer conjeturas y planear refactorizar más tarde.

Esa es la versión corta.

Answer 8

En esquema simple es para tablas no para base de datos. La base de datos es solo la colección de tablas. Crear esquema de tabla depende de las entidades de una tabla. Por ejemplo, si está creando una tabla de una tabla de maestro, las entidades serán. La identificación del maestro, el nombre, el nombre del padre, el género, la calificación, el año de incorporación son los componentes principales que puede agregar más, dependiendo de qué tipo de información le gustaría guardar en la columna diferente de una tabla.

Answer 9

Vea la respuesta de Toby Thain a ¿Cuál es la mejor manera de estructurar una base de datos para preguntas y respuestas?