1. Bases de Datos
Lic. Diego Fabian Gómez
Uniminuto

2. Diseño de Bases de Datos
•Conceptos
Básicos

3. Base de Datos
• Una base de datos es un “almacén” que nos
permite guardar grandes cantidades de
información de forma organizada para que
luego podamos encontrar y utilizar fácilmente.
A continuación te presentamos una guía que te
explicará el concepto y características de las
bases de datos.
• El término de bases de datos fue escuchado
por primera vez en 1963, en un simposio
celebrado en California, USA. Una base de
datos se puede definir como un conjunto de
información relacionada que se encuentra
agrupada ó estructurada.

4. Bases de Datos
• Desde el punto de vista informático, la
base de datos es un sistema formado
por un conjunto de datos almacenados
en discos que permiten el acceso
directo a ellos y un conjunto de
programas que manipulen ese conjunto
de datos.
• Cada base de datos se compone de una
o más tablas que guarda un conjunto
de datos. Cada tabla tiene una o
más columnas y filas. Las columnas
guardan una parte de la información
sobre cada elemento que queramos
guardar en la tabla, cada fila de la tabla
conforma un registro.

5. Base de Datos
Se define una base de datos
como una serie de datos
organizados y relacionados entre
sí, los cuales son recolectados y
explotados por los sistemas de
información de una empresa o
negocio en particular.
http://www.maestrosdelweb.com/editorial/%C2%BFque-son-las-bases-de-datos/

6. Características de las
BD

7. Características de las BD
• Entre las principales características de los sistemas de base datos
podemos mencionar:
• Independencia lógica y física de datos
• Redundancia mínima
• Acceso concurrente por parte de múltiples usuarios
• Integridad de los datos.
• Consultas complejas optimizadas.
• Seguridad de acceso y auditoría.
• Respaldo y recuperación.
• Acceso a través de diferentes lenguajes.

8. DBMS (Database
Management System)
• Es un conjunto coordinado de
programas, procedimientos, le
nguajes, etc. Que suministra
tanto a los usuario no
informáticos como a los
analistas, programadores o al
administrador los medios
necesarios para
describir, recuperar y
manipular los datos
almacenados en la
base, manteniendo su
integridad, confidencialidad y
seguridad.

9. Ejemplos de DBMS
• Oracle
• SQL Server
• Sybase
• DB2
• MySQL
• PostgreSQL

10. Lenguaje de Definición de
Datos. (DDL)
• En la parte de definición de
un DBMS debe existir un
conjunto de instrucciones o
comando que permitan
crear las estructuras de las
bases de datos. A este
conjunto de instrucciones se
le conoce como lenguaje de
definición de datos.
En esta especifican los elementos de datos que
integran la BD, su estructura y las relaciones que
existen entre ellos, las reglas de integridad
semántica, los controles a efectuar antes de
autorizar el acceso a la base de datos, así como
las características de tipo de físico y las vistas
lógicas de los usuarios.

11. Lenguaje de Manipulación de
datos (DML)
• La función de manipulación permite a los usuarios de la base, informáticos o
no, buscar, añadir, suprimir o modificar los datos de la misma, siempre de
acuerdo con las especificaciones y las normas de seguridad dictadas por el
administrado. Al conjunto de instrucciones de este tipo se le conoce como
lenguaje de manipulación de datos.

12. Diseño de la Base de Datos
• Al igual que existe una
metodología para crear
programas que
resuelvan una
problemática, es
necesario establecer un
procedimiento de
diseño de las
estructuras de las bases
de datos.
• El diseño se divide en
varios niveles:
Nivel Conceptual
Nivel Lógico
Nivel Físico
Entendimiento de la persona
Entendimiento de la máquina
DBMS

13. Modelo Conceptual
• Se visualiza los conjuntos de
datos que deben incluirse
en el modelo de datos, así
como sus relaciones. En
esta etapa se puede hacer
uso del modelo Entidad –
Vínculo, que es uno de los
modelos de mayor
semántica de diseño.
Después de identificar el grupo de dato, se debe
generar una estructura lógica para la
manipulación de la base de datos por medio del
DBMS. Para ello es necesario usar un modelo
que puede ser el relacional, que además de
establecer la estructura de campos y
registros, permite establecer reglas de
integridad de datos y reglas de normalización
para mejorar la estructura. Finalmente la parte
de estructura física la maneja el DBMS con
algunos que son necesarios, como por ejemplo
la creación de índices.

