GUIA DIDACTICA

Programa de Formación de Grado: Informática para la Gestión Social

Unidad Curricular: Bases de Datos
Trayecto:
Tramo:
Profesor: Ing. Juan Carlos Herrera Ríos

1.- Descripción de la Unidad Curricular:

Esta unidad curricular estudia el diseño y uso de sistemas de base de datos (sistemas
que manejan grandes cantidades de datos). Existen dos grandes enfoques para la
organización y recuperación (querying) de datos: el “modelo relacional” el cual utiliza una
tabla de dos dimensiones (relación) como su estructura primaria y “el modelo
semiestructurado” que utiliza árboles como estructura fundamental. El modelo relacional
es la base de la mayoría de los sistemas manejadores de base de datos en la actualidad.

El modelo semiestructurado es muy reciente, pero comienza a tener influencia

significativa, especialmente en la integración y compartimiento de datos sobre el Web.
Esta unidad curricular se centra en el estudio del diseño relacional usando el modelo
entidad-relación (E/R), seguido de una revisión exhaustiva del modelo relacional y
finalmente cómo convertir modelos E/R a relaciones y cómo utilizar sistemas manejadores
de bases de datos relacionales para crear bases de datos. El lenguaje estándar para
bases de datos SQL (Structured Query Language) será utilizado a lo largo del curso.
Aunque no es el objetivo estudiar implementaciones de sistemas manejadores de bases
de datos, el estudiante se familiarizará con los principales componentes y funcionalidades
de estos sistemas.

2.- Objetivo General:

Desarrollar en el estudiante habilidades necesarias para usar, diseñar, e implementar una
aplicación de base de datos, desde la etapa inicial del modelo conceptual, hasta su
implementación con un sistema manejador de base de datos relacional.

3.- Objetivos Específicos:

Definir Sistema Gestor de Base de Datos, Transacciones, Propiedades ACID.

Identificar los componentes de un Sistema de Gestión de Bases de Datos (DBMS).
Identificar los Tipos de Arquitecturas.
Administrar una Base de Datos (MySQL y/o POSTGRESQL)

4.- Actividades de Aprendizaje y Evaluación:

Tema I: El mundo de las bases de datos y los sistemas manejadores de base de

datos.

Contenidos:

1
1.1 Concepto de sistema de base de datos y sistema manejador de base de datos
(SMBD).

Evolución de los Sistemas Manejador de Base de Datos.

Evolución de la Base de Datos Relacional

En 1970, el Dr. I. B. Codd propuso el primer modelo de de datos relacional en un paper

titulado “A Relational Model of Data for Large Shared Data Banks”. Este paper es
recordado como la piedra angular en la Evolución de las base de datos modernas.

Evolución de Proyectos de Base de Datos Relacional

System R
IBM's System R fue desarrollado durante al última etapa de los años 70 para demostrar
que el modelo relacional puede trabajar. Se implementó las estructuras de datos del
modelo relacional y se realizaron operaciones sobre estas estructuras. Varias productos
comerciales de Sistemas de Gestión de Base de Datos Relacional (RDBMS) surgieron de
este proyecto.

INGRESS (Interactive Graphics Retrieval System)

El proyecto INGRES tuvo lugar en la Universidad de California al mismo tiempo en que
desarrollo el System R. Se desarrollo un prototipo de sistema de Gestión de base de
datos relacional (DBMS). Una académica versión de INGRES dio luz a una comercial
versión desde Relational Technology, Inc.

The Peter lee Relational Test Vehicle

Se desarrolló en 1976, fue mas teórico en su naturaleza que el System R y INGRES

projects. Importante información concerniente al procesamiento de consultas y la
optimización de la base de datos emergió de este proyecto.
Productos comerciales utilizando el modelo relacional aparece al final de los 70 y principio
de los 80. Hoy, varios cientos de diferentes tipos de RDBMSs existen tanto para sistemas
mainframe y desktop.

La investigación en la tecnología relacional continua hoy, con el desarrollo de base de

datos relacional orientada a objeto liderando el camino.

Sistemas de Base de Datos Relacionales.

Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos

interrelacionados y un conjunto de programas para acceder a dichos datos. La colección
de datos, normalmente se denomina base de datos, contiene información relevante para
una organización. El objetivo principal de un SGBD es proporcionar una forma de
almacenar y recuperar la información de una base de datos de manera que sea tanto
práctica como eficiente.

La gestión de los datos implica tanto la definición de estructuras para almacenar la

