• Author / Uploaded
• leydi yohana sua niño

Citation preview

ACTIVIDAD DE APRENDIZAJE 4 EVIDENCIA 4

Presentado por: LEYDI YOHANA SUA NIÑO

Tutor: GIOVANNY ZAMBRANO LONDOÑO

Ficha: 1700898 – BASES DE DATOS GENERALIDADES Y SISTEMAS DE GESTION SERVICIO NACIONAL DE APRENDIZAJE SENA Duitama Boyacá junio UNIDAD 4 AÑO: 2018 CASO / DISEÑO DE BASES DE DATOS RELACIONALES

DEDICATORIA Dedico este trabajo a mi familia y a todos los que creen en mis capacidades

AGRADECIMIENTOS Este trabajo esta dedicado a mi familia tutor y compañeros

Índice Presentación ........................................................................................................ 1 Introducción .......................................................................................................... 2 Definición del problema ......................................................................................... 3 Solución del problema .......................................................................................... 4 Normalización: 1NF, 2NF, 3FN, BCNF ................................................................. 5 Criterios para normalizar ...................................................................................... 6 Aplicación del diseño de Bases de Datos Relacionales ....................................... 7 ¿Hasta dónde se debe normalizar una base de datos?........................................... 8 Conclusiones ......................................................................................................... 9

PRESENTACIÓN

Diseñar una Base de Datos Relacional es el paso más importante en la construcción y desarrollo de sistemas de información, porque es el que va a contener todos y cada uno de los datos de una empresa; es por eso que de allí surge la imperiosa necesidad de tener expertos que trabajen en esta área, ya que está en la capacidad de comprender, estructurar, organizar, explicar y relacionar todos los elementos que componen la empresa, a tal punto que la lleva a un diagrama final conocido como Entidad-Relación. Entonces, a partir de los conceptos vistos en los contenidos anteriores, en este último se presentará un ejemplo completo y concreto del proceso de diseño de una Base de Datos Relacional, utilizando la normalización, así como el diagrama Entidad – Relación. .

Introducción El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño. El modelo relacional representa la segunda generación de los DBMS. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los DBMS de la primera generación, lo que constituye otro punto a su favor. En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un puntero físico, siempre señalaría desde el registro al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los DBMS. En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y para disponer de capacidad deductiva.

Definición del problema La definición del problema es el proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar. Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para expertos: más un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseño de bases de datos y éste se considera ahora una disciplina estable, con métodos y técnicas propios. Debido a la creciente aceptación de las bases de datos por parte de la industria y el gobierno en el plano comercial, y a una variedad de aplicaciones científicas y técnicas, el diseño de bases de datos desempeña un papel central en el empleo de los recursos de información en la mayoría de las organizaciones. El diseño de bases de datos ha pasado a constituir parte de la formación general de los informáticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programación convencional Para definir correctamente al Problema lo primero es realizar diseño conceptual, que parte de las especificaciones de los requisitos del usuario y su resultado es el esquema conceptual de la base de datos que corresponderá a un Modelo Entidad – Relación (E / R). Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del DBMS que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de los Datos de la base de datos (DB) y no las estructuras de almacenamiento que se necesitarán para manejar esta información

Solución de problemas Redundancia e inconsistencia de datos Puesto que los archivos que mantienen almacenada la información son creados por diferentes tipos de programas de aplicación existe la posibilidad de que si no se controla detalladamente el almacenamiento, se pueda originar un duplicado de información, es decir que la misma información sea más de una vez en un dispositivo de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos, además de que puede originar la inconsistencia de los datos es decir diversas copias de un mismo dato no concuerdan entre si -, por ejemplo: que se actualiza la dirección de un cliente en un archivo y que en otros archivos permanezca la anterior.

