1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen Organization of Large Database Applications These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see

2 © Ellis Cohen Overview of Lecture Subsystems Subsystem Design Problems Subsystems & Information Hiding Database-Oriented Subsystems

3 © Ellis Cohen Subsystems

4 © Ellis Cohen Subsystems Subsystem Name ~ visible data - private data ~ visible data ~ visible operation - private operation ~ visible operation Subsystems contain operations and data some of which are public/visible (outside of the subsystem) and some of which are private (to the subsystem)

5 © Ellis Cohen Subsystem Dependencies Subsystems have dependencies on other subsystems (shown as dashed lines) if they use their data or operations. It is preferable that there be no cycles in the dependency graph. A  subsystem operation may use any operation or data of its own, as well as the visible/public operations or data of any of its dependent children. Each piece of data is assigned to EXACTLY ONE subsystem

6 © Ellis Cohen Nested Subsystems Parent Subsystem Child Subsytems A subsystem may itself be so large, that it may need to be divided into child subsystems An operation of a parent system may use any operation or data of its own, as well as the visible/public operations of any of its nested children.

7 © Ellis Cohen Nested Subsystem Visibility A parent subsystem provides encapsulated functionality to other subsystems. Visible (~) components are only visible within the parent subsytem Public (+) components are also visible outside the parent subsystem Parent Subsystem + ~ + ~ ~ visible + public Child Subsytems

8 © Ellis Cohen Subsystem Design Problems

9 © Ellis Cohen Subsystem Design Problem 1 You are given a system S with data D1 and D2. The public operations and the data each one uses are op1: D1,D2 op2: D1,D2 op3: D1,D2 op4: D1,D2 op5: D1,D2 op6: D1,D2 op7: D1,D2 op8: D1,D2 op9: D1,D2 op10: D1,D2 Organize this into subsystems

10 © Ellis Cohen Subsystem Design Solution 1 S -D1 -D2 + op1 + op2 + op3 + op4 + op5 + op6 + op7 + op8 + op9 + op10 There just needs to be a single subsystem with D1 and D2, since no operations uses just one of them D1 and D2 can both be private, since there are no operations outside the subsystems that use them

11 © Ellis Cohen Subsystem Design Problem 2 You are given a system S with data D1 and D2. The public operations and the data each one uses are op1: D1 op2: D2 op3: D1 op4: D1 op5: D1 op6: D1 op7: D2 op8: D2 op9: D2 op10: D1 Organize this into subsystems

12 © Ellis Cohen Subsystem Design Solution 2 S1 - D1 + op1 + op3 + op4 + op5 + op6 + op10 - D2 + op2 + op7 + op8 + op9 S2 Separate the system into S1 (around D1) and S2 (around D2) because there are no operations that use both D1 and D2 D1 and D2 can both be private, since there are no operations outside of their respective subsystems that use them S

13 © Ellis Cohen Subsystem Design Problem 3 You are given a system S with data D1 and D2. The public operations and the data each one uses are op1: D1 op2: D1,D2 op3: D1,D2 op4: D2 op5: D1,D2 op6: D1 op7: D1,D2 op8: D1,D2 op9: D1,D2 op10: D1,D2 Organize this into subsystems

14 © Ellis Cohen Subsystem Design Solution 3a S1 ~ D1 + op1 + op6 ~ D2 + op4 S2 S12 + op2 + op3 + op5 + op7 + op8 + op9 + op10 S There are a few operations that use just D1 or just D2, so it is not clear whether it is worth defining S1 and S2 for so few operations

15 © Ellis Cohen Subsystem Design Solution 3b S1 ~ D1 + op1 + op6 ~ D2 + op4 S2 S + op2 + op3 + op5 + op7 + op8 + op9 + op10 No need to place the operations that need both D1 and D2 is a separate subsystem. Operations in a parent system can use the visible/public date/operations of its children

16 © Ellis Cohen Subsystem Design Solution 3c S -D1 -D2 + op1 + op2 + op3 + op4 + op5 + op6 + op7 + op8 + op9 + op10 There are a few operations that use just D1 or just D2, but the bulk of the operations use both of them, so there may not be enough to be gained from separating them to offset the cost of defining two additional subsystems. However, this solution is not as good from an information hiding or security perspective

17 © Ellis Cohen Subsystem Design Problem 4 You are given a system S with data D1, D2 and D3. The public operations and the data each one uses are op1: D1, D2 op2: D2, D3 op3: D1, D2 op4: D1, D2 op5: D1, D2 op6: D2, D3 op7: D2, D3 op8: D2, D3 op9: D1, D2 op10: D1, D2 Organize this into subsystems

