Curso de Base de Datos. El alumno realizará el diseño, creación y manipulación de bases de datos relacionales, acorde a los requerimientos establecidos, para la administración de la información.

1. BASES DE
DATOS
PROFESOR: MTRO. JUAN MANUEL AGÜERA CASTRO
!
email: juan.m.aguera@gmail.com
Blog: http://cursos-licenciatura.blogspot.mx

2. BASES DE DATOS
OBJETIVO

3. BASES DE DATOS

4. BASES DE DATOS

5. BASES DE DATOS

6. BASES DE DATOS
Blog: http://cursos-licenciatura.blogspot.mx

7. BASES DE DATOS: INTRODUCCIÓN
SISTEMA GESTOR
DE BASE DE
DATOS
DBMS / SGBD
Una colección de datos
interrelacionados y un conjunto
de programas para acceder a
dichos datos
BASE DE
DATOS
Colección
de
datos
interrelacionada con información
relevante de la empresa

8. BASES DE DATOS: INTRODUCCIÓN
OBJETIVO
PRINCIPAL
DE UN
SGBD
PROPORCIONAR UNA FORMA
DE
ALMACENAR
Y
RECUPERAR LA INFORMACIÓN
R E L E VA N T E PA R A U N A
EMPRESA

9. BASES DE DATOS: INTRODUCCIÓN
¿PORQUE SE
DISEÑAN
SISTEMAS DE
BASES DATOS?

10. BASES DE DATOS: INTRODUCCIÓN
¿PORQUE
SE DISEÑAN
SISTEMAS
DE BASES
DATOS?
PARA GESTIONAR GRANDES VOLUMENES DE
INFORMACIÓN, LA GESTIÓN DE LOS DATOS
IMPLICA:
- LA DEFINICIÓN DE LAS ESTRUCTURAS
PARA ALMACENAR LA INFORMACIÓN
. LA PROVISIÓN DE LOS MECANISMOS PARA
MANIPULAR LA INFORMACIÓN
LOS SISTEMAS DE BASES DE DATOS DEBEN GARANTIZAR
- FIABILIDAD DE LA INFORMACIÓN ALMACENADA
- FIABILIDAD EN LA CONSULTA DE LA INFORMACIÓN

11. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
•
B a n c a . P a r a
información de los
clientes, cuentas y
p r é s t a m o s , y
transacciones bancarias
•Líneas aéreas. Para
r e s e r v a s e
información de
planificación.
•
Recursos humanos.
información de
empleados, salarios,
impuestos y beneficios,
nóminas, etc.
SISTEMAS DE
BASES DATOS
•
Universidades. Para
información de los
estudian-tes,
matrículas de las
asignaturas y cursos
•
•
Transacciones de
tarjetas de crédito. Para
compras con tarjeta de
crédito y generación
mensual de extractos
•
Producción. Para la
gestión de la cadena de
producción:
proveedores, factorías,
inventarios, etc.
•
Comercio en linea.
Para los datos de
venta, seguimiento
de pedidos Web,
etc.
•
Ventas. Para
información de
clientes, productos
y compras
Telecomunicaciones.
Para guardar un registro
de las llamadas
realizadas, generación
mensual de facturas, etc.
Finanzas. Para almacenar
información sobre grandes
empresas, ventas y
compras de documentos
formales financieros

12. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
UN EJEMPLO…

13. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
FIGURA 1.2. EJEMPLO DE ESTRUCTURA DE BASE
DE DATOS Y ALGUNOS DATOS
UN ARCHIVO, ES UNA COLECCIÓN DE REGISTROS
QUE PUEDE O NO ESTAR ORDENADOS…
EJEMPLO DE BASE DE
DATOS QUE ALMACENA
LA INFORMACIÓN DE
ESTUDIANTES Y CURSOS

14. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
DEFINICIÓN
CONSTRUCCIÓN
MANIPULACIÓN
Especificar la estructura de los registros de cada archivo
detallando los diferentes tipos de elementos de datos que
se almacenarán en cada registro
Se realiza almacenando los datos que representan a todos los
estudiantes, cursos, secciones, informes de calificaciones y
prerrequisitos a modo de registro en el archi- vo adecuado.
Los registros de los distintos archivos se pueden relacionar.
Implica la consulta y la actualización de los datos.

15. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
Ejemplos de consultas y/o actualizaciones…
- Recuperar el certificado de estudios (listado de todos los
cursos y calificaciones) de 'Luis'.
- Listado con los nombres de los estudiantes que tomaron la
sección del curso 'Bases de datos' ofrecida en otoño de 2005,
así como sus calificaciones en esa sección.
- Listado de los pre-requisitos del curso 'Bases de datos'. y
estos son algunos ejemplos de actualizaciones:
- Cambiar la clase de 'Luis' a estudiante de segundo año.
- Crear una sección nueva para el curso 'Bases de datos' para
este semestre.
- Introducir una nota 'A' para 'Luis' en la sección 'Bases de
datos' del último semestre.

16. APLICACIONES DE LOS SISTEMAS DE
BASES DE DATOS
Estas consultas y modificaciones informales deben especificarse con exactitud
en el lenguaje de consulta del DBMS antes de poder ser procesadas.
El departamento de Tecnología de la información (TI, Information
Technology) de una entidad (área/empresa) que diseña y mantiene un
sistema de información compuesto por varios computadores, sistemas de
almacenamiento, aplicaciones y bases de datos.
!
El diseño de una aplicación nueva para una base de datos existente o el diseño
de una base de datos nueva empieza con una fase denominada definición
de requisitos y análisis. Estos requisitos son documentados en detalle y
transformados en un diseño conceptual que se puede representar y
manipular mediante algunas herramientas computarizadas, de modo que en
una implementación de base de datos puedan mantenerse, modificarse y
transformarse fácilmente.

17. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
LOS SISTEMAS DE BD SURGIERON EN
RESPUESTA A LOS PRIMEROS MÉTODOS DE
GESTIÓN INFORMATIZADA DE LOS DATOS
COMERCIALES; EJEMPLO, SISTEMAS
BANCARIOS.
!
!
!
LOS SISTEMAS DE PROCESAMIENTO
ARCHIVOS IMPLICA UNA MANERA
GUARDAR LA INFORMACIÓN EN
COMPUTADORA PARA ALMACENARLA
ARCHIVOS DEL SISTEMA OPERATIVO.
DE
DE
LA
EN
!
PA R A P E R M I T I R Q U E L O S U S U A R I O S
MANIPULEN LA INFORMACIÓN, EL SISTEMA
TIENE VARIOS PROGRAMAS DE APLICACIÓN
QUE GESTIONAN LOS ARCHIVOS,
INCLUYENDO PROGRAMAS PARA:
SGBD
Vs.
SISTEMAS DE
PROCESAMIENTO
DE ARCHIVOS
•
Efectuar cargos o abonos
en una cuenta.
•
Añadir una cuenta nueva.
•
Calcular el saldo de una
cuenta.
•
Generar las operaciones
mensuales.

18. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
Mantener información de la organización en un sistema de
procesamiento de archivos tiene una serie de inconvenientes
importantes:
• Redundancia e inconsistencia de datos.
Debido a que los archivos y programas de aplicación son creados por diferentes
programadores en un largo período de tiempo, los diversos archivos tienen
probablemente diferentes formatos y los programas pueden estar escritos en
diferentes lenguajes.
Más aún, la misma información puede estar duplicada en diferentes lugares
(archivos). Por ejemplo, la dirección y número de teléfono de un cliente particular
puede aparecer en un archivo que contenga registros de cuentas de ahorros y en un
archivo que contenga registros de una cuenta corriente. Esta redundancia conduce a
un almacenamiento y coste de acceso más altos. Además, puede conducir a
inconsistencia de datos; es decir, las diversas copias de los mismos datos pueden no
coincidir. Por ejemplo, un cambio en la dirección del cliente puede estar reflejado en
los registros de las cuentas de ahorro pero no estarlo en el resto del sistema.

19. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Dificultad en el acceso a los datos.
Supóngase que uno de los empleados del banco necesita averiguar los nombres de todos
los clientes que viven en el distrito postal 28733 de la ciudad. El empleado pide al
departamento de procesamiento de datos que genere dicha lista. Debido a que esta
petición no fue prevista cuando el sistema original fue diseñado, no hay un programa de
aplicación a mano para satisfacerla. Hay, sin embargo, un programa de aplicación que
genera la lista de todos los clientes. El empleado del banco tiene ahora dos opciones: bien
obtener la lista de todos los clientes y obtener la información que necesita manualmente, o
bien pedir al departamento de procesamiento de datos que haga que un programador de
sistemas escriba el programa de aplicación necesario. Ambas alternativas son obviamente
insatisfactorias. Supóngase que se escribe tal programa y que, varios días más tarde, el
mismo empleado necesita arreglar esa lista para incluir sólo aquellos clientes que tienen
una cuenta con saldo de $10.000 o más. Como se puede esperar, un programa para
generar tal lista no existe. De nuevo, el empleado tiene que elegir entre dos opciones,
ninguna de las cuales es satisfactoria.
La cuestión aquí es que el entorno de procesamiento de archivos convencional no permite
que los datos necesarios sean obtenidos de una forma práctica y eficiente. Se deben
desarrollar sistemas de recuperación de datos más interesantes para un uso general.

20. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Aislamiento de datos
Debido a que los datos
están dispersos en
varios archivos, y los
archivos pueden estar
en diferentes formatos,
es difícil escribir nuevos
programas
de
aplicación para
recuperar los datos
apropiados.
• Problemas de identidad
Los valores de los datos almacenados en
la base de datos deben satisfacer ciertos
tipos de restricciones de consistencia.
Por ejemplo, el saldo de una cuenta
bancaria no puede nunca ser más bajo
de una cantidad predeterminada (por
ejemplo $25. Los desarrolladores hacen
cumplir esas restricciones en el sistema
añadiendo el código apropiado en los
diversos programas de aplicación. Sin
embargo, cuando se añaden nuevas
restricciones, es difícil cambiar los
programas para hacer que se cumplan.
El problema es complicado cuando las
restricciones implican diferentes
elementos de datos de diferentes
archivos.

21. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Anomalias en proceso concurrente
Conforme se ha ido mejorando el conjunto de ejecución de los sistemas y ha sido
posible una respuesta en tiempo más rápida, muchos sistemas han ido permitiendo a
múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno
de interacción de actualizaciones concurrentes puede dar lugar a datos
inconsistentes. Considérese una cuenta bancaria A, que contiene $500. Si dos
clientes retiran fondos (por ejemplo $50 y $100 respectivamente) de la cuenta A en
aproximadamente el mismo tiempo, el resultado de las ejecuciones concurrentes
puede dejar la cuenta en un estado incorrecto (o inconsistente). Supongamos que
los programas se ejecutan para cada retirada y escriben el resultado después. Si los
dos programas funcionan concurrentemente, pueden leer ambos el valor $500, y
escribir después $450 y $400, respectivamente. Dependiendo de cuál escriba el
último valor, la cuenta puede contener bien $450 o bien $400, en lugar del valor
correcto, $350. Para protegerse contra esta posibilidad, el sistema debe mantener
alguna forma de supervisión. Sin embargo, ya que se puede acceder a los datos
desde muchos programas de aplicación diferentes que no han sido previamente
coordinados, la supervisión es difícil de proporcionar.

22. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Problemas de seguridad
No todos los usuarios de un sistema de bases de datos
deberían poder acceder a todos los datos.
Por ejemplo, en un sistema bancario, el personal de nóminas
necesita ver sólo esa parte de la base de datos que tiene
información acerca de varios empleados del banco. No
necesitan acceder a la información acerca de las cuentas de
clientes.
Como los programas de aplicación se añaden al sistema de
una forma ad hoc, es difícil garantizar tales restricciones de
seguridad.

23. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
Estas dificultades, entre otras,
han motivado el desarrollo de
los sistemas de bases de datos.

24. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
Naturaleza autodescriptiva de una SGBD
Una característica fundamental de la metodología de bases
de datos es que el Sistema de BD no sólo contiene la propia
BD, sino también una completa definición o descripción de la
estructura de la BD y sus restricciones.
Esta definición se almacena en el catálogo DBMS, que
contiene información como la estructura de cada archivo, el
tipo y el formato de almacenamiento de cada elemento de
datos, y distintas restricciones de los datos.
La información almacenada en el catálogo se denomina
metadatos y describe la estructura de la base de datos
principal.

25. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
FIGURA 1.2. EJEMPLO DE ESTRUCTURA DE BASE DE DATOS Y ALGUNOS DATOS

26. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
Para el ejemplo de la
Figura 1.2, el catálogo
DBMS almacenará las
definiciones de todos
los
archivos
mostrados. La Figura
1.3 muestra algunas
entradas de ejemplo
en un catálogo de
base de datos. El
diseñador de la BD
especifica estas
definiciones antes de
crear la BD y se
almacenan en el
catálogo.

27. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Independencia programa - datos
En el procesamiento de archivos tradicional, la estructura
de los archivos de datos está incrustada en las
aplicaciones, por lo que los cambios que se introducen
en la estructura de un archivo pueden obligar a realizar
cambios en todos los programas que acceden a ese
archivo.
Por el contrario, los programas que acceden a un DBMS
no necesitan esos cambios en la mayoría de los casos.
La estructura de los archivos de datos se almacena en el
catálogo DBMS, independientemente de los programas
de acceso.

28. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Independencia programa-datos
Ejemplo, un programa de acceso a archivos puede escribirse de
modo que sólo pueda acceder a los registros ESTUDIANTE de la
estructura mostrada en la Figura 1.4 siguiente. Si queremos añadir
otra porción de datos a cada registro ESTUDIANTE, por ejemplo
FechaNac, un programa semejante ya no funcionará y deberá
modificarse. Por el contrario, en un entorno DBMS, sólo tendremos
que cambiar la descripción de los registros ESTUDIANTE en el
catálogo (véase la Figura 1.3) para reflejar la inclusión del nuevo
elemento de datos FechaNac; ningún programa cambia. La
siguiente vez que un programa DBMS haga referencia al catálogo,
se podrá utilizar y acceder a la estructura nueva de los registros
ESTUDIANTE.

29. PROPÓSITO DE LOS SISTEMAS DE BASES
DE DATOS
• Independencia programa-datos

30. VISIÓN DE DATOS…
Nivel de vistas:
El nivel más alto de
abstracción describe sólo parte
de la base de datos completa.
Nivel lógico:
El siguiente nivel más alto de
abstracción describe qué datos
se almacenan en la base de
datos y qué relaciones existen
entre esos datos.
Nivel físico:
El nivel más bajo de
abstracción describe cómo se
almacenan realmente los datos.
En el nivel físico se describen
en detalle las estructu- ras de
datos complejas de bajo nivel

31. VISIÓN DE DATOS…
• Soporte de varias VISTAS de datos
Normalmente una base de datos tiene muchos usuarios, cada uno de los cuales
puede necesitar una pers- pectiva o vista diferente de la base de datos. Una vista
puede ser un subconjunto de la base de datos o puede contener datos virtuales
derivados de los archivos de la base de datos pero que no están explícitamente
almacenados. Algunos usuarios no tienen la necesidad de preocuparse por si los
datos a los que se refieren están almacenados o son derivados.
!
Un DBMS multiusuario cuyos usuarios tienen variedad de diferentes aplicaciones debe ofrecer facilidades para definir varias vistas. Por ejemplo, un usuario de
la base de datos de la Figura 1.2 puede estar interesado únicamente en acceder
e imprimir el certificado de estudios de cada estudiante; la Figura 1.5(a) muestra
la vista para este usuario. Un segundo usuario, que sólo está interesado en
comprobar que los estudiantes cumplen con todos los pre-requisitos de cada
curso para poder registrarse, puede requerir la vista representada en la Figura
1.5(b)

32. VISIÓN DE DATOS…

33. VISIÓN DE DATOS…
Compartición de datos y procesamiento de transacciones multiusuario
Un DBMS multiusuario, como su nombre indica, debe permitir que varios
usuarios puedan acceder a la base de datos al mismo tiempo. Esto es
esencial si los datos destinados a varias aplicaciones serán integrados y
mantenidos en una sola base de datos.
El DBMS debe incluir software de control de la concurrencia para que esos
varios usuarios que intentan actualizar los mismos datos, lo hagan de un
modo controlado para que el resultado de la actualización sea correcto. Por
ejemplo, si varios agentes de viajes intentan reservar un asiento en un vuelo,
el DBMS debe garantizar que en cada momento sólo un agente tiene acceso
a la asignación de ese asiento para un pasajero.
Estos tipos de aplicaciones se denominan, por lo general, aplicaciones de
procesamiento de transacciones en línea (OLTP, online transaction
processing). Un papel fundamental del software DBMS multiusuario es
garantizar que las transacciones concurrentes operan correcta y eficazmente.

34. VISIÓN DE DATOS…
Transacción
El concepto de transacción es cada vez más importante para las aplicaciones
de bases de datos.
Una transacción es un programa en ejecución o proceso que incluye uno o
más accesos a la base de datos, como la lectura o la actualización de los
registros de la misma. Se supone que una transacción ejecuta un acceso
lógicamente correcto a la base de datos si lo ejecutó íntegramente sin
interferencia de otras transacciones.
El DBMS debe implementar varias propiedades de transacción. La propiedad
aislamiento garantiza que parezca que cada transacción se ejecuta de forma
aislada de otras transacciones, aunque puedan estar ejecutándose cientos de
transacciones al mismo tiempo.
La propiedad de atomicidad garantiza que se ejecuten o todas o ninguna de
las operaciones de bases de datos de una transacción.

35. VISIÓN DE DATOS…
Actores de la escena
En el caso de una base de datos personal pequeña,
como una la lista de direcciones, un usuario
normalmente define, construye y manipula la base de
datos, de modo que no se comprometen datos.
!
Sin embargo, en empresas grandes, muchas personas
están implicadas en el diseño, uso y mantenimiento de
una base de datos grande con cientos de usuarios.

36. VISIÓN DE DATOS…
Administradores de la Base de Datos
En cualquier empresa donde muchas personas utilizan los mismo recursos, se
necesita un administrador jefe que supervise y administre esos recursos.
En un entorno de bases de datos, el recurso principal es la base de datos en sí
misma, mientras que el recurso secundario es el DBMS y el software
relacionado.
La administración de estos recursos es responsabilidad del administrador de la
base de datos (DBA, database administrator).
!
El DBA es responsable del acceso autorizado a la base de datos, de la
coordinación y monitorización de su uso, y de adquirir los recursos software y
hardware necesarios. El DBA también es responsable de pro- blemas como las
brechas de seguridad o de unos tiempos de respuesta pobres. En las
empresas grandes, el DBA está asistido por un equipo de personas que llevan
a cabo estas funciones.

37. VISIÓN DE DATOS…
Diseñadores de la Base de Datos
Los diseñadores de las bases de datos son los responsables de identificar los
datos que se almacenarán en la base de datos y de elegir las estructuras
apropiadas para representar y almacenar esos datos.
Estas tareas se acometen principalmente antes de implementar y rellenar la base
de datos.
Es responsabilidad de los diseñadores comunicarse con todos los presuntos
usuarios de la base de datos para conocer sus requisitos, a fin de crear un diseño
que satisfaga sus necesidades.
En muchos casos, los diseñadores forman parte de la plantilla del DBA y se les
pueden asignar otras responsabilidades una vez completado el diseño de la base
de datos. Estos diseñadores normalmente interactúan con los grupos de usuarios
potenciales y desarrollan vistas de la base de datos que satisfacen los requisitos
de datos y procesamiento de esos grupos. Cada vista se analiza después y se
integra con las vistas de los otros grupos de usuarios. El diseño final de la base de
datos debe ser capaz de soportar los requisitos de todos los grupos de usuarios.

38. VISIÓN DE DATOS…
Usuarios Finales
Los usuarios finales son las personas cuyos trabajos requieren acceso a la base de datos para realizar
consultas, actualizaciones e informes. Los usuarios finales se pueden clasificar en varias categorías:
Los usuarios finales casuales acceden
ocasionalmente a la base de datos, pero
pueden necesitar una información diferente
en cada momento. Utilizan un sofisticado
lenguaje de consulta de bases de datos para
especificar sus peticiones y normalmente
son administradores de nivel medio o alto u
otros usuarios interesados.
Los usuarios finales principiantes o
paramétricos constituyen una parte
considerable de los usuarios finales de las
bases de datos. Su labor principal gira entorno
a la consulta y actualización constan- tes de la
base de datos, utilizando tipos de consultas y
actualizaciones estándar
los usuarios finales sofisticados se
encuentran los ingenieros, los científicos,
los analistas comerciales y otros muchos
que están completamente familiarizados
con el DBMS a fin de implementar sus
aplicaciones y satisfacer sus complejos
requisitos.
Los usuarios finales independientes mantienen
bases de datos personales utilizando paquetes
de programas confeccionados que proporcionan
unas interfaces fáciles de usar y basadas en
menús o gráfi- cos. Un ejemplo es el usuario de
un paquete de impuestos que almacena sus
datos financieros personales de cara a la
declaración de la renta.

39. VISIÓN DE DATOS…
Analistas de sistemas y programadores de aplicaciones
(ingenieros de software)
Los analistas de sistemas determinan los requisitos de los
usuarios finales, especialmente de los usuarios finales
principiantes y paramétricos, así como las especificaciones de
desarrollo para las transacciones enlatadas que satisfacen esos
requisitos.
Los programadores de aplicaciones implementan esas
especificaciones como programas; después, verifican, depuran,
documentan y mantienen esas transacciones enlatadas.
Dichos analistas y programadores (normalmente conocidos
como desarrolladores de software o ingenieros de software)
deben familiarizarse con todas las posibilidades proporcionadas
por el DBMS al objeto de desempeñar sus tareas.

40. BASE DATOS…
MODELOS DE
DATOS

41. BASE DATOS…
Bajo la estructura de la base de datos se encuentra
el modelo de datos: una colección de herramientas
conceptuales para describir los datos, las
relaciones, la semántica y las restricciones de
consistencia. Para ilustrar el concepto de un
modelo de datos, describimos dos modelos de
datos en este apartado:
El modelo entidad-relación y el modelo relacional.
Los diferentes modelos de datos que se han
propuesto se clasifican en tres grupos diferentes:
modelos lógicos basados en objetos, modelos
lógicos basados en registros y modelos físicos.
MODELOS DE DATOS

42. BASE DATOS…
MODELO!
ENTIDAD - RELACIÓN!
E-R

43. BASE DATOS…
Está basado en una percepción del mundo real que consta de una colección
de objetos básicos, llamados
entidades,
y de relaciones entre estos
objetos. Una entidad es una «cosa» u «objeto» en el mundo real que es
distinguible de otros objetos. Por ejemplo, cada persona es una entidad, y las
cuentas bancarias pueden ser consideradas entidades.
MODELO
ENTIDAD RELACIÓN
E-R
Las entidades se describen en
una base de datos mediante un
conjunto de
atributos.
Por
ejemplo, los atributos númerocuenta y saldo describen una
cuenta particular de un banco y
pueden ser atributos del conjunto de entidades cuenta.
Análogamente, los atributos
nombre-cliente, calle-cliente y
ciudad-cliente pueden describir
una entidad cliente.

44. BASE DATOS…
Una relación es una asociación entre varias entidades. Por ejemplo, una relación
impositor asocia un cliente con cada cuenta que tiene. El conjunto de todas las entidades
del mismo tipo, y el conjunto de todas las relaciones del mismo tipo, se denominan
respectivamente conjunto de entidades y conjunto de relaciones.
!
La estructura lógica general de una base de datos se puede expresar gráficamente
mediante un diagrama E- R, que consta de los siguientes componentes:
• Rectángulos, que representan conjuntos de entidades.
• Elipses, que representan atributos.
• Rombos, que representan relaciones entre conjuntos de entidades.
• Líneas, que unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con las relaciones.
Cada componente se etiqueta con la entidad o relación que representa.
Como ilustración, considérese parte de una base de datos de un sistema bancario
consistente en clientes y cuentas que tienen esos clientes

45. BASE DATOS…
Lineas
de unión
entidades
relaciones entre
entidades
atributos

46. BASE DATOS…
MODELO!
RELACIONAL

47. BASE DATOS…
MODELO RELACIONAL
En el modelo relacional se
utiliza un grupo de tablas para
representar los datos y las
relaciones entre ellos. Cada
tabla está compuesta por varias
columnas, y cada columna tiene
un nombre único. En la sig. Fig.
se presenta un ejemplo de base
de datos relacional consistente
en tres tablas: la primera
muestra los clientes de un
banco, la segunda, las cuentas,
y la tercera, las cuentas que
pertenecen a cada cliente.

48. BASE DATOS…
MODELO RELACIONAL
El modelo de datos relacional es el modelo de datos más
ampliamente usado, y una amplia mayoría de sistemas de
bases de datos actuales se basan en el modelo relacional.
!
El modelo relacional se encuentra a un nivel de abstracción
inferior al modelo de datos E-R. Los diseños de bases de datos
a menudo se realizan en el modelo E-R, y después se traducen
al modelo relacional;

49. BASE DATOS…
LENGUAJES DE
BASES DE DATOS

50. LENGUAJES DE BASES DE DATOS
Un sistema de bases de datos
p ro p o rc i o n a u n l e n g u a j e d e
definición de datos para especificar
el esquema de la base de datos y
un lenguaje de manipulación de
datos para expresar las consultas a
la base de datos y las modificaciones. En la práctica, los lenguajes
de definición y manipulación de
d at o s n o s o n d o s l e n g u a j e s
separados; en su lugar
simplemente forman partes de un
único lenguaje de bases de datos,
tal como SQL, ampliamente usado
SQL !
!
STRUCTURE
QUERY
LANGUAGE

51. BASE DATOS…
Lenguaje de definición de datos (LDD).
Un esquema de base de datos
se especifica mediante un
conjunto de definiciones
expresadas mediante un
lenguaje especial llamado
lenguaje de definición de datos
(LDD).
La ejecución de la instrucción LDD anterior crea la tabla cuenta.
Además, actualiza un conjunto especial de tablas denominado
diccionario de datos o directorio de datos.

52. BASE DATOS…
Un diccionario de
datos contiene
metadatos, es decir,
datos acerca de los
datos. El esquema
de una tabla es un
ejemplo
de
metadatos. Un
sistema de base de
datos consulta el
diccionario de datos
antes de leer o
modificar los datos
reales.

53. BASE DATOS…
Lenguaje de manipulación de datos (LDD).
La manipulación de datos es:
• La recuperación de información almacenada en la base de datos.
• La inserción de información nueva en la base de datos.
• El borrado de información de la base de datos.
• La modificación de información almacenada en la base de datos.
Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios
acceder o manipular los datos organizados mediante el modelo de datos apropiado.
Hay dos tipos básicamente:
• LMDs procedimentales. Requieren que el usua- rio especifique qué datos se
necesitan y cómo obte- ner esos datos.
• LMDs declarativos (también conocidos como LMDs no procedimentales).
Requieren que el usuario especifique qué datos se necesitan sin espe- cificar
cómo obtener esos datos.

54. BASE DATOS…
CONSULTA
Una consulta es una instrucción de solicitud para recuperar
información. La parte de un LMD que implica recuperación de
información se llama lenguaje de consultas. Aunque técnicamente
sea incorrecto, en la práctica se usan los términos lenguaje de
consultas y lenguaje de manipulación de datos como sinónimos.

55. BASE DATOS…
La consulta especifica que las
filas de (from) la tabla cliente
donde (where) el id-cliente es
19 283 746 se debe recuperar,
y que se debe mostrar el
atributo nombre- cliente de
estas filas. Si se ejecutase la
consulta con la tabla de la sig.
Figura, se mostraría el nombre
González.

56. BASE DATOS…
Si la consulta anterior se ejecutase
con las tablas de la Figura sig., el
sistema encontraría que las dos
cuentas denominadas C-101 y C-201
pertenecen al cliente 19 283 746 e
imprimiría los saldos de las dos
cuentas, es decir, $500 y $900 .