After reading some answers on different websites I am confused now. So, it would be helpful to mention the key difference between DBMS and RDBMS and any relation between them.
Since this question become popular on Stack Overflow, I am posting an answer which answers this question for me. I found this answer on udemy website. Hope this will help future users and newbies searching for a good answer on this topic.
Key Difference between DBMS and RDBMS:
The key difference is that RDBMS (relational database management system) applications store data in a tabular form, while DBMS applications store data as files.
Does that mean there are no tables in a DBMS?
There can be, but there will be no “relation” between the tables, like in a RDBMS. In DBMS, data is generally stored in either a hierarchical form or a navigational form. This means that a single data unit will have one parent node and zero, one or more children nodes. It may even be stored in a graph form, which can be seen in the network model.
In a RDBMS, the tables will have an identifier called primary key. Data values will be stored in the form of tables. The relationships between these data values will be stored in the form of a table as well. Every value stored in the relational database is accessible. This value can be updated by the system. The data in this system is also physically and logically independent.
You can say that a RDBMS is an extension of a DBMS, even if there are many differences between the two. Most software products in the market today are both DBMS and RDBMS compliant. Essentially, they can maintain databases in a (relational) tabular form as well as a file form, or both. This means that today a RDBMS application is a DBMS application, and vice versa. However, there are still major differences between a relational database system for storing data and a plain database system.
Every RDBMS is a DBMS, but the opposite is not true: RDBMS is a DBMS which is based on the relational model, but not every DBMS must be relational.
However, since RDBMS are most common, sometimes the term DBMS is used to denote a DBMS which is NOT relational. It depends on the context.
DBMS : Data Base Management System
..... for storage of data and efficient retrieval of data.
Eg: Foxpro
1)A DBMS has to be persistent (it should be accessible when
the program created the data donot exist or even the
application that created the data restarted).
2) DBMS has to provide some uniform methods independent of a
specific application for accessing the information that is
stored.
3)DBMS does not impose any constraints or security with
regard to data manipulation. It is user or the programmer
responsibility to ensure the ACID PROPERTY of the database
4)In DBMS Normalization process will not be present
5)In dbms no relationship concept
6)It supports Single User only
7)It treats Data as Files internally
8)It supports 3 rules of E.F.CODD out off 12 rules
9)It requires low Software and Hardware Requirements.
FoxPro, IMS are Examples
RDBMS: Relational Data Base Management System
.....the database which is used by relations(tables) to
acquire information retrieval
Eg: oracle, SQL..,
1)RDBMS is based on relational model, in which data is
represented in the form of relations, with enforced
relationships between the tables.
2)RDBMS defines the integrity constraint for the purpose of
holding ACID PROPERTY.
3)In RDBMS, normalization process will be present to check
the database table cosistency
4)RDBMS helps in recovery of the database in case of loss of
data
5)It is used to establish the relationship concept between two database objects, i.e, tables
6)It supports multiple users
7)It treats data as Tables internally
8)It supports minimum 6 rules of E.F.CODD
9)It requires High software and hardware
From Wikipedia,
A database management system (DBMS) is a computer software application that interacts with the user, other applications, and the database itself to capture and analyze data. A general-purpose DBMS is designed to allow the definition, creation, querying, update, and administration of databases.
There are different types of DBMS products: relational, network and hierarchical. The most widely commonly used type of DBMS today is the Relational Database Management Systems (RDBMS)
DBMS:
A DBMS is a storage area that persist the data in files.
There are limitations to store records in a single database file.
DBMS allows the relations to be established between 2 files.
Data is stored in flat files with metadata.
DBMS does not support client / server architecture.
DBMS does not follow normalization. Only single user can access the data.
DBMS does not impose integrity constraints.
ACID properties of database must be implemented by the user or the developer
RDBMS:
RDBMS stores the data in tabular form.
It has additional condition for supporting tabular structure or data that enforces relationships among tables.
RDBMS supports client/server architecture.
RDBMS follows normalization.
RDBMS allows simultaneous access of users to data tables.
RDBMS imposes integrity constraints.
ACID properties of the database are defined in the integrity constraints.
Have a look at this article for more details.
A DBMS is used for storage of data in files. In DBMS relationships can be established between two files. Data is stored in flat files with metadata whereas RDBMS stores the data in tabular form with additional condition of data that enforces relationships among the tables. Unlike RDBMS, DBMS does not support client server architecture. RDBMS imposes integrity constraints and also follows normalization which is not supported in DBMS.
DBMS is the software program that is used to manage all the database that are stored on the network or system hard disk. whereas RDBMS is the database system in which the relationship among different tables are maintained.
DBMS: is a software system that allows Defining, Creation, Querying, Update, and Administration of data stored in data files.
Features:
Normal book keeping system, Flat files, MS Excel, FoxPRO, XML, etc.
Less or No provision for: Constraints, Security, ACID rules, users, etc.
RDBMS: is a DBMS that is based on Relational model that stores data in tabular form.
SQL Server, Sybase, Oracle, MySQL, IBM DB2, MS Access, etc.
Features:
Database, with Tables having relations maintained by FK
DDL, DML
Data Integrity & ACID rules
Multiple User Access
Backup & Restore
Database Administration
There are other database systems, such as document stores, key value stores, columnar stores, object oriented databases. These are databases too but they are not based on relations (relational theory) ie they are not relational database systems.
So there are lot of differences. Database management system is the name for all databases.
DBMS stands for "Database Management Systems" it includes all Databases. RDBMS are a special Type of DMBS . R in RDBMS implies that the database uses the Relational model. a collection of related tables in the relational model makes up a database.DBMS is used for simple and small application while RDBMS is used for applications with a huge database.DBMS are for smaller organizations where security is not concerned(i.e. DBMS does not impose any constraints) while RDBMS is quitely opposite( RDBMS define the integrity constraint for the purpose of holding ACID PROPERTY).
I inherit a project of a program that configures devices via ethernet. Settings are stored in the database. The set of settings is constantly changing as devices are developing so there's a need for a simple schema change (user must be able to perform this operation).
Now, this simplicity is achieved by the XSD-scheme (easy readable and editable), and the data is stored as XML. This approach also satisfies the requirement of the use of various database engines (MS SQL and Oracle are currently supported).
I want to move database structure to the relational model. Are there any solutions which are as easy-to-change as described one while using a relational database?
I want to move database structure to the relational model.
Why?
Do you want to be able to index/query parts of the configuration, or be able to change just one part of the configuration without touching the rest?
If no, then just treating the XML as opaque BLOB should be sufficient.
If yes, then you'll have to tell us more about the actual structure of configuration.1
1 BTW, some DBMSes can "see inside" the XML, index the elemnts and so on, but that would no longer be DBMS-agnostic.
There are several solutions to your design problem.
I suggest the following;
Use a different database. Relational databases are not the best choice for this kind of data. There are databases with good support for dynamic data. One example of such a database is mongoDB, which uses JSON-style documents.
or
2. Create one (or a small set) of Key/Value table(s). You can support a hierarcical structure by adding a parent column that points to the parent key-value pair.
I wouldn't recommend changing a relational db schema on the fly as the result of a user operation. It goes against fundamental design rules for relational database design.
I have read here the discussions on 5NF, EAV and 6NF and the need for a catalogue to handle meta-data and the complex SQL "automatically". How is that implemented in practice?
PerformanceDBA wrote several answers on 6NF and EAV that mentions catalogues, e.g. in the following questions:
Would like to Understand 6NF with an Example
6NF and historical attribute data
and especially Multiple fixed tables vs flexible abstract tables, where PerformanceDBA wrote
"Eg. For 6NF databases with a catalogue, I have a set of procs that
will [re]generate the SQL required to perform all SELECTs, and I
provide Views in 5NF for all users, so they do not need to know or
understand the underlying 6NF structure. They are driven off the
catalogue. Thus changes are easy and automated. EAV types do that
manually, due to the absence of the catalogue."
First, with LedgerSMB we reuse the system catalogs and information schema wherever we can. This means that the application actually spends some time querying the system catalogs. We also have some meta-data calculations for extended attributes. We don't do EAV here. Rather we have actual relations and meta-data about these which allows us to create relational queries on the client side. These are loaded at one point and cached. The catalog looks very much like an EAV catalog, but the underlying storage is actually relational and the functions which maintain these alter underlying tables. This gives you the flexibility of EAV without the underlying difficulties.
In future versions we will probably move to fewer application catalogs and greater use of the Pg system catalogs and information schema, and our interface will be simpler from an application perspective.
I am starting to look into NoSQL databases.
I think I got the main concept which is to store the data as "maps" i.e. as key-value pairs which the NoSQL distinguishes via a unique id.
At this point I am confused (in relation to when designing the database).
Does this (that the data are stored as "maps") imply that the data we store in a Collection of a NoSQL must be "homogenous"?
Same as a Map in Java for instance where the keys are all of the same type and the values are all of the same type?
Also is the concept of referential integrity supported in NoSQL databases? Or Since they are stored as maps, I will have to
write code to manually update any related collection?
If we're talking about MongoDB:
There is no referential integrity enforcement on the DB side. You have to do it in the application code. Triggers and cascade update/delete are also on you.
Documents can be complex tree-like structures, where keys are strings and values can be of different types.
Documents are not required to be homogenous. The same collection can contain documents of any structure and field set.
Not sure if this is a silly question but as an application developer that is abstracted from the database via an ORM (in my case I'm using Grails/GORM) what would be the advantages of using something like MongoDB vs something like MySQL ?
Does it really matter?... especially given that I'll be using the GORM API to access my data and will be identifying relationships between my objects.
Thanks!
If all you're doing is storing data that's basically relational in a NoSQL store like MongoDB then you might as well use a proper relational database. The big benefit of the GORM wrappers for the NoSQL stores is that for data that is basically table/column-based you can use GORM, but you can easily access the native store to work directly with the document/graph/column/key-value/etc storage mechanism.
Anything having tree structure is better to store in mongodb, otherwise if data has table structure mysql will be better solution