Sunteți pe pagina 1din 28

UNIDAD 1 SISTEMAS DE BASES DE DATOS RELACIONALES. 1.1. Conceptos de bases de datos relacionales. 1.2. Normalizacin. 1.3.

Lenguajes de bases de datos relacionales. 1.4. Modelado de una base de datos. Introduccin al modelo relacional El principal objetivo del modelo de datos relacional es facilitar que la base de datos sea percibida o vista por el usuario como una estructura lgica que consiste en un conjunto de relaciones y no como una estructura fsica de implementacin. Esto ayuda a conseguir un alto grado de independencia de los datos. Un objetivo adicional del modelo es conseguir que esta estructura lgica con la que se percibe la base de datos sea simple y uniforme. Con el fin de proporcionar simplicidad y uniformidad, toda la informacin se representa de una nica manera: mediante valores explcitos que contienen las relaciones (no se utilizan conceptos como por ejemplo apuntadores entre las relaciones). Con el mismo propsito, todos los valores de datos se consideran atmicos; es decir, no es posible descomponerlos. El modelo relacional es un modelo de datos y, como tal, tiene en cuenta los tres aspectos siguientes de los datos: 1. La estructura, que debe permitir representar la informacin que nos interesa del mundo real. 2. La manipulacin, a la que da apoyo mediante las operaciones de actualizacin y consulta de los datos. 3. La integridad, que es facilitada mediante el establecimiento de reglas de integridad; es decir, condiciones que los datos deben cumplir. Estructura de los datos La estructura de los datos del modelo relacional se basa en el concepto de relacin. Se puede obtener una buena idea intuitiva de lo que es una relacin si la visualizamos como una tabla o un fichero. Cada fila de la tabla contiene una coleccin de valores de datos relacionados entre s; en nuestro ejemplo, son los datos correspondientes a un mismo empleado. La tabla tiene un nombre (EMPLEADOS) y tambin tiene un nombre cada una de sus columnas (DNI, nombre, apellido y sueldo). El nombre de la tabla y los de las columnas ayudan a entender el significado de los valores que contiene la tabla. Cada columna contiene valores de un cierto dominio; por ejemplo, la columna DNI contiene valores del dominio nmeros DNI.

Conjunto de relaciones Una base de datos relacional consta de un conjunto de relaciones, cada una de las cuales se puede visualizar de este modo tan sencillo. Dominios. Un dominio D es un conjunto de valores atmicos. Por lo que respecta al modelo relacional, atmico significa indivisible; es decir, que por muy complejo o largo que sea un valor atmico, no tiene una estructuracin interna para un SGBD relacional. Los dominios pueden ser de dos tipos: 1. Dominios predefinidos, que corresponde a los tipos de datos que normalmente proporcionan los lenguajes de bases de datos, como por ejemplo los enteros, las cadenas de caracteres, los reales, etc. 2. Dominios definidos por el usuario, que pueden ser ms especficos. Toda definicin de un dominio debe constar, como mnimo, del nombre del dominio y de la descripcin de los valores que forman parte de ste. El nombre de la relacin es EMPLEADOS y el conjunto de atributos es {DNI, nombre, apellido, sueldo}. Tomaremos la convencin de denotar el esquema de la relacin de la forma siguiente: R(A1, A2, ..., An), donde R es el nombre la relacin y A1, A2, ..., An es una ordenacin cualquiera de los atributos que pertenecen al conjunto {A1, A2, ..., An}. El esquema de la relacin de la figura anterior se podra denotar, por ejemplo, como EMPLEADOS(DNI, nombre, apellido, sueldo), o tambin, EMPLEADOS(nombre, apellido, DNI, sueldo), porque cualquier ordenacin de sus atributos se considera vlida para denotar el esquema de una relacin. El atributo DNI corresponde al papel que ejerce el dominio nmeros DNI en el esquema de la relacin EMPLEADOS y, entonces, dominio(DNI) = nmerosDNI. Cada atributo es nico en un esquema de relacin, porque no tiene sentido que un mismo dominio ejerza dos veces el mismo papel en un mismo esquema. Por consiguiente, no puede ocurrir que en un esquema de relacin haya dos atributos con el mismo nombre. En cambio, s que se puede repetir un nombre de atributo en relaciones diferentes. Los dominios de los atributos, por el contrario, no deben ser necesariamente todos diferentes en una relacin. Clave candidata, clave primaria y clave alternativa de las relaciones Toda la informacin que contiene una base de datos debe poderse identificar de alguna forma. En el caso particular de las bases de datos que siguen el modelo relacional, para identificar los datos que la base de datos contiene, se pueden utilizar las claves candidatas de las relaciones. A continuacin definimos qu se entiende por clave candidata, clave primaria y clave alternativa de una relacin. Para hacerlo, ser necesario definir el concepto de superclave: Una superclave de una relacin de esquema R(A1, A2, ..., An) es un subconjunto de los atributos del esquema tal que no puede haber dos tuplas en la extensin de la relacin que tengan la misma combinacin de valores para los atributos del subconjunto. En la relacin de esquema EMPLEADOS(DNI, NSS, nombre, apellido, telfono), algunas de las superclaves de la relacin seran los siguientes subconjuntos de atributos: {DNI, NSS, nombre, apellido, telfono}, {DNI, apellido}, {DNI} y {NSS}. Una clave candidata de una relacin es una superclave C de la relacin que cumple que ningn subconjunto propio de C es superclave. Es decir, C cumple que la eliminacin de cualquiera de sus atributos da un conjunto de atributos que no es superclave de la relacin. Intuitivamente, una clave candidata permite identificar cualquier tupla de una relacin, de manera que no sobre ningn atributo para hacer la identificacin. En la relacin de esquema EMPLEADOS(DNI, NSS, nombre, apellido, telfono), slo hay dos claves candidatas: {DNI} y {NSS}. Habitualmente, una de las claves candidatas de una relacin se designa clave primaria de la relacin. La clave primaria es la clave candidata cuyos valores se utilizarn para identificar las tuplas de la relacin. El diseador de la base de datos es quien elige la clave primaria de entre las claves candidatas. Las claves candidatas no elegidas como primaria se denominan claves alternativas.

