TIPOS DE PRINCIOS DE I.U

Consistencia

 Siempre que sea posible , la interfaz debe ser consistente en el sentido de que las operaciones comparables se activan de la misma forma.

Mínima sorpresa

 El comportamiento del sistema no debe provocar sorpresa a los usuarios.

Recuperabilidad

La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de los errores. Esto puede ser de dos formas: Confirmación de acciones destructivas.Proveer de un recurso para deshacer

Guía al usuario

 Cuando los errores ocurren , la interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto.

Diversidad de usuarios

 La interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios.

principios de diseño I.U

principios de diseño I.U

Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU gráficas, como para la Web.Familiaridad del usuario: Utilizar términos y conceptos que se toman de la experiencia de las personas que más utilizan el sistema.

DISEÑO DE I.U

DISEÑO DE I.U

Conjunto de elementos a través de los

cuales un usuario interactúa con un objeto que realiza una

determinada tarea. (Televisor, teléfono, coche, despertador,

puerta, ...)El ser humano interactúa con los objetos que le rodean, y

tiene unas expectativas de cómo deben comportarse, basas en experiencias anteriores con ellos.

DEFINICION DE I.U

La interfaz de usuario

La interfaz de usuario (I.U) es uno de los componentes más importantes de cualquier sistema computacional, pues funciona como el vínculo entre el humano y la máquina. La interfaz de usuario es un conjunto de protocolos y técnicas para el intercambio de información entre una aplicación computacional y el usuario. La IU es responsable de solicitar comando al usuario, y de desplegar los resultados de la aplicación de una manera comprensible. La IU no es responsable de los cálculos de la aplicación, ni del almacenamiento, recuperación y transmisión de la información.

NORMALIZACION DE BASE DE DATOS

NORMALIZACIÓN 

El proceso de normalización de bases de datos consiste en designar y 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.

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

Terminología equivalente

o    relación = tabla o archivo

o    tupla = registro, fila o renglón

o    atributo = campo o columna

o    base de datos = banco de datos

o    dependencia multivaluada = dependencia multivalor

o    clave = llave

o    clave primaria = superclave

o    clave ajena = clave extranjera o clave foránea

o    RDBMS = del inglés Relational Data Base Manager System que significa, Sistema Gestor de Base de Datos Relacionales

Tercera Forma Normal (3FN)

Base De Datos

Tercera Forma Normal (3FN)

La Tercera Forma Normal (3FN), consiste en que ningún atributo dato. que depende de la PK, dependa de otro atributo dato. Es decir, no debe tener DEPENDENCIA TRANSITIVA. Hacemos la siguiente analogía.

Para que los Datos estén en 3FN, deben estar en 2FN y NO DEBEN tener Dependencia Transitiva DT.

X ---> Y --->Z

Ejemplo 1:

En este cuadro, tendríamos como Clave Primaria al C_Evento y los demás atributos dependen de la PK. Sin embargo, vemos que la Dirección del local T_Dirección depende del nombre del Local donde se realiza el evento. Para resolver este problema y tener un mejor almacenamiento de datos, la 3FN hace que creemos una 2da tabla haciendo PK al Nombre del local teniendo como atributo dato a la Dirección.

Ejemplo 2:

(N_Torneo) ---> (#_Año, N_Ganador, D_Nacimiento_Ganador).

Con la 3FN quedaría así:

(N_Ganador) ---> (D_Nacimiento_Ganador).

Ejemplo 3:

(C_Personal) ---> (N_Personal, D_Nacimiento, F_Mayor_Edad_Personal).

(D_Nacimiento_Personal) ---> (F_Mayor_Edad_Personal).

Ejemplo 4:

(#_Boleto) ---> (N_Cliente, N_Empresa, D_Dirección_Empresa, $_Precio).

(#_Boleto) ---> (N_Cliente, N_Empresa, $_Precio).

(N_Empresa) ---> (D_Dirección_Empresa).

Fallas en la 3FN

La falla que existe en la 3FN es que no se aplica por creer que los atributos dato se encuentran en la 4FN, la de multivalor.

Error: (C_Alumno) ---> (N_Alumno, N_Curso1, N_Curso2, N_Curso3).

(C_Alumno) ---> (N_Curso1, N_Curso2, N_Curso3).

La Segunda Forma Normal (2FN)

Base de Datos

La Segunda Forma Normal (2FN)

La regla de la Segunda Forma Normal (2FN) establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. 

Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada. 

Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales, por ejemplo:

• Puede añadir nuevas columnas a una tabla sin afectar a las demás tablas. 
• Lo mismo aplica para las otras tablas.
• Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados. 

Ejemplos:

 

Como ya habíamos utilizado este ejemplo en la entrada anterior, ahora podemos utilizar la 2FN para poder administrar mejor los datos.

 

Esto denota la diferencia que existe entre la 1FN que incluía los datos del lector,en la tabla Libro sin que exista dependencia de código entre ellos.

Otro Ejemplo:

 

El primary key de la tabla alumnos es el N° de DNI por lo que en tabla asistencia para vincular al alumno con la asistencia, solo se necesitaría el N° de  DNI.

Ejemplos de Anomalias 2FN:

                                                  Ganadores del torneo

Torneo	Año	Ganador	Fecha de nacimiento del ganador
Des Moines Masters	1998	Chip Masterson	14 de marzo de 1977
Indiana Invitational	1998	Al Fredrickson	21 de julio de 1975
Cleveland Open	1999	Bob Albertson	28 de septiembre de 1968
Des Moines Masters	1999	Al Fredrickson	21 de julio de 1975
Indiana Invitational	1999	Chip Masterson	14 de marzo de 1977

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas repetidamente en múltiples registros. Este problema es tratado por la tercera forma normal (3NF).