Topics (384k) Articles (398k) Users (410) Discussions (242) Comments (383) Files (13k) New article
A block transferred between storage and memory; database query plan costs are often estimated by the number of such transfers.
A database transaction groups database operations into a unit that can be committed or rolled back. Transaction atomicity means that its updates take effect together or not at all. Transaction durability concerns retaining an acknowledged committed result after a failure; transaction isolation controls which effects concurrent database transactions may observe.[ref]
Transactions in the PostgreSQL documentation. version 18, section 3.4, all-or-nothing updates, permanent recording and visibility
For example, transferring seven units from an account with balance twenty to one with balance five should produce balances thirteen and twelve. A failure after only the debit must not leave thirteen and five as a completed transfer. In SQL, a transaction block uses
BEGIN, then the related updates, then COMMIT; ROLLBACK abandons the uncommitted changes.[ref]Isolation is a separate question from grouping statements. Two concurrent transfers can each read an old balance before either writes. A correct application must select suitable transaction isolation or locking and handle possible conflicts; merely putting the statements in a database transaction does not establish every desired invariant. The corresponding database schedule records their interleaving.
An entity-relationship model describes identifiable entities, their database attributes and the relationships between them before committing to a physical database layout. Entity types classify the objects being recorded; relationship types describe associations, possibly with their own database attributes. Peter Pin-Shan Chen developed the model as a way to retain the meaning of data while relating several existing database models.[ref]
The Entity-Relationship Model-Toward a Unified View of Data by Peter Pin-Shan Chen. sections 1–2.3, entities, relationships, attributes and multilevel views
For example, a laboratory records scientific instrument entities and measurement entities, with a relationship saying which scientific instrument produced each measurement. An scientific instrument's serial number is an identifying database attribute. A calibration date can describe an scientific instrument, while a usage duration can describe a particular relationship occurrence. Distinguishing these placements prevents unrelated facts from being conflated.
Cardinality and participation constraints add rules: every measurement might require exactly one scientific instrument, while an scientific instrument can produce zero or many measurements. An entity-relationship diagram records these choices. Translating the design to a relational schema introduces database relations, identifiers and appropriate foreign keys; the diagram itself does not require a particular index or file structure.
A constraint requiring stored identifiers or references to denote valid represented entities, except for explicitly permitted absent-reference markers. For a node set with successor identifiers, integrity can require each nonnull successor identifier to equal the identifier of some node in . This is separate from identifier uniqueness and from order constraints on values along edges.
A decimal counter stores a nonnegative integer using an array of base-ten digits, with the least significant digit first. Increment resets trailing nines and increases the next digit, or wraps modulo if all digits are nines. Starting at zero, the exact number of digit changes in increments is . This is an aggregate analysis proving a constant amortized cost per increment under unit-cost digit updates. An arbitrary initial value contributes an additional in Big O notation.
A B+ tree is a balanced search tree designed to keep each vertex in a storage database page. Internal vertices contain separator keys and child references; leaf vertices contain the indexed records or references to them. All leaves occur at the same depth, and linked leaves support ordered scans. PostgreSQL's index implementation illustrates this separation between leaf record references and internal downward references.[ref]
A large fan-out reduces storage accesses: with a fixed positive lower bound on nonroot internal fan-out, the height is . A database query first descends to the leaf containing a boundary key, then follows leaf links for a range. Separator keys guide navigation; their copies do not replace the leaf records.
For example, a root separator can direct keys below twelve to leaf and keys at least twelve to leaf . Searching for seventeen descends right. A range query from eight through seventeen starts in the left leaf and continues right. B+ tree node splits preserve the equal-depth structure as records are inserted.
A skip list stores an ordered sequence in a bottom linked list, with successively sparser linked lists above it. Searching moves right while the next key is too small, then down a level. Randomly chosen node heights give logarithmic expected search and update time complexity with a suitable height policy. Repeated keys require distinguishing equal-valued nodes by identity when removing their links.
Represent a finite set by a list of its elements. Allowing repeated elements makes set union cheap by list concatenation; imposing uniqueness requires membership checks. A representation sorted by a total order and containing no duplicates permits set union and set intersection by a simultaneous scan in linear time. These are different representation invariants for the same abstract set.
A cryptographic key used for one communication session or bounded context. Its freshness and association with the intended peers need authentication; the fact that it arrives in an encrypted message does not by itself establish either property.
A cryptographic protocol specifies an interaction between parties using cryptographic operations to achieve a security property under stated assumptions. A key-exchange protocol, for example, aims to establish a shared secret while controlling what an adversary can learn or alter. Messages need meanings, order, identities and session context in addition to encryption or signatures. A sound primitive does not by itself make every composition secure: replaying a valid message in the wrong session can break an otherwise plausible exchange. Correctness and security depend on the adversary model and the exact transcript rules.
A symbolic adversarial model of Danny Dolev and Andrew Yao granting control of the network while treating cryptographic operations as ideal constructors and destructors. An adversary may split unprotected tuples, replay messages and encrypt with known public keys, but cannot decrypt without the required key. Separate encrypted components are not automatically bound to adjacent clear fields.
An attack using observed ciphertexts without supplied corresponding plaintexts. Recognisable message redundancy or publicly testable relations can sometimes provide key-testing predicates.
An attack using one or more known plaintext–ciphertext pairs, without necessarily controlling the plaintexts.
An attack in which an adversary selects plaintexts and obtains their encryptions, possibly choosing later requests adaptively.
Trying candidate keys and testing them against known plaintext–ciphertext pairs or another available verification condition. A uniformly selected key in a space of size appears at average position in a fixed enumeration.
A process algebra describes interacting systems through CSP events, composition operators and equations relating their behaviours. Communicating sequential processes is one such framework.
A Scala library for constructing communicating concurrent processes with typed message-passing channels, parallel composition and guarded alternation.[ref]
Rules and mechanisms deciding which subjects may perform which operations on protected objects. Discretionary access control permits designated owners to grant rights; the Bell-LaPadula model instead constrains information flow by classification.
Pinned article: Introduction to the OurBigBook Project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
Intro to OurBigBook
. Source. We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivativeVideo 2. OurBigBook Web topics demo. Source. - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 2. You can publish local OurBigBook lightweight markup files to either OurBigBook.com or as a static website.Figure 3. Visual Studio Code extension installation.Figure 5. . You can also edit articles on the Web editor without installing anything locally. Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension. - Infinitely deep tables of contents:
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact





