Embedded Files
Detalle y explicaciones sobre el sistema de información
Detalle y explicaciones sobre el sistema de información
El esquema anterior —que por motivos docentes no es el más eficiente ni necesariamente la mejor solución— describe una tienda de artículos relacionados con la electrónica que opera en Internet. De esta forma, el catálogo de productos disponibles se extrae de la base de datos mediante una consulta que se transforma en código HTML para construir una página legible por cualquier navegador. También se supone que se han programado los formularios y procesos necesarios para guardar "cestas de compra" y realizar pedidos, para lo que se necesita, además, información de facturación de los usuarios registrados en el sistema.
Los artículos se identifican por un código ("cod") y mantienen diversa información de entre la que podemos destacar el "pvp" (precio de venta al público). Este precio es el que se muestra en el catálogo de venta al consumidor y no tiene por qué coincidir con el importe cobrado en algún pedido. Piénsese en una subida de precios en marzo, cuando ya se han vendido anteriormente unidades de ese mismo artículo en febrero. También contiene información de descripción del artículo que incluye una imagen en miniatura ("imagen"; "urlimagen" sería un método alternativo de acceso a la misma imagen, la carpeta en la que se encuentra el banco de imágenes en el servidor, por ejemplo).
Los artículos, aparte de los atributos que se muestran en la entidad, también tienen marca, como muestra la relación "fabricado_por". Los artículos siempre tienen marca y solo una. El objeto de la relación es mantener información adicional sobre la marca, como es el nombre de la empresa que fabrica la marca y su logotipo, una imagen que puede ser mostrada en el catálogo.
Algunos artículos están en disponibles en el almacén o pendientes de renovación. Si esto es así, serán del tipo "stock", estarán presentes en la especialización "stock". Esto debe interpretarse como que si no es así, si el artículo no esta presente en "stock", entonces es que no es visible para el usuario, no se está mostrando en catálogo ninguno o, simplemente, se informa al cliente de que no está disponible para la venta.
Los artículos se agrupan por categorías. En la lista completa de artículos nos encontramos con que unos cuantos son cámaras fotográficas, otros objetivos para esas cámaras, televisiones y memorías (tarjetas de memoria SD, Compact Flash, etc.). Esta zona del esquema entidad-relación nos está diciendo que todos los artículos tienen código, nombre, pvp, imagen, urlimagen y especificaciones. Pero si el artículo pertenece a la categoría "objetivo", además mantiene información sobre el tipo de objetivo, la montura, focal, apertura mínima y máxima de diafragma y elementos especiales. Estos atributos, específicos de los objetivos, no los tiene ninguna otra categoría de artículo. Concretamente, no los tienen los televisores; pero es que estos también tienen sus propios atributos que no son aplicables a otras categorías como el tipo de panel, la resolución, etc.
Un tipo especial de categoría es el "pack". Los artículos "pack" son productos ficticios que representan a un conjunto de artículos que se venden juntos por un precio especial (un "pack" es un tipo de artículo por lo que tiene código, nombre y pvp, como cualquier artículo"). Piénsese en una cámara fotográfica reflex (1000 €) que se venda junto a un objetivo (500 €) y una tarjeta de memoria (30 €): el total de estos artículos por separado es 1530 € pero si el cliente compra el pack "A001", por ejemplo, la empresa puede ofrecer un precio distinto, pongamos 1250 €, y recibirá los tres productos agrupados.
Así, una cosa es el artículo ficticio, el "pack", que se almacena en la entidad "PACK", y otra cosa son los artículos que lo componen: esa lista de artículos agrupados se representa y se consulta desde la relación "PTIENEA"; un pack puede contener varios artículos y un mismo artículo puede estar en varios packs distintos.
Los usuarios se mantiene en una entidad donde se guardan los datos típicos de este tipo de sistemas de información. Especialmente importantes son el "email", que los identifica, y nombre, apellidos y DNI, que son datos obligatorios, todos los usuarios deben proporcionar esta información. Además, los datos de su lugar de residencia y la fecha de nacimiento.
Opcionalmente, algunos usuarios podrían tener una dirección de envío alternativa ("DIRENVIO"), esto es, los productos se le enviarían a esa segunda dirección pero la facturación se haría, en principio aunque no necesariamente, contra la dirección de residencia.
Para que no haya confusiones, la localidad a la que se hace referencia tanto en la dirección principal como en la alternativa de envío se mantiene en una entidad aparte. De esta forma, tanto en "USUARIO" como en "DIRENVIO", se conoce siempre (por el tipo de relación de "vive_en" y "está_en") la localidad donde se encuentran esas direcciones postales. Para esta referencia se usa un código de municipio "codm" que se acompaña del nombre de la población: ('1225', 'San Vicente del Raspeig"), por ejemplo.
No obstante, la identificación de las localidades necesita también el código de provincia ya que el mismo código podría utilizarse en distintas provincias. Este dato lo proporciona la dependencia de identificación "pertenece". Así, San Vicente del Raspeig se identifica, realmente, por ('03','1225') que es, obviamente, una localidad distinta a ('45','1225'), Olías del Rey, que se encuentra en Toledo.
Esta forma de identificar a las localidades tiene consecuencias importantes en aquellas consulta que las necesiten.
Finalmente, los pedidos. Se entiende que los usuarios pueden hacer uso de una herramienta previa que es la "cesta". Es una lista de artículos en los que está interesado y que puede o no utilizar para generar un pedido —no entramos en cómo se ha diseñado el proceso de compra, la base de datos solo almacena esa información—. En realidad, las cestas son parejas de email de usuario y código de artículo más una fecha asociada, lo que permite agrupar lógicamente estas parejas y conformar más de una cesta dependiendo del momento de la conexión del cliente al sistema. Esta información, insistimos, no tiene por qué coincidir con la orden de pedido que se detallará a continuación.
Los pedidos tienen una cabecera ("PEDIDO") que informa del número, la fecha y el usuario que formaliza el trámite (relación "compra"). Un pedido solo, y siempre, tiene un cliente asociado pero evidentemente un cliente puede realizar tantos pedidos como quiera. El detalle del pedido, la lista de artículos a comprar y su importe, se almacena en "LINPED". Por ejemplo, el pedido 1 puede contener 3 líneas de artículos (1-1, 1-2, 1-3) y el pedido 2 podría tener 2 (2-1, 2-2). Nuevamente estamos ante una dependencia de identificador: las líneas de pedido necesitan datos adionales (el pedido al que pertenecen) para poder distinguirse de las otras líneas.
Cada línea siempre hace referencia a un artículo en partícular (relación "pide") y especifica siempre un "importe", un precio de venta. De nuevo insistimos en la diferencia entre este precio de artículo y el precio de venta al público (ARTICULO.pvp) que, tal y como se explicó anteriormente, no necesariamente van a coincidir.
Google Sites
Report abuse