Base de Parcial

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.

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:

Relación

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:

PERSONA

TAREAS LABORALES

TRABAJOSPERSONAS

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 características propias de la asociación entre varias entidades.

Ejemplos de relaciones son las siguientes:

Relación Binaria

Relación Ternaria

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:

Relación Doble

Relación Reflexiva

Jugador EquipoJugar

1:N

1,0

0,1

UnoMuchos

De uno a muchosDe cero a muchos

De cero a uno

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:

JUGADOR JUGADOR

JUGADOR

JUEGA

ENTRENA

Teléfono

Fecha Mes

Día

Un ejemplo de este tipo seria el siguiente:

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).

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.

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. EdadCarlos Cortés 489-22-

1100C/ Libertad 265 749-6492 28

Bárbara Benet 839-8461 C/ Fontana 738 749-1253 20Marí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

DNINOMBRE EDAD

1233344CMARÍA 50

12374678GDANIEL 25

28238232HKARLA 30

Nombre: ClienteEsquema: 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. NULOSCuando 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 emails111 Juan Pérez Jefe de Área 3000 [email protected]; [email protected] José Sánchez Administrativo 1500 [email protected] Ana Díaz Administrativo 1500 [email protected]; [email protected]... ... ... ... ...

Tabla 1

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

nss nombre puesto salario email111 Juan Pérez Jefe de Área 3000 [email protected] Juan Pérez Jefe de Área 3000 [email protected] José Sánchez Administrativo 1500 [email protected] Ana Díaz Administrativo 1500 [email protected] Ana Díaz Administrativo 1500 [email protected]... ... ... ... ...

Tabla 2

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

nss nombre puesto salario111 Juan Pérez Jefe de Área 3000222 José Sánchez Administrativo 1500333 Ana Díaz Administrativo 1500... ... ... ...

Tabla 3

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

nss email

111 [email protected]





... ...

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






... ...

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 puesto111 Juan Pérez Jefe de Área222 José Sánchez Administrativo333 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:

Tlf:

Dirección:

#Tarjeta:

Vigencia:

Banco:

Email:

Recomendado:

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 relacionalMuestra 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


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:


Id Nombre Color

10 Ángel Azul

20 Luis Rojo

30 Jesús Verde

40 David Amarillo


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:


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


10 Ángel Azul 25 2


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:

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

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

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)

Por ejemplo:

tabla1 (x,y, nombre)

tabla1

x y nombre

A 4 Fulginio

A 6 Cascanio

B 3 Melania

C 4 Juanita

C 7 Antonio

D 2 Fernando

D 5 Ana

tabla2 (x,y, numero)

tabla2

x y numero

A 3 120

A 6 145

B 2 250

B 5 450

C 4 140

D 2 130

D 5 302

tabla1 [tabla1.x = tabla2.x Y tabla1.y = tabla2.y] tabla2

x y nombre número

A 6 Cascanio 145

C 4 Juanita 140

D 2 Fernando 130

D 5 Ana 302

División (:): Si R y S son relaciones de grado G1 y G2 respectivamente, y A es el conjunto de atributos comunes a ambas relaciones; R:S obtiene una relación de grado G1-G2 en la que las tupIas resultantes son las tupIas formadas por los atributos distintos de A que poseen todos los valores posibles de A en la tabla S. Es decir, se obtienen las tupIas cuyos contenidos en los atributos comunes poseen todas las combinaciones almacenadas en S.

Por ejemplo:

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

S

R÷S

R

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 (Transact-SQL)

Tablas de trasvase de registros (Transact-SQL)

Tablas de captura de datos de cambio (Transact-SQL)

Tablas de replicación (Transact-SQL)

Tablas de planes de mantenimiento de bases de datos (Transact-SQL)

Tablas de Agente SQL Server (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 sistemaPara 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 mensajeContrato de servicioServicio

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:

EnsambladoDispositivo de copia de seguridadCatálogo de texto completoFunción de particiónEsquema de particiónGrupo de archivosClave 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,

http://es.wikipedia.org/wiki/BBCode

http://es.wikipedia.org/wiki/Ban

http://es.wikipedia.org/wiki/Multiusuario

http://es.wikipedia.org/wiki/Hilo_en_sistemas_operativos

http://es.wikipedia.org/wiki/Modelo_relacional

http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datos

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

http://www.monografias.com/trabajos901/evolucion-historica-concepciones-tiempo/evolucion-historica-concepciones-tiempo.shtml

http://www.monografias.com/trabajos16/romano-limitaciones/romano-limitaciones.shtml

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óncomoTi: 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.

SERIALIZACIÓN DE LOS BLOQUEOS DE LECTURA/ESCRITURALa 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

LECTURA ESCRITURALECTURA Compatible IncompatibleESCRITURA Incompatible Incompatible

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.

Base de Parcial

Documents

Transcript of Base de Parcial