Página Principal | Temas Básicos | PL/SQL |
Bases de Datos II. Temas básicos
Conceptos elementales de Bases de Datos
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).
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:
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.
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 #.
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.
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:
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:
Página Principal Temas Básicos PL/SQL