différence entre un utilisateur et d’un schéma dans Oracle ?

Question

Quelle est la différence entre un utilisateur et d’un schéma dans Oracle ?

Answer 1

De Demander À Tom

Vous devriez envisager un schéma à l'utilisateur de compte et la collection de tous les objets qui y sont comme un schéma pour toutes fins utiles.

SCOTT est un schéma qui inclut l'EMP, DEPT et BONUS des tables avec de diverses subventions, et d'autres trucs.

SYS est un schéma qui comprend des tonnes de tables, de vues, de subventions, etc etc etc.

Le SYSTÈME est un schéma.....

Techniquement -- Un schéma est un ensemble de métadonnées (dictionnaire de données) utilisé par la base de données, généralement générée à l'aide de DDL. Un schéma définit les attributs de la base de données, tels que des tables, des colonnes, et les propriétés. Un schéma de base de données est une description des données dans un la base de données.

Answer 2

Je crois que le problème est que Oracle utilise le terme de schéma un peu différemment de ce qu'il signifie en général.

1. Oracle du schéma (comme expliqué dans Nebakanezer réponse): fondamentalement, l'ensemble de toutes les tables et d'autres objets appartenant à un compte d'utilisateur, de manière à peu près équivalente à un compte d'utilisateur
2. Schéma général: L'ensemble de toutes les tables, sprocs etc. qui composent la base de données pour un système / application (comme dans "les Développeurs doivent discuter avec les Administrateurs de bases de données sur le schéma de notre nouvelle application.")

Schéma dans le sens 2. est similaire, mais pas le même schéma dans le sens 1. E. g. pour une application qui utilise plusieurs DB comptes, un schéma dans le sens 2 peut être constitué de plusieurs schémas Oracle :-).

Plus de schéma peut aussi signifier un tas d'autres, assez indépendants les choses dans d'autres contextes (par exemple, en mathématiques).

Oracle suffit d'avoir utilisé un terme comme "userarea" ou "accountobjects", au lieu de overloadin "schéma"...

Answer 3

De WikiAnswers:

• Un schéma est un ensemble d'objets de base de données, y compris les structures logiques tels que des tables, vues, séquences, des procédures stockées, des synonymes, des index, clusters, et les liens de base de données.
• Un utilisateur possède un schéma.
• Un utilisateur et un schéma du même nom.
• La création d'un UTILISATEUR commande crée un utilisateur. Il crée automatiquement un schéma pour l'utilisateur.
• CRÉER le SCHÉMA de commande ne crée pas un "schéma", comme il l'indique, il permet simplement de créer plusieurs tables et de vues et d'effectuer de multiples subventions dans votre propre schéma en une seule transaction.
• Pour toutes fins utiles, vous pouvez considérer qu'un utilisateur d'un schéma et d'un schéma à un utilisateur.

En outre, un utilisateur peut accéder à des objets dans des schémas autres que les leurs, s'ils ont la permission de le faire.

Answer 4

Pensez à un utilisateur que vous avez normalement do (nom d’utilisateur/mot de passe avec accès pour vous connecter et accéder à certains objets dans le système) et un schéma que la version de base de données du répertoire home de l’utilisateur. Utilisateur « foo » crée généralement choses sous schéma « foo » par exemple, si l’utilisateur « foo » crée ou fait référence à la table « bar » puis Oracle suppose que l’utilisateur veut dire « foo.bar ».

Answer 5

Mes informations ci-dessous ne définit pas la différence entre un propriétaire et le schéma. Cependant, je pense que cela ajoute à la discussion.

Dans mon petit monde de la pensée: J'ai lutté avec l'idée que j'ai créer N nombre d'utilisateurs....où je veux que chacun de ces utilisateurs à "consommer" (aka, utilisation) un seul schéma.

Ce mec (url ci-dessous) montre comment faire (N nombre d'utilisateurs...et chacun de ces utilisateurs seront "redirigé" vers un seul schéma.

Je vais coller son code ainsi, sur la chance le lien de l'URL meurt dans l'avenir.

http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php

Il a un deuxième "synonyme" d'approche (non listés ici). Je ne suis que le collage de la CURRENT_SCHEMA version (l'un de ses approches). ENCORE une fois, je ne vais PAS prendre le crédit pour cela. Je déteste quand quelqu'un dit: "votre réponse est à ce lien", et BOUM, le lien est mort. :<

......................................................

(à partir de http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php)

CURRENT_SCHEMA Approche

Cette méthode utilise la CURRENT_SCHEMA attribut de session pour pointer automatiquement les utilisateurs de l'application du schéma correct.

Tout d'abord, nous avons créer le schéma de propriétaire et un utilisateur de l'application.

CONN sys/password AS SYSDBA

-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;

-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON users;

GRANT CONNECT, CREATE TABLE TO schema_owner;

-- Application user.
CREATE USER app_user IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp;

GRANT CONNECT TO app_user;

Notez que l'utilisateur de l'application peut se connecter, mais ne dispose pas de l'espace de quotas ou de privilèges pour créer des objets.

Ensuite, nous avons créer des rôles pour permettre la lecture-écriture et en lecture seule.

CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;

Nous voulons donner à nos utilisateurs de l'application accès en lecture-écriture pour les objets de schéma, afin de nous accorder le rôle pertinent.

GRANT schema_rw_role TO app_user;

Nous devons nous assurer que l'utilisateur de l'application a son schéma par défaut pointant vers le propriétaire du schéma, nous créons donc un APRÈS déclencheur d'ouverture de session pour le faire pour nous.

CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
  DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
  EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/

Maintenant, nous sommes prêts à créer un objet dans le schéma propriétaire.

CONN schema_owner/password

CREATE TABLE test_tab (
  id          NUMBER,
  description VARCHAR2(50),
  CONSTRAINT test_tab_pk PRIMARY KEY (id)
);

GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;

Remarquez comment les privilèges sont accordés pour les rôles pertinents. Sans cela, les objets ne serait pas visible à l'utilisateur de l'application. Nous avons maintenant un schéma de fonctionnement du propriétaire et l'utilisateur de l'application.

SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
 Name                                                  Null?    Type
 ----------------------------------------------------- -------- ------------------------------------
 ID                                                    NOT NULL NUMBER
 DESCRIPTION                                                    VARCHAR2(50)

SQL>

Cette méthode est idéale, où l'utilisateur de l'application est simplement un autre point d'entrée principale pour le schéma, ne nécessitant pas d'objets de son propre.