oracle中schema指的是什么

Schema，即XML Schema，XSD (XML Schema Definition)是W3C于2001年5月发布的推荐标准，指出如何形式描述XML文档的元素。XSD是许多XML Schema 语言中的一支。XSD是首先分离于XML本身的schema语言，故获取W3C的推荐地位。

像所有XML Schema 语言一样，XSD用来描述一组规则──一个XML文件必须遵守这些规则，才能根据该schema‘合法（Valid）’。

扩展资料：

发展历程

在官方文档的参考附录里，XSD标准承认受到[文件类型描述|DTD]]和其他早期XML schema 语言的影响，如DDML、SOX、XML-Data、以及XDR。XSD从中吸收了一些特性，然而也在这些特性中有所折衷。

这些早期schema 语言中的XDR与SOX在XML Schema发布后仍继续使用了一段时间。不少微软的产品支持XDR直到2006年十二月MSXML60的发布（MSXML 60抛弃了XDR改用XSD）。

Commerce One, Inc支持它自己的SOX schema 语言直到该公司于2004年末破产。2004年十二月，Novell, Inc购买了该公司，包括那些与SOX相关的专利，据报导是尽力防止被某些不相关的、以打专利相关官司为生的公司剥削图利。

参考资料来源：百度百科-Schema

数据库中User和Schema的关系

假如我们想了解数据库中的User和Schema究竟是什么关系，首先必须了解一下数据库中User和Schema到底是什么概念。

在SQL Server2000中，由于架构的原因，User和Schema总有一层隐含的关系，让我们很少意识到其实User和Schema是两种完全不同的概念，不过在SQL Server2005中这种架构被打破了，User和Schema也被分开了。

　首先我来做一个比喻，什么是Database，什么是Schema，什么是Table，什么是列，什么是行，什么是User？我们可以可以把

Database看作是一个大仓库，仓库分了很多很多的房间，Schema就是其中的房间，一个Schema代表一个房间，Table可以看作是每个

Schema中的床，Table（床）就被放入每个房间中，不能放置在房间之外，那岂不是晚上睡觉无家可归了J。，然后床上可以放置很多物品，就好比

Table上可以放置很多列和行一样，数据库中存储数据的基本单元是Table，现实中每个仓库放置物品的基本单位就是床，

User就是每个Schema的主人，（所以Schema包含的是Object，而不是User），其实User是对应与数据库的（即User是每个对应

数据库的主人），既然有 *** 作数据库（仓库）的权利，就肯定有 *** 作数据库中每个Schema（房间）的权利，就是说每个数据库映射的User有每个

Schema（房间）的钥匙，换句话说，如果他是某个仓库的主人，那么这个仓库的使用权和仓库中的所有东西都是他的（包括房间），他有完全的 *** 作权，可以

扔掉不用的东西从每个房间，也可以放置一些有用的东西到某一个房间，呵呵，和现实也太相似了吧。我还可以给User分配具体的权限，也就是他到某一个房间

能做些什么，是只能看（Read-Only），还是可以像主人一样有所有的控制权（R/W），这个就要看这个User所对应的角色Role了，至于分配权

限的问题，我留在以后单独的blog中详述。比喻到这里，相信大家都清楚了吧。

在SQL Server2000中，假如我们在某一个数据库中创建了用户Bosco，按么此时后台也为我们默认地创建了默认Schema Bosco。Schema的名字和User的名字相同，这也是我们分不清楚用户和Schema的原因。

　在SQL Server2005中，为了向后兼容，当你用sp_adduser 存储过程创建一个用户的时候，SQL

Server2005同时也创建了一个和用户名相同的Schema，然而这个存储过程是为了向后兼容才保留的，我们应该逐渐熟悉用新的DDL语言

Create User和Create Schema来 *** 作数据库。在SQL Server2005中，当我们用Create

User创建数据库用户时，我们可以为该用户指定一个已经存在的Schema作为默认Schema，如果我们不指定，则该用户所默认的Schema即为

dbo Schema，dbo

房间（Schema）好比一个大的公共房间，在当前登录用户没有默认Schema的前提下，如果你在大仓库中进行一些 *** 作，比如Create

Tabe，如果没有指定特定的房间（Schema），那么你的物品就只好放进公共的dbo房间（Schema）了。但是如果当前登录用户有默认的

Schema，那么所做的一切 *** 作都是在默认Schema上进行（比如当前登录用户为login1，该用户的默认Schema为login1，那么所做的

所有 *** 作都是在这个login1默认Schema上进行的。实验已经证明的确如此）。估计此时你会有一点晕，为什么呢？我刚才说dbo是一个

Schema，但是你可以在数据库中查看到，dbo同时也是一个user，晕了吧，呵呵。

在SQL Server2005中创建一个数据库的时候，会有一些Schema包括进去，被包括进去的Schema有：dbo，INFORMATION_SCHEMA, guest，sys等等（还有一些角色Schema，不提了，有晕了）。

　我在上文中已经提到了，在SQL Server2005中当用存储过程sp_adduser创建一个user时，同时SQL

Server2005也为我们创建了一个默认的和用户名相同的Schema，这个时候问题出来了，当我们create table

A时，如果没有特定的Schema做前缀，这个A表创建在了哪个Schema上，即进入了哪个房间？答案是：

1如果当前 *** 作数据库的用户（可以用Select current_user查出来）有默认的Schema（在创建用户的时候指定了），那么表A被创建在了默认的Schema上。

