Diseño de BD

No esta mal, pero te recomiendo lo siguiente, que construyas una base de datos tipo estrella, en donde una tabla posee gran parte de la informacion de la base de datos, y el resto es tomada de tablas que contienen datos generales, como los colores, marcas y modelos, etc.:

- Define una tabla "Oferta" con los campos:

N_Oferta (campo clave)
Marca
Modelo
Tipo
Color
Matricula
Precio
Data_Oferta (o Comentarios)
Y las tablas 2, 2-a, 2-b, 2-c, 3, 4, 5 les cambias el nombre y le colocas "Marca" a la tabla 2-b, "Color" a la 4, etc. Y cambias el nombre del campo clave de cada una de ellas por "Codigo_Marca", "Codigo_Color", etc. En estas tablas colocaras un listado de datos que son comunes a todos los registros que estaran en "Oferta", por ejemplo, en color, estaran (rojo, blanco, negro, etc.) cada uno con un codigo diferente que le deras tú como quieras, p.e., bl, ng, rj, etc.

Tienes que enlazar las tablas de la siguiente manera:

- Desde la tabla Marca, el campo Cod_Marca lo arrastras hasta el campo Marca en Oferta.
- Desde la tabla Color, el campo Cod_Color lo arrastras hasta el campo Color en Oferta.
- etc.

Si te das cuenta, la forma de la relacion de tu base de datos es en forma de estrella. Cuando enlaces las tablas, debes colocar que "Requerir integridad referencial" y "Actualizar los campos en cascada" y quitar "Eliminar los campos en cascada" (o algo asi). Esto, para que cuando elimines un coche que es el unico que es rojo en la base de datos, se elimine el color rojo de la tabla Color.

Bueno, todo esto te lo digo, porque al construir una base de datos, debes tener en cuenta que existen normas que se deben seguir, y en tu disenyo que presentaste, estas infringiendo la "5° Forma Normal", que hace referencia a que cada uno de los campos de una tabla, tienen que hacer referencia directa con el nombre de la tabla (esto traducido conceptualmente, es asi: Cada una de las propiedades de una Entidad debe hacer referencia directa a la Entidad).

Si te das cuenta, tienes una sola tabla que contendra todos los datos necesarios, en donde algunos de ellos seran extraidos de otras tablas, como el color. Ademas, los registros no deberian repetirse, porque solamente debe existir un solo coche que este guardado en la base a la vez. De hecho, si quieres que en tu base no exista un coche que este almacenado mas de una vez, puedes eliminar el campo N_Oferta, y colocar el campo Matricula como campo clave.

Esto ultimo, debido a que dos coches no tienen una misma matricula, y una matricula no la pueden tener mas de un coche. Lo malo se presentaria, en el caso que el coche sea vendido, y el comprador quiera venderlo nuevamente. Lo cual puede ser solucionado, eliminando el coche una vez que este ya haya sido vendido.

Creo haberte explicado bien, y espero que la idea te ayude, suerte.

PD: Si no entendiste algo, o si tienes algun comentario o duda, no dudes en preguntarme.

Gracias,
En mi modelo también hay una organización tipo estrella?, En el caso de la tabla 2 relacionada con las tablas 2-a, 2-b y 2-c?.

>Podriamos decir que si, pero tiene sentido solo cuando hay una tabla principal que obtiene los datos de otras tablas (como parametros)...

Yo he relacionado las tablas 2-a, 2-b y 2-c con la 2, pero no sé por qué lo he hecho ya que: Tiene sentido crear la tabla por ejemplo “Tipo_Coche” ya que yo definiré previamente los tipos de coche a escoger, después los usuarios escogeran de un desplegable en el web los tipos de coche de la tabla “Tipo_Coche” y el dato se enviará a la tabla “Oferta” en tu caso o a la tabla 2 en el mio, entonces porqué relacionar las dos tablas (“Tipo_Coche” y “Oferta”)?. Que existan sí, pero porque relacionarlas?

