ISGBD Material de lectura

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

Propósito de la Materia » » »

Ofrecer un tratamiento minucioso y sistemático del diseño lógico y conceptual. Basar este tratamiento en un modelo de entidades-interrelaciones. Recomendar que el diseño conceptual y el análisis funcional se desarrollen a la par.

»

Tratar de manera completa la conversión del diseño conceptual en el modelo de entidades-interrelaciones a los modelos populares de bases de datos: clase-objeto, relacional, de redes, jerárquicos. Representar la problemática de la retroingeniería desde estos tres modelos al modelo E-R. Ilustrar los conceptos mediante un caso de estudio realista y extenso. Ofrecer una visión general de la última tecnología en el campo de las herramientas de diseño. Ofrecer suficiente apoyo pedagógico para los estudiantes de esta metería, en términos de ejercicios y notas bibliográficas sobre la literatura pertinente.

» » » »

Acerca del Profesor: Nombre Completo:

Ana Liz Ramos de Barreto – [email protected] - (0981) 970-754

Antecedentes Académicos: Doctora en Educación con Énfasis en Educación Superior - UA Especialista en Evaluación y Acreditación de Instituciones de Educación Superior. UA Máster en Competencias y Tecnologías Emergentes para el Aprendizaje y Trabajo en Red – eProfesor. (UAA – ULPGC) Formación en Tutoría Virtual (OEA) Certificado de Incorporación de la Educación a Distancia en la Educación Superior. - Colegio de las Américas de la OUI-IOHE Máster en Marketing y Dirección Comercial (UA-Paraguay / CESMA-España). Especialización en Pedagogía (I.S.E). Postgrado en Didáctica Universitaria (Fac. de Derecho – UNA). Certificación Internacional MOS (Microsoft Office Specialist) – Master Instructor. Certificación Internacional MCAS (Microsoft Certified Application Specialist). Licenciada en Análisis de Sistemas (U.A.A.). Antigüedad en la cátedra: 13 años.

Conceptos Generales de las Bases de Datos Orígenes y Antecedentes de las Bases de Datos El término Base de Datos fue acuñado por primera vez en 1963, en un simposio celebrado en California. En la década del 70 Edgar Frank Codd definió el modelo relacional y publicó una serie de reglas para la evaluación de administradores de sistemas de datos relacionales y así nacieron las bases de datos relacionales. A partir de los aportes de Codd el multimillonario Larry Ellison desarrolló la base de datos Oracle, la cual es un sistema de administración de Base de Datos, que se destaca por sus transacciones, estabilidad, escalabilidad y multiplataforma. Inicialmente no se usó el Modelo Relacional debido a que tenía inconvenientes por el rendimiento, ya que no podían ser competitivas con las bases de datos Jerárquicas y de Red. Ésta tendencia cambio por un proyecto de IBM el cual desarrolló técnicas para la construcción de un sistema de bases de datos relacionales eficientes, llamado System R.

Prof.: Lic. Ana Liz Ramos de Barreto

1

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos En la década del 80 Las Bases de Datos Relacionales con su sistema de Tablas, Filas y Columnas, pudieron competir con las Bases de Datos Jerárquicas y de Red, ya que su nivel de programación era bajo y su uso muy sencillo. En esta década el Modelo Relacional ha conseguido posicionarse en el mercado de las Bases de Datos. Y también en este tiempo se iniciaron grandes investigaciones, como las Sistemas de Gestión de Bases de Datos Orientadas a Objetos SGBDOO (System Management Object Oriented Databases). . Principios década de los 90 Para la toma de decisiones se crea el lenguaje SQL (Structured Query Language) , que es un lenguaje programado para consultas. El programa de alto nivel SQL es un lenguaje de consulta estructurado que analiza grandes cantidades de información, el cual permite especificar diversos tipos de operaciones frente a la misma información, a diferencia de las bases de datos de los 80 que eran diseñadas para las aplicaciones de procesamiento de transacciones. Los grandes distribuidores de bases de datos incursionaron con la venta de bases de datos orientadas a objetos. Finales de la década de los 90 El boom de esta década fue la aparición de la WWW “Word Wide Web” ya que por este medio se facilitaba la consulta de las bases de datos. Actualmente tienen una amplia capacidad de almacenamiento de información, también una de las ventajas es el servicio de siete días a la semana las veinticuatro horas del día, sin interrupciones a menos que haya planificaciones de mantenimiento de las plataformas o el software. En la Actualidad Las bases de datos se han constituido como una de las herramientas más ampliamente difundidas en la actual sociedad de la información, utilizadas como fuentes secundarias en cuanto recuperación y almacenamiento de información en todos los campos a nivel científico, social, económico, político y cultural. Las bases de datos son una herramienta de vital importancia para el desarrollo de la actividad profesional; son utilizadas especialmente como fuentes de consulta y de producción de conocimiento por investigadores, científicos y académicos de todas las áreas, que han encontrado en éstas, una herramienta importante para el desarrollo del conocimiento.

Importancia del diseño de las bases de datos Una base de datos correctamente diseñada permite obtener acceso a información exacta y actualizada. Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la base de datos, parece lógico emplear el tiempo que sea necesario en aprender los principios de un buen diseño ya que, en ese caso, es mucho más probable que la base de datos termine adaptándose a sus necesidades y pueda modificarse fácilmente. El diseño de las bases de datos es el proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenidos y las aplicaciones por desarrollar. 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 las bases de datos desempeña un papel central en el uso de los recursos de información de la mayoría de las organizaciones.

¿Qué es un buen diseño de base de datos? El proceso de diseño de una base de datos se guía por algunos principios. El primero de ellos es que se debe evitar la información duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y aumentan la probabilidad de que se produzcan errores e incoherencias. El segundo principio es que es importante que la información sea correcta y completa. Si la base de datos contiene información incorrecta, los informes que recogen información de la base de datos contendrán también información incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarán mal fundamentadas. Un buen diseño de base de datos es, por tanto, aquél que:

Prof.: Lic. Ana Liz Ramos de Barreto

2

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos 

Divide la información en tablas basadas en temas para reducir los datos redundantes.



Proporciona a la base de datos la información necesaria para reunir la información de las tablas cuando así se precise.



Ayuda a garantizar la exactitud e integridad de la información.



Satisface las necesidades de procesamiento de los datos y de generación de informes.

El proceso de diseño El proceso de diseño consta de los pasos siguientes: 

Determinar la finalidad de la base de datos

Esto le ayudará a estar preparado para los demás pasos. 

Buscar y organizar la información necesaria

Reúna todos los tipos de información que desee registrar en la base de datos, como los nombres de productos o los números de pedidos. 

Dividir la información en tablas

Divida los elementos de información en entidades o temas principales, como Productos o Pedidos. Cada tema pasará a ser una tabla. 

Convertir los elementos de información en columnas

Decida qué información desea almacenar en cada tabla. Cada elemento se convertirá en un campo y se mostrará como una columna en la tabla. Por ejemplo, una tabla Empleados podría incluir campos como Apellido y Fecha de contratación. 

Especificar claves principales

Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequívocamente cada fila, como Id. de producto o Id. de pedido. 

Definir relaciones entre las tablas

Examine cada tabla y decida cómo se relacionan los datos de una tabla con las demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones según sea necesario. 

Ajustar el diseño

Analice el diseño para detectar errores. Cree las tablas y agregue algunos registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes necesarios en el diseño. 

Aplicar las reglas de normalización

Aplique reglas de normalización de los datos para comprobar si las tablas están estructuradas correctamente. Realice los ajustes necesarios en las tablas.

Fases del diseño de bases de datos El diseño de bases de datos se realiza generalmente en tres fases: La primera fase, llamada de diseño conceptual, produce una representación abstracta y de alto nivel de la realidad. La segunda fase, llamada de diseño lógico, convierte esta representación en especificaciones que pueden implantarse en un sistema de cómputo y ser procesadas por él. La tercera fase, llamada de diseño físico, determina las estructuras de almacenamiento físico y los métodos de consulta requeridos para un acceso eficaz a los contenidos de una base de datos a partir de dispositivos de almacenamiento secundario. Las fases del diseño lógico y conceptual pueden desarrollarse independientemente de la elección de un sistema de administración de bases de datos (DBMS, Data Base Management System) específico. El diseño de bases de datos representa un enfoque orientado a los datos para el desarrollo de los sistemas de información: la atención completa del proceso de diseño se centra en los datos y sus propiedades.

Prof.: Lic. Ana Liz Ramos de Barreto

3

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Fase 1. Diseño Conceptual: El diseños conceptual parte de la especificación de requerimientos y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independiente del software de DBMS que se use para su manipulación. Un modelo conceptual es un lenguaje que se usa para describir esquemas conceptuales. El propósito del diseño conceptual es describir el contenido de información de la base de datos, más que las estructuras de almacenamiento que se necesitarán para manejar esta información.

Fase 2. Diseño Lógico El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos que puede procesar el software de DBMS. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos; los modelos lógicos más usados pertenecen a las clases: clase-objeto, relacional, de redes y jerárquico. El diseño lógico depende de la clase de modelo de datos usado por el DBMS, no del DBMS utilizado.

