Grupo de Estructuras de Datos

1. Grupo de Estructuras de Datos

2. DISEÑO RELACIONALDiseño Lógico Relacional

3. Traducción de un Diagrama E/R a una definición de Base de Datos Relacional ENTIDADES REGULARES • Cada tipo de entidad regular corresponde a una relación base. Por lo tanto, la base de datos incluirá cinco relaciones base: • DEPTO. • EMP. • S. • P. • J. correspondientes a las entidades regulares departamento, empleado, proveedor, parte y proyecto.

4. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M PROY_TRABAJO NOMPILA M PROV_PARTE M PROV_ PARTE_PROY M M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 PROY_GERENTE M MATERNO M EMP_DEPEN M SALARIO CANT PARTE M M EXP IMP ESTRUCTURA DE PARTE M DEPENDIENTE QTY Traducción de un Diagrama E/R a una definición de Base de Datos Relacional

5. Entidades Regulares • Por supuesto, cada una de estas relaciones base tendrá una clave primaria: • NUMDEPTO. • NUMEMP. • S#. • P#. • J#. correspondientes a las propiedades clave identificadas en el diagrama E/R.

6. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M PROY_TRABAJO NOMPILA M PROV_PARTE M PROV_ PARTE_PROY M M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 PROY_GERENTE M MATERNO M EMP_DEPEN M SALARIO CANT PARTE M M EXP IMP ESTRUCTURA DE PARTE M DEPENDIENTE QTY Entidades Regulares

7. Entidades Regulares • Estos hechos pueden documentarse escribiendo un conjunto apropiado de sentencias de definición de datos de SQL. • Esta sugerencia de utilizar SQL (o un pseudoSQL) para registrar las decisiones de diseño no indica que sea la única forma de realizarlo, pero el formalismo alternativo que se utilice deberá ser equivalente en lo funcional. Por ejemplo, esta sería la proposición para la relación DEPTO (a grandes rasgos): create table DEPTO (NUMDEPTO . . . , . . . , ) primary key (NUMDEPTO)

8. Interrelaciones de Muchos a Muchos • Las que aparecen en el ejemplo (binarias o no), son las siguientes: • PROY_TRABAJO. • PROV_PARTE. • PROV_PARTE_PROY. • ESTRUCTURA DE PARTE. • Cada una de ellas se corresponde con una relación base. Por ello, se introducen otras cuatro relaciones base. Por ejemplo, para la interrelación PROV_PARTE puede ser la relación base SP. Dejando a un lado por el momento la cuestión de la clave primaria de esta relación podemos centrarnos en el asunto de las claves ajenas, ya que son necesarias para identificar a los participantes de la interrelación.

9. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M PROY_TRABAJO NOMPILA M PROV_PARTE M PROV_ PARTE_PROY M M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 PROY_GERENTE M MATERNO M EMP_DEPEN M SALARIO CANT PARTE M M EXP IMP ESTRUCTURA DE PARTE M DEPENDIENTE QTY Interrelaciones de Muchos a Muchos

