You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+2-13Lines changed: 2 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,28 +8,17 @@ Relational Algebra (RA) is the theoretical foundation of SQL and a cornerstone o
8
8
9
9
This project formalizes:
10
10
11
-
- The core constructs of Relational Algebra (e.g. selection, projection, join, union, difference, renaming).
11
+
- The core constructs of Relational Algebra (i.e. selection, projection, join, renaming, union, difference).
12
12
- A corresponding fragment of First-Order Logic with active domain semantics.
13
13
- The expressive equivalence between RA and FOL under this interpretation.
14
14
15
15
The formalization is developed in [Lean 4](https://leanprover.github.io), using its dependent type theory framework and the [mathlib4](https://github.com/leanprover-community/mathlib4) library where possible.
16
16
17
17
## ✅ Goals
18
18
19
-
- ✅ Formalize SPJR algebra.
20
-
- ✅ Formalize SPJRU algebra.
21
-
- ✅ Formalize complete relational algebra.
19
+
- ✅ Formalize relational algebra.
22
20
- ✅ Formalize equivalent fragments of FOL.
23
21
- ✅ Prove equivalence theorems between RA and FOL expressions.
24
22
- 🔄 Ensure reusable and well-documented Lean definitions.
25
23
26
-
## 🧠 Design Rationale
27
-
28
-
The design decisions behind the formalization — such as how tuples, schemas, and relational operations are represented in Lean — are documented in the [`Design.md`](./Design.md) file. This includes:
29
-
30
-
- Key trade-offs (e.g., bundled vs. unbundled representations)
31
-
- Justification for using partial functions and specific Lean constructs
32
-
33
-
Reading `Design.md` is recommended if you're contributing to the codebase or want to understand the reasoning behind implementation choices.
(toRA q.all (q.freeVarFinset ∪ FRan (FreeMap n brs)) brs).evaluateT dbi = {t | ∃h, RealizeDomSet (q.all) (q.freeVarFinset ∪ FRan (FreeMap n brs)) brs t h} := by
To simplify the conversion and proof, we decided to allow for the assumption that the attributes used to represent the bound variables (`brs`)
7
6
is disjoint from the named attributes used in any of the relations AND there is no intersection between free variables and relation attributes used in the query.
8
-
This assumption is a short-cut, given we use `FreshAtts` to generate `brs` which avoids these variables.
9
-
However, due to deadlines we decided to leave this proof as future work.
7
+
This assumption simplifies the proof without real loss of generality, since in practice renaming of attributes/variables could resolve the issues that would occur.
0 commit comments