Différence entre un utilisateur et un schéma dans Oracle?

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

De Ask Tom

Vous devez considérer un schéma comme étant le compte d'utilisateur et la collection de tous les objets qu'il contient en tant que schéma à toutes fins utiles.

SCOTT est un schéma qui inclut les tables EMP, DEPT et BONUS avec diverses subventions et d'autres choses.

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

SYSTEM est un schéma .....

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

Je crois que le problème est qu'Oracle utilise le terme schéma légèrement différemment de ce qu'il signifie généralement.

1. Schéma d'Oracle (comme expliqué dans la réponse de Nebakanezer): essentiellement l'ensemble de toutes les tables et autres objets appartenant à un compte d'utilisateur, donc à peu près équivalent à un compte d'utilisateur
2. Schéma en général: ensemble de toutes les tables, sprocs, etc. qui composent la base de données pour un système / application donné (comme dans "Les développeurs doivent discuter avec les administrateurs de base de données du schéma de notre nouvelle application.")

Le schéma au sens 2. est similaire, mais pas identique au schéma au sens 1. Par exemple, pour une application qui utilise plusieurs comptes DB, un schéma au sens 2 peut être composé de plusieurs schémas Oracle :-).

De plus, le schéma peut également signifier un tas d'autres choses assez peu liées dans d'autres contextes (par exemple en mathématiques).

Oracle aurait juste dû utiliser un terme comme "userarea" ou "accountobjects", au lieu de surchargerdans "schema" ...

De WikiAnswers :

• Un schéma est une collection d'objets de base de données, y compris des structures logiques telles que des tables, des vues, des séquences, des procédures stockées, des synonymes, des index, des clusters et des liens de base de données.
• Un utilisateur possède un schéma.
• Un utilisateur et un schéma ont le même nom.
• La commande CREATE USER crée un utilisateur. Il crée également automatiquement un schéma pour cet utilisateur.
• La commande CREATE SCHEMA ne crée pas de "schéma" comme elle l'indique, elle vous permet simplement de créer plusieurs tables et vues et d'effectuer plusieurs octrois dans votre propre schéma en une seule transaction.
• À toutes fins utiles, vous pouvez considérer un utilisateur comme un schéma et un schéma comme un utilisateur.

De plus, un utilisateur peut accéder à des objets dans des schémas autres que le leur, s'il y est autorisé.

