European Soccer DB

EUROPEAN SOCCER
BIG DATA
ALBERTO ROBLES, ALEJANDRO PEREZ, ALVARO HUARTE

BASES DE DATOS II
ÍNDICE
1. PLANIFICACIÓN.........................................................................................................................2
2. CASUÍSTICA ...............................................................................................................................2
3. ANÁLISIS DE DIFERENTES SGBD:...............................................................................................3
3.1 MySQL ..............................................................................................................................3
3.2 PostgreSQL .......................................................................................................................3
3.3 ORACLE....................................................................................................................................4
4. DISEÑO CONCEPTUAL...............................................................................................................5
5. DISEÑO LÓGICO ........................................................................................................................6
5.1 Cálculo relacional de tuplas T.S ........................................................................................9
5.2 Herencia Exclusiva MySQL ...............................................................................................9
6. DISEÑO UML ...........................................................................................................................10
7. DISEÑO FÍSICO ........................................................................................................................10
7.1 TRIGGER LOAD DATA INFILE EN MYSQL................................................................................10
8. BASES DE DATOS DISTRIBUIDAS .............................................................................................11
8.1 TIPOS DE SGBD...............................................................................................................12
8.2 FEDERADAS EN MYSQL ..................................................................................................12
9. JUSTIFICACIÓN DEL SGBD ELEGIDO ........................................................................................13
9.1 CONCLUSIÓN ..................................................................................................................14
10. ÁRBOL DE DECISIÓN ...........................................................................................................16
11. BIBLIOGRAFÍA .....................................................................................................................16
1
Bases de Datos 2 - EUROPEAN SOCCER
Alberto Robles | Alejandro Pérez | Alvaro Huarte
1. PLANIFICACIÓN
2. CASUÍSTICA
Vamos a realizar un escenario en el cual tenemos información sobre las ligas que hay en cada país
europeo, los diferentes partidos, equipos y los jugadores que han participado en dichas ligas.
Cada país dispone de la siguiente información: id y nombre. Cada liga debe pertenecer a un país y
contiene la siguiente información: id, country_id y su nombre. Cada partido se disputará en una
determinada liga, se desea almacenar información relevante para la misma: id, country_id,
league_id, temporada, fase, fecha_partido, home_team, away_team, posee una lista con la
alineación de cada equipo, las predicciones de cada partido podrán ser de tipo BWH (victoria local),
BWD (empate) y BWA (victoria visitante), junto con una serie de cuotas ligados a distintas casas de
apuestas.
Cada jugador se identificará con id numérico, y tiene la siguiente información: nombre, un vínculo
que indica el identificador asociado al FIFA, fecha de nacimiento, peso y altura. Además de forma
opcional puede tener una serie de atributos más específicos asociados al jugador
(Player_Attributes).
De los equipos se desea almacenar el id de cada uno, su identificador asociado al FIFA, nombre y
abreviatura. Además de forma adicional puede tener una serie de atributos más específicos
asociados al equipo (Team_Attributes), como por ejemplo: defenceTeamWidth,
defenceAgressionClass, defencePressure... Los atributos específicos del equipo no contemplan
posibilidad de atributos nulos.
2
3. ANÁLISIS DE DIFERENTES SGBD:
3.1 MySQL
MySQL es una base de datos relacional en lugar de una OO. Se puede utilizar como orientada a
objetos desde su código utilizando una biblioteca ORM (Object Relational Mapping). Un buen
ejemplo es la doctrina para PHP.
En el tema de orientación a objetos no hemos encontrado mucha información al respecto por

lo que hemos hecho un resumen de las prestaciones más generales que MySQL posee:
• Posee una gran velocidad de respuesta.

• Se puede utilizar como cliente-servidor o incrustando aplicaciones.
• Soporta múltiples métodos de almacenamiento de tablas.
• Puede manejar hasta 50 millones de registros, sesenta mil tablas y 5 millones de
columnas.
• Sus opciones de conectividad abarcan TCP/IP, sockets UNIX y sockets NT, además de
soportar completamente ODBC.
También posee una serie de limitaciones importantes:
• No considera las claves ajenas. Ignora la integridad referencial, dejándola en manos

