Base de datos relacional

Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros
(líneas) y campos (columnas), que se vinculan entre sí por un campo en común, en ambos casos
posee las mismas características como por ejemplo el nombre de campo, tipo y longitud; a este
campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de
datos se le denomina modelo relacional.

Estrictamente hablando el término se refiere a una colección específica de datos pero a menudo se
le usa, en forma errónea como sinónimo del software usado para gestionar esa colección de datos.
Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del
inglés relational database management system).

Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización de
una base de datos, el cual es entendido como el proceso necesario para que una base de datos
sea utilizada de manera óptima.

Entre las ventajas de este modelo están:

1. Garantiza herramientas para evitar la duplicidad de registros, a través de campos claves o

llaves.
2. Garantiza la integridad referencial: Así al eliminar un registro elimina todos los registros
relacionados dependientes.
3. Favorece la normalización por ser más comprensible y aplicable.

Ejemplo base de datos relacional

Una
base
de
datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo
más utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten
establecer interconexiones (relaciones) entre los datos (que están guardados en tablas), y a través
de dichas conexiones relacionar los datos de ambas tablas, de ahí proviene su nombre: "Modelo
Relacional". Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios
IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos
de base de datos.[1]

Características

 Una base de datos relacional se compone de varias tablas o relaciones.

 No pueden existir dos tablas con el mismo nombre.
 Cada tabla es a su vez un conjunto de registros (filas y columnas).
 La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves
primarias y ajenas (o foráneas).
 Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben
cumplir con la integridad de datos.
 Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave
primaria del registro padre; por medio de éstas se hacen las relaciones.

Elementos

 Relaciones base y derivadas

En una base de datos relacional, todos los datos se almacenan y se accede a ellos por medio de
relaciones. Las relaciones que almacenan datos son llamadas "relaciones base" y su
implementación es llamada "tabla". Otras relaciones no almacenan datos, pero son calculadas al
aplicar operaciones relacionales. Estas relaciones son llamadas "relaciones derivadas" y su
implementación es llamada "vista" o "consulta". Las relaciones derivadas son convenientes ya que
expresan información de varias relaciones actuando como si fuera una sola.

 Restricciones

Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base de
datos. Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el
simple hecho de que la base de datos sea relacional. Algunas otras restricciones las puede definir
el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.

Las restricciones proveen un método de implementar reglas en la base de datos. Las restricciones
restringen los datos que pueden ser almacenados en las tablas. Usualmente se definen usando
expresiones que dan como resultado un valor booleano, indicando si los datos satisfacen la
restricción o no.

Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el rol
de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos
relacionales.

 Dominios

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio
restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente,
atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser
elementos del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha, no procedurales etc.
  Clave única

Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada registro
de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores en dichos
campos sean idénticos. Este conjunto de campos se llama clave única.

Pueden existir varias claves únicas en una determinada tabla, y a cada una de éstas suele
llamársele candidata a clave primaria.

 Clave primaria

Una clave primaria es una clave única elegida entre todas las candidatas que define unívocamente
a todos los demás atributos de la tabla, para especificar los datos que serán relacionados con las
demás tablas. La forma de hacer esto es por medio de claves foráneas.

Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave puede contener
valores NULL.

 Clave foránea

Una clave foránea es una referencia a una clave en otra tabla. Las claves foráneas no necesitan
ser claves únicas en la tabla donde están y sí a donde están referenciadas.

Por ejemplo, el código de departamento puede ser una clave foránea en la tabla de empleados,
obviamente se permite que haya varios empleados en un mismo departamento, pero existirá sólo
un departamento.

 Clave índice

Las claves índices surgen con la necesidad de tener un acceso más rápido a los datos. Los índices
pueden ser creados con cualquier combinación de campos de una tabla. Las consultas que filtran
registros por medio de estos campos, pueden encontrar los registros de forma no secuencial
usando la clave índice.

Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de ellas es
óptima para cierta distribución de datos y tamaño de la relación.

Los índices generalmente no se consideran parte de la base de datos, pues son un detalle
agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de
programadores que las otras partes de la base de datos.

Procedimientos almacenados

Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la base de

datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones
comunes, como insertar un registro dentro de una tabla, recopilar información estadística, o
encapsular cálculos complejos. Son frecuentemente usados por un API por seguridad o
simplicidad.

Los procedimientos almacenados no son parte del modelo relacional, pero todas las
implementaciones comerciales los incluyen.
Estructura

La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia).

El esquema es la definición de la estructura de la base de datos y principalmente almacena los

siguientes datos:

 El nombre de cada tabla

 El nombre de cada columna
 El tipo de dato de cada columna
 La tabla a la que pertenece cada columna

Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización, el
resultado de dicho proceso es un esquema que permite que la base de datos sea usada de manera
óptima.

Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si, el

contenido de todos los registros.

Manipulación de la información

Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos
lenguajes formales el álgebra relacional y el cálculo relacional. El álgebra relacional permite
describir la forma de realizar una consulta, en cambio, el cálculo relacional sólo indica lo que se
desea devolver.

El lenguaje más común para construir las consultas a bases de datos relacionales es SQL
(Structured Query Language), un estándar implementado por los principales motores o sistemas de
gestión de bases de datos relacionales.

En el modelo relacional los atributos deben estar explícitamente relacionados a un nombre en

todas las operaciones, en cambio, el estándar SQL permite usar columnas sin nombre en
conjuntos de resultados, como el asterisco taquigráfico (*) como notación de consultas.

Al contrario del modelo relacional, el estándar SQL requiere que las columnas tengan un orden
definido, lo cual es fácil de implementar en una computadora, ya que la memoria es lineal.

Es de notar, sin embargo, que en SQL el orden de las columnas y los registros devueltos en cierto
conjunto de resultado nunca está garantizado, a no ser que explícitamente sea especificado por el
usuario.

Manejadores de base de datos relacionales

Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este software
se conoce como SGBD (Sistema de Gestión de Base de Datos relacional) o RDBMS (del inglés
Relational Database Management System).

Entre los gestores o manejadores actuales más populares encontramos: MySQL, PostgreSQL,
Oracle, DB2,INFORMIX, Interbase, FireBird, Sybase y Microsoft SQL Server.

Ventajas y desventajas Modelo relacional

Ventajas

 Provee herramientas que garantizan evitar la duplicidad de registros.

 Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros
relacionados dependientes.
 Favorece la normalización por ser más comprensible y aplicable.

Desventajas

 Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información

geográfica.
 No se manipulan de forma manejable los bloques de texto como tipo de dato.

Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de satisfacer las
necesidades de las aplicaciones anteriores y así, complementar pero no sustituir a las bases de
datos relacionales.

Diseño de las bases de datos relacionales

El primer paso para crear una base de datos, es planificar el tipo de información que se quiere
almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la
información que necesitamos.

La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la

gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción
de cada uno de los campos que componen el registro y los valores o datos que contendrá cada
uno de esos campos.

Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido,
domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del
campo, etc.

Los registros constituyen la información que va contenida en los campos de la tabla, por ejemplo: el
nombre del paciente, el apellido del paciente y la dirección de este. Generalmente los diferente
tipos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numérico
(números), Fecha / Hora, Lógico (informaciones lógicas si/no, verdadero/falso, etc.), imágenes.

En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es determinar
claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su
tipo y su longitud.

Modelo entidad relación

El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de

bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado
por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de
representaciones
Un modelo conceptual es un conjunto de conceptos que permiten describir la realidad mediante
representaciones lingüísticas y gráficas. Los modelos conceptuales deben poseer una serie de
propiedades: expresividad, simplicidad, minimalidad y formalidad.

El modelo entidad-relación, posee los siguientes conceptos: entidades, relaciones, atributos,

dominios de atributos, identificadores y jerarquías de generalización.

Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa
englobando la relación abstraída y las entidades que participan en ella en un rectángulo.

Objetivos

 Independencia física. La forma de almacenar los datos, no debe influir en su manipulación

lógica. Si el almacenamiento físico cambia, los usuarios no tienen ni siquiera porqué
enterarse, seguirán funcionando sus aplicaciones.

 Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser
modificadas por que se modifiquen elementos de la base de datos. Es decir, añadir, borrar
y suprimir datos, no influye en las vistas de los usuarios.

 Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y
aplicaciones.

 Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las
tablas).

 Sencillez.

Características

 Refleja tan sólo la existencia de los datos, no lo que se hace con ellos.
 Es independiente del sistema operativo y del DBMS que se emplee.
 Es independiente de las restricciones de almacenamiento y de tiempo de ejecución.

Entidad

Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda almacenar
información en la base de datos. Es decir, cualquier elemento informativo que tenga importancia
para una base de datos.

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto
abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños
de productos, conciertos, excursiones, etc.

Ejemplos de entidades son Pedro, la factura número 32456, el coche matrícula BBJ-OOJ. Una
entidad no es una propiedad concreta sino un objeto que puede poseer múltiples propiedades
(atributos). Es decir "Sánchez" es el contenido del atributo Primer Apellido de la entidad que
representa a la persona Pedro Sánchez Crespo con C.l. 12.345.678
Una entidad es un objeto concreto, no un simple dato: el carro que tenemos en el
estacionamiento es una entidad, "Hyundai" sin embargo es la marca de ese carro, es decir, es un
atributo de esa entidad.

Conjunto de Entidades: Las entidades que poseen las mismas propiedades forman
conjuntos de entidades. Ejemplos de conjuntos de entidades son los conjuntos: personas, facturas,
coches.

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como conjunto de

entidades. De este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona en
concreto sería una ocurrencia o un ejemplar de la entidad persona. Esa terminología es la que de
ahora en adelante vamos a utilizar en la representación gráfica de las entidades.

 Todas las entidades de un conjunto tiene los mismos Atributos.

 Cada conjunto de entidades tiene una clave principal.
 Cada atributo tiene un dominio.

En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro
del cual se escribe el nombre de la entidad

Tipos de Entidades:

 Fuertes o regulares. Son las entidades normales que tienen existencia por sí mismas sin
depender de otras. Su representación gráfica es la siguiente.

PERSONA

 Débiles. Su existencia depende de otras. Por ejemplo la entidad tarea laboral sólo podrá
tener existencia si existe la entidad trabajo. Las entidades débiles se presentan de la
siguiente forma:

TAREAS
Relación LABORALES

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre
que describe su función. Las relaciones se representan gráficamente mediante rombos y su
nombre aparece en el interior.

Por ejemplo, en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se
realizan ya que las personas trabajan y los trabajos son realizados por personas:
La representación gráfica de las entidades se realiza con un rombo al que se le unen líneas que se
dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo
anterior podría usarse como nombre de relación, trabajar:

Una relación también puede tener atributos de relación, o descriptivos, los cuales representan
PERSONAS
características propias de la asociación entre varias entidades. TRABAJOS

Ejemplos de relaciones son las siguientes:

Relación Binaria

Relación Ternaria
 Relación Doble

Relación Reflexiva

 Relaciones Binarías. Son las relaciones típicas. Se trata de relaciones que

asocian dos entidades.

 Relaciones Ternarias. Relacionan tres entidades. Muchas veces se pueden simplificar en

relaciones binarias, pero no siempre es posible (se tratará en lo posible de no modelarlas
de esta manera, ya que se encuentra en desuso).

 Relaciones n-arias. Relacionan n entidades. Igual que en la anterior, ya se