información como la provisión de mecanismos para la manipulación de la información.
Además, los sistemas de bases de datos deben proporcionar la fiabilidad de la
información almacenada, a pesar de las caídas del sistema o los intentos de acceso sin
autorización. Si los datos van a ser compartidos entre diversos usuarios, el sistema debe

2
evitar posibles resultados anómalos.

Dado que la información es tan importante en la mayoría de las organizaciones, los

científicos informáticos han desarrollado un amplio conjunto de conceptos y técnicas para
la gestión de los datos.

Sistemas de Bases de Datos frente a Sistemas de Archivos.

Este sistema de procesamientos de archivos típico que se acaba de describir se mantiene

mediante un sistema operativo convencional. Los registros permanentes son
almacenados en varios archivos y se escriben diferentes programas de aplicación para
extraer registros y para añadir registros a los archivos adecuados. Antes de la llegada de
los sistemas de gestión de bases de datos (SGBDs), las organizaciones normalmente han
almacenado la información usando tales sistemas.

Mantener información de la organización en un sistema de procesamiento de archivos

tiene una serie de inconvenientes importantes:

Redundancia e inconsistencia de datos.

Debido a que los archivos y programas de aplicación son creados por diferentes
programadores en un largo periodo de tiempo, los diversos archivos tienen
probablemente diferentes formatos y los programas puedan estar escritos en
diferentes lenguajes. Más aun, la misma información puede estar duplicada en
diferentes lugares (archivos). Además, puede conducir a inconsistencia de datos;
es decir, las diversas copias de los mismos datos pueden no coincidir.

Dificultad en el acceso a los datos.

Existe la posibilidad que la información solicitada no pueda ser satisfecha debido a

que cuando se diseño el sistema original no existe un programa de aplicación que
la satisfaga. Por los cual debe obtener la información que necesita manualmente o
pedir al departamento de procesamiento de datos que haga que un programador
de sistemas escriba el programa de aplicación necesario. La cuestión aquí es que
el entorno de procesamiento de archivos convencional no permite que los datos
necesarios sean obtenidos de una forma práctica y eficiente.

Aislamiento de datos.
Debido a que los datos están dispersos en varios archivos, y los archivos pueden
estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para
recuperar los datos apropiados.

Problemas de integridad.
Los valores de los datos almacenados en la base de datos deben satisfacer ciertos
tipos de restricciones de consistencia. Los desarrolladores hacen cumplir esas
restricciones en el sistema añadiendo el código apropiado en los diversos
programas. Sin embargo, cuando se añaden nuevas restricciones, es difícil cambiar
los programas para hacer que se cumplan. El problema es complicado cuando las
restricciones implican diferentes elementos de datos de diferentes archivos.

Problemas de atomicidad.
Un sistema de un computador, como cualquier otro dispositivo mecánico o
eléctrico, esta sujeto a fallo. En muchas aplicaciones es crucial asegurar que, una

3
 vez que un fallo ha ocurrido y se ha detectado, los datos se restauran al estado de
consistencia que existía antes del fallo.

Anomalías en el acceso concurrente.

Conforme se ha ido mejorando el conjunto de ejecución de los sistemas y ha sido
posible una respuesta en tiempo mas rápida, muchos sistemas han ido permitiendo
a múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un
entorno de interacción de actualizaciones concurrentes puede dar lugar a datos
inconsistentes. Sin embargo, ya que se puede acceder a los datos desde muchos
programas de aplicación diferentes que no han sido previamente coordinados, la
supervisión es difícil de proporcionar.

Problemas de seguridad.
No todos los usuarios de un sistema de bases de datos deberían poder acceder a
todos los datos. Como los programas de aplicación se añaden al sistema de una
forma ad hoc, es difícil garantizar tales restricciones de seguridad.

Estas dificultades, han motivado el desarrollo de los sistemas de bases de datos.

Visión de los datos:

Un sistema de bases de datos es una colección de archivos interrelacionados y un
conjunto de programas que permitan a los usuarios acceder y modificar estos archivos.
Uno de los propósitos principales de un sistema de bases de datos es proporcionar a los
usuarios una visión abstracta de los datos. Es decir, el sistema esconde ciertos detalles
de cómo se almacenan y mantienen los datos.

Abstracción de datos
Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación
ha conducido al diseño de de estructuras de datos complejas para la representación de
los datos en la base de datos. Como muchos usuarios de sistemas de base de datos no
están familiarizados con computadores, los desarrolladores esconden la complejidad a los
usuarios a través de varios niveles de abstracción para simplificar la interacción de los
usuarios con el sistema:

