• Author / Uploaded
• Samantha

Citation preview

Contenido Contenido ........................................................................................................... 2 Introducción ....................................................................................................... 3 Desarrollo ........................................................................................................... 4

REPORTE

1

INTRODUCCIÓN Las bases de datos surgieron por la necesidad que tenían las empresas de almacenar grandes cantidades de información de una forma rápida, sencilla y fiable, y que a su vez pudieran acceder a ella en cualquier momento sin tener que almacenar tanto papel en archivos físicos.

En esta unidad se presenta el proceso de desarrollo de un sistema de base de datos paso a paso. Se muestran aspectos generales y precisos sobre los sistemas de bases de datos relacionales. Además de una detallada descripción del modelo relacional, la teoría del diseño y el modelo entidad relación.

Se muestra además del diseño de bases de datos en su etapa conceptual de alto nivel, como por ejemplo la descripción concisa de los requerimientos de información de los usuarios, descripciones detalladas de los tipos de datos, las entidades y las relaciones. Este esquema conceptual sirve como referencia para asegurarse de satisfacer los requerimientos de los usuarios y que no haya conflictos con tales requerimientos.

Luego se detalla la forma en que este nivel conceptual puede representarse como un modelo lógico en el SGBD utilizando conceptos como las relaciones, llaves primarias y foráneas, integridad referencial y normalización y otros.

Por lo cual, en la presente unidad, estudiaremos y aplicaremos ciertos conceptos relacionados con las bases de datos que son necesarios para el diseño de la misma, para luego construir este modelo en el siguiente capítulo en un SGBD utilizando el lenguaje SQL.

REPORTE

2

DESARROLLO MODELO ER Y EREXTENDIDO - REPORTE. Un modelo de datos es una colección de herramientas conceptuales para la descripción de datos, relaciones entre datos, semántica de los datos y restricciones de consistencia. El modelo entidad-relación (E/R), también llamado modelo conceptual de datos, fue propuesto por Peter Chen en 1976 y consiste en una técnica especial de representación gráfica que incorpora información relativa a los datos y la relación existente entre ellos, para suministrar una visión del mundo real, pudiendo ser usado “como una base para una vista unificada de los datos adoptando el enfoque más natural del mundo real que consiste en entidades e interrelaciones”. El modelo entidad-relación es un paso previo al futuro diseño de una base de datos y, por tanto, independiente del modelo de datos que utilice. 1.2.1 ELEMENTOS DE UN MODELO ENTIDAD RELACIÓN. El modelo debe estar compuesto por:     

Entidades Relaciones Atributos Cardinalidad Llaves

ENTIDADES: Una Entidades un objeto que existe y es distinguible de otros objetos por su sola existencia, por medio de un conjunto de atributos. Tipo de objeto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso (coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc.). Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior de él. Un nombre de entidad sólo puede aparecer una vez en el esquema. Una entidad puede ser concreta, tal como una persona o un libro, o puede ser abstracta, como un día festivo o un concepto.

REPORTE

3

Se utilizan rectángulos dobles para representar conjuntos de entidades débiles. Ejemplos de entidades: Materias, Estudiantes, Profesores, Empleados, clientes, etc. cada una con características que describen y diferencian cada elemento. RELACIONES: Las relaciones son las asociaciones que se establecen entre los campos de dos tablas, básicamente para compartir información. Es una asociación o correspondencia existente entre entidades, sin existencia propia, de varias entidades. Se representa mediante un rombo. Por ejemplo, podemos definir una relación que asocia al cliente Juan López con la cuenta 12345. ATRIBUTOS: Una entidad está representada por un conjunto de atributos. Los atributos son datos que describen una entidad dada. Es la unidad básica e indivisible de información acerca de una Entidad o una Relación, que sirve para identificarla o para describirla. Es pues cada una de las propiedades o características que tiene una Entidad o una Relación. Se representa mediante una elipse o un círculo con su nombre. Por ejemplo, de la Entidad Vehículo se pueden establecer atributos como marca, modelo, color, chasis, placa, etc. Estas son características propias del vehículo, es decir, hablan de un vehículo en particular y lo diferencian de otros, el dueño del vehículo no puede ser un atributo del vehículo ya que no define al vehículo y este además tiene atributos propios que lo definen, como nombre, DUI, dirección, teléfono, edad, sexo, etc. Cuando se representan los atributos, pueden usarse elipses dobles para representar atributos multivariados y elipses discontinuas para denotar atributos derivados. Cuando definamos atributos, hay que tener cuidado de no confundirnos. Por ejemplo, podemos tener una entidad Estudiante y otra entidad Profesor, que aparentemente tienen los mismos atributos como DUI, nombre, edad, teléfono, etc. Podemos malinterpretar esta situación y crear una entidad llamada persona para englobar a ambas entidades, pero esto no es conveniente; por lo que se debe ser muy específico al nombrar los atributos de las entidades para que hagan referencia a la entidad a la que pertenecen. Entonces, podemos crear los siguientes atributos de la entidad estudiante: Identificador estudiante Nombre_ estudiante Edad_ estudiante