encuentra en desuso.

 Relaciones Dobles. Se llaman así a dos relaciones distintas que sirven para relacionar a las
mismas relaciones. Son las más difíciles de manejar ya que al manipular las entidades hay
que elegir muy bien la relación a utilizar para relacionar los datos (enredado ¿no?).
 Relación Reflexiva. Es una relación que sirve para relacionar ejemplares de la misma
entidad (personas con personas, piezas con piezas, etc.)

La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el
número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha
entidad.

Indica el número de relaciones en las que una entidad puede aparecer, expresa el número máximo
de entidades de un conjunto que se relaciona con una entidad de otro conjunto y viceversa. Se
denota en términos de:

 Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá cada
ejemplar de la entidad (el valor que se anota es de cero o uno, aunque tenga una
cardinalidad mínima de más de uno, se indica sólo un uno).
 Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer
cada ejemplar de la entidad. Puede ser uno, otro valor concreto mayor que uno (tres por
ejemplo) o muchos (se representa con n).

En los esquemas entidad/relación la cardinalidad se puede indicar de muchas formas. Quizá la

más completa consiste en anotar en los extremos la cardinalidad máxima y mínima de cada
entidad en la relación. Ejemplo:
 1,0
Jugador Jugar Equipo
0,1

1:N

En el ejemplo un jugador tiene una cardinalidad mínima de 0 (puede no estar en ningún equipo) y
una máxima de 1 (como mucho está en un equipo, no puede estar en dos equipos a la vez).

Cada equipo tiene una cardinalidad mínima de uno (en realidad sería una cardinalidad mínima más
alta, pero se anota un uno), y una máxima de n (en cada equipo hay muchos jugadores).

También es muy frecuente, y la más usada, indicar la cardinalidad referida a la relación mediante
los símbolos: 1 y N. Indicando que la cardinalidad de la relación es:

 1:1 -> uno a uno: Una entidad del primer conjunto sólo puede relacionarse con una
entidad del segundo conjunto y viceversa.

 1:N -> uno a muchos: Una entidad del primer conjunto puede relacionarse con varias del
segundo, pero una entidad del segundo conjunto sólo puede relacionarse con una entidad
del primero.

 N:N -> muchos a muchos: Una entidad del primer conjunto puede relacionarse con varias
entidades del segundo y viceversa.

En nuestro ejemplo la cardinalidad es 1:N porque un Equipo puede estar formado por muchos
Jugadores.

Otras notaciones para las cardinalidades serian las siguientes:

Muchos Uno

De cero a De uno a muchos

muchos

De cero a uno
Un ejemplo de este tipo seria el siguiente:

JUEGA JUGADOR
JUGADOR

ENTRENA

JUGADOR

En el ejemplo, la interpretación sería que cada equipo cuenta con varios jugadores. Un jugador
juega como mucho en un equipo y podría no jugar en ninguno. Cada entrenador entrena a un
equipo (podría no entrenar a ninguno), el cual tiene un solo entrenador como mucho y como poco.

Atributo

Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos
representan las propiedades básicas de las entidades y de las relaciones. Toda la información
extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan
de las entidades o relaciones a las que pertenecen.

Un ejemplo de esto sería lo siguiente:

Tipos de Atributos:
Aparte de los atributos "normales" de los que ya hablamos en el ítem anterior, podemos encontrar
otros dos tipos adicionales a este, que son:
 Atributos simples o atómicos. Son atributos no divisibles (normales).

Teléfono

 Compuesto. Es cuando un atributo está formado a su vez por subatributos, o sea, que se
pueden dividir en sus componentes, pudiendo formar jerarquías.
Día

Fecha Mes
 Años

Identificador

Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único
cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones:

1.      No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.

2.      Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.

Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las
relaciones no tienen identificadores.

Identificador o Clave: Se trata de uno o más campos cuyos valores son únicos en cada ejemplar
de una entidad. Se indican subrayando el nombre del identificador. Para que un atributo sea
considerado un buen identificador tiene que cumplir con lo siguiente:

 Deben distinguir a cada ejemplar teniendo en cuenta las entidades que utiliza el modelo.
No tiene que ser un identificador absoluto.
 Todos los ejemplares de una entidad deben tener el mismo identificador.
 Cuando un atributo es importante aun cuando no tenga una entidad concreta
asociada, entonces se trata de una entidad y no de un atributo.

Identificador Alternativo: Se trata de uno o más campos cuyos valores son únicos para cada
ejemplar de una entidad, pero que no son identificadores ya que existen identificadores mejores
en la entidad. En este caso, los candidatos es aconsejable marcarlos con un subrayado
discontinuo.

Ventajas del modelo E-R:

 Diseño de alto nivel: Expresa con bastante precisión el esquema conceptual.

 Los diagramas de E-R permiten mantener una visión global del diseño y favorece la
comunicación entre los diseñadores.

Desventajas del modelo E-R:

Carece de un soporte formal y los SGBD no suelen implementarlo directamente. Normalmente hay
que transformarlo en un modelo de más bajo nivel.

TERMINOLOGÍA DEL MODELO RELACIONAL

DOMINIOS:

Un dominio contiene todos los posibles valores que puede tomar un determinado atributo. Dos
atributos distintos pueden tener el mismo dominio.

Para indicar el contenido del dominio, se utiliza dos técnicas:

  Intensión: Se define indicado la definición exacta de sus posibles valores. Ejemplo, edades
de los trabajadores como números enteros entre el 16 y el 65.

 Extensión: Se indican algunos valores y se sobreentiende el resto debido a que se

autodefinen con las anteriores. Ejemplo, Puerto la Cruz, Barcelona, entre otros.

Ejemplos de Dominios:

Números_telefónicos_locales: El conjunto de números telefónicos de siete dígitos validos dentro de

un código de área en particular.

Números_de_seguro_social: El conjunto de números de seguro social válidos formados por nueve

dígitos.

Nombres: El conjunto de nombre de personas.

Departamentos_académicos: El conjunto de Departamentos Académicos de una Universidad.

RELACIÓN O TABLA:

En el Modelo Relacional, las relaciones se utilizan para almacenar información sobre los objetos
que se representan en la base de datos. Una relación se representa gráficamente como una tabla
bidimensional en la que las filas corresponden a registros individuales y las columnas
corresponden a los campos o atributos de esos registros.

Las relaciones constan de:

 Atributo: Es el nombre de una columna de una relación.

 Tuplas: Representa cada una de las filas de la tabla.

GRADO DE UNA RELACIÓN:

Es el número de atributos que contiene la tabla. Cuanto mayor es el grado de una relación, mayor
es su complejidad al manejarla.
CARDINALIDAD:
Es el número de tuplas de una relación.

Ejemplo de una relación:

Estudiante

Nombre Tlf. Dirección Cel. Edad

Carlos Cortés 489-22- C/ Libertad 265 749-6492 28
1100
Bárbara Benet 839-8461 C/ Fontana 738 749-1253 20
María Castillo 373-1865 C/Balboa 2918 749-5863 24

La relación Estudiante tiene tres filas o tuplas.

Es de grado cuatro porque tiene cuatro atributos.

CARACTERÍSTICAS DE UNA BASE DE DATOS RELACIONAL

 No puede haber dos tuplas con valores iguales.

 Cada atributo se representa por su nombre.

  Cada tabla es a su vez un conjunto de registros: filas y columnas.

 Los registros poseen un campo identificador único llamada clave primaria.

 Las claves primarias son la clave principal de un registro de una tabla.

 Las tuplas de una relación no tienen un orden específico.

 Las entradas en la tabla tienen un solo valor, son atómicos; no se admiten valores
múltiples.

 La información en las bases de datos son representados como datos explícitos, no existen
apuntadores o ligas entre las tablas.

CUALIDADES DE UN BUEN DISEÑO DE BASE DE DATOS RELACIONAL

 Reflejar la estructura del problema en el mundo real.

 Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.

 Evitar el almacenamiento de información redundante.

 Proporcionar un acceso eficaz a los datos.

 Mantener la integridad de los datos a lo largo del tiempo.

 Ser claro, coherente y de fácil comprensión.

VENTAJAS Y DESVENTAJAS DE UNA BASE DE DATOS RELACIONAL

VENTAJAS:

 Reduce la duplicación en el ingreso de datos.

 Búsquedas más rápidas.

 Puede crear formularios e informes que muestren sólo los datos que se quieren ver.

 Puede crear cuestionarios para contestar preguntas que son difíciles e imposibles de ser
contestadas en las bases de datos más simples.

DESVENTAJAS:

 Pueden ser de instalación compleja, usando muchas tablas.

 Es más difícil entender como se relaciona cada parte con la otra.

ELEMENTOS DE LA RELACIÓN

Una relación está formada por los siguientes elementos:

 Nombre: Identifica la relación.

  Cabecera de relación: Conjunto de todos los pares atributo- dominio de la relación.

 Cuerpo de la relación: Representa el conjunto de m tuplas {t1, t2, tn} que forman la
relación.

 Esquema de la relación: Se forma con el nombre R y la cabecera.

 Estado de la relación: Lo forman el esquema y el cuerpo.

Ejemplo:

Cliente

DNI
NOMBRE EDAD

1233344C
MARÍA 50

12374678G
DANIEL 25

28238232H
KARLA 30

Nombre: Cliente
Esquema: Cliente (DNI: DNI, NOMBRE: NOMBRE, EDAD: EDAD)
Cuerpo: {( DNI:” 1233344C”, NOMBRE:” MARÍA”, EDAD: 50);
( DNI:” 12374678G”, NOMBRE:” DANIEL”, EDAD: 25);
( DNI:” 28238232H”, NOMBRE:” KARLA”, EDAD: 30)}

TABLAS O RELACIONES

Las tablas o relaciones están constituidas por una o más tablas que contiene la información
ordenada de una forma organizada. Cumplen las siguientes reglas básicas:

 Generalmente, contendrán muchas tablas.

 Una tabla sólo contiene un número fijo de campos.
 El nombre de los campos de una tabla es distinto.
 Cada registro de la tabla es único.
 El orden de los registros y de los campos no está determinado.
 Para cada campo existe un conjunto de valores posibles.

Tipos de tablas:

Permanentes: Sólo pueden ser eliminadas por los usuarios.

  Base: Se crean indicando su estructura y sus ejemplares.

 Vistas: Son tablas que sólo almacenan información de consulta. Sí los datos de las tablas
base cambian, los de vista que utiliza esos datos también cambian.

 Sólo modifican su resultado (actualiza los datos), siendo refrescadas por el sistema cada
cierto tiempo.

Temporales: Son tablas que se eliminan automáticamente por el sistema.

BASES DE DATOS RELACIONALES EN ACCESS

Microsoft Access es un sistema gestor de bases de datos relacionales (SGBD), creado y

modificado por Microsoft para uso personal en pequeñas organizaciones.

Posiblemente, la aplicación más compleja de la suite Office, sea Access, una base de datos
visual. Como todas las modernas bases de datos que trabajan en el entorno Windows, puede
manejarse ejecutando unos cuantos clics de mouse sobre la pantalla. Access contiene
herramientas de diseño y programación reservadas a los usuarios con mayor experiencia, aunque
incluye bases de datos listas para ser usadas; están preparadas para tareas muy comunes, que
cualquiera puede realizar en un momento determinado –ordenar libros, archivar documentación,
etc.

Este programa permite manipular datos en forma de tablas, realizar cálculos complejos con
fórmulas y funciones, incluso dibujar distintos tipos de gráficas.

