Bases DE Datos 1 - Apuntes 1 PDF

Preview

Summary

introduccion a la bdd...

Description

BASES DE DATOS 1 MODULO 1

MODELO RELACIONAL Definición de base de datos Una base de datos es un conjunto de datos estructurados y definidos a través de un proceso específico, que busca evitar la redundancia, y que se almacenará en algún medio de almacenamiento masivo, como un disco. Además, cada dato está en contacto con otros mediante relaciones.

Sistema de Gestión de Bases de Datos (DBMS) El sistema de gestión de base de datos es como una capa de software que controla todos los accesos a la base de datos. El DBMS se desempeñará tanto para fines de un sistema de gestión de alumno como para un sistema bancario, una empresa telefónica, etc. El DBMS puede implementar instrucciones dadas por los distintos usuarios. Las instrucciones se agrupan mínimamente en: DDL (lenguaje de definición de datos) y DML (lenguaje de manipulación de datos) o también DCL (lenguaje de control de datos). DDL: es el conjunto de órdenes que permite definir la estructura de una base de datos. DML: las instrucciones que conforman este grupo son las que están incluidas en las aplicaciones y se usan para alternar el contenido de un archivo de datos. DCL: son ordenes que se utilizan para implementar seguridad en la base de datos. Teniendo en cuenta lo expresado, la nueva definición de base de datos puede ser: Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una aplicación o más, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados

Usuarios de la base de datos Los distintos usuarios de una base de datos son:  Administrador de la base de datos: comúnmente es profesional con perfil técnico que, en el ambiente informático, se denomina DBA (Data Base Administrator). Este recibe las especificaciones del equipo de análisis y diseño para su implementación en un sistema de gestión de base de datos.  Programador de aplicaciones: conoce los casos que se desarrollaran, los prototipos de interfaces y las estructuras de los almacenamientos que se manipularan. Este genera las aplicaciones necesarias para la obtención de entradas de datos que alimentaran la base de

datos y para lograr las salidas que se plantearon en la propuesta de solución. Solo necesita conocer lo que va a programar. Generalmente trabaja en un equipo de desarrollo.  Usuario final: es el personal que interactuara con las aplicaciones desarrolladas y es el que menos conocimiento tiene de estas.

Seguridad de las bases de datos Por lo general, la seguridad de las bases de datos esta manejada por el DBA. Este último es responsable de la creación de los nuevos usuarios y de la accesibilidad de los objetos de la base de datos. Es importante que los desarrolladores, los DBA y los usuarios entiendan las opciones disponibles en el modelo de seguridad. Se debe llegar a un balance entre el permiso de acceso a los usuarios y el control de lo que se les permite. En Oracle el modelo de seguridad se basa en los siguientes elementos: • Privilegios de sistema. • Uso de roles para administrar el acceso a los datos. • Privilegios de objeto. • Contraseñas modificables. • Otorgar y revocar los privilegios de objetos y de sistema. • Uso de sinónimos para la transparencia de base de datos. El modelo de seguridad de Oracle consiste en dos partes: 1. Autenticación de contraseñas, que puede basarse en el Sistema Operativo que aloja al motor o usar el propio sistema de autenticación de la base. Si el DBA elige la última opción, las contraseñas se encriptan y guardan en el diccionario de la base de datos. 2. Control de que objeto de la base de datos se puede acceder y por qué usuario.

Creación de usuarios Se hace mediante el comando SQL: CREATE USER IDENTIFIED BY

Otorgar privilegios de sistema Los privilegios de sistema permiten al usuario que los recibe la creación, modificación y eliminación de los objetos de la base de datos que almacenan los datos de las aplicaciones. Para poder realizar alguna operación en la base de datos, el usuario necesita un privilegio llamado CREATE SESSION. Dentro de alcance de los privilegios del sistema hay dos categorías: ■La primer de ellas es el conjunto de privilegios que se relacionan con el manejo de objetos como tablas, índices, etc. Con estos priveligos se pueden realizar las siguientes acciones: crear,

alterar su definición y eliminarlos en general y, para las tablas y programas, tenemos los privilegios de creación de índices, hacer referencia a la clave primaria con una foránea y ejecutar un programa almacenado. ■La segunda categoría de los privilegios se refiere a la habilidad de un usuario para realizar funciones como actividades de auditoria, generación de estadísticas para soportar el funcionamiento del optimizador basado en costos y permitir el acceso a la base de datos solamente a los usuarios con un privilegio de sistemas especial denominado restricted session. El otorgamiento de permisos se ejecuta con la sentencia GRANT y para otorgar un privilegio de sistema a otro usuario, el que lo transmite (GRANTOR) debe haber recibido el mismo privilegio con el agregado WITH ADMIN OPTION. Los usuarios pueden crear objetos dentro de su esquema y si fuera necesario que un usuario deba crear objetos para cualquier otro esquema, deberá recibir el privilegio GRANT CREATE ANY TABLE TO miusuario. La anulación de un privilegio se realiza con REVOKE.

