Ya no busques más por todo internet porque llegaste al sitio adecuado, contamos con la respuesta que quieres sin complicarte.
Solución:
Si bien ha realizado un trabajo bastante minucioso al seguir los requisitos de los libros de texto, hay algunas consideraciones prácticas que podría o no querer incluir, según las expectativas de la tarea. Algunos de estos tienen que ver con malos requisitos. No sé si obtendría puntos extra o reducidos por señalarlos.
- La cantidad de alimentos como un número entero probablemente no sea lo suficientemente precisa
- Las cantidades de alimentos deben tener una unidad de medida. Algunos alimentos estarán secos, otros líquidos. Las iguanas probablemente necesitan unos pocos gramos de “Iguana Chow”, mientras que los elefantes necesitarán varios kilos de lo que estén comiendo.
- Las cantidades de dinero deben almacenarse como MONEY u otro tipo de datos que no sean enteros.
- Si sus zoológicos están por todas partes, es posible que deba considerar almacenar una moneda con la cantidad monetaria
- Almacenar la edad de un visitante es un error. Los visitantes envejecen entre visitas. Es mejor almacenar la fecha de nacimiento del visitante y calcular su edad en cada visita, ya que conoce la fecha de las visitas.
- En un sistema real, parte de esta información será opcional. No todo el mundo te dirá su fecha de nacimiento. Del mismo modo, es posible que no sepa cuándo nació su tortuga gigante.
- Los nombres de las personas, si son importantes, generalmente se almacenan en más de un campo (por ejemplo, nombre de pila y apellido)
- Es muy poco probable que todos los animales tengan un registro personal de sus necesidades dietéticas. Algunos animales podrían hacerlo, pero para muchos animales podría tener más sentido almacenar los requisitos para todos los animales de una especie determinada.
- El hecho de que las especies animales no se tengan en cuenta en el modelo es algo cuestionable, ya que uno pensaría que a la mayoría de los zoológicos les importaría algo así.
No creo que haya mucho que decir, parece que captó los requisitos de las instrucciones que le dieron. El único pequeño comentario es cuando las instrucciones dicen “una visita se define mediante un identificador único“, algunas veces “identificador único“es sinónimo de la palabra GUID (y en algunos sistemas de bases de datos Identificador único es el nombre del tipo de datos real para un GUID, como Microsoft SQL Server). No estoy seguro de si debe interpretarse de esa manera en este contexto, pero pensé que lo haría saber.
Para responder a su segunda pregunta sobre acortar su vista para obtener el Zoo_Id con la menor cantidad de visitas, puede hacer lo siguiente que usa un CTE y el ROW_NUMBER() función de ventana:
WITH CTE_ZooVisits_Sorted AS
(
SELECT v.zoo_id, ROW_NUMBER() OVER (ORDER BY COUNT(v.zoo_id), v.zoo_id) AS SortId -- Generates a unique sequential ID, ordered by the number of Zoo visits, then by the Zoo's ID to break any ties
FROM Visit v
GROUP BY v.zoo_id
)
SELECT zoo_id
FROM CTE_ZooVisits_Sorted
WHERE SortId = 1 -- Returns only one row with the minimum amount of Zoo Visits (ties broken by whichever Zoo was created first)
Nota con ROW_NUMBER() cuando hay un empate, elige al azar cuál viene primero en el orden a menos que proporcione un campo único como el desempate, que en mi ejemplo anterior hice por zoo_id. (Lo que esto significa lógicamente es que si dos zoológicos están empatados por el número de visitas, el zoológico que se creó primero romperá el empate y se clasificará primero). WHERE SortId = 1 en la final SELECT y reemplácelo con un ORDER BY SortId para obtener la lista completa de zoo_id ordenados por la menor cantidad de visitas a la mayor cantidad de visitas.
Si desea una alternativa en la que desee ordenar las corbatas en el mismo orden sin un desempate entonces en lugar del ROW_NUMBER() función de ventana, puede utilizar RANK() o DENSE_RANK() al igual que:
WITH CTE_ZooVisits_Sorted AS
(
SELECT v.zoo_id, DENSE_RANK() OVER (ORDER BY COUNT(v.zoo_id)) AS SortId -- Generates a sequential ID, ordered by the number of Zoo visits, ties will have the same sequential ID generated
FROM Visit v
GROUP BY v.zoo_id
)
SELECT zoo_id
FROM CTE_ZooVisits_Sorted
WHERE SortId = 1 -- Returns all rows with the minimum amount of Zoo Visits (multiple rows for when there's a tie among minimum visits between multiple Zoos)
Tenga en cuenta el uso de una función de ventana como ROW_NUMBER(), RANK(), o DENSE_RANK() también es útil porque le permite seleccionar todos y cada uno de los campos de la fila que tiene el número mínimo de visitas al zoológico (o cualquier criterio de clasificación que desee utilizar).
Te recomiendo que dividas la parte animal y la parte visitante en dos esquemas diferentes. Conceptualmente son dos dominios diferentes y puede tener diferentes programas de desarrollo y mantenimiento. Creo que combinar los dos aumenta la complejidad y la complejidad se correlaciona con el costo y los errores.
La separación también puede ayudar con la seguridad de la información. Si bien la base de datos de visitantes puede necesitar una presencia en Internet (por ejemplo, cuentas de titulares de pases anuales / de temporada), la parte animal no necesita estar en Internet y puede tener una conectividad limitada (o nula) a Internet.
Abogaría por un tercer esquema: operaciones comerciales (mantenimiento, inventario, compras). Definir un estándar de intercambio de datos entre los diferentes esquemas (por ejemplo, mensaje de consumo de alimentos al esquema de operaciones comerciales).
En mi experiencia, el “esquema de una base de datos para gobernarlos a todos” se vuelve costoso y difícil de mantener.
Al final de todo puedes encontrar las críticas de otros sys admins, tú igualmente puedes mostrar el tuyo si lo deseas.