parte_21.txt

José Ramón Lozano Mínguez 2 TEMARIO OPOSICIONES COIICV | TEMA 28 Los sistemas de gestión de bases de datos forman pa rte de los sistemas de información, de igual forma que el hardware, los usuarios o los administr adores del sistema. Cualquier organización necesita de un sistema de información para...

José Ramón Lozano Mínguez 2 TEMARIO OPOSICIONES COIICV | TEMA 28 Los sistemas de gestión de bases de datos forman pa rte de los sistemas de información, de igual forma que el hardware, los usuarios o los administr adores del sistema. Cualquier organización necesita de un sistema de información para tratar t oda la información que requiere para su funcionamiento. Los primeros sistemas de informació n automatizados ya almacenaban y trataban la información mediante sistemas de ficheros que co ntrolaba directamente el sistema operativo, pero estos sistemas tenían inconvenientes, entre lo s que destacaban: • Seguridad. Los ficheros podían ser accedidos por cu alquier usuario e incluso eliminados como un fichero más del sistema operativo. • Concurrencia. Los accesos concurrentes a los ficher os podían generar inconsistencias. • Dependencia de los programas respecto a los datos. Las aplicaciones tenían sus propios ficheros de datos. • Redundancia. Si teníamos varias aplicaciones, en oc asiones podían manejar los mismos datos, y al tener que almacenarlas por separado par a cada aplicación, se generaba redundancia, que podía provocar inconsistencias. Para resolver los problemas de los sistemas anterio res nace el concepto de base de datos, que pretende unificar la información del sistema de inf ormación estructurado, sin redundancias y manteniendo las distintas vistas de los usuarios. U na base de datos es una colección de datos estructurados según un modelo que refleja las relac iones y restricciones de los mismos en la vida real. A su vez, los sistemas de gestión de bases de datos (SGBD) son herramientas software que: • Permiten a las aplicaciones interactuar con las bas es de datos (consultas, modificaciones, borrados). • Permiten a los administradores definir la estructur a de los datos y las distintas vistas de que éstos tienen las aplicaciones. • Se encargan de mantener la seguridad, concurrencia, integridad e independencia de los datos respecto a las aplicaciones que los consumen. 1. El modelo de referencia ANSI En 1977 el grupo de trabajo ANSI/SPARC (American Na tional Standard Institute/System Planing And Requirement Commitee) propone una arquitectura de tres niveles (conceptual, interno y externo) para la definición de un SGBD, cada uno co n su esquema: Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 3 • Esquema conceptual. Visión del sistema de informaci ón según el punto de vista de la organización, independiente del SGBD, que describe la información y funciones de la organización. • Esquema interno o físico. Representación en la memo ria externa del ordenador de los datos del sistema de información, tipos de registro s almacenados, índices, representación de los datos, etc. Es el nivel más cercano al almac enamiento físico de los datos. • Esquema externo: Representación de los datos para u na aplicación determinada. El nivel externo es el más cercano a los usuarios, habrá muchas vistas externas según los usuarios y sus necesidades de información. El nivel conceptu al es una representación abstracta, y sólo habrá una. Figura 1: Los esquemas propuestos por ANSI/SPARC Veamos un ejemplo de las tres vistas de una base de datos que almacena información de clientes y productos de una empresa de producción. Esquema conceptual: Clientes: Número de cliente (numérico), nombre del cliente (carácter), compras año en curso (numérico). Productos: Código de producto (carácter), nombre de l producto (carácter), precio de coste del producto (numérico), precio de venta del producto ( numérico), instrucciones de producción (carácter, texto libre), componentes (carácter, tex to libre). Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019José Ramón Lozano Mínguez 4 TEMARIO OPOSICIONES COIICV | TEMA 28 Esquema interno: Clientes: NUMERO_CLI integer NOMBRE_CLI string (100) COMPRAS_ANYO real (10) Productos: COD_PRO string (15) NOMBRE_PRO string (100) PRECIO_COSTE_PRO real (10) PRECIO_VENTA_PRO real (10) INS_PRODUCCION TEXT Esquema externo 1 (Gestión comercial): Clientes: NUMERO_CLI integer NOMBRE_CLI string (100) COMPRAS_ANYO real (10) Productos: COD_PRO string (15) NOMBRE_PRO string (100) PRECIO_VENTA_PRO real (10) Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 5 Esquema externo 2 (Control de producción): Productos: COD string (15) NOMBRE string (100) INS_PRODUCCION TEXT Esquema externo 3 (Control de costes): Productos: CODIGO string (15) NOMBRE string (100) PRECIO_COSTE real (10) En este momento es interesante introducir dos conce ptos, el DDL (Data Definition Language o lenguaje de definición de datos) y el DML (Data Man ipulation Language o lenguaje de manipulación de datos). Utilizaremos tanto un lengu aje de definición o como de manipulación de datos distinto según el nivel en el que estemos tra bajando. Los lenguajes serán más o menos formales según el nivel. Puede hablarse, por ejemplo, de un DDL conceptual c omo un lenguaje de definición de datos a nivel conceptual. Dicho lenguaje no puede tener en consideración aspectos de representación física de los datos o de técnicas de acceso, ya que estos aspectos pertenecen al nivel físico. 2. El sistema de gestión de bases de datos El SGBD o DBMS (Sistema de gestión de base de datos , DataBase Management System) es el sistema software que gestiona el acceso a la base d e datos. El sistema recibirá las peticiones de acceso a la base de datos del usuario y las ejecuta rá teniendo en cuenta el esquema externo del usuario, así como los esquemas conceptual e interno . Sus funciones son las siguientes: • Describir los distintos esquemas de la base de dato s. • Manipular la base de datos, recuperación y modifica ción de la información. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019José Ramón Lozano Mínguez 6 TEMARIO OPOSICIONES COIICV | TEMA 28 • Administrar la base de datos. Los sistemas ponen a disposición del DBA (administrador de la base de datos, DataBase Administrator) una serie de utilidades para llevar a cabo las tareas de administración de la base de datos (herra mientas para mantener la seguridad de los datos, herramientas de recuperación, etc.). • Mantener la integridad de los datos. • Permitir la concurrencia en el acceso a los datos. • Definir el diccionario de datos. Un buen SGBD tiene que: • Permitir describir los distintos esquemas de la bas e de datos, los aspectos importantes de los datos y sus relaciones. • Mantener la independencia entre los diferentes nive les, por ejemplo de los datos frente a su representación física. • Permitir establecer la correspondencia entre los es quemas y los datos en cada esquema. • Aislar los esquemas entre sí de forma que las modif icaciones en uno no afecten a los demás (independencia de datos). Los componentes de un SGBD son: • Lenguajes de definición del esquema lógico, interno y externo (en la práctica no existen herramientas de definición del esquema conceptual i ndependiente del SGBD, por lo que se añade un esquema lógico dependiente del SGBD interm edio entre el esquema conceptual y el interno). • Lenguajes de manipulación de la base de datos. • Utilidades, entre las que destacan las generadoras de copias de seguridad, reconstrucción de bases de datos dañadas, obtención de estadística s, etc. • Lenguajes de programación de alto nivel para el man ejo de la base de datos. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 7 Figura 2: Independencia entre los esquemas en los S GBD 3. El modelo relacional 3.1. Los modelos de datos y el modelo relacional Utilizamos los modelos de datos para representar un a abstracción de la parte del mundo real que queremos plasmar en el sistema de información. Con ellos debemos representar las propiedades estáticas (objetos, relaciones y restricciones) com o las dinámicas (operaciones sobre los objetos, transacciones, restricción en la evolución de los o bjetos y sus relaciones). Entre los distintos modelos que se han utilizado, p odemos destacar los modelos jerárquicos (estructurados en árbol), en red (CODASYL), relacio nales, orientados a objetos, etc. El modelo relacional fue presentado por E. Codd en 1970 y aún hoy sigue vigente, es el modelo de datos de más éxito entre los SGBD y en el que se ba san muchos de los grandes sistemas comerciales (Oracle, SQL Server, Informix, DB2, MyS QL, PostgreSQL, etc.). De manera informal en un sistema relacional los datos son percibidos p or el usuario como tablas y los operadores de recuperación de esos datos generan nuevas tablas a partir de las anteriores. Al mismo tiempo, Codd también propuso tres lenguajes de definición y manipulación de datos basados en el Álgebra de conjuntos y en el Cálculo de Predicados de Prime r Orden. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019José Ramón Lozano Mínguez 8 TEMARIO OPOSICIONES COIICV | TEMA 28 Una de las principales ventajas y razones del éxito del modelo es su lenguaje de consulta, el SQL (Structured Query Language) que será estudiado con mayor profundidad en los siguientes apartados. 3.2. Estructuras del modelo relacional La estructura de datos relación es la estructura fundamental del modelo, como su n ombre indica. Relación es el término matemático para la tabla. Representa tanto los objetos como las relaciones entre ellos. Viene definida por un conjunto de nomb res de atributos, cada uno de los cuales tiene asociado un dominio. Una o más relaciones forman el esquema de una base de datos relacional. La forma más cómoda de representar las relaciones e s mediante tablas. Veamos unos ejemplos: Tabla I: Relación Clientes Código Nombre Dir Teléfono 1 Juan Pérez Mayor, 10 999999999 2 Frutas Fresa Enmedio, 21 666666666 3 Automóviles AJ Nueva, 3 777777777 Tabla II: Relación Facturas Código Cod_Cliente Fecha 2015-102 1 10/12/2015 2016-1 2 05/01/2016 2016-2 3 07/01/2016 Tabla III: Relación Productos Código Nombre Precio 1 Hora de análisis 50 2 Hora de desarrollo 40 3 Hora de consultoría 50 Tabla IV: Relación Líneas de factura Cod_Factura Num_Línea Cod_Producto Cantidad 1 1 1 3 1 2 3 3 2 1 2 10 3 1 2 10 Formalmente una relación de esquema R {(A 1,D 1),(A 2,D 2),(A 3,D 3),…,(A n,D n)} es un conjunto de tuplas {(A 1,V 1),(A 2,V 2),(A 3,V 3),…,(A n,V n)} tales que V 1 Є D 1, V 2 Є D 2, V 3 Є D 3, …,V n Є Dn. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 9 El grado de una relación es el número de atributos de su esquema (informalmente corresponde al número de columnas de la tabla) y la cardinalidad e s su número de tuplas (informalmente el número de filas). Un dominio en el modelo relaciona l equivale a un tipo de datos, no tiene estructura, y es la unidad semántica de datos más p equeña. Volviendo al ejemplo anterior, la relación Clientes la representaremos de la siguiente forma: Clientes (codigo:dom_codigo, nombre:dom_nombre, dir :dom_dir, telefono:dom_telefono) Y una ocurrencia de la relación: Clientes={ { (Codigo,1), (Nombre,Juan Pérez), (Dir , Mayor, 10), (Telefono, 999999999) } { (Codigo,2), (Nombre,Frutas Fresa), (Dir, Enmedio, 21), (Telefono, 666666666) } { (Codigo,3), (Nombre,Automóviles AJ), (Dir, Nueva, 3), (Telefono, 777777777) } } Una forma habitual de representar la vida real medi ante el modelo relacional es utilizar diagramas Entidad-Relación, que se estudiarán en detalle en e l Tema 44. Como adelanto, la relación Clientes del ejemplo se representaría como una entidad con s us atributos. Figura 3: Entidad-Relación 3.3. Restricciones en el modelo relacional El modelo relacional permite representar la vida re al, como se ha comentado anteriormente, pero con lo estudiado hasta ahora, permitiría la existen cia de ocurrencias no válidas en la vida real. En el ejemplo anterior podría existir una tupla con el código repetido o sin nombre en el cliente. Las restricciones son las herramientas que nos permiten definir qué cosas queremos que nuestro modelo no permita. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019José Ramón Lozano Mínguez 10 TEMARIO OPOSICIONES COIICV | TEMA 28 Restricción de valor no nulo. Se aplica sobre un at ributo, dicho atributo no puede tener valor nulo para ninguna tupla de la relación. Restricciones de unicidad. • Clave candidata. Conjunto de uno o más atributos qu e identifican de forma única la tupla y no existe un subconjunto de esos atributos que tamb ién identifiquen de forma única la tupla. Dicho de otra forma, no se puede repetir otr a tupla con los mismos valores en el conjunto de atributos que forman la clave candidata . • Clave primaria y alternativa. Si existe más de una clave candidata en una entidad, una u solo una de ellas es la clave primaria. El resto de denominan claves candidatas. La clave primaria servirá para referenciar las tuplas de la relación. La integridad de clave primaria es exactamente el c umplimiento de la restricción de unicidad de la clave primaria y la ausencia de valores nulos. Restricciones sobre entidades y relaciones entre en tidades. • Clave ajena. La clave ajena es el mecanismo del mod elo relacional para establecer las relaciones entre entidades. Dada una entidad R {(A 1,D 1),(A 2,D 2),(A 3,D 3),…,(A n,D n)} y S {(B 1,E 1),(B 2,E 2),(B 3,E 3),…,(B n,E n)} y sea CPS la clave primaria de S, la clave ajena de R que referencia a S : • Un subconjunto de atributos de R CARS={Ai,Aj,…,Ak} y • Una biyección f:CARS → CPS tal que cualquier elemento Ai de CARS se cumpl e que Ai y el atributo de CPS asociado f(Ai) tienen el mismo d ominio. Se cumple que para toda tupla de R existe una tupla de S tal que los atributos Ai de la tupla en R son iguales en la tupla en S o la tupla en R tiene valor nulo en esos atributos. Figura 4: Clave ajena Dicho de otra manera, la clave ajena es uno o más a tributos de una relación R cuyo valor es nulo o coincide con la clave primaria de otra relación S. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 11 3.4. Operadores en el modelo relacional Los operadores son los lenguajes relacionales, leng uajes de especificación mediante los cuales se expresa lo que se quiere obtener de la base de dato s, o las operaciones que se quieren realizar, sin especificar cómo tiene que ser obtenida dicha i nformación. Existen dos notaciones para expresar las operacione s sobre las relaciones, notación algebraica o álgebra relacional y notación lógica o cálculo rela cional (de tuplas y de dominios). En total tres lenguajes equivalentes entre sí con un objetivo fun damental, la expresión de consultas a la base de datos. 3.4.1. Álgebra relacional. Operadores Para el álgebra relacional se definen ocho operador es: • Unión (U). R U S será la unión de todas las tuplas que están en R y todas las tuplas que están en S. Las relaciones tiene que ser compatible s, es decir, tienen el mismo esquema relacional. El resultado también será compatible. • Intersección ( ∩). R ∩ S serán las tuplas que están en R y en S. R y S se rán compatibles, así como el resultado de la intersección. • Diferencia (-). R – S serán las tuplas que están en R y no en S. R y S serán compatibles, así como el resultado de la diferencia. • Producto cartesiano (x). R x S será la combinación de todas las tuplas de R con cada una de las tuplas de S. Los atributos del producto cart esiano serán los atributos de R más los atributos de S. • Selección (donde). S donde condicion selecciona las tuplas de S que cumplen la condició n condicion. Los atributos de la selección son los mismos de S. • Proyección ([]). La relación resultante contiene la s mismas tuplas que la original, pero únicamente los atributos indicados en el operador. • Concatenación ( ∞). R ∞ S es la combinación de todas las tuplas de R y S c uyos valores coincidan en una serie de atributos comunes. La rel ación resultante tendrá todos los atributos de R y todos los de S no comunes con R. • División (÷). R ÷ S son las tuplas R que están comb inadas con todas las tuplas de S. La relación resultante son los atributos no comunes de R. Los cuatro primeros son operadores conjuntistas, si milares a los utilizados en la teoría de conjuntos. Los cuatro últimos son propiamente relac ionales. El resultado de cualquier operación relacional es otra relación, lo que permite el anid amiento de operaciones. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019José Ramón Lozano Mínguez 12 TEMARIO OPOSICIONES COIICV | TEMA 28 Algunos ejemplos de consultas en álgebra relacional y su correspondiente en SQL, que se estudiará más adelante, pero resultará útil empezar a familiarizarse con él: Selección. Clientes cuyo teléfono sea 666666666. Clientes donde telefono=’666666666’ select * from Clientes where telefono=’666666666’ Proyección. Los nombres de los clientes. Clientes [nombre] select nombre from Clientes Producto cartesiano. Combinación de clientes y prod uctos. Clientes x Productos select * from Clientes, Productos Concatenación. Clientes y sus facturas. Clientes ∞ Facturas select * from Clientes, Facturas where clientes.cod igo=facturas.cod_cliente Concatenación. Nombres de clientes y sus números de factura. Clientes [Nombre] ∞ Facturas [Código] select Clientes.nombre, Facturas.codigo from Client es, Facturas where clientes.codigo=facturas.cod_cliente Se observa que el operador concatenación lleva impl ícita la condición que debe cumplirse, en este caso que el código de cliente de la relación Factur as corresponda al código de cliente de la relación Clientes. En lenguaje SQL, la condición se debe indicar explícitamente. 3.4.2. Cálculo relacional de tuplas y dominios El cálculo relacional se basa en el cálculo de pred icados de la lógica matemática. Se basa en el uso de variables-tupla, símbolos de constante, nomb res de relación, operadores de comparación, predicado de comprobación de valor nulo, nombres de atributo, conectivas lógicas (negación ¬, conjunción ∧, disyunción ∨, implicación →) y cuantificadores ( ∃, ∀). Con estos símbolos formamos condiciones y fórmulas bien formadas. Sin entrar en detalles, las sentencias del cálculo Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019