뷰는 SQL 쿼리로 정의하는 가상 테이블입니다. 뷰를 만들 때는 뷰가 나타내는 SQL 쿼리를 지정합니다. 뷰를 만든 후에는 테이블을 참조하는 것처럼 뷰를 참조하는 쿼리를 실행할 수 있습니다.
뷰를 참조하는 쿼리가 실행되면 Spanner에서 뷰에 정의된 쿼리를 실행하여 가상 테이블을 만들고 참조 쿼리에서 해당 가상 테이블의 콘텐츠를 사용합니다.
뷰를 정의하는 쿼리는 뷰를 참조하는 쿼리가 실행될 때마다 실행되므로, 뷰를 논리적 뷰 또는 동적 뷰라고 부르기도 합니다. 이는 데이터 스토리지의 실제 테이블로 뷰를 정의하는 쿼리 결과를 저장하는 SQL 구체화 뷰와 구분하기 위함입니다.
Spanner에서는 뷰를 호출자의 권한 뷰 또는 정의자의 권한 뷰로 만들 수 있습니다. 뷰에 대한 사용자 액세스를 제어하는 두 가지 유형의 보안 모델입니다.
호출자의 권한 뷰
정의자의 권한 뷰
설명
호출자 권한으로 뷰를 만드는 경우 데이터베이스 역할에 뷰 및 뷰에서 해당 뷰를 쿼리하기 위해 참조하는 모든 스키마 객체에 대한 권한이 필요합니다. 자세한 내용은 호출자의 권한 뷰를 참조하세요.
정의자의 권한으로 뷰를 만드는 경우 뷰를 쿼리하려면 데이터베이스 역할에 뷰(뷰만)에 대한 권한이 필요합니다. 정의자의 권한 뷰와 함께 세분화된 액세스 제어를 사용합니다. 그렇지 않으면 정의자의 권한 뷰에서 추가 액세스 제어를 추가하지 않습니다. 자세한 내용은 정의자의 권한 뷰를 참조하세요.
뷰를 만드는 데 필요한 권한
뷰 유형에 대한 액세스 권한을 생성, 부여, 취소하려면 데이터베이스 수준 spanner.database.updateDdl 권한이 있어야 합니다.
뷰를 쿼리하는 데 필요한 권한
데이터베이스 역할에는 뷰와 해당 뷰를 쿼리하기 위한 모든 기본 스키마 객체에 대한 권한이 필요합니다.
뷰를 쿼리하려면 데이터베이스 역할에 해당 뷰(뷰만)에 대한 권한이 필요합니다.
뷰의 이점
뷰는 애플리케이션 논리에 정의하는 쿼리를 포함한 여러 가지 이점을 제공합니다.
뷰는 애플리케이션에 논리적 데이터 모델링을 제공할 수 있습니다.
Spanner에서 물리적 데이터 모델링에 적합한 선택은 해당 데이터를 읽는 애플리케이션을 위한 최상의 추상화가 아닌 경우도 있습니다. 뷰는 애플리케이션에 더 적합한 추상화인 대체 테이블 스키마를 제공할 수 있습니다.
뷰는 쿼리 정의를 중앙화하여 유지보수를 간소화합니다.
널리 사용되는 쿼리나 복잡한 쿼리의 뷰를 만들어 애플리케이션에서 쿼리 텍스트를 분리하고 중앙화할 수 있습니다. 이렇게 하면 여러 애플리케이션에서 쿼리 텍스트를 최신 상태로 더욱 간편하게 유지할 수 있으며 애플리케이션 코드를 변경하지 않아도 쿼리를 수정하고 조정할 수 있습니다.
뷰는 스키마 변경 전반에 걸쳐 안정성을 제공합니다.
뷰를 정의하는 쿼리는 애플리케이션 논리가 아닌 데이터베이스 스키마에 저장되므로 Spanner는 쿼리가 참조하는 객체(테이블, 열 등)에 대한 스키마 변경사항이 쿼리를 무효화하지 않도록 할 수 있고 이를 보장합니다.
일반 사용 사례
Spanner 데이터베이스에 모든 데이터베이스 사용자에게 노출되면 안 되는 높은 권한의 데이터가 포함되어 있거나 데이터를 캡슐화하려는 경우에 뷰를 사용합니다.
뷰에 추가 보안 기능이 필요하지 않고 뷰의 모든 호출자가 뷰에서 참조하는 모든 스키마 객체에 액세스할 수 있는 경우에 호출자 권한 뷰를 만듭니다.
일부 호출자만 뷰에서 참조하는 모든 스키마 객체에 액세스할 수 있는 뷰를 만들려면 정의자의 권한 뷰를 만듭니다. 데이터베이스 관리자가 뷰에서 참조되는 테이블 및 열에 대한 권한을 더 적은 사용자에게 제공할 수 있으므로 정의자의 권한 뷰는 더 안전하게 보호되며 제한이 더 많습니다. 정의자의 권한 뷰는 사용자가 Spanner 데이터베이스의 관련 하위 집합에 안전하게 액세스할 방법이 필요한 경우에 유용합니다. 예를 들어 다음 데이터에 대한 정의자의 권한 뷰를 만들 수 있습니다.
개인 계정 데이터(예: 애플리케이션 고객).
역할별 데이터(예: HR 담당자, 영업 사원)
위치별 데이터
호출자의 권한 뷰
뷰에 호출자 권한이 있으면 사용자, 호출자가 뷰에 대한 쿼리를 실행할 때 Spanner가 뷰 및 해당 뷰에서 참조하는 모든 스키마 객체에 대해 사용자 권한을 확인합니다. 뷰를 쿼리하려면 사용자에게 모든 스키마 객체에 대한 권한이 있어야 합니다.
정의자의 권한 뷰
정의자의 권한 뷰를 사용하면 보기에 추가 보안 기능이 추가됩니다. 뷰와 기본 스키마 객체에 대한 서로 다른 권한을 제공합니다.
호출자 권한 뷰와 마찬가지로 정의자 권한 뷰를 만들려면 사용자에게 데이터베이스 수준 권한이 있어야 합니다. 가장 큰 차이점은 데이터베이스 역할이 정의자의 권한 뷰를 쿼리할 때 Spanner가 역할이 뷰 자체(뷰에만) 액세스 권한이 있는지 확인한다는 것입니다. 따라서 뷰를 쿼리하는 사용자가 모든 기본 스키마 객체에 액세스할 수 없더라도 뷰에 액세스하여 해당 콘텐츠를 볼 수 있습니다. 정의자의 권한 뷰를 통해 사용자가 뷰에 정의된 행으로 제한된 새 데이터에 액세스할 수 있습니다.
Spanner Identity and Access Management(IAM) 권한은 데이터베이스 수준에서 부여됩니다. 정의자의 권한 뷰와 함께 세분화된 액세스 제어를 사용합니다. 그렇지 않으면 정의자의 권한 뷰에서 추가 액세스 제어를 추가하지 않습니다. 이는 사용자에게 데이터베이스에 대한 읽기 권한이 있으면 데이터베이스의 모든 스키마 객체에 대한 읽기 권한이 있기 때문입니다. 데이터베이스에 세분화된 액세스 제어를 구성하면 뷰에 대한 SELECT 권한이 있는 세분화된 액세스 제어 사용자와 데이터베이스에 대한 데이터베이스 수준 권한이 있는 사용자가 뷰를 쿼리할 수 있습니다. 차이점은 세분화된 액세스 제어 사용자는 기본 객체에 대한 권한이 필요하지 않다는 점입니다.
정의자의 권한 뷰의 기본 스키마 객체에 대한 액세스 권한이 없는 사용자가 정상 이외의 쿼리 모드에서 쿼리를 수행하면 오류가 발생합니다.
사용자가 교묘하게 설계된 쿼리를 만들어 Spanner가 정의자 권한 뷰에서 사용할 수 없는 데이터의 존재를 표시하거나 나타내는 오류를 발생시키게 할 수 있습니다.
예를 들어 과정을 수강할 수 있는 학생 점수를 반환하는 다음 StudentStudentScores 뷰가 있다고 가정합니다. 자격 기준은 학생의 수준과 시험 점수를 기준으로 합니다. 학생 수준이 6점 이하인 경우 점수가 중요하며, 자격 요건을 충족하려면 시험에서 50점 이상을 얻어야 합니다. 그렇지 않으면 6점보다 크거나 같은 수준의 경우 학생은 기본적으로 자격 요건을 충족합니다.
사용자는 SELECT * FROM QualifiedStudentScores s WHERE s.Level = 7 AND 1/(s.Score - 20) = 1; 형식의 쿼리를 실행할 수 있습니다.
뷰가 해당 수준에 대해 데이터를 50점 이상으로 제한하더라도 수준 7에서 20점을 받은 학생이 있으면 이 쿼리는 0으로 나누기 오류로 실패할 수 있습니다.
뷰 사용 시 쿼리 성능
뷰를 참조하는 쿼리는 뷰의 정의로 대체된 뷰 참조를 사용하는 동일 쿼리와 비슷한 성능을 보입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Views overview\n\n| **PostgreSQL interface note:** Views are supported in PostgreSQL-dialect databases with some difference from open source PostgreSQL. In Spanner, views are read-only. Views can't be the target of an `INSERT`, `UPDATE`, or `DELETE` statement.\n\n\u003cbr /\u003e\n\nThis document introduces and describes Spanner views.\n\nOverview\n--------\n\nA *view* is a virtual table defined by a SQL query. When you create a view, you\nspecify the SQL query it represents. Once you have created a view, you can\nexecute queries that refer to the view as though it were a table.\n\nWhen a query that refers to a view is executed, Spanner creates\nthe virtual table by executing the query defined in the view, and that virtual\ntable's content is used by the referring query.\n\nBecause the query defining a view is executed every time a query referring to\nthe view is executed, views are sometimes called logical views or\ndynamic views to distinguish them from SQL materialized views, which store\nthe results of the query defining the view as an actual table in data storage.\n\nIn Spanner, you can create a view as either an *invoker's rights\nview* or a *definer's rights view*. They are the two types of security models\ncontrolling access to a view for users.\n\nBenefits of views\n-----------------\n\nViews offer several benefits over including the queries they define in the\napplication logic.\n\n- **Views can provide logical data-modeling to applications.**\n\n Sometimes the choices that make sense for physical data-modeling on\n Spanner are not the best abstraction for applications reading\n that data. A view can present an alternate table schema that is a more\n appropriate abstraction for applications.\n- **Views centralize query definitions and so simplify maintenance.**\n\n By creating views for widely used or complex queries, you can factor query\n text out of applications and centralize it. Doing so makes keeping query text\n up-to-date across applications much simpler and permits revision and tuning of\n queries without requiring application code to change.\n- **Views provide stability across schema changes.**\n\n Because the query that defines a view is stored in the database schema instead\n of in application logic, Spanner can and does ensure that\n schema changes to the objects (tables, columns and so on) the query refers to\n do not invalidate the query.\n\nCommon use cases\n----------------\n\nUse views when your Spanner database includes highly privileged\ndata that shouldn't be exposed to all database users or if you want to\nencapsulate your data.\n\nIf your view doesn't need additional security functionality and all invokers\nof the view have access to all schema objects that the view references, create\nan invoker's rights view.\n\nIf you want to create a view where not all invokers have access to all schema\nobjects that the view references, create a definer's rights view. Definer's\nrights views are better protected and have more restrictions because the\ndatabase admin can provide fewer users with privileges on the tables and\ncolumns referenced in the view. Definer's rights views are useful when a user\nneeds a way to securely access a relevant subset of a Spanner\ndatabase. For example, you might want to create a definer's rights view for the\nfollowing data:\n\n- Personal account data (e.g., application customer).\n- Role specific data (e.g., HR personnel, sales associate).\n- Location specific data.\n\nInvoker's rights views\n----------------------\n\nIf a view has invoker's rights, it means that when a user, the invoker, executes\na query against the view, Spanner checks the user's privileges\non the view and on all the schema objects that the view references. The user\nmust have privileges on all schema objects to query the view.\n\nDefiner's rights views\n----------------------\n\nA definer's rights view adds additional security functionality to the view. It\nprovides different privileges on the view and the underlying schema objects.\nLike for invoker's rights views, users must have database-level permissions to\ncreate definer's rights views. The main difference is that when a database role\nqueries a definer's rights view, Spanner verifies that\nthe role has access to the view itself (and only the view). Therefore,\neven if the user who queries the view doesn't have access to all the underlying\nschema objects, they can access the view and see its contents. Definer's rights\nviews give users access to fresh data, limited to the rows defined in the view.\n\nSpanner Identity and Access Management (IAM) permissions are granted at the\ndatabase level. Use [fine-grained access control](/spanner/docs/fgac-about)\nalongside definer's rights view, otherwise the definer's rights view doesn't add\nany additional access control. This is because if the user has read permissions\non the database, they have read permissions on all schema objects in the\ndatabase. After you configure fine-grained access control on your database,\nfine-grained access control users with the `SELECT` privilege on the view and\nusers with database-level permissions on the database can query the view. The\ndifference is that the fine-grained access control user doesn't need privileges\non the underlying objects.\n\nLimitations of views\n--------------------\n\nViews have limitations compared to actual tables that make them inappropriate\nfor certain use cases.\n\n- **Views are read-only. They cannot be used to add, update or delete data.**\n\n You cannot use views in DML statements (`INSERT`, `UPDATE`, `DELETE`).\n- **The query that defines a view cannot use query parameters.**\n\n- **Views cannot be indexed.**\n\n- **References to views cannot use [table hints](/spanner/docs/reference/standard-sql/query-syntax#table-hints).**\n\n However, the query that defines a view can include table hints on the tables\n it refers to.\n- **Views are not supported by the\n [Read](/spanner/docs/reference/rpc/google.spanner.v1#google.spanner.v1.Spanner.Read)\n API.**\n\n- **Definer's rights views are not supported with Spanner\n [Data Boost](/spanner/docs/databoost/databoost-overview).**\n\n Running a query that contains a definer's rights view in Data Boost results in\n an error.\n- **The recommended [query mode](/spanner/docs/reference/rest/v1/QueryMode) for\n accessing a definer's rights view is `NORMAL` mode.**\n\n Users who don't have access to the underlying schema objects of a definer's\n rights view receive an error when querying in a query mode other than normal.\n- **It's possible for a user to create a carefully crafted query that causes\n Spanner to throw an error that shows or reveals the existence\n of data that is not available in the definer's rights view.**\n\n For example, assume there is the following view QualifiedStudentScores which\n returns scores of students who qualify for a course. The criteria for\n qualifying is based on the level and exam score of the student. If the\n student's level is equal or lower than six, the score matters, and the student\n has to get at least 50 points on the exam to qualify. Otherwise, for levels\n equal or greater than six, the student qualifies by default. \n\n CREATE VIEW QualifiedStudentScores\n SQL SECURITY DEFINER AS\n SELECT\n s.Name,\n s.Level,\n sc.Score\n FROM Students AS s\n JOIN Scores AS sc ON sc.StudentId = s.StudentId\n WHERE\n (CASE\n WHEN (s.Level \u003c 6) OR (s.Level \u003e= 6 AND sc.Score \u003e= 50)\n THEN 'QUALIFIED';\n ELSE 'FAILED';\n END) = 'QUALIFIED';\n\n A user can run a query in the form of\n `SELECT * FROM QualifiedStudentScores s WHERE s.Level = 7 AND 1/(s.Score - 20) = 1;`.\n This query might fail with a division by zero error if there is a student in\n level 7 who got a score of 20 points, even though the view limits data to 50\n points and above for that level.\n\nQuery performance when using views\n----------------------------------\n\nA query that refers to a view performs comparably to that same query with its\nview reference replaced by the view's definition.\n\nQuotas and limits that apply to views\n-------------------------------------\n\n- The [Quotas \\& limits](/spanner/quotas#views) page lists quota and limit\n information specifically for views.\n\n- Using a view in a query can affect that query's conformance to\n [query limits](/spanner/quotas#tables) because the view's definition\n becomes part of the query.\n\nCost impact\n-----------\n\nUsing views has a very small impact on the cost of an instance:\n\n- Using views has no impact on the compute capacity needs of an\n instance, as compared to embedding their defined query text in queries that\n refer to them.\n\n- Using views has very small impact on the database storage of an instance\n because the table generated by executing a view's query definition is not\n saved to persistent database storage.\n\nWhat's next\n-----------\n\n- Learn how to [Create and manage views](/spanner/docs/create-manage-views)."]]