Nivel físico:
El nivel mas bajo de abstracción describe cómo se almacenan realmente los datos.
En el nivel físico se describen en detalle las estructuras de datos complejas de bajo
nivel.

Nivel lógico:
El siguiente nivel más alto de abstracción describe qué datos se almacenan en la
base de datos y qué relaciones existen entre esos datos. La base de datos
completa se describe así en términos de un número pequeño de estructuras
relativamente simples. Aunque la implementación de estructuras de nivel lógico
puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico
no necesitan preocuparse de esta complejidad. Los administradores de base de
datos, que deben decidir la información que se mantiene en la base de datos, usan
el nivel lógico de abstracción.

Nivel de vistas:
El nivel mas alto de abstracción describe solo parte de la base de datos completa.

4
 A pesar del uso de estructuras mas simples en el nivel lógico, queda algo de
complejidad, debido a la variedad de información almacenada en una gran base de
datos. Muchos usuarios del sistema de base de datos no necesitan toda esa
información. En su lugar, tales usuarios necesitan acceder solo a una parte de la
base de datos. Para que su interacción con el sistema sea mas sencilla, se define
la abstracción a nivel de vistas. El sistema puede proporcionar muchas vistas para
la misma base de datos. Además de esconder detalles del nivel lógico de la base
de datos, las vistas también proporcionan un mecanismo de seguridad para evitar
que los usuarios accedan a ciertas partes de la base de datos.

Arquitecturas Cliente–Servidor y Arquitecturas multi-capas.

Cliente - Servidor

La arquitectura cliente-servidor llamado modelo cliente-servidor o servidor-cliente es

una forma de dividir y especializar programas y equipos de cómputo a fin de que la tarea
que cada uno de ellos realizada se efectúe con la mayor eficiencia, y permita
simplificarlas.
En esta arquitectura la capacidad de proceso está repartida entre el servidor y los
clientes.

En la funcionalidad de un programa distribuido se pueden distinguir 3 capas o niveles:

1. Manejador de Base de Datos (Nivel de almacenamiento),
2. Procesador de aplicaciones o reglas del negocio (Nivel lógico) y
3. Interface del usuario (Nivel de presentación)

En una arquitectura monolítica no hay distribución; los tres niveles tienen lugar en el
mismo equipo.

En un comienzo, los mainframes concentraban la funcionalidad de almacenamiento y

lógica y a ellos se conectaban terminales tontas, posiblemente en sitios remotos.

En el modelo cliente-servidor, en cambio, el trabajo se reparte entre dos ordenadores. De

acuerdo con la distribución de la lógica de la aplicación hay dos posibilidades:

1. Cliente liviano (o cliente fino): si el cliente solo se hace cargo de la presentación.

2. Cliente pesado (o cliente grueso): si el cliente asume también la lógica del negocio.

En la actualidad se suele hablar de arquitectura de tres niveles, donde la capa de

almacenamiento y la de aplicación se ubican en (al menos) dos servidores diferentes,
conocidos como servidores de datos y servidores de aplicaciones.

Ventajas de la arquitectura cliente-servidor

 El servidor no necesita tanta potencia de procesamiento, parte del proceso se

reparte con los clientes.

 Se reduce el tráfico de red considerablemente. Idealmente, el cliente se conecta al

servidor cuando es estrictamente necesario, obtiene los datos que necesita y cierra
la conexión dejando la red libre para otra conexión.

5
1.2 Componentes de un DBMS.

Tres tipos comunes de Base de Datos

Base de Datos Relacional: una base de datos relacional almacena información en tablas
así que este puede ser accedido en un número de maneras diferentes.

Base de Datos de Archivos Planos: una base datos de archivos planos colecciona data
en archivos conteniendo líneas de textos.

Base de Datos Orientadas a Objetos: una base de datos orientada a objeto almacena
tipos de datos definidos en objetos de clases y subclases.

SQL
Los datos en una base de datos esta almacenada en un repositorio central. El sistema de
gestión de base de datos soporta un lenguaje de consulta que habilita a los usuarios a
manipular la data. El lenguaje de consulta para base de datos relacionales es llamado
Lenguaje de Consulta Estructurado (SQL). SQL esta dividido en subconjuntos de
lenguaje.

SQL ---> DDL

