Base de datos

“ BASE DE DATOS I” CATEDRATICO: Ing. Guadalupe Hernández Coca E-Mail: isc_ghc@hotmail.com

UNIDAD TEMATICA UNIDAD I. Introducción a las bases de datos 1. Antecedentes históricos de las bases de datos 2. Conceptos generales de las bases de datos 3. Necesidad y justificación del uso de las bases de datos Sistema de información (si) desde un enfoque sistémico 4. Ciclo de vida de un sistema de base de datos 5. Elementos que componen una bases de datos Características generales Funciones Sistema manejador de las bd y usuarios de las bd 6. Características de los diferentes manejadores de bases de datos

UNIDAD II. Modelos de las base de datos 1. Modelo conceptual Identificación de datos internos y externos Modelo Entidad – Relación Generalidades de construcción 2. Modelo lógico Identificación de las entidades y atributos Tipos de modelos de bases de datos (relacional, jerárquico, red y orientado a objetos) 3. Modelo físico Generalidades de construcción Tipos de campos Dominio y cardinalidad

1. Modelo de red o reticular Definición Lineamientos de construcción Tres clases de conjuntos Notación Ventajas y desventajas Diseño del modelo lógico 2. Modelo jerárquico Definición Lineamientos de construcción Operadores de almacenamiento Ventajas y desventajas Diseño del modelo lógico 3. Modelo orientada a objetos Sistemas orientados a objetos Conceptos generales La tecnología orientada a objetos Abstracción, jerarquía de datos, herencia, encapsulamiento Características avanzadas del SMBDOO UNIDAD III. Modelo de base de datos red, jerárquica y orientada a objetos .

UNIDAD IV. Diseño de las bases de datos relacionales 1. Diseño conceptual Simbología del modelo entidad-relación Construcción del modelo Entidad-Relación Herramientas para el diseño 2. Diseño lógico relacional Definiciones Conversión del modelo E-R al modelo relacional Lineamientos para el desarrollo del modelo relacional Definición de una relación Identificación de relaciones entre entidades Obligatoriedad de las relaciones Definición de las diferentes claves Normalización de la base de datos Ejemplos de aplicación

3. Diseño físico Proceso del diseño físico de la base de datos Diseño de los campos Diseño de los ficheros físicos Uso y selección de índices Documentación de la base de datos

UNIDAD V. Lenguajes de bases de datos relacionales 1. Álgebra relacional Operaciones fundamentales Operaciones adicionales Cálculo relacional de tuplas Modificación de una bases de datos (Actualización, inserción y eliminación) Definición de Vistas Actualización por medio de vistas y valores nulos 2. Lenguaje estructurado de consulta (SQL) Definición de la estructura (Select, From y Where) Funciones de agregados (Count, Sum, Avg, Max, Min) Consultas con cláusulas de agrupación (Group by) Operaciones de conjuntos Potencialidad del SQL Consultas de creación, eliminación y actualización de tablas 3. Casos de aplicación

FORMA DE EVALUACIÓN Sistema de evaluación 30-30-40 (dos exámenes parciales que corresponden al 60% de la calificación. Un examen global que corresponde al 40% de la calificación). Dando un total del 70% de la calificación Final. PRACTICAS 15% TAREAS 5% PARTICIPACIÓN EN CLASE 5% ASISTENCIA 5%

BIBLIOGRAFIA SUGERIDA Fundamentos De Bases De Datos Henrry F. Kort, Abraham Silberschatz Mac Graw Hill 2da. Edición Abril, 1995 Introducción A Los Sistemas De Bases De Datos C. J. Date Addison-Wesly Iberoamerica Vol. 1 5ta. Ed.

I . INTRODUCCIÓN A LAS BASES DE DATOS 1. ANTECEDENTES Surgen desde mediados de los años sesenta la historia de las bases de datos, en 1970 Codd propuso el modelo relacional, este modelo es el que ha marcado la línea de investigación por muchos años, ahora se encuentran los modelos orientados a objetos.

2. CONCEPTOS GENERALES Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, alfanuméricos. Información: Es un conjunto ordenado de datos los cuales son manejados según la necesidad del usuario, para que un conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a información, primero se debe guardar lógicamente en archivos. Campo: Es la unidad más pequeña a la cual uno puede referirse en un programa. Desde el punto de vista del programador representa una característica de un individuo u objeto.

Registro: Colección de campos de iguales o de diferentes tipos. Archivo: Colección de registros almacenados siguiendo una estructura homogénea. Base de Datos: Una base de datos es un “almacén” que nos permite guardar grandes cantidades de información de forma organizada para que luego podamos encontrar y utilizar fácilmente. Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada. En una base de datos, además de los datos, también se almacena su descripción. Desde el punto de vista informático, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos. Cada base de datos se compone de una o más tablas que guarda un conjunto de datos. Cada tabla tiene una o más columnas y filas. Las columnas guardan una parte de la información sobre cada elemento que queramos guardar en la tabla, cada fila de la tabla conforma un registro.

3 . NECESIDADES Y JUSTIFICACIÓN DEL USO DE LAS BASES DE DATOS Ventajas del uso de la base de datos. Independencia de datos y tratamiento. Cambio en datos no implica cambio en programas y viceversa (Menor coste de mantenimiento). Coherencia de resultados. Reduce redundancia. Mejora en la disponibilidad de datos Cumplimiento de ciertas normas. Restricciones de seguridad. Accesos (Usuarios a datos). Operaciones (Operaciones sobre datos).

4. CICLO DE VIDA DE UN SISTEMA DE BASE DE DATOS Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes: Planificación del proyecto. Definición del sistema. Recolección y análisis de los requisitos. Diseño de la base de datos. Selección del SGBD. Diseño de la aplicación. Prototipado. Implementación. Conversión y carga de datos. Prueba. Mantenimiento. Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación . Por ejemplo, los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una recolección de requisitos adicional y su posterior análisis. A continuación, se muestran las tareas más importantes que se realizan en cada etapa.

