Ofimática Día 13 - Access parte 3 : Ejemplos propuestos de relaciones en BBDD ZOO

 ZOO:



Errores que puede detectar ChatGPT (cuando le subes esta imagen):

Pregúntale esto:

Quiero hacer una BBDD para un Zoo y he resaltado en otro color, los campos que se conectarían entre las diferentes tablas. Analiza mi trabajo e indica posibles problemas o incompatibilidades.

Te responderá este otro:

¡Gracias por compartir la imagen! Has hecho un buen esfuerzo en organizar las tablas y resaltar los campos que se conectarían entre sí. Aquí tienes un análisis detallado con observaciones, posibles problemas y recomendaciones para mejorar la base de datos del zoo:


✅ TABLAS Y CAMPOS BIEN ENCAMINADOS

  1. Tabla Animales

    • CHIP como clave primaria está bien.

    • ❗ El campo Zoo debe ser una clave foránea que apunte a la tabla Zoos, pero:

      • Problema: En la tabla Zoos, usas Zoo (Nombre) como clave. El nombre no es recomendable como clave primaria (ver más abajo).

  2. Tabla Zoos

    • ❌ Tienes Zoo (Nombre) como clave primaria.

      • Problema: Los nombres pueden repetirse y cambiar con el tiempo.

      • Recomendación: Usa un campo como ID_Zoo (INT o VARCHAR único) como clave primaria.

      • El campo Apellidos… parece fuera de lugar. ¿Quizá querías poner “Dirección”, “Ubicación” o “Nombre del responsable”? Si no, revisa su propósito.

  3. Tabla Partes Veterinarios

    • ✔ Incluyes CHIP animal y Cod Veterinario, que son referencias correctas a Animales y Veterinarios/Cuidadores.

    • ❗ El Nº Parte debería ser clave primaria, y Cod Veterinario necesita existir previamente en la tabla de cuidadores o una tabla separada de veterinarios.

  4. Tabla Cuidadores

    • ✔ Bien estructurada con campos como DNI, TLF.

    • Cod Veterinario es poco claro si esta tabla solo contiene cuidadores. ¿Quieres decir que todos los cuidadores también son veterinarios?

      • Si no, separa en dos tablas: una para Veterinarios y otra para Cuidadores.

    • ZOO donde trabaja correctamente se conecta con Zoos.

  5. Tabla Otros trabajadores

    • ✔ Correctamente enlazas ZOO donde trabaja.

    • ❗ Repetición de estructura con Cuidadores: podrías unificar en una tabla Trabajadores y usar un campo Tipo (cuidador, veterinario, administrativo, etc.).

    • Num_trabajador debe ser clave primaria.


🔍 RESUMEN DE PROBLEMAS DETECTADOS

ProblemaDetalleRecomendación
Claves no establesUsar Nombre como clave (Zoo) es frágilUsar ID_Zoo o similar como clave primaria
Relaciones ambiguas¿Veterinario es cuidador? ¿o entidad aparte?Separar en tablas distintas o unificar con campo Tipo
Campos poco clarosApellidos... en tabla Zoos no tiene sentidoCambiar por “Dirección”, “Ciudad”, etc.
RedundanciaCuidadores y otros trabajadores tienen mismos camposUnificar en tabla Trabajadores con campo Rol
Nombres de campos inconsistentesZOO donde trabaja, Cod Veterinario...Usar convenciones uniformes: id_zoo, id_veterinario, etc.

🧱 ESTRUCTURA RECOMENDADA (simplificada)

🔹 Tabla Zoos

  • id_zoo (PK)

  • nombre

  • ubicación

🔹 Tabla Animales

  • chip (PK)

  • nombre

  • raza

  • fecha_nacimiento

  • id_zoo (FK)

🔹 Tabla Trabajadores

  • id_trabajador (PK)

  • nombre

  • apellidos

  • dni

  • telefono

  • rol (ENUM: 'cuidador', 'veterinario', 'otro')

  • id_zoo (FK)

🔹 Tabla PartesVeterinarios

  • id_parte (PK)

  • chip_animal (FK)

  • id_veterinario (FK a Trabajadores)

  • fecha

  • observaciones




********************************************************************


Entendiendo cómo piensa un ordenador, cuando tiene que conectar datos

Si un animal está en un Zoo y un trabajador también figura "en el Zoo", técnicamente, cualquier trabajador PUEDE atender a CUALQUIER animal.

Un Zoo puede tener infinitos trabajadores, pero hay que tener cuidado con los "partes veterinarios". Sólo te interesa poner el chip del animal atendido y luego el trabajador (no pongas el dato de "Zoo", porque se entiende que sólo con indicar el trabajador, ya sabes en qué Zoo se atendió al animal). Si lo conectas con un veterinario, permites que a ese animal, lo atienda cualquier persona, interna o externa.

Un animal puede tener "infinitos" partes veterinarios (atención por enfermedad, vacunas, fracturas, etc). En teoría, si el animal cambiase de Zoo, su historial médico, NO debería cambiar (la atención facilitada en España, debería seguir figurando, como que se hizo en España, no en el lugar donde finalmente resida).

Animal ----> Zoo (se conecta directamente)
Animal ---> Parte médico, se conecta con el trabajador (para que su expediente NO cambie, si el animal o el trabajador cambian de zoológico). La idea es NO bloquear la BBDD, para que sólo acepte un determinado cuidador, para un animal concreto.



Comentarios

Entradas populares de este blog

Día 1 - Memoria RAM y concepto básico CPU

enlace ejercicios resueltos en clase (EXCEL)

Día 7 - Preparando un pendrive de arranque