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 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. Compartir los Datos – Diferentes sistemas en la misma empresa pueden compartir sus datos sin problema. Se refuerza la estandarización – En las Bases de Datos es más facil estandarizar procesos. Redundancia controlada – La duplicidad de los datos es mínima. Consistencia – Al no haber tanta redundancia, los datos que se modifican pueden ser accedidos sin problemas de que no este sincronizado el cambio. Integridad - La Base de datos tiene la capacidad de validar datos independientemente del programa.

ALGUNAS VENTAJAS DE LAS BASES DE DATOS (CONT.) Seguridad – La Base de datos permite diseñar distintos niveles de seguridad sin tener que programarlo. Flexibilidad y rapidez al obtener datos – El usuario puede tener acceso a los datos sin intervención del personal de IT. 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. 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. 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 Tamaño - Requiere de mucho espacio en disco duro y también requiere de mucha memoria principal (RAM) para poder correr adecuadamente. Complejidad – Es difícil de utilizar y requiere adiestramiento del personal técnico. Costo – Las licencias comerciales son caras. 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.) 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.  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.

BASE DE DATOS RELACIONAL 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 ESTUDIANTE número nombre edad genero seguro social departamento igs escuela procedencia CLIENTE número nombre dirección teléfono crédito e-mail ESTADIO (PARQUE) nombre dirección teléfono capacidad sillas capacidad 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 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: 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 - EMPLEADO ESTUDIANTE - CURSO 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: Una línea une las dos entidades El nombre de la relación va en minúsculas El diagrama de Opcionalidad es: Puede ser Tiene que ser 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 EMPLEADO numero nombre seguro social habitado por

RELACIONES – DIAGRAMAS - EJEMPLOS ESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar

RELACIONES – DIAGRAMAS - EJEMPLOS EDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s) EDIFICIO id localización descripción APARTAMENTO número piso cantidad 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 - 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 habitado por DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social estar asignado

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 código semestre descripción tomar tomado por

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 APARTAMENTO número piso cantidad cuartos poseer poseido por

EJEMPLO DE UN ERD DE UN SISTEMA DE COMPRAS ORDEN número tipo fecha ARTÍCULO numero descripción peso emitida para incluido en almacenado en originado por el depósito para el originador de CLIENTE número nombre seguro social ALMACEN id descripción localización

EXISTEN 3 TIPOS DE RELACIONES ENTRE LAS ENTIDADES Muchos a uno (M : 1) Muchos a muchos (M : M) Uno a uno (1 : 1)

MUCHOS A UNO M a 1 o M : 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. Es el tipo de relación más común dentro de las bases de datos. Las relaciones de muchos a uno que sea obligatoria en ambas partres es rara.

MUCHOS A UNO - EJEMPLO 1 M∞ DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por estar asignado 1 M∞

MUCHOS A MUCHOS M a M o M : M Tiene un grado de uno o más en ambas partes. También es un tipo de relación común. Pueden ser opcionales en una o en ambas partes.

MUCHOS A MUCHOS - EJEMPLO ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar tomado por M ∞ M ∞

UNO A UNO 1 a 1 o 1 : 1 Tiene un grado de uno y sólo uno en ambas partes. Este tipo de relación es raro y más aún si ambas partes son obligatorias. Este tipo de relación podría indicar que ambas relaciones se puedan convertir en solo una.

UNO A UNO - EJEMPLO 1 CARRO tablilla marca modelo MOTOR número descripción posee está asignado

CONVENCIONES DE LOS ATRIBUTOS Los nombres de los atributos se crean pensando en el usuario (debe entenderlos) EL nombre de la entidad no debe incluirse como parte del nombre del atributo Deben ser específicos y descriptivos. (Ej. cantidad devuelta, fecha de nacimiento, etc.)

SÍMBOLOS PARA LOS ATRIBUTOS * - Significa obligatorio (el atributo debe ser llenado por el usuario, no se puede dejar en blanco) 0 – Significa opcional, el usuario no está obligado a llenar ese atributo. # - Identifica un atributo que es UID (también hay que ponerle el símbolo de obligatorio). (#) - 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 * nombre * dirección * ciudad * estado * zipcode SERVICIO * descripción CLIENTE * dirección * zip code SOLICITUD * status * estimado de horas * horas usadas o fecha próximo servicio EJEMPLOS DE DIAGRAMAS COMPLETOS DE SISTEMAS SISTEMA RENTA DE LOTES DE BOTES

SISTEMA SOLICITUD VIAJES INTERNACIONALES ESTUDIANTE #* id * nombre o inicial * apellido paterno * apellido materno * género (#) seguro social o e-mail o celular o comentarios DEPARTAMENTO PROGRAMA PUEBLO SOLICITUD * tipo de solicitud * fecha de solicitud UNIVERSIDAD PERIODO estar compuesto de pertenecer a estar habitado por el originador de originada por seleccionada por creada para seleccionado por

A B B A A B Modelación conceptual y lógica Modelación Física (Access) 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 A B B A A B