2 Periodo Académico
Logros:
1°. Definir La normalización Y Los tipos de normalización en la base de datos.
2°. Definir y utilizar el modelo entidad relación en la base de datos.
3°.Crear y trabajar con base de datos en acces 2007 .
Actividad
1. Que Es normalización O Normalizar Base de datos y para que sirve.
2.que dice la primera forma normal (1FN) y de un ejemplo
3.que dice la segunda forma normal (2FN) y de un ejemplo
4.que dice la tercera forma normal (3FN) y de un ejemplo.
5.que es el modelo entidad relación y cual es su utilidad.
6. ala base de datos de la biblioteca del colegio diseña el modelo entidad relación en excel y tomale una foto y subila al blog ademas el archivo hecho en excel subirlo al dropbox a la carpeta informática 2013.
7. que relaciones se dan entre las tablas que forman una base de datos y explicar cada una de ellas con ejemplo.
NOTA:Cada pregunta debe ir acompañada del link o dirección donde se consulto, ademas de una imagen un vídeo.
DESARROLLO
1.
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 tabla 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.
la Normalización consiste en formular, difundir y aplicar disposiciones o normas que deberán cumplirse ante problemas o situaciones de repetición constante, con el fin de lograr un orden y un proceso justo y equitativo.
La normalización sigue fundamentalmente tres objetivos: Simplificación, Unificación, Especificación. La normalización sirve para regular los requisitos mínimos que debe cumplir un producto en cuanto a seguridad, conformidad, inspección, salud pública, protección del ambiente o prevención de prácticas que induzcan a error al consumidor.
2.3.4.
-La diferencia que existe entre los datos Normalizados en primera forma normal (1FN) y el universo de datos no normalizado:
El universo de datos no normalizado se refiere al conjunto de datos que están reunidos bajo un criterio en común, estos datos son una gran cantidad de información desorganizada y, en algunos casos, compleja para su análisis u otros usos, ya que tiene un albedrio de información, y en ello encontraremos muchas inconsistencias o ¨defectos¨, como las siguientes:
Ø La REDUNDANCIA de datos
Ø ERRORES DE ACTUALIZACION de datos.
Ø FALTA DE INTEGRIDAD E INCONSISTENCIA en los datos.
En relación a tablas no normalizadas (cuando almacenamos información no normalizada):
Ø Repetición de nombres de cada tabla.
Ø Presencia de dos filas iguales.
Ø Los datos de una misma columna de un mismo tipo.
Ø De inserción: imposibilidad de adicionar datos en la BD por la ausencia de otros.
Ø De borrado: pérdida no intencionada de datos debido a la eliminación de otros.
En cambio, cuando tenemos los datos organizados bajo ciertos criterios, como la Primera Forma Normal (1FN), se debe cumplir con lo siguiente:
- Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.
- 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.
- Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.
- Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
- Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.
![]()
EJEMPLOS DE LA 1FN:
Ejemplo 1:
En esta Guía de Pedido, la PK es el Nro_GI (número de guía) quién determina a los demás atributos de la tabla.
Ejemplo 2:
En este caso de la biblioteca, la PK es el CodLibro, quién determina a los demás atributos de la tabla.
![]()
Ejemplo 3:
En esta Informe de Notas, la PK esta conformada por el ID-Estudiante y el ID-Clave, quienes determinan a los demás atributos de la tabla.
![]()
Ejemplo 4:
En esta Boleta de Ventas, la PK es el Num_bol (número de boleta) quién determina a los demás atributos de la tabla.
- Explique detalladamente que resuelve la segunda forma normal (2FN) presente 4 ejemplos. También muestre mediante ejemplos las fallas que presenta la 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. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional
![x \rightarrow y]()
es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que
![A \in X, X - \{A\} \nrightarrow Y]()
. Una dependencia funcional
![x \rightarrow y]()
es una dependencia parcial si hay algunos atributos
![A \in X]()
que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es
![A \in X, X - \{A\} \rightarrow Y]()
.
Por ejemplo {DNI, ID_PROYECTO}
![\rightarrow]()
HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI
![\rightarrow]()
HORAS_TRABAJO ni ID_PROYECTO
![\rightarrow]()
HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO}
![\rightarrow]()
NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI
![\rightarrow]()
NOMBRE_EMPLEADO mantiene la dependencia.
Ejemplos:
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
| Empleado | Habilidad | Lugar actual de trabajo |
|---|
| Jones | Mecanografía | 114 Main Street |
| Jones | Taquigrafía | 114 Main Street |
| Jones | Tallado | 114 Main Street |
| Bravo | Limpieza ligera | 73 Industrial Way |
| Ellis | Alquimia | 73 Industrial Way |
| Ellis | Malabarismo | 73 Industrial Way |
| Harrison | Limpieza ligera | 73 Industrial Way |
La única clave candidata de la tabla es {Empleado, Habilidad}.
El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".
Un alternativa 2NF a este diseño representaría la misma información en dos tablas:
Empleados
| Empleado | Lugar actual de trabajo |
|---|
| Jones | 114 Main Street |
| Bravo | 73 Industrial Way |
| Ellis | 73 Industrial Way |
| Harrison | 73 Industrial Way |
-
-
Habilidades de los empleados
| Empleado | Habilidad |
|---|
| Jones | Mecanografía |
| Jones | Taquigrafía |
| Jones | Tallado |
| Bravo | Limpieza ligera |
| Ellis | Alquimia |
| Ellis | Malabarismo |
| Harrison | Limpieza ligera |
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.
Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:
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 redundantemente en múltiples registros. Este problema es tratado por la
tercera forma normal (3NF).
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.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relacion
![R]()
está en 3 Forma Normal
Elmasri-Navathe,
2 si para toda dependencia funcional
![X \rightarrow A]()
, se cumple al menos una de las siguientes condiciones:
![X]()
es superllave o clave.![A]()
es atributo primo de ![R]()
; esto es, si es miembro de alguna clave en ![R]()
.
Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
Ganadores del torneo
| Torneo | Año | Ganador | Fecha de nacimiento del ganador |
|---|
| 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 |
La única clave candidata es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.
Ejemplos:
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
Ganadores del torneo
| Torneo | Año | Ganador |
|---|
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |
-
-
Fecha de nacimiento del jugador
| Jugador | Fecha de nacimiento |
|---|
| Chip Masterson | 14 de marzo de 1977 |
| Al Fredrickson | 21 de julio de 1975 |
| Bob Albertson | 28 de septiembre de 1968 |
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.
- Explique detalladamente que resuelve la cuarta forma normal (4FN) presente 4 ejemplos. También muestre mediante ejemplos las fallas que presenta la 4FN.
Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.
Ejemplo:
Considere el siguiente ejemplo:
Permutaciones de envíos de pizzas
| Restaurante | Variedad de Pizza | Área de envío |
|---|
| Vincenzo's Pizza | Corteza gruesa | Springfield |
| Vincenzo's Pizza | Corteza gruesa | Shelbyville |
| Vincenzo's Pizza | Corteza fina | Springfield |
| Vincenzo's Pizza | Corteza fina | Shelbyville |
| Elite Pizza | Corteza fina | Capital City |
| Elite Pizza | Corteza rellena | Capital City |
| A1 Pizza | Corteza gruesa | Springfield |
| A1 Pizza | Corteza gruesa | Shelbyville |
| A1 Pizza | Corteza gruesa | Capital City |
| A1 Pizza | Corteza rellena | Springfield |
| A1 Pizza | Corteza rellena | Shelbyville |
| A1 Pizza | Corteza rellena | Capital City |
Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área dada.
Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son independientes de las áreas a las cuales el restaurante envía, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar múltiples registros, uno para cada una de las Áreas de envío de A1 Pizza. En términos formales, esto se describe como que Variedad de pizza está teniendo una dependencia multivalor en Restaurante.
Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre áreas de envío:
Variedades por restaurante
| Restaurante | Variedad de pizza |
|---|
| Vincenzo's Pizza | Corteza gruesa |
| Vincenzo's Pizza | Corteza fina |
| Elite Pizza | Corteza fina |
| Elite Pizza | Corteza rellena |
| A1 Pizza | Corteza gruesa |
| A1 Pizza | Corteza rellena |
| Áreas de envío por restaurante
| Restaurante | Área de envío |
|---|
| Vincenzo's Pizza | Springfield |
| Vincenzo's Pizza | Shelbyville |
| Elite Pizza | Capital City |
| A1 Pizza | Springfield |
| A1 Pizza | Shelbyville |
| A1 Pizza | Capital City |
|
En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un área de envío a otra, la tabla original de la tres columnas satisfaría la 4NF.
5.
Un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datosque permite representar las entidades relevantes de unsistema de información así como sus interrelaciones y propiedades.
El Modelo Entidad-Relación.
- Se elabora el diagrama (o diagramas) entidad-relación.
- Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una
base de datos. Brevemente:
![]()
6.
![]()
7:
Qué son las relaciones entre tablas
En una base de datos relacional, las relaciones permiten evitar datos redundantes. Por ejemplo, si está diseñando una base de datos que realizará un seguimiento de información sobre libros, podría tener una tabla denominada títulos que almacena información acerca de cada libro, como el libro? el título de s, la fecha de publicación y la editorial. También es posible que desee almacenar sobre la editorial, tales como el número de teléfono, dirección y código postal de información. Si desea almacenar toda esta información en los títulos de tabla, el publicador? s número de teléfono se duplicaría por cada título impreso de la editorial.
Una solución mejor es almacenar la información del editor una sola vez en una tabla independiente, Publishers. A continuación, podría situar un puntero en la tabla Titles que haga referencia a una entrada en la tabla Publishers.
Para asegurarse de que sus datos no están sincronizados, puede exigir la integridad referencial entre las tablas Titles y Publishers. Las relaciones de integridad referencial ayudan a garantizar que la información en una tabla coincide con la información de otra. Por ejemplo, cada título de la tabla Titles debe asociarse con un editor específico de la tabla Publishers.No se puede agregar un título a la base de datos de un editor que no existe en la base de datos.
Tipos de relaciones entre tablas
Una relación hace coincidir los datos de las columnas de clave, normalmente las columnas con el mismo nombre en ambas tablas. En la mayoría de los casos, la relación hace coincidir la clave principal de una tabla, que proporciona un identificador único para cada fila, con una entrada en la clave externa de la otra tabla. Por ejemplo, ventas pueden asociarse con los títulos específicos vendidos mediante la creación de una relación entre la columna title_id de la tabla Titles (la clave principal) y la columna title_id de la tabla de ventas (la clave externa).
Hay tres tipos de relaciones entre tablas. El tipo de relación que se crea depende de cómo se definen las columnas relacionadas.
Relaciones uno a varios
Una relación uno a varios es el tipo de relación más común. En este tipo de relación, una fila en la tabla A puede tener muchas filas coincidentes en la tabla B, pero una fila de la tabla B puede tener sólo una fila coincidente en la tabla A. Por ejemplo, las tablas Publishers y Titles tienen una relación uno a varios: cada editor publica muchos títulos, pero cada título le corresponde sólo una editorial.
Se crea una relación uno a varios si sólo una de las columnas relacionadas es una clave principal o tiene una restricción unique.
En Access, el lado de la clave principal de una relación uno a varios se denota mediante un símbolo de clave. El lado de clave externa de una relación se indica mediante un símbolo de infinito.
Relaciones varios a varios
En una relación varios a varios, una fila de la tabla A puede tener muchas filas coincidentes en la tabla B y viceversa. Crear este tipo de relación definiendo una tercera tabla, denominada tabla de unión, cuya clave principal consta de las claves externas de las tablas A y B. Por ejemplo, la tabla Authors y la tabla Titles tienen una relación de varios a varios que se define por una relación de uno a varios entre cada una de estas tablas a la tabla TitleAuthors. La clave principal de la tabla TitleAuthors es la combinación de la columna au_id (la tabla authors? s clave principal) y la columna title_id (la tabla Titles? s clave principal).
Relaciones uno a uno
En una relación uno a uno, una fila de la tabla A puede tener no más de una fila coincidente en la tabla B y viceversa. Si dos de las columnas relacionadas son claves principales o tienen restricciones unique, se crea una relación uno a uno.
Este tipo de relación no es común porque la mayoría de la información relacionada de esta manera estaría toda en una tabla.Puede utilizar una relación uno a uno para:
- Dividir una tabla con muchas columnas.
- Aislar parte de una tabla por razones de seguridad.
- Almacenar datos que son efímeros y pueden eliminarse fácilmente mediante la simple eliminación de la tabla.
- Almacenar la información que sólo se aplica a un subconjunto de la tabla principal.
En Access, el lado de la clave principal de una relación uno a uno se indica mediante un símbolo de clave. El lado de clave externa también está indicado mediante un símbolo de clave.
Hacer clic sobre la opción 
.
de la ventana 
En la primera fila escribir el nombre del primer campo, al pulsar la tecla 
situado, normalmente, en la esquina inferior izquierda de la pantalla. Colocar el cursor y hacer clic sobre el botón 
.