En la relacin de esquema EMPLEADOS(DNI, NSS, nombre, apellido, telfono), donde hay dos claves candidatas, {DNI} y {NSS}, se puede elegir como clave primaria {DNI}. En este caso, la clave {NSS} ser una clave alternativa de EMPLEADOS. Es posible que una clave candidata o una clave primaria conste de ms de un atributo. Claves Forneas El mecanismo que proporcionan las bases de datos relacionales para conectar tuplas son las claves forneas de las relaciones. Las claves forneas permiten establecer conexiones entre las tuplas de las relaciones. Para hacer la conexin, una clave fornea tiene el conjunto de atributos de una relacin que referencian la clave primaria de otra relacin (o incluso de la misma relacin). La relacin EMPLEADOS(DNI, nombre, apellido, telfono, DNIjefe, edificiodesp, nmerodesp), tiene una clave fornea formada por los atributos edificiodesp y nmerodesp que se refiere a la clave primaria de la relacin DESPACHOS(edificio, nmero, superficie). Esta clave fornea indica, para cada empleado, el despacho donde trabaja. Adems, el atributo DNIjefe es otra clave fornea que referencia la clave primaria de la misma relacin EMPLEADOS, e indica, para cada empleado, quien es su jefe.

Las claves forneas tienen por objetivo establecer una conexin con la clave primaria que referencian. Por lo tanto, los valores de una clave fornea deben estar presentes en la clave primaria correspondiente, o bien deben ser valores nulos. En caso contrario, la clave fornea representara una referencia o conexin incorrecta. En la relacin de esquema EMPLEADOS(DNI, nombre, apellido, DNIjefe, edificiodesp, nmerodesp), la clave fornea {edificiodesp, nmerodesp} referencia la relacin DESPACHOS(edificio, nmero, superficie). De este modo, se cumple que todos los valores que no son nulos de los atributos edificiodesp y nmerodesp son valores que existen para los atributos edificio y nmero de DESPACHOS, tal y como se puede ver a continuacin:

Operaciones del Modelo Relacional a. b. c. d. Insercin (INSERT INTO), que sirve para aadir una o ms tuplas a una relacin. Borrado (DELETE), que sirve para eliminar una o ms tuplas de una relacin. Modificacin (UPDATE SET), que sirve para alterar los valores que tienen una o ms tuplas de una relacin para uno o ms de sus atributos. Filtro de consulta (SELECT). La consulta de los datos consiste en la obtencin de datos deducibles a partir de las relaciones que contiene la base de datos.

Segn la forma como se especifican las consultas, podemos clasificar los lenguajes relacionales en dos tipos: 1. Lenguajes basados en el lgebra relacional. El lgebra relacional se inspira en la teora de conjuntos. Si queremos especificar una consulta, es necesario seguir uno o ms pasos que sirven para ir construyendo, mediante operaciones del lgebra relacional, una nueva relacin que contenga los datos que responden a la consulta a partir de las relaciones almacenadas. Los lenguajes basados en el lgebra relacional son lenguajes procedimentales, ya que los pasos que forman la consulta describen un procedimiento. 2. Lenguajes basados en el clculo relacional. El clculo relacional tiene su fundamento terico en el clculo de predicados de la lgica matemtica. Proporciona una notacin que permite formular la definicin de la relacin donde estn los datos que responden la consulta en trminos de las relaciones almacenadas. Esta definicin no describe un procedimiento; por lo tanto, se dice que los lenguajes basados en el clculo relacional son lenguajes declarativos (no procedimentales). El lenguaje SQL, en las sentencias de consulta, combina construcciones del lgebra relacional y del clculo relacional con un predominio de las construcciones del clculo. Este predominio determina que SQL sea un lenguaje declarativo. Reglas de integridad Denominamos integridad la propiedad de los datos de corresponder a representaciones plausibles del mundo real. Por ejemplo un sueldo negativo en la relacin de esquema EMPLEADOS(DNI, nombre, apellido, sueldo), una tupla que tiene un valor de 1.000 para el sueldo probablemente no tiene sentido, porque los sueldos no pueden ser negativos. Las condiciones que garantizan la integridad de los datos pueden ser de dos tipos: 1. Las restricciones de integridad de usuario son condiciones especficas de una base de datos concreta; es decir, son las que se deben cumplir en una base de datos particular con unos usuarios concretos, pero que no son necesariamente relevantes en otra base de datos. Restriccin de integridad de usuario en EMPLEADOS: ste sera el caso de la condicin anterior, segn la cual los sueldos no podan ser negativos. Observa que la condicin era necesaria en la base de datos concreta de este ejemplo porque apareca el atributo sueldo, al que se quera dar un significado; sin embargo, podra no ser necesaria en otra base de datos diferente donde, por ejemplo, no hubiese sueldos. 2. Las reglas de integridad de modelo, en cambio, son condiciones ms generales, propias de un modelo de datos, y se deben cumplir en toda base de datos que siga dicho modelo. En el caso del modelo de datos relacional, habr una regla de integridad para garantizar que los valores de una clave primaria de una relacin no se repitan en tuplas diferentes. Denominamos integridad a la propiedad de los datos de corresponder a representaciones plausibles del mundo real de la relacin. Toda base de datos relacional debe cumplir esta regla que, por lo tanto, es una regla de integridad del modelo.

Regla de integridad de unicidad de la clave primaria

La regla de integridad de unicidad est relacionada con la definicin de clave primaria. Concretamente, establece que toda clave primaria que se elija para una relacin no debe tener valores repetidos.

