136326711.

doc

DEFINICIONES BSICAS:.............................................................................................................................2 Base de dato.................................................................................................................................................2 SISTEMA DE MANEJO DE BASE DE DATOS (DBMS).............................................................................3 NORMA CODASYL PARA DBMS.......................................................................................................................3 ARQUITECTURA INTERNA DE UN DBMS..................................................................................................................6 VENTAJAS Y DESVENTAJAS DE LAS BASES DE DATOS..................................................................................................6 Evolucin de la importancia de elementos de la empresa...........................................................................7 NORMA ANSI-SPARC (POSTERIOR A CODASYL)..............................................................................................7 MODELOS DE BASE DE DATOS................................................................................................................10 Algebra relacional:....................................................................................................................................15 Restricciones:.............................................................................................................................................15 Operaciones especficas:............................................................................................................................15 Consultas a Bases de Datos relacionales usando lgebra Relacional:....................................................15 SQL....................................................................................................................................................................17 CONSULTA DE BASE DE DATOS: LENGUAJE LGICO (LL)........................................................................................20 Comparacin con SQL de ejercicio anterior:............................................................................................22 Cmo pasar un enunciado de Lenguaje Lgico a SQL:............................................................................23 Cmo pasar un enunciado de Lenguaje Lgico a lgebra Relacional:....................................................23 Ejemplo: Divisin.......................................................................................................................................24 DISEO DE BASE DE DATOS (MTODO MATEMTICO):................................................................25 ANOMALAS :......................................................................................................................................................25 TEORA DE LAS DEPENDENCIAS FUNCIONALES:.............................................................................25 AXIOMAS DE ARMSTRONG....................................................................................................................................26 TEOREMA FUNDAMENTAL DE LA DESCOMPOSICIN...................................................................................................27 ALGORITMO DE BEERI BERSTEIN (MTODO MATEMTICO)......................................................................................27 Problema de la Pertenencia (membership)................................................................................................27 Determinacin de superclaves...................................................................................................................28 Bsqueda de claves mnimas......................................................................................................................28 Analizar si una dependencia es completa (full).........................................................................................28 Analizar si una dependencia es transitiva..................................................................................................28 TEORA DE FORMAS NORMALES............................................................................................................................28 Primera Forma Normal (1NF):.................................................................................................................28 Segunda Forma Normal (2NF):.................................................................................................................29 Tercera Forma Normal (3NF):..................................................................................................................29 Forma Normal de Boyce-Codd (BCNF):...................................................................................................29 MTODO DE NORMALIZACIN................................................................................................................................30 HIPERGRAFOS:..............................................................................................................................................30 BASE DE DATOS Y LGICA:......................................................................................................................31

Pgina 1 de 34

136326711.doc

Definiciones bsicas:
objeto: ente del cual queremos hablar. Cualquier ente de existencia real o virtual. valor: ente tiene forma de representar preconcebido. Ej: Enteros (ASCII EBCDIC: existe un cdigo para representarlos). atributo: correspondencia entre objetos y valores. Siempre son correspondencias representables por tuplas. Universo de objetos Universo de valores

propiedad: par ordenado formado por un (atributo, valor) dato: par ordenato formado por un (objeto, propiedad) o terna (objeto, atributo, valor)

Base de dato

algun a vez acaba conjunto

no debe haber un dato que se pueda deducir de los otros (si no es un banco de datos)*

independencia deductiva Base = bsico

Coleccin finita no redundante de datos Base de Dato = { <o, a, v>;<o2, a2, v2>; ... ;<on, an, vn>}se puede organizar en registros Redundancia: Para evitar la redundancia se utiliza un precedimiento parecido al factoreo matemtico. Registro = {datos; ... ; } (factores) Registro natural: si se refiere al mismo objeto. Archivo = {registros; ... ; } Archivo natural: Si los registros son objetos similares. BD = { [o1][a1 v1 , a2 v 2 , ... , an v n]; ... } 1er. Paso: extraer los registros naturales, 2do. Paso: fromar los factor comn archivos naturales, luego por Convencin: BD = { [a1, a2 , ... , an][o1]<v1, v 2 , ... , v n>; ... }

Pgina 2 de 34

136326711.doc

Sistema de Manejo de Base de Datos (DBMS)

Conjunto de mdulos hard y soft que permiten construir, mantener, operar una base de datos. Existen DataBase Machines que permiten direccionar por contenido. Funciones: generar mantener backup recuperar operaciones de actualizacin insercin eliminacin modificacin de localizacin / recuperacin consulta por soluciones de compromiso, se inserta, modifica y eliminar por registro (no dato por dato), aunque hay sistemas que lo permiten. Estudio como caja negra IN OUT

es un sistema no determinstico. A iguales entradas no siempre corresponden iguales salidas, sino que estas son funcin de toda la historia de las instrucciones (de esa manera si se puede decir que sera determinstico).

IN

SMBD

OUT

con este esquema el estudio puede ser ms sencillo

BD

Norma CODASYL para DBMS

1. 2. 3. 4. 5. Construir, mantener, explotar una Base de Datos. Independencia de hardware (datos y hard). Cantidad de datos slo limitada por el hardware (tampoco hay lmite de longitud de registros). Variadas estrategias de consulta (por el criterio que se me ocurra, no tiene por que estar indexado). Condiciones de independencia: (a) del hardware (y de perifricos). (b) representacin interna de los datos. (c) formato (ej.: grabar entero, leer real). (d) direcciones (fsicas FIOS o lgicas LIOS). (e) punteros (debe ser transparente para el programador). (f) da facilidades para resolver los problemas de las Bases de Datos. (f1) seguridad. (f2) privacidad. (f3) integridad. (f4) concurrencia.

TECNICAS PARA ENFRENTAR LOS PROBLEMAS DE LAS BASE DE DATOS

Pgina 3 de 34

136326711.doc (f1) Seguridad. Proteger la base contra su destruccin. Analizar posibles causas: incendio, sabotaje, etc. Por ej: en un incendio no utilizar agua para apagarlo. Se debe utilizar gas halgeno. recuperacin: backup (forward / backward). Tiempo Destruccin de la Backup Backup BD a) tener una copia para cada uno de una serie de puntos en el tiempo, es muy caro. b) hacer una copia ms una bitcora (log) (forward). c) backward: tomar la base destruida y se intenta deshacer hasta llegar a tener integridad. (f2) Privacidad. No es lo mismo que seguridad. Evitar accesos no autorizados. Existen varias tcnicaas. - utilizar palabras claves (este sistema es malo): si cambia la palabra clave, se debe cambiar la codificacin y recompilar el programa. - locks & keys: a cada cerradura se le asigna una llave que la abre (no se necesita modificar el programa). Este mtodo utiliza operaciones lgicas sobre bits, entonces en facil de implementar por hardware. El tema es determinar la longitud de la clave a utilizar (cuando ms larga la clave, mayor es el tiempo necesario para cifrar y descifrar). - Criptografa. para resolverlo se otorgan permisos a) por funcin: por ej. permiso para insertar pero no para modificar. lectura (para consultas). escritura (para modificar). lectura / escritura (eliminar o combinado). b) por niveles para toda la base. por archivo. por registro. por un dato individual No hay forma de asegurar la privacidad de un dato restringiendo la cantidad de consultas a un dato porque siempre me las puedo arreglar para acceder a un dato indivudial haciendo consultas generales (por descarte). En general los algoritmos de encripcin se basan en una clave privada, que usa la base de datos. Los datos se guardan y se transmiten en forma encriptada. Las claves deben ser lo suficientemente largas como para evitar ataques por 'fuerza bruta'. Hay tcnicas para deducir claves cuando hay transliteracin, por ejemplo, ver que smbolo aparece ms porque es la letra ms usada en el idioma original (para ello se venden tablas de frecuencia de uso para descifrar cdigos secretos); permutacin (dar vuelta caracteres de una misma palabra). Hay dos tipos de escritura secreta a) local: sirve para transmitir cantidades finitas de mensajes. No hay forma de descifrarlas. b) global: se permite hablar de cualquier tema cotidiano. Son descifrables. Por ejemplo, un agente secreto usa la escritura local para brindar un informe, pero si precisa dar ms detalles debe usar un lenguaje existente, ya que no puede inventar uno nuevo y ensearlo a su jefe. Entonces cae en un lenguaje existente y se prueba que la funcin de codificacin no puede ser arbitraria y alguna vez se descifrar. No se busca que no sea descifrable, sino que lleve mucho tiempo lograrlo. Con el advenimiento de las redes pblicas no se puede evitar ser interceptado, por lo que se deben desarrollar tcnicas criptogrficas. La criptografa pblica consiste en un algoritmo de encriptado conocido por todo el mundo, con claves distintas para cada caso, una pblica y otra privada que se combinan para encriptar y desencriptar los mensajes, lo que posibilita la transmisin libre de las claves pblicas.

Pgina 4 de 34