El lenguaje de definición de datos (DDL) es un subconjunto del SQL y permite a los
usuarios definir la data en una base de datos relacional. Los diseñadores pueden también
especificar los tipos de datos y restricciones sobre los datos en la base de datos.

Las Sentencias del lenguaje de definición de datos (DDL) que posee SQL operan en base
a tablas. Las Principales sentencias DDL son las siguientes:

 CREATE TABLE
 DROP TABLE
 ALTER TABLE
 CREATE INDEX
 DROP INDEX

SQL --> DML

Un DBMS permite a los usuarios trabajar con la data almacenada en una base de datos.
Esto incluye el acceso a los datos, actualización, inserción de nuevos datos, o eliminación
de datos. Un lenguaje de manipulación de datos (DML), el cual es u8n subconjunto de
SQL, es utilizado para manipular datos.

Características Típicas o funcionalidades de un Sistema de Gestión de Base de

Datos (DBMS)

● Sistema de Seguridad: provee mecanismos para proteger los datos de usuarios

no autorizados.

● Sistema de Preservación de la Integridad: provee mecanismos para la definición

del tipo de dato que puede ser mantenido en una tabla o compartido entre tablas.

● Sistema de Control de Concurrencia: provee mecanismos para manejar

6
 concurrentemente el acceso a los datos.

● Sistema de Recuperación: provee mecanismos para el respaldo y Recuperación

de la base de datos en la eventualidad de una falla en el software o hardware.

● Diccionario de Datos: es un conjunto de tablas creadas como resultado de las

operaciones de DDL que mantiene o guarda la metadata acerca de una base de
datos.

Un administrador de una base de datos gestiona todas las actividades relacionadas con el
mantenimiento y control de un ambiente de base de datos. ellos a menudo son
responsables del control de los derechos de acceso y permisos para ciertos tipos de datos
en la base de datos.

un mecanismo de vistas permite al administrador de la base de datos crear vistas de

datos particulares para cada subconjunto de usuarios de la base de datos. esto es útil
porque algunos usuarios pueden solamente estar autorizados o interesados en una
particular data para sus tareas. Además, el acceso a sensitiva o irrelevante data es
minimizado.

Ventajas del DBMS

Consistencia y Redundancia de los Datos:

un DBMS integra datos dentro de un repositorio central donde la repetición
innecesaria de los datos puede ser eliminada. el DBMS también asegura que todas
las instancias de los datos permanecen consistentes con otra. Esto elimina los
problemas de inconsistencia de los datos y la redundancia de los datos que son
comunes en los sistemas de archivos planos.

Compartición de los datos y incremento del acceso a los datos:

Un DBMS permite a los usuarios autorizados acceder a los datos almacenados en
un repositorio central de la base de datos.

Integridad de los datos: debido a que un DBMS provee mecanismos para la

definición del tipo de dato y las restricciones sobre esos datos, la validez de la data
es protegida. un DBMS asegura las restricciones mucho mas eficiente que un
sistema basado en archivos.

Seguridad de los datos

Con un DBMS, un administrador de base de datos puede definir medidas de
seguridad para proteger datos sensibles. Esto puede mejorar la eficiencia por
restringir a los usuarios la data apropiada. Específica data puede ser protegida con
password, y solamente específicos tipos de operaciones pueden ser permitidos
sobre ciertos tipos de datos.

Adherencia a estándares:
Con un DBMS, un método de acceso a datos estándar puede ser asegurado. El
uso del Lenguaje de Consulta Estructurado (SQL) es un ejemplo de un estándar
asegurado.

7
 Incremento de la productividad:
Un DBMS provee rutinas de manejo de datos de bajo nivel que usualmente se
necesitan para ser escritos dentro de un programa. Esto le permite a los
programadores concentrarse sobre la funcionalidad necesitada por los usuarios. En
un sistema de archivos planos, por el contrario, los programadores tendrán en
concentrarse en proveer funcionalidad de bajo nivel dentro de los programas que
accedan a los datos.

Manejo de la concurrencia:
Con muchos DBMS, mecanismos existen que permiten el acceso concurrente a los
datos.

Incremento del respaldo y Recuperación:

El respaldo y recuperación de una base de datos después de una falla de software
y hardware es la responsabilidad del usuario o desarrollador de programas en un
sistema de base de datos basada en archivos. Con DBMS, mecanismos
automáticos son proporcionados para estas importantes tareas.

Desventajas

