0. Introducción.

1. Diseño
2. Administración. Motor de datos (Postgresql:libre, Oracle:indra)
3. SQL en ambiente transaccional: Programar y poner en funcionamiento las bases de datos.
(Structured Query Language)

INTRODUCCIÓN
Base de datos​: sistema para almacenar información y poder almacenarla. Deben de cumplir
una serie de características.
Las BBDD aparecieron entre los 60-70. Al principio estaban compuestas de archivos, lo cual
conllevaba una serie de limitaciones:
1. Falta de coherencia: No tenían una estructura fija. Por ejemplo podrías introducir un
teléfono con 8 dígitos.
2. Permitían la redundancia: No revisaban la duplicidad de información.
3. Falta de seguridad.
4. Concurrencia. No permitían modificaciones simultáneas.

Ante estas carencias de los archivos aparecieron:

- Un SGBD o Motor de BD: Se trata de un programa que hace de intermediario entre
los usuarios y los datos.
El motor o gestor de BBDD es único y solo se encuentra en un sitio. (Varios usuarios
pueden acceder a las BBDD desde distintos dispositivos, pero lo que es el gestor solo
está en un dispositivo).
 * SQL es el “lenguaje” en el que los usuarios se comunican con el gestor.
*Los usuarios no tienen el motor en cada ordenador, existe otro “programita” que
permite usar los datos a través del único motor de BBDD. (servidor-cliente)

DISEÑO DE BASES DE DATOS

Niveles de diseño:
- Nivel conceptual:​ Vale para cualquier motor
- Nivel lógico: ​cada motor necesita una estructura
- Nivel físico:​ como se guardan los datos, lo hace el SGBD
En los años 70 había 3 maneras tipos de motores para trabajar con BBDD
- relacional
- jerárquico
- red
Para cada tipo de motor se necesitaba una estructura diferente de BBDD. Finalmente
apareció el diseño conceptual que podía derivar para los tres tipos de motores.
A día de hoy, los motores jerárquico y lógico ya no se utilizan, pero se ha extendido tanto el
motor conceptual que se siguen usando los los tipos de motores
● Conceptual
● Relacional

EL MODELO DE DISEÑO A NIVEL CONCEPTUAL

Lo creó Peter Chen en el 1976. El modelo se llama​ Entidad-Relación.

Este modelo tiene varios objetos que pretenden representar la realidad.

Las entidades son tipos de datos que se representan con cuadrados o rectángulos siempre
van en singular. Las entidades se relacionan entre sí mediante un rombito denominado
relación.
Las entidades y las relaciones son los elementos principales del diseño conceptual.

1. ENTIDAD

Las propiedades de las entidades se denominan ATRIBUTOS. Se interpretan a través de

líneas de conexión con círculos.

Existe un atributo especial denominado clave, que se interpreta gráficamente con un círculo
relleno. Se trata del elemento que identifica de manera unívoca a la entidad.
Puede haber más de un atributo clave. En este caso el diseñador debe de escoger cual va a
ser la clave principal, el resto serán claves candidatas.

Es obligado que toda entidad tenga un atributo clave principal. Si por falta de información no
tuviéramos un atributo clave creariamos una clave subrogada.
Este atributo subrogado se usa muchísimo y aún existiendo un clave principal legítimo en
muchas ocasiones usaremos un atributo subrogado. (ejemplo banco)
La clave principal puede estar compuesta por dos o más atributos.
*Cuando este sucede se suele usar un atributo subrogado
Características de atributo clave:
 - No permite repetidos
- No permite datos nulos
- Debe de identificar de forma unívoca cada elemento de la entidad
- La clave debe de ser mínima, o sea, debe de estar formada por el menor número de
elementos. OJO el mínimo no es comparativo

Ejemplo

cod_libro nombre
23 libroA
27 libroB

2. ATRIBUTO COMPUESTO
Son atributos compuestos por subatributos, un ejemplo claro sería una dirección. El
diseñador puede decidir si lo usamos o no:

3. ATRIBUTO CLAVE FORÁNEA

Se trata de un atributo que es clave en otra entidad. A nivel de diseño no se usan, se usan a
nivel implementación del diseño.
Las claves foráneas ​se usan para unir​ tablas.
No se presentan como atributos.

4. RELACIONES
Las relaciones se representan con rombos.

Tipos de Relaciones:
- 1:1
- 1:N
- N:M
Se mira cada lado por separado suponiendo 1 para la primera entidad que vayamos a evaluar
la relación y el valor que indique el tipo de relación para la segunda.
Se representa de manera gráfica poniendo la relación sobre el rombo y añadiendo flechas en
la parte donde haya >1 (refuerzo gráfico).

5. LA CARDINALIDAD
Debe expresar los valores máximos y mínimos de la relación.

Los máximos los da la propia relación, solo hay que pensar el mínimo.
*Los 1 son restricciones que van a acotar nuestro modelo.