En esta relacin, dado que la clave primaria est formada por edificio y nmero, no hay ningn despacho que repita tanto edificio como nmero de otro despacho. Sin embargo, s se repiten valores de edificio (por ejemplo, Marina); y tambin se repiten valores de nmero (120). A pesar de ello, el edificio y el nmero no se repiten nunca al mismo tiempo.

La regla de integridad de unicidad de la clave primaria establece que si el conjunto de atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede tener en ningn momento dos tuplas con la misma combinacin de valores para los atributos de CP. En la siguiente relacin no se debera poder insertar la tupla <Diagonal, 120, 30>, ni modificar la tupla <Marina, 122, 15>, de modo que pasara a ser <Marina, 120, 15>.

Regla de integridad de entidad de la clave primaria

La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una relacin no pueden tener valores nulos. Tenemos la siguiente relacin:

En esta relacin, puesto que la clave primaria est formada por edificio y nmero, no hay ningn despacho que tenga un valor nulo para edificio, ni tampoco para nmero. Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran distinguir. Ejemplo de clave primaria incorrecta con valores nulos. Si un despacho tuviese un valor nulo para edificio porque en un momento dado el nombre de este edificio no se conoce, por ejemplo <NULO, 120, 30>, la clave primaria no nos permitira distinguirlo del despacho <Marina, 120, 10> ni del despacho <Diagonal, 120,10>. No podramos estar seguros de que el valor desconocido de edificio no es ni Marina ni Diagonal. Regla de integridad referencial La regla de integridad referencial est relacionada con el concepto de clave fornea. Concretamente, determina que todos los valores que toma una clave fornea deben ser valores nulos o valores que existen en la clave primaria que referencia.

Donde edificiodesp y nmerodesp de la relacin EMPLEADOS forman una clave fornea que referencia la relacin DESPACHOS. Debe ocurrir que los valores no nulos de edificiodesp y nmerodesp de la relacin EMPLEADOS estn en la relacin DESPACHOS como valores de edificio y nmero. Por ejemplo, el empleado <40.444.255, Juan Garca, Marina, 120> tiene el valor Marina para edificiodesp, y el valor 120 para nmerodesp, de modo que en la relacin DESPACHOS hay un despacho con valor Marina para edificio y con valor 120 para nmero. Referencia incorrecta. Supongamos que en el ejemplo anterior hubiese un empleado con los valores <56.666.789, Pedro, Lpez, Valencia, 325>. Ya que no hay un despacho con los valores Valencia y 325 para edificio y nmero, la tupla de este empleado hace una referencia incorrecta; es decir, indica un despacho para el empleado que, de hecho, no existe. La regla de integridad referencial establece que si el conjunto de atributos CF es una clave fornea de una relacin R que referencia una relacin S (no necesariamente diferente de R), que tiene por clave primaria CP, entonces, para toda tupla t de la extensin de R, los valores para el conjunto de atributos CF de t son valores nulos, o bien valores que coinciden con los valores para CP de alguna tupla s de S. En el caso de que una tupla t de la extensin de R tenga valores para CF que coincidan con los valores para CP de una tupla s de S, decimos que t es una tupla que referencia s y que s es una tupla que tiene una clave primaria referenciada por t. Un SGBD relacional tendr que hacer cumplir esta regla de integridad. Deber efectuar comprobaciones cuando se produzcan las siguientes operaciones: a. Inserciones en una relacin que tenga una clave fornea. b. Modificaciones que afecten a atributos que pertenecen a la clave fornea de una relacin. c. Borrados en relaciones referenciadas por otras relaciones. d. Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relacin referenciada por otra relacin. Por ejemplo retomamos el ejemplo anterior, donde edificiodesp y nmerodesp de la relacin EMPLEADOS forman una clave fornea que referencia la relacin DESPACHOS:

Las siguientes operaciones provocaran el incumplimiento de la regla de integridad referencial: Insercin de <12.764.411, Jorge, Puig, Diagonal, 220> en EMPLEADOS. Modificacin de <40.444.255, Juan, Garca, Marina, 120> de EMPLEADOS por <40.444.255, Juan, Garca, Marina, 400>. Borrado de <Marina, 120, 10> de DESPACHOS. Modificacin de <Diagonal, 120, 10> de DESPACHOS por <Pars, 120, 10>. Un SGBD relacional debe procurar que se cumplan las reglas de integridad del modelo. Una forma habitual de mantener estas reglas consiste en rechazar toda operacin de actualizacin que deje la base de datos en un estado en el que alguna regla no se cumpla. En algunos casos, sin embargo, el SGBD tiene la posibilidad de aceptar la operacin y efectuar acciones adicionales compensatorias, de modo que el estado que se obtenga satisfaga las reglas de integridad, a pesar de haber ejecutado la operacin. Esta ltima poltica se puede aplicar en las siguientes operaciones de actualizacin que violaran la regla de integridad:

Borrado de una tupla que tiene una clave primaria referenciada. Modificacin de los valores de los atributos de la clave primaria de una tupla que tiene una clave primaria referenciada. En los casos anteriores, algunas de las polticas que se podrn aplicar sern las siguientes: restriccin, actualizacin en cascada y anulacin. Restriccin Ms concretamente, la restriccin en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave primaria referenciada por alguna clave fornea. De forma similar, la restriccin en caso de modificacin consiste en no permitir modificar ningn atributo de la clave primaria de una tupla si tiene una clave primaria referenciada por alguna clave fornea.

a. b.

a. b.

Si aplicamos la restriccin en caso de borrado y, por ejemplo, queremos borrar al cliente nmero 10, no podremos hacerlo porque tiene pedidos pendientes que lo referencian. Si aplicamos la restriccin en caso de modificacin y queremos modificar el nmero del cliente 15, no ser posible hacerlo porque tambin tiene pedidos pendientes que lo referencian.

