Patel Group of Institutions Advance Database Management System MCA SEM V UNIT -1

Transcription

1 Patel Group of Institutions Advance Database Management System MCA SEM V UNIT -1 Q-1: Explain Three Schema Architecture of Database. Ans: The goal of the three-schema architecture, illustrated in Figure 2.2, is to separate the user applications from the physical database. In this architecture, schemas can be defined at the following three levels: The internal level has an internal schema, which describes the physical storage structure of the database. The internal schema uses a physical data model and describes the complete details of data storage and access paths for the Database. The conceptual level has a conceptual schema, which describes the structure of the whole database for a community of users. The conceptual schema hides the details of physical storage structures and concentrates on describing entities, data types, relationships, user operations, and constraints. Usually, a representational data model is used to describe the conceptual schema when a database system is implemented. This implementation conceptual schema is often based on a conceptual schema design in a high-level data model. The external or view level includes a number of external schemas or user views. Each external schema describes the part of the database that a particular user group is interested in and hides the rest of the database from that user group. As in the previous level, each external schema is typically implemented using a 1

2 representational data model, possibly based on an external schema design in a high-level data model. See Figure in book, Q-2: Component Modules of Database Systems, Ans: Note: See Figure in book The figure is divided into two parts. The top part of the figure refers to the various users of the database environment and their interfaces. The lower part shows the internals of the DBMS responsible for storage of data and processing of transactions Let us consider the top part of Figure 2.3 first. It shows interfaces for the DBA staff, casual users who work with interactive interfaces to formulate queries, application programmers who create programs using some host programming languages, and parametric users who do data entry work by supplying parameters to predefined transactions. The DBA staff works on defining the database and tuning it by making changes to its definition using the DDL and other privileged commands.. The DDL compiler processes schema definitions, specified in the DDL, and stores descriptions of the schemas (meta-data) in the DBMS catalog. The catalog includes information such as the names and sizes of files, names and data types of data items, storage details of each file, mapping information among schemas, and constraints. Casual users and persons with occasional need for information from the database interact using some form of interface, which we call the 2

3 interactive query interface We have not explicitly shown any menubased or form-based interaction that may be used to generate the interactive query automatically. These queries are parsed and validated for correctness of the query syntax, the names of files and data elements, and so on by a query compiler that compiles them into an internal form. the query optimizer is concerned with the rearrangement and possible reordering of operations, elimination of redundancies Application programmers write programs in host languages such as Java, C, or C++ that are submitted to a precompiler. The precompiler extracts DML commands from an application program written in a host programming language. These commands are sent to the DML compiler for compilation into object code for database Access. The rest of the program is sent to the host language compiler In the lower part of Figure 2.3, the runtime database processor executes (1) the privileged commands (2) the executable query plans (3) the canned transactions with runtime parameters. It works with the system catalog and may update it with statistics. It also works with the stored data manager, which in turn uses basic operating system services for carrying out low-level input/output (read/write) operations between the disk and main memory. The runtime database processor handles other aspects of data transfer, such as management of buffers in the main memory. Some DBMSs have their own buffer management module while others depend on the OS for buffer management.we have shown concurrency control 3

4 and backup and recovery systems separately as a module in this figure. They are integrated into the working of the runtime database processor for purposes of transaction management. Q-3: Database System Utilities, Ans: Common utilities have the following types of functions: Loading. A loading utility is used to load existing data files such as text files or sequential files into the database. Usually, the current (source) for mat of the data file and the desired (target) database file structure are specified to the utility, which then automatically reformats the data and stores it in the database. Backup. A backup utility creates a backup copy of the database usually by dumping the entire database onto tape or other mass storage medium. The backup copy can be used to restore the database in case of catastrophic disk failure. Incremental backups are also often used, where only changes since the previous backup are recorded. Incremental backup is more complex, but saves storage space. Database storage reorganization. This utility can be used to reorganize a set of database files into different file organizations, and create new access paths to improve performance. Performance monitoring. Such a utility monitors database usage and provides statistics to the DBA. The DBA uses the statistics in making decisions such as whether or not to reorganize files or whether to add or drop indexes to improve performance 4

