Página Principal Temas Básicos PL/SQL

Bases de Datos II. Temas básicos

Conceptos elementales de Bases de Datos

    1. Objetivos de las bases de datos
    2. Los computadores necesitan almacenar sus datos antes, durante y después de procesarlos. Al inicio, con sistemas de archivos planos era suficiente, pero con la introducción de los computadores en casi todas las actividades del hombre, se han hecho necesarios sistemas más poderosos, más seguros y más eficientes donde guardar esos datos.

      Una base de datos es una colección de datos relacionados, organizados de cierta manera predefinida y con algunos programas que administren esa información y su procesamiento. Estos programas se conocen como el DBMS (Data Base Management System) y ellos son los encargados de velar por que los datos estén almacenados correctamente, en forma segura y además, de brindar las herramientas para poder acceder a los datos.

      Las bases de datos relacionales (como Oracle) son un tipo de BD (base de datos) que se fundamenta en el paradigma de que los datos deben representar la realidad con dos elementos: las entidades y las relaciones. Se basa en que nuestro mundo se compone de entidades (personas, documentos, artículos, precios, etc.) y que estos se relacionan entre sí ("una persona tiene varios documentos", "un artículo tiene un precio", etc.). En una BD relacional, el sistema gestor se conoce como RDBMS (Sistema Administrador de Bases de Datos Relacionales).

      Una BD debe garantizar que podrá almacenar los datos que recibe, pero que lo hará en forma eficiente y segura. Es decir, que su RDBMS buscará la mejor forma de mantener los datos y que garantizará que la información se mantenga consistente y que no se altere a pesar de fallos que puedan ocurrir (daños en discos, fallo del suministro eléctrico, etc.).

      Otro objetivo de las BD es que deben brindar las herramientas necesarias para que podamos acceder a los datos (consultar, agregar, modificar o eliminar datos).

    3. El gestor de la base de datos (DBMS)

El objetivo principal de un DBMS es facilitar el acceso a los datos, brindando herramientas ágiles, sencillas y realizando las tareas de recuperación y modificación de los datos. Es un conjunto de programas que tiene a su cargo estas tareas:

  1. Interacción con el sistema de archivos del sistema operativo
  2. Implementación de la integridad
  3. Implementación de la seguridad
  4. Respaldo y recuperación
  5. Control de concurrencia

Otro elemento que normalmente va asociado a las BD es el Administrador de BD (DBA por sus siglas en inglés). Este es una persona que es el responsable por velar que la BD funcione correctamente, ejecuta los procesos de respaldo y recuperación que el DBMS le brinda, monitorea el comportamiento de las estructuras de datos y otras tareas relacionadas.

    1. Entidades y relaciones (E-R)
    2. Este es un modelo conceptual para representar los objetos del mundo cotidiano y sus relaciones. Estos modelos se usan cuando hacemos análisis o diseño de una BD, con el fin de representar la realidad que queremos implementar en un sistema de información.

      Existe cierta notación o simbología para hacer los diagramas. En el caso de Oracle, se usan solamente dos símbolos, el rectángulo (de puntas redondeadas) para las entidades y las "patas de gallo" para las relaciones.

      Como ejemplo tomemos el siguiente enunciado: "En un banco los clientes tienen cuentas que pueden ser de dos tipos (ahorro y corriente). Cada cuenta tiene una fecha de inicio, un saldo y una moneda en la que está dado el saldo. Para cada moneda, guardaremos el tipo de cambio de compra y venta diario". Para representar este sencillo enunciado, el diagrama podría ser el siguiente.

      Las entidades contienen atributos, que pueden ser obligatorios u opcionales. Las entidades deben identificarse por un nombre en singular. Las relaciones tienen dos características: la cardinalidad y la obligatoriedad.

      Las entidades se convertirán en las tablas de la BD. Las tablas se componen de columnas (atributos) y contienen filas (que serían los equivalentes de registros en un archivo). Cada fila debe identificarse con un atributo o conjunto de ellos en forma única. A esto se le llama PK o llave primaria y se representa por un #.

    3. Lenguaje DDL y DML
    4. Para acceder a los datos, en una BD se cuenta con dos tipos de lenguaje: el lenguaje de definición de datos (DDL) y el lenguaje de manipulación de datos (DML).

      El DDL se usa para crear, modificar y eliminar las estructuras de los distintos objetos de la base de datos. Por ejemplo, tablas, índices, vistas, triggers, etc. El DML se usa para acceder a los datos (consultar, insertar, modificar y borrar).

      Por ejemplo, en SQL*Plus de Oracle, el DDL tiene comandos para crear una tabla o para eliminar una tabla.

      CREATE TABLE cliente(

      Cliente_id Number NOT NULL,

      Nombre Varchar2(50) NOT NULL,

      Direccion Varchar2(100) NOT NULL,

      Telefono Number,

      Email Varchar2)

      ;

      DROP TABLE cliente

      ;

      El DML en Oracle, podría ejemplificarse con una consulta o con un borrado de datos.

      SELECT Moneda_ID, Descripción

      FROM Moneda

      ;

      DELETE FROM cuenta

      WHERE saldo > 1000

      ;

      Note que el comando DROP elimina la tabla cliente y lógicamente sus datos, mientras que el comando DELETE solamente borra los datos, dejando la tabla pero vacía.

    5. Integridad referencial

