Diseño De Una Base de Datos: respondiendo a una pregunta.
Os traigo otra perla, esta vez de Shordi, del foro de gambas-es.org.
Se trata de explicar como se debería diseñar una base de datos.
Para iniciar el diseño, no debes pensar en maneras de entrar los datos o en la cualidad de cada campo. Eso vendrá después.
Para diseñar una base de datos, escribir un programa, hacer un guiso o escribir una novela nuestro cerebro funciona de la misma manera.
Un cocinero no empieza pensando qué ingredientes se echan con los dedos y cuales con la cuchara. Empieza con identificar los ingredientes.
Un Escritor no empieza pensando qué corbatas llevarán los personajes y de qué color. Empieza identificando los personajes que van a intervenir.
Una base de datos no se empieza pensando qué pantallas vas a rellenar o qué dato será obligatorio: Se empieza identificando las "Entidades" (Clases) que intervienen en ella.
Los Tipos de Entrada, los modos y formatos de salida, la cualidad de sus relaciones, etc. etc. eso vendrá después.
En otras palabras olvídate, de momento, de nada que no sea las propiedades de las Clases. Yo prefiero la palabra "Entidad" que implica que de lo que hablo tiene "existencia" por sí misma, dejando eso de "Clases" para la POO a la hora de diseñar el programa. Como norma general puedes identificar "Entidad" con "Tabla Maestra" (hay entidades complejas, pero eso es otra historia)
Por lo que cuentas en tu diseño hablas de manejar: Libros, Autores, Editoriales, Citas, Tesis.
Empieza por eso: Pregúntate Qué es y de Qué se compone un Libro, un Autor, una Cita, etc.
Eso te dará los campos y su tipo de una forma natural.
Es evidente que
-Un libro tiene: Título, Autor, editorial, Nº de páginas, etc.
-Un Autor tiene: Un nombre, una fecha de nacimiento, un país de nacimiento, una biografía, una bibliografía, etc. etc.
-Una Cita tiene: Un texto, un libro de referencia, una página donde aparece, un libro, o varios, donde es citada, etc. etc.
En el desarrollo de esto verás que el tipo de dato lo marca la naturaleza del mismo y empezarán a surgir las relaciones entre ellos. Por ejemplo el número de página donde aparece la cita no puede ser mayor que el número de páginas del libro, etc. También te encontrarás que, a lo mejor, te aparecen entidades en las que, de entrada, no habías pensado. Por ejemplo, una Tesis tiene un Autor, no confundir con el autor de los libros que se citan ¿Será necesario también una tabla de autores de Tesis? ¿Qué características tendría?, etc. etc.
Una vez que tengas diseñadas las características (campos) de tus "Entidades" (tablas maestras), tendrás que relacionarlas entre sí (esta es la esencia de las Bases de Datos Relacionales), de forma que se constituyan en una estructura de datos coherentes y eficaz. Para ello necesitas encontrar primero de todo la Clave Primaria de cada Entidad, es decir qué identifica cada fila de una forma única y definitiva entre todas las de su clase y construir los índices que apunten a esas claves.
Así una editorial tiene un Id del registro mercantil, Un libro un ISBN, etc. Esto es básico: Dos libros pueden tener el mismo título, dos Autores el mismo nombre, etc.
Puedes construir tus claves mediante la unión de varios campos, Título+Autor o puedes crear campos que sirvan de índice (autonuméricos) para ello.
Con los indices construidos estableceremos las relaciones entre las tablas. Así , en la tabla de libro, campo editorial, almacenaremos la clave de la tabla editoriales, para lo que crearemos una relación Padre-Hijo (Foreign key) y la base de datos misma se encargará de mantener la coherencia y de que no haya claves perdidas o referencias ciegas.
En este paso verás que no es posible, muchas veces, establecer una relación directa y sencilla, por ejemplo:
Un autor ha escrito varios libros. Un libro puede tener varios co-autores. La solución más sencilla entonces es la creación de una tabla de enlace intermedia. Una tabla que se componga exclusivamente de tres campos: índice de la relación, clave el autor, clave del libro.
Finalmente, una vez que tengas la estructura creada, es conveniente hacer una serie de vistas que simplifiquen las consultas más frecuentes que luego usaremos en el programa.
Por ejemplo: una vista que contenga todos los campos del libro y todos los de su autor (recordemos que en la tabla de libros sólo tenemos la clave de la tabla del autor).
Almacenando estas vista, seremos capaces de mostrar al usuario los datos que necesite de manera muy sencilla.
Hay mucho más, claro, pero más o menos estos son los pasos básicos para el diseño de una base de datos.
Todo el tiempo que dediques a esto, será tiempo ganado en la programación. Un error de programación se arregla, a las malas, en unas horas. Un error en el diseño de la base de datos puede costarte meses o, incluso, hacer inútil todo tu proyecto. (Créeme, me ha pasado)
El diseño de tu base de datos es la esencia de tu programa.
Mi cita favorita:
"Enséñame tu código y mantén ocultas tus estructuras de datos, y me seguirás engañando. Muéstrame tus estructuras de datos y normalmente no necesitaré que me enseñes tu código: resultará evidente." (Fred Books.)
Fuente:
http://www.gambas-es.org/viewtopic.php?f=3&t=4419