5 Q-4: Buffering of Blocks, Ans: Note: See figure in Book: When several blocks need to be transferred from disk to main memory and all the block addresses are known, several buffers can be reserved in main memory to speed up the transfer. While one buffer is being read or written, the CPU can process data in the other buffer. (Figure)Processes A and B are running concurrently in an interleaved fashion, whereas processes C and D are running concurrently in a parallel fashion. When a single CPU controls multiple processes, parallel execution is not possible. However, the processes can still run concurrently in an interleaved way. Buffering is most useful when processes can run concurrently in a parallel fashion, either because a separate disk I/O processor is available or because multiple CPU processors exist. (Figure) How reading and processing can proceed in parallel when the time required to process a disk block in memory is less than the time required to read the next block and fill a buffer. The CPU can start processing a block once its transfer to main memory is completed; at the same time, the disk I/O processor can be reading and transferring the next block into a different buffer. This technique is called double buffering Q-5: Places File Record on Disk, Ans: 1. Records and Record Types Data is usually stored in the form of records. Each record consists of a collection of related data values or items, where 5

6 each value is formed of one or more bytes and corresponds to a particular field of the record. For example, an EMPLOYEE record type may be defined using the C programming language notation as the following structure: struct employee{ char name[30]; char ssn[9]; int salary; int job_code; char department[20]; } ; 2. Files, Fixed-Length Records, and Variable-Length Records A file is a sequence of records. In many cases, all records in a file are of the same record type. If every record in the file has exactly the same size (in bytes), the file is said to be made up of fixed-length records. If different records in the file have different sizes, the file is said to be made up of variablelength records.a file may have variable-length records for several reasons: a. The file records are of the same record type, but one or more of the fields are of varying size (variable-length 6

7 fields). For example, the Name field of EMPLOYEE can be a variable-length field. b. The file records are of the same record type, but one or more of the fields may have multiple values for individual records; such a field is called a repeating field and a group of values for the field is often called a repeating group. c. The file records are of the same record type, but one or more of the fields are optional; that is, they may have values for some but not all of the file records (optional fields) d. The file contains records of different record types and hence of varying size (mixed file). This would occur if related records of different types were clustered (placed together) on disk blocks 3. Record Blocking and Spanned versus Unspanned Records The records of a file must be allocated to disk blocks because a block is the unit of data transfer between disk and memory. When the block size is larger than the record size, each block will contain numerous records, although some files may have unusually large records that cannot fit in one block. A pointer at the end of the first block points to the block containing the remainder of the record in case it is not the next consecutive block on disk. This organization is called spanned 7

8 because records can span more than one block. Whenever a record is larger than a block, we must use a spanned organization. If records are not allowed to cross block boundaries, the organization is called unspanned Q-6: Explain Client/Server Architecture, Two Tier Architecture and Three Tier Architecture. Ans: See Figure in Book. The client/server architecture was developed to deal with computing environments in which a large number of PCs, workstations, file servers, printers, data base servers, Web servers, e- mail servers, and other software and equipment are connected via a network. The idea is to define specialized servers with specific functionalities. For example, it is possible to connect a number of PCs or small workstations as clients to a file server that maintains the files of the client machines. Another machine can be designated as a printer server by being connected to various printers; all print requests by the clients are forwarded to this machine. Web servers or servers also fall into the specialized server category. The resources provided by specialized servers can be accessed by many client machines. The client machines provide the user with the appropriate interfaces to utilize these servers, as well as with local processing power to run local applications. 8

9 Two-Tier Client/Server Architectures for DBMSs In such architecture, the server is often called a query server or transaction server because it provides these two functionalities. In an RDBMS, the server is also often called an SQL server. The user interface programs and application programs can run on the client side. When DBMS access is required, the program establishes a connection to the DBMS (which is on the server side); once the connection is created, the client program can communicate with the DBMS. A standard called Open Database Connectivity (ODBC) provides an application programming interface (API), which allows client-side programs to call the DBMS, as long as both client and server machines have the necessary software installed. Most DBMS vendors provide ODBC drivers for their systems. A client program can actually connect to several RDBMSs and send query and transaction requests using the ODBC API, which are then processed at the server sites. Any query results are sent back to the client program, which can process and display the results as needed. Three-Tier and n-tier Architectures Many Web applications use an architecture called the three-tier architecture, which adds an intermediate layer between the client and the database server This intermediate layer or middle tier is called the application server or the Web server, depending on the application. This server plays an intermediary role by running application programs and storing business rules (procedures or constraints) that are used to access data from the database server. It can also improve database 9