14. Modelo Entidad Vínculo
• El modelo Entidad-Vinculo
fue propuesto por Peter P.
Chen en diferentes artículos
en el año de 1976. Consiste
en un modelo de
representación del mundo
real que consiste en
Entidades y relaciones.
• También conocido como
Entidad – Relación, diferente
al modelo Relacional-
Entidad
Objeto real o abstracto
Persona, lugar, suceso, real o
abstracto

15. Entidad
• Una entidad se representa por un rectángulo como
lo muestra la siguiente figura:
LECTOR

16. LECTOR
Entidad Débil
• Son aquellas que no
pueden existir sino existe
una entidad normal, por
ejemplo el crédito de un
cliente. Si el cliente no
existe, la cuenta
tampoco. Y se representa
por medio de un
rectángulo dentro de
otro.
CUENTA

17. EJERCICIO CREACION DE
ENTIDADES
• Inventarios y facturación:
• Una empresa que se dedica a la venta de
productos de papelería desea llevar el control
de su inventario a través de un sistema basado
en bases de datos. El sistema debe registrar las
ventas de mostrador e imprimir facturas si es
necesario, con los datos de los clientes.
Igualmente, se deben capturar las facturas de
los proveedores para actualizar las existencias
de los productos. Cada mes el sistema debe
generar reportes sobre las existencias de los
productos para realizar un inventario. El
sistema debe ser capaz de manejar información
global de ventas al mes, al año, así como la
determinación de la existencia en la tienda de
productos.
• Señalar cuales son las entidades explique
porqué
Inventarios y facturación:
Una empresa que se dedica a la venta de productos de
papelería desea llevar el control de su inventario a través
de un sistema basado en bases de datos. El sistema debe
registrar las ventas de mostrador e imprimir facturas si es
necesario, con los datos de los clientes. Igualmente, se
deben capturar las facturas de los proveedores para
actualizar las existencias de los productos. Cada mes el
sistema debe generar reportes sobre las existencias de
los productos para realizar un inventario. El sistema debe
ser capaz de manejar información global de ventas al
mes, al año, así como la determinación de la existencia en
la tienda de productos.
Señalar cuales son las entidades explique porqué
Solución

18. Creación de Entidades
Clientes Proveedores
Facturas de Ventas Ventas Productos Facturas de Compras

19. 2~ Caso

20. SEMESTRES
Catedráticos Materias
Calificaciones
Carreras
Alumnos

21. Características del Modelo ER
• Refleja tan solo la existencia de los
datos, no lo que se hace con ellos.
• Se incluyen todos los datos relevantes
del sistema en estudio.
• No está orientado a aplicaciones
específicas
• Es independiente de los SGBD
• No tiene en cuenta restricciones de
espacio, almacenamiento, ni tiempo de
ejecución.
• Está abierto a la evolución del sistema.
• Es el modelo conceptual más utilizado
Profesor
Tutor Estudiante
Nombre Curso
ID
Modulo Estudios

22. Elementos del Modelo ER
• ENTIDAD (entity)
• ATRIBUTO (attibute)
• DOMINIO (domain)
• RELACIÓN (relationship)
• LLAVES (KEY)

23. ENTIDADES
• Cualquier objeto (real o abstracto) que existe en la realidad y acerca del cual queremos almacenar
información en la BD
• Las entidades se representan gráficamente mediante rectángulos con su nombre en el interior
• Realmente, los rectángulos representan tipos de entidad, pero se omite el termino “tipo de entidad”. De
tal forma que hablaremos siempre de entidades.
• Las entidades representan conjuntos de instancias, ocurrencias, ejemplares, e un determinado tipo de
objeto del mundo real.