Usar roles para administrar los accesos de base de datos Estos roles agrupan privilegios y su nombre describe un tipo de tarea o función. Para usar roles es necesario realizar dos tareas: 1. 2.

Agrupar lógicamente los privilegios. Agrupar a los usuarios de cada aplicación que manejan necesidades similares.

A estos roles se les puede definir una contraseña para proteger el acceso a los privilegios. Esta forma de hacer niveles de roles como capas intermedias facilita la administración, puesto que bastara con determinar el tipo de usuario que corresponde o la clase de tarea que se le habilitara para encontrar uno o dos roles. Sentencias de los roles:   

CREATE ROLE: crea el rol ALTER ANY ROLE: da permiso para editar roles DROP ANY ROLE: permite eliminar un rol

Otorgar privilegios de objetos Una vez creado el objeto puede ser administrado por su administrador o por cualquier usuario que tenga el privilegio GRANT ANY PRIVILEGE.

Cambio de contraseñas El usuario puede cambiar su contraseña con: ALTER USER juan IDENTIFY BY abretesesamo.

Uso de sinónimos para la transparencia de base de datos

Los objetos de base de datos de los usuarios que los crean estarán disponibles solo para el, a menos que se le otorguen privilegios. Sin embargo, por mas que un usuario presente los privilegios necesarios, primero debe poner el nombre del esquema y luego del objeto para llamarlo, por ejemplo, pedro.materias. Este requisito de anteponer el esquema produce la perdida de transparencia que se debe resolver usando sinónimos. Hay dos tipos de sinónimos:  Privados: tienen una aplicación más limitada.  Públicos: se usan para poner a disposición de los objetos a todos los usuarios sin el requisito de calificarlos con el formato esquema.nombre_del_objeto. Usando la sentencia CREATE PUBLIC SYNONYM materias FOR pedro.materias, cualquiera podrá ingresar a con la sentencia SELECT*FROM materias, sin la necesidad del prefijo. Los sinónimos privados funcionan igual, pero se da acceso solo a determinados usuarios.

Funciones y responsabilidades de un DBA Entre las funciones principales del DBA podemos mencionar:  Especificación lógica de la base de datos: especifica, mediante la interfaz del DBMS elegido o las sentencias de definición de datos, la estructura de la base de datos que recibió del equipo de análisis y diseño. Las sentencias que usa el DBA se agrupan en el lenguaje de definición de datos (DDL) y está formada por las instrucciones para trabajar en la estructura y también para crear, modificar o eliminar objetos.  Especificación física: el DBA define el medio físico para almacenar la base de datos, como se almacenarán los archivos y como se accederá a estos.  Definición de seguridad: define grupos de usuarios y usuarios individuales, con los perfiles para cada uno, e indica los archivos a los que pueden acceder y los derechos que poseen de manera individual.  Definir procedimiento de respaldo: es responsabilidad del DBA asegurar que los datos estén respaldados, por lo tanto, deberá definir la periodicidad y el medio para los respaldos.  Implementar reglas de integridad: El equipo de análisis y diseño especifica ciertas limitaciones a los datos que se almacenaran, determinadas por el mundo real de la organización o por reglas lógicas propias de las bases de datos.  Monitorear la performance de la base de datos: deberá monitorear el rendimiento de la base de datos, detectando los procesos que generen demoras en la devolución de información, para mejorar su performance general.

Arquitectura ANSI/SPARC La arquitectura ANSI/SPARC surge para estandarizar los conceptos y permitir una mejor lectura de la independencia de datos, lo que permitirá que se ubique a cada usuario de una base de datos en función de su relación con ella. ANSI (American National Standards Institute) supervisa la creación, promulgación y el uso de miles de normas y directrices que impactan directamente en casi todos los sectores de las