Fase 3. Diseño Físico El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implantación de una base de datos en la memoria secundaria; describe las estructuras de almacenamiento y los métodos de almacenamiento y los métodos usados para tener un acceso efectivo a los datos. El diseño físico se adapta a un sistema DBMS específico. Existe una retroalimentación entre el diseño físico y el lógico, porque las decisiones tomadas durante el diseño físico para mejorar el rendimiento pueden afectar la estructura del esquema lógico.

Dependencia del:

El tipo de DBMS

Un DBMS específico

Diseño conceptual

No

No

Diseño Lógico

Si

No

Diseño Físico

Si

Si

Con la experiencia, el diseño de una base de datos se convierte en algo casi mecánico. En el proceso de modelado aplicamos reglas y generamos diseños normalizados e incluso desnormalizados casi sin pensar a través de la información adquirida en entrevistas con las personas de negocio. Ciertamente, un buen diseño de base de datos es crítico para cualquier proyecto, pero no siempre el fiel reflejo de la realidad es lo mejor en todos los casos. En un proyecto se creó una base de datos para mantener la información de cierto tipo de construcciones que contenían varios elementos. Como ejemplo, contemplemos sólo 3 elementos y simplifiquemos llamándolos elementos A, B y C, donde: A está formado por n elementos B; y B está formado a su vez por n elementos C. El diseño sería:

Prof.: Lic. Ana Liz Ramos de Barreto

4

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Este modelo era totalmente correcto, pero la aplicación fracasó ya que no se utilizaba, ¿dónde está el problema? Durante la fase de diseño nadie se preocupó de averiguar que los datos que iban a ser almacenados fuesen mantenibles, es decir, que hubiera personas/procesos/sistemas encargadas de mantener la relación entre las entidades. Resultó que aunque en la teoría los elementos B se componían de elementos C, no era viable (por recursos humanos y coste) identificar a qué elemento B pertenecía cada elemento C, aunque sí era necesario almacenar los elementos C. El diseño de datos fue cambiado por algo de este estilo:

Para tener en cuenta: El modelo de datos debe ser una herramienta de almacenamiento de datos mantenible por los usuarios.

¿Qué es una Base de Datos? Aquí se presentan algunas definiciones: Una base de datos está constituida por cierto conjunto de datos persistentes utilizado por los sistemas de aplicaciones de una empresa determinada.1 Puede definirse como una colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias...2 Conjunto de datos homogéneos, ordenados de una forma determinada que se presenta normalmente en forma legible por ordenador (en cinta magnética u otro soporte) y se refieren a una organización, materia o problema determinado.3

Para qué sirven? Las bases de datos sirven para localizar datos e informaciones de manera precisa y exhaustiva en el menor tiempo posible. Para extraer datos almacenados.

Propiedades 

Representa algún aspecto del mundo real, llamado universo de discurso (UoD, Universe of Discourse) del cual provienen los datos. Los cambios en el UoD se reflejan en la Base de Datos.



Es un conjunto de datos lógicamente coherente, con significado implícito. Un montón de datos sin relación entre sí, agrupados de forma aleatoria, no se considera una base de datos.



Toda base de datos se diseña, se crea y se carga con datos, con un objetivo determinado y está dirigida aun grupo de usuarios, interesados en el contenido de la base de datos.



Puede ser de cualquier tamaño o complejidad

Qué es un Sistema de Bases de Datos? Un sistema de Bases de Datos es básicamente un sistema para archivar en computador; o sea; es un sistema computarizado cuyo propósito general es mantener información y hacer que esté disponible cuando se le solicite. La información en cuestión puede ser cualquier cosa que se considere importante para el individuo o la organización a la cual debe servir el sistema.

1 2 3

CJDate, Introducción a los Sistemas de Gestión de Bases de Datos, Vol. I, Quinta Edición, Pág.11 James Martín, Organización de las Bases de Datos, Edit. Prentice Hall, Pág. 19 Definición dada por la Federación Internacional de Documentación (FID) en el ’80.

Prof.: Lic. Ana Liz Ramos de Barreto

5

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Distinción entre Dato e Información Dato: valor atómico con significado implícito. Los datos son símbolos que describen condiciones, hechos, situaciones o valores. Los datos se caracterizan por no contener ninguna información. Un dato puede significar un número, una letra, un signo ortográfico o cualquier símbolo que represente una cantidad, una medida, una palabra o una descripción. La importancia de los datos está en su capacidad de asociarse dentro de un contexto para convertirse en información. Por si mismos los datos no tienen capacidad de comunicar un significado y por tanto no pueden afectar el comportamiento de quien los recibe. Para ser útiles, los datos deben convertirse en información para ofrecer un significado, conocimiento, ideas o conclusiones. Información: Resultado del procesamiento de los datos. La información que se maneja debe responder a ciertas características para que el análisis y las medidas que se tomen correspondan efectivamente a una situación real previamente identificada. Exactitud: En este sentido la información debe reflejar el evento epidemiológico al cual se refiere y su sistema de medición expresado con poca variabilidad. Objetividad: La información debe ser el producto de criterios establecidos que permitan la interpretación en forma estandarizada por diferentes personas en circunstancias diversas de tiempo y lugar. Válida: Se refiere a que la información ha de permitir medir en forma precisa el concepto que se estudia, con criterios uniformes. Continuidad: La información ha de ser generada en forma permanente de tal manera que exista la disponibilidad de los datos a través del proceso de vigilancia. Completa: Debe contener todos los datos y variables previamente establecidas para cumplir con su finalidad en cada evento epidemiológico Oportuna: La información debe generarse y notificarse a la par con los acontecimientos de tal manera que permita la toma de decisiones y la actuación inmediata Comparable: que permita ser confrontada con datos similares. En algunos casos los términos “dato” e “información” se maneja como sinónimos. Pero es importante hacer una distinción entre ellos, empleando “datos” cuando se refieren a los valores almacenados en realidad en la base de datos, valores atómicos o compuestos (ej. El precio de un artículo, la fecha de nacimiento de un alumno, código de cliente, etc) e “información” cuando se refieren al significado resultante de la combinación de esos valores resulta importante para el usuario (ej. Datos organizados de alumnos para consultar sus promedios de notas). En esencia un sistema de bases de datos brindará al usuario los recursos necesarios para realizar operaciones sobre los archivos tales como:      

Agregar archivos nuevos (vacíos) a la base de datos; Obtener datos de archivos ya existentes; Actualizar datos en archivos ya existentes; Borrar datos en archivos ya existentes y Eliminar archivos ya existentes (vacíos o no) de la base de datos. Insertar datos nuevos en archivos ya existentes; Figura 1. 1 Dependencias del diseño, conceptual, lógico y físico de la clase de DBMS y el DBMS específico.

Requerimientos que debe satisfacer un Sistema de Administración de Bases de Datos 1. Versatilidad para la representación de relaciones a.

Diferentes programadores requieren diferentes archivos lógicos.

b.

Estos archivos deben derivarse de la misma colección de datos.

c.

Existen diversas relaciones entre los rubros de datos almacenados.

d.

Algunas bases de datos comprenden un complejo entretejido de relaciones.

e.

El método de organización debe tener la capacidad para representar estas relaciones y acomodar los posibles cambios futuros.

Prof.: Lic. Ana Liz Ramos de Barreto

6

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos f.

El DBMS debe tener capacidad para derivar, de datos y relaciones, los archivos lógicos que se requieran.

2. Desempeño a.

Deben asegurar un tiempo de respuesta adecuado para el diálogo entre el hombre y la terminal.

b.

Debe tener capacidad para un adecuado caudal de transacciones.

c.

El caudal de transacciones no tiene por que imponer muchas restricciones al diseño de la base de datos.

d.

Para ciertas categorías de diálogo se requiere un tiempo de respuesta del orden de dos segundos, etc.

3. Costo mínimo a.

Con el fin de mantener bajo el costo hay que elegir técnicas que minimicen las necesidades totales de almacenamiento. Apelando a estas técnicas, la representación física de los datos en el almacén puede ser muy distinta de la representación que usa el programador.

b.

La conversión entre ambas representaciones se hace por medio del software, o posiblemente del hardware o de la microprogramación.

c.

Debe llegar siempre a una concordancia entre el costo de los algoritmos de conversión y la economía de almacén.

d.

El costo por bit de almacenamiento está disminuyendo rápidamente gracias al progreso tecnológico, mientras que no ocurre lo mismo con el costo de la programación.

e.

Existe una necesidad creciente de mantener sencilla la programación de aplicación, y las organizaciones lógicas de datos deben diseñarse con este objetivo.

4. Redundancia mínima a.

Eliminar valores de datos redundantes, siempre que resulte económico.

b.

Controlar las incoherencias a que pueden dar lugar esos valores redundante.

c.

Almacenar datos que sean necesarios para diversos fines, manteniendo las relaciones pertinentes.

5. Capacidad de búsqueda a.

Exploración y obtención de los datos de manera rápida.

b.

Capacidad de explorar una base de datos rápidamente y con diferentes criterios de búsqueda.

c.

Capacidad de exploración rápida y flexible.

6. Integridad a.

No se pueda destruir datos almacenados ni las relaciones que existan entre ellos.

b.

El almacenamiento de los datos y los procedimientos de actualización e inserción de datos deben asegurar que el sistema pueda recuperarse de estas contingencias sin dañar los datos.