24. ATRIBUTOS
• Atributos = cada una de las propiedades o características
que tiene una entidad.
• Los atributos son valores simples, ejemplo. Enteros, cadena
de caracteres, sin estructura, conjuntos, etc.
• Los atributos se representan mediante un óvalo con el
nombre del atributo dentro.
• Adjetivo: Identificar, relacionar, Describir

25. Tipos de atributos
• Identificadores: son atributos que
identifican de manera unívoca cada
ocurrencia de una entidad. Toda entidad
debe tener al menos un atributo
identificador.
• Se representa subrayando el nombre del
atributo:
• Una entidad puede tener más de 1
atributo identificador; en ese
caso, elegimos un atributo como
identificador primario (P), quedando el
resto como identificador alternativos (A)
NIP
NIP NC
PERSONA
A
DIA HORA
HORARIO

26. Tipos de atributos
• Atributos Simples y
Compuestos
• Simples: son atributos que no
están formados por otros
atributos.
PESO
APELLIDO 1 APELLIDO2
APELLIDOS
NOMBRE
NOMBRE
COMPLETO

27. • Compuestos: son
atributos que están
formados por otros
atributos que a su vez
pueden ser simples o
compuestos.
• Ejemplo de simples y
compuestos:
• Color es simple, toma
valores rojo, azul, etc.
• Nombre es
compuesto, contiene
nombre de pila y
PESO
APELLIDO 1 APELLIDO2
APELLIDOS
NOMBRE
NOMBRE
COMPLETO

28. • Monovaluados: son atributos que representan
un valor para una determinada ocurrencia de
una entidad en un momento
determinado, Pueden ser simples o compuestos.

29. • Derivados (o calculados): son atributos cuyo valor se
obtiene aplicando una formula, no se almacenaran en
la base de datos. Su valor se obtendrá en el momento
en que sea necesario aplicando la fórmula asociada a
ellos.
• Ejemplo: El promedio de préstamo se puede derivar
si tenemos los valores de cada préstamo realizado a
la persona.

30. TELEFONO
Tipos de atributos
• Multivaluados: son atributos
que pueden representar
varios valores
simultáneamente para una
misma ocurrencia de una
entidad. Se representa
mediante un óvalo. Pueden
ser simples o compuestos.
• Ejemplo: Teléfono o
Teléfonos.
TELEFONO
EDAD

31. TIPOS DE ATRIBUTOS
• Propios: son los atributos de las relaciones. Se
representan unidos al rombo de la relación.
CANTIDAD
CLIENTE COMPRA PRODUCTOS

32. DIAGRAMA SIMBOLOS Y
NOTACIONES
Entidad
Entidad Débil
Atributos
Atributo Multivariado
Relación
Relación Débil

33. ENTIDAD
ORDEN

34. ORDEN
ENTIDAD DEBIL
ORDEN Articulo del pedido

35. Comprador
Atributo
Id
Numero
Nombre
Calle
Ciudad
Dirección

36. Atributo Multivaluado
Profesor TemasTemas

37. Atributo Derivado
Circulo
Radio Área

38. Actividad Ejemplo 3
• Modelar el siguiente problema.
• Se trata de una base de datos que debe almacenar la información sobre varias
estaciones meteorológicas, en una zona determinada. De cada una de ellas
recibiremos y almacenaremos un conjunto de datos cada día: temperatura
máxima y mínima, precipitaciones en litros/m2, velocidad del viento máxima y
mínima, y humedad máxima y mínima.
• El sistema debe ser capaz de seleccionar, añadir o eliminar estaciones. Para
cada una almacenaremos su situación geográfica (latitud y
longitud), identificador y altitud.
• Fuente: http://mysql.conclase.net/curso/?cap=002b#ER_EJEMPLO1

39. 1.Crear las entidades
2.Identificar Atributos
3.Crear el modelo con entidades y atributos

