You are on page 1of 10

UNIVERSITI TEKNIKAL MALAYSIA MELAKA

FACULTY OF INFORMATION AND COMMUNICATION TECHNOLOGY

BITP 2323 DATABASE ADMINISTRATION ASSIGNMENT 2(30%)

LECTURER: STUDENT NAME :

PM NORHAZIAH BT MD SALLEH AHMAD HILMAN ARIF BIN MUSTAPA MUHAMMAD FAEEZ BIN MOHD AZMAN AZHAR BIN ABDUL AZIZ MOHAMAD IZAR BIN AZMI B031110444

B031110436 B031110442 B031110327

CLASS / GROUP:

2 BITD / S2G2

Data Integrity 1. Discuss about data integrity.

Data integrity means that the data in a database adheres to business rules. There are three primary ways in which data integrity can be maintained:

i. ii. iii.

Application code Database trigger Declarative integrity constraints

Application code can be implemented either as stored procedures within the database or as application running on the client. This lesson focuses on the use of integrity constraints. Database triggers are PL/SQL programs that are executed when an event, such as insert or an update of a column, occurs on a table. Triggers can be enabled or disable, that is they can be set to execute when event occurs, or they can be set not to execute even through they are defined. Declarative integrity constraints are preferred mechanism for enforcing business rules because they: 1. Provide improved performance 2. Easy to declare and modify 3. Centralized rules 4. Flexible 5. Fully documented in data dictionary

2. List the issues in integrity constraints.

Referential Integrity Referential integrity (RI) issues are the most common of data integrity issues in relational databases. An RI error is essentially a violation of a foreign keyprimary key constraint.

NULL Values Although NULL values are common and even valid in relational databases, they need special treatment in Analysis Services.

Inconsistent Relationship Analysis Services allows relationships to be defined between dimension attributes.

3. Discuss the types of constraints.

Constraints NOT NULL

Description Specifies value that a column cannot contain null values Designates a column or combination of columns as unique Designates a column or combination of columns as the tabless primary key Designates a column or combination of

UNIQUE

PRIMARY KEY

FOREIGN KEY

columns as the foreign key in a referential integrity constraint

CHECK

Specifies a condition that each row of table must satisfy

4.

Explain how to identify constraint violation. Basically, Oracle will return an error message when a constraint is violated. For example if we are using JDBC, a SQLException will get thrown while if we are Pro C users the SQLCA struct gets updated to reflect the error. Constraints are used to enforce table rules and prevent data dependent deletion (enforce database integrity). It may also use to enforce the business rules.

Constraint code: 1 2291 2290

Representing: Primary key (unique key) constraint violations Foreign key violations Attribute and tuple constraint violations

The type of constraint violation: Oracle also provides simple error message strings that have a format similar to the following: ORA-02290: check constraint (YFUNG.GR_GR) violated or ORA-02291: integrity constraint (HONDROUL.SYS_C0067174) violated - parent key not found The constraint violations occur when an insert, update, or delete statement violates a primary key, foreign key, check, or unique constraint or a unique index.

5. Give relevant examples of constraints and how to overcome the constraints. Example 1: Error : ORA-00001 Unique constraint violated. Cause:

This error means that an attempt has been made to insert a record with a duplicate (unique) key. This error will also be generated if an existing record is updated to generate a duplicate (unique) key. Typically this is a duplicate primary key, but it need not be the primary key.

Solution:

1) Remove the unique restriction. 2) Change the restriction to allow duplicate keys. An index could be changed to be a non-unique 3

index, but remember that the primary key must always be unique 3) Do not insert the duplicate key

Example 2: Error: ORA-02291 integrity constraint <constraint name> Cause: When reference a table using a unique or primary key, but the columns that you listed did not match the primary key, or a primary key does not exist for this table. In other word, it is a foreign key constraint failing. Solution: This error commonly occurs when you have a parent-child relationship established between two tables through a foreign key. You then have tried to insert a value into the child table, but the corresponding value does not exist in the parent table. To correct this problem, you need to insert the value into the parent table first and then you can insert the corresponding value into the child table. Example 3: Error : ORA-02290:check constraint (string.string) violated Cause: The values being inserted do not satisfy the named check constraint. Action: Do not insert values that violate the constraint.

B. Data Availibility 1. Discuss about data availability. Data availability is the products and services that ensure that data continues to be available at a required level of performance. Two increasingly popular approaches to providing data availability are the storage area network (SAN) and network-attached storage (NAS). Data availability can be measured in terms of how often the data is available and how much data can flow at a time. In addition, data availability will provide the Oracle to access the data dictionary to find information about users, schema objects, and storage structures. It also means that Oracle can modify the data dictionary every time that a data definition language (DDL) statement is issued. And finally any Oracle user can use the data dictionary as a read-only reference for information about the database.

2. Data Availability Requirements

Availability is a complex concept, which can be expressed through the following requirements:

1.

