Está en la página 1de 36

“Universidad Tecnológica de Xicotepec de Juárez”

“Base de Datos para Aplicaciones”

8° “A”

M.I.E. Héctor Valderrábano González


Integrantes:
Jaziel Cazares Aranda
Gustavo de Jesús León Santos
Libni Heldai Mendoza Paleta
Efrén David Hernández Rodríguez

Índice.

Capítulo 1 Problemática - Base de datos.


Introducción --------------------------------------------------------------------------------------- 3
Planteamiento del problema ----------------------------------------------------------------- 4

Pág. 1
¿Qué es una consulta? ------------------------------------------------------------------------- 5
Consultas en nuestra base de datos -------------------------------------------------------- 5
¿Qué es una subconsulta? -------------------------------------------------------------------- 8
Subconsultas en nuestra base de datos -------------------------------------------------- 9
¿Qué es una vista? ----------------------------------------------------------------------------- 10
Vistas en nuestra base de datos ------------------------------------------------------------ 11
Sintaxis Liga remota ---------------------------------------------------------------------------- 12
Sinónimos ----------------------------------------------------------------------------------------- 12
Modelo Relacional ------------------------------------------------------------------------------ 13
Justificación --------------------------------------------------------------------------------------- 14

Capitulo 2 Bases de datos Distribuidas.


Introducción -------------------------------------------------------------------------------- 15
¿Qué es una base de datos distribuida? -------------------------------------------- 15
¿Por qué nuestra base de datos puede ser distribuida? ----------------------- 15
Ventajas y Desventajas -------------------------------------------------------------------16
Reglas de operación ---------------------------------------------------------------------- 16
Conclusiones --------------------------------------------------------------------------------16

Capitulo 3 Transacciones en Bases de


Datos.
Introducción ------------------------------------------------------------------------- 19
¿Qué son las transacciones? --------------------------------------------------- 19
Para que sirven las transacciones --------------------------------------------- 19
Comandos para una transacción (concurrencia) ------------------------- 20
Evidencia ----------------------------------------------------------------------------- 21
Copias de seguridad ---------------------------------------------------------------21
Bloqueo de tablas ---------------------------------------------------------------22

Capítulo 4 Bases de Datos orientada a


objetos.
Introducción ------------------------------------------------------------------------- 29
¿Qué es una base de datos orientada a objetos? ------------------------ 29
Estructura de una base de datos orientada a objetos ------------------- 30
Diseño de BDOO ---------------------------------------------------------------------------------- 31
 Modelo Entidad Relación
 Modelo Relacional
 Modelo UML

Pág. 2
Implementación de Gestor de base de datos ------------------------------ 34

Conclusión --------------------------------------------------------------------------- 36

Introducción.

Las bases de datos son un elemento fundamental en el entorno informático hoy en


día y tienen aplicación en la práctica totalidad de campos. Concebidas con un
propósito general, son de utilidad para toda disciplina o área de aplicación en la
que exista una necesidad de gestionar datos, tanto más cuanto más voluminosos
sean estos. En nuestro ámbito particular de los SIG, los datos son cada día más
voluminosos, debido no solo a una mayor cantidad de información, sino también a

Pág. 3
una mayor precisión en esta, la cual implica un mayor volumen de datos. Además,
presentan otra serie de características, haciendo todas ellas que sea
recomendable el uso de bases de datos y tecnologías específicas para su manejo.

Planteamiento del problema.


Durante un tiempo, las pequeñas ligas de futbol que no son reconocidas a nivel
estatal o municipal, se caracterizan por el hecho de que todos los datos de la
misma sean hechos en papel. Al no ser un evento muy importante, se piensa que
todos los datos pueden ser manejado por una sola persona sin error alguno, datos
como anotaciones, faltas, cambios, información relacionada a los equipos, árbitros
y jugadores, así como los partidos y tablas de posiciones, a todo esto, hay que
sumarle el trabajo hecho a mano con lápiz y papel, este es muy tardado e

Pág. 4
inseguro, dificultando así la obtención de datos en tiempo real que tanto se
necesitan en lugares como estos.

