CONCEPTOS
INTRODUCTORIOS DE BASES
DE DATOS
Prof. Nelliud D. Torres
Conceptos de Estructuras de Datos
• Una estructura de Datos:
– Puede ser un archivo o tabla que contiene datos
relacionados a personas, lugares, cosas o eventos
que interactúan con el sistema.
– Los sistemas clásicos son: File-oriented y utilizan
ese formato para interactuar con el sistema (File
processing system)
– Actualmente los sistemas se trabajan bajo la
estrucutra de Base de Datos (Database system)
DEFINICIÓN BASE DE DATOS
Una Base de Datos consiste de una colección
de datos interrelacionados y un conjunto de
programas que permiten acceder esos
datos. Su objetivo primordial es proporcionar un
medio ambiente que sea conveniente y eficiente
tanto al extraer como al almacenar datos. Su
orientación es a nivel empresarial como la
entidad central en donde todas sus operaciones
se fusionan al utilizar esta herramienta
(centralizado).
ALGUNAS VENTAJAS DE LAS BASES DE DATOS
1. Obtener más información de la misma cantidad de data –
El usuario tiene la oportunidad de poder obtener más datos
útiles si el sistema está programado en una base de datos.
2. Compartir los Datos – Diferentes sistemas en la misma
empresa pueden compartir sus datos sin problema.
3. Se refuerza la estandarización – En las Bases de Datos es
más facil estandarizar procesos.
4. Redundancia controlada – La duplicidad de los datos es
mínima.
5. Consistencia – Al no haber tanta redundancia, los datos que
se modifican pueden ser accedidos sin problemas de que no
este sincronizado el cambio.
6. Integridad - La Base de datos tiene la capacidad de validar
datos independientemente del programa.
ALGUNAS VENTAJAS DE LAS BASES DE DATOS
(CONT.)
7. Seguridad – La Base de datos permite diseñar distintos
niveles de seguridad sin tener que programarlo.
8. Flexibilidad y rapidez al obtener datos – El usuario puede
tener acceso a los datos sin intervención del personal de IT.
9. Aumenta la productividad de los programadores – Los
programadores no se dedican a programar validación ni
seguridad, ni se tienen que preocupar por el Diseño. Se
pueden dedicar a la programación.
10. Mejora el mantenimiento de los programas – Los datos son
separados de los programas, de este modo el mantenimiento
de los programas no afecta la Base de Datos.
11. Independencia de los Datos – Si existe un cambio en los
datos, esto no tiene impacto en la programación.
ALGUNAS DESVENTAJAS DE LAS BASES DE
DATOS
1. Tamaño - Requiere de mucho espacio en disco duro y también
requiere de mucha memoria principal (RAM) para poder correr
adecuadamente.
2. Complejidad – Es difícil de utilizar y requiere adiestramiento
del personal técnico.
3. Costo – Las licencias comerciales son caras.
4. Requerimientos adicionales de equipo – Generalmente se
requiere más equipo del normal parar poder aguantar los
requerimientos de una Base de Datos. (memoria, velocidad del
procesador, disco duro, etc.)
5. Mayor impacto en caso de falla - Si un componente de la
Base de Datos sufre un desperfecto, se detiene las
operaciones del producto por completo.
6. Complejo recuperar los datos - En caso de un accidente que
corrompa la Base de datos, el proceso de recuperación y de
devolver a la Base de Datos a su estado anterior al problema,
es mucho mas complejo de ejecutar que en sistemas
tradicionales.
BASE DE DATOS - TÉRMINOS
• Entidades – Algo importante que deseamos
almacenarlo. Por ejemplo: Una persona, evento,
lugar, categoría o cualquier otra cosa que se le
pueda nombrar.
• Relaciones – Define como las entidades se
relacionan entre si.
• Atributos – Datos que deseamos guardar en una
entidad y como resultado, la describe.
TERMINOLOGÍA
TRADICIONAL
BASE DE DATOS
BASE DE DATOS
RELACIONAL
Archivo
Entidad
Tabla
Record
Instancia
Fila
Campo
Atributo
Columna
EJEMPLO DE ENTIDADES
•
•
•
•
•
•
•
•
ESTUDIANTE
EMPLEADO
CLIENTE
MATRÍCULA
CURSOS
DEPARTAMENTO
LIBRO
PRESTAMO
EJEMPLOS DE ATRIBUTOS
•
•
•
•
•
•
ENTIDAD CLIENTE
número
nombre
dirección
teléfono
crédito
e-mail
ENTIDAD ESTUDIANTE
• número
• nombre
• edad
• genero
• departamento
• igs
• escuela procedencia
REGLAS PARA DIAGRAMAR
• Las entidades van en una caja (rectangular)
sin bordes preferiblemente.
• Los nombres de las entidades se escriben
en singular y en mayúsculas.
• Cada nombre debe ser único.
• Se puede poner un alias a una entidad que
tenga más de un nombre entre paréntesis.
• Los nombres de los atributos van en letra
minúscula.
EJEMPLOS ENTIDADES EN
DIAGRAMAS
CLIENTE
número
nombre
dirección
teléfono
crédito
e-mail
ESTADIO
(PARQUE)
nombre
dirección
teléfono
capacidad sillas
capacidad carros
ESTUDIANTE
número
nombre
edad
genero
seguro social
departamento
igs
escuela procedencia
IDENTIFICADOR ÚNICO (UID)
Cada instancia (record) de una entidad
necesita tener un campo que lo diferencie
de los demás records o instancias que
coexisten en la entidad. Este campo se
convertirá en el Unique Identifier (UID).
Ejemplos de UID
CLIENTE
número
nombre
seguro social
dirección
teléfono
crédito
e-mail
El número del cliente es muy
buen candidato para un UID
ya que su valor es único
El seguro social también
podría ser un buen candidato
para un UID.
ESTADIO
(PARQUE)
id
nombre
dirección
teléfono
capacidad sillas
capacidad carros
En el caso de un estadio,
necesitamos crear un atributo
artificial (id) que posea un valor
único para que identifique cada
instancia (record) de la entidad.
RELACIONES
Es una asociación bidireccional
(ambas direcciones) e imprecindible
entre dos entidades o entre una
entidad y ella misma.
RELACIONES - SINTAXIS
La sintaxis que vamos a utilizar para determinar
las relaciones va a ser:
TIENE QUE SER
CADA entidad-1
O
PUEDER SER
nombre de la relación
UNO O MÁS
O
UNO Y SOLO UNO
entidad-2
RELACIONES - COMPONENTES
• Nombre de la relación – Se utiliza una
palabra que haga sentido al unir la
relación entre dos entidades
• Opcionalidad – Sólo se puede indicar
“tiene que ser” o “puede ser”
• Grado o Cardinalidad - Sólo se puede
indicar “Uno o más” o “Uno y solo uno”
RELACIONES - EJEMPLOS
DEPARTAMENTO - EMPLEADO
Cada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
ESTUDIANTE - CURSO
Cada ESTUDIANTE puede tomar uno o más CURSO(s)
EDIFICIO – APARTAMENTO
Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
RELACIONES - DIAGRAMAS
Las relaciones se pueden diagramar de la
siguiente forma:
1. Una línea une las dos entidades
2. El nombre de la relación va en minúsculas
3. El diagrama de Opcionalidad es:
•
•
Puede ser
Tiene que ser
4. El diagrama de Grado o Cardinalidad es:
•
•
Uno o más
Uno y solo uno
RELACIONES – DIAGRAMAS EJEMPLOS
DEPARTAMENTO - EMPLEADO
Cada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
El nombre de la relación se
pone arriba o abajo de la línea
que une las dos entidades.
DEPARTAMENTO
id
localización
descripción
habitado por
EMPLEADO
numero
nombre
seguro social
RELACIONES – DIAGRAMAS EJEMPLOS
ESTUDIANTE - CURSO
Cada ESTUDIANTE puede tomar uno o más CURSO(s)
ESTUDIANTE
número
nombre
seguro social
tomar
CURSO
código
semestre
descripción
RELACIONES – DIAGRAMAS EJEMPLOS
EDIFICIO – APARTAMENTO
Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
EDIFICIO
id
localización
descripción
poseer
APARTAMENTO
número
piso
cantidad cuartos
IMPORTANTE
UNA RELACIÓN ES BIDIRECCIONAL. Por lo
tanto hay que detallar y diagramar la relación
también del otro lado.
FINALMENTE LOS DIAGRAMAS QUEDARÍAN
ASÍ:
RELACIONES – DIAGRAMAS EJEMPLOS
DEPARTAMENTO - EMPLEADO
Cada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
Cada EMPLEADO tiene que estar asignado a uno y solo un
DEPARTAMENTO
DEPARTAMENTO
id
localización
descripción
habitado por
estar asignado
EMPLEADO
numero
nombre
seguro social
RELACIONES – DIAGRAMAS EJEMPLOS
ESTUDIANTE - CURSO
Cada ESTUDIANTE puede tomar uno o más CURSO(s)
CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S)
ESTUDIANTE
número
nombre
seguro social
CURSO
tomar
tomado por
código
semestre
descripción
RELACIONES – DIAGRAMAS EJEMPLOS
EDIFICIO – APARTAMENTO
Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
Cada APARTAMENTO tiene que ser poseido por uno y solo un
EDIFICIO
EDIFICIO
id
localización
descripción
poseer
APARTAMENTO
poseido por
número
piso
cantidad cuartos
EJEMPLO DE UN ERD DE UN
SISTEMA DE COMPRAS
ORDEN
ARTÍCULO
emitida para
número
tipo
fecha
incluido en
numero
descripción
peso
almacenado en
originado por
el originador de
el depósito para
CLIENTE
ALMACEN
número
nombre
seguro social
id
descripción
localización
TIPOS DE RELACIONES
EXISTEN 3 TIPOS DE RELACIONES
ENTRE LAS ENTIDADES
1. Muchos a uno (M : 1)
2. Muchos a muchos (M : M)
3. Uno a uno (1 : 1)
MUCHOS A UNO
Ma1 o M:1
1. Tiene un grado de uno o más en una
parte de la relación y de uno y solo uno
en la otra parte.
2. Es el tipo de relación más común dentro
de las bases de datos.
3. Las relaciones de muchos a uno que sea
obligatoria en ambas partres es rara.
MUCHOS A UNO - EJEMPLO
DEPARTAMENTO
habitado por
id
localización
descripción
EMPLEADO
estar asignado
1
M
∞
numero
nombre
seguro social
MUCHOS A MUCHOS
MaM o M:M
1. Tiene un grado de uno o más en ambas
partes.
2. También es un tipo de relación común.
3. Pueden ser opcionales en una o en
ambas partes.
MUCHOS A MUCHOS - EJEMPLO
ESTUDIANTE
CURSO
tomar
número
nombre
seguro social
tomado por
M
M
∞
∞
código
semestre
descripción
UNO A UNO
1a1 o 1:1
1. Tiene un grado de uno y sólo uno en
ambas partes.
2. Este tipo de relación es raro y más aún
si ambas partes son obligatorias.
3. Este tipo de relación podría indicar que
ambas relaciones se puedan convertir en
solo una.
UNO A UNO - EJEMPLO
CARRO
MOTOR
posee
tablilla
marca
modelo
número
descripción
está asignado
1
1
CONVENCIONES DE LOS
ATRIBUTOS
1. Los nombres de los atributos se crean
pensando en el usuario (debe entenderlos)
2. EL nombre de la entidad no debe incluirse
como parte del nombre del atributo
3. Deben ser específicos y descriptivos. (Ej.
cantidad devuelta, fecha de nacimiento,
etc.)
SÍMBOLOS PARA LOS ATRIBUTOS
1. * - Significa obligatorio (el atributo debe ser
llenado por el usuario, no se puede dejar en
blanco)
2. 0 – Significa opcional, el usuario no está
obligado a llenar ese atributo.
3. # - Identifica un atributo que es UID
(también hay que ponerle el símbolo de
obligatorio).
4. (#) - UID segundario. Por ejemplo: seguro
social.
UID’s EN RELACIONES
• Cuando deseamos que un UID se utilize en
otra entidad realcionada, utilizamos el símbolo:
• Cuando deseamos incluir un UID como un
campo foráneo (foreign key) en la otra entidad
relacionada, utilizamos el símbolo:
• IMPORTANTE: En la entidad que lleva uno de
esos dos símbolos,en el ERD NO se le
especifíca el atributo.
FACILIDAD
EJEMPLOS DE DIAGRAMAS
COMPLETOS DE SISTEMAS
#* id
* nombre
* dirección
* ciudad
* estado
* zipcode
SLIP
tener
ubicado
estar
ubicado en
tener
#* id
* numero
* largo
* renta anual
* nombre del bote
* tipo de bote
SOLICITUD
#* id
* descripción
* status
* estimado de horas
* horas usadas
creada por
o fecha próximo servicio
rentado por
SISTEMA RENTA
DE LOTES DE
BOTES
contener
rentar
contenido en
CLIENTE
#* id
* nombre
* dirección
* ciudad
* estado
* zip code
SERVICIO
#* id
* descripción
SISTEMA SOLICITUD VIAJES
INTERNACIONALES
DEPARTAMENTO
PUEBLO
#* id
#* id
* nombre
* nombre
ESTUDIANTE
estar
compuesto de
pertenecer a
#* id
* nombre
o inicial
* apellido paterno
* apellido materno
* género
(#) seguro social
o e-mail
o celular
o comentarios
el originador de
estar habitado
por
pertenecer a
originada por
SOLICITUD
creada para
#* id
* tipo de solicitud
* fecha de solicitud
seleccionada por
creada para
creada para
el originador de
UNIVERSIDAD
seleccionado por
PERIODO
PROGRAMA
#* id
#* id
#* id
* nombre
* nombre
* nombre
DIAGRAMA PARA REPRESENTAR LAS RELACIONES ENTRE LAS ENTIDADES
Modelación
conceptual y lógica
Modelación Física (Access)
Uno a uno (1 : 1)
A
B
Uno a Muchos (1 : M)
A
B
Muchos a Muchos (M : M)
A
B
No aplica
Descargar

CONCEPTOS INTRODUCTORIOS DE BASES DE DATOS