Diseño de BD

¿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?.
>Podríamos decir que si, pero tiene sentido solo cuando hay una tabla principal que obtiene los datos de otras tablas (como parámetros)...
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 escogerán 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 por qué relacionar las dos tablas ("Tipo_Coche" y "Oferta")?. Que existan sí, ¿pero por qué relacionarlas?
>En el caso que yo te presento, tiene sentido en la integridad de los datos, es decir, ! En la tabla "Oferta" no existirá ningún coche cuyo tipo (Tipo_Coche) no este presente en la tabla Tipo. Si por alguna extranya razón, en la tabla "Oferta" se intentara colocar un Tipo_Coche que no este en la tabla Tipo, SQL Server no lo permitiría, 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 más 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 más, 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 único 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 más que yo.
>Tienes razón, por eso yo te propuse el otro modelo, porque si te das cuenta, en vez de buscar en cada tabla por el N°_Oferta, buscarías 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 Camión.
>Respecto a que saben más que tu, no siempre es cierto, de hecho, en lo que a diseño de bases de datos concierne, cada uno de las personas que disenyan bases de datos tiene su manera de hacerlo. No existe un único diseño para un problema en particular.
Muchas gracias por tu interés! Y espero tus comentarios.
>Esos son mis comentarios, espero que ahora te convenzan... ;)
Cesar
>Suerte.

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?.
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 escogerán 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 por qué relacionar las dos tablas ("Tipo_Coche" y "Oferta")?. Que existan sí, ¿pero por qué relacionarlas?
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".
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 más que yo.
Muchas gracias por tu interés! Y espero tus comentarios.
Cesar

Me han ido muy bien tus aclaraciones, creo que tengo al menos por donde empezar a estructurar mi base de datos e ir aprendiendo más :-), saludos!
P.D. Si sabes de recursos gratuitos en la red donde expliquen como estructurar y hacer funcionar bases de datos puedes darme las direcciones, sino no pasa nada, estoy ya contento con tu respuesta.