Modulo Base Datos

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA
I.
MODELADO DE DATOS
Es el proceso de crear un Modelo especfico de datos para el dominio de un problema determinado. Un dominio de problema se refiere a la definicin del ambiente real claramente con fronteras bien limitados. Un modelo de datos es un conjunto de conceptos que pueden ser usados para describir, disear la estructura de una Base de Datos (BD). Con el concepto de estructura de una BD nos referimos a los tipos de datos, las relaciones, las restricciones que deben cumplirse, y las operaciones de manipulacin de los datos (agregado, borrado, modificacin y recuperacin de los datos de la base). Los objetivos del diseo de base de datos son: Representar los datos que requieren las principales reas de aplicacin y los grupos de usuarios, y representar las relaciones entre dichos datos. Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos. Especificar un esquema que alcance las prestaciones requeridas para el sistema. Hay varias estrategias a seguir para realizar el diseo: de abajo a arriba, de arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de arriba abajo es ms apropiada cuando se trata de bases de datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar tambin otros conceptos, asociados con los que se han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de divide y vencers. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se integran despus para obtener el modelo final. Clasificacin en funcin del nivel de abstraccin: En general los modelos de datos pueden dividirse o ms bien clasificarse en: conceptuales, lgicos y fsicos. En la figura 1 podemos observar esta visin general.
ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS
Usuarios
Nivel Conceptual (parcial o integrado) Diseo Conceptual (Definicin del modelo de datos conceptual)
Software A
Software B
Software n
SGBD (DBMS) Servicios que permiten gestionar: transacciones, concurrencia, accesos, restricciones, archivos, optimizar consultas, etc.
Nivel Lgico (esquema) Diseo Lgico (Definicin del esquema)
DDL
DML
Diccionario de datos (Meta-datos)
Base de datos almacenada
Nivel Fsico (interno) Diseo Fsico (Definiciones de almacenamiento y de configuracin de parmetros del DBMS)
Sistema Operativo
Figura 1: Clasificacin en funcin del nivel de abstraccin. a. Los modelos de datos conceptuales son aquellos que describen las estructuras de datos y restricciones de integridad. Se utilizan durante la etapa de anlisis de un problema dado y estn orientados a representar los elementos que intervienen y sus relaciones.
SISTEMA OBJETO
Visin usuario A Visin usuario N
Sub Modelo de Datos A Sub Modelo de Datos B Sub Modelo de Datos N
Visin usuario B
MODELO DE DATOS CONCEPTUAL
Personas Operaciones Materiales Documentos Computadoras
Entidades (atributos, claves, etc) Relaciones (Cardinalidad, dependencias, etc) Restricciones (dominio, relaciones, etc) ------------------------------------------------------------- Normalizacin y otros criterios de diseo
Figura 2: Modelo de Datos Conceptual
b. Los modelos de datos lgicos se centran en las operaciones y se implementan en algn manejador de base de datos (DBMS).
Sub Modelo de Datos A Sub Modelo de Datos B Sub Modelo de Datos N Modelo de Datos Conceptual
DISEO LGICO
Esquema de la Base de Datos
Sub Esquema A, B, N
(esquema externo)
SGBD DBMS DDL DML

Base de datos almacenada
Diccionario de datos (Meta-datos)
Se define en lenguaje de esquema (DLL) segn el SGBD. Nombre de Tablas Elementos de tablas Tipos de Datos Validacin de dominio, de tabla, de integridad referencial, de base de datos. Vistas Etc.
Figura 3: Modelo de Datos Lgico c. Por ltimo, podemos mencionar a los modelos de datos fsicos, que son estructuras de datos a bajo nivel implementadas dentro del propio DBMS.
Sub Modelo de Datos A Sub Modelo de Datos B Sub Modelo de Datos N Modelo de Datos Conceptual
Esquema de la Base de Datos

Almacenamiento y configuracin de parmetros del DBMS
DISEO FSICO
SGBD DBMS
Hardware
Diccionario de datos (Meta-datos) Base de datos almacenada
Sistema operativo
Figura 4: Modelo de Datos Fsico
Arquitectura de hardware para la Base de Datos: procesadores, discos-RAID, etc. Estructuras de almacenamiento y acceso que permite el SGBD: Tipos de indexacin, agrupamiento, tamao de bloques, buffers, etc. Parmetros de configuracin del SGBD: Tamao de memoria intermedia, intervalos de tiempo en proceso, uso de multiprocesadores, etc.
1.1 El Modelo Entidad-Relacin a. Conceptos bsicos Conjuntos de Entidades.- Una entidad es cualquier objeto real o abstracto que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar informacin. Por ejemplo, puede ser concreto, como una persona o un libro, o puede ser abstracta, como un prstamo, unas vacaciones o un concepto. Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las mismas propiedades, o atributos. El conjunto de todas las personas que son clientes en un banco dado, por ejemplo, se pueden definir como el conjunto de entidades cliente. Las entidades individuales que constituyen un conjunto se llaman la extensin del conjunto de entidades. As, todos los clientes de un banco son la extensin del conjunto de entidades cliente. Los conjuntos de entidades no son necesariamente disjuntos. Por ejemplo, es posible definir el conjunto de entidades de todos los empleados de un banco (empleado) y el conjunto de entidades de todos los clientes del banco (cliente). Una entidad se representa mediante un conjunto de atributos. Los atributos describen propiedades que posee cada miembro de un conjunto de entidades. Para cada atributo hay un conjunto de valores permitidos, llamados dominio. Atributos simples y compuestos. Los atributos simples son los que no tienen subpartes(dni, cdigo, celular), en cambio los compuestos son lo que tienen subpartes(nombre_alumno: nombre, primer apellido, segundo apellidos). Estos ejemplos se representan en la figura 5. Atributos monovalorados y multivalorados. Los atributos monovalorados son los que tienen un solo valor (cdigo, nombre, dni), en cambio los multivalorados pueden tener ms de un valor (celular, un alumno puede tener de cero a varios nmeros de celular). Estos ejemplos se representan en la figura 5. Atributos derivados. El valor para este tipo de atributo se puede derivar de los valores de otros atributos. Ejemplo: si el conjunto de atributos tiene un atributo fechanacimiento, se puede calcular edad a partir de fechanacimiento y la fecha actual. EJEMPLARES = REGISTROS
codigo 123001 nombre Julian VILLAF carrera Sistemas dni 41882212 celular 966752351 codigo 111001 nombre Maria SEQUE carrera Derecho dni 02133434 celular codigo 96445532 101001 nombre carrera dni celular Figura 5: Entidad Jose ESPINOZ Educacion 32546734 966752351
ENTIDAD=TABLA
Alumno codigo nombre carrera dni celular
Atributos
b. Claves Las entidades y relaciones individuales son distintas, la diferencia entre ellas se debe expresar en trmino de sus atributos. Por lo tanto, los valores de los atributos de una entidad deben ser tales que permitan identificar unvocamente a la entidad. Una clave permite identificar un conjunto de atributos suficiente para distinguir las entidades entre s. Clave principal o primaria.- Es el atributo o conjunto mnimo de atributos (uno o ms campos) que permiten identificar en forma nica cada instancia de la entidad, es decir, a cada registro de la tabla. Las claves principales se utilizan cuando se necesita hacer referencia a registros especficos de una tabla desde otra tabla. En un principio se puede identificar ms de un atributo que cumpla las condiciones para ser clave, los mismos se denominan Claves candidatas. Si la clave primaria se determina mediante un solo atributo de la entidad, entonces se dice que la misma es una Clave simple. En caso de estar conformada por ms de un atributo, la misma se conoce como Clave compuesta. La Clave fornea, externa o secundaria. Es un atributo que es clave primaria en otra entidad con la cual se relaciona.
Clave Candidata
Clave Principal Alumno codigo nombre carrera celular dni
Simple
Alumno nombre carrera celular codigo dni
Compuesta
Clave Principal Matricula