10 security by checking a client s credentials before forwarding a request to the database server. Clients contain GUI interfaces and some additional application-specific business rules. The intermediate server accepts requests from the client, processes the request and sends database queries and commands to the database server, and then acts as a conduit for passing (partially) processed data from the database server to the clients, where it may be processed further and filtered to be presented to users in GUI format. Thus, the user interface, application rules, and data access act as the three tiers. UNIT - 2 Q-1: Physical Database Design in Relational Database. Ans: Physical design is an activity where the goal is not only to create the appropriate structuring of data in storage, but also to do so in a way that guarantees good performance. There are many factor affect to physical database design in RDBMS which as follow. A. Analyzing the Database Queries and Transactions. Before undertaking the physical database design, we must have a good idea of the intended use of the database by defining in a high-l evel form the queries and transactions that are expected to run on the database. For each retrieval query, the following information about the query would be needed: 1. The files that will be accessed by the query.1 2. The attributes on which any selection conditions for the query are specified. 10

11 3. Whether the selection condition is an equality, inequality, or a range condition. 4. The attributes on which any join conditions or conditions to link multiple tables or objects for the query are specified. 5. The attributes whose values will be retrieved by the query. The attributes listed in items 2 and 4 above are candidates for the definition of access structures, such as indexes, hash keys, or sorting of the file. For each update operation or update transaction, the following information would be needed: 1. The files that will be updated. 2. The type of operation on each file (insert, update, or delete). 3. The attributes on which selection conditions for a delete or update are specified. 4. The attributes whose values will be changed by an update operation. Again, the attributes listed in item 3 are candidates for access structures on the files, because they would be used to locate the records that will be updated or deleted.on the other hand, the attributes listed in item 4 are candidates for avoiding an access structure, since modifying them will require updating the access structures. B. Analyzing the Expected Frequency of Invocation of Queries and Transactions. Besides identifying the characteristics of expected retrieval queries and update transactions, we must consider their expected rates of invocation. This frequency information, along with the attribute information collected on each query and transaction, is used to compile a cumulative list of the expected frequency of use for all queries and transactions. This is expressed as the expected 11

12 frequency of using each attribute in each file as a selection attribute or a join attribute, over all the queries and transactions. Generally, for large volumes of processing, the informal rule can be used: approximately 80 percent of the processing is accounted for by only 20 percent of the queries and transactions. C. Analyzing the Time Constraints of Queries and Transactions. Some queries and transactions may have stringent performance constraints. For example, a transaction may have the constraint that it should terminate within 5 seconds on 95 percent of the occasions when it is invoked, and that it should never take more than 20 seconds. D. Analyzing the Expected Frequencies of Update Operations. A minimum number of access paths should be specified for a file that is frequently updated, because updating the access paths themselves slows down the update operations. For example, if a file that has frequent record insertions has 10 indexes on 10 different attributes, each of these indexes must be updated whenever a new record is inserted. The overhead for updating 10 indexes can slow down the insert operations. E. Analyzing the Uniqueness Constraints on Attributes. Access paths should be specified on all candidate key attributes or sets of attributes that are either the primary key of a file or unique attributes. The existence of an index (or other access path) makes it sufficient to only search the index when checking this uniqueness constraint, since all values of the attribute will exist in the leaf nodes of the index. For example, when inserting a new record, if a key attribute value of the new record already exists in the index, the insertion of the new record should be rejected, since it would violate the uniqueness constraint on the attribute. 12

13 Q-2: Overview of Database Tuning and Relational Systems Ans: To monitor and revise the physical database design constantly an activity referred to as database tuning. The goals of tuning are as follows: To make applications run faster. To improve (lower) the response time of queries and transactions. To improve the overall throughput of transactions. DBMSs can internally collect the following statistics: Sizes of individual tables. Number of distinct values in a column. The number of times a particular query or transaction is submitted and executed in an interval of time. The times required for different phases of query and transaction processing (for a given set of queries or transactions). These and other statistics create a profile of the contents and use of the database. Other information obtained from monitoring the database system activities and processes includes the following: Storage statistics. Data about allocation of storage into tablespaces, indexspaces, and buffer pools. I/O and device performance statistics. Total read/write activity (paging) on disk extents and disk hot spots. 13

14 Query/transaction processing statistics. Execution times of queries and transactions, and optimization times during query optimization. Locking/logging related statistics. Rates of issuing different types of locks, transaction throughput rates, and log records activity. Index statistics. Number of levels in an index, number of noncontiguous leaf pages, and so on. Tuning a database involves dealing with the following types of problems: How to avoid excessive lock contention, thereby increasing concurrency among transactions. How to minimize the overhead of logging and unnecessary dumping of data. How to optimize the buffer size and scheduling of processes. How to allocate resources such as disks, RAM, and processes for most efficient utilization. Tuning Indexes The initial choice of indexes may have to be revised for the following reasons: Certain queries may take too long to run for lack of an index. Certain indexes may not get utilized at all. Certain indexes may undergo too much updating because the index is on an attribute that undergoes frequent changes. Most DBMSs have a command or trace facility, which can be used by the DBA to ask the system to show how a query was executed what operations were performed in what order and what secondary access structures (indexes) were used. By analyzing these execution plans, it is possible to diagnose the causes of the above problems. 14

