The main characteristics of this "databases" is that the belief that what is mathematically elegant, is also the simplest and best. So the relational model is based on relational calculus, where you see the database as "relations" of tuples, where each tuple represent elements of data. You then go on and describe addition, subtraction (insert, delete), multiplication (join) and division (inner join) as operators on tuples, and projection as operators on elements. <p> This works fine, and a RDBM has to support integrity constraints that ensures that the mathematical properties are retained. If you do not like calculus, you can also describe the RDBMS with "relational algebra". A more pragmatic way of structuring data, that was intended to reflect the use of data can be found in the CODASYL DBTG proposal. Such databases will be vastly more efficient, there will be things you cannot do, whereas all can be done with a relational database - somehow.Note that a database as such is based on assumptions of support to retain consistency, data is supposed to never be lost, and when you make changes, you are able to "commit" them all because they are in the application logic defined so that it is not one, but all changes or none. If you do not manage to complete the application logic, every single trace of the changes is to be removed - "undone". A database shall also support multiple users at once, and see to that your changes are protected from others messing around with the data that you work on. This separate the various databases from using the plain file system. If you just make an application, the CODASYL database model will be much easier to work with, but when you later want to expand and add to the application, you will prefer to use the more general relational model, since this does not constrain you in any way.
Copyright © 2026 eLLeNow.com All Rights Reserved.