A ver, me preguntas si esto está bien:

PERSONA(dni,numatri,dirección,telf1,telf2,ctacorriente,relación)

Pues no, no está bien. Esta tabla no está en segunda forma normal. Tenemos que el dni determina la dirección, los teléfonos y la cuenta corriente (hay atributos que dependen de un subconjunto de la clave primaria). Igual se entiende mejor eso de "que determina", "que dependen" con un ejemplo:

Imagina que yo tengo dos hijas en esta guardería y por lo tanto, salgo dos veces en esta tabla en dos filas distintas. Para que no haya faltas de integridad, en las dos filas en donde está mi dni debe salir la misma dirección, los mismos teléfonos y la misma cuenta ¿no? Bueno, pues eso que digo "debe salir" es la noción de "dependencia funcional". Si mis datos están guardados más de una vez, corren el riesgo de que en un momento dado, se cambien en un sitio y no en el otro. Por ejemplo, comunico a la guardería mi cambio de domicilio y lo cambian en la fila de mi hija pequeña y no en la de mi hija mayor. Ya tenemos una falta de integridad: ¿cuál es el domicilio correcto?

Si evitamos las redundancias de datos en nuestra base de datos, evitaremos estos riesgos. Por eso exigimos diseños en donde las tablas estén en tercera forma normal, es decir, sin redundancias de datos.

Desde luego hay otras formas de evitar que se produzcan estos problemas, como puede ser no permitiendo que una persona tenga más de un niño en la guardería, pero eso haría que bajara más el índice de natalidad.

EJERCICIO 16: Si en lugar de crear la tabla CUOTA con los atributos tipo e importe, éstos se introducen como parte de la tabla SOCIO como 'cuota_tipo' y 'cuota_importe', ¿es correcto?

Estamos en las mismas, pero esta vez violas la tercera forma normal. La dependencia funcional que tenemos ahora es entre atributos no clave: todos los socios que tengan el mismo tipo de cuota deben pagar lo mismo. Con la solución que propones, si en un momento dado, tenemos dos socios con un mismo tipo de cuota y distinto importe ¿cuál es el importe que corresponde a ese tipo de socio? Ya no lo sabemos.

Si dejamos la tabla CUOTA como está en la solución del ejercicio, cada socio tiene anotado en su fila el tipo al que corresponde y el importe se sabe yendo a CUOTA con un join. Si se decide cambiar el importe de algún tipo de socio, sólo hay que cambiar el importe que aparece en la fila de la tabla CUOTA que tiene ese tipo. A partir de ese momento todos los socios de ese tipo tienen el nuevo importe.

Luego vamos al mundo al real y nos encontramos que va y resulta que sale caro hacer el join (caro en tiempo de espera del usuario) y que hay que desnormalizar las tablas. Bueno, pues se desnormaliza, pero así: sigue existiendo la tabla CUOTA y cuando a un socio se le asigna un tipo también se copia en su fila el importe que pagará, PERO en los formularios que hagamos para los usuarios (este es el precio que pagamos por desnormalizar, el hacer más faena en las aplicaciones) no permitiremos que el usuario
pueda entrar al campo importe de los datos del socio y ese campo tomará valor automáticamente de CUOTA.importe cuando se escoja el tipo de socio.

La cuestión es que al diseñar, debemos llegar a la tercera forma normal, de modo que nos aseguremos que no quedan redundancias de datos. Luego, por cuestiones
de eficiencia, es posible que tengamos que desnormalizar. Desnormalizar implica introducir redundancias e introducir en las aplicaciones todos los controles necesarios para que éstas no traigan problemas. Pero bueno, siempre puede venir otra persona, hacer una aplicación nueva, no controlar las redundancias y  por lo tanto, abrir la puerta a las faltas de integridad, cosa que no pasará si nuestra base de datos está en tercera forma normal.

En una jerarquia (t,e), si una de las entidades hijo no tiene atributos (que no sean los del padre), ADMINISTRATIVO  en este caso, ¿no se introduciría una tabla ADMINISTRATIVO con la clave primaria del padre como único atributo?

Siguiendo a rajatabla lo que dice la teoría, sí. En este ejercicio no hemos puesto esa tabla porque no aporta información y sólo da más faena al hacer cualquie tipo de operación sobre la base de datos (consultas, inserciones, etc.).

Y en el caso de poderse hacer de este modo, ¿seria necesario el atributo 'tipo' de la tabla VOLUNTARIO?

Juzga tú mismo. Veamos la consulta SQL que saca los datos de los voluntarios administrativos en cada caso.

Caso 1: como está en la solución del boletín:
        SELECT *
        FROM   voluntario
        WHERE  tipo='administrativo';

Caso 2: como tú sugieres, eliminamos el atributo tipo y ponemos la tabla ADMINISTRATIVO con una sola columna, el dni del voluntario.
        SELECT v.*
        FROM   administrativo a, voluntario v
        WHERE  a.dni = v.dni;

Parece que en el segundo caso hacemos más trabajo porque accedemos a dos tablas haciendo un join ¿no?

--> En la solucion del examen de septiembre de 2001 no esta asi (PARTICIPANTE --> JUGADOR / ARBRITO)

Tienes razón, se nos debió escapar al resolverlo.  Siempre que tengas una jerarquía y decidas representarla con una tabla para la entidad padre y una tabla para cada hijo, debes añadir el atributo tipo porque te ayuda a ser un poco más fiel al concepto de jerarquía, ya que con las tablas se pierde (pero con la orientación a objetos no y cada vez más SGBD son objeto-relacionales).

En el ejercicio 1 del boletín de diseño logico de bases de datos ¿cuáles son las perguntas que se hacen para decidir si las claves ajenas ASUNTO_PROC.numexp y ASUNTO_PROC.dniproc aceptan nulos? Es que no entiendo porque no son 'Sí'.
 

Bueno, pues no pueden ser sí nunca en la vida, porque ambas están formando la clave primaria y hay una regla de integridad que se llama "regla de integridad de entidades" que dice que ningún componente de la clave primaria puede ser nulo.

Por otra parte, recuerda que siempre que utilizamos una tabla a parte para representar una relación, las claves ajenas a las tablas de las entidades participantes en la relación NO aceptan nulos porque esa tabla está representando ocurrencias de la relación. La pregunta 2.3 de las preguntas y respuestas de diseño de bases de datos explica bastante bien :) este caso. Echa un vistazo.

En el examen de febrero del 2001, para la jeraquia Proyecto (t,e), se ha creado una tabla por cada entidad. Mi pregunta es: ¿se podria utilizar la jerarquia: "integrar todas las entidades en una tabla"? Ya que LARGO y CORTO no tienen atributos. Yo lo he puesto de esta forma, refiriendome a la pregunta 20 de dicho examen:

         PROYECTO(numero, fecha_inicio, fecha_fin, estado, importe_tot, tipo)
                 donde PROYECTO.tipo toma valores en {'largo','corto'}

Sí, es correcto. La diferencia es que cuando tienes en cuenta la relación "revisión", debes hacer respetar una regla de integridad adicional: en la tabla REVISION, la clave ajena "número" sólo puede hacer referencia a proyectos de tipo 'largo'.