REPORTE

4

Teléfono_ estudiante Dirección_ estudiante Sexo_ estudiante Y los siguientes atributos para la entidad profesor: Identificador_profesor Nombre_ profesor Edad_ profesor Teléfono_ profesor Dirección_ profesor Sexo_ profesor

CARDINALIDAD Otra de las características importantes que hay que tener en cuenta en este modelo es la cardinalidad de cada extremo en una relación. La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están relacionadas con cuántas entidades del conjunto del otro extremo. Pueden ser “uno a uno”', “uno a varios”' o “varios a varios”'. Por ejemplo, un artículo puede ser escrito por un solo autor o por varios, pero nunca por ninguno; un autor puede pertenecer a exactamente una institución (no para cero o varias); un artículo puede tener cero, uno o varios experimentos. Finalmente, un autor puede escribir muchos artículos, o ninguno. CLAVE DE UNA ENTIDAD Antes de definir el concepto de clave debe especificarse el concepto más genérico de Identificador, Superclave o Determinante, que se define como un conjunto de uno o más atributos que permiten identificar de forma única una ocurrencia de una entidad dentro de un conjunto de ellas. Se denominan claves candidatas a aquellas superclaves para las cuales ningún subconjunto propio es a la vez superclave. De entre las claves candidatas el diseñador de la base de datos elige una clave primaria denominándose al resto de las claves candidatas claves alternativas.

REPORTE

5

Se define como clave ajena a aquel o aquellos atributos de una entidad que son clave primaria en otra entidad.

REPRESENTACIÓN GRÁFICA

EJEMPLOS:

REPORTE

6

Relaciones. CARDINALIDAD: La cardinalidad es la forma en que se relacionan las entidades. Se le conoce también como tipo de relación entre entidades. Hay tres tipos de relaciones:   

Uno a Uno Uno a Muchos (O Muchos a uno) Muchos a Muchos

RELACIÓN UNO A UNO. Se presenta cuando una única ocurrencia de la entidad A se relaciona con una sola ocurrencia de la entidad B y viceversa. Este tipo de relación no es normal, porque la mayoría de la información que se relaciona de esta forma estaría en una tabla. Puede utilizarse la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla por razones de seguridad o para almacenar información que sólo se aplica a un subconjunto de la tabla principal. EJEMPLO Un HOMBRE está casado con una sola MUJER. Una MUJER está casada con un solo HOMBRE.

REPORTE

7

ENTIDAD 1 ---- RELACIÓN --- ENTIDAD 2

RELACIÓN UNO A MUCHOS. Es el tipo de relación más común. Significa que un registro de la tabla A puede tener muchos registros coincidentes en la tabla B, pero un registro de la tabla B solo tiene un registro coincidente en la tabla A. EJEMPLO Un CLIENTE puede tener muchas CUENTAS BANCARIAS. La relación se representa como de 1: N. Donde se usa N o M para representar muchos.

RELACIÓN MUCHOS A MUCHOS. Establece que cualquier cantidad de entidades del tipo A pueden estar relacionados con cualquier cantidad de entidades del tipo B. En otras palabras, un registro de la tabla A puede tener muchos registros coincidentes en la tabla B, y viceversa. Este tipo de relación sólo es posible si se define una tercera tabla (denominada tabla de unión), cuya clave principal consta de dos campos: las claves externas de las tablas A y B.