Ej1. Se desea modelizar un colegio para conocer los datos de los alumnos y en qué aulas
están.
 *Un aula tiene entre 0 y N alumnos.
Y un alumno está como mínimo en 1 aula y como máximo en 1 aula

6. TRADUCIR UN MODELO CONCEPTUAL A TABLAS.

Todas las entidades se transforman en tablas.

Las relaciones pueden o no traducirse a tablas dependiendo de su tipo:
1:N →​ No se crea tabla sino que al “lado N” se le añade la foreign key, clave “del lado 1”.
​ 1:1 → ​ Se procede igual que en la relación 1:N, pero en el sentido que queramos.
​N:M → ​En este caso hay que crear una nueva tabla. ​En esta nueva tabla se tienen que
poner las claves principales de ambas entidades que relaciona.​ Este conjunto de
atributos formarán la clave (candidata o no) de esta tabla de la relación. *​*Las relaciones
pueden tener atributos.
**De modo que las claves de ambas entidades son claves foráneas de la tabla de la
relación.
La tabla de la relación se llama: Entidad1-Entidad2.

**​Las claves principales y candidatas siguen las normas definidas anteriormente. Las
foráneas no.

**​Las cardinalidades fijan los límites de las relaciones, los máximos de estas vienen dadas
por el tipo de relación.

**​Cuando la cardinalidad mínima=1 equivale a una restricción que luego nos puede complicar la
implementación del modelo.

**​Las claves foráneas exigen que el valor que se le asigne exista en la tabla donde la foránea
es clave

Ej2
 Se intenta hacer un modelo entidad-relación para guardar los datos de facturas.
● Los datos de la empresa van a ser siempre los mismos, no sería necesario poner sus
datos (en este caso)
● Recuerda: las cardinalidades son “de al revés”.
● Las cardinalidades con mínimo 1 SON RESTRICCIONES. El motor no contemplaba
aquel factor que no tenga al menos un elemento al que se refiere la restricción.
● Al representar en tablas hay que tener en cuenta el tipo de restricciones (foreign
key)
● Tablas Maestro detalle: Conjunto de dos tablas. La segunda nos ofrece los detalles de
la primera

Observación: El total inicial y total final deberían de no existir. La ventaja de esto sería no que
tendríamos que estar actualizando la cuantía, O sea, que aquellos atributos que haya que calcular a
través de otros atributos los omitimos.
La desventaja de esta medida es que para luego analizar los datos no dan resultados exactos ( va a
haber que crear un programita que nos dé ese resultado.)

Ej3
Se desea diseñar una base de datos para una escuela. Profesores, alumnos, matriculaciones,
asignaturas…

+ El mínimo 1 en las cardinalidades: hay que tener cuidado. Al ponerlo el motor no

permite introducir info que no cumpla la restricción. No solo al analizarla sino al
introducirla.
+ Una entidad no debe de tener información de varias cosas, para eso creamos 2
entidades (Ojo con esta afirmación)
+ Las relaciones pueden tener atributos.
+ Cuando hay que implementar datos comunes que pueden varias en vez de poner un
atributo creamos una nueva entidad. (ejemplo: Curso)
+ Puede haber relaciones de 3 entidades: ternarias.
+ Todas las entidades tienen que tener al menos 1 clave
+ Las tablas que provienen de relaciones N:M tienen 2 (ó +) claves foráneas que se
juntan para formar la clave de la tabla.
+ Las claves foráneas implican que los valores van a estar restringidos a los valores de la
tabla donde es clave.
 7. MODELO E.R.EXTENDIDO.

Este modelo pretende aclarar la semántica del modelo E-R. Para esto añade jerarquías entre
entidades, añadiendo entidades débiles y dos tipos de relaciones:

1. ENTIDAD DÉBIL
Se representa con dos cuadrados concéntricos. Es aquella que depende de otra entidad para

su existencia. (Ej planeta y satélite) .

Hay dos tipos de relaciones ligadas a una entidad débil.

● De existencia: ​donde la entidad débil tiene clave propia

● De identificación:​ necesita a la entidad fuerte para identificarse . La clave de

la entidad débil está formada por el conjunto de la clave de la entidad fuerte y otro
atributo de la débil. (Esto se representa solo al pasarlo a tablas, nunca en el diseño).

2. LA ESPECIALIZACIÓN.
Se trata de la bifurcación de la entidad en subtipos que heredan los atributos del
“supertipo”, además de tener los suyos propios. ​Heredan SOLO el atributo clave.

+ La finalidad principal de la especialización es el hecho de que ​los atributos se

heredan​ y de esta manera ​no​ ​hay que repetirlos​ constantemente (​ni en el diseño ni
en las tablas)
+ O haces un atributo discriminatorio o montas tablas, en las tablas los hijos solo
llevan la PK!!!!

Tipos de especialización.
 ​Tipo disjunto:​ mutually exclusive. Si es uno no puede ser el otro.

