Embedded Files
A partir de ahora vas a trabajar con un esquema de base de datos ya creado: "Tienda" o "La Tienda". Negocio electrónico de venta por Internet de productos de alto valor gastronómico, totalmente ficticio. De hecho no puedes fiarte de este esquema si lo que quieres es montar tu propio negocio, lo que aquí vas a manejar está diseñado por su aportación docente, no por su fidelidad a un caso real.
El esquema en sí puedes descargártelo aquí, pinchando sobre el siguiente enlace con el botón derecho del ratón y eligiendo "guardar enlace como...": esquema.txt. Solo tienes que abrirlo, seleccionar todo el texto y pegarlo en una consulta de HeidiSQL conectada a tu servidor MariaDB, por supuesto, arrancado previamente. Ejecuta lo pegado, refresca el panel izquierdo de HeidiSQL y verás la nueva base de datos.
El siguiente paso es rellenar las tablas de datos, de filas. Los datos los puedes descargar desde aquí: datos.txt. Siguiendo los mismos pasos que antes, ejecuta estas órdenes en HeidiSQL y tendrás la base de datos de ejercicios completa.
Te damos ahora una descripción gráfica de ese esquema para entender con qué vas a trabajar.
La base de datos almacena información sobre el sistema de pedidos de una tienda electrónica. Cada uno de los cuadros tiene su correspondencia con una tabla del esquema Tienda. Por ejemplo, los usuarios tienen email, nombre, apellidos, etc. "Email", resaltado en negrita, es el identificador de los usuarios, no hay 2 usuarios que tengan la misma dirección de correo electrónico y todos tienen email. El resto de atributos pueden tener valor o no en cualquier fila de usuario —cualquier usuario almacenado—.
Los usuarios viven en localidades. Como las localidades se identifican por (provincia,codloc), necesitamos 2 columnas en usuario (provincia, localidad) para especificar en qué localidad vive cada uno. Debido a que estas son columnas de usuario, cada usuario solo puede "vivir en" una única localidad. Obviamente, cada usuario vivirá en la suya, no necesariamente todos los usuarios en la misma.
A su vez, las localidades "están en" provincias. Cada localidad en su provincia. Necesitamos una referencia a la tabla PROVINCIA y es la columna "provincia" de Localidad. En esta columna se guardan los códigos de provincia de cada localidad.
Los artículos, con código ("cod"), nombre y precio, además tienen un código que indica la unidad de medida. Las unidades son kilos, litros, gramos, etc. O "unidades", el artículo se vende por unidades, como un jamón que se suministra por piezas enteras —en nuestra tienda; recuerda que este esquema no es del todo real—. En ARTÍCULO se especifica el código y la descripción del mismo en UNIDAD. Por ejemplo, ("k","kilos") sería una de las filas de esta tabla.
Los artículos no se venden tal cual, se venden en un determinado empaquetado. Por ejemplo, un empaquetado de jamón contendrá un único artículo, el jamón. Los chorizos se empaquetan por kilos. Otro empaquetado podría contener varios artículos diferentes, como un muestrario de degustación. En cualquier caso, cada EMPAQUETADO "contiene" ARTÍCULOS. Esto se guarda en la base de datos con una tabla auxiliar CONTIENE que mantiene referencias a las dos tablas anteriores. De esta forma se consigue que un paquete contenga varios artículos y que un artículo pueda aparecer en paquetes diversos.
Llegamos, finalmente, a la parte de pedidos propiamente dicha. PEDIDO mantiene los datos generales de cada pedido: quién lo pide, cuándo y el código de la empresa de transporte que se lo llevara a su casa. Este código es un enlace a la tabla TRANSPORTE donde se almacenan nombre y URL de cada empresa con la que trabaja nuestra tienda.
Los pedidos contienen líneas de pedido, LINPED. Usando el número de pedido como referencia, cada uno puede contener varias líneas de pedido. Cada una de estas hace referencia a un EMPAQUETADO. Que el nombre de la columna no te confunda, LINPED.articulo es, en realidad, un código de EMPAQUETADO.
Evidentemente, esta ayuda gráfica tiene su traslación a verdaderas tablas, la de esquema.txt, del que mostramos un extracto aquí.
Hay algunas cosas que no necesitas saber o que, simplemente, te puedes creer.
DROP TABLE IF EXISTS xxxx se utiliza para borrar una tabla antes de crearla, si es que fuera necesario. Lo único que hace es prevenir que se produzca un error en la siguiente orden CREATE TABLE xxxx, las creaciones de tabla no "machacan" lo que hubiera antes, no se puede crear lo que ya está creado.
A continuación, la lista de columnas. El nombre de columna viene seguido por un tipo de datos y, en algunos casos, por una restricción NOT NULL (no admite valores nulos) o un valor por defecto (DEFAULT).
Al final de cada tabla, las restricciones generales: clave primaria y, si las hubiere, claves ajenas. La clave primaria identifica a cada fila con un valor único que siempre existe. Las claves ajenas son referencias a filas en otras tablas, aunque no vamos a profundizar en su papel en una base de datos relacional. De hecho, verás que apenas las nombraremos en las lecciones que han de venir.
DROP TABLE IF EXISTS provincia;
CREATE TABLE IF NOT EXISTS provincia (
codp char(2) NOT NULL,
nombre char(25) NOT NULL,
PRIMARY KEY (codp)
);
DROP TABLE IF EXISTS localidad;
CREATE TABLE IF NOT EXISTS localidad (
provincia char(2) NOT NULL DEFAULT '',
codloc char(4) NOT NULL DEFAULT '',
nombre varchar(80) DEFAULT NULL,
PRIMARY KEY (provincia,codloc),
CONSTRAINT localidad_ibfk_1 FOREIGN KEY (provincia) REFERENCES provincia (codp)
);
DROP TABLE IF EXISTS usuario;
CREATE TABLE IF NOT EXISTS usuario (
email varchar(50) NOT NULL,
nombre varchar(35) NOT NULL,
apellidos varchar(55) NOT NULL,
dni varchar(12) NOT NULL,
telefono varchar(15) DEFAULT NULL,
calle varchar(45) DEFAULT NULL,
codpos varchar(5) DEFAULT NULL,
provincia char(2) DEFAULT NULL,
localidad char(4) DEFAULT NULL,
nacido date DEFAULT NULL,
PRIMARY KEY (email),
UNIQUE KEY dni_UNIQUE (dni),
CONSTRAINT FK_usuario_loc FOREIGN KEY (provincia, localidad) REFERENCES localidad (provincia, codloc)
);
Report abuse