41. Quiz
A partir del siguiente enunciado se desea realiza el modelo
entidad-relación
1. Una empresa vende productos a varios clientes. Se
necesita conocer los datos personales de los clientes
(nombre, apellidos, DNI, dirección y fecha de nacimiento).
Cada producto tiene un nombre y un código, así como un
precio unitario. Un cliente puede comprar varios productos
a la empresa, y un mismo producto puede ser comprado
por varios clientes.
Los productos son suministrados por diferentes proveedores.
Se debe tener en cuenta que un producto solo puede ser
suministrado por un proveedor, y que un proveedor puede
suministrar diferentes productos. De cada proveedor se desea
conocer el DNI , nombre y dirección.

42. Quiz
A partir del siguiente enunciado se desea realiza el modelo entidad-
relación
2. “Se desea informatizar la gestión de una empresa de transportes que
reparte paquetes por toda Argentina. Los encargados de llevar los
paquetes son los camioneros, de los que se quiere guardar el
DNI, nombre, teléfono, dirección, salario y población en la que vive. De
los paquetes transportados interesa conocer el código de
paquete, descripción, destinatario y dirección del destinatario. Un
camionero distribuye muchos paquetes, y un paquete sólo puede ser
distribuido por un camionero.
De las provincias a las que llegan los paquetes interesa guardar el código
de provincia y el nombre. Un paquete sólo puede llegar a una provincia.
Sin embargo, a una provincia pueden llegar varios paquetes.
De los camiones que llevan los camioneros, interesa conocer la
matrícula, modelo, tipo y potencia. Un camionero puede conducir
diferentes camiones en fechas diferentes, y un camión puede ser
conducido por varios camioneros”

43. Modelo de Entidad - Vínculo
• Se entiende por vínculo, relación o interrelación a
aquella asociación o correspondencia existente entre
entidades.
• Se denomina tipo de vínculo a la estructura genérica
del conjunto de vínculos existentes entre dos o mas
tipos de entidad.

44. Modelo de Entidad - Vínculo
• El vínculo se representa por medio de un rombo, en
el cual se escribe un verbo
CONDUCE

45. Modelo de Entidad - Vínculo
• En los vínculos se debe establecer el nombre, el
grado, la cardinalidad y el tipo de correspondencia. El
grado se refiere a la cantidad de entidades que
intervienen en la relación. Así, si existe una entidad
que se relaciona a así misma es un vínculo de grado
1.

46. Modelo de Entidad - Vínculo
• Se deben definir dos tipos de cardinalidad: mínima y
máxima. La mínima se refiere al número mínimo de
correspondencias en que una entidad puede
participar y la máxima, el número máximo. En los
diagramas las cardinalidades mínima y máxima se
colocan entre paréntesis separadas por una como
sobre la línea del vínculo:
• (card. Mínima, card Máxima)

47. Modelo de Entidad - Vínculo
• El tipo de correspondencias se refiere al
número máximo de ocurrencias de cada
entidad que puede intervenir en una
ocurrencia de vínculo. Esta puede ser: de
una a una, de uno a mucho y de muchos a
muchos.

48. CONDUCE
CONDUCE
CONDUCE
1:1 De uno a Uno
1:N De uno a Muchos
N:M De Muchos a Muchos

49. Inventarios y Facturación
Proveedores
Facturas de Ventas Ventas Productos
Facturas de Compras
realizaClientesgenera
se Tener

50. Catedráticos Materias
Cursos
Carreras
Alumnos

52. RELACIÓN
• Para evitar confusiones con el término usaremos
interrelación, ya que relación tiene un significado
radicalmente diferente dentro del modelo
relacional, y esto nos puede llevar a error.
• Interrelación: es la asociación o conexión entre
conjuntos de entidades.
• Tengamos los dos conjuntos: de personas y de
vehículos. Podemos encontrar una interrelación
entre ambos conjuntos a la que
llamaremos posee, y que asocie una entidad de
cada conjunto, de modo que un individuo posea un
vehículo.

53. • Grado: número de conjuntos de entidades que
intervienen en una interrelación.
• De este modo, en la anterior interrelación
intervienen dos entidades, por lo que diremos que
es de grado 2 o binaria. También existen
interrelaciones de grado 3, 4, etc. Pero las más
frecuentes son las interrelaciones binarias.
• Podemos establecer una interrelación ternaria (de
grado tres) entre personas, de modo que dos
personas sean padre y madre, respectivamente, de
una tercera.