Actualizacin en cascada La poltica de actualizacin en cascada consiste en permitir la operacin de actualizacin de la tupla, y en efectuar operaciones compensatorias que propaguen en cascada la actualizacin a las tuplas que la referenciaban; se acta de este modo para mantener la integridad referencial. Ms concretamente, la actualizacin en cascada en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave primaria referenciada, y borrar tambin todas las tuplas que referencian t. De forma similar, la actualizacin en cascada en caso de modificacin consiste en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y modificar del mismo modo todas las tuplas que referencian t.

Si aplicamos la actualizacin en cascada en caso de borrado y, por ejemplo, queremos borrar el edificio Diagonal, se borrar tambin el despacho Diagonal 120 que hay en el edificio, y nos quedar:

Si aplicamos la actualizacin en cascada en caso de modificacin, y queremos modificar el nombre del edificio Marina por Mar, tambin se cambiar Marina por Mar en los despachos Marina 120, Marina 122 y Marina 230, y nos quedar:

Anulacin Esta poltica consiste en permitir la operacin de actualizacin de la tupla y en efectuar operaciones compensatorias que pongan valores nulos a los atributos de la clave fornea de las tuplas que la referencian; esta accin se lleva a cabo para mantener la integridad referencial. Puesto que generalmente los SGBD relacionales permiten establecer que un determinado atributo de una relacin no admite valores nulos, slo se puede aplicar la poltica de anulacin si los atributos de la clave fornea s los admiten. Ms concretamente, la anulacin en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos. De forma similar, la anulacin en caso de modificacin consiste en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos.

Si aplicamos la anulacin en caso de borrado y, por ejemplo, queremos borrar al vendedor nmero 1, se modificarn todos los clientes que lo tenan asignado, y pasarn a tener un valor nulo en vendedorasig. Nos quedar:

Si aplicamos la anulacin en caso de modificacin, y ahora queremos cambiar el nmero del vendedor 2 por 5, se modificarn todos los clientes que lo tenan asignado y pasarn a tener un valor nulo en vendedorasig. Nos quedar:

El diseador puede elegir para cada clave fornea qu poltica se aplicar en caso de borrado de la clave primaria referenciada, y cul en caso de modificacin de sta. El diseador deber tener en cuenta el significado de cada clave fornea concreta para poder elegir adecuadamente.

Regla de integridad de dominio 1. La primera condicin consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai).

Ejemplo 1.Si en la relacin EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningn empleado que tenga por DNI el valor Luis, que no es un entero. Ejemplo 2. Supongamos ahora que en la relacin EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(edademp) es el dominio definido por el usuario edad. Supongamos tambin que el dominio edad se ha definido como el conjunto de los enteros que estn entre 16 y 65. En este caso, por ejemplo, no ser posible insertar un empleado con un valor de 90 para edademp. 2. Esta segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un operador determinado slo se puede aplicar sobre valores que tengan dominios que le sean adecuados.

Ejemplo 1. Analizaremos esta segunda condicin de la regla de integridad de dominio con un ejemplo concreto. Si en la relacin EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no se permitir consultar todos aquellos empleados cuyo DNI sea igual a Elena (DNI = Elena). El motivo es que no tiene sentido que el operador de comparacin = se aplique entre un DNI que tiene por dominio los enteros, y el valor Elena, que es una serie de caracteres. Ejemplo 2. Veamos otro ejemplo con dominios definidos por el usuario. Supongamos que en la conocida relacin EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio definido por el usuario nmerosDNI y que dominio(edademp) es el dominio definido por el usuario edad. Supongamos que nmerosDNI corresponde a los enteros positivos y que edad corresponde a los enteros que estn entre 16 y 65. En este caso, ser incorrecto, por ejemplo, consultar los empleados que tienen el valor de DNI igual al valor de edademp. El motivo es que, aunque tanto los valores de DNI como los de edademp sean enteros, sus dominios son diferentes; por ello, segn el significado que el usuario les da, no tiene sentido compararlos. Sin embargo, los actuales SGBD relacionales no dan apoyo a la segunda condicin de la regla de integridad de dominio para dominios definidos por el usuario. Si se quisiera hacer, sera necesario que el diseador tuviese alguna forma de especificar, para cada operador que se desease utilizar, para qu combinaciones de dominios definidos por el usuario tiene sentido que se aplique. El lenguaje estndar SQL no incluye actualmente esta posibilidad. UNIDAD 2 REDES DE COMPUTADORAS. 2.1. Conceptos de comunicacin de datos.

2.2. Tipos de redes.

Topologas ms comunes Red en anillo. Topologa de red en la que las estaciones se conectan formando un anillo. Cada estacin est conectada a la siguiente y la ltima est conectada a la primera. Cada estacin tiene un receptor y un transmisor que hace la funcin de repetidor, pasando la seal a la siguiente estacin del anillo. En este tipo de red la comunicacin se da por el paso de un token o testigo, que se puede conceptualizar como un cartero que pasa recogiendo y entregando paquetes de informacin, de esta manera se evita perdida de informacin debido a colisiones. Cabe mencionar que si algn nodo de la red se cae (termino informtico para decir que est en mal funcionamiento o no funciona para nada) la comunicacin en todo el anillo se pierde. 4 Red en rbol. Topologa de red en la que los nodos estn colocados en forma de rbol. Desde una visin topolgica, la conexin en rbol es parecida a una serie de redes en estrella interconectadas. Es una variacin de la red en bus, la falla de un nodo no implica interrupcin en las comunicaciones. Se comparte el mismo canal de comunicaciones. Cuenta con un cable principal (backbone) al que hay conectadas redes individuales en bus.

