- ข้อความ
- ประวัติศาสตร์
5.22 Access Rights 153Example 5.21.
5.22 Access Rights 153
Example 5.21.5 The following delete eliminates all rows of the table ASSIGN:
delete from ASSIGN;
The syntax of delete is: delete from table name [wherecondition]
5.22 Access Rights
The grant operation assigns access rights to users. To delegate access rights to other users, a user must “own” these rights. The set of access rights includes select, insert, update, and delete and refers to the right of executing each of these operations on a table. Further, update can be restricted to specific columns. All these access rights are granted to the creator of a table automatically. The creator, in turn, may grant access rights to other users or to all users (designated in SQL as public). The SQL standard envisions a mechanism that can limit the excessive proliferation of access rights. Namely, a user may receive the select right with or without the right to grant this right to others by his own action.
Example 5.22.1 Suppose that the user alex owns the table COURSES and intends to grant this right to the user whose name is peter. The user alex can accomplish this by
grant select on COURSES to peter
Now, peter has the right to query the table COURSES but he may not propagate this right to the user ellie. In order for this to happen, alex would have to use the directive:
grant select on COURSES to peter with grant option
Example 5.22.2 If peter owns the table STUDENTS, then he may delegate the right to query the table and the right to update the columns addr, city and zip to ellie using the directive:
grant select, update(addr, city, zip) on STUDENTS to ellie
The standard syntax of grant is:
154 SQL — The Relational Language
grant {priv{,priv} | all [privileges]} on [table] tablename{,tablename} to husername{,username}|publici [with grant option] Here priv has the syntax: hselect|insert|delete|update[(attribute{,attribute})]i Privileges can be revoked using the revoke construct, which is a feature of standard SQL. For instance, if peter wishes to revoke ellie’s privileges to update the table STUDENTS, he may write:
revoke update(addr,city,zip) on STUDENTS from ellie
The standard syntax for this directive is revoke {priv{,priv}|all [privileges]} on [table] tablename{,tablename} from husername{,username}|publici
5.23 Views in SQL
Views are virtual tabular variables. This means that in SQL a view is referenced for retrieval purposes in exactly the same way a tabular variable is referenced. The only difference is that a view does not have a physical existence. It exists only as a definition in the database catalog. We refer to “real” tabular variables (that is, the tabular variables that have a physical existence in the database) as base tabular variables. Views are supported in both SQLPlus and in Transact SQL but not in the current version (4.1) of MySQL. To illustrate the notion of view, let us consider the following example. Example 5.23.1 Suppose that we write:
create view STC as select STUDENTS.name, GRADES.cno from STUDENTS, GRADES where STUDENTS.stno = GRADES.stno;
The select construct contained by this create view retrieves all pairs of student names and course numbers such that the student whose name is s has registered for the course c. When this directive is executed by SQL, no data retrieval takes place. The database system simply stores this definition in its catalog. The definition of the view STC becomes a persistent object, that is, an object that exists after our interaction with the DBMS has ceased. From a conceptual point of view, the user treats STC exactly like any other tabular variable. Suppose, for instance that we wish to retrieve the names of students who took cs110. In this case it is sufficient to write the query:
5.23 Views in SQL 155
select name from STC where cno =’cs110’;
In reality, SQL combines this select phrase with the query just shown and executes the modified query:
select STUDENTS.name from STUDENTS, GRADES where STUDENTS.stno = GRADES.stno and GRADES.cno =’cs110’;
The previous example shows that views in SQL play a role similar to the role played by macros in programming languages. Views are important for data security. A user who needs to have access only to list of names of students and the courses they are taking needs to be aware only of the existence of STC. If the user is authorized to use only select constructs, then the user can ignore whether STC is a table or a view. Confidential data (such as grades obtained in specific courses) can be completely protected in this manner. Also, the queries that this limited-access user may write are simpler and easier to understand. No space is wasted with the view STC, and the view remains current always, reflecting the contents of the tabular variables STUDENTS and GRADES. SQL treats views exactly as it treats the tabular variables as far as retrieval is concerned. We can also delegate the select privilege to a view in exactly the same way as we did for a tabular variable. For instance, if the user george created the view STC, then he can give the select right to vanda by writing:
grant select on STC to vanda;
Consider now another example of view: Example 5.23.2 The view SNA that contains the student number and the names of students can be created by:
create view SNA as select stno, name from STUDENTS
The purpose of this view is to insure privacy to students. Any user who has access only to this view can retrieve the student number and name of a student, but not the address of the student. There is a fundamental difference between the views introduced in Examples 5.23.1 and 5.23.2, and this refers to the ways in which these two views behave with respect to updates. Suppose that the user wishes to insert the pair (7799, ’Jane Jones’) in the view SNA. The user may ignore entirely the fact that SNA is not a base tabular variable. On the other hand, the effect on the base tabular variable of this insertion is unequivocally determined: the system inserts in the tabular variable STUDENTS the tuple (7799, ’Jane Jones’, null, null, null). On the other hand, we cannot insert a tuple in a meaningful way in the view STC introduced in Example 5.23.1. Indeed if we attempt to insert a pair (s,c) in STC, then we have to define the effect of this insertion on the base tabular variable. This is clearly
156 SQL — The Relational Language
impossible: we do not know what the student number is, what the identification of the instructor is, etc. SQL forbids users to update views based on more than one table (as STC is). Even if such updates would have an unambiguous effect on the base tabular variable, this rule rejects any such update. Only some views based on exactly one tabular variable can be updated. It is the responsibility of the database administrator to grant to the user the right to update a view only if that view can be updated. If a view can be updated, then its behavior is somewhat different from the base tabular variable on which the view is built. An update made to a view may cause one or several tuples to vanish from the view, whenever we retrieve the tuples of the view. Example 5.23.3 Consider the view uppergr defined by:
create view UPPERGR as select * from GRADES where grade > 75;
If we wish to examine the tuples that satisfy the definition of the view we use the construction:
select * from UPPERGR;
that returns the result:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------2661 019 cs110 FALL 1999 80 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100 3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 FALL 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 cs310 SPRING 2001 100
The update construction:
update UPPERGR set grade = 70 where stno = ’2661’ and empno = ’019’ and cno = ’cs110’ and sem = ’FALL’ and year = 1999;
makes the first row disappear, since it no longer satisfies the definition of the view. Indeed, if we use again the same query on UPPERGR, we obtain:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100
5.23 Views in SQL 157
3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 FALL 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 cs310 SPRING 2001 100
To reestablish the previous content of GRADES, we can use the update:
update UPPERGR set grade = 80 where stno = ’2661’ and empno = ’019’ and cno = ’cs110’ and sem = ’FALL’ and year = 1999;
The standard syntax of create view allows us to use the clause with check option. When this clause is used, every insertion and update done through the view is verified to make sure that a tuple inserted through the view actually appears in the view and an update of a row in the view does not cause the row to vanish from the view. The syntax of create view is:
create view view as subselect [with check option] A view V can be dropped from a database by using the construct
drop view V;
If we drop a tabular variable from the database, then all views based on that table are automatically dropped; if we drop a view, then all other views that use the view that we drop are also dropped. Views are useful instruments in implementing generalizations. Suppose, that we began the construction of the college database from the existing tabular variables UNDERGRADUATES and GRADUATES that modelled sets of entities having the same name, where
heading(UNDERGRADUATES) = stno name addr city state zip major heading(GRADUATES) = stno name addr city state zip qualdate
Then, the tabular variable STUDENTS could have been obtained as a view built from the previous two base tabular variables by
create view STUDENTS as select stno name addr city state zip from U
Example 5.21.5 The following delete eliminates all rows of the table ASSIGN:
delete from ASSIGN;
The syntax of delete is: delete from table name [wherecondition]
5.22 Access Rights
The grant operation assigns access rights to users. To delegate access rights to other users, a user must “own” these rights. The set of access rights includes select, insert, update, and delete and refers to the right of executing each of these operations on a table. Further, update can be restricted to specific columns. All these access rights are granted to the creator of a table automatically. The creator, in turn, may grant access rights to other users or to all users (designated in SQL as public). The SQL standard envisions a mechanism that can limit the excessive proliferation of access rights. Namely, a user may receive the select right with or without the right to grant this right to others by his own action.
Example 5.22.1 Suppose that the user alex owns the table COURSES and intends to grant this right to the user whose name is peter. The user alex can accomplish this by
grant select on COURSES to peter
Now, peter has the right to query the table COURSES but he may not propagate this right to the user ellie. In order for this to happen, alex would have to use the directive:
grant select on COURSES to peter with grant option
Example 5.22.2 If peter owns the table STUDENTS, then he may delegate the right to query the table and the right to update the columns addr, city and zip to ellie using the directive:
grant select, update(addr, city, zip) on STUDENTS to ellie
The standard syntax of grant is:
154 SQL — The Relational Language
grant {priv{,priv} | all [privileges]} on [table] tablename{,tablename} to husername{,username}|publici [with grant option] Here priv has the syntax: hselect|insert|delete|update[(attribute{,attribute})]i Privileges can be revoked using the revoke construct, which is a feature of standard SQL. For instance, if peter wishes to revoke ellie’s privileges to update the table STUDENTS, he may write:
revoke update(addr,city,zip) on STUDENTS from ellie
The standard syntax for this directive is revoke {priv{,priv}|all [privileges]} on [table] tablename{,tablename} from husername{,username}|publici
5.23 Views in SQL
Views are virtual tabular variables. This means that in SQL a view is referenced for retrieval purposes in exactly the same way a tabular variable is referenced. The only difference is that a view does not have a physical existence. It exists only as a definition in the database catalog. We refer to “real” tabular variables (that is, the tabular variables that have a physical existence in the database) as base tabular variables. Views are supported in both SQLPlus and in Transact SQL but not in the current version (4.1) of MySQL. To illustrate the notion of view, let us consider the following example. Example 5.23.1 Suppose that we write:
create view STC as select STUDENTS.name, GRADES.cno from STUDENTS, GRADES where STUDENTS.stno = GRADES.stno;
The select construct contained by this create view retrieves all pairs of student names and course numbers such that the student whose name is s has registered for the course c. When this directive is executed by SQL, no data retrieval takes place. The database system simply stores this definition in its catalog. The definition of the view STC becomes a persistent object, that is, an object that exists after our interaction with the DBMS has ceased. From a conceptual point of view, the user treats STC exactly like any other tabular variable. Suppose, for instance that we wish to retrieve the names of students who took cs110. In this case it is sufficient to write the query:
5.23 Views in SQL 155
select name from STC where cno =’cs110’;
In reality, SQL combines this select phrase with the query just shown and executes the modified query:
select STUDENTS.name from STUDENTS, GRADES where STUDENTS.stno = GRADES.stno and GRADES.cno =’cs110’;
The previous example shows that views in SQL play a role similar to the role played by macros in programming languages. Views are important for data security. A user who needs to have access only to list of names of students and the courses they are taking needs to be aware only of the existence of STC. If the user is authorized to use only select constructs, then the user can ignore whether STC is a table or a view. Confidential data (such as grades obtained in specific courses) can be completely protected in this manner. Also, the queries that this limited-access user may write are simpler and easier to understand. No space is wasted with the view STC, and the view remains current always, reflecting the contents of the tabular variables STUDENTS and GRADES. SQL treats views exactly as it treats the tabular variables as far as retrieval is concerned. We can also delegate the select privilege to a view in exactly the same way as we did for a tabular variable. For instance, if the user george created the view STC, then he can give the select right to vanda by writing:
grant select on STC to vanda;
Consider now another example of view: Example 5.23.2 The view SNA that contains the student number and the names of students can be created by:
create view SNA as select stno, name from STUDENTS
The purpose of this view is to insure privacy to students. Any user who has access only to this view can retrieve the student number and name of a student, but not the address of the student. There is a fundamental difference between the views introduced in Examples 5.23.1 and 5.23.2, and this refers to the ways in which these two views behave with respect to updates. Suppose that the user wishes to insert the pair (7799, ’Jane Jones’) in the view SNA. The user may ignore entirely the fact that SNA is not a base tabular variable. On the other hand, the effect on the base tabular variable of this insertion is unequivocally determined: the system inserts in the tabular variable STUDENTS the tuple (7799, ’Jane Jones’, null, null, null). On the other hand, we cannot insert a tuple in a meaningful way in the view STC introduced in Example 5.23.1. Indeed if we attempt to insert a pair (s,c) in STC, then we have to define the effect of this insertion on the base tabular variable. This is clearly
156 SQL — The Relational Language
impossible: we do not know what the student number is, what the identification of the instructor is, etc. SQL forbids users to update views based on more than one table (as STC is). Even if such updates would have an unambiguous effect on the base tabular variable, this rule rejects any such update. Only some views based on exactly one tabular variable can be updated. It is the responsibility of the database administrator to grant to the user the right to update a view only if that view can be updated. If a view can be updated, then its behavior is somewhat different from the base tabular variable on which the view is built. An update made to a view may cause one or several tuples to vanish from the view, whenever we retrieve the tuples of the view. Example 5.23.3 Consider the view uppergr defined by:
create view UPPERGR as select * from GRADES where grade > 75;
If we wish to examine the tuples that satisfy the definition of the view we use the construction:
select * from UPPERGR;
that returns the result:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------2661 019 cs110 FALL 1999 80 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100 3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 FALL 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 cs310 SPRING 2001 100
The update construction:
update UPPERGR set grade = 70 where stno = ’2661’ and empno = ’019’ and cno = ’cs110’ and sem = ’FALL’ and year = 1999;
makes the first row disappear, since it no longer satisfies the definition of the view. Indeed, if we use again the same query on UPPERGR, we obtain:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100
5.23 Views in SQL 157
3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 FALL 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 cs310 SPRING 2001 100
To reestablish the previous content of GRADES, we can use the update:
update UPPERGR set grade = 80 where stno = ’2661’ and empno = ’019’ and cno = ’cs110’ and sem = ’FALL’ and year = 1999;
The standard syntax of create view allows us to use the clause with check option. When this clause is used, every insertion and update done through the view is verified to make sure that a tuple inserted through the view actually appears in the view and an update of a row in the view does not cause the row to vanish from the view. The syntax of create view is:
create view view as subselect [with check option] A view V can be dropped from a database by using the construct
drop view V;
If we drop a tabular variable from the database, then all views based on that table are automatically dropped; if we drop a view, then all other views that use the view that we drop are also dropped. Views are useful instruments in implementing generalizations. Suppose, that we began the construction of the college database from the existing tabular variables UNDERGRADUATES and GRADUATES that modelled sets of entities having the same name, where
heading(UNDERGRADUATES) = stno name addr city state zip major heading(GRADUATES) = stno name addr city state zip qualdate
Then, the tabular variable STUDENTS could have been obtained as a view built from the previous two base tabular variables by
create view STUDENTS as select stno name addr city state zip from U
0/5000
5.22 สิทธิการเข้าถึง 153ตัวอย่าง 5.21.5 การลบต่อไปนี้เอาแถวของตารางกำหนด:ลบจากกำหนดไวยากรณ์ของลบ: ลบออกจากตารางชื่อ [wherecondition]5.22 สิทธิการเข้าถึงการเงินช่วยเหลือกำหนดสิทธิ์ผู้ใช้ มอบสิทธิ์ให้ผู้อื่น ผู้ใช้ต้อง "เอง" สิทธิเหล่านี้ ชุดของสิทธิ์เลือก แทรก ปรับปรุง และลบ และอ้างอิงถึงการดำเนินการแต่ละการดำเนินการเหล่านี้ในตาราง เพิ่มเติม ปรับปรุงสามารถจำกัดคอลัมน์ specific สิทธิการเข้าถึงเหล่านี้ทั้งหมดจะได้รับการสร้างตารางโดยอัตโนมัติ ผู้สร้าง จะ อาจให้สิทธิการเข้าถึงผู้ใช้อื่น ๆ หรือผู้ใช้ทั้งหมด (กำหนดใน SQL เป็นสาธารณะ) SQL มาตรฐาน envisions กลไกที่สามารถจำกัดสิทธิ์กไปมากเกินไป คือ ผู้ใช้อาจได้รับสิทธิเลือกมี หรือไม่ มีสิทธิที่จะให้สิทธินี้ให้ผู้อื่น โดยการกระทำของเขาเองตัวอย่าง 5.22.1 สมมติว่า ผู้เป็นเจ้าของหลักสูตรตารางอเล็กซ์ และมุ่งมั่นที่จะให้สิทธินี้สำหรับผู้ใช้ที่มีชื่อปีเตอร์ อเล็กซ์สามารถทำได้โดยผู้ใช้ให้เลือกในหลักสูตรกับปีเตอร์ตอนนี้ ปีเตอร์มีสิทธิที่จะสอบถามตารางเรียน แต่เขาอาจไม่แพร่กระจาย ellie ผู้ใช้สิทธินี้ ในการนี้จะเกิดขึ้น อเล็กซ์จะมีการใช้คำสั่ง:ให้เลือกในหลักสูตรเพื่อปีเตอร์ มีให้เลือกตัวอย่างที่ 5.22.2 ถ้าปีเตอร์เป็นเจ้าของตารางเรียน แล้วเขาอาจมอบหมายสิทธิ์ในการสอบถามตารางและสิทธิ์ในการปรับปรุงคอลัมน์ที่อยู่ เมือง และไปรษณีย์ ellie โดยใช้คำสั่ง:ให้เลือก การปรับปรุง (ที่อยู่ เมือง ไปรษณีย์) ในนักเรียนให้ ellieไวยากรณ์มาตรฐานของเงินช่วยเหลือคือ:154 SQL คือภาษาสัมพันธ์กันให้ { priv {, priv } | ทั้งหมด [สิทธิ์] } บน tablename [ตาราง] { tablename } husername {, ชื่อผู้ใช้} |publici [มีให้เลือก] นี่ priv มีไวยากรณ์: hselect|insert|delete|update[(attribute{,attribute})] ฉันสิทธิ์สามารถถูกเพิกถอนโดยใช้การยกเลิกโครงสร้าง ซึ่งเป็นคุณลักษณะของมาตรฐาน SQL ได้ ตัวอย่าง ถ้า ปีเตอร์ต้องการยกเลิกสิทธิ์ของ ellie ปรับปรุงตารางเรียน อาจเขียน:ยกเลิก update(addr,city,zip) กับนักเรียนจาก ellieมาตรฐานไวยากรณ์สำหรับคำสั่งนี้ถูกยกเลิก { priv {, priv } |all [สิทธิ์] } บน tablename [ตาราง] { tablename } จาก husername {, ชื่อผู้ใช้} |publici5.23 มุมมองใน SQLมุมมองเป็นเสมือนตัวแปรตาราง ซึ่งหมายความ ว่า ใน SQL มุมอ้างอิงเพื่อเรียกว่าวิธีเดียวที่มีการอ้างอิงตัวแปรตาราง Difference เดียวอยู่ที่มุมมองไม่มีอยู่จริง มันมีอยู่เท่ากับ definition ในแค็ตตาล็อกฐานข้อมูล เราอ้างอิงถึงตัวแปรตาราง "จริง" (นั่นคือ ตารางตัวแปรที่มีอยู่จริงในฐานข้อมูล) เป็นตัวแปรตารางพื้นฐาน มุมมองที่ได้รับการสนับสนุน ในทั้ง SQLPlus และ ใน Transact SQL แต่ ในเวอร์ชันปัจจุบัน (4.1) ของ MySQL ไม่ เพื่อแสดงแนวคิดของมุมมอง ให้เราพิจารณาตัวอย่างต่อไปนี้ ตัวอย่าง 5.23.1 สมมติว่า เราเขียน:สร้างมุมมอง STC เป็น STUDENTS.name, GRADES.cno จากนักเรียน เลือกเกรด STUDENTS.stno = GRADES.stnoสร้างเลือกมุมมองนี้สร้างอยู่ดึงคู่ของนักศึกษาชื่อและหมายเลขหลักสูตรให้นักศึกษาที่มีชื่อคือ s ได้ลงทะเบียนสำหรับหลักสูตร c คำสั่งนี้จะใช้ โดย SQL เรียกข้อมูลไม่เกิดขึ้น ระบบฐานข้อมูลจัดเก็บ definition นี้ในแค็ตตาล็อกของแค่ Definition ของ STC เป็น วัตถุแบบถาวร คือ วัตถุที่มีอยู่หลังจากติดต่อกับ DBMS มีเพิ่ม จากแนวคิดจุดของมุมมอง ผู้ปฏิบัติ STC เหมือนแปรตารางอื่น ๆ สมมติว่า เช่นว่า เราต้องการเรียกชื่อของนักเรียนที่ cs110 ในกรณีนี้ คือ sufficient การเขียนแบบสอบถาม:5.23 มุมมองใน SQL 155เลือกชื่อจาก STC ที่ซีเอ็นโอ = 'cs110'ในความเป็นจริง SQL รวมวลีนี้เลือกแบบสอบถามเพียงแสดง และดำเนินการแบบสอบถามที่ modified:เลือก STUDENTS.name จากนักเรียน เกรดที่ STUDENTS.stno = GRADES.stno และ GRADES.cno = 'cs110'ตัวอย่างก่อนหน้านี้แสดงว่า มุมมองใน SQL มีบทบาทคล้ายกับบทบาทที่เล่น โดยแมโครในภาษาการเขียนโปรแกรม มุมมองที่มีความสำคัญสำหรับความปลอดภัยของข้อมูล ผู้ที่ต้องการสามารถเข้าถึงรายชื่อนักเรียนและหลักสูตรเฉพาะ พวกเขาจะมีความตระหนักถึงการดำรงอยู่ของ STC เพียง ถ้าผู้ได้รับอนุญาตให้ใช้ เฉพาะ เลือกโครงสร้าง แล้ว ผู้ใช้สามารถละเว้นว่า STC ตารางหรือมุมมอง ข้อมูล Confidential (เช่นเกรดได้รับในหลักสูตร specific) สามารถได้รับในลักษณะนี้อย่างสมบูรณ์ ยัง แบบสอบถามที่ผู้ใช้จำกัดการเข้าถึงนี้อาจเขียนได้ง่ายกว่า และเข้าใจได้ง่ายขึ้น สิ้นเปลืองพื้นที่ไม่ STC มุมมอง และมุมมองปัจจุบันยังคงอยู่เสมอ reflecting เนื้อหาของตัวแปรตารางเรียนและเกรด SQL จะมองเหมือนปฏิบัติต่อตัวแปรตารางเป็นที่เกี่ยวข้องเรียก เราสามารถมอบสิทธิ์เลือกมุมมองในแบบเดียวกับเราไม่ได้สำหรับตัวแปรตาราง ตัวอย่าง ถ้าผู้ใช้จอร์จสร้างมุมมอง STC แล้วเขาจะให้สิทธิเลือกแวนด้า โดยเขียน:ให้เลือกใน STC กับแวนด้าพิจารณาตอนนี้อีกตัวอย่างหนึ่งของมุมมอง: ตัวอย่าง 5.23.2 สามารถสร้างมุมมอง SNA ที่ประกอบด้วยจำนวนนักเรียนและชื่อของนักเรียน โดย:สร้างมุมมอง SNA เป็นเลือก stno ชื่อจากนักเรียนวัตถุประสงค์ของมุมมองนี้จะประกันความเป็นส่วนตัวนักศึกษา ผู้เข้าถึงเฉพาะในมุมมองนี้สามารถดึงข้อมูลจำนวนนักเรียนและชื่อนักเรียน แต่ไม่อยู่ของนักเรียน มี difference พื้นฐานระหว่างมุมมองในตัวอย่าง 5.23.1 และ 5.23.2 และนี้หมายถึงวิธีการที่สองมุมมองนี้ทำงานเกี่ยวกับการปรับปรุง สมมติว่า ผู้ใช้ต้องการแทรกคู่ (7799, 'เจนโจนส์') ใน SNA ผู้ใช้อาจละเว้นทั้งข้อเท็จจริงว่า SNA ไม่ตัวแปรตารางพื้นฐาน บนมืออื่น ๆ unequivocally ได้กำหนด effect ตัวแปรตารางพื้นฐานของแทรกนี้: ระบบแทรกในตารางตัวแปรนักเรียนทูเพิล (7799, 'Jane Jones', null นิพจน์ เป็น null บนมืออื่น ๆ เราไม่สามารถแทรกทูเพิลในทางความหมายใน STC ที่นำมาใช้ในตัวอย่าง 5.23.1 แน่นอนถ้าเราพยายามแทรกคู่ (s, c) ใน STC แล้วเราจะต้อง define effect ของนี้แทรกตัวแปรตารางพื้นฐาน นี้ได้อย่างชัดเจน156 SQL คือภาษาสัมพันธ์กันเป็นไปไม่ได้: เราไม่ทราบจำนวนนักเรียนคืออะไร identification ของผู้สอนคืออะไร ฯลฯ SQL ห้ามปรามผู้ใช้สามารถปรับปรุงมุมมองที่ยึดตามตารางมากกว่าหนึ่งตาราง (เป็น STC) แม้ว่าการปรับปรุงดังกล่าวจะมี effect ชัดเจนบนพื้นฐานตัวแปรตาราง กฎนี้ปฏิเสธการปรับปรุงดังกล่าว เฉพาะมุมมองบางอย่างตามตัวแปรตารางหนึ่งสามารถปรับปรุง ความรับผิดชอบของผู้ดูแลฐานข้อมูลให้แก่ผู้ใช้สิทธิในการปรับปรุงมุมมองเฉพาะมุมมองนั้นสามารถปรับปรุงได้ ถ้าสามารถปรับปรุงมุมมอง แล้วเป็นลักษณะการทำงานได้ค่อนข้าง different จากตัวแปรตารางพื้นฐานที่สร้างมุมมอง การปรับปรุงที่ทำกับมุมมองอาจทำให้หนึ่ง หรือหลาย tuples สูญจากมุมมอง เมื่อเราดึง tuples ของมุมมอง ตัวอย่าง 5.23.3 พิจารณา defined uppergr ดูด้วย:สร้างมุมมอง UPPERGR เป็นเลือก * จากเกรดซึ่งเกรด > 75ถ้าเราต้องการตรวจสอบ tuples ที่ตอบสนอง definition ของ เราใช้การก่อสร้าง:เลือก * จาก UPPERGRที่ส่งกลับผลลัพธ์:STNO EMPNO ซีเอ็นโอ SEM ปีเกรด----------------2661 019 cs110 ฤดูใบไม้ร่วงปี 1999 80 3566 019 cs110 ฤดูใบไม้ร่วงปี 1999 95 5544 019 cs110 ฤดูใบไม้ร่วงปี 1999 100 3566 019 cs240 สปริง 2000 100 2415 019 cs240 สปริง 2000 100 5571 234 cs410 สปริง 2000 80 1011 019 cs210 ตก 2000 90 3566 019 cs210 ตก 2000 90 5571 019 cs210 ฤดูใบไม้ผลิ 2001 85 1011 056 cs240 ฤดูใบไม้ผลิ 2001 90 4022 056 cs240 ฤดูใบไม้ผลิ 2001 80 2661 234 cs310 สปริง 100 ปี 2001ก่อสร้างปรับปรุง:เด UPPERGR ชุดเกรด = 70 ที่ stno = '2661' และ empno = '019' และซีเอ็นโอ = 'cs110' และ sem = 'ตก' และปี 1999 =ทำให้แถว first ที่หายไป เพราะมันไม่ satisfies ยาว definition มุมมอง แน่นอน ถ้าเราใช้อีกแบบสอบถาม UPPERGR เราขอรับ:STNO EMPNO ซีเอ็นโอ SEM ปีเกรด------------------3566 019 cs110 ฤดูใบไม้ร่วงปี 1999 95 5544 019 cs110 ตก 100 ปี 19995.23 มุมมองใน SQL 1573566 019 cs240 สปริง 2000 100 2415 019 cs240 สปริง 2000 100 5571 234 cs410 สปริง 2000 80 1011 019 cs210 ตกราคา 2000 90 3566 019 cs210 ตก 2000 90 5571 019 cs210 ฤดูใบไม้ผลิ 2001 85 1011 056 cs240 ฤดูใบไม้ผลิ 2001 90 4022 056 cs240 ฤดูใบไม้ผลิ 2001 80 2661 234 cs310 สปริง 100 ปี 2001เพื่อสร้างเนื้อหาก่อนหน้านี้ของเกรด เราสามารถใช้การปรับปรุง:เด UPPERGR ชุดเกรด = 80 ที่ stno = '2661' และ empno = '019' และซีเอ็นโอ = 'cs110' และ sem = 'ตก' และปี 1999 =ไวยากรณ์มาตรฐานสร้างมุมมองช่วยให้เราสามารถใช้ประโยคที่ มีตัวเลือกกาเครื่องหมาย เมื่อใช้นี้ ทุกแทรกและปรับปรุงที่ทำผ่านทางมุมมองได้ verified เพื่อให้แน่ใจว่า ทูเพิลที่แทรกผ่านมุมมองจริงปรากฏในมุมมอง และการปรับปรุงแถวในมุมมองทำให้เกิดแถวล่องหนจากมุมมอง คือไวยากรณ์สร้างมุมมอง:สร้างวิวเป็น subselect [ด้วยเครื่อง] มุม V สามารถถูกลบจากฐานข้อมูลโดยใช้โครงสร้างฝากดู Vถ้าเราปล่อยตัวแปรตารางจากฐานข้อมูล แล้วมุมมองทั้งหมดที่ยึดตามตารางนั้นอยู่โดยอัตโนมัติลบ ถ้าเราปล่อยมุม แล้วมุมมองอื่น ๆ ทั้งหมดที่ใช้มุมมองที่เราวางจะยังลบ มุมมองเป็นเครื่องมือมีประโยชน์ในการใช้ generalizations สมมติว่า เราเริ่มการก่อสร้างของวิทยาลัยฐานข้อมูลจากตัวแปรตารางอยู่สูง ๆ และบัณฑิตที่คือที่ แบบจำลองชุดของเอนทิตีที่มีชื่อเดียวกัน ที่heading(UNDERGRADUATES) = stno ชื่อที่อยู่เมืองสถานะไปรษณีย์หลัก heading(GRADUATES) = stno ชื่อที่อยู่เมืองสถานะไปรษณีย์ qualdateแล้ว นักเรียนตัวแปรตารางไม่ได้ถูกรับเป็นมุมมองสร้างขึ้นจากก่อนหน้านี้สองฐานตารางตัวแปรตามสร้างมุมมองนักเรียนเป็น stno เลือกชื่อที่อยู่เมืองสถานะไปรษณีย์จาก U
การแปล กรุณารอสักครู่..
5.22 สิทธิการเข้าถึง 153
ตัวอย่าง 5.21.5 ลบต่อไปนี้จะช่วยลดทุกแถวของตาราง ASSIGN:
ลบออกจาก ASSIGN;
ไวยากรณ์ของลบคือลบจากชื่อตาราง [WhereCondition]
5.22 สิทธิการเข้าถึง
การดำเนินงานทุนกำหนดสิทธิการเข้าถึงให้กับผู้ใช้ การมอบหมายสิทธิการเข้าถึงให้กับผู้ใช้อื่น ๆ ที่ผู้ใช้จะต้อง "เจ้าของ" สิทธิเหล่านี้ ชุดของสิทธิในการเข้าถึงรวมถึงการเลือกแทรกปรับปรุงและลบและหมายถึงการที่เหมาะสมในการดำเนินการแต่ละดำเนินการเหล่านี้บนโต๊ะ นอกจากนี้การปรับปรุงสามารถ จำกัด เฉพาะเจาะจงคอลัมน์ค ทุกสิทธิการเข้าถึงเหล่านี้จะได้รับไปยังผู้สร้างของตารางโดยอัตโนมัติ ผู้สร้างในทางกลับกันอาจให้สิทธิในการเข้าถึงผู้ใช้รายอื่นหรือกับผู้ใช้ทั้งหมด (กำหนดใน SQL เป็นสาธารณะ) SQL มาตรฐานวาดภาพกลไกที่สามารถ จำกัด การแพร่กระจายมากเกินไปของสิทธิในการเข้าถึง กล่าวคือผู้ใช้อาจได้รับสิทธิในการเลือกที่มีหรือไม่มีสิทธิที่จะให้สิทธินี้ให้กับผู้อื่นโดยการกระทำของเขาเอง.
ตัวอย่าง 5.22.1 สมมติว่าผู้ใช้ alex เป็นเจ้าของหลักสูตรโต๊ะและมุ่งมั่นที่จะให้สิทธิกับผู้ที่มีชื่อนี้ จางไป ผู้ใช้ alex สามารถทำได้โดยการ
เลือกทุนเกี่ยวกับหลักสูตรปีเตอร์
ตอนนี้ปีเตอร์มีสิทธิในการค้นหาหลักสูตรตาราง แต่เขาอาจไม่เผยแพร่ที่เหมาะสมให้กับผู้ใช้ ellie นี้ ในการนี้จะเกิดขึ้น, อเล็กซ์จะต้องใช้คำสั่ง:
ทุนเลือกเกี่ยวกับหลักสูตรปีเตอร์กับตัวเลือกทุน
ตัวอย่าง 5.22.2 ถ้าปีเตอร์เป็นเจ้าของนักเรียนโต๊ะแล้วเขาอาจมอบหมายสิทธิที่จะสอบถามตารางและสิทธิในการปรับปรุง คอลัมน์ addr เมืองและไปรษณีย์เอลลีโดยใช้คำสั่ง:
ให้เลือกปรับปรุง (addr เมือง zip) นักศึกษาที่จะ ellie
ไวยากรณ์มาตรฐานของทุนคือ
154 SQL - ภาษาเชิง
ทุน {{priv, priv} | ทั้งหมด [สิทธิพิเศษ]} ในตาราง [] tablename {, tablename} เพื่อ husername {ชื่อผู้ใช้} | Publici [มีตัวเลือกทุน] ที่นี่ priv มีไวยากรณ์: hselect | แทรก | ลบ | ปรับปรุง [(แอตทริบิวต์ {คุณลักษณะ})] ไอสิทธิพิเศษ สามารถยกเลิกการใช้เพิกถอนสร้างซึ่งเป็นคุณลักษณะของ SQL มาตรฐาน ตัวอย่างเช่นถ้าปีเตอร์ประสงค์จะยกเลิกสิทธิ์ของเอลลีในการปรับปรุงนักเรียนโต๊ะเขาอาจเขียน:
ยกเลิกการปรับปรุง (addr เมือง zip) ในนักเรียนจาก ellie
ไวยากรณ์มาตรฐานสำหรับคำสั่งนี้เป็นเพิกถอน {priv {ลูกส} | ทั้งหมด [ สิทธิพิเศษ]} ในตาราง [] tablename {} tablename จาก husername {ชื่อผู้ใช้} | Publici
5.23 ครั้งใน SQL
ครั้งเป็นตัวแปรตารางเสมือน ซึ่งหมายความว่าในมุมมองของ SQL มีการอ้างอิงเพื่อวัตถุประสงค์ในการดึงตรงเช่นเดียวกับตัวแปรตารางมีการอ้างอิง ดิเท่านั้น ff การตั้งเป็นมุมมองที่ไม่ได้มีการดำรงอยู่ทางกายภาพ มันมีอยู่เป็นเพียงไฟเดอ nition ในแคตตาล็อกฐานข้อมูล เราหมายถึง "ของจริง" ตัวแปรตาราง (นั่นคือตัวแปรตารางที่มีการดำรงอยู่ทางกายภาพในฐานข้อมูล) เป็นตัวแปรตารางฐาน ผู้ชมได้รับการสนับสนุนทั้งใน SQLPlus และใน Transact SQL แต่ไม่ได้อยู่ในรุ่นปัจจุบัน (4.1) ของ MySQL เพื่อแสดงให้เห็นความคิดของมุมมองให้เราพิจารณาตัวอย่างต่อไปนี้ 5.23.1 ตัวอย่างสมมติว่าเราเขียน:
สร้างมุมมองที่เป็นเอสทีซีเลือก STUDENTS.name, GRADES.cno จากนักเรียน, การเรียนที่ STUDENTS.stno = GRADES.stno;
สร้างเลือกที่มีอยู่โดยสร้างมุมมองนี้จะเรียกคู่ของชื่อนักเรียนและแน่นอน ตัวเลขดังกล่าวว่านักเรียนที่มีชื่อเป็น S ได้ลงทะเบียนสำหรับคแน่นอน เมื่อคำสั่งนี้จะถูกดำเนินการโดย SQL, การดึงข้อมูลไม่เกิดขึ้น ระบบฐานข้อมูลเพียงแค่เก็บ nition สายนี้ในแคตตาล็อก nition ไฟของเอสทีซีวิวจะกลายเป็นวัตถุถาวรที่เป็นวัตถุที่มีอยู่หลังจากการทำงานร่วมกันของเรากับ DBMS ได้หยุด จากจุดแนวความคิดในมุมมองของผู้ใช้เอสทีซีถือว่าเหมือนกับตัวแปรตารางอื่น ๆ สมมติเช่นที่เราต้องการที่จะดึงชื่อของนักเรียนที่เข้ามา cs110 ในกรณีนี้มันเป็น su เพียงพอ FFI จะเขียนแบบสอบถาม:
5.23 ครั้งใน SQL 155
เลือกชื่อจากเอสทีซีที่ CNO = 'cs110';
ในความเป็นจริง SQL รวมนี้วลีเลือกด้วยแบบสอบถามแสดงเพียงและดำเนิน Fi Modi เอ็ดแบบสอบถาม:
เลือก STUDENTS.name จากนักเรียน, การเรียนที่ STUDENTS.stno = GRADES.stno และ GRADES.cno = 'cs110';
ตัวอย่างก่อนหน้านี้แสดงให้เห็นว่ามุมมองใน SQL มีบทบาทคล้ายกับบทบาทของแมโครในการเขียนโปรแกรมภาษา ผู้ชมมีความสำคัญต่อความปลอดภัยของข้อมูล ผู้ใช้ที่ต้องการให้มีการเข้าถึงเฉพาะรายชื่อนักเรียนและหลักสูตรที่พวกเขามีการตอบสนองความต้องการที่จะทราบเพียงอย่างเดียวของการดำรงอยู่ของเอสทีซี หากผู้มีอำนาจที่จะใช้สร้างเลือกเท่านั้นจากนั้นผู้ใช้สามารถละเว้นไม่ว่าจะเป็นเอสทีซีเป็นตารางหรือมุมมอง Con Fi ข้อมูล dential (เช่นเกรดที่ได้รับในหลักสูตรคที่ระบุไว้) ได้รับความคุ้มครองอย่างสมบูรณ์ในลักษณะนี้ นอกจากนี้คำสั่งที่ว่านี้ผู้ใช้ จำกัด การเข้าถึงอาจเขียนเป็นง่ายและง่ายต่อการเข้าใจ ไม่มีพื้นที่จะสูญเสียกับเอสทีซีมุมมองและมุมมองยังคงเป็นปัจจุบันเสมออีกชั้น ecting เนื้อหาของตัวแปรตารางนักเรียนและการเรียน SQL ปฏิบัติต่อมุมมองที่ตรงตามที่ให้การปฏิบัติต่อตัวแปรตารางเท่าที่ดึงความกังวล นอกจากนี้เรายังสามารถมอบหมายสิทธิ์เลือกไปยังมุมมองในตรงทางเดียวกับที่เราทำสำหรับตัวแปรตาราง ตัวอย่างเช่นหากผู้ใช้สร้างมุมมองที่จอร์จเอสทีซีแล้วเขาสามารถให้สิทธิเลือกเพื่อแวนด้าโดยการเขียน:
ทุนเลือกใน STC เพื่อแวนด้า;
พิจารณาในขณะนี้ตัวอย่างของมุมมองอื่น: ตัวอย่าง 5.23.2 SNA มุมมองที่มีจำนวนนักเรียน และชื่อของนักเรียนที่สามารถสร้างขึ้นโดย:
สร้างมุมมอง SNA เป็น stno เลือกชื่อจากนักเรียน
วัตถุประสงค์ของมุมมองนี้คือการประกันความเป็นส่วนตัวให้กับนักเรียน ผู้ใช้ที่มีการเข้าถึงเฉพาะมุมมองนี้สามารถดึงข้อมูลจำนวนนักเรียนและชื่อของนักเรียน แต่ไม่ได้อยู่ของนักเรียน มีการตั้งดิ ff พื้นฐานระหว่างมุมมองที่นำมาใช้ในตัวอย่าง 5.23.1 และ 5.23.2 เป็นและนี้หมายถึงวิธีการที่ทั้งสองมุมมองที่มีพฤติกรรมเกี่ยวกับการปรับปรุง สมมติว่าผู้ใช้มีความประสงค์จะใส่คู่ (7799, 'เจนโจนส์) ในมุมมอง SNA ผู้ใช้อาจไม่สนใจทั้งหมดความจริงที่ว่า SNA ไม่ตัวแปรตารางฐาน ในทางตรงกันข้าม, อี ff ect บนฐานตัวแปรตารางแทรกนี้จะถูกกำหนดอย่างแจ่มแจ้ง: แทรกระบบในนักเรียนตัวแปรตาราง tuple (7799, 'เจนโจนส์', null, null, null) ในทางกลับกันเราไม่สามารถแทรก tuple ในทางที่มีความหมายในมุมมอง STC นำมาใช้ในตัวอย่าง 5.23.1 อันที่จริงถ้าเราพยายามที่จะแทรกคู่ (s ค) ในเอสทีซีแล้วเรามีให้กับสายตะวันออกเฉียงเหนือจ ff ect แทรกนี้บนตัวแปรตารางฐาน นี้จะชัดเจน
156 SQL - ภาษาเชิงสัมพันธ์
เป็นไปไม่ได้เราไม่ทราบว่าจำนวนนักเรียนเป็นสิ่งที่ไอออนบวกสายการระบุของผู้สอนคือ ฯลฯ SQL ห้ามผู้ใช้สามารถอัปเดตขึ้นอยู่กับมุมมองมากกว่าหนึ่งตาราง (เช่นเอสทีซีเป็น) แม้ว่าการปรับปรุงดังกล่าวจะมีความชัดเจนทาง e ff ect ตัวแปรตารางฐานกฎนี้ปฏิเสธใด ๆ การปรับปรุงดังกล่าว เพียงมุมมองบางอย่างขึ้นอยู่กับว่าหนึ่งตัวแปรตารางสามารถปรับปรุงได้ มันเป็นความรับผิดชอบของผู้ดูแลระบบฐานข้อมูลที่จะกำหนดให้ผู้ใช้สิทธิในการปรับปรุงมุมมองเฉพาะในกรณีที่เห็นว่าสามารถปรับปรุงได้ ถ้ามุมมองที่สามารถปรับปรุงได้แล้วพฤติกรรมของมันจะค่อนข้างดิ ff erent จากตัวแปรตารางฐานที่มุมมองที่ถูกสร้างขึ้น การปรับปรุงที่เกิดขึ้นกับมุมมองที่อาจก่อให้เกิดสิ่งอันดับหนึ่งหรือหลายที่จะหายไปจากมุมมองเมื่อใดก็ตามที่เราเรียก tuples ของมุมมอง ตัวอย่าง 5.23.3 พิจารณามุมมอง uppergr นิยามโดย:
สร้าง UPPERGR มุมมองเป็น * เลือกจากการเรียนที่คะแนน> 75;
ถ้าเราต้องการที่จะตรวจสอบ tuples ที่ตอบสนองความ nition Fi ของมุมมองที่เราใช้ในการก่อสร้าง:
* เลือกจาก UPPERGR;
ว่าผลตอบแทน ผล:
STNO EMPNO CNO SEM ชั้นปี ---------- ----------- ----- ------ --------- - --------- 2661 019 cs110 FALL 1999 80 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100 3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 ฤดูใบไม้ร่วง 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 CS310 SPRING 2001 100
ก่อสร้างปรับปรุง:
ปรับปรุง UPPERGR ชุดชั้นประถมศึกษาปี 70 = ที่ stno = '2661' และ empno = '019' และ CNO = 'cs110' และ SEM = 'FALL' และในปี = 1999;
ทำให้แถวสายแรกหายไปเพราะมันไม่พอไฟ es nition เด Fi ในมุมมองของ อันที่จริงถ้าเราใช้อีกครั้งการค้นหาเดียวกันใน UPPERGR เราได้รับ:
STNO EMPNO CNO SEM ชั้นปี ---------- ----------- ----- --- --- ---------- --------- 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100
5.23 ครั้งใน SQL 157
3566 019 cs240 SPRING 2,000 100 2,415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 ฤดูใบไม้ร่วง 2000 90 3566 019 cs210 ฤดูใบไม้ร่วง 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 CS310 SPRING 2001 100
ในการกอบกู้เนื้อหาก่อนหน้าของการเรียน เราสามารถใช้การปรับปรุง:
การปรับปรุง UPPERGR ชุดชั้นประถมศึกษาปี 80 = ที่ stno = '2661' และ empno = '019' และ CNO = 'cs110' และ SEM = 'FALL' และในปี = 1999;
ไวยากรณ์มาตรฐานของการสร้างมุมมองช่วยให้เรา ที่จะใช้ประโยคที่มีตัวเลือกการตรวจสอบ เมื่อคำสั่งนี้จะใช้การแทรกทุกคนและการปรับปรุงทำผ่านมุมมองที่เอ็ด Fi Veri เพื่อให้แน่ใจว่า tuple แทรกผ่านมุมมองของจริงจะปรากฏในมุมมองและการปรับปรุงของแถวในมุมมองไม่ก่อให้เกิดแถวที่จะหายไปจากมุมมอง . ไวยากรณ์ของสร้างมุมมองคือ:
สร้างมุมมองมุมมองเป็น subselect [มีตัวเลือกในการตรวจสอบ] วีมุมมองสามารถลดลงจากฐานข้อมูลโดยใช้โครงสร้าง
แบบเลื่อนดู V;
ถ้าเราวางตัวแปรตารางจากฐานข้อมูลแล้วมุมมองทั้งหมดขึ้นอยู่กับว่า ตารางจะลดลงโดยอัตโนมัติ ถ้าเราวางมุมมองแล้วมุมมองอื่น ๆ ทั้งหมดที่ใช้มุมมองที่เราลดลงจะลดลงนอกจากนี้ยังมี ครั้งเป็นเครื่องมือที่มีประโยชน์ในการดำเนินการ generalizations สมมติว่าเราเริ่มก่อสร้างของฐานข้อมูลจากวิทยาลัยตัวแปรตารางที่มีอยู่ระดับปริญญาตรีและบัณฑิตที่ถ่ายแบบชุดของหน่วยงานที่มีชื่อเดียวกันที่
มุ่งหน้า (นักศึกษาปริญญาตรี) = ชื่อเมือง addr stno รัฐซิปหัวข้อสำคัญ (ผู้สำเร็จการศึกษา) = ชื่อ addr stno เมืองซิปรัฐ qualdate
จากนั้นนักเรียนตัวแปรตารางจะได้รับในฐานะที่เป็นมุมมองที่สร้างขึ้นจากก่อนหน้านี้สองตัวแปรตารางฐานโดยการ
สร้างมุมมองที่เป็นนักเรียนเลือกชื่อ stno addr ซิปเมืองรัฐจาก U
ตัวอย่าง 5.21.5 ลบต่อไปนี้จะช่วยลดทุกแถวของตาราง ASSIGN:
ลบออกจาก ASSIGN;
ไวยากรณ์ของลบคือลบจากชื่อตาราง [WhereCondition]
5.22 สิทธิการเข้าถึง
การดำเนินงานทุนกำหนดสิทธิการเข้าถึงให้กับผู้ใช้ การมอบหมายสิทธิการเข้าถึงให้กับผู้ใช้อื่น ๆ ที่ผู้ใช้จะต้อง "เจ้าของ" สิทธิเหล่านี้ ชุดของสิทธิในการเข้าถึงรวมถึงการเลือกแทรกปรับปรุงและลบและหมายถึงการที่เหมาะสมในการดำเนินการแต่ละดำเนินการเหล่านี้บนโต๊ะ นอกจากนี้การปรับปรุงสามารถ จำกัด เฉพาะเจาะจงคอลัมน์ค ทุกสิทธิการเข้าถึงเหล่านี้จะได้รับไปยังผู้สร้างของตารางโดยอัตโนมัติ ผู้สร้างในทางกลับกันอาจให้สิทธิในการเข้าถึงผู้ใช้รายอื่นหรือกับผู้ใช้ทั้งหมด (กำหนดใน SQL เป็นสาธารณะ) SQL มาตรฐานวาดภาพกลไกที่สามารถ จำกัด การแพร่กระจายมากเกินไปของสิทธิในการเข้าถึง กล่าวคือผู้ใช้อาจได้รับสิทธิในการเลือกที่มีหรือไม่มีสิทธิที่จะให้สิทธินี้ให้กับผู้อื่นโดยการกระทำของเขาเอง.
ตัวอย่าง 5.22.1 สมมติว่าผู้ใช้ alex เป็นเจ้าของหลักสูตรโต๊ะและมุ่งมั่นที่จะให้สิทธิกับผู้ที่มีชื่อนี้ จางไป ผู้ใช้ alex สามารถทำได้โดยการ
เลือกทุนเกี่ยวกับหลักสูตรปีเตอร์
ตอนนี้ปีเตอร์มีสิทธิในการค้นหาหลักสูตรตาราง แต่เขาอาจไม่เผยแพร่ที่เหมาะสมให้กับผู้ใช้ ellie นี้ ในการนี้จะเกิดขึ้น, อเล็กซ์จะต้องใช้คำสั่ง:
ทุนเลือกเกี่ยวกับหลักสูตรปีเตอร์กับตัวเลือกทุน
ตัวอย่าง 5.22.2 ถ้าปีเตอร์เป็นเจ้าของนักเรียนโต๊ะแล้วเขาอาจมอบหมายสิทธิที่จะสอบถามตารางและสิทธิในการปรับปรุง คอลัมน์ addr เมืองและไปรษณีย์เอลลีโดยใช้คำสั่ง:
ให้เลือกปรับปรุง (addr เมือง zip) นักศึกษาที่จะ ellie
ไวยากรณ์มาตรฐานของทุนคือ
154 SQL - ภาษาเชิง
ทุน {{priv, priv} | ทั้งหมด [สิทธิพิเศษ]} ในตาราง [] tablename {, tablename} เพื่อ husername {ชื่อผู้ใช้} | Publici [มีตัวเลือกทุน] ที่นี่ priv มีไวยากรณ์: hselect | แทรก | ลบ | ปรับปรุง [(แอตทริบิวต์ {คุณลักษณะ})] ไอสิทธิพิเศษ สามารถยกเลิกการใช้เพิกถอนสร้างซึ่งเป็นคุณลักษณะของ SQL มาตรฐาน ตัวอย่างเช่นถ้าปีเตอร์ประสงค์จะยกเลิกสิทธิ์ของเอลลีในการปรับปรุงนักเรียนโต๊ะเขาอาจเขียน:
ยกเลิกการปรับปรุง (addr เมือง zip) ในนักเรียนจาก ellie
ไวยากรณ์มาตรฐานสำหรับคำสั่งนี้เป็นเพิกถอน {priv {ลูกส} | ทั้งหมด [ สิทธิพิเศษ]} ในตาราง [] tablename {} tablename จาก husername {ชื่อผู้ใช้} | Publici
5.23 ครั้งใน SQL
ครั้งเป็นตัวแปรตารางเสมือน ซึ่งหมายความว่าในมุมมองของ SQL มีการอ้างอิงเพื่อวัตถุประสงค์ในการดึงตรงเช่นเดียวกับตัวแปรตารางมีการอ้างอิง ดิเท่านั้น ff การตั้งเป็นมุมมองที่ไม่ได้มีการดำรงอยู่ทางกายภาพ มันมีอยู่เป็นเพียงไฟเดอ nition ในแคตตาล็อกฐานข้อมูล เราหมายถึง "ของจริง" ตัวแปรตาราง (นั่นคือตัวแปรตารางที่มีการดำรงอยู่ทางกายภาพในฐานข้อมูล) เป็นตัวแปรตารางฐาน ผู้ชมได้รับการสนับสนุนทั้งใน SQLPlus และใน Transact SQL แต่ไม่ได้อยู่ในรุ่นปัจจุบัน (4.1) ของ MySQL เพื่อแสดงให้เห็นความคิดของมุมมองให้เราพิจารณาตัวอย่างต่อไปนี้ 5.23.1 ตัวอย่างสมมติว่าเราเขียน:
สร้างมุมมองที่เป็นเอสทีซีเลือก STUDENTS.name, GRADES.cno จากนักเรียน, การเรียนที่ STUDENTS.stno = GRADES.stno;
สร้างเลือกที่มีอยู่โดยสร้างมุมมองนี้จะเรียกคู่ของชื่อนักเรียนและแน่นอน ตัวเลขดังกล่าวว่านักเรียนที่มีชื่อเป็น S ได้ลงทะเบียนสำหรับคแน่นอน เมื่อคำสั่งนี้จะถูกดำเนินการโดย SQL, การดึงข้อมูลไม่เกิดขึ้น ระบบฐานข้อมูลเพียงแค่เก็บ nition สายนี้ในแคตตาล็อก nition ไฟของเอสทีซีวิวจะกลายเป็นวัตถุถาวรที่เป็นวัตถุที่มีอยู่หลังจากการทำงานร่วมกันของเรากับ DBMS ได้หยุด จากจุดแนวความคิดในมุมมองของผู้ใช้เอสทีซีถือว่าเหมือนกับตัวแปรตารางอื่น ๆ สมมติเช่นที่เราต้องการที่จะดึงชื่อของนักเรียนที่เข้ามา cs110 ในกรณีนี้มันเป็น su เพียงพอ FFI จะเขียนแบบสอบถาม:
5.23 ครั้งใน SQL 155
เลือกชื่อจากเอสทีซีที่ CNO = 'cs110';
ในความเป็นจริง SQL รวมนี้วลีเลือกด้วยแบบสอบถามแสดงเพียงและดำเนิน Fi Modi เอ็ดแบบสอบถาม:
เลือก STUDENTS.name จากนักเรียน, การเรียนที่ STUDENTS.stno = GRADES.stno และ GRADES.cno = 'cs110';
ตัวอย่างก่อนหน้านี้แสดงให้เห็นว่ามุมมองใน SQL มีบทบาทคล้ายกับบทบาทของแมโครในการเขียนโปรแกรมภาษา ผู้ชมมีความสำคัญต่อความปลอดภัยของข้อมูล ผู้ใช้ที่ต้องการให้มีการเข้าถึงเฉพาะรายชื่อนักเรียนและหลักสูตรที่พวกเขามีการตอบสนองความต้องการที่จะทราบเพียงอย่างเดียวของการดำรงอยู่ของเอสทีซี หากผู้มีอำนาจที่จะใช้สร้างเลือกเท่านั้นจากนั้นผู้ใช้สามารถละเว้นไม่ว่าจะเป็นเอสทีซีเป็นตารางหรือมุมมอง Con Fi ข้อมูล dential (เช่นเกรดที่ได้รับในหลักสูตรคที่ระบุไว้) ได้รับความคุ้มครองอย่างสมบูรณ์ในลักษณะนี้ นอกจากนี้คำสั่งที่ว่านี้ผู้ใช้ จำกัด การเข้าถึงอาจเขียนเป็นง่ายและง่ายต่อการเข้าใจ ไม่มีพื้นที่จะสูญเสียกับเอสทีซีมุมมองและมุมมองยังคงเป็นปัจจุบันเสมออีกชั้น ecting เนื้อหาของตัวแปรตารางนักเรียนและการเรียน SQL ปฏิบัติต่อมุมมองที่ตรงตามที่ให้การปฏิบัติต่อตัวแปรตารางเท่าที่ดึงความกังวล นอกจากนี้เรายังสามารถมอบหมายสิทธิ์เลือกไปยังมุมมองในตรงทางเดียวกับที่เราทำสำหรับตัวแปรตาราง ตัวอย่างเช่นหากผู้ใช้สร้างมุมมองที่จอร์จเอสทีซีแล้วเขาสามารถให้สิทธิเลือกเพื่อแวนด้าโดยการเขียน:
ทุนเลือกใน STC เพื่อแวนด้า;
พิจารณาในขณะนี้ตัวอย่างของมุมมองอื่น: ตัวอย่าง 5.23.2 SNA มุมมองที่มีจำนวนนักเรียน และชื่อของนักเรียนที่สามารถสร้างขึ้นโดย:
สร้างมุมมอง SNA เป็น stno เลือกชื่อจากนักเรียน
วัตถุประสงค์ของมุมมองนี้คือการประกันความเป็นส่วนตัวให้กับนักเรียน ผู้ใช้ที่มีการเข้าถึงเฉพาะมุมมองนี้สามารถดึงข้อมูลจำนวนนักเรียนและชื่อของนักเรียน แต่ไม่ได้อยู่ของนักเรียน มีการตั้งดิ ff พื้นฐานระหว่างมุมมองที่นำมาใช้ในตัวอย่าง 5.23.1 และ 5.23.2 เป็นและนี้หมายถึงวิธีการที่ทั้งสองมุมมองที่มีพฤติกรรมเกี่ยวกับการปรับปรุง สมมติว่าผู้ใช้มีความประสงค์จะใส่คู่ (7799, 'เจนโจนส์) ในมุมมอง SNA ผู้ใช้อาจไม่สนใจทั้งหมดความจริงที่ว่า SNA ไม่ตัวแปรตารางฐาน ในทางตรงกันข้าม, อี ff ect บนฐานตัวแปรตารางแทรกนี้จะถูกกำหนดอย่างแจ่มแจ้ง: แทรกระบบในนักเรียนตัวแปรตาราง tuple (7799, 'เจนโจนส์', null, null, null) ในทางกลับกันเราไม่สามารถแทรก tuple ในทางที่มีความหมายในมุมมอง STC นำมาใช้ในตัวอย่าง 5.23.1 อันที่จริงถ้าเราพยายามที่จะแทรกคู่ (s ค) ในเอสทีซีแล้วเรามีให้กับสายตะวันออกเฉียงเหนือจ ff ect แทรกนี้บนตัวแปรตารางฐาน นี้จะชัดเจน
156 SQL - ภาษาเชิงสัมพันธ์
เป็นไปไม่ได้เราไม่ทราบว่าจำนวนนักเรียนเป็นสิ่งที่ไอออนบวกสายการระบุของผู้สอนคือ ฯลฯ SQL ห้ามผู้ใช้สามารถอัปเดตขึ้นอยู่กับมุมมองมากกว่าหนึ่งตาราง (เช่นเอสทีซีเป็น) แม้ว่าการปรับปรุงดังกล่าวจะมีความชัดเจนทาง e ff ect ตัวแปรตารางฐานกฎนี้ปฏิเสธใด ๆ การปรับปรุงดังกล่าว เพียงมุมมองบางอย่างขึ้นอยู่กับว่าหนึ่งตัวแปรตารางสามารถปรับปรุงได้ มันเป็นความรับผิดชอบของผู้ดูแลระบบฐานข้อมูลที่จะกำหนดให้ผู้ใช้สิทธิในการปรับปรุงมุมมองเฉพาะในกรณีที่เห็นว่าสามารถปรับปรุงได้ ถ้ามุมมองที่สามารถปรับปรุงได้แล้วพฤติกรรมของมันจะค่อนข้างดิ ff erent จากตัวแปรตารางฐานที่มุมมองที่ถูกสร้างขึ้น การปรับปรุงที่เกิดขึ้นกับมุมมองที่อาจก่อให้เกิดสิ่งอันดับหนึ่งหรือหลายที่จะหายไปจากมุมมองเมื่อใดก็ตามที่เราเรียก tuples ของมุมมอง ตัวอย่าง 5.23.3 พิจารณามุมมอง uppergr นิยามโดย:
สร้าง UPPERGR มุมมองเป็น * เลือกจากการเรียนที่คะแนน> 75;
ถ้าเราต้องการที่จะตรวจสอบ tuples ที่ตอบสนองความ nition Fi ของมุมมองที่เราใช้ในการก่อสร้าง:
* เลือกจาก UPPERGR;
ว่าผลตอบแทน ผล:
STNO EMPNO CNO SEM ชั้นปี ---------- ----------- ----- ------ --------- - --------- 2661 019 cs110 FALL 1999 80 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100 3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 ฤดูใบไม้ร่วง 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 CS310 SPRING 2001 100
ก่อสร้างปรับปรุง:
ปรับปรุง UPPERGR ชุดชั้นประถมศึกษาปี 70 = ที่ stno = '2661' และ empno = '019' และ CNO = 'cs110' และ SEM = 'FALL' และในปี = 1999;
ทำให้แถวสายแรกหายไปเพราะมันไม่พอไฟ es nition เด Fi ในมุมมองของ อันที่จริงถ้าเราใช้อีกครั้งการค้นหาเดียวกันใน UPPERGR เราได้รับ:
STNO EMPNO CNO SEM ชั้นปี ---------- ----------- ----- --- --- ---------- --------- 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100
5.23 ครั้งใน SQL 157
3566 019 cs240 SPRING 2,000 100 2,415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 ฤดูใบไม้ร่วง 2000 90 3566 019 cs210 ฤดูใบไม้ร่วง 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 CS310 SPRING 2001 100
ในการกอบกู้เนื้อหาก่อนหน้าของการเรียน เราสามารถใช้การปรับปรุง:
การปรับปรุง UPPERGR ชุดชั้นประถมศึกษาปี 80 = ที่ stno = '2661' และ empno = '019' และ CNO = 'cs110' และ SEM = 'FALL' และในปี = 1999;
ไวยากรณ์มาตรฐานของการสร้างมุมมองช่วยให้เรา ที่จะใช้ประโยคที่มีตัวเลือกการตรวจสอบ เมื่อคำสั่งนี้จะใช้การแทรกทุกคนและการปรับปรุงทำผ่านมุมมองที่เอ็ด Fi Veri เพื่อให้แน่ใจว่า tuple แทรกผ่านมุมมองของจริงจะปรากฏในมุมมองและการปรับปรุงของแถวในมุมมองไม่ก่อให้เกิดแถวที่จะหายไปจากมุมมอง . ไวยากรณ์ของสร้างมุมมองคือ:
สร้างมุมมองมุมมองเป็น subselect [มีตัวเลือกในการตรวจสอบ] วีมุมมองสามารถลดลงจากฐานข้อมูลโดยใช้โครงสร้าง
แบบเลื่อนดู V;
ถ้าเราวางตัวแปรตารางจากฐานข้อมูลแล้วมุมมองทั้งหมดขึ้นอยู่กับว่า ตารางจะลดลงโดยอัตโนมัติ ถ้าเราวางมุมมองแล้วมุมมองอื่น ๆ ทั้งหมดที่ใช้มุมมองที่เราลดลงจะลดลงนอกจากนี้ยังมี ครั้งเป็นเครื่องมือที่มีประโยชน์ในการดำเนินการ generalizations สมมติว่าเราเริ่มก่อสร้างของฐานข้อมูลจากวิทยาลัยตัวแปรตารางที่มีอยู่ระดับปริญญาตรีและบัณฑิตที่ถ่ายแบบชุดของหน่วยงานที่มีชื่อเดียวกันที่
มุ่งหน้า (นักศึกษาปริญญาตรี) = ชื่อเมือง addr stno รัฐซิปหัวข้อสำคัญ (ผู้สำเร็จการศึกษา) = ชื่อ addr stno เมืองซิปรัฐ qualdate
จากนั้นนักเรียนตัวแปรตารางจะได้รับในฐานะที่เป็นมุมมองที่สร้างขึ้นจากก่อนหน้านี้สองตัวแปรตารางฐานโดยการ
สร้างมุมมองที่เป็นนักเรียนเลือกชื่อ stno addr ซิปเมืองรัฐจาก U
การแปล กรุณารอสักครู่..
5.22 เข้าถึงสิทธิ 153
ตัวอย่าง 5.21.5 ต่อไปนี้ลบขจัดแถวของตารางกำหนด :
ลบจากมอบหมาย ;
ไวยากรณ์ของลบ : ลบจากตารางชื่อ [ ]
wherecondition 5.22 สิทธิการเข้าถึงสิทธิ์การกำหนดสิทธิ์การเข้าถึงให้กับผู้ใช้ เพื่อมอบสิทธิ์การเข้าถึงให้กับผู้ใช้อื่น ๆ ผู้ใช้จะต้อง " เอง " สิทธิเหล่านี้ ตั้งค่าสิทธิ์การเข้าถึงรวมถึงเลือก , แทรก , update ,และลบและหมายถึงสิทธิ์ของการดำเนินการแต่ละงานเหล่านี้บนโต๊ะ เพิ่มเติมการปรับปรุงสามารถ จำกัด การกาจึง C คอลัมน์ ทั้งหมดนี้ จะได้รับสิทธิ์การเข้าถึงเพื่อสร้างตารางอัตโนมัติ ผู้สร้างในการเปิดอาจให้สิทธิ์การเข้าถึงให้กับผู้ใช้อื่น ๆหรือกับผู้ใช้ทั้งหมด ( เขตใน SQL ที่เป็นสาธารณะ )มาตรฐาน SQL envisions กลไกที่สามารถจำกัดการมากเกินไปของสิทธิการเข้าถึง คือ ผู้ใช้อาจได้รับเลือกขวามี หรือ ไม่มีสิทธิที่จะให้สิทธิ์นี้กับคนอื่น โดยการกระทำของเขา 5.22.1
ตัวอย่างสมมติว่าผู้ใช้อเล็กซ์เป็นเจ้าของโต๊ะเรียนและตั้งใจที่จะให้สิทธิ์นี้กับผู้ใช้ที่ชื่อปีเตอร์ ผู้ใช้สามารถบรรลุนี้โดย
อเล็กซ์ให้เลือกในหลักสูตรปีเตอร์
ตอนนี้ ปีเตอร์ มีสิทธิที่จะสอบถามตารางหลักสูตร แต่เขาไม่อาจเผยแพร่สิทธินี้ให้กับผู้ใช้ เอลลี่ เพื่อให้มันเกิดขึ้น อเล็กซ์ จะต้องใช้คำสั่ง :
ให้เลือกในหลักสูตรเพื่อให้ปีเตอร์กับตัวเลือก
ตัวอย่าง 5.22.2 ถ้าปีเตอร์เจ้าของโต๊ะนักเรียน แล้วเขาจะมอบสิทธิในการ query ตารางและคอลัมน์ขวาบาปของเรา ,เมืองและซิปกับเอลลี่โดยใช้คำสั่ง :
ให้เลือก Update ( บาป , เมือง , รหัสไปรษณีย์ ) ในนักเรียนเอลลี่
ไวยากรณ์มาตรฐาน แกรนท์ :
154 SQL - สัมพันธ์ภาษา
{ } { priv สิทธิ์ priv , | ทั้งหมด [ สิทธิพิเศษ ] } ใน { [ ตาราง ] tablename tablename } , husername } { ผู้ใช้ | publici [ ตัวเลือก ] ที่นี่มีประทาน PRIV มีไวยากรณ์ : hselect | แทรก | ลบ | ปรับปรุง [ { ( แอตทริบิวต์ ,แอตทริบิวต์ } ) ] ฉันสามารถเพิกถอนสิทธิ์การยกเลิกสร้าง ซึ่งเป็นคุณลักษณะของ SQL มาตรฐาน ตัวอย่าง ถ้าปีเตอร์ ประสงค์จะเพิกถอนเอลลี่สิทธิพิเศษเพื่อปรับปรุงตารางนักเรียน เขาอาจเขียน :
ยกเลิกการปรับปรุง ( บาป , เมือง , รหัสไปรษณีย์ ) นักเรียนจากเอลลี่
ไวยากรณ์มาตรฐานสำหรับคำสั่งนี้จะถูก | PRIV } { { priv , ทั้งหมด [ พิเศษ ] } ใน { [ ตาราง ] tablename tablename , จาก husername { } ,ชื่อ } | publici
5.23 ในมุมมอง SQL
มุมมองเสมือนตารางตัวแปร ซึ่งหมายความว่าใน SQL มุมมองเป็นอ้างอิงสำหรับวัตถุประสงค์การสืบค้นในตรงทางเดียวกันคือตัวแปรตารางอ้างอิง . แต่ ดิ ff erence นั่นดูไม่มีตัวตนทางกายภาพ มันมีอยู่แค่ เดอ จึง nition ในฐานข้อมูลแคตตาล็อก เราดู " จริง " ตัวแปรตาราง ( นั่นคือตัวแปรตารางที่มีการดำรงอยู่ทางกายภาพในฐานข้อมูล ) เป็นฐานตารางตัวแปร ความคิดเห็นที่ได้รับการสนับสนุนทั้งในประเทศและ sqlplus ใน SQL แต่ไม่ใช่ในรุ่นปัจจุบัน ( 4.1 ) ของ MySQL แสดงให้เห็นถึงความคิด มุมมอง ให้เราพิจารณาตัวอย่างต่อไปนี้ ตัวอย่าง 5.23.1 สมมติว่าเราเขียน :
สร้างวิว STC เป็นเลือก students.name grades.cno จาก , นักเรียนเกรดที่ students.stno = เกรด stno ;
ที่มีอยู่โดยเลือกสร้างนี้สร้างวิวเรียกคู่ของตัวเลขและชื่อนักเรียนหลักสูตรที่นักเรียนที่มีชื่อเป็น S ได้ลงทะเบียนเรียน C เมื่อคำสั่งนี้ดำเนินการโดย SQL , ไม่มีข้อมูลการใช้สถานที่ ระบบฐานข้อมูลเพียงแค่ร้านค้านี้ เดอ จึง nition ในแคตตาล็อกเดอ จึง nition ของมุมมองที่ STC กลายเป็นวัตถุถาวรที่เป็นวัตถุที่มีอยู่หลังจากการปฏิสัมพันธ์ของเรากับ DBMS ได้หยุด . จากจุดของผู้ใช้มุมมองแนวคิดที่ถือว่า STC เหมือนตัวแปรตารางใด ๆอื่น ๆ สมมติว่าตัวอย่างเช่นที่เราต้องการดึงชื่อของนักเรียนที่ได้รับ cs110 . ในกรณีนี้มันซูffi cient เขียนแบบสอบถาม : 5.23 ในมุมมอง SQL 155
เลือกชื่อจาก stc ที่ CNO = 'cs110 ' ;
ในความเป็นจริง , SQL รวมนี้เลือกวลีที่มีแบบสอบถามจะแสดงและรัน Modi จึงเอ็ดแบบสอบถาม :
เลือก students.name จากนักเรียน เกรดที่ students.stno = grades.stno และ grades.cno = 'cs110 ' ;
ตัวอย่างก่อนหน้านี้แสดงให้เห็นว่าในมุมมอง SQL บทบาทคล้ายกับ บทบาทที่เล่นโดยแมโครในการเขียนโปรแกรมภาษามุมมองที่สำคัญสำหรับการรักษาความปลอดภัยข้อมูล ผู้ใช้ที่ต้องมีการเข้าถึงเพียงรายชื่อของนักเรียนและหลักสูตรที่พวกเขาจะต้องการที่จะทราบของการดำรงอยู่ของ STC . หากผู้ใช้จะได้รับอนุญาตให้ใช้เพียงเลือกสร้าง จากนั้นผู้ใช้สามารถละเว้นไม่ว่า STC เป็นตารางหรือมุมมองคอน จึง dential ข้อมูล ( เช่น เกรดได้ C วิชากาจึงสามารถการป้องกันอย่างสมบูรณ์ในลักษณะนี้ นอกจากนี้ ข้อมูลที่ จำกัด การเข้าถึงของผู้ใช้นี้อาจเขียนเป็นง่ายและง่ายต่อการเข้าใจ ไม่มีพื้นที่สูญเปล่ากับมุมมอง STC และมุมมองยังคงเป็นปัจจุบันเสมอ Re fl ecting เนื้อหาของตัวแปรและตารางนักเรียนเกรดมุมมอง SQL ถือว่าตรงตามที่ถือว่าตัวแปรตาราง เท่าที่สืบค้นข้อมูลที่เกี่ยวข้อง นอกจากนี้เรายังสามารถมอบสิทธิพิเศษ เลือกมุมมองในแบบเดียวกับที่เราทำสำหรับตัวแปรของตาราง ตัวอย่างเช่นหากผู้ใช้จอร์จ สร้างมุมมองที่ STC แล้วเขาจะให้เลือกใช่ แวนด้า โดยเขียน :
ให้เลือกที่ STC กับแวนด้า ;
พิจารณาอีกตัวอย่างของมุมมอง : ตัวอย่าง 5.23 .2 มุมมอง SNA ที่มีจำนวนนักเรียนและรายชื่อนักเรียนที่สามารถสร้างขึ้นโดย :
สร้างวิว SNA เป็นเลือก stno ชื่อจากนักศึกษา
วัตถุประสงค์ของมุมมองนี้เพื่อประกันความเป็นส่วนตัวให้กับนักเรียน ผู้ใช้ที่สามารถเข้าถึงได้เพียง มุมมองนี้สามารถเรียกนักเรียนหมายเลขและชื่อของนักเรียน แต่ไม่ใช่ที่อยู่ของนักเรียน
ตัวอย่าง 5.21.5 ต่อไปนี้ลบขจัดแถวของตารางกำหนด :
ลบจากมอบหมาย ;
ไวยากรณ์ของลบ : ลบจากตารางชื่อ [ ]
wherecondition 5.22 สิทธิการเข้าถึงสิทธิ์การกำหนดสิทธิ์การเข้าถึงให้กับผู้ใช้ เพื่อมอบสิทธิ์การเข้าถึงให้กับผู้ใช้อื่น ๆ ผู้ใช้จะต้อง " เอง " สิทธิเหล่านี้ ตั้งค่าสิทธิ์การเข้าถึงรวมถึงเลือก , แทรก , update ,และลบและหมายถึงสิทธิ์ของการดำเนินการแต่ละงานเหล่านี้บนโต๊ะ เพิ่มเติมการปรับปรุงสามารถ จำกัด การกาจึง C คอลัมน์ ทั้งหมดนี้ จะได้รับสิทธิ์การเข้าถึงเพื่อสร้างตารางอัตโนมัติ ผู้สร้างในการเปิดอาจให้สิทธิ์การเข้าถึงให้กับผู้ใช้อื่น ๆหรือกับผู้ใช้ทั้งหมด ( เขตใน SQL ที่เป็นสาธารณะ )มาตรฐาน SQL envisions กลไกที่สามารถจำกัดการมากเกินไปของสิทธิการเข้าถึง คือ ผู้ใช้อาจได้รับเลือกขวามี หรือ ไม่มีสิทธิที่จะให้สิทธิ์นี้กับคนอื่น โดยการกระทำของเขา 5.22.1
ตัวอย่างสมมติว่าผู้ใช้อเล็กซ์เป็นเจ้าของโต๊ะเรียนและตั้งใจที่จะให้สิทธิ์นี้กับผู้ใช้ที่ชื่อปีเตอร์ ผู้ใช้สามารถบรรลุนี้โดย
อเล็กซ์ให้เลือกในหลักสูตรปีเตอร์
ตอนนี้ ปีเตอร์ มีสิทธิที่จะสอบถามตารางหลักสูตร แต่เขาไม่อาจเผยแพร่สิทธินี้ให้กับผู้ใช้ เอลลี่ เพื่อให้มันเกิดขึ้น อเล็กซ์ จะต้องใช้คำสั่ง :
ให้เลือกในหลักสูตรเพื่อให้ปีเตอร์กับตัวเลือก
ตัวอย่าง 5.22.2 ถ้าปีเตอร์เจ้าของโต๊ะนักเรียน แล้วเขาจะมอบสิทธิในการ query ตารางและคอลัมน์ขวาบาปของเรา ,เมืองและซิปกับเอลลี่โดยใช้คำสั่ง :
ให้เลือก Update ( บาป , เมือง , รหัสไปรษณีย์ ) ในนักเรียนเอลลี่
ไวยากรณ์มาตรฐาน แกรนท์ :
154 SQL - สัมพันธ์ภาษา
{ } { priv สิทธิ์ priv , | ทั้งหมด [ สิทธิพิเศษ ] } ใน { [ ตาราง ] tablename tablename } , husername } { ผู้ใช้ | publici [ ตัวเลือก ] ที่นี่มีประทาน PRIV มีไวยากรณ์ : hselect | แทรก | ลบ | ปรับปรุง [ { ( แอตทริบิวต์ ,แอตทริบิวต์ } ) ] ฉันสามารถเพิกถอนสิทธิ์การยกเลิกสร้าง ซึ่งเป็นคุณลักษณะของ SQL มาตรฐาน ตัวอย่าง ถ้าปีเตอร์ ประสงค์จะเพิกถอนเอลลี่สิทธิพิเศษเพื่อปรับปรุงตารางนักเรียน เขาอาจเขียน :
ยกเลิกการปรับปรุง ( บาป , เมือง , รหัสไปรษณีย์ ) นักเรียนจากเอลลี่
ไวยากรณ์มาตรฐานสำหรับคำสั่งนี้จะถูก | PRIV } { { priv , ทั้งหมด [ พิเศษ ] } ใน { [ ตาราง ] tablename tablename , จาก husername { } ,ชื่อ } | publici
5.23 ในมุมมอง SQL
มุมมองเสมือนตารางตัวแปร ซึ่งหมายความว่าใน SQL มุมมองเป็นอ้างอิงสำหรับวัตถุประสงค์การสืบค้นในตรงทางเดียวกันคือตัวแปรตารางอ้างอิง . แต่ ดิ ff erence นั่นดูไม่มีตัวตนทางกายภาพ มันมีอยู่แค่ เดอ จึง nition ในฐานข้อมูลแคตตาล็อก เราดู " จริง " ตัวแปรตาราง ( นั่นคือตัวแปรตารางที่มีการดำรงอยู่ทางกายภาพในฐานข้อมูล ) เป็นฐานตารางตัวแปร ความคิดเห็นที่ได้รับการสนับสนุนทั้งในประเทศและ sqlplus ใน SQL แต่ไม่ใช่ในรุ่นปัจจุบัน ( 4.1 ) ของ MySQL แสดงให้เห็นถึงความคิด มุมมอง ให้เราพิจารณาตัวอย่างต่อไปนี้ ตัวอย่าง 5.23.1 สมมติว่าเราเขียน :
สร้างวิว STC เป็นเลือก students.name grades.cno จาก , นักเรียนเกรดที่ students.stno = เกรด stno ;
ที่มีอยู่โดยเลือกสร้างนี้สร้างวิวเรียกคู่ของตัวเลขและชื่อนักเรียนหลักสูตรที่นักเรียนที่มีชื่อเป็น S ได้ลงทะเบียนเรียน C เมื่อคำสั่งนี้ดำเนินการโดย SQL , ไม่มีข้อมูลการใช้สถานที่ ระบบฐานข้อมูลเพียงแค่ร้านค้านี้ เดอ จึง nition ในแคตตาล็อกเดอ จึง nition ของมุมมองที่ STC กลายเป็นวัตถุถาวรที่เป็นวัตถุที่มีอยู่หลังจากการปฏิสัมพันธ์ของเรากับ DBMS ได้หยุด . จากจุดของผู้ใช้มุมมองแนวคิดที่ถือว่า STC เหมือนตัวแปรตารางใด ๆอื่น ๆ สมมติว่าตัวอย่างเช่นที่เราต้องการดึงชื่อของนักเรียนที่ได้รับ cs110 . ในกรณีนี้มันซูffi cient เขียนแบบสอบถาม : 5.23 ในมุมมอง SQL 155
เลือกชื่อจาก stc ที่ CNO = 'cs110 ' ;
ในความเป็นจริง , SQL รวมนี้เลือกวลีที่มีแบบสอบถามจะแสดงและรัน Modi จึงเอ็ดแบบสอบถาม :
เลือก students.name จากนักเรียน เกรดที่ students.stno = grades.stno และ grades.cno = 'cs110 ' ;
ตัวอย่างก่อนหน้านี้แสดงให้เห็นว่าในมุมมอง SQL บทบาทคล้ายกับ บทบาทที่เล่นโดยแมโครในการเขียนโปรแกรมภาษามุมมองที่สำคัญสำหรับการรักษาความปลอดภัยข้อมูล ผู้ใช้ที่ต้องมีการเข้าถึงเพียงรายชื่อของนักเรียนและหลักสูตรที่พวกเขาจะต้องการที่จะทราบของการดำรงอยู่ของ STC . หากผู้ใช้จะได้รับอนุญาตให้ใช้เพียงเลือกสร้าง จากนั้นผู้ใช้สามารถละเว้นไม่ว่า STC เป็นตารางหรือมุมมองคอน จึง dential ข้อมูล ( เช่น เกรดได้ C วิชากาจึงสามารถการป้องกันอย่างสมบูรณ์ในลักษณะนี้ นอกจากนี้ ข้อมูลที่ จำกัด การเข้าถึงของผู้ใช้นี้อาจเขียนเป็นง่ายและง่ายต่อการเข้าใจ ไม่มีพื้นที่สูญเปล่ากับมุมมอง STC และมุมมองยังคงเป็นปัจจุบันเสมอ Re fl ecting เนื้อหาของตัวแปรและตารางนักเรียนเกรดมุมมอง SQL ถือว่าตรงตามที่ถือว่าตัวแปรตาราง เท่าที่สืบค้นข้อมูลที่เกี่ยวข้อง นอกจากนี้เรายังสามารถมอบสิทธิพิเศษ เลือกมุมมองในแบบเดียวกับที่เราทำสำหรับตัวแปรของตาราง ตัวอย่างเช่นหากผู้ใช้จอร์จ สร้างมุมมองที่ STC แล้วเขาจะให้เลือกใช่ แวนด้า โดยเขียน :
ให้เลือกที่ STC กับแวนด้า ;
พิจารณาอีกตัวอย่างของมุมมอง : ตัวอย่าง 5.23 .2 มุมมอง SNA ที่มีจำนวนนักเรียนและรายชื่อนักเรียนที่สามารถสร้างขึ้นโดย :
สร้างวิว SNA เป็นเลือก stno ชื่อจากนักศึกษา
วัตถุประสงค์ของมุมมองนี้เพื่อประกันความเป็นส่วนตัวให้กับนักเรียน ผู้ใช้ที่สามารถเข้าถึงได้เพียง มุมมองนี้สามารถเรียกนักเรียนหมายเลขและชื่อของนักเรียน แต่ไม่ใช่ที่อยู่ของนักเรียน
การแปล กรุณารอสักครู่..
ภาษาอื่น ๆ
การสนับสนุนเครื่องมือแปลภาษา: กรีก, กันนาดา, กาลิเชียน, คลิงออน, คอร์สิกา, คาซัค, คาตาลัน, คินยารวันดา, คีร์กิซ, คุชราต, จอร์เจีย, จีน, จีนดั้งเดิม, ชวา, ชิเชวา, ซามัว, ซีบัวโน, ซุนดา, ซูลู, ญี่ปุ่น, ดัตช์, ตรวจหาภาษา, ตุรกี, ทมิฬ, ทาจิก, ทาทาร์, นอร์เวย์, บอสเนีย, บัลแกเรีย, บาสก์, ปัญจาป, ฝรั่งเศส, พาชตู, ฟริเชียน, ฟินแลนด์, ฟิลิปปินส์, ภาษาอินโดนีเซี, มองโกเลีย, มัลทีส, มาซีโดเนีย, มาราฐี, มาลากาซี, มาลายาลัม, มาเลย์, ม้ง, ยิดดิช, ยูเครน, รัสเซีย, ละติน, ลักเซมเบิร์ก, ลัตเวีย, ลาว, ลิทัวเนีย, สวาฮิลี, สวีเดน, สิงหล, สินธี, สเปน, สโลวัก, สโลวีเนีย, อังกฤษ, อัมฮาริก, อาร์เซอร์ไบจัน, อาร์เมเนีย, อาหรับ, อิกโบ, อิตาลี, อุยกูร์, อุสเบกิสถาน, อูรดู, ฮังการี, ฮัวซา, ฮาวาย, ฮินดี, ฮีบรู, เกลิกสกอต, เกาหลี, เขมร, เคิร์ด, เช็ก, เซอร์เบียน, เซโซโท, เดนมาร์ก, เตลูกู, เติร์กเมน, เนปาล, เบงกอล, เบลารุส, เปอร์เซีย, เมารี, เมียนมา (พม่า), เยอรมัน, เวลส์, เวียดนาม, เอสเปอแรนโต, เอสโทเนีย, เฮติครีโอล, แอฟริกา, แอลเบเนีย, โคซา, โครเอเชีย, โชนา, โซมาลี, โปรตุเกส, โปแลนด์, โยรูบา, โรมาเนีย, โอเดีย (โอริยา), ไทย, ไอซ์แลนด์, ไอร์แลนด์, การแปลภาษา.
- น่ารักที่สุด รักและคิดถึง
- ฉันไม่ชอบเธอทำอะไรแบบเด็กๆ
- notion
- from GRADESgroup by stno;which generates
- ฉันเขียนจดหมายถึงเพื่อนสวัสดีเพื่อนรัก เ
- ขอบคุณที่ให้ความกรณาในครั้งนี้
- Good
- กูเกิ้ลสามารถให้ข้อมูลที่ครอบคลุมทุกเรื่
- ขี้โมโห
- มีการพัฒนา
- is systematic collection of local
- Test every week
- did you get lots of flowers for Valentin
- pairs of instructors’ names for instruct
- ผมเห็นเขาเมื่อคืน
- เคี้ยว
- what's your ideal job
- Dear Jacek
- To do for you
- โครง
- shipment delivery
- Complaints
- ฉันรู้จักพวกเขา เพราะเพื่อนของฉันแนะนำมา
- I feel so sorry that i make you cry.