EJEMPLO Un ESTUDIANTE puede cursar muchas MATERIAS. Una MATERIA la pueden cursar muchos ESTUDIANTES. Se representa como de M:N. Donde se usa N o M para representar muchos.

REPORTE

8

Representación de restricciones de diseño.         

 



Una entidad puede estar relacionada con varias entidades, pero con rombos separados Los nombres de las relaciones se escriben con verbo sustantivado. No puede haber dos entidades iguales. El orden de las entidades no importa. El orden del nombre de los atributos no importa. Cada atributo solo puede tomar un valor en el dominio en el cual está inscrito. Dos entidades no se pueden conectar directamente entre sí, se deben hacer a través de una relación. La cardinalidad debe escribirse sobre la línea de la relación. Para definir la CARDINALIDAD se debe hacer siempre este tipo de preguntas. Evitar diseños con relaciones circulares. No puede haber entidades o relaciones independientes Un rombo solo puede unir dos entidades

REPORTE

9

Ejemplo Diagramas E-R Un modelo ER de Propietarios de Taxis y Conductores. (UNO ----- MUCHOS) ¿Un Taxi cuantos propietarios tiene? R/ uno (El uno se pone en PROPIETARIO) ¿Un Propietario cuantos Taxis tiene? R/ Varios (La N se pone en TAXI) ¿Un taxi cuantos Conductores tiene? R/ varios (La N se pone en CONDUCTOR) ¿Un conductor Cuantos taxis maneja? R/ Uno (El Uno se pone En TAXI) Se deben realizar los siguientes pasos: 1. Identificamos las Entidades. 2. Identificamos los atributos de las Entidades. 3. Identificamos las relaciones entre las Entidades.

REPORTE

10

4. Colocamos la cardinalidad de las relaciones.

REPORTE

11

REPORTE

12

Entidades débiles. Es posible que un conjunto de entidades no tenga atributos suficientes para formar una clave primaria. Un conjunto de entidades de este tipo se denomina conjunto de entidades débiles. Una entidad débil es aquella cuya existencia depende de alguna otra entidad. Para que un conjunto de entidades débiles sea significativo, debe ser parte de un conjunto de relaciones uno a muchos. Cada entidad débil debe estar asociada con una entidad propietaria o dominante; es decir, que el conjunto de entidades débiles depende existencialmente del conjunto de entidades propietarias. La clave primaria de un conjunto de entidades débiles se forma con la clave primaria del conjunto de entidades propietarias, más el discriminante del conjunto de entidades débiles. El discriminante de un conjunto de entidades débiles se denomina la clave parcial del conjunto de entidades. El conjunto de entidades débiles se indica en los diagramas E-R por medio de un rectángulo de doble contorno.

Ejemplo entidades débiles.

REPORTE

13

EJEMPLO Como ilustración, considérese el conjunto de entidades pago, que tiene los tres atributos: númeropago, fecha-pago e importe-pago. Los números de pago son generalmente números secuenciales, empezando por 1, generados por separado por cada préstamo. Así, aunque cada entidad pago es distinta, los pagos para diferentes préstamos pueden compartir el mismo número de pago. Así, este conjunto de entidades no tiene una clave primaria; es un conjunto de entidades débiles. La relación que asocia el conjunto de entidades débiles con el conjunto de entidades identificadoras se denomina relación identificadora. En nuestro conjunto de para pago préstamo, préstamoasocia la pago con

ejemplo, el entidades identificador es y la relación pago que entidad su

correspondiente entidad préstamo es la relación identificadora.

Rol de las entidades. En los diagramas E-R se indican papeles mediante etiquetas en las líneas que unen rombos con Rectángulos. A veces en las líneas de relación se indican roles. Los roles representan el papel que juega una entidad en una determinada relación. EJEMPLO 1 En la siguiente figura se muestran los indicadores de papeles director y trabajador entre el conjunto de entidades empleado y el conjunto de relaciones trabaja- para.