Availability must not be achieved only through creation of multiple replicas of data; while this is exploited by P2P file sharing networks, it may impose unnecessary burden on owners of very large data sets

2.

Regardless of the requirement above, availability of "popular" data must be better (i.e., faster), in a way similar to file sharing networks: more popular is a file, more copies are there, faster is the access

3.

Availability includes local and remote access; in case a local copy of data is not feasible, remote access must be deployed - via a distributed file system, or via a specialized protocol, or both.

4.

Availability must include protection from unauthorised or undesired removal; in Grid environment a storage administrator, or even a VO manager, cannot know for sure 5

who needs a particular data set. It must be possible for any user to flag any data as precious for him/her a specified amount of time, such that no removal can be done without his/her explicit approval 5. Availability must not necessarily involve massive security solutions; it must be possible for one researcher to make her data available to another researcher without becoming a member of a VO and without deploying an authorisation service 6. Availability must assume mobility of data. This means, if data are on a mobile medium, it should not be necessary to move data to a dedicated Grid storage: it should be sufficient to specify to a Grid storage service that the mobile device currently holds data which are shared with specified users or services. The same concept applies to data that need to be moved from one device to another 7. Availability must be instant or as close to instant as possible: as soon as the device holding the data is made known to Grid, authorised users should be able to discover and access the data on this device. As soon as the device is off-line, Grid queries for its data must return no results.

3.

Discuss availability problems and how to overcome the problems, if any. Specific recovery tactics include: I. II. III. Ensuring that production data changes are logged by the DBMS Retaining sufficient active and archive logs on appropriate media Considering staggered or phased recovery (i.e., pre-set the table/index recovery order so customer-intensive objects are recovered first) IV. Considering options for incremental image copies and index image copies; test and time the options for possible inclusion in recovery plans. Additional tactics that address data availability include: I. Planned data redundancy. Consider options for data replication, publish/subscribe, or multiple copies of production data as candidates for parallel or failover access. II. Coordinated standards for bind parameters, commit frequency, cursor definitions and utility scheduling, since these all must interact cooperatively. Examples include a cursor definition containing WITH HOLD, which may prevent a utility from executing; a package bound with Repeatable Read may prevent update access; and transactions with a low frequency of commits may create timeout or deadlock conditions. 6

Database Auditing

1.

Discuss about database auditing

Database auditing is the monitoring and recording of selected user database actions. Information about the event is stored in the audit trail.

The audit trail can be used to investigate suspicious activity. For example, if an unauthorized user is deleting data from tables, the database administrator may decide to audit all connections to the database in conjunction with successful and unsuccessful deletions of rows from tables in the database.

Auditing might also be used to monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, and how many concurrent users connect at peak times.

Value-Based Auditing Database auditing cannot record column values. If the changes to database columns need to be tracked and column values need to be stored for each change, use application auditing. Application auditing can be done either through client code, stored procedures, or database triggers.

2.

Discuss the auditing guidelines.

Auditing guidelines are discussing about two main tasks. There is defining what want to audit and manage audit trail.

a)

Define what want to audit. Object auditing must be used where possible to reduce the number of entries generated. If statement or privilege auditing needs to be used, the following settings can minimize audit generation:

Specifying users to audit Auditing by session, and not by access Auditing either successes or failures, but not both Audit records may be written to either SYS.AUD$ or the operating systems audit trail. The ability to use the operating systems audit trail is operating system dependent.

b) Manage your audit trail If the audit trail becomes full, no more audit records can be inserted, and audited statements will not execute successfully. Errors are returned to all users that issue an audited statement. Free some space is needed before these statements can be executed. There is how to manage audit trail.

i.

Monitoring the Growth of the Audit Trail Enable auditing only when necessary. Be selective about which audit options are specified. Tightly control schema object auditing. Users can turn on auditing for the objects that they own. The AUDIT ANY privilege also enables a user to turn on auditing, so grant it sparingly. Periodically remove audit records from the audit trail with the DELETE or TRUNCATE command.

ii.

Protecting the Audit Trail Audit trail need to be protect so that audit information cannot be added, modified, or deleted by unauthorized user. Only DBA should have the delete role.

3. Explain the use of the various auditing option with an example. Auditing option is use to indicate which statement, objects, or privileges to audit. Depending on the auditing options set, audit records can contain different types of information. However, all auditing options generate the following information:

The user that executed the audited statement The action code (a number) that indicates the audited statement executed by the user The object or objects referenced in the audited statement The date and time that the audited statement was executed

Example: i. Statement Valid statement audit options that can be included in audit and noaudit. Eg: AUDIT TABLE;

ii.

Privilege Audit Options Privilege audit options exactly match the corresponding system privileges. For example, the option to audit use of the DELETE ANY TABLE Eg: AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

iii.

Object Audit Option This is the selective auditing of specific statements on a particular schema object, such as AUDIT SELECT ON emi.orders Eg: AUDIT SELECT ON emi.orders;

END OF ASSIGNMENT

You might also like