He leido todo lo que habeis dicho y yo veo lo siguiente
TblUnidades
idU
...Campos para los datos generales de la unidad...
TblElementos
idE
idTpE FK a TblTpElementos
idU FK a TblUnidades
...campos comunes a todos los elementos (posición ???...)...
TblTpElementos
idTpE
...Campos que describen al tipo de elemento (nombre, tamaño...??)
TblLecturas
idL
idE FK a TblElementos
idTpL FK a TblTpLecturas
fechaHora (datetime) (No debe ser único podría haber distintas lecturas que se toman al mismo tiempo)
valor
...Quizas no hacen falta mas campos....
TblTpLecturas
idTpL
unidades
...otros campos...
TblRTpElementoTpLecturas
idR
idTpE FK
idTpL FK
... otros (frecuencia?)...
(Con esta tabla consigues obtener los objetos de formulario que se deben mostrar en la pantalla de un elemento)
Tbl---Tabla
Tp---Tipo de
TblR --- Tabla de relación
Con esta estructura es muy posible que puedas representar tu sistema... sin, seguramente, agregar muchos campos en las entradas con suspensivos de cada tabla.
Seguro que no necesitas agregar 1000 campos.
Con esto tendras muchos registros en las tablas Elementos y Lecturas pero pocos campos....
Esta sencilla consulta te da los datos del grafico de enero del 2013 para la lectura X del elemento Y.
Esta los del grafico de
todos los elementos de tipo Y, pera el mismo tipo de lectura y periodo.
Se puede complicar con join para obtener la unidad y los datos del elemento pero para el grafico es suficiente.
Ojo no es el esquema ER (Entidad/Relación) son las tablas físicas. (Sabes que no toda Entidad se convierte en tabla fisica ni a la inversa) Obviamente se puede complicar pero para eso debería conocer mas el caso.