Tipos de datos  complejos

Los elementos de datos básicos son registros bastantes pequeños y cuyos campos son atómicos,  es decir, no contienen estructuras adicionales y en los que se cumple la primera forma normal.

Con sistemas de tipos complejos se pueden representar directamente conceptos del modelo E-R como los atributos compuestos, los atributos multivalorados, la generalización y la especialización, sin necesidad de una compleja traducción al modelo relacional.

La posibilidad de usar tipos de datos complejos como los conjuntos y los arrays puede resultar útil en muchas aplicaciones, pero se debe usar con cuidado.

Tipos estructurados y herencia en SQL

Un sistema de tipos extenso a SQL, lo lo que permite los tipos estructurados y la herencia de tipos.

·         Tipos estructurados

Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, de las tablas anteriores se puede definir el siguiente tipo estructurado para representar el atributo compuesto nombre con los atributos componentes nombredepila y apellidos:

create type Nombre as

(nombredepila varchar(20)

apellidos varchar(20)

final

las especificaciones final y not final están relacionadas con las subtipificación. Se pueden usar esos tipos para crear atributos compuestos en las relaciones, con solo declarar que un atributo es de uno de estos tipos. Por ejemplo, se puede crear la tabla cliente de la manera siguiente:

                       

                                               create table cliente (

                                                           nombreNombre,

                                                           direccionDireccion,

                                                           fechaDeNacimiento date)

 

Se puede tener acceso a los componentes de los atributos compuestos usando la notación “punto”. Una manera alternativa de definir los atributos compuestos en SQL, es usar tipos de fila sin nombre.

 

Sobre los tipos estructurados se pueden definir métodos. Los métodos se declaran coo parte de la definición de los tipos de los tipos estructurados.

 

La clausula for indica el tipo al que se aplica el método, mientras que la palabra clave instante indica que el método se ejecuta sobre un ejemplar. La variable self hace referencia al ejemplar que se invoca el método. Se usan funciones constructoras para crear valores de los tipos estructurados. Las funciones con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado.

 

·         Herencia de tipos

Los métodos de los tipos estructurados se heredan por sus subtipos, igual que los atributos. Sin embargo, cada subtipo puede redefinir el efecto de los métodos volviendo a declararlos, usando overriding method en lugar de method en la declaración del método.

 

SQL solo soporta la herencia simple, es decir, cada tipo solo se puede heredar de un único tipo. La herencia múltiple no esta soportado en SQL, el valor de un tipo estructurado debe tener exactamente un “tipo mas concreto”. Cada valor debe asociarse, al crearlo, con un tipo concreto, denominado su tipo mas concreto.

 

Por ejemplo en un a base de datos información adicional sobre las personas que son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores también son personas se usar la herencia para definir en SQL los tipos estudiantes y profesor.

 

create type Estudiante

            under Persona

            (grado varchar(20)

departamento varchar(20)

create type Profesor

            under Persona

            (sueldo integer,

departamento varchar(20)

 

 Herencia de tablas

 

Las subtablas de SQL se corresponden con el concepto de especialización/generalización de E-R.

Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Todos los atributos presentes también están presentes en las subtablas. La palabra clave only también puede usarse en las sentencias delete y update. Sin la palabra clave only, la instrucción delete aplicada a una supertabla, también borra las tuplas que se insertaron originalmente en las subtablas.

La herencia multiple es posible con las tablas, igual que con los tipos. Por ejemplo, se puede crear una tabla del tipo ProfesorAyudante:

                                   create table profesores_ayudantes

                                   of ProfesorAyudante

                                                under  estudiantes, profesores

 

se dice que las tuplas de una subtabla se corresponden con las tuplas de la tabla madre si tienen el mismo valor para todos los atributos heredados. Por tanto, las tuplas correspondientes representan a la misma entidad.

Los requisitos de consistencia de las subtablas son:

 

1.      Cada tupla de la super tabla puede corresponderse, como máximo con una tupla de cada una de sus subtablas inmediatas.

2.      SQL posee una restricción adicional que hace que todas las tuplas que se correspopnden entre si deben proceder de una tupla (insertada en una tabla)

 

Las subtablas de SQL no se pueden usar para representar las especializaciones que se solapen de los modelos E-R. Por supuesto, se pueden crear tablas diferentes para representar las especializaciones o generalizaciones que se solapen sin usar la herencia. SQL define un nuevo privilegio denominado under, en el cual es necesario para crear subtipos o subtablas bajo otro tipo o tabla la razón de ser de este privilegio es parecida a la del privilegio references.

 

Tipos de arreglo multiconjunto en SQL

 

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos. Multiconjuntos es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. A diferencia de los elementos de los multiconjuntos, los elementos de los arrays están ordenados

 

Por ejemplo se ilustra la manera en que se pueden definir en SQL, estos atributos valorados con arrays y multiconjuntos.

                                  

                                   create type Editor as

(nombre varchar(20)

sucursal vachar(20)

create type Libro as

(titulo vachar (20),

array_autores vachar (20) array[10],

fecha_publicacion date,

editor Editor,

conjunto_palabras_clave varchar(20) multiset)

create table

 

los atributos multivalorados de los esquemas E-R se pueden asignar en SQL atributos valorados como multiconjuntos si el orden es importante se pueden usar los arrays de SQL en lugar de los multiconjuntos.

  

·         Creación y acceso a los valores de los conjuntos

                             array[´silberschatz´,´Korth´, ´Sudarshan´]

de manera parecida se puede crear un multiconjunto de palabras clave de la manera siguiente:

                             multiset[´computadora´, ´base de datos´, ´SQL]

·         Consulta de los atributos valorados como conjuntos´

Ahora se considerara la forma de manejar los atributos que se valoran como conjuntos. Las expresiones que se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre de una relación, como las clausulas FROM.

 

Al desanidar un arrays la consulta anterior pierde información sobre el orden de los elementos de consulta. Se pueden usar las clausulas UNESTED WITH ORDINALITY para obtener esta información. La clausulas WITH ORDINALITY genera un atributo adicional que se registra la posición del elemento en el arrays. Se puede usra una consulta parecida. Pero sin la clausula WITH ORDINALITY, para generar la relación.

 

·         Anidamiento y desanidamiento

La transformación de una relación anidada en una forma con menos atributos de tipos relación (o sin ellos) se denomina desanidamiento.

UNIDAD 4 (Tareas)

 

·         Descomposición

Se sugiere descomponer los esquemas de relación que tienen muchos atributos en varios esquemas con menos atributos:

Esquema-sucursal-cliente = (nombre-sucursal, ciudad-sucursal, activo, nombre-cliente)

Empleando la relación empréstito se crean las nuevas relaciones sucursal-cliente (Esquema sucursal-cliente)

sucursal-cliente = Π nombre-sucursal, ciudad-sucursal, activo, nombre-cliente (empréstito)

En ocasiones existen casos en los que nos hace falta reconstruir las relaciones ya que se requiere hallar datos en los que ninguna relación de la base de datos contiene esos datos.

Cuando se tiene una pérdida de información, es decir, no se encuentra la información que se desea a esto se le llama descomposición con pérdida o una descomposición de reunión con perdida. y cuando la descomposición no es una descomposición con perdida se le conoce como descomposición de reunión sin perdida.

Un ejemplo de descomposición con pérdida cuando se tiene un atributo en común y al representarse de manera inadecuada al ver que no satisface lo que deseamos buscar se debe considerar otro diseño alternativo.

·         Propiedades deseables de la descomposición

Cuando se diseña una base de datos relacional puede hacerse necesaria la descomposición de una relación en varias relaciones de menor tamaño obteniendo propiedades deseadas.

Del esquema Esquema-empréstito exige que se cumpla:

nombre-sucursal → ciudad-sucursal activo

número-préstamo → importe nombre-sucursal

ü  Descomposición de reunión sin pérdida

Resulta fundamental que la descomposición sea una descomposición sin perdida al momento descomponer una relación en varias relaciones de menor tamaño. Se puede presentar un criterio antes para poder demostrar esta afirmación:

R= Esquema de relación.

F=Conjunto de dependencias funcionales de R.

R₁ y R₂= Descomposición de R.

Es una descomposición de reunión sin pérdida de R si al menos una de las siguientes dependencias se halla F^+:

R1 ∩ R2 → R1

R1 ∩ R2 → R2

ü  Conservación de las dependencias

Cuando se lleva a cabo la actualización de una base de datos el sistema debe poder comprobar que la actualización no crea ninguna relación ilegal, se deben diseñar unos esquemas de datos relacionales que permitan validar las actualizaciones sin que haga falta calcular las reuniones.

 

Para decidir si se necesita calcular las reuniones se tiene que determinar las dependencias funcionales las cuales se comprueban verificando cada relación una a una. Cuando las descomposiciones resulta que tienen propiedad F′+ = F+ son descomposiciones que conservan las dependencias:

calcular F+;

for each esquema Ri de E do

begin

Fi : = la restricción de F+ a Ri;

end

F′ := ∅

for each restricción Fi do

begin

F′ = F′ ∪ Fi

end

calcular F′+;

if (F′+ = F+) then return (true)

else return (false);

 

ü  Repetición de información

A veces es necesario repetir la información ya que en la descomposición se llega a separar los datos en relaciones diferentes, con esto ya no se considera como redundancia.

·         Cuarta formal normal

También es denominada dependencia multivalorada son utilizadas para definir una forma normal para los esquemas de relación.

ü  Dependencias multivaloradas

Las dependencias multivaloradas no impiden la existencia de esas tuplas, exigen que estén presentes en la relación otras tuplas de una cierta forma; las dependencias multivaloradas se conocen como dependencias de generación de tuplas.

Sea R un esquema de relación y sean α ⊆ R y β ⊆ R.

La dependencia multivalorada

α →→β

se cumple en R si, en toda relación legal r(R), para todo par de tuplas t1 y t2 de r tales que t1[α] = t2[α], existen unas tuplas t3 y t4 de r tales que:

 

α →→β indica que la relación entre α y β es independiente de la relación entre α y R – β. Si todas las relaciones del esquema R satisfacen la dependencia multivalorada α →→β, entonces α →→β es una dependencia multivalorada trivial en el esquema R.

Las dependencias multivaloradas se utilizan de dos maneras:

1. Para verificar las relaciones y determinar si son legales bajo un conjunto dado de dependencias funcionales y multivaloradas.

2. Para especificar restricciones del conjunto de relaciones legales; de este modo, sólo habrá que preocuparse de las relaciones que satisfagan un conjunto dado de dependencias funcionales y multivaloradas.

Al definir dependencia multivaloradas podemos decir  que cada dependencia funcional es también una dependencia multivalorada:

Si α →β, entonces α →→β.

ü  Definición de la cuarta forma normal

La dependencia multivalorada se puede utilizar para mejorar la BD descomponiendo el esquema en la cuarta forma normal.

Un esquema de relación R está en la cuarta forma normal con respecto a un conjunto F de dependencias funcionales y multivaloradas de F+ de la forma α →→β, donde α ⊆ R y β ⊆ R, donde  mínimo se tiene que cumplir una de las siguientes condiciones:

α →→β = dependencia multivalorada trivial.

α = superclave del esquema R.

La restricción de F a Ri es el conjunto Fi que consta de:

1. Todas las dependencias funcionales de F+ que sólo incluyen atributos de Ri

2. Todas las dependencias multivaloradas de la forma α →→β ∩ Ri donde α ⊆ Ri y α →→β está en F+.

ü  Algoritmo de descomposición

Su analogía de 4FN y FNBC  puede ser aplicable al algoritmo para la descomposición de los esquemas. Este algoritmo es igual al algoritmo de descomposición en FNBC solo que se emplea dependencias multivaloradas y utiliza la restricción F+ a Ri

Sean R un esquema de relación y F un conjunto de dependencias funcionales y multivaloradas de R.

Suponiendo que R1 y R2 forman una descomposición de R. Esta descomposición será una de reunión sin pérdida de R si y sólo si, como mínimo, una de las siguientes dependencias multivaloradas se halla en F+:

R1 ∩ R2 →→ R1

R1 ∩ R2 →→ R2

·         Otras formas normales

Las dependencias multivaloradas ayudan a comprender y abordar algunas formas de repetición de la información.

Dependencias de reunión son restricciones que generalizan las dependencias multivaloradas y las llevan a otra forma normal forma normal de reunión por proyección (FNRP) y existe una clase de restricciones más generalizada llamada forma normal de dominios y claves (FNDC).

 

 

 

 

 

 

Enunciado

Tienda de celulares Crazy Cell

La tienda de celulares Crazy Cell necesita una base de datos para almacenar datos de sus clientes, de las ventas que realiza y de sus productos.
A los clientes se les solicita información básica como su nombre, dirección, teléfono, e-mail, etc., la primera vez que realiza una compra en la tienda.

Cuando en la tienda se realiza una venta es conveniente para los dueños saber que empleado realizó la venta, así como información del producto (tipo, precio, código, marca), cabe destacar que los celulares no se cuentan como parte de los productos. Además se necesita saber a qué cliente se vendió.
Los celulares cuentan con la siguiente información: tipo, marca, modelo, número de serie, número de celular y la compañía a la que pertenece.

La tienda cuenta con un servicio de facturación si la compra excede más de 50 pesos. Los datos que se incluyen en la factura son el IVA, RFC, fecha y los datos básicos del cliente.
Si el cliente no desea la factura se le imprime un ticket.

Los dueños necesitan la siguiente información de sus empleados: nombre, dirección, teléfono, e-mail, número de contrato, así como el turno en que trabaja para un mayor control de su personal.

Diagrama Entidad-Relación

 

 

Tarea 3 (Resumen)

Claves

Es necesario tener una forma de especificar cómo las entidades dentro de un conjunto de entidades dado y las relaciones dentro de un conjunto de relaciones dado son distinguibles.

Los valores de los atributos de una entidad deben ser tales que permitan identificar unívocamente a la entidad (no se permite que ningún par de entidades tengan exactamente los mismos valores de sus atributos)

Una clave permite identificar un conjunto de atributos suficientes para distinguir las entidades entre sí.

     Conjuntos de entidades

Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades. Una superclave puede contener atributos innecesarios.

A menudo interesan las superclaves tales que los subconjuntos propios de ellas no son superclave. Tales superclaves mínimas se llaman claves candidatas.

Se usará el término clave primaria para denotar una clave candidata que es elegida por el diseñador de la base de datos como elemento principal para identificar las entidades dentro de un conjunto de entidades. Una clave (primaria, candidata y superclave) es una propiedad del conjunto de entidades, más que de las entidades individuales. Cualesquiera dos entidades individuales en el conjunto no pueden tener el mismo valor en sus atributos clave al mismo tiempo. La designación de una clave representa una restricción en el desarrollo del mundo real que se modela.

La clave primaria se debería elegir de manera que sus atributos nunca, o muy raramente, cambien.

     Conjuntos de relaciones

Se necesita un mecanismo similar para distinguir entre las diferentes relaciones de un conjunto de relaciones. Sea R un conjunto de relaciones que involucra los conjuntos de entidades E1, E2,…, En. Sea clave-primaria(Ei) el conjunto de atributos que forma la clave primaria para el conjunto de entidades Ei.

La composición de la clave primaria para un conjunto de relaciones depende de la estructura de los atributos asociados al conjunto de relaciones R.

Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto de atributos:

clave-primaria(E1) ∪ clave-primaria(E2) ∪…∪ clave-primaria(En)

En el caso de que los nombres de atributos de las claves primarias no sean únicos en todos los conjuntos de entidades, los atributos se renombran para distinguirlos; el nombre del conjunto de entidades combinado con el atributo formaría un nombre único.

La estructura de la clave primaria para el conjunto de relaciones depende de la correspondencia de cardinalidades asociada al conjunto de relaciones.

Para las relaciones no binarias, si no hay restricciones de cardinalidad, entonces la superclave formada como se describió anteriormente en este apartado es la única clave candidata, y se elige como clave primaria. La elección de la clave primaria es más complicada si aparecen restricciones de cardinalidad.

Cuestiones de Diseño

Las nociones de conjunto de entidades y conjunto de relaciones no son precisas, y es posible definir un conjunto de entidades y las relaciones entre ellas de diferentes formas.

     Uso de conjunto de entidades o atributos

Considérese el conjunto de entidades empleado con los atributos nombre-empleado y número-teléfono. Se puede argumentar fácilmente que un teléfono es una entidad por sí misma con atributos número-teléfono y ubicación. Si se toma este punto de vista, el conjunto de entidades empleado debe ser redefinido como sigue:

• El conjunto de entidades empleado con el atributo nombre-empleado

• El conjunto de entidades teléfono con atributos número-teléfono y ubicación

• La relación empleado-teléfono, que denota la asociación entre empleados y los teléfonos que tienen.

Al tratar un teléfono como una entidad se modela mejor una situación en la que se puede querer almacenar información extra sobre un teléfono.

Las distinciones dependen principalmente de la estructura de la empresa del mundo real que se esté modelando y de la semántica asociada con el atributo en cuestión.

Un error común es usar la clave primaria de un conjunto de entidades como un atributo de otro conjunto de entidades, en lugar de usar una relación.

Otro error relacionado que se comete es designar a los atributos de la clave primaria de los conjuntos de entidades relacionados como atributos del conjunto de relaciones. Esto no se debería hacer, ya que los atributos de la clave primaria son ya implícitos en la relación.

     Uso de conjuntos de entidades o conjuntos de relaciones

No siempre está claro si es mejor expresar un objeto mediante un conjunto de entidades o mediante un conjunto de relaciones.

Una posible guía para determinar si usar un conjunto de entidades o un conjunto de relaciones es designar un conjunto de relaciones para describir una acción que ocurre entre entidades. Este enfoque puede también ser útil para decidir si ciertos atributos se pueden expresar más apropiadamente como relaciones.

     Conjuntos de relaciones binarias o n-arias

Las relaciones en las bases de datos son generalmente binarias. Algunas relaciones que parecen no ser binarias podrían ser representadas mejor con varias relaciones binarias.

De hecho, siempre es posible reemplazar un conjunto de relaciones no binarias (n-aria, para n > 2) por un número de diferentes conjuntos de relaciones binarias.

Por simplicidad, considérese el conjunto de relaciones abstracto R, ternario (n = 3), y los conjuntos de entidades A, B, y C. Se sustituye el conjunto de relaciones R por un conjunto de entidades E y se crean tres conjuntos de relaciones:

• RA, relacionando E y A

• RB, relacionando E y B

• RC, relacionando E y C

Si el conjunto de relaciones R tiene atributos, éstos se asignan al conjunto de entidades E; por otra parte se crea un atributo de identificación especial para E Para cada relación (ai,bi,ci) del conjunto de relaciones R, se crea una nueva entidad ei en el conjunto de entidades E. Entonces, en cada uno de los tres nuevos conjuntos de relaciones, se inserta un nuevo miembro como sigue:

• (ei,ai) en RA

• (ei,bi) en RB

• (ei,ci) en RC

Un atributo de identificación puede haber sido creado para el conjunto de entidades para representar el conjunto de relaciones. Este atributo, con los conjuntos de relaciones extra necesarios, incrementa la complejidad del diseño y los requisitos de almacenamiento.

• Un conjunto de relaciones n-arias muestra más claramente que varias entidades participan en una relación simple.

• Podría no haber una forma de traducir restricciones en la relación ternaria en restricciones sobre relaciones binarias. Por ejemplo, considérese una restricción que dice que R es varios a uno de A, B a C; es decir, cada par de entidades de A y B se asocia con a lo sumo una entidad C. Esta restricción no se puede expresar usando restricciones de cardinalidad sobre los conjuntos de relaciones RA, RB y RC.

     Ubicación de los atributos de las relaciones

La razón de cardinalidad de una relación puede afectar a la situación de los atributos de la relación. Los atributos de los conjuntos de relaciones uno a uno o uno a varios pueden estar asociados con uno de los conjuntos de entidades participantes, en lugar de con el conjunto de relaciones.

La decisión de diseño de dónde colocar los atributos descriptivos en tales casos podría reflejar las características de la empresa que se modela.

La elección de la colocación del atributo es más clara para los conjuntos de relaciones varios a varios.

Cuando un atributo se determina mediante la combinación de los conjuntos de entidades participantes, en lugar de por cada entidad por separado, ese atributo debe estar asociado con el conjunto de relaciones varios a varios.

Conclusión

Entendimos que la entidad es la relación de ambas convirtiéndose dicha relación en una forma de conexión explicita de un lugar implícito. El conjunto de relaciones se tendría que definir en relaciones separadas para cada entidad cuando se presenta una situación en la que varias entidades compartan un atributo ya que se podrían replicar los valores para los atributos descriptivos en cada una de las relaciones, ocasionando el almacenamiento de varios datos repetidos reduciendo así mismo el espacio de almacenamiento, entre otros.

Generalmente las relaciones son binarias en la base de datos. Puede decirse que las relaciones binarias  tienen una relación entre  los mismos elementos de un conjunto, se asignara al conjunto de entidades un atributo de identificación para poder ser distinguidas de los otros miembros pertenecientes al conjunto, de esta manera las entidades participarían en una relación mas simple.

Los atributos de la relación pueden ser afectadas por la razón de cardinalidad de una relación, es decir, en el conjunto de relaciones uno a varios se puede colocar solo en el conjunto de entidades ya que al realizar la asignación de cada atributo tendría el mismo significado. Y para los conjuntos de entidades de uno a uno pueden asociarse con cualquier entidad participante.