Informática


Bases de Datos


BASES DE DATOS

  • LOS DATOS: INTRODUCCIÓN

  • Entidades, atributos y valores= sujeto, verbo y predicado (complementos)=Alumne/Año nacimiento/1979

    Para caracterizar la información, también hay que considerar el tiempo (cambios).

    Dominio del atributo: conjunto de valores válidos o legales de éste. Puede aceptar o no el valor nulo.

    Los atributos que se conciben como aplicaciones inyectivas, se llaman identificadores. El conjunto de atrib. Identificadores, se llama clave.

    Acceso a los datos: secuencial/directo, y por valor/por posición.

    Nivel lógico: nivel de aplicación, con sus registros, campos, etc

    Niviel físico: nivel de programación básica y hardware (SGBD, SO, HDD, índices,...)

    Esquema básico de E/S: Mem externa (bloque)Mem interna (bufferregistro)

    Tiempo de acceso: el necesario para colocar el mecanismo físico al inicio del bloque a leer o escribir.Se divide en tiempo de busqueda (del cilindro) y de espera( a que en su rotación pase por el cabezal)

    Tiempo de transferencia: el necesario para leer o escribir el bloque.

  • LOS FICHEROS

  • El nivel lógico: TAD,Tipos Abstractos de Datos, con sus especificaciones de creación, modificación y consulta. (texto, OLE, numérico, ...)

    El nivel de lenguaje: ficheros internos. A veces coinciden con los TAD.

    El Nivel físico: existencia física en el ordenador, según el dispositivo de almacenamiento. O de termina el soft y el hard.

    Independencia física de los datos: el funcionamiento del programa no ha de depender del nivel físico.

    Nivel lógico

    Es la especificación de los TAD a implementar para cada tipo de fichero: secuencial, relativo o por valor.

    Un fich secuencial es un contenedor de datos, que puede permitir o no, según lo diseñemos, lectura, escritura, modificación y actualización.

    Los fich relativos permiten acceder a los registros mediante una referencia a la posición (relativa al inicio del fichero). Serían p. ej las tablas, y tb hay que definir en ellos los TAD deseados.

    Lo0s ficheros por valor serían como una variante del los conjuntos con clave (tablas con clave)

    Nivel de lenguaje

    Implementación, empleando los constructores de ficheros de los lenguajes de programación, de los ficheros internos como puente entre los fich lógicos que usan los programadores, y los físicos, que realmente almacenan los datos en la memoria secundaria. Como los lenguajes de progr no representan todos el concepto de fich de una misma forma, es fundamental que los programas trabajen sobre los TAD del nivel lógico, que sí proporcionan una visión unitaria de la noción de fichero.

    Nivel físico

    Lo ideal serían que este nivel no fuera accesible desde los programas, pero aveces es necesario, como p ej para la gestión del posible acceso exclusivo al fichero, que se suele hacer desde el SO, pues los lenguajes en su mayoría no se ocupan de este aspecto. Los leng imperativos (Cobol, Basic, RPG), más primitivos, presentan dificultades para implementar los TAD, y acceden demasiado al nivel físico, Los leng estructurados (C, Java, Pascal, Ada), mas modernos, solucionan bastante estos aspectos.

  • INTRODUCCIÓN A LAS BASES DE DATOS

  • Evolución de las BDs

    60-70': Sistemas centralizados, con un gran ordenador y una red de terminales tontas.

    80': SGBD relacionales. Facilitan la programación de aplicaciones con BDs, y consiguen que los programas sean independientes de los aspectos físicos de la BD.

    90': BD distribuidas. Los SGBD actuales permiten que un programa pueda trabajar con diferentes BDs como si fuera una sola, aprovechando tb la facilidad de las redes de comunic actuales. Para estas BDs distrib, se usa la tecnología C/S, donde dos procesos diferentes que se ejecutan en un mismo sistema o en sistemas separados, actuan de manera que uno hace de cliente o peticionario, y el otro de servidor o proveedor del servicio. Un proceso cliente puede pedir servicios a diversos servidores, un proceso puede hacer de servidor de otro, o tb de cliente, y el cli y el serv pueden residir en un mismo sistema.

    Tendencias actuales: SGBD con TAD nuevos para aprovechar la tecnología multimedia. Esto conlleva adoptar la orientación a objetos (OO), con interfaces gráficas y escalables. Adaptación a Internet, incorporando recursos para ser tb sevidores de páginas web, como p ej SQL incluido en guiones HTML o Java. Data Warehouse (almacen de datos), con herramientas para analizar toda la información acumulada a lo largo de años. Data minning, muy vinculado al anterior(minería de datos).

    Objetivos y servicios de lso SGBD

    Deben poder satisfacer varias necesidades:

    Consultas no predefinidas y complejas (SQL, 4GL)

    Flexibilidad a los cambios. Independencia física de los datos (que cambios tecnológicos o físicos no afecten a nadie), e independencia lógica (que diferentes procesos usuarios puedan tener diferentes visiones lógicas de una misma BD, manteniendo una indeppendencia entre ellas mismas y tb con respecto a la BD.

    Facilitar la eliminación de la redundancia, manteniendo la integridad de la BD, y actualizando los datos.

    Integridad de los datos, respetando las reglas de integridad del modelo (p ej que una tabla no tenga filas duplicadas). Todo SGBD debe disponer de procesos de restauración o reconstrucción de la BD (restore o recovery) a estados anteriores (p ej backups ).

    Concurrencia de diversos usuarios a la misma BD, superando los problemas de interferencia, mediante el concepto de transacción (conjunto de operaciones simples que se ejecutan como una unidad, nunca parcialmente. O se ejecutan todas, o ninguna). Para evitar interferencias entre transacciones, se usan técnicas como el bloqueo ( que las otras transacc no puedan acceder a los datos hasta que la actual acabe).

    Seguridad en el sentido de confidencialidad, autorizaciones, derechos de acceso, encriptación de contraseñas, etc.

    Data Warehouse, OO, Internet, Incorporar el factor tiempo en la caracterización de la información.

    Arquitectura de los SGBD

    ESQUEMA DE UNA BD

    Es fundamental en la arquitectura de un SGBD para permitir independizar éste de la BD. Tiene 2 niveles:

  • Lógico: es en el que se inspira el modelo relacional del SQL. Distinguimos en él dos esquemas: Externo (visión lógica que programas y usuarios tendrán de la BD) y Conceptual (donde se describen entidades tipo, sus atributos, reglas de integridad).

  • Físico: se corresponde con el esquema interno, y contiene la descripción de la organización física de la BD (índices, apuntadores, como y dónde se agrupan físicamente los registros. Es transparente al usuario, y el SQL lo deja practicamente (algo sí deja hacer) en manos de los SGBD comerciales.

  • INDEPENDENCIA DE LOS DATOS

    Puede ser física, cuando cambios en la organización física de la BD no afecta a programas y usuarios, y/o lógica, si cambios en este nivel no afectan a los usuarios o programas.

    FLUJO DE DATOS Y DE CONTROL

    Cuando una aplicación realiza por ejemplo una consulta a un SGBD, éste, con la ayuda del SO lee páginas (bloques) de los soportes físicos donde está almacenada la BD física, y los lleva al área de buffers de la memoria principal (RAM) o de la caché. De ahí, pasa al área de trabajo de la aplicación.

    Modelos de BD

    Hay que diferenciar BD (clientes, proveedores, etc ) de SGBD ( Access, Oracle ). El primer model de BD en aparecer fue el jerárquico (60'), con registros interrelacionados en árbol. En los 70' surgieron los modelos en red, derivado del anterior, pero de poco éxito.En los 80' el modelo relacional se vuelve predominante en los SGBD, los cuales en su mayoría utilizan el lenguaje SQL como nativo. Este modelo se basa en el concepto de relación o tabla (filas y columnas), se limita únicamente al nivel lógico, dándose una independencia física de datos total, al menos en la teoría. Actualmente se está extendiendo el modelo relacional con objetos, con tipos de datos abstractos (TAD), aproximándose a la OO. También cabe señalar aquí otros SGBD que no siguen estos modelos, como los documentales o las BD geográficas.

    Lenguajes y Usuarios

    Se distinguen los de tipo DDL (Data Definition Language) para definir las BD, y los DML (Management), para consultas y mantenimiento. Lo frecuente es combinar los dos tipos (SQL).

    Además del SQL, el más estandarizado, tenemos el 4GL y los asistentes o interfaces visuales de algunos SGBD (Access p. ej.) Para trabajar con BD desde otros lenguajes de programación, podemos optar entre las llamadas a funciones (adquirir en el mercado librerias de funciones especializadas en BD, como la ODBC), u hospedar (embedded) directamente el lenguaje de BD (SQL en general) en nuestro programa de C, Pascal u otros.

    Administración de BD

    Mantener y admnistrar los esquemas, hacer backups, diseñar la BD, vigilar su integridad, etc.son funciones del admnistrador de BD.

  • EL MODELO RELACIONAL Y EL ÁLGEBRA RELACIONAL

  • Introducción al modelo relacional (SGBDR): el objetivo es que el usuario vea la BD como una estructura lógica de relaciones (tablas), simple y uniforme.

    Las relaciones

    Una relación o tabla se compone de:

    EMPLEADOS

    DNI

    Nombre

    Apellido

    Despacho

    40.523.685

    Juan

    García

    10

    33.567.711

    Marta

    Roca

    11

    55.898.425

    Carlos

    Bondia

    10

    Esquema

    Extensión

    La relación anterior se denota como EMPLEADOS(DNI, Nombre, Apellidos, Despacho) valiendo cualquier otro orden.

    El dominio es el conjunto de valores atómicos de un atributo (edades aceptadas, DNI's posibles, etc.)

    El grado es el número de atributos o columnas que componen la relación.

    Las filas no están ordenadas, pero no pueden estar repetidas.

    La clave de una relación : claves candidatas aquellos subconjuntos de atributos sin tuplas repetidas y con los mínimos atributos posibles. Clave primaria será la clave candidata que elijamos para identificar las filas de la tabla (tuplas de la relación. En el ejemplo, el DNI). Las otras candidatas serán las claves alternativas. Claves secundarias o foráneas serán aquellas que referencian a una primaria (la columna Despacho del ejemplo, sería secundaria de la primaria nº despacho de la tabla DESPACHOS (nº despacho, calle, población).

    Operaciones del modelo relacional

    Básicamente actualización (inserción, borrado y modificación) y consulta. Usaremos los leguajes relacionales como el SQL.

    Reglas de integridad

    Consisten en evitar que el modelo represente plausiblemente a la realidad, evitando incoherencias (sueldos <0, edades fuera del dominio, etc.). También recogen la unicidad de la clave primaria, su entidad (que no tenga valores nulos), la integridad del dominio ( que no haya valores fuera del dominio) y la integridad referencial (todos los valores que tome la clave secundaria deben existir en la primaria, o ser nulos).

    Para mantener esta integridad referencial, las políticas a seguir son: la restricción (impedir modificar o borrar una tupla con clave primaria relacionada con una secundaria), la actualización en cascada (permite modificar la tupla, actualizando las relacianadas) y la anulación (anula en cascada las relacionadas). Podríamos por ejemplo, aplicar la restricción para el borrado, y la actualización en cascada para la modificación.

    El álgebra relacional

    UNIÓN: EMPLEADOS:= EMPLEADOS_ADM U EMPLEADOS_PROD

    INTERSECCIÓN: T " S.

    DIFERENCIA: T - S

    SELECCIÓN: DESPACHOS( edificio= Marina y superficie>12)

    PROYECCIÓN: Nueva relación con sólo unos atributos escogidos de la relación original.

    COMBINACIÓN: Es una operación binaria, o sea, a partir de dos relaciones. Consiste en obtener una nueva relaciòn resultado de concatenar las tuplas de las dos relaciones que cumplan la condición de combinación especificada. Un ejeplo sería combinar las tablas EDIFICIOS y DESPACHOS para obtener todos los edificios con superficie superior a la media:

    R:= EDIFICIS [nomedificio = edificio, supmediadesp < superficie] DESPACHOS.

    En esta combinación, podrían haber tuplas “perdidas”, por no tener relaciones entre ellas. Para evitar esto, se usan las combinaciones externas, que conservan en el resultado a todas la tuplas. Pueden ser externas derecha , izquierda y plena, según las tuplas que conserven de cada relación.

  • EL LENGUAJE SQL

  • Lenguaje declarativo (se le dice qué se quiere hacer, no cómo) de definición, control y manipulación de BD. Algunos ejemplos:

    CREAR UNA TABLA:

    CREATE TABLE productos (cod_producto INTEGER, nom_producto CHAR (20), tipo CHAR (20), descripción CHAR (50), precio REAL, PRIMARY KEY (cod_producto))

    INSERTAR un producto en la tabla:

    INSERT INTO productos

    Values (1250, `LENA', `Mesa', `Diseño J. Ruíz. Año 1920', 250000

    CONSULTAR qué productos son sillas:

    SELECT cod_producto, nom-producto

    FROM productos

    WHERE tipo = `silla' ; (o WHERE precio > 100000, por ejemplo)

    Sentencias de definición

    CREATE: crea BD, tablas, dominios, aserciones y vistas

    ALTER: modifica tablas y dominios.

    DROP: borra todo lo anterior.

    CREATE SCHEMA { [nom_esquema] / [AUTHORIZATION usuario] }

    [lista_de_elementos_del_esquema]

    Nomenclatura utilizada: Las mayúsculas son palabras reservadas del lengyaje, lo que haya entre [...] se puede poner o no, y la notación {A/.../B} indica que hemos de escoger al menos una opción.

    DROP SCHEMA nom_esquema {RESTRICT / CASCADE}

    RESTRICT borra sólo si el esquema está vacío, CASCADE, borra aunque no lo esté

    CREATE DATABASE y DROP DATABASE, también son validas en la mayoría de BD.

  • Creación de tablas

  • CREATE TABLE nom_tabla

    ( definición_columna [ , definición_columna ] [ , restricciones_tabla ])

    donde definición_columna es:

    nom_columna {tipo_datos /dominio} [def_defecte] [restric_col ]

    Tipos de datos:

    CHARACTER ( longitud)

    Cadena de caracters de longitud fija

    NUMERIC (n, m)

    Decimales con n dígitos y m decimales

    DECIMAL (n, m)

    Decimales con n dígitos y m decimales

    INTEGER

    Enteros

    REAL

    Números con coma flotante y precisión predefinida

    DOUBLE PRECISION

    Igual, pero con más precisión que el REAL

    DATE

    YEAR, MONTH, DAY (`1978-12-25')

    TIME

    HOUR, MINUT, SECOND ('17:15:00.00000')

    TIEMSTAMP

    DATE y TIME juntos (`1998-7-8 9:30:05')

    Restricciones de columna:

    NOT NULL

    No puede tener valores nulos

    UNIQUE

    No puede tener valores repetidos. Es la clave alternativa

    PRIMARY KEY

    Ni valores repetidos ni nulos. Es la clave primaria

    REFERENCES tabla [(columna)]

    Clave secundaria de la col y tabla especificada

    CHECK (condiciones)

    Debe cumplir las condiciones especificadas.

    Restricciones de tabla:

    UNIQUE (columna [ , columna...] )

    Clave alternativa de la tabla

    PRIMARY KEY ( columna [, columna...] )

    Clave primaria de la tabla

    FOREIGN KEY (columna [columna...] )

    REFERENCES [(columna2 [columna 2…])]

    `columnas' son una clave secundaria que referencia a `columnas2', clave primaria

    CHECK (condiciones)

    Condicones a cumplir por la tabla

    Modificación y borrado de claves primarias con claves secundarias:

    FOREIGN KEY clave_secundaria REFERENCES tabla [ (clave_primaria) ]

    [ON DELETE {NO ACTION / CASCADE / SET DEFAULT / SET NULL } ]

    [ON UPDATE {NO ACTION / CASCADE / SET DEFAULT / SET NULL } ]

    donde NO ACTION = restricción (no permitiría el borrado o modificación).

    Aserciones: son restricciones generales que afectan a una o más columnas de más de una tabla.

    CREATE ASSERTION nom_aserción CHECK (condiciones)

    DROP ASSERTION nom_ aserción

    Modificar y borrar tablas:

    ALTER TABLA nom_tabla {acción_modificar_columna / acción_modif_restricción_tabla }

    Donde las accones pueden ser: {ADD/ALTER/DROP [COLUMN ]} Y {ADD restricción / DROP CONSTRAINT restricción {RESTRICT / CASCADE } }

    DROP TABLE nom_tabla { RESTRICT / CASCADE }

  • Consultas en una BD relacional

  • SELECT nom_columna_a_seleccionar [ [ AS ] col_renombrada ] [ , nom_columna_a-seleccionar .[ AS ...] ... ]

    FROM tabla_a_consultar [ [ AS ] tabla_renombrada]

    WHERE condiciones

    Ejemplo: SELECT * FROM clientes (el * es comodín)

    Para indicar las condiones en WHERE, usaremos los operadores de comparación (=, <, >, <=, >=, <>) y los lógicos (NOT, AND, OR).

    Si queremos ver la consulta sin filas repetidas, pondremos SELECT DISTINT en lugar de SELECT.

    Funciones de agregación: se aplican a columnas, por lo que van con SELECT ( ej. SELECT COUNT)

    COUNT (total filas), SUM (suma), MIN, MAX, AVG (media).

    Subconsultas: son consultas dentro de WHERE.

    WHERE precio = (SELECT MAX (precio) FROM proyectos)

    Otros predicados: BETWEEN (entre), [NOT] IN (similar a = [<>]), LIKE, IS [NOT] NULL , ALL/ANY/ SOME, [NOT] EXISTS. Ejemplos:

    WHERE sueldo BETWEEN 2.0E+6 AND 5.0E+6

    WHERE ciudad IN (`Lleida', `Tarragona') (Solo coge los de Lleida y Tarragona)

    WHERE nom_empleado LIKE `J%' ( _ y % serían los equivalentes a ? y * respectivamente)

    WHERE num_proyecto IS NULL

    WHERE precio > ALL/ANY/SOME (subconsulta)

    WHERE EXISTS (subconsulta)

    Otras cláusulas:

    ORDER BY columnas: ordena la consulta según lo especificado aquí

    GROUP BY columnas: agrupa las filas según las col especificadas.

    HAVING: según las condiciones indicadas aquí.

    SELECT columna

    FROM tabla (también se pueden indicar aquí varias tablas)

    [WHERE condiciones]

    GROUP BY columnas

    [HAVING condiciones ] (podemos usar aquí las funciones de agregación SUM, MAX, etc.)

    [ORDER BY columna_de_ordenación [DESC] [ , col_ordenación [DESC]...] ]

  • Combinaciones.(Join en inglés). Consultas a más de una tabla.

  • La combinación consiste en crear una sola tabla a partir de las tablas especificadas en la cláusula FROM, haciendo coincidir los valores de las columnas relacionadas de estas tablas. Para indicar la columna de una tabla, se escribe con el formato tabla.columna. Podemos usar alias para referirnos a las tablas, si los especificamos en FROM ( ej. FROM clientes c, proyectos p )

    Se puede hacer una combinación de la manera básica , o usando la cláusula JOIN que nos aporta el SQL92 completo. Comparemos ambas:

    SELECT p.precio, p.codi_proy, c.nif, p.codi_client, c.codi_cli

    FROM clients c, proyectos p

    WHERE c.codi_cli = p.codi_client AND c.codi_cli = 20

    SELECT p.precio, p.codi_proy, c.nif, p.codi_client, c.codi_cli

    FROM clients c JOIN proyectos p ON c.codi_cli = p.codi_client

    WHERE c.codi_cli = 20

    Combinación natural: la podemos hacer de la misma forma, usan NATURAL JOIN en vez de JOIN.Es una equicombinación, que combina columnas del mismo nombre y elimina las repetidas.

    Combinación interna (INNER JOIN): es la que hace por defecto. Se queda con las filas que tienen valores idénticos en las columnas de las tablas que compara. Esto puede hacer que perdamos alguna fila interesante, si por ejemplo se encuentra un valor nulo en alguna de las tablas al hacer la combinación.

    Combinación externa: nos permite subsanar lo anterior, obteniendo todos los valores de la tabla de la izquierda (LEFT OUTER JOIN), de la derecha (RIGHT OUTER JOIN), o de ambas ( FULL OUTER JOIN). El formato sería:

    SELECT columnas

    FROM t1 [NATURAL] { LEFT/RIGHT/FULL } [OUTER] JOIN t2

    [ON condiciones]

    [USING (columna [ , [columna…] ) ]

    Combinaciones con más de dos tablas: dos posibilidades, según usemos el SQL92 introductorio o el completo:

    SELECT *

    FROM empleados, proyectos, clientes

    WHERE num_proy = codi_proy AND codi_client = codi_cli (nombres de col. diferentes)

    SELECT *

    FROM (empleados JOIN proyectos ON num_proy = codi_proy )

    JOIN clientes ON codi_client = codi_clI

    Unir consultas: usaremos la cláusula UNION [ALL] (sin el ALL evitamos las filas repetidas), entre cada sentencia SELECT.

    Intersección: Usaremos INTERSECT [ALL] entre cada sentencia SELECT. Otra posibilidad es usar las cláusulas IN o EXISTS:

    SELECT columnas FROM filas WHERE columna IN ( SELECT columna FROM tabla [WHERE condiciones] )

    SELECT columnas FROM filas WHERE EXISTS ( SELECT * FROM tabla [WHERE condiciones] )

    Diferencia: usaremos EXCEPT [ALL]entre cada consulta SELECT.

  • DISEÑO DE BASES DE DATOS RELACIONALES

  • Consiste en definir la estructura de la BD, que será un conjunto de esquemas de relaciòn, con sus atributos, dominios, claves primarias y secundarias, etc. Este diseño, se ha de descomponer en etapas, que son tres: diseño conceptual, diseño lógico y diseño físico.

  • Diseño conceptual

  • Obtendremos aquí la estructura de la futura BD, independientemente de la tecnología a emplear posteriormente para llevarla a cabo. Para modelizar esa estructura, se usa el modelo ER (Entity-Relatioship), donde las entidades serían más o menos las tablas a definir, los atributos las columnas de la tabla ( definiremos también los atributos que actuan como claves), y las interrelaciones (relationship) las relaciones entre tablas (asociación entre entidades).

    Una interrelación piede asociar una o más entidades, pudiendo dar lugar, en este último caso, a la creación de nuevas entidades. Por ejemplo, si tenemos la interrelación ESTUDIANTE ASIGNATURA y queremos también tener constancia de las asignaturas que ha cursado en cada trimestre, deberemos crear la entidad TRIMESTRE. Una interrelación binaria, puede ser 1:1 (DELEGACIÓNCIUDAD), 1:N (DESPACHOEMPLEADOS), o M:N (ESTUDIANTESASIGNATURAS).

    Ejemplo: BD casas de colonias

    1 COMARCA

    RESIDENCIA

    1

    N SITUACIÓN

    N

    N 1 M N

    NIÑO CASA-COLONIAS ACTIVIDAD

    ALOJAMIENTO OFERTA

    Las entidades serían: CASA-COLONIAS(nom-casa, capacidad), ACTIVIDAD(nom-actividad), NIÑO (cod-niño, nombre, apellidos, teléfono), COMARCA (nom-comarca, superficie, numero-habitantes). Los atributos subrayados serían las claves primarias.

    Comentarios al modelo ER:

    Al decidir si COMARCA sería un atributo de CASA-COLONIAS y de NINÓ o una entidad propia, optamos por lo último, pues nos interesa reflejar datos adiccionales de la comarca (numero hab., superficie)como atributos de esta entidad.

    La misma decisión cabe tomar con ACTIVIDAD. Se crea como entidad, pues una casa de colonias puede ofrecer varias actividades y otras no.

    Otra elección dificil que sepresenta al diseñar un modelo ER, es decidir si una información es entidad o interrelación. En el ejemplo, podríamos haber puesto OFERTA como entidad entre CASA-COLONIAS y ACTIVIDAD (OFERTA(nom-casa, nom-actividad, nivel), pero no sería del todo correcto, pues se identifica con las claves de las dos entidades entre las cuales está lo que nos debería hacer sospechar.

  • Diseño lógico: la transformación al modelo relacional

  • Las entidades, darán lugar a relaciones. Las interrelaciones, a claves secundarias (las 1:1 y 1:N), o bien a nuevas relaciones (las M:N y todas las n-arias). Los atributos y clave primaria de la entidad, lo serán ahora de la relación.

  • Diseño físico:

  • No nos es necesario pues cada SGBDR se encarga de implementarlo, de forma transparente al usuario.

    Atributos o columnas

    Tuplas o filas




    Descargar
    Enviado por:Miguel Caceres
    Idioma: castellano
    País: España

    Te va a interesar