INFORMATICA 1 Bach BASES DE DATOS

B.D. 1º Bach
INFORMATICA
BASES DE DATOS
1 Bach
1/17
B.D. 1º Bach
INDICE
1. Definiciones básicas ...................................................................................................................................... 3
1.1. Dato ....................................................................................................................................................... 3
1.2. Información ............................................................................................................................................ 3
1.3. Base de datos .......................................................................................................................................... 3
1.4. Abstracción ............................................................................................................................................ 3
1.5. Modelo de base de datos ......................................................................................................................... 3
1.6. Pasos para construir una BD ................................................................................................................... 4
2. Elementos básicos de una BD ........................................................................................................................ 4
2.1. Entidades. ............................................................................................................................................... 4
2.2. Atributos ................................................................................................................................................ 4
2.3. Relación ................................................................................................................................................. 5
3. Modelo E/R ................................................................................................................................................... 5
3.1. Introducción ........................................................................................................................................... 5
3.2. Entidades. ............................................................................................................................................... 5
3.3. Relaciones .............................................................................................................................................. 5
3.4. Cardinalidad ........................................................................................................................................... 6
3.5. Clasificación de las relaciones ................................................................................................................ 6
3.6. Diccionario de Datos .............................................................................................................................. 7
3.7. Metodología de diseño ............................................................................................................................ 7
3.8. ejemplo de E/R completo ........................................................................................................................ 8
4. Implementación en el ordenador .................................................................................................................... 9
4.1. Intro ....................................................................................................................................................... 9
4.2. Transformación. ..................................................................................................................................... 9
4.4. Tipos de datos ...................................................................................................................................... 11
4.5. Pasos para la resolución de los ejercicios. ............................................................................................. 11
4.6. Ejemplo esquema final en el ordenador................................................................................................. 11
4.7. Planificación y DD. .............................................................................................................................. 12
4.8. Ejemplos de transformación.................................................................................................................. 13
5. Ejercicios .................................................................................................................................................... 14
2/17
B.D. 1º Bach
Ejemplos de bases de datos comerciales son
MySQL, SQLServer, DBase y Access. Las hojas de
cálculo como Excell, pueden considerarse bases de
datos de propósito específico.
1. DEFINICIONES BÁSICAS
1.1. DATO
Por DATOS entendemos hechos conocidos
que pueden registrarse.
Un dato no dice nada sobre las cosas y por
si mismo no tiene ninguna relevancia. La toma de
decisiones utilizará los datos, pero estos nunca dirán
lo que hay que hacer, no dicen nada acerca de lo
que es importante o no. Por si mismo no reduce la
ignorancia de quien tiene que tomar decisiones.
Ejemplo: Catálogo de biblioteca. Relaciona
usuarios, libros, préstamos, devoluciones, etc.
El propósito de toda la base de datos es
registrar el préstamo de libros.
No es aleatoria pues todo está organizado
en torno a los libros y no existen datos no
relevantes.
Representa la parcela del mundo real que
antes se hacía con fichas en una biblioteca, pero no
representa la colocación de libros por ejemplo, ni
la atención al usuario.
Ejemplo de datos: nombre, apellidos,
número de teléfono, matrícula del coche.
Solo conviene almacenar datos que después
de analizados o procesados sirvan para resolver un
problema o tomar una decisión. Lo que nos lleva al
concepto de información.
Un SISTEMA GESTOR DE BASE DE
DATOS ( SGBD) es el software que no permite
crear la base de datos, e introducir y obtener datos
de la misma.
Un ejemplo de SGBD es ACCESS o
MySQL.
1.2. INFORMACIÓN
INFORMACIÓN es el significado que una
persona asigna a un dato. Por lo tanto si un dato es
información o no depende de la persona.
1.4. ABSTRACCIÓN
La ABSTRACCIÓN es el proceso de
descarte de los datos que nos llegan del exterior y
que no nos interesan.
Este proceso se está dando continuamente
en nuestro cerebro, por ello solo recordamos ciertas
cosas de lo que ha pasado durante el día, pues
almacenar todos los datos recogidos sería
imposible.
Mediante la abstracción se eliminan los
detalles irrelevantes.
Ejemplo de información: Un fabricante de
perfumes tiene intención de sacar al mercado un
nuevo producto. Necesita conocer la opinión de sus
posibles clientes. Entre las acciones a tomar decide
elaborar una encuesta, en la que recogerá estas
opiniones. Las respuestas recogidas son datos. Si
agrupamos, totalizamos y procesamos los datos
obtendremos
información
útil
para
el
Departamento de Marketing, y además esta
información
será
inteligible
para
este
departamento, aportándole un conocimiento nuevo,
de difícil o imposible predicción, y muy importante
para las decisiones a tomar en lo referente al
proceso de creación del nuevo perfume.
Así por ejemplo de una mesa diremos que
está formada por cuatro patas y un tablero encima,
con lo que todo el mundo sabrá lo que es una mesa.
Se han obviado los detalles del tipo de material:
madera, plastico, metal, el tipo de madera, las
dimensiones, es cuadrada, rectangular redonda,...
1.3. BASE DE DATOS
1.5. MODELO DE BASE DE DATOS
Una BASE DE DATOS (BD a partir de
ahora) es un conjunto de datos relacionados entre
si y con un propósito específico.
Una colección aleatoria de datos no puede
considerarse una base de datos. Una base de datos
representa una parcela del mundo real.
Debido a la complejidad del mundo real
nosotros solo podemos representar en los sistemas
informáticos una pequeña parte del mismo, la que
nos interesa. Además para representar esta parte
debemos simplificar y abstraer el funcionamiento
3/17
B.D. 1º Bach
del mundo real. Para esto se utilizan los modelos de
datos, que nos permiten representar el mundo de
una forma estándar y predeterminada que pueda ser
entendida por la mayoría.
sobre el que se quiere tener información en el
sistema.
Partiendo del lenguaje natural, un nombre
común que actúa como sujeto o complemento
directo en una frase, generalmente es una entidad, o
en su defecto, un atributo. Por su parte los nombres
propios suelen indicar instancias o ocurrencias de
una entidad.
Los MODELOS son por tanto una
representación simplificada de la realidad.
Este modelo sirve como herramienta para
poder manejar la información extraída de la realidad
y aplicada a situaciones que compartan un nexo
común.
Por ejemplo, si la parcela del mundo real es
una empresa, "empleado" sería una entidad puesto
que parece lógico que se quiera tener información
al respecto en el sistema.
Por ejemplo: el movimiento rectilíneo
uniforme. Se ha creado un modelo físico, en el que
a cualquier objeto que tenga un determinado tipo
de movimiento se le aplica siempre la misma
fórmula. El objeto debe cumplir una serie de
características. Cualquier objeto que las cumpla
será intercambiable por otro que también las
cumpla. Es decir, nos abstraemos del objeto en sí
mismo y nos fijamos solo en su movimiento que es
lo que nos interesa estudiar. No nos importa si el
objeto es blanco o negro, pues no afecta a su
movimiento, por tanto abstraemos estos datos.
Toda entidad debe quedar unívocamente
identificada por un nombre, que debe ser único en
el modelo y lo más significativo posible.
Normalmente las entidades se nombran con un
sustantivo.
Se denomina OCURRENCIA a cada uno
de los ejemplares de una entidad.
Por ejemplo, en la entidad "empleado", los
empleados Pedro y Juan, etc., son ocurrencias de la
misma.
Los modelos de datos dividen el mundo en
una serie de elementos, que nos permiten describir
los objetos del mundo real y sus relaciones. En el
punto 2 se estudia cuales son los elementos básicos
de una base de datos.
2.2. ATRIBUTOS
Se define ATRIBUTO como cada una de
las características, básicas de una entidad.
1.6. PASOS PARA CONSTRUIR UNA BD
Cuando queremos crear una base de datos
debemos dar los siguientes pasos:
Por ejemplo: de un empleado nos interesa
saber su nombre, apellidos, dni y puesto que
desempeña en nuestra empresa. Cada una de estas
unidades de información es un atributo y recibirá
un nombre distinto dentro de la entidad.
1. Diseñar la base de datos utilizando un
modelo. En nuestro caso utilizaremos el modelo
entidad/relacion.
2. Pasar este diseño al esquema lógico de la
base de datos que se va a utilizar, en nuestro caso
al modelo relacional.
3. Introducir datos en la base de datos.
2.1. ENTIDADES.
Se entiende por CLAVE PRINCIPAL
aquellos atributos de una entidad que identifican
unívocamente cada una de las ocurrencias de la
misma.
La función de la clave principal es
organizativa, permite identificar cada entidad a lo
hora de tener que buscarla. Es como el titulo de un
libro.
Una ENTIDAD es un objeto real o
abstracto, que tiene existencia por sí mismo, se
puede identificar de una manera clara y precisa y
En el ejemplo anterior la clave principal
sería el DNI, pues nadie puede tener el DNI
repetido.
2. ELEMENTOS BÁSICOS DE UNA BD
4/17
B.D. 1º Bach
Se define DOMINIO como el conjunto de
valores que puede tomar un atributo.
La principal utilidad del esquema E/R es
poner de manifiesto las relaciones entre
entidades.
Para el atributo nombre de un empleado el
dominio es el de los nombres de personas, así por
ejemplo no será posible el nombre mesa, silla,
perro o 1234.
3.2. ENTIDADES.
Las entidades se representan por medio de
un rectángulo, dentro del cual se escribe el nombre
de la entidad.
Los dominios más usuales en las bases de
datos comerciales son:
- números reales o Num
- caracteres o Car
- cadena de caracteres o CdC
- texto o Tex
- autonumérico. o Auto
- fecha o Fech
- moneda o Mon
EMPLEADO
Suponiendo que estamos modelando una
empresa el grafico anterior representaría un
empleado cualquiera.
3.3. RELACIONES
2.3. RELACIÓN
Una RELACIÓN
semántica entre entidades.
es
una
Las relaciones se representan por medio de
un rombo y se une a las entidades mediante una
línea.
Si estamos modelando una empresa que
tiene varias tiendas quizá nos interese saber en qué
tienda trabaja cada empleado, como se ve a
continuación.
conexión
Por ejemplo: entre las entidades
"empleado" y "empresa" se puede reconocer la
relación "pertenece".
3. MODELO E/R
3.1. INTRODUCCIÓN
La relación solo puede unir dos entidades.
Las relaciones no se pueden asociar con
otras relaciones.
La relación tiene dos sentidos de lectura.
La utilización de un modelo estándar tiene
las siguientes ventajas:
- Los esquemas resultantes transmiten un
mensaje preciso. No se pueden deducir de
él cosas que no estén representadas.
- Para las personas que sepan interpretarlos
son suficiente información. No hace falta
ninguna explicación adicional.
En el ejemplo podemos leer:
- En las tiendas trabajan empleados.
- Los empleados trabajan en las tiendas.
Con esta forma de hacer los gráficos ambos
sentidos de lectura dicen lo mismo, pero esta forma
de denotar la relación no nos permite saber cuántos
empleados trabajan en una tienda, ni en cuantas
tiendas trabaja un empleado. Por esto, vamos a
completar el modelo con la cardinalidad, y
comprobaremos como con este nuevo elemento el
sentido de lectura ya no se insignificante.
El modelo entidad relación nos proporciona
dos cosas:
- Un grafismo de representación. Es decir,
una forma de representar los elementos de
la base de datos mediante gráficos.
- Unas reglas. Estas reglas nos indican cómo
se construye un grafico correctamente.
Lo que se obtiene de aplicar lo anterior se
denomina el esquema E/R.
5/17
B.D. 1º Bach
3.4. CARDINALIDAD
La CARDINALIDAD nos permite saber
cuántas ocurrencias de una entidad se relacionan
con cuantas ocurrencias de la entidad del otro lado
de la relación.
“Un empleado trabaja como mínimo en una
tienda y como máximo en dos.”
3.5. CLASIFICACIÓN DE LAS RELACIONES
Existen dos tipos de cardinalidad:
- Se denomina CARDINALIDAD MÁXIMA
de la relación al número máximo de
ocurrencias de cada entidad que pueden
intervenir en la relación que se está
considerando.
- Se denomina CARDINALIDAD MÍNIMA,
al número mínimo de ocurrencias de cada
entidad que deben intervenir en la relación
que se está considerando.
Las relaciones pueden ser de varios tipos
dependiendo de cuantas ocurrencias de una entidad
se relacionen con las de otra a las que este unida
con una relación.
Una vez que hemos determinado la
cardinalidad de la relación es fácil saber de qué tipo
es, simplemente fijándonos es las cardinalidades
máximas. Así tendríamos:
Observar que con la cardinalidad minima la
relación es obligatoria, es decir, para que exista la
relación debe haber al menos tantas entidades
involucradas como indique la cardinalidad mínima.
1/1. Uno con uno. Si una ocurrencia de una
entidad se interrelaciona como máximo con una
ocurrencia de la otra entidad.
Por ejemplo, dadas las entidades "hombre"
y "mujer", la relación "está casado" es 1:1, ya que
un hombre está casado como máximo con una
mujer y una mujer está casada como máximo con
un hombre.
Estas cardinalidades se escriben separadas
por dos puntos, a la izquierda la cardinalidad
mínima y a la derecha la máxima. Se ponen al lado
de la entidad que, según el sentido, se lee en último
lugar.
1/N. Uno con muchos. Si una ocurrencia de
una entidad se interrelaciona con varias de la otra.
Por ejemplo, dadas las entidades
"empleado" y "departamento", la relación
"pertenece" es del tipo 1:N ya que un empleado
pertenece a un departamento y a un departamento
pueden pertenecer varios empleados.
Para nuestro ejemplo, supongamos que un
empleado puede trabajar como mucho en dos
tiendas y que una tienda tiene como mínimo dos
empleados y como mucho cinco. El grafico
quedaría como sigue:
N/N. Muchos con muchos. Si varias
ocurrencias de una entidad se interrelacionan con
varias ocurrencias de la otra.
Por ejemplo, dadas las entidades
"empleado" y "proyecto", la relación "trabaja" es
N:N ya que un empleado puede trabajar en muchos
proyectos y en un proyecto pueden trabajar muchos
empleados.
El mínimo de tiendas en que trabaja un
empleado es de 1, porque en caso contrario no
tendría sentido llamarlo empleado.
Ahora el sentido si importa. Leyendo de
izquierda a derecha leemos:
El tipo de relación se indica encima del robo
de la relación correspondiente.
“En una tienda trabajan al menos dos
empleados y como mucho cinco.”
Pero leyendo de derecha a izquierda:
6/17
B.D. 1º Bach
- Los atributos empieza después de una
tabulación debajo de la entidad a la que
pertenecen.
- La clave principal aparece la primera y
subrayada.
- El dominio de los atributos se indica después
de dos puntos.
- Para las cadenas de caracteres debemos
indicar el espacio que se reserva. Esto se
hace por eficiencia. De esta forma nuestra
base de datos ocupará solo el espacio
necesario y no más.
3.6. DICCIONARIO DE DATOS
Los datos que vamos a guarda en la base de
datos realmente se van a almacenar en los atributos
de las entidades. Por ello de cada entidad debemos
identificar los atributos que la componen, su
dominio y cuál es la clave principal.
Determinar el dominio de cada atributo nos
va a servir para restringir el tipo de información que
puede almacenarse en los atributos.
Por ejemplo si tenemos una entidad
denominada Alumno, con los atributos: nombre,
apellido1, apellido2, fechaNac y DNI. Obviamente
no queremos que el usuario se confunda e
introduzca el nombre en campo fecha. Si fijamos el
dominio a fecha para fechaNac evitaremos esto,
pues el sistema no lo permitará, ya que el nombre
son letras.
3.7. METODOLOGÍA DE DISEÑO
Para realizar el estudio de un enunciado y
llegar a una base de datos idónea, se debe seguir un
plan de acción organizado como sigue:
1. Leer el enunciado completamente.
2. Dividir el enunciado en partes coherentes y
resolver cada parte independientemente.
3. Para cada parte identificar las entidades y
sus atributos, así como la clave principal.
Crearemos el diccionario de datos.
4. Identificamos las relaciones entre entidades
y creamos el modelo E/R.
Debemos determinar cual es la clave
principal porque asi podremos identificar
unívocamente cada una de las ocurrencias.
Para el ejemplo anterior fijaríamos como
clave principal el atributo DNI, pues nadie puede
tener el mismo DNI. De esta forma para buscar un
alumno me basta con su DNI. En cambio como el
nombre se puede repetir, necesitaría también el
nombre y apellidos.
Con la práctica los pasos anteriores se
agilizan y podemos directamente pasar a crear el
esquema final.
Para determinar todo lo anterior crearemos
el diccionario de datos( DD en adelante).
La estructura del diccionario de datos se
puede observar en el siguiente ejemplo:
Existen una serie de consideraciones que nos
hacen más fácil la traducción de un enunciado del
lenguaje natural a un esquema E/R:
1. ¿Tengo todas las entidades?
2. ¿Todas las entidades tienen clave?
3. ¿Todas las relaciones tienen cardinalidades?
4. ¿Existe alguna entidad repetida en mi
esquema?
5. Si una entidad tiene un solo atributo o
ninguno posiblemente haya que representarla
como atributo de otra entidad.
6. Las relaciones de las que no se nos diga nada
normalmente tendrán cardinalidad 1:n.
7. Si no nos dicen la clave y no podemos
determinar una clave adecuada, crearemos
una clave autonumérica, de nombre ID_algo.
8. Si tenemos que asociar el atributo con otra
entidad diferente de a la que pertenece, es
probable que ese atributo deba ser una
entidad.
@Tienda
IdTienda: Auto
Ubicación: CdC (50)
Tamaño: Núm
@Empleado
DNI: CdC (9)
Nombre: CdC (20)
Apellido1: CdC (20)
Apellido2: CdC (20)
Como se puede observar cumple varias
reglas:
- Al nombre de la entidad se le antecede la @
7/17
B.D. 1º Bach
3.8. EJEMPLO DE E/R COMPLETO
El administrador de una empresa nos ha llamado porque quiere que creemos una base de datos para
gestionar su negocio. Nos ha dado las siguientes explicaciones:
“ Existen diferentes Jefes, de los que tenemos guardado su nombre, apellidos, DNI, titulación y
teléfono. De las dependientas solo tenemos el nombre, apellidos y DNI. Los jefes mandan en una sola tienda,
aunque es jefe de todas las dependientas de la tienda. Estas trabajan en una sola tienda. Las dependientas
tienen un solo jefe y nos interesa saber que productos son los que venden cada dependienta, teniendo en cuenta
que un mismo producto se puede vender por varias dependientas. De los productos nos interesa saber su
precio, nombre, tipo y cantidad de los mismos que tenemos. De cada tienda queremos saber tamaño y
ubicación”
DICCIONARIO DE DATOS
@Jefe
DNI: CdC (9)
Nombre: CdC (20)
Apellido1: CdC (20)
Apellido2: CdC (20)
Titulación: CdC(50)
Telefono: Num
@Dependienta
DNI: CdC (9)
Nombre: CdC (20)
Apellido1: CdC (20)
Apellido2: CdC (20)
@Productos
Codigo: Num
Precio: moneda
Nombre: CdC(30)
Tipo: CdC(10)
Cantidad: Num
@Tienda
Idtienda: Auto
Ubicación: CdC (30)
Tamaño: Num
8/17
B.D. 1º Bach
4. IMPLEMENTACIÓN EN EL ORDENADOR
4.1. INTRO
El modelo E/R nos sirve para diseñar la BD,
es decir, nos ayuda a pensar sobre el problema y a
hallar una solución lo más adecuada posible. Pero
este modelo no puede utilizarse directamente en el
ordenador. Además cada empresa de software
utiliza diferentes herramientas para crear la BD.
En
este
apartado
veremos
cómo
implementar la BD. Para ello debemos saber que
correspondencia hay entre los elementos de
nuestros diseños y los elementos que pone a nuestra
disposición el SGBD.
Nosotros vamos a utilizar ACCESS, que
utiliza el MODELO RELACIONAL, en el que el
elemento básico son las tablas.
Si pasamos la clave principal de Tienda a
Jefe tendríamos:
Access utiliza dos símbolos: 1 e ∞. El ∞ es
como N. Por tanto lo que dice el esquema superior
es: Un jefe atiende una sola tienda, pero una tienda
es atendida por infinitos jefes.
Además debemos obligar a que en la tabla
jefe, todo jefe tenga relleno el campo IdTienda pues
la cardinalidad mínima es 1. En Access esto se
consigue poniendo el atributo como requerido.
Pero eso no es exactamente lo que nosotros
queríamos. Probemos a poner la relación al revés.
4.2. TRANSFORMACIÓN.
4.2.1. ELEMENTOS.
El modelo de ACCESS se compone de tres
elementos básicos: tablas y claves ajenas. Las tablas
están compuestas a su vez por columnas y filas.
Las entidades son transforman en tablas.
Los atributos son las columnas de la tabla.
Cada atributo tiene un dominio. Un conjunto de
ellos será la clave principal.
Una fila representa una ocurrencia de la
entidad.
Las relaciones se modelan por medio de
claves ajenas que veremos a continuación.
4.3.2. RELACIONES.
Para relacionar dos entidades, en este caso
dos tablas, se utilizan un conjunto de atributos que
denominamos CLAVE AJENA. Lo que se hace es
coger un atributo de una tabla y colocarlo en otra,
de tal forma que la clave ajena se corresponde con
el atributo de origen.
Por tanto tenemos ya dos tipos de clave, la
principal y la ajena.
Debemos transformar las relaciones
atendiendo a su tipo:
¿Que indica el esquema anterior?
¿Qué es lo que me impide que un jefe
mande varias tiendas, si la relación que vemos es
1,? Nada. Para ello hay que añadir una restricción,
de tal forma que no se pueda repetir el valor de la
clave ajena dentro de la tabla que la contiene. En
este caso no se pueden repetir los valores de DNIJefe. En ACCESS esto se consigue poniendo como
características del atributo(o campo): Indexado, con
valor: Si( sin duplicados).
1/1. Uno con uno. Se crean dos tablas una
para cada entidad. La clave principal de una de ellas
pasa a la otra como clave ajena.
1/N. Uno con muchos. Se crean dos tablas
una para cada entidad. La clave principal de la
En el ejemplo del apartado anterior tenemos:
9/17
B.D. 1º Bach
entidad con cardinalidad 1 pasa como clave ajena a
la que tiene cardinalidad N.
Es igual a la anterior estrategia, pero en este
caso no podemos elegir donde va la clave ajena.
Siguiendo con el ejemplo del apartado
anterior, vamos a transformar los siguiente:
requeridas tantas como indique J. En realidad este
caso incluye al anterior.
Según lo anterior, ¿cómo se transformaría el
siguiente esquema?
N/N. Muchos con muchos. Se crean dos
tablas, una para cada entidad. Además se crea una
tabla que tendrá sendas claves ajenas apuntando a
cada una de las claves primarias correspondientes
de las entidades que asocia. Estas claves ajenas se
convierten en claves ajenas en la nueva tabla.
Nos quedaría así:
Teniendo esto:
Además debemos obligar a que el campo
Dependienta.IdTienda nunca pueda estar vacio,
pues la cardinalidad mínima es 1.
En la tabla tienda no se pueden repetir los
valores de IDTienda, pero en cambio en
Dependienta, los valores de IDTienda pueden estar
repetidos, por lo que varias dependientas distintas
pueden trabajar en la misma tienda. Obviamente en
nuestra base de datos, habrá más dependientas que
tiendas.
Nos quedaría:
De esta forma un producto puede ser
vendido por muchas dependientas y una
dependienta puede vender distintos productos.
Caso genérico
Pero podemos tener el caso que las
cardinalidades no sean 1,1, sino J:K, siendo J y K
dos números concretos cualesquiera, como por
ejemplo 2 y 3. Lo vemos en el siguiente diagrama.
Caso genérico
Si las cardinalidades no son 1:N, sino J:N y
K:N, siendo J y K dos números concretos
cualesquiera.
En este caso procederíamos de la siguiente
manera: desde E2 hacia E1, pasamos tantas claves
ajenas como indique K y se marcarán como
10/17
B.D. 1º Bach
- Texto. Texto o combinaciones de texto y
números, así como números que no
requieran cálculos, como los números de
teléfono. Solo permite hasta 255 caracteres.
- Numérico. Datos numéricos utilizados en
cálculos matemáticos.
- Autonumérico. Valor numérico que
aumenta automáticamente cuando se inserta
una nueva fila.
- Memo. Texto extenso de mas de 255
caracteres.
- Fecha/hora. Tipo especial de datos para
almacenar fechas.
Entonces hacemos una tabla con tantas
claves ajenas procedentes de E1 como indique J y
tantas de E2 como indique K, convirtiendose todas
en claves principales de la nueva tabla.
En caso de que J o K sean 0 se pasarán
como mínimo una clave ajena. El caso de que una
ocurrencia de E1 no se asocie con ninguna de E2 se
refleja en que no existirá entrada para esa
ocurrencia en la tabla, existiendo la ocurrencia en su
propia tabla de entidad.
Consideraciones
- Cuando una clave principal de tipo
autonumerico, pasa como ajena a otra tabla,
en esta se define como numérico.
- Para componer el nombre de la clave ajena
utilizaremos el nombre de la clave principal,
seguido de un guión y después el nombre de
la entidad de la que proviene.
- Las claves ajenas son también primarias solo
en las tablas que provienen de una relación
N/N.
- La cardinalidad mínima se asegura poniendo
las claves ajenas como requeridas.
- Si la cardinalidad mínima es cero, entonces
la clave ajena no se pondrá como requerida.
- Si la cardinalidad máxima es uno, entonces
la clave ajena se pondrá sin duplicados.
¿Porque distintos tipos de datos? Porque
aunque el atributo esté vacío ocupa el espacio
reservado para el tipo de datos, por tanto estamos
desperdiciando espacio. Siempre hemos de elegir el
tipo de dato que más se ajusta a los datos que
vamos a almacenar.
4.5. PASOS PARA LA RESOLUCIÓN DE LOS
EJERCICIOS.
Cuando resolvemos este tipo de ejercicios es
útil proceder de manera ordenada, un posible orden
de resolución es el siguiente:
1. Pasar las entidades a tablas y poner las
claves.
2. Transformar las relaciones:
2.1. Las N/M a tablas.
2.2. Las 1/N transportan la clave: 1  N.
2.3. Las 1/1 transportan la clave donde
queramos.
3. Unir las tablas.
4. Determinar los tipos de datos.
4.4. TIPOS DE DATOS
El tipo de datos se asocia a cada atributo y
determina los valores que este puede tomar. Es la
correspondencia con el término dominio que hacen
los sistemas comerciales.
En ACCESS el tipo de datos se debe definir
al crear un atributo y los más usados son:
4.6. EJEMPLO ESQUEMA FINAL EN EL ORDENADOR
11/17
B.D. 1º Bach
Por su parte los atributos que son claves
ajenas se indican con #.
Si algún atributo es requerido se indica
poniendo /R detrás de su tipo de datos.
Si algún atributo no se puede repetir,
entonces se indica con /ND. Ten en cuenta que la
clave principal nunca se puede repetir, así que no
hace falta ponerle /ND.
4.7. PLANIFICACIÓN Y DD.
Una de las tareas mas importantes de la
informática es la planificación. Por ello antes de
pasar a implementar la solución, vamos a estudiar
esta por medio de los esquemas E/R, los esquemas
relacionales como el anterior y por medio del DD.
Por ello por cada problema tendremos tres
documentos el primero el esquema E/R, después
haremos el DD, continuamos con el relacional y
volvemos a completar el DD.
Vamos a completarlo con la información
necesaria concerniente a las relaciones, es decir,
indicando las tablas que provienen de una relación
N/M, las claves ajenas y las restricciones sobre las
claves ajenas.
Para nuestro ejemplo el DD quedarías así:
DICCIONARIO DE DATOS
@Jefe
DNI: CdC (9)
Nombre: CdC (20)
Apellido1: CdC (20)
Apellido2: CdC (20)
Titulación: CdC(50)
Telefono: Num
@Dependienta
DNI: CdC (9)
Nombre: CdC (20)
Apellido1: CdC (20)
Apellido2: CdC (20)
#IdTienda: Num /R
@Productos
Codigo: Num
Precio: moneda
Nombre: CdC(30)
Tipo: CdC(10)
Cantidad: Num
@Tienda
Idtienda: Auto
Ubicación: CdC (30)
Tamaño: Num
#DNI-Jefe: CdC(9) /R /ND
$Vende:
#Codigo-Producto: Num.
#DNI-Dependienta: CdC(9)
Como se puede observar que, por medio de
$, se indica que la tabla vende proviene de una
relación N/N.
12/17
B.D. 1º Bach
4.8. EJEMPLOS DE TRANSFORMACIÓN
@EMPLEADO
DNI
Telefono
@TIENDA
Direccion
Nombre
@EMPLEADO
DNI
Telefono
#Direccion /ND
@EMPLEADO
DNI
Telefono
@TIENDA
Direccion
Nombre
@TIENDA
Direccion
Nombre
@Trabaja
#DNI
#Direccion
@EMPLEADO
DNI
Telefono
@TIENDA
Direccion
Nombre
#DNI /R
@EMPLEADO
@TIENDA
DNI
Direccion
Telefono
Nombre
#DNI
@EMPLEADO
@TIENDA
DNI
Direccion
Telefono
Nombre
#DNI /R /ND
#DNI /R /ND
#DNI /ND
@EMPLEADO
@TIENDA
DNI
Direccion
Telefono
Nombre
#DNI /R
#DNI /R
@EMPLEADO
@TIENDA
No se pueden representar
DNI
Direccion
las cardinalidades del
Telefono
Nombre
empleado.
#DNI /R
#DNI /R
Igual al anterior. Necesitamos mecanismos que aun no se han estudiado.
@EMPLEADO
DNI
Telefono
@TIENDA
Direccion
Nombre
13/17
@Trabaja
#DNI
#DNI
#DIreccion
#Direccion
#Direccion
B.D. 1º Bach
Ejemplo transformación a ACCESS
En la tabla tienda los siguientes atributos tienen características especiales:
DNI_empleado /R /ND
DNI_empleado_1 /ND
Al crear las relaciones en ACCESS, la tabla empleado se muestra dos veces, para poder crear dos
relaciones en la misma tabla.
En el grafico de ACCESS las relaciones creadas muestran 1-1, en vez de 1-∞, porque se a las claves
ajenas se le asignado /ND(indexado, sin duplicados), como antes se ha dicho, y por tanto no se pueden repetir
dentro de la tabla tienda. De esta forma conseguimos la cardinalidad 1:1.
La representación de la cardinalidad 1:2 se corresponde con las dos relaciones, desde una tabla a otras
dos.
Por ejemplo la relación "cursa": un alumno
cursa una asignatura.
5. EJERCICIOS
1. Piensa en 10 ejemplos de dato.
7. Realiza el diseño en el modelo E/R indicando
los supuestos que no han podido recogerse,
así como los que ha sido necesario introducir.
2. Para los datos anteriores describe situaciones
en las que se conviertan en información.
A. Alquiler de automóviles.
Se desea diseñar según el modelo E/R una
base de datos sobre la información de las
reservas de una empresa de alquiler de
automóviles. Los supuestos semánticos son los
siguientes:
a) Un determinado cliente puede tener en
un momento dado varias reservas.
b) Una reserva la realiza un único cliente,
pero puede involucrar varios coches.
c) Todo coche tiene siempre asignado un
determinado garaje que no puede cambiar.
d) Cada reserva se realiza en una
determinada agencia.
e) Pueden existir en la base de datos
clientes que no hayan hecho ninguna reserva.
3. Piensa cinco ejemplos de parcelas del mundo
real donde sería útil una base de datos.
4. Identifica como mínimo cinco entidades y dos
ocurrencias de las mismas de estas parcelas
del mundo real: instituto, partido de fútbol,
zapatería, concesionario y mapa de carreteras.
5. Identifica los atributos que puedan ser útiles
de las entidades reconocidas en el ejercicio 2.
Pon dos ejemplos de los posibles valores de
cada atributo, es decir, de su dominio.
6. Identifica posibles relaciones entre las
entidades reconocidas en el ejercicio anterior.
14/17
B.D. 1º Bach
f) Todas las entidades tienen una clave
alfanumérica que las identifica unívocamente.
Construya un diagrama de E/R para una
compañía de seguros automovilísticos sabiendo
que:
a) Se dispone de un fichero de clientes
con el dni, nombre y dirección.
b) Se dispone de un fichero de
automóviles con la matrícula, marca y modelo.
c) Un cliente puede asegurar varios
automóviles.
d) A cada cliente se la aplica una tarifa
distinta según el método bonus-malus, es decir,
paga más quien mas accidentes haya tenido.
Para ello se dispone de un historial con la fecha y
costes de los accidentes que ha tenido cada
cliente con cada automóvil.
e) Cada automóvil siniestrado en un
accidente se repara en un determinado taller,
para lo cual existe un fichero de talleres con su
nombre y dirección. Pueden existir accidentes en
los cuales no se repare el vehículo, por ejemplo,
en caso de siniestro total.
f) Se emite un recibo anual por cada
automóvil asegurado de cada cliente, llevándose
un control de cuales están pagados.
B. Agencia de viajes
Realiza el diseño de una base de datos
para una agencia de viajes que, para ofrecer
mejor servicio a sus clientes, considera de interés
tener registrada la información referente a los
diferentes tours que puede ofrecer. Tener en
cuenta lo siguiente:
a) Un tour, según su finalidad, cultural,
histórica, deportiva,.. tiene unos determinados
puntos de ruta y puede repetirse varias veces al
año.
b) Un tour concreto se realiza a partir de
una fecha determinada.
c) Los puntos de ruta de un tour pueden
ser ciudades, monumentos, zonas geográficas,
etc. y se consideran de visita solamente o de
visita y estancia.
d) En este último caso el punto de ruta
tiene asignado un hotel o varios.
e) Entendemos por cliente de un viaje la
persona que ha decidido hacerlo y ha hecho
efectiva una señal.
f) Un cliente puede confirmar su
participación en más de un viaje( se
sobreentiende que las fechas son diferentes)
g) Las personas que participan en un viaje
pueden ser alojadas en los mismos o en
diferentes hoteles.
E. Biblioteca.
Se pretende mecanizar la gestión de una
biblioteca. Para ello se recoge la siguiente
información:
a) Se dispone de un fichero de usuarios
con el número de carnet, nombre y dirección.
b) Se dispone de un fichero de libros con
la signatura, autor, titulo y editor.
c) Se realizan prestamos de libros a los
usuarios. Cada usuario puede tener prestados a
la vez varios libros.
d) Se quiere llevar un control histórico de
todos los prestamos que se van realizando,
sabiendo además del libro y usuario, las fechas
de inicio y de devolución del préstamo.
e) Para cada libro se debe llevar un
control de su estado, para saber si está
disponible cuando un usuario los pide prestado.
f) A los usuarios se les puede penalizar
cuando cometan diversos retrasos en la
devolución,
impidiéndoles
realizar
nuevos
prestamos.
C. Metro.
Las siguientes reglas de negocio indican
como funciona una empresa que gestiona las
líneas de metro de la ciudad:
a) Una línea está compuesta por una serie
de estaciones en un orden determinado, siendo
muy importante recoger la información de este
orden.
b) Cada estación pertenece al menos a
una línea, pudiendo pertenecer a varias.
c) Cada línea tiene asignados una serie de
trenes, no pudiendo suceder que un tren esté
asignado a más de una línea.
d) Algunas estaciones tienen cocheras y
cada tren tiene reservada una cochera.
e) Cada cochera puede estar reservada
para uno o varios trenes.
f) Hay dos tipos de estaciones: normales y
mixtas. Las estaciones normales solo tienen
servicio de metro, mientras que las mixtas tienen
conexión con otros servicios( RENFE, cercanías,
estación de autobuses, aeropuerto, etc) Solo
interesa saber que conexiones existen desde
cada estación.
F. Banco
Se conocen las siguientes reglas de
negocio de un banco:
a) El banco tiene cuentas corrientes,
cuentas de ahorro y clientes.
b) Un cliente tiene al menos una cuenta,
aunque puede tener varias cuentas de los dos
tipos.
c) Cada cuenta pertenece a un único
cliente.
D. Compañía de seguros.
15/17
B.D. 1º Bach
d) Los clientes tienen un nombre, una
dirección y se identifican por un código. Los
clientes del banco son personas reales u
organizaciones. Las personas tienen fecha de
nacimiento y sexo; en cambio las organizaciones
tienen un tipo de organización, un representante
y un numero de empleados.
e) Cada cuenta se identifica por un
código-cuenta-cliente(CCC), formado por el
identificador del banco, de la sucursal y el
numero de cuenta(dentro de dicha sucursal).
f) Todas las cuentas tienen un saldo actual
y un saldo medio, pero el tipo de amortización
sólo lo tienen las cuentas de ahorro.
g) Cada sucursal se identifica por su
número. Además tiene una dirección, un código
postal y una ciudad.
h) Los empleados del banco se identifican
por su DNI. También interesa conocer su
nombre, fecha de nacimiento, sexo y la sucursal
en la que trabajan.( aunque hay empleados que
no trabajan en ninguna sucursal)
d) En las tiendas se venden diferentes
productos y estos se venden en diferentes
tiendas.
e) Los productos se identifican por un
identificador llamando IDProductos. Además
poseen una talla.
f) Los diferentes productos son: faldas,
pantalones, calzado y camisas.
g) Nos interesa saber la hora y el día en
que una dependienta vende un producto.
h) Existen dos tipos de trabajadores, las
dependientas( antes mencionadas) y los jefes.
Ambos poseen los atributos: DNI, teléfono,
nombre y salario.
i) Los jefes se diferencia por que tiene un
bonus al salario.
j) Los jefes manda en diferentes tiendas y
una tienda es mandada por un solo jefe.
I.Empresa electrica
Una empresa dedicada al suministro de
energía eléctrica, como FENOSA, nos ha pedido
que hagamos una base de datos con las
siguientes condiciones:
a) La empresa está compuesta por
centrales eléctricas, de las cuales sabemos su
ubicación, tamaño y potencia.
b) En cada central tenemos un director,
varios instaladores y cuatro transportistas. De
todos ellos tenemos una lista con su: DNI,
nombre, primer apellido y segundo apellido.
c) Los transportistas transportan varios
tipos de materiales distintos y de los cuales se
sabe su cantidad y precio. Me interesa saber el
vehiculo que conduce el transportista.
d) De los instaladores nos interesa su
titulación y la zona geográfica en la que trabajan.
Los instaladores instalan el material. Se quiere
llevar un registro de cuando un instalador instala
un material y la cantidad de material que instala.
e) El director dirige las centrales
eléctricas. Como mucho puede dirigir tres
centrales. No puede haber más de un director en
cada central. El director tiene un bonus a su
sueldo.
f) Cada central eléctrica suministra
electricidad a varios hogares. Un hogar solo
recibe su electricidad de una central. De los
hogares nos interesa su ubicación y la potencia
que necesitan. Queremos almacenar los hogares,
incluso si no se le está suministrando electricidad
por ninguna central.
g) Cada central tiene al menos 2 sectores.
De cada sector se quiere guardar su número,
tamaño en metros cuadrados, función y nivel de
producción. No se quiere que una central sea
muy grande por tanto no se permite que tenga
más de 5 sectores.
G. Autobuses
Se quiere crear una base de datos para
gestionar la red de autobuses urbanos.
a) De los conductores nos interesa
guardar el nombre, DNI y numero de telefono.
b) De los autobuses nos interesa guardar
la marca y la matricula.
c) Hay dos tipos de autobuses: simples y
dobles. De los dobles nos interesa guardar el tipo
de bisagra que une las dos mitades.
d) Cada conductor conduce siempre el
mismo autobús y un autobús puede ser
conducido por distintos conductores.
e) Un autobús recorre una o varias lineas
y una línea es recorrida por distintos autobuses.
f) Nos interesa saber a que hora empieza
cada autobús a recorrer la línea.
g) De la línea nos interesa almacenar el
nombre y el color.
h)
Cada
linea
está
formada
por
estaciones, pero una estación solo pertenece a
una sola línea, es decir, las líneas son
independientes, no se cruzan.
i) De la estación nos interesa guardar el
nombre, ubicación y el orden en la línea.
H. Tiendas de ropa
a) Las tiendas tienen una ubicación y un
identificador numérico, llamado IDtienda.
b) Las dependientas trabajan en solo una
tienda y en una tienda trabajan mas de una
dependienta.
c) De las dependientes nos interesa saber
el nombre, DNI, salario y teléfono.
16/17
B.D. 1º Bach
J.Tienda de informática
Se quiere crear una base de datos para
gestionar una empresa de venta de productos
informáticos. De la base de datos se tiene la
siguiente información:
a) De todos los trabajadores nos interesa
saber su DNI, nombre, primer apellido, segundo
apellido y sueldo. En plantilla, es decir, propios
de la empresa, tenemos a los dependientes, los
jefes y los limpiadores.
b) De cada tienda nos interesa saber las
dimensiones, la calle y la ciudad donde está. En
cada tienda trabaja como mínimo un dependiente
y como máximo tres. Un dependiente atiende
solo una tienda.
c) De los dependientes nos interesa saber
donde viven, porque si viven en la misma ciudad
que en la que trabajan venden mas.
d) Los jefes mandan en varias tiendas y
en una tienda solo manda un jefe. De estos nos
interesa guardar el bonus de sueldo, que
depende de lo bien que funcionen las tiendas que
mandan. Como mucho un jefe puede mandar en
tres tiendas.
e) De los limpiadores nos interesa saber si
son ajenos o no, es decir, si los ha contratado la
empresa o son de una empresa de limpieza. Los
limpiadores limpian como mucho cuatro tiendas y
una tienda solo la limpia un limpiador.
f) De los productos que se venden nos
interesa saber el nombre, la marca, el precio y la
descripción. Un mismo producto puede ser
vendido por distintas marcas. Nos interesa saber
cuando vende un dependiente un determinado
producto.
g) Queremos guardar información de los
proveedores. Incluso de los que no nos proveen
ningún
producto.
De
estos
proveedores
queremos guardar el teléfono, nombre y DNI.
17/17