Wednesday, January 15, 2020

TYFK: "What is better than relational databases?"



Note: About TYFK posts (Test Your Foundation Knowledge) see the post insert below.
“Relational databases like MySQL, PostgreSQL and SQLite3 represent and store data in tables and rows. They're based on a branch of algebraic set theory known as relational algebra. Meanwhile, non-relational databases like MongoDB represent data in collections of JSON documents. The Mongo import utility can import JSON, CSV and TSV file formats. Mongo query targets of data are technically represented as BSON (binary JASON).

“Relational databases use Structured Querying Language (SQL), making them a good choice for applications that involve the management of several transactions. The structure of a relational database allows you to link information from different tables through the use of foreign keys (or indexes), which are used to uniquely identify any atomic piece of data within that table. Other tables may refer to that foreign key, so as to create a link between their data pieces and the piece pointed to by the foreign key. This comes in handy for applications that are heavy into data analysis.

“If you want your application to handle a lot of complicated querying, database transactions and routine analysis of data, you’ll probably want to stick with a relational database. And if your application is going to focus on doing many database transactions, it’s important that those transactions are processed reliably. This is where ACID (the set of properties that guarantee database transactions are processed reliably) really matters, and where referential integrity comes into play.”
First try to detect the misconceptions, then check against our debunking. If there isn't a match, you can acquire the necessary foundation knowledge in our POSTS, BOOKS, PAPERS, LINKS or, better, organize one of our on-site SEMINARS, which can be customized to specific needs.

------------------------------------------------------------------------------------------------------------------

SUPPORT THIS SITE 

Up to 2018, DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics column. In 2018 that website was discontinued. The content of this site is not available anywhere else, so if you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing publications, or donating. Thank you. 

DATA FUNDAMENTALS 

The industry is chockful of misconceptions due to lack of foundation knowledge. Attempts to correct them are dismissed as "theory that is not practical", misinterpreted as "ad-hominem attacks", or ignored altogether, regardless of the amount and quality of reasoning and supporting evidence. Most practitioners -- be it user or vendor personnel -- cannot discern these fallacies and do not realize the practical implications thereof and, thus, associate problems with their real causes. This explains the industry's "cookbook approach" and succession of fads.

What about you? Are you just a practitioner, or a thinking professional? 

TYFK (Test Your Foundation Knowledge) posts present and debunk one or more misconceptions. First try to detect them, then check against our debunking. If there isn't a match, you can acquire the necessary foundation knowledge in our BOOKS and PAPERS or, better, organize one of our on-site SEMINARS, which can be customized to specific needs. 

NEW 
  • 01/14/20 Updated the LINKS page
  • 01/04/20 Updated the POSTS page with the 2020 posts
  • 12/08/19 Added two educational references on set theory to the LINKS page.

LATEST PUBLICATIONS (order PAPERS and BOOKS)


USING THIS SITE 

  • To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the FUNDAMENTALS page. For detailed instructions on how to understand and use the labels in conjunction with the that page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search. 
  • Following the discontinuation of AllAnalytics site, the links to my columns there no longer work. I moved only the 2017 columns to dbdebunk, within which only links to sources external to AllAnalytics may work or not.

SOCIAL MEDIA 

I deleted my Facebook account. You can follow me:

  • @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture? posts, and my exchanges on LinkedIn.
  • @The PostWest blog: Evidence for Antisemitism/AntiZionism – the only universally acceptable hatred – as the (traditional) response to the existential crisis of decadence and decline of Western (including the US)
  • @ThePostWest Twitter page where I comment on global #Antisemitism/#AntiZionism and the Arab-Israeli conflict.
------------------------------------------------------------------------------------------------------------------

Note: Language such as "piece of data", "link between data pieces", and "piece pointed to by the foreign key" is a good indicator of lack of foundation knowledge. Also, as one response correctly pointed out:
“You need to provide a definition of what you mean by "better" and a set of objective and comparative criteria which can be employed to accept or reject such a definition. I am not going to speculate upon what you might mean by "better" (e.g. the types of database available or implementation(s) thereof, types of data, scalability, security, business requirements, performance, hardware platform and so on). You need to consider these criteria because they provide the necessary context upon which a meaningful answer to be your question can be derived. Without these your question cannot be answered.”
True, but we actually can, based on the motivation for the RDM.

The Misconceptions


  • MySQL, PostgreSQL, and SQLite3 are SQL DBMSs, not "relational databases".
  • SQL tables are not relations, which is one of many reasons SQL databases are not relational.
  • Databases do not "represent data" -- their data represents information about the real world, and is not stored as tables.
  • A relational DBMS (RDBMS) is a software implementation of the relational data model (RDM), which is an adaptation and application of simple set theory (SST) expressible in first order predicate logic (FOPL) to database management.
  • Transaction management is a DBMS function that is not part of, and is orthogonal to the RDM.
  • The relational algebra (RA) is only the data manipulation component of the RDM, the other being the "structural"-integrity component.
  • There are many types of non-relational DBMSs; document management systems (such as MongoDB) cannot be considered DBMSs in the sense in which relational, or even SQL ones are.

Note: According  to conventional wisdom, the structural component of the RDM is the relation (not the table!). However, a relation is a relationship among attributes constrained by other real world relationships -- so the constraints are the structure.

  • RDBMSs use a relational data sublanguage, which -- for various reasons -- SQL is not, another reason SQL DBMSs are not relational.
  • Referential constraints (not foreign keys) represent relationships among entity groups in a conceptual model.
  • While FKs are usually indexed for performance, they are logical and distinct from "links" or indexes, which are a physical implementation feature (other constraints represent relationships among entity properties and among entities within each group).

Note: But see Association Relations vs. Foreign Keys, The RDM and Model Stability, and 5NF, Association Relations, and Join for a new understanding of FKs. 

  • Database relations have attributes defined on simple domains, the values of which are treated as atomic by the data sublanguage; every atomic value in a relation is logically accessible by relation name + attribute name + primary key value.
  • While PKs are indexed for performance, they are -- like FKs -- logical and distinct from indexes; PKs (not indexes) uniquely identify relation tuples (not atomic values).
  • That even SQL DBMSs, which are not relational, support transaction management and ACID confirms that these are orthogonal to a DBMS's relational fidelity. 

Answer: There is nothing better than relational databases/DBMSs for conceptual models that focus on relationships among groups of entities, rather than  on relationships among individual entities (e.g., social networks).


Note: I will not publish or respond to anonymous comments. If you have something to say, stand behind it. Otherwise don't bother, it'll be ignored.





No comments:

Post a Comment

View My Stats