Como pensar la estructura de una base de datos?

[enridp]

Hola a todos!
He diseñado muchas veces bases de datos, pero la verdad es que como siempre fueron proyectos muy chicos, con muy pocas tablas y campos, nunca debí "pensar" demasiado en lo que se refiere a performance o buenos hábitos a la hora de diseñar la estructura de una BD.

Por ese este tema. Alguien podría recomendarme un buen tutorial o libro al respecto.
Tal vez estoy equivocado pero, por ejemplo, al programar en un lenguaje Orientado a Objetos es MUY util saber como pensar las cosas, por ejemplo hacerse preguntas sencillas como:
"Es un? o contiene un?"
Uno puede deducir si necesita usar herencia o inclusión, etc.
Existe algo similar en el diseño de base datos?
Es decir algunas preguntas que uno debería hacerse a la hora de crear una nueva tabla, como para poder deducir si es necesario realmente una nueva tabla, o si es necesario agregar algun campo nuevo en otra tabla, o si algun campo en realidad no deberia pertenecer a cierta tabla, etc.

Creo que me serviría de mucha ayuda alguna especie "de guía" para poder decidir con más seguridad la estructura de mi BD porque la verdad siempre la armé a "puro criterio".

Saludos !!
Enrique.

[enridp]

Bueno despues de leer un poco algunos tutoriales creo que pueden pensarse las tablas en forma similar a los objetos.
La idea es tratar de que nuestras tablas encapsulen informacion de UN solo objeto. (Normalizar las tablas segun la jerga).
No hacer tablas enormes donde hay una ensalada de datos. Es siempre mejor tener mas tablas y de ultima relacionarlas (agregar un campo IDdeOtraTabla).
Una forma facil de darse cuenta que se esta pensando mal la tabla es si necesitamos muchos campos que llevan informacion similar y que para colmo no siempre se usan.
Por ejemplo las canciones de un Album. No es bueno hacer una tabla Album que ademas del nombre del album año, etc guarde guarde tambien las canciones. En este caso Canciones tiene que ser otra tabla, y estara relacionada con Album.


Asique creo que unas de las preguntas que podemos hacernos es:
Este campo que quiero agregar, no podria ser una tabla?
Este campo que deseo agregar realmente pertenece a esta tabla? o se podria armar otra donde ese campo (y otros) encajen mejor?

Si es medio pobre pero bueno, ojalá algun experimentado nos deja un mejor consejo...

[TheFace]

hola, yo estoy en la misma situación que tú, solo que mi experiencia en bases de datos es un poco deficiente.
He creado varias bases de datos, tanto en SQL como en ACCESS,
He leído estos días sobre bases de datos, como crearlas, plantearlas, y todos coinciden sobre la gran importancia de ahorrar espacio por medio de dividir los datos en tablas en vez de mantener una ensalada de datos que lo único que provoca es espacio innecesario.
Mi problema es que he dividido la antigua ensalada de datos en varias tablas, pero llevo muy mal lo de las relaciones puesto que hay datos que no se como relacionarlos, y luego está el tema de que si relacionas unas con otras, hay otras tablas que no pueden estar o no tienen que estar relacionadas con las anteriores, lo que me obliga a crear otras tablas solo para relacionar las anteriores...vamos.. que estoy hecho un lío y si alguien explica aquí como se puede hacer todo ésto... pues nos haría un gran favor.

Un saludo.

[enridp]

Hola TheFace, para relacionarlas lo único que tienes que hacer es agregar un campo "tablaExternaID" en la tabla que hace referencia a otra tabla.
En ese campo almacenas el ID (la llave primaria) de la tabla a la que queres apuntar.

Por lo general yo diseño asi mis tablas. Creando en todas un campo ID como llave primaria, y luego poniendole INDICES (si va a ser una tabla muy buscada) a los campos que realmente son representativos de esa tabla (porque el ID no significa nada por lo general para nosotros es solo util para el motor de la BD), y dan pie para ser indices es (decir no se repite demasiado el mismo valor, etc.)

