1. Relations with Stored and Inherited Attributes Witold Litwin Dauphine University June 13, 2016

2. What’s Up ? A 1NF construct for relational DBs Mixes stored and inherited attributes Adds up to Codd’s 1NF classics – Stored (base) relation stored attributes only – View Inherited attributes only We proposed the construct in 92 – Examples showed it interesting – But no one followed We revisit in now in depth 2

3. Why More faithful conceptual modelling No need for ER-model Simpler queries by less: – Logical navigation through joins – Complex expressions No need for annoying dedicated views – Necessary for the above goals at present – Cumbersome in turn 1st solution to this decades’ old dillema Details in the paper with the talk title pdf through my or Lamsade Web page 3

4. How ? Stored and Inherited Relation (SIR) – Concept – Utility Relational Schema Design Restated – Normal Forms: 2NF and up for SIRs – Heath’s & Fagin’s Theorems for SIRs – Lossless decomposition into the minimal number of relations without anomalies – Same # of relations as with current rules But the DB should usually be less procedural for queries Implementation over an RDBS Conclusion 4

5. Stored and Inherited Relation Formally: a 1NF Relation – Hence with atomic attributes only Basic axiom for Codd’s model But: SIR has some attributes stored (SAs) and some inherited (IAs) Unlike for Codd’s model dichotomy: – Stored (base) relations have SAs only – Inherited relations (views) have IAs only 5

6. Relational Data Model with SIRs Stored Relation or View Model (Codd) / Stored & Inherited Relation Model 6 Mathematical model 1NF Relation DB model SR View (IR) Mathematical model 1NF Relation DB model SIR View (IR) SR SRV - modelSIR - model

7. Motivating Example : Codd’s S-P DB Restated Table SP is now a SIR Codd’s SP is in black: SRs only 7 S-P2 Scheme Table STable PTable SP S# Char, P# Char,S# Char, SNAME Char,PNAME Char,P# Char, STATUS Char,COLOR Char, QTY Int, CITY Char; WEIGHT Char, I_SP (Select SNAME, CITY Char; STATUS, S.CITY As SCITY, PNAME, COLOR, WEIGHT, P.CITY As PCITY From S,P,SP Where SP.S# = S.S# And SP.P# = P.P#);

8. Motivating Example : Codd’s S-P DB Restated S-P2 Content Table S Table P S#SNAMESTATUS CITYP# PNAMECOLOR WEIGHT CITY S1 Smith20LondonP1 NutRed12London S2Jones10ParisP2 BoltGreen17Paris S3Blake30ParisP3 Screw Blue17Oslo S4Clark20LondonP4 ScrewRed14London S5Adams30 AthensP5 CamBlue12Paris P6 CogRed19London Table SP S#P#QTYSNAME STATUS SCITY PNAME COLOR WEIGHT PCITY S1P1300 Smith 20 London Nut Red 12 London S1P2200 Smith 20 London Bolt Green 17 Paris S1P3400 Smith 20 London Screw Blue 17 Oslo S1P4 200 Smith 20 London Screw Red 14 London S1P5100 Smith 20 London Cam Blue 12 Paris S1P6100 Smith 20 London Cog Red 19 London S2P1300 Jones 10 Paris Nut Red 12 London S2P2400 Jones 10 Paris Bolt Green 17 Paris S3P2200 Blake 30 Paris Bolt Green 17 Paris S4P2200 Clark 20 London Bolt Green 17 Paris S4P4300 Clark 20 London Screw Red 14 London S4P5400 Clark 20 London Cam Blue 12 Paris 8

9. The Idea Most or all attributes of a supplier should be also those of a supply in real life – A supplier and part name at least They cannot be in SP in SRV-model – Would need to be stored ones – SP would not be in 2NF – Would thus present numerous anomalies Its no more the case when they can be inherited ones – SIR-model 9