​Tipo no disjunto​: puede ser 1, ó 2 ó 1 y 2. ( no tiene porque ser de manera

simultánea.

Especialización total:​ Para indicar que los elementos de la “superentidad” tienen que
pertenecer por fuerza a uno de los subtipos se representa con una línea doble. (un una línea
simple será especialización parcial)

3. LA GENERALIZACIÓN
Es el concepto contrario a la especialización.

En este caso se trata de ​la unión de varias entidades en una super entidad.
Esta super entidad tiene todos los atributos de ambas subentidades

● TRUCO: La base del triángulo nos indica de dónde proceden los atributos.

4. LA EXCLUSIVIDAD​ (general)
Se dice que una relación es exclusiva cuando​ su existencia​ entre dos entidades ​implica la no
existencia ​de otras relaciones entre ese elemento de la entidad. (Mutually exclusive.)

● Si un profesor recibe un curso jamás impartirá un curso.

5. LA EXCLUSIÓN
En la exclusión se sigue una restricción parecida a la exclusividad pero no afecta al modelo
completo si no a un elemento individual.

El profesor recibe curso X por lo que no puede impartir el curso X pero si puede impartir el
curso Y

6. LA INCLUSIVIDAD​ (general)
Las relaciones tienen ​un sentido.​ Indican que para tener una relación tiene que ​existir una
relación previa​. La flecha va hacia la relación restringida, la relación entre relaciones tiene
una ​cardinalidad​.

● Para que un profesor pueda impartir un curso tiene que haber recibido entre 3 y n
cursos.

7. LA INCLUSIÓN
Sigue la misma línea que la inclusividad, pero la relación entre relaciones afecta de manera
independiente a cada elemento​ de la entidad.

8. RELACIONES REFLEXIVAS
Son relaciones en las que solo interviene una única entidad.
Esto en tablas

Ej 04 Olimpiadas
Las sedes olímpicas se dividen en complejos deportivos. Los complejos deportivos se subdividen e
aquellos en los que se desarrolla un único deporte y en los polideportivos. Los complejos
polideportivos tienen áreas designadas para cada deporte con un indicador de localización (ejemp
centro, esquinaNE, etc.). Un complejo tiene una localización, un jefe de organización individual y u
área total ocupada. Los dos tipos de complejos (deporte único y polideportivo) tendrán diferentes
tipos de información. Para cada tipo de sede, se conservará el número de complejos junto con su
presupuesto aproximado. Cada complejo celebra una serie de eventos (ejemplo: la pista del estad
puede celebrar muchas carreras distintas.). Para cada evento está prevista una fecha, duración,
número de participantes, número de comisarios. Una lista de todos los comisarios se conservará
junto con la lista de los eventos en los que esté involucrado cada comisario ya sea cumpliendo la
tarea de juez u observador. Tanto para cada evento como para el mantenimiento se necesitará
cierto equipamiento (ejemplo: arcos, pértigas, barras paralelas, etc)
+ Cuando ponemos una entidad débil implica una restricción en su cardinalidad (1,x)
+ El “atributo” discontinuo indica que es un atributo calculado , o sea que no es un
atributo real.
+ Las debilidades de existencia no tienen repercusión al pasar a tabla, las de
identificación sí.
+ Las relaciones ternarias tienen que tenerla misma relación entre todos los elementos
+ Si una relación tiene atributo pasa a haber una tabla de la relación.
+ En la especificación heredan la clave de la superentidad, pero no es necesario usarla,
podemos usar una clave subrogada

+ En la especificación puede haber un atributo en el que va a pertenecer a la

“super entidad”. Este atributo va a ser determinante en la especificación. En este
 ejemplo lo pusimos de prueba (el atributo determinante), pero no lo aplicamos al hacer
tablas, de aplicarlos las 3 entidades estarían en una única tabla

Tablas (Intensión)

SEDE [cod_sede, presupuesto]

10​, 50000

COMPLEJO[cod_complejo, localizacion, area_total, jefe, cod_sede]

1​, zona_A, 3000, Luis Estevez, ​10

EVENTO(cod_evento, fecha, duracion, participantes, cod_complejo]

20​, 22/10/2020, 90, 24, ​1
21, 22/10/2020, 30, 2, ​1

EQUIPAMIENTO[cod_eq, nombre]

COMISARIO[cod_comisario, nombre]
30​, Ana

AREA[codigo, localizacion, cod_complejo]

MONODEPORTE[cod_complejo]

POLIDEPORTE[cod_complejo]

JUEZ[cod_comisario]​ ​(para poder poner un juez, primero hay que intruducir un comisario)
30

OBSERVADOR[cod_comisario]

EVENTO_JUEZ[cod evento, cod_comisario]

30​, ​20

EVENTO_OBSERVADOR[cod_evento, cod_comisario]
EVENTO_EQUIPAMIENTO[cod_evento, cod_equipamiento, cantidad]

EVENTO_COMPLEJO[cod_complejo, cod_equipamiento, cantidad]

+ En la especificación con atributo discriminatorio en el cual las subentidades no tiene

atributos propios que puede hacer una única tabla de la super entidad). No es
necesario hacer una tabla para cada entidad.