c.

Proteger los datos contra posibles problemas sistémicos, asegurando que los valores de los datos se ajusten a ciertas reglas prescritas de antemano.

7. Reserva (“privacidad”) y seguridad a.

Deben estar protegidas contra su pérdida o robo.

b.

Deben estar protegidas contra fallos del hardware o el software, contra catástrofes y contra criminales,

vándalos, incompetentes y personas que pretendan darle uso ilegítimo. c.

Protegerlos contra acceso accidental o intencional por parte de personas no autorizadas y contra su indebida destrucción o alteración.

d.

Reservarse al derecho de los individuos y organismos para determinar por sí mismos cuándo, cómo y en qué medida se permitirá la transmisión a terceros de la información que les concierne.

e.

Supervisión sobre las acciones de los usuarios de manera a ser descubierta cualquier acción indebida o errónea.

Prof.: Lic. Ana Liz Ramos de Barreto

7

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos 8. Interfaz con el pasado a.

Que permita poder trabajar con programas y procedimientos existentes y que los datos ya almacenados puedan ser convertidos a las nuevas formas.

9. Interfaz con el futuro a.

Planear de manera que se la pueda modificar sin necesidad de tener que alterar los programas de aplicación en uso.

10. Afinación a.

Debe permitir realizar ajustes de la organización del almacén con el objeto de mejorar su desempeño convirtiéndose así un proceso continuo. La operación está a cargo del Administrador o su grupo.

11. Migración de Datos: a.

Permita ajustar el almacenamiento de los daos de acuerdo son su popularidad de manera a poder accederlos más rápidamente. El proceso está a cargo del programador de sistema o del administrador de datos. En ocasiones se lo considera como parte del proceso de afinación de la base de datos.

12. Simplicidad a.

Los medios que se utilizan para representar la vista general de los datos deben ser concebidos de manera simple y nítida.

Los cuatro componentes principales de un sistema de bases de datos son: 1. Información Dentro de una base de datos – en sistemas grandes- estarán integradas y además será compartida. »

“Integrada” significa que la base de datos puede considerarse como una unificación de varios archivos de datos, por lo demás distintos y que elimina del todo o en parte cualquier redundancia entre ellos.

Ejemplo: Empleado Nombre

dirección

Departamento Salario

....

Inscripción Nombre »

Curso

“Compartida” significa que los elementos individuales de información en la base de datos pueden compartirse entre varios usuarios distintos, en el sentido de que todos ellos pueden tener acceso al mismo elemento de información (y diferentes usuarios pueden utilizarlos para propósitos diferentes). Esta capacidad de compartir (en forma simultánea o no) se desprende en parte de la integración de la base de datos.

2. Equipos Los componentes de un equipo del sistema son: Los volúmenes de almacenamiento secundario- por lo regular discos magnéticos de cabeza móvil- donde se conservan los datos almacenados, junto con los dispositivos de E/S asociados (unidades de discos, etc.), controladores de dispositivos, canales de E/S. Y demás. El procesador o procesadores y la memoria principal asociada que hacen posible la ejecución de los programas del sistema de bases de datos.

3. Programas Prof.: Lic. Ana Liz Ramos de Barreto

8

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Es el software que gerencia, administra, manipula y controla todas las operaciones que se realizan sobre la Base de Datos. Una de las funciones generales del DBMS es distanciar a los usuarios de la base de datos de detalles al nivel del equipo. Es uno de los componentes de software más importante de todo el sistema, junto con las utilería, las herramientas para desarrollar aplicaciones, las ayudas para el diseño, los generadores de informes, etc.

4. Usuarios: Podemos clasificarlos en tres clases: 1.

El programador de aplicaciones: se encarga de escribir los programas de aplicación que utilizan la base de datos.

2.

Usuario final: es quien interactúa con el sistema desde una terminal en línea. Puede tener acceso a la base de datos a través de las aplicaciones en línea o utilizar una interfaz incluida como parte integral de los programas del sistema de bases de datos.

3.

El administrador de bases de datos o DBA (Database Administrator).

Tipos de Estructuras de Bases de Datos 1. Estructura Jerárquica de una Base de Datos Este tipo de estructuras o árbol está compuesto por una jerarquía de elementos denominados nudos. El nivel más alto de la jerarquía tiene un solo nudo, el que se llama raíz. Con excepción de la raíz, todo nudo está vinculado a otro nudo de nivel más alto al que se denomina padre. Ningún elemento puede tener más de un padre. En cambio, todo elemento puede tener uno o más elementos relacionados, en un nivel más bajo; al que se los denomina hijos. Los elementos que se encuentran en las puntas de las ramas (es decir, que no tienen hijos) se llaman hojas. Este tipo de estructura se aplica a los archivos que exhiben relaciones de tipo árbol entre sus registros. Resulta satisfactorio para muchas aplicaciones, pero algunas estructuras de datos necesitan tener más de un padre, por lo que el software previsto para manejar solo archivos planos o archivos jerárquicos se ve limitado en su capacidad. Nivel 1 1

Raíz

Nivel 2 2

3

4

Nivel 3 5

6

7

8

9

15

16

17

10

11

12

Nivel 4 13

14

18

19

20

21

22

Hojas 23

2. Estructura Plex o Red En este tipo de estructura cualquier componente puede vincularse con cualquier otro. Como en el caso de la estructura jerárquica puede ser descrita en términos de padres e hijos y dibujada de tal manera que los hijos aparezcan debajo de los padres. Pero en la estructura plex un hijo puede tener más de un padre.

Prof.: Lic. Ana Liz Ramos de Barreto

9

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

1

2

1 1

3

2

1

2

3

4

2

3

5

3

4 6

7

9

10

8

4

11 5

Una estructura plex “simple se puede representar como una estructura jerárquica, agregando elementos redundantes. En algunos casos la redundancia es tolerable por lo escasa; en otros, ella es excesiva.

Ejemplo

3. Estructura del Modelo Entidad-Relacional (E-R). El modelo entidad-relación (modelo E-R) fue introducido por Peter Chen en 1976. En su informe, Chen estableció las bases del modelo, que a partir de entonces ha sido ampliado y modificado por el mismo Chen y muchos otros. Los símbolos empleados para expresar el modelo E-R difieren en forma significativa. El modelo ER es un modelo simple, potente y formal para representar la realidad. Además ofrece una base firme para enfocar y analizar formalmente muchos problemas relacionados con la gestión de bases de datos, como el diseño de la base de datos, la redundancia, la distribución, etc.

Prof.: Lic. Ana Liz Ramos de Barreto

10

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos La sencillez del modelo ha facilitado la construcción de lenguajes de consultas e interfaces para los usuarios finales de fácil utilización, y ha resultado en una productividad más alta de los programadores de bases de datos. Los elementos básicos de este modelo son las entidades, las relaciones y los atributos. Entidades: representan clases de objetos de la realidad, como una persona, lugar o cosa de interés para la comunidad usuaria y acerca del cual el sistema desea mantener, correlacionar y desplegar información, cosas que se pueden identificar claramente, objetos distinguibles en el sistema. Características de las entidades: a.

Son sustantivos

b.

Forman parte del alcance del sistema

c.

Tienen existencia propia y no dependen ni están subordinados a nada.

d.

Pueden ser tangibles. Ej. Edificio, Empleado, Alumno, Cliente, etc.

e.

Pueden ser intangibles. Ej. Departamentos, Cuentas, etc.

f.

Semi-tangibles. Ej. Ordenes, Facturas, Pedidos, etc.

g.

Poseen característica o propiedades. ALUMNO

Gráficamente son representados por rectángulos.

Interrelaciones: representan agregaciones de dos o más entidades. Atributos: Los atributos representan las propiedades básicas de las entidades o interrelaciones. Toda la información extensiva es aportada por los atributos. El elemento básico del modelo es la relación, y un esquema de base de datos relacional es una colección de definiciones de relaciones. El esquema de cada relación es una agregación de atributos; el conjunto de todos los valores que puede adoptar un atributo en particular se denomina dominio de ese atributo. Un caso de relación (también llamado extensión de la relación) es una tabla con filas y columnas. Las columnas de las relaciones corresponden a los atributos; las filas, denominadas tuplas, son colecciones de valores tomados de cada atributo, y desempeñan la misma función que los casos individuales de entidades en el modelo E/R. El grado de una relación es el número de columnas; la cardinalidad de una relación es el número de tuplas. La tabla 1. muestra un ejemplo de los ejemplo citados. La relación ESTUDIANTE tiene tres atributos (NOMBRE, EDAD Y SEXO) y cinco tuplas, cada una representando nombre, edad y sexo de un estudiante. Por tanto, el grado y la cardinalidad de ESTUDIANTE son tres y cinco, respectivamente.

Nombre

Edad

Sexo

John Smith

19

Varón

Sally Boyce Tom Hagen Lucy Lein Henry Folle

23 25 20 19

Mujer Varón Mujer Varon

