APUNTE DE BASES DE DATOS 2013

Texto completo

(1)Informática II (20002). Ciencias Económicas. BASES DE DATOS 1 Definición Una Base de Datos (BD), es un conjunto integrado de datos, interrelacionados, junto con una serie de aplicaciones para su manejo, accesibles simultáneamente por diferentes usuarios y programas. Para la interpretación de esta definición, es necesario antes explicar como se organiza la información para llegar a una BD. La información que se maneja dentro de una computadora, se combina formando diferentes niveles de significación. JERARQUÍA BIT BYTE CAMPO. REGISTRO. Representa un carácter, número o símbolo Agrupación de bytes Agrupación de campos. TABLA O ARCHIVO. Conjunto de registros igual estructura. BASE DE DATOS. Archivos relacionados. EJEMPLO 1ó0 10101010 = “a”. José García Nombre. Código. José García. 123. Nombre. Código. José García 123 Carlos 412 López Archivo de empleados Archivo de sueldos. Año ingreso 1997. de. Año ingreso 1997 1998. de. La complejidad de una BD crece en relación directa con la cantidad de tablas que incluye, siendo esta cantidad resultante del alcance del sistema de que se trate. Debe cumplir con las siguientes condiciones: 1.- Los datos se encuentran almacenados en distintos archivos o tablas 2.- La base de datos puede ser usada por varias aplicaciones y hasta simultáneamente. 3.- La gestión o explotación de los datos está a cargo de procedimientos que realiza el software llamado Sistema Gestor de Base de datos.. Se muestra un esquema para su comprensión. 1 de 16.

(2) Informática II (20002). Archivo 1. Ciencias Económicas. Archivo 2. Archivo 3. Sistema Gestor de Base de Datos. Programa/ Aplicación 1. Programa/ Aplicación 2. Programa/ Aplicación 3. Usuarios. Usuarios. Para el manejo de una BD se utiliza lo que se llama Sistema de Gestión de Bases de Datos (SGBD), que es un software cuyas funciones principales son:. 2 Funciones de un Sistema de Gestión de Base de Datos (SGDB) 2.1 Consulta y actualización Consiste en un conjunto de herramientas que permite a los distintos tipos de usuarios del SGBD extraer, manipular y modificar la información almacenada en la BD. Cuando se habla de usuarios de un SGBD, se pueden distinguir por lo menos tres tipos: Usuario final: aquella persona sin conocimientos técnicos sobre BD ni sobre programación y computación en general que usa la base ya generada. Programador de aplicación: encargado de construir sistemas que utilizan SGBD Administrador de BD: es el usuario que maneja íntimamente los mecanismos internos del sistema, uso de recursos, performance, requerimientos de seguridad, etc.. 2.2 Mantenimiento de esquemas El esquema de la BD es la descripción de la estructura de la información almacenada en ella. Ej: para un sistema basado en tablas, el esquema lo constituye la lista de tablas intervinientes, que campos contienen, el tipo de datos de cada campo, una descripción del propósito de cada tabla y cada campo y las restricciones sobre los valores que se admiten dentro de cada campo.. 2 de 16.

(3) Informática II (20002). Ciencias Económicas. 2.3 Manejo de transacciones Una transacción es una o más instrucciones de programa de aplicación, generalmente de duración breve, que accede y actualiza una parte también pequeña de la BD. Ej: Una extracción de una cuenta bancaria. El manejo de transacciones consiste en controlar múltiples transacciones que se ejecutan en forma paralela en una misma BD. Existen distintos objetivos que deben cumplir los SGBD: Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción. Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella. Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones. Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos. Manejo de transacciones. Una transacción es una interacción que se ejecuta como una sola operación. Si dos o más usuarios acceden en el mismo momento al mismo registro, el SGBD se encarga de asignar a uno solo el recurso, no permitiendo acceder el otro. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos. Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD demora en proporcionar la información solicitada y en almacenar los cambios realizados.. 3 MODELOS DE DATOS El modelo de BD hace referencia a la estructura que utiliza para expresar las relaciones existentes entre las diferentes unidades de datos que la constituyen. Un modelo de datos debe poder representar tanto las características estáticas como las dinámicas de un sistema real que se pretende modelizar, y se define por los siguientes componentes: Un conjunto de objetos y sus interrelaciones. Esto representa las características estáticas o invariantes e incluye las propiedades de los objetos. Un conjunto de operaciones, o lenguaje, que representa las características dinámicas.. 3 de 16.

