Ayuda para crear modelo E-R

[tortiman]

Hola a todos soy nuevo en esto de la programacion en base de datos y estoy bastante verde en la creación de modelos E-R, ya que me pierdo. Quiero crear un modelo E-R para la siguiente ejemplo:

Una empresa que se dedica a inspeccionar ítems(coches, gruas,maquinaria..) necesita contener información de sus clientes, empleados, equipos de inspección e ítems de los clientes.

Los empleados se dividen en 3 tipos según las funciones que desempeñan: administrativos, inpectores y supervisores.

El cliente (nº cliente, nombre, dirección, teléfono, fax, email, cif) solicita la realización de una inspección de un ítem(ascensor, caldera, vehículo...), debe quedar constancia de la fecha de la petición y del empleado que recoge la oferta. Se le confeccionará una oferta donde se indicara los datos del cliente, importe, descripción del trabajo indicando la normativa que le aplica al ítem (rd842/02, rd3245/82.....), el tipo de inspección es periódica, inicial o voluntaria y nº de oferta. Esta oferta se le enviará al cliente.

Si transcurridos tres meses desde el envío de la oferta, esta no se acepta, se anula.

Si se acepta, la oferta se asigna a un inspector (nº inspector, nombre, dirección, nº seguridad social, dni, campo1, campo2,….,campon).

El inspector realizara la inspección del ítem en un tiempo no superior a 5 días desde la aceptación de la oferta, previamente notificará dicha inspección asignando a la inspección un número de notificación. Deberá quedar también recogida la hora de inicio y fin de la inspección

El inspector al inspeccionar el ítem(nº identificación, características particulares de cada ítem) puede encontrar o no defectos. Los defectos tendrán una descripción, calificación de gravedad, plazo de subsanación. El inspector usará unos equipos de inspección(nº identificación, plazo calibración, rango medida, fecha compra, marca, nº serie..) para realizar la inspección, estos deberán estar calibrados y en buen estado.

El inspector posteriormente realizará un informe (nº informe, fecha inspección, fecha informe, plazo validez inspección), éste estará dividido en tres partes, en una se indicara los datos del titular, datos del ítem, datos de los defectos. El informe se enviará al cliente como máximo dentro de los 10 días si el informe es DESFAVORABLE, y si es FAVORABLE se enviará dentro de los 20 días siguientes a la fecha de realización de inspección.

Dentro del funcionamiento de la empresa hay una serie de requisitos que esta tiene que cumplir cada cierto tiempo, cada 2 años cada inspector será supervisado por el supervisor, en todos los campos en los que está acreditado, estos datos se guardaran en una tabla supervisión(nº supervisión, inspector, fecha supervisión, campo supervisado,…..)

Además, se tiene que verificar que el inspector realiza 3 inspecciones mínimo anuales, supervisión anual, en cada campo que está dado de alta, si no las realiza se suspende de ese campo, esto se guarda indicando el inspector, fecha suspensión y campo.

-------------------------------------
Espero vuestra ayuda. Un saludo

[gnzsoloyo]

Esto es un TP de la facultad...
¿No sería mejor que tratases de resolverlo tu mismo?
Al menos es lo que a mí me tocó vivir...

[tortiman]

Hola, me gustaria resolverlo, pero no soy informatico y no es por falta de interes o vagueria, lo que pasa que me pierdo a medida que avanzo. Si alguien me puede echar una mano se lo agradeceria. Un saludo.


Edito: ademas no se, si sintacticamente está bien planteado el problema.

[Valery-Net]

Te recomiendo usar una herramienta de modelación, te hace la vida más sencilla, me gusta usar Microsoft Visio

[tortiman]

Hola Valery-net, no se si es cuestion de usar unas herramientas u otras, sino de saber obtener el diagrama correcto, de todas maneras gracias y probare microsoft visio.

[gnzsoloyo]

Bien, una manito...

Hoy le dí una leída más detallada y como ejercicio de la facultad es bastante complejo para desarrollar un modelo de datos. Hay muchos detalles que se infieren pero que no aparecen en la descripción, pero pertenecen al sistema.

Por suerte no hay mucha información-basura, cosa habitual en los TP. Han sido bastante piadosos (vieras las barbaridades que he tenido que resolver). Aún así, siendo tan largo, voy a tratar al menos de decirte algunas cosas:

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).

2) Cliente compone una tabla separada. No está categorizado.

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.

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

5) Hay una tabla Orden_Inspeccion, relacionada con Solicitud e Inspector y de la que depende Items_Inspeccion.

6) Se infiere la existencia de una tabla HerramientaUsada y otra Herramienta, la primera de las cuales está relacionada con Orden_Inspeccion y determina qué herramientas está retirando el Inspector para su trabajo.

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.

8) Existe una tabla Supervisiones_Inspector, relacionada con Supervisor e Inspector.

9) Se infiere la existencia de una tabla Acreditaciones_Inspector que se relaciona con Inspector.

10) Existe una tabla Suspension_Inspector, relacionada con Acreditaciones_Inspector, Supervisor e Inspector.

No queda claro de qué depende la periodicidad de las inspecciones, si de la normativa vigente o de la decisión del cliente. En un caso, el período está indicado en la normativa.; en el segundo puede estar en el ReporteInspeccion, el cual se puede usar de referencia para obtener el listado de inspecciones futuras a realizar.

Se puede llegar a inferir que exista algún tipo de entidades que defina la relación entre el cliente y la empresa. Eso puede dar lugar a Contrato, CuentaCorreinte o muchas otras más, pero en este punto no componen parte del sistema relevado.

Esto sería, más o menos a vuelo de pájaro, lo que se puede sacar del relevamiento que estás posteando.
Puede haber mucha información faltante y muchas tablas más que sean necesarias para el funcionamiento del sistema (los listados de ciudades, provincias, países, categorizaciones varias y muchas otras cosas se suelen poner como tablas fijas para evitar que los usuarios deban escribir -mal muchas veces- ciertos datos críticos).
Pero creo que por ahora alcanza para ver algo de la transformación de un relevamiento en modelo de datos.

Espero que te sirva.

[tortiman]

Iniciado por gnzsoloyo

Bien, una manito...

Hoy le dí una leída más detallada y como ejercicio de la facultad es bastante complejo para desarrollar un modelo de datos. Hay muchos detalles que se infieren pero que no aparecen en la descripción, pero pertenecen al sistema.

Por suerte no hay mucha información-basura, cosa habitual en los TP. Han sido bastante piadosos (vieras las barbaridades que he tenido que resolver). Aún así, siendo tan largo, voy a tratar al menos de decirte algunas cosas:

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).

2) Cliente compone una tabla separada. No está categorizado.

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.

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

5) Hay una tabla Orden_Inspeccion, relacionada con Solicitud e Inspector y de la que depende Items_Inspeccion.

6) Se infiere la existencia de una tabla HerramientaUsada y otra Herramienta, la primera de las cuales está relacionada con Orden_Inspeccion y determina qué herramientas está retirando el Inspector para su trabajo.

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.

8) Existe una tabla Supervisiones_Inspector, relacionada con Supervisor e Inspector.

9) Se infiere la existencia de una tabla Acreditaciones_Inspector que se relaciona con Inspector.

10) Existe una tabla Suspension_Inspector, relacionada con Acreditaciones_Inspector, Supervisor e Inspector.

No queda claro de qué depende la periodicidad de las inspecciones, si de la normativa vigente o de la decisión del cliente. En un caso, el período está indicado en la normativa.; en el segundo puede estar en el ReporteInspeccion, el cual se puede usar de referencia para obtener el listado de inspecciones futuras a realizar.

Se puede llegar a inferir que exista algún tipo de entidades que defina la relación entre el cliente y la empresa. Eso puede dar lugar a Contrato, CuentaCorreinte o muchas otras más, pero en este punto no componen parte del sistema relevado.