empresas: desde dispositivos acústicos hasta los equipos de construcción, desde la producción lechera y ganadera hasta la distribución de energía, y muchos más. El comité llamado SPARC (Standars Planning and Requirements Committee) fija un grupo de estudio de DBMS para especificar los modelos para la estandarización de las bases de datos. Divide la vista de sistema en vista de empresa y de almacenamiento que actualmente se conoce como:  Nivel externo: lo conforman las múltiples vistas de los datos almacenados en la base de datos y se presentan a los distintos usuarios de múltiples formas, adecuándolas a las necesidades de información que tiene cada uno. Se lo denomina nivel de visión.  Nivel conceptual: es la estructura lógica global, que representa las estructuras de datos y sus relaciones. Hay una única vista en este nivel y se la define con el lenguaje de definición de datos.  Nivel interno: se define como el conjunto de datos que están almacenados físicamente y, como no se accede a ellos, también se lo denomina nivel físico. El DBA está en condiciones y es el único que debería conocer el nivel físico, para modificarlo si hiciera falta. Solo el DBA puede introducir cambios en el nivel conceptual. Físicamente los archivos son solo bytes que son invisibles para cualquier usuario, pero el DBA, mediante herramientas e instrucciones del DBMS, puede organizarlos e indicar en que disco almacena la base de datos y definirá, para cada archivo, su método de acceso. En el nivel conceptual o de estructura lógica, el DBA puede crear o modificar las estructuras de estos archivos. En el nivel externo, cada usuario verá lo que necesita y tiene habilitado.

Modelos de datos Un modelo de datos brinda distintos conceptos y permite definir las reglas y las estructuras para el almacenamiento de datos para, después, manipularlos. Modelo de datos orientado a objetos Este modelo nace con el objetivo de permitir el almacenamiento de datos para aplicaciones complejas que no se orientan a las del área comercial y administrativa, sino a las de las ingenierías en las que la estructura de los datos es compleja y las operaciones se definen en función de la necesidad de las aplicaciones. El grupo de gestión de bases de datos orientadas a objetos (ODMG) es el encargado de estandarizar el modelo de datos, el lenguaje de definición de objetos y el lenguaje de consulta de objetos. Los datos se almacenan de manera persistente en objetos, que se identifican, unívocamente, por un OID generado por el sistema. Los objetos se definen con una estructura (OID,Constructor_Tipo,Estado) en la que:

 OID (identificador de objeto): identificador único en el sistema; incluso, cuando se elimina un objeto, es conveniente que el OID no se reutilice.  Constructor_Tipo: es la definición de la construcción del estado del objeto.  Estado: se define a través del Constructor_Tipo. Para consultar la base de datos, se utiliza el lenguaje OQL propuesto por ODMG. Las sentencias de este lenguaje son similares a las de SQL y pueden ser insertadas en programas desarrollados con lenguajes de la programación orientada a objetos. Entre las ventajas de este modelo, se pueden distinguir: la posibilidad de manipular objetos complejos con buen rendimiento, la integración de la persistencia de datos a la programación orientada a objetos y un menor consto y esfuerzo en el desarrollo de las aplicaciones y en el mantenimiento. En la actualidad se conocen prototipos y productos de gestión de bases de datos orientadas a objetos como:  Jasmine: tecnología orientada a objetos que permite tratar datos multimedia y complejas informaciones relacionadas.  GemStone: es el ODBMS comercial con mas tiempo en el mercado. Soporta acceso concurrente de multiples lenguajes.  Versant Object Database (V/OD): ofrece caracteristicas importantes a los desarrolladores C++, java o NET, el apoyo a la concurrencia masiva y a grandes conjuntos de datos. Modelos de datos basados en registros Estos modelos de datos tienen sus inicios con los modelos de red y jerárquicos. Ambos modelos compartían el concepto de registro de datos y los enlaces físicos entre ellos, pero diferían en sus restricciones y en su representación.

Modelo relacional: características y origen El concepto fundamental, en el Modelo Relacional, es que los datos se representan de una sola manera, en el nivel de abstracción que es visible al usuario y es específicamente una tabla con valores. Los conceptos básicos que se utilizarán, a partir de este momento, son propios del modelo y se resumen en: Relación: no es más que una representación de doble entrada, constituida por filas, o tuplas, y columnas o atributos. Es el concepto primitivo y fundamental del modelo. La relación debe cumplir con un conjunto de restricciones o propiedades que ya han sido mencionadas. Dentro del diseño de la base de datos, las relaciones representan a las entidades que se modelaron. Las entidades poseen atributos que las distinguen y cada uno de ellos está ligado a un dominio en particular. Fila o tupla: es un hecho en la relación que contiene datos de la realidad. Cuerpo: al conjunto de tuplas de una relación se lo denomina cuerpo de la relación. Columna o atributo: es una propiedad que caracteriza a cada entidad, como el color o tamaño de un artículo. Los elementos que componen la estructura de la entidad se denominan atributos y serán irrepetibles en la entidad. Cabecera: el conjunto de atributos de una relación conforma la cabecera de dicha relación.

