Consideraciones Diseño Base Dato Relacional



Descargar 65,66 Kb.
Fecha de conversión11.05.2017
Tamaño65,66 Kb.
UNIDAD3

Consideraciones Diseño Base Dato Relacional
Cualidades de un buen diseño de base de datos
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.
Proporcinar 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.
Normalizacion Base Dato Relacional
El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional.
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.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla bidimensional sea considerada como una relación tiene 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 Base Dato Relacional
Dependencia funcional
Una dependencia funcional son conexiones entre uno o más atributos. Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos conocer el valor de Edad.
Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:
Fecha De Nacimiento→Edad
Aquí a Fecha De Nacimiento se le conoce como un determinante. Se puede leer de dos formas Fecha De Nacimiento determina a Edad o Edad es funcionalmente dependiente de Fecha De Nacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr mayor eficiencia en las tablas.
Dependencia funcional transitiva
Supongamos que en la relación de la figura 3.0 los estudiantes solo pueden estar matriculados en un solo curso y supongamos que los profesores solo pueden dar un curso.
ID_Estudiante → Curso_Tomando
Curso_Tomando → Profesor_Asignado
ID_Estudiante → Curso_Tomando → Profesor_Asignado
Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a través del ID_estudiante el Profesor_Asignado. Entonces en la figura 3.0 tenemos una dependencia transitiva
Primeras Formas Normales
Formas Normales
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, éste introdujo la normalización en un artículo llamado A Relational

1 FN
Primera forma normal.
Definición formal:
Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.
Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando cumple lo siguiente:
1. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.
2. Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.
3. Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
4. Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.
Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir que la mayoría de las relaciones se encuentran en la primera forma normal.
Para ejemplificar como se representan gráficamente las relaciones en primera forma normal consideremos la relación alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal, gráficamente así representamos a las relaciones en 1FN.

2 FN
Segunda forma normal (2FN)
Para poder definir la segunda forma normal es necesario saber que es una dependencia funcional, consiste en edificar que atributos dependen de otros atributos.
Una relación R se encuentra en 2FN si y solo si esta en 1FN, y los atributos no primos dependen de la llave primaria.
Una relación se encuentra en segunda forma normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave. Cada tabla que tiene un atributo único como clave, esta en segunda forma normal.

3 Fn Y Fnbc Forma Normal Boyce Cood
Tercera forma normal y la forma normal de Boyce Codd.
Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C pero no determina a A.
Tercera forma normal.
Definición formal:
Una relación R está en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria.
Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relación esta en tercera forma normal si está en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe más de una forma de llegar a referencias a un atributo de una relación.
Por ejemplo, consideremos el siguiente caso:
Tenemos la relación alumno-cursa-materia manejada anteriormente, pero ahora consideramos al elemento maestro, gráficamente lo podemos representar de la siguiente manera:
Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos, entonces tenemos:
Forma normal de Boyce Codd.
Determinante: Uno o más atributos que, de manera funcional, determinan otro atributo o atributos. En la dependencia funcional (A,B)→C, (A,B) son los determinantes.
Definición formal:
Una relación R esta en FNBC si y solo si cada determinante es una llave candidato.
Denominada por sus siglas en ingles como BCNF; Una tabla se considera en esta forma si y sólo sí cada determinante o atributo es una llave candidato.
Continuando con el ejemplo anterior, si consideramos que en la entidad alumno sus atributos control y nombre nos puede hacer referencia al atributos esp., entonces decimos que dichos atributos pueden ser llaves candidato.
Gráficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:
Obsérvese que a diferencia de la tercera forma normal, agrupamos todas las llaves candidato para formar una global (representadas en el recuadro) las cuales hacen referencia a los atributo que no son llaves candidato.

Normalizacion Adicional
Dependencia funcional
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
Sean x e y atributos (o conjunto de atributos) de una relación \!R. Se dice que y depende funcionalmente de x (se denota por x \to y) si cada valor de x tiene asociado un solo valor de y. En esta relación, a x se le denomina determinante (de y). Se dice que el atributo y es completamente dependiente de x si depende funcionalmente de y y no depende de ningún subconjunto propio de x.
Dependencia Multivaluada Y 4 Fn
Cuarta Forma Normal (4FN)
Dependencia Multivaluada y 4F
Las dependencias multivaluadas son una consecuencia de la primera forma normal, que prohíbe que un atributo de una tupla tenga un conjunto de valores. Si tenemos dos o más atributos multivaluados independientes en el mismo esquema de relación, nos enfrentamos al problema de tener que repetir todos los valores de uno de los atributos con cada valor del otro atributo para que las tuplas de la relación sigan siendo consistentes.
Ejemplo: Consideremos la relación EMPLEADOS que se muestra en la figura 3.16 (a). Una tupla de esta relación representa el hecho de que un empleado cuyo nombre es NOMBREE trabaja en el proyecto cuyo nombre es NOMBREPR y tiene un dependiente cuyo nombre es NOMBRED.
Un empleado puede trabajar en varios proyectos y tener varios dependientes, y los proyectos y dependientes de un empleado no están relacionados directamente entre sí. Para que las tuplas de la relación sean consistentes, debemos tener una tupla por cada una de las posibles combinaciones de dependiente y proyecto de un empleado como se muestra en la figura 3.16 (b). Esta restricción se especifica como una dependencia multivaluada sobre la relación EMP.
Dependencia De Juntura Y 5 Fn
Quinta Forma Normal (5FN)
Dependencia de Juntura y 5FN
Una descomposición posee la propiedad de reunión sin pérdidas. Sin embargo, en algunos casos puede ser que no exista una descomposición con reunión sin pérdidas que dé dos esquemas de relación, pero sí que produzca más de dos esquemas de relación. Estos casos se manejan con la dependencia de reunión y la quinta forma normal. Es importante señalar que estos se presentan muy rara vez y que es difícil detectarlos en la practica.
Una dependencia de reunión (DR) , denotada por DR(R1, R2, …, Rn), especificada sobre el esquema de relación R, especifica una restricción sobre los ejemplares r de R. La restricción establece que todo ejemplar permitido r de R debe tener una descomposición con reunión sin pérdidas para dar R1, R2, …, R;
Una dependencia multivaluada es un caso especial de una DR donde n = 2. Una dependencia de reunión DR (R1, R2, …, Rn), especificada sobre el esquema de relación R, es una DR trivial si uno de los esquemas de relación Ri en DR (R1, R2, …,Rn) es igual a R. Se dice que tal dependencia es trivial porque posee la propiedad de reunión sin pérdidas para cualquier ejemplar de relación r de R y, por tanto, no especifica ninguna restricción sobre R. Ahora podemos especificar la Quinta Forma Normal , que también se denomina forma normal de proyección-reunión .
Quinta Forma Normal (5FN)
Un esquema R está en quinta forma normal (5FN) o forma normal de proyección-reunión (FNPR) respecto a un conjunto F de dependencias funcionales, multivaluadas y de reunión si, para cada dependencia de reunión no trivial DR (R1, R2, …, Rn) en F+ (esto es, implicada por F), toda Ri es una superclave de R.
Integridad Bases Datos Concepto
La integridad significa que todos los datos requeridos para responder a una pregunta específica están disponibles. Por ejemplo, un marcador de béisbol debe incluir el tanteo de ambos equipos. Si se oye el tanteo “New York 6″ y no oyes el del oponente, el anuncio será incompleto y sin sentido.
Los datos son inequívocos cuando el contexto es claro. Por ejemplo, el grupo de signos 2-x puede parecer “la cantidad 2 menos la cantidad desconocida llamada x” para un estudiante de álgebra, pero puede significar “2 barra x” a un vaquero que marca ganado. Tenemos que conocer el contexto de estos símbolos antes de poder conocer su significado.
Restricciones Basicas
Restricciones
Restricción de Valores Nulos
Si muchos de los tributos no se aplican a todas las tuplas de la relación, es decir, son nulos, se acabará con un gran número de nulos en esas tuplas.
Esto puede originar un considerable desperdicio en el nivel de almacenamiento y posiblemente dificultar el entendimiento del significado de los atributos y la especificación de operaciones de reunión con en el nivel lógico.
Restricciones de Llave
Esta restricción, es una de las restricciones estándar que con frecuencia aparecen en las aplicaciones de bases de datos. Estas restricciones se manejan de formas ligeramente distintas en los diversos modelos de datos. En el modelo E-R, una clave es un atributo de un tipo de entidades que debe tener un valor único para cada entidad que pertenezca a dicho tipo en cualquier momento específico. Así el valor del atributo clave puede servir para identificar de manera única cada entidad. Los atributos claves deben ser monovaluados, pero pueden ser simples o compuestos.
Un tipo de entidades normal puede tener una o más claves; un tipo de entidades débil no tiene clave, pero casi siempre tiene una clave parcial cuyos valores identifican de manera única las entidades débiles que están relacionadas a la misma entidad propietario a través de un vínculo identificador.
Restricción de Dominio
Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor atómico del dominio Dom(A) para ese atributo. Los tipos de datos asociados a los dominios por lo general incluyen:
Datos Numéricos Estándar de los números Enteros (como Entero- Corto, Entero, Entero-Largo),
Datos Numéricos Reales (Flotante y Flotante de Doble Precisión).
Caracteres,
Cadenas de longitud fija, y
Cadenas de longitud variable, así como
Tipos de datos de fecha,
Hora,
Marca de Tiempo y
Dinero.
Otros dominios posibles se pueden describir mediante un intervalo de valores de un tipo de datos o como un tipo de datos enumerado en el que se listan explícitamente todos los valores posibles.
Restricción de Aserción
Una técnica más formal para representar restricciones explícitas es con un lenguaje de especificación de restricciones, que suele basarse en alguna variación del cálculo relacional. Este enfoque declarativo establece una separación clara entre la base de restricciones (en la que las restricciones se almacenan en una forma codificada apropiada) y el subsistema de control de integridad del SGBD (que tiene acceso a la base de restricciones para aplicar estas últimas correctamente a las transacciones afectadas).
Cuando se usa esta técnica, las restricciones suelen llamarse aserciones . Se ha sugerido el uso de esta estrategia con SGBD relaciónales. El subsistema de control de integridad compila las aserciones, que entonces se almacenan en el catalogo del SGBD, donde el subsistema de control de integridad puede consultarlas e imponerlas automáticamente. Esta estrategia es muy atractiva desde el punto de vista de los usuarios y programadores por su flexibilidad.
ITSP
Integridad Entidad
Integridad de entidad
La integridad de entidad define una fila como una única instancia de una entidad para una tabla en particular. La integridad de entidad asegura la integridad de la columna de identificación o la clave primaria de una tabla ( a través de índices, estricciones UNIQUE, restricciones PRIMARY KEY, o propiedades IDENTITY).
Integridad Referencial
La base de datos no debe conter valores de clave ajena sin concordancia. Así como los valores de clave primaria representan identificadores de entidades, las claves ajenas representan referencia a entidades.
La regla dice: Si B hace referencia a A entonces A debe existir.
Surgen los siguientes dos puntos: - La integridad referencial exige concordancia en las claves ajenas, con las claves primerias, no con la claves alternativas. - Los conceptos de clave ajena e integridad referencial se definen uno en termino del otro.
Reglas De Relacion
Reglas de Relación Según [Elmasri / Navathe]
• Orden de las tuplas en una relación : una relación se define como un conjunto de tuplas matemáticamente, los elementos de un conjunto no están ordenados; por tanto, las tuplas de una relación no tienen orden específico.
El ordenamiento de las tuplas no forma parte de la definición de una relación, porque la relación intenta representar los hechos en un nivel lógico abstracto.
• Orden de los valores dentro de una tupla, y definición alternativa de relación : Una tupla es una lista ordenada de n valores, así que el orden de los valores de una tupla y por tanto de los atributos en la definición de un esquema de relación es importante. No obstante, en un nivel lógico, el orden de los atributos y de sus valores en realidad no es importante en tanto se mantengas la correspondencia entre atributos y valores.
• Valores en las Tuplas: Cada valor en una tupla es un valor atómico; esto es, no es divisible en componentes en lo que respecta al modelo relacional. Por ello no se permiten valores compuestos ni multivaluados.




Reglas De Negocios
Reglas de negocio
La forma de interpretar las reglas de negocio aplicadas en base de datos, las puedes considerar como sigue:
es cualquier restricción, necesidad, requerimiento, o actividad especial que debe ser verificada al momento de intentar grabar información, borrar, actualizar o consultar la ya existente.
Ejemplo, puedes definir un campo o una tabla que contenga información relacionada los clientes a los que se les vende algún determinado producto. Tal vez, la regla te indique, que las claves para determinados clientes de una determinada región empiece con A, para otros con B y así con las claves, pero con los nombres u otros determinantes de identificación con un determinado valor, ISO, algo así.
Seguridad Bases De Datos
Seguridad
La seguridad de la base de datos esta implementada en varios niveles:



  • Protección de los ficheros de la base de datos. Todos los ficheros almacenados en la base de datos estan protegidos contra escritura por cualquier cuenta que no sea la del superusuario de Postgres.

  • Las conexiones de los clientes al servidor de la base de datos estan permitidas, por defecto, únicamente mediante sockets Unix locales y no mendiante sockets TCP/IP. Ha de arrancarse el demonio con la opcion -i para permitir la conexion de clientes no locales.

  • Las conexiones de los clientes se pueden restringir por dirección IP y/o por nombre de usuario mediante el fichero pg_hba.conf situado en PG_DATA.

  • Las conexiones de los clientes pueden ser autentificadas mediante otros paquetes externos.

  • A cada usuario de Postgres se le asigna un nombre de usuario y (opcionalmente) una contraseña. Por defecto, los usarios no tienen permiso de escritura a bases de datos que no hayan creado.

  • Los usuarios pueden ser incluidos en grupos, y el acceso a las tablas puede restringirse en base a esos grupos.