Cuando en tus tablas las relaciones (o sea tablas que tienen campos que apuntan a otras) se vuelven muy importantes, se recomienda usar "llaves foráneas" (foreign keys, FK), si el motor de BD lo soporta (por ej. en MySQL lo soporta InnoDB pero no MyISAM, aunque creo que en la prox version si ya lo va a soportar).
Una FK lo que hace primordialmente es evitar que hagas lios y se rompan las relaciones. Porque si por ejemplo borras un ID de una tabla, y habia otra tabla que apuntaba a ese ID, esa tabla te queda apuntando a NADA. Asique las FK no te permiten por ej. borrar un ID si esta siendo apuntado por otra tabla, etc.

A lo mejor si pones tu problema en concreto se puede ver mejor como solucionarlo.
Incluso tal vez esa seria una buena forma de "aprender" a diseñar bases de datos, CON EJEMPLOS (un problema, una solucion erronea, y una solucion correcta).

[TheFace]

Hola Enridp...

Mira, te explico un poco por encima lo que tengo y quiero hacer, intentaré desarrollarlo lo máximo posible y que se entienda, espero que no se haga muy pesado el tocho...

En principio tengo las siguientes tablas:

Tabla EXPEDIENTES
Con un IDExpedientes (Clave principal autonumérica)

Tabla VEHICULOS
Con IDVehículo (Clave principal autonumérica)

Tabla PERSONAS
Con IDPersona (Clave principal autonumérica)

Tabla NOVEDADES
Con IDNovedad (Clave principal autonumérica)

1º Lo que pretendo es crear un formulario que cuando consulte un expediente me salga en el mismo los datos del expediente y además, los vehículos y personas que tiene relacionados con el mismo, así como si ha habido alguna novedad (accidente con el vehículo o lo que sea que queramos hacer constar).

2º De igual forma desearía que cuando consulte un vehículo, me salga la persona que tiene relacionada (puede ser conductor, titular, pasajero o cualquier relación con dicho vehículo) y además, si tiene alguna novedad y el expediente que tiene asignado.

3º Y de igual forma con las personas, si consulto una persona que me salga todo lo relacionado con la misma que haya en la base de datos.

4º Si consulto las novedades, pues que me salga todo lo relacionado con lo sucedido y los vehículos y personas que han intervenido en dicha novedad.

Y para complicar más la cosa, solo añadir que un vehículo puede tener varias personas relacionadas, una persona puede estar relacionada con varios vehículos, un expediente puede tener varios vehículos y varias personas y una novedad igual.

Complicado... ¿no?

Añadir que las bases de datos las estoy creando con Visual Studio 2008, (Visual Basic), y las relaciones las voy a crear en el dataset con el mismo diseñador, aunque esto es lo de menos, porque me imagino que para crear la base de datos da igual el medio que utilice, lo importante es crearla de alguna forma, yo más o menos controlo los métodos para crearla, lo que me falta es llevar a cabo el trabajo y quitarme el bloqueo mental que tengo.

En principio creo que tengo que crear más tablas, he hecho varias pruebas, he añadido varias claves a otras tablas, pero al final lo he desecho todo porque no avanzo y la tengo en la situación que te he planteado.

Se que es un poco lío, pero si alguien me puede ir diciendo como ir confeccionando todo el tocho este para que funcione se lo agradecería enormemente.

Un saludo.

[plantala]

Lo primero que tienes que hacer es un diagrama entidad/relacion para poder aclararte bien, aqui te dejo un dibujo por si te suena de algo como son:
http://www.google.es/imgres?imgurl=h...ed=0CBsQ9QEwAQ

Y lo segundo que tienes que hacer, es el modelo relacional. Con eso, podras crear las tablas perfectamente.
La verdad que ayuda muchisimo a la hora de crear la base de datos.

Eso si, hay que hacerlo bien, sino a la hora de hacer las tablas, podras tener problemas con las relaciones entre tablas y tal...