codigo 123001 111001 123001 111001 semestre 2012-I 2012-I 2012-II 2012-II fechamat 12/04/2012 14/04/2012 15/08/2012 15/08/2012 creditos 21 20 22 22 estado N R N N
codigo semestre fechamat creditos estado
Figura 6: Claves c. Relacin.- Es la asociacin entre 2 o ms entidades. o Clasificacin por cardinalidad Relacin de Uno a Uno. Cuando un registro de una tabla slo puede estar relacionado con un nico registro de la otra tabla y viceversa. En este caso la clave fornea se ubica en alguna de las 2 tablas. Uno a Uno 1 1
Relacin Uno a Muchos: Cuando un registro de una tabla (tabla secundaria) slo puede estar relacionado con un nico registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener ms de un registro relacionado en la tabla secundaria. En este caso la clave fornea se ubica en la tabla secundaria. Uno a Muchos 1
Relacin Muchos a Muchos: Cuando un registro de una tabla puede estar relacionado con ms de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar relacionadas directamente, se tiene que aadir una tabla entre las dos (Tabla dbil o de vinculacin) que incluya los pares de valores relacionados entre s.
Muchos a Muchos
Clasificacin por Modalidad. Dadas las tablas A y B, que se encuentran relacionadas: Si para todo registro de A debe existir siempre al menos un registro de B asociado, se dice que la relacin en sentido A B es Obligatoria. Si para todo registro de A, pueden existir o no, uno o varios registros de B asociados, se dice que la relacin en sentido AB es Optativa. La modalidad de las relaciones se debe analizar en ambos sentidos. Optativa
Obligatoria
1.2 Diagramas Entidad-Relacin La estructura lgica general de una base de datos se puede expresar grficamente mediante un diagrama E-R. Los diagramas son simples y claros, cualidades que pueden ser responsables del amplio uso del modelo E-R. Tal diagrama consta de los siguientes componentes principales: Rectngulos, que representan conjuntos de entidades. Elipses, que representan atributos. Rombos, que representan relaciones. Lneas, que unen atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones. Elipses dobles, que representan atributos multivalorados. Elipses discontinuas, que denotan atributos derivados. Lneas dobles, que indican participacin total de una entidad en un conjunto de relaciones. Rectngulos dobles, que representan conjuntos de entidades dbiles
Smbolo
Significado Entidad Entidad dbil
Relacin
Relacin de Identificacin
Atributo Atributo clave Atributo multivalor Atributo compuesto
Atributo derivado
. E1
E2
Participacin total de E2 en R
E1
E2
Razn de cardinalidad 1:N para E1:E2 en R
(min, max) R E2 Restriccin estructural (min, max) en la participacin de E en R
Figura 7: Resumen de Notacin para los diagramas ER.
1.3 El modelado UML (Lenguaje de Modelado Universal Universal Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos a un sistema de software. UML es una notacin no un mtodo, que prescribe un conjunto de notaciones y diagramas estndar. La ventaja de UML es que aunque sus conceptos estn basados en tcnicas de orientacin a objetos, los modelos resultantes de estructura y comportamiento pueden utilizarse para disear base de datos relacionales, orientada a objetos y de objetos relacionales. Los diagramas de clases son parecidos a los diagramas Entidad-Relacin, por lo que se puede considerar notacin alternativa a los diagramas ER. 1.4 Diagramas UML Diagramas de Casos de Uso. Para modelar los procesos Business. Diagramas de Secuencia. Para modelar el paso de mensajes entre objetos. Diagramas de colaboracin. Para modelar interacciones entre objetos. Diagramas de estado. Para modelar el comportamiento de los casos de uso, objetos y operaciones. Diagramas de actividad. Para modelar el comportamiento de los casos de uso, objetos u operaciones. Diagramas de clases. Para modelar la estructura esttica de los objetos en el sistema. Diagramas de componentes. Para modelar componentes. Diagramas de implementacin. Para modelar la distribucin del sistema. 1.5 Herramientas CASE Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Ordenador) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Las herramientas en funcin de las fases del ciclo de vida que cubre, se pueden agrupar de la siguiente forma: a. Herramientas Integradas I-CASE (Integrated CASE, CASE Integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench. b. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y diseo. c. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las ltimas fases del desarrollo: construccin e implantacin. Ejemplo de Herramientas CASE Erwin. Esta herramienta es muy eficaz cuando se busca hacer el diseo de una Base de Datos ya que permite crear paralelamente el modelo fsico y lgico de la BD. As mismo permite crear Triggers, Indices Stored Procedures, en bastantes Manejadores de Base de Datos tanto para hacer una ingeniera inversa o pasar el diseo a un manejador. UML2Tools. Para la generacin de diagramas de clases en Eclipse se necesita un plugin, este tiene una facilidad de uso muy buena y es fcil de realizar diagramas de Clases con todos los atributos necesarios. 8
OracleSQLDeveloper. Herramienta CASE especializada en Base de Datos, tiene varios mdulos de modelado de datos entre otras y tiene compatibilidad con distintos manejadores de Base de Datos. CaseStudio2. Es una herramienta case que es principalmente orientada al diseo y modelado de diagramas de entidad relacin. Poseidon. Herramienta para realizar diagramas UML YUML. Herramienta CASE enfocada a diagramacin de UML, servicio de la nube, con diagramas de clase, actividad y casos de uso.
1.6 Mapeo al modelo Relacional Consiste en disear el esquema de una base de datos relacional basndose en un diseo de esquema conceptual. Los pasos para el mapeado de un Modelo Entidad-Relacin al Relacional son: a. Mapeado de los tipos de entidades regulares. Por cada entidad regular E del esquema ER, crear una relacin R simple que incluya todos los atributos simples de E. En caso de atributos compuestos incluir solamente los atributos simples, y seleccionar uno de los atributos clave de E como clave principal de R, en el caso que la clave elegida de E sea compuesta, entonces el conjunto de los atributos simples que la conforman constituirn la clave principal de R. b. Mapeado de los tipos de entidad dbiles. Por cada tipo de entidad dbil W del esquema ER, crear una relacin R que incluya todos los atributos simples (o componentes simples de los atributos compuestos) de W como atributos de R. Adems, incluir como atributos de la foreign key de R, el(los) atributo(s) de la o las relaciones que correspondan al o los tipos de entidad propietarios; esto se encarga de identificar el tipo de relacin de W. La clave principal de R es la combinacin de la(s) clave( s) principal( es) del o de los propietarios y la clave parcial del tipo de entidad dbil W, si la hubiera. c. Mapeado de los tipos de relacin 1:1 binaria. Por cada tipo de relacin 1:1 binaria R del modelo ER, identificar las relaciones S y T que corresponden a los tipos de entidad que participan en R. La metodologa de la foreign key, indica seleccionar una de las relaciones (por ejemplo: S) e incluya como foreign key en S la clave principal de T. Lo mejor es elegir un tipo de entidad con participacin total en R. d. Mapeado de tipos de relaciones 1:N binarias. Por cada relacin 1:N binaria regular R, identifique la relacin S que representa el tipo de entidad participante en el lado N del tipo de relacin, incluir como foreign key en S la clave principal de la relacin T que representa el otro tipo de entidad participante en R. e. Mapeado de tipos de relaciones M:N binarias. Por cada tipo de relacin M:N binaria R, cree una nueva relacin S para representar a R. Incluya como atributos de la foreign key en S las claves principales de las relaciones que representan los tipos de entidad participantes; su combinacin formar la clave principal de S. Incluya tambin atributos simples del tipo de relacin M:N. f. Mapeado de atributos multivalor. Por cada atributo multivalor A, cree una nueva relacin R. Esta relacin incluir un atributo correspondiente a A, ms el atributo clave principal K (como foreign key en R) de la relacin que representa el tipo de entidad o tipo de relacin que tiene A como un atributo. La clave principal de R es la combinacin de A y K. Si el atributo multivalor es compuesto, incluimos sus componentes g. Mapeado de los tipos de relacin n-ary. Por cada tipo de relacin n-ary R, donde n > 2, crear una nueva relacin S para representar R. Incluya como atributos de la foreign key en S las claves principales de las relaciones que representan los tipos de entidad participantes. Por lo general la ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 9
clave principal de S es una combinacin de todas lasforeign keys que hacen referencia a las relaciones que representan los tipos de entidad participantes. Modelo E-R Tipo de entidad Tipo de relacin 1:1 o 1:N Tipo de relacin M:N Tipo de relacin n-ary Atributo simple Atributo compuesto Atributo multivalor Conjunto de valores Atributo clave Modelo Relacional Relacin de entidad Foreign key (o relacin de relacin) Relacin de relacin y dos foreign keys Relacin de relacin y n foreign keys Atributo Conjunto de atributos simples Relacin y foreign key Dominio Clave principal (o secundaria)
Tabla1: Correspondencia entre los modelos ER y relacional
10
II.
DISEO DE BASES DE DATOS RELACIONALES

2.1 Conceptos del modelo relacional Es un modelo de datos basado en la teora de las relaciones, en donde los datos se estructuran lgicamente en forma de relaciones-tablas, siendo un objetivo fundamental del modelo mantener la independencia de esta estructura lgica respecto al modo de almacenamiento y a otras caractersticas de tipo fsico. a. Objetivos Independencia fsica: es decir, el modo en el que se almacenan los datos no influya en su manipulacin lgica y, por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico. Independencia lgica: esto es, que el aadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos (vistas). Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en que ste prefiera. Uniformidad: las estructuras lgicas de los datos presentan un aspecto uniforme, lo que facilita la concepcin y manipulacin de la base de datos por parte de los usuarios. Sencillez: las caractersticas anteriores, as como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender y de utilizar por parte del usuario final. b. Estructura del Modelo Relacional La relacin es el elemento bsico en el modelo relacional y se puede representar como una tabla: Nombre Atributo 1 Atributo 2 ..................... Atributo n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 1 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 2 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX . XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX . XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla n Tabla 2: Estructura del modelo relacional El nmero de filas de una relacin se denomina cardinalidad de la relacin y el nmero de columnas es el grado de la relacin. Ejemplo: AUTOR Nombre Nacionalidad Pepe Espaa John EE.UU. Pierre Francia Tabla 3: Ejemplo de una tabla
Institucion O.N.U. O.M.S. N.A.S.A.
11
Una relacin se puede representar en forma de tabla, pero va a tener una serie de elementos caractersticos: No puede haber filas duplicadas, es decir, todas las tuplas tienen que ser distintas. El orden de las filas es irrelevante. La tabla es plana, es decir, en el cruce de una fila y una columna slo puede haber un valor.
c. Dominio Un dominio D es un conjunto finito de valores homogneos (porque son todos del mismo tipo) caracterizados por un nombre. Todo dominio ha de tener un nombre por el cual nos podamos referir a l y un tipo de datos; as el tipo de datos del dominio "nacionalidades" es una tira de caracteres de longitud 10. Ejemplos de dominios seran: Colores: Es el conjunto de los colores D={rojo, verde, azul,} Nmeros de DNI: Es conjunto de nmeros del DNI vlidos, formados por ocho dgitos. Edad: Edades posibles de los empleados entre 18 y 80 aos. d. Atributo Describen propiedades que posee cada miembro de un conjunto de entidades. Cada entidad puede tener su propio valor para cada atributo. 2.2 Claves Una clave permite identificar un conjunto de atributos suficiente para distinguir las entidades entre s. Las claves tambin ayudan a identificar unvocamente a las relaciones y as a distinguir las relaciones entre s. a. Clave candidata. Son todos los atributos que cumplen las condiciones para ser claves principales. b. Clave principal o primaria. Es un conjunto de uno o ms atributos que, permiten identificar de forma nica una entidad en el conjunto de entidades. Por ejemplo, el atributo idestudiante del conjunto de entidades estudiante es suficiente para distinguir una entidad estudiante de las otras. Clave simple.- Es simple cuando la clave primaria se determina por un solo atributo. Clave compuesta.- Es compuesta cuando la clave esta conformada por mas de un atributo. c. Clave Fornea. Tambin externa o secundaria, es un atributo que es clave primaria en otra en otra tabla con la cual se relaciona. 2.3 ndices Para permitir un acceso directo rpido a los registros de un archivo se puede usar una estructura de ndice. Cada estructura de ndice est asociada con una clave de bsqueda concreta. Existe dos tipos de ndice: Primario y Secundario.
2.3.1 ndice Primario La clave de bsqueda de un ndice primario es por lo general la clave primaria, aunque no es as necesariamente
12
Es cuando los registros en el archivo indexado se encuentran almacenados siguiendo un orden, es decir que el archivo que contiene los registros est ordenado secuencialmente. El ndice cuya clave de bsqueda especifica el orden secuencial del archivo es el ndice primario, los ndices primarios tambin se llaman ndices con agrupacin (clustering indices.). Todos los archivos estn ordenados secuencialmente segn alguna clave de bsqueda. Estos archivos con ndice primario segn una clave de bsqueda se llaman archivos secuenciales indexados. Se emplean en aquellas aplicaciones que demandan un procesamiento secuencial del archivo completo as como un acceso directo a sus registros.
Agronomia Derecho Sistemas
991102C
Agronomia
Julio Alfredo Maria Julio Julio Pedro Mara
991110A Contabilidad 011012B 980189C 971567B Contabilidad Derecho Derecho
981267V Derecho 976523C Sistemas
Figura 8: Archivo Secuencial

Un registro ndice o entrada del ndice consiste en un valor de la clave de bsqueda y punteros a uno o ms registros con ese valor de la clave de bsqueda. El puntero a un registro consiste en el identificador de un bloque de disco y un desplazamiento en el bloque de disco para identificar el registro dentro del bloque.
ndice Denso. Aparece un registro ndice por cada valor de la clave de bsqueda en el archivo. El registro ndice contiene el valor de la clave y un puntero al primer registro con ese valor de la clave de bsqueda. El resto de registros con el mismo valor de la clave de bsqueda se almacenan consecutivamente despus del primer registro, dado que, ya que el ndice es primario, los registros se ordenan sobre la misma clave de bsqueda. Las implementaciones de ndices densos pueden almacenar una lista de punteros a todos los registros con el mismo valor de la clave de bsqueda; esto no es esencial para los ndices primarios.
13
Agronomia Contabilidad Derecho Sistemas
991102C
Agronomia
Julio Alfredo Maria Julia Jose Pedro Ketty
981267V Derecho 976523C Figura 8. ndice Denso Sistemas
ndice Disperso. Slo se crea un registro ndice para algunos de los valores. Al igual que en los ndices densos, cada registro ndice contiene un valor de la clave de bsqueda y un puntero al primer registro con ese valor de la clave. Para localizar un registro se busca la entrada del ndice con el valor ms grande que sea menor o igual que el valor que se est buscando. Se empieza por el registro apuntado por esa entrada del ndice y se contina con los punteros del archivo hasta encontrar el registro deseado. Agronomia Derecho Sistemas 991102C Agronomia Julio Alfredo Maria Julia Jose Pedro Ketty
981267V Derecho 976523C Figura 9. ndice Disperso Sistemas
ndices Multinivel. Si un ndice es lo bastante pequeo como para guardarlo en la memoria principal, el tiempo de bsqueda para encontrar una entrada ser breve. Sin embargo, si el ndice es tan grande que se debe guardar en disco, buscar una entrada implicar leer varios bloques de disco. Para localizar una entrada en el archivo ndice se puede realizar con una bsqueda binaria, pero aun as sta conlleva un gran coste. Si el ndice ocupa b bloques, la bsqueda binaria tendr que leer a lo sumo log2(b) bloques. Para el ndice de 100 bloques, la bsqueda binaria necesitar leer siete bloques. En un disco en el que la lectura de un bloque tarda 30 milisegundos, la bsqueda emplear 210 milisegundos, lo que es mucho. Obsrvese que si se estn usando bloques de desbordamiento, la bsqueda binaria no sera posible. En ese caso, lo normal es una bsqueda secuencial, y eso requiere leer b bloques, lo que podra consumir incluso ms tiempo. As, el proceso de buscar en un ndice grande puede ser muy costoso. 14
Para resolver este problema se trata el ndice como si fuese un archivo secuencial y se construye un ndice disperso sobre el ndice primario, como se muestra en la Figura 10. Para localizar un registro se usa en primer lugar una bsqueda binaria sobre el ndice ms externo para buscar el registro con el mayor valor de la clave de bsqueda que sea menor o igual al valor deseado. El puntero apunta a un bloque en el ndice ms interno. Hay que examinar este bloque hasta encontrar el registro con el mayor valor de la clave que sea menor o igual que el valor deseado. El puntero de este registro apunta al bloque del archivo que contiene el registro buscado. Usando los dos niveles de indexacin y con el ndice ms externo en memoria principal, tenemos que leer un nico bloque ndice en vez de los siete que se lean con la bsqueda binaria. Si al archivo es extremadamente grande, incluso el ndice exterior podra crecer demasiado para caber en la memoria principal. En este caso se podra crear todava otro nivel ms de indexacin. De hecho, se podra repetir este proceso tantas veces como fuese necesario. Los ndices con dos o ms niveles se llaman ndices multinivel. La bsqueda de registros usando un ndice multinivel necesita claramente menos operaciones de E/S que las que se emplean en la bsqueda de registros con la bsqueda binaria. Cada nivel de ndice se podra corresponder con una unidad del almacenamiento fsico. As, podramos tener ndices a nivel de pista, cilindro o disco.
Bloque de ndice 0
Bloque de Datos 0
Bloque de Datos 1 Bloque de ndice 1 ndice externo
ndice interno
Figura 10: ndice disperso de dos niveles.
15
2.3.2 ndice Secundario Los ndices secundarios deben ser densos, con una entrada en el ndice por cada valor de la clave de bsqueda, y un puntero a cada registro del archivo. Un ndice primario puede ser disperso, almacenando slo algunos de los valores de la clave de bsqueda, ya que siempre es posible encontrar registros con valores de la clave de bsqueda intermedios mediante un acceso secuencial a parte del archivo. Si un ndice secundario almacena slo algunos de los valores de la clave de bsqueda, los registros con los valores de la clave de bsqueda intermedios pueden estar en cualquier lugar del archivo y, en general, no se pueden encontrar sin explorar el archivo completo. Un ndice secundario sobre una clave candidata es como un ndice denso primario, excepto en que los registros apuntados por los sucesivos valores del ndice no estn almacenados secuencialmente. Por lo general, los ndices secundarios estn estructurados de manera diferente a como lo estn los ndices primarios. Si la clave de bsqueda de un ndice primario no es una clave candidata, es suficiente si el valor de cada entrada en el ndice apunta al primer registro con ese valor en la clave de bsqueda, ya que los otros registros podran ser alcanzados por una bsqueda secuencial del archivo. En cambio, si la clave de bsqueda de un ndice secundario no es una clave candidata, no sera suficiente apuntar slo al primer registro de cada valor de la clave. El resto de registros con el mismo valor de la clave de bsqueda podran estar en cualquier otro sitio del archivo, ya que los registros estn ordenados segn la clave de bsqueda del ndice primario, en vez de la clave de bsqueda del ndice secundario. Por tanto, un ndice secundario debe contener punteros a todos los registros. Se puede usar un nivel adicional de indireccin para implementar los ndices secundarios sobre claves de bsqueda que no sean claves candidatas. Los punteros en estos ndices secundarios no apuntan directamente al archivo. En vez de eso, cada puntero apunta a un cajn que contiene punteros al archivo. En la Figura 11 se muestra la estructura del archivo estudiante, con un ndice secundario que emplea un nivel de indireccin adicional, y teniendo como clave de bsqueda la carrera. Siguiendo el orden de un ndice primario, una bsqueda secuencial es eficiente porque los registros del archivo estn guardados fsicamente de la misma manera a como est ordenado el ndice. Sin embargo, no se puede almacenar el archivo ordenado fsicamente por el orden de la clave de bsqueda del ndice primario y la clave de bsqueda del ndice secundario. Ya que el orden de la clave secundaria y el orden fsico difieren, si se intenta examinar el archivo secuencialmente por el orden de la clave secundaria, es muy probable que la lectura de cada bloque suponga la lectura de un nuevo bloque del disco, lo cual es muy lento. Los ndices secundarios mejoran el rendimiento de las consultas que emplean claves que no son la de bsqueda del ndice primario. Sin embargo, implican un tiempo adicional importante al modificar la base de datos. El diseador de la base de datos debe decidir qu ndices secundarios son deseables, segn una estimacin sobre las frecuencias de las consultas y las modificaciones.
16
991102C Julio Alfredo Mara Pedro
Agronomia
Julio Alfredo Mara Julio Julio Pedro Mara
981267V Derecho 976523C Sistemas
Figura 11. ndice secundario del archivo estudiante, con la clave no candidata nombre.
2.4 Integridad Cada tupla de una relacin debe proporcionar valores a sus atributos, no de cualquier manera. Para garantizar la consistencia y la facilidad de manipulacin de la informacin representada, existen una serie de reglas que deben ser cumplidas, llamadas tambin restricciones de integridad. Restriccin de dominio. Los dominios de los atributos de una relacin deben ser atmicos. Esta restriccin exige que los valores de cualquier tupla de una relacin R correspondientes a los atributos A1,,An de R deben ser valores atmicos, es decir que esos valores no pueden ser descomponibles en valores ms pequeos o simples. Esta condicin pretende garantizar que todas las relaciones presenten un formato regular, que pueda ser fcilmente manipulable por medio de un sencillo procedimiento o algoritmo, implementado en la forma de un programa informtico. codigo 123001 Fecha semestre
12/04/2013 2013-I 2013-II 12/05/2013 2013-I
111001
Figura 12: Relacin no valida por uso de valor mltiple. En la figura 12 se muestra un ejemplo de una relacin en la que una de sus tuplas, la correspondiente a Matricula, presenta un doble valor para el atributo semestre. De esa forma se pretende representar el hecho de que una matrcula tiene dos semestres simultneos: 2013-I y 2013-II. Este formato viola la restriccin de dominio, ya que rompe la regularidad de la tabla (de la relacin).
17
codigo 123001 111001 123001 Figura 13. Relacin correcta.
Fecha
semestre
12/04/2013 2013-I 12/05/2013 2013-I 14/08/2013 2013-II
Restriccin de clave. En una relacin no puede haber ninguna tupla repetida. Ningn conjunto admite, por definicin, la existencia de elementos repetidos en su contenido. Tratndose de un conjunto de tuplas, las relaciones requieren la misma exigencia. Que la extensin de una relacin no incluya tuplas repetidas, implica que todas las tuplas que contiene puedan ser diferenciadas entre s por el valor de al menos un atributo. Eso nos lleva al concepto de superclave de una relacin cualquier subconjunto (propio o no) de atributos de la relacin, que nos permita diferenciar a cualesquiera dos tuplas que formen parte de su extensin a partir de los valores de las tuplas para esos atributos. Toda relacin cuenta con una o ms superclaves. En el peor de los casos, tendremos una superclave nica: aquella formada por el conjunto de todos los atributos de la relacin. En el caso de nuestro ejemplo, seran superclaves los siguientes conjuntos de atributos: (cdigo, semestre) Restriccin de Integridad de Entidad. Ninguna tupla de una relacin puede tomar valores nulos en los atributos que forman parte de su clave primaria. La necesidad de esta restriccin es clara: dado que es la clave primaria la que nos permite distinguir a las tuplas entre s, los valores correspondientes a la clave deben ser conocidos en cada tupla para poder diferenciarla. codigo 123001 111001 123001 nombre 12/04/2013 12/05/2013 2013-I 14/08/2013 Carrera
Figura 14: Restriccin de Integridad de entidad incorrecta. Siendo desconocidos los valores de Carrera en ambas tuplas, es imposible distinguir a una de otra. Se trata por tanto de una relacin incorrecta, no vlida, debido a que viola la restriccin de integridad de entidad. Restricciones de Integridad Referencial. Si una tupla de una relacin R1 hace referencia a una relacin R2, debe referirse a una tupla que exista realmente en R2. Este tipo de restricciones permite garantizar la consistencia en el caso de relaciones que mantengan una cierta vinculacin.
18
codigo 123001 111001 123001
nombre
Carrera
12/04/2013 2013-I 12/05/2013 2013-I 14/08/2013 2013-II
Figura 15. Restriccin de Integridad referencial La relacin pretende representar el cdigo de estudiante, su nombre, y todos los datos relativos al estudiante. Para evitar problemas de redundancia, en lugar de representar todos los datos de cada estudiante, se incluye una referencia a la tupla que le corresponde en la relacin Estudiante. Esa referencia se realiza por medio de los valores de la clave primaria de la tupla. 2.5 Normalizacin Son criterios formales para valorar y mejorar el diseo de una base de datos, que permiten: Reducir redundancias (consumen espacio y pueden generar problemas de consistencia) Facilitar la actualizacin de datos de forma ms modular (evitar anomalas) Facilitar la evolucin de los esquemas Neutralidad respecto de las consultas 2.5.1 Dependencias funcionales. Hay veces en que los atributos estn relacionados entre s de manera m as espec fica que la de pertenecer a una misma relacin. Hay veces en que es posible determinar que un atributo depende de otro funcionalmente, como si existiera una funcin, la que se notara f: A B, pero como f es desconocida slo nos quedamos con A B, la dependencia funcional, que se lee A determina B. Primera Forma Normal. Un dominio es atmico si se considera que los elementos del dominio son unidades indivisibles. Se dice que el esquema de una relacin R est en la primera forma normal (1FN) si los dominios de todos los atributos de R son atmicos. Los atributos compuestos, como el atributo direccin con sus atributos componentes calle y ciudad, tienen tambin dominios no atmicos. Algunos tipos de valores no atmicos pueden resultar tiles, aunque deben utilizarse con cuidado. Por ejemplo, los atributos con valores compuestos suelen resultar tiles, y los atributos de tipo conjunto tambin resultan tiles en muchos casos, que es el motivo por el que el modelo E-R los soporta. En muchos dominios en los que las entidades tienen una estructura compleja, la imposicin de la representacin en la primera forma normal representa una carga innecesaria para el programador de las aplicaciones, que tiene que escribir cdigo para convertir los datos a su forma atmica. Tambin hay sobrecarga en tiempo de ejecucin por la conversin de los datos a la forma atmica y desde ella. Por tanto, el soporte de los valores no atmicos puede resultar muy til en esos dominios. Segunda Forma Normal. Primero se debe cumplir con estar en la 1FN. Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema, 19
2.5.2
2.5.3
es decir para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una sub clave. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN.
2.5.4
Tercera Forma Normal. Primero se debe cumplir con estar en la 2FN. Un modelo de datos relacional en tercera forma normal se considera de buena calidad. 3FN garantiza un buen equilibrio entre eficiencia y control de redundancia. Se basa en que cada atributo que no est incluido en la clave primaria no depende transitivamente de la llave primaria. Se tiene que buscar secuencias de dependencias como la siguiente; K A y A B, donde A y B no pertenecen a la clave; la solucin a este tipo de dependencias est en separar en una tabla adicional N los atributos B. Forma Normal de Boyce-Codd: (FNBC) Una forma normal ideal, el mximo control de redundancia mediante dependencias funcionales. La idea consiste en que cada atributo depende de slo de la llave (en su totalidad, no de una parte). Un esquema R est en FNBC si XY no trivial, X es superllave (contiene a alguna llave candidato). Cuarta Forma Normal Es como FNBC, pero con dependencias multivaluadas. Un esquema R est en 4FN si X Y no trivial, X es superllave. La 4FN exige que toda dependencia multivaluada sea en realidad una dependencia funcional. Se aplica a relaciones de muchos a muchos, entidades independientes no pueden ser almacenadas en la misma tabla.
2.5.5
2.5.6
2.5.7
Quinta Forma Normal Se trata de producto-reunin (join). Una relacin tal que R - A B C 3, todas relaciones con distintos esquemas, NO est en 5FN. Una relacin est en 5FN cuando no se puede dividir y puede volver a ser reconstruida desde las tablas resultantes sin prdida de informacin.
2.6 El diseo de bases de datos y el proceso de implementacin Los objetivos del diseo de una base de datos son: Satisfacer los requisitos de informacin de los usuarios y aplicaciones especificados. Ofrecer una estructuracin de la informacin natural y fcil de comprender. Soportar las necesidades de procesamiento y cualquier objetivo de rendimiento, como el tiempo de respuesta, el tiempo de procesamiento y el espacio de almacenamiento. El proceso de diseo consta de dos actividades paralelas. La primera supone el diseo de los contenedores de informacin y de la estructura de la base de datos; la segunda est relacionada con el diseo de las aplicaciones de base de datos. Estas dos actividades influyen la una en la otra. Tradicionalmente, las metodologas de diseo de bases de datos se han centrado inicialmente en la primera de estas actividades, mientras que el diseo del software lo est en la segunda; esto se podra llamar un diseo orientado-a-datos frente a un diseo orientado-a-procesos. Son 6 fases principales en el proceso de diseo e implementacin: ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 20
a. Recopilacin y anlisis de requisitos Para disear una base de datos, se debe conocer y analizar las expectativas de los usuarios sobre el sistema, este proceso recibe el nombre de recopilacin de requisito y anlisis. Para lo cual se puede realizar las siguientes actividades: Identificar las reas de aplicacin y usuarios que usan la base de datos. Estudiar y analizar la documentacin existente relativa a las aplicaciones. Estudiar el entorno actual y el uso que se pretende dar a la informacin, as como el anlisis de los tipos de transacciones y sus frecuencias. Recabar preguntas de los usuarios y grupos potenciales de la base de datos y escribir respuestas para ellas. b. Diseo conceptual de la base de datos En esta etapa es importante utilizar un modelo de datos conceptual de alto nivel, que tenga las siguientes caractersticas: Expresividad. El modelo de datos debe ser suficientemente expresivo para distinguir los distinto tipos de datos, relaciones y restricciones. Simplicidad y comprensibilidad. El modelo debe ser bastante simple para que los usuarios no experimentados lo entiendan y utilicen sus conceptos. Minimalista. El modelo debe tener una pequea cantidad de conceptos bsicos que sean distintos y cuyo significado no se solape. Representacin diagramtica. El modelo debe tener una notacin diagramtica fcil de entender y que sirva para visualizar el esquema conceptual. Formalidad. Los conceptos del modelo deben definirse con precisin y sin ambigedad.
Estrategias para disear un esquema Estrategia descendente. Empezamos con un esquema que contiene abstracciones de alto nivel y despus aplicamos refinamientos sucesivos de arriba abajo. Por ejemplo, se especifica slo unos cuantos tipos de entidades de nivel alto y, a continuacin, al especificar sus atributos, dividirlas en tipos de entidades de bajo nivel y relaciones. Estrategia ascendente. Empezamos con un esquema que contiene las abstracciones bsicas, y despus combinamos o aadimos a esas abstracciones. Por ejemplo, podemos empezar con los atributos y agruparlos en tipos de entidades y relaciones. Podemos aadir relaciones nuevas entre los tipos de entidades a medida que progresa el diseo. Estrategia de dentro a fuera. Se trata de un caso especial de estrategia ascendente, en la que la atencin se centra en un conjunto central de conceptos que son muy evidentes. Podramos especificar unos pocos tipos de entidades claramente evidentes en el esquema y continuar aadiendo otros tipos de entidades y relaciones relacionados con ellos. Estrategia mixta. En lugar de seguir una estrategia en particular durante el diseo, los requisitos se dividen segn una estrategia descendente, y se disea parte del esquema para cada una de esas divisiones siguiendo una estrategia ascendente.
21
c. Eleccin de DBMS Coste de adquisicin del software. Es el coste directo por comprar el software, incluyendo las opciones del lenguaje, las diferentes opciones de interfaz (formularios, mens y herramientas GUI [interfaz grfica de usuario] basadas en la Web), las opciones de recuperacin y copia de seguridad, los mtodos especiales de acceso, y la documentacin. Hay que seleccionar la versin correcta del DBMS para un sistema operativo concreto. En el precio bsico normalmente no se incluyen las herramientas de desarrollo, las herramientas de diseo y el soporte adicional del idioma. Coste de mantenimiento. Es el coste recurrente por recibir un servicio de mantenimiento estndar ofrecido por el fabricante y por mantener actualizada la versin del DBMS. Coste de adquisicin del hardware. Es posible que se necesite hardware nuevo, como memoria adicional, terminales, unidades de disco y controladores, o almacenamiento especializado para el DBMS. Coste de creacin y conversin de la base de datos. Es el coste de crear el sistema de bases de datos desde el principio o de convertir un sistema existente al nuevo software DBMS. En el ltimo caso es habitual hacer funcionar el sistema existente en paralelo con el sistema nuevo hasta haber implementado y probado completamente todas las aplicaciones nuevas. Este coste es muy difcil de proyectar y a menudo se subestima. Coste de personal. La adquisicin de un software DBMS por primera vez suele suponer para la empresa una reorganizacin del departamento de procesamiento de datos. En la mayora de las empresas que han adoptado un DBMS normalmente cuenta con DBA y su personal. Coste de formacin. Como los DBMSs suelen ser sistemas complejos, a menudo es preciso formar al personal en su uso y programacin. La formacin es necesaria a todos los niveles, incluyendo la programacin, el desarrollo de aplicaciones y la administracin de la base de datos. Coste de funcionamiento. El coste de un funcionamiento continuado del sistema de bases de datos normalmente no se tiene en cuenta en la evaluacin de alternativas, porque se incurre en l independientemente del DBMS seleccionado. d. Mapeo del modelo de datos. En esta etapa, el mapeo no considera ninguna caracterstica especfica o caso especial que se aplique a la implementacin DBMS del modelo de datos (mapeo de un esquema ER a un esquema relacional independientemente del DBMS). El resultado de esta fase deben ser sentencias DDL en el lenguaje del DBMS elegido que especifican los esquemas a nivel conceptual y externo del sistema de bases de datos. Pero si las sentencias DDL incluyen algunos parmetros de diseo fsico, la especificacin DDL completa debe esperar hasta haberse completado la fase de diseo fsico de la base de datos. Las herramientas de diseo CASE pueden generar DDL para los sistemas a partir de un diseo de esquema conceptual. e. Diseo fsico de la base datos. El diseo fsico de la base de datos es el proceso de elegir estructuras de almacenamiento especficas y rutas de acceso para los ficheros de la base, a fin de lograr un buen rendimiento de las distintas aplicaciones de la base de datos. Cada DBMS ofrece distintas opciones para la organizacin de los ficheros y las rutas de acceso, entre las que destacan varios tipos de indexacin, agrupamiento de registros relacionados en bloques de disco, enlace de registros ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 22
relacionados mediante punteros, y varios tipos de dispersin (hashing). Una vez elegido un DBMS, el proceso de diseo fsico de la base de datos queda restringido a elegir las estructuras ms apropiadas para los ficheros de la base de datos entre las opciones ofrecidas por dicho DBMS. Tiempo de respuesta. Es el tiempo transcurrido entre el envo de una transaccin de base de datos para su ejecucin y la recepcin de una respuesta. Una influencia importante en el tiempo de respuesta que est bajo el control del DBMS es el tiempo de acceso de la base de datos a los datos a los que hace referencia la transaccin. El tiempo de respuesta tambin se ve influido por factores que no estn bajo el control del DBMS, como la carga del sistema, la planificacin del sistema operativo, o los retardos en la comunicacin. Utilizacin del espacio. Es la cantidad de espacio de almacenamiento utilizada por los ficheros de la base de datos y sus estructuras de ruta de acceso al disco, incluyendo los ndices y otras rutas de acceso. Rendimiento o flujo de transacciones. Es la cantidad media de transacciones que se pueden procesar por minuto; es un parmetro crtico para los sistemas de transacciones, como los que se utilizan para las reservas en aerolneas o en la banca. Este dato debe medirse cuando el sistema se encuentre bajo condiciones de mximos (Picos). f. Implementacin puesta a punto de un sistema Con los diseos lgico y fsico, podemos implementar el sistema de bases de datos, una tarea que es responsabilidad del DBA (Administrador de la Base de Datos) y que lleva a cabo junto con los diseadores de la base de datos. Para crear los esquemas de la base de datos y los ficheros (vacos) de la misma, se utilizan las sentencias del lenguaje DDL (lenguaje de definicin de datos) del DBMS seleccionado. Despus de lo dicho anteriormente, ya se puede cargar con datos. Si es necesario convertir stos porque proceden de un sistema computarizado anterior, es posible que necesitemos rutinas de conversin para reformatear los datos y poder cargarlos en la base de datos nueva. Las transacciones de bases de datos las deben implementar los programadores de la aplicacin, refirindose a las especificaciones conceptuales de las transacciones, y escribiendo y probando despus el cdigo con los comandos DML incrustados. Una vez listas las transacciones y cargados los datos en la base de datos, la fase de diseo e implementacin se da por terminada y empieza la fase operativa del sistema de bases de datos.
23
III.
FUNDAMENTOS DE SQL
3.1 Conceptos bsicos SQL (Structured Query Language), Lenguaje Estructurado de Consulta es el lenguaje utilizado para definir, controlar y acceder a los datos almacenados en una base de datos relacional. Como ejemplos de sistemas gestores de bases de datos que utilizan SQL podemos citar DB2, SQL Server, Oracle, MySql, Sybase, PostgreSQL o Access. El SQL es un lenguaje universal que se emplea en cualquier sistema gestor de bases de datos relacional. Tiene un estndar definido, a partir del cual cada sistema gestor ha desarrollado su versin propia. En SQL Server la versin de SQL que se utiliza se llama TRANSACT-SQL. EL SQL en principio es un lenguaje orientado nicamente a la definicin y al acceso a los datos por lo que no se puede considerar como un lenguaje de programacin como tal ya que no incluye funcionalidades como son estructuras condicionales, bucles, formateo de la salida, etc. Se puede ejecutar directamente en modo interactivo, pero tambin se suele emplear embebido en programas escritos en lenguajes de programacin convencionales. En estos programas se mezclan las instrucciones del propio lenguaje (denominado anfitrin) con llamadas a procedimientos de acceso a la base de datos que utilizan el SQL como lenguaje de acceso. Como por ejemplo en Visual Basic, Java, C#, PHP .NET, etc. Las instrucciones SQL se clasifican segn su propsito en tres grupos: El DDL (Data Description Language) Lenguaje de Descripcin de Datos. El DCL (Data Control Language) Lenguaje de Control de Datos. El DML (Data Manipulation Language) Lenguaje de Manipulacin de Datos. TRANSACT-SQL El sistema gestor de base de datos SQL utiliza su propia versin del lenguaje SQL, el TRANSACT-SQL. TRANSACT-SQL es un lenguaje muy potente que nos permite definir casi cualquier tarea que queramos efectuar sobre la base de datos. TRANSACT-SQL va ms all de un lenguaje SQL, ya que incluye caractersticas propias de cualquier lenguaje de programacin, caractersticas que nos permiten definir la lgica necesaria para el tratamiento de la informacin: Tipos de datos. Definicin de variables. Estructuras de control de flujo. Gestin de excepciones. Funciones predefinidas. Sin embargo no permite: Crear interfaces de usuario. Crear aplicaciones ejecutables, sino elementos que en algn momento llegarn al servidor de datos y sern ejecutados. Debido a estas restricciones se emplea generalmente para crear procedimientos almacenados, triggers y funciones de usuario. Puede ser utilizado como cualquier SQL como lenguaje embebido en aplicaciones desarrolladas en otros lenguajes de programacin como Visual Basic, C, Java, etc. Y por supuesto los lenguajes incluidos en la plataforma .NET. ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 24
3.2 Lenguaje de definicin de datos DDL Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado Lenguaje de definicin de datos(LDD). SQL permite la especificacin no slo de un conjunto de relaciones, sino tambin de alguna informacin relativa a esas relaciones, incluyendo: El esquema de cada relacin El dominio de valores asociado a cada atributo Las restricciones de integridad El conjunto de ndices que se deben mantener por cada relacin Informacin de seguridad y autorizacin para cada relacin La estructura de almacenamiento fsico de cada relacin en disco.
3.2.1
Tipos de dominios en SQL char (n) es una cadena de caracteres de longitud fija, con una longitud n especificada por el usuario. Tambin se puede utilizar la palabra completa character. varchar (n) es una cadena de caracteres de longitud variable, con una longitud n especificada por el usuario. Tambin se puede utilizar la palabra completa carcter varying. int es un entero (un subconjunto finito de los enteros, que es dependiente de la mquina). Tambin se puede usar la palabra completa integer. smallint es un entero pequeo (un subconjunto del dominio de los enteros, tambin dependiente de la mquina). numeric (p,d) es un nmero en coma flotante, cuya precisin la especifica el usuario. El nmero est formado por p dgitos (ms el signo), y de esos p dgitos, d pertenecen a la parte decimal. As, numeric (3,1) permite que el nmero 44,5 se almacene exactamente, mientras que los nmeros 444,5 y 0,32 no se pueden almacenar exactamente en un campo de este tipo. real, double precision son respectivamente nmeros en coma flotante y nmeros en coma flotante de doble precisin, con precisin dependiente de la mquina. float (n) es un nmero en coma flotante, cuya precisin es de al menos n dgitos. date es una fecha del calendario, que contiene un ao (de cuatro dgitos), un mes y un da del mes. time es la hora del da, expresada en horas, minutos y segundos. Se puede usar una variante, time(p), para especificar el nmero de dgitos decimales para los segundos (el nmero predeterminado es 0). Tambin es posible almacenar la informacin del uso horario junto al tiempo. datetime es una combinacin de date y time.
3.2.2 Definicin de esquemas en SQL Un esquema de relacin se define utilizando la orden create table: create table r (A1D1, A2D2, AnDn, <restriccin-integridad1> <restriccin-integridadk> ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 25
Donde r es el nombre de la relacin, cada Ai es el nombre de un atributo del esquema de relacin r y Di es el dominio de los valores del atributo Ai. Las restricciones de integridad vlidas incluyen: Primary key. Los atributos clave primaria deben ser no nulos y nicos. check (P): la clusula check especifica un predicado P que debe satisfacer cada tupla de la relacin. Null. De manera predeterminada, null es un valor vlido para cualquier atributo en SQL, a menos que se especifique con not null. Unique. La especificacin unique indica que los atributos forman una clave candidata; es decir, no puede haber dos tuplas en la relacin con todos los atributos que forman la clave candidata iguales. create table estudiante (idestudiante int not null, nombre char (50), apaterno char (40), amaterno char(40), primary key (idestudiante)) Para borrar una relacin de una base de datos SQL, se utiliza la orden drop table. La instruccin es la siguiente: drop table r La instruccin alter table se utiliza para aadir atributos a una relacin existente. La sintaxis de la instruccin es la siguiente: alter table r add A D donde r es el nombre de una relacin existente, A es el nombre del atributo que se desea aadir y D es el dominio del atributo A. Se pueden eliminar atributos de una relacin utilizando la orden: alter table r drop A donde r es el nombre de una relacin existente y A es el nombre de un atributo de la relacin. 3.3 Lenguaje manipulacin de datos DML EL Lenguaje de manipulacin de datos, se encarga de: La insercin de informacin nueva en la base de datos. El borrado de informacin de la base de datos. La modificacin de la informacin almacenada en la base de datos. La recuperacin de informacin almacenada en la Base de datos.
Un lenguaje de manipulacin de datos (LMD) es un lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado. Existen dos tipos:
26
3.3.1 SENTENCIA SELECT 3.3.1.1 La clasula SELECT Se usa para listar los atributos deseados del resultado de una consulta. SELECT idestudiante FROM estudiante SQL permite duplicidad en las relaciones, as como en el resultado de las expresiones SQL. En aquellos casos donde se quiera forzar la eliminacin de duplicados, se insertar la palabra clave distinct despus de select. Por lo tanto, se puede reescribir la consulta anterior como: SELECT DISTINCT nombre FROM estudiante Asi tambien SQL permite usar la palabra clave all para especificar explcitamente que no se eliminan los duplicados: SELECT ALL carreras FROM estudiante El smbolo asterisco * se puede usar para denotar todos los atributos. SELECT * FROM estudiante La clusula select puede contener tambin expresiones aritmticas que contengan los operadores, +, , * y / operando sobre constantes o atributos de la tuplas. SELECT nombre, edad*10 FROM estudiante 3.3.1.2 La clasula FROM Lista las relaciones que deben ser analizadas en la evaluacin de la expresin. SELECT estudiante.nombre, carrera.nombre estudiante.idestudiante=carrera.idcarrera FROM estudiante, carrera WHERE
3.3.1.3 La clasula WHERE Es un predicado que engloba a los atributos de las relaciones que aparecen en la clusula from. SQL usa las conectivas lgicas and, or y not en la clusula where. Los operandos de las conectivas lgicas pueden ser expresiones que contengan los operadores de comparacin <, <=, >, >=, = y <>. SQL permite usar los operadores de comparacin para comparar cadenas y expresiones aritmticas, as como tipos especiales, tales como el tipo fecha. SQL incluye un operador de comparacin between para simplificar las clusulas where que especifica que un valor sea menor o igual que un valor y mayor o igual que otro valor. SELECT estudiante.nombre, carrera.nombre FROM estudiante, carrera WHERE estudiante.idestudiante=carrera.idcarrera AND carrera.idcarrera=IS
27
Operaciones sobre cadenas SQL especifica las cadenas encerrndolas entre comillas simple, como Julio. La operacin ms usada sobre cadenas es el encaje de patrones, para el que se usa el operador like. Para la descripcin de patrones se utilizan los dos caracteres siguientes: Tanto por ciento (%): El carcter % encaja con cualquier subcadena. Subrayado (_): El carcter _ encaja con cualquier carcter. Los patrones son muy sensibles, esto es, los caracteres en maysculas no encajan con los caracteres en minscula, o viceversa. Nava% encaja con cualquier cadena que empiece con Nava. %cer% encaja con cualquier cadena que contenga uli como subcadena, por ejemplo julio. _ _ _ encaja con cualquier cadena de tres caracteres. _ _ _% encaja con cualquier cadena de al menos tres caracteres.
Valores Nulos SQL permite el uso de valores nulos para indicar la ausencia de informacin sobre el valor de un atributos. Se usa la palabra clave null para comprobar si un valor es nulo. Se usa is not null para verificar valores no nulos 3.3.1.4 La clasula AS SQL proporciona un mecanismo para renombrar tanto relaciones como atributos. Para ello utiliza la clusula as. La clusula as puede aparecer tanto en select como en from. SELECT e.nombre, c.nombre as nomcarrera FROM estudiante as e, carrera as c WHERE e.idestudiante=c.idcarrera AND c.idcarrera=IS 3.3.1.5 La clasula Order By SQL ofrece al usuario cierto control sobre el orden en el cual se presentan las tuplas de una relacin. La clusula order by hace que las tuplas resultantes de una consulta se presenten en un cierto orden. SELECT e.nombre, c.nombre as nomcarrera FROM estudiante as e, carrera as c WHERE e.idestudiante=c.idcarrera AND c.idcarrera=IS Order By e.nombre De manera predeterminada la clusula order by lista los elementos en orden ascendente. Para especificar el tipo de ordenacin se puede incluir la clusula desc para orden descendente o asc para orden ascendente. Adems, se puede ordenar con respecto a ms de un atributo. SELECT e.nombre, c.nombre as nomcarrera FROM estudiante as e, carrera as c WHERE e.idestudiante=c.idcarrera AND c.idcarrera=IS Order By c.nombre ASC, e.nmbre DESC
28
3.3.1.6 Clasula GROUP BY El atributo o atributos especificados en la clusula group by se usan para formar grupos. Las tuplas con el mismo valor en todos los atributos especificados en la clusula group by se colocan en un grupo. Sobre estos grupos se aplican las funciones de agregacin que toman una coleccin (un conjunto o multiconjunto) de valores como entrada y producen un nico valor como salida. SQL proporciona cinco funciones de agregacin primitivas: Media: avg Mnimo: min Mximo: max Total: sum Cuenta: count SELECT c.nombre, count(e.idestudiante) FROM estudiante as e, carrera as c WHERE e.idestudiante=c.idcarrera AND c.idcarrera=IS GROUP BY c.nombre 3.3.1.7 Clusula HAVING Tambin se puede establecer condicines a los grupos. Esta condicin no es aplicable a una nica tupla; se aplica a cada grupo construido por la clusula group by. Para expresar este tipo de consultas se utiliza la clusula having de SQL. SELECT c.nombre, count(e.idestudiante) FROM estudiante as e, carrera as c WHERE e.idestudiante=c.idcarrera AND c.idcarrera=IS GROUP BY c.nombre HAVING count(e.idestudiante)>10 3.3.1.8 Clasula UNION Permite unir dos consultas para generar un nico conjunto resultado. Para ello se tiene que cumplir que ambas generen conjuntos con idnticas columnas (nmero y tipo de datos). Select nombre from estudiante UNION Select nombre from docente La operacin unin elimina los duplicados automticamente; pero si se desea conservar los duplicados se debe usar UNION ALL. 3.3.2 SENTENCIA INSERT Para insertar datos en una relacin, o bien se especifica la tupla que se desea insertar o se formula una consulta cuyo resultado sea el conjunto de tuplas que se desean insertar. Los valores de los atributos de la tuplas que se inserten deben pertenecer al dominio de los atributos. Se utiliza la sentencia insert. Ejm: insert into estudiante values (991102C,Jose,Valdez,IS) insert into estudiante (idestudiante, momestudiante, apestudiante, idcarrera) values (991102C,Jose,Valdez,IS) ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 29
insert into estudiante select iddocente, nomdocente, apdocente, IS from docente
3.3.3 SENTENCIA UPDATE Sql permite cambiar un valor dentro de una tupla, sin cambiar todos los valores de la misma. Para este tipo de situaciones se utiliza la sentencia update. update estudiante set nombre = Jose Manuel update estudiante set nombre = Jose Manuel Where idestudiante=991102C 3.3.4 SENTENCIA DELETE Un borrado se expresa de igual forma que una consulta. Se pueden borrar slo tuplas completas, es decir, no se pueden borrar valores de atributos concretos. delete from estudiante Where idestudiante=991102C 3.4 DEFINICIN DE VISTAS Una vista es una tabla derivada de otras tablas (bsicas o virtuales). Una vista se caracteriza porque: Se considera que forma parte del esquema externo. Una vista es una tabla virtual (no tiene una correspondencia a nivel fsico) Se puede consultar como cualquier tabla bsica. Las actualizaciones se transfieren a la/s tabla/s original/es. Una vista en SQL se define utilizando la orden create view. Para definir una vista se le debe dar un nombre y se debe construir la consulta que genere dicha vista. La forma de la orden create view es la siguiente: create view v as <expresin de consulta> 3.5 DEFINICION DE PROCEDIMIENTOS ALMACENADOS Un procedimiento almacenado Transact-SQL es una coleccin guardada de instrucciones TransactSQL que puede tomar y devolver los parmetros proporcionados por el usuario. Por ejemplo, un procedimiento almacenado puede contener las instrucciones necesarias para insertar una nueva fila en una o ms tablas segn la informacin suministrada por la aplicacin cliente o es posible que el procedimiento almacenado devuelva datos de la base de datos a la aplicacin cliente. Por ejemplo, una aplicacin Web de comercio electrnico puede utilizar un procedimiento almacenado para devolver informacin acerca de determinados productos en funcin de los criterios de bsqueda especificados por el usuario en lnea. 3.6 DEFINICION DE DESENCADENADORES Un desencadenador (Trigger) es un tipo especial de procedimiento almacenado que se activa de forma controlada por sucesos antes que por llamadas directas. Los desencadenadores (Triggers) estn asociados a tablas. Son una gran herramienta para controlar las reglas de negocio ms complejas que una simple integridad referencial, los desencadenadores (Triggers) y las sentencias que desencadenan su ejecucin trabajan unidas como una transaccin. Las instrucciones de la definicin del Desencadenador deben ser INSERT, UPDATE o DELETE. Un Desencadenador para insercin de registros genera automticamente una tabla en el cache con la informacin que intenta aadir, esta tablita se denomina INSERTED y es a travs de esta tabla que se pueden hacer comparaciones en otras tablas. ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 30
Un Desencadenador para eliminacin de registros genera automticamente una tabla en el cache con la informacin que intenta eliminar, esta tablita se denomina DELETED y es a travs de esta tabla que se pueden hacer comparaciones en otras tablas. Si se trata de un Desencadenador para actualizacin se generan ambas tablas INSERTED con los nuevos datos y DELETED con la informacin que ser reemplazada La sintaxis para la creacin de triggers es la siguiente: CREATE TRIGGER <trigger name> FOR <INSERT|DELETE|UPDATE> ON <relation name> EXECUTE PROCEDURE <procedure name> (<function args>);
31
IV.
ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS

4.1 ARQUITECTURA CENTRALIZADA Una Base de Datos Centralizada es una Base de Datos que almacena grandes cantidades de datos en un solo punto, estos datos son accesados por todos los usuarios de los diferentes sistemas que interactan con ella.
Figura 16. Base de Datos centralizada Por sus caractersticas y seguridades una Base de Datos es uno de los elementos primordiales en todo sistema de informacin, a diferencia de otros medios de almacenamientos, como lo son archivos, las Bases de Datos poseen estructuras y componentes internos que organizan de una manera eficaz y eficiente los datos, el acceso a los datos almacenados en una Base de Datos se realiza mediante el lenguaje SQL (Structure Query Languaje). Las Bases de Datos son administradas por un Motor de Base de Datos o Sistema de Administracin de Bases de Datos DBMS por sus siglas en ingles, estos sistemas manejan todos los requerimientos que hacen los usuarios a una Base de Datos. Los usuarios de una Base de Datos se dividen por lo general en tres grandes grupos: Los usuarios finales: son quienes interactan con la Base de Datos desde sus terminales de trabajo, por lo general los usuarios finales son quienes ingresan, consultan, modifican y eliminan registros mediante programas o sistemas instalados en sus terminales de trabajo. Los programadores: son los responsables de escribir los programas o sistemas que interactan con la Base de Datos en algn lenguaje de programacin. Los Administradores de Bases de Datos (DBA): son los encargados de supervisar la consistencia e integridad de los datos almacenados en una Base de Datos, tambin son los responsables de migrar datos y hacer respaldos para evitar perdida de datos. Las Bases de Datos estn compuestas por entidades o tablas, las tablas estn asociadas entre si mediante relaciones y de estas asociaciones nace lo que se conoce como el Modelo Entidad Relacin (representacin grfica de cmo se relacionan las tablas de una Base de Datos). Ventajas de las Bases de Datos Centralizadas Se evita la redundancia. En sistemas que no usan Bases de Datos Centralizadas, cada aplicacin tiene sus propios archivos privados o se encuentran en diferentes localidades. Esto a menudo ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 32
origina enorme redundancia en los datos almacenados, as como desperdicio resultante del espacio de almacenamiento. Cumplimiento de normas establecidas. Con un control central de la base de datos, el administrador de la DB puede garantizar que se cumplan todas las formas aplicables a la representacin de los datos. Las normas aplicables pueden ser: normas de la compaa, de instalacin, departamentales, industriales, etc. Es muy deseable unificar los formatos de los datos almacenados como ayuda para el intercambio o migracin de datos entre sistemas. Aplicacin de restricciones de seguridad. Al tener jurisdiccin completa sobre los datos de operacin, el DBA puede: o Asegurar que el nico medio de acceder la base de datos sea a travs de los canales establecidos. o Definir controles de autorizacin para que se apliquen cada vez que se intente el acceso a datos sensibles. Diferentes controles pueden establecerse para cada tipo de acceso (recuperacin, modificacin, supresin, etc.) a cada parte de la informacin de la base de datos. Conservacin de la integridad. El problema de la integridad es garantizar que los datos de la Base de Datos sean exactos. El control centralizado de la base de datos, (que los datos se encuentren en una sola mquina), ayuda a evitar la inconsistencia de los datos. La integridad de los datos es un aspecto muy importante en una Base de Datos, porque los datos almacenados se comparten y porque sin procedimientos de validacin adecuados es posible que un programa con errores genere datos incorrectos que afecten a otros programas que utilicen esa informacin. Cuando se conocen los requerimientos globales de la empresa, en contraste con los requerimientos de cualquier usuario individual, el administrador de la DB puede estructurar el sistema de Base de Datos para brindar un servicio que sea el mejor para la empresa en trminos globales.
4.2 ARQUITECTURA CLIENTE-SERVIDOR Cualquier LAN (red de rea local) puede ser considerada como un sistema cliente/servidor, desde el momento en que el cliente solicita servicios como datos, ficheros o imprimir desde el servidor. Cuando un usuario se conecta a Internet, interacta con otros computadores utilizando el modelo cliente/servidor. El servidor es el computador que contiene informacin (bases de datos, ficheros de texto...). El usuario, o cliente, accede a esos recursos va programas cliente (aplicaciones) que usan TCP/IP para entregar la informacin a su computadora. Dado este entorno un cliente que necesite hacer una consulta o actualizacin en una Base de Datos centralizada, enva una peticin al servidor de la Base de Datos y este le devuelve los datos solicitados. La funcionalidad de una base de datos se puede dividir en dos partes: El sistema subyacente gestiona el acceso a las estructuras, la evaluacin y optimizacin de consultas, el control de concurrencia y la recuperacin. La parte visible al usuario de un sistema de base de datos est formado por herramientas como formularios, diseadores de informes y facilidades grficas de interfaz de usuario. La interfaz entre la parte visible al usuario y el sistema subyacente puede ser SQL o una aplicacin.
33
4.2.1 Las normas: ODBC (Open Database Connectivity, conectividad abierta de bases de datos) define una forma para que un programa de aplicacin se comunique con un servidor de bases de datos. ODBC define una interfaz para programas de aplicacin (API, Application Program Interface) que pueden usar las aplicaciones para abrir una conexin con una base de datos, enviar consultas y actualizaciones y obtener los resultados. JDBC (Java Database Connectivity conectividad de bases de datos con Java), La norma JDBC define una API que pueden usar los programas Java para conectarse a los servidores de bases de datos 4.2.2 TIPOS DE ARQUITECTURAS CLIENTE/SERVIDOR a) Arquitectura de 2 capas La arquitectura cliente/servidor tradicional es una solucin de 2 capas. La arquitectura de 2 capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios). Los tres componentes son: o Interfaz de usuario. o Gestin del procesamiento. o Gestin de la base de datos.
Figura 17. Arquitectura 2 capas Hay 2 tipos de arquitecturas cliente servidor de dos capas: Clientes obesos (thick clients): La mayor parte de la lgica de la aplicacin (gestin del procesamiento) reside junto a la lgica de la presentacin (interfaz de usuario) en el cliente, con la porcin de acceso a datos en el servidor. Clientes delgados (thin clients): solo la lgica de la presentacin reside en el cliente, con el acceso a datos y la mayora de la lgica de la aplicacin en el servidor. Es posible que un servidor funcione como cliente de otro servidor. Esto es conocido como diseo de dos capas encadenado. b) Arquitectura de 3 capas La arquitectura de 3 capas surgi para superar las limitaciones de la arquitectura de 2 capas. La tercera capa (servidor intermedio) est entre el interfaz de usuario (cliente) y el gestor de datos
34
(servidor). La capa intermedia proporciona gestin del procesamiento y en ella se ejecutan las reglas y lgica de procesamiento. Permite cientos de usuarios (en comparacin con slo 100 usuarios de la arquitectura de 2 capas). La arquitectura de 3 capas es usada cuando se necesita un diseo cliente/servidor que proporcione, en comparacin con la arquitectura de 2 capas, incrementar el rendimiento, flexibilidad, mantenibilidad, reusabilidad y escalabilidad mientras se esconde la complejidad del procesamiento distribuido al usuario.
Figura 18. Arquitectura 3 capas VENTAJAS Las principales ventajas del modelo Cliente/Servidor son las siguientes: Interoperabilidad: los componentes clave (cliente, servidor y red) trabajan juntos. Flexibilidad: la nueva tecnologa puede incorporarse al sistema. Escalabilidad: cualquiera de los elementos del sistema puede reemplazarse cuando es necesario, sin impactar sobre otros elementos. Si la base de datos crece, las computadoras cliente no tienen que equiparse con memoria o discos adicionales. Esos cambios afectan solo a la computadora en la que se ejecuta la base de datos. Usabilidad: mayor facilidad de uso para el usuario. Integridad de los datos: entidades, dominios, e integridad referencial son mantenidas en el servidor de la base de datos. Accesibilidad: los datos pueden ser accedidos desde mltiples clientes. Rendimiento: se puede optimizar el rendimiento por hardware y procesos. Seguridad: la seguridad de los datos est centralizada en el servidor.
INCONVENIENTES Hay una alta complejidad tecnolgica al tener que integrar una gran variedad de productos. El mantenimiento de los sistemas es ms difcil pues implica la interaccin de
35
diferentes partes de hardware y de software, distribuidas por distintos proveedores, lo cual dificulta el diagnstico de fallos. Requiere un fuerte rediseo de todos los elementos involucrados en los sistemas de informacin (modelos de datos, procesos, interfaces, comunicaciones, almacenamiento de datos, etc.). Adems, en la actualidad existen pocas herramientas que ayuden a determinar la mejor forma de dividir las aplicaciones entre la parte cliente y la parte servidor. Es ms difcil asegurar un elevado grado de seguridad en una red de clientes y servidores que en un sistema con un nico ordenador centralizado (cuanto ms distribuida es la red, mayor es su vulnerabilidad). A veces, los problemas de congestin de la red pueden reducir el rendimiento del sistema por debajo de lo que se obtendra con una nica mquina (arquitectura centralizada). Tambin la interfaz grfica de usuario puede a veces ralentizar el funcionamiento de la aplicacin. Existen multitud de costes ocultos (formacin en nuevas tecnologas, cambios organizativos, etc.) que encarecen su implantacin. La arquitectura cliente/servidor es una arquitectura que est en evolucin, y como tal no existe estandarizacin.
4.3 Arquitectura distribuida
Nodo w
DBMw
BDw
Nodo x Programa de consulta o transaccin Nodo y
DTMx
DBMx
BDx
Programa de consulta o transaccin Nodo z Programa de consulta o transaccin
DTMy
DBMy
BDy
DDB DTMz Interfaz de accin

