SQL - Ayuda con diseño de tablas

Buenos días, me dispongo a diseñar una bbdd para la inserción de datos, pero no se muy bien como organizar estos datos.

Voy a poner un ejemplo que he pensado parecido al real, pero para que se vea más claro de mis necesidades.

Quiero registrar cadenas de números cuyas propiedades cambian según si pertenecen a una cadena o a otra.

Por ejemplo, tengo una cadena de números que van del 1 al 100, y otra que va de 5 a 105.

El nº 5 pertenece a las 2 cadenas, pero si está en el primer registro, en el que están los 100 primeros números, resulta que el nº 5 tiene la propiedad orden establecida a 5.

Sin embargo, en el siguiente registro que registra la segunda cadena, la que va de 5 a 105, el nº 5 tiene la propiedad orden establecida a 1.

A parte, tengo otras propiedades que varían de igual manera y sin aparente lógica. La propiedad orden si tiene cierta lógica, pero las otras propiedades no la tienen.

En total, tengo 5 propiedades para cada número de cada serie.

Cada propiedad tiene unos posibles valores finitos. En este caso, la propiedad orden depende del mínimo y máximo de las series. Pero en el caso real, cada propiedad puede tener unas posibilidades finitas. Por ejemplo, si fuese la propiedad color, yo tendría una lista de 10 colores, y la propiedad color solo podría tener 1 de esos 10 colores, pero como digo, según en qué serie esté tendrá un color u otro.

Me gustaría saber como se os ocurre que puedo establecer la tabla/s o si necesito 2 tablas conectadas según el modelo entidad/relación para almacenar estos datos.

Se me ha ocurrido hacerlo en una sola tabla, poniendo como campos campo1, campo1propiedad1,campo1propiedad2, etc... y así me salen 600 campos. Pero no se me ocurre como puedo establecer estos datos con varias tablas utilizando el modelo entidad/relación para no tener que tener 1 tabla con 600 campos.

Como bien te comento gnzsoloyo, en FDW, "No tienes ni la menos idea de lo que es un modelo ENTIDAD-RELACION", deberia leer un poco mas sobre este tema.

Veo que me has pillado. Ahora que he sido baneado de ese foro le he pedido a mi socio que se registre él. Pero luego he caído en que no es el único foro... y por eso he empezado a buscar otros, como este. Espero que esta contestación en plan acceso directo al otro foro no sea costumbre entre los participantes de este foro.

Por cierto, te aconsejo que no uses esa página que comentas. Yo he descubierto que como alguno le venga en gana señalarte por la razón que le da la gana... te buscas un problema de los gordos más allá de lo que sea que puedas debatir en ese sitio. Yo llevo unos días sufriendo esos problemas.

Buenas Kritic

Ya veo que te han dado bien, pero es que si no sabes lo básico ... A ver lo primero que tienes que hacer es aprender el modelo E/R bien, si tienes alguna duda ahí, pues en el foro de Bases de Datos se te puede ayudar. Después tendrás que aprender a Normalizar ese modelo antes de ponerte a hacer las tablas.

Cuando lo anterior lo tengas claro puedes empezar a pensar en las tablas y estudiar el lenguaje SQL, que no es difícil (salvo en algunas consultas), pero que también hay que estudiarlo para saber utilizarlo.

Vamos ... que te queda aún bastante camino por recorrer.

Un saludo

Hola, primero gracias por la molestia que supone contestar.

Debo decirte que no es problema de desconocimiento del modelo E/R. Lo he aplicado otras veces con y el resultado ha sido bastante bueno. Sin embargo este problema me parece más un problema de abstracción, más que de conocimiento del modelo E/R.

Creo que este problema es algo más complicado que los que me he encontrado hasta ahora, y de ahí que me cueste abstraerlo.

Lo único que se me ocurre, siguiendo el ejemplo anterior, es separar los campos en distintas tablas, pasando de una sola tabla con 600 campos a una con 100, y otra con 500 ambas relacionadas. O eso, o 6 tablas cada una con 100 campos también todas relacionadas. Es lo único que se me ocurre para que solvente mi problema actual.

Para otros problemas si se me ocurren formas de reducir el número total de tablas para luego, al relacionarlas, sacar todos mis datos siendo menos campos en total, aunque estén en más tablas. Pero en este caso en concreto no se me ocurre.

Por cierto, como hay tantos foros he venido directamente a este. Pero bueno es saber que hay uno de bases de datos en general, para futuras ocasiones. Gracias por ello. Sin embargo ahora no se si abrir otro post en ese foro o continuar con este.

He estado viendo que existen bases de datos multidimensionales. Tal como me imagino yo un cubo, esta solución podría resolver el problema de simplificar mis tablas.

Me imagino que tengo en una tabla normal el 1º número de la serie, junto con sus 5 propiedades como un registro. El 2º número como un registro distinto, etc. Luego me imagino que otra serie construye una tabla diferente con la misma estructura, y cada serie posterior construye una tabla diferente con la misma estructura. De esta forma solo tengo 6 columnas en cada tabla. Y ahora, por último, coloco una tabla encima de la otra, no a continuación, sino encima construyendo una tercera dimensión, y cada tabla la coloco también encima, teniendo para cada serie una posición de esa tercera dimensión.

De esta manera me sale un cubo con 6 columnas (1 número + 5 propiedades), 100 filas (100 números) y 1 "capa" (no se como llamarlo para esa tercera dimensión) por cada serie.

Sin embargo... por lo que estoy viendo en mis primeros vistazos intuyo que las bases de datos multidimensionales son bastante complejas. Y no es fácil construirlas aunque sea "para salir del paso".

Pienso que en este caso el modelo E/R no me puede hacer tener menos de mis 600 columnas (o al menos yo no se abstraer el problema para que tenga menos, aunque sea con el uso de otras tablas)