parte_22.txt

Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 13 relacional de tuplas tienen su equivalente en el ál gebra relacional, y viceversa. Unos ejemplos del cálculo relacional de tuplas servirán de ilustració n: Nombres de los clientes cuyo teléfono sea 666666666 . X: Cliente C...

Sistemas de gestión de bases de datos TEMARIO OPOSICIONES COIICV | TEMA 28 13 relacional de tuplas tienen su equivalente en el ál gebra relacional, y viceversa. Unos ejemplos del cálculo relacional de tuplas servirán de ilustració n: Nombres de los clientes cuyo teléfono sea 666666666 . X: Cliente Cliente(X) ∧ X.telefono=’666666666’ Nombre de los clientes con alguna factura. X: Cliente Y: Factura Cliente (X) ∧ ∃Y (Factura(Y) ∧ X.codigo=Y.cod_cliente) La diferencia fundamental entre el cálculo relacion al de tuplas y el cálculo relacional de dominios consiste en que el segundo utiliza variables defini das sobre el dominio de alguno de los atributos del esquema (variables-dominio) en lugar de las var iables-tupla del primero. En los ejemplos anteriores: X:dom_nombre Y:dom_telefono ∃X(Cliente(codigo:X,telefono:Y) ∧ Y=’666666666’) X:dom_codigo Y:dom_nombre Z:dom_cod_cliente ∃X(Cliente(codigo:X,nombre:Y) ∧ ∃Z(Factura(cod_cliente:Z) ∧ Z=X )) 4. El lenguaje SQL El lenguaje SQL es el estándar para trabajar con ba ses de datos relacionales. Fue desarrollado por IBM en los años 70, pero su versión más estándar y utilizada fue SQL/92, aceptada y asumida por muchos fabricantes con muy pocas modificaciones. In cluye operaciones de definición de datos (DDL) y de manipulación (DML). Aunque no es un leng uaje que cumpla todos los requisitos del modelo relacional, su amplia difusión hace que su c onocimiento y dominio sea necesario para cualquier profesional que maneje como parte de su t rabajo bases de datos relacionales. 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 14 TEMARIO OPOSICIONES COIICV | TEMA 28 Versiones posteriores de SQL añadieron funcionalida des al estándar, como SQL/99 (triggers y soporte para expresiones regulares) o SQL/2005 (sop orte XML) entre otras. Es importante destacar que SQL es un estándar, pero no tiene por qué estar completamente implementado en todos los gestores, de igual forma que algunos gestores incorporan instrucciones a su SQL que no forman parte de estándar. El manejo de cadenas o de tipos de datos de fecha y hora puede cambiar de unos gestores a otros, e incl uso de unas versiones a otras dentro del mismo sistema, por lo que es necesario conocer el s istema destino a la hora de escribir sentencias SQL. 4.1. Instrucciones básicas Para la definición de datos, la sentencia más impor tante el CREATE TABLE, el siguiente ejemplo crearía las tablas clientes y productos del ejemplo anterior en lenguaje SQL/92, crearía las restricciones de integridad de clave primaria de la s tablas y la restricción de clave ajena de la tabl a de productos a la de tipos de producto. Create table clientes (numero_cli numeric(5), nombre_cli char (100), compras_anyo numeric (10,2), primary key (numero_cli)); Create table tipo_producto (cod_tipo char(15), nombre_tipo char (100), primary key (cod_tipo)); Create table productos (cod_pro char(15), nombre_pro char (100), precio_coste_pro numeric (10,2), precio_venta_pro numeric (10,2), precio_coste_pro numeric (10,2), 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 15 ins_produccion char(100), tipo_producto char(15), primary key (cod_pro), foreign key (tipo_producto) references tipo_product o ); Para la manipulación de datos, las sentencias más c omunes son SELECT (consultar a la base de datos), INSERT (instrucciones de inserción de uno o varios registros en una tabla), UPDATE (modificación de algún registro de una tabla) y DEL ETE (borrado de algún registro de una tabla). Dentro de éstas podemos utilizar operaciones para p royectar, restringir y juntar. Por ejemplo la siguiente sentencia une las tablas productos y tipo_producto , restringiendo los productos con un precio de coste mayor a 100 y proyectando alguna de sus columnas: SELECT cod_pro, nombre_pro, precio_coste, nombre_ti po –proyectar FROM productos, tipo_producto –juntar, join WHERE precio_coste>100 –restringir and productos.tipo_producto=tipo_producto.cod_tipo –condicion join Para insertar un registro en una tabla de la base d e datos, utilizamos el operador INSERT. En el siguiente ejemplo insertamos en la tabla de product os un registro con código ‘ A001’, nombre ’ Hora de desarrollo ’ y precio de venta 30 . No se han indicado valores para el resto de colum nas de la tabla, lo que las dejará a NULO o a sus valores por defecto si los tuvieran. En caso de que alguna de esas columnas tuviera una restricción de no nulo , la sentencia daría un error de ejecución al incumplir las restricciones definidas: INSERT into productos (cod_pro, nombre_pro, precio_ venta_pro) VALUES (‘A001’,‘Hora de desarrollo’,30) Para modificar uno o varios registros de una tabla utilizamos el operador UPDATE. En el siguiente ejemplo se incrementará el precio de todos los prod uctos que cumplan una condición. Dicha condición está implementada a su vez como una consu lta a otra tabla de la base de datos. Estos anidamientos nos permitirán construir sentencias SQ L tan complejas como sea necesario. UPDATE productos SET precio_venta_pro=precio_venta_ pro*1.2 WHERE tipo_producto in ( SELECT cod_tipo FROM tipo_producto 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 16 TEMARIO OPOSICIONES COIICV | TEMA 28 WHERE nombre_tipo=‘Desarrollo’ or nombre_tipo=‘Cons ultoría’) Para eliminar registros de una tabla utilizamos el operador DELETE. El siguiente ejemplo borrará todos los registros de la tabla de tipos de product o: DELETE FROM tipo_producto La instrucción anterior dará error de ejecución si alguno de los tipos de producto ha sido referenciado en la tabla de productos, ya que su el iminación rompería la integridad de la base de datos definida por restricción de clave ajena de pr oductos a tipos de producto ( foreign key (tipo_producto) references tipo_producto en la sentencia de creación de la tabla de product os). Para eliminar uno o algunos de los registros de una tabla, podemos incluir una condición de la siguiente manera: DELETE FROM tipo_producto WHERE tipo_producto=‘A002’ O utilizando una sentencia SELECT dentro de la cond ición, se pueden eliminar los tipos de producto que no han sido referenciados en ningún re gistro de la tabla de productos: DELETE FROM tipo_producto WHERE cod_tipo not in ( SELECT tipo_producto FROM productos) 4.2. Vistas Las vistas son consultas a la base de datos que se utilizan frecuentemente. No son tablas, únicamente consultas sobre tablas, pero en el caso de dispongan de los permisos pertinentes, pueden ser utilizadas tanto para consultar como par a insertar o borrar. Una vez creada una vista, ésta puede ser utilizada en los mismos contextos que una tabla. Podemos crear una vista con información de los prod uctos desde el punto de vista de producción con la siguiente sentencia: CREATE VIEW productos_produccion (codigo, nombre, i nstrucciones) AS select cod_pro, nombre_pro, ins_produccion 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 17 from productos También podemos utilizarlas para filtrar la informa ción, por ejemplo: CREATE VIEW productos_consultoria (codigo, nombre, precio_venta) AS select cod_pro, nombre_pro, precio_venta_pro from productos where tipo_producto=‘A001’ O para unir información de más de una tabla: CREATE VIEW productos_con_tipo (codigo, nombre, cod _tipo, nombre_tipo) AS select productos.cod_pro, productos.nombre_pro, tipo_producto.cod_tipo, tipo_producto.nombre_tipo from productos, tipo_producto where productos.tipo_producto=tipo_producto.cod_tip o Las vistas son un mecanismo que puede ayudar a mant ener la independencia lógica, ya que añadir un nuevo atributo en una tabla no afectaría a las v istas que actúan sobre ella. También permite mostrar distinta información a distintos usuarios y pueden ser un mecanismo de ayuda a mantener la seguridad de los datos, ocultando algunos atribu tos o incluso algunos registros. 4.3. Triggers y procedimientos almacenados Los sistemas de gestión de bases de datos pueden im plementar procedimientos, programas, disponibles para el usuario y ejecutados directamen te por el gestor, lo que los hace especialmente eficientes. Los usos más habituales son para manten er la integridad lógica de los datos y para encapsular tareas complejas, que pueden involucrar más de una tabla de la base de datos. Los triggers o disparadores son procesos que se eje cutan automáticamente después de hacer una operación en la base de datos. Por ejemplo: CREATE TRIGGER ins_productos ON productos AFTER INSERT execute pr_ins_pruductos (cod_pro) 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 18 TEMARIO OPOSICIONES COIICV | TEMA 28 Cada vez que se inserte un registro en la tabla de productos, el sistema llamará al procedimiento almacenado pr_ins_productos pasándole el código del producto recién creado. El procedimiento podría hacer algún tipo de comprobación o insertar un registro en una tabla de auditoría donde se incluyera información del momento en el que se ha c reado el producto, por ejemplo. Definiendo un disparador en el borrado de una tabla , podríamos hacer que se guardaran los datos del registro a borrar en otra tabla de registros el iminados, de forma que pudieran ser recuperados en caso de necesidad. CREATE PROCEDURE pr_del_clientes (numero_cli, nombr e_cli, compras_anyo) BEGIN INSERT INTO clientes_borrados (numero_cli, nombre_c li, compras_anyo) END CREATE TRIGGER del_clientes ON clientes AFTER DELETE execute pr_del_clientes (numero_cli, nombre_cli, co mpras_anyo) La sintaxis de los triggers y procedimientos almace nados no siempre es compatible entre los distintos sistemas de gestión relacionales. La sint axis utilizada en los ejemplos anteriores, con fines didácticos, trata de mostrar las posibilidade s que nos ofrecen estas herramientas sin corresponder con ninguna sintaxis real implementada en un sistema o en el estándar SQL. 5. Bases de datos no relacionales Aunque el modelo relacional sigue siendo un modelo válido para muchos de los sistemas de información actuales tales como el tratamiento de d atos alfanuméricos o los sistemas de gestión empresarial, por poner algún ejemplo, la evolución de los sistemas de información ha hecho que en algunos casos el modelo no sea válido. Así se han i do desarrollando nuevos modelos de bases de datos y sus respectivos sistemas de gestión. En los siguientes apartados se estudiarán algunos de ellos. 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 19 5.1. Bases de datos orientadas a objetos y objeto-r elacionales Durante muchos años los modelos relacionales han pr edominado como sistemas de bases de datos necesarios para los sistemas de información t radicionales de gestión de las empresas y los negocios. Pero estos modelos no son los más adecuad os cuando los sistemas necesitan almacenar y tratar documentos, imágenes, vídeos, et c. (multimedia) o con la aparición los sistemas de fabricación asistidos por ordenador (CAD/CAM), l as bases de datos gráficas, los sistemas de información geográfica, etc. Las nuevas aplicacione s necesitan estructuras más complejas para almacenar los datos, transacciones más grandes, tip os de datos para almacenar imágenes, grandes bloques de texto, etc. También operaciones que manejen esos datos. Una primera solución planteada para ese problema fueron las bas es de datos orientadas a objetos. Muchos fabricantes de sistemas de gestión de bases de datos tradicionales (relacionales) han añadido funcionalidades de orientación a objetos, d ando lugar a las bases de datos objeto- relacionales. Incluso revisiones más modernas del e stándar SQL han incluido algunas de esas características. 5.1.1. Bases de datos orientadas a objetos En el modelo de datos de las bases de datos orienta das a objetos cada elemento es un objeto con identidad única, propiedades y comportamiento. Conc eptos de la orientación a objetos llevados a las bases de datos. Las tuplas del mundo relacional se sustituyen por objetos. La identidad única no equivale a la clave primaria, sino que es un identificador generado por el sistema, no modificable y oculto al usuario. El val or del objeto se expresa mediante sus propiedades, que se almacenan en una estructura de datos que puede ser tan compleja como sea necesario. Las operaciones que manipulen los valore s también tendrán que ser proporcionados por el sistema. Se definen constructores para los tipos de objetos utilizando constructores básicos (enteros, cadenas, etc.) y pueden ser anidados creando estruc turas más complejas. También se definen referencias entre objetos cuando un atributo se define como referencia a otro tipo de objeto. La integridad referencial de los si stemas relacionales es aquí más fácil de implementar. Los objetos tienen un estado que se corresponde con el valor que tiene asignado el objeto en un momento dado. Las operaciones sobre un objeto tiene n que estar previamente implementadas, así como la comunicación entre objetos, asegurando de e sta manera el encapsulamiento. Distinguimos la signatura (parte pública de la oper ación) del método (procedimiento implementado en algún lenguaje de programación y oculto al usuar io). Así pues la única forma de acceder a un atributo de un objeto es desarrollar una operación que lo consulte y devuelva como salida su valor. 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 20 TEMARIO OPOSICIONES COIICV | TEMA 28 Las bases de datos orientadas a objetos permiten a nivel de diseño métodos de abstracción similares a las relacionales, además de otros métod os específicos, como agregación, asociación, generalización y especialización, herencia, polimor fismo. También se han propuesto lenguajes de consulta similares a SQL como el OQL (Object Query Language). Algunos de los sistemas de gestión de bases de dato s orientadas a objetos son O2 y ObjectStore. Tabla V: Ventajas e inconvenientes de las bases de datos orientadas a objetos Ventajas Inconvenientes Mejor integrados con los lenguajes orientados a objetos Mejor representación y tratamiento de los datos Acerca el modelo conceptual al modelo lógico Mejora en las capacidades de consulta a la base de datos Aunque tiene mayor capacidad de consulta, éstas son más complejas Pérdida de la generalidad de las bases de datos relacionales No existe una implementación estándar. Cada fabricante lo ha implementado a su manera 5.1.2. Bases de datos objeto-relacionales Los sistemas de gestión de bases de datos relaciona les han ido adaptándose a las nuevas necesidades de los sistemas de información añadiend o las características propias de la orientación a objetos, al mismo tiempo que han aparecido nuevos sistemas con estas características ya implementadas, dando lugar a los sistemas de gestió n de bases de datos objeto-relacionales. Estos sistemas, a diferencia de los orientados a ob jetos recién estudiados, cumplen con los dos modelos, tanto el relacional como el orientado a ob jetos. Este enfoque permite a los usuarios utilizar la ori entación a objetos, definir sus propios tipos de datos, asociar métodos y constructores, aunque inte rnamente los datos sigan siendo almacenados en tablas. SQL:1999 propone un modelo de objetos que enriquece el modelo relacional con la posibilidad de definir tipos de datos estructurados con interfaz d e métodos y asignar (o no) un tipo a una tabla. Una tabla sin tipo asociado es una tabla relacional tradicional, una tabla con tipo es una tabla cuyas filas son instancias del tipo de datos corres pondiente. Así pues la principal diferencia entre los sistemas de gestión de bases de datos orientadas a objetos y los objeto-relacionales es que los primer os se desarrollan según el paradigma de la orientación a objetos y los segundos son sistemas r elacionales que han evolucionado hasta sistemas que soportan las dos tecnologías, la relac ional y la orientación a objetos. 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 21 Podemos asumir que las ventajas e inconvenientes de los sistemas objeto-relacionales son similares a las de los sistemas orientados a objeto s, con la diferencia de que los objeto- relacionales son compatibles con los relacionales. Un sistema puede mantener sus bases de datos relacionales, al ser éstas un subconjunto de las qu e puede mantener un sistema objeto-relacional. Además, admiten el lenguaje SQL, aunque con alguna diferencia. 6. Bases de datos no estructuradas. NoSQL Las bases de datos NoSQL (Not Only SQL, no solo SQL ) aparecen también para resolver la gestión de los datos donde las bases de datos tradi cionales (relacionales) no alcanzan. Cuando los sistemas a implementar necesitan de una gran flexib ilidad en los datos, los sistemas relacionales, con su estructura bien definida, no son la mejor op ción. Tampoco cuando las bases de datos tienen altos niveles de distribución, requisitos muy estri ctos de rendimiento en consulta o grandes volúmenes de datos. Aplicaciones como Facebook, Instagram, FourSquare, Twitter, etc. son las pioneras en el uso de estas bases de datos. Que cualquier usuario pueda i ncluir información en sus bases de datos provocó que el volumen creciera exponencialmente, h aciendo desaconsejable el uso de sistemas tradicionales. También es útil este tipo de bases de datos en ento rnos de desarrollo ágil, con frecuentes modificaciones en el modelo de datos. Situaciones e n las que el modelo relacional puede hacer que las iteraciones no sean tan ágiles como se espe ra. Según el modelo de datos, las bases de datos NoSQL pueden dividirse en: Clave-valor Los elementos se identifican por una clave única y almacenan el resto de información en un campo BLOB o similar, haciendo la recuperación de informa ción muy rápida. Algunos ejemplos son Cassandra (Facebook, Twitter) o BigTable (Google). Documentales También utilizan una clave única para cada elemento , pero almacenan la información en una estructura tipo JSON o XML, lo que le permite una e structura dinámica. Permite búsquedas más complejas que el Clave-valor. Una estructura que en el mundo relacional podría consistir en varias tablas y columnas relacionadas por claves ajenas, a quí se almacena como un único registro o documento. Dos documentos de la mista “tabla” puede n o no tener la misma estructura. MongoDB (FourSquare, Ebay) o Firebase Realtime Database (ad quirida por Google) utilizan esta estructura. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019