Tabla 1 Ejemplo de un esquema y caso relacional Es necesario que el programador o el administrador de datos tenga capacidad para referirse a un registro o una tupla relacionado con cierta entidad, y es preciso que la computadora tenga capacidad para identificarlo y medios para encontrarlo en la unidad de almacenamiento. Para ello es necesario conferir a uno de los atributos el carácter de identificador de entidad. De esta manera, el identificador de entidad de un empleado sería el NÚMERO-DE-EMPLEADO. El identificador debe ser único; ninguna otra entidad puede tener el mismo valor para este atributo. En algunas ocasiones son requeridos más de un atributo para identificar un registro. Claves

Prof.: Lic. Ana Liz Ramos de Barreto

11

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Se denomina clave al atributo o conjunto de atributos que la computadora utiliza para identificar un registro o una tupla. Definiéndose la clave primaria como aquella que se utiliza para definir unívocamente un registro o una tupla, es decir, el identificador de entidad formada por uno o más atributos. También existen claves que no identifican registros únicos, sino todos aquellos que tienen cierta propiedad y son denominadas claves secundarias. A menudo un archivo tienen varias claves secundarias, utilizadas para explorar el archivo en busca de entidades que tienen determinadas propiedades.

   

Clave candidata: Conjunto no vacío de atributos que identifican univoca y mínimamente cada tupla. Clave primaria: La que el usuario escoge de las calves candidatas. Claves alternativas: Claves candidatas que no han sido escogidas. Clave ajena: Conjunto de atributos de la tabla cuyos valores han de coincidir con los de la clave primaria de otra tabla. (Clave ajena y primaria debe estar definida sobre los mismos dominios).

4. Sistemas Orientados a Objetos. El modelo relacional para algunas representaciones presenta deficiencias. Existen obviamente dos maneras de abordar los problemas causados por tales deficiencias: a.

Ampliar el modelo relacional en forma apropiada

b.

Desechar por completo el modelo relacional y sustituirlo por algo nuevo.

El modelo orientado a objetos define una base de datos en términos de objetos, sus propiedades y sus operaciones. Los objetos con la misma estructura y comportamiento pertenecen a una clase, y las clases se organizan en jerarquías o grafos acíclicos. Las operaciones de cada clase se especifican en términos de procedimientos predefinidos denominados métodos. Algunos SGBD relacionales existentes en el mercado han estado extendiendo sus modelos para incorporar conceptos orientados a objetos. A estos SGBD se les conoce como sistemas objeto-relacionales. Las entidades y los objetos son similares en algunas formas y diferentes en otras.

Entidades/Objetos  Son representaciones de algunas cosas identificables en el ambiente de trabajo de los usuarios.  Es un conjunto de atributos que describen con eficacia una entidad bien determinada.  Se agrupan en clases.

Semejanzas

 Una clase de objeto tiene un nombre que la hace diferente a otras y que corresponde a los nombres de las cosas que representa.  Tiene un conjunto de atributos.  Representan identidades bien definidas; son algo que los usuarios reconocen como independencia y separado de lo que desean registrar y reportar.  Pueden o no tener existencia física  El modelo E-R considera básico el concepto de entidad.

Diferencias

 El modelo de objeto considera fundamental el concepto de objeto donde el conjunto de estos objetos representan el mapa de la estructura esencial de las cosas que el usuario considera importantes.

La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto. Los sistemas de bases de datos orientados a objetos (SBDOO) tienen sus orígenes en los lenguajes de programación orientados a objetos (LPOO). La idea fundamental en ambos casos es que el usuario no debería tener batallar con construcciones orientadas al computador tales como registros y campos, sino más bien debería poder manejar objetos que se asemejen más a sus equivalentes en el mundo real. La idea fundamental del modelado semántico es tratar de identificar un conjunto de construcciones que parezcan útiles de manera genérica, en el sentido de que se presenten en alguna forma o variedad en una amplia gama de aplicaciones. Como ejemplos de estas construcciones podemos mencionar las claves primarias, claves

Prof.: Lic. Ana Liz Ramos de Barreto

12

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos ajenas y dominios (al nivel del modelo relacional); los núcleos, características y asociaciones, etc. Si podemos identificar y formalizar tales construcciones y así hacerlos “más inteligentes”.

Clase

Cliente

Persona

Objetos Exclusivos

Sociedad

Empresa

Clase

Empresa

Empresa Gravable

Objetos Anidados

Empresa no Gravable

Agencia Gubernamental

Escuela

Modelo de Datos Relacional Universo de Discurso (UoD), es la parte o visión del mundo real relevante para nuestro Sistema de Información. Se trata de la información del mundo real que sirve a nuestro sistema para su funcionamiento. Según sea la parte del mundo que esté orientado, el sistema tendrá uno o varios universos del discurso. Por ejemplo en el caso de una frutería, puede haber una universo del discurso relativo al almacén, donde nos interesan características de los productos como tipo de producto, cantidad almacenada, precio de compra, etc. Otro universo relativo a los proveedores donde no interesan datos como nombre, dirección, etc.

Entidad - Tablas Objeto del mundo real con existencia propia (física o abstracta) y distinguible del resto de los objetos. Representación Bi-Dimensional de Datos que está compuesto por filas y columnas. También se lo llama relación.

Registros (Filas) Cada uno de los renglones de la tabla (tupla o tuple).

Atributos (Columnas) Propiedad de una entidad. Describen a la entidad. Ej. Película está descrita pos su título, género, nacionalidad, fecha del fin del rodaje, etc. Cada entidad en particular tendrá un valor para cada atributo, que son los valores de datos que se almacenarán en la BD. Cada uno de los elementos verticales de la tabla que representa a cada valor atómico de misma.

Los tipos de atributos pueden ser: a. Simples: No divisibles. Atómicos. Ej. Sexo, Color, Nacionalidad, Nombre

Prof.: Lic. Ana Liz Ramos de Barreto

13

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos b. Compuestos: Pueden dividirse en otros atributos con significado propio. Ej. Fecha en Dia-MesAño; la dirección en calle-ciudad-provincia-codpostal, etc. c.

Monovaluados: que tiene un único valor para cada entidad. Ej. Fecha de nacimiento [de un director].

d. Multivaluados: Mas de un valor para la misma entidad. Ej. Nacionalidad [de una película coproducida por varios países], etc. y pueden tener límite superior e inferior del n° de valores por entidad Ej. Nacionalidad (1-4); n° teléfono [de un director] (0-3). e. Derivados: Su valor se calcula a partir de otra información ya existente (atributos, interrelaciones, ...). Son informaciones redundantes como la “edad”, que puede ser calculada a partir de la fecha de nacimiento. f.

Almacenados: Su valor no se deriva de otros atributos como son la nacionalidad, fecha de nacimiento, etc. SITUACIONS

NOMBRE

S#

CIUDAD

Dominios

S

Relación

S# S1 S2 S3 S4 S5

SNombre Salazar Jaime Bernal Corona Aldana

Situación 20 10 30 20 30

Ciudad Londres París París Londres Atenas

Tuplas

Cardinalidad

Clave Primaria

Atributos Grado Características a. b. c. d.

No puede haber tuplas duplicadas EL orden de las tuplas es irrelevante La tabla es plana, en el cruce entre un atributo y una tupla sólo puede haber un valor. El orden de los atributos o columnas en una tabla debe ser arbitrario. Las columnas no están ordenadas (de izquierda a derecha). Si el orden de las columnas no es arbitrario, entonces la tabla tendrá las siguientes propiedades indeseables: » Datos implícitos y no explícitos. » Un nro. limitado y arbitrario de ocurrencias. » Un mantenimiento anormal de la tabla al querer insertar una nueva columna. » Una recuperación anormal de la información ya que la posición actual de los valores es inseparable. e. El orden de las filas en una tabla debe ser arbitrario. Las tuplas no están ordenadas (de arriba hacia abajo).

Convención para nominación a. Los nombres de tablas deben ser únicos dentro del sistema. Prof.: Lic. Ana Liz Ramos de Barreto

14

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos b. c. d. e. f. g.

Los nombres de columnas deben ser únicos dentro de cada tabla. Los nombres de las filas y las columnas deben ser seleccionadas con cuidado. Seleccionar los nombres de las tablas y las columnas con los usuarios. Elegir nombres de tablas y columnas breves. Usar formas en singular antes que en plural. Usar nombres de dominios sin cualificación donde fuere posible. Ejemplo: cualificador.nombredominio. Nombres de dominios que requieren cualificación: Fechas, Horas, Cantidades, Montos.

Dominio Conjunto de valores manejado por un sistema. Cada atributo simple está asociado a un dominio que especifica sus valores válidos. Mas de una columna pueden estar basados en el mismo dominio.

Reglas: Dos atributos están basados en el mismo dominio si los correspondientes valores en cada columna se refieren a la misma persona, lugar o cosa del mundo real. Los dominios son importantes porque ellos definen comparaciones lógicas válidas entre tablas y sus contenidos, permiten conocer homónimos y sinónimos y dan a conocer el alcance del sistema diseñado. El número de dominios de un sistema debe ser minimizado. Los dominios deben ser no-descomponibles en lo que al sistema concierne. Ej. Un nro. de empleado 1-10-0002 donde 1 es el nro. de dpto., 10 la sección y 0002 el del empleado, en la tabla deben representarse en 3 columnas diferentes. Por razones de conveniencia los dominios de FECHAS y HORAS son reconocidas como excepciones a esta regla y que los mismos están constituidos por Día, Mes, y Año y Hora, Minutos y Segundos respectivamente.