Ej 5. Reparto de agua
Aguas de Caraño tiene subempresas que son los distribuidores por zona, el distribuidores
tiene que ir agrandando la cartera de clientes.
Cada distribuidor tiene empleados que reparten el agua, estos clientes pueden tener varias
direcciones.
Los distribuidores necesitan saber para cada cliente que le ha comprado y cuando.
Hay dos productos de 11 y 15 litros.
Los distribuidores tienen visitas programadas por rutas.
Los distribuidores pasan cada semana, a ver a los clientes.
Por cada visita tenemos que apuntar si el cliente estaba ausente, quería agua o no la quería.
+ Si vamos a querer tener más datos de un atributo lo convertimos en entidad. (zona).
+ Si queremos darle una dimensión temporal, tenemos que usar atributos temporales
(fechas) a la relación. No siempre pero suele ser en relaciones N:M.
+ Escogí relacionar cliente con zona por su estabilidad.
+ En este caso NO se puede poner como clave el DNI del cliente ya que el mismo cliente
podría serlo de distintos distribuidores.
+ Entidades en singular!
 + El atributo “orden” de vivienda puede ir en vivienda por la relación 1:N con Ruta. Si
fuera N:M el atributo pertenecería a la relación entre ellos.”pertenece a”.
TABLA
DISTRIBUIDOR[​id_distrib​, nombre, NIF]
TRABAJADOR[​id_trabajador​, login, nombre, id_distrib]
ZONA[​id_zona​]
CLIENTE[​id_cliente​, mail, direc_factura, id_zona]
VIVIENDA[​id cliente, numero,​ ordenRE, id_RE]
RUTAESTABLECIDA[​id_RE, ​id_zona]
RUTAREAL[​id_RR​, fecha_hora_inicio, fecha_hora_fin, id_zona]
PEDIDO[​id_ped​]
ARTICULO[​id_articulo​, precio]
DISTRIBUIDOR-ZONA[​id_distribuidor,​ ​id_zona​, fecha_inicio, fecha_fin]
VISITA[​id_cliente, id_vivienda,​ ​id_RR​, ​id_visita​, estado, ordenRR, fecha_hora, id_ped]
PEDIDO-ARTICULO[​id_articulo,​ ​id_ped​, cantidad, precio_real]

9. AGREGACIÓN.
Convertir una relación en una entidad. Esto se hace para diferenciar una relación ternaria y
una relación entre tres elementos.
Un conjunto de elementos constituye en sí un conjunto de elementos.

● Hay que tener en cuenta que el cambiar un dato cambiará un dato del pasado. (Esto se
usa con elementos cambiantes en el tiempo por ejemplo precio)

MODELO LÓGICO RELACIONAL

En el modelo lógico sólo se expresan las tablas y atributos de estas tablas.

Para definir una tabla se puede usar su intensión o s extensión.
● La extensión es la estructura de la tabla con datos..
Para definir las foráneas se utiliza un gráfico llamado grafo relacional que consiste en poner
las intensiones de la tabla con una flechita desde la foránea hasta donde es clave principal.

NORMALIZACIÓN.​ (wiki)
Toda tabla debe cumplir unas normas para evitar problemas en su manipulación.
Hay hasta la 6ª forma normal, que son escalonadas (son 8).
Nosotros vamos a ver las 3 primeras que son las más comunes.
LA 1ª FN (Requisitos)
- Hay 1 clave principal en funcionamiento.
- Los valores de los atributos son atómicos (Solo puede haber un dato para cada casilla)
LA 2ª FN
- Seguir la 1ª FN
- Los atributos tienen que depender completamente de la clave principal. Si se trata de
una clave no compuesta y cumple la 1° FN estará directamente en 2°FN
LA 3ª FN
- Seguir la 2ª FN
- Evitar dependencias transitivas (depende de otro atributo que no es la clave)

DISEÑO A NIVEL LÓGICO

No es necesario hacer un diseño si dispones de un diseño conceptual. Si no se dispone, sí se
puede diseñar a nivel lógico.
El diseño a nivel lógico solo tiene entidades, las relaciones no son más que flechas para
trasladar la foreign key. Esta notación es la de pata de gallo.
● En el programa Case Studio2 char no se usa ya que es antiguo y con la llegada de
varchar este último no ocupa memoria si no se usan todos sus caracteres.

1. LOS DOMINIOS
Es la creación de un tipo de dato para así facilitar su modificación. Se crean en una “librería”
lo cual permite usar el mismo tipo de datos en diferentes tablas.

