resueltos relacional proyeccion producto primitivos ppt operadores historia ejercicios ejemplos datos cartesiano calculo orm scala dsl type-systems database-relations

orm - proyeccion - producto cartesiano algebra relacional



Características del lenguaje para implementar el álgebra relacional (5)

Lo que usted solicita es poder definir estructuralmente un tipo como la diferencia de otros dos tipos (la relación original y la definición de proyección). Honestamente, no puedo pensar en ningún lenguaje que te permita hacer eso. Los tipos pueden ser estructuralmente acumulativos ( A with B ) ya que A with B es un subtipo estructural de A y B Sin embargo, si lo piensas, una operación de tipo A less B sería en realidad un supertipo de A , en lugar de un subtipo. Está pidiendo una relación de tipeo arbitraria y contravariante en tipos covariantes naturales. Ni siquiera se ha demostrado que ese tipo de cosas son sólidas con los tipos existenciales nominales, y mucho menos con los tipos estructurales de puntos de declaración.

He trabajado en este tipo de modelos antes, y la ruta que tomé fue restringir las proyecciones a uno de los tres dominios: P == T , P == {F} where F in T , P == {$_1} where $_1 anonymous . El primero es donde la proyección es equivalente al tipo de entrada, lo que significa que es un no-op ( SELECT * ). El segundo es decir que la proyección es un solo campo contenido dentro del tipo de entrada. El tercero es el complicado. Está diciendo que está permitiendo la declaración de algún tipo anónimo $_1 que no tiene una relación estática con el tipo de entrada. Es de suponer que consistirá en campos que deleguen en el tipo de entrada, pero no podemos hacer cumplir eso. Esta es aproximadamente la estrategia que toma LINQ.

Lo siento, no podría ser más útil. Ojalá fuera posible hacer lo que me pides, abriría muchas posibilidades muy buenas.

He estado tratando de codificar un álgebra relacional en Scala (que según mi conocimiento tiene uno de los sistemas de tipo más avanzados) y simplemente no encuentro una manera de llegar a donde quiero.

Como no tengo tanta experiencia en el campo académico del diseño de lenguaje de programación, realmente no sé qué característica buscar.

Entonces, ¿qué características del lenguaje se necesitarían, y qué lenguaje tienen esas características, para implementar un álgebra relacional estáticamente verificada?

Algunos de los requisitos: A Tuple es una función que asigna nombres desde un conjunto estáticamente definido de nombres válidos para la tupla en cuestión a valores del tipo especificado por el nombre. Permite llamar a este tipo de nombre establecer el dominio.

Una relación es un conjunto de tuplas con el mismo dominio, de modo que el rango de cualquier tupla es único en el conjunto

Hasta ahora, el modelo se puede modelar fácilmente en Scala simplemente por

trait Tuple trait Relation[T<Tuple] extends Set[T]

El vals, vars y defs en Tuple es el conjunto de nombre de tipo definido anteriormente. Pero no debería haber dos defs en Tuple con el mismo nombre. También vars y definiciones impuras probablemente también deberían estar restringidas.

Ahora para la parte difícil:

Una unión de dos relaciones es una relación donde el dominio de las tuplas es la unión de los dominios de las tuplas operandos. De modo que solo se conservan las tuplas que tienen los mismos rangos para la intersección de sus dominios.

def join(r1:Relation[T1],r2:Relation[T2]):Relation[T1 with T2]

debería hacer el truco.

Una proyección de una relación es una relación donde el dominio de las tuplas es un subconjunto del dominio de tuplas de operandos.

def project[T2](r:Relation[T],?1):Relation[T2>:T]

Aquí es donde no estoy seguro si es posible encontrar una solución. ¿Qué piensas? ¿Qué características del lenguaje se necesitan para definir el proyecto?

Implícito por encima del curso es que la API tiene que ser utilizable. Capas y capas de texto repetitivo no son aceptables.

El tutorial D es tan simple y tan alineado con la teoría relacional que un lenguaje puede ser.

Creo que me he decidido por usar las instalaciones normales para la recopilación de mapas para la parte del proyecto. El cliente solo especifica una función [T<:Tuple](t:T) => P

Con algunos trucos java para llegar a la clase de PI debería ser capaz de utilizar la reflexión para implementar la lógica de consulta.

Para la unión probablemente use DynamicProxy para implementar la función de mapeo.

Como beneficio adicional, podría obtener la API para usarla con la sintaxis especial de Scalas.

HaskellDB tiene algunas ideas sobre cómo crear DSL de álgebra relacional de tipo seguro, puede que le resulte útil.