¿Qué es una consulta?

En base de datos, una consulta es el método para acceder a los datos dentro de
una base de datos o un gestor de datos.
Con las consultas se pueden modificar, borrar, obtener y agregar datos en una
base de datos, para esto se utiliza el lenguaje de consultas uno de estos es SQL.

Pág. 5
Técnicamente hablando, las consultas a una base de datos se realizan a través de
un lenguaje de manipulación de datos (DML – Data Manipulation Language).
Por lo tanto SQL es un lenguaje DML, pero además posee otras características de
otros lenguajes; por ejemplo, permite también crear bases de datos.
SQL es un poderoso lenguaje capaz de avanzadas consultas.

Sintaxis de una consulta.


SELECT campo1, campo2… * FROM tabla1, tabla2...

Consultas en nuestra base de datos.

Pág. 6
Pág. 7
Pág. 8
¿Qué es una subconsulta?

Una subconsulta es una consulta anidada en una


instrucción SELECT, INSERT, UPDATE o DELETE, o bien en otra
subconsulta. Las subconsultas se pueden utilizar en cualquier parte en la que se
permita una expresión. En este ejemplo, se utiliza una subconsulta como una
expresión de columna llamada MaxUnitPrice en una instrucción SELECT.
Se llama también subconsulta a una consulta o selección interna, mientras que la
instrucción que contiene una subconsulta también es conocida como consulta o
selección externa.
Una subconsulta anidada en la instrucción externa SELECT tiene los
componentes siguientes:
 Una consulta SELECT normal, que incluye los componentes normales de la
lista de selección.
 Una cláusula normal FROM que incluye uno o varios nombres de tablas o
vistas.
 Una cláusula opcional WHERE.
 Una cláusula opcional GROUP BY.
 Una cláusula opcional HAVING.

Sintaxis de una subconsulta

SELECT Name
FROM Camp…
WHERE ListPrice =
(SELECT ListPrice
FROM Production.Product
WHERE Name = 'Chainring Bolts');

Pág. 9
Subconsultas en nuestra base de datos

Pág. 10
¿Qué es una vista?

Una vista de base de datos es un subconjunto de una base de datos y se basa en


una consulta que se ejecuta en una o más tablas de base de datos. Las vistas de
base de datos se guardan en la base de datos como consultas con nombre y se
pueden utilizar para guardar consultas completas que se utilizan con frecuencia.
Hay dos tipos de vistas de base de datos: vistas dinámicas y vistas estáticas. Las
vistas dinámicas pueden contener datos de una o dos tablas e incluir
automáticamente todas las columnas de la tabla o tablas especificadas. Las vistas
dinámicas se pueden actualizar dinámicamente cuando se crean o modifican
objetos relacionados u objetos ampliados. Las vistas estáticas pueden contener
datos de varias tablas y las columnas necesarias de estas tablas se deben
especificar en las cláusulas SELECT y WHERE de la vista estática. Las vistas
dinámicas se pueden actualizar manualmente cuando se crean o modifican
objetos relacionados u objetos ampliados.

Sintaxis de una vista.


CREATE VIEW HumanResources.EmployeeHireDate
AS
SELECT p.FirstName, p.LastName, e. HireDate
FROM HumanResources.Employee AS e JOIN Person.Person AS p
ON e.BusinessEntityID = p.BusinessEntityID ;

Pág. 11
Vistas en nuestra base de datos.

Pág. 12
Sintaxis liga remota.

#mysql -u root -p
Mysql > USE “nombre de base de datos”;
Mysql > update db set Host = “xxx.xxx.xxx.xxx” where db = ”nombre de base de
datos”;
Mysql> update user ser Host = “xxx.xxx.xxx.xxx” where user = “base de datos”;

Sinónimos.

Un sinónimo es un objeto de base de datos que sirve para los siguientes objetivos:
Proporciona un nombre alternativo para otro objeto de base de datos, denominado
objeto base, que puede existir en un servidor local o remoto.
Proporciona una capa de abstracción que protege una aplicación cliente de
cambios realizados en el nombre o la ubicación del objeto base.

Pág. 13
Modelo Relacional.

