I'm new to SQL Server, just some questions on schema. my uni database textbook says database schema is something like a database's structure described in a formal language.
But it seems like SQL Server Schema is more like ownership. Why one thing can have two concepts?
Yes. The word "schema" means two different things.
"schema" in English means "plan, or technical design, or model", and as applied to databases it means the design of all the tables, columns, foreign keys, etc in a database. This is common in database literature going way back.
So the short answer is that "schema" means "the design of a set of tables", but many database systems can manage multiple, independent designs, or schemas. So a the word "schema" came to mean also "the subdivision of a database containing a set of related tables".
Related
This seems a design question but I wanted to know if there is a pattern or design consideration we need to have where we would want to create a Database and not a new schema.
why not create one big database and separate schemas. Under what circumstance should we create a new database.
They are just logical divisions, so for the most part it's a matter of preference. There is one place where it's not a matter of preference: replication.
As of September, 2022, the unit of replication is the database. It's possible to specify which databases you want to replicate, but not which schemas within a database to replicate.
If you plan to replicate, you'll want to think about keeping only the schemas/tables that are important to replicate in one or more databases that get replicated and keep other data in databases that do not get replicated.
Another thought could be, In a large DWH Enterprise Solution,
There can be variety of flavours of tables which You can map to different databases. Sales DB, Master DB, Finance DB for ex. Then Inside DBs, You may want to have schemas for tables, views ,procedures and other object .
From Database System Concepts, by Silberschatz et al:
4.5.7 Schemas, Catalogs, and Environments
Like early file systems, early database systems also had a single name
space for all relations. Users had to coordinate to make sure they did
not try to use the same name for different relations. Contemporary
database systems provide a three-level hierarchy for naming relations.
The top level of the hierarchy consists of catalogs, each of which can
contain schemas. SQL objects such as relations and views are contained
within a schema. (Some database implementations use the term
“database" in place of the term catalog.)
In order to perform any actions on a database, a user (or a program)
must first connect to the database. The user must provide the user name
and usually, a password for verifying the identity of the user. Each
user has a default catalog and schema, and the combination is unique
to the user. When a user connects to a database system, the default
catalog and schema are set up for the connection; this corresponds to
the current directory being set to the user’s home directory when the
user logs into an operating system.
To identify a relation uniquely, a three-part name may be used, for
example, catalog5.univ schema.course We may omit the catalog
component, in which case the catalog part of the name is considered to
be the default catalog for the connection. Thus if catalog5 is the
default catalog, we can use univ schema.course to identify the same
relation uniquely.
A relation has a schema, which is the collection of all the
attributes of the relation. The "schema" in the above quote seems
to correspond to more than one relations. Does "schema" in the
above quote mean the same as the schema of a relation?
What is the relation between catalogs and databases? Is the relation
between catalogs and databases one-to-one?
What do the catalogs and schemas look like in mysql, postgresql, or
SQL Server?
Thanks.
Your first sentence in # 1 makes no sense.
A table/relation like “person” has attributes/columns like “name”, “phone”, and “email”.
Tables are grouped together in a namespace known as a schema. So a schema such as “warehouse” can have a table named “person” while another schema such as “sales” can also have a table coincidentally named “person”. Each catalog has one or more schema, each schema carrying a name such as “warehouse” and “sales” seen here.
A schema commonly acts a security boundary, besides being a namespace. As far as I know, that is an implementation detail, not required by the SQL standard.
The word “schema” is also commonly used in a different, more casual and general way, to describe the tables & columns design choices made to fit the needs of an application. See first comment by IMSoP below. A schema in the casual sense might involve any number of catalogs, schemas, tables, and columns in the formal SQL Standard sense.
As for # 2, your quotation explains that. “Catalog” and “database” are synonyms. The word “catalog” is used formally by the SQL standard.
For # 3, advanced databases striving to implement the SQL standard typically support all levels defined by the standard: cluster > catalog > schema > table. This includes both Postgres and Microsoft SQL Server.
H2 Database Engine supports separate databases, each being a catalog with schemas, but no cluster grouping the catalogs/databases together.
MySQL is more limited and does not support the full hierarchy, from what I can tell in my limited searching of MySQL documentation.
For more info, see this related Question: What's the difference between a catalog and a schema in a relational database?
I've recently had to do some work on an Oracle database. I come from a MS SQL background. I am still trying to get my head around some basic definitions in Oracle
Schema - to me this just meant the structure of the database. Which includes the structure of the tables, indexes and any constrains. This does NOT include any data that is stored in the tables. A database would only contain one Schema and one set of data.
But in Oracle it seems like a Schema is defined as the structure and the data. And a database can hold many Schemas.
Is that accurate?
Regardless of the database engine, it isn't uncommon to talk about your data model as your "schema". That's not necessarily how any relational database engine defines the term but it may be perfectly clear from the context that you're talking only about the definitions of objects and not the actual data.
In both SQL Server and Oracle, a "schema" is a way of collecting together a bunch of related objects, code, and data. If you define a schema in SQL Server and create a table foo in that schema along with a usp_setFoo procedure, the data that is in foo would be part of that schema. In the same way, an Oracle schema would generally involve table and index definitions, data, code, etc.
Technically, in Oracle, a schema is defined as the set of objects owned by a particular user. Practically, an Oracle schema is generally roughly analogous to a SQL Server "database". Oracle normally has two levels of object naming (schema.object) rather than three levels in SQL Server (database.schema.object). If you're using the enterprise edition of Oracle 12.1 with pluggable databases, that changes things a bit and an Oracle pluggable database can be similar to a SQL Server database.
Is it possible to define relationships between tables in different databases in SQL server 2008? And can you recommend an online tutorial for studying it? (I prefer ASP.NET, C#)
No, you can't have foreign keys between databases.
Data integrity is within a single database only. If you need transactional consistency across databases then you should use a single database. The main issue is backups/restores: you will end up with broken data after a restore because your backups are not consistent.
A recent blog article "One Database or Ten?" explains in more details
Saying that, you can use triggers if you need this and are prepared to have broken data
Yes you can but NOT using FOREIGN KEYS:
You can use specific stored procs, which checks the consistency - in
this case you have to make the user to use only these procedures for
all the CRUD operations in both DBS
Triggers, which will check the same
All of the above have to run within properly isolated transaction to
be sure, that your "just checked" values will not be deleted in a
moment
what is the difference between creating ordinary tables using 'dbo' and creating tables using schemas.How this schema works & supports the tables
A schema is just a container for DB objects - tables, views etc. It allows you to structure a very large database solution you might have. As a sample, have a look at the newer AdventureWorks sample databases - they have a number of schemata included, like "HumanResources" and so forth.
A schema can be a security boundary, e.g. you can give or deny certain users access to a schema as a whole. A schema can also be used to keep tables with the same name apart, e.g. you could create a "user schema" for each user of your application, and have a "Settings" table in each of them, holding that user's settings, e.g. "Bob.Settings", "Mary.Settings" etc.
In my experience, schemata are not used very often in SQL Server. It's a way to organize your database objects into containers, but unless you have a huge amount of database objects, it's probably something you won't really use much.
dbo is a schema.
See if this helps.
Schema seems to be a way of categorizing objects (tables/stored procs/views etc).
Think of it as a bucket to organize related objects based on functionality.
I am not sure, how logged in SQL user is tied to a specific schema though.