Mora Marquez Luis Omar 07210172Martinez Martinez Armando 07210167

Anguiano Aguirre Javier 072101

Unidad 3Diseño de base de datos

relacionados.

Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseño de la base de datos, quizá las más fuertes sean:

• La velocidad de acceso.• El tamaño de la información. • El tipo de la información.• Facilidad de acceso a la información.• Facilidad para extraer la información requerida.• El comportamiento del manejador de bases de datos con cada tipo de

información.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia mas alto en lo que se refiere a almacenamiento y recuperación de la información.

Diseño de Bases de Datos.

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.

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

3.2 Normalización.

Una dependencia funcional es una conexión entre uno o más atributos.

Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento Edad.

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.

3.2.1 Dependencias funcionales.

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.

• Propiedades de la Dependencia funcional.Existen 3 axiomas de Armstrong:

• Dependencia funcional Reflexiva.Si "y" está incluido en "x" entonces x ySi la dirección o el nombre de una persona están incluidos en el

DNI, entonces con el DNI podemos determinar la dirección o su nombre.

• Dependencia funcional Aumentativa.entonces DNI nombreDNI,dirección nombre,direcciónSi con el DNI se determina el nombre de una persona, entonces

con el DNI más la dirección también se determina el nombre o su dirección.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:

X Y Z entonces X ZFechaDeNacimiento EdadEdad ConducirFechaDeNacimiento Edad Conducir.

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

Dependencia funcional transitiva

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.

Formas Normales

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.

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 BD

Primera Forma Normal (1FN)

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

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:

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.

Una dependencia funcional 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 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.

Segunda Forma Normal (2FN)

La segunda forma normal se representa por dependencias funcionales como:

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

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.

Tercera Forma Normal (3FN)

Ejemplo de 3FN.

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante.

Forma normal de Boyce-Codd (FNBC).

• Ejemplo grafico de fnbc.

3.5Recuperación debases 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óny 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.

3.5.1.1 Definición de transacción. 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.

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

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.

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

Estoy invitando a todos los maestros y profesionales de esta area y/o carrera a colaborar construyendo este sitio dedicado a esta hermosa y util profesion aportando el material apropiado a cada uno de los mas de 1,000 temas que lo componen.  

3.5.2 Bitácora. 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.

3.5.2.1 Tipos de bitácora. • 1. Blogs Políticos: Se caracterizan por mostrar noticias

políticas, activismo o cualquier actividad relacionada a personalidades política, se usan tambien como blogs para realizar campañas.

• 2. Blogs Personales: Conocidos como diarios online, usualmente sus propietarios escriben acerca de su día a día, lo que más encontrarás son temas muy personales, que quizás sólo a ellos les interese, pero resulta que construyen una fuerte comunidad afin a ellos.

• 3. Blog temático: Se enfocan en un determinado nicho de mercado, rara vez comentan de otra cosa que no sea su temática.

• 4. Blogs de Salud: De hecho caben dentro de los blogs temáticos, pero se diferencian por los temas tratados, independientemente que sean temáticos, hablan sobre temas de salud, encabezados en su mayoría por personal médico.

• 5. Blogs literarios: Pueden confundirse con los blogs personales, pero en los blogs literarios se escribe y comenta exclusivamente de poesía.

• 6. Blogs de viajes: encontraremos en estos blogs comentarios y experiencias de los viajeros por determinadas ciudades, países, etc.

• 7. Blogs investigativos: Generalmente son académicos, se publican anotaciones, investigaciones y artículos enfocados en el “Dar a conocer” los resultados de un estudio.

• 8. Blog Legal: Sobre temas de Leyes.

• 9. Media blog: enfocado principalmente en inconsistencias o deficiencias en productos informáticos (Gadgets).

• 10. Blogs Religiosos: Se enfocan en temas religiosos

• 11. Blog educativo: La finalidad de estos blogs es compartir el conocimiento, sus autores destacan en determinadas áreas y comparten lo que saben con la comunidad que los lee y sigue.

• 12. Blogs Colectivos: Escrito por gente perteneciente a determinado grupo en un determinado tema, en este tipo de blogs vemos como escriben muchas personas pero siempre dentro de la misma temática.

• 13. Directorios de Blogs: Su nombre lo indica, es una colección enorme de blogs en la red.

• 14. Blog de Negocios ó Corporativo: utilizado or las empresas para informar a su clientela del quehacer de la empresa y aplicaciones nuevas, es una canal de comunicación que ha dado muy buenos resultados a empresas de todo tamaño en el Soporte Técnico y una valiosa fuente de retroalimentación

3.5.2.2 Contenido de la bitácora.

El contenido de la bitácora se muestra en la ventana 5 de la pantalla de dBase; generalmente este contenido corresponde al ítem que tiene foco en la ventana superior (1) que está activa (sus miembros están en negrita), pero recuerde que no siempre es necesariamente así.  Esta es una ventana multiuso, de forma que la bitácora mostrada también puede pertenecer al ítem seleccionado en una de las ventanas inferiores de enlaces (2) o a un ítem de una ventana de resultados.

3.6 Diccionario de datos. 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.