z
Interfaz de solicitud
DDBMS
Figura 19. Arquitectura 3 capas ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 36
Es el procesamiento de bases de datos en el cual la ejecucin de transacciones, la recuperacin y actualizacin de los datos acontece a travs de dos o ms computadoras independientes, por lo general separadas geogrficamente. En la siguiente figura se muestra un sistema de base de datos distribuida. El sistema de administracin de base de datos distribuida (DDBMS), est formado por las transacciones y los administradores de base de datos distribuidos de todas las computadoras. Tal y como se muestra en la figura anterior, es un esquema genrico que implica un conjunto de programas que operan en diversas computadoras. Estos programas pueden ser subsistemas de un producto nico DDBMS, concesionado por un slo fabricante, o tambin pudiera resultar una coleccin de programas de fuentes dispares: algunos concesionados por fabricantes, y algunos otros escritos en casa. Un administrador de transacciones distribuidas (DTM) es un programa que recibe so- licitudes de procesamiento de los programas de consulta o de transacciones y a su vez las traduce en acciones para los administradores de la base de datos. Una funcin importante del DTM es coordinar y controlar dichas acciones. Un administrador de la base de datos (DBM) es un programa que procesa cierta porcin de la base de datos distribuida, como es el hecho de recuperar y actualizar datos del usuario y generales, de acuerdo con comandos de accin recibidos de los DTM. 4.3.1 CARACTERISTICAS DE LAS BDD Los datos deben estar fsicamente en ms de un ordenador, es decir, los datos se encuentran almacenados en distintas sedes. Las sedes deben estar interconectadas mediante una red de computadoras (cada sede ser un nodo de la red). Para realizar el diseo no se tendr en cuenta la topologa, tipo y rendimiento de la red, aunque estas propiedades tengan relevancia en el buen funcionamiento del sistema. Los datos han de estar lgicamente integrados en una nica estructura o esquema lgico global comn. Los usuarios han de tener acceso (recuperacin y actualizacin) a los datos pertenecientes a la BDD, ya residan stos en la misma sede (acceso local) o en otra sede (acceso remoto). Cada nodo o emplazamiento facilita un entorno para la ejecucin de transacciones tanto locales como globales. En una nica operacin, tanto de consulta como de actualizacin, se puede acceder a datos que se encuentran en ms de una sede sin que el usuario sepa la distribucin de los mismos en las distintas sedes. Es decir, que la distribucin de la informacin sea transparente para el usuario. VENTAJAS DE LAS BDD La naturaleza distribuida de algunas aplicaciones de bases de datos. Muchas de estas aplicaciones estn distribuidas naturalmente en diferentes lugares. Por ejemplo, una compaa puede tener oficinas en varias ciudades, o un banco puede tener mltiples sucursales. Es natural que las bases de datos empleadas en tales aplicaciones estn distribuidas en esos lugares. Muchos usuarios locales tienen acceso exclusivamente a los datos que estn en el lugar, pero otros usuarios globales pueden requerir acceso ocasional a los datos almacenados 37
4.3.2
en varios de estos emplazamientos. Mayor fiabilidad y disponibilidad. La fiabilidad se define como la probabilidad de que un sistema est en funcionando en un momento determinado. La disponibilidad es la probabilidad de que el sistema est disponible continuamente durante un intervalo de tiempo. Cuando los datos y el software del sistema gestor de base de datos estn distribuidos en varios sitios, un sitio puede fallar mientras que los dems siguen operando. Slo los datos y el software que residen en el sitio que fall estn inaccesibles. Esto mejora tanto la fiabilidad como la disponibilidad. En un sistema centralizado, el fallo de un solo sitio hace que el sistema completo deje de estar disponible para todos los usuarios. Posibilidad de compartir los datos al tiempo que se mantiene un cierto grado de control local. En algunos tipos de Sistemas de Bases de Datos Distribuidas (SBDD), es posible controlar los datos y el software localmente en cada sitio. Sin embargo, los usuarios de otros sitios remotos pueden tener acceso a ciertos datos a travs del software del SGBDD. Esto hace viable poder compartir de forma controlada los datos en todo el sistema distribuido. Mejor rendimiento. Cuando una base de datos grande est distribuida en mltiples sitios, hay bases de datos ms pequeas en cada uno de stos. En consecuencia, las consultas locales y las transacciones que tienen acceso a datos de un solo sitio tienen un mejor rendimiento porque las bases de datos locales son ms pequeas. Adems, cada sitio tiene un menor nmero de transacciones en ejecucin que si todas las transacciones se enviaran a una sola base de datos centralizada. En el caso de transacciones que impliquen acceso a ms de un sitio, el procesamiento en los diferentes sitios puede efectuarse en paralelo, reducindose as el tiempo de respuesta. Plataforma autnoma. Dado que las aplicaciones y bases de datos no residen en las mismas mquinas, no hay ninguna razn particular para residir en el mismo tipo de mquina. Esta libertad permite a los administradores de bases de datos, desarrolladores y usuarios de escritorio elegir sus plataformas sin arriesgar cambios de funcionalidad en el motor de base de datos. Localizacin transparente. Esto significa que ni las aplicaciones ni los usuarios necesitan preocuparse de dnde residen los datos o cmo se distribuyen. Al ser protegidos por estas caractersticas especficas la usabilidad de una base de datos aumenta ya que los desarrolladores y los usuarios no necesitan tener en cuenta detalles tales como cadenas de conexin. Por otra parte, los datos pueden ser trasladados de una instancia de base de datos a otra con un impacto mnimo sobre los usuarios y aplicaciones. Autonoma del sitio. Las BDD permiten varias localizaciones para compartir sus datos sin ceder el control administrativo. Si la sede de una instancia de base de datos contiene informacin especialmente sensible o tiene requerimientos de alta disponibilidad, todava puede compartir datos sin comprometer su seguridad o la disponibilidad. Adems, un sitio determinado en un entorno de BDD puede seguir sus propios procedimientos administrativos y actualizacin de rutas, dentro de lo razonable. Seguridad mejorada. Los componentes de la arquitectura distribuida son completamente independientes unos de otros, lo que significa que cada sitio puede mantenerse de forma independiente. Se pueden compartir los datos sin compartir cuentas y contraseas. Cada sitio puede tener sus propios administradores y sus propios conjuntos de cuentas, y los datos privados se pueden mantener en privado. Tambin se puede configurar un entorno distribuido para proporcionar seguridad en el sentido de la supervivencia, es decir, puede mantener dos o 38
ms versiones del esquema completo de la BD replicados en diferentes mquinas en diferentes lugares. En BDD no hay ninguna razn para que los desarrolladores o usuarios finales tengan su cuenta en un servidor de base de datos, porque todos los accesos de base de datos se producen a travs de APIs (Application Programming Interfaces) de red. De este modo, se minimiza la exposicin de dicho servidor de base de datos a posibles intrusiones maliciosas o a usuarios poco cuidadosos. 4.3.3 Desventajas de las BDD En contra, la distribucin produce un aumento en la complejidad del diseo y en la implementacin de nuevos sistemas [3]. Seguridad. Es una ventaja y tambin una desventaja, debido a que puede ser difcil saber y controlar quin est accediendo a una base de datos mediante un enlace de BD. Las cuentas a las cuales se conecta un enlace de BD no debe dar ms derechos de acceso que los absolutamente necesarios. Coherencia de los datos. Si existen varias rplicas una de las tareas de mayor esfuerzo ser garantizar la coherencia de datos. Esta responsabilidad es compartida entre los diseadores, desarrolladores y administradores de bases de datos. Seguimiento. La carga de trabajo de un DBA en un entorno distribuido puede ser considerable. El DBA debe controlar objetos tales como las colas de trabajos, colas de transacciones, y las colas de errores. Si los problemas en un entorno distribuido se dejan sin resolver, puede ser tan difcil corregirlos que incluso sea ms fcil recargar los datos desde el principio que tratar de solucionar errores especficos. Recuperacin. Si una base de datos que forma parte de un entorno distribuido falla, el proceso de recuperacin no slo debe garantizar la restauracin completa de los datos locales, sino tambin la restauracin de los datos distribuidos, tales como las transacciones e instancias suspendidas. Rendimiento. Varios factores pueden afectar el rendimiento en una base de datos distribuida. Si la aplicacin, referencia datos desde un enlace de base de datos, el rendimiento de la red tendr una influencia directa en el funcionamiento de la BDD. Los componentes de replicacin que utilizan tcnicas de almacenamiento y reenvo, tales como instantneas y maestros de replicacin, tambin tendrn su coste en el rendimiento global del sistema. El almacenamiento y la transmisin de operaciones impacta en el rendimiento general del sistema, y se debe tener en cuenta lo que esto significa cuando se especifican los requisitos de hardware.
39
4.3.4
Clasificacin de los SGBDD
Figura 20. Clasificacin de los SGBDD Distribucin Los datos pueden ser distribuidos entre mltiples bases de datos. Estas bases de datos pueden estar almacenadas en un nico sistema informtico o en varios, distribuidos geogrficamente, pero interconectados por un sistema de comunicacin. Los datos pueden ser distribuidos entre mltiples bases de datos de diferentes maneras. Estos incluyen, en trminos relacionales, particiones de base de datos verticales y horizontales. Adems pueden mantenerse varias copias de todo o parte de los datos. Estas copias no tienen por qu tener una estructura idntica. Autonoma Se refiere a la distribucin del control, no de los datos. Indica el grado en el que los SGBDs pueden actuar independientemente y es funcin de factores tales como el nivel de intercambio de informacin entre los componentes del sistema, la ejecucin independiente de transacciones, la tolerancia a modificaciones respectivas en los datos, etc. Autonoma de diseo: La capacidad de que cada nodo de la base de datos decida los aspectos relacionados con su diseo. Es decir, las personas involucradas son libres de decidir cualquier particularidad e incluso decidir qu SGBD utilizar. Los aspectos a considerar en la autonoma de diseo son: Autonoma de comunicacin: es la habilidad de que un nodo decida comunicarse o no con otro componente.
40
Autonoma de ejecucin: es la habilidad de un nodo para ejecutar operaciones locales sin la interferencia de operaciones externas, en el orden en que el nodo lo decida. Autonoma de asociacin: cada nodo cunto y cundo puede compartir su funcionalidad y recursos con otros componentes.
Heterogeneidad La heterogeneidad puede referirse a diferentes aspectos, desde diferencias hardware o en los protocoles de red, hasta variaciones en los SGBDs propiamente (modelos de datos, lenguaje de manipulacin de datos, protocolos de gestin de transacciones,)
4.3.5 Fragmentacin La fragmentacin es un conjunto de tcnicas para dividir la BD en unidades lgicas, llamadas fragmentos, cuyo almacenamiento puede asignarse a los diversos sitios. Estas tcnicas se utilizan durante el proceso de diseo de BDD. Fragmentacin vertical La fragmentacin vertical divide la relacin verticalmente en columnas, as cada fragmento mantiene ciertos atributos de la relacin original. Fragmentacin horizontal La fragmentacin horizontal divide la relacin en subconjuntos de tuplas, cada uno de ellos con un significado lgico. Fragmentacin mixta o hbrida La fragmentacin mixta es la mezcla de fragmentacin horizontal y vertical. Hay dos tipos de fragmentacin mixta: Fragmentacin VH Es una fragmentacin vertical seguida de una fragmentacin horizontal, sobre cada uno de los fragmentos verticales. Fragmentacin HV Es una fragmentacin horizontal seguida de una fragmentacin vertical.
41
V.
PROCESAMIENTO DE TRANSACCIONES
5.1 Concepto de transaccin Una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos y est delimitada por instrucciones de la forma: inicio transaccin y fin transaccin. La transaccin consiste en todas las operaciones que se ejecutan entre inicio transaccin y el fin transaccin. Para asegurar la integridad de los datos se necesita que el sistema de la base de datos mantenga las siguientes propiedades de las transacciones: Atomicidad: Todas las operaciones de la transaccin se realizan adecuadamente en la base de datos o ninguna de ellas. Consistencia: La ejecucin aislada de la transaccin (es decir, sin otra transaccin que se ejecute concurrentemente) conserva la consistencia de la base de datos. Aislamiento: Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones Ti y Tj se cumple que para los efectos de Ti, o bien Tj ha terminado su ejecucin antes de que termine Ti, o bien que Tj ha comenzado su ejecucin despus de que Ti termine. Durabilidad: Tras la finalizacin con xito de una transaccin, los cambios realizados en la base de datos permanecen incluso si hay fallos en el sistema. 5.2 Operaciones de una transaccin Inicio de transaccin.- Operacin que marca el momento en el que una transaccin comienza a ejecutarse. Leer o escribir.- Operaciones de lectura/escritura de elementos de la base de datos. Fin de la transaccin.- Se verifica si la transaccin debe abortarse por alguna razn. Confirmar (COMMIT).- La operacin termino con xito. Abortar(ROLLBACK).- La transaccin termino sin xito. 5.3 Estados de una transaccin En ausencia de fallos todas las transacciones se completan con xito. Sin embargo una transaccin puede que no siempre acabe su ejecucin con xito. Una transaccin de este tipo se denomina abortada. Una vez deshechos los cambios efectuados por la transaccin abortada, se dice que la transaccin esta retrocedida. Una transaccin que termina con xito se dice que est comprometida. Una transaccin debe estar en uno de los siguientes estados: Activa: Estado inicial, permanece en ese estado durante su ejecucin. Parcialmente comprometida: Despus de ejecutarse la ltima instruccin. Fallida: Tras descubrir que no puede continuar la ejecucin normal. Abortada: Despus del retroceso de la transaccin y de haber restablecido la Base de Datos a su estado anterior al comienzo de la transaccin. Comprometida: Tras completarse con xito.
42
Parcialmente comprometida
Comprometida Activa
Fallida
Abortada
Figura 21. Estados de una Transicin
Una transaccin llega al estado fallida despus de que el sistema determine que dicha transaccin no puede continuar su transaccin normal. En abortada el sistema debe decidir entre reiniciar la transaccin o cancelarla. 5.4 Atomicidad y durabilidad El componente de gestin de recuperaciones de un sistema de base de datos implementa el soporte para la atomicidad y la durabilidad. En primer lugar consideramos un esquema simple pero extremadamente ineficiente, denominado copia en la sombra. Este esquema, que se basa en hacer copias de la base de datos, denominadas copias sombra, asume que slo una transaccin est activa en cada momento. El esquema asume que la base de datos es simplemente un archivo en disco. En disco se mantiene un puntero llamado puntero_bd que apunta a la copia actual de la base de datos. En el esquema de copia en la sombra, una transaccin que quiera actualizar una base de datos crea primero una copia completa de dicha base de datos. Todos los cambios se hacen en la nueva copia de la base de datos dejando la copia original, la copia en la sombra, inalterada. Si en cualquier punto hay que abortar la transaccin, la copia nueva simplemente se borra. La copia antigua de la base de datos no se ve afectada. Si la transaccin se completa, se compromete como sigue. En primer lugar se consulta al sistema operativo para asegurarse de que todas las pginas de la nueva copia de la base de datos se han escrito en disco. Despus de terminar esta orden se actualiza el puntero puntero_bd para que apunte a la nueva copia de la base de datos; la nueva copia se convierte entonces en la copia de la base de datos actual. La copia antigua de la base de datos se borra despus. El esquema se describe en la Figura , en la cual se muestra el estado de la base de datos antes y despus de la actualizacin. Se dice que la transaccin est comprometida en el momento en que puntero_bd actualizado se escribe en disco. En primer lugar, considerar un fallo en la transaccin. Si la transaccin falla en algn momento antes de actualizar puntero_ bd, el contenido de la base de datos anterior no se ve afectado. Se puede ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 43
abortar la transaccin simplemente borrando la nueva copia de la base de datos. Una vez que se ha comprometido la transaccin, puntero_bd apunta a todas las modificaciones que sta ha realizado en la base de datos. De este modo, o todas las modificaciones de la transaccin se ven reflejadas o ninguna de ellas, independientemente del fallo de la transaccin. Considrese ahora el resultado de un fallo en el sistema. Supngase que el sistema falla en algn momento antes de escribir en disco el puntero_bd actualizado. Entonces cuando se reinicie el sistema, leer puntero_bd y ver el contenido original de la base de datos, y ninguno de los efectos de la transaccin ser visible en la base de datos. Supongamos que el sistema falla despus de actualizar en disco puntero_bd. Antes de que el puntero se actualice, todas las pginas actualizadas de la nueva copia de la base de datos se escriben en disco. De nuevo, se asume que una vez que un archivo se escribe en disco, su contenido no se daa incluso si hay un fallo del sistema. Por tanto, cuando el sistema se reinicie, leer puntero_bd y ver el contenido de la base de datos despus que la transaccin haya realizado todas las modificaciones. La implementacin depende realmente de que escribir puntero_bd sea una operacin atmica; es decir, o se escriben todos sus bytes o ninguno de ellos. Si se escribieran algunos de los bytes del puntero y otros no, el puntero no tendra sentido y al reiniciarse el sistema no se podran encontrar ni la versin anterior ni la nueva de la base de datos. Los sistemas de disco proporcionan actualizaciones atmicas de bloques enteros, o al menos de un sector del disco; es decir , el sistema de disco garantiza la actualizacin automtica de puntero_bd. siempre que nos aseguremos de que puntero_bd cabe en un nico sector, lo que se puede asegurar almacenndolo al comienzo de un bloque. De este modo, la implementacin de la copia en la sombra del componente de gestin de recuperaciones asegura las propiedades de atomicidad y durabilidad de las transacciones.
puntero-bd
puntero-bd
Copia anterior de la base de datos
Copia anterior de la base de datos
nueva copia de la base de datos
5.5 Ejecuciones concurrentes Los sistemas de procesamiento de transacciones permiten la ejecucin de varias transacciones concurrentemente. Permitir varias transacciones que actualizan concurrentemente los datos provoca complicaciones en la consistencia de los mismos. Asegurar la consistencia a pesar de la ejecucin concurrente de las transacciones requiere un trabajo extra; es mucho ms sencillo exigir que las transacciones se ejecuten secuencialmente, es decir, una a una, comenzando cada una slo despus de que la anterior se haya completado. Sin embargo, existen dos buenas razones para permitir la concurrencia. Productividad y utilizacin de recursos mejorados. Una transaccin consiste en varios pasos. Algunos implican operaciones de E/S; otros implican operaciones de UCP. La UCP y los discos pueden trabajar en paralelo en una computadora. Por tanto, las operaciones de E/S se pueden ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 44
realizar en paralelo con el procesamiento de la UCP. Se puede entonces explotar el paralelismo de la UCP y del sistema de E/S para ejecutar varias transacciones en paralelo. Mientras una transaccin ejecuta una lectura o una escritura en un disco, otra puede ejecutarse en la UCP mientras una tercera transaccin ejecuta una lectura o una escritura en otro disco. Todo esto incrementa la productividad (throughput) del sistema, es decir, en el nmero de transacciones que puede ejecutar en un tiempo dado. Tiempo de espera reducido. Debe haber una mezcla de transacciones que se ejecutan en el sistema, algunas cortas y otras largas. Si las transacciones se ejecutan secuencialmente, la transaccin corta debe esperar a que la transaccin larga anterior se complete, lo cual puede llevar a un retardo impredecible en la ejecucin de la transaccin. Si las transacciones operan en partes diferentes de la base de datos es mejor hacer que se ejecuten concurrentemente, compartiendo los ciclos de la UCP y los accesos a disco entre ambas. La ejecucin concurrente reduce los retardos impredecibles en la ejecucin de las transacciones. Adems se reduce tambin el tiempo medio de respuesta: el tiempo medio desde que una transaccin comienza hasta que se completa. Cuando se ejecutan varias transacciones concurrentemente, la consistencia de la base de datos se puede destruir a pesar de que cada transaccin individual sea correcta. En este apartado se presenta el concepto de planificaciones que ayudan a identificar aquellas ejecuciones que garantizan que se asegura la consistencia. El sistema de base de datos debe controlar la interaccin entre las transacciones concurrentes para evitar que se destruya la consistencia de la base de datos. Esto se lleva a cabo a travs de una serie de mecanismos denominados esquemas de control de concurrencia. Las secuencias de ejecucin que se acaban de describir se denominan planificaciones. Representan el orden cronolgico en el que se ejecutan las instrucciones en el sistema. Obviamente una planificacin para un conjunto de transacciones debe consistir en todas las instrucciones de dichas transacciones, y debe conservar el orden en que aparecen las instrucciones en cada transaccin individual. Por ejemplo, en la transaccin T1 la instruccin escribir(A) debe aparecer antes de la instruccin leer(B) en cualquier planificacin vlida.
5.6 Secuenciabilidad El sistema de base de datos debe controlar la ejecucin concurrente de las transacciones para asegurar que el estado de la base sigue siendo consistente. Primero se debe entender las planificaciones que aseguran la consistencia y las que no, luego examinar cmo debe realizar esta tarea. Las transacciones son programas, es difcil calcular cules son las operaciones exactas que realiza una transaccin y cmo interaccionan las operaciones de varias transacciones. Por este motivo no se van a interpretar los tipos de operaciones que puede realizar una transaccin sobre un elemento de datos. En lugar de esto se consideran slo dos operaciones: leer y escribir. Se asume as que entre una instruccin leer(Q) y otra escribir(Q) sobre un elemento de datos Q, una transaccin puede realizar una secuencia arbitraria de operaciones con la copia Q que reside en la memoria intermedia local de dicha transaccin. De este modo las nicas operaciones significativas de la transaccin son, desde el punto de vista de la planificacin, las instrucciones leer y escribir. Por tanto, normalmente slo se mostrarn las instrucciones leer y escribir en las planificaciones, como se muestra en la planificacin 3 de la Figura. En este apartado se discuten diferentes formas de ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 45
equivalencia de planificacin; esto lleva a los conceptos de secuencialidad en cuanto a conflictos y secuencialidad en cuanto a vistas.
T1 leer(A) escribir(A)
T2
leer(A) escribir(A) leer(B) escribir(B) leer(B) escribir(B) Figura 22: Planificacin, slo se muestran las instrucciones leer y escribir. 5.7 Recuperabilidad Si la transaccin Ti falla, por la razn que sea, es necesario deshacer el efecto de dicha transaccin para asegurar la propiedad de atomicidad de la misma. En un sistema que permita la concurrencia es necesario asegurar tambin que toda transaccin Tj que dependa de Ti (es decir, Tj lee datos que ha escrito Ti) se aborta tambin. Para alcanzar esta garanta, es necesario poner restricciones al tipo de planificaciones permitidas en el sistema.
46
VI.
CONTROL DE CONCURRENCIA 6.1 Concepto de concurrencia Los sistemas de procesamiento de transacciones permiten la ejecucin de varias transacciones concurrentemente. Permitir varias transacciones que actualizan concurrentemente los datos provoca complicaciones en la consistencia de los mismos. Asegurar la consistencia a pesar de la ejecucin concurrente de las transacciones requiere un trabajo extra; es mucho ms sencillo exigir que las transacciones se ejecuten secuencialmente, es decir una por una, comenzando cada una slo despus que la anterior se haya completado. Sin embargo existen dos razones para permitir la concurrencia. Productividad y utilizacin de recursos mejorada: Se puede explotar el paralelismo de la CPU y del sistema E/S para ejecutar varias transacciones en paralelo. Esto incrementa la productividad y la utilizacin del procesador y del disco aumenta tambin. Estn menos tiempo sin hacer ningn trabajo til. Un tiempo de espera reducido: Si las transacciones operan en partes distintas de la BD es mejor hacer que se ejecuten concurrentemente compartiendo los ciclos de la CPU y los accesos a disco entre ambas. Adems se reduce el tiempo medio de respuesta que es el tiempo medio desde que empieza una transaccin hasta que se completa Cuando se ejecutan varias transacciones concurrentemente, la consistencia de la base de datos se puede destruir a pesar de que cada transaccin individual sea correcta. El sistema de base de datos debe controlar la interaccin entre las transacciones concurrentes para evitar que se destruya la consistencia de la base de datos. Esto se lleva a cabo a travs de una serie de mecanismos denominados esquemas de control de la concurrencia. 6.2 Bloqueos Una forma de asegurar la secuencialidad, es exigir que el acceso a los elementos de datos se haga en exclusin mutua; es decir, mientras una transaccin accede a un elemento de datos, ninguna otra transaccin puede modificar dicho elemento. Existen muchos modos mediante los cuales se puede bloquear un elemento de datos. Compartido. Si una transaccin T obtiene un bloqueo en modo compartido (denotado por C) sobre el elemento Q, entonces T puede leer Q pero no escribir. Exclusivo. Si una transaccin T obtiene un bloqueo en modo exclusivo (denotado por X) sobre el elemento Q, entonces T puede tanto leer como escribir Q. Es necesario que toda transaccin solicite un bloqueo del modo apropiado sobre el elemento de datos Q dependiendo de los tipos de operaciones que se vayan a realizar sobre Q. La peticin se hace al gestor se control de concurrencia. La transaccin puede realizar la operacin solo despus de que el gestor de control de concurrencia conceda el bloqueo a la transaccin. Una transaccin solicita un bloqueo compartido sobre el elemento de datos Q a travs de la instruccin bloquear-C (Q). De forma similar se solicita un bloqueo exclusivo a travs de la instruccin bloquear-X (Q). Se puede desbloquear un elemento de datos Q por medio de la instruccin desbloquear (Q).
47
Leer(B); B:=B-50 Transaccin T1 Escribir(B); Desbloquear (B); Bloquear-X(A); Leer(A); A:= A+50; Escribir(A); Desbloquear Bloquear-C(A); Leer(A); Transaccin T2 Desbloquear(A); Bloquear-C(B); Leer(B); Desbloquear(B); Visualizar (A+B). Transaccin T2 Se exige en toda transaccin del sistema siga un conjunto de reglas llamado protocolo de bloqueo, que indica el momento en que una transaccin puede bloquear y desbloquear cada uno de los elementos de datos. Los protocolos de bloqueo restringen el nmero de planificaciones posibles. El conjunto de tales planificaciones es un subconjunto propio de todas las planeaciones secuenciales posibles. Bloquear-X(B); Leer(B); Transaccin T3 B:=B-50; Escribir(B); Bloquear-X(A); Leer(A); A:=A-50; Desbloquear(B); Desbloquear(A). CONCESIN DE BLOQUEOS. Cuando una transaccin solicita un bloqueo de un modo particular sobre un elemento de datos y ninguna otra transaccin posee un bloqueo sobre el mismo elemento de datos en un modo conflictivo, se puede conceder el bloqueo. Se puede evitar la inanicin de las transacciones al conceder los bloqueos de la siguiente manera: cuando una transaccin T1 solicita un bloqueo sobre un elemento de datos Q en un modo particular M, el gestor de control de concurrencia concede el bloqueo siempre que:
48
a. No exista una transaccin que posea un bloqueo sobre Q en un modo que este en conflicto con M. b. No exista otra transaccin que este esperando un bloqueo sobre Q y que lo haya solicitado antes que T. De este modo, una particin de bloqueo nunca se quedara bloqueada por otra peticin de bloqueo solicitada mas tarde. 6.3 Marcas temporales Cada transaccin genera una marca temporal cuando se introduce en el sistema. Si a la transaccin T, se le ha asignado la marca temporal MT(Ti) y una nueva transaccin Tj entra en el sistema entonces MT(Ti)< MT(Tj). El protocolo maneja la ejecucin concurrente de modo que las marcas temporales de las transacciones determinan el orden de secuencia. Para asegurar este comportamiento, el protocolo mantiene por cada elemento de datos Q dos valores de marca temporal: Marca_temporal-E(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con xito escribir(Q). Marca_temporal-L(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con xito leer(Q). El protocolo de ordenacin por marcas temporales asegura que todas las operaciones leer y escribir conflictivas se ejecutan ene l orden de las marcas temporales. Existen dos mtodos para implementar este esquema: a. Usar el valor del reloj del sistema como marca temporal; es decir, la marca temporal de una transaccin es igual al valor del reloj en el momento en que la transaccin entra en el sistema. b. Usar un contador lgico que se incrementa cada vez que se asigna una nueva marca temporal; es decir, la marca temporal de una transaccin es igual al valor del contador en el momento en el cual la transaccin entra en el sistema. Las marcas temporales de las transacciones determinan el orden da secuencia. Marca_temporal-E(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con xito escribir(Q). Marca_temporal-L(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con xito leer(Q). Estas marcas temporales se actualizan cada vez que se ejecuta una nueva operacin leer (Q) o escribir (Q). 6.4 Validacin Se asume que una transaccin T se ejecuta en dos o tres fases diferentes durante su tiempo de vida dependiendo de si es una transaccin de solo lectura o una de actualizacin. Las fases son, en orden: a. Fase de lectura. Durante esta fase tiene lugar la ejecucin de la transaccin T. Se leen los valores de varios elementos de datos y se almacenan en variables locales de T. Todas las operaciones escribir se realizan sobre las variables locales temporales sin actualizar la base de datos actual.
49
b. Fase de validacin. La transaccin T realiza una prueba de validacin para determinar si puede copiar a la base de datos las variables locales temporales que tienen los resultados de las operaciones escribir sin causar una violacin de secuencialidad. c. Fase de escritura. Si la transaccin T tiene xito en la validacin (paso 2) entonces las actualizaciones reales se aplican a la base de datos. En otro caso T se retrocede. Cada transaccin debe pasar por las tres fases y en el orden que se muestra. Sin embargo, se pueden entrelazar las tres fases de la ejecucin concurrente de las transacciones. Para realizar la prueba de validacin se necesita conocer el momento en que tienen lugar las distintas fases de las transacciones T. Se asociaran por tanto tres marcas temporales distintas a las transaccin T. a. Inicio (T). momento en el cual T comienza si ejecucin. b. Validacin (T), momento en el cual T termina su fase de lectura y comienza su fase de validacin. c. Fin (T), momento en el cual T termina su fase de escritura.
50
TRABAJO Es un trabajo individual en el cual aplicars lo aprendido durante el desarrollo del curso. a. Caractersticas de Formato. Fuente Arial 12 puntos, a 1.5 interlineado. Portada o Nombre de la universidad o Nombre del mdulo o Nombre del estudiante o Nombre del docente o Fecha de entrega o Tabla de contenido b. Introduccin. En este apartado debers mencionar de una forma general el contenido de tu proyecto. c. Objetivos del proyecto. Explicar cul es la finalidad que se busca alcanzar con la elaboracin del proyecto, incluir tanto el objetivo general como los particulares. d. Justificacin. Explicar la importancia que tiene el realizar el proyecto pa-ra la organizacin seleccionada, en especial para los miembros de la mis-ma. e. Planteamiento del contexto empresarial. El perfil de la organizacin elegida. Visin, Misin, fines, recursos humanos y tcnicos, tamao, giro, historia, importan-cia econmica y social, etc. El diagnstico de la necesidad informtica. El perfil del usuario. Habilidades, expectativas, actitudes. f. Desarrollo de la base de datos. Modelo Entidad-relacin que incluya la definicin de: Entidades Instancias Relaciones y su cardinalidad Diagrama entidad-relacin Modelo Relacional que incluya el diseo de: Tablas Campos Claves primarias Claves ajenas Reglas de integridad referencial Implementacin en SQL Script de creacin de la Base de Datos. Consultas Vistas Procedimientos almacenados Triggers g. Conclusiones. En este apartado comentars los puntos ms sobresalientes sobre tu trabajo: Limitaciones ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS 51
Comentarios generales h. Anexo
52

Modulo Base Datos

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modulo Base Datos

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Nivel Lgico (esquema) Diseo Lgico (Definicin del esquema)

Diccionario de datos (Meta-datos)

Base de datos almacenada

Sub Modelo de Datos A Sub Modelo de Datos B Sub Modelo de Datos N

MODELO DE DATOS CONCEPTUAL

Personas Operaciones Materiales Documentos Computadoras

Figura 2: Modelo de Datos Conceptual

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Esquema de la Base de Datos

SGBD DBMS DDL DML

Diccionario de datos (Meta-datos)

Esquema de la Base de Datos

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Alumno codigo nombre carrera dni celular

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Clave Principal Alumno codigo nombre carrera celular dni

Alumno nombre carrera celular codigo dni

Clave Principal Matricula

codigo semestre fechamat creditos estado

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Significado Entidad Entidad dbil

Atributo Atributo clave Atributo multivalor Atributo compuesto

Razn de cardinalidad 1:N para E1:E2 en R

(min, max) R E2 Restriccin estructural (min, max) en la participacin de E en R

Figura 7: Resumen de Notacin para los diagramas ER.

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Tabla1: Correspondencia entre los modelos ER y relacional

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

DISEO DE BASES DE DATOS RELACIONALES

Institucion O.N.U. O.M.S. N.A.S.A.

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Agronomia Derecho Sistemas

Julio Alfredo Maria Julio Julio Pedro Mara

991110A Contabilidad 011012B 980189C 971567B Contabilidad Derecho Derecho

981267V Derecho 976523C Sistemas

Figura 8: Archivo Secuencial

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Agronomia Contabilidad Derecho Sistemas

Julio Alfredo Maria Julia Jose Pedro Ketty

991110A Contabilidad 011012B 980189C 971567B Contabilidad Derecho Derecho

981267V Derecho 976523C Figura 8. ndice Denso Sistemas

991110A Contabilidad 011012B 980189C 971567B Contabilidad Derecho Derecho

981267V Derecho 976523C Figura 9. ndice Disperso Sistemas

ACTUALIZACIN PRE PROFESIONAL MODULO DE BASE DE DATOS

UNIVERSIDAD TECNOLGICA DE LOS ANDES CARRERA PROFESIONAL DE ING DE SISTEMAS E INFORMTICA

Bloque de Datos 1 Bloque de ndice 1 ndice externo