Cliente

En el diseño de base de datos, el cliente es la persona o la entidad que proporciona los requerimientos y necesidades que la base de datos debe satisfacer.

Un cliente que no sabe de bases de datos, suele expresar sus necesidades en términos simples y cotidianos. Aquí te doy ejemplos de cómo podrían sonar estos requerimientos desde su perspectiva:

  1. "Quiero un sistema que me permita llevar el control de los clientes, las ventas y los productos que manejo en la tienda."
  2. "Necesito almacenar la información de mis clientes, como nombre, teléfono y correo. También quiero guardar los productos que vendo, con su nombre, precio y cantidad en inventario."
  3. "Me gustaría poder agregar nuevos clientes, modificar su información si cambia y borrar los datos de clientes antiguos. También quiero poder ver todas las ventas que se han hecho."
  4. "Yo quiero ser el único que pueda modificar los precios de los productos, pero mis empleados deben poder registrar ventas y ver la información de los clientes."

El cliente describe lo que necesita sin usar términos técnicos. Tu trabajo como diseñador es interpretar esto y traducirlo en requerimientos más formales para el diseño de la base de datos.

Diseñador

El diseñador no solo recibe los requerimientos del cliente, sino que también debe traducirlos a términos técnicos y asegurar que se implementen correctamente en el sistema:

  1. Refina y detalla esos requerimientos para que sean técnicamente claros.
  2. Identifica posibles problemas y plantea soluciones, como mejorar la eficiencia de las consultas o asegurar la integridad de los datos.
  3. Optimiza el diseño para cumplir tanto con los requerimientos funcionales como no funcionales, considerando el mejor rendimiento y la escalabilidad del sistema.

Requerimientos funcionales

Estos definen qué debe hacer el sistema. El diseñador de base de datos toma las necesidades del cliente y las convierte en especificaciones técnicas que dictan cómo debe funcionar la base de datos. Ejemplos incluyen:

  • Gestión de datos: Cómo se va a almacenar, recuperar, actualizar y eliminar la información.
    Ejemplo: El sistema debe permitir registrar nuevas ventas y asociarlas a clientes.
  • Relaciones entre entidades: Definir cómo interactúan las diferentes tablas y entidades en la base de datos.
    Ejemplo: Un cliente puede tener varias compras asociadas, pero cada compra pertenece a un solo cliente.
  • Consultas y reportes: Determinar qué información debe estar disponible a través de consultas o reportes.
    Ejemplo: El sistema debe generar un reporte mensual de ventas.

Los estudiantes de Ofimática se limitarán a gestionar y analizar datos de manera sencilla y eficiente para hacer análisis/cálculo básicos y generar reportes visuales.

Desarrollador

Los requerimientos no funcionales son de interés principalmente para desarrolladores o programadores porque determinan cómo debe funcionar un sistema.

Requerimientos no funcionales

Estos definen cómo debe funcionar el sistema en términos de rendimiento, seguridad, disponibilidad, etc. El desarrollador debe garantizar que estos aspectos se consideren en el diseño.

Ejemplos:

  • Rendimiento: La base de datos debe ser capaz de manejar una cierta cantidad de consultas y operaciones en un tiempo razonable.
    Ejemplo: El sistema debe poder buscar clientes en menos de 2 segundos.
  • Escalabilidad: El sistema debe ser capaz de crecer con el tiempo, ya sea en volumen de datos o cantidad de usuarios.
    Ejemplo: La base de datos debe soportar hasta 10,000 usuarios activos.
  • Seguridad: Controlar el acceso a los datos para que solo usuarios autorizados puedan ver o modificar cierta información.
    Ejemplo: Solo los administradores deben poder eliminar clientes.
  • Disponibilidad y recuperación: Establecer mecanismos para asegurar que los datos estén disponibles incluso en caso de fallo y se puedan recuperar.
    Ejemplo: El sistema debe tener un mecanismo de respaldo diario.