Consulta Sobre Diseño De La DB


Objetivo: Consulta Sobre Diseño De La DB
Hola a tod@s

Estoy haciendo una aplicación que maneja referencias bibliográficas y dada una peculiaridad al momento de hacer consultas a la DB, no estoy seguro de cuál sea el mejor modelo de diseño, de ahí mi pedido de ayuda; primero hago una breve explicación y luego las peculiaridades de las consultas.

El sistema tiene 26 tipos de entradas (en adelante TE), en la carga de datos de cada TE existen dos áreas de datos: a) que son obligatorios y b) que son opcionales, hay un número de datos que existen por igual en los 26 TE, por ejemplo autor y año, pero son más.

Pongo 2 ejemplos:

TE = Libro
datos obligatorios: author, title, year/date
datos opcionales: editor, editora, editorb, editorc, translator, annotator, commentator, introduction, foreword, afterword, subtitle, titleaddon, maintitle, mainsubtitle, maintitleaddon, language, origlanguage, volume, part, edition, volumes, series, number, note, publisher, location, isbn, chapter, pages, pagetotal, addendum, pubstate, doi, eprint, eprintclass, eprinttype, url, urldate

TE = Tesis
datos obligatorios: author, title, thesistype, institution, year/date
datos opcionales: subtitle, titleaddon, language, note, location, month, isbn, chapter, pages, pagetotal, addendum, pubstate, doi, eprint, eprintclass, eprinttype, url, urldate

Hasta acá el modelo de DB parece llevarme a diseñar una tabla por cada TE, pero el problema surge cuando se realizan búsquedas durante una nueva alta en la DB --por ejemplo de un libro-- me puedo encontrar con un autor que existe en otras TE (por ejemplo conferencias, artículos, online, etc., pero no en un libro) y la idea es no escribir nuevamente el nombre del autor, sino tomar los datos que ya existen (a: para no terminar teniendo en la DB casos como: Pablo Pozzi, y P. Pozzi y b: para no repetir, es decir que el autor este una sola vez para todas las TE), y además para el caso de otros datos --por ejemplo journal y publisher-- tomar sus datos asociados, en estos 2 datos un dato asociado (por que es exclusivo) es location.

El motor sobre el que estoy trabajando es MySQL, que corre en el servidor de un proveedor de internet (yo accedo desde una dirección IP), las ABM se van a hacer desde PCs que están en diferentes lugares y con diferentes horarios de trabajo, en algún momento pueden llegar a existir 100.000 TE.

Cualquier sugerencia es agradecida.

Objetivo: Re: Consulta Sobre Diseño De La DB
Citar:
- me puedo encontrar con un autor que existe en otras TE (por ejemplo conferencias, artículos, online, etc., pero no en un libro) y la idea es no escribir nuevamente el nombre del autor, sino tomar los datos que ya existen

Yo lo que haría seria crear una tabla de Autores, y que las otras tablas usen esa tabla para leer los datos del autor mediante un indice.

Para añadir a un TE el autor, lo que añadiria el el IdAutor, y usaria un combobox, o listbox, para elegir el autor.

tabla

Seguro que Shordi, te puede orientar mejor.

Objetivo: Re: Consulta Sobre Diseño De La DB
Citar:
El sistema tiene 26 tipos de entradas (en adelante TE), en la carga de datos de cada TE existen dos áreas de datos: a) que son obligatorios y b) que son opcionales, hay un número de datos que existen por igual en los 26 TE, por ejemplo autor y año, pero son más.


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.)

Como siempre, no sé si ayudo o confundo.

Perdón por el ladrillo

última edición por shordi el Domingo, 01 Marzo 2015, 12:14; editado 2 veces
Perfil MP  
Objetivo: Re: Consulta Sobre Diseño De La DB
Shrodi:

Muy buena explicación. +1

(si me das permiso, lo copio y pego en mi blog )

Cuando uno empieza a programar, siempre tiene en la cabeza como lo verá el usuario, y parece que eso es lo más importante y tenemos la tendencia de programar asi.

Luego te das cuenta, que no puedes programar de esa manera, que tienes que empezar desde abajo, desde los cimientos. En tu comentario lo has explicado muy bien.

Saludos

Julio

Objetivo: Re: Consulta Sobre Diseño De La DB
Gracias Julio. Permiso tienes, por supuesto.

Perfil MP  
Objetivo: Re: Consulta Sobre Diseño De La DB
Shordi, gracias por las sugerencias, voy a trabajar en la linea de tu planteo, ya que el tratamiento de las referencias bibliográficas con Biber (el motor de DB) + Biblatex [1] en la producción de textos académicos es mucho más complejo de lo que expuse, y tiene bastante de la lógica que expusiste.

Estoy haciendo algunos diagramas en lápiz y papel (a la vieja usanza) para sacar luz, espero en unos días tener la cosa más clara y pedir ayuda con otro panorama.

Pido disculpas, si en algún momento mis preguntas llegasen a parecer «increíbles de preguntar», pero a pesar de programar en LaTeX desde hace tantos años, son mis primeros pininos en gambas (que me parece genial).

Lo que me a motivado a querer desarrollar un software específico para producción, es porque los que existen [2], se han salido de la filosofía de Unix, que es: a) programas puntuales para soluciones concretas y b) no repetirse.


[1] http://biblatex-biber.sourceforge.net/
[2] http://jabref.sourceforge.net, https://www.zotero.org, http://www.mendeley.com, http://www.citeulike.org, https://www.myendnoteweb.com/EndNoteWeb.html?

Saludos


Página 1 de 1


  
No puede crear mensajes
No puede responder temas
No puede editar sus mensajes
No puede borrar sus mensajes
No puede votar en encuestas
No puede adjuntar archivos
Puede descargar archivos
No puede publicar eventos en el calendario

   

Está utilizando la versión (Lo-Fi). Para ver la versión completa del foro, haga clic aquí.

Powered by Icy Phoenix based on phpBB
Design by DiDiDaDo

Página generada en:: 0.2345s (PHP: -64% SQL: 164%)
Consultas SQL: 45 - Debug off - GZIP Activado