Busca por internet aber si encuentras informacion sobre como hacerlo.
Suerte!

[enridp]

Bueno yo creo que lo que deberias hacer (no se si lo hiciste ya pero en lo que me pusiste abajo no figura), es RELACIONAR las tablas.
Es muy sencillo solo tienes que agregar un nuevo campo en las tablas de abajo.
Por ejemplo:

1º Lo que pretendo es crear un formulario que cuando consulte un expediente me salga en el mismo los datos del expediente y además, los vehículos y personas que tiene relacionados con el mismo, así como si ha habido alguna novedad (accidente con el vehículo o lo que sea que queramos hacer constar).

Para hacer eso primero tendrias que aclarar COMO es la relacion.
Es decir, un vehiculo puede tener mas de un expediente? un MISMO expediente puede estar vinculado a mas de un vehiculo? un vehiculo puede tener asociada mas de una persona? (por lo que vi abajo parece que si pero parecen ser de distinto tipo las personas, es decir, dueño, conductor, pasajero, etc. asique creo que mas que una tabla personas tal vez habria que hacer una tabla "conductores", "pasajeros", "dueños", etc.).
Las novedades de que son? del expediente? del vehiculo? de las personas?

Es importante que definas bien esas cosas antes de seguir.

[TheFace]

Hola enridp y plantala.

Primero de todo, daros las gracias por vuestra colaboración.
Plantala, tengo presente estudiar bien el modelo relacional que comentas y primeramente realizarlo en un diagrama, que la verdad, nunca he realizado, pero veo que es lo mejor.

enridp, para que tengas un poco de visión de lo que se pretende solo decirte que es para llevar el control de una flota de vehículos, pero cada vez que hay algún suceso con los mismos, se cree una novedad de lo que ha sucedido, puede ser una avería, un accidente, un robo, etc, una vez leída la novedad, se decide si se abrirá un expediente sobre el suceso, donde constará lo que se ha realizado, si se ha llevado al taller, si se repara por los mismos trabajadores, etc.

Cuando se cree un nuevo expediente hay que añadir los vehículos implicados, es decir, todos los vehículos que pudieran tener relación, (que pueden ser varios)
Cada vehículo tiene que tener relacionadas a todas las personas que vayan en el mismo con su relación como conductor, pasajero, si es la persona titular o encargada del vehículo, etc.

Las novedades tienen que estar relacionadas con todo lo que pueda tener relación, pueden haber varios vehículos, varias personas, y varios expedientes.

Un vehículo puede estar relacionado con varios expedientes, así como una persona también.

Vamos, que todo debe de estar relacionada de muchos a muchos.

Yo por ahora lo que tenía pensado es lo siguiente, (pero no lo tengo del todo claro):

O bien, crear una tabla llamada RELACIÓN_VEHIC_PERSONAS_EXPEDIENTES con las siguientes columnas:

- IDTablaRelación
- IdPersonas
- IdVehiculos
- IdExpedientes
- IdNovedades

Donde iré añadiendo los datos además de sus correspondientes tablas a ésta el ID de cada tabla en concreto para que quede de esta forma:

- IDTablaRelación - IdPersonas - IdVehiculos - IdExpedientes - IdNovedades
1 1 1 1 1
2 2 2 2 Null
3 3 3 Null 2
4 4 3 1 1
5 2 3 1 1

De esta forma podría hacer consultas y sacar los datos de cada relación.


Otra posibilidad que tengo en mente es crear otra tabla con el tipo de relación entre vehículos y personas por ejemplo:

-ID
- IDPersona
- IdVehiculo
- TipoRelación

En la columna relación pondría el tipo de relación tal como "Conductor", "titular", "pasajero", etc y en las demás los ID de cada tabla, de esta forma podría extraer los datos de alguna forma.

Lo que pasa es que todo esto no lo puedo llevar a cabo porque no se si será realmente como se debe de hacer, y una vez que tenga por ejemplo los datos en la tabla primera que he mencionado, ¿como llevo los datos de sus tablas a el formulario?...