Hay tres conceptos claves dentro de las tablas: campo, registro y dato.

 Campo: Son los distintos tipos de datos que componen la tabla, por ejemplo: nombre,
apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de
campo, el ancho del campo, etc.

 Registro: Constituyen la información que va contenida en los campos de la tabla, por

ejemplo: el nombre del paciente, el apellido del paciente y la dirección de éste.

 Dato: Es la intersección entre un campo y un registro

Elementos de Access:

 Tablas: Las tablas contienen datos sobre algo o alguien, proveedores, clientes, libros en
una biblioteca, compras, ventas, etc.

 Consultas: Las consultas se utilizan para localizar y depurar los datos en particular que
cumplen unas determinadas condiciones especificadas por el usuario. Las consultas
permiten realizar operaciones de muy diversa índole relacionadas con los datos contenidos
en la tabla. Por ejemplo, a partir de una tabla que contenga los registros de notas de
ciertos alumnos, mediante una consulta se puede depurar la tabla y saber la cantidad de
aprobados y reprobados.

 Formularios: Los formularios son otra herramienta de Access que permite visualizar,
introducir y modificar los datos de las tablas de una manera muy sencilla e interactiva que
hace más ameno el trabajo al usuario. Al abrir un formulario, Access recupera en él los
datos de una o varias tablas y les muestra en un diseño de ficha creado, bien de forma
 automática por el Asistente para Formularios, o manualmente por el usuario. Al mostrar los
datos, el usuario puede desplazarse en la tabla visualizando toda la información y
realizando operaciones sobre los registros.

 Informes: Los Informes se utilizan primordialmente para presentar, resumir e imprimir los
datos de la forma que resulte más apropiada para cada proyecto. Permite realizar
impresiones personalizadas así también como etiquetas. Se pueden crear informes que
incorporen cálculos basados en los datos de las tablas para mostrar resultados totales o
promedios o bien para generar catálogos.

 Macro: es una lista de tareas que Access lleva a cabo automáticamente.

 Módulos: Son objetos donde se almacena código escrito en lenguaje de programación

denominado Access Basic.

Ejemplo:

Elementos de Access

CLAVES

Clave candidata: Conjunto de atributos que identifica unívocamente cada tupla de la relación de la
relación. Es decir, columnas cuyos valores no se repiten en ninguna otra tupla de esa tabla.

Clave primaria: Clave candidata que se escoge como identificador de las tuplas. Se elige como
primaria la candidata que identifique mejor a cada tupla en el concepto de la base de datos. Por
ejemplo, un campo con el DNI sería clave candidata de una tabla de clientes, si esa relación tiene
un campo de código cliente éste sería mejor candidato y por lo tanto clave principal porque es
mejor identificador para ese contexto.

Clave alternativa: Cualquier clave candidata que no sea primaria.

Clave externa, ajena o secundaria: Son los datos de atributos de una tabla cuyos valores están
relacionados con atributos de otra tabla.
Por ejemplo, en la Tabla Equipos se tienen los siguientes datos.

Equipo No. Equipo

Real Madrid 1
F.C. Barcelona 2
Athletic Bilbao 3

En la tabla anterior, la clave principal es el atributo No. Equipo. En esta tabla, se tiene los
siguientes datos:
No. Jugador Jugador No. Equipo
1 karanka 1
2 Ronaldinho 2
3 Raúl 1
4 Beckam 1

El atributo No. Equipo sirve para relacionar el jugador con el equipo al que pertenece. Ese campo
en la tabla de jugadores es una clase externa.
NULOS
Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el
valor cero ni la cadena vacía, éstos son valores que tienen significado. El nulo implica ausencia de
información, bien porque al insertar la tupla se desconocía el valor del atributo, o bien porque para
dicha tupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas
de implementación. De hecho, no todos los SGBD relacionales los soportan.

En los lenguajes de programación se utiliza el valor nulo para reflejar que un identificador no
tiene ningún contenido. Al programar en esos lenguajes, se trata de un valor que no permita
utilizarse en operaciones aritméticas o lógicas.

En las bases de datos relacionales se utiliza con más posibilidades, aunque su significado no
cambia: valor vacío, se utiliza para diversos fines. En claves secundarias indican que el registro
actual no está relacionado con ninguno. En otros atributos indica que no se puede rellenar ese
valor por la razón que sea. Es importante indicar que el texto vacío “, no es lo mismo que el nulo;
como tampoco el valor cero significa nulo. *

Puesto que ese valor se utiliza continuamente, resulta imprescindible saber cómo actúa
cuando se emplea operaciones lógicas sobre ese valor. Eso significa definir un tercer valor e la
lógica booleana, además de los clásicos verdadero y falso. Un valor nulo no es ni verdadero ni
falso; se suele interpretar como un quizás. Se utiliza un operador en todas las bases relacionales
llamado is null que devuelve verdadero si el valor con el que se compara es nulo. El uso de
operadores lógicos con el nulo da lugar a que:
 Verdadero Y (AND) nulo da como resultado, nulo.
 Falso Y (AND) nulo da como resultado, falso.
 Verdadero O (OR) nulo da como resultado, verdadero.
 Falso O nulo da como resultado, nulo.
RESTRICCIONES

Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en los datos de
la base de datos, provee un método de implementar reglas y restringen los datos que pueden ser
almacenados en las tablas. Usualmente, se definen usando expresiones que dan como resultado
un valor booleano, indicando si los datos satisfacen la restricción o no. Las restricciones no son
parte formal del modelo relacional, pero son incluidas porque juegan el rol de organizar mejor los
datos.

Algunas restricciones las puede definir el usuario, por ejemplo, usar un campo con valores
enteros entre 1 y 10. Otras restricciones no son determinadas por los usuarios, sino que son
inherentemente definidas por el simple hecho de que la base de datos sea relacional. Entre los
tipos de restricciones se encuentran las siguientes:

Restricciones Inherentes: Son aquellas que no son determinadas por los usuarios, sino que son
definidas por el hecho de que la base de datos sea relacional. Entre las Restricciones Inherentes
más importantes se encuentran:

 No puede haber dos tuplas iguales.

 El orden de las tuplas no es significativo.
 El orden de los atributos no es significativo.
 Cada atributo sólo puede tomar un valor en el dominio en el que está inscrito.

Restricciones Semánticas: El modelo relacional permite a los usuarios incorporar restricciones

personales a los datos. A continuación detallan las diferentes reglas semánticas:

Clave primaria (primary key): Hace que los atributos marcados como clave primaria o puedan
repetir valores. Además, obliga a que esos atributos no puedan estar vacíos (nulos); es más, si la
clave primaria la forman varios atributos, ninguno de ellos podrá estar vacío.

Unicidad (unique): Impide que los valores de los atributos marcados de esa forma, puedan
repetirse. Esta restricción debe indicarse en todas las claves alternativas. Al marcar una clave
primaria se añade automáticamente sobre los atributos que forman la clave un criterio de unicidad.

Obligatoriedad (not null): Prohibe que el atributo marcado de esta forma no tenga ningún valor, es
decir, impide que pueda contener el valor nulo, null.

Integridad referencial: (foreign key): Sirve para indicar una clave externa. Cuando esa clave se
marca con integridad referencial, no se podrán introducir valores que no estén incluidos en los
campos relaciones con esa clave.

Por ejemplo, si hay una tabla de alquileres en la que cada fila es un alquiler, existirá un
atributo cod_cliente que indicará el código del cliente y que estará relacionado con una tabla de
clientes, e la que dicho atributo es la clave principal. De hecho no se podrá incluir un código que no
esté en la tabla clientes; eso es lo que prohíbe la integridad referencial.

Esto causa problemas en las operaciones de borrado y modificación de registros; ya que si

se ejecutan esas operaciones sobre la tabla principal (si se modifica o borra un cliente) quedarán
filas en la tabla secundaria con la clave externa haciendo referencia a un valor que ya no existe.
Esto último se puede controlar de las siguientes formas:

 Prohibiendo la operación (no action): Modificación/Borrado restringidos.

 Transmitiendo la operación de cascada (cascade): Si se modifica o borra un cliente,
también se modificarán o borrarán los alquileres relacionados con él. Modificación/Borrado
en cascada.
  Colocando nulos (set null): Las referencias al cliente en la tabla de alquileres se colocan
como nulos, es decir, alquileres sin clientes. Modificación/Borrado con puesta a nulo.
 Usando el valor por defecto (default): Se coloca un valor por defecto en las claves externas
relacionadas. Modificación y Borrado con puesta a un valor.

Regla de validación (check): Condición que debe cumplir un dato concreto para que sea
actualizado. Puede afectar a una tabla o a varias. Por ejemplo, restringir el campo sueldo para que
siempre sea mayor de 1000, sería una regla de validación.

Disparadores (triggers): Permiten además de indicar una condición, especificar la acción que se
quiere que se ejecute, si la condición se cumple. En la actualidad, los disparadores lo soportan la
mayoría de los productos comerciales relacionales.

NORMALIZACIÓN

La normalización es el proceso de organizar los datos de una base de datos. Se incluye la

creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para
proteger los datos como para hacer que la base de datos sea más flexible al eliminar la
redundancia y las dependencias incoherentes.

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a

las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional que asegura
la eliminación de redundancias e inconsistencias.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.

Las relaciones resultantes deben cumplir ciertas características:

 Se debe conservar la información:

o Conservación de atributos.
o Conservación de las tuplas, evitando la aparición de tuplas que no estaban en las
relaciones originales.
 Se deben conservar las dependencias.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla
sea considerada como una relación tiene que cumplir con algunas restricciones:

 Cada columna debe tener su nombre único.

 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.

Dependencias funcionales.

Una relación se compone de atributos y dependencias. Los atributos son fáciles de identificar,
ya que forman parte de la estructura de la relación, y además, los elegimos nosotros mismos como
diseñadores de la base de datos.
 Estas dependencias son consecuencia de la estructura de la base de datos y de los objetos del
mundo real que describen, y no de los valores actualmente almacenados en cada relación.

Definición: Sean X e Y subconjuntos de atributos de una relación. Diremos que Y tiene una
dependencia funcional de X, o que X determina a Y, si cada valor de X tiene asociado siempre un
único valor de y.

La dependencia funcional se representa X → Y.

El símbolo → se lee como “implica” o “determina”, y la dependencia anterior se lee como X

implica Y o X determina Y.

Otro símbolo del álgebra de dependencias: el símbolo | significa negación.

Así X → | Y se lee X no determina Y.

Dependencia funcional completa: En una dependencia funcional X → Y, cuando X es un

conjunto de atributos, decimos que la dependencia funcional es completa, si solo depende de X, y
no de ningún subconjunto de X.

La dependencia funcional se representa como X = › Y.

Dependencia funcional elemental: Si tenemos una dependencia completa X = › Y, diremos

que es una dependencia funcional elemental si Y es un atributo, y no un conjunto de ellos.

Estas son las dependencias que buscaremos en nuestras relaciones.

Dependencia funcional trivial: Una dependencia funcional A → B es trivial cuando B es parte

de A. Esto sucede cuando A es un conjunto de atributos, y B es a su vez un subconjunto de A.

Dependencia funcional transitiva: supongamos que tenemos una relación con tres conjuntos
de atributos: X, Y y Z, y las siguientes dependencias X → Y, Y → Z, Y → |X. Es decir, X determina
Y e Y determina Z, pero Y no determina X. En este caso decimos que Z tiene dependencia
transitiva con respecto a X, a través de Y.