del programador de la aplicación.
• A la hora de soporte de transacciones o la integridad referencial, MySQL está
condicionado a un esquema de almacenamiento de tabla concreto, ya que si el usuario
no usa transacciones puede usar MyISAM y si lo usa tiene que usar InnoDB.
3.2 PostgreSQL
Es un sistema de gestión de bases de datos relacional orientada a objetos de software libre,
publicado bajo la licencia BSD. Esta licencia tiene menos restricciones en comparación con
otras como la GPL ya que permite el uso de código fuente en software no libre.
Las ventajas más significativas que hemos encontrado de PostgreSQL:
• Alta concurrencia e integridad transaccional.

• Permite a los usuarios hacer búsquedas (solo lectura) en los servidores mientras están
en modo espera o recuperación.
• Posee copias de seguridad en caliente y multiplataforma.
• Gran capacidad de almacenamiento.
• Posee un administrador gráfico muy intuitivo llamado pgAdmin.
• Herencia de tablas.
3
PostgreSQL soporta funciones que retornan “filas”, donde la salida puede tratarse como un
conjunto de valores retornados de una consulta.
Los inconvenientes más destacados son:
• Más lento en operaciones de escritura que MySQL.

• Consume más recursos que MySQL.
• La sintaxis de algunos comandos es poco intuitiva.
3.3 ORACLE
Una base de datos orientada a objetos, que incorpora todos los conceptos importantes del
modelo de objetos:
1. Encapsulación.
2. Herencia.
3. Polimorfismo.
Las BDOO están diseñadas para trabajar con lenguajes de programación como Java o C++, con
unas propiedades específicas las cuales hemos nombrado anteriormente.
Ventajas:
• Manipulación de datos de forma rápida, flexibilidad y buen desempeño.
Desventajas:
• No posee agrupamiento de objetos, está diseñada para un tipo de objetos.
Aquí vamos a hablar un poco de la OO de la versión 9i de Oracle. Esta es la primera versión de

Oracle que soporta herencia de tipos, cuando se crea un subtipo a partir de otro tipo este
hereda todos los atributos del “padre”.
No soporta la herencia múltiple, cuando se produce el polimorfismo solo se puede heredar un