Tamaño y Complejidad:
El diseñador de la base de datos y el administrador deben tener un sólido
conocimiento de la funcionalidad que un DBMS ofrece para realizar su completo
potencial. Una base de datos que modela las reglas de negocios de una
organización puede ser compleja, tanto para crearla como para mantenerla. Esto
puede resultar también en grandes cantidades de espacio en disco siendo utilizado.

Costos:
Un DBMS puede ser muy costoso debido a que se tiene que comprar software
adicional. Adicionalmente convertir la vieja data al nuevo formato del DBMS debe
ser considerado, junto con el tiempo y el costo del entrenamiento de los empleados
que usan el nuevo sistema.

DBMS Crash (bloqueo del sistema):

Cuando una DBMS colapsa, esto causa problemas mayores. Las implicaciones del
almacenaje de información centralizada son tales que si la fuente de datos cae,
todos los sistemas de acceso son afectados.

1.3 Administración de Bases de Datos.

Definición de Administración de Bases de Datos.

Los Sistemas Gestores de Bases de Datos son un tipo de software muy específico,
dedicado a servir de interfaz entre la Base de datos y el usuario, las aplicaciones que la
utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de
manipulación de datos y de un lenguaje de consulta. En los textos que tratan este tema, o
temas relacionados, se mencionan los términos SGBD y DBMS, siendo ambos
equivalentes, y acrónimos, respectivamente, de Sistema Gestor de Bases de Datos y
DataBase Management System, su expresión inglesa.

8
Tareas y funciones a realizar por un Administrador de Bases de Datos.

Fase de Análisis: Requerimientos y Alcance

Antes de que una base de datos sea creada, información acerca de la base de datos es
recolectada y los planes y objetivos de la organización son documentadas. Esto ayuda a
determinar las necesidades que la base de datos deberá reunir y el alcance de la
aplicación.

Una actividad común durante esta fase de planificación de la base de datos es la creación
de un modelo de datos corporativo. Un modelo de dato es utilizado para mostrar datos
importantes, relaciones de los datos, y como esos datos están asociados con una unidad
funcional clave a través de la organización. Un modelo de datos puede asemejarse a un
diagrama Entidad Relación (ER) simplificado.

Cuando se define el alcance de la aplicación de la base de datos, usted designa sus

fronteras y como esta puede hacer interface con otras partes de la infraestructura de la
organización. Esta actividad involucra la definición de los usuarios de la base de datos y
sus correspondientes aplicaciones.

Un documento de requerimientos de base de datos contiene las especificaciones de la

base de datos y la información acerca de las características requeridas de la base de
datos. El tipo de información que debe ser recolectada incluye alguna documentación que
puede ser requerida y los detalles pertinentes para todas las transacciones requeridas.

Información del Documento de Requerimientos

● Misión
Declara el propósito específico de la base de datos en términos amplios sin la
definición de las tareas específicas pertinentes a la implementación de la base de
datos.

● Requerimientos de datos

● Requerimientos de procesamiento de datos

● Objetivos
Requerido para el sistema de base de datos desde la perspectiva de los usuarios.

● Restricciones
Posibles restricciones, incluyendo requerimientos de velocidad y plataformas de
hardware.

● Descripción de la interfaz gráfica del usuario (GUI)

Describe los menús y sus componentes, si la GUI es centrada en menús.

● Descripciones de escenarios opcionales

Describe uno o mas transacciones de principio a fin involucrada en el sistema de
base de datos y su ambiente.

9
 ● Misceláneas
Incluye seguridad, confiabilidad, mantenibilidad, portabilidad, y extensibilidad, una
agenda preliminar y presupuesto.

● Glosario de términos
Típicamente, cada termino introducido en un glosario tiene una breve Descripción,
posibles sinónimos, y una referencia para otros términos contenidos en el glosario
con el cual aquí esta un enlace lógico.

Cuando se escriben requerimientos, es útil identificar homónimos y sinónimos, y

estandarizar términos. Sinónimos son términos que comparten el mismo significado.
Homónimos son términos que tienen múltiples significados.

Después que las ambigüedades han sido identificadas, ellas son removidas por
reemplazar los términos incorrectos con los más apropiados. si una decisión es difícil de
alcanzar correspondiente a un termino, el usuario quien provee la información debe ser
entrevistado nuevamente y aclararlo.

Las reglas de Codd

Reglas de Codd: Tablas

El sistema de gestión de base de datos relacional fue diseñado por el Dr. Edgar Codd y
desde entonces ha sido conocido como las reglas de Codd.

Codd comienza numerando las reglas desde cero en vez de uno.

