¿Es mi base de datos relacional?

La relacionalidad no es una propiedad de su modelo de datos, sino del sistema de administración de la base de datos en el que se implementa. Un DBMS es relacional si representa las entidades como “tablas”; las relaciones entre estas tablas no están cableadas, pero debe buscar condiciones como Shopper.shopper_: id = birthday.shopper_id en su consulta. Por lo general, puede agregar índices que permitan búsquedas más rápidas y relaciones de clave externa que impongan coherencia.

Un sistema de base de datos no relacional típico es una base de datos CODASYL, donde esas relaciones que planea consultar como las mencionadas anteriormente están representadas por “conjuntos” cableados, por lo que no necesitará una búsqueda, pero es menos flexible.

El mismo modelo de datos Entidad-Relación (como el de su ejemplo) puede representarse en un DBMS relacional así como en uno CODASYL.

Los DBMS habituales que utiliza son relacionales (Oracle, MSSQL, MySQL, SQLITE, DB2, …). Los DBMS de CODASYL son elementos heredados que generalmente se ejecutan en mainframes. Otros tipos de DBMS no relacionales (que generalmente no pueden representar todos los modelos de datos de Entidad-Relación) son DBMS orientados a objetos, o los diversos tipos de DBMS NoSQL.

Sí, técnicamente califica como relacional. Pero, ¿qué tan útil es para tu dominio?

¿Cómo puede un comprador tener más de un cumpleaños? Tienes una interesante compra demográfica en tu sitio.

Además, probablemente no sea muy útil tener varias direcciones por persona sin ningún calificador que ayude a distinguir el tipo de las diferentes direcciones (por ejemplo, envío frente a facturación o lo que sea).

Puede ser que esté diciendo que una persona tiene 0 o 1 cumpleaños / dirección dependiendo de si su sistema tiene esa información o no. Está bien, ciertamente es válido modelar usando tablas separadas (la alternativa es campos anulables en el comprador). Pero con tablas separadas, no necesita birthday_id y address_id para modelar la relación 0 o 1, ya que un shopper_id es suficiente para identificar de forma exclusiva a cualquiera de ellos.

Sí, su base de datos es relacional.
La clave principal de kanga.Shopper (es decir: shopper_id), La clave principal de kanga.address (es decir, address_id), La clave principal de kanga.birthday (es decir, birthday_id) donde la clave externa de kanga.address (es decir, shopper_id) y el La clave externa de kanga.birthday (es decir, shopper_id) hace referencia a la clave principal de Kanga.Shopper.
Esta es la relación que se desarrolla entre estas tres tablas.
Entonces, es una base de datos real.

Sí, su base de datos es relacional.

La tabla de direcciones tiene relación con la tabla de compradores (shopper_id es una clave foránea en la tabla de direcciones).

Y también la tabla de cumpleaños tiene relación con la tabla de compradores (shopper_id es una clave foránea en la tabla de cumpleaños).

Como muestra el diseño del esquema físico de un sistema de base de datos relacional, sí, es relacional. La pregunta que creo que realmente está preguntando es si está diseñada correctamente. La respuesta allí es no. Cumpleaños es un atributo del comprador y no puede sostenerse por sí mismo como una entidad. Si la dirección es realmente una entidad dependiente del comprador, terminará con datos incorrectos ya que se pueden ingresar direcciones duplicadas tanto para múltiples compradores como para el mismo comprador.