Pág. 14
Justificación
¿Por qué desarrollar una aplicación web para esto? Desarrollar una aplicación
web enlazada a una base de datos que capture datos de partidos, equipos,
jugadores, árbitros y pagos. Con la finalidad de hacer que haya menos errores a la
hora de obtener tablas de posiciones, porcentajes de goleo, faltas y asistencias.
Facilitando el acceso por parte de los directores técnicos a las estadísticas
correspondientes. Este proyecto se pretende implementar en la comunidad
futbolera de pequeños municipios, aligerando la carga para los encargados y
haciendo que obtengan un flujo de datos mucho más rápido de lo que es ahora.
Tomando en cuenta que ahora la mayoría de la gente utiliza la internet para
muchas cosas, entre ellas pasatiempos como el futbol, es que podemos obtener
buenos resultados con esta aplicación, tales como, mayor reconocimiento de la
liga de futbol, mejor calidad en presentación de resultados, etc.
Desarrollar una aplicación web basada en JSP’s (Java Server Pages) y Java
Servlets que se encargue de manejar los datos referentes a las estadísticas de
una liga de futbol, así mismo, este sistema realizará búsqueda, inserción,
actualización y eliminación de datos, todo esto, con la finalidad de hacer más
rápido y eficaz el proceso de registro de usuarios, equipos y jugadores. Este
sistema contará con un Login para restricción de permisos de los usuarios para
poder
La implementación de esta aplicación reducirá el tiempo de espera en para la
publicación de resultados de la jornada ya que este los usuarios no tendrán que
estar físicamente en un partido o una junta previa a los partidos para visualizar
toda su información, esto dará como resultado una mejor atención por parte del
funcionario a cargo de la liga de futbol, resolviendo así esta problemática.

Pág. 15
Capítulo 2: Bases de datos distribuidas.
Introducción
Una base de datos distribuida es una colección de múltiples bases de datos
interconectadas, que se extienden físicamente a través de varias ubicaciones que
se comunican a través de una red informática.

¿Qué es una base de datos distribuida?


Una Base de Datos Distribuida (BDD) es, una base de datos construida sobre una
red de computadores. La información que estructura la base de datos esta
almacenada en diferentes sitios en la red, y los diferentes sistemas de información
que las utilizan accedan datos en distintas posiciones geográficas.
Por ende, una Base de Datos Distribuida es una colección de datos que
pertenecen lógicamente a un solo sistema, pero se encuentra físicamente
distribuido en varios computadores o servidores de datos en una red de
computadoras. Un sistema de bases de datos distribuidas se compone de un
conjunto de sitios lógicos, conectados entre sí, mediante algún tipo de red de
comunicaciones.

¿Por qué nuestra base de datos puede ser


distribuida?
La base de datos puede ser distribuida debido a la cantidad de peticiones que
podría tener la aplicación debido al número de usuarios que podrían registrarse y
hacer cambios en la misma de una forma simultánea, con esto evitamos que la
base de datos caiga por completo y en caso de haber algún problema con la base
de datos se recuperarían toda la información de manera eficaz y rápida, ya que
solo seria de cada nodo y no es necesario el reinicio del sistema.
Un ejemplo seria la tabla llamada tb_equipo ya que esta podría ser distribuida
entre categorías, es decir que cada categoría de un torneo tiene su propia
distribución y en ella se guardan réplicas de información de los equipos

Pág. 16
Ventajas:
 Poca perdida de información
 Acceso simultaneo para los usuarios
 Seguridad de información
 Copias de seguridad exactas
 Menor Probabilidad de fallos en consultas
 El precio es razonable al usuario
 Los datos se pueden colocar físicamente
 Mueve dato con facilidad entre memorias volátiles y no volátiles

Desventajas:
 Mayor tiempo de espera de respuesta
 Redundancia de datos
 Datos basura
 Mayor costo y no beneficiario económicamente para el usuario.
 Mayor tiempo de mantenimiento
 Que los usuarios tengan control local sobre la información
 Fallos de los nodos
 Fallo de las conexiones en comunicaciones