Concepto Seguridad Base Datos
Concepto de seguridad de Base de Datos
Consiste en las acciones que toma el diseñador de base de datos al momento de crear la base de datos, tomando en cuenta el volumen de las transacciones y las restricciones que tiene que especificar en el acceso a los datos; esto permitirá que el usuario adecuado sea quién visualice la información adecuada.
Autenticacion Y Autorizacion Base De Datos
AUTORIZACIÓN
Proceso de permitir al acceso de una persona a un sistema.
Los usuarios pueden tener varios tipos de autorización para diferentes partes de la base de datos:
Autorización de lectura: permite la lectura de los datos, pero no su modificación.
Autorización de inserción: permite la inserción de nuevos datos, pero no la modificación de los ya existentes.
Autorización de actualización: permite la modificación de los datos, pero no su borrado.
Autorización de borrado: permite el borrado de los datos.
MODIFICAR EL ESQUEMA DE LA BD
Autorización de índices. Permite la creación y borrado de los índices.
Autorización de recursos: permite la creación de nuevas relaciones.
Autorización de alteración: permite el añado o el borrado de atributos de las relaciones.
Autorización de eliminación: permite el borrado de las relaciones.
DIFERENCIA
Las autorizaciones de eliminación y borrado se diferencian en que la autorización de borrado sólo permite el borrado de tuplas. Si un usuario borra todas las tuplas de una relación, la relación sigue existiendo, pero vacía; en cambio si se elimina una relación, deja de existir completamente.
AUTENTICACIÓN
Se refiere a la tarea de verificar la identidad de una persona o software que se conecte a una BD; es decir consiste en una contraseña secreta que se debe presentar cuando se abra una conexión a la BD.
USO
La autenticación basada en palabras clave es ampliamente usada por los sistemas operativos y bases de datos.
EJEMPLOS:
Sistema de desafío respuesta. El sistema de BD envía una cadena de desafío al usuario. El usuario cifra la cadena de desafío usando una contraseña secreta como clave de cifrado y devuelve el resultado.
El sistema de bases de datos puede verificar la autenticidad del usuario descifrando la cadena con la misma contraseña secreta y comparando el resultado con la cadena de desafío original.
=Este esquema asegura que las contraseñas no circulen por la red=
Firmas digitales. Este se usa para verificar la autenticidad de los datos; las firmas digitales desempeñan el papel electrónico de las firmas físicas en los documentos.
La clave privada es usada para firmar los datos y los datos firmados se pueden hacer públicos; cualquiera podría verificarlos con la clave pública, pero nadie podría haber generado los datos codificados sin tener la clave privada. Por lo tanto se puede comprobar que los datos fueron creados realmente por la persona que afirma haberlos creado.
Rol Y Privilegios Usuarios
Un rol es un papel desempeñado por un individuo dentro de un conjunto de personas. En la base de datos, siempre existen un conjunto de personas que harán uso de ella, las acciones que pueden hacer son: visualización, modificación, agregación, eliminación de registros entre algunas otras, y la regla que permite esto es conocida como privilegio.
Un ejemplo de un sistema punto de venta en donde existen usuarios tales como: encargado de caja, supervisor de caja y gerente general, todos estos son usuarios de un sistema de base de datos, la forma en que se comportaran dentro de la BD es muy diferente. El encargado de caja, no podrá modificar o visualizar ciertos registros que se encuentren en otra terminal, el supervisor de caja tendrá más privilegios al poder accesar a los registros de todas las terminales sin poder crear informes mensuales o trimestrales y por último el gerente general podrá hacer todo lo que los dos anteriores y por supuesto podrá crear informes y todas las acciones que el SGBD le permita.