Formas Normales

Definición: son reglas que permiten crear bases de datos libres de redundancias e
inconsistencias, que se ajusten a la definición de Edgar Codd de bases de datos relacional.

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base
de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades
de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue
Edgar F. Codd.

Primera Forma Normal (1FN)

Una tabla está en Primera Forma Normal si:

  Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son
indivisibles, mínimos.
 Cada atributo debe tener un nombre único.
 No pueden existir tuplas idénticas.
 La tabla contiene una clave primaria.
 La clave primaria no contiene atributos nulos.
 No debe de existir variación en el número de columnas

Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X
le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)

Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

EJEMPLO:

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.

nss nombre puesto salario emails

111 Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es
222 José Sánchez Administrativo 1500 jsanchez@ecn.es
333 Ana Díaz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...
Tabla 1

Tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria
(nss, email):

nss nombre puesto salario email

111 Juan Pérez Jefe de Área 3000 juanp@ecn.es
111 Juan Pérez Jefe de Área 3000 jefe2@ecn.es
222 José Sánchez Administrativo 1500 jsanchez@ecn.es
333 Ana Díaz Administrativo 1500 adiaz@ecn.es
333 Ana Díaz Administrativo 1500 ana32@gmail.com
... ... ... ... ...
Tabla 2

Tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss nombre puesto salario

111 Juan Pérez Jefe de Área 3000
222 José Sánchez Administrativo 1500
333 Ana Díaz Administrativo 1500
... ... ... ...
Tabla 3

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

nss email
 111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...

Tabla 4

Segunda Forma Normal (2FN)

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no
forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no
existen dependencias parciales.

Esta regla significa que en una relación sólo se debe almacenar información sobre un tipo
de entidad, y se traduce en que los atributos que no aporten información directa sobre la clave
principal deben almacenarse en una relación separada.

En otras palabras podríamos decir que la segunda forma normal está basada en el
concepto de dependencia completamente funcional. Una dependencia funcional X → Y es
completamente funcional si al eliminar los atributos A de X significa que la dependencia no es
mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional X → Y es una
dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la
dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.

Para aplicar esta forma normal, lo primero es identificar las claves candidatas. Además, se
elige una clave principal, que se abrevia PK, las iniciales de Primary Key. Esto es optativo, el
modelo relacional no obliga a elegir una clave principal para cada relación, sino tan sólo a la
existencia de al menos una clave candidata.

La inexistencia de claves candidatas implica que la relación no cumple todas las normas
para ser parte de una base de datos relacional, ya que la no existencia de claves implica la
repetición de tuplas.

Siguiendo el ejemplo: 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:

nss nombre puesto salario

111 Juan Pérez Jefe de Área 3000

222 José Sánchez Administrativo 1500

333 Ana Díaz Administrativo 1500

... ... ... ...

Tabla 5

Y al eliminar de la tabla original estos atributos nos quedaría:

nss email

111 juanp@ecn.es

111 jefe2@ecn.es

222 jsanchez@ecn.es

333 adiaz@ecn.es

333 ana32@gmail.com

... ...

Tabla 6

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional

transitiva entre los atributos que no son clave.

La tercera forma normal consiste en eliminar las dependencias transitivas. Esto significa
que se debe eliminar cualquier relación que permita llegar a un mismo dato de dos o más formas
diferentes.

Un ejemplo de este concepto sería que, una dependencia funcional X→Y en un esquema
de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un
subconjunto de alguna clave de R, donde se mantiene X→Z y Z→Y.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

nss nombre puesto

111 Juan Pérez Jefe de Área
222 José Sánchez Administrativo
333 Ana Díaz Administrativo
... ... ...
Tabla 7

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.

Forma normal de Boyce-Codd (FNBC)

La tabla se encuentra en FNBC si cada determinante, atributo que determina

completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante la presencia
de un intervalo seguido de una formalización perpetua, es decir las variantes creadas, en una tabla
no se llegaran a mostrar, si las ya planificadas, dejan de existir.

Atributos Multivaluados: Se dice que un atributo es multivaluado cuando para una

misma entidad puede tomar varios valores diferentes, con independencia de los valores que
puedan tomar el resto de los atributos.

Se representa como X→→Y, y se lee como X multidetermina Y.

Dependencias multivaluadas: Si existe más de un atributo multivaluado es cuando se

presentan dependencias multivaluadas. Es una relación con los atributos X, Y y Z existe una
dependencia multivaluada de Y con respecto a X si los posibles valores de Y para un par de
valores de X y Z dependen únicamente del valor de X.

Reglas de Codd

Codd se percató de que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas
tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema
relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá
considerarse "más relacional" cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

Toda la información en un RDBMS está explícitamente representada de una sola manera por
valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información,
incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las
columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que
contienen tal información constituyen el Diccionario de Datos. Esto significa que todo tiene que
estar almacenado en las tablas.
Regla No. 2 - La regla del acceso garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el
nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el
nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la
definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos

La información inaplicable o faltante puede ser representada a través de valores nulos

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar
el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables

Regla No. 4 - La regla de la descripción de la base de datos

La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios,
esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe

ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles
igual que todas las tablas, a través de sentencias de SQL (o similar).

Regla No. 5 - La regla del sub-lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos,
manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones
y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que
pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos
de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no sólo para la
recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos'.

Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT,
UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente
del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe
permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados,
o sean cambiados los métodos de acceso a los datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales

debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento
debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben permanecer
lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en
las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las
actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios
en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el
catalogo, no en el programa de aplicación.

Las reglas de integridad

1. Ningún componente de una clave primaria puede tener valores en blanco o nulos (ésta es
la norma básica de integridad).
2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La
combinación de estas reglas aseguran que haya integridad referencial.

Regla No. 11 - La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté
distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de
aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de
relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas
operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera
disponible como en una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados
para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como
SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos
No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad.
Esto no debe ser permitido.

Cuarta Forma Normal (4FN)

 La cuarta forma normal tiene por objetivo eliminar las dependencias multivaluadas. Una
relación está en 4FN si y sólo sí, en cada dependencia multivaluada X →→ Y no trivial, X es clave
candidata.

Una dependencia multivaluada A→→B es trivial cuando B es parte de A. Esto sucede

cuando A es un conjunto de atributos, y B es un subconjunto de A.

Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si:

 La tabla está en 4FN

 No existen relaciones de dependencias no triviales que no siguen los criterios de las
claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada
relación de dependencia se encuentra definida por las claves candidatas.

Sirve para eliminar dependencias de proyección o reunión, que raramente se encuentran en

las bases de datos.

EJEMPLO 1:

Normalización de base de datos para una tienda de video

Fecha: Cliente:
# Factura: Nombre:
CI:
Dirección:
Video Teléfono:
ID #Copia Título Costo

Subtotal:
IVA:
Total:

Se ordenan los datos en forma esquemática

Video (num-factura, fecha_transacción, nombre_cliente, CI_cliente, dirección_cliente,

tlf_cliente, Id_video, copia_video, titulo_video, costo_video)

Primera forma normal

Video1 (num-factura, fecha_transacción, nombre_cliente, CI_cliente, dirección_cliente,

tlf_cliente)
Video2 (num-factura, Id-video, copia_video, titulo_video, costo_video)

Segunda forma normal

Video1 (num-factura, fecha_transacción, nombre_cliente, CI_cliente, dirección_cliente,

tlf_cliente)
Video2 (num-factura, Id-video, copia_video)
Video (Id-video, titulo_video, costo_video)

Tercera forma normal

Video1 (num-factura, fecha_transacción)

Videocliente (num-factura, nombre_cliente, CI_cliente, dirección_cliente,
tlf_cliente)
Video2 (num-factura, Id-video, copia_video)
Video (id-video, título_video, costo_video)

EJEMPLO 2:

Normalización de una base de datos para una empresa que vende productos por internet

# Factura:
Cliente Tarjeta Internet

Nombre: #Tarjeta: Email:

Tlf: Vigencia: Recomendado:

Dirección: Banco:

Artículo
#Artículo Nombre Descripción Cant Solicitada PVS PVP Cant enviada

Subtotal:
IVA:
Total:

Pedido (num-factura, nombre_cliente, tlf, dirección, num-tarjeta, vigencia, banco, email,

recomendado, num-artículo, nombre_artículo, descipción, cant_solicitada, pvs, pvp,
cant_enviada)

Primera Forma normal

Pedido (num-factura, nombre_cliente, tlf, dirección, num-tarjeta, vigencia, banco, email,

recomendado)
Artículo (num-factura, num-artículo, nombre_artículo, descipción, cant_solicitada, pvs, pvp,
cant_enviada)

Segunda Forma normal

Pedido (num-factura, nombre_cliente, tlf, dirección, num-tarjeta, vigencia, banco, email,
recomendado)
Artículo (num-factura, num-artículo, cant_solicitada, pvp, cant_enviada)
Artículo1 (num-artículo, nombre_artículo, descipción, pvs)

Tercera Forma normal

Pedido (num-factura, nombre_cliente, tlf, dirección, num-tarjeta, vigencia, banco, email,

recomendado)
Cliente (nombre-cliente, tlf, dirección)
Tarjeta (num-tarjeta, vigencia, banco)
Internet (email, recomendado)
Artículo (num-factura, num-artículo, cant_solicitada, pvp, cant_enviada)
Artículo1 (num-artículo, nombre_artículo, descipción, pvs)

Base de datos relacional

Muestra las tablas en forma de filas y columnas, en ella podemos distinguir un conjunto de
columnas, denominadas atributos, que representan propiedades de la misma y que están
caracterizadas por un nombre; y un conjunto de filas llamadas tuplas que son las ocurrencias de la
relación. Existen también unos dominios donde los atributos toman sus valores. El número de filas
de una relación se denomina cardinalidad de la relación y el número de columnas es el grado de la
relación.
 
La integridad referencial: es una restricción de comportamiento ya que viene impuesta por el
mundo real y es el usuario quien la define al describir el esquema relacional; es también de tipo
implícito, ya que se define en el esquema y el modelo la reconoce (o así algunos productos) sin
necesidad de que se programe ni de que se tenga que escribir ningún procedimiento para obligar a
que se cumpla.

 Ejemplo

EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS)

LIBRO (CODIGO, TITULO, IDIOMA, ..., NOMBRE_E)

En este ejemplo el atributo nombre_e de la relación LIBRO es clave ajena que referencia a
EDITORIAL, de modo que debe concordar con la clave primaria de la relación EDITORIAL o bien
ser nulo, porque los libros de nuestra base de datos deberán pertenecer a una editorial existente, o
si se desconoce la editorial, no se tendrá ningún valor para este atributo.

AUTOR (NOMBRE, NACIONALIDAD, INSTITUCION, ..)

LIBRO (CODIGO, TITULO, IDIOMA, EDITORIAL, ...)

ESCRIBE (NOMBRE, COD LIBRO)

En este ejemplo la relación ESCRIBE posee dos claves ajenas: nombre, que referencia a
la relación AUTOR, y cod_libro, que referencia a la relación LIBRO; en este caso ninguna de las
dos claves ajenas puede tomar valores nulos, ya que forman parte de la clave primaria de la
relación ESCRIBE.