2. LOS ÍNDICES
El objeto del índice es mejorar o acelerar el rendimiento en las búsquedas. Es la misma idea
que el índice de un libro. Puede existir o no y será propio de la tabla.
Lo maneja el gestor de la BD y es totalmente transparente para los programas que acceden a
la BD.
NIVEL DE IMPLEMENTACIÓN O NIVEL FÍSICO:
SQL.
Persigue que haya un único lenguaje común a todos los programas clientes.
El SQL es un lenguaje declarativo, no imperativo.(java)
Los lenguajes declarativos dicen los que quieren obtener en vez de como lo quieren obtener.
Tiene 2 sublenguajes:
● DDL: Lenguaje de definición de datos. Lo usan los diseñadores para crear y borrar
estructuras.
● DML: Lenguaje de manipulación de datos. Para los programadores, actualización y
consulta.

DDL (Data Definition Language)

Concepto de schema:Agrupación de las estructuras (tablas, tipos de datos, índices…) en un
mismo contenedor. Puede haber 1 ó más.

● En SQL es distinto el uso de mayus y minus.

● Script: Fichero con órdenes a ejecutar
TRANSACCIÓN: Conjunto de operaciones para llegar a un objetivo que o se hacen todas y
cada una de ellas o ninguna
- Commit: Confirmar que todas las operaciones son válidas y se ha finalizado la
transacción. → Si está bien lo pasa al motor.
- Rollback: Deshacer todas las operaciones de una transacción → Verifica pero no lo
pasa al motor aunque esté correcto

PGAdmin
- drop: borrar
- grant all: darle todos los permisos

- commit: todo bien → transacción

- rollback: algo mal → no hay transacción
- Auto commit: Si esta bien se sube
- Auto rollback: aunque este bien, no se sube

● ¡Ojo! En el orden de las tablas, si en una se referencia a otra, primero se creará la

referenciada.
 ● No es lo mismo guardar el archivo que “subirlo”.
● Cardinalidad mínima 1 → NOT NULL (esta es una forma fácil, hay más)
● En los manuales cuando encontremos:
[] → lo de dentro será opcional
{} → opción a escoger
● on delete cascada: borra los registros
on update cascada: actualiza los registros
de la tabla dependiente cuando se borra o actualiza el registro de la tabla principal.
● Para crear una base de datos de igual estructura que una que ya tengo creada lo que
hago es crear una nueva BD con los ficheros de la primera BD. de manera secuencial.

PRIMARY KEY
Para insertar una PK lo que hacemos es poner (en primera línea) el atributo e indicar que es
una primary key acto seguido.

create table provincia (

nombre_provincia d_nombre ​primary key
);
En caso de que sea una PK compuesta, lo que hay que hacer es introducir normal los
elementos componen la primary y al final poner que la primary key(atrib.1, atrib.2, atrib.3)
create table vehiculos(
patente char(6),
tipo char(4),
horallegada time ,
horasalida time,
​primary key(patente,horallegada)
);

Ej1 002_modificar20201112.sql
Se desean añadir dos columnas a la tabla módulo. Las columnas son ciclo y duración. Hay que
crear dominios para las variables.
*Si te equivocas una vez subida la info tienes que ir al inicio.
create domain d_ciclo as varchar(20);
create domain d_duracion as integer;

alter table modulo

add column ciclo d_ciclo,
add column duracion d_duracion;

Ej2
Camba el dominio nombre a un varchar(50)
*Para cambiar el tipo de un dominio ya en uso la única forma es cambiar en cada tabla
que se haya usado (individualmente) entonces borrarlo y crear uno nuevo volviéndolo a
introducir en cada tabla.
*MEJOR: Creo el segundo dominio y luego borro y pongo DIRECTAMENTE el nuevo en
cada tabla (mongolita)

alter table deporte

alter column nombre type text;

alter table alumno

alter column nombre type text;

alter table modulo

alter column nombre type text;

drop domain d_nombre;

create domain d_nombre2 as varchar(50);

alter table deporte

alter column nombre type d_nombre2;

alter table alumno

alter column nombre type d_nombre2;

alter table modulo

alter column nombre type d_nombre2;

alter domain d_nombre2

rename to d_nombre;

Ej3
Añade la restricción not null al dominio id:
alter domain d_id
set not null;

Ej4
Elimina la foreign de la tabla alumno

alter table alumno

drop constraint alumno_id_deporte_fkey;

*Para eliminar una restricción así^

*PK y FK son restricciones

Ej5
Añade un valor por defecto al atributo ( tb se puede poner al dominio pero OJO que le
pondrá el mismo valor por defecto a todas las tablas que tengas dicho dominio)

alter table modulo

alter column duracion set default 200;

● RECUERDA: Las BD son SECUENCIALES!

● Hay programadores que prefieren poner FK al final del fichero de producción, esto es
porque así no tienen que tener en cuenta el orden de las tablas.
Primero hacen todas las create table y en el mismo archivo, al final, introducen las FK
con alter table

SECUENCIAS (integer)