136326711.doc Integridad. Se debe asegurar la consistencia de los datos, es decir que guarden relacin con la realidad. Un dato inconsistente, por ejemplo sera un valor negativo para una edad o uno desmesuradamente alto (como 250 para una persona!). Este problema tiene que ver con la semntica. La consistencia se puede asegurar a dos niveles a) local: si el dato que ingreso se compara contra datos del mismo registro para ver si tiene sentido. Ejemplo: verificacin del rango (que la edad sea entera y est en un rango dado; que el salario est entre 0 y 1.000.000, o que si el puesto es cadete, entonces estar entre 100 y 300 es mejor verificacin que la anterior). b) global: cuando se compara contra toda la base o buena parte de la misma. Ejemplo: el salario asignado no debe ser mayor que el mximo salario de alguien que ya est trabajando, o que no gane menos que el que est trabajando, o debe estar entre un 10% ms y menos de los extremos de lo que se paga. Las verificaciones globales son ms costosas de implementar porque hay mas consultas pero son mejores que las locales. Concurrencia. Se debe asegurar el acceso simultneo de varios usuarios, es decir que no sea necesaria una sincronizacin previa entre ellos. Un usuario dispara un proceso. Este proceso necesita recursos (CPU asignada, memoria, etc.) que pueden estar asignados a otros procesos (pudiendo producirse un punto muerto o abrazo mortal o deadlock). Una de las tareas de los Sistemas Operativos es la de job scheduling que decide que proceso corre en cada momento. Otro mdulo importante es el de resource allocation, que decide que espacio le asigna a cada trabajo, qu recursos, etc. Esta ltima tarea se puede realizar de distintas formas: esttica: se asignan al comienzo de la ejecucin, permaneciendo inmviles durante el tiempo que sta lleve. No presenta problemas de deadlocks ni interrupcin pero se hace un mal uso de los recursos (reservados). dinmica: el proceso le va solicitando recursos al sistema a medida que los precisa. Problemas de la concurrencia: 1. deadlocks: se da cuando dos o ms procesos no pueden avanzar ya que cada uno necesita recursos asignados a otros que precisan recursos que maneja el primero. La solucin es terminar un proceso kill process. El Sistema Operativo debera decidir a que proceso matar, para lo que suele contar con un algoritmo de deteccin de deadlocks, mediante la confeccin de un grafo doblemente etiquetado (procesos + recursos) y determina la supresin de alguno de ellos. P2

P1

R1

R1 Con bases de datos distribuidas, donde no todos los procesos corren en la misma CPU, el Sistema Operativo tendra que consultar con cada nodo para saber si hay un deadlock, lo que sera muy costoso en una red muy dispersa (problema de conjunto, no local). A esto no se le encontr una buena solucin. bloqueo: se debe dar la impresin de que a los usuarios se los atiende simultneamente, por lo que se les asigna a cada uno de ellos una porcin de tiempo (time slice) de CPU (64 milisegundos), lo que se denomina time sharing. Otra posibilidad es administrar estos quantums de tiempo de acuerdo a las necesidades de cada usuario. Entonces, un proceso corre en foreground y otros en background, y en general se aprovechan las operaciones de entrada / salida, por lo que pueden ocurrir inconsistencias en la informacin (por ejemplo si un usuario que estaba actualizando un registro en disco es interrumpido y se pasa el control a otro usuario que quiere consultar ese mismo dato inconsistente). Para evitar este

2.

Pgina 5 de 34

136326711.doc problema se bloquean los registros involucrados en estas operaciones por medio de semforos (cuando est en verde se puede acceder, no cuando est en rojo). El problema se da al grabar. Se determin que un solo usuario graba a la vez y muchos pueden leer. El Sistema Operativo debe ser absolutamente imparcial (fare) en esta y otras asignaciones de recursos. Pero an esto no es suficiente. Hay operaciones que guardan relacin entre si, formando una unidad lgica. Por ejemplo, si se deposita un cheque y otra persona lo consulta, pero no ve el nuevo saldo. La solucin est dada por las transacciones, conjuntos de operaciones que se toma como atmico, no pudindose interrumpir ni dividir. Es oportuno notar que las transacciones deben ser de una longitud razonable (no consultar toda la base sin interrupciones), lo que es una responsabilidad del programador. Aparecen las instrucciones begin transaction y end transaction para que el compilador reconozca las transacciones. Queda tambin para el Sistema Operativo trabajar con la transaccin. Lo que se hace es trabajar en un rea auxiliar y cuando est todo listo, se bloquea y se pasa todo al rea principal. Existe tambin la instruccin rollback que permite deshacer la instruccin (o transaccin) anterior, que en realidad todava est en el rea auxiliar y no fue grabada. Es preciso remarcar que todo esto se realiza en tiempo real.

Arquitectura interna de un DBMS

Un usuario dispara una consulta o actualizacin
Mdulo Intrprete

Privacidad

Formatos

Conversor

Interpreta las instrucciones del usuario

Asegura la privacidad, pidiendo la clave de usuario

Modifica los formatos. Ej: Si se tipea como real y se pidio entero, trunca LIOCS

Mdulo que convierte cdigo (ASCII)

DB

PHIOCS

Asigna Punteros

Mdulo que graba o lee el dato

Phisical I-O System. Calcula da ubicacin fisica (pista, sector) en el disco.

Calcula direcciones lgicas (que deben ser independientes de las $)

Modifica o calcula los punteros

La gente de Base de Datos se dedica mucho a hacer mdulos interpretadores. Los dems mdulos los sacan de la gente de Sistemas Operativos.

Ventajas y desventajas de las Bases de Datos

Antes de la existencia de las bases de datos, haba muchos programadores en una empresa que desarrollaban cdigos para manejar sus archivos, muchos de ellos con los mismos datos (redundancia = mal aprovechamiento de los discos) y cada uno de estos programas hace reserva de buffers de memoria (con lo que tambin se utiliza mal la memoria inmediata). Con las bases de datos se tiene un solo archivo que sirve para todos los usuarios, haciendo reserva de un solo buffer. Cada usuario programa una consulta o actualizacin y usa el mismo sistema de manejo de base de datos, que centraliza todo y hace una mejor administracin. Se ahorra en software porque los mdulos propios de la base de datos se hacen una sola vez. El desarrollo de los sistemas es ms rpido.

Pgina 6 de 34

136326711.doc

Evolucin de la importancia de elementos de la empresa.

Inicialmente se incorporan nuevos equipos, que son lo ms costoso de la empresa. Luego de un tiempo de hacer programas estos pasan a ocupar ese sitial y la empresa debe proteger el software. Ms tarde, al haber demasiados archivos de datos, se decide implantar una base de datos y en ese momento son los datos lo que ms vale en la empresa. Finalmente, luego de un nuevo perodo de tiempo se hace an ms importante el saber cmo aprovechar los datos que se tienen (know-how)

FPS: File Processing System. DPS: Data Processing System. DBMS: Data Base Managment System. IMS: Information Management System (adems de todas las funciones anteriores, provistas por los subsistemas, estipula quines reciben y quines generan informacin. El problema del ciclo de vida del soft es el siguiente a) Etapa de anlisis. b) Etapa de codificacin. c) Etapa de testeo: correcciones. Siempre queda algo por corregir (sndrome del 99%). Es ms costosa, por producir menos instrucciones, pero los errores salen caros.

Norma ANSI- SPARC (posterior a COD ASYL)

Exige que la descripcin de las bases de datos se puedan hacer a travs de un esquema o descripcin de la estructura, consistente en la forma en que se estructura, la informacin esttica, las relaciones. Se hace a travs de tres esquemas: 1) Esquema conceptual o global o Esquema de la Base de Datos: es una descripcin de toda la base de datos desde el punto de vista de todos los usuarios. Tiene que describir los datos y las relaciones. Como no es posible reunir a todos los usuarios hay un Administrador de la Base de Datos (DBA) para prever la forma de archivos que van a existir, entre otras cosas. 2) Subesquema o Esquema de Aplicacin: es una descripcin parcial de la Base de Datos desde el punto de vista de un usuario o grupo de usuarios. Tambin lo realiza el DBA y le da a cada usuario solamente lo que necesita. Debe existir un lenguaje para describir los datos (Data Description Language). 3) Esquema Interno: descripcin de los dispositivos a usarse en el SMBD. Lo hace el Jefe de Centro de Cmputos. Indica cosas como qu archivos quedan en disco y cules van a parar a cinta.Los programas deben ser independientes de los datos. El usuario no debe saber que un archivo est en un lado o en otro, es decir que debe ser transparente a l.Puede residir en distintos medios de grabacin (discos, cintas, CD, juke-box) simultneamente. No se deben tener que cambiar los programas cuando se modifica un archivo (cosa que debe dejarse bien claro en el esquema interno). Las operaciones posibles sobre los datos dependen de los tipos de estos. Pueden definirse tipos de datos adicionales a los predefinidos. Para cada tem se define: - Ocurrencia o instancia del tem: - Tipo del tem: subconjunto de valores posibles que puede tomar el dato y las operaciones permitidas.

Pgina 7 de 34

136326711.doc La base de datos va cambiando a medida que se modifica. Va a tener registros del tipo que se le indiquen. La descripcin de los esquemas y subesquemas se hace a nivel de los tipos. El DBA conversa con cada usuario y se fija que tipos de datos va a usar y los describe. Por ejemplo, el IDS 2 posee un intrprete de DDL, en el que existe un SDDL (Subscheme Data Definition Language), que permite describir la parte que al usuario le interesa. SKEMA mi base RECORD comp Legajo INT PIC XXX Salario REAL PIC ... ... ... ... ... ... ... SSKEMA sueldos SKEMA mi base RECORD comp Salario REAL PIC ... ... ... ... (sueldos es un subesquema de mi base. Slo se definen los registros y tipos de datos que incumben al usuario).