Atributo

Dominio Nombres: cadenas de caracteres alfabéticos, separadas Nombre por espacios. Teléfonos: cadenas de caracteres numéricos de hasta 9 Teléfono caracteresAltura Medidas: números decimales entre 0y 2.5 (metros) Nacionalidad Nacionalidades: “Inglesa”, “española”, “francesa” fechaNacimiento Fechas: Fechas válidas

ASOCIACIONES Es un relacionamiento o interrelacionamiento entre dos o más entidades (u otras asociaciones), de interés para el usuario y acerca del cual el sistema mantiene, correlaciona y despliega información. Podría decirse también que es una vinculación entre entidades.

Características a. Las asociaciones forman parte del alcance del sistema b. Las asociaciones pueden darse de tres forma: uno a uno (1:1); uno a muchos (1:M) y muchos a muchos (M:M). c. La mayoría de las asociaciones son BINARIAS (dos entidades intervienen en la asociación), pero también pueden ser N-ARIAS (tres o mas entidades intervienen en la asociación).

Prof.: Lic. Ana Liz Ramos de Barreto

15

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Tipos de asociaciones Asociación Uno a Uno: se da cuando dos entidades (A y B) están vinculadas de la siguiente manera: cada ocurrencia de una de la entidad A está vinculada a lo máximo con una sola ocurrencia de la entidad B y cada ocurrencia de la entidad B está relacionada a lo máximo con una sola ocurrencia de la entidad A.

1

País

1

Bandera

Las asociaciones uno a uno se modelan ubicando la PK de una de las entidades como FK en la otra entidad sin admitir duplicados (ND) en esta última entidad. Este tipo de asociaciones se da muy rara vez y su uso es poco frecuente. Ejemplo:

País IDPaís PK

País IDPaís PK

IDBandera FK,ND

Bandera IDBandera PK

Bandera IDBandera

PK

IDPaís FK,ND

Asociación Uno a Muchos: este tipo de asociación de da cuando dos entidades (A y B) están vinculadas de la siguiente manera: cada ocurrencia de la entidad A está vinculada a cero, una o más ocurrencias de la entidad B, pero cada ocurrencia de la entidad B está vinculada a al menos a una ocurrencia de la entidad A.

País

1

M

Ciudad

Las asociaciones uno a muchos se modelan ubicando la PK de la entidad A como FK en la entidad B. Este tipo de asociaciones son muy frecuentes

País IDPaís PK

Ciudad IDCiudad PK

IDPaís FK

Una asociación Muchos a Muchos se da cuando dos entidades A y B por ejemplo están vinculadas de la siguiente manera: cada ocurrencia de la entidad A está vinculada a ero, una o mas ocurrencias de la entidad B y cada ocurrencia de la entidad B está vinculada a cero, una o más ocurrencias de la entidad A.

Alumno

M

M

Profesor

Este tipo de asociaciones se modelan definiendo una nueva tabla con una clave primaria compuesta. Los componentes de la nueva tabla son las claves primarias de las entidades A y B. Estos dos componentes pueden conformarse como claves primaria compuesta de la nueva tabla e individualmente son definidas como FK’s.

Alumno IDAlumno PK

Prof.: Lic. Ana Liz Ramos de Barreto

16

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Profesor IDProfesor PK Alumno/Profesor IDAlumno IDProfeso r PK + FK FK

LAS CLAVES EN EL MODELO ER. En el modelo relacional, el concepto de concepto de clave esta definido de una manera muy similar al concepto de identificador en el modelo ER.; una clave de una relación es un conjunto de atributos de la relación que identifica de manera única cada tupla de cada extensión de esa relación. Así, la única diferencia entre nuestro uso de identificadores y claves es que en el modelo relacional sólo se acepta la identificación interna. En general, una relación puede tener más de una clave, y cada clave se denomina clave candidata. Por ejemplo, la relación PERSONA puede tener dos claves candidatas: la primera un número de seguro social (NSS); la segunda una clave compuesta formada por (APELLIDO, NOMBRE). Es común designar una de las claves como clave primaria de la relación.

Propiedades de las claves primarias: a. Unicidad: en cualquier momento dado, no existen dos tuplas en R con el mismo valor de K. b. Minimalidad: Si K es compuesto, no será posible eliminar ningún componente de K sin destruir la propiedad de unicidad. Clave ajena, es un atributo (quizá compuesto) de una relación R2 cuyos valores deben concordar con os de la clave primaria de alguna relación R1. Un valore de clave ajena representa una referencia a la tupla donde se encuentra el valor correspondiente de la clave primaria. El problema de garantizar que la base de datos no incluya valores no válidos de una clave ajena se conoce como el problema de la integridad referencial. Una clave ajena dada y la clave primaria correspondiente deben definirse sobre el mismo dominio. La clave ajena no necesita ser un componente de la clave primaria de la relación que la contiene.

TABLAS PRIMAS Las tablas primas son tablas con una clave primaria constituida por una sola columna (con compuesta). Las demás tablas son Tablas No-Primas.

Reglas: a.

Las Tablas Primas siempre modelan entidades.

b.

Las entidades son siempre modeladas por tablas.

TABLAS ASOCIATIVAS Son tabla no primas cuyos componentes de PK son todos (con posibilidad de serlo compuestas) FK.

Reglas: a.

Las tablas asociativas siempre modelan asociaciones M:M

b.

Las asociaciones M:M siempre son modeladas por tablas Asociativas.

c.

Las filas de una tabla asociativa nunca representan cosas, personas o lugares de interés para el usuario, representan los vínculos e interrelaciones entre tales personas, lugares o cosas.

Prof.: Lic. Ana Liz Ramos de Barreto

17

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos d.

Es aconsejable modelar primero las tablas primas de las entidades involucradas en la asociación M:M y luego la tabla asociativa correspondiente.

e.

Las tablas asociativas se nombran normalmente de las siguiente forma: Nombre-Tabla-PrimaA/Nombre-Tabla-PrimaB De esta manera de logra mantener el orden alfabético de las tablas y su secuencia lógica sincronizada y ayuda a ubicar rápidamente a las tablas primas involucradas en la asociación.

REGLAS DE INTEGRIDAD RELACIONAL Cualquier base de datos se compone de alguna configuración de valores de los datos, de tal forma que esta configuración de valores refleje la realidad o representación de algún fragmento del mundo real. Para ello es necesario incluir ciertas reglas de integridad, cuyo propósito es informar al DBMS de ciertas restricciones en el mundo real para que pueda impedir la ocurrencia de tales configuraciones imposibles de valores. Ej.: el peso no puede tener una valor negativo. La mayor parte de las bases de datos estarán sujetas a un gran número de tales reglas de integridad.

Regla de integridad de las entidades Es una de las dos reglas generales de integridad del modelo relacional. Esta regla es muy sencilla y dice así;

“Ningún componente de la clave primaria de una relación base puede aceptar nulos” Un valor nulo es aquella donde falta valor por alguna razón. La justificación de la regla de integridad de las entidades es la siguiente: a.

La relación base (las tuplas dentro de las relaciones base) corresponden a entidades en el mundo real. Ej., la relación base S corresponde a un conjunto de proveedores del mundo real.

b.

Por definición, las entidades en el mundo real son distinguibles; es decir, se les puede identificar de alguna manera.

c.

Los representantes de entidades dentro de la base de datos deben ser distinguibles (identificables) también.

d.

Las claves primarias realizan esta función de identificación única en el modelo relacional.

Regla de Integridad Referencial Esta es la segunda regla general de integridad del modelo relaciona.

“La base de datos no debe contener valores de clave ajena sin concordancia” Así como los valores de la clave primaria representan identificadores de entidades, así los valores de la clave ajena representan referencias a entidades. La regla de integridad referencial dice tan solo que si B hace referencia a A, entonces A debe existir. A partir de estas definiciones surgen los siguientes puntos: a.

La integridad referencial exige concordancia de las claves ajenas muy específicamente, con claves primarias, no con claves alternativas.

b.

Los conceptos de clave ajena e integridad referencial se definen uno en términos del otro. No es posible explicar que es una clave ajena sin mencionar la noción de integridad referencial y de igual forma es imposible explicar que es la integridad referencial sin mencionar la noción de clave ajena.

Bibliografía:  C.J.Date – Introducción a los Sistemas de Bases de datos – Vol. I – Quinta Edición  J.Martín – Organización de las Bases de Datos  Batini/Ceri/Navathe – Diseño Conceptual de Bases de Datos  David M. Kroenke – Procesamiento de Bases de Datos – Quinta Edición. Prof.: Lic. Ana Liz Ramos de Barreto

18

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

Ejercicios de Aplicación Elabore un esquema lógico en notación E/R que permita describir correctamente los requisitos de datos que incluyen los siguientes enunciados. a. Una empresa produce CDs con un código y un título; cada CD ha sido grabado por uno o más cantantes, cada uno de los cuales tiene un nombre y una dirección, y algunos de ellos tienen un nombre artístico. b. Una empresa de alquiler de vehículos tiene una bolsa de automóviles, en la cual cada uno tiene nº de registro, marca y color, y pertenece a una categoría; para cada categoría está establecida una tarifa de alquiler. c. En una universidad los alumnos de una determinada titulación, cada curso académico, se matriculan en diferentes asignaturas de dicha titulación y de algunas otras por libre configuración. d. En un jardín zoológico hay animales que pertenecen a una especie determinada y que tienen cierta edad; cada especie está situada en un sector (que tiene un nombre) del zoológico.

Prof.: Lic. Ana Liz Ramos de Barreto

19

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

Peligros en el diseño de bases de datos relacionales. Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que: a.

El sistema de base de datos no sufra de anomalías de almacenamiento.

b.

El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.

Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en un ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos experimenta una reorganización general cada seis años, dependiendo de lo dinámico de los requerimientos de los usuarios. Una base de datos bien diseñada tendrá un buen desempeño aunque aumente su tamaño, y será lo suficientemente flexible para incorporar nuevos requerimientos o características adicionales. Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma, los riesgos generalmente son la redundancia de información y la inconsistencia de datos.

Normalización La normalización es el proceso de simplificar la relación entre los campos de un registro. Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que son más simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por cuatro razones:

 Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.  Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes.  Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.  Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones. En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en ella. Pasos de la Normalización: a.

Descomponer todos los grupos de datos en registros bidimensionales.

b.

Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro.

c.

Eliminar todas las relaciones que contengan dependencias transitivas.

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. Reglas de Normalización: a.

Eliminar redundancias e inconsistencias de dependencia en el diseño de las tablas.

b.

Las bases de datos deben ser funcionales y eficientes.

Formas Normales. Son las técnicas para prevenir las anomalías en las tablas. Dependiendo de su estructura, una tabla puede estar en primera forma normal, segunda forma normal o en cualquier otra. Relación entre las formas normales:

Prof.: Lic. Ana Liz Ramos de Barreto

20

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Formalización Cero Se da cuando a una tabla ninguna regla de normalización ha sido aplicada. Usuario Nombre Juan

ABC

DirEmpresa JOB1

URL1 Abc.com

URL2 Def.com

July

DEF

WORK1

Abc.com

Wyz.com

Empresa

Qué pasará si se quiere agregar una URL3? Primera y Segunda Forma Normal. Primera FormaNnormal. Definición formal: Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos. Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando cumplen las siguientes reglas: a.

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.

b.

Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.

c.

Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.

d.

Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.

e.

Eliminar los grupos repetitivos de las tablas individuales

f.

Crear una tabla por cada grupo de datos relacionados

g.

Identificar cada grupo de datos relacionados con una clave primaria.

Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir que la mayoría de las relaciones se encuentran en la primera forma normal. Usuario IDUsr 1 2 3 4

Nombre Juan

Empresa ABC

DirEmpresa JOB1

URL abc.com

Juan July July

ABC DEF DEF

JOB1 WORK1 WORK1

xyz.com abc.com xyz.com

Esta tabla está en primera forma normal porque se solucionó la limitación del campo URL. Pero existe duplicación en el nombre de la empresa y el usuario. Esto hace que crezca mucho y hará fácil que la base de datos se corrompa si se escribe mal algunos de los datos redundantes. Ejemplificación gráfica de las relaciones en primera forma normal considerando la relación alumno cursa materia cuyo diagrama E-R es el siguiente:

Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal. A ambos ejemplos se debe aplicar el segundo nivel de Formalización/Normalización (2FN).

Prof.: Lic. Ana Liz Ramos de Barreto

21

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Segunda Forma Normal. Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s).

Definición formal: Una relación R está en 2FN si y solo si está en 1FN y los atributos no primos dependen funcionalmente de la llave primaria. Una relación se encuentra en segunda forma normal, cuando cumple con las siguientes reglas: a.

Estar en primera forma normal

b.

Que todos sus atributos que no son claves (llaves) dependen por completo de la clave.

c.

Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.

d.

Relacionar estas tablas a través de claves externas.

e.

De acuerdo con está definición, cada tabla que tiene un atributo único como clave, esta en segunda forma normal.

Usuario IDUsr 1

Nombre Juan

Empresa ABC

DirEmpresa JOB1

2

July

DEF

WORK1

URL’s IDUrl 1 2 3 4

relUsr 1 1 2 2

URL abc.com xyz.com abc.com xyz.com

Se han creado la clave primaria a la tabla USUARIO y está relacionada a través de la clave externa con la tabla URL’s. Pero que pasa si queremos agregar más empleados a la empresa. Se duplicarían el nombre de la empresa y la dirección, pudiéndose generar errores en los datos por lo que se debe aplicar la tercera formalización/normalización. Gráficamente la segunda forma normal podemos representar por dependencias funcionales como:

Nótese que las llaves primarias están representadas con doble cuadro, las flechas nos indican que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave primaria.

Prof.: Lic. Ana Liz Ramos de Barreto

22

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Tercera Forma Normal y la Forma Normal de Boyce Codd. Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C pero no determina a A. Tercera Forma Normal. Definición formal: Una relación R está en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria. Reglas: a.

Eliminar aquellos campos que no dependan de la clave.

Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relación esta en tercera forma normal si está en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe más de una forma de llegar a referencias a un atributo de una relación.

Usuario IDUsr 1

IDEmpresa 1

Nombre Juan

2 3 4 5

2 1 1 1

July Ana Ema Mario

Empresa IDEmpresa 1

Empresa ABC

DirEmpresa ABC

2

DEF

DEF

Considerando un ejemplo gráfico:

Tenemos la relación alumno-cursa-materia manejada anteriormente, pero ahora consideramos al elemento maestro, gráficamente lo podemos representar de la siguiente manera:

Prof.: Lic. Ana Liz Ramos de Barreto

23

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos, entonces tenemos:

Forma Normal de Boyce Codd. Determinante: Uno o más atributos que, de manera funcional, determinan otro atributo o atributos. En la dependencia funcional (A,B)  C, (A,B) son los determinantes. Definición formal: Una relación R esta en FNBC si y solo si cada determinante es una llave candidata. Son tablas que solo tienen claves externas.

URL’s IDUrl 1 2 3 4

Prof.: Lic. Ana Liz Ramos de Barreto

URL abc.com xyz.com abc.com xyz.com

24

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos Usuario IDUsr 1

IDEmpresa 1

Nombre Juan

2 3 4 5

2 1 1 1

July Ana Ema Mario

URL’s/Usuario IDUsr 1 2 2 3

IDUrl 1 1 2 1

Gráficamente continuando con el ejemplo anterior y si consideramos que en la entidad alumno sus atributos control y nombre nos puede hacer referencia al atributos esp., entonces decimos que dichos atributos pueden ser llaves candidatas. Podemos representar la forma normal de Boyce Codd de la siguiente forma:

Observando que a diferencia de la tercera forma normal, agrupamos todas las llaves candidatas para formar una global (representadas en el recuadro) las cuales hacen referencia a los atributos que no son llaves candidato.

Cuarta y Quinta Forma Normal Cuarta Forma Normal. Definición formal: Un esquema de relaciones R está en 4FN con respecto a un conjunto D de dependencias funcionales y de valores múltiples sí, para todas las dependencias de valores múltiples en D de la forma X  Y, donde X  R y Y  R, se cumple por lo menos una de estas condiciones:



X  Y es una dependencia de valores múltiples trivial.



X es una superllave del esquema R.

Para entender mejor aún esto consideremos una afinidad (tabla) llamada estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:

Clave S01 S01 S01 B01 C03

Especialidad Sistemas Bioquímica Sistemas Bioquímica Civil

Curso Natación Danza Natación Guitarra Natación

Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El estudiante con clave S01 tiene su especialidad en sistemas y Bioquímica y toma los cursos de Natación y danza, el estudiante B01 tiene la especialidad en Bioquímica y toma el curso de Guitarra, el estudiante con clave C03 tiene la especialidad de Civil y toma el curso de natación.

Prof.: Lic. Ana Liz Ramos de Barreto

25

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos En esta tabla o relación no existe dependencia funcional porque los estudiantes pueden tener distintas especialidades, un valor único de clave puede poseer muchos valores de especialidades al igual que de valores de cursos. Por lo tanto existe dependencia de valores múltiples. Este tipo de dependencias produce redundancia de datos, como se puede apreciar en la tabla anterior, en donde la clave S01 tiene tres registros para mantener la serie de datos en forma independiente lo cual ocasiona que al realizarse una actualización se requiera de demasiadas operaciones para tal fin. Existe una dependencia de valores múltiples cuando una afinidad tiene por lo menos tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen solo del tercer atributo, en otras palabras en la afinidad R (A,B,C) existe una dependencia de valores múltiples si A determina valores múltiples de B, A determina valores múltiples de C, y B y C son independientes entre sí. En la tabla anterior Clave determina valores múltiples de especialidad y clave determina valores múltiples de curso, pero especialidad y curso son independientes entre sí. Las dependencias de valores múltiples se definen de la siguiente manera: Clave  Especialidad y Clave  Curso; Esto se lee "Clave multidetermina a Especialidad, y clave multidetermina a Curso". Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los atributos de valores múltiples. Para nuestro ejemplo, las tablas correspondientes son:

Tabla Especialidad Clave

Especialidad

Tabla ECurso Clave

Curso

S01

Sistemas

S01

Natación

B01

Bioquímica

S01

Danza

C03

Civil

B01

Guitarra

C03

Natación

