Dudas en diseño de bbdd

[josito_777]

Hola, tengo que hacer un diseno de una bbdd y no se como hacerlo para normalizarlo. Os expongo en problema:

tengo sucursales de una empresa.

sucursal ( id_sucursal, trabajadores, proyectos, años, ...,....)

son en total 650 sucursales y esos datos son de diferentes años del 2008, 2009, 2010 y 2011. Cual podria ser la clave primaria? id_sucursal y el año?.
Seria mejor dividirlo en tablas por años?

y la otra pregunta es que el numero de campos de la sucursal son aproximadamente 800, es mejor dividirlo en varias tablas?.

Muchas gracias!

[Omura]

800 campos mas que seguro deban ser repartidos en varias tablas, ahora mencionas 650 sucursales, esto es a nivel país o hay sucursales en otros países.

por lógica tienes que tener un campo dirección, ahí deberías tener mínimo 2 tablas adicionales si no son mas, por ejemplo por aquí en caso tuviéramos que registrar las direcciones en la BD de sucursales repartidas por todo el país, tendríamos que manejar por separado varios datos...

av. Javier Prado 1234, San Isidro, Lima, Lima, Perú

para una dirección como esta, necesitarías las siguientes tablas...

tabla tblSucursal
idSucursal
...
dirección
idDistrito
idPronvicia
idDepartamento
....

tabla tlbDistrito
idDistrito
nombreDistrito

tabla tblProvincia
idProvincia
nombreProvincia

tabla tblDepartamento
idDepartamento
nombreDepartamento

[gnzsoloyo]

¿800 campos?
Más allá de que el sistema lo soporte, da toda la impresión de que a esa base le está faltando algo de normalización, o al menos hay que revisar su estructura, porque puede haber errores de diseño...

[josito_777]

son 800 campos porque toda la información corresponde a una sola entidad, es decir a una sola sucursal.

Pensando en dividir la información me saldría esto:


General information ( aqui hay como 100 valores unicos )

Labour detail ( aqui hay como 200 valores unicos )

Costs ( aqui hay como 100 valores unicos )

Production ( aqui hay como 300 valores unicos )



¿Debería crear estas tablas?. Pero serían siempre relacciones 1:1, ¿no?

[gnzsoloyo]

Sin ver el tipo de datos que tiene esa tabla no te puedo aconsejar segmentarla o no.
Puede ser que si, puede ser que no. Depende de los datos.

[josito_777]

La mayoria de los datos son numericos de pocas cifras

[gnzsoloyo]

Iniciado por josito_777

La mayoria de los datos son numericos de pocas cifras

Eso no nos dice nada.
El tema es saber qué representan esos datos, cómo se relacionan con otra/s tablas, etc.
En definitiva: Esa tabla representa una entidad del sistema, pero sin saber cómo se relaciona esa entidad con el resto, no podemos saber, a priori si existe alguna forma de simplificarla.
Un caso sería, por ejemplo, si existe un subconjunto de datos en la tabla tal que sea conceptualmente tratable como unidad, y que a su vez fuese opcional. Es la situación en la cual ese subconjunto puede no tener dependencia funcional de la PK de la tabla, sino de alguno de los otros atributos. En ese caso, ese subconjunto no pertenece a la tabla. Es otra tabla, aunque la relación fuese 1:1.

[josito_777]

Creo que he entendido bien lo que me has escrito. Entonces si que lo podría agrupar en subconjuntos, ya que algunos datos son opcionales. Entonces lo dividiré en varias tablas. Al ser una relación 1:1 propagaría la PK de tabla principal a la tabla secundaria o viceversa?.

Y otra apregunta:
Los datos son de diferentes años. por lo que los valores de los campos podrán no ser iguales en cada año. ¿Habría que crear otra entidad? o dejarlo asi:

tabla( id, campo1, campo2, ..., ...., año)

En el caso de ponerlo en la tabla principal, ¿es mejor poner la PK "id" mas "año" o poner el año como clave alternativa?.