Se compilaba con un procesador especial. Luego el programador, con el SDDL, programaba en COBOL68, intercalando llamadas a la base de datos. Se lograba as la tan mentada independencia (el programador no deba preocuparse por la forma en que estaba grabado o algn otro detalle fsico). Para el esquema interno se describa en un archivo aparte, que luego se linkeditaba y sacaba un ejecutable. Si bien esto no concerna al programador, si preocupaba al Jefe de Centro de Cmputos que deba hacer ciertas operaciones como copias de seguridad. FILE mi base RECORD .... ... ... ...

Las computadoras ms antiguas tenan un procesador de canales para manejar la E/S, que se encarga realmente de hacer la lectura y no la CPU. Antes de contar con estas normas, se deba cambiar todo ante cada modificacin en los datos y no se tena independencia. Luego de esto, no es ms necesario recompilar, aunque s a linkeditar, porque cada esquema es independiente. En resumen, en vez de describir en los programas, se hace en los esquemas. Mientras no se modifiquen los subesquemas, no se tocan los programas. El sistema de manejo de los esquemas de las bases de datos debe poder registrar no slo los datos sino las asociaciones entre ellos. Pueden existir dos tipos de asociaciones: Intrarregistro: relacin de un dato con otro dentro del mismo registro. Interregistro: relacin entre datos de distintos registros. A su vez se las divide en: Escenciales: las realmente importantes para mantener la consistencia e integridad. Eventuales: no son vitales o no merecen que uno se ocupe de ellas. El sistema debe mantener las asociaciones escenciales, sea intra o interregistros, pudindolo implementar: Por continuidad fsica: cuando se graba un dato el otro est al lado. Por puntero: los datos se graban en cualquier lugar libre del disco pero con un puntero al otro dato. Las asociaciones intrarregistros se obtienen generalmente por continuidad fsica. Se implementan, y se trata de mantenerlos en el mismo orden. Las interregistros son ms difciles de implementar por continuidad fsica, por lo que se suelen emplear punteros. Salvo en modelos jerrquicos (en los que se puede implementar por continuidad fsica, lo que es interesante para el caso en que se debe usar cinta magntica).

Pgina 8 de 34

136326711.doc En los primeros Sistemas de Base de Datos, los esquemas eran estticos. Se escriban una vez y no se los tocaba. En los actuales, el programador puede crear tipos nuevos de registros (dinmicos). Los lenguajes modernos permiten modificar el esquema de las bases de datos intercalando las instrucciones.

Pgina 9 de 34

136326711.doc

Modelos de Base de Datos

Es una descripcin abstracta de la estructura de la base de datos y las relaciones entre los elementos que la forman. Es una abstraccin en la que no interesan los elementos concretos que estn grabados en ella. Pueden nombrarse, por orden de aparicin: 1. Jerrquico: Los registros pueden ser de 2 tipos: parent o children. a- Un registro padre puede estar vinculado con N hijos, pudiendo variar N entre 0 y todo lo que entre en el disco. b- De un registro padre pueden depender N ocurrencias de un hijo, y un hijo de un nico padre. Una ocurrencia de un tem (dato, registro, etc.) es la existencia fsica de l y debe distinguirse del tipo del dato, que es el dominio al que pertenece y determina un rango y operaciones permitidas. Es decir, es un conjunto genrico al que pertenece el dato. Cada registro se representa con un nodo y los arcos son las asociaciones. Para que el modelo sea jerrquico, el padre debe ser de un tipo diferente al de los hijos. Ejemplo: Registro de tipo gerencia. Asociados a l: departamentos, proyectos. Una gerencia maneja departamentos y supervisa proyectos. Los departamentos supervisan oficinas, secretaras TIPO PADRE

TIPO HIJO

Departamento

Proyecto

Oficina

Taller

y talleres. Un departamento no puede depender de dos gerencias. El padre debe ser nico. Si tomo dos hijos del mismo tipo (por ejemplo dos departamentos) sus padres deben ser del mismo tipo (en este caso, gerencia). No puede ser una gerencia y otro directorio. Este tipo de grafos con un conjunto de rboles se denomina jungla (forest). Desventaja: Son diagramas incmodos. Se puede representar el estado de una base de datos pero debe cambiarse si se la modifica. Por ello se dise otro tipo de diagrama en el que se representa el tipo de registro
G D O f i c i n aS e r e n c ia eP n r to o y e c t o

e p a r t a m

e c r e t a r T aa l l e r

mediante un nodo, con a lo sumo un arco incidente en cada uno. Lenguajes para el modelo jerrquico. Tienen instrucciones distintas para el nodo raz y los nodos descendentes. Ejemplo: DL-I (data definition language) tiene una instruccin de consulta GET, GET U para consultar un nodo raz: GET U (<nombre del registro a consultar>, <condicin (<, >, >=, <=, <>)>)

Pgina 10 de 34

136326711.doc GET U (Gerencia, NGER = 1001) encuentra la gerencia 1001 y detiene la cinta. Luego se usa un GET (departamento, ...) para recorrer los hijos, recorriendo toda la cinta y saltando los hijos de otros tipos, con lo que se tiene un problema de violacin de frontera jerrquica (por devolverse los hijos de todas las gerencias, no de la encontrada en primer trmino). Para solucionarlo se desarroll la instruccin GETW (get within parent) que da una seal de fracaso cuando se acaban los hijos del tipo pedido de la gerencia y comienza otra. Los registros se almacenan en cinta, en forma secuencial por jerarqua: Raz (gerencia) Primer hijo (departamento) Hijos del primer hijo Segundo hijo (oficina, seccin, taller) (proyecto) .... ...

Para actualizar la base de datos se ponen dos cintas (IN y OUT), copindose los datos de la de entrada en la de salida, con las modificaciones pertinentes. Las instrucciones para hacerlo son las mismas que para obtener datos seguidas de una hache (GETUH, GETH, GETWH) por la palabra inglesa hold. (lee y mantiene en un buffer de memoria). Cuando termina el proceso se dan vuelta las cintas. Este modelo, si bien permite el trabajo con cintas, modelizando asosiaciones de 1 a 1 o de 1 a muchos, no permite representar asociaciones de M a N elementos. 2. En red (network): Los registros pueden ser propietarios (owners) o miembro (member) de un conjunto (set) Puede haber muchos conjuntos. Mientras un propietario puede tener varios miembros (ocurrencias o instancias), un miembro tiene un nico propietario para un conjunto dado, y puede ser un propietario en otro conjunto. En cuanto a los tipos, distintos propietarios de un tipo pueden tener miembros de tipos diferentes, pero registros miembros del mismo tipo slo pueden tener propietarios de un nico tipo. Ejemplo: Diagrama detallado. La ocurrencia de cada registro se representa como un nodo. Se representa el conjunto (set) Controla a en lnea continua y el conjunto Supervisa a con arcos punteados. Gerencia

Departamento

Taller

En la prctica se implementa con punteros como una lista circular en la que el ltimo registro del conjunto apunta al propietario. Su ventaja radica en la facilidad de recorrido, teniendo como contrapartida la poca practicidad y el costo excesivo de hallar al registro propietario a partir de uno de sus miembros. Insertar o eliminar registros puede ser muy laborioso, por lo que surgi la lista doblemente enlazada, con un puntero al registro siguiente (next) y otro al anterior (prior). Un tercer juego de punteros, sealando al propietario evita las recorridas por todo el disco, aunque desperdicia un pequeo espacio en el propio registro propietario (permanece sin uso). Se deben agregar para buffers, 3 veces la longitud de los punteros por cada arco emergente e incidente en el nodo, siendo todo esto transparente para el usuario. La cantidad mxima de registros slo est limitada por el hardware. Diagrama de Tipos:
G
Controla a

e r t a i n

r e mT aS e

i a

D O

a f i c

a e l nl e t r o c r e t a r a

Los departamentos reportan a las gerencias. Los talleres suministran elementos a los departamentos. Las secretaras mandan a los gerentes.

Pgina 11 de 34

136326711.doc A <> B es una relacin del tipo 1 a N. A B es una relacin del 1 a 1. A <>> B es una relacin de N a M y se representa con un NEXO. Una base de datos es un modelo en red si su diagrama es un grafo sin bucles, aunque puede tener ciclos. Si se precisara utilizar bucles podran implementarse creando registros nexos que no contienen ningn tipo de informacin ms que los punteros y utilizando 2 conjuntos distintos (en la figura representados por distintos tipos de lneas). Gerencia

Nexo Este modelo es adecuado para el manejo de bases de datos grandes. Es ms general que el modelo Jerrquico, que es un caso particular de este. La norma distingue tres formas de lograr el acceso al primer registro (propietario): a) Va punteros: b) Calculando (mediante hashing, es el ms usado). c) Directo (al grabar el registro se guarda la direccin en memoria, accedindose al registro por ella). Ejemplo: IDS 2 es un muy eficiente sistema de manejo de bases de datos muy grandes SKEMA mi base RECORD nombre tiporeg Pres REAL PIC... (tipos de datos) ... ... ... RECORD nombre tiporeg ... ... ... SET controlar (para indicar que las Gerencias controlan a los Departamentos). OWNER IS Gerencia ACCESS IS CALC (reserva las tablas de hashing) MEMBER IS Departamento MEMBER IS Taller ACCESS IS VIA set SET contra ... ... ... ... SET chusmea con OWNER IS GER MEMBER IS Secretara ORDER IS... ascending by ACCESS IS VIA set OWNER Gerencia THEN THRU A THEN THRU B THEN THRU C Pgina 12 de 34

136326711.doc