create sequence s_codigos

…..........
id_provincia default nextval(‘s_codigos)

Generación de códigos secuenciales incrementales.

Se usa para aplicar en tablas, con default nextval(‘s_codigos’)
Se puede indicar en la línea de creación en que nº comienza la secuencia.
TIPO DE DATO SERIAL (integer)
Se trata de un pseudodato, es un atajo que me crea una secuencia (create+default) por lo
que me omite el nextval(‘ ’). No hay manera de indicar con este método donde empezar la
secuencia. SOLO SE USA EN LAS PK.
Uno de los fallos, es a lo referente a seguridad, informa por ejemplo de cuántos usuarios
tengo.
Otro problema de este método viene a la hora de unificar dos bases de datos, ya que se
pueden solapar las claves. Habría que tratarlo antes otorgando un valor manual, ya que serial
se pone por “default”

HASH
Se trata de un código de números y letras que no sigue ningún tipo de correlación. Es casi
imposible que se generen 2 hash iguales. De esta manera el hash cubre la brecha de
seguridad y por otro lado arreglan el problema de solución de claves en la unificación de
tablas.
● El fallo de este elemento es que en BD muy grandes se pierde rendimiento ya que al
motor le cuesta más buscar entre hash→ para solucionarlo cambiar a un servidor más
potente.
Para generar los hash se añade al comienzo del proyecto el “plugin”
create extension if not exist uuide_ossp;
Para implementarlos creamos un dominio (o no) que en vez de integer tenga el tipo “uuid” que
se trata de una combinación de letras y alfanuméricos predefinido:
create domain d_id uuid default uuid_generate_v4();
DML (Data Manufacturing Language)
Las acciones que se gestionan con este lenguaje es:
● CRUD: (Create, Reed, Update, Delate)
- Create: insert into tabla(atributo1, atributo2)
values(numero, ’varchar’);
- Reed: select (*) from tabla;
- Update: update tabla
set atributo = ’bbb’
where nombre = ’dfsf;
- Delete: delete from tabla
where nombre= ‘ fdfd’;

Ej03.Pantalán
Deseamos guardar en un BD info sobre los barcos de un pantalán. Cada barco tiene
matricula, eslora y propietario. El prop. tiene CIF, apellidos, teléfono y mail. Cada barco
está amarrado en una plaza, la plaza tiene un número y una longitud. Se pide:
Haz el DDL de las tablas, un fichero de inicialización, otro de meter datos y otro de
consultas.
1. DIBUJO
2. 001_inicializar.sql
drop schema public cascade;
create schema public;
grant all on schema public to postgres;
create extension if not exists "uuid-ossp";

create domain d_nombre as varchar(20);

create domain d_matricula as varchar(10);
create domain d_numero as integer;

create table propietario ( ​--lo ponemos primero porque luego a la ora de poner
los datos nos va a dar una imagen mas acertada de como meterlos
nombre d_nombre,
cif varchar(9) primary key,
apellido varchar(30),
telefono bigint,
email varchar(25)

);

create table barco (

matricula d_matricula primary key,
 nombre d_nombre,
eslora integer,
cif varchar(9)
);

create table plaza (

numero integer primary key,
longitud integer,
matricula d_matricula
);

alter table barco

add foreign key (cif) references propietario(cif);

alter table plaza

add foreign key (matricula) references barco(matricula);

3. 002_introduccion
insert into propietario(nombre, cif, apellido, email, telefono)
values ('Marta','44425845A','Naveira', 'martanave@gmail.com', '685468912');

insert into propietario(nombre, cif, apellido, email, telefono)

values ('Borja','77725845A','Varela', 'bvar@gmail.com', '611111111');

insert into barco(nombre, matricula, eslora, cif)

values('Hightechs','52478fgd' , '6','44425845A');

insert into barco(nombre, matricula, eslora, cif)

values('Catamaram','6666aaa' , '11', '77725845A');

insert into plaza(numero, longitud, matricula)

values
('1','7','52478fgd');

insert into plaza(numero, longitud, matricula)

values
('2','12','6666aaa');

insert into plaza(numero, longitud, matricula)

values
('3','12',null);

4. 003_select
select * from plaza;
select * from propietario;
select * from barco;
select matricula, nombre from barco ​--PROYECT
order by matricula desc; ​--para ordenar las tuplas segun un atributo, en orden
descendente.

select p.numero, p.longitud from plaza p;

select numero, p.matricula, b.nombre
from plaza p join barco b
on p.matricula=b.matricula;

select *
from plaza p left join barco b
on p.matricula=b.matricula
join propietario pr
on pr.cif=b.cif;

select p.numero, b.matricula, pr.cif, pr.nombre nombre_persona

from plaza p left join barco b
on p.matricula=b.matricula
join propietario pr
on pr.cif=b.cif;

select p.numero, b.matricula, pr.cif, pr.nombre nombre_persona