54. • Existen además tres tipos distintos de interrelaciones
binarias, dependiendo del número de entidades del
primer conjunto de entidades y del segundo. Así
hablaremos de interrelaciones 1:1 (uno a uno), 1:N
(uno a muchos) y N:M (muchos a muchos).
• Nuestro ejemplo anterior de "persona posee vehículo"
es una interrelación de 1:N, ya que cada persona puede
no poseer vehículo, poseer uno o poseer más de uno.
Pero cada vehículo sólo puede ser propiedad de una
persona.
• Otras relaciones, como el matrimonio, es de 1:1, o la de
amistad, de N:M.

55. Modelo Entidad
RelaciónRelación.- Asociación entre entidades para reflejar las
interacciones existentes entre entidades.
Relaciones n-n.-Cada ocurrencia, en
cualquiera de las dos entidades de la
relación, puede estar asociada con
muchas (n) de la otra y viceversa
Relaciones 1-1.- Las
entidades que intervienen en
la relación se asocian una a
una
Relaciones 1-n.- Una
ocurrencia de una entidad
está asociada con muchas
(n) de otra

56. Representación
Gráfica 1
Existen diversas formas de representar un Modelo Entidad-
Relación:
Entidades: Rectángulo redondeado, con
Nombre en Mayúscula
Atributos: en minúscula
Relaciones:
Uno a Uno: 1-1
Uno a Muchos: 1-
n
Muchos a Muchos: n-n
CLIENTE
#*ci
*nombre
*apellido
Campos claves: #
Campos Obligatorios: *

57. Representación
Gráfica 2Existen diversas formas de representar un Modelo Entidad-
Relación:
Entidades: Rectángulo nombre en
mayúscula
Atributos: en minúscula dentro de
óvalos
Relaciones:
Uno a Uno: 1-1
Uno a Muchos: 1-n
Muchos a Muchos: n-n
CLIENTE
ci nombre
apellido
compra
compra
Campo clave: Se subraya

58. Relaciones "uno a uno"
• Estas relaciones entre bases de datos se dan
cuando cada campo clave aparece sólo una vez en
cada una de las tablas.
• Tomando un ejemplo del mundo real, una clara
relación de "uno a uno" podría ser, el nombre de
cualquier persona y su número de teléfono. Si
partimos del supuesto en que cada persona tiene
un solo número de teléfono, se podría hablar de
una relación "uno a uno".

60. • Este tipo de relaciones se caracteriza porque cada
uno de los campos define a aquél con el que se
relaciona.
• Es decir, conociendo el nombre de una persona
podemos conocer su número telefónico. O si
sabemos su número telefónico, podemos
identificar al dueño. En estos casos, se suele
aconsejar incluir todos los datos dentro de una sola
tabla.

61. Relaciones de "uno a
varios"
• El ejemplo del caso anterior (cada persona, un
teléfono), si bien es correcto teóricamente, es muy
improbable desde el punto de vista de la realidad. Con
la gran expansión de los teléfonos, por lo general, cada
persona tiene un número de teléfono fijo, y además del
teléfono móvil. Debemos tener en cuenta que de el de
su casa también tendrá un número de teléfono de
empresa, y que quizá también sus móviles estén
divididos en ocio y trabajo.
• Por ello, debemos tener nuestras bases de datos
preparadas para ello. Este tipo de relaciones es
conocido como "uno a varios", y se podría representar
de la siguiente manera:

63. Relaciones de "uno a
varios"
• En este caso, lo aconsejable no es almacenar todos
los datos en una sola tabla, sino lo eficiente es
hacerlo en tablas separadas, utilizando el
identificador ID para relacionarlas.

65. • En la tabla Nombre almacenamos el nombre y
apellido, con su ID o número identificador. En la otra
tabla, Teléfonos, almacenamos únicamente números
de teléfono, con su correspondiente número
identificador, en este caso TID. La manera en que se
relaciona una con otra es mediante el identificador
ID, que está presente en ambas tablas.

