CONCEPTOS INTRODUCTORIOS DE BASES DE DATOS Prof. Nelliud D. Torres

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