1. Planificación del proyecto Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será necesaria y cómo se va a llevar a cabo el diseño y la implementación.

2. Definición del sistema En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación. 3. Recolección y análisis de los requisitos En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas: Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés. Observando el funcionamiento de la empresa. Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información. Utilizando cuestionarios para recoger información de grandes grupos de usuarios. La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación grupo de usuarios. Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos de los usuarios..

4. Diseño de la base de datos Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera fase consiste en la producción de un esquema entidad relacion, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria. Los objetivos del diseño de la base de datos son: Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos. Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos. Especificar un esquema que alcance las prestaciones requeridas para el sistema.

5. Selección del SGBD Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico. 6. Diseño de la aplicación En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y procesen los datos de la base de datos. Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema debe ser fácil de aprender, fácil de usar y ser directo. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a dudas.

7. Prototipado Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rápidamente. Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías.

8. Implementación En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios. Las sentencias de este lenguaje se pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. En esta etapa, también se implementan los menús, los formularios para la introducción de datos y los informes de visualización de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de aplicaciones mediante lenguajes de consultas, generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.

9. Conversión y carga de datos Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo. 10. Prueba En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de test con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los Programas de aplicación y en la estructura de la base de datos.

11. Mantenimiento Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas: Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos. Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.

ELEMENTOS QUE COMPONEN UNA BASE DE DATOS Los componentes principales de un sistema de base de datos son el hardware, el software DBMS y los datos a manejar, así como el personal encargado del manejo del sistema.

Sistema Manejador de Base de Datos. (DBMS) El sistema manejador de bases de datos es la porción más importante del software de un sistema de base de datos. Un DBMS es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de una tarea específica. El objetivo primordial de un sistema manejador base de datos es proporcionar un contorno que sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular información de la base de datos. Todas las peticiones de acceso a la base, se manejan centralizadamente por medio del DBMS, por lo que este paquete funciona como interfase entre los usuarios y la base de datos.

DBMS Y SUS FUNCIONES Las funciones principales de un DBMS son: Crear y organizar la Base de datos. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que los datos puedan ser accesados rápidamente. Manejar los datos de acuerdo a las peticiones de los usuarios. Registrar el uso de las bases de datos. Interacción con el manejador de archivos. El DBMS es conocido también como Gestor de Base de datos

Usuarios de las bases de datos Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto con el sistema de base de datos desde que este se diseña, elabora, termina y se usa. Los usuarios que accedan una base de datos pueden clasificarse como: Administrador de base de datos (DBA): Es la persona o equipo de personas profesionales responsables del control y manejo del sistema de base de datos, generalmente tiene (n) experiencia en DBMS, diseño de bases de datos, Sistemas operativos, comunicación de datos, hardware y programación. Programadores de aplicaciones. Los profesionales en computación que interactúan con el sistema por medio de llamadas en DML (Lenguaje de Manipulación de Datos), las cuales están incorporadas en un programa escrito en un lenguaje de programación (Por ejemplo, COBOL, PL/I, Pascal, C, etc.)

Usuarios sofisticados. Los usuarios sofisticados interactúan con el sistema sin escribir programas. En cambio escriben sus preguntas en un lenguaje de consultas de base de datos. Usuarios especializados. Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que no Encajan en el marco tradicional de procesamiento de datos. Usuarios ingenuos. Los usuarios no sofisticados interactúan con el sistema invocando a uno de los programas de aplicación permanentes que se han escrito anteriormente en el sistema de base de datos, podemos mencionar al usuario ingenuo como el usuario final que utiliza el sistema de base de datos sin saber nada del diseño interno del mismo por ejemplo: un cajero.

CARACTERÍSTICAS DE LOS DIFERENTES MANEJADORES DE LAS BASES DE DATOS

MANEJADOR DE BASE DE DATOS E s la porción más importante del software de un sistema de base de datos.

VENTAJAS Proveen facilidades para la manipulación de grandes volúmenes de datos. Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos DESVENTAJAS Coste Complejidad Tamaño

EJEMPLOS APACHE DERBY FOXPRO ACCESS SQL SERVER FIREBIRD

Para introducirnos en este tema, empezaremos definiendo que es un modelo. Modelo: Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica.

¿Qué es modelo de datos? Una de las características fundamentales de los sistemas de bases de datos es que proporcionan cierto nivel de abstracción de datos, al ocultar las características sobre el almacenamiento físico que la mayoría de usuarios no necesita conocer. Los modelos de datos son el instrumento principal para ofrecer dicha abstracción. Un modelo de datos es un conjunto de conceptos que sirven para describir la estructura de una base de datos: los datos, las relaciones entre los datos y las restricciones que deben cumplirse sobre los datos. Los modelos de datos contienen también un conjunto de operaciones básicas para la realización de consultas (lecturas) y actualizaciones de datos. Además, los modelos de datos más modernos incluyen conceptos para especificar comportamiento, permitiendo especificar un conjunto de operaciones definidas por el usuario. Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la base de datos.

MODELO CONCEPTUAL Los modelos de datos de alto nivel, o modelos conceptuales , disponen de conceptos muy cercanos al modo en que la mayoría de los usuarios percibe los datos. Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Los modelos conceptuales utilizan conceptos como entidades, atributos y relaciones. Una entidad representa un objeto o concepto del mundo real como, por ejemplo, un empleado de la empresa inmobiliaria o una oficina. Un atributo representa alguna propiedad de interés de una entidad como, por ejemplo, el nombre o el salario del empleado. Una relación describe una interacción entre dos o más entidades, por ejemplo, la relación de trabajo entre un empleado y su oficina.

Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación . Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades: Expresividad : deben tener suficientes conceptos para expresar perfectamente la realidad. Simplicidad : deben ser simples para que los esquemas sean fáciles de entender. Minimalidad : cada concepto debe tener un significado distinto. Formalidad : todos los conceptos deben tener una interpretación única, precisa y bien definida.

