You are on page 1of 7

The GRANT statement in SQL is used to grant security rights

to users. A user with administrative authorithy or a user
who owns a table or view can use the GRANT statement to let
other users execute one or more of the SELECT, INSERT,
against the table or view. Some examples of GRANT along
with the syntax of GRANT is given. Granted privileges can
be revoked with the SQL REVOKE statement. The GRANT
statement also inserts a tuple into one of the system
tables in the DBMS catalog.
Grant Statement for DBA:
... TO userid,...
REFERENCES [ (StudentID, Name, LoginID,
DegreeCode, Address)(DegreeCode, DegrreName, NumberOfYears,
FacultyCode) ]

UPDATE [ (StudentID, Name, LoginID, DegreeCode,
Address)(DegreeCode, DegrreName, NumberOfYears,
FacultyCode) ]

], ...
... ON [ owner.]table-name TO userid, ... [ WITH GRANT


DegreeCode.. NumberOfYears) FROM STUDENT AND DEGREE WHERE Student. Name. CREATE VIEW SciFac AS (SELECT StudentID. LoginID.... Name.Statement for staff GRANT CONNECT TO userid... IDENTIFIED BY password. LoginID. LoginID.. IDENTIFIED BY password. DegreeName. .DegreeCodE = Degree. DegreeCode. Name.. Referential keys is a rule defined on a column (or set of columns) in one table that allows the insert or update of a row only if the value for the column or set of columns (the dependent value) matches a value in a column of a related table (the referenced value).. FROM SciFac WHERE NumberOfYears = 3 AND StudentID<>like”01%” AND GROUP BY DegreeName Question 2 Integrity constraints are a set of data validation rules that you can specify to restrict the data values accepted into a data file. Using integrity constraints can preserve the correctness and consistency of stored data. CREATE VIEW STUDENT StudentID...DegreeCode AND FacultyCode=18 Statement for student GRANT CONNECT TO userid. Address FROM STUDENT Question 1 Part2 SELECT COUNT(StudentID)AS StuID.DegreeNAME.. Address AS (SELECT StudentID. DegreeCode.

they are easy to write. • Flexibility for Data Loads and Identification of Integrity Violations . your application may have to apply SQL insert and delete update statements in a specific table order. the last detail record must be deleted before the master record can be deleted. Further I will also discuss the fact that integrity constraint in contrast to using a declarative foreign key in the management of Powerbuilder. Introducing an integrity constraint would have certain advantages such as: • Declarative Ease Because you define integrity constraints using SQL commands. performance optimisations are implemented for each specific declarative rule. depending on whether the sql type is insert or delete. when you define or alter a table. a master record must be inserted (if it does not exist) before the first detail record can be inserted. • Superior Performance Because the semantics of integrity constraint declarations are clearly defined. When there is a master detail relationship. Therefore. When referential integrity constraints have been declared for database tables related by foreign keys. the data entered by any application must adhere to the same integrity constraints associated with a Table. eliminate programming errors. Implementing a referential or foreign key would ensure that any changes made to the client software would not effect the integrity constraint. no programming is required.A couple of proposals have been put forward I will discuss the advantages and disadvantages of each of those with group members. Therefore. for insert. for delete. • Centralised Rules Integrity constraints are defined for tables (not an application) and stored in the data dictionary.

When the data load is complete. But the two constraints will perform similar functions and will be beneficial to use rather than declaring the constraint in the database. Another disadvantage would be that the software could be altered allowing the implemented constraint to break therefore causing damage to the database structure. Question 3 i) CALCULATIONS OF DEGREE TABLE Bytes per degree table record = overhead + degreecode + degreename + numberofyears + facultycode = 4+2+30++2+2 = 40 bytes There are 200 rows in the degree table Number of record per data page = bytes per data page – overhead of page data record = (2048 – 32)/40 = 2016/40 = 50. you can easily enable the integrity constraints. The implementation of both these constraints will produce significant advantages and disadvantages. and you can automatically report any new rows that violate integrity constraints to a separate exception table.4 = 51 records Number of data pages needed = number of rows / 51 data records per page at 75% full = 200/ (75% * 51) = 200/ 38. However there are disadvantages such as any updates to the database would require assurance checks for checking if the integrity constraints still exist.25 .Integrity constraints can be temporarily disabled so that large amount of data can be loaded without the overhead of constraint checking.

228758 = 6 data pages The size of the student table = 6 pages Calculations for Student table Byte per record = overhead + studentId + name + loginID + degreecode + address = 4+8+30+10+2+30 =84 bytes There are 50000 rows in the student table Number of record per data page = bytes per data page – overhead of page data record = (2048 –32)/84 = 2016/84 = 24 records Number of data pages needed = number of rows / 24 data records per page at 75% full = 50000/(75% * 24) = 50000/ 18 = 2777.= 5.77777778 = 2778 data pages Calculation for indices Primary index Primary index needs: studentID + pointer + overhead = 8+4+1 = 13 bytes Each page has (2048-32) = 2016 bytes available .

0769 = 155 index records Since index pages are only 75% full the fan out would be 155*75% = 116.230.8967777 = 24 leaf pages + 1 for root Secondary Index Secondary index needs: degreecode + pointer + overhead = 2+4+1 = 7 bytes Each page has (2048-32) = 2016 bytes available 2016/7 = 288 records Since index records are only 75% full the fan out is 288*75% = 216 on average index records per page 50000/216 = 231.25 on average index records per page = 23.48148 = 232 second level leaf pages + 1 for root The size of indices = primary leaf pages + root + secondary leaf pages + root = 24 + 1 + 232 + 1 = 258 pages Total space used by database = degreetable + student table + indexes = 6 + 2778 + 258 = 3042 pages In bytes 3042*2048 = 6.2016/13 = 155.016 bytes ii) From part 1 there are 216 index records in each leaf page on average .

the estimated number of disk I/O would be . 3 levels + 24 leaf pages + 5000 records = 5027 pages .Now we take 10% of 50000 records = 5000 5000/216 (fanout for secondary index) = 23 leaf pages 5000 + 23 + 4 (levels) = 5027 Hence.