China
Africa
Explore chapters and articles related to this topic
Storage and databases for big data
Published in Jun Deng, Lei Xing, Big Data in Radiation Oncology, 2019
Tomas Skripcak, Uwe Just, Ida Schönfeld, Esther G.C. Troost, Mechthild Krause
Relational databases are known for strictly following the atomicity, consistency, isolation, durability (ACID) properties for database transactions and they act as ACID-compliant transaction managers. This prevents concurrent users from working with data in a conflicting way; however, this also comes with a performance penalty and limits the system-scaling ability. The approaches for scaling the database resources fall into two categories: vertical scaling (scale up) and horizontal scaling (scale out). This analogy originates from the typical positioning of hardware in a rack within a data center. Scaling up refers to the addition of new resources (e.g., storage space, memory) to the existing server within one rack, and scaling out refers to the addition of new server nodes to neighboring racks in the server room. Conventional relational databases normally scale up well, but their ability to scale out is limited. Moreover, scaling out relational databases often means losing ACID compliance, which is their biggest advantage in transactional workload scenarios.
Big Data in Medical Image Processing
Published in R. Suganya, S. Rajaram, A. Sheik Abdullah, Big Data in Medical Image Processing, 2018
R. Suganya, S. Rajaram, A. Sheik Abdullah
Document databases can scale horizontally very well for more than 1000 patients in the hospital. Data can be stored over many thousands of computers and the system will perform well. This is often referred to as sharding. Relational databases are not well suited to scaling in this fashion. Relational DBs are more suited towards scaling vertically (i.e., adding more memory, storage, etc.). Seeing as there’s a limit to how many resources one can fit inside one machine, there could come a point where horizontal scaling becomes the only option. Document stores don’t have foreign keys, like relational databases have. Foreign keys are used by relational databases to enforce relationships between tables. If a relationship needs to be established with a document database, it would need to be done at the application level.
General introduction
Published in Adedeji B. Badiru, Handbook of Industrial and Systems Engineering, 2013
The idea that database systems should present the user with a view of data organized as tables called relations was originally proposed by Codd (1979). Each relation is made up of attributes. Attributes are values describing properties of an entity, a concrete object in its reality. Furthermore, the connections among two or more sets of entities are called relationships. The idea of a key on a table is central to the relational model. The purpose of a key is to identify each row uniquely. A primary key is the attribute (or combination of attributes) that uniquely identifies one row or record. On the other hand, a foreign key is the attribute (or combination of attributes) that appears as a primary key in another table. Foreign key relationships provide the basis for establishing relationships across tables in a relational database.
Development of a worldwide ferry safety database utilizing relational database approach
Published in Journal of Transportation Safety & Security, 2019
Siyu Xu, Hao Hu, Roberta Weisbrod
Having identified the relevant entities, the next step is to recognize the logical connection among these entities, that is, the relationships. Because data are stored in multiple tables in a relational database, records are distinguished from each other through the primary key and relate to the corresponding records in other tables through the foreign keys. Here, the key means one or more attributes that determine other attributes.