¿Cómo modelar un tipo personalizado en una base de datos relacional?

Soy bastante nuevo en el diseño de bases de datos, pero entiendo los fundamentos. Estoy creando una base de datos relacional y me gustaría hacer algo similar a crear un tipo o clase reutilizable. Por ejemplo, supongamos que tengo una tabla Customer y una tabla Item. El cliente y el artículo están relacionados por una relación estándar de uno a varios, por lo que el artículo tiene una columna llamada CustomerId.¿Cómo modelar un tipo personalizado en una base de datos relacional?

También me gustaría tener varias "notas" para cada cliente y cada artículo. En un modelo OOP normal, solo crearía una clase Note y crearía instancias de eso siempre que lo necesitara. Por supuesto, una base de datos relacional es diferente. Estaba pensando en tener una tabla Note, y me gustaría una relación de 1 a muchos entre el Cliente y la Nota, así como el Artículo y la Nota. El problema entonces es que la tabla de notas tendrá que tener una columna para cada otra tabla que desee usar este "tipo". (Ver ejemplo a continuación) note_relation1

También pensé que en su lugar, podría crear una tabla intermedia entre Nota y Cliente/Artículo (u otros). Esto me permitiría evitar tener columnas adicionales en Note para cada tabla que hace referencia a él, por lo que la nota podría permanecer igual ya que agrego más tablas que requieren notas. Estoy pensando que esta es la mejor solución. (ver ejemplo) note_relation2

¿Cómo se maneja este tipo de situaciones? ¿Estoy cerca de corregir? Agradecería cualquier consejo sobre cómo diseñar mi base de datos para tener el tipo de funcionalidad que he descrito anteriormente.

Fuente

2010-10-04 Benny Jobigan

Pregunta: ¿una nota cada vez se aplica a múltiples entidades; es decir, ¿se puede aplicar la misma nota tanto a un cliente como a un artículo? ¿O la misma nota puede aplicarse a múltiples clientes o a múltiples artículos? –

No, cada nota sería solo para un solo cliente, artículo o lo que sea. –

Nada en el diseño de su base de datos lo impide. Debe mover los campos TEXTO y FECHA de NOTA a Nota al Cliente y Notación de Artículo para asignar correctamente el mapa de que cada nota se puede asociar con un Cliente o Artículo como máximo. Como resultado, la tabla NOTA se eliminaría por completo. –

Sí, su ejemplo final es correcto, y debería ser el camino a seguir.

Usted modela un "tipo complejo" en bases de datos relacionales mediante la creación de tablas. Puede considerar la tabla como una clase: de hecho, las soluciones ORM asignan una clase directamente a una tabla. Una instancia del tipo personalizado es una fila en su tabla, y la instancia puede ser referenciada por el valor de la clave primaria.

Puede utilizar su costumbre "tipo complejo" para los campos de otras tablas utilizando el mismo tipo de datos como la clave principal del "tipo complejo", y hacer cumplir la relación con un foreign key constraint:

Vamos a construir una tipo complejo de "países":

CREATE TABLE countries (
    iso_code  char(2)  NOT NULL,  
    name   varchar(100) NOT NULL, 
    population bigint  
    PRIMARY KEY (iso_code) 
);

Y vamos a añadir un par de casos "país":

INSERT INTO countries VALUES ('IE', 'Republic of Ireland', 4470700); 
INSERT INTO countries VALUES ('US', 'United States of America', 310403000);

Ahora vamos a utilizar nuestros complejos "países" de tipo en una tabla "usuarios":

CREATE TABLE users (
    id   int   NOT NULL, -- primitive type 
    name  varchar(50) NOT NULL, -- primitive type 
    age   int,      -- primitive type 
    country  char(2),     -- complex type 
    PRIMARY KEY (id), 
    FOREIGN KEY (country) REFERENCES countries (iso_code) 
);

Con el modelo anterior, tenemos la garantía de que el campo de la tabla userscountry sólo puede ser un país válido, y nada más que un país válido .

Además, el uso de un junction table, como usted sugiere, también es un enfoque adecuado para hacer frente a ese tipo de polymorphic relationship. Usted puede estar interesado en probar los siguientes mensajes desbordamiento de pila para leer un poco más sobre este tema:

Fuente

2010-10-04 12:38:43

hmm, supongo que cuando creo una tabla de unión como "CustomerNote", podría modelar eso como una relación de herencia en un ORM (he leído que es la forma de varias mesas para hacer herencia, de hecho, ya he diseñado mi tabla de "Cliente" debe ser una subclase de otra tabla de "Contacto"). Aunque mi objetivo no era crear una herencia para las notas, básicamente estoy creando subclases de notas (CustomerNote ...) para cada tabla de la que quiero hacer referencia a "Notes" (por ejemplo, Cliente y Artículo). Cuando modelo esto en un ORM, ¿sería mejor crear solo una clase de "Nota" o modelar la herencia? –

@Benny: Es una pregunta interesante, pero creo que una respuesta depende de la solución ORM. Lamentablemente, no tengo mucha experiencia en el uso de ORM para agregar más información. –

Creo que puede agregar mejor un campo Nota a la tabla Cliente y a la tabla Artículo. En este campo de nota (clave externa) puede almacenar la identificación de la nota que pertenece al Cliente/Artículo. Para asegurarse de que puede adjuntar varias notas a un Cliente u Objeto, puede optar por agregar una tabla de Notas y adjuntar Notas individuales a la tabla "Notas" que puede adjuntar a su tabla Cliente/Artículo.

Fuente

2010-10-04 12:37:57 Younes

¿Cómo modelar un tipo personalizado en una base de datos relacional?

Respuesta

Cuestiones relacionadas