Pensez à un utilisateur comme vous le faites normalement (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 comme la version de base de données du répertoire personnel d'un utilisateur. L'utilisateur "foo" crée généralement des choses sous le schéma "foo" par exemple, si l'utilisateur "foo" crée ou fait référence à la table "bar", Oracle supposera que l'utilisateur signifie "foo.bar".

Cette réponse ne définit pas la différence entre un propriétaire et un schéma, mais je pense qu'elle ajoute à la discussion.

Dans mon petit monde de pensée:

J'ai eu du mal avec l'idée que je crée N nombre d'utilisateurs où je veux que chacun de ces utilisateurs "consomme" (alias, utilise) un schéma unique.

Tim sur oracle-base.com montre comment procéder (avoir N nombre d'utilisateurs et chacun de ces utilisateurs sera "redirigé" vers un seul schéma.

Il a une seconde approche "synonyme" (non listée ici). Je ne cite ici que la version CURRENT_SCHEMA (une de ses approches):

CURRENT_SCHEMA Approche

Cette méthode utilise l' CURRENT_SCHEMAattribut de session pour pointer automatiquement les utilisateurs d'application vers le schéma correct.

Tout d'abord, nous créons le propriétaire du schéma et un utilisateur d'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 qu'il n'a aucun quota ou privilège d'espace de table pour créer des objets.

Ensuite, nous créons des rôles pour autoriser l'accès en lecture-écriture et en lecture seule.

CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;

Nous voulons donner à notre utilisateur d'application un accès en lecture-écriture aux objets de schéma, nous accordons donc le rôle approprié.

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 déclencheur AFTER LOGON 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;
/

Nous sommes maintenant prêts à créer un objet dans le propriétaire du schéma.

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 aux rôles concernés. Sans cela, les objets ne seraient pas visibles pour l'utilisateur de l'application. Nous avons maintenant un propriétaire de schéma et un utilisateur d'application qui fonctionnent.

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 lorsque l'utilisateur de l'application est simplement un point d'entrée alternatif au schéma principal, ne nécessitant aucun objet propre.

C'est très simple.

If USER has OBJECTS
then call it SCHEMA
else
     call it USER
end if;

Un utilisateur peut avoir accès aux objets de schéma appartenant à différents utilisateurs.

Le schéma est une encapsulation de DB.objects sur une idée / domaine d'intérêt, et appartenant à UN utilisateur. Il sera ensuite partagé par d'autres utilisateurs / applications avec des rôles supprimés. Les utilisateurs n'ont donc pas besoin de posséder un schéma, mais un schéma doit avoir un propriétaire.

Un compte d'utilisateur est comme des parents qui détiennent une clé de votre maison, mais ne possède rien, c'est-à-dire qu'un compte d'utilisateur ne possède aucun objet de base de données ... pas de dictionnaire de données ...

Alors qu'un schéma est une encapsulation d'objets de base de données. C'est comme le propriétaire de la maison qui possède tout dans votre maison et un compte d'utilisateur ne pourra accéder aux biens à la maison que lorsque le propriétaire, c'est-à-dire le schéma, lui accordera les subventions nécessaires.

- UTILISATEUR et SCHÉMA

Les deux mots utilisateur et schéma sont interchangeables, c'est pourquoi la plupart des gens se trompent sur ces mots ci-dessous, j'ai expliqué la différence entre eux

- L'utilisateur utilisateur est un compte pour connecter la base de données (serveur). nous pouvons créer un utilisateur en utilisant CREATE USER nom_utilisateur IDENTIFIED BY mot de passe.

--Schéma

En fait, Oracle Database contient une structure logique et physique pour traiter les données. Le schéma a également une structure logique pour traiter les données dans la base de données (composant mémoire). Il est créé automatiquement par oracle lors de la création de l'utilisateur.Il contient tous les objets créés par l'utilisateur associé à ce schéma.Par exemple, si j'ai créé un utilisateur avec le nom santhosh puis oracle crée un schéma appelé santhosh, oracle stocke tous les objets créés par l'utilisateur santhosh dans santhosh schéma.

Nous pouvons créer un schéma par l'instruction CREATE SCHEMA, mais Oracle crée automatiquement un utilisateur pour ce schéma.

Nous pouvons supprimer le schéma à l'aide de l'instruction DROP SCHEMA schama_name RESTRICT, mais il ne peut pas supprimer scehema contient des objets, donc pour supprimer le schéma, il doit être vide. Ici, le mot de restriction spécifie forcément ce schéma sans objets.

Si nous essayons de supprimer un utilisateur contenant des objets dans son schéma, nous devons spécifier le mot CASCADE car oracle ne vous permet pas de supprimer des objets contenant un utilisateur. DROP USER nom_utilisateur CASCADE afin que Oracle supprime les objets du schéma, puis il supprime automatiquement l'utilisateur, les objets référencés à ce schéma à partir d'autres schémas comme les vues et les synonymes privés passent à un état non valide.

J'espère que vous avez maintenant la différence entre eux, si vous avez des doutes sur ce sujet, n'hésitez pas à demander.

Je vous remercie.

Un utilisateur de schéma et de base de données est le même, mais si le schéma possède des objets de base de données et qu'il peut faire tout son objet, mais que l'utilisateur accède simplement aux objets, il ne peut FAIRE aucune opération DDL tant que l'utilisateur du schéma ne vous a pas accordé les privilèges appropriés.

Sur la base de ma petite connaissance d'Oracle ... un USER et un SCHEMA sont quelque peu similaires. Mais il y a aussi une différence majeure. Un UTILISATEUR peut être appelé SCHEMA si l '"UTILISATEUR" possède un objet, sinon ... il ne restera qu'un "UTILISATEUR". Une fois que l'UTILISATEUR possède au moins un objet, en vertu de toutes vos définitions ci-dessus ... L'UTILISATEUR peut maintenant être appelé SCHEMA.

Utilisateur: accès aux ressources de la base de données. Comme une clé pour entrer dans une maison.

Schéma: collecte d'informations sur les objets de base de données. Comme Index dans votre livre qui contient les brèves informations sur le chapitre.

Regardez ici pour plus de détails

Pour la plupart des gens qui connaissent mieux MariaDB ou MySQL, cela semble peu déroutant car dans MariaDB ou MySQL, ils ont des schémas différents (qui incluent différentes tables, vues, blocs PLSQL et objets DB, etc.) et les UTILISATEURS sont les comptes qui peuvent accéder à ces schéma. Par conséquent, aucun utilisateur spécifique ne peut appartenir à un schéma particulier. L'autorisation doit être donnée à ce schéma pour que l'utilisateur puisse y accéder. Les utilisateurs et le schéma sont séparés dans des bases de données comme MySQL et MariaDB.

Dans le schéma Oracle, les utilisateurs sont presque traités de la même manière. Pour travailler avec ce schéma, vous devez avoir l'autorisation qui est l'endroit où vous sentirez que le nom du schéma n'est rien d'autre que le nom d'utilisateur. Des autorisations peuvent être accordées sur plusieurs schémas pour accéder à différents objets de base de données à partir de schémas différents. Dans oracle, nous pouvons dire qu'un utilisateur possède un schéma parce que lorsque vous créez un utilisateur, vous créez des objets de base de données pour lui et vice versa.

Le schéma est un conteneur d'objets. Il appartient à un utilisateur.

Eh bien, j'ai lu quelque part que si votre utilisateur de base de données a les privilèges DDL, c'est un schéma, sinon c'est un utilisateur.