REPORTE

14

EJEMPLO 2 Ejemplo de rol. Un trabajador puede ser visto como jefe o como empleado según a qué lado de la relación esté.

Modelo Entidad Relación extendida. GENERALIZACIÓN. Es una relación contenida que existe entre el conjunto de nivel más alto (superclase) y uno o más conjuntos de entidades de nivel más bajo (subclase). La generalización permite que las entidades de nivel más bajo hereden los atributos de la entidad generalizadora de más alto nivel. La entidad general se llama superentidad y las otras subentidades. La superentidad normalmente tiene una clave principal distinta de las subentidades (éste sería el detalle más importante para diferenciarlas de las relaciones ISA de especificación). La Generalización trata de eliminar la redundancia (repetición) de atributos, al englobar los atributos semejantes. La entidad(es) de bajo nivel cuentan (heredan) todos los atributos correspondientes. Para la representación de este tipo de interrelación, utilizamos un triángulo invertido, con la base paralela al rectángulo que representa el supertipo (Generalización) y conectado a éste y a los subtipos (Especialización). Las cardinalidades son siempre (1,1) en el supertipo y (0,1) en los subtipos. ESPECIALIZACIÓN.

REPORTE

15

El proceso por el que se definen las diferentes subclases de una superclase se conoce como especialización. Ocurre cuando partimos de una entidad que podemos dividir en subentidades para detallar atributos que varían en las mismas. Comparten clave con la superentidad y los atributos de la superclase se heredan en las subclases. EJEMPLO 1 La entidad empleado tiene varios atributos como nombre, dirección, teléfono, fecha de nacimiento, tiempo de servicio, etc. Pero un empleado tiene la característica de que puede ser contratado por horas o permanente. Si es por horas, necesitaremos conocer cuántas horas trabajó en el mes y el precio de la hora para calcular su salario mensual. En cambio si es asalariado, ya tiene un salario mensual fijo. En este ejemplo, los subtipos Empleado por horas y Empleado Asalariado corresponden a la especialización. En especialización, los subtipos heredan los atributos y las interrelaciones de su supertipo. La clave la tiene la superentidad. Empleado por horas y empleado asalariado heredan los atributos de la superentidad. El resto son atributos propios solo de cada entidad. Podemos tener varias especializaciones de una misma entidad basándonos en distintos criterios. Por ejemplo, otra especialización de EMPLEADO podría dar lugar a las subclases Secretaria, Ingeniero, Técnico. La generalización o la especialización se suelen distinguir por las claves. Si se comparte clave entre la superentidad y sus descendientes, se habla de especialización; de otro modo se habla de generalización. En la generalización cada entidad de alto nivel debe ser también una entidad de bajo nivel. La especialización no tiene esta limitante. EJEMPLO 2 Se tiene las entidades Cta_Ahorro y Cta_Cheques, ambas tienen los atributos semejantes de No_Cta y Saldo, aunque además de estos dos atributos, Cta_Ahorro tiene el atributo Tasa_Interes y Cta_Cheques el atributo Saldo_Deudor. De todos estos atributos podemos juntar (generalizar) No_Cta y Saldo que son iguales en ambas entidades.

REPORTE

16

EJEMPLO 3 Se tiene la superclase Médico y las subclases Cirujano, Pediatra, Oftalmólogo, Ginecólogo, Dermatólogo. Entonces podemos decir que Cirujano y Pediatra, es un tipo de Médico.

REPORTE

17

Características: Generalización:  

Énfasis en las similitudes Cada instancia del supertipo es también una instancia de alguno de los subtipos.

Especialización:  

Énfasis en las diferencias Alguna instancia del supertipo puede no ser instancia de ningún subtipo.

