1. COMP 5138 Relational Database Management Systems Semester 2, 2007 Lecture 8 Database System Architectures

2. 22 L8 DB System Architectures Database System Architectures Centralized systems Client-Server systems Three-tier systems Presentation layer technologies Application layer technologies Today’s Agenda

3. 33 L8 DB System Architectures Three types of functionality: The system architecture determines whether these three components reside on a single system (1-tier) or whether they are distributed across several tiers Presentation Services - Input – keyboard/mouse - Output – monitor/printer Application Services - Business rules - I/O processing Data Management (Storage Logic) - data storage and retrieval GUI Interface Procedures, functions, programs DBMS activities Data-intensive Systems

4. 44 L8 DB System Architectures Single-User System Presentation Services - displays forms, handles flow of information to/from screen Application Services - implements user request, interacts with DBMS Transactional properties automatic (isolation is trivial) or not required (this is not really an enterprise) DBMS runs within the user process Examples: Access or Berkeley DB presentation application services DBMS user module centralized system

5. 55 L8 DB System Architectures Centralized Multi-User System Dumb terminals connected to mainframe Application and presentation services on mainframe ACID properties required Atomicity - Consistency - Isolation - Durability Isolation: DBMS sees an interleaved schedule Atomicity and durability: system supports a major enterprise Transaction abstraction, implemented by DBMS, provides ACID properties More details on implementing transactions in week 11

6. 66 L8 DB System Architectures Centralized Multi-User System user module central machine presentation application services presentation application services communication DBMS dumb terminal

7. 77 L8 DB System Architectures Evaluation All functionality combined into a single tier Centralised system: runs on a single computer system and does not interact with other computer systems System resources must be used for both DBMS and application logic Usually: mainframe, but also PC Benefit: Easy maintenance and central administration Drawback: Bad scalability for larger number of users Typically only dumb terminals as a user interface

8. 88 L8 DB System Architectures Two-Tier Architectures: Client-Server Functionality divided between client and server typically separated by a network Server systems satisfy requests of m client systems

9. 99 L8 DB System Architectures Front-End versus Back-End Database functionality can be divided into: Back-end: manages access structures, query evaluation and optimization, concurrency control and recovery. Front-end: consists of tools such as forms, report- writers, and graphical user interface facilities. The interface between the front-end and the back-end is through SQL or through an application program interface. SQL user- interface forms interface report writer graphical interface front-end interface (SQL ; API) SQL engine back-end

10. 1010 L8 DB System Architectures Thin versus Thick Client Database applications: data management + application logic + presentation Work division: Thin client Client responsible for presentation (typically GUI) Server: business logic and data management Work division: Thick client Client implements both user interface and business logic Server: data management only Application Logic Data Presentation Client Data Management Server ??

11. 1111 L8 DB System Architectures C/S Architecture “Zoom-In” Client and server are completely separated 2 separated processes / systems Communication between client & server via network Usage of a special protocol, e.g. JDBC, Net8 (Oracle) DB Server Library Operating System DB Server Process DB Client Library / Driver Operating System Client Process Network ServerClient

12. 1212 L8 DB System Architectures DB Server Internals DB Server Monolithic Server single DB process Multiple Server multiple DB processes Symmetric per AP one DB process Asymmetric dynamic assignment of APs to DB processes

13. 1313 L8 DB System Architectures Monolithic Server Exactly one server process for all clients (“One-to-many”) DBMS server process typically prioritised by operating system Server uses multi-threading Server does own resource management Examples: Sybase, MS SQL Server AP Client i DBMS Server operating system 1 AP Client 1 CL AP Client k CL operating system n network …

14. 1414 L8 DB System Architectures Multiple Server DBMS consists of several processes Scheduling done by the operating system Communication between server processes: via shared memory clients and servers: via operating system or network Two variants: Symmetric - each client is mapped to exactly one server process: static mapping with a certain number of n servers pre-generated  maximal degree of parallelism is n Asymmetric - a dispatcher connects a client to a server process. Again, a certain number of servers are instantiated beforehand, but degree of parallelism can be higher Examples: Oracle, Informix, DB2

15. 1515 L8 DB System Architectures Asymmetric Multiple Server DBMS Server k AP Client i DBMS Server 1 Operating system 1 AP Client 1 CL AP Client m CL Operating system n network …… Dispatcher shared mem

16. 1616 L8 DB System Architectures Oracle Server Architecture

