Estoy de acuerdo con quimfv, el modelo es en principio correcto. Posiblemewnte esta tabla sea bastante más optimizable:
Código sql:
Ver originalCREATE TABLE inscripciones (
idInscripcion INT NOT NULL AUTO_INCREMENT,
nombre VARCHAR(40) NOT NULL,
apellidos VARCHAR(40) NOT NULL,
fnacimiento DATE,
dni VARCHAR(20),
direccion VARCHAR(90) NOT NULL,
poblacion VARCHAR(40) NOT NULL,
cpostal VARCHAR(10) NOT NULL,
provincia VARCHAR(20) NOT NULL,
tel_particular VARCHAR(10) NOT NULL,
mov_particular VARCHAR(10) NOT NULL,
ema_particular VARCHAR(50) NOT NULL,
tel_profesional VARCHAR(10),
mov_profesional VARCHAR(10),
ema_profesional VARCHAR(50),
fax VARCHAR(15),
nos_conocio VARCHAR(150) NOT NULL,
pref_tel_particular CHAR(1) DEFAULT '0',
pref_tel_profesional CHAR(1) DEFAULT '0',
pref_ema_particular CHAR(1) DEFAULT '0',
pref_ema_profesional CHAR(1) DEFAULT '0',
idioma VARCHAR(2) DEFAULT 'es',
PRIMARY KEY(idInscripcion));
Sobre la base de la normalización, hay al menos dos tablas desprendiéndose de ella, como es el caso de los teléfonos, que en mi opinión deberían ir en otra tabla, unificando los profesionales, particulares y comerciales en una sola con un campo para distingir tipo. Además, poner los prefijos en otro campo no resulta funcional, ya que conceptualmente es parte del mismo número y no se debe hacer una atomización tan detallada.