Las subtablas en SQL se corresponden con la noción del modelo E-R
de la especialización y la generalización. Por ejemplo, supóngase que se define
la tabla personas de la manera siguiente:
create
table persona of Persona
Se pueden definir
entonces las tablas estudiantes y profesores como subtablas de
persona:
create
table estudiantes
of Estudiante under persona create table profesores of Profesor under persona
Los tipos de las subtablas deben ser subtipos del tipo de la tabla
padre. Por tanto, cada atributo presente en persona debe estar también
presente en las subtablas.
Además, cuando se declaran estudiantes y profesores como
subtablas de persona, cada tupla presente en estudiantes o profesores
también están presentes implícitamente en persona. Así, si una
consulta usa la tabla persona, encontrará no sólo las tuplas insertadas directamente en la tabla, sino también las tuplas insertadas en sus subtablas estudiantes
y profesores. Sin embargo, sólo se puede acceder a los atributos que
están presentes en persona.
Es posible
la herencia múltiple con las tablas, como con los tipos. Por ejemplo, se puede
crear una tabla del tipo Ayudante:
create table ayudantes of Ayudante under estudiantes, profesores
Como resultado de la declaración, cada tupla presente en la tabla ayudantes
también está presente implícitamente en las tablas profesores y estudiantes,
y a su vez en la tabla persona.
SQL permite buscar tuplas que estén en persona pero no en
sus subtablas usando «only persona» en lugar de persona en
la consulta.
Hay algunos requisitos de consistencia para las sub-tablas. Antes
de indicar las restricciones es necesaria una definición: se dice que las
tuplas de una subtabla corresponden a las tuplas de una tabla padre si
tienen los mismos valores para todos los atributos heredados. Así, las tuplas
correspondientes representan la misma entidad.
Los
requisitos de consistencia para las subtablas son:
1.
Cada
tupla de la supertabla puede corresponder a lo sumo con una tupla de cada una
de sus tablas inmediatas.
2. SQL tiene una restricción adicional
que establece que todas las tuplas que se correspondan se deben derivar de una
tupla (insertada en una tabla).
Por ejemplo, sin la primera condición se podrían tener dos tuplas
en estudiantes (o en profesores) correspondiente a la misma
persona.
La
segunda condición descarta una tupla en persona correspondiente a
tuplas de estudiantes estudiantes y profesores, a menos que esas
tuplas estén presentes implícitamente porque se insertó una tupla en la tabla ayudantes,
que es una subtabla de profesores y estudiantes.
Dado que algunos lenguajes no soportan herencia múltiple, la
segunda condición realmente impide que una persona sea tanto profesor como
estudiante. El mismo problema surgiría si no existiese la subtabla ayudantes,
incluso si hubiese herencia múltiple. Obviamente sería útil modelar una
situación donde una persona pueda ser profesor y estudiante, incluso si no está
presente la sub-tabla común ayudantes. Por tanto, puede ser útil eliminar
la segunda restricción de consistencia.
Las subtablas pueden
guardarse de manera eficiente sin réplica de todos los campos heredados de una
de las dos siguientes formas:
•
Cada tabla almacena la clave primaria (que se puede heredar de
una tabla padre) y los atributos definidos localmente. Los atributos heredados
(aparte de la clave primaria) no hace falta guardarlos y pueden obtenerse
mediante una reunión con la supertabla basada en la clave primaria.
•
Cada tabla almacena todos los atributos heredados y definidos
localmente. Cuando se inserta una tupla se almacena sólo en la tabla en la que
se inserta y su presencia se infiere en cada supertabla. El acceso a todos los
atributos de una tupla es más rápido, dado que no se requiere una reunión. Sin
embargo, en el caso de que no se considere la segunda restricción de integridad
—es decir, una entidad se puede representar en dos subtablas sin estar presente
en una subtabla común de ambas— esta representación puede resultar en
duplicación de información.
Referencias
Silberschatz,
A. (2002). Fundamentos de Bases de Datos. Madrid: McGrauHill, Pag 215-216.
No hay comentarios.:
Publicar un comentario