66. Relaciones de "varios a
varios"
• La última de la relaciones que podemos encontrar
es la de "varios con varios". Dado que en la vida las
cosas rara vez son sencillas, éste será el tipo de
relación que nos encontraremos más a menudo.

67. • Volviendo al tema de los teléfonos, hemos
encontrado la manera de relacionar cada una de las
personas con sus diversos teléfonos: el de su
casa, el de su empresa, el móvil. Pero no será
extraño tener en nuestra base de datos diversas
personas que trabajen en la misma empresa, por lo
que el número de su trabajo será el mismo, o
miembros de una misma familia, por lo que
compartirán el mismo teléfono de su hogar.

68. • ¿Cómo tratar este tipo de relaciones? Si nos
limitamos a repetir dicho número de
tablas, estaremos creando problemas de
redundancia de datos, que a largo plazo lastrarán la
rapidez y eficacia de nuestras tablas.

70. • Como vemos, cada elemento de la base de datos puede
relacionarse libremente con uno o varios miembros de
las distintas tablas.
• En estos casos no hay una regla fija a la que podamos
acogernos, pero lo aconsejable es aproximarse lo más
posible a la realidad, y no dudar en establecer tablas
intermedias que nos ayuden a asociar mejor los datos.
• Volviendo al tema de los teléfonos, imaginemos que
varias personas de nuestra tabla trabajan en la misma
empresa en donde tienen varias líneas, por lo que los
números de teléfono de trabajo de estas personas
serían varios. ¿Cómo representarlo en nuestra base de
datos?

72. • En este caso hemos creado una tabla intermedia
llamada "empresas". En la tabla "nombres"
incluimos un nuevo campo TID, que se relaciona
con la tabla "empresas", y es esta tabla la que se
relaciona directamente con los teléfonos. De esta
manera, podemos almacenar todos los datos con
facilidad sin tener que repetir un sólo número
telefónico.

73. • Se pueden distinguir tres tipos de relaciones:
• Relación Uno a Uno: Cuando un registro de una
tabla sólo puede estar relacionado con un único
registro de la otra tabla y viceversa.
• Por ejemplo: tenemos dos tablas una con los datos
de diferentes poblaciones y otra con una lista de
Alcaldes, una población sólo puede tener un
alcalde, y un alcalde lo será únicamente de una
población.

74. • Relación Uno a Varios: Cuando un registro de una
tabla (tabla secundaria) sólo puede estar
relacionado con un único registro de la otra
tabla (tabla principal) y un registro de la otra
tabla (tabla principal) puede tener más de un
registro relacionado en la primera tabla (tabla
secundaria).
• Por ejemplo: tenemos dos tablas una con los datos
de diferentes poblaciones y otra con los
habitantes, una población puede tener más de un
habitante, pero un habitante pertenecerá (estará
registrado) en una única población.

75. • Relación Varios a Varios: Cuando un registro de una
tabla puede estar relacionado con más de un registro
de la otra tabla y viceversa.
• Por ejemplo: tenemos dos tablas una con los datos de
clientes y otra con los artículos que se venden en la
empresa, una cliente podrá realizar un pedido con
varios artículos, y un artículo podrá ser vendido a más
de un cliente.
• Las relaciones varios a varios se suelen representar
definiendo una tabla intermedia entre las dos tablas.
Por ejemplo sería definir una tabla líneas de pedido
relacionada con clientes y con artículos.

76. Ejemplos:
• Un alumno puede estar en uno y solo un grupo de
escuela y un grupo de escuela puede tener uno o
muchos alumnos. (relación uno a muchos)
• Un producto puede estar en una o muchas ventas y
una venta puede tener uno o muchos productos
(relación de muchos a muchos)

77. Ejemplos:
• Un esposo puede tener una y solo una esposa y una
esposa puede tener uno y solo un esposo (relación
uno a uno)
• Una amante puede tener uno y solo un esposo y un
esposo puede tener una o muchas amantes (relación
de uno a muchos)

78. Ejercicio:
• Según el concepto de relaciones, escriba 2 ejemplos
de cada una.