Instrucciones de Consulta: FIND slo localiza el registro , no lo trae a la memoria (para eso se usa GET). Estos sistemas diferencian entre los registros de la localizacin y obtencin. Porque para contar registros se puede usar FIND sin leer los registros (sin GET), lo que ahorra accesos innecesarios a disco. MOVE 329 TO CLAVE (Para los que tienen acceso calculado previamente se le carga un valor a la clave para que me busque la clave). FIND ANY Gerencia NEXT WITHIN PRIOR WITHIN FIRST WITHIN LAST WITHIN OWNER WITHIN Ejemplo READ codpieza FIND ANY codpieza IF (STATUS NE 0) STOP FIND NEXT NEXO WITHIN necesita IF (STATUS NE 0) GOTO 5 FIND OWNER P WITHIN interviene RETAINING CURRENT FOR necesita (Para cada registro y cada conjunto el sistema tiene un puntero llamado current, o sea el ltimo consultado. Si se desea que se lea el mencionado registro, antes de avanzar el puntero debe agregarse esta clusula al programa). IF (STATUS NE 0) GOTO 5 GET P PRINT GOTO 10 3. Relacional (sistemas comerciales): Fue formulado por Ted Codd. Est basado en asociaciones intrarregistros. En lugar de usar punteros, se agregan atributos a los registros que los relacionan unos con otros. El grfico es un grafo sin arcos, con un nodo por cada registro. Nomenclatura computacional Nomenclatura matemtica Base de datos relacional Conjunto de relaciones (esquema + relaciones) (esquema = nombres, dominios de atributos) Archivos {n-Tuplas} = relacin (si cambia el orden cambia la tupla) Registros n-Tuplas Datos Componente Representacin grfica Conjunto de tablas

Tablas Filas Entrada

4. DIAM (mtodo de acceso independiente de los datos): Consiste en almacenar un registro por dato, con asociaciones por punteros entre ellos. Contrariamente al anterior, aqu se tienen asociaciones interregistros y ninguna intraegistros. Su gran ventaja (terica) es el hecho de estar siempre normalizada. No lleg a tener una implementacin comercial.

Pgina 13 de 34

136326711.doc El modelo ms general es el modelo en red, pero de todas formas, tanto el modelo relacional como el DIAM tienen el mismo poder expresivo, es decir, todo lo que se puede representar en uno se puede hacer en alguna forma en los dems. Acerca de la conveniencia de usar uno u otro modelo, podra hacerse una distincin entre dos tipos de usuarios. El usuario sistemtico que usa la base siempre para lo mismo (por ejemplo imprimir un listado cada semana) prefiere el modelo en red, dada su alta eficiencia que se refleja en mayor velocidad de consultas. Los usuarios eventuales, que consultan la base ocasionalmente y para distintos propsitos, preferirn el modelo relacional, ya que es improbable que en un esquema de red se hallen presentes todos los punteros necesarios para los distintos tipos de consultas. Si el usuario sistemtico utiliza el modelo relacional, podr efectuar las mismas tareas aunque ms lentamente. Pero este tiempo de mquina es cada vez ms barato, a diferencia del costo de capacitar al personal. Todo esto hace que el modelo relacional sea el ms conveniente, lo que se refleja en los productos comerciales de la actualidad.

Pgina 14 de 34

136326711.doc

Algebra relacional:
Operaciones con conjuntos: Unin: R1 R2 Interseccin: R1 R2 Complemento o Dif.: R1 R2 Producto cartesiano: R1 R2 = {<X1, ... , Xn > / <X1, ... , Xn> R1 <X1, ... , Xn> R2} = {<X1, ... , Xn > / <X1, ... , Xn> R1 <X1, ... , Xn> R2} = {<X1, ... , Xn > / <X1, ... , Xn> R1 <X1, ... , Xn> R2} = {<X1, ... , Xn, Y1, ... , Yn> / <X1, ... , Xn> R1 <Y1, ... , Yn> R2}

Restricciones:
Las restricciones para la Unin, Interseccin y Complemento R1 y R2 deben tener la misma ARITUD. Esto quiere decir que no puedo hacer estas operaciones con una relacin binaria y otra relacin ternaria. ARITUD: que tiene la misma cantidad de atributos. Ley de composicin interna: operaciones entre relaciones deben dar relaciones. Para que sea un lgebra no se debe salir del dominio. Si no es un espacio.

Operaciones especficas:
Proyeccin: A1, ... ,An R = {<X1, , XL > / XL+1, ... , Xn <X1, ... , Xn> R} Es una familia de operaciones (tantas como subndices haya). Como en todo conjunto, en su resultado no puede haber elementos repetidos. Coincide con la operacin SELECT DISTINCT de SQL. Seleccin: A1=V R = {<X1, ... , Xn > / <X1, ... , Xn> R X1 = V} La condicin de seleccin puede ser cualquier operacin de comparacin contra una constante. Tampoco pueden emplearse conjunciones en ella, ya que y y o son operaciones lgicas, por lo que no se tratara de un lgebra. Junta o Fusin: R1 R2 = {<X1, ... , Xn, Y1, ... , Yn> / <X1, ... , Xn> R1 <Y1, ... , Yn> R2 X1 = A1=A1 Y1} Divisin: R1 % R2 = {<X1, ... , Xn > / <Y1, ... , Yn> R2, <X1, ... , Xn, Y1, ... , Yn > R1} NOTA: La nica forma de expresar el cuantificador es con la operacin divisin. Se indican atributos de cada relacin sin que tengan necesariamente que tener el mismo nombre. Matemticamente una relacin es un conjunto de tuplas. El esquema se define como: nombre_relacin (nombre_atributo)dominio_atributo, Si cambia el orden cambia la tupla. Con todas estas operaciones se puede armar cualquier consulta, a excepcin de la Clausura reflexiva transitiva.

Consultas a Bases de Datos relacionales usando lgebra Relacional:

SEAN LAS SIGUIENTES RELACIONES: EMP (E, ED, SALARIO) BONIF (ED, BONIF) Se pide: a) Listar empleados. e emp b) Listar todas las edades. ( ed emp) ( ed bonif) c) Cada empleado con el valor de la bonificacin que recibe. e, bonif (emp bonif)

d) Todos los pares posibles de empleado y bonificacin. e, bonif (emp bonif) Pgina 15 de 34

136326711.doc e) Empleados que duplican su salario. e, bonif (emp bonif) (emp bonif) ed=ed sal=bonif ed=ed

f) Empleados que no obtiene bonificacin. e (emp ) - e (emp bonif)

ed=ed

SEAN LAS SIGUIENTES RELACIONES: PROD (E, P) CAT (P, C) Se pide: g) Empresas que fabrican al menos un producto rojo. e ( c=rojo (prod cat))
p=p

h) Empresas que fabrican al menos un producto de cada color. e ((prod cat) % c (cat)) MAL !!
p=p

e,c (prod cat) % c (cat)) BIEN !!

p=p

i) Empresas que fabrican solamente productos rojos. e (prod) - ( e ( c<>rojo (prod cat)))
p=p

j) Empresas que fabrican en todos los colores. e,c (prod cat) % c (cat)
p=p

k) Empresas que fabrican solamente productos rojos. e (prod) - ( e,c (prod cat) % ( c<>rojo (cat)))
p=p

Pgina 16 de 34

136326711.doc

SQL
SELECT DISTINCT Proyeccin (motivo de ALL consulta). exp1, ...expm ... COUNT (atr) Condiciones del WHERE (cond): AND, OR, NOT EXISTS (subselect) NOT EXISTS (subselect) ANY (subselect) NOT ANY (subselect) (subselect) CONTAINS (subselect) Lista de objetivos.

exp

Atributo rel.atributo alias.atributo exp + exp

Algebraica: Sum (atr) Count(atr) Average(atr) (order by ...??)

FROM rel as alias, rel as alias WHERE cond ORDER is GROUP by ... FROM REL1 LEFT RIGHT INNER El concepto es enviar una consulta al servidor que sea el servidor quien la ejecute y luego devuelva el resultado. Es necesario ser cuidadoso con la manipulacin de este resultado: son mltiples registros, quizs ms de los que puede manejar mi computadora. Existe por esto, una instruccin que me devuelve registro a registro que se llama CURSOR: utilizo un registro y pido el siguiente. SELECT lista objetivo FROM REL1, ..., RELn [AS Alias1, ..., Aliasn] WHERE condicin ORDER BY lista de atributos [ASC, DESC] GROUP BY lista de atributos; JOIN REL2 ON REL1.Atr = REL2.Atr

SUBSELECT (booleanas) EXISTS (subselect que si obtiene por resultado una tabla con al menos un elemento, da verdadero) NOT EXISTS (subselect) ANY NOT ANY (subselect1) CONTAINS (subselect2) Nota: en los subselect no se puede utilizar ORDER BY ni GROUP BY Inner join (): figuran las tuplas de la primera relacin concatenadas con las tuplas de la segunda relacin si los valores de los atributos indicados coinciden.

Pgina 17 de 34

136326711.doc Left join: aparecen todas las tuplas de la primera tabla (de la izquierda) independientemente de que tengan o no tupla correspondiente en la segunda tabla (de la derecha), dejando en caso de no haberla, los mencionados valores en blanco. Right join: se comporta como un left join pero en forma inversa.

Esto a veces es til, por ejemplo, para la transparencia referencial que se trata de que no haya categoras sueltas, o sea inexistentes en la otra tabla. FROM R1 inner join (R2 inner join R3 on R2.A = R3.A) on R1.B = B R1 (R2 R3) (join de join)
A=A B=B

