La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "CONCEPTOS INTRODUCTORIOS DE BASES DE DATOS Prof. Nelliud D. Torres."— Transcripción de la presentación:

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

2 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)

3 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).

4 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.

5 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.

6 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.

7 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.

8 TERMINOLOGÍA TRADICIONALBASE DE DATOS BASE DE DATOS RELACIONAL ArchivoEntidadTabla RecordInstanciaFila CampoAtributoColumna

9 EJEMPLO DE ENTIDADES ESTUDIANTE EMPLEADO CLIENTE MATRÍCULA CURSOS DEPARTAMENTO LIBRO PRESTAMO

10 EJEMPLOS DE ATRIBUTOS ENTIDAD CLIENTE número nombre dirección teléfono crédito ENTIDAD ESTUDIANTE número nombre edad genero departamento igs escuela procedencia

11 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.

12 EJEMPLOS ENTIDADES EN DIAGRAMAS CLIENTE número nombre dirección teléfono crédito ESTUDIANTE número nombre edad genero seguro social departamento igs escuela procedencia ESTADIO (PARQUE) nombre dirección teléfono capacidad sillas capacidad carros

13 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).

14 Ejemplos de UID CLIENTE número nombre seguro social dirección teléfono crédito ESTADIO (PARQUE) id nombre dirección teléfono capacidad sillas capacidad 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.

15 RELACIONES Es una asociación bidireccional (ambas direcciones) e imprecindible entre dos entidades o entre una entidad y ella misma.

16 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

17 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

18 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)

19 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

20 RELACIONES – DIAGRAMAS - EJEMPLOS DEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por El nombre de la relación se pone arriba o abajo de la línea que une las dos entidades.

21 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

22 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

23 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Í:

24 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 EMPLEADO numero nombre seguro social habitado por estar asignado

25 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

26 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

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

28 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)

29 MUCHOS A UNO M 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.

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

31 MUCHOS A MUCHOS M 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.

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

33 UNO A UNO 1 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.

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

35 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.)

36 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.

37 UIDs 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.

38 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

39 ESTUDIANTE #* id * nombre o inicial * apellido paterno * apellido materno * género (#) seguro social o o celular o 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 estar habitado por el originador de originada por seleccionada por el originador de creada para seleccionado por SISTEMA SOLICITUD VIAJES INTERNACIONALES

40 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 A B B B B A A A A B B


Descargar ppt "CONCEPTOS INTRODUCTORIOS DE BASES DE DATOS Prof. Nelliud D. Torres."

Presentaciones similares


Anuncios Google