Dificultad para tener acceso a los datos. Un sistema de base de datos debe contemplar un entorno de datos que le facilite al usuario el manejo de los mismos. Supóngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos los clientes que viven dentro del código postal 78733 de la ciudad. El gerente pide al departamento de procesamiento de datos que genere la lista correspondiente. Puesto que esta situación no fue prevista en el diseño del sistema, no existe ninguna aplicación de consulta que permita este tipo de solicitud, esto ocasiona una deficiencia del sistema. Aislamiento de los datos Puesto que los datos están repartidos en varios archivos, y estos no pueden tener diferentes formatos, es difícil escribir nuevos programas de aplicación para obtener los datos apropiados. Anomalías del acceso concurrente. Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta más rápido, muchos sistemas permiten que múltiples usuarios actualicen los datos simultáneamente. En un entorno así la interacción de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe mantenerse alguna forma de supervisión en el sistema.

Problemas de seguridad. La información de toda empresa es importante, aunque unos datos lo son más que otros, por tal motivo se debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna información, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado de seguridad que garantice la autentificación y protección de los datos. En un banco por ejemplo, el personal de nóminas sólo necesita ver la parte de la base de datos que tiene información acerca de los distintos empleados del banco y no a otro tipo de información. Problemas de integridad. Los valores de datos almacenados en la base de datos deben satisfacer cierto tipo de restricciones de consistencia. Estas restricciones se hacen cumplir en el sistema añadiendo códigos apropiados en los diversos programas de aplicación. Lo anterior es originado por: • Redundancia • Anomalías o Actualización o Inserción o Borrado Creadas durante: • Mantenimiento • Creación • Modificación

Normalización: 1NF, 2NF, 3FN, BCNF Si nunca antes hemos oído hablar de la "normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización. Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, que podríamos diseñar algo parecido. La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas) según su afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes: • Evita anomalías en inserciones, modificaciones y borrados. • Mejora la independencia de datos. • No establece restricciones artificiales en la estructura de los datos.

Criterios para normalizar Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas. Regla No. 1 - La Regla de la información Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas. Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos. Regla No. 2 - La regla del acceso garantizado Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna. Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria. Regla No. 3 - Tratamiento sistemático de los valores nulos La información inaplicable o faltante puede ser representada a través de valores nulos. Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.

Regla No. 4 - La regla de la descripción de la base de datos La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados. La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc., debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL (o similar).

Regla No. 5 - La regla del sub-lenguaje Integral Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones. Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos. Regla No. 6 - La regla de la actualización de vistas Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo. La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas. Regla No. 7 - La regla de insertar y actualizar La capacidad de manejar una base de datos con operandos simples aplica no sólo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos'. Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas. Regla No. 8 - La regla de independencia física El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos. El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos. La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación. Regla No. 10 - La regla de la independencia de la integridad Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación.

Las reglas de integridad 1. Ningún componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma básica de integridad). 2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya Integridad referencial. Regla No. 11 - La regla de la distribución El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación. El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una única base de datos en una sola máquina. Regla No. 12 - Regla de la no-subversión Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL). Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.

