Informática: Bases de datos

1 Bach
INFORMATICA
BASES DE DATOS
1 Bach
1/12
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 ordenador ............................................................................................................. 11
2/12
1 Bach
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 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.
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.
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.
1.3. 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.
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.
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.
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.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.
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.5. MODELO DE BASE DE DATOS
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/12
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.
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: 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.
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.
1.6. PASOS PARA CONSTRUIR UNA BD
Cuando queremos crear una base de datos
debemos dar los siguientes pasos:
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.
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.
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.
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.
2.2. ATRIBUTOS
Se define ATRIBUTO como cada una de
las características, básicas de una entidad.
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.
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/12
1 Bach
Se define DOMINIO como el conjunto de
valores que puede tomar un atributo.
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.
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
2.3. RELACIÓN
Una RELACIÓN
semántica entre entidades.
es
una
conexión
Por ejemplo: entre las entidades
"empleado" y "empresa" se puede reconocer la
relación "pertenece".
La principal utilidad del esquema E/R es
poner de manifiesto las relaciones entre
entidades.
3.2. ENTIDADES.
Las entidades se representan por medio de
un rectángulo, dentro del cual se escribe el nombre
de la entidad.
EMPLEADO
Suponiendo que estamos modelando una
empresa el grafico anterior representaría un
empleado cualquiera.
3.3. RELACIONES
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.
3. MODELO E/R
3.1. INTRODUCCIÓN
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.
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.
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.
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.
Lo que se obtiene de aplicar lo anterior se
denomina el esquema E/R.
5/12
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.
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.
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.
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:
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:
“En una tienda trabajan al menos dos
empleados y como mucho cinco.”
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:
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.
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.
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 tipo de relación se indica encima del robo
de la relación correspondiente.
Pero leyendo de derecha a izquierda:
6/12
1 Bach
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.
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.
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:
@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 @
- 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.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.
Con la práctica los pasos anteriores se
agilizan y podemos directamente pasar a crear el
esquema final.
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.
7/12
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/12
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.
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:
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.
En el ejemplo del apartado anterior tenemos:
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.
¿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/N. Uno con muchos. Se crean dos tablas
una para cada entidad. La clave principal de la
9/12
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:
Nos quedaría así:
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.
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.
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.
Nos quedaría:
De esta forma un producto puede ser
vendido por muchas dependientas y una
dependienta puede vender distintos productos.
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/12
1 Bach
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.
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:
- 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.
¿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 a la 1:n.
2.3. Las 1/1 transportan la clave donde
queramos.
3. Unir las tablas.
4. Determinar los tipos de datos.
4.6. EJEMPLO ESQUEMA FINAL ORDENADOR
11/12
1 Bach
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.
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.
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/12