PDF de programación - Caso de estudio

Caso de estudio

Marc Gibert Ginesta

P06/M2109/02154

© FUOC • P06/M2109/02154

Índice

Caso de estudio

Introducción .............................................................................................. 5

Objetivos ..................................................................................................... 6

1. Presentación del caso de estudio ..................................................... 7

2. El modelo relacional y el álgebra relacional ............................... 8
2.1. Determinar las relaciones ................................................................. 8
2.2. Definición de claves ......................................................................... 9
2.3. Reglas de integridad .......................................................................... 11
2.4. Álgebra relacional ............................................................................. 12

3. El lenguaje SQL .................................................................................... 13
3.1. Sentencias de definición ................................................................... 13
3.2. Sentencias de manipulación ............................................................. 15

4. Introducción al diseño de bases de datos ..................................... 17
4.1. Diseño conceptual: el modelo ER ..................................................... 17
4.2. Diseño lógico: la transformación del modelo ER

al modelo relacional ......................................................................... 19

5. Bases de datos en MySQL ................................................................... 22

6. Bases de datos en PostgreSQL ........................................................... 24

7. Desarrollo de aplicaciones en conexión con bases

de datos .................................................................................................. 25

Resumen ...................................................................................................... 30

© FUOC • P06/M2109/02154

Introducción

5

Caso de estudio

Este módulo forma parte del curso “Bases de datos” del itinerario “Administra-
dor web y comercio electrónico” dentro del Máster Internacional de Software
Libre de la Universitat Oberta de Catalunya.

El módulo está estructurado en apartados que corresponden al resto de los mó-
dulos de la asignatura, de modo que el estudiante puede ir siguiendo este caso
de estudio a medida que va progresando en el curso.

Aunque algunos de los módulos ya disponen de ejercicios de autoevaluación,
el caso de estudio presenta una visión completa de un proyecto de bases de
datos y proporciona una visión práctica de cada uno de ellos.

© FUOC • P06/M2109/02154

6

Caso de estudio

Objetivos

Los objetivos que deberíais alcanzar al finalizar el trabajo con la presente uni-
dad son los siguientes:

• Comprender desde un punto de vista práctico los conceptos explicados en

las unidades didácticas teóricas.

• Disponer de un modelo de referencia para emprender proyectos de bases

de datos.

• Adquirir el criterio suficiente para identificar las actividades clave y tomar

decisiones en un proyecto que implique el uso de bases de datos.

© FUOC • P06/M2109/02154

7

Caso de estudio

1. Presentación del caso de estudio

Acabamos de entrar a trabajar en una pequeña empresa –SuOrdenadorAMedi-
da, S.L.– dedicada a la venta de ordenadores a particulares y otras empresas.
Cuando nos hicieron la entrevista de trabajo, comentamos nuestra pasión por
el software libre y en concreto hicimos hincapié en nuestro conocimiento de
los motores de bases de datos libres y las ventajas que podían aportar respecto
de los gestores propietarios. No sabemos si eso fue lo que convenció a la per-
sona de recursos humanos o no, pero, en todo caso, y visto el resultado de la
reunión que hemos tenido en nuestro primer día de trabajo, vamos a tener
que aplicar nuestros conocimientos a fondo.

Nos han contado que, hasta ahora, la gestión de la empresa se llevaba a cabo
con programas propietarios de gestión y contabilidad, pero que debido a pro-
blemas con la empresa que desarrollaba estos programas, se está considerando
la migración de la gestión administrativa y de operaciones a entornos abiertos.
Para acabar de decidirse, nos proponen que empecemos por renovar el sistema
de gestión de peticiones e incidencias por parte de los clientes, de modo que
esté basada en software libre.

Actualmente, las peticiones e incidencias se reciben telefónicamente, por co-
rreo electrónico o en persona en alguno de los locales que tiene la empresa. La
persona que atiende al teléfono o lee los correos electrónicos de plantea una
serie de preguntas al cliente y escribe en una plantilla de documento las res-
puestas. A continuación, se imprime el documento y se deja en una bandeja
que recogen los técnicos cada mañana.

A medida que los técnicos van avanzando en la solución de la incidencia (o han
llamado al cliente para pedir más datos), van apuntando las acciones y el estado
del problema en la hoja que recogieron, hasta que la incidencia queda resuelta.
En ese momento, la dejan en una bandeja que recoge cada mañana el personal
de administración, que se pone en contacto con el cliente y factura el importe
correspondiente a las horas de trabajo y componentes sustituidos.

Es obvio que este sistema presenta numerosas deficiencias, y que el rendimien-
to tanto de los técnicos, como del personal administrativo y de atención al
cliente podría aumentar enormemente si muchos de estos procesos fueran au-
tomáticos, centralizados y, a poder ser, conectados con el resto del sistema de
información de la empresa.

