Cita: 1) Los empleados componen un sistema de jerarquía, compuesto de cuatro tablas: La tabla principal es Empelados, de la que dependen Administrativo, Inspector y Supervisor (la ortodoxia dice que los nombres de las tablas se expresan en singular).
Aqui la clave primaria de las 4 tablas ¿como seria? y como estarian relacionadas la tabla Empleados con las otras 3.
En una jerarquía, las tablas hijas no poseen clave propia: Usan la clave de la tabla madre, en lo que se denomina "relación identificatoria". Así, las tablas hijas sólo tienen como atributos propios aquellos atributos que pertenecen a su entidad.
En Inspector, por ejemplo, puede tener título, categoría, fecha de última evaluación, etc. Esos atributos no pertenecen al Administrativo, y tampoco al Supervisor.
El Administrativo puede tener relación con una tabla que determine su horario de trabajo o las entradas y salidas, cosa que carece de sentido con el Inspector.
Cita: 3) Existe una tabla que contiene las ofertas. Esa, más que ofertas, yo le pondría de nombre Solicitud o bien Presupuesto. Está vinculada a un Administrativo y al Cliente, y de ella depende otra denominada Solicitud_Item, que contiene los ítems a inspeccionar, si hay más de uno.
En este punto, cuando hablas de vinculacion estas diciendo que un administrativo puede realizar muchas ofertas(1:n) y que la Pk(primary key) de administrativo aparece en Solicitud,¿es correcto?. Cuando dices "de ella depende otra denominada Solicitud_Item", aqui ya me pierdo, no se que quieres decir con esto.
La relación entre Administrativo y Ofertas o Presupuesto se expresa:
"Un administrativo recibe N pedidos de oferta y cada Oferta es recibida por un único Adminsitrativo". De allí que la relación sea 1:N, entonces la PK representada por cardinalidad N va en la tabla representada en cardinalidad 1.
Respecto al otro tema, si te imaginas una planilla de pedidos, puede ser más claro:
La tabla Presupuesto contiene el encabezado y los datos de identificación del cliente. Pero si hubiese más de un ítem a revisar, o bien se requiere una lista con columnas para describir el pedido, esa lista compone otra tabla (Normalización de Bases de Datos), donde cada línea contiene uno de los renglones de la solicitud, identificado por el ID de Presupuesto, más un ID por subitem. Ex exactamente el mismo principio que para hacer una factura, sólo que esto es un listado de revisiones diferentes.
En el caso que cada pedido se corresponda con una única inspección, de un único elemento, y abarcando una única tarea, puedes usar una sola tabla.
Cita: 4) Se infiere la existencia de una serie de tablas : Normativa, la que contiene las normativas que deben cumplirse; Inspeccionable, para listar todos los elementos sometidos a normativas; Inspecionable_Norma, que relaciona ambos elementos. Inspeccionable está relacionada con Solicitud_Item, las otras se usan para verificación
Aqui lo que no entiendo es la tabla Inspeccionable_Norma. Ya que en la tabla Solicitud los datos a incluir son los procedentes de las tablas Normativa, Inspeccionable y Tipo_Inspeccion(tabla que tu no mencionas pero si aparece en el modelo). Estas tablas procederian, creo yo de atributos multivaluados.
No existen atributos multivaluados en el modelo relacional. Eso es una transgresión
gravísima. Si tienes un atributo multivaluado, en realidad lo que tienes es una tabla desnormalizada, y debes proceder a normalizarla.
En tu contexto Inspeccionables son todo tipo de aparatos, elementos, maquinarias, vehículos, etc, que pueden ser revisados por un inspector. Como algunos de ellos
pueden tener periodos de revisión regulados por reglamentación del Estado, debería haber una relación n:n entre esa tabla y la tabla de Normativas. En esa vinculación puede que no estén todos los Inspeccionables (el único nombre que se me ocurrió)., porque entonces el período sería establecido por el cliente.
Cita: 5) Hay una tabla Orden_Inspeccion, relacionada con Solicitud e Inspector y de la que depende Items_Inspeccion.
Esta tabla tampoco la veo, no se que atributos podria tener. No tienes en cuenta una tabla Item, que es donde se guardan los datos de los elementos que se inspeccionan, y que es conveniente guardarlos para saber si los defectos se han corregido o no. Tampoco indicas la existencia de una tabla defectos, ademas no seria una tabla serian varias, ya que los defectos que tiene un coche no son los mismos que los de una grua. Edito: Y ademas un mismo coche hoy y dentro de 4 años pueden no tener los mismos defectos, con lo que tenemos un historico de defectos.
Esta tabla hereda los datos del Presupuesto, al que sólo hace referencia, pero remite a la existencia de un documento propio del Inspector: El reporte de inspección.
Si el reporte final es realizado por un Inspector, eso se debe asentar, porque si bien comparte datos con el pedido original, no se emite ni se llena con la misma información...
Hasta existe la posibilidad de que se cancele, sin que por ello deje de existir el pedido original.
Todo flujo I/O de datos de un sistema debe ser registrado. Y Cada registración con identidad propia en un sistema de bases de datos, es una entidad que debe existir como tal.
En una tabla donde estén los reportes de inspección, puede estar presente otra relación que se denomine "ReparacionesRealizadas", y tal vez alguna más...
Habría que analizar el ssitema más detalladamente en ese segmento del proceso para ver bien la estructura de datos que le da soporte.
Cita: 7) Existe una tabla ReporteInspección que se relaciona con OrdenInspeccion. No se indica que existe una discriminación del reporte por item solicitado, por lo cual a priori no se puede establecer si se requiere de una tabla ItemsReporte o no.
Aqui no se lo que quieres decir
Lo mismo que antes: Si se realizó un listado de items para inspector, y cada item requiriese diferentes herramientas, puede que quieras relacionar los items con las herramientas. Sino, deberás relacionar la orden de inspección con un listado de herramientas, lo que de todos modos se expresaría en una tabla porque la relación sería N:N...