#+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