17. 1717 L8 DB System Architectures Oracle Server Configurations

18. 1818 L8 DB System Architectures Oracle Client-Server Connections

19. 1919 L8 DB System Architectures Comparison Thick Clients Makes good use of resources on desktop machines which are often lightly loaded Allows server machine to concentrate on disk transfers etc More responsive Some responses don’t need to cross the network Eg data validation done in client May scale better Perhaps smaller and fewer data transfers between client and server (if many different presentations are needed of the same data) Thin clients Server doesn’t need to trust clients No threat to data integrity from malicious client Less complex administration and maintenance Eg no need to deploy upgrades or patches to application logic? May scale better Perhaps smaller and fewer data transfers between client and server (if results of database queries are further reduced and filtered in application layer, to just what user needs) The best design varies according to technology changes

20. 2020 L8 DB System Architectures Three-Tier Architectures Client Program Web / Application Server Database System Presentation Tier Middle Tier Data Management Tier primary interface to the user (e.g. web browser) needs to adapt to different display devices (PC, PDA,...) implements business logic and workflow may access several different DBMSs one or more standard database management systems

21. 2121 L8 DB System Architectures Three-Tiered Model of TPS DBMS database server machine present. server client machines communication present. server applic. server applic. server machines trans. server trans. server machines typically clustered

22. 2222 L8 DB System Architectures Interconnection/Clustering of Servers in Three-Tiered Model presentation server presentation server presentation server presentation server application server application server transaction server transaction server database server database server

23. 2323 L8 DB System Architectures E-Commerce as Example Web Server (dynamic web pages such as CGI or JSP) JDBC or ODBC Web Browser http Database System network Web browser is client Application logic in dynamic web pages Servlets or “Java Server Pages” (JSP): Java code that runs in web server Non-Java world: ASP, PHP, CGI, … Database access from servlets / JSPs via JDBC

24. 2424 L8 DB System Architectures More complicated example Web Browser Web Server (servlets; JSP) Database System network Application Server http EJB JDBC ODBC RMI Dynamic web pages mostly presentation Again servlets or JSPs Application Server Container for application logic e.g. Enterprise Java Beans (EJB) Resource mgmt. (e.g. db connections) Database system is accessed from application server using JDBC or ODBC

25. 2525 L8 DB System Architectures Example 1: Course Enrolment System Build a system in which students can enroll in courses Client Program Log in different users (students, staff, faculty), display forms and human- readable output Web Server Logic to add a course, drop a course, create a new course, etc. Database System Student info, course info, instructor info, course availability, pre- requisites, etc. Browser Web Server Database(s) Server Client

26. 2626 L8 DB System Architectures Example 2: Internet Shop Web Browser: GUI, navigation, presentation, simple input checks WWW Server: Log in different users, session management, display forms etc. Application Server: Logic for placing orders, purchasing, order status checks, etc. Database item infos, customer data, orders, … Browser Web Server Database(s) Server Client Application Server Server Client

27. 2727 L8 DB System Architectures Technologies for the Three Tiers Client Program (Web Browser) Application Logic (Web Server; Application Server) Data Management (Database System) HTML JavaScript Servlets; JSP; ASP J2EE; EJB;.NET SQL, XML Stored Procedures HTTP JDBC; SQLJ; OLEDB

28. 2828 L8 DB System Architectures Advantages of Three-Tier Architectures Heterogeneous Systems Tiers can be independently maintained, modified, and replaced Thin Clients Only presentation layer at clients (web browser) Integrated data access Several database systems can be handled transparently at the middle tier Central management of connections Scalability Replication at middle tier allows scalability of business logic Software development Code for business logic is centralised Interaction between tiers through well-defined APIs: One can reuse standard components at each tier

29. 2929 L8 DB System Architectures Review Question What kind of system architecture has Oracle’s iSQL*Plus, which we are using in the labs? A.1-Tier (centralized) B.2-Tier (Client/Server) C.3-Tier

30. 3030 L8 DB System Architectures Database System Architectures Presentation layer technologies HTML, Javascript Application layer technologies Today’s Agenda

31. 3131 L8 DB System Architectures Overview of the Presentation Tier Recall: Functionality of the presentation tier Primary interface to the user Needs to adapt to different display devices (PC, PDA, cell phone, voice access?) Simple functionality, such as field validity checking We will cover: HTML Forms: How to pass data to the middle tier JavaScript: Simple functionality at the presentation tier