Esto sería, más o menos a vuelo de pájaro, lo que se puede sacar del relevamiento que estás posteando.
Puede haber mucha información faltante y muchas tablas más que sean necesarias para el funcionamiento del sistema (los listados de ciudades, provincias, países, categorizaciones varias y muchas otras cosas se suelen poner como tablas fijas para evitar que los usuarios deban escribir -mal muchas veces- ciertos datos críticos).
Pero creo que por ahora alcanza para ver algo de la transformación de un relevamiento en modelo de datos.

Espero que te sirva.

---

Gracias por responder, pero antes de las tablas quiero ver el diagrama e-r correcto. Es cierto que aun faltan cosas, como por ejemplo el sistema de facturación de la empresa, voy a pegar una imagen del diagrama e-r con sus relaciones y su cardinalidad.



En este diagrama, faltan las propiedades de los objetos, que las ire incluyendo, pero quiero saber si la estructura principal está bien planteada.

[tortiman]

vuelvo a cargar la imagen, se ve mal.

[gnzsoloyo]

Estás haciendo un DER de análisis de sistemas y no de modelo de datos. Eso es un error conceptual, porque no son iguales por más que usen las mismas estructuras de representación.
Ten en cuenta que en el modelo conceptual de datos no existen los procedimientos, por lo que por ejemplo, no existe una relación que se denomine "asigna". Ese tipo de relaciones pertenece a los sistema procedurales y compone parte del análisis de flujo de datos, pero no de la estructura de datos.
¿Se entiende la diferencia?

Esta tarde trato de postearte un ejemplo de DER lógico de tu caso.

[tortiman]

Iniciado por gnzsoloyo

Estás haciendo un DER de análisis de sistemas y no de modelo de datos. Eso es un error conceptual, porque no son iguales por más que usen las mismas estructuras de representación.
Ten en cuenta que en el modelo conceptual de datos no existen los procedimientos, por lo que por ejemplo, no existe una relación que se denomine "asigna". Ese tipo de relaciones pertenece a los sistema procedurales y compone parte del análisis de flujo de datos, pero no de la estructura de datos.
¿Se entiende la diferencia?

Esta tarde trato de postearte un ejemplo de DER lógico de tu caso.

------

No entiendo lo que me quieres decir con "en el modelo conceptual de datos no existen los procedimientos". Como te digo al principio soy novato en esto, y lo que se lo he aprendido de buscar en google, por ejemplo de

[URL="http://elies.rediris.es/elies9/5-1.htm"]http://elies.rediris.es/elies9/5-1.htm[/URL]

Gracias por tu ayuda

[tortiman]

He realizado una modificación en diagrama, ya que los items a inspeccionar son de diferente naturaleza( no es lo mismo un vehiculo que una grua o una caldera) asi como sus defectos. El diagrama quedaria asi.

[tortiman]

Bueno dandole vueltas a la semantica, he intentado definir el modelo lo más posible para arrojar la máxima luz posible. Al final he indicado las posibles entidades aunque aqui ya me empiezo a perder. El problema se redefiniria tal que así:

Una empresa se dedica a la inspección de servicios industriales, la empresa para desarrollar la actividad tiene empleados de tres categorias(administrativos, inspectores y supervisores), tiene equipos de inspección para el desarrollo de las inspecciones.

El funcionamiento es el siguiente, un cliente llama a la empresa para solicitar la inspección de uno o varios items, estos items pueden ser de su propiedad o no serlo.

Del cliente nos interesa saber nombre, dirección(calle, número, ciudad, provincia, código postal, teléfono, fax, email), persona de contacto, cif.

El administrativo que recoge la nota confecciona una oferta, se realizara una oferta por item, donde se indican código oferta, los datos del cliente(nombre, calle, numero, ciudad, código postal, teléfono, fax, cif, provincia), el tipo de item(camión, grúa….) a inspeccionar, la normativa(vehículos, grúas..) que le es de aplicación, el tipo de inspección(periódica, inicial o voluntaria), la cantidad de ítems a inspeccionar, la fecha de oferta y el importe.

