Manual
Manual
Manual
INGENIERÍA INFORMÁTICA
CONCEPTO PÁGINAS
PRESENTACIÓN.................................................................................................................... 3
OBJETIVO GENERAL............................................................................................................ 3
SEGURIDAD........................................................................................................................... 3
La información ha pasado a ser considerada un recurso fundamental de toda organización. Por un lado,
encontramos que los usuarios cada vez demandan sistemas más flexibles y eficientes lo que obliga a poner
mayor atención en los datos y su estructura; por otro lado, los diseñadores de sistemas de información se han
convencido de la trascendencia que tiene la gestión de los datos para conseguir un desarrollo coherente y
eficaz de los sistemas. Esto ha hecho que las bases de datos ocupen un primer plano en el área de las
tecnologías de la información. Por ello, esta asignatura tiene las siguientes aportaciones al perfil profesional
del ingeniero informático:
El propósito de este manual es aportar al perfil del Ingeniero Informático los conceptos de las nuevas
tendencias en bases de datos, así como logro de cuatro competencias específicas dirigidas a la
comprensión de los dominios de: bases de datos distribuidas, bases de datos orientadas a objetos, sistemas
multibase de datos y seguridad en los sistemas de base de datos.
OBJETIVO GENERAL
Conoce y utiliza sistemas de base de datos acordes a las necesidades del problema que atiende,
considerando la optimización de los recursos de datos en el tratamiento y seguridad de la
información.
SEGURIDAD
-INTRODUCCIÓN
Un sistema de bases de datos distribuidas es aquel en el que hay múltiples sitios de bases de datos unidos
por un sistema de comunicaciones, en forma tal que los datos en cualquier sitio son accesibles para los
usuarios de otros sitios. Normalmente, cada sitio o nodo tiene un sistema completo de procesamiento de
información, con su propia función de administración de datos, personal, usuarios, hardware y software,
inclusive una base de datos local, sistema de administración de base de datos y software de
comunicaciones. Lo mínimo que debe tener un sitio es memoria y procesador de comunicaciones. Los
sitios por lo general están separados geográficamente y están unidos por un sistema de
telecomunicaciones, aunque es posible tener un sistema distribuido y comunicado por medio de una red
de área local dentro de un solo edificio o área pequeña. Se pretende que los usuarios no necesiten conocer
la verdadera localización de los datos a que acceden, y para ellos el sistema parece ser una base de datos
local. En función de las necesidades de la organización, las bases de datos distribuidas tienen las
siguientes ventajas sobre un sistema único y centralizado que dé acceso remoto a los usuarios.
1. Autonomía local.
2. Confiabilidad mejorada.
3. Mejor disponibilidad de datos.
4. Mejor rendimiento.
5. Tiempo menor de respuesta.
-OBJETIVO (S)
-LUGAR
Aula
-SEMANA DE EJECUCIÓN
Semana 2
- MATERIAL Y EQUIPO
-DESARROLLO DE LA PRÁCTICA
PASO 1
Configurar los equipos para el diseño de base de datos distribuidas, siguiendo el procedimiento:
server-id=1
log-bin=mysql-bin
5. Abrir la Línea de comandos de MySQL, para otorgar permiso al esclavo de realizar tareas en el
servidor
flush privileges;
server-id=2
log-bin=mysql-bin.000001
skip-slave-start
change master to
master_host=’192.168.1.71’,
master_user=’root’,
master_password=’abc’,
master_log_file=’mysql-bin.000001’,
master_log_pos=999;
12. Arrancar el servicio de esclavo
start slave;
14. Checar las líneas que indican que el servicio está corriendo
Maquina master
15. Para comprobar que todo es correcto, crea una base de datos (maquina master)
Show databases;
PASO 2
Se requiere una base de datos que sirva como seguimiento de los empleados, los departamentos y los
proyectos de una empresa, con los siguientes requisitos:
La empresa está organizada en departamentos. Cada uno tiene un nombre único, un número único y
un empleado concreto que lo administra. Se realizará un seguimiento de la fecha en que ese
empleado empezó a administrar el departamento. Un departamento puede tener varias ubicaciones.
Un departamento controla una cierta cantidad de proyectos, cada uno de los cuales tiene un nombre
único, un número único y una sola ubicación.
También se desea realizar un seguimiento de las personas a cargo de cada empleado por el tema de
los seguros. Por cada persona a cargo o subordinado, se registrará su nombre de pila, sexo, fecha de
nacimiento y relación con el empleado.
PASO 3
Código:
Dirección Académica CPE-FO-02-03
Revisión: 1
A partir del modelo entidad-relación creado, convertirlo a un modelo de tablas relacionales (Modelo
Relacional).
PASO 4
Crear el esquema de la base de datos. Crear las tablas resultantes del análisis del problema, teniendo en
cuenta la problemática asociada a la integridad referencial.
Crear tablas
mysql> CREATE TABLE DEPTO (NOMBRE VARCHAR(20), ID INT(1) NOT NULL, IDJEFE VARCHAR(10),
FEC_DIR DATE) ENGINE=INNODB;
mysql> CREATE TABLE LOCAL (ID INT(1) NOT NULL, DEP_LOCA VARCHAR(20)) ENGINE=INNODB;
mysql> CREATE TABLE TRABAJA_EN (IDPROY INT(2), IDEMP VARCHAR(10), HORAS DOUBLE(4,2))
ENGINE=INNODB;
mysql> CREATE TABLE PROYECTO (NOMBRE VARCHAR(20), ID INT(2) NOT NULL, LOCAL
VARCHAR(20), IDDEPTO INT(1)) ENGINE=INNODB;
Código:
Dirección Académica CPE-FO-02-03
Revisión: 1
mysql> CREATE TABLE CARGO (IDEMP VARCHAR(10) NOT NULL, NOMDEPTO VARCHAR(20), SEX
VARCHAR(1), FECNAC DATE, RELACION VARCHAR(10)) ENGINE=INNODB;
mysql> ALTER TABLE EMPLEADO ADD FOREIGN KEY (IDDEPTO) REFERENCES DEPTO (ID) ON
DELETE SET NULL ON UPDATE CASCADE, ADD FOREIGN KEY (SUPERID) REFERENCES EMPLEADO
(ID) ON DELETE SET NULL ON UPDATE CASCADE;
mysql> ALTER TABLE DEPTO ADD FOREIGN KEY (IDJEFE) REFERENCES EMPLEADO (ID) ON DELETE
SET NULL ON UPDATE CASCADE;
mysql> ALTER TABLE LOCAL ADD FOREIGN KEY (ID) REFERENCES DEPTO (ID) ON DELETE CASCADE
ON UPDATE CASCADE;
mysql> ALTER TABLE PROYECTO ADD FOREIGN KEY (IDDEPTO) REFERENCES DEPTO (ID) ON DELETE
SET NULL ON UPDATE CASCADE;
Código:
Dirección Académica CPE-FO-02-03
Revisión: 1
mysql> ALTER TABLE CARGO ADD FOREIGN KEY (IDEMP) REFERENCES EMPLEADO (ID) ON DELETE
CASCADE ON UPDATE CASCADE;
Restriccion Unique
mysql> ALTER TABLE DEPTO ADD UNIQUE (NOMBRE);
- EVALUACIÓN Y RESULTADOS
DATOS
GENERALES
Criterio Descripción
Portada Nombre, matrícula, nombre del profesor, nombre de la asignatura, parcial,
fecha.
CONTENIDO
Aspec Pe
to so
Análisis del Problema 20
Desarrollo y resultados. 60
De Miguel, A., & Piattini, M. (s.f.). Fundamentos y modelos de bases de datos. Alfa-Omega
Ramma.Alfa-Omega Ramma.
Korth, H. F., & Silbertchatz, A. (2010). Fundamentos de Bases de datos (5 ed.). McGraw Hill.
Post, Gerald V. (2006), “Sistemas de Administración para bases de datos”. 1ra. edición. McGrawHill. México.
Pratt Philip J., Last Mary Z. Sql. 1ra. Edición. Anaya Multimedia. España. 2009.
-INTRODUCCIÓN
Los factores que debe considerar el diseñador de un sistema de base de datos distribuidas al elegir una
arquitectura incluyen la colocación de los datos, tipo de sistemas de comunicaciones, modelos de datos que
soporta y tipos de aplicaciones.
Difieren en la cantidad de replicación que permiten de los datos. Cada alternativa impone un tipo diferente de
sistema y utiliza procedimientos distintos de actualización y descomposición de solicitudes. Si el sistema de
comunicaciones es lento y caro de usar se favorece un almacenamiento y procesamiento locales. Un sistema
rápido y barato de comunicaciones, como una red de área local, favorece el almacenamiento y procesamiento
centralizados. Los sistemas distribuidos aceptan varios modelos de datos y lenguajes de manipulación para
ellos, igual que en los sistemas centralizados. En general, un diseñador debe evitar los modelos que usen una
recuperación de un registro a la vez, y a cambio de eso elegir aquellos que permitan operaciones a nivel de
conjunto, debido al número de mensajes que se requieren para la recuperación con navegación del
programador. Ésta es una de las razones por las que el modelo relacional es el que se usa con más frecuencia
en las bases de datos distribuidas. Al considerar los tipos de aplicaciones por realizar contra la base de datos
escogida, el diseñador necesita estimar el tamaño de ésta, número de transacciones, cantidad de datos que
requiere la transacción, complejidad de las transacciones, número de recuperaciones en relación con el
número de actualizaciones, y número de transacciones que hacen referencia a datos locales en comparación
con los remotos. Entre las alternativas están las siguientes:
-OBJETIVO
Realizar práctica de ejercicios atendiendo una batería de consultas y operaciones sobre la BDD elaborada
anteriormente.
-LUGAR
Aula o centro de cómputo
-SEMANA DE EJECUCIÓN
Semana 3
- MATERIAL Y EQUIPO
-DESARROLLO DE LA PRÁCTICA
PASO 1
PASO 2
PASO 3
PASO 4
Simples
mysql> SELECT * FROM EMPLEADO;
Concatenación
mysql> SELECT CONCAT (nombre, ' ', apellido) as Empleados from empleado;
mysql> SELECT ID, NOMBRE, APELLIDO, SUPERID FROM EMPLEADO WHERE IDDEPTO IS not NULL;
mysql> SELECT NOMBRE, APELLIDO FROM EMPLEADO WHERE APELLIDO LIKE 'D%';
mysql> SELECT NOMBRE, APELLIDO FROM EMPLEADO WHERE NOMBRE LIKE ' ' AND
APELLIDO LIKE 'D%';
mysql> SELECT DEPTO.ID, NOMBRE FROM DEPTO, LOCAL WHERE DEPTO.ID= LOCAL.ID AND
DEP_LOCA='ACAPULCO';
Funciones de columna
mysql> SELECT COUNT(ID) FROM EMPLEADO;
Ordenamiento
mysql> SELECT APELLIDO, NOMBRE FROM EMPLEADO ORDER BY APELLIDO DESC;
Consultas agrupadas
mysql> SELECT IDEMP, NOMBRE,APELLIDO, SUM(HORAS) FROM TRABAJA_EN, EMPLEADO WHERE
ID=IDEMP GROUP BY IDEMP;
PASO 5
- EVALUACIÓN Y RESULTADOS
DATOS
GENERALES
Criterio Descripción
Portada Nombre, matrícula, nombre del profesor, nombre de la asignatura, parcial,
fecha.
Bibliografía Inclusión apropiada de datos bibliográficos. Reportar todas las fuentes
correctamente en formato APA.
CONTENIDO
Aspec Pe
to so
Análisis del Problema 20
Desarrollo y resultados. 60
-REFERENCIAS
De Miguel, A., & Piattini, M. (s.f.). Fundamentos y modelos de bases de datos. Alfa-Omega
Ramma.Alfa-Omega Ramma.
Korth, H. F., & Silbertchatz, A. (2010). Fundamentos de Bases de datos (5 ed.). McGraw Hill.
Post, Gerald V. (2006), “Sistemas de Administración para bases de datos”. 1ra. edición. McGrawHill. México.
Pratt Philip J., Last Mary Z. Sql. 1ra. Edición. Anaya Multimedia. España. 2009.
-INTRODUCCIÓN
En el contexto de esta práctica se proporciona al estudiante el concepto de sistemas abiertos, así como la
descripción y análisis de los diferentes protocolos de comunicación que requieren las redes.
Se llama Transacción a una colección de operaciones que forman una unidad lógica de trabajo en una BD
realizada por una o más sentencias SQL estrechamente relacionadas.
Una transacción es una unidad de la ejecución de un programa que lee y escribe datos a y desde la Base de
Datos. Puede consistir en varias operaciones de acceso a la base 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).
El concepto de transacción se desarrolló para atender los casos en los que el estado resultante de la base de
datos depende del éxito completo en una serie de operaciones. Este concepto vio la luz debido a que varias
operaciones sucesivas pueden modificar el resultado de operaciones anteriores. En esos casos, si alguna
operación produce un error, el estado resultante puede ser indeterminado.
Para solucionar este problema, las transacciones agrupan una serie de operaciones de manera que es posible
garantizar la integridad del resultado final. O todas las operaciones se ejecutan con éxito y se confirman (se
escriben en la base de datos), o toda la transacción se considera no realizada. La acción de cancelar una
transacción se denomina deshacer la transacción. Deshacer una transacción permite anular los cambios y
recuperar el estado de la base de datos previo a la transacción.
Por ejemplo, en una transacción bancaria automatizada, si un banco transfiere dinero desde la cuenta A a la
cuenta B, la retirada de fondos de A y el depósito en B deben producirse con éxito para procesar los fondos
correctamente, de lo contrario la transacción entera debe cancelarse.
En SQL
Éxito Fracaso
Begin Begin
transacction transacction
Instrucción 1 Instrucción 1
Instrucción 2 Instrucción 2
... ...
Commit workEnd Rollback workEnd
transacction transacction
Propiedades de la Transacción
Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades ACID
(atomicidad, coherencia, aislamiento y durabilidad), para ser calificacada como transacción.
Atomicity : Una Transacción (Tx) se ejecuta completamente ó de otra manera se eliminan los
cambios parciales realizados.
Coherencia: Asegura que los datos queobservamos no cambian (por otros usuarios) hasta que
acabemos la Transacción.
Después de terminar una Transacción la Base de datos no viola ninguna de sus reglas: valores
obligatorios, claves únicas,etc.
Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen. Una
Transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de
finalizar.
Más aun, si varias transacciones, se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado secuencialmente. Esto se conoce como seriabilidad debido a
que su resultado es la capacidad de volver a cargar los datos iniciales y reproducir una serie de
transacciones para finalizar con los datos en el mismo estado en que estaban después de realizar
transacciones originales.
Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx
ya confirmadas.
-OBJETIVO
Realizar práctica de ejercicios atendiendo una batería de consultas y operaciones sobre la BDD
elaborada anteriormente.
-LUGAR
-SEMANA DE EJECUCIÓN
Semana 4
- MATERIAL Y EQUIPO
-DESARROLLO DE LA PRÁCTICA
PASO 1
Ejemplo: Concurrencia
Para este ejercicio se requiere tener abiertas dos ventanas concurrentes para la ejecución de los comandos.
3. Vuelva a ventana 1
mysql> COMMIT;
PASO 2
1. En una ventana 1
mysql> BEGIN;
mysql> COMMIT;
El resultado ventana 2
mysql> INSERT INTO EMPLEADO VALUES ("ANTONIO","ROBLES", 8,"1982-11-12","CALLE 12",
'M', 120,1,3);
4. En la ventana 2
mysql> COMMIT;
Si consulta vera que ya puede visualizar el registro insertado en la ventana 1, pero el de esta
no se insertó.
PASO 3
mysql> BEGIN;
mysql> COMMIT;
PASO 4
mysql> BEGIN;
Si realiza una consulta normal de selección en la ventana 2, no recuperaremos el ultimo valor (porque la
transacción anterior no se ha completado y la tabla InnoDB realiza una lectura coherente como parte de su
comportamiento predeterminado).
Sin embargo, si realiza una consulta con un bloqueo en modo compartido, no obtendrá un resultado hasta que
se complete la transacción en la ventana 1.
+ + + + + + + + + +
+ + + + + + + + + +
+ + + + + + + + +
Todavía en la ventana 2, si realiza la misma consulta en modo de bloqueo de uso compartido no se generará
ningún resultado:
PASO 5
De manera predeterminada, y a menos que se especifique una transacción con BEGIN, MySQL confirma
automáticamente las instrucciones.
Sin embargo, en las tablas de transacción segura (InnoDB, DBD), puede cambiar este comportamiento
asignando 0 a AUTOCOMMIT.
Sin embargo, la secuencia AUTOCOMMIT=0 no se aplica a todo el servidor, sino solo a la sesión especifica.
Si se asigna el valor 0 al comando AUTOCOMMIT en la ventana 2, el comportamiento será diferente.
mysql> COMMIT;
El nuevo registro no aparece, aunque hayamos confirmado los resultados. La razón es que la instrucción de
selección de la ventana 1 forma también parte de una transacción. A la lectura coherente se le ha asignado un
punto temporal y este punto temporal avanza si la transacción en la que se estableció se ha completado.
Existen dos tipos de bloqueos de tabla: los bloqueos de lectura y los bloqueos de escritura. Los bloqueos de
lectura solo permiten realizar lecturas sobre la tabla, quedando bloqueadas las operaciones de escritura. Los
bloqueos de escritura impiden la realización de operaciones de lectura o escritura sobre la tabla durante el
bloqueo. La sintaxis para bloquear una tabla es la siguiente: LOCK TABLE nombre-de-tabla
(READ/WRITE)
Para desbloquear una tabla, basta con utilizar la instrucción UNLOCK TABLE de la siguiente forma:
UNLOCK TABLES
Si el subproceso que creo el bloqueo intenta agregar un registro a la tabla EMPLEADO, fallara. No esperara a
que el bloqueo se libere (como se creó el bloqueo, si se suspende, no volverá a poder liberarlo nunca); en su
lugar la operación de inserción simplemente fallara.
ERROR 1099 (HY000): Table 'EMPLEADO' was locked with a READ lock and can't be
updated
7. Sin embargo, puede realizar lecturas sobre la tabla cuya escritura bloqueo, de
la siguiente forma, desde la ventana 1 :
8. En la ventana 2
11. Intente aplicar otro bloqueo de escritura desde una tercera ventana:
mysql> LOCK TABLE EMPLEADO WRITE;
Solo cuando se libera el bloqueo de escritura de la ventana 3 se puede obtener el bloqueo de escritura de
la ventana 2 (no es necesario volver a escribirlo):
Puede variar este comportamiento especificando una prioridad inferior para el bloqueo de escritura, mediante
la palabra clave LOW PRIORITY.
Si vuelve a ejecutar el ejemplo anterior con una solicitud de prioridad baja para un bloqueo de escritura,
se obtendrá primero el bloqueo de lectura anterior.
+ +
| @S:=(salario) |
+ +
| 200 |
+ +
1 row in set (0.09 sec)
mysql> COMMIT;
mysql> COMMIT;
- EVALUACIÓN Y RESULTADOS
DATOS
GENERALES
Criterio Descripción
Portada Nombre, matrícula, nombre del profesor, nombre de la asignatura, parcial,
fecha.
CONTENIDO
Aspec Pe
to so
Análisis del Problema 20
Desarrollo y resultados. 60
-REFERENCIAS
De Miguel, A., & Piattini, M. (s.f.). Fundamentos y modelos de bases de datos. Alfa-Omega
Ramma.Alfa-Omega Ramma.
Groff, Jaes R. ; N. Weinberg, Paul. (2011) Manual de referencia SQL. Ed. McGraw Hill.
Malware - Ataque a la Base de Datos. Recuperado a partir de http://ataquebd.blogspot.mx/ Korth, H. F., &
Silbertchatz, A. (2010). Fundamentos de Bases de datos (5 ed.). McGraw Hill. Pratt Philip J., Last
Catherine M. Ricardo, Iona College. “Database Illuminated”. Editorial Jones and Bartlett Publishers.
PRACTICA 4.
-INTRODUCCIÓN
Una base de datos orientada a objetos es una base de datos donde los elementos son objetos. Estos pueden ser
bases de datos multimedia (videos, imágenes y sonidos), donde la herencia nos permita una mejor
representación de la información, estas bases de datos tienen una identidad de ser un Todo, y no solo una
parte de una gran base, por ejemplo una base de secuencias de ADN.
El objetivo de una base de datos orientada a objetos son los mismos que los de las bases de datos
tradicionales, pero con la ventaja de representar las modelos de datos con un marco mucho más eficiente,
manteniendo la integridad y relación entre ellos.}
Un objeto puede heredar comportamiento de otro tipo de objetos (herencia) y puede adaptarse para responder
de diferentes maneras ante la solicitud de una acción (polimorfismo), lo importante es que permite representar
cosas de la vida real con relativa facilidad (abstracción) y que todo esto se puede implementar de manera que
no nos importe el código, sino sólo la manera de comunicarnos con estos objetos pensando en ellos como una
sola unidad (encapsulamiento).
Las bases de datos orientados a objetos han adoptado muchos de los objetos creados para los lenguajes de
programación orientados a objetos.
Para modelar la estructura o vista lógica de la BD, se utiliza el Diagrama de clases que permite presentar las
clases con sus respectivas relaciones estructurales y de herencia, además del Diagrama de Objetos cuando no
está muy claro y preciso cómo serían las instancias de las clases o para especificar más el Diagrama de
Clases.
Para modelar la parte dinámica, la interacción y comportamiento entre los objetos, se emplearía el Diagrama
de Secuencia para presentar las interacciones entre los objetos organizados en una secuencia temporal y
describir como estos objetos colaboran; así como también, el Diagrama de
Estado para mostrar los posibles estados en que puede encontrarse un objeto y las transacciones que pueden
causar un cambio de estado, luego que ocurre un evento.
Un conjunto de variables que contiene los datos del objeto; las variables corresponden con los atributos del
modelo E-R.
Un conjunto de mensajes a los que responde; cada mensaje puede o no tener parámetros o tener uno o varios.
Un conjunto de métodos, cada uno de los cuales es el código que implementa un mensaje; el método
devuelve un valor como respuesta al mensaje.
Además tienen un Nombre, Tiempo de vida pueden ser transitorios o persistentes, estado y comportamiento.
Mandatorias: son las que el Sistema debe satisfacer a orden de tener un sistema de BDOO y estos son:
Objetos complejos, Identidad de Objetos, Encapsulación, Tipos o clases, Sobre paso con unión retardada,
Extensibilidad, Completación Computacional, Persistencia y Manejador de almacenamiento
secundario, Concurrencia, Recuperación y Facilidad de Query
Opcional: Son las que pueden ser añadidas para hacer el sistema mejor pero que no son Mandatorias, estas
son de: herencia múltiple, chequeo de tipos e inferencia d e distribución y diseño de
transacciones y versiones.
Abiertas: Son los puntos donde el diseñador puede hacer un número de opciones y estas son el
paradigma de la programación, la representación del sistema ó el tipo de sistema y su uniformidad. Hemos
tomado una posición no muy a la expectativa para tener una palabra final más bien para proveer un punto de
orientación para un debate futuro.
La clave que posee la BDOO es el poder que confieren al diseñador para especificar tanto la estructura de
objetos complejos como las operaciones que se pueden aplicar a esos objetos.
Está su flexibilidad, y soporte para el manejo de tipos de datos complejos. Ya que puedo tener clases y
subclases creadas por ejemplo una base de clientes puede tener una subclase de la referencia de este cliente y
esta heredara todos sus atributos y característica de la clase original.
La segunda ventaja de una BDOO, es que manipula datos complejos en forma rápida y ágilmente. La
estructura de la base de datos está dada por referencias (o apuntadores lógicos) entre objetos.
Desventajas
Al considerar la adopción de la tecnología orientada a objetos, la inmadurez del mercado de BDOO constituye
una posible fuente de problemas. Hay muy pocos manejadores de base de datos en el mercado que soporten
este tipo de arquitectura Algunos de los pocos oodbms que existen son:
• Db4o
• Informix
• Bdoviedo3
Quizá esta sea una de las causas por las cuales las OODB aún no tengan ese crecimiento que en algún
momento tantas expectativas generaron.
-OBJETIVO
-LUGAR
-SEMANA DE EJECUCIÓN
Semana 5
- MATERIAL Y EQUIPO
-DESARROLLO DE LA PRÁCTICA
PASO 1
3. Cambiar el nombre a la carpeta que se extrajo por SQL Developer y mover a Archivos
de programas.
6. Abrir el programa SQL Developer, en caso de salir en mensaje de la imagen, dar clic en NO.
PASO 2
7. Una vez abierto el programa dar clic en el botón Crear una conexión.
15. Crear la tabla trabaja_en, que viene de una relación varios a varios.
16. Crear la tabla tabLocal_D
PASO 3
Crear una conexión para crear la base de datos con la siguiente problemática
La liga de fútbol “Calkiní” ha decidido informatizar sus procesos creando una base de datos para guardar la
información de los partidos que se juegan en la liga.
En primer lugar, se desea guardar en los datos de los jugadores. De cada jugador se quiere guardar el nombre,
fecha de nacimiento y posición en la que juega (portero, defensa, delantero…). Cada jugador tiene un código
de jugador que lo identifica de manera única.
De cada uno de los equipos de la liga es necesario registrar el nombre del equipo, el año de fundación del
equipo y la colonia de la que es el equipo. Cada equipo también tiene un código que lo identifica de manera
única. Un jugador solo puede pertenecer a un único equipo.
De cada partido que los equipos de la liga juegan hay que registrar la fecha en la que se juega el partido, los
goles que ha metido el equipo de casa y los goles que ha metido el equipo de fuera. Cada partido tendrá un
código numérico para identificar el partido. Se debe tomar en cuenta que un equipo puede jugar varios
partidos, pero un partido solo puede tener a un equipo “x” solo una vez.
Por último, se quiere almacenar, en la base de datos, los datos de los presidentes de los equipos de fútbol (Id,
nombre, apellidos, fecha de nacimiento, equipo del que es presidente y año en el que fue elegido presidente).
Un equipo de fútbol tan sólo puede tener un presidente, y una persona sólo puede ser presidente de un equipo
de la liga.
- EVALUACIÓN Y RESULTADOS
DATOS
GENERALES
Criterio Descripción
Portada Nombre, matrícula, nombre del profesor, nombre de la asignatura, parcial,
fecha.
CONTENIDO
Aspec Pe
to so
Análisis del Problema 20
Desarrollo y resultados. 60
-REFERENCIAS
De Miguel, A., & Piattini, M. (s.f.). Fundamentos y modelos de bases de datos. Alfa-Omega
Ramma.Alfa-Omega Ramma.
Korth, H. F., & Silbertchatz, A. (2010). Fundamentos de Bases de datos (5 ed.). McGraw Hill.
Post, Gerald V. (2006), “Sistemas de Administración para bases de datos”. 1ra. edición. McGrawHill. México.
Pratt Philip J., Last Mary Z. Sql. 1ra. Edición. Anaya Multimedia. España. 2009.
MULTIBASE DE DATOS
-INTRODUCCIÓN
Un sistema multibase de datos (SMulBD) soporta operaciones en múltiples sistemas de base de datos
componentes (SBDC).
Cada SBDC es manejado por un sistema manejador de base de datos (SMBD).
Un SMulBD es llamado homogéneo si todos los SMBD componentes son iguales; si son diferentes entonces es
llamado un SMulBD heterogéneo.
Diseño
Comunicaciones
Ejecución
Asociación
• Autonomía y heterogeneidad
• El sistema es distribuido
• Un sistema de base de datos puede ser componente de varias federaciones al mismo tiempo.
Base de Datos no Federada
Un sistema de base de datos no federado es una integración de SMBDs componentes que no son autónomos.
• Pierden su autonomía
Un tipo particular de sistema de base de datos no-federado en el cual todas las bases están completamente
integradas para proveer un esquema global simple puede ser llamado SMulBD unificado. Esto lógicamente
parece a los usuarios como un sistema de base de datos distribuida.
-OBJETIVO
-LUGAR
-SEMANA DE EJECUCIÓN
Semana 11
- MATERIAL Y EQUIPO
-DESARROLLO DE LA PRÁCTICA
PASO 1
192.168.1.72 local.com
192.168.1.74 servidor1.remoto.com
PASO 2
Configurara Mysql para que sea federada
federated
show engines \G
PASO 3
PASO 4
C:\wamp64\bin\mysql\mysql5.7.19\bin
3. Enseguida conectar con el usuario userP5:
SHOW DATABASES;
USE TIENDA
SHOW TABLES;
PASO 5
2. En la maquina local verificar que ya existe una tabla con el comando SHOW.
PASO 6
1. En la maquina local, abrir la línea de comando de Windows, con el usuario root y crear
una base de datos que va ser la federada:
CREATE DATABASE FED_TIENDA;
2. Crear una tabla con la misma estructura de la tabla Clientes del servidor remoto
3. Comprobar si tabla esta federada, en la maquina local, haciendo una consulta en f_clientes;
PASO 7
Realiza el mismo procedimiento para tener una tabla federada de la base de datos “Liga de futbol” (ver
problemática en la “Práctica 4”)
- EVALUACIÓN Y RESULTADOS
DATOS
GENERALES
Criterio Descripción
Portada Nombre, matrícula, nombre del profesor, nombre de la asignatura, parcial,
fecha.
CONTENIDO
Aspec Pe
to so
Análisis del Problema 20
Desarrollo y resultados. 60
-REFERENCIAS
De Miguel, A., & Piattini, M. (s.f.). Fundamentos y modelos de bases de datos. Alfa-Omega
Ramma.Alfa-Omega Ramma.
Korth, H. F., & Silbertchatz, A. (2010). Fundamentos de Bases de datos (5 ed.). McGraw Hill.
Post, Gerald V. (2006), “Sistemas de Administración para bases de datos”. 1ra. edición. McGrawHill. México.
Pratt Philip J., Last Mary Z. Sql. 1ra. Edición. Anaya Multimedia. España. 2009.