Las opciones para la integridad referencial son:

 B:C, borrado en cascada.

 B:N, borrado con puesta a nulos.

 B:D, borrado con puesta a un valor por defecto.

  B:R, borrado restringido.

 M:C, modificación en cascada.

 M:N, modificación con puesta a nulos.

 M:D, modificación con puesta a un valor por defecto.

 M:R, modificación restringido.

Operaciones Unitarias:

• Renombrado:

La operación de renombrado se utiliza exclusivamente para cambiar el nombre de una

relación.

Se utiliza de la siguiente forma: r empleado2(empleado)

• Selección:

El operador de Selección (σ) es una operación que aplicada a una tabla obtiene un
subconjunto de filas de esa tabla en la que solo aparecen las filas que cumplan un
determinado criterio.

Se expresa de la siguiente manera: σF(R)=R’

• Operadores de comparación.

(=,>, <, >=, <=, <>)

• Operadores de lógicos.

∧(and),∨(or), ¬ (not)

• Formato de Uso:

σ (condición) (RELACION)

Ejemplo.

Los datos de los empleados con sueldo ≥ $500.000 que ingresaron después del 2003:

Proyección ( π ):

Operador de proyección π , proyecta una relación sobre un subconjunto de sus atributos. El

operador p toma una relación como argumento y el resultado es una nueva relación.

π nombre,apellidos(Cliente)
Por ejemplo: Se tiene la siguiente tabla:

tabla1 (id,nombre, apellido)

tabla1

id nombre apellido fecha estado

123 Fulano Prierez 04/12/1987 soltero

454 Mengano Sanchiez 15/01/1990 soltero

102 Tulana Lopez 24/06/1985 casado

554 Fulano Gomez 15/05/1998 soltero

5 Tutulano Gonzalez 02/06/1970 viudo

Unas posibles proyecciones serian las siguientes:

tabla [id, apellido]

id apellido

123 Prierez

454 Sanchez

102 Lopez

554 Gomez

5 Gonzalez

tabla [nombre, estado]

nombre estado

Fulano soltero

Mengano soltero

Tulana casado

Tutulano viudo

Se ha eliminado una tupla,ya que aparece repetida.

Operaciones básicas binarias

Unión (U):

Si R y S son dos relaciones del mismo grado y definidas sobre el mismo conjunto de atributos; R u
5 es una relación del mismo grado que R y S, y definida sobre el mismo conjunto de atributos,
donde Las tuplas de esa nueva relación son todas las tuplas de R y todas Las tuplas de S.

Ejemplo:

TABLA1(id, nombre, apellido)

Id Nombre Apellido

15 Ángel Romero

34 Luis Hernández

12 Jesús Ríos

43 David Medina

TABLA2(id, nombre, apellido)

Id Nombre Apellido

44 José Pérez

63 Enrique Páez

55 Raúl Marcano

TABLA1 U TABLA2

Id Nombre Apellido

15 Ángel Romero

34 Luis Hernández

12 Jesús Ríos

43 David Medina

44 José Pérez

63 Enrique Páez

55 Raúl Marcano

Diferencia (-):
Si R y S son dos relaciones del mismo grado y definidas sobre el mismo conjunto de atributos; R -
S es una relación del mismo grado y atributos formada por todas las tuplas de R que no están
presentes en S.

Ejemplo:

TABLA1(id, nombre, color)

Id Nombre Color

10 Ángel Azul

20 Luis Rojo

30 Jesús Verde

40 David Amarillo

TABLA2(id, nombre, color)

Id Nombre Color

20 Luis Rojo

25 Enrique Azul

30 Jesús Verde

TABLA1 - TABLA2

Id Nombre Color

10 Ángel Azul

40 David Amarillo

Intersección (∩):

Si R y S son dos relaciones del mismo grado y definidas sobre el mismo conjunto de atributos; R ∩
S es una relación del mismo grado y atributos formada por todas las tupias de R y están presentes
en S.

Ejemplo:

TABLA1(id, nombre, color)

Id Nombre Color

10 Ángel Azul

20 Luis Rojo
 30 Jesús Verde

40 David Amarillo

TABLA2(id, nombre, color)

Id Nombre Color

20 Luis Rojo

25 Enrique Azul

30 Jesús Verde

TABLA1 ∩ TABLA2

Id Nombre Color

20 Luis Rojo

30 Jesús Verde

Producto cartesiano (x):

Si R es una relación de grado GI y S es una relación de grado G2; R x S es una relación de grado
GI +G2 cuyos GI primeros componentes forman una tupla de R y los siguientes G2 forman una
tupla de S. Es decir, el producto cartesiano es una relación que contiene todas Las tuplas que
resultan de combinar cada tupla de R con cada tupla de S.

Ejemplo:

TABLA1(id, nombre, color)

Id Nombre Color

10 Ángel Azul

40 David Amarillo

TABLA2(id, numero)

Id Numero

20 1

25 2
 30 3

TABLA1 X TABLA2

Id Nombre Color Id Numero

10 Ángel Azul 20 1

40 David Amarillo 25 2

10 Ángel Azul 30 3

40 David Amarillo 20 1

10 Ángel Azul 25 2

40 David Amarillo 30 3

Podemos ver que el grado resultante es: 3 + 2 = 5, y la cardinalidad será de: 2*3= 6.

• Combinación o Join (∞): es una de las más útiles del álgebra relacional y la empleada con
mayor frecuencia para combinar información de dos o mas relaciones.

cliente ∞ alquiler = σcliente.dni = alquiler.dni(clientexalquiler)

cliente.dni = alquiler.dni

Por ejemplo, se tienen las siguientes relaciones:

tabla1 (id,nombre,apellido)

tabla1

id nombre apellido

15 Fulginio Llepez

26 Cascanio Sanchez