La validez de la oferta tiene 90 días desde la fecha de su envío, en caso de no aceptación de la oferta o plazo cumplido, estas ofertas se guardan para dejar un registro. La oferta aceptada por el cliente se asigna a un inspector, se guarda la fecha en la que se asigna la oferta, ya que es un dato relevante. A un inspector se le pueden asignar varias ofertas de distintos ítems.

El inspector realiza la inspección del item, para ello usa obligatoriamente unos equipos de inspección, y durante dicha inspección puede encontrar o no defectos. Un mismo item puede ser inspeccionado mas de una vez por un inspector.

De los equipos no interesa saber, para su control, su código, marca, nº de serie, modelo, rango, fecha compra, fecha calibración, plazo de calibración, inspector que usa el equipo. Un equipo puede ser usado por varios inspectores.

Los defectos estarán tipificados y tendrán un código y una descripción. Además cada item tiene sus propios defectos, osea, los defectos que pueda tener un vehículo no son los mismos que los que tiene una grúa.

El inspector después de realizar la inspección emitirá una informe donde se recogerá la siguiente información, código del informe, datos del propietario del item (nombre, dirección fiscal, dirección del emplazamiento del item, cif, coordenadas), datos del item (que dependiendo de que tipo sea, los datos a guardar serán distintos), la fecha de informe, plazo de inspección reglamentaria, fecha validez inspección, la fecha de inspección y los defectos encontrados, indicando su plazo de corrección y su calificación (leve, grave,..).

Del inspector nos interesa saber nombre, dirección, cif, código empleado, teléfono, campos en los que esta acreditado(campo1, campo2…..), como máximo puede estar acreditado en 8 campos, fecha alta empresa, fecha acreditado campo 1, fecha acreditado campo 2, fecha acreditado campo 8.

La empresa necesita realizar una serie de controles tanto a los inspectores, ofertas e informes, estos los realizará un supervisor, que como hemos visto antes es un empleado con funciones de supervisor.

De la supervisión de inspectores nos interesa tener tres informes a final de cada año de cada campo en el que esta acreditado, y se registrarán los siguientes datos, código para la supervisión, código supervisor, inspector, código del informe, campo y fecha supervisión. Si se da el caso de que el inspector tiene menos de 3 informes en un año de un campo, el inspector se suspende de ese campo, tenemos de guardar código para la supervisión, inspector, fecha suspensión, campo. El inspector no puede recuperar la acreditación hasta que no aporte 3 inspecciones en un año.

De la supervisión de ofertas, se da un código de supervisión de oferta, código oferta, fecha supervisión, código supervisor, verificacion1, verificacion2, verificacion3, verificación n.

De la supervisión de informes, se da un código de supervisión de informe, código informe, fecha supervisión, código supervisor, verificacion1, verificacion2, verificacion3, verificación n.

El informe será enviado al cliente, se guardará la fecha de envío, junto con la factura, en esta constará, el número de factura, fecha factura, cliente(nombre, calle, numero, ciudad, codigo postal, teléfono, fax, cif, provincia), el tipo de item(camión, grúa….) a inspeccionar, la normativa(vehículos, grúas..) que le es de aplicación, el tipo de inspección(periódica, inicial o voluntaria) y la cantidad de ítems a inspeccionar.

Los campos marcados en rojo se insertará en un texto, a modo de descripción.


ENTIDADES

Empleados
Cliente
Oferta
Tipo de item
Normativa
Tipo de inspección
Equipos
Item1
Item2
Item3
Item n
Supervision inspectores
Supervision ofertas
Supervisión informes
Acreditaciones
suspensiones
defectos item 1
defetos item 2
defectos item n

[enla]

Una de las mejores herramientas que he podido usar es Erwin y ahora soporta MYSQL se encuentra actualmente en la versión 7.3, con respecto al modelado lo puedes encontrar aqui varios ejemplos

Código:

 http://www.databaseanswers.org/data_models/

dependera del rubro que necesites.

[tortiman]

Gracias por la pagina Enla, es muy interesante y con muchisimos ejemplos, ¿cual crees que es el que mejor se adapta a mi problema?, te lo pregunto porque ando escaso de tiempo y si lo sabes me harias un favor. Un saludo.