from plaza p left join barco b
on p.matricula=b.matricula
left join propietario pr
on pr.cif=b.cif
order by b.nombre desc;​-- se pueden ordenar por atributos que no estén en la
tabla

select pr.*, b.matricula

from propietario pr left join barco b
on pr.cif=b.cif
order by pr.nombre;

● El check solo comprueba con valores de la propia FILA o con valores que yo le
introduzca.
● A la hora de poner los datos si usamos(uuid) hash es un follo, al meter los datos
en el elemento que tiene el atributo”problematico” como foreign key → Hay que
poner el hash como uno mas
ALGEBRA RELACIONAL
Las operaciones que podemos hacer con las tablas (son 4). La tablas creadas son virtuales, no
están almacenadas en el disco.

OPERACIONES:
- SELECCIÓN:​ Coger las filas de una tabla (SELECT)
*:coge todos los atributos (columnas)

- PROYECCIÓN:​ coge columnas

- UNIÓN​: Consiste en unir dos tablas para conseguir una nueva tabla. La unión exige
que los tipos de datos de la columna converjan. A esto se le llama que las tablas sean
homogéneas. No es necesario que las columnas se llamen igual pero si que sean del
mismo tipo (en el mismo nombre)
● La tabla tendrá los mismos atributos que las iniciales pero tendrá más filas
(AUN NO SABEMOS HACERLO)
- JOIN:
+ Inner Join: Solo salen en la tabla aquellas tuplas relacionadas, los artículos con
atributos, coincidentes.
+ Outer Join: Salen todas las filas de la tabla que se elija, la que se pongan
primero, estén relacionadas o no. Existe el LEFT join y el RIGHT join

Ej en 003_select.sql Pantalán

select * from plaza;

select * from propietario;
select * from barco;
select matricula, nombre from barco​ ​--PROYECT
order by matricula desc;​ ​--para ordenar las tuplas segun un atributo, en orden
descendente.

select p.numero, p.longitud from plaza p;

select numero, p.matricula, b.nombre

from plaza p join barco b
on p.matricula=b.matricula;

select *
from plaza p left join barco b
on p.matricula=b.matricula
join propietario pr
on pr.cif=b.cif;

select p.numero, b.matricula, pr.cif, pr.nombre nombre_persona

from plaza p left join barco b
on p.matricula=b.matricula
join propietario pr
on pr.cif=b.cif;

select p.numero, b.matricula, pr.cif, pr.nombre nombre_persona

from plaza p left join barco b
on p.matricula=b.matricula
left join propietario pr
on pr.cif=b.cif
order by b.nombre desc;​-- se pueden ordenar por atributos que no estén en la
tabla

select pr.*, b.matricula

from propietario pr left join barco b
on pr.cif=b.cif
order by pr.nombre;

● Cuando se unen más de dos tablas, si se mezcla left join con inner join hay que usar ()
para indicar que tipo de join se usa primero entre que tablas.
● Lo normal es combinar las diferentes operaciones para así obtener el resultado
deseado.

EJERCICIO REPASO.
Comercio.
Las tiendas venden artículos digitalizados usando un cod de barras. El cod puede ser propio
del fabricante o de la tda descripción precio y un IVA
Para facilitar la gestión de los art. se agrupan por tallas y colores.
Además las tdas de comercio trabajan tb con articulos compuestos, un art compuesto por
varios art. El art compuesto tiene un precia que suele ser inferior al de la suma de los art,
tiene descripcion cod y IVA
*No nos importan las cantidades en este modelo
001.inicializar
drop schema public cascade;
create schema public;
grant all on schema public to postgres;
create extension if not exists "uuid-ossp";

create domain d_id as integer;

create domain d_precio as numeric(19,2);
create domain d_cod_tda as varchar(20);
create domain d_cod_fabr as varchar(20);
create domain d_descripcion as varchar(30);
create domain d_nombre as varchar(15);

create table color (

id_color d_id primary key,
nombre d_nombre
);

create table talla (

id_talla d_id primary key
);

create table grupo(

id_grupo d_id primary key,
nombre_grupo d_nombre
);

create table articulo(

id_art d_id primary key,
precio d_precio,
iva integer,
cod_tda d_cod_tda,
cod_fabr d_cod_fabr,
descripcion d_descripcion,
id_color d_id,
id_talla d_id,
id_grupo d_id ,
activo boolean

);

create table articulo_simple(

id_art_simple d_id primary key
);

create table articulo_compuesto(

id_art_compuesto d_id primary key
);

create table art_simple_compuesto(

id_art_simple_compuesto d_id primary key,
id_art_simple d_id ,
id_art_compuesto d_id
--primary key(id_a_simple, id_a_compuesto)

);

alter table articulo

add foreign key (id_color) references color(id_color);
alter table articulo
add foreign key (id_talla) references talla(id_talla);
alter table articulo
add foreign key (id_grupo) references grupo(id_grupo);