tipo, pero se pueden construir jerarquías de tipos y subtipos.
Oracle ha definido una arquitectura, llamada NCA, que representa un modelo para el proceso
distribuido orientado a objetos en la. Esta arquitectura ofrece un marco unificado que permite
que los diversos sistemas de procesamiento cliente/servidor, WWW (World Wide Web) y la
tecnología de objetos distribuidos como CORBA o DCOM compartan un modelo común basado
en estándares.
4
4. DISEÑO CONCEPTUAL
1.SOFTWARE DISEÑO E/R DEREDITOR HTTP://DEREDITOR.SOURCEFORGE.NET
5
5. DISEÑO LÓGICO
PAIS (country_id: dom_id, name: dom_name)
Clave Primaria: {id}
LIGA (league_id: dom_id, country_id: dom_country_id, name: dom_name)
Único: {country_id}
VNN: {country_id} → RE
Clave Ajena: {country_id} hace referencia a PAIS
PARTIDOS (match_id: dom_id, season: dom_season, stage: dom_stage, date: dom_date,

match_api_id: dom_match_api_id, home_team_goal: dom_home_team_goal,
away_team_goal: dom_away_team_goal, home_player_X1: dom_ home_player_X1,
home_player_X2: dom_home_player_X2, home_player_X3: dom_home_player_X3,
away_player_X1: dom_away_player_X1, away_player_X2: dom_away_player_X2, away_player_X3:
dom_away_player_X3, away_player_X4: dom_away_player_X4, away_player_X5:
dom_away_player_X11, home_player_Y1: dom_home_player_Y1, home_player_Y2:
dom_home_player_Y2, home_player_Y3: dom_dom_home_player_Y3, home_player_Y4:
dom_home_player_Y4 ,home_player_Y5: dom_home_player_Y5, home_player_Y6:
dom_home_player_Y6, home_player_Y7: dom_home_player_Y7, home_player_Y8:
dom_home_player_Y8, home_player_Y9: dom_home_player_Y9, home_player_Y10:
dom_home_player_Y10, home_player_Y11: dom_home_player_Y11, away_player_Y1:
dom_away_player_Y1, away_player_Y2: dom_dom_away_player_Y2, away_player_Y3:
dom_dom_away_player_Y3, away_player_Y4: dom_dom_away_player_Y4, away_player_Y5:
dom_dom_away_player_Y11, goal: dom_goal, shoton: dom_shoton, shotoff: dom_shotoff,
foulcommit: dom_foulcommit, card: dom_card, cross: dom_cross, corner: dom_corner, possession:
dom_possesion, B365H: dom_B365H, B365D: dom_B365D, B365A: dom_B365A, BWH: dom_BWH,
BWD: dom_BWD, BWA: dom_BWA, IWH: dom_IWH, IWD: dom_IWD, IWA: dom_IWA, LBH:
dom_LBH, LBD: dom_LBD, LBA: dom_LBA, PSH: dom_PSH, PSD: dom_PSD, PSA: dom_PSA, WHH:
6
dom_WHH, WHD: dom_WHD, WHA: dom_WHA, SJH: dom_SJH, SJD: dom_SJD, SJA: dom_SJA, VCH:
dom_VCH, VCD: dom_VCD, VCA: dom_VCA, GBH: dom_GBH, GBD: dom_GBD, GBA: dom_GBA,
BSH: dom_BSH, BSD: dom_BSD, BSA: dom_BSA, country_id: dom_country_id, league_id:
dom_league_id, home_team_api_id: dom_home_team_api_id, away_team_api_id:
dom_away_team_api_id, home_player_1: dom_home_player_1, home_player_2:
dom_home_player_2, home_player_3: dom_home_player_3, home_player_4:
dom_home_player_10, home_player_11: dom_home_player_11, away_player_1:
dom_home_player_1, away_player_2: dom_home_player_2, away_player_3:
dom_home_player_11)
Clave Primaria: {match_id}
Clave Ajena: {team_id} hace referencia a EQUIPO
Clave Ajena: {league_id} hace referencia a LIGA
Clave Ajena: {player_id} hace referencia a JUGADOR
VNN: {team_id} → RE
VNN: {team_id} → RE
EQUIPO (team_id: dom_team_id, team_api_id: dom_team_api_id, team_fifa_api_id:

dom_team_fifa_api_id, team_long_name: dom_team_long_name, team_short_name:
dom_team_short_name)
Clave Primaria: {team_id}
ATRIBUTOS_EQUIPO (id: dom_id, team_attributes_id: dom_team_attributes_id,

team_fifa_api_id: dom_team_fifa_api_id, team_api_id: dom_team_api_id, date: dom_date,
buildUpPlaySpeed: dom_buildUpPlaySpeed, buildUpPlaySpeedClass:
dom_buildUpPlaySpeedClass, buildUpPlayDribbling: dom_buildUpPlayDribbling,
buildUpPlayDribblingClass: dom_buildUpPlayDribblingClass, buildUpPlayPassing:
dom_buildUpPlayPassing, buildUpPlayPassingClass: dom_buildUpPlayPassingClass,
buildUpPlayPositioningClass: dom_buildUpPlayPositioningClass, chanceCreationPassing:
dom_chanceCreationPassing, chanceCreationPassingClass: dom_chanceCreationPassingClass,
chanceCreationCrossing: dom_chanceCreationCrossing, chanceCreationCrossingClass:
dom_chanceCreationCrossingClass, chanceCreationShooting: dom_chanceCreationShooting,
7
chanceCreationShootingClass: dom_chanceCreationShootingClass,
chanceCreationPositioningClass: dom_chanceCreationPositioningClass, defencePressure:
dom_defencePressure, defencePressureClass: dom_defencePressureClass, defenceAggression:
dom_defenceAggression, defenceAggressionClass: dom_defenceAggressionClass,
defenceTeamWidth: dom_defenceTeamWidth, defenceTeamWidthClass:
dom_defenceTeamWidthClass, defenceDefenderLineClass: dom_defenceDefenderLineClass,
team_id: dom_team_id)
JUGADOR (player_id: dom_player_id, player_api_id, player_name: dom_player_name,

player_fifa_api_id: dom_player_fifa_api_id, birthday: dom_birthday, height: dom_height,
weight: dom_weight)
Clave Primaria: {player_id}
PORTERO (player_id: dom_team_id, gk_reflexes: dom_gk_reflexes)
DEFENSA (player_id: dom_team_id, aggression: dom_aggression)
CENTROCAMPISTA (player_id: dom_team_id, interceptions: dom_interceptions)
DELANTEROS player_id: dom_team_id, agility: dom_agility)
ATRIBUTOS_JUGADOR (id: dom_id, player_attributes_id: dom_player_attributes_id,

player_fifa_api_id: dom_player_fifa_api_id, player_api_id: dom_player_api_id, date:
dom_date, overall_rating: dom_overall_rating, potential: dom_potential, preferred_foot:
dom_preferred_foot, attacking_work_rate: dom_attacking_work_rate, defensive_work_rate:
dom_defensive_work_rate, crossing: dom_crossing, finishing: dom_finishing,
heading_accuracy: dom_heading_accuracy, short_passing: dom_short_passing, volleys:
dom_volleys, dribbling: dom_dribbling, curve: dom_curve, free_kick_accuracy:
8
dom_free_kick_accuracy, long_passing: dom_long_passing, ball_control: dom_ball_control,
acceleration: dom_acceleration, sprint_speed: dom_sprint_speed, agility: dom_agility,
reactions: dom_reactions, balance: dom_balance, shot_power: dom_shot_power, jumping:
dom_jumping, stamina: dom_stamina, strength: dom_strength, long_shots: dom_long_shots,
aggression: dom_aggression, interceptions: dom_interceptions, positioning: dom_positioning,
vision: dom_vision, penalties: dom_penalties, marking: dom_marking, standing_tackle:
dom_standing_tackle, sliding_tackle: dom_sliding_tackle, gk_diving: dom_gk_diving,
gk_handling: dom_gk_handling, gk_kicking: dom_gk_kicking, gk_positioning:
dom_gk_positioning, gk_reflexes: dom_gk_reflexes, player_id: dom_player_id)
5.1 Cálculo relacional de tuplas T.S