79. Ejercicio:
• Cree el enunciado y el modelo entidad relación de:
• Una persona tiene un numero de cédula.
• Una persona puede tener varios correos electrónicos.
• Varios conductores para varios buses.
• Un usuario una clave
• Una persona tiene varios uniformes
• Hay varios alimentos para muchas personas.

80. Solución Parcial
Cliente
Pedido
Articulo
Fabrica

81. Solución Parcial
Cliente
Pedido
Articulo
Fabrica
Rea
liza
1,1
0,n
con
tie
ne
1,n
1,n
Cantidad
Dis
trib
uye
1,n
1,n

82. Cliente
#Cliente
Saldo Descuento
Credito
Direcciones
de envio
N
Calle Ciudad
Comuna

83. Pedido
#Cliente
Fecha
Hora
Dia, mes
año
Direcciones
de envio
N
Calle Ciudad
Comuna

84. Articulo
#Articulo
Descrip
cion

85. Fabrica
#Fabrica Telefono
Artículos
distribui
do

86. Clave
• En principio, cada entidad se puede distinguir de
otra por sus atributos. Aunque un subconjunto de
atributos puedan ser iguales en entidades
distintas, el conjunto completo de todos los
atributos no se puede repetir nunca. Pero a
menudo son sólo ciertos subconjuntos de atributos
los que son diferentes para todas las entidades.

87. • Clave: es un conjunto de atributos que identifican
de forma unívoca una entidad.
Cliente
#Cliente
Saldo Descuento
Crédito

88. • Por ejemplo la entidad persona, podemos pensar
que de una forma intuitiva sabemos qué atributos
distinguen a dos personas distintas. Sabemos que
el nombre por si mismo, desde luego, no es uno de
esos atributos, ya que hay muchas personas con el
mismo nombre.
Persona
nombre

89. • A menudo, el conjunto de nombre y apellidos
puede ser suficiente, pero todos sabemos que
existen ciertos nombres y apellidos comunes que
también se repiten, y que esto es más probable si
se trata de personas de la misma familia.
Persona
nombres
apellidos

90. • Las personas suelen disponer de un documento de
identidad que suele contener un número que es
distinto para cada persona.
Persona
nombres
apellidos documento

91. • Pero habrá aplicaciones en que este valor tampoco
será una opción: podemos tener, por
ejemplo, personas en nuestra base de datos de
distintas nacionalidades, o puede que no tengamos
acceso a esa información (una agenda personal no
suele contener ese tipo de datos), también hay
personas, como los menores de edad, que
generalmente no disponen de documento de
identidad.

92. • Con otros tipos de entidad pasa lo mismo. En el
caso de vehículos no siempre será necesario
almacenar el número de matrícula o de bastidor, o
tal vez no sea un valor adecuado para usar como
clave (ya veremos más adelante que en el esquema
físico es mucho mejor usar valores enteros).
Vehiculos
matricula
bastidor dueño

93. • En ocasiones, por un motivo u otro, creamos un
atributo artificial para usarlo sólo como clave. Esto
es perfectamente legal en el modelo E-R, y se hace
frecuentemente porque resulta cómodo y lógico.
Vehiculos
#Id_vehiculos
bastidor dueño
Id_matricula

94. Claves candidatas
• Una característica que debemos buscar siempre en
las claves es que contengan el número mínimo de
atributos, siempre que mantengan su función.
Diremos que una clave es mínima cuando si se
elimina cualquiera de los atributos que la
componen, deja de ser clave. Si en una entidad
existe más de una de estas claves mínimas, cada
una de ellas es una clave candidata.

95. • Clave candidata: es cada una de las claves mínimas
existente en un conjunto de entidades.
Vehiculos
color
bastidor dueño
matricula

96. color
bastidor
dueño
matricula
Llaves
Candidatas

97. Clave principal
• Si disponemos de varias claves candidatas no
usaremos cualquiera de ellas según la ocasión. Esto
sería fuente de errores, de modo que siempre
usaremos la misma clave candidata para identificar
la entidad.

98. • Clave principal: (o primaria), es una clave candidata
elegida de forma arbitraria, que usaremos siempre
para identificar una entidad.

99. color
bastidor
dueño
#matricula
Llaves
Principal

100. Claves de interrelaciones
• Para identificar interrelaciones el proceso es
similar, aunque más simple. Tengamos en cuenta
que para definir una interrelación usaremos las
claves primarias de las entidades interrelacionadas.
De este modo, el identificador de una interrelación
es el conjunto de las claves primarias de cada una
de las entidades interrelacionadas.

101. • Por ejemplo, si tenemos dos personas identificadas
con dos valores de su clave
primaria, clave1 y clave2, y queremos establecer
una interrelación "es padre de" entre
ellas, usaremos esas dos claves. El identificador de
la interrelación será clave1,clave2.
ENTIDAD1 ENTIDAD2INTERRELACION
CLAVE1 CLAVE2CLAVE1 CLAVE2

102. Entidades fuertes y débiles
• A menudo la clave de una entidad está ligada a la
clave principal de otra, aún sin tratarse de una
interrelación.

103. • Por ejemplo, supongamos una entidad viaje, que
usa la clave de un vehículo y añade otros atributos
como origen, destino, fecha, distancia.
viaje
Id_matricula
origen destino
distancia
fecha

104. • Decimos que la entidad viaje es una entidad
débil, en contraposición a la entidad vehículo, que
es una entidad fuerte. La diferencia es que las
entidades débiles no necesitan una clave
primaria, sus claves siempre están formadas como
la combinación de una clave primaria de una
entidad fuerte y otros atributos.

105. • Además, la existencia de las entidades débiles está
ligada o subordinada a la de la fuerte. Es
decir, existe una dependencia de existencia. Si
eliminamos un vehículo, deberemos eliminar
también todos los viajes que ese vehículo ha
realizado.

106. • Se trata de gestionar una biblioteca, y nuestro cliente
quiere tener ciertas herramientas a su disposición para
controlar libros, socios y préstamos. Adicionalmente se
necesita un control de los ejemplares de cada libro, su
ubicación y su estado, con vistas a su retirada o
restitución, para esto último necesita información sobre
editoriales a las que se deben pedir los libros.
• Tanto los ejemplares como los socios estarán sujetos a
ciertas categorías, de modo que según ellas cada ejemplar
podrá ser o no prestado a cada socio. Por ejemplo, si las
categorías de los ejemplares van de A a F, y la de los socios
de B a F, un ejemplar de categoría A nunca puede ser
prestado a ningún socio. Estos ejemplares sólo se pueden
consultar en la biblioteca, pero no pueden salir de ella. Un
ejemplar de categoría B sólo a socios de categoría B, uno
de categoría C se podrá prestar a socios de categorías B y
C, etc. Los ejemplares de categoría F siempre pueden
prestarse.

107. • El sistema debe proporcionar también un método de
búsqueda para libros por parte de los socios, por
tema, autor o título. El socio sólo recibirá información
sobre los libros de los que existen ejemplares, y sobre la
categoría.
• Además, se debe conservar un archivo histórico de
préstamos, con las fechas de préstamo y devolución, así
como una nota que el responsable de la biblioteca quiera
hacer constar, por ejemplo, sobre el estado del ejemplar
después de su devolución. Este archivo es una
herramienta para la biblioteca que se puede usar para
discriminar a socios "poco cuidadosos".
• Los préstamos, generalmente, terminan con la devolución
del libro, pero algunas veces el ejemplar se pierde o el
plazo supera un periodo de tiempo establecido y se da por
perdido. Estas circunstancias pueden cerrar un préstamo y
provocan la baja del ejemplar (y en ocasiones la del socio
:-). Nuestro archivo histórico debe contener información
sobre si el libro fue devuelto o perdido.

108. • Identificar entidades
• Identificar relaciones
• Primer diagrama
• Identificar atributos
• Selección claves
• Verificar modelo

109. Catedráticos Materias
Cursos
Carreras
Alumnos
Impa
rte
De
los
Perte
nece
Acre
dita
Id_Cat Id_Mat Id_Carre
Id_Curso Id_Alum