18 © Ellis Cohen Subsystem Design Solution 4 S2 ~ D2 You want one developer to only have to deal with D1 (and, of course its interactions with D2), and a separate developer to only have to deal with D3 (and its interactions with D2). S2 is needed because a piece of data can only be assigned to one subsystem. Also, you may want to assign a developer to "own" D2 and interact with the developers of S12 and S23. -D1 + op1 + op3 + op4 + op5 + op9 + op10 S12 -D3 + op2 + op6 + op7 + op8 S23 S

19 © Ellis Cohen Subsystem Design Problem 5 You are given a system with data D1 and D2. The public operations and the data each one uses are op1: D2 op2: D2 op3: D1, D2 op4: D1 op5: D1 op6: D1 op7: D2 op8: D2 op9: D2 op10: D1 Organize this into subsystems

20 © Ellis Cohen Subsystem Design Solution 5a S1 ~ D1 + op4 + op5 + op6 + op10 ~ D2 + op1 + op2 + op7 + op8 + op9 S2 It is worth dividing the system into S1 and S2 since there are a significant number of operations that just use D1 or just use D2. But S12 depends on both S1 and S2, since it uses D1 from S1 and D2 from S2. Both D1 and D2 need to be visible, since they are used by S12. S +op3

21 © Ellis Cohen Subsystem Design Solution 5b ~ D2 + op1 + op2 + op7 + op8 + op9 S2 S2 contains the operations which only depend upon D2. S not only contains the operations which only depend upon D1, but also op3, which uses D2. D2 must be visible, since op3 uses it. This solution is only reasonable if there a more general reason why S needs to know about S2 – one good reason is that D1 has a reference to data in D2 S - D1 + op3 + op4 + op5 + op6 + op10

22 © Ellis Cohen Subsystem Organization Goals Cohesive Most tables in the subsystem should be used by most of the operations of the subsystem. Independent Most tables an operation needs should be part of the same subsystem. This principles argues against making subsystems too large. Acyclic Avoid cycles in the subsystem graph. –Sometimes cycles can be fixed by reorganizing subsystems. –Sometimes you must also change your relational model. A good design balances these goals

23 © Ellis Cohen Subsystems & Information Hiding

24 © Ellis Cohen Information Hiding It sometimes can be useful to hide visible data by instead making functionality available through visible (but not public) operations. Suppose op3 actually computes f1(D1) + f2(D2) Redesign the subsystems

25 © Ellis Cohen Subsystem Design Solution 5a S1 - D1 + op4 + op5 + op6 + op10 ~ f1 - D2 + op1 + op2 + op7 + op8 + op9 ~ f2 S2 S +op3 D1 and D2 can now be made private, since they are not needed directly outside of their respective subsystems. op3 can get the needed information by calling f1 and f2, which are visible (but not public) operations

26 © Ellis Cohen D1 + op3 + op4 + op5 + op6 + op10 - f1 Subsystem Design Solution 5b - D2 + op1 + op2 + op7 + op8 + op9 ~ f2 S2 S D2 can be made private, since it is not needed directly outside of its subsystems. f2 is visible in S2, since op3 needs to call it.

27 © Ellis Cohen Subsystem Design Solution 5b' S12 - D1 + op3 + op4 + op5 + op6 + op10 - f1 - D2 + op1 + op2 + op7 + op8 + op9 ~ f2 S2 D1 and D2 can be made private, since they are not needed directly outside of their respective subsystems. f2 is visible in S2, since op3 in S12 needs to call it. But f1 can now be private in S1, since op3 is in f1 as well

28 © Ellis Cohen Database-Oriented Subsystems

29 © Ellis Cohen Database-Oriented Subsystems Database Applications can be organized into subsystems as well, following the same principles –The data of a database subsystem can include tables and views (and package variables) –Operations include procedures, functions and cursors, which can be organized into one or more packages

30 © Ellis Cohen Subsystems & Packages Subsystem Name ~ visible tables - private tables ~ visible tables ~ visible operation - private operation ~ visible operation Package ~ visible variables - private variables ~ visible views - private views

31 © Ellis Cohen View-Based Encapsulation In databases, views & cursors play the most significant encapsulation role. A subsystem can keep a table (e.g. T) private by making a cursor or view (e.g. V) visible. Changes can then be made to the underlying table representation (and to the view definition), but other subsystems that use the view will not need to be changed - T + V

32 © Ellis Cohen Enforcing Information Hiding It is possible to enforce information hiding by –using a separate schema for each subsystem –granting privileges (SELECT for the views, and EXECUTE for the packages) to the other subsystem schemas that depend on it Even without enforcement, a subsystem organization enhances maintainability