Scribd
Upload
129 views

Assign2 Ods

The document discusses the GRANT statement in SQL which is used to grant security rights to users. It allows administrative or object owners to grant privileges like SELECT, INSERT, DELETE etc on tables or views to other users. Some examples of GRANT statements are given for granting privileges to DBAs, staff and students. It also discusses integrity constraints and referential keys which ensure data integrity. Introducing integrity constraints has advantages like declarative ease of use, centralized rules and better performance but also disadvantages like needing to check constraints on database updates.

Uploaded by

anuji
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
129 views

Assign2 Ods

The document discusses the GRANT statement in SQL which is used to grant security rights to users. It allows administrative or object owners to grant privileges like SELECT, INSERT, DELETE etc on tables or views to other users. Some examples of GRANT statements are given for granting privileges to DBAs, staff and students. It also discusses integrity constraints and referential keys which ensure data integrity. Introducing integrity constraints has advantages like declarative ease of use, centralized rules and better performance but also disadvantages like needing to check constraints on database updates.

Uploaded by

anuji
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 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,
DELETE, UPDATE, ALTER TABLE and CREATE INDEX statements
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:
GRANT
DBA
GROUP
MEMBERSHIP IN GROUP userid,...
RESOURCE
... TO userid,...
GRANT
[ ALL [ PRIVILEGES]
ALTER
DELETE
INSERT
REFERENCES [ (StudentID, Name, LoginID,
DegreeCode, Address)(DegreeCode, DegrreName, NumberOfYears,
FacultyCode) ]

SELECT * FROM STUDENT AND DEGREE


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

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

CREATE VIEW STUDENT AND DEGREE


AS SELECT * FROM STUDENT And DEGREE
Statement for staff
GRANT CONNECT TO userid,... IDENTIFIED BY password,...
CREATE VIEW SciFac
AS (SELECT StudentID, Name, LoginID, DegreeCode,
DegreeName, NumberOfYears) FROM STUDENT AND DEGREE
WHERE Student.DegreeCodE = Degree.DegreeCode
AND FacultyCode=18

Statement for student

GRANT CONNECT TO userid,... IDENTIFIED BY password,...

CREATE VIEW STUDENT


StudentID, Name, LoginID, DegreeCode, Address
AS (SELECT StudentID, Name, LoginID, DegreeCode,
Address FROM STUDENT

Question 1
Part2
SELECT COUNT(StudentID)AS StuID,DegreeNAME, 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.

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).
A couple of proposals have been put forward I will discuss
the advantages and disadvantages of each of those with
group members. Further I will also discuss the fact that
integrity constraint in contrast to using a declarative
foreign key in the management of Powerbuilder.

When referential integrity constraints have been declared


for database tables related by foreign keys, your
application may have to apply SQL insert and delete update
statements in a specific table order,
depending on whether the sql type is insert or delete. When
there is a master detail relationship, for insert, a master
record must be inserted (if it does not exist) before the
first detail record can be inserted; for
delete, the last detail record must be deleted before the
master record can be deleted. Implementing a referential or
foreign key would ensure that any changes made to the
client software would not effect the integrity constraint.

Introducing an integrity constraint would have certain


advantages such as:

• Declarative Ease

Because you define integrity constraints using SQL


commands, when you define or alter a table, no programming
is required. Therefore, they are easy to write, eliminate
programming errors,

• Centralised Rules

Integrity constraints are defined for tables (not an


application) and stored in the data dictionary. Therefore,
the data entered by any application must adhere to the same
integrity constraints associated with a
Table.

• Superior Performance

Because the semantics of integrity constraint declarations


are clearly defined, performance optimisations are
implemented for each specific declarative rule.

• Flexibility for Data Loads and Identification of


Integrity Violations
Integrity constraints can be temporarily disabled so that
large amount of data can be loaded without the overhead of
constraint checking. When the data load is complete, you
can easily enable the integrity constraints, and you can
automatically report any new rows that violate integrity
constraints to a separate exception table.

However there are disadvantages such as any updates to the


database would require assurance checks for checking if the
integrity constraints still exist. Another disadvantage
would be that the software could be altered allowing the
implemented constraint to break therefore causing damage to
the database structure. The implementation of both these
constraints will produce significant advantages and
disadvantages. But the two constraints will perform similar
functions and will be beneficial to use rather than
declaring the constraint in the database.

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.4
= 51 records

Number of data pages needed = number of rows / 51 data


records per page at 75% full

= 200/ (75% * 51)


= 200/ 38.25
= 5.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.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


2016/13 = 155.0769
= 155 index records

Since index pages are only 75% full the fan out would be
155*75% = 116.25 on average index records per page
= 23.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.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,230,016 bytes

ii) From part 1 there are 216 index records in each leaf
page on average
Now we take 10% of 50000 records = 5000

5000/216 (fanout for secondary index) = 23 leaf pages

5000 + 23 + 4 (levels) = 5027

Hence, the estimated number of disk I/O would be ,


3 levels + 24 leaf pages + 5000 records = 5027 pages

You might also like