Si se desea hacer un join en que figuren todas las categoras de ambas tablas, se necesita una unin. categ = c select c from tab1 union select c from tab2 No es necesario que el select lleve un atributo, puede ser una constante. select socorro from emp (escribe socorro en la pantalla). select distinct socorro from emp (lo escribe una sola vez). Ejemplos: SEAN LAS SIGUIENTES RELACIONES: EMP (E, C) CAT (C, SUELDO)

Hacer una instruccin SQL que emita la palabra error si encuentra un empleado con una categora que no figure en la otra tabla.

select socorro from emp where emp not in (select cat.c from cat) (no para en el primero, revisa todos, por lo que puede emitirse varias veces el mensaje de error) SEAN LAS SIGUIENTES RELACIONES: PRO (E, P)(EMPRESA, PRODUCTO) MER (P, M)(PRODUCTO, MERCADO)

Con una sola instruccin en SQL, listar las empresas que ofrecen al menos un producto en el mercado de pulgas.
p=p

( e ( m<>pulgas (pro mer)))

Proyeccin Si se quiere eliminar los duplicados.

Join Usar alias no es obligatorio, pero es muy conveniente . SELECT DISTINCT P1.E FROM PRO AS P1 MER AS M1 WHERE P1.P = M1.P AND M1.M = pulgas;

Seleccin Aqu se ubican las condiciones de seleccin de las filas a mostrar

Otra formas de expresar el join:

Pgina 18 de 34

136326711.doc FROM PRO [INNER | LEFT | RIGHT] JOIN MER ON PRO.P = MER.P CUATIFICADOR UNIVERSAL: Listar aquellas empresas que venda todos sus productos en el mercado de pulgas.

En SQL no se puede usar el cuantificador universal (), por lo que se debe usar la lgica (ver Leyes de DeMorgan). Para esto se utiliza la divisin algebraica. p/(p) p/(p) SELECT P1.E FROM PRO AS P1 MER AS M1 WHERE NOT EXIST (SELECT P2.P Funcin de agregado. Cambia de nombre por estar en un subSELECT.

FROM PRO AS P2 WHERE NOT (P2.P = M1.P AND M1.M = pulgas AND P2.E = P1.E)); Otra tcnica es utilizar INCLUDES, aunque no todos los compiladores lo soportan. Si lo hacen con la clusula EXIST.

SELECT P1.E FROM PRO AS P1 WHERE (SELECT MER.P FROM MER WHERE MER.M = pulgas INCLUDES (SELECT P2.P FROM PRO AS P2 WHERE P2.E = P1.E)); En ACCESS las funciones agregadas estn mal. Lo que debera ser: SELECT PRO.E, COUNT (SELECT P1.P = ...) se realiza con la clusula especficamente agregada HAVING: SELECT PRO.E, COUNT (PRO.P) ... HAVING () Listar las empresas que ofrecen exactamente todos los productos que se venden en el mercado de pulgas.

Se buscan dos conjuntos que sean iguales (p / pE ppulgas), y no se dispone en SQL de un operador IMPLICA o EQUIVALE: Leyes de DeMorgan p q pq qp pq p q a.-) p, pE ppulgas b.-) p, ([pE ppulgas] [ppulgas pE]) c.-) p, ([pE ppulgas] [ppulgas pE]) d.-) p, (p E p pulgas p pulgas p E]) 4.1.2.3. Lo que se expresa en trminos de una sentencia SQL de la forma:

Pgina 19 de 34

136326711.doc SELECT P1.E FROM PRO AS P1 WHERE NOT EXISTS (SELECT P2.P FROM PRO AS P2, MER AS M1 WHERE (P2.E = P1.E AND NOT (P2.P = M1.P AND M1.M = pulgas)) OR (P2.P = M1.P AND M1.M = pulgas AND P2.E <> P1.E)) 3.1.4.a) Listar todos los pares de empresas que son competidoras (tienen 2.por lo menos un producto en comn).

Ejercicios tipo Coloquio:

SELECT DISTINCT P1.E, P2.E FROM PRO AS P1, PRO AS P2 WHERE (P1.P = P2.P AND P1.E > P2.E) b) Listar todos los pares de competidoras completas (todo producto de la primera es fabricada tambin por la segunda). LL: p, pE1 pE2 p, (pE1 pE2) p, ( pE1 pE2) p, pE1 pE2 (son los conjuntos en donde no existe productos que pertenezcan a E1 y no pertenezcan a E2). SELECT DISTINCT P1.E, P2.E FROM PRO AS P1, PRO AS P2 WHERE P1.E > P2.E AND NOT EXISTS(SELECT P3.P FROM PRO P3 WHERE (P3.P = P1.P AND P3.P <> P2.P) c) Listar todos los pares de competidoras completas perfectas (fabrican exactamente los mismos productos)