Vistas Y Seguridad
Los mecanismo de seguridad se ocupan, entre otras cosas, de lo siguiente:
prevenir accesos no autorizados a la base de datos.
prevenir accesos no autorizados a objetos (tablas, vistas, índices, procedimientos, etc) pertenecientes a un usuario.
controlar el uso del disco.
controlar el uso de los recursos del sistema (Por ejemplo: el tiempo de CPU)
monitorear las acciones de los usuarios
Asociado con cada usuario de la base de datos existe un esquema con el mismo nombre. Un esquema es un conjunto lógico de objetos (tablas, vistas, sinónimos, índices, procedimientos, funciones, etc). Por defecto, cada usuario de la base de datos crea y tiene acceso a todos los objetos en su correspondiente esquema .
La seguridad de la base de datos puede ser clasificada en dos categorías distintas:
Seguridad del sistema
Seguridad de los datos
La Seguridad del Sistema posee los mecanismos que controlan el acceso y el uso de la base de datos a nivel del sistema.
Incluye:
combinación válida de usuario y clave de acceso
la cantidad de espacio en disco disponible para los objetos de los usuarios
la limitación de los recursos para un usuario
La Seguridad de los Datos posee los mecanismos que controlan el acceso y el uso de la base de datos a nivel de los objetos.
Incluye:
qué usuarios tienen acceso a un esquema de objetos específico y qué acciones les está permitido desarrollar sobre esos objetos.
las acciones que son monitoreadas por cada esquema.
Recuperacion Bases De Datos
La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA’s.
La recuperabilidad, frecuentemente denominada “recuperación de desastres”, tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos ó bugs que pudieran haber corrompido los respaldos.
Transacciones
Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.



  • BEGIN TRAN: Especifica que va a empezar una transacción.

  • COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.

  • ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.