32. 3232 L8 DB System Architectures HTML Forms Common way to communicate data from client to middle tier General format of a form: … Components of an HTML FORM tag: ACTION: Specifies URI that handles the content METHOD: Specifies HTTP GET or POST method NAME: Name of the form; can be used in client-side scripts to refer to the form

33. 3333 L8 DB System Architectures Inside HTML Forms INPUT tag Attributes: TYPE: text (text input field), password (text input field where input is, reset (resets all input fields) NAME: symbolic name, used to identify field value at the middle tier VALUE: default value Example: Example form:

34. 3434 L8 DB System Architectures Passing Arguments Two methods: GET and POST GET Form contents go into the submitted URI Structure: action?name1=value1&name2=value2&name3=value3 Action: name of the URI specified in the form (name,value)-pairs come from INPUT fields in the form; empty fields have empty values (“name=“) Example from previous password form: TableOfContents.jsp?userid=john&password=johnpw Note that the page named action needs to be a program, script, or page that will process the user input

35. 3535 L8 DB System Architectures HTTP GET: Encoding Form Fields Form fields can contain general ASCII characters that cannot appear in an URI A special encoding convention converts such field values into “URI-compatible” characters: Convert all “special” characters to %xyz, were xyz is the ASCII code of the character. Special characters include &, =, +, %, etc. Convert all spaces to the “+” character Glue (name,value)-pairs from the form INPUT tags together with “&” to form the URI

36. 3636 L8 DB System Architectures HTML Forms: A Complete Example Userid Password <input type="submit" value="Login“ name="submit">

37. 3737 L8 DB System Architectures JavaScript Goal: Add functionality to the presentation tier. Sample applications: Detect browser type and load browser-specific page Form validation: Validate form input fields Browser control: Open new windows, close existing windows (example: pop-up ads) Usually embedded directly inside the HTML with the … tag. tag has several attributes: LANGUAGE: specifies language of the script (such as javascript) SRC: external file with script code Example:

38. 3838 L8 DB System Architectures JavaScript (Contd.) If tag does not have a SRC attribute, then the JavaScript is directly in the HTML file. Example: Two different commenting styles <!-- comment for HTML, since the following JavaScript code should be ignored by the HTML processor // comment for JavaScript in order to end the HTML comment

39. 3939 L8 DB System Architectures JavaScript (Contd.) JavaScript is a complete scripting language Variables Assignments (=, +=, …) Comparison operators (,…), boolean operators (&&, ||, !) Statements if (condition) {statements;} else {statements;} for loops, do-while loops, and while-loops Functions with return values Create functions using the function keyword f(arg1, …, argk) {statements;}

40. 4040 L8 DB System Architectures JavaScript: A Complete Example HTML Form: <form method="POST“ action="TableOfContents.jsp"> Associated JavaScript: function testLoginEmpty() { loginForm = document.LoginForm if ((loginForm.userid.value == "") || (loginForm.password.value == "")) { alert('Please enter values for userid and password.'); return false; } else return true; }

41. 4141 L8 DB System Architectures Stylesheets Idea: Separate display from contents, and adapt display to different presentation formats Two aspects: Document transformations to decide what parts of the document to display in what order Document rending to decide how each part of the document is displayed Why use stylesheets? Reuse of the same document for different displays Tailor display to user’s preferences Reuse of the same document in different contexts Two stylesheet languages Cascading style sheets (CSS): For HTML documents Extensible stylesheet language (XSL): For XML documents

42. 4242 L8 DB System Architectures CSS: Cascading Style Sheets Defines how to display HTML documents Many HTML documents can refer to the same CSS Can change format of a website by changing a single style sheet Example: Each line consists of three parts: selector {property: value} Selector: Tag whose format is defined Property: Tag’s attribute whose value is set Value: value of the attribute

43. 4343 L8 DB System Architectures CSS: Cascading Style Sheets Example style sheet: body {background-color: yellow} h1 {font-size: 36pt} h3 {color: blue} p {margin-left: 50px; color: red} The first line has the same effect as:

44. 4444 L8 DB System Architectures XSL Language for expressing style sheets More at: http://www.w3.org/Style/XSL/ Three components XSLT: XSL Transformation language Can transform one document to another More at http://www.w3.org/TR/xslt XPath: XML Path Language Selects parts of an XML document More at http://www.w3.org/TR/xpath XSL Formatting Objects Formats the output of an XSL transformation More at http://www.w3.org/TR/xsl/

45. 4545 L8 DB System Architectures Database System Architectures Presentation layer technologies Application layer technologies CGI, application servers, Servlets, JavaServerPages, maintaining state Today’s Agenda

46. 4646 L8 DB System Architectures Overview of the Middle Tier Recall: Functionality of the middle tier Encodes business logic Connects to database system(s) Accepts form input from the presentation tier Generates output for the presentation tier We will cover CGI: Protocol for passing arguments to programs running at the middle tier Application servers: Runtime environment at the middle tier Servlets: Java programs at the middle tier JavaServerPages: Java scripts at the middle tier Maintaining state: How to maintain state at the middle tier. Main focus: Cookies.

47. 4747 L8 DB System Architectures CGI: Common Gateway Interface Goal: Transmit arguments from HTML forms to application programs running at the middle tier Details of the actual CGI protocol unimportant à libraries implement high-level interfaces Disadvantages: The application program is invoked in a new process at every invocation (remedy: FastCGI) No resource sharing between application programs (e.g., database connections) Remedy: Application servers

48. 4848 L8 DB System Architectures CGI: Example HTML form: Type an author name: Perl code: use CGI; $dataIn=new CGI; $dataIn->header(); $authorName=$dataIn->param(‘authorName’); print(“ Argument passing test ”); print(“The author name is “ + $authorName); print(“ ”); exit;

49. 4949 L8 DB System Architectures Application Servers Idea: Avoid the overhead of CGI Main pool of threads of processes Manage connections Enable access to heterogeneous data sources Other functionality such as APIs for session management

50. 5050 L8 DB System Architectures Application Server: Process Structure Process Structure Web BrowserWeb Server Application Server C++ Application JavaBeans DBMS 1 DBMS 2 Pool of Servlets HTTP JDBC ODBC

51. 5151 L8 DB System Architectures Servlets Java Servlets: Java code that runs on the middle tier Platform independent Complete Java API available, including JDBC Example: import java.io.*; import java.servlet.*; import java.servlet.http.*; public class ServetTemplate extends HttpServlet { public void doGet(HTTPServletRequest request, HTTPServletResponse response) throws SerletExpection, IOException { PrintWriter out=response.getWriter(); out.println(“Hello World”); } }

52. 5252 L8 DB System Architectures Servlets (Contd.) Life of a servlet? Webserver forwards request to servlet container Container creates servlet instance (calls init() method; deallocation time: calls destroy() method) Container calls service() method service() calls doGet() for HTTP GET or doPost() for HTTP POST Usually, don’t override service(), but override doGet() and doPost()

53. 5353 L8 DB System Architectures Servlets: A Complete Example public class ReadUserName extends HttpServlet { public void doGet(HttpServletRequest request, HttpSevletResponse response) throws ServletException, IOException { reponse.setContentType(“text/html”); PrintWriter out=response.getWriter(); out.println(“ \n \n” + “ ” + request.getParameter(“userid”) + “\n” + “ ” + request.getParameter(“password”) + “\n” + “ \n ”); } public void doPost(HttpServletRequest request, HttpSevletResponse response) throws ServletException, IOException { doGet(request,response); } }

54. 5454 L8 DB System Architectures Java Server Pages Servlets Generate HTML by writing it to the “PrintWriter” object Code first, webpage second JavaServerPages Written in HTML, Servlet-like code embedded in the HTML Webpage first, code second They are usually compiled into a Servlet

55. 5555 L8 DB System Architectures JavaServerPages: Example Welcome to B&N Welcome back! <% String name=“NewUser”; if (request.getParameter(“username”) != null) { name=request.getParameter(“username”); } %> You are logged on as user

56. 5656 L8 DB System Architectures Maintaining State HTTP is stateless. Advantages Easy to use: don’t need anything Great for static-information applications Requires no extra memory space Disadvantages No record of previous requests means No shopping baskets No user logins No custom or dynamic content Security is more difficult to implement

57. 5757 L8 DB System Architectures Application State Server-side state Information is stored in a database, or in the application layer’s local memory Client-side state Information is stored on the client’s computer in the form of a cookie Hidden state Information is hidden within dynamically created web pages

58. 5858 L8 DB System Architectures Application State So many kinds of state… …how will I choose?

59. 5959 L8 DB System Architectures Server-Side State Many types of Server side state: 1. Store information in a database Data will be safe in the database BUT: requires a database access to query or update the information 2. Use application layer’s local memory Can map the user’s IP address to some state BUT: this information is volatile and takes up lots of server main memory 5 million IPs = 20 MB

60. 6060 L8 DB System Architectures Server-Side State Should use Server-side state maintenance for information that needs to persist Old customer orders “Click trails” of a user’s movement through a site Permanent choices a user makes

61. 6161 L8 DB System Architectures Client-side State: Cookies Storing text on the client which will be passed to the application with every HTTP request. Can be disabled by the client. Are wrongfully perceived as "dangerous", and therefore will scare away potential site visitors if asked to enable cookies 1 Are a collection of (Name, Value) pairs 1 http://www.webdevelopersjournal.com/columns/stateful.html

62. 6262 L8 DB System Architectures Client State: Cookies Advantages Easy to use in Java Servlets / JSP Provide a simple way to persist non-essential data on the client even when the browser has closed Disadvantages Limit of 4 kilobytes of information Users can (and often will) disable them Should use cookies to store interactive state The current user’s login information The current shopping basket Any non-permanent choices the user has made

63. 6363 L8 DB System Architectures Creating A Cookie Cookie myCookie = new Cookie( “ username", “ jeffd"); response.addCookie(userCookie); You can create a cookie at any time

64. 6464 L8 DB System Architectures Accessing A Cookie Cookie[] cookies = request.getCookies(); String theUser; for(int i=0; i<cookies.length; i++) { Cookie cookie = cookies[i]; if(cookie.getName().equals( “ username ” )) theUser = cookie.getValue(); } // at this point theUser == “ username ” Cookies need to be accessed BEFORE you set your response header: response.setContentType("text/html"); PrintWriter out = response.getWriter();

65. 6565 L8 DB System Architectures Cookie Features Cookies can have A duration (expire right away or persist even after the browser has closed) Filters for which domains/directory paths the cookie is sent to See the Java Servlet API and Servlet Tutorials for more information

66. 6666 L8 DB System Architectures Hidden State Often users will disable cookies You can “hide” data in two places: Hidden fields within a form Using the path information Requires no “storage” of information because the state information is passed inside of each web page

67. 6767 L8 DB System Architectures Hidden State: Hidden Fields Declare hidden fields within a form: Users will not see this information (unless they view the HTML source) If used prolifically, it’s a killer for performance since EVERY page must be contained within a form.

68. 6868 L8 DB System Architectures Hidden State: Path Information Path information is stored in the URL request: http://server.com/index.htm?user=jeffd Can separate ‘fields’ with an & character: index.htm?user=jeffd&preference=pepsi There are mechanisms to parse this field in Java. Check out the javax.servlet.http.HttpUtils parserQueryString() method.

69. 6969 L8 DB System Architectures Multiple state methods Typically all methods of state maintenance are used: User logs in and this information is stored in a cookie User issues a query which is stored in the path information User places an item in a shopping basket cookie User purchases items and credit-card information is stored/retrieved from a database User leaves a click-stream which is kept in a log on the web server (which can later be analyzed)

70. 7070 L8 DB System Architectures Extra non-examined material Parallel System Distributed System See R+G ch 22 for more information Today’s Agenda

71. 7171 L8 DB System Architectures Parallel Systems Parallel database systems consist of multiple processors and multiple disks connected by a fast interconnection network. A coarse-grain parallel machine consists of a small number of powerful processors A massively parallel or fine grain parallel machine utilizes thousands of smaller processors. Two main performance measures: throughput --- the number of tasks that can be completed in a given time interval response time --- the amount of time it takes to complete a single task from the time it is submitted

72. 7272 L8 DB System Architectures Terminology Speed-Up More resources means proportionally less time for given amount of data. Scale-Up If resources increased in proportion to increase in data size, time is constant. degree of parallel Xact/sec. (throughput) Ideal degree of parallel sec./Xact (response time) Ideal

73. 7373 L8 DB System Architectures Factors Limiting Speedup and Scaleup Speedup and scale-up are often sub-linear due to: Startup costs: Cost of starting up multiple processes may dominate computation time, if the degree of parallelism is high. Interference: Processes accessing shared resources (e.g.,system bus, disks, or locks) compete with each other, thus spending time waiting on other processes, rather than performing useful work. Skew: Increasing the degree of parallelism increases the variance in service times of parallel executing tasks. Overall execution time determined by slowest of parallel executing tasks.

74. 7474 L8 DB System Architectures Parallel System Architectures Shared memory -- processors share a common memory Shared disk -- processors share a common disk Shared nothing -- processors share neither a common memory nor common disk Hierarchical -- hybrid of the above architectures

75. 7575 L8 DB System Architectures Parallel System Architectures

76. 7676 L8 DB System Architectures Shared Memory Processors and disks have access to a common memory, typically via a bus or through an interconnection network. Extremely efficient communication between processors Data in shared memory can be accessed by any processor without having to move it using software. Downside: architecture is not scalable beyond 32 or 64 processors since the bus or the interconnection network becomes a bottleneck Widely used for lower degrees of parallelism (4 to 8).

77. 7777 L8 DB System Architectures Shared Disk All processors can directly access all disks via an interconnection network, but the processors have private memories. The memory bus is not a bottleneck Architecture provides a degree of fault-tolerance — if a processor fails, the other processors can take over its tasks since the database is resident on disks that are accessible from all processors. Examples: IBM Sysplex and DEC clusters (now part of Compaq) running Rdb (now Oracle Rdb) were early commercial users Downside: bottleneck now occurs at interconnection to the disk subsystem. Shared-disk systems can scale to a somewhat larger number of processors, but communication between processors is slower.

78. 7878 L8 DB System Architectures Shared Nothing Node consists of a processor, memory, and one or more disks. Processors at one node communicate with another processor at another node using an interconnection network. A node functions as the server for the data on the disk or disks the node owns. Examples: Teradata, Tandem, Oracle-n CUBE Data accessed from local disks (and local memory accesses) do not pass through interconnection network, thereby minimizing the interference of resource sharing. Shared-nothing multiprocessors can be scaled up to thousands of processors without interference. Main drawback: cost of communication and non-local disk access; sending data involves software interaction at both ends.

79. 7979 L8 DB System Architectures Hierarchical Combines characteristics of shared-memory, shared-disk, and shared-nothing architectures. Top level is a shared-nothing architecture – nodes connected by an interconnection network, and do not share disks or memory with each other. Each node of the system could be a shared- memory system with a few processors. Alternatively, each node could be a shared- disk system, and each of the systems sharing a set of disks could be a shared-memory system.

80. 8080 L8 DB System Architectures Distributed DBMS Data is stored at several sites, each managed by a DBMS that can run independently. Distributed Data Independence: Users should not have to know where data is located (extends Physical and Logical Data Independence principles). Distributed Transaction Atomicity: Users should be able to write transactions accessing multiple sites just like local transactions.

81. 8181 L8 DB System Architectures Recent Trends Users have to be aware of where data is located, i.e., Distributed Data Independence and Distributed Transaction Atomicity are not supported. These properties are hard to support efficiently. For globally distributed sites, these properties may not even be desirable due to administrative overheads of making the location of the data transparent.

82. 8282 L8 DB System Architectures Types of Distributed Databases Homogeneous: Every site runs the same type of DBMS. Heterogeneous: Different sites run different DBMSs (different RDBMSs or even non-relational DBMSs). DBMS1DBMS2DBMS3 Gateway

83. 8383 L8 DB System Architectures Storing Data Fragmentation Horizontal Vertical Replication Gives increased availability Faster query evaluation TID t1 t2 t3 t4 R1 R2 R3 SITE A SITE B

84. 8484 L8 DB System Architectures Distributed Catalog Management Must keep track of how data is distributed across sites. Must be able to name each replica of each fragment. To preserve local autonomy: Site Catalog: Describes all objects (fragments, replicas) at a site + Keeps track of replicas of relations created at this site. To find a relation, look up its birth-site catalog. Birth-site never changes, even if relation is moved.

85. 8585 L8 DB System Architectures Distributed Queries Horizontally Fragmented: Tuples with rating = 5 at Melbourne. Must compute SUM (age), COUNT (age) at both sites. If WHERE contained just S.rating>6, just one site. Vertically Fragmented: sid and rating at Sydney, sname and age at Melbourne, tid at both. Must reconstruct relation by join on tid, then evaluate the query. Replicated: Sailors copies at both sites. Choice of site based on local costs, shipping costs. SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND S.rating < 7