domingo, 20 de marzo de 2011
viernes, 18 de marzo de 2011
CONCLUSIÓN
Debido a la cantidad de gestores manejadores de bases de datos y las caraterísticas que representan cada uno de ellos, es de vital importancia tener al menos la escencia de cada uno de estos en mente, pues así resultará mucho más fácil elegir alguno que cubra nuestras necesidades.
Es importante conocer las características de los gestores, sus ventajas, desventajas para saber explotarlos al máximo y no caer en los errores; así como saber que tipo de software manejamos o deseamos utilizar, ya que existen los libres, no libres, no libres y gratuitos así como los costos que se requiere al momento de adquirir licencias de propietarios.
Es importante conocer las características de los gestores, sus ventajas, desventajas para saber explotarlos al máximo y no caer en los errores; así como saber que tipo de software manejamos o deseamos utilizar, ya que existen los libres, no libres, no libres y gratuitos así como los costos que se requiere al momento de adquirir licencias de propietarios.
miércoles, 16 de marzo de 2011
NORMATIZACIÓN
El proceso de normalización de bases de datos relacionales
La normalización de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de técnicas para producir un nuevo esquema que representa la misma información pero contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y borrados.
El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relación, que se define por una serie de atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restricción que nos indica que cada entidad representada por una tupla tiene que ser diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos valores identifiquen unívocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave ajena.
El proceso de normalización
El proceso de normalización consiste en comprobar en secuencia si el esquema original está en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.
Un ejemplo completo
Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional
La normalización de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de técnicas para producir un nuevo esquema que representa la misma información pero contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y borrados.
Breve recordatorio del modelo (formal) relacional
El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relación, que se define por una serie de atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restricción que nos indica que cada entidad representada por una tupla tiene que ser diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos valores identifiquen unívocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave ajena.
El proceso de normalización
El proceso de normalización consiste en comprobar en secuencia si el esquema original está en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.
Un ejemplo completo
Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.
Primera forma normal (1FN)
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.
Solución 1: duplicar los registros con valores repetidos
En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:
El atributo M que violaba 1FN se elimina.
Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M.
La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email):
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.
Solución 1: duplicar los registros con valores repetidos
En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:
El atributo M que violaba 1FN se elimina.
Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M.
La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email):
Solución 2: separar el atributo que viola 1FN en una tabla
En general, esta solución pasa por:
sustituir R por una nueva relación modificada R' que no contiene el atributo M.
Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.
La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)
En general, esta solución pasa por:
sustituir R por una nueva relación modificada R' que no contiene el atributo M.
Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.
La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)
Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):
Segunda forma normal (2FN)
Un esquema está en 2FN si:
Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta:
Un esquema está en 2FN si:
Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta:
Y al eliminar de la tabla original estos atributos nos quedaría:
Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el problema de 1FN.
Tercera forma normal (3FN)
Una relación está en tercera forma normal si, y sólo si:
está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
Por lo tanto la descomposición sería la siguiente:
Tercera forma normal (3FN)
Una relación está en tercera forma normal si, y sólo si:
está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
Por lo tanto la descomposición sería la siguiente:
En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.
sábado, 26 de febrero de 2011
Una base de datos programada en MYSQL
CREATE database nombre_bd;
USE nombre_bd
CREATE TABLE usuario(
clave INT NOTNULL primary key,
nombre VARCHAR(20) NOTNULL,
DIRECCION VARCHAR(30) NOTNULL,
TELEFONO VARCHAR(10) NOTNULL,
EMAIL VARCHAR(20) NOTNULL,
OCUPACION VARCHAR(20) NOTNULL,
)EGINE = INNOBD;
CREATE TABLE LIBRO(
ISBN VARCHAR(20) NOTNULL PRIMARY KEY,
TITULO VARCHAR(20) NOTNULL,
AUTOR VARCHAR (30) NOTNULL,
NEDICION VARCHAR(20) NOTNULL,
NEJEMPLAR VARCHAR (20) NOTNULL,
)ENGINE = INNOBD;
CREATE TABLE EJEMPLAR(
ISBN VARCHAR(20) NOTNULL,
NUMEJEMPLAR VARCHAR(20) NOTNULL,
EDOCONSERVACION VARCHAR(2'0) NOTNULL
PRIMARY KEY(ISBN,NUMEJEMPLAR),
FOREINGN KEY (ISBN) REFERENCES LIBRO(ISBN)
)ENGINE = INNODB;
CREATE TABLE PRESTAMO(
CLAVEUSUARIO VARCHAR(20) NOTNULL PRIMARY KEY,
ISBN VARCHAR(20) NOTNULL,
NUMEJEMPLAR VARCHAR(10) NOTNULL,
MULTA INT NOTNULL,
FOREINGN KEY (ISBN) REFERENCES EJEMPLAR(ISBN),
FOREINGN KEY (NUMEJEMPLAR) REFERENCES EJEMPLAR(NUMEJEMPLAR),
)ENGINE = INNODB;
USE nombre_bd
CREATE TABLE usuario(
clave INT NOTNULL primary key,
nombre VARCHAR(20) NOTNULL,
DIRECCION VARCHAR(30) NOTNULL,
TELEFONO VARCHAR(10) NOTNULL,
EMAIL VARCHAR(20) NOTNULL,
OCUPACION VARCHAR(20) NOTNULL,
)EGINE = INNOBD;
CREATE TABLE LIBRO(
ISBN VARCHAR(20) NOTNULL PRIMARY KEY,
TITULO VARCHAR(20) NOTNULL,
AUTOR VARCHAR (30) NOTNULL,
NEDICION VARCHAR(20) NOTNULL,
NEJEMPLAR VARCHAR (20) NOTNULL,
)ENGINE = INNOBD;
CREATE TABLE EJEMPLAR(
ISBN VARCHAR(20) NOTNULL,
NUMEJEMPLAR VARCHAR(20) NOTNULL,
EDOCONSERVACION VARCHAR(2'0) NOTNULL
PRIMARY KEY(ISBN,NUMEJEMPLAR),
FOREINGN KEY (ISBN) REFERENCES LIBRO(ISBN)
)ENGINE = INNODB;
CREATE TABLE PRESTAMO(
CLAVEUSUARIO VARCHAR(20) NOTNULL PRIMARY KEY,
ISBN VARCHAR(20) NOTNULL,
NUMEJEMPLAR VARCHAR(10) NOTNULL,
MULTA INT NOTNULL,
FOREINGN KEY (ISBN) REFERENCES EJEMPLAR(ISBN),
FOREINGN KEY (NUMEJEMPLAR) REFERENCES EJEMPLAR(NUMEJEMPLAR),
)ENGINE = INNODB;
lunes, 21 de febrero de 2011
SISTEMA GESTOR DE BASE DE DATOS
Un Sistema Gestor de Bases de Datos (SGBD) o DBMA (DataBase Management System) es una colección de programas cuyo objetivo es servir de interfaz entre la base de datos, el usuario y las aplicaciones. Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta. Un SGBD permiten definir los datos a distintos niveles de abstracción y manipular dichos datos, garantizando la seguridad e integridad de los mismos.
Un SGBD debe permitir:
• Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
• Construir la base de datos: guardar los datos en algún medio controlado por el mismo SGBD
• Manipular la base de datos: realizar consultas, actualizarla, generar informes.
Las características de un Sistema Gestor de Base de Datos SGBD son:
• 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.
• Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición de información repetida o redundante. De entrada, lo ideal es lograr una redundancia nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la aparición de redundancias.
• Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, 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.
• 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 segurizada frente a usuarios malintencionados, que intenten leer información privilegiada; frente a ataques que deseen manipular o destruir la información; o simplemente ante las torpezas de algún usuario autorizado pero despistado. Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.
• Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper la información almacenada.
• Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.
• Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo más habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso concurrente a la información, que podría derivar en inconsistencias.
Componentes SGBD
Un SGBD debe permitir:
• Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
• Construir la base de datos: guardar los datos en algún medio controlado por el mismo SGBD
• Manipular la base de datos: realizar consultas, actualizarla, generar informes.
Las características de un Sistema Gestor de Base de Datos SGBD son:
• 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.
• Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición de información repetida o redundante. De entrada, lo ideal es lograr una redundancia nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la aparición de redundancias.
• Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, 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.
• 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 segurizada frente a usuarios malintencionados, que intenten leer información privilegiada; frente a ataques que deseen manipular o destruir la información; o simplemente ante las torpezas de algún usuario autorizado pero despistado. Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.
• Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper la información almacenada.
• Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.
• Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo más habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso concurrente a la información, que podría derivar en inconsistencias.
Componentes SGBD
- Lenguajes
- Lenguaje de definición de datos (DDL)
- Lenguaje de manipulación de datos (DML)
- Diccionario de datos: lugar donde se deposita información sobre todos los objetos que forman la base de datos (estructura lógica y física de los datos, definiciones de todos los objetos de la base de datos...)
Modelos de datos
- Uno de los objetivos más importantes de un SGBD es proporcionar a los usuarios una visión abstracta de los datos.
- Los modelos de datos son el instrumento ideal para ofrecer esa abstracción.
- Modelos lógicos basados en objetos
- Modelos lógicos basados en registros
Modelos lógicos basados en objetos
- Se usan para describir datos en el nivel conceptual y el externo
- Los más conocidos son:
- Modelo entidad-relación
- Modelo orientado a objetos
Modelos lógicos basados en registros
- Se usan para describir los datos en los modelos conceptual y físico.
- La BD está estructurada en registros de formato fijo de varios tipos
- Cada tipo de registro define un número fijo de campos o atributos, y cada normalmente es de longitud fija
PRODUCTOS SGBD DISPONIBLES EN EL MERCADO
SGBD libres
- PostgreSQL (http://www.postgresql.org Postgresql) Licencia BSD
- Firebird basada en la versión 6 de InterBase, Initial Developer's PUBLIC LICENSE Version 1.0.
- SQLite (http://www.sqlite.org SQLite) Licencia Dominio Público
- DB2 Express-C (http://www.ibm.com/software/data/db2/express/)
- Apache Derby (http://db.apache.org/derby/)
SGBD no libres
- MySQL: Licencia Dual, depende del uso. No se sabe hasta cuándo permanecerá así, ya que ha sido comprada por Oracle. Sin embargo, existen 2 versiones: una gratuita que sería equivalente a la edición "express" SQL server de Microsoft Windows, y otra más completa de pago.
- Advantage Database
- dBase
- FileMaker
- Fox Pro
- gsBase
- IBM DB2: Universal Database (DB2 UDB)
- IBM Informix
- Interbase de CodeGear, filial de Borland
- MAGIC
- Microsoft Access
- Microsoft SQL Server
- NexusDB
- Open Access
- Oracle
- Paradox
- PervasiveSQL
- Progress (DBMS)
- Sybase ASE
- Sybase ASA
- Sybase IQ
- WindowBase
- IBM IMS Base de Datos Jerárquica
- CA-IDMS
SGBD no libres y gratuitos
- Microsoft SQL Server Compact Edition Basica
- Sybase ASE Express Edition para Linux (edición gratuita para Linux)
- Oracle Express Edition 10
Suscribirse a:
Entradas (Atom)