Title: SYSTEMS AND METHODS THAT PROVIDE ROW LEVEL SECURITY FOR DATABASE TABLE ROW
TECHNICAL FIELD
The present invention generally relates to databases, and more particularly to systems and methods that provide a row level security model in a relational database.
BACKGROUND OF THE INVENTION
With increasing popularity of computers and electronic databases, more and more data is being stored in databases. Such data can include personal (e.g., bank account and social security numbers) and sensitive information (e.g., medical records) and may not be backed up via hard copies. Therefore, security related to such databases and data stored therein is growing in importance. However, many of today's security techniques can be breached, for example, through wholes and/or by hackers. Thus, there is a.need for database security improvements.
DESCRIPTION OF THE INVENTION
The present invention provides systems and methods that specify row level database security. In general, databases store data in structured format, wherein a set of entities with the same structure can be referred to as a table and respective entities can be referred to as table rows. In addition, respective rows can include fields that can be referred to as columns. One or more entities (e.g., a subset, a set and more than one set) of a table can be accessed utilizing a database processing language such as SQL (Structured Query Language). Such languages can be utilized to specify one or more tables as the source of data such that returned data comprises data from the specified table(s) sources when condition is satisfied. The present invention can be employed with essentially any database programming interface (e.g., SQL programming language) to cluster one or more sets of rows with similar security characteristics and treat them as a named expression, wherein clustered tables and/or rows can be accessed based on associated row-level security. Such security can provide advantages for databases (e.g., relational) that enable a user to perform associative queries over respective tables,
wherein queries can be improved (e.g., optimized) based on access paths and/or indices present on the tables.
In order to associate security with a row, respective rows need to be individually identified. In many instances, database programming languages do not account for identifying respective rows in a table with an address. In some cases, a primary key can be utilized as an address for a table. However, not every table has an associated primary key. Furthermore, associating security such that respective rows in a table can be individually identified can lead to data management problems since there may be a large number of rows in a table. Moreover, storing security information within respective rows can be inefficient and consume space, especially if the values stored in respective rows are not very large. In addition, many database programming languages prescribe a syntax by which securitycan be specified on a table or one or more of its constituent columns.
The novel systems and methods of the present invention can be utilized to mitigate the aforementioned shortcoming by providing syntax for row level security, wherein database security can be associated with a row(s), a column(s) and/or a table(s) via one or more programming statements. In one example, this functionality is provided via one or more table expressions (e.g., a named expression of a table). Such expressions can include an arbitrary Boolean expression defined over but not restricted to the columns of the table and/or any other contextual data or data in another table. Rows in the table that return "true" when evaluated against the expression are said to "satisfy" the security expression. It is understood that that it is possible to write a security expression that satisfies all, more than one, one or no rows in the table. A security expression can also be referred to as an alias for a set of rows with similar security characteristics that embodies a horizontal segment of a table, wherein an arbitrary number of expressions can be defined on the table and a similar row can satisfy an arbitrary number of security expressions defined on the table.
In order for a user to see a row and/or query and perform an operation (e.g., query) thereon, the user needs.'lo be granted permission to one or more security expressions that the row satisfies and not be denied that permission on any security expressions the row satisfies. This permission can be obtained as an outcome of a direct grant or indirectly through one or more user roles. For example, the following is an exemplary statement utilized to grant Userl security permission for row access: Grant select(where SalLimit) on Emp to Userl, wherein Grant is an instruction to provide permission, SalLimit is a security expression, Emp is a table, and Userl is the user granted permission. This statement can imply that Userl is allowed to see all rows in the Emp table that satisfies the SalLimit expression. In the absence of any other granted security expression, Userl would not be provided with access to any other row. In addition, any row that does not satisfy such conditions is rendered not visible to Userl. The following depicts another exemplary expression: Emp(id int, salary float), wherein the definition of a security expression can be: Create expression SalLimit on Emp As ( salary < 100000 ). It is noted that various other statements such as denial and/or revocation statements can be employed via corresponding security expressions. For example, the following statement grants both row and column permission in one statement: Grant select(where El, Coll) on T to U, wherein El is an expression defined'' on a table T, Coll is a column of table T and U is the user. Furthermore, there can be multiple grant, deny, and/or revoke statements, on the same table.
The grantee of such statements can be any principal-authorized in the database system, for example, as defined by the specification. When the user issues a query against a table enabled with row level security, the "where" clause of the query is augmented by grafting an expression composed out of the disjunction of the Boolean expressions that are granted, respective expressions conjuncted with the security principal to whom the grant is made. The conjunction of the complement of respective Boolean expressions denied is conjuncted to the disjunction, wherein the conjunction is conjuncted with the security principal to whom the deny is made.
Such security expressions can be tagged as part of a parse tree. Further, an expression can be defined to be safe if a.query optimizer determines that the expression cannot have side effects or throw exceptions resulting in the query to be aborted. By default, logical operations are safe and everything else is unsafe. In order to enable various other scenarios, a database administrator can attribute user-defined functions that are referenced in queries to be safe. The optimizer rules of predicate movement can be changed to ensure that only safe expressions can be pushed below security expressions when considering alternate plans; thereby guaranteeing that unless the database
administrator commits an error, all security expressions are evaluated before unsafe expressions specified as part of the query.
In general, a named expression behaves as a surrogate for essentially all rows that satisfy that expression. Thus, by utilizing this technique, one could express all rows in a table (e.g., the expression would be: (TRUE)) and/or respective rows when a primary key exists. In addition, virtually any number of security expressions can be defined on a table, and a single row can be satisfied by more than one expressions defined on the table. The foregoing provides a mechanism to cluster a set of rows with similar security characteristics and treat the set as a named expression.
EXAMPLE SECURITY EXPRESSION
The following depicts exemplary database table security expressions (e.g., restrictions or predicates) that can be employed in accordance with aspects of the subject invention. The depicted expressions include: CREATE EXPRESSION; DROP EXPRESSION; GRANT; REVOKE; and DENY. Such expressions, as well as other security expressions, can provide a finer or higher resolution for access control at the row level and is advantageous when employing, inter alia, a SELECT, an UPDATE, a DELETE, and/or an INSERT action on a table.
TE EXPRESSION
Predicates that are to be applied to a table to activate row level access control can be created using a DDL CREATE EXPRESSION. These predicates are given a name and can be subsequently applied to the table utilizing syntax (e.g., GDR) with the name of the expression.
Syntax:
CREATE EXPRESSION ON AS
()
This creates on table an expression as stipulated in and assigns it a name called . The current user is marked as the owner of the expression.
Restrictions:
• Sub-queries cannot be included
• Function calls can be included if an expression comprises references to
functions and the creator reference permissions on these functions.
• An expression must be given a name (expression_name)
• The expression_name must be unique.
Permissions:
Members of a db_ddladmin, a db_owner role, a sysadmin role, a table owner and users with FULL CONTROL permission at the database, schema and/or table level can have permission to create expressions on that table. In addition, users with ALTER ANY TABLE and/or. ALTER on the table have permission to create an expression on the table.
Example:
CREATE EXPRESSION My_Filter ON shipTable AS (ship_city='redmond' and order_num > 35)
DROP EXPRESSION
Predicates created using the CREATE EXPRESSION statement can subsequently be dropped using the DROP EXPRESSION statement.
Syntax:
DROP EXPRESSION ON
Restrictions:
An expression_name specified must already exist.
• The current user needs to be a member of a db_ddladmin, a db_owner and/or
a sysadmin role, an owner of the table on which the expression is identified, and/or have
FULL CONTROL and/or ALTER permission on the table to drop the expression.
• The expression generally can only be dropped if it is not currently being
utilized for establishing row level security on tables.
• If any restriction is violated, an error (e.g., "Expression may not exist or may
be in use or you do not have permission to execute this statement") can be returned.
GRANT Syntax:
GRANT
{
ALL [ PRIVILEGES ]
[ ( column | [,...n ])] ON {table \ view } ON { table view } [ ( column \ [,...// ])] ON { stored procedure \ extende_procedure } | ON { user_definedfunction }
} TO security_account [,...n ]
[ WITH GRANT OPTION j
]
[ AS { group | role } ]
The UPDATE permission can be prefixed with a BEFORE or an AFTER. The BEFORE or AFTER can only be specified if row level security is being specified. In general, BEFORE implies that the predicate applies to the pre image of the row; security is based on the current values in the row. AFTER implies that the security is based on the post image; the values utilized to update the row. The is the name of the expression (e.g., created earlier via CREATE EXPRESSION syntax) that is utilized to initiate the security restrictions.
Restrictions:
• An expression generally can only be dropped if it is not currently being
utilized for establishing row level security on tables.
• A GRANT has to be on a table (views and other objects are not supported)
• A permission applies at the table level (not column level).
• A WITH GRANT OPTION will be allowed when specifying row level
restrictions. However, further grants generally can only be made by the grantee on this
expression.
• must be a valid expression name that was already
specified through the CREATE EXPRESSION statement.
• A user issuing the GRANT needs to be the owner of the table or have full
control permissions on the table or member of a db owner, a b securityadmin and/or a
sys-admin role.
Example:
GRANT SELECT WHERE (Myfilter) ON Tablel TO RedMgrs GRANT BEFORE UPDATE WHERE (Filler2) ON Table2 TO public
REVOKE
Syntax:
REVOKE [ GRANT OPTION FOR ]
{
ALL [ PRIVILEGES ]
[BEFORE lAFTER] permission [WHERE([,....n])[

[( column /[,...n] )] ON { table view } [ON { able/ view } [ ( column / [ ,...n ] ) ] [ON { stored _procedure/ extended _procedure [ON { user_defined_function }
{TO / FROM }
security_account [,...n ] [CASCADE] [ AS { group \ role } ]
Where in addition to the normal definitions as explained in BOL: is the name for the security restriction that was applied earlier through a GRANT or a DENY, to the permission that is being revoked.
Restrictions:
• The must be a valid expression name already specified on
the table using an earlier GRANT or DENY for the particular permission being revoked.
• A column name or the expression being revoked can be specified.
• A CASCADE option will apply for REVOKE'S of expressions based
GRANTS or DENYS. This will have to be the same expression specified in an earlier
GRANT or DENY and a subset of rows defined by expressions already granted cannot be
revoked.
• For the REVOKE to succeed, the user needs to be a table owner or must have
FULL CONTROL permissions on the (able or a member of a db securityadmin, a
db_owner and/or a sysadmin role.
Example:
REVOKE SELECT WHERE (MyFiller) ON Tablel TO RedMgrs
DENY Syntax:
DENY
{
ALL [ PRIVILEGES
permission [WHERE (
[,....n)][
[ ( column | [,...n ])] ON {table \ view } | ON {table \ view } [ ( column \ [,...n])] | ON { stored_procedure \ extended_procedure } | ON { user_defined_function }
}
TO security_account[ ,...n] [CASCADE]
The is the name of the expression (created throug an earlier CREATE EXPRESSION syntax) that is used to bring about the security restrictions
Restrictions:
• A DENY is on a table.
• A permission applies at the table leve.
• The CASCADE option is allowed when specifying row level restrictions, and
this will deny at the first level and revoke at lower levels the exact same expression if
granted, but not any subset of it.
• The must be a valid expression name already specified
through the CREATE EXPRESSION statement.
• A user issuing the DENY needs to be the owner of the table or member of the
a db_owner, a db_securityadmin and/or a sysadmin role.
Example:
DENY SELECT WHERE (MyFiller) ON Table 1 TO BelvMgrs
Viewing the Expressions Applied on a Table:
The expressions can be include in a sysobjects object. A corresponding catalog view can reside in is sys.objects. A table owner(s) and a user(s) with FULL CONTROL and/or VIEW DEFINITION permission will be able to see the expressions that are applied on the table.

Row level Security Behavior:
When a query is issued against a table, it is augmented with predicates that have been applied at the table level to invoke the necessary security restrictions. When a SELECT is issued against the table, the query is internally augmented with all the predicates that have been applied on the table by virtue of GRANT SELECT or DENY SELECT statements. When an UPDATE is issued against the table, the query is internally augmented with all the BEFORE and UPDATE predicates applied to the table by virtue of the GRANT/DENY, UPDATE For BEFORE and SELECT statements. For BEFORE UPDATES, the restrictions specified in the predicates are based on the current values in the rows and not the updated values. AFTER, UPDATE and INSERT restrictions behave like constraints; they act on the after image of the update. It is only possible to update rows that the user currently has access to select. When a DELETE is issued, the query is augmented with the predicates applied to the table by virtue of the GRANT/DENY SELECT and DELETE statements. The user can only delete rows currently selected. The security expressions defined on the table are applied before any other predicate is applied; user predicates are pushed below all the security predicates in the evaluation tree.
If there are multiple security predicates, the predicates specified in the GRANTS are OR'd and the negative of respective predicates specified by virtue of DENY's are ANDed to these. In addition, table level or column level permissions can be set without row level security. With the introduction of row level security, the user has access to those rows with which explicit access has been granted. Thus, what a user sees in a particular table is an intersection of the column level and row level permissions. In order to allow for row level security, the table has to first be marked as such. This can be done using the ROW_SECUR1TY flag in the CREATE/ALTER TABLE syntax (e.g., ALTER TABLE SET ROW_SECURITY = ON). When the table has been enabled for row level security, the owner can determine, whether row level security applies to certain individual rows. This can be done through the use of predicates that grant access to one or more rows. The Exempt Row Security permission can also be utilized to achieve the same effect. This permission can ensure that none of the security predicates are applied to the query when the grantee issues one against the table, which achieves the effect of not
applying row level security, as row level security is only applied through the predicates. The Exempt Row Security permission is also useful in that it allows the owner to selectively decide who should receive row level security. It is to be appreciated that predicates can be applied to the table at any time; however, these will only be augmented to queries of users that do not have the ExemptRowSec permission.
Exempting row level security checks
As noted above, it can be useful to grant certain users the ability to query the table without augmenting the query with the predicates. In addition, it can be useful to temporarily disable row level security without having to add, remove and/or alter some or all predicates. This can be done by granting the ExemptRowSec permission. Table Owners, members of the db_owner and sysadmin roles and users with CONTROL permission have this permission by default.
Example 1: To exempt user! from row level security checks on Table T: GRANT ExemptRowSec ON T TO
When this statement is issued, user! \s queries to table T arc not augmented with any predicates. This permission can only be granted at the table level and not al the column level.
Trapping circular predicates
Since predicates can include calls to functions that in turn call other lables that could also have predicates defined on them, it is important to trap cases where there may be a circular loop. For example, if Table T has a predicate defined on it that is essentially a call to function F, which in turn queries Table T and Table S, the predicates can be applied on Table S, but not the predicates on table T (because the latter would cause an endless loop otherwise), and, thus, trapping such cases of circular predicates, but only when the number of hops in the circle is less than n, but where n is the same number used to trap circular dependencies for views.

CREATE TABLE Syntax:
CREATE TABLE
[ database_name.[ owner ]. \ owner. ] table_name ({< column_definition >
| column_name AS computed_column_expression
\ < table_constraint > ::= [ CONSTRAINT constraint_name ]}
[ { PRIMARY KEY | UNIQUE } [,...n ] )
[ ON {filegroup \ DEFAULT } ] [ TEXTIMAGE_ON {filegroup \ DEFAULT } ]
< column_definition > ::= { column_name data_type }
[COLLATE < colladon_name > ] [ [ DEFAULT constant_expression ]
| [ IDENTITY [ (seed, increment) [ NOT FOR REPLICATION ] ] ]
]
.[ ROWGUIDCOL] [<"column_constraint > ] [ ...n }
< column_constraint > ::= [ CONSTRAINT constraint_name ]
{[ NULL | NOT NULL ]
| [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED J [ WITH FILLFACTOR = filifaclor ] [ON {filegroup \ DEFAULT} ] ]
]
| [ [ FOREIGN KEY ]
REFERENCES ref_table [ ( ref_column ) ] [ ON DELETE { CASCADE NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] [ NOT FOR REPLICATION ]
]
| CHECK [ NOT FOR REPLICATION ]
(logical_expression )
}
< table_constraint > ::= [ CONSTRAINT constraint_name ]
{ [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ] {(column [ ASC | DESC ] [,...n])} [ WITH FILLFACTOR =fillfactor ] [ ON {filegroup \ DEFAULT } ]
] FOREIGN KEY
[ ( column [,...n ])]
REFERENCES ref_table [ (ref_column [,...n]) [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] [ NOT FOR REPLICATION ] | CHECK [ NOT FOR REPLICATION ] ( search_conditions)
ALTER TABLE Syntax:
ALTER TABLE table
{ [ ALTER COLUMN column_name
{ new_data_type [ (precision [, scale } ) ] [ COLLATE < collation_name > ] [ NULL | NOT NULL ] | {ADD | DROP } ROWGUIDCOL }
| ADD
{[ < column_definition > ]
| column_name AS computed_column_expression
\ [ WITH CHECK | WITH NOCHECK ] ADD
{ < table_constraint > } [,...n ] DROP
{ [ CONSTRAINT ] constraint_name
\ COLUMN column }[,...n] { CHECK | NOCHECK } CONSTRAINT
{ ALL | constraint _name [,...n ] } { ENABLE | DISABLE } TRIGGER { ALL | trigger_name [,...n] }
< column_defmition > ::=
{ column _name datajype }
[[ DEFAULT constant_expression } [ WITH VALUES ]
| [ IDENTITY [ (seed, increment) [ NOT FOR REPLICATION ] ] ]
] [ ROWGUIDCOL ]
[ COLLATE < collation_name > ] [ < column_constraint > ] [...n ]
< column_constraint > ::=
[ CONSTRAINT constraint_name ] {[NULL NOT NULL]
| [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ] [ WITH FILLFACTOR =fillfactor} [ ON {filegroup \ DEFAULT } ]
| [ [ FOREIGN KEY J
REFERENCES refjable [ ( ref_colmnn ) ] [ ON DELETE { CASCADE j NO ACTION } ] [ ON UPDATE { CASCADE NO ACTION } ] [ NOT FOR REPLICATION ]
| CHECK [ NOT FOR REPLICATION ] (logical _expression)
< table_constraint > ::=
[ CONSTRAINT constraint_name ] {[ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ] {(column [,...n ])} [ WITH FILLFACTOR = fill/actor ] [ ON {filegroup \ DEFAULT } ]
| FOREIGN KEY
[ ( column [ ,...n ] ) ]
REFERENCES refjable [ (ref_column [ ,...n ]) ]
[ ON DELETE f CASCADE NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ] | DEFAULT constant_expression
[ FOR column ] [ WITH VALUES ] | CHECK [NOT FOR REPLICATION]
(search_conditions }
Auditing:
In an audit trail, a privileged user can view an augmented query.
Example
In the example below, data from Table 1 is utilized to illustrate various exemplary aspects of the invention.
(Table Reemoved)
Table 1.
Example 1—Select restrictions:
Goal: Grant select to the Orders table with the following restrictions: Users who are
members of the FranceMgr role can only see orders to that country; Users who are
members of the SpainMgr role can only see orders to that country; andUsers who are
members of the Director role can see all rows.
Steps:

1) Enable the table for row level security
ALTER TABLE Orders SET ROW_SECURITY = ON
2) Grant select permissions to the director, FranceMgr and SpainMgr roles
GRANT SELECT ON Orders TO directors GRANT SELECT ON Orders TO FranceMgr GRANT SELECT ON Orders TO SpainMgr
3) Bring about the required restrictions for the FranceMgr and SpainMgr
a. Create the relevant predicates:
CREATE EXPRESSION SpainFilter ON Orders AS ( Orders.ShipCountry = 'Spain')
CREATE EXPRESSION FranceFilter ON Orders AS ( Orders.ShipCountry - 'France')
b. Associate the predicates to the relevant roles on the Orders table
GRANT SELECT WHERE (SpainFilter) ON Orders to SpainMgrs GRANT SELECT WHERE (FranceFilter) ON Orders to FanceMgrs
4) Query the predicates:
At this point the following predicates are associated with the table: SpainFilter and Francefilter
At Query time:
When any query is issued against the table the queiy would be augmented with the above predicates, so if the original query is:
SELECT * FROM Orders,
it is internally augmented to:
SELECT * FROM Orders WHERE
(IS MEMBER('Spain Mgrs')=1 ANDOrders.Shipcountty='Spain)
OR
(IS MEMBER('France Mgrs')=1 ANDOrders.Shipcountty='France')
)
Explanation:
This augmented query will bring about the security restrictions required. So now, if a member of the SpainMgrs role were to perform the following query she would get only those Orders that were placed after Jan 1, 2002 AND where the ship Country was Spain.
SELECT * FROM ORDERS WHERE OrderDate >' 1/1/02'
Is internally automatically augmented (o the query below (the augmented portion is highlighted)
SELECT * FROM ORDERS WHERE OrderDate> '1/1/02' AND
(IS MEMBER('Spain Mgrs')=1 ANDOrders.Shipcountty='Spain)
OR
(IS MEMBER('France Mgrs')=1 ANDOrders.Shipcountty='France')
)
FranceMgrs role members will have a similar behavior; these members can generally only view rows where the ShipCounlry is france, and since no predicates for a Director's role were added, these members will not be able to view any rows in the table In order to enable all members of the Directors' role to be able to view all rows, one of the following can be employed:
• Grant ExemptRowSec to Directors
In this case, members of the Directors role are exempt from any augmenting of row level predicates, so when the member of the Directors role queries the table the query is not augmented with any of the predicates.
• Add the following predicate
o CREATE EXPRESSION SeeAll ON Orders AS 1=1
o GRANT SELECT ON Orders TO Directors Where SeeAll
With this option, a predicate is added to the table that provides access to all rows in the table to members of the Directors role. Thus, when a member of the Director's role queries the table, the query is augmented with the three predicates as follows...
Original Query:
SELECT * FROM Orders
Augmented Query
SELECT * FROM Orders WHERE
(IS MEMBER('Spain Mgrs')=1 ANDOrders.Shipcountty='Spain)
OR
(IS MEMBER('France Mgrs')=1 ANDOrders.Shipcountty='France')
)
(IS MEMBER('Directors')=1 AND1=1)

As used in this application, the terms "component" and "device" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a computer component. In addition, one or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more
computers. Furthermore, a component can be an entity (e.g., within a process) that an operating system kernel schedules for execution. Moreover, a component can be associated with a context (e.g., the contents within system registers), which can be volatile and/or non-volatile data associated with the execution of the thread.
With reference to Fig. 1, an exemplary environment 110 for implementing various aspects of the invention includes a computer 112. The computer 112 includes a processing unit 114, a system memory 116, and a system bus 118. The system bus 118 couples system components including, but not limited to, the system memory 116 to the processing unit 114. The processing unit 114 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 114.
The system bus 118 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, an 8-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Persona! Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 116 includes volatile memory 120 and nonvolatile memory 122. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1 12, such as during start-up, is stored in nonvolatile memory 122. By way of illustration, and not limitation, nonvolatile memory 122 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 120 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 112 also includes removable/nonremovable, volatile/nonvolatile computer storage media. Fig. 1 illustrates, for example a disk storage 124. Disk storage 124 includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memory stick. In addition, disk storage 124 can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage devices 124 to the system bus 118, a removable or non¬removable interface is typically used such as interface 126.
It is to be appreciated that Fig 3 describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment 110. Such software includes an operating system 128. Operating system 128, which can be stored on disk storage 124, acts to control and allocate resources of the computer system 112. System applications 130 take advantage of the management of resources by operating system 128 through program modules 132 and program data 134 stored either in system memory 116 or on disk storage 124. It is to be appreciated that the present invention can be implemented with various operating systems or combinations of operating systems.
A user enters commands or information into the computer 112 through input device(s) 136. Input devices 136 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card/digital camera, digital video camera, web camera, and the like. These and other input devices connect lo the processing unit 114 through the system bus 118 via interface port(s) 138. Interface port(s) 138 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 140 use some of the same type of ports as input dcvicc(s) 136. Thus, for example, a USB port may be used to provide input to computer 112, and fo output information from computer 112 to an output device 140. Output adapter 142 is provided to illustrate that there are some output devices 140 like monitors, speakers, and printers among other output devices 140 that require special adapters. The output adapters 142 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 140 and the system bus 118. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 144.
Computer 112 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 144. The remote computer(s) 144 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 112. For purposes of brevity, only a memory storage device 146 is illustrated with remote computer(s) 144. Remote computer(s) 144 is logically connected to computer 112 through a network interface 148 and then physically connected via communication connection 150. Network interface 148 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 150 refers to the hardware/software employed to connect the network interface 148 to the bus 118. While communication connection 150 is shown for illustrative clarity inside computer 112, it can also be external to computer 112. The hardware/software necessary for connection to the network interface 148 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
Fig. 2 is a schematic block diagram ofa sample-computing environment 200 with which the present invention can interact. The system 200 includes one or more client(s) 210. The client(s) 210 can be hardware and/or software (e.g., threads, processes, computing devices). The system 200 also includes one or more server(s) 230. The server(s) 230 can also be hardware and/or software (e.g., threads, processes, computing
devices). The servers 230 can house threads to perform transformations by employing the present invention, for example. One possible communication between a client 210 and a server 230 may be in the form of a data packet adapted to be transmitted between two or more computer processes. The system 200 includes a communication framework 250 that can be employed to facilitate communications between the client(s) 210 and the server(s) 230 The client(s) 210 are operably connected to one or more client data store(s) 260 that can be employed to store information local to the client(s) 210. Similarly, the server(s) 230 are operably connected to one or more server data store(s) 240 that can be employed to store information local to the servers 230.
What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or (he claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

We Claim;
1. A database security system, comprising:
a component that employs a structured query language (SQL) to cluster one or more sets of data set rows with similar security characteristics and treat the clustered rows as a named expression.
2. The system as claimed in claim 1, further comprising an access component that can access clustered tables and/or rows based on associated row-level security.
3. The system as claimed in claim 1, further comprising a query component that can perform associative, queries over respective tables, wherein the queries can be improved based on access paths and/or indices present on the tables.
4. The system as claimed in claim 1 further comprising a component that provides a named expression of a table.

5. The system as claimed in claim 4, the expression includes an arbitrary Boolean
expression defined over but not restricted to the columns of the table and/or any
other contextual data or data in another table.
6. A computer readable medium having stored thereon the computer executable
components of claims.