15 Some indexes may be dropped and some new indexes may be created based on the tuning analysis The goal of tuning is to dynamically evaluate the requirements, which sometimes fluctuate seasonally or during different times of the month or week, and to reorganize the indexes and file organizations to yield the best overall performance. Dropping and building new indexes is an overhead that can be justified in terms of performance improvements. Updating of a table is generally suspended while an index is dropped or created; this loss of service must be accounted for. Besides dropping or creating indexes and changing from a nonclustered to a clustered index and vice versa, rebuilding the index may improve performance. Q-3: Database Security and its Issues Ans: 1. Types of Security. Various legal and ethical issues regarding the right to access certain information for example, some information may be deemed to be private and cannot be accessed legally by unauthorized organizations or persons. In the United States, there are numerous laws governing privacy of information. Policy issues at the governmental, institutional, or corporate level as to what kinds of information should not be made publicly available for example, credit ratings and personal medical records. 15

16 System-related issues such as the system levels at which various security functions should be enforced for example, whether a security function should be handled at the physical hardware level, the operating system level, or the DBMS level. The need in some organizations to identify multiple security levels and to categorize the data and users based on these classifications for example, top secret, secret, confidential, and unclassified. Threats to Databases Loss of integrity. Database integrity refers to the requirement that information be protected from improper modification. Modification of data includes creation, insertion, updating, changing the status of data, and deletion. Integrity is lost if unauthorized changes are made to the data by either intentional or accidental acts. Loss of availability. Database availability refers to making objects available to a human user or a program to which they have a legitimate right. Loss of confidentiality. Database confidentiality refers to the protection of data from unauthorized disclosure. The impact of unauthorized disclosure of confidential information can range from violation of the Data Privacy Act to the jeopardization of national security. Unauthorized, unanticipated, or unintentional disclosure could result in loss of public confidence, embarrassment, or legal action against the organization. It is now customary to refer to two types of database security mechanisms: 16

17 Discretionary security mechanisms. These are used to grant privileges to users, including the capability to access specific data files, records, or fields in a specified mode (such as read, insert, delete, or update). Mandatory security mechanisms. These are used to enforce multilevel security by classifying the data and users into various security classes (or levels) 2. Control Measures Four main control measures are used to provide security of data in databases: Access control Inference control Flow control Data encryption A security problem common to computer systems is that of preventing unauthorized persons from accessing the system itself, either to obtain information or to make malicious changes in a portion of the database. The security mechanism of a DBMS must include provisions for restricting access to the database system as a whole. This function, called access control, is handled by creating user accounts and passwords to control the login process by the DBMS. Statistical databases are used to provide statistical information or summaries of values based on various criteria. For example, a database for population statistics may provide statistics based on age groups, income levels, household size, education levels, and other 17

18 criteria. Statistical database users such as government statisticians or market research firms are allowed to access the database to retrieve statistical information about a population but not to access the detailed confidential information about specific individuals. Security for statistical databases must ensure that information about individuals cannot be accessed. It is sometimes possible to deduce or infer certain facts concerning individuals from queries that involve only summary statistics on groups; consequently, this must not be permitted either. This problem, called statistical database security or Inference Control. Another security issue is that of flow control, which prevents information from flowing in such a way that it reaches unauthorized users. A final control measure is data encryption, which is used to protect sensitive data (such as credit card numbers) that is transmitted via some type of communications network. Encryption can be used to provide additional protection for sensitive portions of a database as well. The data is encoded using some coding algorithm. 3. Database Security and the DBA 1. Account creation. This action creates a new account and password for a user or a group of users to enable access to the DBMS. 2. Privilege granting. This action permits the DBA to grant certain privileges to certain accounts. 18