Bueno, aquí dejo el tocho por si alguien me puede echar una mano.

Gracias.

[enridp]

Hola TheFace!
Perdon por la tardanza pero no tuve tiempo todavia de ver mejor el tema de tus tablas.
Te dejo una mini guia mientras que a lo mejor te ayuda un poco a ver como armarlo
Te dejo una pequeña guia que encontre por ahi:

Proceso de diseño en el modelo E-R
* Identificar las entidades que debe presentar la base de datos.
* Determinar las cardinalidades de las interrelaciones establecidas entre las distintas entidades y clasificar estas interrelaciones entre los siguientes tipos:
o Uno a uno (p.ej., una parcela sólo tiene una dirección).
o Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios).
o Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender varios propietarios y cada propietario puede vender varias parcelas).
* Dibujar el diagrama Entidad/Interrelación.
* Determinar los atributos de cada entidad.
* Definir la clave primaria (única) de cada entidad.

Paso del modelo E/R al diseño de la base de datos
* Las entidades entre las que hay una interrelación uno a uno se deben fusionar en una sola entidad.
* Una vez hecho esto, cada una de las entidades que quedan se convierte en una tabla con una clave primaria y una serie de atributos, de los cuales algunos pueden ser claves secundarias.
* Las interrelaciones uno a muchos se transforman en atributo y clave secundaria de la tabla que representa a la entidad situada del lado de la interrelación correspondiente a muchos .
* Las interrelaciones muchos a muchos entre dos entidades pasan a ser una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias deberán formar parte de la clave primaria de la tabla en la que se convierte la interrelación, cuando corresponda.

[TheFace]

Gracias enridp es breve y muy útil.

Voy a estudiar el tema, aunque así de pronto, veo que en mi caso tengo que hacer lo que menciona el último párrafo: "una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias deberán formar parte de la clave primaria de la tabla en la que se convierte la interrelación, cuando corresponda."

Lo que no entiendo muy bien es lo que comenta de "Las entidades entre las que hay una interrelación uno a uno se deben fusionar en una sola entidad."
¿quiere decir que si solo hay un campo se elimine dicha tabla (o no se llegue a crear) y se meta el dato en otra tabla?.

Bueno, primero voy a trabajar con la primera sección y luego ya veré a ver que me problemas me surgen.

Muchísimas gracias por vuestra ayuda y el tiempo que habéis empleado.

Un saludo.

[enridp]

Claro, si cuando armas tu bosquejo ves que te quedaron tablas que UNO a UNO entonces mete todos los campos en una sola tabla, no hace falta tener varias tablas.
Por ejemplo, a lo mejor al principio podes bosquejar una tabla USUARIOS y otra ADN, ahora cada Usuario tiene UN adn y cada ADN tiene UN usuario, asique podriamos meter los campos de la tabla ADN adentro de la tabla Usuarios (o viceversa)

[TheFace]

Ok, queda claro, gracias por tu ayuda, ya te comentaré algo más adelante cuando avance...

[jbastus]

Buenos días.

Estaba leyendo vuestras respuestas porque me encuentro en una situación en la que no se por donde ir. Debo realizar una sencilla aplicación de recogida de datos.

El usuario accede a la web y empieza a rellenar un formulario de 500 campos.

Todo son datos acerca de un producto, que si color, material, medidas, ... así hasta 500.

Trabajaremos con una base de datos MsSQL Server 2008.

No hay nada más. Como creéis que debería crear esa base de datos?
- una tabla con los 500 campos?
- 500 tablas relacionadas con un FK?

Voy un poco perdido.
Gracias

[gnzsoloyo]

Puedo decirte algunas cosas:

1) Si tienes una pregunta para consultar, no te cuelgues de un post ajeno. Es una falta de cortesía en los foros (es como meterse en conversación ajena para hablar de otra cosa), y además tu pregunta se perderá porque uno no abre un post por la última pregunta, sino por el tema de la primera...