10. The Idea Sample SIR-model SQL query Select Sname, Pname From SP Where P# = ‘P1’ ; Equivalent SRV-model query Select Sname, Pname From S,SP,P Where SP.P# = ‘P1’ and S.S# = SP.S# and P.P# = SP.P# ; SIR-model query avoids the logical navigation 10

11. SRV-model solution A dedicated view SP1 Select Sname, Pname From SP1 Where P# = ‘P1’ ; Price to pay : an additional view scheme to manage If one does it for every stored relation, the # of S-P schemes at least doubles Using views for the CS is not conform to the ANSI-SPARC architecture – RDBs claimed to basically respect this one 11

12. SIR Structure Let R (S, V) be a SIR S are all stored attributes – Defined as usual (see the Fig.) Basically using any SQL DDL dialect V are all the inherited ones – Defined by one or more Inheritance Expressions (IEs) We require every key of R[S] to be also a key of R – Thus card (R) = card R[S] 12

13. SIR Structure Stored values are In grey Inherited ones are in yellow. IEs actually bring respectively three, four and as many tuples as there are stored ones. V unions all IAs. 13 S IE 1 Null IE 2 Null IE n Null

14. Inheritance Expressions An IE is a named relational expression – SQL basically – Partly similar to a view definition expression – But with additional joins Defining for each SIR tuple every value of an IA that should join it Bold in I_SP and called recursive join clause(s) – I_SP defines SP from SP – Meaning: current content of SP when I_SP is to be evaluated I_SP (Select SNAME, STATUS, S.CITY As SCITY, PNAME, COLOR, WEIGHT, P.CITY As PCITY From S,P,SP Where SP.S# = S.S# And SP.P# = P.P#); 14

15. Inheritance Expressions Every IE brings inherited values through single-sided outer join preserving every tuple pre-existing IE evaluation Some tuples may inherit nothing – Nulls on IA represents then the ‘nothing’ IAs V 1 …V n defined respectively by IE 1 …IE n should be all disjoins V should be V = V 1  …  V n Name conflicts should be resolved For each key value of R, there should be only one tuple of IAs joining it – A well-formed IE 15

16. Well-Formed Inheritance Expressions I_SP (Select SNAME, CITY, STATUS, S.CITY As SCITY, PNAME, COLOR, WEIGHT, P.CITY As PCITY From S,P,SP Where SP.S# = S.S# And SP.P# = P.P#); I_SP1 (Select SNAME, STATUS, S.CITY, PNAME, COLOR, WEIGHT, P.CITY From (SP Left Join S On SP.S# = S.S#) Left Join P On SP.P# = P.P#) I_SP inherits from S and from P I_SP1 inherits from S or from P 16

17. Multiple Inheritance Expressions I_S (Select SNAME, STATUS, S.CITY S.CITY As SCITY from S,SP WHERE SP.S# = S.S#) I_P (Select PNAME, COLOR, WEIGHT, P.CITY As PCITY from P,SP WHERE SP.P# = P.P#) Equivalent to I_SP1 Less procedural Likely to be preferred in practice Case should be general 17

18. More Inheritance Expressions Imagine that S.STATUS is the total quantity delivered by the supplier divided by hundred and rounded. Cumbersome to be represented as a stored integer But could result the IE in S implicitly named STATUS: (Select Int(SUM(QTY)/100) AS STATUS FROM S, SP GROUP BY S# WHERE S.S# = SP.S#). In SRV-model at least one stored and one inherited relation would be necessary for S instead. Or a complex value expression in the query for STATUS An ex. of more faithful conceptual modelling by by SIR- model 18

19. Inheritance Expressions Continued One wishes each supplier in S to have the attribute with the list of current supplies, including quantity and part names This IE in Create Table S would do: (Select LIST (P#, PNAME, QTY) As SUPPLIES From S, SP where S.# = SP.S# Group By SP.S# Order By Qty Dsc, PNAME Asc) Without LIST the IE would not be well-formed – I.e., would be invalid 19

20. DDL statements for SIR-model We suppose some kernel SQL dialect from SRV- model Kernel’s Create Table & Alter Table statements expand – To define or update also IEs Drop Table and Create Index stay as is – But Drop deletes IEs as well – Index may refer only to SAs See the paper for more 20

21. Example Suppose WEIGHT expressed implicitly in pounds. Alter P by appending IA WEIGTH_KG converting it to kilograms and IA WEIGTH_T converting further kilos to tons. Following Alter with two IEs would do Alter Table P Add (Select WEIGHT / 2.1 As WEIGTH_KG From P X, P Where X.WEIGHT = P.WEIGHT), (Select WEIGHT_KG / 1000 As WEIGTH_T From P X, P Where X.WEIGHT_KG = P.WEIGHT_KG); 21

22. Example Cont. Each IE bears implicit name of IA it creates – WEIGHT_KG and WEIGHT_T These are self-referencing IEs Proposed by major DBMSs since decades in fact Named virtual or computed attribute – A view-saver departure from Codd’s model – As SIRs are, but more generally See the paper for a simpler form of this Alter – With a single IE reusing the kernel syntax for virtual attributes in, e.g., SQL Server 22

23. Example Cont. Observe that after above alterations all three relations in SP-2 are SIRs The optimal scheme for S-P2 – Minimal # of relations free of anomalies As it will appear With much less need for the logical navigation than in Codd’s S-P And more faithful conceptual modeling – No more need for ER-modeling especially 23

24. DML statements for SIRs DML statements stay as they are in the kernel Any selection works as if any SIR involved was a view Updates to SAs work “classically” These to IAs require caution – E.g. to SP.CITY for S# = ‘S1’ and P# = ‘P1’ Some may be impossible – For calculated STATUS – For WEIGHT_KG and WEIGHT_T at present – But not in theory See the paper for more on this 24

25. SIR-model Schema Design Normal Forms We talk about 1-3NF, BCNF, 4-5NF – Classics of SRV-model – Avoiding the anomalies Any SIR is in 1NF by definition – Like both constructs in SRV-model SIR R (S, V) is in iNF or BCNF, iff R[S] is in iNF or BCNF Rationale : IAs do not create anomalies 25

26. Examples SP in S-P2 is in (restated) BCNF and 4NF – even in 5NF Stored SP’ (S#, SNAME, P#, QTY) would not be in BCNF – We recall, as S# -> SNAME SIR SP’ = SP [S#, SNAME, P#, QTY] would be – SNAME became an IA Generally, if any IA in SP became stored, SP would not be in BCNF anymore 26

27. Schema Design Goal : least number of relations free of anomalies – Same goal as for SRV-model Resulting DB scheme is called minimal or optimal In practice, each relation has to be proven in 4NF Or in BCNF at least – When relations are known to be with FDs only Case by far more frequent than the former – Of presence of non-trivial MVDs Non-respect de 5NF is very rare in both cases – Enough to be usually safely ignored – What we do as well 27

28. Schema Design “Least number of relations” means grouping of possibly all attributes FD-dependent on some, into the same relation – With “some” becoming a key – We take care of IAs as well, e.g. STATUS ‘Possibly’ means : open door for a myriad of other sometimes useful criteria – E.g., not too many nulls 28

29. Schema Design Generally we follow SRV-model – Restated for SIRs We start with the universal relation U – But U may now be an SIR U has anomalies almost always We decompose U into lossless projections – There are often several choices Any projection not anomaly-free is decomposed in turn – Until all are in BCNF The final result is the optimal scheme 29

30. Schema Design In presence of (non-trivial) MVDs, we decompose through restated Fagin’s Theorem In presence of anomalies due to FDs only, restated Heath’s Theorem applies Fagin’s decomposition must be first A sub-optimal scheme may result otherwise Generalization to SIRs of other known decomposition rules is the future work 30

31. Schema Design : End Result We reach the same number of relations as the SRV-model – But the latter takes care of SRs only thus Decomposition using restated Heat’s Th. avoids the logical navigation through the projections for any query – SRV-model does it for none Restated Fagin’s decomposition still does not help some queries – Hopefully rare 31

32. Restated Heat’s Theorem ABC (A,B,C) is an SIR with FD : A -> B A,B are Sas, A,B,C are perhaps composed We decompose ABC into AB (A, B) and ABC (A, B, C) B is “classically” an SA ABC.B in the projection is an IA in contrast Defined by the IE: (select B from AB where AB.B = ABC.B) Result helps every select …B,C… 32

33. Restated Fagin’s Theorem ABC (A,B,C) is an SIR with MVD A ->> B | C A,B,C are perhaps composed, from SAs in partic. B’ is a (perhaps empty) subset of B where A -> B’ C’ is a (perhaps empty) subset of C where A -> C’ We decompose into AB (A, B, C’) and AC (A, B’, C) C’ results IE (select C’ from AC where AB. A = AC.A) B’ results IE (select B’ from AB where AB. A = AC.A) 33

34. Restated Fagin’s Theorem B’ is a (perhaps empty) subset of B where A -> B’ C’ is a (perhaps empty) subset of C where A -> C’ We decompose into AB (A, B, C’) and AC (A, B’, C) C’ results IE (select C’ from AC where AB. A = AC.A) B’ results IE (select B’ from AB where AB. A = AC.A) This decomposition – Helps select …, B,C’ and select …B’,C – But does not help select …B,C 34

35. Examples S-P2 needs only Heath’s decomposition – As we said, it is the optimal scheme – Also with IAs STATUS, WEIGHT_KG and WEIGHT_T Easy to see – Otherwise see the paper See the paper for the examples of – Restated Fagin’s Decomposition – Sub-optimal scheme if it is not performed 1st on U 35

36. Implementing SIRs SIRs should use an existing DBMS SIRs could be managed by a specific SIR-layer Internally calling the services of the DBMS SIR-layer should allow for SIRs, stored (only) relations and views Servicing the latter two by the DBMS is a trivial story Servicing SIRs is not 36 SIR-layer DBMS

37. Implementing SIRs SIR-layer creates in DBMS for each SIR R (S, V) : – One stored relation named R_S with attributes S – One full view R with all the attributes and values of SIR R – One view R 1 …R n for each IE I 1 …I n defining SIR R IEs are in some necessary or user-chosen order Each view R j ; j > 1 ; refers to R j – 1 and to I j R 1 refers to R 0 = R_S and R n is R 37

38. Implementing SIRs Each R j preserves all the values of R j – 1 – Using Select …. From R j – 1 Left Join On R j – 1.A = B With A and B being the attributes in the recursive join clause of I j Perhaps composed Once view R gets created, when SIR-layer gets Select … From R… from the user, It forwards the query as is to DBMS for execution on view R 38

39. Examples SIR-layer gets Creating Table SP… with our two IEs I_S inheriting all from S and I_P everything from P SIR-layer issues to DBMS the commands: Create Table SP_S …. from all and only stored attributes of SP. Create View SP_1 As select SP_S.*, SNAME, STATUS, S.CITY From SP_S Left Join S On SP.S# = S.S# ; Create View SP As select SP_1.*, PNAME, COLOR, WEIGHT, P.CITY From SP_1 Left Join P On SP.P# = P.P# ;. DBMS subsequently executes every Select …From SP received from SIR-layer as query to view SP 39

40. Examples S-P3 DB with calculated STATUS, SUPPLIES, WEIGHT_KG and WEIGHT_T 40

41. Conclusion SIR construct appears useful Solves decades’ old problems Eliminates current need for ER-model Should not have operational overhead in practice DBMSs should integrate it – “Better late than never” Future work : Implementation & see the paper 41

42. Thanks For Your Attention Witold LITWIN Witold.litwin@dauphine.fr 42