19 3. Privilege revocation. This action permits the DBA to revoke (cancel) certain privileges that were previously given to certain accounts. 4. Security level assignment. This action consists of assigning user accounts tothe appropriate security clearance level. 4. Access Control, User Accounts, and Database Audits Whenever a person or a group of persons needs to access a database system, the individual or group must first apply for a user account. The DBA will then create a new account number and password for the user if there is a legitimate need to access the database. The user must log in to the DBMS by entering the account number and password whenever database access is needed. The DBMS checks that the account number and password are valid; if they are, the user is permitted to use the DBMS and to access the database. The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session, which consists of the sequence of database interactions that a user performs from the time of logging in to the time of logging off. When a user logs in, the DBMS can record the user s account number and associate it with the computer or device from which the user logged in. All operations applied from that computer or device are attributed to the user s account until the user logs off. It is particularly important to keep track of update operations that are applied to the database so that, if the database is tampered with, the DBA can determine which user did the tampering. 19

20 To keep a record of all updates applied to the database and of particular users who applied each update, we can modify the system log system log includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash. We can expand the log entries so that they also include the account number of the user and the online computer or device ID that applied each operation recorded in the log. If any tampering with the database is suspected, a database audit is performed which consists of reviewing the log to examine all accesses and operations applied to the database during a certain time period.when an illegal or unauthorized operation is found, the DBA can determine the account number used to perform the operation. Q-4: Granting and Revoking Privileges or Discretionary Access Control Ans: 1. Types of Discretionary Privileges The account level. At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database. The relation (or table) level. At this level, the DBA can control the privilege to access each individual relation or view in the database. 20

21 The privileges at the account level apply to the capabilities provided to the account itself and can include the CREATE SCHEMA or CREATE TABLE privilege, the CREATE VIEW privilege; the ALTER privilege, the DROP privilege, the MODIFY privilege, and the SELECT privilege. The second level of privileges applies to the relation level, whether they are base relations or virtual (view) relations. These privileges are defined for SQL2. In the following discussion, the term relation may refer either to a base relation or to a view, unless we explicitly specify one or the other. Privileges at the relation level specify for each user the individual relations on which each type of command can be applied. Some privileges also refer to individual columns (attributes) of relations. SQL2 commands provide privileges at the relation and attribute level only. discretionary privileges known as the access matrix model 2. Specifying Privileges through the Use of Views o The mechanism of views is an important discretionary authorization mechanism in its own right. 3. Revoking of Privileges o In some cases it is desirable to grant a privilege to a user temporarily 4. Propagation of Privileges Using the GRANT OPTION Whenever the owner A of a relation R grants a privilege on R to another account B, the privilege can be given to B with or without the GRANT OPTION. If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts. Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C, also with the GRANT OPTION. In this way, privileges on R can propagate to 21

22 other accounts without the knowledge of the owner of R. If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privilege should automatically be revoked by the system. Q-5: Role Based Access Control for Multilevel Security or Mandatory Access Control. Ans: Mandatory access control (MAC), would typically be combined with the discretionary access control mechanisms It is important to note that most commercial DBMSs currently provide mechanisms only for discretionary access control. However, the need for multilevel security exists in government, military, and intelligence applications, as well as in many industrial and corporate applications. Typical security classes are top secret (TS), secret (S), confidential (C), and unclassified (U), where TS is the highest level and U the lowest. For simplicity, we will use the system with four security classification levels, where TS S C U, The commonly used model for multilevel security, known as the Bell-LaPadula model, classifies each subject (user, account, program) and object (relation, tuple, column, view, operation) into one of the security classifications TS, S, C, or U.We will refer to the clearance (classification) of a subject S as class(s) and to the classification of an object O as class(o). Two restrictions are enforced on data access based on the subject/object classifications: 22

23 1. A subject S is not allowed read access to an object O unless class(s) class(o). This is known as the simple security property. 2. A subject S is not allowed to write an object O unless class(s) class(o). This is known as the star property (or *-property). The first restriction is intuitive and enforces the obvious rule that no subject can read an object whose security classification is higher than the subject s security clearance. The second restriction is less intuitive. It prohibits a subject from writing an object at a lower security classification than the subject s security clearance. To incorporate multilevel security notions into the relational database model, it is common to consider attribute values and tuples as data objects. Hence, each attribute A is associated with a classification attribute C in the schema, and each attribute value in a tuple is associated with a corresponding security classification. In addition, in some models, a tuple classification attribute TC is added to the relation attributes to provide a classification for each tuple as a whole. The model we describe here is known as the multilevel model, because it allows classifications at multiple security levels. A multilevel relation schema R with n attributes would be represented as: R(A1, C1, A2, C2,..., An, Cn, TC) The apparent key of a multilevel relation is the set of attributes that would have formed the primary key in a regular (single-level) relation. it is possible to store a single tuple in the relation at a higher classification level and produce the corresponding tuples at a lowerlevel classification through a process known as filtering. 23