APLICACIÓN DEL DISEÑO DE BASES DE DATOS RELACIONALES Un sistema de gestión de base de datos, lógicamente debe tener definida la misma, para que a partir de ella se realice el diseño, y por ende, el desarrollo del sistema de información. Con el fin de comprender específicamente el diseño de Bases de Datos Relacionales, se presenta a continuación un caso práctico en el cual se aplican los conceptos y normas establecidas para tal fin. Caso Corporativo Un grupo corporativo se compone de varias empresas. Cada empresa tiene varias sucursales. Una sucursal está en una ciudad del país y tiene varios agentes, así como un conjunto de clientes. Un agente se asigna a una sola sucursal y un cliente es atendido por un solo agente. Un cliente se encuentra en una sucursal y en una sola ciudad (no necesariamente la misma de la sucursal) y cada empresa tiene un catálogo de productos que vende. Un cliente puede tener varias facturas. Cada factura tiene un detalle, y en cada detalle se muestran los productos comprados en esa factura, así como la cantidad comprada. Para una factura se pueden tener varios pagos, así como varias notas de cargo o crédito. En esa factura se puede tener devolución de los productos defectuosos y se tiene detalle de la devolución, del producto devuelto y la cantidad (unidades) (Tecnológico de Monterey y SENA). Es decir: Para cada empresa se tiene su número, nombre, las sucursales, los productos que venden, los clientes, las ciudades que atiende y los agentes de ventas que trabajan en la empresa. Para cada sucursal se tiene su número, su dirección, los clientes que atiende y los agentes que trabajan en la sucursal. Para cada cliente se tiene su número, nombre del cliente, límite de crédito, número de la empresa, número de sucursal, número de ciudad, número de agente que lo atiende, dirección y facturas Para cada ciudad se tiene su número, la empresa, el nombre, el número de sucursal. Para cada agente se tiene su número, nombre, la empresa, la ciudad, la sucursal y los clientes que atiende. Para cada producto se tiene su número, nombre, la empresa y las unidades de medición

Para cada factura se tiene el número de la factura, la fecha, los productos y su cantidad, cliente y la sucursal. Para cada pago se tiene el número de factura, un número consecutivo, la fecha y el valor pagado (importe). Para cada devolución se tiene la factura, un número consecutivo y el importe, así como el detalle de la devolución. Para cada detalle de la devolución se tiene la factura, un número consecutivo de devolución, el número de producto, la sucursal y la cantidad Para cada nota se tiene la factura, el tipo de nota (cargo o crédito), un consecutivo, la fecha y el importe (Tecnológico de Monterey y SENA) Entonces, para el caso corporativo planteado, es importante lograr identificar los siguientes puntos:  Obtener las entidades que representen los requerimientos descritos en el caso.  Obtener las relaciones y atributos en forma 1NF.  Aplicar la 2FN a las entidades que lo requieran.  Normalizar las relaciones obtenidas hasta la forma 3NF.  Obtener el diagrama Entidad - Relación (E-R) que representa la información descrita con su respectiva cardinalidad.

Reflexión inicial & actividad 4 ¿Hasta dónde se debe normalizar una Base de Datos? R: En primera instancia una BD se debe normalizar hasta su mínima expresión, aunque este proceso también depende de parte del diseñador. La base de datos se debe diseñar teniendo en cuenta los requerimientos de la empresa, organización o compañía. Por lo tanto existen también otros factores como en cuanto a la información si será consultada de manera multiusuario, etc. Una empresa desarrolla varios proyectos que son asignados a distintos empleados; cada empleado sólo estará vinculado a un proyecto, en un momento dado. Cada proyecto consume diferentes recursos en cantidades determinadas: los empleados estarán a cargo de un supervisor, quién también es un empleado. Los empleados pueden tener a su cargo personas beneficiarias (hijos, esposas(os), padres, entre otros). Para este caso deberá realizar los siguientes puntos: Obtener las entidades que representen los requerimientos descritos en el caso. 1. 2. 3. 4.

Obtener las relaciones y atributos en forma 1NF Aplicar la 2FN, a las entidades que lo requieran. Normalizar las relaciones obtenidas hasta la forma 3NF Obtener el diagrama entidad relación (E-R) que representa la información descrita con su respectiva cardinalidad.

SOLUCION

1. Las entidades son: Proyecto Empleado Recurso Beneficiario

2 Las relaciones son: Proyecto

Empleado

Recurso

Beneficiario

IdProy (PK)

IdEmp (PK)

IdRec (PK)

IdEmp(PK)

NomProy

CedEmp

Descrip

NomBen (PK)

Durac

Nombre

Unid

FechaNac

FechaIn

Direcc Telef IdSup

4 3NF: no es necesario.

Sexo

5 Diagrama E-R:

Mapa conceptual