viernes, 25 de febrero de 2011

Avance de la Base de Datos


A continuación un pequeño avance del diseño de una base de datos de un videoclub,  esto tiene como fin estudiar los diagramas entidad-relación, los grafos relacionales y el código en SQL.


Diagrama Entidad - Relación


Grafo Relacional


Boceto de la base de datos en SQL 

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`Pelicula`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Pelicula` (
  `id_pelicula` INT NOT NULL ,
  `titulo` VARCHAR(45) NOT NULL ,
  `nacionalidad` VARCHAR(45) NOT NULL ,
  `productora` VARCHAR(45) NOT NULL ,
  `año` YEAR NOT NULL ,
  `genero` VARCHAR(45) NOT NULL ,
  `nombre_director` VARCHAR(45) NOT NULL ,
  `nombre_actor` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`id_pelicula`, `nombre_director`, `nombre_actor`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`Ejemplar`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Ejemplar` (
  `ISBN` INT NOT NULL ,
  `numero_ejemplar` VARCHAR(45) NOT NULL ,
  `estado_conservacion` VARCHAR(45) NOT NULL ,
  `id_pelicula` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`ISBN`, `id_pelicula`) ,
  INDEX `id_pelicula` (`ISBN` ASC) ,
  CONSTRAINT `id_pelicula`
    FOREIGN KEY (`ISBN` )
    REFERENCES `mydb`.`Pelicula` (`id_pelicula` )
    ON DELETE SET NULL
    ON UPDATE SET NULL)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`Cliente`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Cliente` (
  `curp` INT NOT NULL ,
  `nombre` VARCHAR(45) NOT NULL ,
  `sexo` VARCHAR(20) NOT NULL ,
  `adeudos` VARCHAR(45) NOT NULL ,
  `edad` VARCHAR(45) NOT NULL ,
  `telefono` INT NOT NULL ,
  `direccion` VARCHAR(60) NOT NULL ,
  PRIMARY KEY (`curp`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`Prestamo`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Prestamo` (
  `id_pelicula` INT NOT NULL ,
  `numero_ejemplar` VARCHAR(45) NOT NULL ,
  `existencia` INT NOT NULL ,
  `multa` VARCHAR(45) NOT NULL ,
  `fecha_entrega` VARCHAR(45) NOT NULL ,
  `fecha_devolucion` VARCHAR(45) NOT NULL ,
  `curp` INT NOT NULL ,
  PRIMARY KEY (`id_pelicula`, `curp`) ,
  INDEX `id_pelicula` (`id_pelicula` ASC) ,
  INDEX `numero_ejemplar` (`numero_ejemplar` ASC) ,
  INDEX `curp` (`curp` ASC) ,
  CONSTRAINT `id_pelicula`
    FOREIGN KEY (`id_pelicula` )
    REFERENCES `mydb`.`Pelicula` (`id_pelicula` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `numero_ejemplar`
    FOREIGN KEY (`numero_ejemplar` )
    REFERENCES `mydb`.`Ejemplar` (`id_pelicula` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `curp`
    FOREIGN KEY (`curp` )
    REFERENCES `mydb`.`Cliente` (`curp` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`Director`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Director` (
  `nombre_director` VARCHAR(45) NOT NULL ,
  `nacionalidad` VARCHAR(45) NOT NULL ,
  `sexo` VARCHAR(20) NOT NULL ,
  PRIMARY KEY (`nombre_director`) ,
  INDEX `nombre_director` (`nombre_director` ASC) ,
  CONSTRAINT `nombre_director`
    FOREIGN KEY (`nombre_director` )
    REFERENCES `mydb`.`Pelicula` (`nombre_director` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`Actor Principal`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`Actor Principal` (
  `nombre_actor` VARCHAR(45) NOT NULL ,
  `nacionalidad_actor` VARCHAR(45) NOT NULL ,
  `sexo_actor` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`nombre_actor`) ,
  INDEX `nombre_actor` (`nombre_actor` ASC) ,
  CONSTRAINT `nombre_actor`
    FOREIGN KEY (`nombre_actor` )
    REFERENCES `mydb`.`Pelicula` (`nombre_actor` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


Nota importante:

Para el diseño de esta base de datos, se hizo uso de la herramienta workbench,
si deseas adquirirla haz click aqui.

viernes, 18 de febrero de 2011

Ejemplo de Normalización de una Base de Datos



Esta vez se analizará la normalización de una base de datos desde un ejemplo, su desglosamiento, su análisis y su finalización.


 Ejemplo simplificado de una base de datos para una pequeña biblioteca.


Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla. 



Como se puede ver, hay cierta redundancia característica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro.

Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra tabla.
 
 

La nueva tabla sólo contendrá datos del lector.


Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de la base de datos necesita que exista otra tabla para mantener la información de qué libros están prestados a qué lectores. Esta tabla se muestra a continuación:


Para la Tercera Forma Normal (3NF) la relación debe estar en 2NF y además los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. También recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente información sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva información acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.



Aunque hemos creado nuevas tablas para que cada una tenga sólo información acerca de una entidad, también hemos perdido la información acerca de qué autor ha escrito qué libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.




Y el resto de las tablas no necesitan modificación.


Ahora un video complementario:  


  


Créditos:

 Luiz Paez  
e-mail: yupan03@yahoo.com

Dante Eduardo Luna Hernández
kintaluna@gmail.com 

miércoles, 9 de febrero de 2011

Sistemas Gestores de Bases de Datos

Concepto

Los sistemas de gestión de bases de datos (en inglés database management system, abreviado DBMS) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. 


Su propósito

El propósito general de los sistemas de gestión de bases de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante para una organización.  


Objetivos de su uso

Existen distintos objetivos que deben cumplir los SGBD:

Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.

Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.

Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.

Manejo de transacciones. Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.

Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD demora en proporcionar la información solicitada y en almacenar los cambios realizados.


A continuación se presenta un video con el fin de dar a entender la importancia de los Sistemas Gestores de Bases de Datos. 


Ver más videos sobre Gestores de Bases de Datos


Agentes que interactúan con estos gestores:

El gestor de la base de datos 
 

Se trata de un conjunto de programas no visibles al usuario final que se encargan de la privacidad, la integridad, la seguridad de los datos y la interacción con el sistema operativo. Proporciona una interfaz entre los datos, los programas que los manejan y los usuarios finales.
Cualquier operación que el usuario hace contra la base de datos está controlada por el gestor. El gestor almacena una descripción de datos en lo que llamamos diccionario de datos, así como los usuarios permitidos y los permisos.
Tiene que haber un usuario administrador encargado de centralizar todas estas tareas.



Diccionario de datos

Es una base de datos donde se guardan todas las propiedades de la base de datos, descripción de la estructura, relaciones entre los datos, etc. 


El diccionario debe contener:
La descripción externa, conceptual e interna de la base de datos
Las restricciones sobre los datos
El acceso a los datos
Las descripciones de las cuentas de usuario
Los permisos de los usuarios
Los esquemas externos de cada programa



 El administrador de la base de datos 

Es una persona o grupo de personas responsables del control del sistema gestor de base de datos.
 

Las principales tareas de un administrador son:
La definición del esquema lógico y físico de la base de datos
La definición de las vistas de usuario
La asignación y edición de permisos para los usuarios
Mantenimiento y seguimiento de la seguridad en la base de datos
Mantenimiento general del sistema gestor de base de datos
 


Los lenguajes

Un sistema gestor de base de datos debe proporcionar una serie de lenguajes para la definición y manipulación de la base de datos. 


Estos lenguajes son los siguientes:
Lenguaje de definición de datos (DDL). Para definir los esquemas de la base de datos
Lenguaje de manipulación de datos (DML). Para manipular los datos de la base de datos
Lenguaje de control de datos(DCL). Para la administración de usuarios y seguridad en la base de datos.
 

Ver presentación