5 2 - note PDF

Preview

Summary

Download 5 2 - note PDF

Description

UNIVERSIDAD AUTÓNOMA DE SANTO DOMINGO (UASD)

TEMA: Actividad 5.2: Comentar Video

INF4200-1-2022-10 BASES DE DATOS 1 Rosmery Alberto Monegro

Participante: Francis Alcántara, L (100438497)

Santo Domingo, D. N.: República Dominicana abril 2022

introducción a las bases de datos Me gustó mucho la manera en la que introdujo el tema haciendo ver al espectador de una forma clara y sencilla que es una base de datos y como en el diario vivir de muchas personas se hace y hacen uso de ellas, como por ejemplo: los contactos del teléfono, la guía telefónica al momento de ubicar algún negocio para ordenar algo hasta el récord académico de un estudiante en la universidad dejándonos ver la diferencia entre una base de datos física frente a una digitalizada y de igual forma su eficiencia ya que buscar una información exacta en un gran lote de hojas o documentos sería muy difícil en comparación a tener un sistema que maneje estos archivos o documentos y que de una forma más practica y rápida podamos acceder a ellos desde cualquier parte además de que a nivel organizacional esto puede significar tanto como ganancia o perdida. como ganancia, ejemplo: en un banco el cual no tengan debidamente sistematizados los saldos reales de varios clientes esto puede significar un gran problema para la compañía.

hoy en día existen bases de datos como: ACCES, MySQL server, fox, entre otras. Todas estas bases de datos trabajan bajo el principio de base de datos relacional y como fundamental elemento es la entidad de la base de datos que no es más que una cosa o un objeto el cual está en el mundo real distinguible de otros, un ejemplo son los números de préstamos, un estudiante y más. estas son los elementos que participaran en la base de datos. Cada entidad posee sus propiedades o características como la entidad persona que puede tener el pelo negro o rubio, ojos azules, de tal estatura y otras características más. El siguiente modelo es la entidad-relación que según el autor se creó para identificar la entidad y sus atributos, este representa por medio de un diagrama tanto a la entidad como sus atributos en donde en el video se nos deja ver que la entidad va contenida en un rectángulo y los atributos en óvalos. El dominio de la base de datos se plantea en el video como los valores permitidos para cada atributo, un ejemplo es el número de celular el dominio de este sería de 10 atributos separados por guiones y solo abarcaría a números mas no letras conforme se va desarrollando la base de datos se llega al punto de crear relaciones entre las entidades, estas relaciones se diagraman mediante rombos que van entre lazados con otros dependiendo cuantas relaciones queramos. Hasta ahora solo la información se ha convertido en diagramas y a más diagramas relacionados entre sí pero el siguiente paso es pasar al modelo relacional para que

vaya afinándose la base de datos, este modelo consiste en pasar del modelo anterior al relacional simplemente ubicando en tablas cada entidad de la base de datos.

Al momento que se pasan a estas tablas se deben de aplicar unos criterios para que sea posible y a esto es lo que se le llama normalización. La cual consiste en aplicar una serie de reglas a las relaciones obtenidas y se normalizan para que no se repitan los datos además de salvar su integridad la cual consta de 3 tipos: la de dominio, entidad y referencial. La normalización consta de 6 reglas, cada fila o tupla debe de representar una entidad y las entidades tienen que ser únicas y tiene que haber un atributo que lo defina esto se hace por un PK para identificar de forma única una columna en la tabla además de que los atributos deben de ser atómicos ósea indivisibles un ejemplo un nombre el cual consta del nombre y el apellido no se puede considerar atómico ya que es dividirse y al igual pasa con los apellidos y también las direcciones, el orden de los datos no pueden ser relevantes ya que el orden no afecta el orden de los atributos, ejemplo: en el video se muestra como nombre está en segundo lugar en la tabla pero igual bien podría estar en quinto o sexto lugar y esto no afectaría en lo absoluto. Segunda regla de normalización dice que previamente se debe de cumplir la primera y después toda columna que no sea PK tiene que guardar relación directa con su PK, un ejemplo es la columna código que guarda relación con el nombre del empleado que a su vez guarda relación con el apellido, la zona, el código de departamento, pero el departamento no forma parte al igual que el jefe ya que pertenecen a otra distinta de empleado. También hay que tener en cuenta cuando la PK sea compuestas, cuando tenemos dos tablas con valores distintos pero se relacionan perfectamente aunque en el ejemplo del video no se cumple la segunda forma normal porque las PK no guardan relación con todas las demás columnas de la tabla, para satisfacer la segunda regla habría que crear dos tablas, una empleado y que se relacione con el lugar del trabajo y otra tabla con los empleados y sus habilidades y con una llave compuesta de los atributos de la tabla. La tercera regla de normalización se ocupa de eliminar de una tabla las dependencias transitivas. Es decir, eliminar los atributos no claves que no dependen de la clave primaria, sino de otro atributo. Una dependencia transitiva es un tipo de dependencia funcional en la que el valor de un atributo o campo no clave viene determinado por el valor de otro campo que tampoco es clave.

Se deben buscar los valores repetidos en los atributos no claves para asegurar que estos atributos que no son clave no dependan sino nada más que de la clave primaria. Se dice que los atributos son mutuamente independientes si ninguno de ellos depende funcionalmente de una combinación de otros. Esta independencia mutua garantiza que se puedan actualizar los atributos individualmente, sin peligro de afectar a otro atributo. Por tanto, para que una relación de una base de datos esté en tercera forma normal debe cumplir con: Ejemplo: Sea la tabla ESTUDIANTE, cuya clave primaria es la identificación del estudiante (ID_ESTUDIANTE) y está compuesta por los siguientes atributos: NOMBRE_ESTUDIANTE, CALLE, CIUDAD y CODIGO_POSTAL, cumpliendo las condiciones para ser 2FN.

En este caso, CALLE y CIUDAD no tienen una relación directa con la clave primaria ID_ESTUDIANTE, ya que no están directamente relacionados con el estudiante, sino que dependen totalmente del código postal.

Como el estudiante se ubica por el sitio determinado por CODIGO_POSTAL, CALLE y CIUDAD se relacionan es con este atributo. Debido a este segundo grado de dependencia, no es necesario almacenar estos atributos en la tabla ESTUDIANTE. Supongamos que hay múltiples estudiantes ubicados en un mismo código postal, con la tabla ESTUDIANTE teniendo una inmensa cantidad de registros, y se requiere cambiar el nombre de la calle o la ciudad, entonces se deberá buscar y actualizar esta calle o ciudad en toda la tabla ESTUDIANTE. Por ejemplo, si se requiere cambiar la calle “El Limón” por “El Limón II”, se tendrá que buscar “El Limón” en toda la tabla ESTUDIANTE y luego actualizarla a “El Limón II”. Buscar en una tabla enorme y actualizar los registros únicos o múltiples requerirá mucho tiempo y, por tanto, afectará el rendimiento de la base de datos. En su lugar, estos detalles se pueden tener en una tabla separada (POSTAL) que esté relacionada con la tabla ESTUDIANTE usando el atributo CODIGO_POSTAL. La tabla POSTAL tendrá una cantidad comparativamente menor de registros y solo se tendrá que actualizar una vez esta tabla POSTAL. Esto se reflejará automáticamente en la tabla ESTUDIANTE, simplificando la base de datos y las consultas. Así las tablas estarán en 3FN:...