1.本公开涉及基于云的计算领域，更具体地，涉及基于云的计算环境中的集中式多租户即服务。
背景技术：
：：2.企业可以利用在基于云的计算环境中执行的应用或服务。例如，企业可以利用访问在数据中心的数据库的应用来处理采购订单、人力资源任务、工资单功能等。注意的是，基于云的计算环境可能希望支持(例如，与不同的企业相关联的)多个租户(tenant)。在一个服务中实现多租户有不同的方式(诸如postgresql)。例如，基于模式和基于数据库的分离可以在某些方面帮助系统实现这一点。然而，值得注意的是，在许多情况下，这种租户的分离可能是不可能的和/或不可取的。例如，一些云软件即服务(softwareasaservice，“saas”)实施也可能依赖于每个表中的租户标识符列。反过来，这可能导致复杂的实现，并且应用可能变得更容易受到漏洞(bug)的影响(这可能导致受限数据暴露给未授权方)。3.因此，希望为基于云的计算环境提供一种与应用和基础设施服务分离的集中式多租户服务，其中该集中式多租户服务能够以高效和安全的方式实施租户策略。技术实现要素：4.方法和系统可以与基于云的计算环境相关联。一些实施例可以与基于云的计算环境相关联。集中式多租户服务可以包括从多个应用之一接收查询的应用接口。租户策略储存器可以包含声明性租户策略，并且租户策略管理器引擎可以基于至少一个租户策略自动处理所接收的查询。如果所接收的查询未被成功处理，集中式多租户服务可以经由应用接口向应用返回错误消息。如果所接收的查询被成功处理，集中式多租户服务可以经由应用接口与多租户服务实例(例如，多租户数据库即服务实例(multi-tenantdatabaseasaserviceinstance))交换信息，并且将数据结果返回给应用。5.一些实施例包括：经由集中式多租户服务的应用接口接收来自多个应用之一的查询的方法(means)；用于由租户策略管理器引擎从包含声明性租户策略的租户策略储存器中检索至少一个租户策略的方法；用于由租户策略管理器引擎基于至少一个租户策略来验证所接收的查询的方法；如果所接收的查询未被成功处理，则用于经由应用接口向应用返回错误消息的方法；并且如果所接收的查询被成功处理，则用于经由应用接口与多租户服务实例交换信息并向应用返回数据结果的方法。6.这里公开的一些实施例的一些技术优点是改进的系统和方法，为基于云的计算环境提供与应用和基础设施服务分离的集中式多租户服务，其中该集中式多租户服务能够以高效和安全的方式实现租户策略。附图说明7.图1是根据一些实施例的高级系统架构。8.图2是根据一些实施例的方法。9.图3是根据一些实施例的更详细的系统图。10.图4是根据一些实施例的查询树(querytree)。11.图5是根据一些实施例的修改的查询树。12.图6是根据一些实施例的租户策略管理器引擎。13.图7是根据一些实施例的策略图的示例。14.图8是根据一些实施例的策略图的另一示例。15.图9是根据一些实施例的人机界面显示。16.图10是根据一些实施例的装置或平台。17.图11示出了根据一些实施例的租户策略数据库。18.图12示出了根据一些实施例的平板设备。具体实施方式19.在以下详细描述中，阐述了许多具体细节，以便提供对实施例的透彻理解。然而，本领域普通技术人员将理解，实施例可以在没有这些具体细节的情况下实施。在其他情况下，没有详细描述众所周知的方法、过程、组件和电路，以免模糊实施例。20.下面将描述本发明的一个或多个具体实施例。为了提供这些实施例的简明描述，在说明书中可能没有描述实际实现的所有特征。应当理解，在任何这样的实际实现的开发中，如在任何工程或设计项目中，必须做出许多特定于实现的决定来实现开发者的特定目标，诸如符合系统相关和业务相关的约束，这些约束可能因实现的不同而不同。此外，应当理解，这种开发努力可能是复杂和耗时的，但是对于受益于本公开的普通技术人员来说，仍然是设计、加工和制造的例行工作。21.这里描述的一些实施例为基于云的计算环境提供了与应用和基础设施服务分离的集中式多租户服务，其中该集中式多租户服务可以以高效和安全的方式实现租户策略。例如，图1是根据一些实施例的高级系统100架构。系统100包括集中式多租户服务150，其中该集中式多租户服务经由应用接口130在(a)从应用120(例如，不知道多租户并且在应用层中执行的应用120)接收请求。此外，根据这里描述的任何实施例，集中式多租户服务150与租户策略管理器170和策略储存器190相关联。如这里所使用的设备(包括与系统100相关联的设备和这里所描述的任何其他设备)可以经由任何通信网络交换信息，其中通信网络可以是局域网(localareanetwork，“lan”)、城域网(metropolitanareanetwork，“man”)、广域网(wideareanetwork，“wan”)、专有网络、公共交换电话网(publicswitchedtelephonenetwork，“pstn”)、无线应用协议(wirelessapplicationprotocol，“wap”)网络、蓝牙网络、无线lan网络和/或互联网协议(internetprotocol，“ip”)网络(诸如互联网、内联网或外联网)中的一个或多个。注意，这里描述的任何设备可以经由一个或多个这样的通信网络进行通信。22.集中式多租户服务150可以将信息存储到各种数据储存器(诸如策略储存器190)中和/或从各种数据储存器中检索信息，其中该策略储存器可以本地存储或远离集中式多租户服务150放置。尽管图1中示出了单个集中式多租户服务150，但是可以包括任何数量的这种设备。此外，根据本发明的实施例，这里描述的各种设备可以被组合。系统100功能可以由连网的设备的群集(constellation)来执行，诸如在分布式处理或基于云的架构中。23.根据这里描述的任何实施例，操作员或管理员可以经由远程设备(例如，个人计算机(personalcomputer，“pc”)、平板设备或智能手机)访问系统100，以查看关于和/或管理操作信息的信息。在一些情况下，交互式图形用户界面显示可以让操作员或管理员定义和/或调整某些参数(例如，以实现各种规则和策略)和/或提供或接收来自系统100的自动生成的建议或结果。24.在(a)接收到查询之后，系统100可以访问租户策略管理器170，其中该租户策略管理器170可以在(c)从策略储存器190中检索适当的租户策略(或多个策略)。租户策略管理器170然后可以自动处理所接收的请求。如这里所用，术语“自动”可以指在很少或没有人工干预的情况下执行的过程。如果请求无法被成功处理，可能会在(e)返回错误消息。如果该请求可以被成功处理，则系统可以在(d)与多租户服务实例180(例如，与数据库即服务相关联的多租户服务实例180)交互，以及然后可以在(e)响应于该请求将适当的数据提供回应用120。25.图2是可以由这里描述的任何实施例的一些或所有元件执行的方法。这里描述的流程图并不意味着步骤的固定顺序，并且本发明的实施例可以以任何可行的顺序实施。注意，这里描述的任何方法可以由硬件、软件、命令的自动脚本或这些方法的任意组合来执行。例如，计算机可读存储介质可以在其上存储指令，这些指令在被机器执行时导致根据这里描述的任何实施例的执行。26.在s210，该系统可以经由集中式多租户服务的应用接口接收来自多个应用之一的查询。在s220，租户策略管理器引擎可以从包含声明性租户策略的租户策略储存器中检索至少一个租户策略。在s230，系统可以基于至少一个租户策略来处理所接收的查询。例如，此处理可能包括令牌化、解析、验证、识别和应用策略等。如果在s230所接收的查询未被成功处理(例如，未被验证或以其他方式成功处理)，则系统可以在s240经由应用接口向应用返回错误消息(例如，当全局约束策略拒绝用户访问时)。如果在s230成功地处理了所接收的查询，则在s250，系统可以与多租户服务实例交换信息，并且经由应用接口向应用返回数据结果。27.因此，为了解决多租户挑战，一些实施例可以提供集中式多租户服务。在某些情况下，集中式多租户服务(诸如postgresql)可以被视为服务层，其中该服务层与应用和基础设施服务完全分离，并被置于它们之间。集中式多租户服务可以包括接收、处理和/或存储复杂的基于租户的策略的租户策略引擎或管理器。例如，这些策略可以过滤和/或转换发送回各种应用的数据。在一些实施例中，策略本质上可以是声明性的，并且作为对策略引擎的输入给出。集中式多租户服务可以在运行时期间将这些策略应用于来自(多个)应用的查询，并且因此控制允许租户在逐请求的基础上查看和/或操作的数据。28.根据一些实施例，集中式多租户服务可以永久地共同在本地(例如，在执行数据库服务的同一虚拟或物理机器中)执行和/或托管。在其他实施例中，当需要处理请求时，集中式多租户服务可以作为功能即服务共同在本地执行。注意的是，因为在执行流程中不涉及额外的跳点(hop)，同处一地(co-located)的特性(以及通过域套接字的通信)可能有助于提高性能。29.根据一些实施例，集中式多租户服务可以是灵活且易于使用的。此外，集中式多租户服务可以与任何其他服务相关联，诸如即服务、即服务等。在这种情况下，自定义查询解析器和策略解析器可以实现为插件，以便集中式多租户服务可以理解其适当的语义。30.注意的是，租户策略可以以声明的方式提供，使得管理员的定义相对直接。有由策略引擎可以支持的不同类型的策略。例如，在某些情况下，租户策略可能表示“全局约束策略”。使用这些类型的策略，约束可以在全局级别上应用，并且因此管理员可以将该约束应用于数据库服务中的所有对象。考虑这样的需求，即设计一个只有管理员(administrator)才能访问applicationlogs表的系统。在这种情况下，可能会创建以下全局约束策略：31.·策略名:gcpolicy1,32.·表:applicationlogs33.·动作:允许访问(allow-access)关系applicationlogs34.·角色:管理员(administrator)35.还考虑其中推荐服务(recommenderservice)不能访问账户表的系统。在这种情况下，可能会创建以下全局约束策略：36.·策略名:gcpolicy2,37.·表:account38.·动作:拒绝访问(reject-access)关系account39.·角色:推荐服务(recommenderservice)40.作为另一示例，在一些情况下，租户策略可能表示“多租户策略”。考虑两个租户(租户1和租户2)，其中这两个租户由模式(schema)实现和分离。在这种情况下，可以定义以下策略：41.·策略名:tenant1policy42.·表:<all>43.·动作:重写(rewrite)关系r→tenant1.r44.·角色:tenant1appuser45.·策略名:tenant2policy46.·表:<all>47.·动作:重写关系r→tenant2.r48.·角色:tenant2appuser49.这些策略可能意味着对任何关系(relation)的访问都可以指向每个租户的相关模式。50.还考虑这样的系统，其中管理员希望以这样的方式设计应用，即数据库中的每个表包含唯一标识租户的列。管理员可以简单地在cms(centralizedmulti-tenancyservice，集中式多租户服务)中定义以下策略，而不是在应用中编写复杂且容易出错的逻辑：51.·策略名:columnidentifierpolicy,52.·表:<all>53.·动作:重写谓词(predicate)c→and$table.tenantid＝$tenantid54.·角色:$tenantid55.该策略意味着，任何对表的查询都将被重写为具有如上所示的附加谓词(predicate)的查询中，该具有如上所示的附加谓词的查询实际上只返回属于该用户的行。56.作为另一示例，在一些情况下，租户策略可能表示“匿名策略”。根据一些实施例，这种类型的策略可以帮助管理员匿名化从数据库中检索的数据。考虑机器学习(machinelearning，“ml”)服务，其中该机器学习服务需要访问所有账户持有人的投资组合(portfolio)信息，以便对投资的最新趋势提出建议。管理员不想共享诸如名字、姓氏、帐号等敏感信息给这样的服务。相反，管理员可以定义以下策略：57.·策略名:accountanonpolicy,58.·表:账户(account),组合(portfolio)59.·动作:重写映射(rewrite-projection)pfname,lname,accounted60.·用户:机器学习(machinelearning)61.每当机器学习(machinelearning)用户试图访问账户(account)或组合(portfolio)表时，这种策略可以在动作中排除上述列。62.作为另一示例，在一些情况下，租户策略可以表示“数据共享策略”。注意，可能希望在租户内共享关于给定用户集的信息子集。在这种情况下，可以使用数据共享策略。考虑一个在线交通应用(例如，)，其中管理员想要共享关于与一个家庭相关联的所有乘车(ride)的信息。在这种情况下，管理员可以定义以下策略，其中这些策略将使乘车信息能够在用户1和用户2(例如，父亲和女儿、丈夫和妻子等)之间共享。63.·策略名:ridesharingpolicyuser1,64.·表:乘车(ride)65.·动作:重写谓词(rewrite-predicate)c→oruserid＝user266.·用户:user167.·策略名:ridesharingpolicyuser2,68.·表:ride69.·动作:重写谓词c→oruserid＝user170.·用户:user271.作为最后一个示例，在一些情况下，租户策略可以表示“临时策略”。根据一些实施例，临时策略可以让管理员在给定的时间间隔期间针对集中的多租户服务应用策略。考虑每季度执行一次以分析和报告在线公司的产品销售业绩的报告服务。管理员可能希望此服务仅在给定的日期时间内访问表。因此，临时策略可以定义如下：72.·策略名:reportgenerationpolicy73.·表:product,order74.·动作:重写谓词c→orrolein(selectrolefromroleswhererole＝'reportgenerator')75.·用户:reportgenerator76.·时间约束:[30-12-201918:00:00,30-12-201923:00:00][0077]在上面给出的时间限制期间，集中的多租户服务可以应用该策略，以便为报告服务提供对表的访问。[0078]图3是根据一些实施例的更详细的系统300图。如前所述，系统300包括集中式多租户层或系统350，该系统经由应用接口330从应用320(例如，与应用用户310相关联的应用320，其中该应用不知道多租户并且在应用层中执行)接收请求。此外，根据这里描述的任何实施例，集中式多租户层350与租户策略管理器370和策略储存器390相关联。[0079]在初始配置步骤中，每个应用320(例如，1到m)可以被配置为命中(hit)集中式多租户系统350的端点(endpoint)，而不是直接访问多租户服务实例380(例如，数据库实例)。此外，适当的策略由租户策略储存器390中的管理员设置。集中式多租户系统350也可以配置有多租户服务实例380的端点。[0080]在执行期间，应用320发出要在服务实例380中执行的查询。根据一些实施例，该查询可以由集中式多租户系统350中的查询扫描器352接收。查询扫描器352可以例如负责扫描查询并将它们令牌化为由sql(在postgresql的情况下)定义的令牌。参考名为“gcpolicy2”的先前全局约束策略，租用121的应用320可以发出以下查询：[0081]“selectpname,pcode,pricefromproductwhereprice>1000”在这种情况下，查询扫描器352将“select”、“from”和“where”标识为关键词，将“>”标识为操作符，将“product”和“price”标识为标识符。[0082]查询解析器354可以接收令牌以及查询字符串。查询解析器354然后可以解析该sql字符串并创建查询树。这样做是为了识别查询字符串是否符合适当的语言语义。例如，图4是根据一些实施例的用于先前查询的查询树400。树400包括查询的节点410(例如，“select”、“from”和“where”等)。[0083]再次参考图3，查询树验证器356可以处理输入，并且验证查询中提到的表/列名称是有效的并对应于正在被查询的数据库中的名称。查询树处理器358然后可以用输入的查询细节调用租户策略管理器370。租户策略管理器370可以从策略储存器390读取策略(例如，可以基于文件系统或数据库)。租户策略管理器370然后可以检查适用于当前查询的策略(或多个策略)。识别到的策略(或多个策略)然后被返回到查询树处理器358。在另一个实施例中，租户策略管理器370可以使用诸如等缓存服务来缓存租户策略，从而可以减少策略存储390的读取命中(导致更好的系统300性能)。[0084]查询树处理器358然后可以从返回的策略列表中识别任何全局约束策略。如果任何识别到的全局约束策略拒绝对给定用户310的访问，则查询树处理器358可以停止任何进一步的处理，并且向调用应用320返回“拒绝访问”错误消息。如果没有可应用的全局约束策略(或者所识别的策略都不可应用)，则查询树处理器358将识别到的策略应用于查询树以形成修改的查询树。例如，图5是根据一些实施例的针对查询510的修改的查询树500。根据一些实施例，查询生成器360从查询树处理器358作为输入给出的查询树形成修改的查询。例如，针对先前查询树的修改的查询可以是：[0085]"selectpname,pcode,pricefromproductwhereprice>1000andtenanted＝121"[0086]集中式多租户系统350然后可以用修改的查询来命中配置的多租户服务实例380，并且将结果返回给调用应用320。[0087]图6是根据一些实施例的租户策略管理器引擎600。注意的是，租户策略管理器引擎600可以负责接收、处理和/或存储复杂的基于租户的策略。反过来，这些策略可以过滤和转换被发送回应用的数据。根据一些实施例，租户策略管理器引擎600包括可满足性求解器640，其中当策略被提交给系统时，该可满足性求解器640以静态方式验证策略。租户策略通常由平台管理员和租户管理员定义。在一些实施例中，这些策略以声明的形式提供(使得管理员更容易定义)。[0088]租户策略管理器引擎600可以从管理员接收输入(“i/p”)租户策略610。例如，system#1的策略可能指示具有“tenant1role”的用户能够访问account_transaction表，而具有“推荐服务(recommenderservice)”角色的用户不能访问该表。为了实施该策略，可以定义以下策略，并将一个接一个地添加这些策略。[0089]·策略名:gcpolicy1,[0090]·表:account_transaction[0091]·动作:拒绝访问(reject-access)关系account_transaction[0092]·角色:推荐服务(recommenderservice)[0093]·策略名:tenant1policy2,[0094]·表:account_transaction[0095]·动作:允许访问(allow-access)关系account_transaction[0096]·角色:tenant1role[0097]这些策略可以由策略扫描器620接收，其中策略扫描器620扫描输入并识别策略中的令牌。例如，在上面示出的第一策略中，策略扫描器620可以将表识别为account_transaction，将角色识别为推荐服务(recommenderservice)，将动作识别为拒绝访问(reject-access)。策略扫描器620然后可以用这些输入的策略细节调用策略解析器630模块。策略解析器630然后可以解析输入并创建策略图。根据一些实施例，策略图可以包括其中顶点表示所涉及的构件(例如，关系、用户等)并且边表示使用符号表达式的所有可能的值的图。例如，这些符号表达式可以符合一阶逻辑，其中当需要真值时，该一阶逻辑随后可以由系统进行评估。例如，在上述示例中，图7是根据一些实施例的策略图700的示例。策略图700包括角色710(用户1)和表720(account_transaction)。[0098]再次参考图6，策略图和令牌可以作为输入被传递给租户策略管理器引擎600的标准可满足性求解器640。可满足性求解器640可以求解“可满足性问题”，其中该可满足性问题是确定是否存在满足给定一阶逻辑公式的解释的问题。这可能涉及到识别给定公式的变量是否可以以评估为“真(true)”的方式被赋予值“真”或“假(false)”。在前面的示例中，当给出tenant1policy2作为输入时，可满足性求解器640可以对照现有策略gcpolicy1对其进行评估，并且检查是否存在可以将这些所得策略的组合评估为“假”的解释。[0099]如果所得组合对于所有可能的值评估为“假”，则可满足性求解器640的输出将是“假”，这意味着作为输出(“o/p”)650的无效策略，并且可能导致对该策略进行更正的请求。如果所得组合对于所有可能的值评估为“真”，则可满足性求解器640的输出将是“真”，这意味着可以存储到策略储存器690中的有效策略。如果对于可能值的子集，所得组合评估为“假”和“真”，则可满足性求解器640的输出可以生成可能被数据库管理员覆写的警告(这意味着它可能是无效策略)。在前面的示例中，结果总是评估为“真”，以及因此输出将为“真”(意味着将被存储的有效策略)。[0100]图8是根据一些实施例的策略图800的另一示例。策略图800再次包括角色810(用户3)和表820(purchase_orders)。在本示例中，角色为tenant2的所有用户(用户1、用户2、…用户n)都可以通过第一个策略访问表purchase_orders。当限制用户1和用户3于purchase_orders的第二策略被提交给策略引擎600时，可满足性求解器640输出警告，因为存在所得组合评估为“假”的至少存在一个组合(新策略将否定用户1和用户3的现有策略)。在这种情况下，租户管理员可以选择覆写该警告。[0101]然后可以评估可满足性求解器640的输出。如果可满足性求解器640的输出意味着策略是有效的，则它被存储在策略储存器690中。如果可满足性求解器640的输出意味着该策略无效(或生成警告)，则该输出被显示给管理员以进行更正。在警告的情况下，可以允许管理员覆写该警告，并将策略保存到策略储存器690。在无效的策略输出情况下，管理员将进行任何必要的更改，并重新提交已更正的租户策略。[0102]图9是根据一些实施例的与集中式多租户即服务(multi-tenancyasaservice)相关联的人机界面显示。显示900包括基于云的计算环境系统的元素的图形表示910(例如，用以提供集中式多租户层)。对元素的选择(例如，经由触摸屏或计算机指针920)可以导致包含各种选项(例如，用以调整规则或逻辑、分配各种设备、配置策略等)的弹出窗口的显示。显示900还可以包括用户可选的“设置”图标990(例如，用以配置云管理和/或供应的参数(例如，用以改变或调整多租户策略或到多租户服务实例的链接))。[0103]注意的是，这里描述的实施例可以使用任何数量的不同硬件配置来实现。例如，图10可以是例如与图1的系统100(和/或这里描述的任何其他系统)相关联的装置或平台1000的框图。平台1000包括处理器1010，诸如单芯片微处理器形式的一个或多个商业上可获得的中央处理单元(centralprocessingunit，“cpu”)，其中该处理器1010耦合到通信设备1020，该通信设备被配置为经由通信网络(图10中未示出)进行通信。通信设备1020可以用于例如与一个或多个远程用户平台、云资源提供商、管理员等通信。平台1000还包括输入设备1040(例如，用于输入租户策略、规则或逻辑的计算机鼠标和/或键盘)和/或输出设备1050(例如，用于呈现显示、发送推荐、警告和/或创建数据中心报告的计算机监视器)。根据一些实施例，移动设备和/或pc可以用于与平台1000交换信息。[0104]处理器1010还与存储设备1030通信。存储设备1030可以被实现为单个数据库，或者存储设备1030的不同组件可以使用多个数据库来分布(即，不同的部署信息存储选项是可能的)。存储设备1030可以包括任何适当的信息存储设备，包括磁存储设备(例如，硬盘驱动器)、光存储设备、移动电话和/或半导体存储设备的组合。存储设备1030存储用于控制处理器1010的程序1012和/或租户策略管理器平台1014。处理器1010执行程序1012、1014的指令，以及从而根据这里描述的任何实施例进行操作。例如，处理器1010可以从多个应用中的一个接收查询。处理器1010还可以基于至少一个租户策略自动处理所接收的查询。如果所接收的查询未被成功处理，则处理器1010可以经由应用接口向应用返回错误消息。如果所接收的查询被成功处理，则处理器1010可以与多租户服务实例(例如，多租户数据库即服务实例)交换信息，并将数据结果返回给应用。[0105]程序1012、1014可以以压缩、未编译和/或加密的格式存储。程序1012、1014还可以包括其他程序元素，诸如操作系统、剪贴板应用、数据库管理系统、和/或处理器1010用来与外围设备连接的设备驱动程序。[0106]如这里所使用的，信息可以被“接收”或“发送”，例如：(i)由平台1000从另一个设备接收，或从另一个设备发送到平台1000；或者(ii)由平台1000内的软件应用或模块从另一软件应用、模块或任何其他来源接收，或从另一软件应用、模块或任何其他来源发送到平台1000内的软件应用或模块。[0107]在一些实施例中(诸如图10所示的实施例)，储存器设备1030还存储关系数据库管理系统(relationaldatabasemanagementsystem，“rdbms”)1060和租户策略数据库1100。现在将参照图11详细描述可结合平台1000使用的数据库的示例。注意的是，这里描述的数据库仅仅是一个示例，并且附加的信息和/或不同的信息可以存储在其中。此外，根据这里描述的任何实施例，各种数据库可以被分割或组合。[0108]参考图11，示出了根据一些实施例的表示可以存储在平台1000上的租户策略数据库1100的表。该表可以包括例如定义与服务实例相关联的多租户规则或策略的条目。该表还可以为每个条目定义字段1102、字段1104、字段1106、字段1108。根据一些实施例，字段1102、字段1104、字段1106、字段1108可以指定：租户策略标识符1102、租户标识符1104、策略类型1106和声明性语句1108。租户策略数据库1100可以例如由管理员创建和更新。[0109]租户策略标识符1102可以是与特定多租户策略相关联的唯一字母数字标签或链接。租户标识符1104可以指定与策略相关联的一个或多个租户。策略类型1106可以指示策略是全局约束策略、多租户策略、匿名策略、数据共享策略、临时策略等。声明性语句1108可以定义与租户策略相关联的规则。[0110]因此，实施例可以为基于云的计算环境提供与应用和基础设施服务分离的集中式多租户服务(诸如postgresql)，其中该集中式多租户服务可以以高效和安全的方式实现租户策略。此外，租户策略引擎可以负责接收、处理、验证和/或存储复杂的基于租户的声明性策略。这样，系统可以在数据被发送回请求应用之前限制、过滤和/或转换数据。[0111]下面示出了本发明的各种附加实施例。这些并不构成所有可能实施例的定义，并且本领域技术人员将理解，本发明可应用于许多其他实施例。此外，尽管为了清楚起见简要描述了以下实施例，但是本领域技术人员将理解，如果需要，如何对上述装置和方法进行任何改变以适应这些和其他实施例和应用。[0112]尽管这里已经描述了特定的硬件和数据配置，但是注意，根据本发明的一些实施例，可以提供任何数量的其他配置(例如，与这里描述的数据库相关联的一些信息可以被组合或者存储在外部系统中)。此外，尽管一些实施例集中于特定类型的数据库应用和服务，但是这里描述的任何实施例都可以应用于其他类型的应用和服务。此外，这里所示的显示仅作为示例提供，并且可以实现任何其他类型的用户界面。例如，图12示出了呈现显示1210的平板计算机1200。根据一些实施例，显示1210可以用于查看关于系统的组件的更详细的元素(例如，当经由触摸屏选择图形元素时)，或者用于配置系统的操作(例如，经由“设置”图标1220为系统设置)。[0113]仅出于说明的目的，已经根据几个实施例描述了本发明。本领域技术人员将从该描述中认识到，本发明不限于所描述的实施例，而是可以通过仅受所附权利要求的精神和范围限制的修改和变更来实施。当前第1页12当前第1页12