Red en malla. La Red en malla es una topologa de red en la que cada nodo est conectado a uno o ms de los otros nodos. De esta manera es posible llevar los mensajes de un nodo a otro por diferentes caminos. Si la red de malla est completamente conectada no puede existir absolutamente ninguna interrupcin en las comunicaciones. Cada servidor tiene sus propias conexiones con todos los dems servidores. Red en bus. Topologa de red en la que todas las estaciones estn conectadas a un nico canal de comunicaciones por medio de unidades interfaz y derivadores. Las estaciones utilizan este canal para comunicarse con el resto. La topologa de bus tiene todos sus nodos conectados directamente a un enlace y no tiene ninguna otra conexin entre nodos. Fsicamente cada host est conectado a un cable comn, por lo que se pueden comunicar directamente, aunque la ruptura del cable hace que los hosts queden desconectados. La topologa de bus permite que todos los dispositivos de la red puedan ver todas las seales de todos los dems dispositivos, lo que puede ser ventajoso si desea que todos los dispositivos obtengan esta informacin. Sin embargo, puede representar una desventaja, ya que es comn que se produzcan problemas de trfico y colisiones, que se pueden paliar segmentando la red en varias partes. Es la topologa ms comn en pequeas LAN, con hub o switch final en uno de los extremos. Red en estrella. Red en la cual las estaciones estn conectadas directamente al servidor u ordenador y todas las comunicaciones se han de hacer necesariamente a travs de l. Todas las estaciones estn conectadas por separado a un centro de comunicaciones, concentrador o nodo central, pero no estn conectadas entre s. Esta red crea una mayor facilidad de supervisin y control de informacin ya que para pasar los mensajes deben pasar por el hub o concentrador, el cual gestiona la redistribucin de la informacin a los dems nodos. La fiabilidad de este tipo de red es que el malfuncionamiento de un ordenador no afecta en nada a la red entera, puesto que cada ordenar se conecta independientemente del hub, el costo del cableado puede llegar ser muy alto. Su punto dbil consta en el hub ya que es el que sostiene la red en uno. Red Inalmbrica Wi-Fi. Wi-Fi es una marca de la Wi-Fi Alliance (anteriormente la Wireless Ethernet Compatibility Alliance), la organizacin comercial que prueba y certifica que los equipos cumplen los estndares IEEE 802.11x. Las nuevas redes sin cables hacen posible que se pueda conectar a una red local cualquier dispositivo sin necesidad de instalacin, lo que permite que nos podamos pasear libremente por la oficina con nuestro ordenador porttil conectado a la red o conectar sin cables cmaras de vigilancia en los lugares ms inaccesibles. Tambin se puede instalar en locales pblicos y dar el servicio de acceso a Internet sin cables. La norma IEEE 802.11b dio carcter universal a esta tecnologa que permite la conexin de cualquier equipo informtico a una red de datos Ethernet sin necesidad de cableado, que actualmente se puede integrar tambin con los equipos de acceso ADSL para Internet. Uno de los problemas ms graves a los cuales se enfrenta actualmente la tecnologa WiFi es la seguridad. Un muy elevado porcentaje de redes se han instalado por administradores de sistemas o de redes por su simplicidad de implementacin, sin tener en consideracin la seguridad y por tanto han convertido sus redes en redes abiertas, sin proteger el acceso a la informacin que por ellas circulan. Existen varias alternativas 7para garantizar la seguridad de estas redes, las ms comunes son la utilizacin de protocolos de encriptacin de datos como el WEP y el WPA, proporcionados por los propios dispositivos inalmbricos, o IPSEC (tneles IP) y 802.1x, proporcionados por o mediando otros dispositivos de la red de datos. Red celular. La topologa celular est compuesta por reas circulares o hexagonales, cada una de las cuales tiene un nodo individual en el centro. La topologa celular es un rea geogrfica dividida en regiones (celdas) para los fines de la tecnologa inalmbrica. En esta tecnologa no existen enlaces fsicos; silo hay ondas electromagnticas. La ventaja obvia de una topologa celular (inalmbrica) es que no existe ningn medio tangible aparte de la atmsfera terrestre o el del vaco del espacio exterior (y los satlites). Las desventajas son que las seales se encuentran presentes en cualquier lugar de la celda y, de ese modo, pueden sufrir disturbios y violaciones de seguridad. Como norma, las topologas basadas en celdas se integran con otras topologas, ya sea que usen la atmsfera o los satlites. Red en Bus: 802.3 Ethernet. Norma o estndar (IEEE 802.3) que determina la forma en que los puestos de la red envan y reciben datos sobre un medio fsico compartido que se comporta como un bus lgico

