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

28. MANEJADORES DE BASE DE DATOS

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

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

31. 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

33. MODELOS DE LAS BASES DE DATOS

34. 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.

35. ¿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.

36. 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.

37. 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.

38. 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

39. 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

40. 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.

41. 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.

42. 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.

45. 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.

46. Ejemplo de dos entidades con sus atributos, relacionadas entre si

47. 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.

49. 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 .

50. 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.

51. 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.

52. 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.

53. 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.

54. 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.

55. 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.

56. 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.

57. 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.

58. 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.

59. 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.

60. 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 …

61. 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.

62. 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.

63. 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.

64. 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.

65. MODELO FISICO

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

68. 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.

69. 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.

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

73. 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.

74. 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.

75. 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

76. 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.

77. 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.

79. 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

80. 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.

81. 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.

82. 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

83. 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.

84. 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.

87. 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.

88. 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". .

91. 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.

95. 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

99. 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

100. 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

102. 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.

103. 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

104. 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.

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

107. 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.

108. 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.

109. 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

110. UNIDAD IV Diseño de las bases de datos relacionales