(4) Informática II (20002). Ciencias Económicas. Restricciones sobre los objetos, sus interrelaciones y las operaciones definidas sobre ellos. El conjunto de objetos y sus interrelaciones resultan de abstracciones realizadas sobre la estructura del sistema real. Ejemplos de estos objetos son las tablas y registros. Las operaciones pueden dividirse en dos grupos: Operaciones de manipulación que permiten crear, modificar y destruir tanto los objetos como sus interrelaciones. Operaciones de consulta que permiten identificar objetos por medio de sus propiedades. Las restricciones son aplicables a los objetos, sus interrelaciones, a las interrelaciones entre sus atributos, como así también a las operaciones posibles.. 4 de 16.

(5) Informática II (20002). Ciencias Económicas. 3.1 Modelo Jerárquico Utiliza la estructura del árbol para establecer relaciones de uno a muchos. Existe un nodo distinguido como raíz, y a partir de él, se establecen las relaciones de sucesión, denominándose nodos hijos a los descendientes.. Agencia. Conductor. Pasajero. Destino. 3.2 Modelo en red Utiliza la estructura de red o de grafo, que permite definir entre todos los nodos relaciones. Mediante el establecimiento de apuntadores entre nodos se puede relacionar cualquier unidad de datos con cualquiera de las otras.. 3.3 Modelo relacional Se basa en el álgebra relacional. Las relaciones entre las unidades de datos o entidades se expresan mediante tablas de dos dimensiones. Una base de datos de este tipo estará formada por varias de estas tablas en las que una fila (tupla) contiene una ocurrencia de valores interrelacionados y una columna contiene los diferentes valores posibles de cada entidad. Código Conductor Ciudad Pasajero Agencia 105 Julián Pérez Lima Peinado Tour 125 Aldo Juares Santiago Martorelli Prisa 135 Pedro Rosales Santa Fe Sancho Tour 145 Aldo Contreras Asunción Arranz Tour En el modelo relacional, existe la noción de Clave Principal que representa unívocamente a cada registro de la tabla. El campo elegido como clave principal no puede contener valores duplicados, ni nulos.. 4 TEORÍA DEL DISEÑO RELACIONAL En el momento de diseñar una estructura de base de datos relacional existen tres objetivos fundamentales: 1 - Es necesario evitar ciertos problemas lógicos tales como redundancia o las anomalías de actualización.. 5 de 16.

(6) Informática II (20002). Ciencias Económicas. 2 – Las descomposiciones de las estructuras deben ser llevadas a cabo sin pérdida de información 3 – Las descomposiciones de las estructuras deben ser llevadas a cabo preservando las dependencias funcionales.. 4.1 Redundancia: Sucede cuando la misma información está almacenada más de una vez en la base de datos. El efecto que causa la redundancia es la incongruencia, ya que los datos pueden quedar desactualizados si no se actualizan en todos los lugares en los que figuran, además de utilizar más espacio de disco. Con lo cual, la información deja de ser confiable. Ejemplo: Supongamos que debemos registrar los turnos de los pacientes en un centro médico de la siguiente manera. Número. Apellido. Nombre. Obra Social. fecha. Hora. Especialidad. 1023. Almeyda. Joaquín. O.SDE. 15/04/12. 18:00. Clínica gral.. 2288. Montero. Mariano. IOMA. 15/04/12. 18:15. Cli. general. 1069. Castro. Juan. OS.DE. 16/04/12. 7:00. Oftalmología. 1023. Almeyda. Joaquín. OSDE. 15/04/12. 19:00. Oftalmologo. En el caso anterior: número de paciente, el apellido nombre, obra social, Especialidad son campos redundantes. Si observamos el campo Especialidad podemos ver que no sólo es redundante sino que además está codificado de distinta manera. Así, si deseamos consultar cuántos turnos tiene la especialidad Oftalmología sólo encontraremos un turno, cuando en realidad, por estar mal codificado, hay dos turnos. En el caso de la Obra social, además de estar mal codificada, si alguno de los pacientes cambiara de obra social, podríamos cometer el error de cambiarlo en alguno de los registros y no en todos los que se encuentra el mismo paciente. Supongamos que arreglamos el turno de Almeyda del día 15/04/12 para clínica general y colocamos IOMA en lugar de OSDE 1023. Almeyda. Joaquín. IOMA. 15/04/12. 18:00. Clínica gral.. El archivo de turnos ahora quedaría mal actualizado, ya que Almeyda tiene otro turno el día 15/4/12 con la obra social OSDE y la especialidad oftalmología. Para salvar estos problemas es que hay que organizar los turnos en más de un archivo, sin redundancia y relacionarlos. Se podría, entonces, diseñar las siguientes tablas:. 6 de 16.

(7) Informática II (20002). Ciencias Económicas. PACIENTES con los datos Número de paciente. Apellido. Nombre. Código de Obra Social. 1023. Almeyda. Joaquín. 10. 2288. Montero. Mariano. 20. 1069. Castro. Juan. 20. OBRAS SOCIALES con los datos de todas las obras sociales que trabaja el centro médico Código de Obra social. Denominación. 10. OSDE. 20. IOMA. 30. OSECAC. ESPECIALIDADES con los datos de todas las especialidades que atiende el centro médico Código de especialidad. Denominación. 1. Clínica General. 2. Oftalmología. 3. Traumatología. 4. Pediatría. TURNOS con los datos de todos los turnos que tiene dados el centro médico Número de turno. Número de paciente. fecha. Hora. Código de especialidad. 250. 1023. 15/04/12. 18:00. 1. 251. 2088. 15/04/12. 18:15. 1. 252. 1069. 16/04/12. 7:00. 2. 253. 1023. 15/04/12. 19:00. 2. En este diseño observamos que hay campos comunes en varias de las tablas. Pero no se consideran redundancia, ya que son los campos que permiten relacionar las tablas. Las relaciones son los campos de igual color. Repasando el concepto, con este ejemplo, definimos distintas tablas relacionadas por los campos Código de especialidad, Código de obra social, Número de paciente. Una de las herramientas principales para evitar la redundancia es establecer restricciones sobre los posibles valores que la información de la base de datos puede tomar. El concepto de clave es un caso especial de tales restricciones: no existen dos pacientes con el mismo número de paciente. Pongamos un ejemplo:. 7 de 16.

(8) Informática II (20002). Ciencias Económicas. Supongamos que deseamos representar en una base de datos los datos de los alumnos y sus exámenes, tales como: nombre y número de alumno, resultado de sus exámenes, inscripciones, etc. Quizás lo más simple sería tomar todos los atributos y formar un solo esquema de relación, como el siguiente:. Estructura UNIV Nro. De Nombre de Alumno Alumno. Materia. Fecha de Fecha de Nota Inscripción examen. 12 12 18 12 12 22 31 12 31 12 31 35 12 22 35 12 31 12 12 12 18 22 18 31. Matemática Matemática Financiera Matemática Contabilidad I Legislación Contable Contabilidad I Impuestos Impuestos Contabilidad I Impuestos Matemática Financiera Matemática Impuestos Contabilidad II Matemática Financiera Contabilidad II Mercado de Capitales Matemática Financiera Inglés I Inglés II Impuestos Matemática Matemática Financiera Legislación Contable. 15/11/2001 15/11/2001 17/11/2001 15/11/2001 8/11/2000 7/11/1997 16/11/2001 20/2/2000 15/2/2000 18/11/1999 15/2/2001 18/11/2000 17/11/2001 10/11/2000 1/3/1990 18/2/2002 1/3/1998 16/2/2002 3/3/2000 10/11/2001 2/2/2002 31/2/2002 2/2/2002 12/2/2002. Carrizo Isabel Carrizo Isabel Pérez Luis Carrizo Isabel Carrizo Isabel Juárez Alicia González Paola Carrizo Isabel González Paola Carrizo Isabel González Paola Fernández Vladimiro Carrizo Isabel Juárez Alicia Fernández Vladimiro Carrizo Isabel González Paola Carrizo Isabel Carrizo Isabel Carrizo Isabel Pérez Luis Juárez Alicia Pérez Luis González Paola. 23/12/2001 18/12/2001 23/12/2001 22/12/2001 15/12/2000 10/12/1997 18/12/2001 13/3/2000 3/3/2000 15/12/1999 5/3/2001 20/12/2000 18/12/2001 20/12/2000 15/3/1990 9/3/2002 19/3/1998 8/3/2002 18/3/2000 10/12/2001 27/2/2002 27/2/2002 28/2/2002 28/2/2002. 7 2 7 6 4 6 7 2 4 2 8 2 4 7 2 7 8 5 7 7 6 7 2 4. En este caso la clave sería la unión de los campos número alumno-materia-fecha examen. Ahora bien, supongamos también que la alumna Isabel Carrizo, con número 4, ha cursado 25 materias y rendido examen en todas ellas, algunas más de una vez. Claro está que cada examen rendido requiere la creación de un registro en la estructura Univ; y que cada uno de estos registros repite innecesariamente el nombre “Isabel Carrizo”, cuando bastaría con su número para identificarla. Por un lado esto implica espacio desperdiciado en el almacenamiento de la relación, pero por otro lado, la redundancia dificulta la actualización de los datos. La esencia del problema es que estamos juntando en una misma relación hechos que son independientes entre sí: el nombre de la alumna es independiente de los exámenes rendidos y la fecha de examen es independiente de la fecha de inscripción.. 4.2 Anomalías de actualización: Al agrupar datos que son independientes entre si, surgen problemas al momento de querer cargar algunos registros. Por ejemplo, si quisiéramos agregar el dato de que en la materia Informática II se tomó examen el día 20/12/2001, pero ningún alumno se presentó, no podríamos hacerlo en la estructura Univ, ya que ésta requiere valores para. 8 de 16.

(9) Informática II (20002). Ciencias Económicas. los campos número alumno, nombre alumno, fecha inscripción y nota que en este caso no existen. Una posibilidad sería usar valores nulos en los atributos no usados, o sea: Nro. De Nombre de Alumno Alumno ---. Materia Informática II. Fecha de Fecha de Nota Inscripción examen -20/12/2001 --. Pero esto requeriría poner un valor nulo para parte de la clave principal, lo cual no es posible en base de datos.. 4.3 Pérdida de información: Por lo tanto, es razonable pensar en descomponer un esquema de relación cuando esto ocurre. Pero no cualquier descomposición es aceptable. Por ejemplo: Si descompusiéramos la relación Univ en varias relaciones más pequeñas tales como: Alumno (número, nombre) Resultado (número alumno, materia, nota) Examen (materia, fecha) Inscripción (número alumno, materia, fecha) y quisiéramos saber simplemente en qué fechas rindió examen el alumno con número 45678, no nos sería posible averiguarlo, ya que el número del alumno y las fechas en que se rindieron los exámenes no aparecen juntas en ningún esquema de relación, ni tampoco existe un vínculo real que nos permita realizar un cruce de datos entre los esquemas de relación Resultado y Examen.. 4.4 Dependencias funcionales Una dependencia funcional es una restricción sobre el conjunto de registros que pueden aparecer en una relación. Se representa de la siguiente manera: df = X Y Leída como “X determina a Y”. Ejemplos de dependencias funcionales: Número de alumno Nombre de alumno Número de materia Materia Número de alumno-Materia Fecha de inscripción (si suponemos que el alumno se inscribe una solo vez en la materia) Número de alumno-Materia Fecha de examen-nota El concepto de dependencia funcional es la formalización de la constitución de cada tabla y es la formalización de la noción de clave. Cuando se realiza la descomposición de un esquema de relación deben respetarse las dependencias funcionales, es más, el análisis de claves puede ser útil para determinar si una descomposición produce o no pérdida de información. 9 de 16.

(10) Informática II (20002). Ciencias Económicas. Veamos un ejemplo: Si descomponemos la estructura de Univ de la siguiente manera: Estructura Alumnos Nro. de Nombre de Alumno Alumno 12. Carrizo Isabel. 18. Pérez Luis. 22. Juárez Alicia. 31. González Paola. 35. Fernández Vladimiro. Estructura Exámenes Nro. de Nro. de Alumno Materia 12 100 12 101 18 100 12 102 12 104 22 102 31 105 12 105 31 102 12 105 31 101 35 100 12 105 22 103 35 101 12 103 31 108 12 101 12 106 12 107 18 105 22 100 18 101 31 104. Fecha de examen 23/12/2001 18/12/2001 23/12/2001 22/12/2001 15/12/2000 10/12/1997 18/12/2001 13/3/2000 3/3/2000 18/11/1999 5/3/2001 20/12/2000 18/12/2001 20/12/2000 15/3/1990 9/3/2002 19/3/1998 8/3/2002 18/3/2000 10/12/2001 27/2/2002 27/2/2002 27/2/2002 28/2/2002. Estructura Materias Nro. de Materia Materia Matemática 100 Matemática Financiera 101 Contabilidad I 102 Contabilidad II 103 Legislación Contable 104 Impuestos 105 Inglés I 106 Inglés II 107 Mercado de Capitales 108. Estructura Inscripciones Nro. de Nro. de Fecha de Alumno Materia Inscripción 12 100 15/11/2001 12 101 15/11/2001 18 100 17/11/2001 12 102 15/11/2001 12 104 8/11/2000 22 102 7/11/1997 31 105 16/11/2001 12 105 20/2/2000 31 102 15/2/2000 12 105 18/11/1999 31 101 15/2/2001 35 100 18/11/2000 12 105 17/11/2001 22 103 10/11/2000 35 101 1/3/1990 12 103 18/2/2002 31 108 1/3/1998 12 101 16/2/2002 12 106 3/3/2000 12 107 10/11/2001 18 105 2/2/2002 22 100 31/2/2002 18 101 2/2/2002 31 104 12/2/2002. Nota 7 2 7 6 4 6 7 2 4 2 8 2 4 7 2 7 8 5 7 7 6 7 2 4. 10 de 16.

(11) Informática II (20002). Ciencias Económicas. Tómese en cuenta que las columnas sombreadas corresponden a los campos que serían clave principal de cada tabla (Recordar que una tabla puede tener como clave principal una combinación de varios campos). Podríamos perfectamente ahora saber en qué fechas rindió examen el alumno con número 45678, ya que al ser número alumno el campo clave en Alumno (identificando unívocamente a una persona), y este campo figurar en Exámenes, podríamos realizar sin problemas un cruce de datos entre ambas estructuras y obtener así la información deseada. De esta manera evitamos la redundancia y la pérdida de información.. 5 CLAVES La clave de una tabla es un campo o conjunto de campos que permiten identificar a cada registro dentro de esa tabla en forma unívoca. Normalmente una vez definidos los campos que conforman una tabla, la base de datos no debe admitir que en esa tabla existan dos o más registros con los mismos valores para esos campos. Ejemplo: Supongamos una tabla de artículos compuesta por los campos: Código, Descripción, y Precio Unitario, conformada por los siguientes registros: Código 1151 2410 2484 2492 5045. Descripción Resma Hojas A4 Cuaderno chico x 20 hojas Goma borrar lápiz Goma borrar tinta Lápiz mecánico. Precio Unitario 5.20 1.10 0.70 0.85 1.32. En este ejemplo, el Código es sin duda la clave, debido a que cada código identifica inequívocamente a un artículo, y, por consiguiente, no deberían existir dos o más artículos con el mismo código. En casos menos obvios que la tabla de artículos, se emplea el concepto de dependencia entre los campos de una tabla para determinar cuál es la clave. Utilizando este concepto, se establece que la clave de la tabla será aquel conjunto de campos del cual dependan los datos de los demás campos de la tabla. Ejemplo: Supongamos una tabla de artículos donde éstos son prendas de vestir, cuyos datos no sólo se definen por un código, sino también por un talle y un tipo de material. Código 2000 2000 2000 5080 5080 6000. Talle S M L S M S. Material Jean Jean Jean Corderoy Corderoy Jean. Descripción Campera de Jean Small Campera de Jean Medium Campera de Jean Large Campera de Corderoy Small Campera de Corderoy Medium Camisa de Jean Small. 11 de 16. Precio 34.50 36.12 36.50 42.55 42.55 18.20. Stock 70 52 30 55 20 33.

(12) Informática II (20002) 6500 6500. M L. Corderoy Corderoy. Ciencias Económicas Pantalón de Corderoy Medium Pantalón de Corderoy Large. 22.70 22.70. 35 41. En este ejemplo, los datos de Descripción, Precio y Stock no sólo dependen del Código, sino que también del Talle y del Material; es por eso que estos tres campos constituyen la clave de esta tabla.. 6 Aspectos específicos en un SGBD ACCESS Microsoft Access impide que se almacenen valores duplicados o Nulos en los campos de la clave principal. Existen tres tipos de clave principal que pueden definirse en Microsoft Access: Autonumérico, Campo simple y Campos múltiples.. 6.1 Claves principales de Autonumérico: Un campo Autonumérico puede establecerse para que introduzca automáticamente un número secuencial cuando se agrega un registro a la tabla. Designar un campo de este tipo como clave principal de una tabla es la forma más sencilla de crear una clave principal. Si no establece una clave principal antes de guardar una tabla recién creada, Microsoft Access le preguntará si desea que cree una clave principal automáticamente. Si contesta afirmativamente, Microsoft Access creará una clave principal de Autonumérico.. 6.2 Claves principales de Campo simple: Si tiene un campo que contiene valores exclusivos, como números de identificación o números de pieza, puede designar ese campo como la clave principal. Si el campo seleccionado como clave principal tiene valores duplicados o Nulos, Microsoft Access no establece la clave principal. Puede ejecutar una Consulta de buscar duplicados con el fin de determinar qué registros contienen datos duplicados. Si no puede eliminar fácilmente las entradas duplicadas mediante la edición de los datos, puede agregar un campo Autonumérico y establecerlo como clave principal o bien definir una clave principal de campos múltiples.. 6.3 Claves principales de Campos múltiples: En situaciones en las que no se puede garantizar la exclusividad de un solo campo, puede designar dos o más campos como clave principal. La situación más común en la que surge este problema es en la tabla utilizada para relacionar otras dos tablas en una relación varios a varios.. 7 RELACIONES En el modelo de bases de datos relacionales, las tablas se vinculan entre sí mediante uno o más campos cuyos valores son iguales en una y otra tabla. Cada relación une dos tablas en una de tres formas:. 12 de 16.

(13) Informática II (20002). Ciencias Económicas. 7.1 Uno a uno: Cada registro de la primera tabla se corresponde sólo con un registro de la segunda tabla. Ejemplo: Una tabla caballos de carrera y otra de jockeys. A cada registro de la tabla de caballos le corresponderá un registro de la tabla jockeys y viceversa.. 7.2 Uno a muchos: Cada registro de la primera tabla se corresponde con uno o más registros de la segunda tabla. En este caso, se dice que la primera es la tabla “madre” y la otra la tabla “hija”. Ejemplo: Una tabla de editoriales y otra de libros. En este caso a cada editorial le corresponderán varios libros, pero cada libro puede estar relacionado sólo con una editorial.. 7.3 Muchos a muchos: Varios registros de la primera tabla se corresponden con varios registros de la segunda tabla. En este caso es necesario crear una tabla intermedia para poder determinar qué registros de la primera tabla se corresponden con cuáles de la segunda tabla. Ejemplo: Una tabla de comidas y otra ingredientes. En este caso una comida normalmente tiene más de un ingrediente, y un mismo ingrediente puede formar parte en más de una comida. En esta figura se muestras los tres tipos de relaciones:. Veamos ahora cómo el concepto abstracto de una tabla o relación puede implementarse en términos de archivos. La idea más simple es la de representar cada relación por. 13 de 16.

(14) Informática II (20002). Ciencias Económicas. medio de un archivo. Generalmente las tuplas de una relación pueden representarse como registros de longitud fija sin demasiado desperdicio de espacio. Esta organización es frecuente en sistemas para máquinas relativamente pequeñas, donde las relaciones no serán demasiado grandes y es importante tener una implementación simple que permita que el código del sistema en sí no ocupe demasiado espacio. En sistemas de mayor envergadura puede ocurrir que se combinen varias relaciones en un mismo archivo.. 8 INDICES Una de las operaciones fundamentales en cualquier base de datos es el acceso a una tupla o registro según el valor dado de su clave; por ejemplo, extraer el registro de un empleado dado el número de empleado o el registro de un vehículo dada su matrícula. Obviamente tales operaciones siempre pueden implementarse mediante un barrido secuencial del archivo en cuestión, pero si nos interesa sólo acceder a un registro o a una pequeña fracción de todos los registros, una búsqueda secuencial será inaceptable. Por esto es necesario agregar un índice. Siempre se aplica un índice para los campos que componen la clave de una tabla. Para ganar eficiencia, también pueden crearse índices para lograr búsquedas rápidas de cualquier otro dato de la tabla.. 14 de 16.

(15) Informática II (20002). Ciencias Económicas. Ejemplo: 1.1.1 Código 2000. Código 2000 2000 2000. Talle S M L. 1.1.3 Talle S M L. Material Jean Jean Jean. 1.1.2 Material Jean Corderoy. Descripción Campera de Jean Small Campera de Jean Medium Campera de Jean Large. 15 de 16. Precio 34.50 36.12 36.50. Stock 70 52 30.

(16) Informática II (20002) 1 2. 3. 4. 5 6. 7. 8. Ciencias Económicas. Definición 1 Funciones de un Sistema de Gestión de Base de Datos (SGDB) ............................. 2 2.1 Consulta y actualización ................................................................................... 2 2.2 Mantenimiento de esquemas ............................................................................ 2 2.3 Manejo de transacciones ................................................................................... 3 MODELOS DE DATOS .......................................................................................... 3 3.1 Modelo Jerárquico ............................................................................................ 5 3.2 Modelo en red ................................................................................................... 5 3.3 Modelo relacional ............................................................................................. 5 TEORÍA DEL DISEÑO RELACIONAL ................................................................ 5 4.1 Redundancia: .................................................................................................... 6 4.2 Anomalías de actualización: ............................................................................. 8 4.3 Pérdida de información:.................................................................................... 9 4.4 Dependencias funcionales ................................................................................ 9 CLAVES ................................................................................................................. 11 Aspectos específicos en un SGBD ACCESS ......................................................... 12 6.1 Claves principales de Autonumérico: ............................................................. 12 6.2 Claves principales de Campo simple:............................................................. 12 6.3 Claves principales de Campos múltiples: ....................................................... 12 RELACIONES ....................................................................................................... 12 7.1 Uno a uno: ...................................................................................................... 13 7.2 Uno a muchos: ................................................................................................ 13 7.3 Muchos a muchos: .......................................................................................... 13 INDICES ................................................................................................................ 14 1.1.1 Código ........................................................................................................ 15 1.1.2 Material ....................................................................................................... 15 1.1.3 Talle ............................................................................................................ 15. 16 de 16.

(17)