independientemente de su configuracin fsica. Originalmente fue diseada para enviar datos a 10 Mbps, aunque posteriormente ha sido perfeccionada para trabajar a 100 Mbps, 1 Gbps o 10 Gbps y se habla de versiones futuras de 40 Gbps y 100 Gbps. En sus versiones de hasta 1 Gbps utiliza el protocolo de acceso al medio CSMA/CD (Carrier Sense Multiple Access / Collision Detect - Acceso mltiple con deteccin de portadora y deteccin de colisiones). Actualmente Ethernet es el estndar ms utilizado en redes locales/LANs. Ethernet fue creado por Robert Metcalfe y otros en Xerox Parc, centro de investigacin de Xerox para interconectar computadoras Alto. El diseo original funcionaba a 1 Mbps sobre cable coaxial grueso con conexiones vampiro (que "muerden" el cable). Para la norma de 10 Mbps se aadieron las conexiones en coaxial fino (10Base2, tambin de 50 ohmios, pero ms flexible), con tramos conectados entre si mediante conectores BNC; par trenzado categora 3 (10BaseT) con conectores RJ45, mediante el empleo de hubs y con una configuracin fsica en estrella; e incluso una conexin de fibra ptica (10BaseF). Los estndares sucesivos (100 Mbps o Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet) abandonaron los coaxiales dejando nicamente los cables de par trenzado sin apantallar (UTP - Unshielded Twisted Pair), de categoras 5 y superiores y la Fibra ptica. 2.3. Consecuencia del empleo de redes y sus protocolos en bases de datos distribuidas. La informacin de directorio puede dejarse disponible mediante interfaces Web, como hacen muchas organizaciones y, en especial, las compaas telefnicas. Estas interfaces son buenas para las personas que las utilizan. Sin embargo, tambin los programas necesitan tener acceso a la informacin de directorio. Los directorios pueden utilizarse para almacenar otros tipos de informacin, de manera parecida a como hacen los directorios del sistema. Por ejemplo, los exploradores Web pueden almacenar marcas personales de favoritos y otros parmetros del explorador en el sistema de directorios. Por tanto, los usuarios pueden tener acceso a los mismos parmetros desde varias ubicaciones, por ejemplo, desde casa y desde el trabajo, sin tener que compartir un sistema de archivos. Se han desarrollado varios protocolos de acceso a directorios para ofrecer una manera normalizada de acceso a los datos de los directorios. Entre ellos, el ms utilizado hoy en da es el protocolo de acceso ligero a directorios (Lightweight Directory Access Protocol, LDAP). Evidentemente, todos los tipos de datos pueden almacenarse sin demasiados problemas en sistemas de bases de datos y se puede tener acceso a ellos mediante protocolos como JDBC u ODBC. La pregunta, entonces, es el motivo de crear un protocolo especializado para el acceso a la informacin de directorio. En primer lugar, los protocolos de acceso a directorios son protocolos simplificados que atienden a un tipo limitado de acceso a los datos. Han evolucionado en paralelo con los protocolos de acceso a las bases de datos. En segundo lugar, y lo que es ms importante, los sistemas de directorio ofrecen un mecanismo sencillo para nombrar a los objetos de manera jerrquica, parecida a los nombres de directorios de los sistemas de archivos, que pueden utilizarse en un sistema distribuido de directorio para especificar la informacin que se almacena en cada servidor de directorio. Por ejemplo, puede que un servidor de directorio concreto almacene la informacin de los empleados de Laboratorios Bell en Cceres y que otro almacene la informacin de los empleados de Laboratorios Bell, lo que da a ambos sitios autonoma para controlar sus datos locales. Se puede utilizar el protocolo de acceso al directorio para obtener datos de los dos directorios por la red. Lo que es ms importante, el sistema de directorios puede configurarse para que enve de manera automtica a un sitio las consultas formuladas en el otro, sin intervencin del usuario.

UNIDAD 3 BASES DE DATOS DISTRIBUIDAS. 3.1. Bases de datos distribuidas. 3.2. reas de investigacin en bases de datos distribuidas. 3.3. Arquitectura de un sistema manejador de bases de datos distribuida.

El incremento de la globalizacin y el clima ms competitivo ha hecho necesario que las compaas internacionales trabajen de una nueva manera, que maximicen sus sinergias entre sus diferentes unidades de negocios, ingeniera y proyectos alrededor del mundo. Con la explosiva popularidad de la Internet y el world wide web (WWW) hay una necesidad de crecimiento rpido para suministrar acceso sin precedente a fuentes de datos distribuidas globalmente a travs de la Internet. La integracin de los datos dispersos en diferentes sitios para ser accedidos a travs del web, puede requerir de nuevas arquitecturas y herramientas de software para el desarrollo de estos sistemas. Diferentes empresas se han visto en la necesidad de integrarse a estas nuevas tecnologas. Esta necesidad ha creado una fuerte demanda por capacidades de acceso a bases de datos a travs de la Internet Los sistemas distribuidos de bases de datos consisten en un conjunto de sitios, cada uno de los cuales mantiene un sistema local de bases de datos. Cada sitio puede procesar las transacciones locales: las transacciones que slo tienen acceso a datos de ese sitio. Adems, cada sitio puede participar en la ejecucin de transacciones globales, las transacciones que tienen acceso a los datos de varios sitios. La ejecucin de las transacciones globales necesita que haya comunicacin entre los sitios. Muchas organizaciones son descentralizadas y los usuarios de los sistemas de informacin en estas corporaciones como en los bancos, grupos industriales, servicios nacionales de salud y educacin ven ms til un enfoque de base distribuida que refleje la estructura de la organizacin. Esto ha podido ocurrir con el desarrollo reciente de tecnologas de cmputo, la presin ejercida por los usuarios y el advenimiento de las nuevas tecnologas de comunicacin. Se deben tomar en cuenta varios factores para la definicin de la arquitectura de un sistema: 1. 2. 3. Distribucin: Los componentes del sistema estn localizados en la misma computadora o en diferente computador. Heterogeneidad: Es cuando existen en l componentes que se ejecutan en diversos sistemas operativos. Autonoma: Se puede presentar en diferentes niveles, como son: a. b. c. Autonoma de diseo: Est relacionadas a su propio diseo. Autonoma de comunicacin: Es cmo y cundo comunicarse con otros SMBD. Autonoma de ejecucin: Ejecutar operaciones locales como quiera.

No existe un equivalente de una arquitectura estndar para sistemas de manejo de bases de datos distribuidas, cada sistema ha adoptado su propia arquitectura. Se debe definir un modelo de referencia para un esquema de estandarizacin en bases de datos distribuidas, cuyo propsito es dividir el trabajo en piezas y esas piezas se relacionan unas con otras. Se sigue los siguientes enfoques: 1. 2. 3. Basado en componentes. Se definen las componentes del sistema junto con las relaciones entre ellas. Basado en funciones. Se identifican las diferentes clases de usuarios junto con la funcionalidad que el sistema ofrecer para cada clase. Basado en datos. Se identifican los diferentes tipos de descripcin de datos y se especifica un marco de trabajo arquitectural el cual define las unidades funcionales que realizarn y usarn los datos de acuerdo con las diferentes vistas.

Los sistemas de datos distribuidos estn divididos en dos clases: 1. Sistemas de manejo de bases de datos distribuidos homogneos. Los sistemas homogneos se parece a un sistema centralizado, a diferencia que estos sus datos se distribuyen en varios sitios comunicados por la red. No existen usuarios locales y todos ellos accesan a la base de datos a travs de una interfaz global.