Jx: J, Px: P, DEFx: DEF, Cx: C, DELx: DEL
∀ Jx(J(Jx)  (ƎDELx(DEL(DELx) ^ DELx.player_id = Jx.player_id) v
(ƎCx(C(Cx) ^ Cx.player_id = Jx.player_id) v
(ƎDEFx(DEF(DEFx) ^ DEFx.player_id = Jx.player_id) v
(ƎPx(P(Px) ^ Px.player_id = Jx.player_id)))
5.2 Herencia Exclusiva MySQL
CREATE DEFINER=`root`@`%` TRIGGER `completaAuto`

AFTER INSERT ON `Jugador`
FOR EACH ROW
INSERT INTO Delantero VALUES(new.player_id,'77')
CREATE DEFINER=`root`@`%` TRIGGER `exclusivoDefensa`

BEFORE INSERT ON `Defensa`
FOR EACH ROW BEGIN
DELETE FROM Portero where player_id = new.player_id;
DELETE FROM Mediocampista where player_id = new.player_id;
DELETE FROM Delantero where player_id = new.player_id;
END
9
6. DISEÑO UML
2. SOFTWARE DISEÑO LENGUAJE UNIFICADO DE MODELADO (UML) STAR UML
7. DISEÑO FÍSICO
7.1 TRIGGER LOAD DATA INFILE EN MYSQL
SET FOREIGN_KEY_CHECKS = 0
LOAD DATA LOCAL INFILE
'C:/Users/Alejandro/Desktop/bd2/database.sqlite/database.sqlite/Match.
csv'
INTO TABLE matchs
FIELDS TERMINATED BY ';'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES
(id,country_id,league_id,season,stage,date,match_api_id,home_team_api_
id,away_team_api_id,home_team_goal,away_team_goal,home_player_X1,home_
player_X2,home_player_X3,home_player_X4,home_player_X5,home_player_X6,
home_player_X7,home_player_X8,home_player_X9,home_player_X10,home_play
er_X11,away_player_X1,away_player_X2,away_player_X3,away_player_X4,awa
y_player_X5,away_player_X6,away_player_X7,away_player_X8,away_player_X
9,away_player_X10,away_player_X11,home_player_Y1,home_player_Y2,home_p
layer_Y3,home_player_Y4,home_player_Y5,home_player_Y6,home_player_Y7,h
ome_player_Y8,home_player_Y9,home_player_Y10,home_player_Y11,away_play
er_Y1,away_player_Y2,away_player_Y3,away_player_Y4,away_player_Y5,away
10
_player_Y6,away_player_Y7,away_player_Y8,away_player_Y9,away_player_Y1
0,away_player_Y11,home_player_1,home_player_2,home_player_3,home_playe
r_4,home_player_5,home_player_6,home_player_7,home_player_8,home_playe
r_9,home_player_10,home_player_11,away_player_1,away_player_2,away_pla
yer_3,away_player_4,away_player_5,away_player_6,away_player_7,away_pla
yer_8,away_player_9,away_player_10,away_player_11,goal,shoton,shotoff,
foulcommit,card, cross, corner, possession, B365H, B365D,
B365A,BWH,BWD,BWA,IWH,IWD,IWA,LBH,LBD,LBA,PSH,PSD,PSA,WHH,WHD,WHA,SJH,
SJD,SJA,VCH,VCD,VCA,GBH,GBD,GBA,BSH,BSD,BSA);
8. BASES DE DATOS DISTRIBUIDAS

El avance espectacular de las comunicaciones y la
creciente necesidad de cooperar con otras
entidades independientes han obligado a
replantearse los conceptos de bases de datos,
destacando entre ellos la tendencia de crear un
software para tener acceso a varias bases de datos
autónomas preexistentes, las cuales están
almacenados en SGBD HETEROGENEOS.
Este procedimiento es muy costoso y complicado

ya que hay que tener en cuenta varios conceptos
como la integración, seguridad. .etc. debido a esto
surgieron los SGBDF (Sistemas Gestores de Bases
de datos Federadas).
Como definición general las BDF podemos decir que es una colección de sistemas de BD
cooperativos y autónomos en el cual los usuarios tienen acceso a los datos de los distintos
sistemas, gracias a los esquemas unificados en los cuales hay datos de cada BD. Presentan las
siguientes características:
- Bi-procesamiento, es decir, poseen la capacidad de atender consultas globales.

- Distribución: datos ubicados en múltiples BD.
- Autonomía: cada BD tiene el control independiente sobre sí misma.
- La autonomía o la integración de los componentes la controla el administrador del
sistema global en colaboración con los administradores de las BD componente.
- Se basan en dos esquemas: exportación (las partes que comparten) e importación
(información que desea usar de otro componente).
- El sistema está formado por BD heterogéneas, por lo que podemos encontrar
diferentes S.O., diferente hardware o diferentes estructuras de datos.
- El MBDF (Manejador de Bases de Datos Federadas) recibe una consulta sencilla y este
a su vez la descompone en varia consultas parciales.
11
8.1 TIPOS DE SGBD
Los SGBDF se pueden clasificar en dos grandes categorías:
1. Fuertemente acopladas: poseen un esquema conceptual global que está formado por un
subconjunto de los esquemas conceptuales locales, compuesto por los datos que el
sistema local quiere compartir. Son capaces de soportar actualizaciones y la interpretación
de la semántica de los múltiples datos integrados en el sistema aes uniforme.
2. Débilmente acopladas: se basan en no tener un esquema conceptual global, en este caso
los esquemas externos están compuestos por uno o más esquemas conceptuales locales.
En este caso los usuarios son los responsables de la creación y mantenimiento de las
federaciones y soporta sistemas de BD altamente autónomos.
8.2 FEDERADAS EN MYSQL

Una vez explicado lo que son las bases de datos federadas, vamos a realizar un sencillo ejemplo de
BDF, con el SGDB que hemos tenido que realizar en nuestro proyecto, MySQL.
Vamos a utilizar la tabla jugador de nuestra base de datos creada anteriormente
CREATE TABLE `Jugador` (

`player_id` INT(11) NOT NULL DEFAULT '0',
`player_api_id` INT(11) NULL DEFAULT NULL,
`player_name` VARCHAR(80) NULL DEFAULT NULL,
`player_fifa_api_id` INT(11) NULL DEFAULT NULL,
`birthday` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
`height` INT(11) NULL DEFAULT NULL,
`weight` INT(11) NULL DEFAULT NULL,
PRIMARY KEY (`player_id`)
) ENGINE= MyISAM DEFAULT CHARSET=utf8;
12
Ahora creamos nuestra base de datos federada llamada “BD_federada”, la cual va a contener otra
tabla llamada “Jugador_federada” que va a tener federación con la tabla “jugador”, que pertenece
a nuestra primera base de datos.
CREATE DATABASE IF NOT EXISTS BD_federada;

USE BD_federada;
CREATE TABLE `Jugador_federada` (
`player_id` INT(11) NOT NULL DEFAULT '0',
`player_api_id` INT(11) NULL DEFAULT NULL,
`player_name` VARCHAR(80) NULL DEFAULT NULL,
`player_fifa_api_id` INT(11) NULL DEFAULT NULL,
`birthday` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
`height` INT(11) NULL DEFAULT NULL,
`weight` INT(11) NULL DEFAULT NULL,
PRIMARY KEY (`player_id`)
) ENGINE=FEDERATED DEFAULT CHARSET=utf8
CONNECTION=’mysql://root:*@155.210.68.183:3306/Eu_So_Herencia/Jugador;
La tabla federada que se acaba de crear posee los mismos datos que la tabla remota a la cual
consulta (Jugador). Tendremos en cuenta los siguientes aspectos:
• Para que el servidor MySQL en el esclavo pueda tener acceso a la tabla, el servidor MySQL
maestro debe estar corriendo. La máquina no puede estar apagada, ya que es un enlace en
tiempo real.
• Las tablas se pueden llamar distinto, lo que importa es la cadena de conexión a la tabla
remota.
• Si se elimina la tabla federada en el esclavo, se mantienen el maestro.
• Tanto el servidor remoto como el local tienen acceso a la tabla.
9. JUSTIFICACIÓN DEL SGBD ELEGIDO
Una vez realizado el análisis de los diferentes gestores de bases de datos, destacamos dos
alternativas que destacan por encima del resto, (MySQL y PostgreSQL) desechando, entre otras, la
opción de Oracle ya que su utilización e implementación es más compleja y costosa.
Ahora vamos a realizar una comparación más exhaustiva de estas dos alternativas elegidas,
comparando diferentes aspectos entre ellas:
• Modelo de licencia y precio: la licencia dual de MySQL va a ser un aspecto a tener en

cuenta si alguien se interesa por nuestra aplicación (si quieres vender o distribuir un
sistema que se conecta en MySQL, con el cliente oficial, debes liberar tu código o pagar a
Oracle), mientras que la licencia BSD que posee PostgreSQL, no nos limita ningún aspecto.
13
• Conexión desde PHP: Ambos SGBD siempre han incluido soporte para PHP, ya bien con
funciones especiales que aprovecharan al máximo sus características, o bien con librerías
PEAR que soportan ambos SGBD a la perfección.
• Prestaciones en creación de las estructuras (tablas, índices, etc.): MySQL es fácil de

manejar en cuanto a estos aspectos, y aunque no ofrece todas las prestaciones como
PostgreSQL, sí que cubre nuestras necesidades.
• Prestaciones en consultas simples: es una de las principales características que hace que
tanto MySQL como PostgreSQL sean uno de los SGBD mejor posicionados.
• Prestaciones en consultas complejas: Aunque en sus inicios MySQL no incluía soporte para
realizar subconsultas, en la actualidad ya soporta éstas y por tanto, está a la altura de sus
mayores competidores como es PostgreSQL que siempre ha mantenido esta característica.
• Facilidad en la administración de usuarios: En cuanto a MySQL, soporta muy bien el

estándar en cuanto a la creación de usuarios y la gestión de sus privilegios con GRANT Y
REVOKE. Además, todos estos datos están accesibles en tablas de sistema, lo que hace
muy sencilla la verificación de permisos, todo lo contrario que en el caso de PostgreSQL, el
cual, su sistema múltiple de autenticación, lo hace demasiado complejo en este aspecto.
9.1 CONCLUSIÓN
Como conclusión parece que MySQL es más estable y PostgreSQL tiende a desperdiciar memoria y
sobrecargar bastante el sistema.
Parece ser que MySQL junto con APACHE Y PHP forman un buen equipo para servir páginas webs
con contenido dinámico.
En general, sistemas en los cuales la velocidad y el número de accesos concurrentes es algo

primordial y la seguridad no sea muy importante (basta con hacer backups periódicos).
14
En cambio para sistemas más serios como PostgreSQL la
consistencia de la BD es fundamental (información realmente
importante, bancos, etc…), es una mejor opción pese a su
mayor lentitud.
Finalmente nos hemos decantado por MySQL debido a una

serie de razones:
• Mayor rendimiento y mayor velocidad al conectar

con el servidor.
• Mejores utilidades de administración (backups).
• Mejor integración con PHP.
• Posee un mayor control de acceso y se comporta

“mejor” que PostgreSQL a la hora de modificar o
añadir campos a una tabla “en caliente”.
• No hay límite en el tamaño de los registros.
Recapitulando:
PostgreSQL funciona más rápido en bases de datos grandes, ya sea en sistemas web o de escritorio.
MySQL es el más rápido en los sistemas web pequeños (que trabajan con PHP), porque es más
rápido que PostgreSQL en ese aspecto. Los servicios de hosting LAMP (Linux + Apache + MySQL +
PHP) con los que más abundan en este momento en el mercado.
✓ Para la escala vertical (más recursos a la máquina, mayor rendimiento con alto volumen
de información), las situaciones de misión crítica, permite lanzar queries tanto de lectura
como de escritura al mismo tiempo para evitar esperar por tablas bloqueadas mientras son
actualizadas, PostgreSQL.
✓ Para la escala horizontal (más servidores), aplicaciones sencillas basadas en lectura de
tablas con queries no demasiado complejas MySQL.
15
10. ÁRBOL DE DECISIÓN
Tras analizar los datos de interés generados podremos crear un modelo de predicción para
representar y categorizar la siguiente serie de condiciones que podrá resolver si podrías ser un
buen jugador dada unas condiciones iniciales.
11. BIBLIOGRAFÍA
1. https://developers.google.com
2. https://www.smartdraw.com/software/tree-diagram-software.htm
3. http://blogs.ua.es/labseps/2015/09/23/tablas-federadas-en-mysql/
4. http://www.wetec.es/mysql-vs-postgresql/
5. https://www.percona.com/blog/2017/01/06/millions-queries-per-second-postgresql-and-
mysql-peaceful-battle-at-modern-demanding-workloads/
6. https://moodle2.unizar.es/add/pluginfile.php/1437581/mod_resource/content/2/913.pdf
16

European Soccer DB

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

European Soccer DB

Загружено:

Авторское право:

Доступные форматы

EUROPEAN SOCCER

ALBERTO ROBLES, ALEJANDRO PEREZ, ALVARO HUARTE

En el tema de orientación a objetos no hemos encontrado mucha información al respecto por

• Posee una gran velocidad de respuesta.

También posee una serie de limitaciones importantes:

• No considera las claves ajenas. Ignora la integridad referencial, dejándola en manos

Las ventajas más significativas que hemos encontrado de PostgreSQL:

• Alta concurrencia e integridad transaccional.

Los inconvenientes más destacados son:

• Más lento en operaciones de escritura que MySQL.

• Manipulación de datos de forma rápida, flexibilidad y buen desempeño.

• No posee agrupamiento de objetos, está diseñada para un tipo de objetos.

Aquí vamos a hablar un poco de la OO de la versión 9i de Oracle. Esta es la primera versión de

No soporta la herencia múltiple, cuando se produce el polimorfismo solo se puede heredar un

1.SOFTWARE DISEÑO E/R DEREDITOR HTTP://DEREDITOR.SOURCEFORGE.NET

Clave Primaria: {id}

LIGA (league_id: dom_id, country_id: dom_country_id, name: dom_name)

Clave Primaria: {id}

Clave Ajena: {country_id} hace referencia a PAIS

PARTIDOS (match_id: dom_id, season: dom_season, stage: dom_stage, date: dom_date,

Clave Primaria: {match_id}

Clave Ajena: {team_id} hace referencia a EQUIPO

Clave Ajena: {team_id} hace referencia a EQUIPO

Clave Ajena: {league_id} hace referencia a LIGA

Clave Ajena: {player_id} hace referencia a JUGADOR

EQUIPO (team_id: dom_team_id, team_api_id: dom_team_api_id, team_fifa_api_id:

Clave Primaria: {team_id}

ATRIBUTOS_EQUIPO (id: dom_id, team_attributes_id: dom_team_attributes_id,

Clave Primaria: {id}

Clave Ajena: {team_id} hace referencia a EQUIPO

JUGADOR (player_id: dom_player_id, player_api_id, player_name: dom_player_name,

Clave Primaria: {player_id}

PORTERO (player_id: dom_team_id, gk_reflexes: dom_gk_reflexes)

Clave Primaria: {player_id}

Clave Ajena: {player_id} hace referencia a JUGADOR

DEFENSA (player_id: dom_team_id, aggression: dom_aggression)

Clave Primaria: {player_id}

Clave Ajena: {player_id} hace referencia a JUGADOR

CENTROCAMPISTA (player_id: dom_team_id, interceptions: dom_interceptions)

Clave Primaria: {player_id}

Clave Ajena: {player_id} hace referencia a JUGADOR

DELANTEROS player_id: dom_team_id, agility: dom_agility)

Clave Primaria: {player_id}

Clave Ajena: {player_id} hace referencia a JUGADOR

ATRIBUTOS_JUGADOR (id: dom_id, player_attributes_id: dom_player_attributes_id,

Clave Primaria: {id}

Clave Ajena: {player_id} hace referencia a JUGADOR

5.1 Cálculo relacional de tuplas T.S

∀ Jx(J(Jx)  (ƎDELx(DEL(DELx) ^ DELx.player_id = Jx.player_id) v

(ƎCx(C(Cx) ^ Cx.player_id = Jx.player_id) v

(ƎDEFx(DEF(DEFx) ^ DEFx.player_id = Jx.player_id) v

(ƎPx(P(Px) ^ Px.player_id = Jx.player_id)))

5.2 Herencia Exclusiva MySQL

CREATE DEFINER=`root`@`%` TRIGGER `completaAuto`

CREATE DEFINER=`root`@`%` TRIGGER `exclusivoDefensa`

2. SOFTWARE DISEÑO LENGUAJE UNIFICADO DE MODELADO (UML) STAR UML

8. BASES DE DATOS DISTRIBUIDAS

Este procedimiento es muy costoso y complicado

- Bi-procesamiento, es decir, poseen la capacidad de atender consultas globales.

8.2 FEDERADAS EN MYSQL

Vamos a utilizar la tabla jugador de nuestra base de datos creada anteriormente

CREATE TABLE `Jugador` (

CREATE DATABASE IF NOT EXISTS BD_federada;