24 This leads to the concept of polyinstantiation,4 where several tuples can have the same apparent key value but have different attribute values for users at different clearance levels SEE Figure in Books Role-Based Access Control Role-based access control (RBAC) emerged rapidly in the 1990s as a proven technology for managing and enforcing security in large-scale enterprise-wide systems.its basic notion is that privileges and other permissions are associated with organizational roles, rather than individual users. Individual users are then assigned to appropriate roles. Roles can be created using the CREATE ROLE and DESTROY ROLE commands. For example, a company may have roles such as sales account manager, purchasing agent, mailroom clerk, department manager, and so on. Multiple individuals can be assigned to each role. RBAC can be used with traditional discretionary and mandatory access controls; it ensures that only authorized users in their specified roles are given access to certain data or resources Q-6: Encryption and PKI Ans: Encryption is the conversion of data into a form, called a ciphertext, which cannot be easily understood by unauthorized persons. It enhances security and privacy when access controls are bypassed, because in cases of data loss or theft, encrypted data cannot be easily understood by unauthorized persons. With this background, we adhere to following standard definitions 24

25 Ciphertext: Encrypted (enciphered) data. Plaintext (or cleartext): Intelligible data that has meaning and can be read or acted upon without the application of decryption. Encryption: The process of transforming plaintext into ciphertext. Decryption: The process of transforming ciphertext back into plaintext. 1. The Data Encryption and Advanced Encryption Standards The Data Encryption Standard (DES) is a system developed by the U.S. government for use by the general public DES can provide end-to-end encryption on the channel between sender A and receiver B The algorithm derives its strength from repeated application of these two techniques for a total of 16 cycles. Plaintext (the original form of the message) is encrypted as blocks of 64 bits. 2. Symmetric Key Algorithms A symmetric key is one key that is used for both encryption and decryption. By using a symmetric key, fast encryption and decryption is possible for routine use with sensitive data in the database. A message encrypted with a secret key can be decrypted only with the same secret key. Algorithms used for symmetric key encryption are called secret-key algorithms. Since secret-key algorithms are mostly used for encrypting the content of a message, they are also called contentencryption algorithms. 3. Public (Asymmetric) Key Encryption 25

26 A public key encryption scheme, or infrastructure, has six ingredients: 1. Plaintext. This is the data or readable message that is fed into the algorithm as input. 2. Encryption algorithm. This algorithm performs various transformations on the plaintext. 3. and 4. Public and private keys. These are a pair of keys that have been selected so that if one is used for encryption, the other is used for decryption. The exact transformations performed by the encryption algorithm depend on the public or private key that is provided as input. For example, if a message is encrypted using the public key, it can only be decrypted using the private key. 5. Ciphertext. This is the scrambled message produced as output. It depends on the plaintext and the key. For a given message, two different keys will produce two different ciphertexts. 6. Decryption algorithm. This algorithm accepts the ciphertext and the matching key and produces the original plaintext. As the name suggests, the public key of the pair is made public for others to use, whereas the private key is known only to its owner. A general-purpose public key cryptographic algorithm relies on one key for encryption and a different but related key for decryption. The essential steps are as follows: 26

27 1. Each user generates a pair of keys to be used for the encryption and decryption of messages. 2. Each user places one of the two keys in a public register or other accessible file. This is the public key. The companion key is kept private. 3. If a sender wishes to send a private message to a receiver, the sender encrypts the message using the receiver s public key. 4. When the receiver receives the message, he or she decrypts it using the receiver s private key. No other recipient can decrypt the message because only the receiver knows his or her private key. 4. Digital Signatures A digital signature is an example of using encryption techniques to provide authentication services in electronic commerce applications. Like a handwritten signature, a digital signature is a means of associating a mark unique to an individual with a body of text. The mark should be unforgettable, meaning that others should be able to check that the signature comes from the originator A digital signature consists of a string of symbols. If a person s digital signature were always the same for each message, then one could easily counterfeit it by simply copying the string of symbols. Thus, signatures must be different for each use. UNIT 3 27

28 Q-1: Recovery Techniques Based on Deferred Update. Ans: The idea behind deferred update is to defer or postpone any actual updates to the database on disk until the transaction completes its execution successfully and reaches its commit point. During transaction execution, the updates are recorded only in the log and in the cache buffers. After the transaction reaches its commit point and the log is forcewritten to disk, the updates are recorded in the database. If a transaction fails before reaching its commit point, there is no need to undo any operations because the transaction has not affected the database on disk in any way. We can state a typical deferred update protocol as follows: 1. A transaction cannot change the database on disk until it reaches its commit point. 2. A transaction does not reach its commit point until all its REDO-type log entries are recorded in the log and the log buffer is force-written to disk. Notice that step 2 of this protocol is a restatement of the write-ahead logging (WAL) protocol. Because the database is never updated on disk until after the transaction commits, there is never a need to UNDO any operations. REDO is needed in case the system fails after a transaction commits but before all its changes are recorded in the database on disk. In this case, the transaction operations are redone from the log entries during recovery. For multiuser systems with concurrency control, the concurrency control and recovery processes are interrelated. Consider a system in which concurrency control uses strict two-phase locking, so the locks on items remain in effect until the transaction reaches its commit point. After that, the locks can be released. This ensures strict and 28

29 serializable schedules. Assuming that [checkpoint] entries are included in the log, a possible recovery algorithm for this case, which we call RDU_M (Recovery using Deferred Update in a Multiuser environment) Q-2: Recovery Techniques Based on Immediate Update. Ans: In these techniques, when a transaction issues an update command, the database on disk can be updated immediately, without any need to wait for the transaction to reach its commit point. Notice that it is not a requirement that every update be applied immediately to disk; it is just possible that some updates are applied to disk before the transaction commits. Provisions must be made for undoing the effect of update operations that have been applied to the database by a failed transaction. This is accomplished by rolling back the transaction and undoing the effect of the transaction s write_item operations. Therefore, the UNDOtype log entries, which include the old value (BFIM) of the item,must be stored in the log. If the transaction is allowed to commit before all its changes are written to the database, we have the most general case, known as the UNDO/REDO recovery algorithm. Q-3: Recovery in Distributed Database, Ans: For concurrency control and recovery purposes, numerous problems arise in a distributed DBMS environment that are not encountered in a centralized DBMS environment. These include the following: 29

30 Dealing with multiple copies of the data items. The concurrency control method is responsible for maintaining consistency among these copies. The recovery method is responsible for making a copy consistent with other copies if the site on which the copy is stored fails and recovers later. Failure of individual sites. The DDBMS should continue to operate with its running sites, if possible, when one or more individual sites fail.when a site recovers, its local database must be brought up-to-date with the rest of the sites before it rejoins the system. Failure of communication links. The system must be able to deal with the failure of one or more of the communication links that connect the sites. An extreme case of this problem is that network partitioning may occur. This breaks up the sites into two or more partitions, where the sites within each partition can communicate only with one another and not with sites in other partitions. Distributed commit. Problems can arise with committing a transaction that is accessing databases stored on multiple sites if some sites fail during the commit process. The two-phase commit protocol (see Section 23.6) is often used to deal with this problem. Distributed deadlock. Deadlock may occur among several sites, so techniques for dealing with deadlocks must be extended to take this into account. 30

31 1. Distributed Concurrency Control Based on a Distinguished Copy of a Data Item To deal with replicated data items in a distributed database, a number of concurrency control methods have been proposed that extend the concurrency control techniques for centralized databases. A number of different methods are based on this idea, but they differ in their method of choosing the distinguished copies. In the primary site technique, all distinguished copies are kept at the same site. A modification of this approach is the primary site with a backup site. Another approach is the primary copy method, where the distinguished copies of the various data items can be stored in different sites. Primary Site Technique. In this method a single primary site is designated to be the coordinator site for all database items. Hence, all locks are kept at that site, and all requests for locking or unlocking are sent there. This method is thus an extension of the centralized locking approach The advantage of this approach is that it is a simple extension of the centralized approach and thus is not overly complex. However, it has certain inherent disadvantages. One is that all locking requests are sent to a single site, possibly overloading that site and 31

32 causing a system bottleneck. A second disadvantage is that failure of the primary site paralyzes the system, since all locking information is kept at that site. This can limit system reliability and availability. Primary Site with Backup Site. This approach addresses the second disadvantage of the primary site method by designating a second site to be a backup site All locking information is maintained at both the primary and the backup sites. In case of primary site failure, the backup site takes over as the primary site, and a new backup site is chosen This simplifies the process of recovery from failure of the primary site, since the backup site takes over and processing can resume after a new backup site is chosen and the lock status information is copied to that site. Primary Copy Technique. This method attempts to distribute the load of lock coordination among various sites by having the distinguished copies of different data items stored at different sites. Failure of one site affects any transactions that are accessing locks on items whose primary copies reside at that site, but other transactions are not affected. This method can also use backup sites to enhance reliability 2. Distributed Recovery The recovery process in distributed databases is quite involved.we give only a very brief idea of some of the issues here. In some cases it is quite difficult even to determine whether a site is down without exchanging numerous messages with other sites. For example, suppose that site X sends a message to site Y and expects a response 32

