Notas de Introducción a las Bases de Datos

Notas de Introducción a las Bases de Datos Enero de 2002 Desarrolladas por: Dr. Felipe López Gamino Adaptadas por: Angel Kuri Morales

1 INTRODUCCION AL PROCESAMIENTO CON BASES DE DATOS 1.1 CONCEPTOS DE BASES DE DATOS 1.1.1 SISTEMA DE BASE DE DATOS Una base de datos es una colección de datos relacionados la cual tiene las siguientes propiedades implícitas: representa algún aspecto del mundo real, llamado el minimundo o el Universo de Discurso (UD). Cambios en el minimundo se reflejan en la base de datos; su colección de datos es lógicamente coherente con un significado, inherente; esto es, un conjunto de datos al azar normalmente no constituye una base de datos; su colección de datos es lógicamente coherente con un significado inherente; esto es, un conjunto de datos al azar normalmente no constituye una base de datos; se diseña, se construye, y se llena con datos para un propósito especifico; puede ser usada desde múltiples aplicaciones por diversos grupos de usuarios; está sujeta a un conjunto de restricciones para garantizar la integridad de la información. Un DBMS (DataBase Management System) (o SGBD- Sistema de Gestión de Bases de Datos) es una colección de programas que permite a usuarios crear y mantener bases de datos. Es un software de propósito general que facilita los procesos de: - definición (especificación de estructuras, tipos de datos y restricciones), - construcción (almacenamiento de los datos en algún medio) y - manipulación (consultas y actualización) de bases de datos para diversas aplicaciones. Un DBMS puede ser de propósito especial para manipular bases de datos que tienen un propósito especifico.

Un lenguaje de 4a. generación (4GL) es un lenguaje de programación con un conjunto poderoso de instrucciones el cual permite crear aplicaciones que manipulan bases de datos. Actualmente estos lenguajes incluyen elementos para manejar en forma gráfica la información de una base de datos (Visual Basic es un ejemplo). Con un 4GL se pueden definir aplicaciones constituidas por formas, reportes, menúes, etc., que utilicen el contenido de una base de datos a fin de satisfacer las necesidades de usuarios de la misma. A la conjunción de base de datos con el software que la manipula le llamaremos Sistema o Aplicación de Base de Datos. 1.1.2 CARACTERÍSTICAS DEL ENFOQUE DE BASE DE DATOS Una serie de características distingue el enfoque de base de datos del enfoque tradicional de programación con archivos. En el procesamiento de archivos tradicional, cada usuario define e implementa los archivos necesitados para una aplicación especifica. En este enfoque normalmente existe mucha redundancia en la información y cambios en el minimundo son difíciles de implementar en la aplicación. En el enfoque de base de datos, en un solo diccionario de datos se mantienen las estructuras de las diversas bases de datos requeridas por los usuarios; éste se define una sola vez y después es usado por diversas aplicaciones. Normalmente la redundancia es menor y los cambios son más fáciles de hacer. A continuación se detallan las principales diferencias entre ambos enfoques: Naturaleza auto-descriptiva de un sistema de base de datos El sistema de base de datos contiene no sólo a la base de datos misma sino también una definición completa de su estructura. La definición se almacena en el catálogo del sistema. Esta información se conoce como meta-datos. El catálogo es usado por el DBMS para poder trabajar con cualquier base de datos. En un sistema con procesamiento de archivos la definición de los datos típicamente es parte de los programas de aplicación mismos. De esta manera, estos programas están restringidos a trabajar con una base de datos especifica: la declarada en ellos. Cambios en el UD son difíciles de reflejar en la base. Aislamiento entre datos y programas En el procesamiento de archivos, la estructura de los archivos de datos está embebida en los programas que los usan, así cualquier cambio en la estructura de un archivo puede requerir cambiar todos los programas que tienen acceso a él. Por el contrario, los módulos del DBMS son independientes de cualesquier archivos específicos, ya que la estructura, de éstos está almacenada en el catálogo del DBMS. Esta propiedad se conoce como independencia entre programas y datos. El DBMS proporciona a los usuarios una representación conceptual de los datos sin incluir muchos de los detalles de cómo éstos son almacenados. Soporte de múltiples vistas de los datos Una base de datos normalmente tiene muchos usuarios, cada uno de los cuales puede requerir diferentes perspectivas o vistas de la base de datos. Una vista puede ser un subconjunto de la base de datos o puede contener datos virtuales que son derivados de otros datos de la base.

Compartimento de datos y procesamiento de transacciones multiusuario El DBMS debe incluir software para control de la concurrencia a fin de asegurar que varios usuarios que tratan de actualizar los mismos datos, lo hagan en una forma controlada de tal manera, que los resultados sean correctos. Ejemplo: A este tipo de procesamiento se le conoce corno de transacciones multiusuario. 1.1.3 USUARIOS DE BASES DE DATOS Para bases de datos personales, normalmente la misma persona define, construye y manipula la base de datos. Para bases de datos multiusuario grandes, con varias decenas o cientos de usuarios, diverso tipo de personal está involucrado: Administrador de la base de datos (DBA) Es el responsable por la administración de los recursos tanto del DBMS como de las bases de datos que tenga la organización. El DBA se encarga de autorizar el acceso a las bases de datos, coordinar y supervisar su uso, adecuar el sistema para un uso eficiente, etc. Diseñadores de la base de datos (o Programadores de aplicaciones) Son los responsables de identificar los datos a ser almacenados en una base de datos y de escoger las estructuras apropiadas para representar y almacenar estos datos. Normalmente definen las vistas de los diversos grupos de usuarios para al final integrar una base de datos con todas ellas. Usuarios finales Son las personas que tienen acceso a la base de datos para hacer consultas y actualizaciones y generar reportes. El rango es amplio y puede ir desde usuarios simples (capturistas) hasta usuarios experimentados (analistas).

1.1.4 CAPACIDADES DESEABLES EN UN DBMS Control de la redundancia Cuando se hace el diseño de una base de datos se debe almacenar una sola vez cada dato lógico, tal como el nombre o fecha de nacimiento de una persona. Esto evita inconsistencias en la información y a la vez ahorra espacio de almacenamiento. En algunos casos es deseable, o necesario, tener una redundancia controlada para optimizar tiempos de respuesta en consultas o porque así lo exige el modelo de datos empleado. El DBMS debe proporcionar este recurso. Restricciones de integridad Esta característica se encuentra relacionada con la del punto anterior. Estas restricciones van desde permitir que a la base sólo ingresen datos correctos, por ejemplo valores en un rango, hasta forzar que un registro está relacionado con otros registros de una, cierta manera. Normalmente estas restricciones se derivan del significado, o semántica de los datos del minimundo. La mayoría de las restricciones pueden ser controladas por el DBMS; otras deben controlarse por medio, de módulos especializados programados. Restricción a accesos no autorizados (Seguridad) Normalmente el DBMS debe proporcionar un subsistema de seguridad y autorización que el DBA utiliza para, asignar cuentas y privilegios (restricciones) a los usuarios de una base de datos. Con este subsistema se puede definir el tipo de operaciones que un usuario puede efectuar y a qué partes de la base puede tener acceso. El uso de vistas es otra forma de controlar el acceso. Múltiples interfaces de usuario Debido a los diversos tipos de usuarios que usan una base de datos, el DBMS debe proporcionar una variedad de interfaces para los mismos. Estas pueden incluir: lenguajes de consulta; lenguajes de programación, con capacidades gráficas inclusive; interfaces basadas en menúes e interfaces de lenguaje natural. Representación de vínculos complejos entre datos El DBMS debe tener la capacidad de representar una gran variedad de vínculos complejos entre los datos, así como poder recuperarlos y actualizarlos fácil y eficientemente. Respaldo (Backup) y Recuperación (Recovery) El DBMS debe tener los recursos para, recuperarse de fallas de hardware y de software. El subsistema de respaldo y recuperación es el responsable por esta tarea. Por ejemplo, si el sistema falla. a mitad de una transacción, el DBMS debe poder restaurar la base de datos hasta el estado previo, que tenia antes de la falla, y así asegurar que su contenido es válido. 1.1.5 IMPLICACIONES DEL ENFOQUE DE BASES DE DATOS La utilización de bases de datos en las organizaciones presenta varias implicaciones las, cuales pueden beneficiar a las funciones computacionales de las mismas. Potencial para establecer estándares En una organización grande el enfoque de bases de datos permite al DBA establecer estándares entre los usuarios de las mismas. Esto facilita la comunicación y la cooperación entre los departamentos, proyectos y usuarios dentro de la organización. Los estándares pueden ser definidos para los nombres y formatos de los datos, formatos de despliegue, estructuras de reportes, terminología, etc. Reducción del tiempo de desarrollo de aplicaciones Una característica principal de las bases de datos es que el desarrollo de una nueva aplicación toma poco tiempo. El diseñar e implementar una nueva base de datos a partir de cero puede llevar mucho menos tiempo que escribir una sola aplicación con archivos especializados. Sin embargo, ya que la base

de datos está en funcionamiento, se requiere macho menos tiempo para crear nuevas aplicaciones usando las facilidades del DBMS. Se estima un ahorro de un sexto a un cuarto de tiempo con respecto a sistemas de archivos especializados. Disponibilidad de información "al día" Cuando una actualización a la base de datos es hecha por un usuario, todos los demás usuarios pueden ver inmediatamente dicha actualización. Esta disponibilidad de información "al día" es esencial para muchas transacciones, tales corno sistemas de reservaciones y bases de datos de bancos. 1.1.6 Ventajas y desventajas en el uso de bases de datos Ventajas - Al minimizar la redundancia, disminuye el margen de error. - Independencia entre hardware y datos. - Independencia entre datos y programas de aplicación. - Los datos pueden compartirse (concurrencia). - Disminución del tiempo de programación. - Nuevas aplicaciones se pueden agregar más fácilmente. - Mecanismos de seguridad superiores a los convencionales. - Es más fácil recuperar información cuando ocurre una falla. Desventajas - Un sistema de bases de datos normalmente es menos eficiente (en tiempo y en espacio) que el mismo sistema con procesamiento de archivos. - El DBMS consume muchos recursos de hardware (memoria central y secundaria). - Mayor costo (de adquisición y de mantenimiento). - En bases de datos centralizadas el sistema es más vulnerable a catástrofes físicas. 1.2 TRES EJEMPLOS DE BASES DE DA TOS En esta sección se describen tres ejemplos de bases de datos que muestran el espectro de aplicaciones en las que éstas se pueden usar, así corno las características importantes de cada tipo de base de datos. Micro-empresa para pintar casas Es una micro-empresa, compuesta por dos personas de tiempo completo y algunos trabajadores eventuales, que se dedica a pintar casas. Es una micro-empresa que ya tiene varios años en el mercado, con una buena reputación, que consigue la mayor parte de sus trabajos por recomendaciones de clientes y, ocasionalmente, por contratistas. Cuentan con una cartera de varias docenas de clientes y emplean Una pequeña base de datos personal para guardar información importante acerca de trabajos realizados anteriormente. Esto con el fin de poder obtener datos relevantes cuando se va a efectuar un nuevo trabajo, ya sea para un cliente nuevo (recomendado o no) o para un cliente anterior. Enseguida se muestra un ejemplo de esta base de datos:

Las bases de datos personales, en general, no son grandes, contienen pocas tablas y almacenan poca información. Agencia de venta de automóviles Las bases de datos pueden ser mis complicadas que la del ejemplo anterior. Considérese ahora una agencia de venta de autorn6viles en la cual laboran dos supervisores, cuatro agentes de ventas y un administrador. La base de datos contiene información sobre modelos en venta, clientes, ventas realizadas, etc. Esta base de datos es compartida. por el personal de la agencia y está localizada en una red de área local formada. por: - un servidor de base de datos, - dos PCs para los supervisores, - una PC para el administrador, y - cuatro PCs para. los agentes de ventas. La base de datos requerida para gestionar la información de esta aplicación es más complicada que la de la micro-empresa que pinta casas. Un ejemplo de las tablas que podría contener es el siguiente: Obviamente, la información almacenada en esta base de datos es mucho mayor que en el primer caso. Además, esta base de datos es multiusuario. Sistema de transacciones bancarias (cuentas de cheques) Este es un ejemplo de un sistema de base de datos de mucho mayor complejidad que los dos anteriores. El sistema debe poder:

- almacenar los datos generales de los clientes y de las cuentas que poseen, - registrar las transacciones que se realizan y el lugar en que se efectúan, - generar estados de cuenta, - Ilevar a cabo consolidaciones, etc. Además, el sistema debe permitir acceso multiusuario ya que las diversas transacciones se pueden efectuar: - en ventanilla (en varias decenas de sucursales), - a través de cajero automático (varias decenas), - por teléfono, etc. Esta base de datos tiene cientos de usuarios. Así, la base de datos es grande y compleja, pudiendo constar de varias decenas de tablas, conteniendo cientos de miles de datos. Comparación de las bases de datos Estos tres ejemplos representan una muestra de los usos de la tecnología de las bases de datos. Cientos de miles de ellas son corno la usada por la micro-empresa que pinta casas: bases de datos monousuario, con una cantidad relativamente pequeña de datos. Las formas y reportes que generan normalmente son simples y directos. Otras son corno la usada por la agencia de autos; tienen más de un usuario pero generalmente menos de veinte o treinta usuarios en total. Contienen una cantidad moderada de datos y las formas y reportes deben ser de cierta complejidad para satisfacer la diferentes funciones de la organización. Las bases de datos mis grandes son como la del sistema bancario que tiene cientos de usuarios y varios gigabytes de datos. En general, muchas aplicaciones las usan, teniendo cada una sus propias formas y reportes. En la siguiente tabla se resumen las características importantes de cada una de estas clases de bases de datos: 1.3 CONCEPTOS Y COMPONENTES DE UN SISTEMA DE BASE DE DATOS 1.3.1 MODELOS DE DATOS, ESQUEMAS E INSTANCIAS Una característica fundamental del enfoque de base de datos es que proporciona un cierto nivel de abstracción de los datos, ocultando detalles de su almacenamiento que no son necesarios para la mayor parte de los usuarios de una base de datos. Un modelo de datos es la herramienta principal usada para proporcionar esta abstracción. Un modelo de datos: - es un conjunto de conceptos usado para describir la estructura de una base de datos (el t6imino estructura se refiere a la conjunción de tipos de datos, vínculos y restricciones que deben observarse para los datos);

- en la mayoría de los casos, incluye un conjunto de operaciones básicas para especificar recuperaciones y actualizaciones sobre la base de datos; - puede incluir conceptos para especificar comportamiento, lo cual se refiere a especificar un conjunto de operaciones definidas por el usuario permitidas sobre la base de datos. ' Muchos modelos de datos han sido propuestos. Se pueden definir tres categorías según el tipo de conceptos que proporcionan: - conceptuales (o de alto nivel): proporcionan conceptos que están más cercanos a la forma en que los usuarios perciben los datos. Frecuentemente se auxilian en diagramas para plasmar un modelo para. un caso especifico; - físicos (o de bajo nivel): brindan conceptos que describen los detalles de la manera en que los datos están almacenados en la computadora. En general, estos conceptos están dirigidos a especialistas en Computación más que a usuarios finales típicos; de representación (o de implementación): proporcionan conceptos que pueden ser entendidos por usuarios finales pero, que no están demasiado lejos del modo, en que los datos están organizados dentro de la computadora. Estos modelos son los usados en la mayoría. de los DBMS comerciales: de redes, jerárquico, relacional y de objetos. Esquemas e instancias En cualquier modelo de datos es importante distinguir entre la descripción de la base de datos y la base de datos en si misma. La descripción de la base de datos se conoce como esquema de la base de datos (o metadatos). Este esquema se especifica durante el diseño de la base de datos y se espera que no cambie con frecuencia. Un esquema dibujado se conoce como diagrama del esquema. Cada unidad en el esquema es un elemento del esquema. Ejemplo: Un diagrama de esquema muestra sólo algunos aspectos del esquema, tal como el nombre de los elementos y de los campos de datos; pero no muestra otros, como el tipo de los datos, los vínculos entre ellos o restricciones sobre los mismos. Los datos actuales en una base de datos pueden cambiar frecuentemente. Al conjunto de datos que está en la base de datos en un momento particular del tiempo se le conoce corno estado de la base de datos

o conjunto de ocurrencias o instancias). En un estado dado, cada elemento del esquema tiene su propio conjunto actual de instancias. Cada vez que se actualiza la base de datos (inserción, modificación o eliminación de datos), ésta cambia de un estado a otro. Cuando se define una nueva base de datos, sólo se especifica su esquema al DBMS. Su estado inicial es el "estado vacío". Cuando se cargan los primeros datos, éstos definen el "estado inicial" de la base de datos. Después, cada actualización hace que la base de datos pase de un estado a otro. En cualquier momento, un estado de la base de datos debe ser válido, esto es, el estado debe satisfacer tanto la estructura como las restricciones especificadas para la base de datos. El esquema es llamado algunas veces la intensión de la base de datos; al estado también se le conoce como la extensión de la base de datos. 1.3.2 ARQUITECTURA DE UNA BASE DE DATOS En esta parte se describirá una arquitectura de base de datos, llamada arquitectura de los tres esquemas, cuyo propósito es, sobre todo, permitir el aislamiento entre datos y programas y múltiples vistas de los datos. En esta arquitectura 1, los esquemas pueden ser definidos en tres niveles: (Véase la siguiente figura). 1. El nivel interno tiene un esquema interno, el cual describe la estructura de almacenamiento físico de la base de datos. El esquema interno usa un modelo de datos físico y describe los detalles completos del almacenamiento de los datos y los caminos de acceso para la base de datos. 2. El nivel conceptual tiene un esquema conceptual, el cual describe la estructura de la base de datos completa para una comunidad de usuarios. El esquema conceptual oculta los detalles de almacenamiento físico y se concentra en describir entidades (datos), tipos de datos, vínculos, operaciones del usuario y restricciones. Se puede usar un modelo de datos conceptual o uno de implementación en este nivel.. 3. El nivel externo o de vistas comprende un conjunto de esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que utiliza un grupo particular de usuarios y oculta el resto de la base de datos. Se puede usar en este nivel un modelo de datos similar al del punto anterior. Hay que notar que los tres esquemas son sólo descripciones de datos; los únicos datos que actualmente existen están en el nivel físico (base de datos almacenada). 1 Propuesta por la ANSI/SPARC (American National Standards Institute/Standard Planning and Requirements Committee).

También hay que observar que se deben efectuar transformaciones entre los diferentes esquemas para poder atender las solicitudes/resultados que se envían entre los diversos niveles. Dado que este proceso puede consumir tiempo, no todos los DBMS se ajustan totalmente a esta arquitectura, aunque varios de ellos sí la observan, hasta cierto punto. Independencia de datos La arquitectura de los tres esquemas puede ser usada para explicar el concepto de independencia de datos, el cual puede ser definido como la capacidad para cambiar el esquema en un nivel de la base de datos, sin tener que cambiar el esquema en el siguiente nivel superior. Se pueden definir dos tipos de independencia de datos: 1. Independencia de datos lógica, es la capacidad de cambiar el esquema conceptual sin tener que cambiar los esquemas externos o programas de aplicación. Cuando esto sucede, sólo las definiciones de las vistas y sus transformaciones correspondientes deben ser cambiadas en un DBMS que soporta este concepto. Cambios a las restricciones en el nivel conceptual tampoco deben afectar al nivel externo. 2. Independencia de datos física, es la capacidad para cambiar el esquema interno sin tener que cambiar el esquema conceptual o los esquemas externos. Debido a que la independencia física se refiere solamente al aislamiento de una aplicación de las estructuras físicas de almacenamiento, es más fácil lograrla que la independencia lógica.

1.3.3 LENGUAJES E INTERFACES Lenguajes de un DBMS A continuación se describen los diferentes lenguajes que un DBMS proporciona para poder definir, construir (llenar) y manipular (consultar) una base de datos. Lenguaje de definición de datos (DDL), es usado por el DBA y los diseñadores de bases de datos para definir el esquema conceptual. Esta definición se compila y se guarda en el catálogo del DBMS. Lenguaje de definición del almacenamiento (SDL), es usado para especificar el esquema interno. No es común encontrarlo en los DBMS, salvo en los de gran complejidad. Las transformaciones entre los esquemas interno y conceptual se pueden especificar en este lenguaje o en el anterior. Lenguaje de definición de vistas (VDL), especifica vistas de usuarios y sus transformaciones hacia el esquema conceptual. En un DBMS que no observa estrictamente la arquitectura de los tres esquemas, el DDL es usado con frecuencia para definir estas vistas. Lenguaje de manipulación de datos (DML), permite manipular los datos de la base, lo cual incluye recuperar, insertar, eliminar y modificar los datos. En los DMBS actuales no es común encontrar separados a estos lenguajes, sino reunidos en uno solo. Tal es el caso de SQL para manejadores relacionales. Por otro lado, el DMI (en particular el de SQL) puede brindar instrucciones para ser usadas en forma interactiva, a través de terminal o de PC comunicada con la base de datos, o embebidas en un lenguaje de programación de propósito general. En este último caso, el lenguaje de programación se conoce como lenguaje anfitrión (host) y al DML se le llama sublenguaje de datos. Al DMI, también se le conoce como lenguaje de consulta (query language). Interfaces Son las diferentes interfaces que se pueden encontrar en un ambiente de bases de datos. Algunas pueden ser proporcionadas por el DBMS; otras, programadas por medio de un lenguaje de 3a. o 4a. generación. Basadas en menúes, presentan al usuario listas de opciones que lo van guiando a través del sistema. Los menús pueden presentarse por medio de caracteres, exclusivamente, o por medio de un ambiente de ventanas. Gráficas, típicamente despliegan al usuario un diagrama el cual éste va llenando con información. Normalmente están combinadas con menús basados en ventanas. Basadas en formas, presenta un forma al usuario para que éste edite datos; esto es, para que inserte, elimine o modifique datos. De lenguaje natural, las cuales aceptan solicitudes escritas en lenguaje natural (normalmente, inglés). No son comunes y se puede decir que aún están en desarrollo. Para usuarios paramétricos, que se emplean para presentar al usuario un conjunto reducido de operaciones, muchas de ellas asignadas a teclas del teclado. Están destinadas a usuarios que efectúan operaciones repetitivas, como los cajeros de bancos. Para el DBA, que normalmente contienen instrucciones privilegiadas para ser usadas exclusivamente por el DBA.

1.3.4 COMPONENTES DE UN DBMS Un DBMS es un sistema de software grande y complejo. A continuación se describen brevemente las partes importantes de un DBMS. Catálogo del Sistema Compilador DDL Compilador DMI Administrador de datos Procesador Run-time Subsistema de control de concurrencia Subsistema de seguridad Subsistema de respaldo/ recuperación Catálogo del sistema, es una mini-base de datos almacenada en disco que puede estar separada físicamente o no de las bases de datos controladas por el DBMS. Contiene información como nombres de archivos, campos de datos, tipos de datos, detalles de almacenamiento, información de transformación entre esquemas y restricciones. En su lugar puede usarse un diccionario de datos. Compilador DDL, procesa las definiciones de los esquemas, especificadas con un DDL, y almacena sus descripciones (meta-datos) en el catálogo. Compilador DIVIL, analiza y traduce instrucciones del DML. Normalmente genera llamados al procesador run-time para que éste las ejecute. Administrador de datos, controla el acceso a la información almacenada en disco, ya sea que forme parte de una base de datos o del catálogo. Usa servicios del sistema operativo para intercambiar datos entre disco y memoria central. Procesador run-time, recibe operaciones de recuperación y de actualización y las ejecuta sobre la base de datos; para esto se apoya en el administrador de datos. Subsistema de control de concurrencia, controla el acceso simultáneo a una base de datos realizado por varios usuarios. Subsistema de seguridad, restringe el acceso a la base de datos, tanto a usuarios no autorizados como a partes de ésta que sólo determinado grupo de usuarios puede usar. Subsistema de respaldo/recuperación, permite crear respaldos de las bases de datos en otro dispositivo, ya sea disco o cinta magnética, para poder recuperar la información, posteriormente, en caso de una falla catastrófica. 1.3.5 APLICACIONES Una aplicación para una base de datos consiste de formas, consultas, reportes, menús y módulos especializados. El programa se elabora utilizando un lenguaje de programación y a través de una interfaz se comunica con el DMBS para tener acceso a la base de datos. El lenguaje puede ser un: Lenguaje de 3a. generación: son lenguajes de tipo algoítmico. basados en procedimientos, en los cuales se insertan llamados a instrucciones del DBMS para realizar procesos con la base de datos. Ejemplo de estos lenguajes son: C, Pascal. Cobol, Basic, etc. Actualmente no es común usarlos, ya que es engorroso crear las aplicaciones y darles mantenimiento, salvo en aquellos casos en los que se requiere una gran eficiencia, en tiempos de respuesta sobre todo. Lenguaje asociado al DBMS: normalmente son lenguajes de 4a. generación, de caracteres o ventanas, que son vendidos por la misma empresa propietaria del DBMS. Son bastante versátiles y la comunicación con el DBMS es casi directa. Tienen como desventaja el que son especializados para un DBMS particular.

Lenguaje de 4a. generación de terceros: son lenguajes basados en ventanas, en su gran mayoría, producidos por empresas terceras y que no están ligados a DBMS particulares. Son bastante poderosos y requieren siempre de una interfaz (ODBC) para comunicarse con algún DBMS particular. Como ejemplos están: Visual Basic, Power Builder, Delphi, etc. La interfaz y las ventanas pueden ocasionar tiempos de respuesta un poco lentos. También se pueden usar lenguajes orientados a objetos (C++, SmallTalk, etc.) para crear programas de aplicación, aunque en general éstos se asocian más a bases de datos 00 que a bases en otro paradigma. 1.4 FASES EN EL DESARROLLO DE UNA BASE DE DATOS En esta sección se describen a grandes rasgos las fases usuales seguidas durante el desarrollo de una base de datos. En conjunción se comentan las actividades que normalmente se realizan para el desarrollo de programas de aplicación asociados, bajo la perspectiva del análisis y diseño estructurados.

El diagrama anterior muestra las etapas del desarrollo, enmarcadas con rectángulo, y los productos que se obtienen en cada etapa, sin enmarcar. Recolección y análisis de requerimientos, es la etapa en la que se hacen entrevistas con los usuarios potenciales de la base de datos con el fin de entender y documentar sus requerimientos de datos. El resultado es un conjunto de requerimientos de usuario. Estos deberán ser especificados de una manera tan detallada, completa y precisa como sea posible. En paralelo se deben especificar los requerimientos funcionales de la aplicación. Estos consisten de operaciones definidas por el usuario (o transacciones) que serán aplicadas a la base de datos, e incluyen tanto recuperaciones como actualizaciones. Es común usar técnicas como los diagramas de flujo de datos para especificar estos requerimientos. Diseño conceptual de la base de datos, aquí se crea un modelo conceptual de la base de datos usando para ello un modelo de datos de alto nivel. El modelo conceptual es una descripción concisa de los requerimientos de datos de los usuarios y comprende descripciones de los tipos de datos, vínculos y restricciones para los datos; expresados por medio de los elementos que proporciona el modelo de datos de alto nivel. Dado que estos elementos no incluyen detalles de implementación, pueden ser usados para comunicarse con usuarios no especializados a fin de asegurar que todos sus requerimientos son cubiertos y que no hay contradicciones. Después que el modelo conceptual ha sido elaborado, por medio de las operaciones básicas del modelo de datos se deben especificar las transacciones de alto nivel correspondientes a las operaciones del usuario identificadas durante el análisis funcional. Esto también sirve para confirmar que el modelo conceptual satisface todos los requerimientos funcionales. Diseño lógico de la base de datos, es la etapa en la cual se implementa la base de datos usando un DBMS comercial. Aquí se transforma el modelo conceptual de la base de datos, obtenido en la fase anterior, a una implementación usando el modelo de datos empleado por el DBMS: relacional, objetual, de red o jerárquico (los dos últimos ya de poco uso). El resultado es un esquema lógico (conceptual, según la arquitectura de los tres esquemas) de la base de datos. Diseño físico de la base de datos, durante esta fase son especificadas las estructuras de almacenamiento internas y las organizaciones de archivos para la base de datos. Normalmente el DBMS controla estos aspectos y el diseñador tiene poca injerencia en los mismos. En paralelo con estas actividades, los programas de aplicación son diseñados e implementados como transacciones de la base de datos correspondientes a las especificaciones de las transacciones de alto nivel.

2 MODELO DE ENTIDAD-VÍNCULO El modelo de entidad-vínculo es un modelo de datos conceptual de uso muy extendido. Este modelo, y sus variantes, se emplea frecuentemente para elaborar el esquema conceptual de una base de datos y muchas herramientas existentes para tal fin utilizan sus conceptos. El modelo fue creado por el Dr. Peter S. Chen con la finalidad de poder crear esquemas conceptuales, independientes de la implementación física, que pudieran ser transformados posteriormente a cualquiera de los modelos de DBMS comerciales existentes en ese entonces: de redes, jerárquico y relacional. En inglés recibe el nombre de: entity-relationship; en español también se conoce como: entidad-relación, entidad-parentesco o modelo ER. 2.1 CONCEPTOS BASICOS 2.1.1 DEFINICIÓN DE ENTIDAD Una entidad es un objeto (tangible o intangible) que puede distinguirse de los objetos de su misma especie. Ejemplo: A las propiedades (características) que distinguen a las entidades entre sí se les conoce con el nombre de atributos. La entidad persona anterior tiene 3 atributos: Nombre, Edad y Estado civil. Una entidad particular tiene un valor para cada uno de sus atributos. Los valores para el ejemplo podrían ser: "Pablo Sosa", "25", "soltero". Tipos de atributos Una entidad puede tener diferentes tipos de atributos: Atómico, es un atributo indivisible, por ejemplo, un apellido, la edad de una persona, el nombre de una calle. También se conoce como atributo simple. Compuesto, es aquel que puede ser dividido en subpartes más pequeñas, las cuales representan atributos más básicos con significado independiente entre sí. Un ejemplo es un domicilio compuesto

por calle, número, colonia y código postal. Las subpartes pueden ser atributos atómicos o también compuestos. Monovaluado, se usa este término cuando un atributo contiene un solo valor, que es el caso normal. Por ejemplo, la edad de una persona es un atributo monovaluado. Multivaluado, se tiene cuando el atributo puede contener varios valores. Por ejemplo, el atributo Teléfono de una empresa puede ser multivaluado. Almacenado, es un atributo cuyo valor físicamente existe para la entidad. Este atributo físicamente existirá en la base de datos cuando ésta sea implementada. Ejemplo: la fecha de nacimiento de una persona. Derivado, es un atributo cuyo valor se deriva de otro(s) atributo(s) de la misma entidad o de una entidad relacionada. Ejemplo: la edad de una persona la cual puede derivarse de la fecha actual y de su fecha de nacimiento. Obviamente un atributo es: atómico o compuesto, monovaluado o multivaluado y almacenado o derivado. En algunos casos una entidad particular puede no tener valor para un atributo. En estos casos se utiliza un valor especial: el valor nulo (null). Este valor significa que, para esa entidad. el valor del atributo correspondiente no es aplicable o es desconocido. Si el valor es desconocido puede ser por dos casos: porque el valor existe pero está perdido, por ejemplo la estatura de una persona; o porque no se conoce si el valor existe, por ejemplo el teléfono de una persona. Tipos de entidades, atributos clave y conjuntos de valores Tipo de entidades, se aplica este término a un conjunto de entidades que tienen los mismos atributos. Por ejemplo, el conjunto de empleados de una empresa podría formar el tipo de entidades ENIPLEADO; o el conjunto de materias que ofrece un departamento académico podría formar el tipo MATERIA. Cada tipo de entidades se representa por un nombre y la lista de los atributos de las entidades. Atributos clave, es el conjunto de atributos de un tipo de entidades cuyos valores son distintos para cada entidad individual. Por ejemplo, el RFC de un empleado en el tipo EMPLEADO. Hay una restricción para estos atributos clave y es que dos entidades distintas no pueden tener los mismos valores para estos atributos. Un tipo de entidades puede tener más de un conjunto de atributos clave. Dominio de un atributo, es el conjunto de valores que puede ser asignado a un atributo simple de un tipo de entidades. Por ejemplo, si el rango de edades permitido para un empleado va de 18 a 70 años, entonces el dominio de ese atributo es el conjunto de números enteros entre 18 y 70. 2.1.2 DEFINICIÓN DE VÍNCULO Definición matemática de relación binaria Sean A y B dos conjuntos no vacíos. Una relación binaria R entre A y B es un subconjunto del producto cartesiano A x B. (Esta definición se puede generalizar a n conjuntos) Un vínculo es una asociación entre entidades de diferentes tipos. Un tipo de vínculos es una relación (en el sentido matemático) y representa a un conjunto de asociaciones que existen entre entidades de tipos diferentes. Un vínculo específico asocia exactamente a una entidad de cada tipo participante. Un vínculo específico representa una situación correspondiente en el minimundo.

Ejemplo: El grado de un tipo de vínculos está dado por el número de tipos de entidades participantes. Un tipo de vínculos de grado dos es llamado binario y asocia a entidades de dos tipos. Uno de grado tres es llamado temario y asocia entidades de tres tipos. Un tipo de vínculos también puede tener atributos, en forma similar a los tipos de entidades. 2.1.3 DIAGRAMA DE ENTIDAD-VÍNCULO Su función es la de representar en forma gráfica el esquema conceptual que se está elaborando para una base de datos, empleando para ello los elementos que proporciona el modelo de entidad-vínculo. En el diagrama, los tipos de entidades se representan con rectángulos, los tipos de vínculos con rombos, etc. 2.1.4 CARDINALIDAD

La razón de cardinalidad (cardinalidad, para abreviar) es una restricción de un tipo de vínculos que nos indica, en el caso de vínculos binarios, con cuántas entidades de un tipo está relacionada una entidad del otro tipo y viceversa. Las cardinalidades comunes para los vínculos binarios son: 1-1, 1 -N y M-N. En el caso del mini-sistema escolar, las cardinalidades de los tipos de vínculos son:

Si el modelo conceptual de la base de datos está bien diseñado, se deben poder contestar las siguientes preguntas: Dado un profesor qué materias imparte? Dado un profesor, quiénes son los alumnos? Dada una materia, qué profesor la imparte? Dada una materia, qué alumnos la cursan? Dado un alumno, qué materias cursa? Dado un alumno, quiénes son sus profesores? Ejemplo de entidades en el mini-sisterna escolar: Ejemplo de vínculos: Imparte: El profesor P1 imparte las materias M1 y M2. El profesor P5 imparte la materia M3. Cursa: El alumno A1 cursa las materias MI y M2. El alumno A4 cursa la materia M2. El alumno A5 cursa la materia M2. Cómo están las asociaciones a nivel de entidades?

Otros modelos conceptuales del mini-sistema escolar Cuál funciona? Cuál es menos redundante? Cuál es más sencillo? Cuál es más eficiente en consulta? Cuál es más eficiente en actualización?

2.2 CONCEPTOS AVANZADOS 2.2.1 GENERALIZACIÓN/ESPECIALIZACIÓN. VÍNCULO ISA El concepto de Generalización/Especialización ocurre cuando se tienen varios tipos de entidades que tienen atributos comunes entre sí, pero también tienen atributos que los diferencian. En este caso se puede crear un nuevo tipo que agrupe a todos los atributos comunes de los tipos originales. A este nuevo tipo se le [Luna tipo generalizado o supertipo. Los tipos originales sólo conservarán aquellos atributos que los diferencian. A estos tipos se les conoce como tipos especializados o subtipos. Ejemplo: Existe un conjunto de atributos en el supertipo que actúa como discriminante para determinar a que subtipo pertenece una entidad especializada particular. En este ejemplo, el discriminante es el atributo Tipo_e. El conjunto de atributos de las entidades de un tipo especializado está constituido por los de ese tipo más los del tipo generalizado. El vínculo establecido entre un subtipo y su supertipo se conoce también como vínculo ISA (ES-UN o ES-UNA), porque, según el ejemplo, un ASALARIADO ES-UN EMIPLEADO y uno de HONORARIOS también ES-UN EMPLEADO. Los tipos de entidades pueden participar en cualquier otro tipo de vínculos. 2.2.2 ENTIDAD DÉBIL Este concepto surge cuando la existencia de una entidad en la base de datos depende de la existencia de otra entidad asociada.

Por ejemplo, la existencia de una entidad HIJO, en una base de datos de empleados, depende de la existencia de una entidad asociada EMPLEADO: Esto es, si el empleado deja la empresa, ya no se registrarán sus hijos. Al tipo de entidades del cual dependen las entidades débiles se le llama propietario o dueño. 2.2.3 VÍNCULO RECURSIVO Un vínculo recursivo existe cuando entidades de un tipo están relacionadas con entidades del mismo tipo. Por ejemplo, si se tiene el tipo de entidades EMPLEADO, un vínculo recursivo entre entidades de este tipo podría ser SUPERVISA. La siguiente figura muestra este caso: Cuando existe un vínculo recursivo las entidades participantes en él pueden jugar dos papeles. Refiriéndonos al ejemplo anterior, una entidad particular puede participar en un caso como Supervisor y en otro caso, como Supervisado. Algunos empleados sólo participarán como Supervisados (los que están en el nivel más bajo de la jerarquía). 2.2.4 VÍNCULOS QUE SE USAN COMO ENTIDADES En ocasiones es conveniente utilizar un vínculo como si se tratara de una entidad. Por ejemplo, en el siguiente caso:

CURSA no se puede conectar ni a PROFESOR ni a CURSO porque se pierde información; se debe conectar a INTARTE. La solución es tratar a MPARTE como si fuera un tipo de entidades. El símbolo usado en este caso es un rectángulo conteniendo un rombo. Ejemplo: 2.2.5 VÍNCULO TERNARIO Es un vínculo en el cual participan tres tipos de entidades; esto es. es un vínculo que relaciona a entidades de tres tipos diferentes. Por ejemplo, si tenemos PROVEEDORes que abastecen MATERIALes a diversos PROYECTOs entonces estos tres tipos de entidades podrían estar relacionados por medio de un vínculo temario. La siguiente figura muestra este caso:

Las cardinalidades que se pueden presentar en los vínculos ternarios son: 1-1-1, 1-1-N, 1-M-N y L-M-N. 2.3 CONDICIONALIDAD Hasta ahora sólo se ha considerado la cota superior de la cardinalidad. También se puede especificar la cota inferior. Cuando la cota inferior es uno, la participación es total u obligatoria, es decir. todas las entidades de los tipos involucrados participan en el vínculo. Cuando la cota inferior es cero, la participación es parcial, o sea no todas las entidades de los tipos participan en el vínculo. 2.3.1 VÍNCULOS CONDICIONALES Son vínculos en los cuales hay entidades de un tipo que no participan en el vínculo. Uno a uno (1c-1) Es similar al vínculo incondicional uno a uno, excepto que no todas las entidades de un tipo participan en el mismo. Ejemplo: Uno a muchos (lado "uno" obligatorio) (1c-N) Cada entidad de un tipo A (lado uno) está asociada a una o más de un tipo B (lado muchos). Cada entidad de A participa en el vínculo. Una entidad de B está asociada con cero o una de A; o sea, no todas las entidades de B participan en el vínculo. Ejemplo: Uno a muchos (lado "muchos" obligatorio) (1-Nc) Cada entidad de un tipo A (lado uno) está asociada con cero o más de un tipo B (lado muchos); mientras que cada entidad de B está asociada exactamente con una de A. Ejemplo:

Muchos a muchos (M-Nc) Es como la incondicional muchos a muchos, excepto que algunas de las entidades de un tipo pueden no participar en el vínculo. Ejemplo: 2.3.2 VÍNCULOS BICONDICIONALES Son vínculos en los cuales hay entidades de ambos tipos que no participan en el vínculo. Uno a uno (1c-1c) Una entidad de un tipo A está asociada con cero o una de un tipo B y viceversa. Ejemplo: Uno a muchos (1c-Nc) Es una variación del. vínculo uno a muchos; aquí puede haber entidades de ambos tipos qu e no participen en el vínculo. Ejemplo:

Muchos a Muchos (Mc-Nc) - puede haber oficinas vacías (por ej. en reparación) - puede haber empleados sin oficina (por ej. mensajeros). Es como la incondicional M-N, pero puede haber entidades de ambos tipos que no participen en el vínculo. Ejemplo (sólo durante inscripciones): 2.4 Sugerencias para la elaboración de un modelo conceptual 1. Cuando un tipo de entidades A tiene un solo atributo, este atributo puede pasarse a un tipo de entidades relacionado y desaparecer a A. 2. Cuando un tipo de entidades tiene un conjunto de atributos cuyos valores se repiten para entidades diferentes, entonces ese conjunto se puede quitar del tipo y con él crear un nuevo tipo de entidades. Obviamente también surge un nuevo vínculo entre los dos tipos de entidades resultantes. 3. Cuando el dominio de un conjunto de atributos de un tipo de entidades A sea el mismo dominio que el de los atributos clave de otro tipo de entidades B, entonces dicho conjunto de atributos de A debe desaparecer y en su lugar establecer un vínculo entre A y B. 4. Los atributos de un tipo de vínculos binarios con cardinalidad 1-N, pueden pasarse al tipo de entidades que está en el lado N. Cuando la cardinalidad es 1-1, los atributos pueden pasarse a cualquiera de los tipos de entidades participantes. 5. Cuando por la naturaleza de los vínculos entre dos tipos de entidades se requiera que una entidad de un tipo esté relacionada más de una vez con una misma entidad del otro tipo, entonces esos vínculos deben representarse como un nuevo tipo de entidades en lugar de ser representados como vínculos. Obviamente, se tendría que definir un conjunto de atributos clave para ese nuevo tipo de entidades.

3 MODELO RELACIONAL 3.1 ANTECEDENTES El modelo de datos relacional fue introducido por E.F. Codd en 1970. Está basado en una estructura de datos simple y uniforme: la relación. Tiene un fundamento formal: teoría de conjuntos, álgebra y cálculo relacionales. El acceso a la base de datos se realiza usando lenguajes basados en el álgebra relacional o en el cálculo relacional. Los conceptos de este modelo pueden ser usados para crear modelos lógicos de bases de datos, hasta cierto punto independientes de un DBMS particular. Es un modelo de datos firmemente establecido en el mundo de las aplicaciones de bases de datos, sobre todo las orientadas a negocios. Es la base de una gran cantidad de productos comerciales de DBMS. 3.2 CONCEPTOS Toda la información de una base de datos (tanto de entidades como de vínculos) se representa por medio de relaciones (también conocidas como tablas). Ejemplo: Mini-sistema escolar: Cuando una relación es vista como una tabla de valores, cada fila en la tabla representa una colección de datos relacionados. Estos valores pueden ser interpretados como hechos que describen una entidad o un vínculo del minimundo. A continuación se presentan los conceptos usados en este modelo: Dominio Es un conjunto de valores atómicos. Es el mismo concepto que en el caso del modelo de entidad-vínculo. Ejemplos: Teléfonos: conjunto de números telefónicos válidos de 10 dígitos;

Nombres: conjunto de cadenas de caracteres de nombres de personas. Para especificar un dominio normalmente hay dar un nombre, un tipo de datos y un formato. Esquema de relación (o esquema relacional) Está formado por un nombre de relación R y una Esta de atributos Al, A2,..., An; se denota como R(Al, A2,..., AJ Ejemplo: Profs(Id_prof, Nom_prof, Categoría) Cada atributo A tiene un dominio D asignado y es denotado por dorn(ai). Un esquema de relación es la descripción de una relación. Relación Una relación r del esquema de relación R(A1, A2,..., An), también denotada por r(r), es un conjunto de tuplas r = {t1, t2,..., tm}. Cada tupla t es una lista ordenada de n valores t = <v 1, v2, vn>, donde cada valor vi es un elemento de dom(ai) o es un valor nulo. Ejemplo: r = {<1, "Laura", "tc">, <3, "Luis", "tc">} Esta definición puede ser re-establecida como sigue: Una relación r(r) es un subconjunto del producto cartesiano de los dominios que definen a R: r(r) ( dom(a1) x dom(a2) x... x dorn(an)) De todas las posibles combinaciones del producto cartesiano, una relación refleja, en un momento dado, sólo las tuplas válidas que representan un estado particular del minimundo. En la terminología comercial, una relación comúnmente recibe el nombre de tabla, un atributo el de columna o campo y una tupla el de fila o renglón. Gráficamente: El grado de una relación es el número de atributos de su esquema. Esquemas de bases de datos relacionales Un esquema de base de datos relacional S es un conjunto de esquemas de relación S = {Rl, R2,..., Rm} y un conjunto de restricciones de integridad RI. Una instancia de base de datos relacional BD de S es un conjunto de relaciones BD = {r1, r2,..., r m } tal que cada r i es una relación de Ri y tal que las relaciones r i satisfacen las restricciones de integridad especificadas en RI.

Ejemplo de esquema de base de datos relacional: Mini-sistema escolar: Profs(ld_prof Nom_prof, Categoría) Curso(Clave, Nom_cu, Creds, Id_prof) Alumno(Matri, Nonm_al, Carr, Prom) Cursa(Matri, Clave, Calif) Ejemplo de instancia de base de datos relacional: La figura mostrada al inicio del capítulo para el mini-sistema escolar. Las restricciones de integridad son especificadas sobre un esquema de base de datos y deben respetarse para cada instancia de ese esquema.. 3.3 RESTRICCIONES En esta sección se analizan los diversos tipos de restricciones que pueden especificarse sobre un esquema relacional de base de datos. Restricción de dominio Especifica que el valor de cada atributo A de una relación debe ser un valor atómico tomado del dominio dom(a) de ese atributo. Restricciones de clave Dado que una relación está definida como un conjunto de claves, y por definición todos los elementos de un conjunto son distintos, entonces todas las tuplas en una relación deben ser distintas. Esto significa que ningún par de tuplas puede tener la misma combinación de valores para todos sus atributos. Lo anterior da pie a la definición de clave de un esquema de relación: Sea R(Al, A2,..., An) un esquema de relación. Se dice que un subconjunto X de los atributos es clave de R si cumple con las siguientes dos propiedades: i) cada valor de X identifica de manera única a cada tupla de la relación; ii) no se puede remover algún atributo de X y seguir cumpliendo la propiedad (i). La propiedad de clave debe cumplirse para cada instancia de un esquema de relación. La clave de un esquema de relación es determinada en base al significado de sus atributos. Un esquema de relación puede tener más de una clave, en cuyo caso cada una se conoce como clave candidata. De éstas, una se escoge como clave primaria, cuyos valores se usarán para identificar a las tuplas de la relación. La clave primaria normalmente será la que tenga menos atributos. Se sigue la convención de subrayar la clave primaria de un esquema de relación. Ejemplo: Profs(id_prof, Nom prof, Categoría)