Wiley Microsoft SQL Server 2005 For Dummies 978-0-7645-7755-0 ユーザーズマニュアル
製品コード
978-0-7645-7755-0
exposed on the Internet. SQL Server has to give you the tools to keep your
data safe in order to allow the right people to access data that you want them
to access and to stop other people from accessing data that you don’t want
them to access.
data safe in order to allow the right people to access data that you want them
to access and to stop other people from accessing data that you don’t want
them to access.
I describe security in SQL Server 2005 in more detail in Chapter 11.
System catalog security
The system catalog in SQL Server 2005 consists of views of the underlying
system data structures. Users do not see any underlying tables, so unskilled
or malicious users can’t change or otherwise corrupt them. This stops you or
anyone else from damaging the core structures on which your SQL Server
installation depends.
system data structures. Users do not see any underlying tables, so unskilled
or malicious users can’t change or otherwise corrupt them. This stops you or
anyone else from damaging the core structures on which your SQL Server
installation depends.
Password policy enforcement
When installed on Windows 2003 Server, you can apply to SQL Server 2005
any Windows password policy that you have in effect. You can enforce poli-
cies for password expiration and strength on SQL Server 2005 in exactly the
same way as for Windows logins. Windows 2000 Server does not support this.
any Windows password policy that you have in effect. You can enforce poli-
cies for password expiration and strength on SQL Server 2005 in exactly the
same way as for Windows logins. Windows 2000 Server does not support this.
You can turn off (or on, in some cases) password policy enforcement for indi-
vidual logins. For example, you can turn off password policy enforcement
when you’re using an application with built-in authentication information that
you can’t change.
vidual logins. For example, you can turn off password policy enforcement
when you’re using an application with built-in authentication information that
you can’t change.
I show you how to alter password enforcement in Chapter 11.
Schema and user separation
SQL Server 2000 had no concept of a schema: A user owned a database object.
So if a user User1 created an object called myTable, then the object’s qualified
name was User1.myTable. If User1 is deleted — for example, when the indi-
vidual leaves the company — you needed to change the name of the object,
which caused problems for applications that depended on the name of the
object for data access. In SQL Server 2005, a user can create a schema, which
in turn contains database objects, which has a different name from the user.
User1
So if a user User1 created an object called myTable, then the object’s qualified
name was User1.myTable. If User1 is deleted — for example, when the indi-
vidual leaves the company — you needed to change the name of the object,
which caused problems for applications that depended on the name of the
object for data access. In SQL Server 2005, a user can create a schema, which
in turn contains database objects, which has a different name from the user.
User1
can create a schema called HR. and create an object called myTable.
You refer to that object as HR.myTable. So if User1 leaves the company, you
can leave the schema name unchanged, which means you can leave your appli-
cation code unchanged because the object is still called HR.myTable.
can leave the schema name unchanged, which means you can leave your appli-
cation code unchanged because the object is still called HR.myTable.
22
Part I: SQL Server 2005: An Overview
06_577557 ch02.qxp 12/20/05 9:43 PM Page 22