33 from Y but does not receive it. There are several possible explanations: The message was not delivered to Y because of communication failure. \ Site Y is down and could not respond. Site Y is running and sent a response, but the response was not delivered. Without additional information or the sending of additional messages, it is difficult to determine what actually happened. Q-4: Types of Single Level Ordered Indexes. Ans: There are several types of ordered indexes. 1. Primary Indexes A primary index is an ordered file whose records are of fixed length with two fields, and it acts like an access structure to efficiently search for and access the data records in a data file The first field is of the same data type as the ordering key field called the primary key of the data file, and the second field is a pointer to a disk block (a block address). The total number of entries in the index is the same as the number of disk blocks in the ordered data file. The first record in each block of the data file is called the anchor record of the block, or simply the block anchor. Indexes can also be characterized as dense or sparse. A dense index has an index entry for every search key value (and hence every 33

34 record) in the data file. A sparse (or nondense) index, on the other hand, has index entries for only some of the search values. A sparse index has fewer entries than the number of records in the file. Thus, a primary index is a nondense (sparse) index, since it includes an entry for each disk block of the data file and the keys of its anchor record rather than for every search value (or every record). The index file for a primary index occupies a much smaller space than does the data file, for two reasons. First, there are fewer index entries than there are records in the data file. Second, each index entry is typically smaller in size than a data record because it has only two fields; consequently, more index entries than data records can fit in one block. A major problem with a primary index as with any ordered file is insertion and deletion of records. With a primary index, the problem is compounded because if we attempt to insert a record in its correct position in the data file, we must not only move records to make space for the new record but also change some index entries, since moving records will change the anchor records of some blocks. 2. Clustering Indexes If file records are physically ordered on a nonkey field which does not have a distinct value for each record that field is called the clustering field and the data file is called a clustered file. We can create a different type of index, called a clustering index, to speed up retrieval of all the records that have the same value for the clustering field. A clustering index is also an ordered file with two fields; the first field is of the same type as the clustering field of the data file, and the second field is a disk block pointer. There is one entry in the clustering index for each distinct value of the clustering field, and it contains the value and a pointer to the first 34

35 block in the data file that has a record with that value for its clustering field. 3. Secondary Indexes A secondary index provides a secondary means of accessing a data file for which some primary access already exists. The secondary index may be created on a field that is a candidate key and has a unique value in every record, or on a nonkey field with duplicate values. The index is again an ordered file with two fields. The first field is of the same data type as some nonordering field of the data file that is an indexing field. The second field is either a block pointer or a record pointer. First we consider a secondary index access structure on a key (unique) field that has a distinct value for every record. Such a field is sometimes called a secondary key; in the relational model, this would correspond to any UNIQUE key attribute or to the primary key attribute of a table. A secondary index usually needs more storage space and longer search time than does a primary index, because of its larger number of entries. However, the improvement in search time for an arbitrary record is much greater for a secondary index than for a primary index, since we would have to do a linear search on the data file if the secondary index did not exist. Q-5: Multilevel Index Ans: A multilevel index considers the index file, which we will now refer to as the first (or base) level of a multilevel index, as an ordered file with a distinct value for each K(i). 35

36 Therefore, by considering the first-level index file as a sorted data file, we can create a primary index for the first level; this index to the first level is called the second level of the multilevel index. We can repeat this process for the second level. The third level, which is a primary index for the second level, has an entry for each second-level block, so the number of third-level entries is r3 = (r2/fo). Notice that we require a second level only if the first level needs more than one block of disk storage, and, similarly, we require a third level only if the second level needs more than one block. The multilevel scheme described here can be used on any type of index whether it is primary, clustering, or secondary. Unit 4 Q-1: Temporal Database Concepts. Ans: Temporal databases, in the broadest sense, encompass all database applications that require some aspect of time when organizing their information. 1. Time Representation, Calendars, and Time Dimensions For temporal databases, time is considered to be an ordered sequence of points in some granularity that is determined by the application. For example, suppose that some temporal application never requires time units that are less than one second. Then, each time point represents one second using this granularity. In reality, each second is 36