2.

Sistemas de manejo de bases de datos distribuidos heterogneos. Un sistema multibases de datos tiene mltiples SGDB, que pueden ser de tipos diferentes, y mltiples bases de datos existentes. Existen usuarios locales y globales.

El esquema de fragmentacin describe la forma en que las relaciones globales se dividen entre las bases de datos locales. El esquema de asignacin especifica el lugar en el cual cada fragmento es almacenado. De aqu, los fragmentos pueden migrar de un sitio a otro en respuesta a cambios en los patrones de acceso.

1. Arquitectura basada en componentes de un SGDB de datos distribuidos El procesador de usuario es el encargado de procesar las solicitudes del usuario, consiste en cuatro partes: un manejador de la interfaz con el usuario, un controlador semntico de datos, un optimizador global de consultas y un supervisor de la ejecucin global. El procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un esquema local conceptual y un esquema local interno, el procesador de datos consiste de tres partes: un procesador de consultas locales, un gestor de recuperacin de fallas locales y un procesador de soporte para tiempo de ejecucin.

2. Arquitectura basada en componentes de un sistema multibases de datos

Consta de un sistema de manejo de bases datos para usuarios globales y usuarios locales. Para comunicar el sistema global con los sistemas locales se define una interfaz comn entre componentes mediante la cual, las operaciones globales se convierten en una o varias acciones locales. Transparencia Se refiere a la divisin del nivel semntico y la implementacin del sistema. El objetivo es ocultar al usuario los detalles de diseo, es decir, el usuario no tiene que saber que se encuentra trabajando sobre un sistema distribuido, por ejemplo la independencia de los datos es una forma de transparencia El propsito fundamental de la transparencia en el ambiente distribuido es la independencia de datos. La transparencia la podemos encontrar en: Manejo de la red de comunicacin. Manejo rplicas En la distribucin o fragmentacin de la informacin.

Independencia de datos Es la inmunidad de las aplicaciones de usuarios a los cambios en la definicin y organizacin de los datos y viceversa. La independencia de datos se puede darse en dos aspectos: lgico y fsico. 1. Independencia lgica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lgica de la base de datos. Esto permite que un cambio en la definicin de un esquema no debe afectar a las aplicaciones de usuario. Por ejemplo, el agregar un nuevo atributo a una relacin, la creacin de una nueva relacin, el reordenamiento lgico de algunos atributos. Independencia fsica de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripcin fsica de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organizacin de los datos puede cambiar.

2.

Niveles de transparencia El propsito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la informacin. Primer Nivel. Se soporta la transparencia de red. Segundo Nivel. Se permite la transparencia de replicacin de datos. Tercer Nivel. Se permite la transparencia de la fragmentacin. Cuarto Nivel. Se permite transparencia de acceso (por medio de un lenguaje de manipulacin de datos) Transparencia de localizacin La trasparencia de localizacin le permite acceder al usuario a los datos sin tener en cuenta la ubicacin de estos, es decir debe ser transparente al usuario, ya q este no necesita saber dnde est el dato para utilizarlo. Se consigue cuando los administradores de transacciones distribuidas pueden determinar la localizacin de los datos y emitir acciones a los administradores apropiados, esto se puede ejecutar cuando los administradores de transacciones tienen acceso a los directorios de localizaciones de los datos. Los administradores de transacciones necesitan conocer si los datos cambian de lugar, ya que las transacciones ignoran la modificacin en la localizacin. Transparencia de fragmentacin

El acceso a una base de datos distribuida debe hacerse en forma transparente. Los usuarios deben comportarse, como si los datos en realidad no estuvieran fragmentados, lo cual es necesario por razones de rendimiento. El programador no necesita saber si la base de datos es distribuida o est fragmentada. Los accesos a la base de datos es de forma global, es decir el usuario no necesita especificar los nombres de los fragmentos ni la ubicaciones de los datos. El sistema maneja la conversin de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. Las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global.

Transparencia de rplica La transparencia sobre replicacin de datos se refiere a que si existen rplicas de objetos de la base de datos, esta debe ser controlada por el SGDB, ms no por el usuario. El usuario no necesita saber sobre la replicacin de los datos, la funcin principal de la transparencia de replicacin es la de mantener la consistencia entre las copias, esta funciona en forma transparente a las aplicaciones. La replicacin puede mejorar el funcionamiento y proteger la disponibilidad de las aplicaciones, porque alterna opciones de acceso de los datos existente. Existe una copia principal y varias copias secundarias, las que se extienden a lo largo de las modificaciones en forma asncrona. Existen dos tipos de propagacin de modificaciones: Incremental: La informacin que se enva desde la copia principal a las secundarias son las variaciones en los datos. Total: Se enva toda la copia principal completa.

Su principal utilidad es hacer que el sistema sea menos sensible a los fallos, ya que si la copia principal no est disponible se puede seguir usando alguna de las copias secundarias.

La replicacin es necesaria por las siguientes razones: Mayor rendimiento, debido a que se dispone de copias locales. Mayor disponibilidad, ya que los datos son accesibles siempre al tenerse varias copias.

La principal desventaja, es que hay que mantener actualizadas todas las copias de ese objeto o dato replicado. Esto nos lleva al problema de la propagacin de las actualizaciones.

Formas de rplica

Las rplicas pueden asumir los siguientes formatos: Peridica

Continua

Check-in / Check-out