LL: p, pE1 pE2 p, (pE1 pE2) p, (pE1 pE2 pE2 pE1) p, ((pE1 pE2) (pE2 pE1) p, ((pE1 pE2) (pE2 pE1) p, (pE1 pE2) (pE2 pE1) (son los conjuntos en donde no existe productos que pertenezcan a E1 y no pertenezcan a E2). SELECT DISTINCT P1.E, P2.E FROM PRO AS P1, PRO AS P2 WHERE P1.E > P2.E AND NOT EXISTS(SELECT P3.P FROM PRO P3 WHERE (P3.P = P1.P AND P3.P <> P2.P OR P3.P <> P1.P AND P3.P = P2.P)

Consulta de Base de Datos: Lenguaje Lgico (LL)

Nomenclatura: a los relacionamientos que comunmente los identificamos con verbos, conviene identificarlos con la forma sust-sust, donde cada sustantivo es el nombre de las entidades que relacionana. Se trata de encontrar el conjunto de tuplas que cumplen una cierta condicin V o F. {<x1, ..., xn> / (x1, ..., xn) }. Donde <x1, ..., xn> son las tuplas que quiero que me devuelva y (x1, ..., xn) es la condicin que deben cumplir dichas tuplas. Cmo se arma la condicin (frmula bien formada expresin lgica condicin)?

Pgina 20 de 34

136326711.doc Frmula atmica: (los smbolos terminales vlidos son las relaciones o tuplas que existieran). P (t1, ..., tn) (predicado y trminos). ej: H(S): Scrates es hombre. ej: Emp (x, 5) Frmula compuesta: (estas operaciones, no son las mismas que las que se dan entre conjuntos). formula formula formula formula formula formula formula x, formula x, formula (formula, ...) formula formula ej: {<x> / y, Emp(x,y)} (devuelve el conjunto de las x (primer columna) que estn relacionadas con alguna y. Es decir que se cumpla p = y, Emp(x,y) {<x> / Emp(x, 10)} (todas las x / exista la tupla (x,10)). {<x> / y, Emp(x, y) y 10} (todas las x que estn relacionadas con al menos una y que no sea 10). DADAS LAS SIGUIENTES RELACIONES: EMP (EMP, CAT) CAT(C, SUEL) Listar los nombres de todos los empleados M(S): Scrates es mortal. Rel (arg, ..., arg) (nombre de tabla y todos sus argumentos)

{<x> / x, y, Emp(x, y, z)} Hay por para indicar que y y z pueden tomar cualquier valor. NOTA: deben estar todas las variables. Listar los nombres de todos los empleados con sus respectivos salacrios.

{<x,y> / z, Emp(x, y, z)} Hay por para indicar que z puede tomar cualquier valor. {<x> / z, Emp(x, y, 100)} {<x> / ( z, Emp(x, y, 100))} Listar error si hay un empleado tal que todas las categoras que tiene asignadas no figuran en la tabla de categoras. Listar los nombres de todos los empleados que ganan salarios distintos a $ 100. Listar los nombres de todos los empleados que ganan $ 100.

{<error> / x, y, Emp(x, y) z, Cat(y, z)} Variables annimas: se indica con un guin bajo (underscore) a las variables que no se van a usar para otra cosa. Igualmente se prefiere la notacin anterior (en el ejemplo a la izquierda).

Pgina 21 de 34

136326711.doc {<x> / y, Emp(x, y)} {<x> / Emp(x, _)} Negacin: {<x> / y, Emp(x, y)} (no tiene sentido) {<x> / R1(x) R2(x)}

Comparacin con SQL de ejercicio anterior:

Ejemplo de las empresas competidoras (competidoras, competidoras completas, competidoras perfectas): {<e1, e2> / p, Prod(e1, p) Prod(e2, p) e1 e2} {<e1, e2> / p, [Prod(e2, p) Prod(e1, p)] e1 e2} {<e1, e2> / p, [Prod(e2, p) Prod(e1, p)] e1 e2} En general, se suele usar implicaciones con los cuantificadores universales y conjunciones existenciales. x, y, (x, y) y, x, (x, y) x, y, (x, y) y, x, (x, y) pero x, y, (x, y) y, x, (x, y) ej: todos los seres humanos tiene una nariz no es lo mismo que hay una nariz que tienen todos los seres humanos Teoremas: El lenguaje es completo. La consulta dura un tiempo finito. Las bases de datos deductivas deben tener una forma estratificada. Las ms poderosas son las Bases de Conocimiento. Diferencia entre el SQL y el LL: SQL: las variables estn tupladas (EMP.N), recorre filas. LL: las variables estn definidas por los dominios de los atributos, recorre columnas. Un puntero por cada columna, se limita a recorrer solo el universo de la BD. Las variables buscan los valores almacenados en la BD y no en el universo. Algunos conceptos: LL = {Resultado / Para todo, Existe Condicin Cumple} El resultado tiene que esta en Cumple Para todo existe tiene que estar en Condicin Para todo A, existe B quiere decir: Para cada A que hay, existe algn B que puede ser distinto segn A. Existe B, para todo A quiere decir: Existe el mismo B, para todos los A que hay. Si hay solo un existe, entoces es un AND. Si hay un para todo es un implica o un si solo s. con los

Pgina 22 de 34

136326711.doc

Cmo pasar un enunciado de Lenguaje Lgico a SQL:

{<x1, ..., xn> / (x1, ..., xn)} {<T1.atr1, ..., Tn.atrn> / T1Rel1 ... TnReln (T1.atr1, ..., Tn.atrn)} SELECT <x1, ... , xn> FROM Rel1 AS T1, Rel2 AS T2, ..., Reln AS Tn WHERE condicin; Adems se debe cambiar los nombres de las variables: SELECT <T1.atr1, ..., Tn.atrn> FROM Rel1 AS T1, Rel2 AS T2, ..., Reln AS Tn WHERE condicin; y se debe tener en cuenta que: a.- ) Traduccin de : 1 2 1 OR 2 1 2 1 AND 2 1 NOT 1 1 2 NOT 1 OR 2 1 2 1 AND 2 OR NOT 1 AND NOT 2 (Precedencia: NOT AND OR) Cuantificadores: x, (x) Ti.atri, (Ti.atri) EXISTS (SELECT Ti.atri FROM Ti, .... WHERE (Ti.atri)...); x, (x) Ti.atri, (Ti.atri) NOT EXISTS (SELECT Ti.atri FROM Ti, .... WHERE NOT (Ti.atri)...); b.- ) Traduccin de Frmula Atmica: Toda frmula en Lenguaje Lgico tiene su traduccin en SQL: Rel (x1, x2, ..., xn) <T1.atr1, ..., Tn.atrn> IN Rel c.- ) Traduccin de tablas y atributos: En el ejercicio 2.-, se sabe que X pertenece a la tabla PRO y que Y pertenece a la tabla PRO, por lo tanto vemos que estn en PRO separadas, de este modo resolv la clusula FROM. De la misma forma se que X se corresponde a la primera columna de PRO y para Y Idem, por lo tanto se corresponden con E. SELECT X.E, Y.E FROM PRO AS X, PRO AS Y WHERE ... Nota: toda variable tiene que figurar por lo menos una vez en alguna tabla, afirmada (no negada).

Cmo pasar un enunciado de Lenguaje Lgico a lgebra Relacional:

Reglas: {x / R(x)} R (las x que estn en la relacin x son, exactamente, R). {x / y, (x, y)} x {<x, y> / (x, y)} proyeccin segn X. {<x, y> / (x)} {x / (x) } Uy (Uy = y R proyeccin de las Y de R). Producto cartesiano. Pgina 23 de 34

136326711.doc {x / (x)} Ux - {x / (x)} resta. {x / (x) (x)} {x / (x)} {x / (x)} interseccin {x / (x) (x)} {x / (x)} {x / (x)} unin. {x / (x) (x)} {x / (x)} {x / (x)} {x / (x) (x)} {{x / (x)} {x / (x)}} {{x / (x)} {x / (x)}} {x / y, (x, y)} {x / y , (x, y)} {x / (x, a)} x ( y = a{<x, y> / (x, y)}) Para el ejercicio 2.-: {<x, y> / z, (x, y) (y, z)} {<x, y> / z, ((x, y) (y, z))} (Ux Uy) - {<x, y> / z, ((x, y) (y, z))} (Ux Uy) - x, y (Ux Uy Uz - {<x, y, z> / (x, y) (y, z)}) (Ux Uy) - x, y (Ux Uy Uz ({<x, y, z> / (x, y)} {<x, y, z> /(y, z)})) (Ux Uy) - x, y (Ux Uy Uz (Ux Uy Uz - {<x, y, z> / (x, y)} { Ux <y, z> /(y, z)}) ) (Ux Uy) - x, y (Ux Uy Uz {<x, y> / (x, y)} Uz { Ux <y, z> /(y, z)}) (ac se pasa al lgebra, siendo Pro el nombre de la relacin correspondiente a ) (Ux Uy) - x, y ((Ux Uy Uz Pro Uz) (Ux Pro)) ( e Pro p Pro) - x, y (( e Pro e Pro p Pro - Pro p Pro) ( p Pro Pro)) Se trata de ver, en cada instancia, cul es la operacin principal, para aplicarle la traduccin.

Ejemplo: Divisin
lgebra Relacional: R1 % R2 = {<x1, ..., xk> / y1, ..., yk, <y1, ..., yk> R2 < x1, ..., xk, y1, ..., yk> R1 } Lenguaje Lgico con cuantificadores: R1 % R2 = {<x1, ..., xk> / y1, ..., yk, R2 (y1, ..., yk) R1 (x1, ..., xk, y1, ..., yk)} Lenguaje Lgico con variables tupleadas: Sean las siguientes relaciones: pro (e, p)(empresa, producto) mer (p, m)(producto, mercado) R1 % R2 = {<T1.e, T2.p> / T1 Prod T2 Prod m, (Merc(m) Prod(e, p, m) )} = {<T1.e, T2.p> / T1 Prod T2 Prod T3, T3 Merc, Merc(T3, m) Prod(T1.e, T2.p, T3.m} = Ahora la traduccin a SQL es simple: SQL: SELECT T1.e, T2.p FROM Prod AS T1, Prod AS T2 WHERE NOT EXISTS (SELECT T3.* FROM Merc AS T3 WHERE <T3.n> IN Merc AND NOT <T1.e, T2.p, T3.m> in Prod); SELECT T1.e, T1.p FROM Prod AS T1 WHERE (SELECT T3.m

Pgina 24 de 34

136326711.doc FROM Prod AS T1 WHERE T3.e = T1.e AND T3.p = T1.p) INCLUDES (SELECT T4.m FROM Merc AS T4);

Diseo de Base de Datos (mtodo matemtico):

Empleado Andrs Juan Juan Legajo 1001 1000 1000 Salario 100 100 100 nombre_hijo Adrin Jordi Joan

En algunos casos hay gran redundancia de datos. El problema es que esta redundancia crea anomalas durante inserciones, eliminaciones y modificaciones. El objetivo del diseo es, justamente eliminar estas anomalas. Si no se hace esto, con el tiempo aparecen inconsistencias. Por qu no poner una lista para nombre_hijo, en vez de una fila por hijo? Por que se viola un principio de la Base de Datos Relacional que los elementos deben ser atmicos. Si la lista se considerara atmica, no se podra conocer un hijo en particular (debieran agregarse selectores que tomen pedazos de la lista). Esto trae complicaciones. Entre ellas la forma de implementacin. No se puede manejar una longitud fija, sino que se tiene una construccin que necesita operadores especiales. Se trata de evitar el uso de elementos no atmicos, ya que se tendra una tabla redundante (aparecen las anomalas de insercin, modificacin y eliminacin). NOTA: Diseo semntico: se hace teniendo en cuenta el significado de las cosas.

Anomalas:
La redundancia de la informacin en una BD produce distintas anomalas. Anomala de actualizacin: Modificacin: si le quiero dar un aumento a Rocinante no puedo modificar solamente la primer aparicin de Rocinante, ya que quedara inconsistente. Se deben buscar (y modificar) todas sus ocurrencias. Eliminacin: Si quiero despedir a Rocinante, nuevamente tengo que buscar todas las apariciones del mismo y borrarlas. Insercin: en teora si no tengo todos los atributos no puedo agregar el registro. Por ejemplo si Rocinante no tiene hijos no lo puedo agregar. En la prctica se permite poner un valor nulo (null) al atributo que falta si no es imprescindible. A veces en su lugar se utiliza un valor por defecto (default). Para tener un buen diseo hay que tratar de evitar las anomalas. Estas se deben a que, por ejemplo, el salario es funcin del nro. de legajo y el nombre del hijo es una relacin con el nro. de legajo. Es decir que se estn mezclando relaciones con funciones. En este caso, se debe crear otra tabla para los hijos. Legajo Edad 1000 Jordi 1000 Joan 1001 Adrin El problema de la insercin est solucionado, ya que si un empleado no tiene hijos, se lo da de alta en la tabla de empleados pero no en la de hijos.

Teora de las dependencias funcionales:

Dada una relacin: Rel (A1, A2, ..., An, B1, ..., Bm, C1, ..., Cp) Se dice que A1, A2, ... , An determinan funcionalmente B1, B2, ... , Bm A1, A2, ... , An B1, B2, ... , Bm x1, x2, ..., xn y1, y2, ... , ym z1, z2, ... , zm x1, x2, ..., xn y1, y2, ... , ym z1, z2, ... , zm, <x1, x2, ..., xn, y1, y2, ... , ym, z1, z2, ... , zl> Rel <x1, x2, ..., xn, y1, y2, ... , ym, z1, z2, ... , zl> Rel x1 = x1, x2 = x2, ... , xn = xn y1 = y1, y2 = y2, ... , yn = yn LL: lo que puede escribirse en forma abreviada como A B x, y, z x, y, z, <x, y, z > Rel <x, y, z > Rel x = x y = y SQL: o en la notacin con tuplas:

Pgina 25 de 34

136326711.doc A B r1 r2, A(r1) = A(r2) B(r1) = B(r2) En un caso concreto, se dice que el nmero de legajo determina la edad si cada vez que se da un mismo nmero de legajo, la edad debe ser la misma. Esto es una dependencia funcional al igual que la del nmero de legajo con el salario, mencionada en el apartado anterior. Pero no hay dependencia funcional entre el nmero de legajo y el nombre del hijo. No siempre la dependencia es as de sencilla. A veces necesita ms de un dato para determinar otro. Por ejemplo, para determinar una nota se necesita el nmero de padrn y la materia. nro_padron , materia nota Cmo se descubren las dependencias funcionales? Hablando con el cliente. Las dependencias existen en el mundo, simplemente hay que implementarlas. Estas relaciones son irreflexivas, es decir que si A B, no necesariamente, B A. La propiedades de las dependencias funcionales se deducen de su definicin. Las dependencias funcionales son relaciones entre conjuntos de atributos. Como tales puede decirse si son reflexivas, simtricas o transitivas.

Axiomas de Armstrong
De estos axiomas se desprenden todas las propiedades de las dependencias funcionales. i [1,n], A1, A2, , An Ai (reflexividad o dependencias triviales). a.-) A1, A2, , An B1, B2, , Bm A1, A2, , An B1 A1, A2, , An B2 A1, A2, , An Bm p q r s (p q r) (p q s) b.-) A1, A2, , An B1, B2, , Bm B1, B2, , Bm C1, C2, , Cm A1, A2, , An C1, C2, , Cm (transitividad). p q q r p r Armstrong descubri que cambiando por y , por tendra los mismos axiomas que la implicacin lgica. Otras propiedades: Dependencia completa: A determina funcionalmente a B en forma completa (full) si A (full) B A B A,A A/ A B (no hay subconjuntos de A que determinen a B) A (no full) B A B A, A A, C B Dependencia transitiva A determina B transitivamente por C si A (trans) B A B C, C A = C, C B = A B B C (en caso contrario se dice que la dependencia es no transitiva). A (no trans) B A B (A B) Superclaves: un conjunto de atributos C es superclave de la relacin R si A, A R C A Claves: un conjunto de atributos C es clave (mnima) de la relacin R si A, A R C A (C es superclave) y C, C C A, A R C A (o sea no contiene subconjuntos que sean [super]claves) ejmplo: dada la relacin: R(NL, ed, sal, hijo) con NL ed, sal. superclaves: (NL, ed, sal, hijo); (NL, ed, hijo); etc. clave mnima: (NL, hijo). Los atributos que dependen de las claves se dicen no primos.