Regla 1:
La regla de información, esta relacionada con las tablas.

Toda la información en una base de datos relacional esta representada explícitamente en

el nivel lógico y en exactamente una manera, por valores en tablas. La regla de
información establece que toda la data deberá ser almacenada en tablas.

Regla 2:
La segunda regla es la regla de acceso garantizado. esta establece que todos los datos
en una base de datos relacional esta garantizado para ser lógicamente accesible
recurriendo a una combinación de nombre de la tabla, valor de clave primaria, y nombre
de columna. la regla de acceso garantizado establece que usted deberá ser capaz de
localizar cada pieza de información, o entrada de dato, en una tabla de datos con solo el
nombre de la tabla, el nombre del campo, y el valor de la clave primaria.

La clave primaria es un valor asociado con una entrada de dato. Cuando este valor es
especificado, la asociada entrada de dato puede ser localizada. La clave primaria es una
parte esencial de la tabla. Cada tabla en una base de datos relacional debe tener una
clave primaria, y cada valor para la clave primaria debe tener un único identificador.

Regla 3:
La tercera regla cubre el tratamiento sistemático de los valores nulos. Esta regla establece
que los valores nulos son soportados completamente por los sistemas de gestión de base
de datos relacional (RDBMSs) para representar información faltante y información

10
inaplicable, independientemente del tipo de dato.

Los valores nulos son soportados en un RDBMS y son importantes debido a que ellos
representan la ausencia de información.

Las reglas de Codd establecen que los valores nulos no son permitidos en cada columna
clave primaria.

El sistema de gestión de base de datos relacional es definido por las reglas de Codd. Las
primeras tres reglas son relacionadas a tablas.

Reglas de Codd: Diccionario de Datos

Un diccionario de datos es también conocido como un catalogo del sistema. Este

mantiene una descripción de las relaciones en la base de datos, su estructura, los
vínculos (correspondencia) entre ellos, y las consultas (queries). Estos datos son a
menudo referidos como metadata.

Las Reglas 4, 10 y 12 se relacionas a un diccionario de datos.

Regla 4:
Establece que la descripción de la base de datos está representada al nivel lógico en la
misma forma como la data ordinaria así los usuarios autorizados pueden aplicar el mismo
lenguaje relacional para sus interrogaciones así como las aplicadas a los datos regulares.

La información en el diccionario de datos deberá ser mantenida en las mismas estructuras

como los datos en la misma base de datos.

Codd estable que los usuarios deben tener la posibilidad de tratar con los datos en el
diccionario de datos tan fácilmente como losa datos en la base de datos. esto significa
que un usuario podrá encontrar información en el diccionario de datos acerca de como
esta estructurada la base de datos. Esta información debe estar almacenada en
relaciones.

Regla 10:
Independencia de la integridad.
Esta establece que las restricciones de integridad específicas para un particular base de
datos relacional deben ser definida en un sublenguaje de datos relacional y almacenada
en el diccionario de datos, no en los programas de aplicación.

Reglas de integridad en RDBMS

● Integridad de entidad: establece que ningún componente de una clave primaria

tiene permitido tener un valor nulo.

● Integridad referencial: establece que para cada distinto valor de clave foránea no
nulo en una base de datos relacional, aquí debe tener su correspondiente valor
clave primaria del mismo dominio.

La regla 10 contiene una importante expansión. Esta establece que adicionalmente a las
dos reglas de integridad que aplican a todas las bases de datos relacionales, aquí hay

11
una necesidad clara de poder especificar restricciones adicionales de integridad reflejando
tanto las políticas del negocio como las políticas gubernamentales.

Las reglas de integridad son parte esencial de una base de datos relacional. Es mucho
mas fácil ya sea accidentalmente, o a propósito, derribar estas reglas si ellas están
almacenadas en una aplicación.

Regla 12:
Establece que si un sistema relacional tiene un lenguaje de bajo nivel, este bajo nivel no
puede ser utilizado para derribar o saltarse las reglas de integridad y restricciones
expresadas en las reglas de alto nivel, las cuales han sido aplicadas a las relaciones y
son almacenadas en el diccionario de datos.

Esta regla establece que no debe ser posible para un usuario utilizar un lenguaje de bajo
nivel para realizar cambios a registros individuales el cual derriba las reglas de integridad
de alto nivel. Cambios incluyen adiciones, eliminaciones y modificaciones a los registros.

