conceptos introductorios de bases de datos prof. nelliud d. torres
TRANSCRIPT
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 DATOSUna 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 DATOSBASE 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
CLIENTEnúmeronombredirecciónteléfonocréditoe-mail
ESTUDIANTEnúmeronombreedadgeneroseguro socialdepartamentoigsescuela procedencia
ESTADIO(PARQUE)
nombredirecciónteléfonocapacidad sillascapacidad carros
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 UIDCLIENTE
númeronombreseguro socialdirecciónteléfonocréditoe-mail
ESTADIO(PARQUE)
idnombredirecciónteléfonocapacidad sillascapacidad carros
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.
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:
CADA entidad-1
nombre de la relación
entidad-2
TIENE QUE SER
O
PUEDER SER
UNO O MÁS
O
UNO Y SOLO UNO
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 - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s)
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
RELACIONES - DIAGRAMASLas relaciones se pueden diagramar de la siguiente forma:1. Una línea une las dos entidades2. El nombre de la relación va en minúsculas3. 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 - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
DEPARTAMENTO
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
habitado por
El nombre de la relación se pone arriba o abajo de la línea que une las dos entidades.
RELACIONES – DIAGRAMAS - EJEMPLOS
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
ESTUDIANTE
númeronombreseguro social
CURSO
códigosemestredescripción
tomar
RELACIONES – DIAGRAMAS - EJEMPLOS
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
EDIFICIO
idlocalizacióndescripción
APARTAMENTO
númeropisocantidad cuartos
poseer
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 - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
Cada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO
DEPARTAMENTO
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
habitado por
estar asignado
RELACIONES – DIAGRAMAS - EJEMPLOS
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S)
ESTUDIANTE
númeronombreseguro social
CURSO
códigosemestredescripción
tomar
tomado por
RELACIONES – DIAGRAMAS - EJEMPLOS
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
Cada APARTAMENTO tiene que ser poseido por uno y solo un EDIFICIO
EDIFICIO
idlocalizacióndescripción
APARTAMENTO
númeropisocantidad cuartos
poseer
poseido por
EJEMPLO DE UN ERD DE UN SISTEMA DE COMPRAS
CLIENTE
númeronombreseguro social
ALMACEN
iddescripciónlocalización
ORDEN
númerotipofecha
ARTÍCULO
numerodescripciónpeso
el originador de
originado por
emitida para
incluido en
almacenado en
el depósito para
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 UNOM a 1 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
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
habitado por
estar asignado
M∞
1
MUCHOS A MUCHOSM a M 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
M
∞
M
∞
ESTUDIANTE
númeronombreseguro social
CURSO
códigosemestredescripción
tomar
tomado por
UNO A UNO1 a 1 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
11
CARRO
tablillamarcamodelo
MOTOR
númerodescripción
posee
está asignado
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.
EJEMPLOS DE DIAGRAMAS COMPLETOS DE SISTEMAS
tener ubicado
estar ubicado en
rentar
rentado por
tener
creada por
contener
contenido en
SLIP
#* id
* numero
* largo
* renta anual
* nombre del bote
* tipo de bote
FACILIDAD
#* id
* nombre
* dirección
* ciudad
* estado
* zipcode
SERVICIO
#* id
* descripción
CLIENTE
#* id
* nombre
* dirección
* ciudad
* estado
* zip code
SOLICITUD
#* id
* descripción
* status
* estimado de horas
* horas usadas
o fecha próximo servicio
SISTEMA RENTA DE LOTES DE
BOTES
ESTUDIANTE#* id* nombreo inicial* apellido paterno* apellido materno* género(#) seguro socialo e-mailo celularo comentarios
DEPARTAMENTO
#* id
* nombre
PROGRAMA
#* id
* nombre
PUEBLO
#* id
* nombre
SOLICITUD#* id* tipo de solicitud* fecha de solicitud
UNIVERSIDAD
#* id
* nombre
PERIODO
#* id
* nombre
estar compuesto de pertenecer a pertenecer a
estar habitado por
el originador de
originada por
seleccionada por
el originador de
creada paracreada para
creada para seleccionado por
SISTEMA SOLICITUD VIAJES INTERNACIONALES
DIAGRAMA PARA REPRESENTAR LAS RELACIONES ENTRE LAS ENTIDADES
Modelación conceptual y lógica
Modelación Física (Access)
Uno a uno (1 : 1)
Uno a Muchos (1 : M)
Muchos a Muchos (M : M)
No aplica
AA BB
BBAA
AA BB