>En el caso que yo te presento, tiene sentido en la integridad de los datos, es decir, !!!!en la tabla "Oferta" no existira ningun coche cuyo tipo (Tipo_Coche) no este presente en la tabla Tipo. Si por alguna extranya razon, en la tabla "Oferta" se intentara colocar un Tipo_Coche que no este en la tabla Tipo, SQL Server no lo permitiria, enviando un error. (NOTA: Ese tipo de errores tienes que saber capturarlos, para que tu sitio no se caiga).

En mi modelo, lo he puesto así como has visto porque quiero hacer tablas con pocos datos y así agilizar las consultas e inserciones (todo eso de la normalización ;-)), además que todos los datos tengan como elemento en común el código de la oferta ya que es el verdaderamente único e irrepetible en la base de datos “Ofertas”.

>Agilizar las consultas e inserciones recide, principalmente, en que tan bien disenyado este tu base de datos, y no en la cantidad de datos. Si te das cuenta, en tu modelo, para consultar por una cierta oferta, la consulta seria algo asi: SELECT Tabla1.*, Tabla2.*, Tabla2-a.*, Tabla2-b.*, Tabla2-c.*, Tabla3.*, Tabla4.*, Tabla5.* FROM Tabal1, Tabla2, Tabla2-a, Tabla2.b, Tabla2-c, Tabla3, Tabla4, Tabla5 WHERE Tabla1.N°_Oferta = 'Algun Numero' AND Tabla2.N°_Oferta = 'Algun Numero' AND .....blablabla...;

>Como te daras cuenta es un poco larga... en el caso que yo te propongo, seria algo asi: SELECT Oferta.* FROM OFERTA WHERE Oferta.N_Oferta = 'Alguna Oferta';

>Creo que es un poco menos larga (lo que no implica, en todo caso que sea mas rapida). Ahora si quieres rescatar los datos de las demas tablas y no los codigos, puedes hacer un INNER JOIN: SELECT Oferta.*, Color.Color, Tipo.Tipo, Marca.Marca FROM OFERTA INNER JOIN Tipo ON Oferta.Tipo_Coche = Tipo.Cod_Tipo INNER JOIN Marca ON Oferta.Marca = Marca.Cod_Marca INNER JOIN blablablablabla WHERE Oferta.N_Oferta = 'Alguna Oferta';

>Esta ultima consulta puede resultar igual o mas larga que la que te presentaba en tu caso, pero existe un pequenyo gran detalle: Cuando tu realizas una consulta que no esta anidada (tu caso) por lo general suele tardar un poco mas, porque primero abre cada una de las tablas, y luego saca todos los registros que coinciden con la clausula WHERE. En mi caso, no abre cada una de las tablas primero, sino que las va abriendo y haciendo una subconsulta a esa tabla, para sacer exactamente el unico registro que coincide con la clausula ON (si te das cuenta es uno a uno, es decir, un coche tiene un solo tipo de coche).

>Respecto a la velocidad, no te preocupes, SQL Server gestiona muy bien los datos, y esta disenyado para mantener alrededor de 80.000 registros...

Como es la primera vez que hago una base de datos y solo he visto algunos ejemplos, me extraña que en mi estructura todas las tablas se relacionen por el mismo campo y además este sea el campo clave en todas, entonces cuando se añade una nueva oferta todas las tablas tienen que añadir una nueva fila de datos que debe ser en todas del mismo código de oferta (campo calve que las une a todas). Igual esta muy bien hecha pero quiero asegurarme consultando a gente que quizás sabe mas que yo.

>Tienes razon, por eso yo te propuse el otro modelo, porque si te das cuenta, en vez de buscar en cada tabla por el N°_Oferta, buscarias por el Cod_ALGO de cada una de las tablas. Ademas, con ello, puedes tener grupos de registros, por ejemplo, todas las ofertas cuyo tipo de coche es Camion.

>Respecto a que saben mas que tu, no siempre es cierto, de hecho, en lo que a disenyo de bases de datos concierne, cada uno de las personas que disenyan bases de datos tiene su manera de hacerlo. NO EXISTE UN UNICO DISENYO PARA UN PROBLEMA EN PARTICULAR.

Muchas gracias por tu interés! y espero tus comentarios.

>Esos son mis comentarios, espero que ahora te convenzan... ;)

Cèsar

>Suerte.