Las reglas de Codd relacionadas al diccionario de datos establecen que todas las base de
datos deben tener un diccionario de datos y las reglas de integridad pueden ser
almacenadas en este diccionario. Además, el lenguaje utilizado para manipular la base de
datos no puede ser usado para derribar estas reglas de integridad.

Reglas de Codd: Actualización de Datos

Las reglas 5, 6 y 7, Codd muestra como los datos deben ser actualizados en una base de
datos.

Regla 5:
Establece que un sistema relacional puede soportar varios lenguajes y varios modos de
uso de terminal. Sin embargo, aquí debe estar al menos un lenguaje cuyas sentencias
son expresadas mediante alguna sintaxis bien definida.

Codd lista los ítems que deben ser soportados por un solo lenguaje. Los ítems son:

● Definición de datos

● Definición de vistas

● Manipulación de datos

● Restricciones de integridad

● Autorización

● Límites de la transacción

Esta regla básicamente establece que debe haber un único lenguaje que permite
manipular la base de datos. Aunque las bases de datos son generalmente manipuladas
mediante una interface gráfica de usuario (GUI), aquí se encuentra aún un lenguaje
subyacente.

12
Regla 6:
Establece que todas las vistas que son actualizables teóricamente son también
actualizables por el sistema. Una vista puede ser igual a la respuesta (answer) de una
consulta (query)

Codd establece que usted puede ser capaz de ver datos en una tabla y también ser capaz
de modificar estos datos. Sin embargo, Codd expande esta regla por lo cual usted solo
debe tener la posibilidad de modificar estos datos si los datos actualizados tienen sentido
de acuerdo a la estructura de la base de datos. No se puede modificar o actualizar los
datos porque este dato es derivado de un número diferente de registros de datos.

Regla 7:
Establece que la capacidad de manejar una relación base o una relación derivada como
un simple operando no solo para la recuperar los datos sino también para la inserción,
actualización, y borrado de los datos. Codd usa el término relación al referirse a una tabla.

Esta regla establece que usted tiene la capacidad de modificar o actualizar datos con un
simple comando. Se pueden eliminar registros individualmente, pero también debería ser
capaz de eliminar registros colectivamente por utilizar un simple comando. Esta regla es
importante debido a que se reduce la cantidad de código que se necesita escribir para
especificar la actualización.

Reglas de Codd: Independencia de datos

Regla 8:
Esta regla establece que los programas de aplicación permanecen intactos lógicamente
aun si algunos cambios son hechos en la representación de almacenamiento o en los
métodos de acceso. Esta regla establece que la interacción del usuario sebe estar
separada de la estructura física de la base de datos.

Regla 9:
Establece que los programas de aplicación permanecen lógicamente intactos aun si
cambios de preservación-información de algún tipo que teóricamente previene intacto
debilitación son hechas en las relaciones base.

Esta regla es cercanamente relacionada con la regla 8. Esta indica que la interacción
lógica debe estar separada de la estructura física de la base de datos.

la reglas de independencia lógica y física permiten que los gestores de base de datos
modifiquen la estructura subyacente sin trastornar la manera en que los usuarios trabajan
y sin el requerimiento de que los programas sean reescritos.

Regla 11:
Establece que un RDBMS tiene independencia de distribución. Codd expande esta regla
indicando que la interacción lógica debe permanecer intacta cuando la distribución de los
datos es primero introducida y también cuando los datos esta redistribuidos. Esta regla
aplica a las base de datos dentro de una red. Usuarios pueden estar distribuidos a través
de una red a, similarmente, datos pueden ser distribuidos a través de la misma red. Aun si
las relaciones son movidas alrededor d ellas, los usuarios no deben enterarse de el
cambio de la localización.

13
La ventaja de tener la interacción lógica separada de la distribución de los datos es que
los cambios pueden ser fácilmente hechos para la distribución de los datos.

Según las reglas de Codd 8, 9 y 11, la interacción lógica y del usuario deben estar
separadas de a estructura física de una base de datos.

1.4 Transacciones.

Gestión de transacciones

Varias operaciones sobre la base de datos forman a menudo una única unidad lógica de
trabajo.

Ejemplo: Transferencia de fondos de una cuenta A a una cuenta B.

Claramente es esencial que, o bien tanto el cargo como el abono tengan lugar, o bien no
ocurra ninguno.

Es decir, la transferencia de fondos debe ocurrir por completo o no ocurrir en absoluto.