En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento. Un ejemplo de transacción [editar]
Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la consistencia del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.
Definicion De Transaccion
Una transacción en un sistema de gestión de bases de datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured query language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.
BEGIN TRAN: Especifica que va a empezar una transacción.
COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.
ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.
Un ejemplo de transacción [editar]Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la consistencia del sistema (es decir, para que no aparezca o desaparezca dinero), los dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.
Reglas De Base De Datos
Regla 0
Para que un sistema se denomine sistema de administración de bases de datos relacionales, debe usar (exclusivamente) sus capacidades relacionales para gestionar la base de datos.
Regla 2: regla del acceso garantizado
Para todos y cada uno de los datos (valores atómicos) de una Base de Datos Relacional (BDR) se garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.
Cualquier dato almacenado en una BDR tiene que poder ser direccionado unívocamente. Para ello hay que indicar en qué tabla está, cuál es la columna y cuál es la fila (mediante la clave primaria).
Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas implementaciones. En estos casos, para lograr un efecto similar se puede hacer lo siguiente:
Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).
Crear un índice único sobre la clave primaria.
No eliminar nunca el índice.
Regla 3: tratamiento sistemático de valores nulos
Los valores nulos (que son distintos de la cadena vacía, blancos, 0, …) se soportan en los SGBD totalmente relacionales para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos.
Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento sistemático de los mismos.
Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lógicas.
Lógica trivaluada. En una posible solución. Existen tres (no dos) valores de verdad: Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones lógicas:
null Y null = null
Verdadero Y null = null
Falso Y null = Falso
Verdadero O null = Verdadero
etc.
Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica pues es más difícil de entender.
Regla 4: diccionario dinámico en línea basado en el modelo relacional
La descripción de la base de datos se representa a nivel lógico de la misma manera que los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales.
Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se almacenan usando el modelo relacional, con todas las consecuencias.
Regla 5: regla del sublenguaje de datos completo
Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ej: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
Definición de datos
Definición de vistas
Manipulación de datos (interactiva y por programa)
Limitantes de integridad
Limitantes de transacción (iniciar, realizar, deshacer) (Begin, commit, rollback).
Además de poder tener interfaces más amigables para hacer consultas, etc. siempre debe de haber una manera de hacerlo todo de manera textual, que es tanto como decir que pueda ser incorporada en un programa tradicional.
Un lenguaje que cumple esto en gran medida es SQL.
Regla 6: regla de actualización de vistas
Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.
El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no está muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.
Regla 7: inserción, actualización y borrado de alto nivel
La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la recuperación de los datos (consultas), si no también a la inserción, actualización y borrado de datos.
Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una (un registro de cada vez).
Regla 8: independencia física de datos
Los programas de aplicación y actividades del terminal permanecen inalterados a nivel fisico cuandoquiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.
El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.
• es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualización de datos. la independencia física se refiere sólo a la separación entre las aplicaciones y las estructuras físicas de almacenamiento.
Regla 9: independencia lógica de datos
Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen cambios a las tablas base que preserven la información.
Cuando se modifica el esquema lógico preservando información (no valdría p.ej. eliminar un atributo) no es necesario modificar nada en niveles superiores.
Ejemplos de cambios que preservan la información:
Añadir un atributo a una tabla base.
Sustituir dos tablas base por la unión de las mismas. Usando vistas de la unión puedo recrear las tablas anteriores…
Regla 10: independencia de integridad
Los limitantes de integridad específicos para una determinada base de datos relacional deben poder ser definidos en el sublenguaje de datos relacional, y almacenables en el catálogo, no en los programas de aplicación.
El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus relaciones y evitar que estas (limitantes) se codifiquen en los programas. Por tanto en una BDR se deben poder definir limitantes de integridad.
Cada vez se van ampliando más los tipos de limitantes de integridad que se pueden utilizar en los SGBDR, aunque hasta hace poco eran muy escasos.
Como parte de los limitantes inherentes al modelo relacional (forman parte de su definición) están:
Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una clave primaria.
Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe existir en la relación donde es primaria.
Regla 11: independencia de distribución
Una BDR tiene independencia de distribución.
Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una distribuida.
Las BDR son fácilmente distribuibles:
Se parten las tablas en fragmentos que se distribuyen.
Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los fragmentos.
Sin embargo se complica más la gestión interna de la integridad, etc.
Esta regla es responsable de tres tipos de transparencia de distribución:
Transparencia de localización. El usuario tiene la impresión de que trabaja con una BD local. (aspecto de la regla de independencia física)
Transparencia de fragmentación. El usuario no se da cuenta de que la relación con que trabaja está fragmentada. (aspecto de la regla de independencia lógica de datos).
Transparencia de replicación. El usuario no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares.
Regla 12: regla de la no subversión
Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto nivel (una relación (conjunto de registros) de cada vez)
Algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel.
Normalmente se usa SQL inmerso en un lenguaje anfitrión para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una relación. En cualquier caso no debe ser posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel
Propiedades De Atomicidad Consistencia Aislamiento Y Durabilidad Acid
PROPIEDADES (deseables) DE UNA TRANSACCIÓN
Se suele hacer referencia a estas como las propiedades ACID (por sus iniciales en inglés).
1. Atomicidad
Todas las operaciones de la transacción son ejecutadas por completo, o no se ejecuta ninguna
de ellas (si se ejecuta la transacción, se hace hasta el final).
2. Consistencia
Una transacción T transforma un estado consistente de la base de datos en otro estado consistente,
aunque T no tiene por qué preservar la consistencia en todos los puntos intermedios de
su ejecución. Un ejemplo es el de la transferencia de una cantidad de dinero entre dos cuentas
bancarias.
3. Aislamiento (Isolation)
Una transacción está aislada del resto de transacciones.
Aunque existan muchas transacciones ejecutándose a la vez, cualquier modificación de datos
que realice T está oculta para el resto de transacciones hasta que T sea confirmada (realiza
COMMIT).
Es decir, para cualesquiera T1 y T2, se cumple que
- T1 ve las actualizaciones de T2 después de que T2 realice COMMIT, o bien
- T2 ve las modificaciones de T1, después de que T1 haga un COMMIT
Pero nunca se cumplen ambas cosas al mismo tiempo.
Nota: esta propiedad puede no imponerse de forma estricta2; de hecho, suelen definirse niveles
de aislamiento de las transacciones.
4. Durabilidad
Una vez que se confirma una transacción, sus actualizaciones sobreviven cualquier fallo del sistema.
Las modificaciones ya no se pierden, aunque el sistema falle justo después de realizar dicha
confirmación.
El Subsistema de Recuperación del SGBD es el encargado de conseguir el cumplimiento de las
propiedades de atomicidad y durabilidad de las transacciones.
La conservación de la consistencia es una propiedad cuyo cumplimiento han de asegurar, por un
lado los programadores de base de datos, y por otro el Subsistema de Integridad del SGBD.
El Subsistema de Control de Concurrencia es el encargado de conseguir el aislamiento de las transacciones
Estados De Las Transacciones
El coordinador de transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para cada una de estas transacciones, el coordinador debe:
Iniciar la ejecución de la transacción.
Dividir la transacción en varias subtransacciones, las cuales ha de distribuir en las localidades apropiadas para su ejecución.
Coordinar la terminación de la transacción, ya sea que quede ejecutada o abortada en todas las localidades.
Bitacora
Cuaderno Bitácora es un gestor de información personal que te permitirá organizar tus colecciones de libros, discos, vídeos, software y direcciones de Internet.
Este manual te brinda toda la información necesaria para que puedas utilizar el programa sin ningún inconveniente.
Tipos De Bitacora
Bitácora Incremental con Actualizaciones Diferidas
Bitácora Incremental con Actualizaciones InmediatasEn la bitácora incremental con actualizaciones inmediatas si se permiten salidas a disco.En la bitácora se almacena un registro de comienzo:< Ti start >Un registro de modificación:< Ti, X, xa, xn > donde:- Ti es la transacción.- X es el valor que queremos modificar.- xa es el valor antiguo de X.- xn es el valor nuevo de X.Un registro de fin de fin de transacción:< Ti commit >La bitácora debe estar entera hasta commit para que la transacción este cometida.
Contenido De Bitacora