Quinta Forma Normal. Definición formal: Un esquema de relaciones R está en 5FN con respecto a un conjunto D de dependencias funcionales, de valores múltiples y de producto, si para todas las dependencias de productos en D se cumple por lo menos una de estas condiciones:

a. (R1, R2, R3, ... Rn) es una dependencia de producto trivial. b. Toda Ri es una superllave de R. La quinta forma normal se refiere a dependencias que son extrañas. Tiene que ver con tablas que pueden dividirse en subtablas, pero que no pueden reconstruirse.

Prof.: Lic. Ana Liz Ramos de Barreto

26

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos

A Trabajar Objetivos Crear esquemas conceptuales de bases de datos sencillos, empleando la notación del modelo conceptual de datos Entidad-Relación. Valorar y comparar diferentes opciones de diseño conceptual para representar una misma situación, en función de su corrección y adecuación a los requisitos de datos. Elegir la opción de diseño conceptual más adecuada entre varias alternativas posibles, justificando y argumentando la decisión tomada.

Contenidos Esta práctica consiste en el planteamiento y resolución de una serie de ejercicios sencillos de diseño de esquemas conceptuales, mediante los cuales se enfrentará, quizá por primera vez, al problema del diseño conceptual de bases de datos utilizando el modelo Entidad-Relación. Para realizar los ejercicios basta con que utilice lápiz y papel. Es conveniente que trate de resolverlos de forma individual, aunque más tarde pueda discutir sus ideas con sus compañeros, y siempre antes de ser discutidos en clase. Durante las sesiones de prácticas, y de forma conjunta profesora/alumnos, se revisará cada ejercicio, se comentarán y compararán las diferentes representaciones posibles y se discutirán las ventajas e inconvenientes de cada una de ellas.

1. Esquema Conceptual de Datos de un Banco Un banco gestiona las cuentas corrientes y las cuentas de ahorro de sus clientes. El banco permite que un mismo cliente sea el titular de varias cuentas corrientes o bien de varias cuentas de ahorro, o bien posea a la vez cuentas de ambos tipos. Según la política del banco, una misma cuenta de ahorro puede ser compartida por varios clientes, pero una cuenta corriente sólo puede tener un titular. De los clientes, interesa representar su código de cliente, CI, nombre (completo), dirección y teléfono de contacto. De las cuentas, se representará el número de cuenta y el saldo actual. No todos los clientes del banco son personas, sino que algunos son instituciones u organizaciones (de negocios, no lucrativas, religiosas, agencias gubernamentales, etc.). El banco desea distinguir entre los diferentes tipos de clientes, pues tienen características y propiedades diferentes. Para los clientes «humanos», se desea representar su CI, fecha de nacimiento y sexo. Para los clientes institucionales se desea representar su RUC, Razón Social, de qué tipo (de organización) son, su número de empleados y el nombre del representante o persona de contacto.

2. Esquema Conceptual de Datos de Ventas Una empresa del sector del mueble y la madera se dedica a la fabricación y venta de muebles de diversos tipos (sillas, mesas, sofás...); cada uno de los tipos de producto está compuesto de una serie de modelos concretos, de forma que los artículos a la venta se conocen por su tipo y el modelo al que pertenecen (silla SC22, mesa E20x30, etc.) tal y como aparecen en el catálogo comercial de la empresa. Uno de los departamentos es el encargado de la recepción de los pedidos que los clientes hacen llegar a la empresa, ya sea por carta, teléfono, fax o correo electrónico. Un cliente puede realizar cuantos pedidos desee. Cuando el operario del departamento de ventas recibe un pedido, crea la correspondiente “orden de pedido” que, más adelante, hará llegar al departamento de producción y entrega y al de facturación. Al crear la orden de pedido, el operario le asigna un número de pedido y anota en la misma la fecha actual y el nombre, dirección postal y electrónica (si la posee) y código del cliente que realiza el pedido.

Prof.: Lic. Ana Liz Ramos de Barreto

27

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos La orden de pedido incluye además la relación de artículos solicitados por el cliente a la empresa: para cada producto pedido indica el código correspondiente al tipo y modelo concreto que el cliente solicita (armario X500, cabezal Victoria), una descripción del mismo, la cantidad (número de unidades) pedida y el precio de cada unidad del producto. En una orden de pedido aparecerá como mínimo un producto solicitado y no hay, en principio, un límite del número de productos diferentes que pueden incluirse en un pedido. Cada tipo y modelo de producto concreto puede aparecer una sola vez en cada orden de pedido, y puede aparecer en muchas órdenes de pedido distintas. Es posible que alguno de los productos fabricados por la empresa nunca sea solicitado por los clientes. Modificación: Considere ahora que se permite que un mismo producto aparezca varias veces en una misma orden de pedido; esto sería necesario si, por ejemplo, se regalara una unidad de producto por cada tres adquiridas, pues debería anotarse en el pedido “3 unidades del producto ‘silla Victoria’ a precio por unidad de 50.000 ptas., y 1 unidad de ‘silla Victoria’ a precio 0”. ¿Qué otras ventajas tiene esta segunda representación, en comparación con la anterior?

3. Esquema Conceptual de Datos de una Biblioteca En una biblioteca se necesita un sistema para llevar el control de los libros que se tienen catalogados, los lectores o socios de la biblioteca y los préstamos de libros a dichos lectores. Un libro puede tener varios autores y ha sido publicado por una editorial. Un mismo autor puede haber escrito varios libros distintos, para diferentes editoriales. Cada libro tiene un conjunto de ejemplares o copias. La biblioteca consiste en realidad de una serie de sucursales de la biblioteca, aunque la gestión de la información está centralizada (en la sucursal principal). De este modo, las copias de los libros están repartidas entre las diferentes sucursales. Cada sucursal de la biblioteca tiene su propio nombre, dirección y número de teléfono. De los libros interesa representar su ISBN, título, el género al que pertenecen (novela, ensayo, divulgación, científico, épica fantástica, etc.), la edición y el año de publicación. De las editoriales interesa representar su nombre, dirección y teléfono de contacto. De los lectores interesa representar su número de socio, dirección y teléfono. También se desea representar el número de ejemplares de cada uno de los libros asignados a cada sucursal de la biblioteca. Un lector puede tener varios libros prestados al mismo tiempo, hasta un máximo de cuatro. Cuando un lector se lleva (un ejemplar de) un libro, se anota la fecha actual como fecha de préstamo y la de 15 días después como fecha de devolución, puesto que es política de la biblioteca sancionar a aquellos socios que no devuelvan los libros en el plazo establecido, retirándoles el carné de lector durante los 15 días siguientes a la devolución (real) del ejemplar, en consecuencia de lo cual durante dicho plazo de tiempo no podrán tomar prestado ningún otro libro. Ampliación 1: Un libro puede estar publicado en diferentes idiomas. Ampliación 2: Considere además las sucesivas ediciones de libros (tras actualización, revisión, etc.).

4. Esquema Conceptual de Datos de un Colegio Mayor En un colegio mayor interesa recoger en lo que a cada uno de sus residentes se refiere, el CI, nombre, dirección (domicilio familiar), edad, sexo, el centro en el que cursa sus estudios, y sus datos bancarios a efectos de domiciliar el pago de las mensualidades por el alquiler de las habitaciones. El colegio dispone de habitaciones de una, dos o tres camas. En las habitaciones compartidas sólo se pueden alojar los residentes del mismo sexo, y uno de ellos es el responsable de la habitación. El colegio organiza diversas actividades en las que los residentes pueden participar de forma voluntaria. Las actividades son individuales o bien colectivas; se programan (al principio de cada curso académico) para una fecha (de comienzo) determinada y se identifican por un código, además, cada actividad tiene asociada una descripción, que da más información acerca de lo que consiste dicha actividad. En las actividades colectivas se participa por equipos. De cada equipo interesa representar su nombre, el número de residentes que lo componen, y el nombre y primer apellido de cada uno de ellos. Un mismo equipo puede participar en varias actividades colectivas. Un mismo residente sólo puede pertenecer a un equipo. Además, un residente, independientemente de que pertenezca o no a un equipo, también puede participar en varias actividades individuales.

Prof.: Lic. Ana Liz Ramos de Barreto

28

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos 5.- Esquema Conceptual de SERVICIO MILITAR El Ministerio de Defensa desea diseñar una Base de Datos para llevar un cierto control de los soldados que realizan el servicio militar. Los datos significativos a tener en cuenta son: 

Un soldado se define por su código de soldado (único), su nombre y apellidos, y su graduación.



Existen varios cuarteles, cada uno se define por su código de cuartel, nombre y ubicación.



Hay que tener en cuenta que existen diferentes Cuerpos del Ejército (Infantería, Artillería, Armada, ....), y cada uno se define por un código de Cuerpo y denominación.



Los soldados están agrupados en compañías, siendo significativa para cada una de éstas, el número de compañía y la actividad principal que realiza.



Se desea controlar los servicios que realizan los soldados (guardias, imaginarias, cuarteleros, ...), y se definen por el código de servicio y descripción.

Consideraciones de diseño: 

Un soldado pertenece a un único cuerpo y a una única compañía, durante todo el servicio militar. A una compañía pueden pertenecer soldados de diferentes cuerpos, no habiendo relación directa entre compañías y cuerpos.