Creacin de rplicas Es posible crear rplicas completas o parciales: Rplica completa: Contiene todos los documentos y elementos de diseo de la base de datos como son: formularios y agentes. Rplica parcial: Contiene documentos abreviados, resmenes de documentos o documentos cuyos campos contienen informacin especificada, documentos preseleccionados, documentos de carpetas o vistas especificadas. Este tipo de rplica le resultar til cuando slo necesite una parte de la base de datos y quiere ahorrar espacio en el disco. NOTA: Las rplicas que no contienen documentos se denominan rplicas vacas. Si intenta abrir una rplica vaca, se mostrar un mensaje diciendo que la base de datos no est inicializada y debe replicarse. Ventajas Disponibilidad frente a fallos de la red. Paralelismo, las peticiones se pueden procesar en varios nodos en paralelo. Transferencia de datos reducida

Desventajas Se eleva el coste de la actualizaciones Se complica el control de la concurrencia Considrese una relacin r que hay que almacenar en la base de datos. Hay dos enfoques del almacenamiento de esta relacin en la base de datos distribuida: Rplica. El sistema conserva rplicas (copias) idnticas de la relacin y guarda cada rplica en un sitio diferente. La alternativa a las rplicas es almacenar slo una copia de la relacin r. Ventajas y desventajas: o o Disponibilidad. Si alguno de los sitios que contiene la relacin r falla, la relacin puede hallarse en otro sitio distinto. Por tanto, el sistema puede seguir procesando las consultas que impliquen a r, pese al fallo del sitio. Paralelismo incrementado. En caso de que la mayora de los accesos a la relacin r slo resulten en la lectura de la relacin, varios sitios pueden procesar en paralelo las lecturas que impliquen a r. Cuantas ms rplicas de r haya, mayor ser la posibilidad de que los datos necesarios se hallen en el sitio en que se ejecuta la transaccin. Por tanto, la rplica de los datos minimiza el movimiento de los datos entre los sitios.

Sobrecarga incrementada durante la actualizacin. El sistema debe asegurar que todas las rplicas de la relacin r sean consistentes; en caso contrario pueden producirse cmputos errneos. Por eso, siempre que se actualiza r, hay que propagar la actualizacin a todos los sitios que contienen rplicas. El resultado es una sobrecarga incrementada. Por ejemplo, en un sistema bancario, en el que se replica en varios sitios la informacin de las cuentas, es necesario asegurarse de que el saldo de cada cuenta concuerde en todos los sitios.

Fragmentacin. El sistema divide la relacin en varios fragmentos y guarda cada fragmento en un sitio diferente. o En la fragmentacin horizontal la relacin r se divide en varios subconjuntos, r1, r2, . . . , rn. Cada tupla de la relacin r debe pertenecer como mnimo a uno de los fragmentos, de modo que se pueda reconstruir la relacin original, si fuera necesario. o La fragmentacin vertical de r (R) implica la definicinde varios subconjuntos de atributos R1, R2, . . ., Rn del esquema R de modo que R = R1 R2 Rn

Se pueden aplicar los dos tipos de fragmentacin a un solo esquema; por ejemplo, los fragmentos obtenidos de la fragmentacin horizontal de una relacin pueden dividirse nuevamente de manera vertical. Los fragmentos tambin pueden replicarse. En general, los fragmentos pueden replicarse, las rplicas de los fragmentos pueden fragmentarse ms. Hay dos tipos de transacciones que se deben considerar. Las transacciones locales son las que tienen acceso a los datos y los actualizan slo en una base de datos local; las transacciones globales son las que tienen acceso a datos y los actualizan en varias bases de datos locales.

Cada sitio tiene su propio gestor local de transacciones, cuya funcin es asegurar las propiedades ACID (Atomicity, Consistency, Isolation y Durability).de las transacciones que se ejecuten en ese sitio. Los diferentes gestores de transacciones colaboran para ejecutar las transacciones globales El gestor de transacciones administra la ejecucin de las transacciones (o subtransacciones) que tienen acceso a los datos almacenados en un sitio local. Tngase en cuenta que cada una de esas transacciones puede ser una transaccin local (es decir, una transaccin que se ejecuta slo en ese sitio) o parte de una transaccin global (es decir, una transaccin que se ejecuta en varios sitios). El coordinador de transacciones coordina la ejecucin de las diferentes transacciones (tanto locales como globales) iniciadas en ese sitio. Modos de fallo del sistema Los sistemas distribuidos pueden sufrir los mismos tipos de fallos que los sistemas centralizados (por ejemplo, errores de software, errores de hardware y fallos de discos). No obstante, hay ms tipos de fallos con los que hay que tratar en los entornos distribuidos. Los tipos bsicos de fallos son

Fallo de un sitio Prdida de mensajes Fallo de un enlace de comunicaciones Divisin de la red

La prdida o deterioro de los mensajes siempre constituye una posibilidad en los sistemas distribuidos. El sistema utiliza protocolos de control de las transmisiones, como TCP/IP, para tratar esos errores. Si hay que asegurar la atomicidad, todos los sitios en los que se ejecute una transaccin T deben coincidir en el resultado final de la ejecucin. T debe comprometerse en todos los sitios o abortarse en todos los sitios. Para asegurar esta propiedad el coordinador de transacciones de T debe ejecutar un protocolo de compromiso. Entre los protocolos de compromiso ms sencillos y ms utilizados est el protocolo de compromiso de dos fases (C2F). Una alternativa es el protocolo de compromiso de tres fases (C3F), que evita ciertos inconvenientes del protocolo C2F pero aade complejidad y sobrecarga.

UNIDAD 4 ASPECTOS DE DISEO EN UNA BASE DE DATOS DISTRIBUIDA. 4.1. Fragmentacin. 4.2. Tipos de fragmentacin. 4.3. Localizacin. 4.4. Manejo de vistas en bases de datos distribuidas. 4.5. Diseo de bases de datos distribuidas. UNIDAD 5 OTROS MODELOS DE BASES DE DATOS. 5.1. Bases de datos distribuidas heterogneas. 5.2. Sistemas de bases de datos paralelas. 5.3. Conceptos generales. 5.4. Tendencias actuales de los diferentes tipos de base de datos.

S-ar putea să vă placă și