Reglas de operación:
1. Autonomía local
2. No dependencia de un sitio central
3. Operación continua
4. Independencia con respecto a la localización
5. Independencia con respecto a la fragmentación.
6. Independencia de réplica.
7. Procesamiento distribuido de consultas.
8. Manejo distribuido de transacciones.
9. Independencia con respecto al equipo.
10. Independencia con respecto al sistema operativo
11. Independencia con respecto a la red.
12. Independencia con respecto al DBMS.

Pág. 17
Conclusión
Es una de las mejores opciones que se podrían tomas para que el usuario no
tenga problemas mayores cuando de alguna u otra forma se caiga la base y esta
solo sea una parte de ella.

Jaziel
Las bases de datos son un buen recurso para las empresas que tienen varios
usuarios en diferentes lugares, es una opción que debe ser considerado por todas
aquellas.

Libni
Este tipo de bases tiene la ventaja de mantenerse un poco más segura cuando se
cae una parte de algún o de algún usuario esta no falla al 100%, se mantiene
arriba algún porcentaje.

Efrén
Es una forma de seguridad para usuarios con bastantes datos y tenga enemigos
que quisieran tirar su servicio o en este caso sus datos.

Pág. 18
Gustavo
La construcción de base de datos distribuido es una buena ruta hoy en día ya que
en muchas empresas o usuarios que ofrecen algún servicio lo toman mucho en
cuenta para sus trabajos.

José Luis
La implementación de esta herramienta de forma correcta es una gran ventaja en
los clientes que tienen varias sucursales y suelen almacenar los datos de los que
compran o usan sus servicios, esto para asegurar que sus datos estén protegidos
ante alguna caída de la base e implique una perdida masiva.

Pág. 19
Capitulo 3: Transacciones en Bases de Datos.
Introducción.
Se llama Transacción a una colección de operaciones que forman una unidad
lógica de trabajo. Una Transacción es una unidad de la ejecución de un programa
que accede y, posiblemente, actualiza varios elementos de datos.
Una Transacción está delimitada por instrucciones de inicio transacción y fin
transacción (la transacción consiste en todas las operaciones que se ejecutan
entre inicio transacción y fin transacción).

¿Qué son las transacciones?


Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un
programa de aplicación, que acceden o cambian el contenido de la base de datos.
Existen 3 tipos de transacciones:
1. Transacciones de Recuperación: se accede a los datos para visualizar en
la pantalla a modo de informe.
2. Transacciones de actualización: se insertan, borran o actualizan daros de
la base de datos.
3. Transacciones mixtas: Se mezclan operaciones de recuperación y de
actualización.

¿Para qué sirven las transacciones?


las transacciones base de datos delimitan un conjunto de operaciones de base de
datos, que son procesadas como un todo, de forma que las operaciones que están
incluidas dentro de esas transacciones base de datos se validan (commit) o se
cancelan (rollback) como una única operación.

Pág. 20
Comandos para una transacción.
START TRANSACTION:
START transaction [nombre]

Update producto
Set prod_qoh=prod_qoh-100
Where prod_code=’x’;
Update acct_receibable
Set acc_balance=acc_balance+500
Where acc_num=’y’

COMMIT:
Update producto
Set prod_qoh=prod_qoh-100
Where prod_code=’x’;
Update acct_receibable
Set acc_balance=acc_balance+500
Where acc_num=’y’
Commit;
ROLLBACK:
Begin transaction T;
Update pedidos Set num_pedido=num_pedido+1;
Rollback transaction T;

Pág. 21
Evidencias:
Ejemplo:
Para el siguiente ejemplo fue utilizada la base de datos que se ha creado
anteriormente.
Para verificar los resultados, se hace una consulta de la tabla tb_personas en la
cual se aprecian solo 3 registros antes de iniciar la transacción. (SELECT * FROM
tb_personas;)

Iniciamos la transacción para agregar una nueva persona a la base de datos, esto
se hace con el comando BEGIN que significa que la transacción fue iniciada.

En la imagen anterior también se aprecia el comando para insertar un registro en