Los soldados de una misma compañía pueden estar destinados en diferentes cuarteles, es decir, una compañía puede estar ubicada en varios cuarteles, y en un cuartel puede haber varias compañías. Eso si, un soldado sólo esta en un cuartel.



Un soldado realiza varios servicios a lo largo de la milicia. Un mismo servicio puede ser realizado por más de un soldado (con independencia de la compañía), siendo significativa la fecha de realización.

6. Esquema Conceptual GESTIÓN DE TRABAJOS DE FIN DE CARRERA. Una Escuela de Informática quiere generar un sistema para tener controlado en una base de datos todo lo referente a los Trabajos Fin de Carrera: alumnos que los realizan, profesores que los dirigen, temas de los que tratan y tribunales que los corrigen. Por tanto, es de interés: 

Que los alumnos se definan por su número de matrícula, CI y nombre. Un alumno realiza, evidentemente, sólo un T.F.C.



Que los T.F.C. se definen por su tema, por un número de orden y por la fecha de comienzo. Un T.F.C. determinado, no puede ser realizado por varios alumnos.



Que un profesor se define por su CI, nombre y domicilio; y puesto que los T.F.C. son del área en el que trabaja, NO interesa conocer el T.F.C. que dirige sino a qué alumno se lo dirige.



Que un Tribunal está formado por varios profesores y los profesores pueden formar parte de varios tribunales. Por otra parte, sí es de interés para el tribunal conocer qué alumno es el que se presenta, con qué T.F.C. y en qué fecha lo ha defendido. El tribunal se define por un número de tribunal, lugar de examen y por el número de componentes.



Al margen de esto, un alumno puede haber pertenecido a algún grupo de investigación del que haya surgido la idea del T.F.C. Dichos grupos se identifican por un número de grupo, su nombre y por su número de componentes. Un alumno no puede pertenecer a más de un grupo y no es de interés saber si el grupo tiene algo que ver o no con el T.F.C. del alumno; sí siendo de interés la fecha de incorporación a dicho grupo.



Por otra parte, un profesor, al margen de dirigir el T.F.C. de algunos alumnos, puede haber colaborado con otros en la realización de dicho T.F.C. pero siendo otro profesor el que lo dirige. En este caso, sólo es interesante conocer qué profesor ha ayudado a qué alumno (a un alumno le pueden ayudar varios profesores).

7. Esquema Conceptual AGENCIAS DE VIAJES Una cadena de agencias de viajes desea disponer de una Base de Datos que contemple información relativa al hospedaje y vuelos de los turistas que la contratan. Los datos a tener en cuenta son:

Prof.: Lic. Ana Liz Ramos de Barreto

29

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos 

La cadena de agencias está compuesta por un conjunto de sucursales. Cada sucursal viene definida por el código de sucursal, dirección y teléfono.



La cadena tiene contratados una serie de hoteles de forma exclusiva. Cada hotel estará definido por el código de hotel, nombre, dirección, ciudad, teléfono y número de plazas disponibles.



De igual forma, la cadena tiene contratados una serie de vuelos regulares de forma exclusiva.



Cada vuelo viene definido por el número de vuelo, fecha y hora, origen y destino, plazas totales y plazas de clase turista de las que dispone.



La información que se desea almacenar por cada turista es el código de turista, nombre y apellidos, dirección y teléfono.



Por otra parte, hay que tener en cuenta la siguiente información:



A la cadena de agencias le interesa conocer que sucursal ha contratado el turista.



A la hora de viajar el turista puede elegir cualquiera de los vuelos que ofrece la cadena, y en que clase (turista o primera) desea viajar.



De igual manera, el turista se puede hospedar en cualquiera de los hoteles que ofrece la cadena, y elegir el régimen de hospedaje (media pensión o pensión completa). Siendo significativa la fecha de llegada y de partida.

8. Esquema Conceptual GESTIÓN DE EXÁMENES Los profesores de la asignatura de Bases de Datos de una Escuela Universitaria deciden crear una base de datos que contenga la información de los resultados de las pruebas realizadas a los alumnos. Para realizar el diseño se sabe que: 

Los alumnos están definidos por su n° de matrícula, nombre y el grupo al que asisten a clase.



Dichos alumnos realizan dos tipos de pruebas a lo largo del curso académico:

1. Exámenes escritos: cada alumno realiza varios a lo largo del curso, y se definen por el n° de examen, el n° de preguntas de que consta y la fecha de realización (la misma para todos los alumnos que realizan el mismo examen). Evidentemente, es importante almacenar la nota de cada alumno por examen. 2. Prácticas: se realiza un n° indeterminado de ellas durante el curso académico, algunas serán en grupo y otras individuales. Se definen por un código de práctica, título y el grado de dificultad. En este caso los alumnos pueden examinarse de cualquier práctica cuando lo deseen, debiéndose almacenar la fecha y nota obtenida. En cuanto a los profesores, únicamente interesa conocer (además de sus datos personales: CI y nombre), quien es el qué ha diseñado cada práctica, sabiendo que en el diseño de una práctica puede colaborar más de uno, y que un profesor puede diseñar más de una práctica. Interesa, además, la fecha en que ha sido diseñada cada práctica por el profesor correspondiente.

9. Esquema Conceptual CONCESIONARIO DE AUTOMÓVILES Un concesionario de automóviles desea informatizar su gestión de ventas de vehículos. En particular, se quiere tener almacenada la información referente a los clientes que compran en el concesionario, los vehículos vendidos, así como los vendedores que realizan las distintas ventas. Para ello se tendrá en cuenta que: 

El concesionario dispone de un catálogo de vehículos definidos por su marca, modelo, cilindrada y precio.



Cada uno de los modelos dispondrá de unas opciones adicionales (aire acondicionado, pintura metalizada, etc.). Las opciones vienen definidas por un nombre y una descripción. Hay que tener en cuenta que una opción puede ser común para varios modelos variando sólo el precio en cada caso.



En cuanto a los clientes, la información de interés es el nombre, CI, dirección y teléfono, lo mismo que para los vendedores.



Los clientes pueden ceder su coche usado en el momento de comprar un vehículo nuevo. El coche usado vendrá definido por su marca, modelo, matrícula y precio de tasación. Es importante conocer la fecha en la que el cliente realiza esta cesión.

Prof.: Lic. Ana Liz Ramos de Barreto

30

Universidad Autónoma de Asunción Facultad de Ciencias Informática Introducción a los Sistemas de Gestión de Bases de Datos 

Se desea saber qué vendedor ha vendido qué modelo a qué cliente. También la fecha de la venta y la matricula del nuevo vehículo. Es importante así mismo saber las opciones que el cliente ha elegido para el modelo que compra.

10. Esquema Conceptual HOLDING EMPRESARIAL Un holding de empresas desea tener una base de datos referente a las empresas que posee, sus vendedores, así como los asesores que trabajan en el holding. La información está organizada de la siguiente forma: 

Los vendedores se organizan en una jerarquía de pirámide, es decir, cada vendedor puede captar otros vendedores para el holding, de manera que un vendedor tendrá a su cargo varios vendedores. Hay que tener en cuenta que un vendedor sólo podrá trabajar en una empresa y sólo podrá captar vendedores para la empresa en que trabaja; siendo importante almacenar la fecha en que se realiza la captación. Los datos de interés para los vendedores serán el código de vendedor, nombre y la dirección.



Las empresas cubrirán diferentes áreas del mercado y un mismo área puede ser cubierta por varias empresas. Es interesante conocer el nombre del área y una descripción de ésta. Las empresas pueden estar actuando en varios países y en un país pueden estar desarrollando actividades varias empresas. Sin embargo, cada empresa tendrá su sede en un único país, siendo importante la ciudad donde se localiza la sede. Por cuestiones fiscales, una empresa puede tener su sede en un país en el que no esté desarrollando actividad alguna. Los datos de interés para las empresas son el nombre, la fecha de entrada en el holding, la facturación anual y el número de vendedores que posee.



Los datos de interés de los países son: el nombre, el PIB, el número de habitantes y la capital.



Los asesores entran en el holding para dar soporte en cada una de las áreas en las que actúa el holding. Un asesor puede cubrir varias áreas y un área puede ser cubierta por varios asesores. Un asesor puede asesorar a varias empresas y una empresa tener varios asesores. Es importante saber en qué fecha un asesor comienza a trabajar para una empresa en un área determinada. Los datos de interés de los asesores son el código de asesor, nombre, dirección y la titulación.

Para todos los enunciados se pide: a. Realizar el Diseño Lógico correspondiente a la Base de Datos Relacional utilizando el Diagrama Entidad/Relación en el que figurarán de forma obligatoria todos los atributos de cada una de las entidades. b. Realizar el paso a Tablas del Diseño Lógico obtenido en el punto anterior, obteniendo el menor número posible de tablas relacionales. c. Especificar justificadamente las claves de las tablas relacionales obtenidas en el paso anterior y obtener un esquema relacional en Tercera Forma Normal hasta la FNBC si es que se da el caso. d. Crear las bases de datos respectivas en un SGBD y con los registros mínimos necesarios para la realización de las prácticas en clase cuando el profesor así lo requiera.

Prof.: Lic. Ana Liz Ramos de Barreto

31