Dato: es la mínima unidad que se almacena en una relación, es la intersección entre una columna y una fila. Grado: es el número de columnas, es estático, pero puede cambiar dependiendo de las necesidades. Cardinalidad: es el número de filas, es dinámica ya que depende de los agregados. Dominio: es el conjunto de valores posibles de un atributo. El dominio es la restricción de lo que se quiere que el atributo represente dentro de la entidad.

Propiedades de las relaciones Estas propiedades, definidas por el Dr. Codd, fijan limitaciones en el modelo. Tienen su origen en la matemática de conjuntos. Orden de las tuplas en una relación: una relación es un conjunto de tuplas y como el concepto en matemática indica que los conjuntos no están ordenados, estas tampoco lo están. El orden de las filas es inmaterial. Orden de los atributos: los atributos son elementos de un conjunto, por lo tanto tampoco se pueden ordenar. Todas las filas son distintas: los elementos de un conjunto son distintos entre si, por lo tanto las filas, al ser un conjunto, también lo son. Un valor único en la intersección de fila y columna: toda relación esta normalizada, por lo que no se acepta la idea de que un valor pueda ser una estructura divisible.

Reglas de Codd Regla 0: Regla de fundación: un sistema de gestión de base de datos debe gestionar sus datos almacenados utilizando solo sus capacidades relacionales. Regla 1: Regla de la información: toda la información debe estar representada como valores en una relación. Regla 2: Regla de acceso garantizado: todos y los datos están garantizados para ser lógicamente accesibles recurriendo a una combinación de nombre de la relación, valor de clave primaria y nombre de columna. Regla 3: Tratamiento sistemático de valores nulos: los valores nulos se soportan en el DBMS (DataBase Management System) relacional para la representación de información que falta en una manera sistemática. El DBMS es una colección de software muy específico, orientado al manejo de base de datos, cuya función es servir de interfaz entre la base de datos, el usuario y las distintas aplicaciones utilizadas. Regla 4: Catalogo dinámico en línea basado en el modelo relacional: la descripción de la base de datos esta representada, en el nivel lógico, de la misma manera que los datos ordinarios, de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para consultar que le aplicado a los datos regulares. Regla 5: Regla del sublenguaje de datos completa: un sistema relacional puede admitir varios lenguajes y modos de uso de terminales, pero debe haber un lenguaje cuyas sentencias se puedan expresar por una sintaxis bien definida. Debe soportar:

a) Definición de datos. b) Definición de vista. c) Manipulación de datos (interactiva y por programa.

d) Restricciones de integridad. e) Autorización. f) Límites de la transacción (iniciar “BEGIN”, realizar “COMMIT” y deshacer “ROLLBACK”). Regla 6: Regla de actualización de visitas: por el sistema se deben actualizar todas las visitas que son teóricamente actualizables. Regla 7: inserción, actualización y borrado de alto nivel: se deben manejar estas operaciones como una simple operación. Regla 8: independencia física de datos: los programas de aplicación y a las actividades de terminales permanecen lógicamente inalterables cuando los cambios preservan la información en las relaciones bases. Regla 9: independencia lógica de datos: los programas de aplicación y las actividades preservan la información en las relaciones bases. Regla 10: independencia de integridad: las reglas de integridad se deben definir en un sublenguaje de datos y almacenar en el catálogo o diccionario de datos. Regla 11: independencia de distribución: el sublenguaje de manipulación de datos de un DBMS relacional debe permitir que los programas de aplicación y actividades de terminal permanezcan lógicamente intactos, cuando los datos están físicamente centralizados o distribuidos. Regla 12: regla de no subversión: si un sistema relacional tiene o soporta un lenguaje de bajo nivel, ese lenguaje no se puede usar para saltear las reglas de integridad o las reglas expresadas en el lenguaje relacional de alto nivel.

Atributos claves En las relaciones hay atributos que cumplen ciertas condiciones y, en función de ellas, se clasifican.

Condiciones de las claves candidatas Para que un atributo o conjuntos de atributos de una relación sea clave candidata, deba cumplirse las siguientes condiciones: Unicidad: indica la no repetición del valor de un atributo en la vida de una relación. La clave candidata debe ser compuesta por más de un atributo, entonces debe buscarse la combinación de atributos que sean únicos. Si está bien elegida, permite que nunca haya una fila duplicada. Minimalidad: se llama así a la condición que se debe considerar cuando se elige una clave candidata compuesta por más de un atributo y que indica que será la mínima combinación de atributos posibles que cumpla con la condición de unicidad.

Claves primarias Estas claves son de gran importación, ya que, si no se determ...