10. Interrelaciones de Muchos a Muchos create table SP (S# . . . , P# . . . , . . . ) foreign key (S#) references S foreign key (P#) references P • Es evidente que la relación SPdebe incluir 2 claves ajenas: S# y P#, correspondientes a los 2 participantes:proveedores y partes y por ello hacen referencia a las relaciones participantesS y P. • Además, es preciso especificar un conjunto apropiado de reglas para cada clave ajena.

11. Reglas para Claves Ajenas • Es importante darse cuenta que la regla de integridad referencial se formula en términos de estados de la base de datos. La base de datos no debe contener valores no nulos de claves ajenas para los cuales no exista un valor concordante de la clave primaria en la relación objetivo pertinente. • Cualquier estado de la base de datos que no satisfaga la regla será incorrecto por definición, pero ¿cómo evitar esos estados incorrectos? La regla en si no lo dice. • Una posibilidad es que el sistema rechace cualquier operación que produzca estados ilegales.

12. Reglas para Claves Ajenas • Una alternativa preferible en algunos casos será que el sistema: • Acepte la operación. • En caso necesario, realice operaciones compensatorias que garanticen un estado legal como resultado final. Por ejemplo, si el usuario solicita eliminar el proveedor S1 de la relación S, también debería ser posible hacer que el sistema también elimine de la relación SP las referencias a dicho proveedor sin necesidad de acciones adicionales por parte del usuario. Todo ello suponiendo que el efecto de eliminación en cascada constituye lo deseado. • En consecuencia, para cualquier base de datos, el diseñador podrá especificar: • Qué operaciones habrán de rechazarse. • Cuáles habrán de aceptarse. • Qué operaciones de compensación habrá de realizar el sistema.

13. Reglas para Claves Ajenas • La línea fundamental es que, para cada clave ajena, será necesario responder a tres pregutas: • ¿Puede aceptar nulos esa clave ajena? • ¿Qué deberá suceder si hay un intento de eliminar el objetivo de una referencia de clave ajena? • ¿Qué deberá suceder si hay un intento de modificar la clave primaria del objetivo de una referencia de clave ajena?

14. Aceptación de Nulos en Claves Ajenas PREGUNTA ¿PUEDE ACEPTAR NULOS ESA CLAVE AJENA? • Por ejemplo: ¿Tiene sentido la existencia de una oferta cuyo proveedor se desconoce? En este caso concreto es de suponer que la respuesta será no, pero en otros podría ser diferente. • En el caso de empleados y departamentos, podría existir un empleado que, momentáneamente, no estuviera asignado a ningún departamento. • Obsérvese de paso que la respuesta a la pregunta no depende del capricho del diseñador, sino que es consecuencia de las políticas vigentes en la porción del mundo real que se intenta representar. Por supuesto que este mismo comentario puede hacerse sobre las siguientes preguntas.

15. Eliminación de Referenciados PREGUNTA ¿QUÉ DEBERÁ SUCEDER SI HAY UN INTENTO DE ELIMINAR EL OBJETIVO DE UNA REFERENCIA DE CLAVE AJENA? • Por ejemplo: Un intento de eliminar un proveedor del cual existe por lo menos una oferta. • Considerando este caso de forma explícita, existen al menos tres posibilidades: • RESTRICCIÓN: La operación está restringida al caso en que no existen tales ofertas y se rechaza en caso contrario. • PROPAGACIÓN: La operación se propaga en cascada, eliminando también las ofertas correspondientes. • ANULACIÓN: Se asignan nulos a la clave ajena en todas las ofertas implicadas y a continuación se elimina el proveedor. Por supuesto, este caso no es aplicable si la clave ajena no puede aceptar nulos.

16. Modificación de la Clave Primaria Referenciada PREGUNTA ¿QUÉ DEBERÁ SUCEDER SI HAY UN INTENTO DE MODIFICAR LA CLAVE PRIMARIA DEL OBJETIVO DE UNA REFERENCIA DE CLAVE AJENA? • Por ejemplo: Un intento de modificar el número de un proveedor del cual existe por lo menos una oferta. • Considerando este caso de forma explícita, existen al menos las mismas tres posibilidades que en el caso de la eliminación: • RESTRICCIÓN: La operación está restringida al caso en que no existen tales ofertas y se rechaza en caso contrario. • PROPAGACIÓN: La operación se propaga en cascada, modificando también la clave ajena de las ofertas correspondientes. • ANULACIÓN: Se asignan nulos a la clave ajena en todas las ofertas implicadas y a continuación se modifica el número del proveedor. Por supuesto, este caso no es aplicable si la clave ajena no puede aceptar nulos.

17. Ejemplos de Interrelaciones Muchos a Muchos • Volviendo al ejemplo de la interrelación muchos a muchos PROV_PARTE representada por la tabla SP, ahora se pueden especificar sus reglas para claves ajenas. Adviértase que las reglas en cuestión: • Son solo una posibilidad. • No las fija el diagrama E/R. create table SP (S# . . . , P# . . . , . . . ) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades

18. Ejemplos de Interrelaciones Muchos a Muchos create table SP (S# . . . , P# . . . , . . . ) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades • Las referencias a ambos participantes en la interrelación muchos a muchos presentan las mismas reglas de claves ajenas: • No permiten las referencias a partes o proveedores desconocidos, dado que ello implicaría la existencia de ofertas de las cuales no se conocería su proveedor o la parte. • Se impide la eliminación de un proveedor o una parte que estén referenciados en la interrelación. Mientras existan ofertas correspondientes no deben eliminarse ni el proveedor ni la parte implicada.

19. Ejemplos de Interrelaciones Muchos a Muchos create table SP (S# . . . , P# . . . , . . . ) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades • Se permite la actualización de la clave de las entidades participantes, de forma que será factible reflejar, por ejemplo, el cambio del código identificativo de un proveedor, reflejándose este cambio adecuadamente en la interrelación.

20. Ejemplos de Interrelaciones Muchos a Muchos • ¿Qué sucede con la clave primaria de la relación que representa a la interrelación muchos a muchos. • La combinación de las claves ajenas que identifican a los participantes siempre ofrecerá: • Unicidad: no puede existir mas de una ocurrencia de las misma interrelación que asocie a los mismos participantes • y no nulidad: el grado de la interrelación es el mismo para todas sus ocurrencias En el ejemplo de la relación SP, sería la combinación (S# , P#). • Otra posibilidad sería introducir un nuevo atributo, no compuesto, que funcione como clave primaria de la interrelación. Por ejemplo, número de oferta. • El diseñador de la base de datos puede tener objeciones con respecto a las claves primarias compuestas (el grado de la interrelación puede ser alto).

21. Ejemplos de Interrelaciones Muchos a Muchos • A efectos del ejemplo podríamos decidirnos por la primera opción, añadiendo a la proposición create table la cláusula primary key (S# , P#). create table SP (S# . . . , P# . . . , . . . ) primary key (S# , P#) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades

22. Ejemplos de Interrelaciones Muchos a Muchos • En lo que respecta a la interrelación PROY_TRABAJO: • Suponiendo que las relaciones EMP y J representan a las entidades participantes empleado y proyecto, respectivamente. • Suponiendo que las claves primarias de ambas relaciones son, respectivamente, NUMEMP y J#. Se puede representar esta interrelación con una relación base JEMP con la siguiente definición: create table JEMP (NUMEMP . . . , J# . . . , . . . ) primary key (NUMEMP , J#) foreign key (NUMEMP) references EMP nulls . . . delete of EMP . . . update of EMP.NUMEMP . . . foreign key (J#) references J nulls . . . delete of J . . . update of J.J# . . .

23. Ejemplos de Interrelaciones Muchos a Muchos • En este caso siguen estando impedidos los valores nulos de las claves ajenas. • Igualmente, se propagan las actualizaciones de los códigos que actúan como claves primarias de las relaciones que representan a las entidades participantes. • La novedad aquí consiste en relajar la restricción de las eliminaciones de participantes, ya que se puede establecer que la eliminación de, por ejemplo, un empleado, debe aceptarse y propagarse automáticamente a todas sus implicaciones de la empresa. create table JEMP (NUMEMP . . . , J# . . . , . . . ) primary key (NUMEMP , J#) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP cascades update of EMP.NUMEMP cascades foreign key (J#) references J nulls not allowed delete of J cascades update of J.J# cascades

24. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M M PROY_TRABAJO NOMPILA M M PROV_PARTE PROV_ PARTE_PROY M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 M PROY_GERENTE MATERNO M M SALARIO EMP_DEPEN CANT PARTE M M EXP IMP M ESTRUCTURA DE PARTE DEPENDIENTE QTY Ejemplos de Interrelaciones Muchos a Muchos • En la interrelación estructura_de_parte aparece la misma entidad (parte) participando doblemente. • Se puede representar con una relación PP con dos claves ajenas a EP# e IP#, que referencian ambas a las partes en sus facetas de explosión de partes e implosión de partes, respectivamente.

25. Ejemplos de Interrelaciones Muchos a Muchos • La clave primaria de la relación PP puede ser la combinación (EP# , IP#). • La definición de la relación PP podría expresarse como se indica en la tabla siguiente. • Se pueden aplicar aquí comentarios similares a los de los ejemplos anteriores, referentes a las reglas de nulos y actualización. • Nótese sin embargo, como parece lógico pensar, que no es admisible la eliminación sin más de una parte que puede ser componente de otras. • Mientras que al eliminar una parte no hay inconveniente en borrar su descomposición. create table PP (EP# . . . , IP# . . . , . . . ) primary key (EP# , IP#) foreign key (EP#) references P nulls not allowed delete of P cascades update of P.P# cascades foreign key (IP#) references P nulls not allowed delete of P restricted update of P.P# cascades

26. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M M PROY_TRABAJO NOMPILA M M PROV_PARTE PROV_ PARTE_PROY M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 M PROY_GERENTE MATERNO M M SALARIO EMP_DEPEN CANT PARTE M M EXP IMP M ESTRUCTURA DE PARTE DEPENDIENTE QTY Ejemplos de Interrelaciones Muchos a Muchos • En la interrelación prov_parte_proy aparecen tres participantes y podemos representarla con la relación SPJ. • Obviamente, los comentarios sobre la clave primaria de SPJ son similares a todos los anteriores. • Aparecerán tres claves ajenas: S#, P#, J#, que referencian a proveedores, partes y proyectos, respectivamente.

27. Ejemplos de Interrelaciones Muchos a Muchos create table SPJ (S# . . . , P# . . . , J# . . . , . . . ) primary key (S# , P# , J#) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades foreign key (J#) references J nulls not allowed delete of J cascades update of J.J# cascades • Debe imposibilitarse la desaparición (sin más tramite) de los proveedores y de las partes que estén participando en un proyecto. Al menos se puede pensar que habrán de ser sustituidos/das por otros/as de similares características. Por ello la regla de eliminaciones de los proveedores y la de las partes están restringidas.

28. Ejemplos de Interrelaciones Muchos a Muchos create table SPJ (S# . . . , P# . . . , J# . . . , . . . ) primary key (S# , P# , J#) foreign key (S#) references S nulls not allowed delete of S restricted update of S.S# cascades foreign key (P#) references P nulls not allowed delete of P restricted update of P.P# cascades foreign key (J#) references J nulls not allowed delete of J cascades update of J.J# cascades • Sin embargo, la eliminación de un proyecto debe aceptarse, propagándose este eliminación a todos los participantes en el mismo. Por ello, la regla de eliminación para los proyectos aparece relajada, de forma que se propaga. • Por último, a las reglas de actualización de las claves primarias de las relaciones que representan a los participantes se le aplican, en este caso, similares comentarios que en los anteriores.

29. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M M PROY_TRABAJO NOMPILA M M PROV_PARTE PROV_ PARTE_PROY M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 M PROY_GERENTE MATERNO M M SALARIO EMP_DEPEN CANT PARTE M M EXP IMP M ESTRUCTURA DE PARTE DEPENDIENTE QTY Ejemplos de Interrelaciones Muchos a Uno • En el ejemplo existen tres interrelaciones de este tipo: • PROY_GERENTE: Los proyectos designan a los gerentes. • DEPTO_EMP: Los empleados designan a los departamentos. • EMP_DEPEN: Los dependientes designan a los empleados. • La última implica un tipo de entidad débil, dependiente. • Las otras dos implican solo tipos de entidades regulares.

30. Interrelaciones Muchos a Uno • Estas interrelaciones no provocan la introducción de nuevas relaciones. • En su lugar, basta con introducir una clave ajena en la relación correspondiente al lado de muchos en la interrelación que haga referencia a la relación del lado de uno. • De esta forma, en el caso de la interrelación DEPTO_EMP: create table EMP (NUMEMP . . . , NUMDEPTO . . . , . . . ) primary key (NUMEMP) foreign key (NUMDEPTO) references DEPTO nulls not allowed delete of DEPTO restricted update of DEPTO.NUMDEPTO cascades Bajo la suposición de que no podremos eliminar un departamento que tenga asignado empleados,necesitándose reasignar previamente los empleados a otro departamento para, a continuación, proceder a la eliminación.

31. Interrelaciones Muchos a Uno • Aunque también podrían eliminarse los empleados de un departamento al desaparecer este (regla de eliminación en cascada en lugar de restringida)si así lo establece la política de la empresa: create table EMP (NUMEMP . . . , NUMDEPTO . . . , . . . ) primary key (NUMEMP) foreign key (NUMDEPTO) references DEPTO nulls not allowed delete of DEPTO cascades update of DEPTO.NUMDEPTO cascades • En cualquiera de los dos casos representaremos fielmente la participación total de EMPLEADO en la relación DPTO_EMP.

32. Ejemplos de Interrelaciones Muchos a Uno create table EMP (NUMEP . . . , NUMDEPTO . . . , . . . ) primary key (NUMEMP) foreign key (NUMDEPTO) references DEPTO nulls allowed delete of DEPTO nullifies update of DEPTO.NUMDEPTO cascades • En este caso sería válido si la participación de EMPLEADO en DPTO_EMP fuese parcial. • Para un empleado podría desconocerse (al menos temporalmente) cuál es su departamento. Por ejemplo, durante un proceso de reestructuración de la empresa en el que desaparecen algunos departamentos. Por ello, pueden ser lógicos los valores que representan sus reglas de nulos y de eliminación.

33. Ejemplos de Interrelaciones Muchos a Uno • La interrelación PROY_GERENTE se representa incluyendo en la relación J (que representa a los proyectos) la clave ajena NUMEMP (que referencia al empleado que actúa como gerente del proyecto: create table J (J# . . . , NUMEMP . . . , . . . ) primary key (J#) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP restricted update of EMP.NUMEMP cascades

34. Ejemplos de Interrelaciones Muchos a Uno create table J (J# . . . , NUMEMP . . . , . . . ) primary key (J#) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP restricted update of EMP.NUMEMP cascades • Es obvio que, en este caso, pueden comentarse las reglas para claves ajenas de forma parecida a las del ejemplo anterior: • La restricción parece apropiada dado que no es lógico pensar que la eliminación de un gerente cause la desaparición del proyecto que maneja. • La anulación está contraindicadapor la participación total dePROYECTO en PROY_GERENTE. Aunque quizás convendría redefinir dicha participación como parcial, dado que alguna reasignación de personal podría dejar a un proyecto sin gerente temporalmente.

35. Entidades Débiles • La interrelación entre un tipo de entidad débil y el tipo de entidad del cual depende es, por supuesto, una relación de muchos a uno. • Sus reglas para claves ajenas deben ser la siguientes nulls not allowed delete . . . cascades update . . . cascades • Estas tres reglas juntascapturan y reflejan la necesaria dependencia de existencia. Sirva como ejemplo la interrelación EMP_DEPEN.

36. S# SNOM SITUA CUIDAD DEPARTM 1 DPTO_EMP PROVEEDOR NUMEMP M PROY_TRABAJO NOMPILA M PROV_PARTE M PROV_ PARTE_PROY M M M PATERNO ENOMBRE EMPLEADO PROYECTO 1 1 PROY_GERENTE M MATERNO M EMP_DEPEN M SALARIO CANT PARTE M M EXP IMP ESTRUCTURA DE PARTE M DEPENDIENTE QTY Entidades Débiles

37. Ejemplo de Entidad Débil • Para representar la entidad débil DEPENDIENTE y la interrelación EMP_DEPEN: • Habrá que utilizar una relación base DEPENDIENTEe incluir, como clave ajena de esta relación, el atributo NUMEMP, que es la clave primaria de la entidad EMPLEADO y de la cual depende la existencia de DEPENDIENTE. create table DEPENDIENTE (NUMEMP . . . , NOMBRE_DEPEN . . . , . . . ) primary key ( . . . ) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP cascades update of EMP.NUMEMP cascades

38. Clave Primaria de las Entidades Débiles • Para la clave primaria: • Una posibilidad es tomar la combinación de la clave ajena y el discriminante de la entidad débil del diagrama E/R. Recuérdese que el discriminante de la entidad débil en el diagrama E/R proporciona unicidad tan solo en el contexto del caso de la entidad regular diferenciada. Esta posibilidad es la adecuada para el caso de dependencia en identificación. • Otra posibilidad sería contar con un atributo de la entidad débil que sirva como clave primaria de la misma. Caso que se produce cuando la dependencia solo es en existencia.

39. Ejemplo de Entidad Débil • En el ejemplo se ha elegido la primera posibilidad: create table dependiente (NUMEMP . . . , NOMBRE_DEPEN . . . , . . . ) primary key (NUMEMP, NOMBRE_DEPEN) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP cascades update of EMP.NUMEMP cascades bajo la suposición de que NOMBRE_DEPEN es el nombre del dependiente del empleado y que es el discriminante de la entidad dependiente en el diagrama E/R, existiendo por lo tanto dependencia en identificación.

40. Propiedades Multivaluadas • Cada propiedad mostrada en el diagrama E/R corresponde a un atributo de la relación pertinente, excepto que: • Si la propiedad es multivaluada, se crea una nueva relación para ellaa fin de respetar los principios básicos de normalización (1NF). Por ejemplo, si cada proveedor tuviese un número indeterminado de líneas telefónicas se consideraría que la propiedad teléfono es multivaluada. En tal caso, se añadiría una nueva relación STF: create table STF (S# . . . , TF# . . . ) primary key ( . . . ) foreign key (S#) references S nulls not allowed delete of S cascades update of S.S# cascades

41. Propiedades Multivaluadas create table STF (S# . . . , TF# . . . ) primary key ( . . . ) foreign key (S#) references S nulls not allowed delete of S cascades update of S.S# cascades • Nótese que las reglas de claves ajenas coinciden con las de las relaciones que representan a entidades débiles. • Sin embargo, en el caso de las propiedades multivaluadas, sólo aparecerán dos atributos en la relación: • La clave primaria de la relación que representa a la entidad a la que pertenece la propiedad multivaluada. • La propiedad multivaluada en si.

42. Propiedades Multivaluadas create table STF (S# . . . , TF# . . . , primary key (TF) foreign key (S#) references S nulls not allowed delete of S cascades update of S.S# cascades • En cuanto a la clave primaria de la relación STF, obsérvese que basta con el atributo TF. Ello se debe a sus características especiales de unicidad. • En otros tipos de propiedades multivaluadas, será necesario utilizar como clave primaria la combinación de los dos atributos de la relación.

43. EMPLEADO PROGRAMADOR PROGRAMADOR DE APLICACIONES PROGRAMADOR DE SISTEMAS Supertipos y Subtipos • Cada uno de los tipos de entidad mostrados en la figura corresponderá a una relación base. • Cada una de estas relaciones incluirá atributos correspondientes a las propiedades. • Aplicables a su posición dentro de la jerarquía de tipos y, por lo tanto, por herencia: a todas las posiciones subordinadas y a ninguna posición superior.

44. Supertipos y Subtipos • Para las relaciones EMP y PGMR, correspondientes a los tipos de entidad empleado y programador: create table EMP (NUMEMP . . . , NUMDEPTO . . . , SALARIO . . . , . . . ) primary key ( . . . ) . . . create table PGMR (NUMEMP . . . , LENG . . . , . . . ) primary key ( . . . ) . . . • El atributo LENG representa la propiedad lenguaje principal de programación, que sólo es aplicable a los empleados que son programadores. • El atributo SALARIO, por el contrario, representa a una propiedad que es aplicable a todos los empleados.

45. Supertipos y Subtipos • Las dos relaciones tienen la misma clave primaria: NUMEMP. • La clave primaria de la relación del subtipo programador funciona también como clave ajena y hace referencia a la clave primaria de la relación del supertipo empleado. create table EMP (NUMEMP . . . , NUMDEPTO . . . , SALARIO . . . , . . . ) primary key (NUMEMP) . . . create table PGMR (NUMEMP . . . , LENG . . . , . . . ) primary key (NUMEMP) foreign key (NUMEMP) references EMP nulls . . . allowed delete of EMP . . . update of EMP.NUMEMP . . .

46. Supertipos y Subtipos • Las reglas para claves ajenas que aparecen en la definición de la relación que representa al subtipo constituyen la forma lógica de representar la situación de jerarquía de tipos. • No deben permitirse los valores nulos ya que claramente deben ser rechazadas las representaciones de propiedades de un caso de subtipo sin conocer a qué caso del supertipo se está refiriendo. • Por otro lado, cualquier eliminación o actualización de la clave primaria del supertipo debe propagarse automáticamente a sus características como subtipo. create table PGMR (NUMEMP . . . , LENG . . . , . . . , ) primary key (NUMEMP) foreign key (NUMEMP) references EMP nulls not allowed delete of EMP cascades update of EMP.NUMEMP cascades

47. Supertipos y Subtipos • Las relaciones PGMR_APL y PGMR_SISrepresentan a los subtipos de programador: programador_de_aplicaciones y programador_de_sistemas. create table PGMR_APL (NUMEMP . . . , ATRIBUTO1 . . . , . . . , ) primary key (NUMEMP) foreign key (NUMEMP) references PGMR nulls not allowed delete of PGMR cascades update of PGMR.NUMEMP cascades • Los atributos ATRIBUTO1 y ATRIBUTO2representan a propiedades quesólo son aplicables a los programadores de aplicaciones o a los de sistemas, respectivamente. create table PGMR_SIS (NUMEMP . . . , ATRIBUTO2 . . . , . . . , ) primary key (NUMEMP) foreign key (NUMEMP) references PGMR nulls not allowed delete of PGMR cascades update of PGMR.NUMEMP cascades