1.3.2 AGREGACIÓN Es un concepto de abstracción para construir objetos compuestos a partir de sus objetos componentes. Permite combinar entidades entre las que existe una interrelación y formar una entidad de más alto nivel. Es útil cuando la entidad de más alto nivel se tiene que interrelacionar con otra entidad. La agregación surge de la limitación que existe en el modelado de E-R, al no permitir expresar las relaciones entre relaciones de un modelo E-R en el caso de que una relación X se quiera unir con una entidad cualquiera para formar otra relación. EJEMPLO 1 Supóngase que se desean registrar los directores para las tareas realizadas por un empleado en una sucursal; es decir, se desean registrar directores por combinaciones (empleado, sucursal, trabajo). Asúmase que existe una entidad director. Considere el conjunto de relaciones trabaja-en (que relaciona los conjuntos de entidades empleado, sucursal y trabajo) como un conjunto de entidades de nivel más alto denominado trabaja-en. Tal conjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades. Una alternativa es crear una relación cuaternaria “dirige” entre empleado, sucursal, trabajo y director. Algunas combinaciones empleado – sucursal – trabajo puede ser que no tengan director.

REPORTE

18

Diseño del Modelo Relacional

NORMALIZACIÓN. ENFOQUE INTUITIVO La normalización es un método científico de convertir tablas complejas en estructuras de tablas simples usando ciertas reglas. Es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una relación está en una determinada forma normal si satisface un conjunto de restricciones. Las bases de datos relacionales se normalizan para:

REPORTE

19

      

Evitar la redundancia de los datos Evitar problemas de actualización de los datos en las tablas Proteger la integridad de los datos. Prevenir inconsistencias. Evitar campos cuyos valores se repitan frecuentemente Visualizar si se pueden combinar campos poco necesarios para convertirlos en uno solo. Estructurar adecuadamente las llaves primarias y foráneas de las tablas.

NORMALIZACIÓN BASADA EN DEPENDENCIAS FUNCIONALES. La teoría de la normalización está basada en la noción fundamental de dependencia. Existen varios tipos: 1. Dependencia funcional: dado un conjunto B decimos que dicho conjunto depende funcionalmente de otro conjunto A si para cualquier valor de A le corresponde un único valor de B. Se denota A à B. Al conjunto A del que depende funcionalmente el conjunto B se le llama determinante. Al conjunto B se le llama implicado. EJEMPLO. Tenemos la tabla TRABAJADOR que contiene tres campos: DUI, NOMBRE, DEPTO. El nombre de un trabajador depende de su número de DUI y para cada DUI en particular solo existe un nombre de trabajador posible. En cambio, DEPTO. No tiene dependencia funcional, ya que en un Departamento pueden haber muchos DUI’s y para un mismo DUI no puede haber más de un departamento. Si tenemos la siguiente tabla EMPLEADOS:

En este caso Código es el determinante porque de él dependen Nombre y Ciudad. Código será único en cada tupla (fila) lo que significa que es una llave candidata. Código es el determinante y podemos decir que Código determina Ciudad y Nombre.

REPORTE

20

Ejemplo DBD_1 Realice el proceso de Normalización para el documento "Hoja de control de Libros" para la Biblioteca de la Escuela Especializada en Ingeniería ITCA-FEPADE.

1FN: Dependencia funcional. No deben existir grupos repetidos para un valor clave. El primer paso es colocar todos los datos del documento en una tabla para analizar la información:

Podemos observar que un usuario puede solicitar en un mismo préstamo uno o más libros, por lo que los datos del préstamo y del lector, aunque pareciera que no se repiten en el documento si se repiten en la tabla. Separamos los datos que se repiten de los que no y crearemos dos tablas en la primera forma normal.

REPORTE

21

2FN: Dependencia Funcional Completa. Se trabaja sobre la tabla Detalle y se examinan todos los campos para verificar la dependencia funcional competa de todos los campos con respecto a las claves nPrestamo e ISBN. Se crea una nueva tabla con los atributos restantes, siendo su clave el subconjunto de atributos de la clave inicial de los que dependen de forma completa.

3FN: Dependencia Transitiva. Se evaluan todas las tablas examinando si existe dependencia transitiva entre los campos y la clave principal. Si se encuentra una de estas dependencias se crean nuevas tablas. Se crea una nueva tabla con los dos atributos no clave, que intervienen en la dependencia transitiva, seleccionando entre ambos a aquel que cumpla los requerimientos de clave. En la tabla origen el atributo no clave que origina la dependencia transitiva se convierte en una clave ajena.

REPORTE

22