tabla2(id, numero

tabla2

id numero

15 12345678

26 21222112

15 66525425
 La composición de estas dos tablas, para una combinacion en que “id” sea igual en ambas sería:

tabla1 [tabla1.id = tabla2.id] tabla2

id nombre apellido t2.id numero

15 Fulginio Llepez 15 12345678

26 Cascanio Sanchez 26 21222112

15 Fulginio Llepez 15 66525425

• Combinación natural o Join natural: Es una combinación que no indica condición alguna y
que automáticamente obtiene las tuplas combinadas cuyos atributos comunes a ambas
tablas sean del mismo valor.

R ∞ S = σ R.A1 = S.A1 ˄…˄ R.An = S.An (RxS)

tabla1 (x,y, nombre) Por ejemplo:

tabla1

x y nombre

A 4 Fulginio

A 6 Cascanio

B 3 Melania

C 4 Juanita
tabla1 [tabla1.x = tabla2.x Y tabla1.y = tabla2.y] tabla2
C 7 Antonio
x y nombre número
D 2 Fernando

D 5 Ana
A 6 Cascanio 145

tabla2 (x,y, numero) C 4 Juanita 140

tabla2
División (:): Si R y
S son relaciones D 2 Fernando 130
x y numero de grado G1 y G2
respectivamente,
A 3 120 y A es el conjunto D 5 Ana 302
de atributos
A 6 145 comunes a ambas
relaciones; R:S obtiene una relación de grado G1-G2 en la que
B 2 250 las tupIas resultantes son las tupIas formadas por los atributos
distintos de A que poseen todos los valores posibles de A en la
B 5 450

C 4 140

D 2 130

D 5 302
tabla S. Es decir, se obtienen las tupIas cuyos contenidos en los atributos comunes poseen todas
las combinaciones almacenadas en S.

Por ejemplo:

R S

R÷S

Tablas del Sistema

Las tablas del Sistema es una base de datos creada y mantenida de manera automática por el
propio DBMS que contiene información (descripción) de los objetos del propio sistema y de la
estructura de la base de datos, en otras palabras, es conocida como” la base de datos de la base
de datos”.

El catalogo del sistema acepta que se realicen consultas externas, pero evidentemente no
permite que se manipulen los datos que contienen (por ejemplo actualizarlos). Cabe destacar que
para manejar el catalogo de sistema se hace mediante el DBMS, el cual es un conjunto de
programas que se encarga de manejar la creación y todos los accesos a la base de datos. Así
como también es un medio de interfaz entre la base de datos, el usuario, y las aplicaciones que la
utilizan.

Ningún usuario debe modificar directamente las tablas del sistema. Por ejemplo, no intente
modificar tablas del sistema con las instrucciones DELETE, UPDATE o INSERT, ni con
desencadenadores definidos por el usuario. Se permite hacer referencia a columnas
documentadas en las tablas del sistema. Sin embargo, muchas de las columnas de las tablas del
sistema no están documentadas. No deben escribirse aplicaciones que consulten directamente
columnas no documentadas. En su lugar, las aplicaciones deben usar cualquiera de los
componentes siguientes para recuperar la información almacenada en las tablas del sistema:

 Procedimientos almacenados del sistema

 Instrucciones y funciones Transact-SQL
 Objetos de administración de SQL Server (SMO)
 Objetos de administración de replicación (RMO)
 Funciones de catálogo de API de base de datos

Estos componentes conforman una API publicada para obtener información del sistema de
SQL Server. Microsoft mantiene la compatibilidad de estos componentes entre versiones. El
formato de las tablas del sistema depende de la arquitectura interna de SQL Server y puede
cambiar de una versión a otra. Por tanto, puede ser necesario modificar las aplicaciones que tienen
acceso directo a columnas no documentadas de las tablas del sistema para que puedan tener
acceso a una versión posterior de SQL Server.

Las tablas del sistema se forman dependiendo de diversos tipos de gestores resaltando que
un gestor es una herramienta de una base de datos. En este caso utilizaremos dos tipos de
gestores los cuales son SQLServer y MySQL.

CARACTERISTICAS DE ORGANIZACIÓN DE LAS TABLAS DEL SISTEMA

Las tablas del sistema se organizan según las siguientes áreas de características:

Tablas de copias de seguridad y restauración Tablas de trasvase de registros

(Transact-SQL) (Transact-SQL)
Tablas de captura de datos de cambio (Transact- Tablas de replicación (Transact-
SQL) SQL)
Tablas de planes de mantenimiento de bases de Tablas de Agente SQL Server
datos (Transact-SQL) (Transact-SQL)
Tablas de Integration Services (Transact-SQL) sysoledbusers (Transact-SQL)
  systranschemas (Transact-SQL)

Transact-SQL

Es el lenguaje de bases de datos soportado por SQL Server. Transact-SQL es un lenguaje

completo de programación de bases de datos que incluye instrucciones de definición y
manipulación de datos, instrucciones iterativas y condicionales, variables, procedimientos y
funciones. Transact-SQL cumple el nivel de entrada de la norma SQL-92 pero también soporta
varias características desde los niveles intermedios y superiores. Transact-SQL también soporta
extensiones a la norma SQL-92.

 Tablas de copias Seguridad y restauración (Transact-SQL)

Los Siguientes temas describen las tablas del sistema que almacenan la información que
utilizan las operaciones de copias de seguridad y restauración de bases de datos.

 Backupfile: Contiene una fila por cada archivo de datos o de registro de una base de
datos. Las columnas describen la configuración del archivo en el momento en que se
realizó la copia de seguridad. La columna is_present determina si el archivo se va a incluir
en la copia de seguridad. Esta tabla se almacena en la base de datos msdb.

 Backupfilegroup: Contiene una fila para cada grupo de archivos de una base de datos en
el momento de realizar la copia de seguridad. La tabla backupfilegroup se almacena en la
base de datos msdb.

 Backupmediafamily: Contiene una fila por cada familia de medios. Si una familia de
medios reside en un conjunto de medios reflejado, la familia tiene una fila independiente
para cada reflejo del conjunto de medios. Esta tabla se almacena en la base de datos
msdb.

 Backupmediaset: Contiene una fila por cada conjunto de medios de copia de seguridad.
Esta tabla se almacena en la base de datos msdb.

 Backupset: Esta tabla se almacena en la base de datos msdb.

  Logmarkhistory: Contiene una fila por cada transacción marcada que se ha confirmado.
Esta tabla se almacena en la base de datos msdb.

 Restorefile: Contiene una fila por cada archivo restaurado, incluidos los restaurados
indirectamente por el nombre de grupo de archivos. Esta tabla se almacena en la base de
datos msdb.

 Restorefilegroup: Contiene una fila por cada grupo de archivos restaurado. Esta tabla se
almacena en la base de datos msdb.

 Restorehistory: Contiene una fila por cada operación de restauración. Esta tabla se
almacena en la base de datos msdb.

 suspect_pages: Contiene una fila por página en la que se produjo un error pequeño 823 o
un error 824. Se hace una lista de páginas en esta tabla porque se sospecha que estén
dañadas, pero es posible que, en realidad, sean correctas. Cuando se repara una página
sospechosa, su estado se actualiza en la columna event_type.

La siguiente tabla, con un límite de 1.000 filas, se almacena en la base de datos msdb.

 Sysopentapes: Contiene una fila por cada dispositivo de cinta abierto. Esta vista
se almacena en la base de datos maestra.

 Tablas de captura de datos de cambio (Transact-SQL)

La captura de datos de cambio permite realizar un seguimiento de las tablas de tal

manera que los cambios en el lenguaje de manipulación de datos (DML) y en el lenguaje
de definición de datos (DDL) realizados en las tablas se puedan cargar incrementalmente
en un almacén de datos. Los temas de esta sección describen las tablas del sistema que
almacenan la información que usan las operaciones de captura de datos modificados.

cdc. <capture_instance>_CT: Devuelve una fila para cada cambio realizado en

una columna capturada en la tabla de origen asociada.

cdc.captured_columns: Devuelve una fila para cada columna de la que se ha

realizado un seguimiento en una instancia de captura.

cdc.change_tables: Devuelve una fila por cada tabla de cambios en la base de

datos.

cdc.ddl_history: Devuelve una fila para cada cambio del lenguaje de definición de
datos (DDL) realizado en las tablas que se habilitan para la captura de datos de cambio.

cdc.lsn_time_mapping: Devuelve una fila para cada transacción que tiene filas en
una tabla de cambios. Esta tabla se utiliza para las asignaciones entre los valores de
confirmación de número de secuencia de registro (LSN) y la hora de confirmación de la
transacción.

cdc.index_columns: Devuelve una fila para cada columna de índice asociada a

una tabla de cambios.

dbo.cdc_jobs (Transact-SQL): Devuelve los parámetros de configuración para los

trabajos de agente de captura de datos del cambio.
 Tablas de planes de Mantenimiento de Bases de datos (Transact-SQL)

Estas tablas conservan información de instancias actualizadas desde una versión

anterior de SQL Server.

sysdbmaintplan_databases: Contiene una fila por cada base de datos que tiene
un plan de mantenimiento de bases de datos actualizado asociado.

sysdbmaintplan_history: Contiene una fila por cada acción del plan de

mantenimiento de bases de datos actualizado que se ha realizado.

sysdbmaintplan_jobs: Contiene una fila por cada trabajo del plan de

mantenimiento de bases de datos actualizado.

Sysdbmaintplans: Contiene una fila por cada plan de mantenimiento de bases de

datos actualizado.

 Tablas de Integración Services (Transact-SQL)

Los temas de esta sección describen las tablas del sistema que almacenan
información utilizada en las operaciones de trasvase de registros.

log_shipping_monitor_alert: Almacena los identificadores de trabajo de alerta del

trasvase de registros.

log_shipping_monitor_error_detail: Almacena los detalles de errores de los

trabajos de trasvase de registros.

log_shipping_monitor_history_detail: Almacena los detalles del historial para los

trabajos de trasvase de registros.

log_shipping_monitor_primary: Almacena un registro de supervisión por cada

base de datos principal en cada configuración de trasvase de registros.

log_shipping_monitor_secondary: Almacena un registro de supervisión por cada

base de datos secundaria en una configuración de trasvase de registros.

log_shipping_primary_databases: Almacena un registro para la base de datos

principal en una configuración de trasvase de registros.

log_shipping_primary_secondaries: Asigna cada base de datos principal a sus

bases de datos secundarias.

log_shipping_secondary: Almacena un registro por cada identificador

secundario.

log_shipping_secondary_databases: Almacena un registro por cada base de

datos secundaria en una configuración de trasvase de registros.

TABLAS BASE DEL SITEMA

Las tablas base del sistema son las tablas subyacentes que almacenan los
metadatos para una base de datos específica. La base de datos maestra es especial al
respecto porque contiene algunas tablas adicionales que no se encuentran en ninguna de
las demás bases de datos. Estas tablas contienen metadatos persistentes con un ámbito
para todo el servidor
 Las tablas base del sistema se utilizan sólo en SQL Server Database Engine
(Motor de base de datos de SQL Server) y no son para el uso general de los clientes.
Están sujetas a cambios y no se garantiza su compatibilidad.

Metadatos de tablas base del sistema

Para enlazar con una tabla base del sistema, un usuario tiene que conectarse a la
instancia de SQL Server utilizando la conexión de administrador dedicada (DAC:
conversión digital análoga). Si intenta ejecutar una consulta SELECT de una tabla base del
sistema sin conectarse a través de la conexión DAC, se producirá un error.
El acceso a las tablas base del sistema mediante DAC sólo está diseñado para el
personal de Microsoft y no es un escenario de cliente compatible.

En la tabla siguiente se enumeran y describen algunas de las tablas base del sistema de
SQL Server.

Tabla base Descripción

sys.sysschobjs Existe en todas las bases de datos. Cada fila representa un

objeto en la base de datos.
sys.sysbinobjs Existe en todas las bases de datos. Contiene una fila para
cada entidad de Service Broker en la base de datos. Las
entidades de Service Broker contienen los siguientes
elementos:

Tipo de mensaje
Contrato de servicio
Servicio

Los nombres y tipos utilizan intercalación binaria fija.

sys.sysclsobjs Existe en todas las bases de datos. Contiene una fila para
cada entidad clasificada que comparte las mismas propiedades
comunes, entre las que se incluyen las siguientes:

Ensamblado
Dispositivo de copia de seguridad
Catálogo de texto completo
Función de partición
Esquema de partición
Grupo de archivos
Clave de ofuscación

My SQL:

Es un sistema de gestión de base de datos relacional, multihilo y multiusuario.

CARACTERISTICAS DE My SQL:

 Gratuito y de código abierto

 Creación ilimitada de foros y subforos
 Mejoramiento en el rendimiento desde su versión anterior
 Uso de caché para todos los archivos del foro
 Registro de usuarios y personalización de cada campo
 Mensajes privados a múltiples usuarios y carpetas de mensajes
 Búsqueda de temas y usuarios
 Panel de administrador y de moderador por separado
 Creación de encuestas con múltiples opciones
 Perfil para cada usuario con sus datos personales
 Aplicar Ban por tiempo definido o indefinido
 Personalización de BBCode
 Creación de grupos de usuarios, moderadores o administradores
 Advertencia y reportes por usuarios a moderadores ante posts indebidos
 Poder crear nuevos campos para el perfil de usuario
 Poder editar, desde el panel de administración, los archivos del Tema usado
 Múltiples archivos adjuntos
 Fácil creación y asignación de rangos por posts o por grupos
 Respaldo y restauración de la base de datos a través del panel de administrador.

SQL SERVER:

Este tipo de gestor almacenan los datos que definen la configuración del servidor y
de todas sus tablas en un conjunto de tablas especial, conocida como tablas del sistema.

SQL Server no permite a los usuarios actualizar directamente la información de

objetos del sistema, como tablas del sistema, procedimientos almacenados del sistema y
vistas de catálogo. En su lugar, Microsoft proporciona un completo conjunto de
herramientas administrativas con las que los usuarios pueden administrar totalmente el
sistema, así como todos los usuarios y objetos de una base de datos. Entre ellas figuran
las siguientes:

 Utilidades de administración, como SQL Server Management Studio.

 API de SQL-SMO. Permite a los programadores incluir funcionalidad completa para
administrar SQL Server en sus aplicaciones.
 Secuencias de comandos y procedimientos almacenados de Transact-SQL. Pueden
utilizar procedimientos almacenados del sistema e instrucciones DDL de Transact-SQL.

Estas herramientas protegen a las aplicaciones de cambios en los objetos del

sistema. Por ejemplo, en ocasiones Microsoft tiene que cambiar las tablas del sistema de
nuevas versiones de SQL Server para que admitan las nuevas funciones agregadas. Las
aplicaciones que utilizan instrucciones SELECT que hacen referencia directa a tablas del
sistema suelen basarse en el formato anterior de estas tablas. Es posible que los sitios no
puedan actualizar una versión de SQL Server a otra nueva hasta que se hayan modificado
las aplicaciones que realizan consultas SELECT en las tablas del sistema. Microsoft tiene
en cuenta las interfaces publicadas de procedimientos almacenados del sistema,
instrucciones DDL y SQL-SMO, e intenta mantener la compatibilidad con las versiones
anteriores de dichas interfaces.

Microsoft no admite la definición de desencadenadores en las tablas del sistema

porque pueden alterar el funcionamiento del sistema.

Si se quieren ver datos de base del sistema no se debe utilizar en los programas
instrucciones Transact-SQL que consulten directamente las tablas del sistema, a menos
que ése sea el único modo de obtener la información que requiere la aplicación. En su
lugar, las aplicaciones deben obtener información de catálogo y del sistema mediante el
uso de:

 Vistas de catálogo del sistema

 SQL-SMO
  Interfaz de Instrumental de administración de Windows (WMI)
 Funciones de catálogo, métodos, atributos o propiedades de la API de datos utilizada en
la aplicación, como ADO, OLE DB u ODBC.
 Procedimientos almacenados del sistema y funciones integradas de Transact-SQL.

A continuación se muestran las tablas del sistema que almacenan la información utilizada por el
agente SQL Server.

syssubsystems Contiene una fila por cada alerta.

syscategories Contiene Studio para organizar los trabajos, las

alertas y los operadores.

sysdownloadlist Mantiene la cola de instrucciones de descarga

para todos los servidores de destino.

sysjobactivity Contiene información sobre la actividad y el

estado de los trabajos actuales del Agente SQL
Server.

sysjobhistory Contiene información acerca de la ejecución de

los trabajos programados por el Agente SQL
Server.

sysjobs Almacena la información de cada trabajo

programado que debe ejecutar el Agente SQL
Server.

sysjobschedules Contiene información de programación de los

trabajos que el Agente SQL Server debe ejecutar.

sysjobservers Almacena la asociación o relación de un trabajo

determinado con uno o más servidores de
destino.

sysjobsteps Contiene la información de cada paso de un

trabajo que debe ejecutar el Agente SQL Server.

sysjobstepslogs Contiene información sobre los registros de pasos

de trabajo.

sysnotifications Contiene una fila por cada notificación.

sysoperators Contiene una fila por cada operador del Agente
SQL Server.

systargetservergroupmembers Registra los servidores de destino dados de alta

actualmente en este grupo multiservidor.

systargetservergroups Registra los grupos de servidores de destino

dados de alta actualmente en este entorno
multiservidor.

systargetservers Registra los servidores de destino datos de alta

actualmente en este dominio de operación
multiservidor.

systaskids Contiene una asignación de las tareas creadas en

versiones anteriores de SQL Server a trabajos de
Management Studio de la versión actual.

sysproxies Contiene información sobre las cuentas de proxy

del Agente SQL Server.

sysproxylogin Registra qué inicios de sesión de SQL Server

están asociados a cada cuenta de proxy del
Agente SQL Server.

sysproxysubsystem Registra qué subsistema del Agente SQL Server

se utiliza en cada cuenta de proxy.

sysschedules Contiene información sobre las programaciones

de trabajo del Agente SQL Server.
 syssessions Contiene la fecha de inicio del Agente SQL Server
para cada sesión del Agente SQL Server. Se crea
una sesión cada vez que se inicia el servicio del
Agente SQL Server.

TIPOS DE TABLAS SQL SERVER:

SQL Server proporciona las siguientes tipos de tablas que permiten llevar a cabo
objetivos especiales en una base de datos.

Tablas con particiones: Son tablas cuyos datos se han dividido horizontalmente
entre unidades que pueden repartirse por más de un grupo de archivos de una base,
facilitan la administración de las tablas y los índices grandes porque permiten obtener
acceso y administrar subconjuntos de datos con rapidez y eficacia al mismo tiempo que
mantienen la integridad del conjunto.

Tablas temporales:

Existen dos tipos de tablas temporales: locales y globales.

Las tablas temporales locales: son visibles solo para sus creadores durante la
misma conexión a una instancia de SQLServer, las tablas locales se eliminan cuando el
usuario se desconecta de la instancia de SQLServer.

Las tablas globales: están visibles para cualquier usuario y conexión una vez
creadas, y se eliminan cuando todos los usuarios que hacen referencia a la tabla se
desconectan de la instancia de SQLServer.

Tablas persistentes:

Son aquellas que permiten que los registros sean eliminados o borrados
manualmente y tenemos de tres tipos: base, vistas, instantáneos.

Base: es en donde se encuentra toda la información de todos los registros sin que
se haga ninguna validación adicional.

Vistas: en una vista o relación que se hace en referencia a una fila o columna
específica.

Instantáneos: son aquellos registros que se puede ver de manera inmediata con
solo una referencia.

Vistas de catálogo (Transact-SQL)

Las vistas de catálogo devuelven información utilizada por el SQL Server Database
Engine (Motor de base de datos de SQL Server). Se recomienda utilizar las vistas de
catálogo porque son la interfaz más general para los metadatos del catálogo y
 proporcionan el método más eficaz para obtener, transformar y presentar formas
personalizadas de esta información. Todos los metadatos del catálogo disponibles para el
usuario se exponen mediante las vistas de catálogo.

Las vistas de catálogo no contienen información sobre los datos de catálogo de

replicación, copia de seguridad, plan de mantenimiento de bases de datos o Agente SQL
Server.

TRANSACCIÓN: Es una unidad de la ejecución de un programa que accede y

posiblemente actualiza varios elementos de datos. Una transacción se inicia por la ejecución de un
programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un
lenguaje de programación (por ejemplo SQL, COBOL, C, C++ o Java), y está delimitado por
instrucciones (o llamadas a función) de la forma inicio transacción y fin transacción.

La transacción consiste en todas las operaciones que se ejecutan entre inicio transacción
y el fin transacción. Para asegurar la integridad de los datos se necesita que el sistema de base
de datos mantenga las siguientes propiedades de las transacciones:

 Atomicidad. O todas las operaciones de la transacción se realizan adecuadamente en la

base de datos o ninguna de ellas.
 Consistencia. La ejecución aislada de la transacción (es decir, sin otra transacción que se
ejecute concurrentemente) conserva la consistencia de la base de datos.
 Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema
garantiza que para cada par de transacciones Ti y Tj, se cumple que para los efectos de Ti, o bien
Tj ha terminado su ejecución antes de que comience Ti , o bien que Tj ha comenzado su ejecución
después de que Ti termine. De este modo, cada transacción ignora al resto de las transacciones
que se ejecuten concurrentemente en el sistema.
 Durabilidad. Tras la finalización con éxito de una transacción, los cambios realizados en la
base de datos permanecen, incluso si hay fallos en el sistema. Estas propiedades a menudo
reciben el nombre de propiedades ACID; el acrónimo se obtiene de la primera letra de cada una
de las cuatro propiedades en inglés (Atomicity, Consistency, Isolation y Durability,
respectivamente).

 Permanencia. Es la propiedad de las transacciones que asegura que una vez que una
transacción finaliza exitosamente, sus resultados son permanentes y no pueden ser borrados de la
base de datos por alguna falla posterior
 Confiabilidad. Puesto que los sistemas de base de datos en línea no pueden fallar.
 Disponibilidad. Debido a que los sistemas de base de datos en línea deben estar
actualizados correctamente todo el tiempo.
 Rendimiento. Los sistemas de base de datos en línea requieren procesar miles de
transacciones por segundo.

Para comprender mejor las propiedades ACID y la necesidad de dichas propiedades,

considérese un sistema bancario simplificado constituido por varias cuentas y un conjunto de
transacciones que acceden y actualizan dichas cuentas. Por ahora se asume que la base de datos
reside permanentemente en disco, pero una porción de la misma reside temporalmente en la
memoria principal.
Sea Ti una transacción para transferir 50 € de la cuenta A a la cuenta B. Se puede definir
dicha transacción
como
Ti: leer(A);
A := A – 50;
escribir(A);
leer(B);
B := B + 50;
escribir(B).
 Considérense ahora cada uno de los requisitos ACID (para una presentación más cómoda,
se consideran en distinto orden al indicado por A-C-I-D).

 Consistencia: en este caso el requisito de consistencia es que la suma de A y B no sea

alterada al ejecutar la transacción. Sin el requisito de consistencia, ¡la transacción podría crear o
destruir dinero! Se puede comprobar fácilmente que si una base de datos es consistente antes de
ejecutar una transacción, sigue siéndolo después de ejecutar dicha transacción. La responsabilidad
de asegurar la consistencia de una transacción es del programador de la aplicación que codifica
dicha transacción. La comprobación automática de las restricciones de integridad puede facilitar
esta tarea.

 Atomicidad: El sistema de base de datos mantiene los valores antiguos (en disco) de
aquellos datos sobre los que una transacción realiza una escritura y, si la transacción no completa
su ejecución, los valores antiguos se recuperan para que parezca que la transacción no se ha
ejecutado.

La responsabilidad de asegurar la atomicidad es del sistema de base de datos; en

concreto, lo maneja un componente llamado componente de gestión de transacciones.

 Durabilidad: una vez que se completa con éxito la ejecución de una transacción, y
después de comunicar al usuario que inició la transacción que se ha realizado la transferencia de
fondos, no debe suceder que un fallo en el sistema produzca la pérdida de datos correspondientes
a dicha transferencia. La propiedad de durabilidad asegura que, una vez que se completa con éxito
una transacción, persisten todas las modificaciones realizadas en la base de datos, incluso si hay
un fallo en el sistema después de completarse la ejecución de dicha transacción. A partir de ahora
se asume que un fallo en la computadora del sistema produce una pérdida de datos de la memoria
principal, pero los datos almacenados en disco nunca se pierden. Se puede garantizar la
durabilidad si se asegura que:
1. Las modificaciones realizadas por la transacción se guardan en disco antes de que finalice la
transacción.
2. La información de las modificaciones realizadas por la transacción guardada en disco es
suficiente para permitir a la base de datos reconstruir dichas modificaciones cuando el sistema se
reinicie después del fallo. La responsabilidad de asegurar la durabilidad es de un componente del
sistema de base de datos llamado componente de gestión de recuperaciones.
El componente de gestión de transacciones y el componente de gestión de recuperaciones
están estrechamente relacionados, y su implementación.
 Aislamiento: incluso si se aseguran las propiedades de consistencia y de atomicidad para
cada transacción, si varias transacciones se ejecutan concurrentemente, se pueden entrelazar sus
operaciones de un modo no deseado, produciendo un estado inconsistente. Por ejemplo, como se
ha visto antes, la base de datos es inconsistente temporalmente durante la ejecución de la
transacción para transferir fondos de la cuenta A a la cuenta B, con el total deducido escrito ya en
A y el total incrementado todavía sin escribir en B. Si una segunda transacción que se
ejecuta concurrente lee A y B en este punto intermedio y calcula A + B, observará un valor
inconsistente. Además, si esta segunda transacción realiza después modificaciones en A y B
basándose en los valores leídos, la base de datos puede permanecer en un estado inconsistente
aunque ambas transacciones terminen.
Una solución para el problema de ejecutar transacciones concurrentemente es ejecutarlas
secuencialmente, es decir, una tras otra. Sin embargo, la ejecución concurrente de transacciones
produce notables beneficios en el rendimiento, Se han desarrollado otras soluciones que permiten
la ejecución concurrente de varias transacciones.
La propiedad de aislamiento asegura que el resultado obtenido al ejecutar
concurrentemente las transacciones es un estado del sistema equivalente a uno obtenido al
ejecutar una tras otra en algún orden. La responsabilidad de asegurar la propiedad de aislamiento
es de un componente del sistema de base de datos llamado componente de control de
concurrencia.
 ESTADOS DE UNA TRANSACCIÓN

Una transacción debe estar en uno de los estados siguientes:

 Activa, el estado inicial; la transacción permanece en este estado durante su ejecución.
 Parcialmente comprometida, después de ejecutarse la última instrucción.
 Fallida, tras descubrir que no puede continuar la ejecución normal.
 Abortada, después de haber retrocedido la transacción y restablecido la base de datos a
su estado anterior al comienzo de la transacción.
 Comprometida, tras completarse con éxito.

El diagrama de estados correspondiente a una transacción. Se dice que una transacción se

ha comprometido sólo si ha llegado al estado comprometida. Análogamente, se dice que una
transacción ha abortado sólo si ha llegado al estado abortada. Una transacción se dice que ha
terminado si se ha comprometido o bien se ha abortado. Una transacción comienza en el estado
activa. Cuando acaba su última instrucción pasa al estado de parcialmente comprometida. En este
punto la transacción ha terminado su ejecución, pero es posible que aún tenga que ser abortada,
puesto que los datos actuales pueden estar todavía en la memoria principal y puede producirse un
fallo en el hardware antes de que se complete con éxito. El sistema de base de datos escribe en
disco la información suficiente para que, incluso al producirse un fallo, puedan reproducirse los
cambios hechos por la transacción al reiniciar el sistema tras el fallo. Cuando se termina de escribir
esta información, la transacción pasa al estado comprometida. Como se ha mencionado antes, se
asume que los fallos no provocan pérdidas de datos en disco.
Una transacción llega al estado fallida después de que el sistema determine que dicha
transacción no puede continuar su ejecución normal (por ejemplo, a causa de errores de hardware
o lógicos). Una transacción de este tipo se debe retroceder.

Después pasa al estado abortada. En este punto, el sistema tiene dos opciones:

 Reiniciar la transacción, pero sólo si la transacción se ha abortado a causa de algún error

hardware o software que no lo haya provocado la lógica interna de la transacción. Una
transacción reiniciada se considera una nueva transacción.
 Cancelar la transacción. Normalmente se hace esto si hay algún error interno lógico que
sólo se puede corregir escribiendo de nuevo el programa de aplicación, o debido a una
entrada incorrecta o debido a que no se han encontrado los datos deseados en la base de
datos.

CONCURRENCIA: Es la propiedad de los sistemas que permite múltiplos procesos sean

ejecutados al mismo tiempo y que potencialmente pueden interactuar entre sí, los procesos
concurrente pueden ser ejecutados en manera simultánea solo cuando cada uno de ellos es
ejecutado en diferentes procesadores, en cambio la concurrencia es simulada si solo existe un
procesador encargado de ejecutar los proceso concurrente simulando la concurrencia ocupándose
de forma alternada en uno y otro proceso por pequeños intervalos de tiempo.

CONTROL DE CONCURRENCIA EN BASES DE DATOS

El control de transacciones concurrentes en una base de datos brinda un eficiente

desempeño del Sistema de Base de Datos, puesto que permite controlar la ejecución de
transacciones que operan en paralelo, accesando a información compartida y, por lo tanto,
interfiriendo potencialmente unas con otras.

La mayoría de las bases de datos se utilizan en entornos multi-usuario, en los que muchos
clientes utilizando la misma aplicación, o muchas aplicaciones cada una con uno o muchos clientes
acceden a la misma Base de Datos. Cada una de esas aplicaciones enviará consultas al gestor, y
normalmente cada hilo de ejecución será una transacción diferente. En la mayoría de los sistemas
operativos actuales, las diferentes tareas o hilos se ejecutan de forma intercalada (incluso en el
caso de máquinas con varios procesadores). Es decir, el sistema operativo decide por su cuenta
cuando suspender una de las tareas y darle un poco de tiempo de ejecución a otra. Si hay tareas
simultáneas o concurrentes sobre la misma Base de Datos, esta intercalación puede resultar en
que las lecturas y escrituras de las diferentes tareas o aplicaciones en el medio físico se realicen
en cualquier orden y secuencia.

El acceso simultáneo descrito puede dar como resultados información inconsistente o

simplemente incorrecta, dependiendo de la mala o buena suerte que tengamos en la intercalación
de las lecturas y escrituras simultáneas. Esta problemática ha llevado a diseñar e implementar
diferentes estrategias de control de concurrencia, que se encargan de evitar todos esos problemas,
de modo que los desarrolladores de las aplicaciones pueden “olvidarse” de ellos al escribir su
código.

Existen varias técnicas para controlar la concurrencia. Los bloqueos son los más
conocidos, aunque también se utiliza el control multi-versión y otras técnicas como las marcas de
tiempo.

LOS BLOQUEOS COMO SOLUCIÓN AL PROBLEMA DE LA CONCURRENCIA

Una forma de controlar la concurrencia es hacer que cada transacción deba adquirir un
derecho de acceso exclusivo a cada fragmento de datos que necesite modificar. A estos
“derechos” se les denomina bloqueos.

Entre los que podemos destacar:

 BLOQUEOS BINARIOS

La forma más simple de bloquear es utilizar Bloqueos Binarios. En este cada transacción
debe solicitar el bloqueo de cada fragmento de datos A que vaya a utilizar antes de acceder a él
(sea para leerlo o escribirlo), mediante una operación bloquear(A). Deberá liberar todos los
bloqueos, mediante una operación desbloquear(A) de modo que otras tareas puedan tomarlos.

Este sistema de bloqueos tiene una implementación muy simple, ya que solo requiere
mantener una tabla que indica qué partes de los datos está bloqueada y por qué transacción.

 BLOQUEOS DE LECTURA/ESCRITURA

El sistema de bloqueos binarios es simple pero demasiado restrictivo, ya que no permite

que dos transacciones que van a leer el mismo fragmento de datos A lo hagan simultáneamente,
cuando en realidad, no puede haber problemas en varios lectores simultáneos. Los bloqueos de
lectura/escritura hacen más débil la restricción permitiendo la siguiente compatibilidad de bloqueo.

LECTURA ESCRITURA
LECTURA Compatible Incompatible
ESCRITURA Incompatible Incompatible
SERIALIZACIÓN DE LOS BLOQUEOS DE LECTURA/ESCRITURA
 La Serialización de las operaciones de lectura y escritura consiste en ordenar esas
operaciones para un conjunto de transacciones concurrentes de modo que los resultados de las
operaciones sean correctos.
Los bloqueos garantizan el acceso exclusivo a un dato o fragmento de información
(evitando ciertos problemas), pero los problemas asociados a la intercalación de las operaciones
compuestas aún pueden darse.

Por lo tanto, hace falta alguna política o mecanismo de adquisición y liberación de

bloqueos que permita hacer las operaciones serializables.

 BLOQUEOS DE DOS FASES

Es utilizado normalmente para afrontar la problemática originada por la concurrencia de

transacciones, también permite la serialización.
Este bloqueo en dos fases fuerza a las transacciones cuando todas las operaciones de
adquisición de bloqueos (bloquear_lectura, bloquear_escritura) preceden a la primera operación de
desbloqueo (desbloquear). Dicho de otro modo, primero hay que adquirir todos los bloqueos, y
después se pueden liberar.

 BLOQUEOS COMPARTIDOS
Los Bloqueos Compartidos permiten que varias transacciones simultáneas lean (SELECT)
un recurso en situaciones de control de simultaneidad pesimista. Ninguna otra transacción podrá
modificar los datos mientras el Bloqueo Compartido exista en el recurso. Los Bloqueos
Compartidos en un recurso se liberan tan pronto como finaliza la operación de lectura, a menos
que se haya establecido el nivel de aislamiento de la transacción como REPEATABLE READ o
más alto, o bien se utilice una sugerencia de bloqueo para mantener los bloqueos compartidos
durante la transacción.

 BLOQUEOS EXCLUSIVOS
Los Bloqueos Exclusivos evitan que transacciones simultáneas tengan acceso a un
recurso. Al utilizar un Bloqueo Exclusivo, el resto de las transacciones no pueden modificar los
datos; las operaciones de lectura sólo se pueden realizar si se utiliza la sugerencia NOLOCK o el
nivel de aislamiento de lectura no confirmada.
Las instrucciones para modificar datos, como INSERT, UPDATE y DELETE combinan las
operaciones de modificación con las de lectura. En primer lugar, la instrucción lleva a cabo
operaciones de lectura para adquirir los datos antes de proceder a ejecutar las operaciones de
modificación necesarias. Por tanto, las instrucciones de modificación de datos suelen solicitar
bloqueos compartidos y exclusivos. Por ejemplo, una instrucción UPDATE puede modificar las filas
de una tabla a partir de una combinación con otra tabla. En este caso, la instrucción UPDATE
solicita bloqueos compartidos para las filas leídas en la tabla de combinación, además de bloqueos
exclusivos para las filas actualizadas.

CONTROL MULTI-VERSIÓN: Es cuando una transacción modifica un dato, se crea una

nueva versión del mismo, pero se guarda la anterior. De este modo, al acabar la ejecución de las
transacciones, se puede utilizar para cada una de ellas la versión de los datos que hace la
ejecución correcta.
Varias transacciones leen y escriben diferentes versiones del mismo dato siempre que
cada transacción sea un conjunto consistente de versiones de todos los datos a los que accede.

MARCA DE TIEMPO: Es un identificador único asociado a cada transacción. En lugar de

determinar el orden entre las transacciones en conflicto en función del momento del acceso a los
elementos, determinan por adelantado una ordenación de las transacciones.

CARACTERISTICAS DE MARCA DE TIEMPO

 El interbloqueo es imposible.
 Las actualizaciones físicas se retrasan hasta la confirmación de las transacciones.
  No se puede actualizar

LA CONCURRENCIA PUEDE PRESENTARSE EN TRES CONTEXTOS DIFERENTES:

 Múltiples aplicaciones: la multiprogramación se creó para permitir que el tiempo de

procesador de la máquina fuese compartido dinámicamente entre varias aplicaciones
activas.

 Aplicaciones estructuradas: como ampliación de los principios del diseño modular y la

programación estructurada, algunas aplicaciones pueden implementarse eficazmente
como un conjunto de procesos concurrentes.

 Estructura del sistema operativo: las mismas ventajas de estructuración son aplicables a
los programadores de sistemas y se ha comprobado que algunos sistemas operativos
están implementados como un conjunto de procesos o hilos.

PRINCIPIOS GENERALES DE LA CONCURRENCIA

Un sistema multiprogramado con un único procesador, los procesos se intercalan en el

tiempo aparentando una ejecución simultánea. Aunque no se logra un procesamiento paralelo y
produce una sobrecarga en los intercambios de procesos, la ejecución intercalada produce
beneficios en la eficiencia del procesamiento y en la estructuración de los programas.

La intercalación y la superposición pueden contemplarse como ejemplos de procesamiento

concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad de
ejecución de los procesos que no pueden predecirse y depende de las actividades de otros
procesos, de la forma en que el sistema operativo trata las interrupciones surgen las siguientes
dificultades:

Compartir recursos globales es riesgoso Para el sistema operativo es difícil gestionar la

asignación óptima de recursos. Las dificultades anteriores también se presentan en los sistemas
multiprocesador.

El hecho de compartir recursos ocasiona problemas, por esto es necesario proteger a

dichos recursos. Base

Los problemas de concurrencia se producen incluso cuando hay un único procesador.

MECANISMOS QUE SE UTILIZAN PARA PROPORCIONAR CONCURRENCIA

Dentro de estos mecanismos podemos resaltar:

SEMÁFOROS: Un semáforo nos sirve para poder permitir o restringir a los procesos o
hilos el acceso a algún recurso compartido. También es una estructura formada por una posición
de memoria y dos instrucciones, una para reservarlo y otra para liberarlo, ellas son: semwait
(espera) que decrementa el valor del semáforo si el valor pasa a ser negativo entonces el proceso
que está ejecutando semwait se se bloquea, en otro caso el proceso continua su ejecución, y
semsignal (señal) esta incrementa el valor del semáforo si el valor es menor o igual a cero
entonces se desbloquea unos de los proceso bloqueados en la operación semwait, y por ultimo un
semáforo no puede comenzar en un valor negativo.

MONITORES: Son un mecanismo de software para control de concurrencia que contiene

los datos y los procedimientos necesarios para realizar la asignación de un determinado recurso o
grupo de recursos compartidos reutilizables en serie. Un monitor se usa para manejar todas las
funciones de concurrencia, comunicación entre procesos y localización física de recursos en una
región crítica, donde esta se entiende como un mecanismo seguro para comunicar procesos
concurrentes.

Los datos contenidos en el monitor pueden ser globales (accesibles a todos los
procedimientos dentro del monitor), o locales (accesibles a un procedimiento específico). Estos
datos sólo son accesibles dentro del monitor; no hay forma de que un proceso fuera del monitor
pueda acceder a dichos datos

PASO DE MENSAJES: Es un sistema donde la comunicación se hace mediante

operaciones explícitas de envío y recepción. El Paso de Mensajes tiene la ventaja añadida de que
se presta a ser implementados tanto en sistemas distribuidos como en procesadores de memoria
compartida y los sistemas monoprocesadores.