Este requisito de todo o nada se denomina atomicidad. Además, es esencial que la
ejecución de la transferencia de fondos preserve la consistencia de la base de datos. Este
requisito de corrección se llama consistencia. Finalmente, tras la ejecución correcta de la
transferencia de fondos, los nuevos valores de las cuentas deben persistir, a pesar de la
posibilidad de fallo del sistema. Este requisito de persistencia se llama durabilidad.

Una transacción es una colección de operaciones que se lleva a cabo como una única
función lógica en una aplicación de bases de datos. Cada transacción es una unidad de
atomicidad y consistencia. Cada transacción es una unidad de atomicidad y consistencia.

Es responsabilidad del programador definir adecuadamente las diferentes transacciones,

de tal manera que cada una preserve la consistencia de la base de datos. Por ejemplo, la
transacción para transferir fondos de la cuenta A a la cuenta B se podría definir como
compuesta de dos programas separados: uno carga la cuenta A y otro que abona la
cuenta B. La ejecución de estos dos programas uno después del otro preservara
realmente la consistencia. Sin embargo, cada programa en si mismo no transforma la
base de datos de un estado consistente en otro nuevo estado consistente. Así, estos
programas no son transacciones.

Asegurar las propiedades de atomicidad y durabilidad es responsabilidad del propio

sistema de bases de datos, específicamente del componente de gestión de
transacciones. En ausencia de fallos, toda transacción completada con éxito y atómica
se archiva fácilmente. Sin embargo, debido a diversos tipos de fallos, una transacción
puede no siempre completar su ejecución con éxito. Si se asegura la propiedad de
atomicidad, una transacción que falle no debe tener efecto en el estado de la base de
datos. Así, la base de datos se restaura al estado en que estaba antes de que la
transacción en cuestión comenzara su ejecución. El sistema de bases de datos debe
realizar la recuperación de fallos, es decir, detectar los fallos del sistema y restaurar la
base de datos al estado que existía antes de que ocurriera el fallo.

Finalmente, cuando varias transacciones actualizan la base de datos concurrentemente,

14
la consistencia de los datos puede no ser preservada, incluso aunque cada transacción
individualmente sea correcta. Es responsabilidad del gestor de control de concurrencia
controlar la interacción entre las transacciones concurrentes para asegurar la consistencia
de la base de datos.

Los sistemas de bases de datos diseñados para uso sobre pequeñas computadoras
personales pueden no tener todas las características vistas.

Propiedades ACID.

En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability:

Durabilidad, Aislamiento, Consistencia e Indivisibilidad en español.

 Atomicidad (Indivisible) es la propiedad que asegura que la operación se ha

realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.

 Consistencia es la propiedad que asegura que sólo se empieza aquello que se

puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper
la reglas y directrices de integridad de la base de datos.

 Aislamiento es la propiedad que asegura que una operación no puede afectar a

otras. Esto asegura que dos transacciones sobre la misma información nunca
generará ningún tipo de error.

 Durabilidad es la propiedad que asegura que una vez realizada la operación, ésta
persistirá y no se podrá deshacer aunque falle el sistema.

15
Actividades:

 Individuales:
Especificar sentencias SQL que permitan la realización de consultas, inserción,
modificación y eliminación de registros en una base de datos.
 Grupales:
Diseño de una Base de Datos para un Sistema de Información
 Comunitarias:

Actividades de auto evaluación

Glosario de términos.

ACID:
En el contexto de bases de datos se denomina ACID a la propiedad de una base de datos
para realizar transacciones seguras. Así pues ACID compliant define a un sistema de
gestión de bases de datos que puede realizar transacciones seguras.

AD HOC:
El término también se utiliza en la informática para referirse a consultas en bases de datos
"ad hoc querying" o "ad hoc reporting", esto implica que el sistema permite al usuario
personalizar una consulta en tiempo real, en vez de estar atado a los queries
prediseñados para reportes.

RDBMS
Sistema de Gestión de Bases de Datos Relacional.

DBMS
Sistema de Gestión de Base de Datos

Tabla:
Relación de datos

Tupla:
Registro de una tabla

SQL:
Lenguaje de Consulta Estructurado

Bibliografía básica y complementaria:

FUNDAMENTOS DE BASES DE DATOS, cuarta edición, Silberschatz, Korth, Sudarshan,

2002, McGRAW-HILL.

Curso de Thomson NETg CIW Database Specialist Part - Introducción al Diseño de Base
de Datos. www.CIWcertified.com

Wikipedia
http://es.wikipedia.org

16