Base de datos
- 1. Introducción: Trabajo ex aula, consta sobre investigación de los modelos entidad relación y modelo relacional, y como convertir una entidad relación a un modelo relacional, y de una manera fácil y practica explicando, como hacerlo correctamente, y como normalizarlo. También sobre las reglas del CODD. Objetivo general: Obtener as conocimientos sobre los modelos E-R, relacional, y normalización Y los CODD Objetivo especifico: Saber relacionar y normalizar una entidad relación.
- 2. MODELO ENTIDAD RELACION: Esta compuesto por entidades atributos y las relaciones, se pueden representar por ovalo, rectángulos y rombos, en los cuales, el ovalo se utilizan para sus atributos, los rectángulos, se utilizan para entidad, y el rombo para las relaciones, las cuales llevan una cardinalidad. MODELO RELACIONAL: Es cuando ya el modo relacional evoluciona a tablas, por ejemplo, los atributos se convierten en campos de la entidad, en este modelo, se utilizan PK (primari kays) llaves primarias, que son las que acezan a una información específica. 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. COMO CONVERTIR EL MODELO E-R A EL MODELO RELACIONAL Tres reglas básicas: 1) Todo tipo de entidad se convierte en una relación 2) Todo tipo de relación muchos a muchos se convierte en una relación 3) Para todo tipo de relación 1:M se realiza lo que se conoce como propagación de clave (regla gnral.) o se crea una nueva relación. Terminología relacional equivalente Relación = tabla o archivo Registro = registro, fila , renglón o tupla Atributo = columna o campo
- 3. Clave = llave o código de identificación Clave Candidata = superclave mínima Clave Primaria = clave candidata elegida Clave Ajena (o foránea) = clave externa o clave foránea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form. El modelo relacional no distingue entre entidades y relaciones, ambos modelos deben presentarse mediante relaciones, esto implica una perdida semántica (parte de lo que esta escrito en el modelo entidad relación se pierde en el modelo relacional) con respecto al modelo E-R Transformación de entidades: Cada tipo de entidad se convierte en una tabla La tabla se llamara igual que el tipo de entidad de donde proviene. Transformación de atributos de entidades: Cada atributo de una entidad se transforma en una columna de la tabla a la que a dado lugar la entidad Teniendo en cuenta que existen atributos identificador principal o PK, otros son identificadores alternativos o SK (únicos) y el resto de atributos que son identificadores – atributos no principales. Este se divide en subreglas Atributo identificadores
- 4. Los atributos que son identificadores principales pasan a formar parte la clave primaria de la clave atributos no identificadores Se representan solo como columnas de la tabla correspondiente Ejemplo: E-R: profesor: Cod_profesor, Nombre, Materia que imparte, dirección. En este caso, Cod_profesor… son atributos nada más. Relacional: Profesor: Cod_profesor, Nombre, Materia que imparte, dirección. En este caso, Cod_profesor s convierte en la llave primaria que sirve para accesar a la info. De un profesosr en específico en una tabla X, y los demás son campos en la atabla. Esto se puede llevar hasta una segunda y tercera forma normal, en este caso las tablas se van reduciendo, pero siempre con una llave primaria que permita accesar a dicha información la única condición es que para la segunda forma normal es que la primaria este bien hecha, igual para la tercera formal, la condición es que la primera y segunda forma normal este bien hechas. Normalización:
- 5. 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 La normalización es un concepto de base de datos relacionales, pero sus principios se aplican al modelamiento de datos conceptuales. Una ves creadas las tablas hay que verificar si aun se puede reducir u optimizar de alguna manera. Los problemas tales como redundancia que ocurren cando se abarrotan demasiado en una relación son llamadas anomalías. Los principales tipos son. Redundancia:La información se repite demasiadas veces innecesariamente. Anomalías de actualización: cuando al actualizar la información en una tabla se descuida el actualizarla en la siguiente Anomalías de eliminación:si un conjunto de valores llega a estar vacíos se llega a perder información relacionada como un efecto de las eliminaciones. Una relación esta en primera forma normal, si todo atributo contiene un valor unitario, es decir cada atributo contiene un solo valor apara cada ocurrencia de la entidad. Ningún atributo contiene valores repetidos o que conforman un grupo. Ejemplos: Persona: DUI, nombre, apellido, teléfono, dieccion. Los atributos son únicos, lo que implica que esta relacion persona esta 1FNormal.
- 6. Estudiante: cod_estud. Nombre, apellido, teléfono, dirección, ciclo, materias También son unitarios o atomicos, los primros. 5 pero los dos últimos no están en 1FN. Para convertirla en 1FN se proyecta en dos relaciones, obteniendo: Estudiante: cod_estud. Nombre, apellido, teléfono, dirección Cursa: ciclo, materias Una relación esta en 2FN, siesta en 1FN esta, y que todo atributo que no pertenece a una clave, no puede depender de una parte de esa clave. Ejemplo: Proveedor: cod-prov; cod-art, dirprov, precio. Esta ebrelacion esta en 1FN, pero dado lo siguiente:cod-prov; cod-art Precio depende de la clave primaria por completo;cod.art dirprov este solo depende de una parte de la clave de cod-prov por lo tanto esta relacion no esta en 2FN, pues hay un atributo no clave (dirprov) que depende de una parte de la clave. Ejemplo: Proveedor: cod-prov; cod-art, dirprov, precio. Para normalizer se proyecta en dos relaciones, Proveedor: cod-prov; cod-art, precio. Ejem. 2: Auto: placa, marca, modelo, color. Esto esta en 2FN, pero no en tercera forma normal, ya que las condiciones de esta son: Que este en 2FN
- 7. Todo atributo que no pertenece a la clave, no depende de un atributo que no es clave. Entonces el atributo marca, de pende de el modelo, y este no es parte de la clave primaria, para normalizar se proyecta en dos relaciones: Auto: placa, modelo, color ModeloAuto: modelo, marca Un esquema normalizado hasta 3FN debe cumplir lo siguiente: Cada fial de cada columna depende: De la clave 1FN De toda la clave 2FN Nada mas que de la clave 3FN. Un tema extra que no puede ayudar es Dependencias Funcionales (FD): Es el diseño de esquemas de base de datos, el concepto dependencia funcional (functionaldependency) es vital para eliminar la reundancia, una FD es una relacinenunción ‘R’ de la manera “si dos tuplas de de ‘R’ concuerdan en las atributos A1, A2, …An. (tienen los mismos valores para caa atributo), entonces debe conocordar también con otro atributo B, esta FD se escribiría como A1, A2..An B, es decir que están determinadas funcionalmnete a B
- 8. Dependencia funcional: Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de DNI tiene una conexión con Apellido o Nombre . Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera: FechaDeNacimiento Edad 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. Propiedades de la Dependencia funcional Existen 3 axiomas de Armstrong: Dependencia funcional Reflexiva: Si "x" está incluido en "x" entonces x x A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si 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 nombre DNI,direcciónnombre,dirección Si 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 y su dirección. Reglas de CODD: Reglas
- 9. Regla 0: El sistema debe ser relacional, base de datos y administrador de sistema. Ese sistema debe utilizar sus facilidades relacionales (exclusivamente) para manejar la base de datos. Edgar Frank Codd: El inglés creador del modelo relacional, un modelo considerado por la revista Forbes como uno de las grandes innovaciones en el mundo computacional en los últimos 100 años, es sin duda el principal aporte a la ciencia de este gran científico y visionario. Con esta teoría, el modelo relacional, logro darle un marco teórico con una base científica solida a la administración de datos. Es por esta innovación la cual se perfecciono con los años que a Edgar Frank Codd se le considera el padre de las bases de datos. Codd, fue galardonado con el premio Turing en 1981, premio considerado como el novel de las Ciencias de la Computación. Un premio que le fue entregado por sus contribuciones a la ciencias de la computación y especialmente al área de los sistemas de bases de datos. El modelo relacional fue una idea genial, simple y radical en su momento, que le dio la teoría lógica/matemática para respalda cientificamente las bases de datos relacionales, que en la actualidad son el tipo de base de datos mas usadas en el mundo. Reglas de CODD: Regla 1: La regla de la información, toda la información en la base de datos es representada unidireccionalmente, por valores en posiciones de las columnas dentro de filas de tablas. Toda la información en una base de datos relacional se
- 10. representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. Regla 2: La regla del acceso garantizado, todos los datos deben ser accesibles sin ambigüedad. Esta regla es esencialmente una nueva exposición del requisito fundamental para las llaves primarias. Dice que cada valor escalar individual en la base de datos debe ser lógicamente direccionable especificando el nombre de la tabla, la columna que lo contiene y la llave primaria. Regla 3: Tratamiento sistemático de valores nulos, el sistema de gestión de base de datos debe permitir que haya campos nulos. Debe tener una representación de la "información que falta y de la información inaplicable" que es sistemática, distinto de todos los valores regulares. Regla 4: Catálogo dinámico en línea basado en el modelo relacional, el sistema debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a los usuarios autorizados. Es decir, los usuarios deben poder tener acceso a la estructura de la base de datos (catálogo). Regla 5: La regla comprensiva del sublenguaje de los datos, el sistema debe soportar por lo menos un lenguaje relacional que; Tenga una sintaxis lineal. Puede ser utilizado recíprocamente y dentro de programas de uso. Soporte operaciones de definición de datos, operaciones de manipulación de datos (actualización así como la recuperación), seguridad e integridad y operaciones de administración de transacciones.
- 11. Regla 6: Regla de actualización, todas las vistas que son teóricamente actualizables deben ser actualizables por el sistema. Regla 7: Alto nivel de inserción, actualización, y cancelación, el sistema debe soportar suministrar datos en el mismo tiempo que se inserte, actualiza o esté borrando. Esto significa que los datos se pueden recuperar de una base de datos relacional en los sistemas construidos de datos de filas múltiples y/o de tablas múltiples. Regla 8: Independencia física de los datos, los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso. Regla 9: Independencia lógica de los datos, los cambios al nivel lógico (tablas, columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la estructura. La independencia de datos lógica es más difícil de lograr que la independencia física de datos. Regla 10: Independencia de la integridad, las limitaciones de la integridad se deben especificar por separado de los programas de la aplicación y se almacenan en la base de datos. Debe ser posible cambiar esas limitaciones sin afectar innecesariamente las aplicaciones existentes. Regla 11: Independencia de la distribución, la distribución de las porciones de la base de Datos a las varias localizaciones debe ser invisible a los usuarios de la base de Datos. Los usos existentes deben continuar funcionando con éxito:
- 12. Cuando una versión distribuida del SGBD se introdujo por primera vez Cuando se distribuyen los datos existentes se redistribuyen en todo el sistema. Regla 12: La regla de la no subversión, si el sistema proporciona una interfaz de bajo nivel de registro, a parte de una interfaz relacional, que esa interfaz de bajo nivel no se pueda utilizar para subvertir el sistema, por ejemplo: sin pasar por seguridad relacional o limitación de integridad. Esto es debido a que existen sistemas anteriormente no relacionales que añadieron una interfaz relacional, pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.