Como parte de la seguridad para garantizar que la información sea consistente, correcta y para facilitar la exactitud de las relaciones entre las filas de las tablas, se implementan algunas restricciones de integridad. Estas son reglas que el DBMS valida y que obliga a cumplir. El diseñador de la BD decide cuáles reglas se programarán.

Existen varios tipos de restricciones de integridad. Desde el modelo E-R ya se pueden implementar algunas como lo son las llaves y la cardinalidad. Las llaves (primarias, foráneas y únicas) evitan que se almacenen filas inconsistentes. Por ejemplo, basados en el ejemplo anterior, no podríamos insertar una fila en la tabla cuentas si el valor de la columna Moneda_ID no está también en la tabla monedas. De igual manera, no podríamos borrar una moneda de la tabla monedas si existen cuentas que tengan asociada esa moneda.

La cardinalidad restringe el conjunto de relaciones permitidas entre entidades (uno a muchos, muchos a muchos, etc.).

Otros tipos de restricciones son:

  1. De dominio: limita la cantidad de valores posibles para una columna. Ej.: el campo fecha sólo puede tomar valores válidos de una fecha y el día 30-Feb-2000 no se podrá almacenar. Para una columna de estado civil, por ejemplo, podemos programar que solamente acepte los valores S, C, D, V, U. Si alguien trata de cambiar el valor de la columna u poner cualquier otro carácter distinto de los indicados, el DBMS lo rechazará. Los tipos de datos son ejemplos de dominios.
  2. De valores nulos: Un valor nulo es un valor vacío o la ausencia de valor alguno en la columna. Cuando se dice que una columna es NOT NULL, quiere decir que la fila siempre tendrá un valor válido en esa columna. Es distinto de un blanco en una columna string o de un cero en una numérica. Este tiene sus propias características y una importante es que cuando se compara cualquier valor contra una columna nula, la comparación siempre será falsa.
  3. De afirmaciones: son reglas específicas que se implementan en el ámbito de columnas. Por ejemplo, podríamos decir que una columna de número de alumnos en un curso no puede valer menos que cero o que el saldo en una cuenta nunca puede ser menor a 100 mil.
  4. De disparadores (triggers). Estas son sentencias o programas que se ejecutan automáticamente cuando ocurre un evento en la BD. Para programar un disparador se debe indicar las condiciones que activarán el disparador y las acciones que se ejecutarán. Por ejemplo, puedo decir que cuando se borre una fila en cierta tabla, ejecute ciertas instrucciones para incrementar un contador de filas borradas en otra. Los triggers pueden dispararse antes o después de insertar, borrar o modificar una fila.
    1. Normalización

Cuando se diseñan bases de datos, se busca evitar la redundancia de información y que el acceso a los datos sea eficiente. Las reglas de normalización tratan de ir eliminando, paso a paso, esas deficiencias y dejar un diseño de la BD lo más depurado posible. Sin embargo, no siempre hay que normalizar completamente. Las reglas de normalización son, al fin y al cabo, teoría y algunas veces, con fines prácticos, es necesario "desnormalizar" algún diseño. Esto es una excepción, no a menudo ocurre, pero es bueno tomarlo en cuenta.

Reglas de normalización hay muchas, pero más bien yo quiero concentrarme en algunos consejos prácticos para el diseño de BD:

    1. Diseñe la BD en función de las entradas, salidas y los procesos. Al final de cuentas, lo que contiene una BD debe ingresarse, calcularse o producirse. El diseño de las pantallas de entrada, de las consultas y reportes y los datos que necesitemos para ejecutar un proceso, nos dicen qué debe llevar una base de datos.
    2. Las llaves primarias deben ser lo más pequeñas posibles (en cantidad de columnas). Se debe jerarquizar la información tantos niveles como sea necesario y llaves heredadas van complicando la nomenclatura.
    3. La información debe, en la medida de lo posible, estar en un solo lugar, pero tener las relaciones necesarias para que las entidades puedan llegar a ella. Esto evita tener información repetida (lo cual hace que gastemos más espacio) y elimina el peligro de información inconsistente (si en un lugar decimos que el cliente se llama Carla y en otro lado decimos que se llama Karla, por ejemplo).
    4. Tenga estándares para nomenclatura, documentación y estilo.
    5. Busque siempre un diseño flexible, use parámetros y sea consistente.

    Página Principal Temas Básicos PL/SQL

Trance Convexo