I am trying to figure out the list schema created in a database, I came across many answers like this and this which are trying to tell either use dba_segments or use dba_users.
But when I use those in my database then results have substantial difference.
I am looking for answers explaining which one is correct (dba_segments or dba_users) and why, so please do not think that my question is "how to get a list of all available schema in database".
dba_segments shows SEGMENTS - which are owned by schemas
you can have a schema that has no segments - objects that use segments can generally be thought of as tables or indexes. A user could own a synonym or a PL/SQL unit but have no segments for example.
Here's a list of segment types for my 12c system
HR#orcl🍻🍺 >select distinct segment_type from dba_segments;
SEGMENT_TYPE
LOBINDEX
INDEX PARTITION
ROLLBACK
NESTED TABLE
TABLE PARTITION
LOB PARTITION
LOBSEGMENT
INDEX
TABLE
CLUSTER
dba_users will show you EVERY user in the database, whether they own 'data' or not
here's how to find SCHEMAS with no segments, or one way
HR#orcl🍻🍺 >select distinct username
2 from dba_users
3 minus
4 select distinct owner
5 from dba_segments;
USERNAME
ANONYMOUS
APEX_LISTENER
APEX_PUBLIC_USER
APEX_REST_PUBLIC_USER
APPQOSSYS
BASIC_PRIVS
BI...
Which database design would be most efficient for an SaaS product, and why?
Design1: three tables (standard way to design your role permission tables)
ROLE
Id
Name
Description
PERMISSION
Id
Name
ROLEPERMISSION
Id
RoleId
PermissionId
Design2: two tables
ROLE
Id
Name
Description
PermissionSetData
PERMISSION
Id
Name
Where role.permissionsetdata column contains a CVS of permissionsets stored in the role record. (Save database storage space, may help with performance?)
Solution 1 is the only appropriate design.
Saving database storage space is nearly always a moot point here I think. When you can buy TERA bytes of space at a reasonable price, why would you try saving a few kilo bytes? (the space needed for each solution would be approximately the same).
The multi-value column in the second design doesn't follow proper database design.
From a practical point of view, retrieving data in a muli-value column is massively more complex and expensive than in a properly designed db. For instance, you can't index a CSV column properly, you can't join easily.
If I have three different user with different occupation (manager, salesman, accounting)
The main question is to how display right column to right person based on star schema and requirement below in SQL server?
The fact and dim are using regular table inside of data mart.
Background information:
The manager is authorized to see all column in factTransaction
The salesman is not allowed to see TaxAmount, TotalAmount and ProductBusinessKey.
The Accounting is note allowed to see Product Quantity, ProductPrice and GeographyFullname.
In windows, the they have their own user account.
The picture is take from the address (Design of a data warehouse with more than one fact tables)
SQL Server does have the ability to assign column permissions (http://msdn.microsoft.com/en-us/library/ms180341%28v=sql.105%29.aspx). You can set the specific permissions as you like, by treating each column as an object with its own security.
Managing column level security is likely to be cumbersome, because you have to remember to update the security every time the table changes and new users are added.
You consider a different approach. Define a separate view for each of the different groups. Only the manager would have access to the "manager" view; only the salesman (and the manager perhaps) would have access to salesman view and so on. Then build the application for each group based on those views.
Finally, managing multiple views might be a bit cumbersome. Instead, you can also have a table-valued function that wraps all the views into a single function. The function would check the permissions for each user and choose the appropriate data to return.
The advantage of user defined functions is that only the user who created the function needs to have access to the underlying tables. That is, the users only have permissions for the function; otherwise, they cannot see the underlying tables. The function would control what they can see.
I know this can be done, because I've seen it at my last workplace, but I don't know how to replicate!
Basically, there is a MASTER user who has write privileges for all our tables. In our application's DB adapter connection settings, we use DEFAULT_SCHEMA: MASTER
I have created a new test user for myself (on the same database as the master user, not using a database link) so that I can freely create test data without messing with real data. Then copied a table for my test user so that I can freely manipulate data: create table SIMMBOT.real_data_table as select * from MASTER.real_data_table
The problem is that I don't know how to set up the connection so that Oracle knows to override MASTER.real_data_table with my own SIMMBOT.real_data_table. I have a hunch that you can't actually do that in the connection settings... so starting from square one, what would I have to do to set up test tables like this? Something like a shared schema?
If your code is using fully qualified table names (i.e. MASTER.real_data_table or SIMMBOT.real_data_table) then there is no way from a configuration standpoint to change what object is being referred to.
Assuming, however, that your code is not using a fully qualified table name-- if it is just selecting from real_data_table, then Oracle will first look for an object in the current schema with that name then look for a public synonym with that name.
If you connect as MASTER, you can change the current schema
ALTER SESSION SET current_schema = SIMMBOT
Once you've done that, all unqualified references to a table name will resolve to tables in the SIMMBOT schema. Note that the MASTER user would need to be granted appropriate access on the objects in the SIMMBOT schema separately-- setting the current schema only affects name resolution, not privileges. The SIMMBOT schema would also need to have every table that the code wants to reference-- there is no way to specify a hierarchy for resolving unqualified names. You can't tell Oracle to first resolve unqualified names in the SIMMBOT schema and then the MASTER schema.
An alternative would be to create synonyms for each table and manipulate the synonyms to reference your table for some or all users. If your application logged in as a third user that did not own any objects-- APP_USER for example-- you could create either private synonyms in the APP_USER schema that pointed to different objects in different schemas--
CREATE SYNONYM app_user.real_data_table FOR simmbot.real_data_table;
CREATE SYNONYM app_user.some_other_table FOR master.some_other_table;
or you could create public synonyms that would apply to all users (other than those that owned the objects)
CREATE PUBLIC SYNONYM real_data_table FOR simmbot.real_data_table;
CREATE PUBLIC SYNONYM some_other_table FOR master.some_other_table;
This is probably a n00blike (or worse) question. But I've always viewed a schema as a table definition in a database. This is wrong or not entirely correct. I don't remember much from my database courses.
schema -> floor plan
database -> house
table -> room
A relation schema is the logical definition of a table - it defines what the name of the table is, and what the name and type of each column is. It's like a plan or a blueprint. A database schema is the collection of relation schemas for a whole database.
A table is a structure with a bunch of rows (aka "tuples"), each of which has the attributes defined by the schema. Tables might also have indexes on them to aid in looking up values on certain columns.
A database is, formally, any collection of data. In this context, the database would be a collection of tables. A DBMS (Database Management System) is the software (like MySQL, SQL Server, Oracle, etc) that manages and runs a database.
In a nutshell, a schema is the definition for the entire database, so it includes tables, views, stored procedures, indexes, primary and foreign keys, etc.
This particular posting has been shown to relate to Oracle only and the definition of Schema changes when in the context of another DB.
Probably the kinda thing to just google up but FYI terms do seem to vary in their definitions which is the most annoying thing :)
In Oracle a database is a database. In your head think of this as the data files and the redo logs and the actual physical presence on the disk of the database itself (i.e. not the instance)
A Schema is effectively a user. More specifically it's a set of tables/procs/indexes etc owned by a user. Another user has a different schema (tables he/she owns) however user can also see any schemas they have select priviliedges on. So a database can consist of hundreds of schemas, and each schema hundreds of tables. You can have tables with the same name in different schemas, which are in the same database.
A Table is a table, a set of rows and columns containing data and is contained in schemas.
Definitions may be different in SQL Server for instance. I'm not aware of this.
Schema behaves seem like a parent object as seen in OOP world. so it's not a database itself. maybe this link is useful.
But, In MySQL, the two are equivalent. The keyword DATABASE or DATABASES
can be replaced with SCHEMA or SCHEMAS wherever it appears. Examples:
CREATE DATABASE <=> CREATE SCHEMA
SHOW DATABASES <=> SHOW SCHEMAS
Documentation of MySQL
SCHEMA & DATABASE terms are something DBMS dependent.
A Table is a set of data elements (values) that is organized using a model of vertical columns (which are identified by their name) and horizontal rows. A database contains one or more(usually) Tables . And you store your data in these tables. The tables may be related with one another(See here).
As per https://www.informit.com/articles/article.aspx?p=30669
The names of all objects must be unique within some scope. Every
database must have a unique name; the name of a schema must be unique
within the scope of a single database, the name of a table must be
unique within the scope of a single schema, and column names must be
unique within a table. The name of an index must be unique within a
database.
From the PostgreSQL documentation:
A database contains one or more named schemas, which in turn contain tables. Schemas also contain other kinds of named objects, including data types, functions, and operators. The same object name can be used in different schemas without conflict; for example, both schema1 and myschema can contain tables named mytable. Unlike databases, schemas are not rigidly separated: a user can access objects in any of the schemas in the database he is connected to, if he has privileges to do so.
There are several reasons why one might want to use schemas:
To allow many users to use one database without interfering with each other.
To organize database objects into logical groups to make them more manageable.
Third-party applications can be put into separate schemas so they do not collide with the names of other objects.
Schemas are analogous to directories at the operating system level, except that schemas cannot be nested.
Contrary to some of the above answers, here is my understanding based on experience with each of them:
MySQL: database/schema :: table
SQL Server: database :: (schema/namespace ::) table
Oracle: database/schema/user :: (tablespace ::) table
Please correct me on whether tablespace is optional or not with Oracle, it's been a long time since I remember using them.
As MusiGenesis put so nicely, in most databases:
schema : database : table :: floor plan : house : room
But, in Oracle it may be easier to think of:
schema : database : table :: owner : house : room
More on schemas:
In SQL 2005 a schema is a way to group objects. It is a container you can put objects into. People can own this object. You can grant rights on the schema.
In 2000 a schema was equivalent to a user. Now it has broken free and is quite useful. You could throw all your user procs in a certain schema and your admin procs in another. Grant EXECUTE to the appropriate user/role and you're through with granting EXECUTE on specific procedures. Nice.
The dot notation would go like this:
Server.Database.Schema.Object
or
myserver01.Adventureworks.Accounting.Beans
A Schema is a collection of database objects which includes logical structures too.
It has the name of the user who owns it.
A database can have any number of Schema's.
One table from a database can appear in two different schemas of same name.
A user can view any schema for which they have been assigned select privilege.
I try answering based on my understanding of the following analogy:
A database is like the house
In the house there are several types of rooms. Assuming that you're living in a really big house. You really don't want your living rooms, bedrooms, bathrooms, mezzanines, treehouses, etc. to look the same. They each need a blueprint to tell how to build/use them. In other words, they each need a schema to tell how to build/use a bathroom, for example.
Of course, you may have several bedrooms, each looks slightly different. You and your wife/husband's bedroom is slightly different from your kids' bedroom. Each bedroom is analogous to a table in your database.
A DBMS is like a butler in the house. He manages literally everything.
In oracle Schema is one user under one database,For example scott is one schema in database orcl.
In one database we may have many schema's like scott
Schemas contains Databases.
Databases are part of a Schema.
So, schemas > databases.
Schemas contains views, stored procedure(s), database(s), trigger(s) etc.
A schema is not a plan for the entire database. It is a plan/container for a subset of objects (ex.tables) inside a a database. This goes to say that you can have multiple objects(ex. tables) inside one database which don't neccessarily fall under the same functional category. So you can group them under various schemas and give them different user access permissions. That said, I am unsure whether you can have one table under multiple schemas. The Management Studio UI gives a dropdown to assign a schema to a table, and hence making it possible to choose only one schema. I guess if you do it with TSQL, it might create 2 (or multiple) different objects with different object Ids.
A database schema is a way to logically group objects such as tables, views, stored procedures etc. Think of a schema as a container of objects.
And tables are collections of rows and columns.
combination of all tables makes a db.