2) Yendo a tu problema, si tienes un formulario de 500 datos, lo más probable es que ese formulario:
- Alimente más de una tabla, por lo que en realidad se traba de un sistema desnormalizado.
- Muchos datos puedan provenir de otras tablas, ya que se trata de datos de otro origen.
- El formulario se alimente de esas tablas, o ciertos datos estén entre opciones seleccionables.

En el primer caso, habría que analizar el conjunto completo para ver qué entidades existen y cuáles son las tablas a crear. Desde ya se pude inferir que debe haber más de una (tablas con tantos campos suelen ser excepciones y no regla).
En el segundo caso, algunas tablas pueden ser fijas y otras implicar formularios de alta de datos para esas tablas específicas.
En el último, es posible que algunos campos representen en realidad tipos de campo ENUM dentro de tablas, pero eso sólo se pude saber analizando el caso específico.

¿Se comprende la idea?

Lo que sí puedo afirmarte es que no es un caso de 500 tablas relacionadas. Eso es básicamente absurdo; si tuvieses 500 tablas relacionadas para un sólo formulario, tendrías un serio problema de diseño...

Las tablas no se crean simplemente para guardar datos. Se crean para almacenar instancias de una entidad real o virtual, pero son conjuntos relacionados con una identidad.
SI la identidad no existe o no es definible, lo más probable es que esa tabla no represente un sistema, sino que sea un invento mal hecho.

[jbastus]

al punto 1: creí que la pregunta podía estar relacionada con el tema, pero tienes razón, fue de mala educación por mi parte, lo siento Enrique.

volviendo al punto 2. del formulario no cuelga nada más, son 500 campos varchar(50), algunos obligatorios, otros no, pero libres, ninguno viene definido por terceras tablas, no hay una tabla de colores por ejemplo, ni una de materiales, ...

El formulario no se rellana todo de golpe, seria muy pesado, esta dividido en 5 secciones de campos cada una, pero solo como método para no agobiar más de lo necesario al usuario.

Sería esta una de esas excepciones donde usar una tabla de 500 campos? lo divido en 5 tablas solo por comodidad?

Gracias.

[gnzsoloyo]

volviendo al punto 2. del formulario no cuelga nada más, son 500 campos varchar(50), algunos obligatorios, otros no, pero libres, ninguno viene definido por terceras tablas, no hay una tabla de colores por ejemplo, ni una de materiales, ...

El formulario no se rellana todo de golpe, seria muy pesado, esta dividido en 5 secciones de campos cada una, pero solo como método para no agobiar más de lo necesario al usuario.

Sería esta una de esas excepciones donde usar una tabla de 500 campos? lo divido en 5 tablas solo por comodidad?

No es una excepción. El hecho que no puedas percibir las estructuras relacionales que se puedan inferir de ese formulario no implica que esas relaciones no existan.
El tema es que no podemos darte directivas en abstracto. Necesitaríamos ver el caso para saber de qué estamos hablando, pero aún así puedo afirmar que es altamente probable que haya una estructura de datos de varias tablas detrás de ese formulario.
Que no la veas, por falta de práctica o de dominio del modelo E-R, no significa no no esté alli.
Es una cuestión de experiencia y estudio. Nada más.

Yo mismo, luego de un año y medio de trabajar exclusivamente en BBD, me enfrenté a modelos que había creado previamente y me dí cuenta que las estructuras que me parecían perfectas estaban, en realidad, mal normalizadas.

"Como todo, Pedro: práctica" (Juan Salvador Gaviota)

Deberías darnos una muestra de lo que es ese conjunto de formularios para poder ver bien de qué se trata.

P.D.: Abre un post nuevo y empecemos desde el principio.

[jbastus]

Gracias gnzsoloyo.
He abierto un nuevo post en http://www.forosdelweb.com/f21/duda-sobre-estructura-tablas-811376/

Gracias por tu ayuda.