1. 1 III) COMPLEX VALUE DATABASES

2. 2 Introduction l Relax the 1 Normal Form of the Relational Model  Set-value attributes (e.g., set of tuples => Relations) l Alternative Names: N1NF, NF2, and Nested Relations Models l Three simultaneous innovating approaches:  INRIA 1981-1985: VERSO Database Machine (M. Scholl & S. Abiteboul & F. Bancillon & N. Bidoit & al)  University of Texas 1983: N1NF (P. Fisher & S. Thomas)  IBM Heidelberg + Darmstand 1983-1986: DASDBS NF2 Relational database (G. Jaeschke, H. Schek, P. Pistor, M. H. Scholl) l No programming languages l Only experimental prototypes

3. 3 A Model for Complex Values Set of Atomic values: D =  D i, where D i are atomic domains such as strings, integers, reals, etc. l Set of Attribute names A l Set of Complex values:  each element v of D is a complex value  if v1, v2,..., vn are structured values and a1, a2,..., an are attribute names then [a1:v1, a2:v2,..., an:vn] is a complex value, called tuple  if v1, v2,..., vn are structured values then {v1, v2,..., vn} is a complex value, called set ò NOTE: In N1NF Models the set and tuple value constructors can be applied only alternatively  is not possible to represent set of sets or tuples of tuples

4. 4 Complex Values: Examples l In the FineArt database we want to represent artists with their work u From a relational perspective we have the multi-valued dependency: Name ->-> Artifacts

5. 5 Complex Value Types l Set of Atomic types: STRING, INT, REAL l Set of Attribute names A l Set of types for Complex values:  each atomic type is a type  if t1, t2,..., tn are types and a1, a2,..., an are attribute names then [a1:t1, a2:t2,..., an:tn] is a tuple type  if t is a type then {t} is a set type l EXAMPLE: The type (sort) of the FINE-ART N1NF Relation is: {[Name: STRING, Style: STRING, Artifacts: {[Title: STRING]}, Live-Time: STRING, Nationality: STRING]}

6. 6 Typing: DB vs. PL view l Types in PL:  Part of the program  Focus on variables and functions  Used to avoid inconsistent computations  Type checking is mainly a static activity (compiler) l Types in DB:  Part of the schema  Focus on data  Used to check semantic integrity  Type checking could be also a dynamic activity (run time) l NOTE: The conception of good constructs in DBPL is twofold:  Support a type system for data modeling  Support a data model for program typing

7. 7 Toward a Formalization of Complex Value Databases A schema S is a triple (N, T,  ) :  N is a set of names (e.g., relation names)  T is a set of types   is a function from N to T The Extension (Interpretation) I of a name n is the set of values (instances) of sort  (n) A Database instance is a mapping of the schema S names n such that for each n in S, I(n) is a set of values of sort  (n)

8. 8 Complex value Query Languages: Algebra l Uses relation names + constants + new operations u Basic Set Operations: Union, Intersection and Difference u Constructive Operations: PowerSet, Tuple_create, Set_create u Destructive Operations: Flatten, Tuple_destroy u Restructuring Operations: Nest and Unnest u Filtering Operations: Selection, Projection, Renaming u Additional Operations: Cross Product, Join

9. 9 Complex Value Algebraic Operators B b1 b2 b1 b2 b1 PowerSet B b1 b2 Flatten {[B:T]} {{[B:T]}} Join A a2 B CD a1 c1 c2 d1 d2 d3 c2 c3 EF e1 f1 Product {[E:T 1, F:T 2 ]} {[A:T 3, B:{[C:T 4, D:T 5 ]}]} {[B:T]} {{[B:T]}} {[E:T 1, F:T 2, A:T 3, B:{[C:T 4, D:T 5] }]} B b2 B B CD A a2 B CD a1 c1 c2 d1 d2 d3 c2 c3 CD EF e1f1 e1 f1 A a2 B CD a1 c1 c2 d1 d2 d3 c2 c3 CD AE a2 e1 {[A:T 1, E:T 4 ]} {[A:T 1, B:{[C:T 2, D:T 3 ]}]} A a2 B d2 d3 c2 c3 CD E e1 {[ A:T 1, B:{[C:T 2, D:T 3 ]}, E:T 4 ]} B b1 b2 b1 B b2 B B B

10. 10 Complex Value Algebraic Operators A a2 B d2 d3 c2 c3 CD BB B d2 d3 c2 c3 CD d2 d3 c2 c3 CD Tuple_ destroy d2 d3 c2 c3 CD Flatten PowerSet CD c2 d2 d3c3 CD CD d2 d3 c2 c3 CD Tuple_ create B B CD c2d2 d3c3 CD B d2 d3 c2 c3 CD d2 d3 c2 c3 CD { [A:T 1, B:{ [C:T 2, D:T 3 ] } ] }{ [B:{ [C:T 2, D:T 3 ] } ] }{ { [C:T 2, D:T 3 ] } }{ [C:T 2, D:T 3 ] } { { [C:T 2, D:T 3 ] } } { [B: [C:T 2, D:T 3 ]] }

11. 11 Complex Value Query Examples l Find the artifacts of Impressionist artists ( Flatten(Tuple_destroy (  Artifacts (  Style=‘Impressionist’ ( FINEART )))))

12. 12 Complex Value Unnest & Nest R1 = Unnest Artifacts (FINEART)

13. 13 Complex Value Unnest & Nest R2= Nest ArtWork= Name,Title,Live-Time,Nationality (R1)

14. 14 Complex Value Unnest & Nest l Unnest is the right inverse of nest, whereas unnest is in general not information preserving Nest Artifacts=Title (Unnest Artifacts (FINEART)))  FINEART Unnest Artifacts (Nest Artifacts=Title ( R1))) = R1 l Why? u Grouped attributes may be empty u Remaining attributes may have the same values

15. 15 Complex Value Query Languages: Calculus l Relies on (first-order) relational calculus + quantification over set (second-order) + many sorted (complex value types) u Alphabet of constants D (complex values) + a set V of variable names + a set A of attribute names u Terms:  constants of D (e.g. 1, [name: ”Vassilis”], etc.)  variables of V (e.g., X, Y, Z, etc.)  expressions of the form t.a where a an attribute of A and t a tuple term  Positive Literals: R(t), t = t’, t  t’, t < t’  Well Formed Formulas: and, not, exists, forall  Query: {X |  } where X is the only free variable in  l Range Restrictions to formulae variables guarantee safety of calculus l Set-type Variables + PowerSet result in more expressive power than the relational calculus (equivalent to Datalog-Transitive Closure) l THEOREME: The above complex value algebra and the safe calculus have the same expressive power [Kupper, Abiteboul, Grumbach, Beeri]

16. 16 A Critic of Complex Value Databases l Compared to the Relational Model u More Complex Attribute Values u Typed Data Model u Expressive Power of N1NF Languages l But u No Object Identity (Data Sharing) u No Programming Language (Extensibility, Flexibility)