alter table articulo_simple

add foreign key (id_art_simple) references articulo(id_art);

alter table articulo_compuesto

add foreign key (id_art_compuesto) references articulo(id_art);

alter table art_simple_compuesto

add foreign key (id_art_simple) references articulo_simple(id_art_simple );
alter table art_simple_compuesto
add foreign key (id_art_compuesto) references articulo_compuesto(id_art_compuesto );

002.insertar.sql
INSERT INTO color(
id_color, nombre)
 VALUES (1, 'azul');

INSERT INTO color(

id_color, nombre)
VALUES (2, 'rojo');

INSERT INTO color(

id_color, nombre)
VALUES (3, 'verde');

INSERT INTO public.talla(

id_talla)
VALUES (1);

INSERT INTO public.talla(

id_talla)
VALUES (2);

INSERT INTO public.talla(

id_talla)
VALUES (3);

INSERT INTO public.grupo(

id_grupo, nombre_grupo)
VALUES (1, 'camisas');

INSERT INTO public.grupo(

id_grupo, nombre_grupo)
VALUES (2, 'pantalones');

INSERT INTO public.articulo(

id_art, precio, iva, cod_tda, cod_fabr, descripcion, id_color, id_talla, id_grupo,
activo)
VALUES (1, 10.50, 21, 32, 1, 'Pantalon estampado de raso', null, null, 2, false );

INSERT INTO public.articulo(

id_art, precio, iva, cod_tda, cod_fabr, descripcion, id_color, id_talla, id_grupo,
activo)
VALUES (2, 12.50, 21, 32, 1, 'Pantalon volantes', null, null, 2, true );

INSERT INTO public.articulo(

id_art, precio, iva, cod_tda, cod_fabr, descripcion, id_color, id_talla, id_grupo,
activo)
VALUES (3, 25.50, 21, 32, 1, 'camisa abullonada', null, null, 1, true );

INSERT INTO public.articulo(

id_art, precio, iva, cod_tda, cod_fabr, descripcion, id_color, id_talla, id_grupo,
activo)
VALUES (4, 40.5, 21, 32, 1, 'Pantalon + Camisa', null, null, null, true );

INSERT INTO public.articulo_simple(

id_art_simple)
VALUES (1);

INSERT INTO public.articulo_simple(

id_art_simple)
VALUES (2);

INSERT INTO public.articulo_simple(

id_art_simple)
VALUES (3);
INSERT INTO public.articulo_compuesto(
id_art_compuesto)
VALUES (4);

INSERT INTO public.art_simple_compuesto(

id_art_simple_compuesto, id_art_simple, id_art_compuesto)
VALUES (1, 2, 4);

INSERT INTO public.art_simple_compuesto(

id_art_simple_compuesto, id_art_simple, id_art_compuesto)
VALUES (2, 3, 4);

003.consultas.sql
--consultas
--nombres precios e iva de todos los artículos
select a.descripcion, a.iva, a.precio
from articulo a;​ --los alias sirven para acortar y ayudar a. (control+espacio),
si lo usas luego tienes que usarlo

--todas las descripciones de los artículos activos

select a.descripcion
from articulo a
where a.activo=true;

--las desc, su precio, y su color (no el id del color sino su nombre!)

select a.descripcion, a.precio, c.nombre
from articulo a left join color c
on a.id_color = c.id_color; ​ --el join siempre va con el on que indica el
atributo por el que se relacionan las tablas

select a.descripcion, a.precio, c.nombre

from articulo a join color c
on a.id_color = c.id_color; ​--con el join normal no me coge los que tienen valor
null (todos en mi caso)

--las descrip, precio talla y color de todos los arts JOIN LEFT ENTRE 3 TABLAS
select a.descripcion, a.precio, t.id_talla , c.nombre
from articulo a
left join talla t
on a.id_talla = t.id_talla
left join color c
on a.id_color = c.id_color;
APUNTACOS!
● Exclusión (independiente al modelo), exclusividad (afecta al modelo completo),
inclusión e inclusividad : relaciona relaciones

● Si pones un id a una tabla o a una entidad, PUTA! ponlo en el diseño JODER!

● OJO!
create domain d_id uuid default uuid_generate_v4();
por que al llevar el id a la foránea de esta manera le estoy diciendo, que en la
entidad donde es foranea si no pongo nada cree un hash para él, y no!
“default uuid_generate_v4();” se pone mejor en la primary key y no en el domain.
Así cuando lo pongamos en la FK, el tipo de dato será uuid pero no se generará
solo
● En la especificación. O haces un atributo discriminatorio o montas tablas, en las
tablas los hijos solo llevan la PK!!!!

LINKS DE INTERÉS
https://bbdd.codeandcoke.com/apuntes:diseno

PDF en grupo de clase

http://ocw.uc3m.es/ingenieria-informatica/diseno-de-bases-de-datos/ejercicios-teoricos/e
jercicios-teoricos