　2如果当前 *** 作数据库的用户没有默认的Schema（即在创建User的时候默认为空），但是有一个和用户名同名的Schema，那么表A照样被创建

在了dbo

Schema上，即使有一个和用户名同名的Schema存在，由于它不是该用户默认的Schema，所以创建表的时候是不会考虑的，当作一般的

Schema来处理，别看名字相同，可是没有任何关系哦。

3如果在创建表A的时候指定了特定的Schema做前缀，则表A被创建在了指定的 Schema上（有权限吗？）

　现在问题又出来了，在当前 *** 作数据库的用户（用select

current_user可以查看到，再次强调）没有默认Schema的前提下，当我们用Create table A语句时，A表会去寻找dbo

Schema，并试图创建在dbo Schema上，但是如果创建A表的用户只有对dbo

Schema的只读权限，而没有写的权限呢？这个时候A表既不是建立不成功，这个就是我以后会提及到的Login,User,

Role和Schema四者之间的关系。在这里，为了避免混淆和提高 *** 作数据库的速度（在少量数据范围内，对我们肉眼来说几乎看不到差异），我们最好每次

在 *** 作数据库对象的时候都显式地指定特定的Schema最为前缀。

现在如果登录的用户为Sue，该用户有一个默认Schema也为Sue，那么如果现在有一条查询语句为Select from mytable, 那么搜寻每个房间（Schema）的顺序是怎样的呢？顺序如下：

1 首先搜寻sysmytable （Sys Schema）

2 然后搜寻Suemytable (Default Schema)

3 最后搜寻 dbomytable (Dbo Schema)

执行的顺序大家既然清楚了，那么以后在查询数据库表中的数据时，最好指定特定的Schema前缀，这样子，数据库就不用去扫描Sys Schema了，当然可以提高查询的速度了。

另外需要提示一下的是，每个数据库在创建后，有4个Schema是必须的（删都删不掉），这4个Schema为：dbo，guest，sys和INFORMATION_SCHEMA，其余的Schema都可以删除。

没绝对关系。

user即Oracle中的用户，和所有系统的中用户概念类似，用户所持有的是系统的权限及资源；而schema所涵盖的是各种对象，它包含了表、函数、包等等对象的“所在地”，并不包括对他们的权限控制。好比一个房子，里面放满了家具，对这些家具有支配权的是房子的主人(user)，而不是房子

(schema)。你可以也是一个房子的主人(user)，拥有自己的房子(schema)可以通过altersession的方式进入别人的房子。如果你没有特别指定的话，你所做的 *** 作都是针对你当前所在房子中的东西。至于你是否有权限使用(select)、搬动(update)或者拿走(delete)这些家具就看这个房子的主人有没有给你这样的权限了，或者你是整个大厦(DB)的老大(DBA)。

altersessionsetschema可以用来代替synonyms。如果你想调用其他schema的对象（有权限的前提下），但并没有建synonym,同时又不想把其他schema名字放入代码中，就可以首先使用altersessionsetschema=<其他schema名字>。

自己练习几次，就可以清晰认识了。

三级模式结构：外模式、模式、内模式

一、模式（Schema）

定义：也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。

理解：

①一个数据库只有一个模式；

②是数据库数据在逻辑级上的视图；

③数据库模式以某一种数据模型为基础；

④定义模式时不仅要定义数据的逻辑结构（如数据记录由哪些数据项构成，数据项的名字、类型、取值范围等），而且要定义与数据有关的安全性、完整性要求，定义这些数据之间的联系。

二、外模式（ExternalSchema）

定义：也称子模式（Subschema）或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。

理解：

①一个数据库可以有多个外模式；

②外模式就是用户视图；

③外模式是保证数据安全性的一个有力措施。

三、内模式（InternalSchema）

定义：也称存储模式（StorageSchema），它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式（例如，记录的存储方式是顺序存储、按照B树结构存储还是按hash方法存储；索引按照什么方式组织；数据是否压缩存储，是否加密；数据的存储记录结构有何规定）。

理解：

①一个数据库只有一个内模式；

②一个表可能由多个文件组成，如：数据文件、索引文件。

它是数据库管理系统(DBMS)对数据库中数据进行有效组织和管理的方法

其目的有：

①为了减少数据冗余，实现数据共享；

②为了提高存取效率，改善性能。

人们为数据库设计了一个严谨的体系结构，数据库领域公认的标准结构是三级模式结构，它包括外模式、概念模式、内模式，有效地组织、管理数据，提高了数据库的逻辑独立性和物理独立性。用户级对应外模式，概念级对应概念模式，物理级对应内模式，使不同级别的用户对数据库形成不同的视图。所谓视图，就是指观察、认识和理解数据的范围、角度和方法，是数据库在用户“眼中"的反映，很显然，不同层次（级别）用户所“看到”的数据库是不相同的。

美国国家标准协会(AmericanNationalStandardInstitute,ANSI)的数据库管理系统研究小组于1978年提出了标准化的建议，将数据库结构分为3级：面向用户或应用程序员的用户级、面向建立和维护数据库人员的概念级、面向系统程序员的物理级。

以上就是关于oracle中schema指的是什么全部的内容，包括:oracle中schema指的是什么、数据库中的Schema和Database的区别、oracle数据库与用户名之间是什么关系比如建了一个orcl数据库，为什么会有很多用户 system，sys等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！