Se trata de obtener el esquema conceptual de la base de datos a partir de la lista descriptiva de objetos y asociaciones identificadas en la organización durante el análisis. Se recomienda realizar esta Modelización en varias etapas. Luego de cada etapa se realiza una "depuración" de la etapa precedente. Todas las etapas se apoyan sobre el mismo modelo: el modelo relacional introducido en el universo de la estructuración de datos. Esquemáticamente, el proceso de Conceptualización lleva a elaborar varias colecciones de esquemas de relaciones que deben traducirse de la manera mas sintética incluyendo la representación de los objetos y asociaciones que constituyen la realidad organizacional. MODELO CONCEPTUAL

El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Es una herramienta para el modelado de datos de un sistema de información. Expresa entidades relevantes para un sistema de información, sus inter-relaciones y propiedades. Fue introducido por Peter Chen en 1976. Sus siglas: E-R "Entity relationship", ó "DER" Diagrama de Entidad Relación MODELO ENTIDAD-RELACIÓN

Utiliza diagramas entidad relación. Consiste en los siguientes pasos: 1.-Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos). 2.-Se hace una lista de los sustantivos y verbos que aparecen. 3.-Los sustantivos son posibles entidades o atributos. 4.-Los verbos son posibles relaciones. 5.-Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. 6.-Se elabora el diagrama (o diagramas) entidad-relación. 7.-Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama. Se caracteriza por utilizar una serie de símbolos y reglas para representar los datos y sus relaciones. Representa de manera grafica la estructura lógica de una base de datos.

Entidad: Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Ejemplo: coches, casas, empleados, etc. Se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual. Relación (interrelación) :Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.

Atributo Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.

Identificador Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones: No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse. Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores.

Ejemplo de dos entidades con sus atributos, relacionadas entre si

GENERALIDADES DE CONSTRUCCIÓN El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos humanos, etc. Estas visiones de la información, denominadas vistas , se pueden identificar de varias formas. Una opción consiste en examinar los diagramas de flujo de datos, que se pueden haber producido previamente, para identificar cada una de las áreas funcionales. La otra opción consiste en entrevistar a los usuarios, examinar los procedimientos, los informes y los formularios, y también observar el funcionamiento de la empresa.

A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales . Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores. El esquema conceptual también tendrá una documentación, que se irá produciendo durante su desarrollo. Las tareas a realizar en el diseño conceptual son las siguientes: Identificar las entidades. Identificar las relaciones. Identificar los atributos y asociarlos a entidades y relaciones. Determinar los dominios de los atributos. Determinar los identificadores. Determinar las jerarquías de generalización (si las hay). Dibujar el diagrama entidad-relación. Revisar el esquema conceptual local con el usuario.

1. Identificar las entidades En primer lugar hay que definir los principales objetos que interesan al usuario. Estos objetos serán las entidades. Una forma de identificar las entidades es examinar las especificaciones de requisitos de usuario. En estas especificaciones se buscan los nombres o los sintagmas nominales que se mencionan (por ejemplo: número de empleado, nombre de empleado, número de inmueble, dirección del inmueble, alquiler, número de habitaciones). También se buscan objetos importantes como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sólo son propiedades de otros objetos. Por ejemplo, se pueden agrupar el número de empleado y el nombre de empleado en una entidad denominada empleado , y agrupar número de inmueble, dirección del inmueble, alquiler y número de habitaciones en otra entidad denominada inmueble .

Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por ejemplo, empleado es una entidad porque los empleados existen, sepamos o no sus nombres, direcciones y teléfonos. Siempre que sea posible, el usuario debe colaborar en la identificación de las entidades. Conforme se van identificando las entidades, se les dan nombres que tengan un significado y que sean obvias para el usuario. Los nombres de las entidades y sus descripciones se anotan en el diccionario de datos. Cuando sea posible, se debe anotar también el número aproximado de ocurrencias de cada entidad. Si una entidad se conoce por varios nombres, éstos se deben anotar en el diccionario de datos como alias o sinónimos.

2. Identificar las relaciones Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas. Del mismo modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Si las especificaciones de requisitos reflejan estas relaciones es porque son importantes para la empresa y, por lo tanto, se deben reflejar en el esquema conceptual. Pero sólo interesan las relaciones que son necesarias. En el ejemplo anterior, se han identificado las relaciones empleado gestiona inmueble y cliente visita inmueble . Se podría pensar en incluir una relación entre empleado y cliente: empleado atiende a cliente , pero observando las especificaciones de requisitos no parece que haya interés en modelar tal relación. La mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que también puede haber relaciones en las que participen más de dos entidades, así como relaciones recursivas.

3. Identificar los atributos y asociarlos a entidades y relaciones Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son atributos los nombres que identifican propiedades, cualidades, identificadores o características de entidades o relaciones. Lo más sencillo es preguntarse, para cada entidad y cada relación, ¿qué información se quiere saber de ...? La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Pero, en ocasiones, será necesario preguntar a los usuarios para que aclaren los requisitos. Desgraciadamente, los usuarios pueden dar respuestas a esta pregunta que también contengan otros conceptos, por lo que hay que considerar sus respuestas con mucho cuidado. Al identificar los atributos, hay que tener en cuenta si son simples o compuestos.