la base de datos, INSERT INTO.
Al momento de ejecutar los primeros 2 comando, se muestra el siguiente resultset
en la interfaz gráfica de MySQL, WORKBENCH.

Una vez ejecutados ambos comandos, volvemos a consultar la tabla tb_personas


para asegurarnos de que se llevó a cabo correctamente el llenado de datos.

Los datos se han grabado correctamente, sin embargo, esto solo sucede en la
conexión actual, es decir, en esta conexión que estamos trabajando, ya que, si
hacemos una segunda conexión y hacemos la misma consulta, los datos no se
muestran en la segunda conexión.

Pág. 22
Como se puede observar en la imagen anterior, no aparecen los datos del
comando INSERT que llevemos a cabo anteriormente.
Antes de grabar los datos definitivamente en la base de datos, se debe tomar en
cuenta que se debe hacer en caso de que no se deban guardar cambios. Para
esto, usaremos el comando ROLLBACK, que se muestra en la primera imagen y
con el cual devolveremos la base de datos de la primera conexión a su estado
original.

Se hace la consulta en la primera conexión y devuelve los datos tal y como


estaban antes de ejecutar el comando INSERT.

Una vez explicado esto, pasamos al comando COMMIT, este es usado para
escribir los datos definitivamente y así poder verlos aun desde otras conexiones
distintas a la que se trabaja actualmente.
Una vez ejecutado el comando, podemos ir a la segunda conexión a verificar que
los datos han sido grabados correctamente y con ello dar por terminada una
transacción exitosa.

Pág. 23
Copia de seguridad
BACKUPS FÍSICOS
Los backups físicos son aquellos que copian físicamente los ficheros de la BD.
Existen dos opciones: en frío y en caliente. Se dice que el backup es en frio
cuando los ficheros se copian cuando la BD está parada. En caliente es cuando se
copian los ficheros con la BD abierta y funcionando.
Backup en Frío
El primer paso es parar la BD en un estado consistente, es decir, una parada
normal del servidor. Después se copian los ficheros de datos.
Una buena idea es automatizar todo este proceso con los scripts
correspondientes, de modo que no nos olvidemos de copiar ningún fichero.
Como este tipo de backup es una copia de los ficheros de la BD, si estos
contienen algún tipo de corrupción, la traspasaremos a la copia de seguridad sin
detectarla. Por esto es importante comprobar las copias de seguridad.
Ventajas:
 Mas rápido que los backups lógicos
 Menos probabilidades de inconsistencias
Desventajas:
 El servidor no estará disponible temporalmente
Backup en Caliente
Si la BD requiere disponibilidad 24×7, no se pueden realizar backups en frío. Para
efectuar un backup en caliente debemos trabajar con la BD en modo online
(funcionamiento normal). El procedimiento de backup en caliente es bastante
parecido al frío. Pero para evitar inconsistencias en la base de datos es
recomendable bloquear las actualizaciones e inserciones.
Así como el backup en frio permitía realizar una copia de toda la BD sin parar el
servidor.
Ventajas:
 Mas rápido que los backups lógicos
 La base de datos esta disponible
Desventajas:

Pág. 24
 Alta probabilidad de inconsistencias si no se controla
 
BACKUPS LÓGICOS
Este tipo de backups se realizan con el servidor en funcionamiento, copian el
contenido de la BD pero sin almacenar la posición física de los datos. Se realizan
con alguna herramienta que copia los datos y la definición de la BD en un fichero.
Durante el proceso no se deberán realizar actualizaciones ni inserciones puesto
que daría lugar a inconsistencias en la base de datos.
Ventajas:
 La base de datos esta disponible
 Los backups son portables
Desventajas:
 Lentitud
 Alta probabilidad de inconsistencias si no se controla
En esta parte vamos a mostrar varias formas de hacer una copia de seguridad de
una o varias bases de datos en MySQL
Backup en Caliente
Usaremos el comando “mysqldump” que se creo al instalar MySQL, por lo que si
se instaló correctamente, deberíamos tenerlo.
Además, aprovechando que tenemos una herramienta gráfica para gestionar
MySQL (MySQL Workbench) realizaremos copias de seguridad con ella.
Backup en Frío
Usaremos comandos comunes de Linux como “cp”, “rm”, “mkdir”…
 
