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?
Vous devez considérer un schéma comme étant le compte d'utilisateur et la collection de tous les objets qu'il contient comme un schéma à toutes fins utiles.
SCOTT est un schéma qui inclut les tables EMP, DEPT et BONUS avec diverses subventions et autres éléments.
SYS est un schéma qui inclut des tonnes de tables, vues, droits, 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 pense que le problème est que Oracle utilise le terme schéma légèrement différent de ce qu'il signifie généralement.
- Schéma d'Oracle (comme expliqué dans la réponse de Nebakanezer): en gros l'ensemble de toutes les tables et autres objets appartenant à un compte d'utilisateur, donc à peu près équivalent à un compte d'utilisateur
- Schéma en général: ensemble de toutes les tables, sprocs, etc. constituant la base de données d'un système/d'une application donnée (voir "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. E.g. pour une application utilisant plusieurs comptes de base de données, un schéma au sens 2 peut être composé de plusieurs schémas Oracle :-).
De plus, schéma peut également signifier un tas d’autres choses relativement différentes dans d’autres contextes (par exemple en mathématiques).
Oracle devrait juste avoir utilisé un terme comme "userarea" ou "accountobjects", au lieu de overloadin "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'implique, 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 qu'un utilisateur est un schéma et qu'un schéma est un utilisateur.
De plus, un utilisateur peut accéder à des objets dans des schémas autres que le leur, s'il en a l'autorisation.
Pensez à un utilisateur comme vous le faites habituellement (nom d'utilisateur/mot de passe avec un accès permettant de se connecter et d'accéder à certains objets du système) et à un schéma en tant que version de base de données du répertoire de base d'un utilisateur. L'utilisateur "foo" crée généralement des éléments 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 que cela ajoute à la discussion.
Dans mon petit monde de pensées:
J'ai eu du mal avec l'idée que je crée un nombre N d'utilisateurs où je veux que chacun de ces utilisateurs "consomme" (c'est-à-dire, utilise) un seul schéma.
Tim sur Oracle-base.com montre comment faire cela (N nombre d'utilisateurs et chacun de ces utilisateurs sera "redirigé" vers un seul schéma.
Il a une deuxième approche "synonyme" (non répertoriée ici). Je ne fais que citer la version de CURRENT_SCHEMA (une de ses approches) ici:
CURRENT_SCHEMAApprocheCette méthode utilise l'attribut de session
CURRENT_SCHEMApour diriger automatiquement les utilisateurs de l'application vers le schéma approprié.Tout d'abord, nous créons le propriétaire du schéma 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 d'aucun quota ou privilège d'espace table pour créer des objets.
Ensuite, nous créons des rôles pour permettre un 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 octroyons donc le rôle correspondant.
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;Notez comment les privilèges sont accordés aux rôles pertinents. Sans cela, les objets ne seraient pas visibles pour l'utilisateur de l'application. Nous avons maintenant un propriétaire de schéma fonctionnel et un utilisateur d'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 lorsque l'utilisateur de l'application est simplement un point d'entrée alternatif au schéma principal, ne nécessitant aucun objet.
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 à des objets de schéma appartenant à différents utilisateurs.
Schema est une encapsulation de DB.objects sur une idée/domaine d’intrest, et appartenant à UN utilisateur. Il sera ensuite partagé par d'autres utilisateurs/applications avec des rôles supprimés. Les utilisateurs ne doivent donc pas posséder de schéma, mais un schéma doit avoir un propriétaire.
Un compte utilisateur est comme un membre de la famille qui détient une clé de votre maison, mais ne possède rien, c’est-à-dire qu’un compte 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 si le propriétaire de la maison possédait tout ce qui se trouvait dans votre maison et un compte utilisateur ne serait en mesure d’accéder aux biens de la maison que lorsque le propriétaire, c’est-à-dire le schéma, accorderait les subventions nécessaires.
--USER et SCHEMA
Les deux mots utilisateur et schéma sont interchangeables, c’est pourquoi la plupart des gens obtiennent la confusion sur ces mots ci-dessous j’ai expliqué la différence entre eux.
--Utilisateur est un compte pour connecter une 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. La structure logique du schéma permet également de 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, 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 à l'aide de l'instruction CREATE SCHEMA, mais Oracle crée automatiquement un utilisateur pour ce schéma.
Nous pouvons supprimer le schéma en utilisant l'instruction RESTRICT DROP SCHEMA schama_name mais elle ne peut pas supprimer les objets contenant scehema. Par conséquent, pour supprimer un schéma, il doit être vide. Ici, le mot Word restreint spécifie ce schéma sans objets.
Si nous essayons de supprimer un utilisateur contenant des objets dans son schéma, nous devons spécifier CASCADE Word, car Oracle ne vous permet pas de supprimer des objets contenant un utilisateur. DROP USER nom_utilisateur CASCADE pour qu'Oracle supprime les objets du schéma, puis supprime automatiquement l'utilisateur. Les objets référencés à ce schéma proviennent d'un autre schéma, comme les vues et les synonymes privés, et deviennent invalides.
J'espère que vous avez maintenant la différence, si vous avez des doutes sur ce sujet, n'hésitez pas à demander.
Je vous remercie.
D'après ma petite connaissance d'Oracle ... un USER et un SCHEMA sont un 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, alors, 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: Collection d'informations sur les objets de base de données. Comme dans votre livre, Index contient des informations brèves sur le chapitre.
Pour la plupart des gens qui sont plus familiers avec MariaDB ou MySQL, cela semble peu déroutant, car MariaDB ou MySQL ont des schémas différents (qui incluent différentes tables, vues, blocs PLSQL et objets de base de données, etc.) et USERS sont les comptes pouvant accéder à ces comptes. schéma. Par conséquent, aucun utilisateur spécifique ne peut appartenir à un schéma particulier. La permission 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 telles que MySQL et MariaDB.
Dans le schéma Oracle, les utilisateurs sont presque traités de la même manière. Pour utiliser ce schéma, vous devez disposer de l'autorisation qui vous permettra de penser que le nom du schéma n'est rien d'autre que le nom d'utilisateur. Des autorisations peuvent être accordées à travers les schémas pour accéder à différents objets de base de données à partir de différents schémas. Dans Oracle, nous pouvons dire qu'un utilisateur possède un schéma, car lorsque vous créez un utilisateur, vous créez des objets de base de données pour celui-ci, et inversement.
Les utilisateurs de schéma et de base de données sont identiques, mais si le schéma possède des objets de base de données et qu'ils peuvent tout faire, ils ne peuvent accéder qu'aux objets. Ils ne peuvent effectuer d'opération DDL tant que l'utilisateur de schéma ne vous a pas accordé les privilèges appropriés.