Por ejemplo, el atributo dirección puede ser simple, teniendo la dirección completa como un solo valor: `San Rafael 45, Almazora'; o puede ser un atributo compuesto, formado por la calle (`San Rafael'), el número (`45') y la población (`Almazora'). El escoger entre atributo simple o compuesto depende de los requisitos del usuario. Si el usuario no necesita acceder a cada uno de los componentes de la dirección por separado, se puede representar como un atributo simple. Pero si el usuario quiere acceder a los componentes de forma individual, entonces se debe representar como un atributo compuesto.

4. Determinar los dominios de los atributos El dominio de un atributo es el conjunto de valores que puede tomar el atributo. Por ejemplo el dominio de los números de oficina son las tiras de hasta tres caracteres en donde el primero es una letra y el siguiente o los dos siguientes son dígitos en el rango de 1 a 99; el dominio de los números de teléfono y los números de fax son las tiras de 9 dígitos. Un esquema conceptual está completo si incluye los dominios de cada atributo: los valores permitidos para cada atributo, su tamaño y su formato. También se puede incluir información adicional sobre los dominios como, por ejemplo, las operaciones que se pueden realizar sobre cada atributo, qué atributos pueden compararse entre sí o qué atributos pueden combinarse con otros. Aunque sería muy interesante que el sistema final respetara todas estas indicaciones sobre los dominios, esto es todavía una línea abierta de investigación. Toda la información sobre los dominios se debe anotar también en el diccionario de datos.

5. Determinar los identificadores Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos. De cada entidad se escogerá uno de los identificadores como clave primaria en la fase del diseño lógico. Cuando se determinan los identificadores es fácil darse cuenta de si una entidad es fuerte o débil. Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son padre , propietaria o dominante ). Si una entidad no tiene atributos que le sirvan de identificador, es débil (otras denominaciones son hijo , dependiente o subordinada ). Todos los identificadores de las entidades se deben anotar en el diccionario de datos.

6. Determinar las jerarquías de generalización En este paso hay que observar las entidades que se han identificado hasta el momento. Hay que ver si es necesario reflejar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirán nuevas subentidades de esta entidad genérica; o bien, si hay entidades que tienen características en común y que realmente son subentidades de una nueva entidad genérica. En cada jerarquía hay que determinar si es total o parcial y exclusiva o superpuesta.

7. Dibujar el diagrama entidad-relación Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad-relación correspondiente a una de las vistas de los usuarios. Se obtiene así un esquema conceptual local.

8. Revisar el esquema conceptual local con el usuario Antes de dar por finalizada la fase del diseño conceptual, se debe revisar el esquema conceptual local con el usuario. Este esquema está formado por el diagrama entidad-relación y toda la documentación que describe el esquema. Si se encuentra alguna anomalía, hay que corregirla haciendo los cambios oportunos, por lo que posiblemente haya que repetir alguno de los pasos anteriores. Este proceso debe repetirse hasta que se esté seguro de que el esquema conceptual es una fiel representación de la parte de la empresa que se está tratando de modelar.

MODELO LOGICO El modelo lógico se usa en el UML para modelar los elementos estructurales estáticos. Captura y define los objetos, entidades y bloques de construcción de un sistema. Las clases son los moldes genéricos a partir de los que se crean los objetos en tiempo de ejecución del sistema. Los componentes (se discuten en "El modelo de componentes") se construyen a partir de las clases. Las clases (y las interfaces) son los elementos de diseño que corresponden a los artefactos de software codificados o desarrollados. Este artículo describirá algunas características del modelo de clases, cubrirá la notación del UML para describir las clases/objetos y dará un ejemplo del uso de la notación.

IDENTIFICACIÓN DE ATRIBUTOS Y ENTIDADES En nuestro esquema conceptual debemos incluir únicamente aquellos atributos que aparezcan referenciados en la especificación (lista de requerimientos funcionales, casos de uso y documentos adicionales) y, además, sean estrictamente necesarios para dar soporte a la funcionalidad de nuestro sistema. Los atributos puede que no se incluyan explícitamente en el diagrama asociado al esquema conceptual de una base de datos (para facilitar su interpretación cuando éste es complejo) pero SIEMPRE deberán aparecer en el diccionario de datos asociado al diagrama. En el esquema conceptual se pueden incluir atributos derivados (que, en UML, se marcan con el prefijo /), si bien éstos no se almacenarán físicamente en la base de datos (salvo que nos encontremos con problemas de rendimiento al llegar a la etapa de diseño físico). Es importante identificar el dominio de los atributos (el conjunto de valores permitido para cada atributo), así como indicar si el atributo puede tomar un valor nulo o no. Así mismo, cualquier restricción reseñable deberá figurar en el diccionario de datos asociado al modelo conceptual de nuestra base de datos: claves primarias y alternativas, relaciones entre atributos …

BASE DE DATOS RELACIONAL Éste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla). En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información. El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas , un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales. Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.Durante los años '80 (1980-1989) la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.

BASE DE DATOS JERARQUICO Éstas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos . El nodo que no tiene padres es llamado raíz , y a los nodos que no tienen hijos se los conoce como hojas . Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento. Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.

BASE DE DATOS DE RED Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo : se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico). Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.

BASE DE DATOS ORIENTADO A OBJETOS Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento). Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos: Encapsulación - Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos. Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases. Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos. En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones. SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.

Objetivos Disminuir los tiempos de respuesta. Minimizar espacio de almacenamiento. Evitar las reorganizaciones. Proporcionar la máxima seguridad. Optimizar el consumo de recursos.

VENTAJAS • Sirven para encontrar más rápido aquello que buscamos, por lo tanto y extrapolando a bases de datos podemos decir que nos sirven para agilizar las consultas a las tablas. • Evitamos un "escaneo completo de la tabla" lo que hace que cuando tenemos grandes cantidades de datos en nuestras tablas, la mejora puede ser muy importante.

ELEMENTOS Aunque no todos los sistemas comerciales disponen de ellos, y si existen el diseñador tiene la posibilidad de actuar sobre ellos ajustándolos a cada caso concreto, algunos de ellos se muestran a continuación: * Registros físicos. * Punteros. * Direccionamiento calculado (Hashing). * Agrupamientos (cluster). * Bloqueo y comprensión de datos. * Asignación de espacios de almacenamientos como memorias intermedias (buffers). * Asignación de conjuntos de datos a particiones y a dispositivos físicos.

El SGBD impone una estructura interna, dejándole al diseñador muy poca flexibilidad, lo que suele aumentar la independencia física/lógica, pero disminuye la eficacia. 2) El administrador diseña la estructura interna , esto supone una importante carga para el administrador y puede influir de forma negativa en la independencia, aunque puede mejorar la eficacia. 3) El SGBD proporciona una estructura interna opcional que el diseñador puede cambiar a fin de optimizar el rendimiento de la Base de Datos. Esta estrategia tiene unas ventajas: La Base de Datos puede comenzar a funcionar de inmediato. La eficacia va aumentando al irse efectuando los ajustes sucesivos. La independencia se mantiene. ESTRATEGIAS

La metodología del Diseño Físico de la Base de Datos presentada está dividida en tres pasos principales: El Diseño Físico de la Base de Datos: Traducción del modelo de datos Métodos de acceso para las relaciones base.

UNIDAD III Modelo de base de datos red, jerárquica y orientada a objetos.

Modelo de red o reticular En el modelo relacional, los datos y las relaciones entre ellos se representan mediante un conjunto de tablas. El modelo de red se diferencia del modelo relacional en que los datos se representan mediante conjuntos de registros, y las relaciones entre ellos mediante punteros. Una base de datos en red consiste en un conjunto de registros conectados entre si mediante punteros. Los registros son en muchos aspectos parecidos a las entidades del modelo entidad-relación (E-R). Cada registro es un conjunto de campos (atributos), cada uno de los cuales sólo contiene un valor de datos. Los punteros son asociaciones entre exactamente dos registros. Por tanto, los punteros pueden considerarse una forma restringida (binaria) de relación en el sentido del modelo E-R. En cuanto a la dinamica, los modelos en red se carecterizan por ser navegacionales, es decir, la recuperacion y la actualizacion de la base de datos se lleva a cado registro a registor, y procedimentales, es decir, asumen el conocimiento de la estructura interna de la base de datos por parte del programador.

Como ejemplo, considérese una base de datos que represente una relación cliente-cuenta en un sistema bancario. Hay dos tipos de registros, cliente y cuenta. La base de datos de ejemplo de la Figura muestra que López tiene la cuenta C-102, González tiene las cuentas C-101 y C-201 y Abril tiene la cuenta C-305.

Los diagramas de estructura de datos son esquemas que representan el diseño de las bases de datos en red. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a tipos de registros, y las líneas, que corresponden a punteros. Los diagramas de estructuras de datos cumplen la misma finalidad que los diagramas E-R, es decir, especifican la estructura lógica global de la base de datos. Los diagramas E-R pueden transformarse en los diagramas de la estructura de datos correspondientes. DIAGRAMAS DE ESTRUCTURA DE DATOS

A modo de ejemplo, considérese el diagrama E-R de la Figura a, que consta de dos conjuntos de entidades, cliente y cuenta, relacionados mediante una relación binaria de varios a varios impositor, sin atributos descriptivos. El diagrama especifica que un cliente puede tener varias cuentas y que una cuenta puede pertenecer a varios clientes diferentes. El diagrama de la estructura de datos correspondiente se ilustra en la Figura b. El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos — nombre-cliente, calle-cliente y ciudad-cliente—, tal y como se ha definido anteriormente. De manera parecida, cuenta es el tipo de registro correspondiente al conjunto de entidades cuenta. Incluye los dos campos número-cuenta y saldo. Finalmente, la relación impositor ha sido sustituida por el puntero impositor. Si la relación impositor fuera de uno a varios de cliente a cuenta, el puntero impositor tendria una flecha que apuntaría al tipo de registro cliente. De manera parecida, si la relación impositor fuera de uno a uno, el puntero impositor tendría dos flechas, una que apuntaría al tipo de registro cuenta y otra que apuntaría al tipo de registro cliente.

Considérese el diagrama E-R siguiente de la Figura a, que consta de tres conjuntos de entidades — cuenta, cliente y sucursal— relacionadas mediante la relación general CCS sin atributos descriptivos. El diagrama específica que un cliente puede tener varias cuentas, cada una de ellas abierta en una sucursal bancaria específica, y que una cuenta puede pertenecer a varios clientes diferentes. Dado que los punteros pueden conectarse exactamente con dos tipos de registros diferentes, hay que conectar estos tres tipos de registros mediante un nuevo tipo de registro que se vincule directamente con cada uno de ellos. Para transformar el diagrama E-R de la Figura a en un diagrama la estructura de datos de red hay que crear un nuevo tipo de registro Renlace que pueda no tener ningún campo o tener un solo campo que contenga un identificador único. Este identificador lo proporciona el tema y no lo utiliza directamente el programa de aplicación. Este nuevo tipo de registro se denomina a veces tipo de registro ficticio (o enlace o conexión). También hay que crear tres punteros de varios a uno, ClienRenl, CuenRenl y SucRenl, tal y como se muestra en la Figura b. Si la relación CCS tuviera atributos descriptivos, se transformarían en campos del tipo de registro Renlace.

La primera especificación de una norma para las bases de datos, denominada informe CODASYL DBTG 1971, la elaboró a finales de los años sesenta el grupo de trabajo sobre bases de datos (Database Task Group, DBTG). En el modelo DBTG sólo se pueden utilizar punteros de varios a uno. Los punteros de uno a uno se representan como punteros de varios a uno. No se permiten los punteros de varios a varios para simplificar la aplicación. Si la relación impositor es de varios a varios, el algoritmo de transformación debe refinarse de la manera siguiente. Considérese la relación mostrada en la Figura a. Para transformar la relación hay que crear un nuevo tipo de registro ficticio, Renlace, que puede no tener ningún campo o tener un solo campo que contenga un identificador único definido externamente, y dos punteros de varios a uno, ClienRenl y CuenRenl, tal y como se muestra en la Figura b. EL MODELO CODASYL DE DBTG

Dado que sólo se pueden utilizar punteros de varios a uno en el modelo DBTG, un diagrama de estructura de datos que consta de dos tipos de registro vinculados entre sí tiene la forma general de la Figura. Esta estructura se denomina conjunto DBTG en el modelo DBTG. El nombre del conjunto suele elegirse para que sea igual que el del puntero que conecta los dos tipos de registro. En cada uno de estos conjuntos DBTG, el tipo de registro A se denomi na propietario (o padre) del conjunto, y el tipo de registro B se denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener un número indefinido de apariciones del conjunto, es decir, casos reales de registros vinculados. Por ejemplo, en la Figura siguiente hay tres apariciones del conjunto correspondientes al conjunto DBTG de la Figura anterior.

Dado que no se permiten los punteros de varios a varios, cada aparición del conjunto tiene exactamente un propietario y cero o más registros miembros. Además, ningún registro miembro de un conjunto puede participar en más de una aparición del conjunto en ninguna ocasión. Los registros miembros, sin embargo, pueden participar simultáneamente en varias apariciones de conjuntos DBTG diferentes. El lenguaje de tratamiento de datos de la propuesta DBTG consta de órdenes que se incorporan en un lenguaje anfitrión. Las órdenes permiten a los programadores seleccionar registros de la base de datos de acuerdo con el valor de un campo especificado e iterar en los registros seleccionados mediante órdenes repetidas para obtener el registro siguiente. También se facilitan a los programadores órdenes para averiguar el propietario de un conjunto en el que tome parte un registro e iterar en los miembros de dicho conjunto. Y por supuesto que hay órdenes para actualizar la base de datos.

En el modelo DBTG los punteros se establecen añadiendo campos puntero a los registros que se asocian mediante ellos. Para mostrar la manera de hacerlo, supóngase que la relación impositor es de varios a uno de cuenta a cliente. Un registro cuenta sólo puede estar asociado con un registro cliente. Por tanto, para representar la relación impositor sólo hace falta un puntero en el registro cuenta. Sin embargo, los registros cliente pueden estar asociados con varios registros cliente. En vez de utilizar varios punteros en los registros cliente, se puede utilizar una estructura de anillo para representar todas las apariciones del conjunto DBTG impositor. En las estructuras de anillo, los registros de los tipos propietario y miembro de cada aparición del conjunto se organizan en listas circulares. Hay una lista circular por cada aparición del conjunto (es decir, por cada registro del tipo propietario). En la Figura 7.7 se muestra la estructura de anillo del ejemplo de la Figura 7.1. Examínese la aparición del conjunto DBTG que posee el registro «González». Hay dos registros de tipo miembro (cuenta). En vez de contener un puntero por cada registro miembro, el registro propietario (González) sólo contiene un puntero para el primer registro miembro (la cuenta C-101). Este registro miembro contiene un puntero al siguiente registro miembro (la cuenta C-201). Dado que el registro de la cuenta C-201 es el último registro miembro, contiene un puntero para el registro propietario. TÉCNICAS DE IMPLEMENTACIÓN

Establecer punteros de varios a varios utilizando punteros es significativamente más difícil. Por tanto, el modelo DBTG restringió los punteros a ser de varios a uno. La estrategia de implementación del modelo DBTG también proporcionó la base para el sistema de recuperación de datos DBTG.

Resulta evidente del estudio anterior que el modelo de red está estrechamente vinculado con su implementación. Como se vio anteriormente, los diseñadores de bases de datos tienen que crear tipos de registros artificiales incluso para establecer relaciones sencillas de varios a varios. A diferencia del modelo relacional, en el que las consultas pueden realizarse de una manera sencilla y declarativa, la realización de consultas resulta significativamente más complicada. Los programadores se ven obligados a pensar en términos de punteros y de la manera de atravesarlos para llegar a la información necesaria; el tratamiento de los datos en el modelo de red se denomina, por tanto, de navegación Así, el modelo de red aumenta de manera significativa el trabajo de los programadores, tanto para el diseño de las bases de datos como para el tratamiento de los datos, en comparación con el modelo relacional. Fue preferido al modelo relacional durante muchos años debido a que las primeras implementaciones del modelo relacional fueron muy poco eficientes. Hoy en día hay excelentes implementaciones del modelo relacional, por lo que el modelo de red ha perdido importancia.

Simplicidad conceptual: la vista conceptual de la basde de datos es simple y por lo tanto simplifica el diseño. Maneja mas tipos de relaciones: las relacones M:N son mas faciles de ejecutar en el modelo de bases de datos de red que en el jerarquico. Flexibilidad de acceso a los datos: una aplicacion puede tener acceso a un registro propietario y a todos los registros mienbros dentro de un conjunto. Por consiguiente, si un registro miembro tiene dos o mas propietarios, puede pasarse directamente de un propietario a otro. Promueve la integridad de la base de datos: hace que se cumpla la integridad de la base de datos, ya que el usuaro primero debe definir el registro propietario y luego el miembro, (un miembro no puede existir sin un propietario). Independencia de los datos: ofrece una indeendencia suficiente de datos para, por lo menos, aislar parcialmente los programas de los detalles de almacenamiento fisico complejo. Por consiguiente, los cambios de los datos no requiren cambios en las partes de acceso a los datos de los programas de aplicacion. Ventajas del modelo de red

Desventajas del modelo de red Complejidad del sistema: el control de la integridad de la base de datos y la eficiencia con la que el modelo de red maneja las relaciones, en ocasiones se ve anulada por la complejidad del sistema. El modelo de red proporciona un ambiente de acceso navegacional a los datos, en el que los datos son accesados con un registro a la vez, la base de datos de red no fue diseñada para producir un sistema facil de utilizar. Falta de indepencia estructural: por su ambiente de acceso navegacional a los datos, es dificil cambiar la estructura de una base de datos de red, y algunos cambios estructurales son imposibles de hacer. Si se cambia la estructura de la base de datos, todos los programas de aplicacion deben ser revalidados antes de que puedan tener acceso a la base de datos. Debido a las desventajas del modelo de red, fue remplazado en gran medida por el modelo relacional en los años 80.

Modelo jerárquico Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que repite y usa relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad.

Un ejemplo de un modelo de datos jerárquico sería si una organización tuviera los registros de empleados en una tabla (el tipo de entidad) llamada "Empleados". En la tabla habría atributos/columnas como el Nombre de pila, el Apellido, el Nombre de Trabajo y el Salario. La empresa también tiene datos sobre los hijos del empleado en una tabla separada "Hijos" llamada con atributos como el Nombre de pila, el Apellido, y la fecha de nacimiento. La tabla de Empleado representa un segmento paternal y la tabla de Hijos representa un segmento Infantil. Estos dos segmentos forman una jerarquía donde un empleado puede tener muchos hijos, pero cada hijo sólo puede tener un padre. Considere la estructura siguiente: En esta tabla, "el hijo" es el mismo tipo que "el padre". La jerarquía que declara EmpNo 10 es el jefe de 20, y30 y 40 cada informe a 20 es representado por la columna "Reporta". .

En este tipo de modelos la organización se establece en forma de árbol, donde la raíz es un nodo ficticio. Así tenemos que, una base de datos jerárquica es una colección de árboles de este tipo. El contenido de un registro específico puede repetirse en varios sitios(en el mismo árbol o en varios árboles). La repetición de los registros tiene dos desventajas principales: Puede producirse una inconsistencia de datos El desperdicio de espacio.

Un diagrama de estructura de árbol es la representación de un esquema de la base de datos jerárquica, de ahí el nombre, ya que un árbol esta desarrollado precisamente en orden descendente formando una estructura jerárquica. Este tipo de diagrama está formado por dos componentes básicos: Rectángulos: que representan a los de registros. Líneas: que representan a los enlaces o ligas entre los registros. Un diagrama de árbol tiene el propósito de especificar la estructura global de la base de datos. Un diagrama de estructura de árbol es similar a un diagrama de estructura de datos en el modelo de red. La principal diferencia es que en el modelo de red los registros se organizan en forma de un grafo arbitrario, mientras que en modelo de estructura de árbol los registros se organizan en forma de un árbol con raíz. Características de las estructuras de árbol: El árbol no puede contener ciclos. Las relaciones que existen en la estructura deben ser de tal forma que solo existan relaciones muchos a uno o uno a uno entre un padre y un hijo. Diagramas de estructura de árbol

En este diagrama podemos observar que las flechas están apuntando de padres a hijos. Un padre (origen de una rama) puede tener una flecha apuntando a un hijo, pero un hijo siempre puede tener una flecha apuntando a su padre. El esquema de una base de datos se representa como una colección de diagramas de estructura de árbol. Para cada diagrama existe una única instancia de árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo son instancias de los registros de la base de datos. Cada una de las instancias que son hijos pueden tener a su vez, varias instancias de varios registros.

Las representaciones según las cardinalidades son: Consideremos la relación alumno-materia sin atributo descriptivo. La transformación según las cardinalidades seria: Cuando la relación es uno a uno.

Cuando la relación es uno a muchos. Cuando la relación es muchos a uno .

Cuando la relación es muchos a muchos.

Cuando la relación tiene atributos descriptivos, la transformación de un diagrama E-R a estructura de árbol se lleva a cabo cubriendo los siguientes pasos: Crear un nuevo tipo de registro. Crear los enlaces correspondientes. Consideremos que a la relación Alumno-Materia añadimos el atributo Cal a la relación que existe entre ambas, entonces nuestro modelo E-R resulta: Añadir el diagrama E-R

Según las cardinalidades los diagramas de estructura de árbol pueden quedar de la siguiente manera:  Cuando la relación es uno a uno. Cuando la relación es uno a muchos

Cuando la relación es Muchos a uno. Cuando la relación es Muchos a Muchos. Si la relación es muchos a muchos entonces la transformación a diagramas de árbol es un poco más compleja debido a que el modelo jerárquico solo se pueden representar las relaciones uno a uno o uno a muchos. Existen varias formas distintas de transformar este tipo de relaciones a estructura de árbol, sin embargo todas las formas constituyen la repetición de algunos registros. La decisión de qué método de transformación debe utilizarse depende de muchos factores, entre los que se incluyen: El tipo de consultas esperadas en la base de datos. El grado al que el esquema global de base de datos que se está modelando se ajusta al diagrama E-R dado.

A continuación se describe la forma de transformar un diagrama E-R a estructura de árbol con relaciones muchos a muchos. Suponemos el ejemplo de la relación alumno-materia. Crear dos diagramas de estructura de árbol distintos T1 yT2, cada uno de los cuales incluye los tipos de registro alumno y materia, en el árbol T1 la raíz es alumno y en T2 la raíz es materia. Crear los siguientes enlaces: Un enlace muchos a uno del registro cuenta al registro Alumno, en T1 Un enlace muchos a uno del tipo de registro cliente al tipo de registro materia en T2. Como se muestra en el siguiente diagrama:

Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los obj etos completos (estado y comportamiento). En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones. Modelo orientado a objetos

Un sistema es un conjunto de elementos que interactúan entre si, en un sistema orientado a objetos los elementos toman el nombre de objetos. Un sistema de información Orientado a Objetos no es Base de datos + programas, sino que es un conjunto de objetos colaborativos donde los objetos persistente son guardados en una Base de Datos. El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales. Estructura de objetos El modelo orientado por objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. Sistemas Orientados a Objetos

Un objeto Posee una identidad, la cual no es una característica del objeto, es definida por el sistema propiamente y no puede ser cambiada. Tiene un estado, este puede ser descrito por las características (atributos) del mismo. Tiene un comportamiento, el cual puede ser descrito por los métodos, estos forman parte del objeto y nos sirve como una interfaz para interactuar con el mismo. Un objeto tiene asociado: Un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto. Un conjunto de mensajes a los que el objeto responde. Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje. El término mensaje en un contexto orientado por objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación. La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos.

Jerarquía de objetos o clases En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo. Sería inútil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definición común, aunque difieran en los valores asignados a las variables. Así que básicamente las bases de datos orientadas por objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase.

Por ejemplo: Tomemos como referencia la entidad Alumno y la entidad Maestro. Donde los atributos considerados para cada uno son: Alumno : • Nombre • Dirección • Teléfono • Especialidad • Semestre • Grupo

Maestro : • Nombre • Dirección • Teléfono • Número económico • Plaza • RFC Los atributos de Nombre , Dirección y Teléfono se repiten en la entidad Alumno y Maestro , así que podemos agrupar estos elementos para formar la clase Persona, con dichos campos.

• Quedando por separado en Alumno : • Especialidad • Semestre • Grupo. • Y en Maestro : • Número Económico • Plaza • RFC.

Interacción entre objetos. Los objetos se comunican entre si usando mensajes, la recepción de un mensaje provoca entonces que uno de los métodos de mi objeto sea ejecutado. Tipos de objetos Cuando clasificamos los objetos estamos generalizando las propiedades que puede tener el objeto, el tipo de objeto es un patrón para todos los objetos de este tipo y esto se denomina tipo de dato abstracto o más conocido como clase. Encapsulamiento Los datos y los métodos para manipular los datos son una sola unidad y están encapsulados en este objeto, los datos que son parte del objeto pueden ser manipulados únicamente por la invocación de los métodos publicados en la interfase del objeto. Entonces los datos – atributos son descritos junto con la rutina (método) que permite manipularlos.

Ocultamiento de la Información. Los detalles de la implementación de los métodos son ocultados para los clientes. Herencia. Un tipo de objeto puede tener subtipos los cuales son clases especializadas que heredan los atributos y métodos de la clase general. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan. Polimorfismo. Una subclase tiene la posibilidad de sobrescribir los métodos heredados, con esto pueden existir dos clases que a pesar de poseer los mismos atributos e interfaces son diferentes.

Los lenguajes de programación orientados por objetos requieren que toda la interacción con objetos se realiza mediante el envío de mensajes. Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la materia de Base de Datos 1, para realizar esta consulta se tendría que enviar un mensaje a cada instancia alumno. En sí la estructuración de modelos orientados por objetos simplifica una estructura evitando elementos o variables repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando un modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar una reestructuración que involucra una serie de pasos complejos. Consultas orientadas por objetos

UNIDAD IV Diseño de las bases de datos relacionales

Tipos de modelado de datos Basicamente son 3: Conceptual: muy general y abstracto, visión general del negocio/institución. Lógico: versión completa que incluye todos los detalles acerca de los datos. Físico: esquema que se implementara en un manejador de bases de datos (DBMS).

Diseño conceptual Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Algunos aspectos a considerar al momento de realizar el modelado/análisis No pensar físicamente, pensar conceptualmente No pensar en procesos, pensar en estructura No pensar en navegación, pensar en términos de relaciones

Modelo Entidad-Relación Generalmente todo modelo tiene una representación gráfica, para el caso de datos el modelo más popular es el modelo entidad-relación o digrama E/R. Se denomina así debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos). El modelo debe estar compuesto por: Entidades Atributos Relaciones Cardinalidad Llaves

Entidades: todo lo que existe y es capaz de ser descrito (sustantivo). Entidades débiles Una entidad débil es aquella que no posee una llave primaria Para existir dependen de una relación con una entidad fuerte Pueden contener algun atributo "discriminante" que podría considerarse como aquel que lo distingue pero no de manera única, de ahí que no se considere como llave Atributos: es una característica (adjetivo) de una entidad que puede hacer 1 de tres cosas: · Identificar · Relacionar · Describir

En el diseño se pueden considerar 3 categorías de atributos Simples o compuestos: ya sea que el atributo sea un todo o bien este compuesto Color es simple, toma valores rojo, azul, etc Nombre es compuesto, contiene nombre de pila, apellido materno, apellido materno Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores. Telefono o Teléfonos Derivados: que se pueden calcular en base a otros atributos El promedio de préstamos se puede derivar si tenemos los valores de cada préstamo realizado a un persona NOTA: en la práctica es mejor considerar "siempre" a todos los atributos como simples y con valores simples

Relaciones Tipo de relación Ejemplo: es_jefe_de, participar_en_curso Instancia de relación Juan es_jefe_de Pedro Grado de una relación Número de entidades que participan Binario, terciario, etc.

Llaves Llave candidata: es una super llave mínima Llave primaria: la seleccionada para identificar a los elementos de un conjunto de entidades. Super llave: conjunto de uno o más atributos que "juntos" identifican de manera única a una entidad Ejemplo: Teniendo los atributos de la entidad "persona" Nombre Dirección Teléfono CURP Las superllaves serían: Nombre y Dirección Nombre y CURP CURP Las llaves candidatas serían Nombre y Dirección CURP La llave primaria sería CURP

Cardinalidades En base al número de instancias involucradas en cada relación, éstas presentan un cardinalidad, que puede ser:

Base de datos

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Base de datos

Base de datos