1 files changed, 89 insertions, 0 deletions
diff --git a/docs/tuple-insertion.org b/docs/tuple-insertion.org
new file mode 100644
index 0000000..0aed262
--- /dev/null
+++ b/docs/tuple-insertion.org
@@ -0,0 +1,89 @@
+#+title: Tuple Insertion
+
+
+* Theory
+
+As taught by Pascal, user should not be concerned about what relation
+a tuple is inserted: a tuple is a *set of values*, that should be
+added to a single relation, thus, the relational database is
+responsible to identify the relation that the set of values belong to,
+or to discard the set of values and inform the user that this specific
+tuple is not suitable for the database.
+
+** Theory details
+
+In Relational Data Theory, every entity group/type maps to a relation;
+a relation is a set, and, as such, it has an *extensional* (items that
+belong to the set) and an *intensional* (rules that the items of the
+set must adhere to in order to be part of the set) definition;
+
+The *intensional* definition of sets that exist in the *logical model*
+are mapped to the semantical *conceptual model*, which enables users
+to infer theorems (query) from axioms (tuples), in the form of
+querying the database, and mapping the logical model symbols to the
+equivalent corresponding conceptual model meaning.
+
+| Conceptual Model    | Logical Model |
+|---------------------+---------------|
+| Entity group/type   | Relation      |
+| Entity              | Tuple         |
+| Property            | Domain        |
+| Property in context | Attribute     |
+| Business Rule       | Constraint    |
+
+As such, each relation has a *unique* set of constraints, in such a
+way that tuples that are inserted in a database should be only
+mappable to a *unique* relation, otherwise, we'd have two relations
+that are being mapped to the same entity group/type of our databse,
+which would mean our design has a redundant mapping (two logical model
+symbols mapped to the same conceptual model entity group)
+
+** Typing and subtyping
+
+A relation can be defined by a *type*; that said, some entity groups
+are better defined as subgroups, which in the logical model are called
+*subtypes*; such description creates the need for a type system in the
+relational database theory, which must enable a database designer to
+create *types* and *subtypes* from those types.
+
+If a *type* maps to a relation, a *subtype* must inherit all of the
+defining attributes of that type and have at least one extra type,
+which we call *meaning criteria* in the conceptual
+model. Theoretically, with these at hand, the RDBMS is able to insert
+a tuple given by a user in the adequate relation, without the need for
+extra constraints.
+
+*** User Interface
+
+* Architecture
+
+#+begin_src plantuml
+@startuml
+actor user as user
+boundary RNT as rnt
+control parser as p
+control "Relation Identifier" as ri
+database db as Database
+
+user -> rnt : insert tuple request
+rnt --> p : parse tuple
+p -[#green]-> ri : tuple parsed, check relation
+ri -[#green]-> db : exactly one relation matches tuple, insert
+db -[#green]-> rnt : success
+rnt -[#green]-> user : success
+rnt --> p : parse tuple
+p -[#red]-> rnt : tuple can't be parsed
+rnt -[#red]-> user : error
+rnt --> p : parse tuple
+p -[#green]-> ri : tuple parsed, check relation
+ri -[#red]-> rnt : more than one relation matches; invalid tuple
+ri -[#red]-> rnt : no relation matches; invalid tuple
+rnt -[#red]-> user :error
+@enduml
+#+end_src
+
+The user must be able to send a tuple to be inserted; this tuple,
+first, must be a valid tuple in the sense of the database being able
+to identify all of the types there.
+
+** Parser