Éste es, a grandes rasgos, el problema que se nos plantea, y que utilizaremos
como caso de estudio para aplicar los conocimientos adquiridos durante el de-
sarrollo del curso.

© FUOC • P06/M2109/02154

8

Caso de estudio

2. El modelo relacional y el álgebra relacional

Visto el proyecto planteado, decidimos hacer las cosas bien hechas para, de
paso, impresionar a nuestro jefe con nuestros conocimientos en bases de da-
tos. El primer paso será presentarle un documento que describa el modelo
relacional que vamos a utilizar, en el que incluiremos algunas consultas de
muestra para que pueda comprobar qué será capaz de hacer con nuestro pro-
yecto cuando esté acabado.

2.1. Determinar las relaciones

En primer lugar determinaremos las relaciones, sus atributos y los dominios
de cada uno de ellos:

PETICION(referencia, cliente, resumen, estado, fecharecepcion, fechainicio, fechafin,
tiempoempleado)

NOTA_PETICION(peticion, nota, fecha, empleado)

MATERIAL_PETICION(nombrematerial, peticion, cantidad, precio)

CLIENTE(nombre, nif, telefono, email)

EMPLEADO(nombre, nif)

En la relación PETICION, hemos decidido que convendría tener una referen-
cia interna de la petición, que nos ayudará al hablar de ella con el cliente (si
tuviese varias abiertas) y evitará confusiones al trabajar. El resto de atributos
son bastante explícitos.

Como una petición puede evolucionar con el tiempo, a medida que se piden
más datos al cliente, la incidencia va evolucionando, etc., hemos creado las re-
laciones NOTA_PETICION y MATERIAL_PETICION para reflejarlo.

También hemos tenido que definir las relaciones CLIENTE y EMPLEADO para
poder relacionarlas con las peticiones y las notas que se vayan generando du-
rante su resolución.

A continuación vamos a definir los dominios de los atributos:

PETICION:

dominio(referencia)=números

dominio(cliente)=NIF

© FUOC • P06/M2109/02154

9

Caso de estudio

dominio(resumen)=texto

dominio(estado)=estados

dominio(fecharecepcion)=fechayhora

dominio(fechainicio)=fechayhora

dominio(fechafin)=fechayhora

dominio(tiempoempleado)=horasyminutos

NOTA_PETICION:

dominio(peticion)=números

dominio(nota)=texto

dominio(fecha)=fechayhora

dominio(empleado)=NIF

MATERIAL_PETICION:

dominio(nombrematerial)=nombreMaterial

dominio(peticion)=números

dominio(precio)=precio

dominio(cantidad)=números

CLIENTE:

dominio(nombre)=nombreCliente

dominio(nif)=NIF

dominio(telefono)=teléfonos

dominio(email)=emails

EMPLEADO:

dominio(nombre)=nombreEmpleado

dominio(nif)=NIF

Al definir los dominios de cada atributo, ya nos hemos avanzado en la toma
de algunas decisiones: al decidir, por ejemplo, que el dominio del atributo em-
pleado en la relación NOTA_PETICION es NIF, estamos implícitamente deter-
minando que la clave primaria de la relación EMPLEADO será del dominio NIF
y que usaremos un atributo de este dominio para referirnos a él.

Este proceso descrito indicando directamente su resultado, normalmen-
te es fruto de una revisión de las entidades a medida que se van defi-
niendo y analizando las necesidades de éstas.

2.2. Definición de claves

Aunque algunas claves ya se intuyen a partir de los atributos de las relaciones,
vamos a determinarlas para completar el caso.

Nota

La regla de integridad del mode-
lo correspondiente a la clave pri-
maria obligará a que no existan
dos notas sobre la misma peti-
ción hechas en la misma fecha
y hora por parte del mismo em-
pleado, lo cual es perfectamente
lícito y coherente.

© FUOC • P06/M2109/02154

10

Caso de estudio

En todos los casos sólo tenemos
una clave candidata y, por lo tanto,

no caben dudas a la hora de

escoger la clave primaria. Esto no
tiene por que ser así: en la relación

EMPLEADO, podríamos haber

incluido más atributos (número de
la seguridad social, un número de
empleado interno, etc.) que serían

claves candidatas susceptibles

de ser clave primaria.

PETICION:

Claves candidatas: {referencia}

Clave primaria: {referencia}

NOTA_PETICION:

Claves candidatas: {peticion,fecha,empleado}

Clave primaria: {peticion, fecha,empleado}

MATERIAL_PETICION:

Claves candidatas: {nombrematerial,peticion}

Clave primaria: {nombrematerial,peticion}

CLIENTE:

Claves candidatas: {nif}

Clave primaria: {nif}

EMPLEADO:

Claves candidatas: {nif}

Clave