Para que no tengamos que revisar toda la bitácora cuando cae el sistema, el sistema cada cierto tiempo pone un checkpoint que es un registro que asegura que desde hay hasta el principio de la bitácora esta asegurado.Si cae el sistema, este revisa hasta la transacción en la que esta el checkpoint. El funcionamiento es desde el final hasta el checkpoint va haciendo Unidosy cuando llega al checkpoint vuelve para abajo haciendo Redos.Es decir la bitácora contiene un registro de las modificaciones de los datos en orden cronológico. Las transacciones se escriben en la bitácora, antes de su aplicación a la base de datos. Si el sistema se cae antes de que la transacción haya sido registrada y el momento en que se aplica, en el peor de los casos, existe un registro de una transacción no aplicada. Si las transacciones fueron aplicadas antes de su inclusión en la bitácora, seria posible modificar la base de datos, pero no tener registro del cambio.


Diccionario De Datos Concepto
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
Contenido Y Funcion Diccionario Datos
El diccionario de datos almacena información acerca de la estructura de la base de datos, y la información de autorización, y datos acerca de las relaciones.Tipos de información que el sistema debe almacenar están:

• Los nombres de las relaciones.

• Los nombres de los atributos de cada relación.

• Los dominios de los atributos.

• Los nombres de las vistas definidas en la base de datos y la definición de esas vistas.

• Las restricciones de integridad de cada relación (por ejemplo, las restricciones e clave).

Además de esto, muchos sistemas conservan los datos siguientes de los usuarios del sistema:• Nombres de los usuarios autorizados.• Información contable acerca de los usuarios.En los sistemas que utilizan estructuras altamente sofisticadas para almacenar relaciones, pueden conservarse datos estadísticos y descriptivos acerca de las relaciones:• Número de tuplas en cada relación.• Método de almacenamiento utilizado para cada relación (por ejemplo, agrupado o sin agrupar).

Tipos Diccionario Datos

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los elementos datos y estructura de datos.Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos.Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema.Estructura de datos: es un grupo de datos que están relacionados con otros y que en conjunto describen un componente del sistema.Descripción: Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjunción con alguna otra.Y por su funcion se divide en:

Diccionario de datos Activo: Es un diccionario cuyas entradas son modificadas en forma automática por el software, siempre que ocurran modificaciones en la escritura de la base de datos.



Diccionario de datos Pasivo: necesitan ser actualizados en forma separada, para hacer modificaciones en la base de datos, de lo contrario no reflejarán con exactitud el estado de la base de datos.

Los diccionarios de datos activos cuestan más, pero son seguros y se actualizan constantemente; no están disponibles con todos los productos DBMS.Los diccionarios de datos pasivos son menos costosos que los activos, pero se requiere de mayor esfuerzo para mantenerlos actualizados. Cualquiera de ellos es una gran ayuda al DBA para registrar y rastrear nombres, formatos, relaciones y referencias cruzadas de los datos.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal