Apunte De Bases De Datos

Informática II- Materia 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 EJEMPLO
BIT Representa 1ó0
Representa un 10101010 = “a”
BYTE carácter, número o
símbolo
CAMPO Agrupación de José García
bytes
Nombre Código Año de
Agrupación de ingreso
REGISTRO
campos José García 123 1997
Nombre Código Año de
Conjunto de ingreso
TABLA O José García 123 1997
registros igual
ARCHIVO
estructura Carlos 412 1998
López
Archivo de empleados
Archivos
BASE DE DATOS Archivo de sueldos
relacionados

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.
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.
Programador de aplicación: encargado de construir sistemas que utilizan SGBD

1 de 12


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.3 Manejo de transacciones
Una transacción es un 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.

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

2 de 12


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.

3 de 12


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:
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
alumnos con el mismo número de matrícula.
Pongamos un ejemplo:

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 Materia Fecha de Fecha de Nota
Alumno Inscripción examen
12 Carrizo Isabel Matemática 15/11/2001 23/12/2001 7
12 Carrizo Isabel Matemática Financiera 15/11/2001 18/12/2001 2
18 Pérez Luis Matemática 17/11/2001 23/12/2001 7
12 Carrizo Isabel Contabilidad I 15/11/2001 22/12/2001 6
12 Carrizo Isabel Legislación Contable 8/11/2000 15/12/2000 4
22 Juárez Alicia Contabilidad I 7/11/1997 10/12/1997 6
31 González Paola Impuestos 16/11/2001 18/12/2001 7
12 Carrizo Isabel Impuestos 20/2/2000 13/3/2000 2
31 González Paola Contabilidad I 15/2/2000 3/3/2000 4
31 González Paola Matemática Financiera 15/2/2001 5/3/2001 8
35 Fernández Vladimiro Matemática 18/11/2000 20/12/2000 2
22 Juárez Alicia Contabilidad II 10/11/2000 20/12/2000 7
35 Fernández Vladimiro Matemática Financiera 1/3/1990 15/3/1990 2
12 Carrizo Isabel Contabilidad II 18/2/2002 9/3/2002 7
31 González Paola Mercado de Capitales 1/3/1998 19/3/1998 8
12 Carrizo Isabel Matemática Financiera 16/2/2002 8/3/2002 5
12 Carrizo Isabel Inglés I 3/3/2000 18/3/2000 7
12 Carrizo Isabel Inglés II 10/11/2001 10/12/2001 7
18 Pérez Luis Impuestos 2/2/2002 27/2/2002 6
22 Juárez Alicia Matemática 31/2/2002 27/2/2002 7
18 Pérez Luis Matemática Financiera 2/2/2002 28/2/2002 2
31 González Paola Legislación Contable 12/2/2002 28/2/2002 4

en la cual 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.

4 de 12


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
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 Materia Fecha de Fecha de Nota
Alumno Inscripción examen
-- -- Informatica II -- 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:

5 de 12


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.
Veamos un ejemplo:
Si descomponemos la estructura de Univ de la siguiente manera:

Estructura Alumnos Estructura Materias
Nro. de Nombre de Alumno Nro. de Materia
Alumno Materia
12 Carrizo Isabel 100 Matemática
18 Pérez Luis 101 Matemática Financiera
22 Juárez Alicia 102 Contabilidad I
31 González Paola 103 Contabilidad II
35 Fernández Vladimiro 104 Legislación Contable
105 Impuestos
106 Inglés I
107 Inglés II
108 Mercado de Capitales

Estructura Exámenes Estructura Inscripciones
Nro. de Nro. de Fecha de Nota Nro. de Nro. de Fecha de
Alumno Materia examen Alumno Materia Inscripción
12 100 23/12/2001 7 12 100 15/11/2001
12 101 18/12/2001 2 12 101 15/11/2001
18 100 23/12/2001 7 18 100 17/11/2001
12 102 22/12/2001 6 12 102 15/11/2001
12 104 15/12/2000 4 12 104 8/11/2000
22 102 10/12/1997 6 22 102 7/11/1997
31 105 18/12/2001 7 31 105 16/11/2001
12 105 13/3/2000 2 12 105 20/2/2000
31 102 3/3/2000 4 31 102 15/2/2000
12 105 18/11/1999 2 12 105 18/11/1999
31 101 5/3/2001 8 31 101 15/2/2001
35 100 20/12/2000 2 35 100 18/11/2000
12 105 18/12/2001 4 12 105 17/11/2001
22 103 20/12/2000 7 22 103 10/11/2000
35 101 15/3/1990 2 35 101 1/3/1990
12 103 9/3/2002 7 12 103 18/2/2002

6 de 12


31 108 19/3/1998 8 31 108 1/3/1998
12 101 8/3/2002 5 12 101 16/2/2002
12 106 18/3/2000 7 12 106 3/3/2000
12 107 10/12/2001 7 12 107 10/11/2001
18 105 27/2/2002 6 18 105 2/2/2002
22 100 27/2/2002 7 22 100 31/2/2002
18 101 27/2/2002 2 18 101 2/2/2002
31 104 28/2/2002 4 31 104 12/2/2002

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 campo o conjunto de campos que permiten identificar a cada
registro dentro de esa tabla. Normalmente una vez definidos los campos que conforman
una tabla, la base de datos no debe admitir que en esa tabla existan dos o mas 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 Descripción Precio Unitario
1151 Resma Hojas A4 5.20
2410 Cuaderno chico x 20 hojas 1.10
2484 Goma borrar lápiz 0.70
2492 Goma borrar tinta 0.85
5045 Lápiz mecánico 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 lo 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:

7 de 12


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 Talle Material Descripción Precio Stock
2000 S Jean Campera de Jean Small 34.50 70
2000 M Jean Campera de Jean Medium 36.12 52
2000 L Jean Campera de Jean Large 36.50 30
5080 S Corderoy Campera de Corderoy Small 42.55 55
5080 M Corderoy Campera de Corderoy Medium 42.55 20
6000 S Jean Camisa de Jean Small 18.20 33
6500 M Corderoy Pantalón de Corderoy Medium 22.70 35
6500 L Corderoy Pantalón de Corderoy Large 22.70 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.

8 de 12


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:

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 mas registris 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 primer 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 comidas y otra ingredientes. En este caso una comida normalmente tiene más
de un ingrediente, y un mismo ingrediente puede formar parte en mas de una comida.

En esta figura se muestras los tres tipos de relaciones:

9 de 12


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

10 de 12


Ejemplo:
1.1.3 Talle 1.1.2 Material
1.1.1 Código S Jean
2000 M Corderoy
L

Código Talle Material Descripción Precio Stock
2000 S Jean Campera de Jean Small 34.50 70
2000 M Jean Campera de Jean Medium 36.12 52
2000 L Jean Campera de Jean Large 36.50 30

11 de 12


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

12 de 12

Apunte De Bases De Datos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Apunte De Bases De Datos

Similar a Apunte De Bases De Datos (20)

Último

Último (20)

Apunte De Bases De Datos