[enla]

Bueno, tendria que saber el rubro de tu empresa (define a que se dedica en una o dos palabras, por ejemplo, venta de carros, tecnico pc, taller de auto) la página es solo una idea de como lo vas hacer, porque hay muchas cosas que faltan y lo que se viene en tu realidad...

Código:

http://www.databaseanswers.org/data_models/car_svc_center/index.htm

Como te dije anteriormente, mira cual es tu rubro, lo traduces al ingles y de ahi lo buscas.

Suerte en tu busqueda

[tortiman]

Iniciado por enla

Bueno, tendria que saber el rubro de tu empresa (define a que se dedica en una o dos palabras, por ejemplo, venta de carros, tecnico pc, taller de auto) la página es solo una idea de como lo vas hacer, porque hay muchas cosas que faltan y lo que se viene en tu realidad...

Código:

http://www.databaseanswers.org/data_models/car_svc_center/index.htm

Como te dije anteriormente, mira cual es tu rubro, lo traduces al ingles y de ahi lo buscas.

Suerte en tu busqueda

La empresa se dedica a la inspección industrial, como indico en el ejemplo, la empresa se dedica a la inspeccion de items, pudiendo ser un item una caldera, un ascensor, un vehiculo, una grua, un transformador,......, o sea cualquier cosa sujeta a inspección.

[tortiman]

Hola gnzsoloyo, he estado dandole vueltas a tus indicaciones pero hay cosas que no entiendo y hay otras que has pasado por alto, seguro porque soy novato en el tema. Te las indico en azul para ver si me las puedes aclarar. Un saludo.

Bien, una manito...

Hoy le dí una leída más detallada y como ejercicio de la facultad es bastante complejo para desarrollar un modelo de datos. Hay muchos detalles que se infieren pero que no aparecen en la descripción, pero pertenecen al sistema.

Por suerte no hay mucha información-basura, cosa habitual en los TP. Han sido bastante piadosos (vieras las barbaridades que he tenido que resolver). Aún así, siendo tan largo, voy a tratar al menos de decirte algunas cosas:

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.

2) Cliente compone una tabla separada. No está categorizado.

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.

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.

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.


6) Se infiere la existencia de una tabla HerramientaUsada y otra Herramienta, la primera de las cuales está relacionada con Orden_Inspeccion y determina qué herramientas está retirando el Inspector para su trabajo.

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

8) Existe una tabla Supervisiones_Inspector, relacionada con Supervisor e Inspector.

9) Se infiere la existencia de una tabla Acreditaciones_Inspector que se relaciona con Inspector.

10) Existe una tabla Suspension_Inspector, relacionada con Acreditaciones_Inspector, Supervisor e Inspector.

No queda claro de qué depende la periodicidad de las inspecciones, si de la normativa vigente o de la decisión del cliente. En un caso, el período está indicado en la normativa.; en el segundo puede estar en el ReporteInspeccion, el cual se puede usar de referencia para obtener el listado de inspecciones futuras a realizar.
La periodicidad depende de la normativa y si, en el ReporteInspeccion esta la fecha para obtener el listado de futuras inspecciones

Se puede llegar a inferir que exista algún tipo de entidades que defina la relación entre el cliente y la empresa. Eso puede dar lugar a Contrato, CuentaCorreinte o muchas otras más, pero en este punto no componen parte del sistema relevado.

Esto sería, más o menos a vuelo de pájaro, lo que se puede sacar del relevamiento que estás posteando.
Puede haber mucha información faltante y muchas tablas más que sean necesarias para el funcionamiento del sistema (los listados de ciudades, provincias, países, categorizaciones varias y muchas otras cosas se suelen poner como tablas fijas para evitar que los usuarios deban escribir -mal muchas veces- ciertos datos críticos).
Pero creo que por ahora alcanza para ver algo de la transformación de un relevamiento en modelo de datos.

Espero que te sirva.

[gnzsoloyo]

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.

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.

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.

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.

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...