Pgina 26 de 34

136326711.doc

Teorema Fundamental de la Descomposicin

La idea es reemplazar relacione complejas por otras mas simples. R(A,B,C) A,B (R) y A,C (R). Si la tabla original se obtiene a travs de la junta de la otra, es descomponible. A,B (R) | | : A=A A,C (R) Se dice que existe prdida de informacin si no se obtiene la tabla original. Sean las siguientes relaciones: R A, B A, C A B C A B A a1 b1 c1 a1 b1 a1 a1 b2 c2 a1 b2 a1 a2 b2 c2 a2 b2 a2 Ahora, haciendo un join (natural) de las dos ltimas se puede ver si hubo prdida de informacin. A, C A, B
(A=A)

C c1 c2 c2

A B C a1 b1 c1 a1 b1 c2 a1 b2 c1 a1 b2 c2 a2 b2 c2 Marcadas en negrita, se tienen las tuplas espurias, que no estaban en la relacin original R. Por qu ocurre esto? Cuando proyect hice una descomposicin con prdida, ya que al agregar tuplas me aparece que a ax le corresponde tambin b2. Perd informacin, por que antes saba que a a2 slo le corresponda b1, cosa que ahora no se. En general no se puede proyectar y luego hacer un join sin perder informacin. Hay un caso en que s se puede juntar y saber que va a quedar lo mismo que al principio. Esto es cuando A determina funcionalmente a B (es decir, A B) Teorema: En una relacin R(A, B, C) si A B o A C R = A, B A, C (o ms rigurosamente A, B, C ( A, B A, C) para eliminar el atributo A. Para que una relacin no tenga anomalas se debe normalizar proyectando (sin perder informacin), descomponiendo en tablas ms sencillas hasta normalizar todas las tablas.

Algoritmo de Beeri Berstein (mtodo matemtico)

Dado el siguiente conjunto F de dependencias funcionales: F = {A B, C; B D; C E, F} se llama clausura de dependencia transitiva de F (notacin F+) al conjunto de todas las dependencias que puedan deducirse a partir de ellas, a saber: F+ = {A B, C; A B; A C; A A(trivial); B D; A D;C E, F; C E; C F; A E, F; A E; A F; ; A C, D, E, F } Formalmente, F+ = {X Y / F A (por Armstrong) (se demuestra, se puede deducir) X Y}

Problema de la Pertenencia (membership)

Se plantea entonces el problema de la pertenencia o membership. La idea es determinar si una dependencia se puede deducir de F, esto es si pertenece a la clausura. Para saber si A B F+ 1. Se construye el conjunto {A} = U0. 2. Se revisan las dependencias: si A B A Ui Ui+1 = Ui B. 3. Si as se consigue agregar B si B Un A B F+

Pgina 27 de 34

136326711.doc (esto siempre tiene fin, por lo que es un algoritmo). Ejemplo: E A B,C BE DU UD EU {A,B} {A,B,C} {A,B,C,E} {A,B,C,E,U} {A,B,C,E,U,D} {E,D} {A,B,C,E,U,D} A,B E,D F+

Determinacin de superclaves
1. 2. 3. Formar cada subconjunto (no vaco) de atributos de A. Para cada conjunto (no vaco) de atributos B, ver si A B F+ Si B R, A B F+ A es (super)clave.

Bsqueda de claves mnimas

1. 2. 3. Listar todas las superclaves. Si A es superclave borrar todas las superclaves B tales que B A (propiamente incluidas). Si B / B es superclave (no fue borrada), A no es mnima.

Analizar si una dependencia es completa (full)

1. 2. 3. 4. Verificar que A B F+. Tomar todos los subconjuntos de A, sea A. Si A /A B F+ A (full) B. Si no ocurre para ninguna A A (full) B.

Analizar si una dependencia es transitiva

1. 2. 3. 4. Verificar que A B F+. Tomar todos los C / C A C B. Si C / A C F+C B F+ A (trans) B. Si no ocurre para ninguna A A (trans) B.

Teora de Formas Normales

Impide las anomalas pues no se pueden violar las restricciones. El diseo semntico se centra en el significado de los atributos, que representan el mundo real. A travs del anlisis semntico se descubren las relaciones y las dependencias funcionales. Se abren en tablas distintas segn estas condiciones para evitar las anomalas. Las primeras 4 formas normales, surgen del trabajo de Codd. Cada una involucra a todas las anteriores, adems de las particularidades que se detallan a continuacin. Analogamente se define el anlisis generalizado tomando todas las claves (no slo las mnimas).

Primera Forma Normal (1NF):

Todo atributo toma valores atmicos, o sea indivisibles. Se dice que un valor es atmico si sus registros no son de longitud variable. No cambiara mucha una base si se divide una fecha en tres campos: ao, mes, da. Por ejemplo, en el caso de la base de empleados, para pasarlo a 1FN se debe poner un registro por cada hijo.

Pgina 28 de 34

136326711.doc

Segunda Forma Normal (2NF):

No hay dependencias parciales, es decir, si C es clave primaria A, A R Primo(A) C (full) A. En el caso anterior, se debe sacar de la relacin al atributo hijo, ya que no determina a ninguno de los atributos no primos. Ejemplo 1: Suponemos que hemos probado que esta en 1FN R(A,B;C) A,B clave mnima. A,B C y A,B D Tomemos los atributos no primos C,D y veamos si se determinan FULL. Como A,B determina FULL a C,D entonces esta en 2FN. Ejemplo 2: R (A,B,C,D) A,B C,D D A Hay que verificar para toda la clave. Como hay ms de una clave no me alcanza verificar con una sola. No primos C D D, B A C Entonces no esta en 2FN Clave mnima A, B A,B > C? Si full A,B D? Si full D,B A? no full, pero D A full No vale la pena seguir

Tercera Forma Normal (3NF):

No hay dependencias transitivas fuera de las claves, es decir, A, A R Primo(A) / C (trans) A Ejemplo 1: R (A,B,C,D) A,B C C D A,B D No primos C D Entonces no esta en 3FN Clave mnima A, B A,B > C? Si trans A,B D? No trans

Forma Normal de Boyce-Codd (BCNF):

Es una generalizacin de la tercer forma normal. No siempre existe, ya que es muy difcil de encontrar computacionalmente. No hay dependencias transitivas, ni siquiera en las claves (sin tener en cuenta las dependencias triviales), es decir, A, A R / C (trans) A. Para toda la clave, todo atributo, depende no transitivamente de la clave (recordar que no toma en cuenta los triviales). Ejemplo: el tpico es el cdigo postal. CIUDAD, DIR COD POSTAL COD POSTAL CIUDAD CIUDAD, DIR Si Ciudad, Dir Cod Postal Ciudad, dir > Cod Postal NO trnas No Ciudad Ciudad, dir Ciudad NO trans Dir Ciudad, Dir Ciudad NO trans porque: Ciudad,Dir Cod Postal Cod Posta Ciudad No existe un mtodo matemtico para resolver este problema por lo que es poco prctico y no es necesario tomarlo en cuenta para el Coloquio.

Pgina 29 de 34

136326711.doc

Mtodo de normalizacin
Dada una relacin, llevarla a la forma normal. 1. Llevar R a 1FN: ver que los atributos tomen valores atmicos. Que haya registros de longitud fija. 2. Llevar R a 2FN: segn Codd, la idea es tomar una clave primaria. En el caso ms general, en cambio, se deben analizar todas las claves candidatas (Nota de la Ctedra: ste es el mtodo preferido). En cualquier caso, se verifica que para cada clave, la misma determine en forma completa a todos los atributos restantes. En los casos en que no se cumpla, se fracciona la relacin.. Por un lado la subclave con los atributos que determina y por el otro la misma subclave con los atributos restantes. Ejemplo: dada R(A, B, C, D) con A,B C, D , B, D A, C y D A se puede observar que B, D (full) A ya que slo con D alcanza para determinar A. El nuevo diseo es: R1(D, A); R2(D, B, C). El anlisis se repite (slo para R2 ya que las relaciones binarias siempre estn normalizadas) hasta llegar a que todas las relaciones estn en 2FN. 3. Llevar a 3FN: tambin aqu coexisten dos enfoques: el de Codd que slo toma para el anlisis las claves primarias y el ms general que observa todas las claves candidatas. Se trata de detectar las posibles dependencias transitivas y eliminarlas separando los atributos dependientes transitivamente (junto con aquellos de los que depende). La forma normal de Boyce Codd no siempre se puede obtener y el trabajo para encontrarla crece de manera exponencial, por lo que suele no buscarse. Ejemplo: dada R(A, B, C) con A C B A (trans) B. El nuevo diseo es: R1(A, C); R2(C, B). Si R2 fuera (A, C), se estara perdiendo la dependencia de B respecto de C. Esta descomposicin se denomina natural ya que permite reconstruir las dependencias originales. El anlisis se repite hasta llegar a que todas las relaciones estn en 3FN. Ejemplos: (pginas 33 a 35)

Hipergrafos:
Un grafo es un conjunto de elementos llamados nodos y una relacin binaria entre ellos. G = (N,R) R N^2 N^2: Es el producto cartesiano de los nodos. En un hipergrafo se generaliza la definicin a hiperarcos. G (N,R) R 2^n * N, donde 2^n es el conjunto potencial de N. Conjunto de nodos nodo a c Part(N) = {B/ B N} Ejemplo de un hipergrafo:
b

Donde <{a},b> es un arco simple, y es un caso particular de un hiper-arco, en donde sale de un solo nodo. Ejemplo con una relacin: R (A,B,C,D,E,F,G) A,B C,D C,E E,F F A,B EC Para que un conjunto de atributos determine a otro debe haber un hipercamino desde el nodo inicial al nodo final. A,B,E F? Cmo se halla un hipercamino? Cada hiper-arco se conecta con otro pero recorriendo las ramas del hiper-arco simultaneamente. AF

Pgina 30 de 34

136326711.doc B,A F me falta E Condiciones para determinar una clave mnima: Los nodos de donde salen arcos son candidatos a ser claves. Los nodos de donde salen y llegan arcos, pueden dar lugar a ms de una clave. Los nodos que solo reciben son candidatos a no ser claves. Y los nodos aislados siempre forman parte de la clave. Claves: - A,B,E,G - F,E,G La clave mnima es: E,G. Una vez halladas todas las claves mnimas empiezo a ver, si es full y transitivas. NOTA: la unin de todos los grafos devuelven el grafo original.

Base de Datos y Lgica:

Teora bsica: Conjunto de frmulas. TB. Cmo demostrar que es falso? E Ed IN 10 PE 20 P(IN,10) y P(IN,10) P(PE,20) y P(PE,10) CWA= Closed World Assumption = {F/FTb} Negar todas las condiciones que no estn en la tabla. UNA= Unique name Assumption: todas las constantes usadas de la tabla son distintas. = Ci Cj;i;j Sin esto no podra demostrar que 10 y 20 son dos edades y no una sola. En BD no se escriben las operaciones. Solo existen cosas mensionadas. CDA = Closed Domain Assumption = x: x=c1 o x=c2 o ... o x=cn. TBB = Tb CWA UNA CDA. Luego se analizaron la BDs con 3 valores de verdad: lgica ternaria. Conviene registrar la V y La indeterminada y tomar por default la F. BD Deductivas: La + moderna. Tambin BDOO. BD Relacionales: tablas o relacin ya vistas esquemas de relacin (R(A/D, ..., C/D).Condiciones de integridad: locales o globales. Condiciones: 1. Que las definiciones no sean contradictorias. 2. Que la base de datos sea estratificada (por estratos o capas). Ejemplos: A A1 A2 B B1 B2

Tb = R(a1,b1), R(a2,b2) CWA = {R(a1,a2), R(a1,b2), R(a1,a1),R(b1,b1),R(b1,b2),R(a2,b1),R(b2,b2)} UNA = a1 a2; a1 b1; a1 b2; b1 b2; a2 b1; a2 b2 CDA = x=a1 x=a2 x=b1 x=b2 TBB = {R(a1,b1) R(a2,b2); R(a1,a2); R(a1,b2); R(a1,b2); R(a1,b2) a1 a2 a1 b1 a1 b2 b1 b2 a2 b1a2 b2 x: x=a1 x=a2 x=b1 x=b2}

Pgina 31 de 34

136326711.doc Enunciados tipo examen: Dadas las sig. relaciones: producto (e, p) 1. mercado (p,m) Listar las empresas que ofrecen algn producto en todos los mercados.

En LL sera: {<e>/ p, m, mercado(p,m) producto(e,p)} hay 1, para todos. Todos los mercados un producto: p, m, ( mercado(p,m) producto(e,p)) p, m, mercado(p,m) producto(e,p) exists P2.p, not exists M1.m, not (P1.p = P2.p) and P2.p = M1.p En AR: e,m (PROD*MERC) % m (MERC) estas son las empresas que proveen algn producto en todos los mercados. En SQL: SELECT P1.E FROM PROD AS P1 WHERE EXISTS (SELECT P2.P FROM PROD AS P2 WHERE NOT EXISTS (SELECT M1.M FROM MER AS M1 WHERE NOT (P1.P = P2.P AND P2.P = M1.P))); 2. Listar las empresas que en todos los mercados ofrecen algn producto.

En LL sera: {<e>/ m, p, mercado(p,m) producto(e,p)} para cada uno, hay 1 de estos. Cada mercado algn producto: m, p, ( mercado(p,m) producto(e,p)) m, p, mercado(p,m) producto(e,p) not exists M1.m, not exists P2.p, not (P1.p = P2.p) and P2.p = M1.p En AR: e,m (PROD*MERC) % m (MERC) estas son las empresas que en todos los mercados ofrecen algn producto. En SQL: SELECT P1.E FROM PROD AS P1 WHERE NOT EXISTS (SELECT M1.M FROM MERC AS M1 WHERE NOT EXISTS (SELECT P2.P FROM PROD AS P2 WHERE NOT (P2.P = P1.P AND M1.P = P2.P));

Pgina 32 de 34

136326711.doc Dadas las sig. relaciones: Clau (p, m)(profesor, materia) 1. 2. 3. 4. 5. e p

Hor (m, t)(materia, turno)

Listar los competidores (que dictan las mismas materias) de Leopoldo Carranza. Listar los reemplazantes (que dictan todas las materias por lo menos) de Leopoldo Carranza. Listar los profesores intercambiables (que dictan exactamente las mismas materias) de Leopoldo Carranza. Listar los profesores que dictan una materiaen todos los turnos. Listar los profesores que en todo turno dan una materia. m SYS

6.

Pasar las tablas de Pro y Merc del diagrama relacional al diagrama en red 7. Qu diferencia hay entre el problema de seguridad y de privacidad? Uno es contra intrusin no deseada y el otro contra acceso no deseado. 8. Mencionar 3 tcnicas para proteger la privacidad. Palabra clave, cerradura y llave y criptografa. 9. Qu diferencia hay entre un Sistema de Manejo de Base de Datos y la Base de Datos en s? La Base de Datos es una coleccin de Datos. El SMBD es un conjunto de soft y hard que tiene que cumplir ciertas funciones de manejo sobre la base. 10. Diferencia entre Dato, informacin y conocimiento. El dato puede contener o no informacin. La informacin es una medida de cmo cambian las inferencias antes y despus de recibir el dato. El conocimiento es algo que me hace actuar de una forma que me demanda mi conducta. Coloquio de diciembre del 2001: Dadas las siguientes relaciones: Responder en LL, SQL y si es posible en AR. Match (jugadores, partidos, resultado) Campeonatos (Campeonatos, Partidos) Liga (Campeonato) 1. Listar los jugadores que en algn campeonato oficial resultaron invitados. 2. Listar los jugadores que ganaron por lo menos un partido en todos los campeonatos oficiales. 3. Listar error si jugadores > Partidos, resultados en Match. 4. 5. 6. Hacer el diagrama de red de los equipos del punto anterior. Con un tipo de registro J,P,R,C. Idem anterior sabiendo que: J,P R con P que son del tipo monocampeonato. Con Liga hacer teora de Base de Datos y demostrar que Res = {<x>/ C(a1) <> C1}={<C2>}

Pgina 33 de 34

136326711.doc

7. Normalizar: R (J,P,R,C,L) con J,P R,C ; R,C L y L J ; L P.

Pgina 34 de 34