COPIA LOGICA EN CALIENTE
MYSQLDUMP
Primero comprobamos que tenemos “mysqldump” correctamente instalado
consultando la versión
mysqldump –version
Si se produce un error puede que MySQL no este bien instalado o que tengamos
que poner la ruta completa

Pág. 25
/usr/local/mysql/bin/mysqldump –version
El usuario que usemos para realizar la copia de seguridad debe tener permisos
de:
 SELECT sobre las tablas de la base de datos
Ahora para realizar una copia de seguridad básica ejecutaremos lo siguiente:
mysqldump –u usuario -p nombre_bbdd > nombre_fichero.sql
En nuestro caso:

Introducimos la contraseña y se creara el fichero .sql con todas las sentencias


para poder replicar la base de datos.
Para recuperar/importar la base de datos introduciremos el mismo comando pero
cambiando la redirección:
mysqldump –u usuario -p nombre_bbdd < nombre_fichero.sql
En nuestro caso:

Y al introducir la contraseña se empiezan a ejecutar todas las sentencias, por


motivos de seguridad pregunta si existe lo que va a crear, si existe lo borra, y sino
lo crea, así no habrá problemas si ya tenemos la base de datos creada.
Para realizar una copia de varias bases de datos el proceso seria igual, solo
cambiaría algo en la sintaxis.
Copia de seguridad de varias bases de datos:
mysqldump –u usuario -p -B nombre_bbdd-1 nombre_bbdd-2 nombre_bbdd-
3 > nombre_fichero.sql
Para importar la copia de varias bases de datos:
mysqldump –u usuario -p -B nombre_bbdd-1 nombre_bbdd-2 nombre_bbdd-
3 < nombre_fichero.sql
Copia de seguridad de todas las bases de datos:
mysqldump –u usuario -p -A > nombre_fichero.sql
Para importar la copia de todas las bases de datos:
mysqldump –u usuario -p -A < nombre_fichero.sql

Pág. 26
Script:
mysqldump -u root -p bd_futbol > “C:/Users/Jaziel/Desktop/CP/CP_futbol.sql
mysqldump -u root -p bd_futbol < “C:/Users/Jaziel/Desktop/CP/CP_futbol.sql

Bloqueo de tablas:
Script:
SET autocommit=0;
START TRANSACTION;
lock tables tb_personas write;
insert into tb_personas values(default, 'Jaziel', 'Cazarez, 'Perez',
'jaziel@gmail.com', 'M', 'Mexico', 'Administrador');
SELECT id into @id FROM tb_personas ORDER BY id DESC LIMIT 1;
commit;
unlock tables;

Explicación:
Para hacer una consulta de transacción con bloqueo, es necesario colocar desde
un inicio el comando SET autocommit=0 debido a que provocará que todas las
tablas dentro de la relación sean bloqueadas y no se puedan modificar al ejecutar
la transacción, al iniciar se deberá colocar el comando lock tables tb_personas
write;Esto permitirá únicamente insertar los datos en los campos de esas únicas
dos tablas mientras que las demás ya fueron bloqueadas. Se coloca dentro de la
consulta los datos a insertar dentro de las tablas, al terminar se colocará el
comando commit que confirmará la ejecución de la transacción, una vez realizado
todo, el comando unlock tables volverá a bloquear las dos tablas para que no se
pueda realizar ninguna otra transacción. Esto es un gran beneficio porque
relaciona los datos de dos tablas bloqueando las demás para así insertar datos de
forma segura sin afectar a tablas externas, logrando una mejor calidad de servicio
y coordinación dentro de la base datos dando positivo en los resultados.

Pág. 27
Pág. 28
Capítulo 3: Transacciones en Bases de Datos.
Introducción.
Los modelos de bases de datos tradicionales presentan deficiencias en
cuento a aplicaciones más complejas o sofisticadas. Además, son difíciles de
utilizar cuando las aplicaciones que acceden a ellas están escritas en un
lenguaje de programación orientado a objetos.

La orientación a objetos ofrece flexibilidad, no está limitada por los tipos


de datos y los lenguajes de consulta de los sistemas de bases de datos
tradicionales. La característica clave es la potencia que proporcionan al
diseñador al permitirle especificar tanto la estructura de objetos complejos,
como las operaciones que se pueden aplicar sobre dichos objetos.

Las BDOO se han diseñado para que se puedan integrar directamente


con aplicaciones desarrolladas con lenguajes orientados a objetos. También
están diseñadas para simplificar la POO. Almacenan los objetos en la BD con
las mismas estructuras y relaciones que los lenguajes de POO.
Una SGBDOO es una SGBD que almacena objetos incorporando así
todas las ventajas de la OO. Pueden tratar directamente con objetos, no
teniendo que hacer la traducción a tablas o registros. Sus objetos se
conservan, pueden ser gestionados, aunque su tamaño sea grande, pueden ser
compartidos entre múltiples usuarios y mantienen su integridad como sus
relaciones.

¿Qué es una base de datos orientada a


objetos?

Una base de datos orientada a objetos es una base de datos que incorpora a
todos los conceptos importantes del paradigma de objetos:

 Encapsulación: Propiedad que permite ocultar la información al resto de


los objetos, impidiendo así accesos incorrectos o conflictos.
 Herencia: Propiedad a través de la cual los objetos heredan
comportamiento dentro de una jerarquía de clases.
 Polimorfismo: Propiedad de una operación mediante la cual ser aplicada a
distintos tipos de objetos.

Pág. 29
Estructura de una base de datos orientada a
objetos.

El paradigma orientado a objetos se basa en el encapsulamiento de datos y del


código relacionado con cada objeto en una sola unidad. Conceptualmente, todas
las interacciones entre cada objeto y el resto del sistema se realizan mediante
mensajes. Por lo tanto, la interfaz entre cada objeto y el resto del sistema se
define mediante un conjunto de mensajes permitidos.

a) Identidad de objetos
a. Un sistema de BDOO provee una identidad única a cada objeto
independiente almacenado en la base de datos. Esta identidad única
suele implementarse con un identificador de objeto único, generado
por el sistema.
b) Constructores de tipos
a. En las BDOO, los valores (o estados) de los objetos complejos se
pueden construir a partir de otros objetos mediante ciertos
constructores de tipos. Una forma de representar tales objetos es
considerar a cada objeto como tripleta (i, c, v), donde i es un
identificador de objeto único (el OID), c es un constructor (esto es,
una indicación de cómo se construye el valor del objeto) y v es el
valor (o estado) del objeto. Puede haber varios constructores, según
el modelo de datos y el sistema OO.
c) Encapsulamiento
a. Tanto la estructura de los objetos como las operaciones que se
pueden aplicar a ellos se incluyen en las definiciones de clases de
los objetos.
d) Compatibilidad con lenguajes de programación
a. Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-
Relación para modelar los datos y luego se convierten de manera
manual en un conjunto de relaciones; por lo tanto, los conceptos de
la Programación Orientada a Objetos se utilizan simplemente como
herramientas de diseño y se codifican, utilizándose para trabajar con
una base de datos.
e) Jerarquía de tipos y herencia
a. Los esquemas de BDOO suelen necesitar un gran número de clases.
Sin embargo, varias clases son parecidas entre sí.
b. Para permitir la representación directa de parecidos entre las clases,
hay que ubicarlas en una jerarquía de especializaciones. El concepto
de jerarquía de clases es parecido al de especialización del modelo

Pág. 30
E-R. Las especializaciones de las clases son denominadas
subclases; lo cual especifica atributos y métodos adicionales para
una clase existente. Los objetos creados por medio de unas
subclases heredan todos los atributos y métodos de la clase padre.
Algunas de estas características heredadas pueden ellas mismas
haber sido heredadas de clases más altas en la jerarquía.
f) Manejo de objetos complejos
a. Los objetos se consideran complejos porque requieren un área de
almacenamiento sustancial y no forman parte de los tipos de datos
estándar que suelen ofrecer los SGBD. Puesto que el tamaño de los
objetos es considerable, un SGBD podría obtener una porción del
objeto y proporcionarla al programa de aplicación antes de obtener
todo el objeto. El SGBD podría también usar técnicas de
almacenamiento intermedio y caché para obtener por anticipado
porciones del objeto, antes de que el programa de aplicación
necesite tener acceso a ellas.
g) Polimorfismo
a. El polimorfismo se refiere al uso de la misma firma de mensaje para
dirigir diferentes métodos en diferentes clases. Cuando el diseñador
envía una señal a un objeto, el método de la clase de objeto,
posiblemente heredado, procesa la señal.
b. Un método puede tener acceso directamente a atributos de un objeto
destino por no nombre, al incluir cualesquiera atributos heredados de
clases padres, pero debe tener acceso a atributos de otros objetos
con señales secundarias.

Pág. 31
Diseño de BDOO
Modelo Entidad Relación

Pág. 32
Modelo Entidad Relación

Pág. 33
Modelo UML

Implementación de gestor de BD

API de reflexión de Java.


La reflexión es una característica de algunos lenguajes de programación que
permite acceder, en tiempo de ejecución, a sus componentes de alto nivel como
clases, atributos o métodos. Dado que nuestra librería trabaja con objetos que
pueden ser instancias de cualquier clase, hemos de saber a qué clase concreta
pertenece cada objeto para poder determinar qué atributos tiene cada uno para
guardarlo en la base de datos. Del mismo modo, también se necesita reflexión
para poder reconstruir un objeto a partir su información en la base de datos. En
nuestro proyecto, las principales clases relacionadas con la reflexión de Java que
hemos utilizado han sido la clase Class y la clase Field. La clase Class representa
la clase a la que pertenece una instancia de un objeto. Mediante los métodos
getName() y getFields() hemos podido acceder al nombre de la clase y a sus
campos. La clase Field representa cada uno de los campos pertenecientes a una
clase de Java. Permite acceder a su nombre mediante el método getName(), a su
clase usando el método getType(), a su valor asociado en una instancia del objeto
a través del método get(Object obj) y modificar su valor en una instancia del objeto
mediante set(Object obj, Object value). Supongamos una instancia de una clase
Pág. 34
denominada Prueba, incluida en el paquete ucm.fdi, que contiene dos atributos: str
de tipo String y num de tipo int (Diagrama de clases: Figura 3.1). Esta instancia se
ha creado con nombre prueba y con los valores “cadena” para str y 1 para num.

Si utilizamos el método getClass() de nuestra instancia obtendremos un objeto de


tipo Class que contendrá la clase asociada a la instancia prueba. Este objeto lo
asociamos a la variable clasePrueba. Sobre esta nueva variable podemos ejecutar
los métodos nombrados anteriormente de la clase Class. Si ejecutamos el método
getName() obtendremos un String que contendrá “ucm.fdi.Prueba” y si ejecutamos
el método getFields() obtendremos un array de atributos de tipo Field con dos
posiciones que corresponden a las variables str y num, en ese orden. Si
recorremos este array podremos acceder a los campos y obtener su valor,
modificarlo u obtener su tipo. Por ejemplo, si para la posición [0] del array, que
corresponde a la variable de tipo String, ejecutamos el método
getName()obtendremos “str”, y si ejecutamos el método getClass() obtendremos
un objeto de tipo Class que corresponde a la clase String. Si queremos obtener el
valor asociado a ese campo tendremos que especificar para qué instancia
queremos obtener dicho valor (en nuestro caso el objeto prueba) dentro del
método get de la forma getFields()[0].get(prueba). Con esto, obtendremos el valor
de nuestro campo str que, como se especificó anteriormente, es “cadena”. Para
modificar el valor, al igual que para obtenerlo, hay que especificar el objeto del que
se quiere modificar, además del nuevo valor, utilizando el método set de la forma
getFields()[0].set(prueba,”cadena2”). Después de esto, si ahora obtenemos el
valor del campo str el resultado será “cadena2”, en vez que cadena, como
obtuvimos anteriormente.

Pág. 35
Conclusión Jaziel.

Pág. 36

También podría gustarte