Fact-checked by Grok 2 weeks ago

IBM System R

IBM System R was a pioneering relational database management system (RDBMS) developed by IBM's San Jose Research Laboratory as an experimental project from 1974 to 1979, implementing F. Codd's relational data model through a full-scale, multiuser that proved the viability of relational technology for production environments. The system introduced key innovations, including the Structured English QUEry Language (, later renamed SQL due to issues), which provided a high-level, declarative for querying and manipulating stored in tables based on values rather than physical links. The project unfolded in three main phases: Phase Zero (1974–1975) created a single-user using an existing to test basic relational concepts; Phase One (1976–1977) built a robust, multiuser system with relational storage () and data system () components, incorporating indexes, locking mechanisms, and recovery features; and Phase Two (1978–1979) involved performance evaluations at sites and external user trials to assess scalability for databases up to 200 MB and 10 concurrent users. Key contributors included and , who co-invented SQL; Patricia G. Selinger, who advanced cost-based query optimization; and others like Morton M. Astrahan and James N. Gray, working under the direction of W. F. King. System R's design emphasized , allowing users to interact with logical views without navigating physical structures, and it demonstrated efficient query processing through a compilation-based optimizer that reduced execution overhead by up to 80% for complex transactions. Performance benchmarks showed it handled queries and updates effectively for experimental workloads, though it highlighted challenges like I/O bottlenecks in joins and locking convoy issues in multiuser scenarios. Despite at to fully replace hierarchical systems like IMS, System R's success validated relational principles, directly influencing the development of in 1983 and establishing SQL as an industry standard adopted by competitors such as . Its legacy endures in modern RDBMS architectures, underscoring the shift from navigational to declarative that powered the multibillion-dollar database industry.

History

Inception and Goals

The inception of IBM System R traces back to Edgar F. Codd's seminal 1970 paper, "A Relational Model of Data for Large Shared Data Banks," which proposed organizing data into tables with relationships defined by values rather than physical links, aiming to achieve and simplify user access to large databases. This theoretical framework challenged existing hierarchical and network models, inspiring IBM researchers to explore its practical viability. In 1974, amid internal debates at over database architectures, the San Jose Research Laboratory launched System R as a research prototype to implement and test the . The company was heavily invested in its Information Management System (IMS), a hierarchical database dominant in , which prioritized performance through navigational access but lacked flexibility and . prevailed within regarding the relational approach's ability to match IMS's efficiency for production workloads, prompting the need for an empirical demonstration to resolve these concerns and potentially shift corporate strategy. The primary goals of System R were to prove the relational model's usability in real-world production environments, develop a high-level for non-programmers, and rigorously evaluate its performance for tasks. By building a complete, industrial-strength system, the project sought to address doubts about scalability and functionality, ultimately influencing IBM's future database products.

Project Phases

The development of IBM System R proceeded through three principal phases, each building on the previous to , refine, and evaluate the . These phases, spanning from 1974 to 1979, focused on iterative , testing, and to assess the feasibility of the for practical use. Phase Zero (1974–1975) marked the initial effort, emphasizing the usability of the early interface. During this period, a single-user was developed using the XRM manager to implement a subset of , supporting basic queries, updates, and dynamic relation creation but lacking joins, , or recovery mechanisms. The focus was on demonstrating the benefits of storing metadata in catalogs and evaluating intuitiveness, with demonstrations highlighting issues like optimizer inefficiencies in handling identifiers. This phase's code was ultimately discarded after evaluation, but it provided critical insights into SQL enhancements and data strategies. Phase One (1976–1977) expanded the prototype into a full-function, multiuser system, introducing key production-ready features. The Relational Storage System () and Relational Data System () were developed to handle multiuser access under environments like VM/CMS or MVS/TSO, incorporating locking for concurrency, recovery mechanisms, views, and authorization controls. This phase supported interfaces in , , and standalone queries, with an emphasis on a compilation-based approach for efficient SQL execution. The first customer installation occurred at in June 1977, marking a in transitioning from research to applied testing. Phase Two (1978–1979) shifted to field evaluations and performance assessments at IBM's San Jose Research Laboratory and selected customer sites. Experimental installations were deployed at three external customer locations to gather user feedback on SQL usability, system performance, and subsystem reliability, identifying issues such as the "convoy phenomenon" in locking. This phase involved extensive testing that confirmed the relational model's viability but revealed limitations in scalability for certain workloads. User input drove refinements like the addition of EXISTS and LIKE operators to SEQUEL, ultimately leading IBM to abandon further internal development of System R in favor of commercial products like SQL/DS. The project's timeline highlights these sequential advancements:
  • 1974: Phase Zero begins with SEQUEL interface development.
  • Mid-1975: Phase Zero concludes; prototype evaluated and code discarded.
  • Late 1975: RSS construction starts, informed by XRM experiences.
  • 1976: Phase One initiates with RDS development and compilation strategy proposal.
  • 1977: Multiuser prototype completes; first installation at Pratt & Whitney in June.
  • 1978–1979: Phase Two evaluations at IBM and customer sites; project concludes in 1979 without further internal advancement.

Key Personnel and Collaborations

The IBM System R project was fundamentally shaped by Edgar F. Codd, who served as the theoretical leader and primary advocate for the relational data model that underpinned the entire effort. Codd's 1970 paper introducing the relational model provided the conceptual foundation, influencing the project's design decisions from inception. A pivotal contribution came from Donald D. Chamberlin and Raymond F. Boyce, who co-designed the SEQUEL query language as the high-level interface for System R. Their 1974 work outlined SEQUEL's structured English-like syntax for data manipulation, enabling user-friendly relational queries. Tragically, Boyce was killed in 1974 at age 27 due to a brain aneurysm, shortly after the language's initial development. Implementation efforts were led by a core team at IBM's San Jose Research Laboratory, including Patricia G. Selinger, who developed key optimizer algorithms for access path selection; Morton M. Astrahan, responsible for and early prototypes; Mike Blasgen, who advanced and join methods; and Jim Gray, who designed the locking and subsystems to ensure transaction integrity. These individuals collaborated closely within the laboratory's Research Division, integrating components like the (RDS) for query processing and the Relational Storage System (RSS) for data management. While System R was an internal IBM initiative with no formal external partnerships, it drew influences from broader academic research on relational databases and inspired parallel university-led projects, such as Ingres at the , which adopted similar relational concepts for its open-source implementation.

Technical Design

Relational Model Implementation

IBM System R implemented Edgar F. Codd's by adopting as the primary , consisting of (rows) representing individual records and attributes (columns) defining the properties of those records. For instance, a such as EMP(EMPN0, NAME, DNO, JOB, SAL, MGR) stored where each encapsulated a complete employee entry, enabling declarative access without explicit navigation. This structure was realized through the Relational Data System (RDS) subsystem, which managed in variable-length records embedded directly within to minimize overhead. To achieve a self-describing database, System R stored its system catalog—containing about relations, attributes, and authorizations—as ordinary relations within the database itself. These catalog relations were automatically maintained and queryable, allowing the system to introspect its own structure for purposes like query optimization and schema validation. External names provided by users were mapped to internal system-generated identifiers via these catalogs, ensuring flexibility in evolution without altering stored data. At the relational level, System R supported primary keys to uniquely identify tuples within a , such as using PARTNO in a parts , and foreign keys to establish between relations, exemplified by linking supplier and part numbers in pricing tables. Integrity constraints were enforced declaratively through the data control subsystem, which handled assertions for data consistency, alongside locking mechanisms to prevent violations during concurrent access. rules were also integrated at this level, restricting access to relations or attributes based on user privileges stored in the . Unlike hierarchical systems such as IMS or network models like , System R explicitly rejected navigational access methods that relied on user-visible pointers or links, instead promoting a high-level, declarative focused on set-oriented operations. This design emphasized operations like joins and projections over entire relations, allowing users to specify what data they wanted without detailing how to traverse the storage structure. served as the primary for these set-oriented queries on the relational structures. In its early phases, System R had limitations, including no support for complex data types beyond basic scalars. These constraints reflected the project's focus on validating core relational principles in a production-like environment before expanding to advanced features.

SEQUEL Query Language

The SEQUEL (Structured English QUEry Language) was developed as the primary query interface for IBM's System R management system prototype during 1974 and 1975. It was designed to provide a high-level, English-like syntax for users to access and manipulate data in , drawing from Codd's while emphasizing ease of use for both programmers and non-experts. Originally named to reflect its structured, English-oriented approach, the language was later renamed SQL due to a trademark conflict with a hardware product called SEQUEL. A core feature of was its declarative syntax, which allowed users to specify desired results using operations such as SELECT for row filtering, for column selection, and JOIN for combining relations. This syntax supported advanced capabilities including views (virtual tables simplifying complex queries), aggregates (functions like and AVG for summarizing data), and embedded queries (subqueries nested within primary statements to express intricate conditions). For instance, the query SELECT * FROM EMP WHERE SALARY > 10000 retrieves all employee records with salaries exceeding 10,000, demonstrating the language's straightforward tabular operations equivalent to first-order predicate calculus without explicit quantifiers. SEQUEL's non-procedural nature distinguished it from earlier navigational database languages, enabling users to describe what data was needed—such as specific attributes and conditions—without specifying how the system should retrieve or process it, thereby shifting complexity to the . This design promoted flexibility and reduced errors in query formulation, as seen in examples like PROJECT EMP OVER NAME, SALARY WHERE AGE > 30, which lists names and salaries for employees over age 30. The language evolved progressively within System R's phases: an initial prototype subset was implemented in Phase Zero (1974–1975) using a simple relational memory (XRM) for basic queries and updates, followed by full integration in Phase One (1976–1977) with support for multiuser access and joins. For complex tasks, such as finding the minimum price for a part category, a query like SELECT MIN(PRICE) FROM PRICES WHERE PARTNO IN (SELECT PARTNO FROM PARTS WHERE NAME = 'BOLT') illustrated embedded query usage. statements were compiled into executable form during these phases to interface with System R's subsystems.

System Subsystems

System R's architecture was divided into two primary subsystems: the and the . The RDS provided the high-level interface for data manipulation, definition, and control, while the RSS managed low-level storage, buffering, and concurrency. These subsystems interfaced through the Relational Data Interface (RDI) and Relational Storage Interface (RSI), enabling a modular design that supported and multi-user access. The RSS handled physical storage management, including space allocation on disk devices, buffer pooling, and access to relations stored as segments of fixed-size pages. It supported relation scans by sequentially accessing all data pages within a segment, allowing efficient full-table retrieval without indexes. For selective access, the RSS implemented indexes, known as "images," which provided both associative searches on key values and sequential scans in sorted order; each relation could have multiple such indexes on different field combinations to optimize query performance. Recovery in the RSS utilized shadow paging, where each segment maintained current and shadow page maps; updates created new page versions, preserving the old map for rollback in case of transaction failure, thus avoiding the need for extensive log replay during aborts. The managed relational semantics at a higher level, including the creation and manipulation of user views defined through statements; these views were stored as pre-optimized packages for reuse, promoting by shielding users from physical storage details. Authorization was enforced via and REVOKE commands, which assigned capabilities such as READ, INSERT, , and DELETE to users or groups on relations or views, with an optional WITH OPTION to propagate privileges. Integrity constraints were supported through assertions—declarative rules checked at commit or immediately if specified—ensuring relational without procedural code. Concurrency control in System R was primarily handled by the RSS's locking subsystem, which operated on a hierarchy of granularities: database (entire segments), table (relations), page, and tuple levels. This multi-granularity approach used intention locks (e.g., intent-shared or intent-exclusive) to efficiently manage locks at higher levels without enumerating all subordinates, reducing overhead in multi-user environments. Three isolation levels were provided: Level 1 permitted dirty reads with minimal locking for high concurrency but low consistency; Level 2 ensured clean reads by acquiring and releasing locks dynamically, preventing non-repeatable reads but allowing phantoms; and Level 3 enforced full serialization by holding locks until transaction commit, guaranteeing repeatable reads and absence of phantoms at the cost of reduced concurrency. Predicate locking was not implemented due to its implementation complexity and potential for excessive overhead; instead, the system relied on locking at tuple, page, or index entry levels to approximate isolation. Deadlock detection was performed periodically via a centralized monitor. Recovery mechanisms in System R combined write-ahead logging (WAL) with checkpointing to ensure durability and atomicity. Under WAL, all modifications were logged to a dedicated disk segment before being applied to the database pages, recording before and after images of affected data for both redo and undo operations; logs were periodically archived to tape for long-term audit trails and full system recovery. Checkpointing occurred frequently on disk to flush dirty buffers and record the log position, enabling quick restart by redoing only post-checkpoint actions, while infrequent tape-based checkpoints supported recovery from media failures by incrementally copying pages. This hybrid approach allowed ongoing transactions during checkpoints, balancing recovery time with system availability.

Query Processing and Optimization

Access Path Selection

The access path selection in IBM System R was handled by a cost-based query optimizer that automatically chose efficient execution plans for user queries specified in , without requiring manual hints on paths or join orders. This optimizer represented a pioneering approach in management systems, as it was the first practical implementation to systematically evaluate multiple access strategies for both simple single-relation queries and complex multi-relation joins. At its core, the optimizer employed a dynamic programming algorithm to enumerate and select optimal join orders and access paths. For a query involving n relations, the algorithm iteratively built solutions for all subsets of relations, constructing a tree of partial plans and selecting the lowest-cost path for each subset based on prior computations. This exhaustive enumeration was feasible for up to 15 relations, with optimization times typically under a second for queries with 8 tables on contemporary hardware like the IBM 370/158. However, for more complex queries exceeding this threshold, the exponential growth in search space posed significant challenges, often leading to heuristic approximations or timeouts. The cost model focused on minimizing a composite estimate of resource usage, primarily page fetches (I/O operations) and weighted random selective index (RSI) calls (CPU operations), using the formula COST = PAGE FETCHES + W * RSI CALLS, where W represented a tunable weight for CPU relative to I/O. These estimates relied on statistics stored in the system catalog, including relation cardinality (number of tuples, NCARD), page counts (TCARD), index levels and entries (NLEAF and NINDX), and selectivity factors (F) derived from predicate constraints. For instance, selectivity for equality predicates on indexed columns was approximated as F = 1/ICARD, where ICARD denoted distinct values in the index, enabling predictions of intermediate result sizes without full scans. To manage the vast search space, the optimizer incorporated heuristics such as restricting plans to left-deep join trees, which chained relations sequentially from left to right, and prioritizing "interesting orders" that could satisfy requirements for GROUP BY, ORDER BY, or subsequent joins without additional sort operations. These constraints reduced complexity while preserving near-optimal plans in most cases, deferring Cartesian products until necessary and favoring indexed accesses over sequential scans when selectivity warranted it. Preliminary evaluations demonstrated that this approach selected paths within 10-20% of the actual minimum cost, even with imperfect statistics, underscoring its robustness for practical workloads.

Compilation and Execution

In IBM System R, the compilation process for SQL statements employed a preprocessor that analyzed embedded SQL code within host language programs, such as PL/I or COBOL, and translated the statements into machine-language access modules for efficient static binding. This approach bound database object names and optimized access paths at compile time, generating callable routines from approximately 100 predefined code fragments to minimize runtime overhead. The resulting access modules were invoked during program execution, interfacing with the Relational Data System (RDS) and Research Storage System (RSS) layers to handle data retrieval without repeated parsing or optimization. The execution engine in System R utilized a record-at-a-time model, where operators processed incrementally through the , enabling pipelined execution for compatible operations. For example, join operations typically employed nested loops, scanning the outer and probing the inner for each tuple via or , as selected by the optimizer's access path choices. This iterator-style interface supported efficient data flow between operators, with the managing low-level storage operations like scans and while providing transaction-level abstractions. Compared to interpretive execution in earlier prototypes, the compilation strategy significantly reduced overhead for repeated queries by shifting , validity checking, and optimization to the preprocessing phase. For instance, compilation of a simple SELECT statement required about 13.3 milliseconds of with no I/O, a cost quickly amortized during execution. This efficiency was particularly beneficial for transaction-oriented workloads, where access modules could be reused across multiple invocations. Early versions of System R, such as Phase Zero, lacked dynamic SQL support and relied on , but later phases introduced facilities like PREPARE and EXECUTE statements through the User-Friendly Interface (UFI) for query compilation at . A key limitation was the need for recompilation of access modules upon changes, tracked via lists in the system catalog to ensure validity, which could introduce maintenance overhead in evolving databases.

Performance Evaluation

Performance evaluations of IBM System R were conducted primarily during Phase Two (1978-1979) at the San Jose Research Laboratory and external sites, focusing on and for production-like workloads. The system was tested on experimental typically smaller than 200 MB (one 3330 ) and accessed by fewer than ten concurrent users, reflecting its research-oriented scope rather than enterprise-scale deployment. Benchmarks highlighted System R's strengths in handling ad-hoc queries and short transactions, where query compilation into removed parsing and validation overhead, enabling efficient execution. For instance, a simple fetch query required 13.3 ms for , 40 ms for access path selection, 10.1 ms for , and 1.5 ms per record fetched with 0.7 I/Os per record; a more complex join query took 20.7 ms , 73.2 ms selection, 19.3 ms generation, and 8.7 ms per record with 10.7 I/Os per record. In typical short transactions, approximately 80% of instructions were executed by the Relational Storage System (RSS), with the remaining 20% handled by the access module and application program, demonstrating low overhead for repetitive operations. However, interactive response times degraded for complex joins involving multiple tables, often extending to several seconds due to normalization trade-offs that increased processing complexity. Key lessons from these evaluations underscored the benefits of for speeding up execution by eliminating interpretive overhead, though it introduced upfront costs unsuitable for infrequent queries. The optimizer's cost model, which minimized a weighted sum of I/Os and calls, often underestimated actual I/O expenses due to unpredictable buffer behavior and sorting operations, highlighting the need for more accurate statistics and refined models to improve path selection reliability. These insights influenced subsequent designs by emphasizing balanced trade-offs between compilation efficiency and real-world variability.

Legacy and Influence

Transition to Commercial Products

The success of System R's prototype demonstrated the viability of relational database technology, prompting to develop commercial products based directly on its innovations. In 1979, initiated the development of SQL/DS, the company's first commercial management system, targeted at the /VS operating system on midrange systems like the series. SQL/DS was released in 1981 for /VSE and VM/CMS environments, incorporating substantial portions of System R's codebase with minimal modifications. This was followed by DB2 in 1983, initially available in limited form for the operating system on mainframes, achieving general availability in 1985. Both products reused core elements from System R, marking 's entry into offerings for production use. Key components from System R were ported to these commercial systems to ensure reliability and performance in production settings. The query language, renamed SQL, was directly adapted, along with the relational data system (RDS) optimizer, which was transliterated from PL/I to PL/S with few alterations to preserve its optimization algorithms. Storage subsystems, including the RSS (relational storage system), were largely carried over unchanged, facilitating efficient and access paths in the new environments. These transfers allowed IBM development teams in Endicott and Santa Teresa to build upon proven research without starting from scratch, accelerating the path to market. To validate the technology's commercial feasibility, System R underwent pilots with external customers starting in 1977. A notable joint study occurred in 1977 with Aircraft, where the system was installed for of parts and supplies used in , marking one of the first external evaluations. Additional pilots with organizations like Pharmaceuticals and further tested scalability and usability, providing feedback that informed refinements for productization. These efforts confirmed System R's robustness beyond internal labs, paving the way for SQL/DS and DB2 deployments. The advent of these products signaled IBM's strategic shift from its dominant hierarchical IMS database, which had long held the enterprise market, toward embracing relational models. System R's demonstrated success—through pilots and metrics—convinced to invest in SQL/ and DB2 as complementary offerings. By the late 1980s, DB2 began competing effectively with IMS for workloads, reflecting IBM's broader commitment to relational technology while maintaining IMS support to avoid market disruption.

Contributions to SQL Standardization

IBM System R's development of the SEQUEL query language played a pivotal role in shaping the standardization of SQL as the dominant for relational databases. Initially introduced in , SEQUEL provided a user-friendly, English-like syntax for querying relational data, featuring operations such as SELECT for projection, JOIN for combining relations, and support for views to simplify complex queries. This language was first presented at the ACM SIGFIDET Workshop in , where demonstrations highlighted its practicality for relational data access, influencing early adoption and discussion within the database community. By 1976, an enhanced version, SEQUEL 2, extended the syntax to include data definition and manipulation capabilities, further promoting relational query paradigms through additional publications and prototypes. A key aspect of SEQUEL's path to standardization involved resolving naming conflicts. Originally standing for Structured English Query Language, SEQUEL was renamed to SQL (Structured Query Language) in the late due to a trademark dispute with the UK-based company, which had registered "SEQUEL" for an aircraft project. This rename, as recounted by co-inventor , involved shortening the name after receiving legal notice, preserving the core functionality while avoiding infringement. Early features like views, which allowed predefined query results to be treated as virtual tables, and equi-joins for merging datasets on matching keys, were integral to SEQUEL and carried forward into subsequent iterations. System R's prototype validation significantly influenced the ANSI X3H2 committee's work on the 1986 SQL standard (ANSI X3.135-1986). The committee, which included key figures from the System R project, adopted SEQUEL's core syntax—such as the declarative SELECT-FROM-WHERE structure—with minimal modifications, establishing it as the foundation for data manipulation and definition in relational systems. This standardization effort ensured portability across vendors, with SQL's relational operators and integrity constraints directly tracing back to System R's demonstrations of efficient query processing. Over the long term, System R's prototyping of SQL validated its viability for production environments, contributing to SQL's ubiquity in modern database management systems. By providing empirical evidence of relational query performance and usability, System R paved the way for SQL's adoption in commercial products and its evolution through successive ISO and ANSI updates, solidifying its role as the .

Broader Impact on Database Technology

System R's demonstration of the relational model's practical viability marked a pivotal shift in database technology, proving that relational systems could outperform and simplify development compared to prevailing hierarchical and network models. By implementing a complete management system (DBMS) with support for concurrent transactions and recovery, System R showed that relational approaches were not only theoretically sound but also efficient for real-world workloads, influencing the industry's transition away from CODASYL-style databases. This proof-of-concept encouraged widespread adoption of relational principles, as evidenced by the rapid emergence of commercial systems inspired by its architecture and findings. The project's innovations in query processing and optimization further advanced the field, establishing cost-based optimization as a of modern DBMS design. System R's optimizer, developed by Selinger and colleagues, evaluated multiple access paths using estimated costs derived from database statistics, significantly reducing query execution times compared to heuristic methods. This approach spurred extensive in query optimization techniques, including join ordering and index selection, which remain central to academic and industrial efforts today. Additionally, System R's emphasis on declarative query languages like (later SQL) fostered a cultural shift toward user-friendly, non-procedural interfaces, decoupling application logic from physical storage details and enabling . These elements promoted the development of cost-based optimizers in both academia and , standardizing efficient query evaluation across diverse systems. System R directly inspired several non-IBM relational systems, accelerating the commercialization of RDBMS technology. , released in 1979 by Relational Software Inc. (later ), was developed by based on publicly available System R papers, becoming the first commercially successful SQL-based RDBMS and predating IBM's own products. Similarly, the Ingres project at UC Berkeley, running parallel to System R from 1973, drew from relational concepts and influenced subsequent systems, while Sybase, founded in 1984 by former Ingres developers including Bob Epstein, adapted these ideas for client-server architectures. Later RDBMS like Sybase extended this lineage, incorporating relational storage and query paradigms. Echoes of System R's design persist in contemporary DBMS, underscoring its foundational role. Its adoption of structures for indexing enabled efficient range queries and order maintenance, a technique still used as the default index type in systems like and for primary keys and sorted access. Likewise, System R's multi-granularity locking hierarchy—allowing locks at database, table, and tuple levels with intent modes—addressed concurrency without excessive overhead, influencing transaction isolation mechanisms in modern engines such as 's MVCC and 's storage. These contributions, disseminated through over 40 published papers, continue to shape research directions in scalable, high-performance database systems.

References

  1. [1]
    A history and evaluation of System R | Communications of the ACM
    System R: An architectural overview. IBM Syst. J. 20, 1 (Feb. 1981), 41-62 ... PDF. View or Download as a PDF file. PDF. eReader. View online with eReader ...
  2. [2]
    The relational database - IBM
    (Larry Ellison's company Relational Software, later renamed Oracle, produced the first commercially available relational database in 1977). DB2 was first ...Missing: primary | Show results with:primary
  3. [3]
    6 The Rise of Relational Databases | Funding a Revolution
    In the early 1970s, two projects emerged to develop relational technology and prove its utility in practical applications. One, System R, began within IBM, and ...Missing: primary | Show results with:primary
  4. [4]
    [PDF] A Relational Model of Data for Large Shared Data Banks
    Future users of large data banks must be protected from having to know how the data is organized in the machine. (the internal representation). A prompting.Missing: inception | Show results with:inception
  5. [5]
    [PDF] A History and Evaluation of System R
    This paper describes the three principal phases of the System R project and discusses some of the lessons learned from System R about the design of relational ...
  6. [6]
    https://dl.acm.org/doi/10.1145/356663.356668
  7. [7]
    [PDF] The 1995 SQL Reunion: People, Projects, and Politics
    May 29, 1995 · he died on Father's Day in 1974. His daughter was only about nine ... made System R a success: Raymond's idea to compile rather than ...
  8. [8]
    https://dl.acm.org/doi/10.1145/320044.320083
  9. [9]
    System R: relational approach to database management
    This paper contains a description of the overall architecture and design of the system. At the present time the system is being implemented and the design ...Missing: project phases<|control11|><|separator|>
  10. [10]
    CS262a: System R & DBMS Overview - People @EECS
    Ellison's Oracle beats IBM to market by reading white papers. IBM releases multiple RDBMSs, settles down to DB2. Gray (System R), Jerry Held (Ingres) and ...
  11. [11]
    [PDF] The Design and Implementation of INGRES
    The currently operational (March 1976) version of the INGRES database management system is described. This multiuser system gives a relational view of data, ...
  12. [12]
    (PDF) System R: Relational Approach to Database Management
    System R is a database management system which provides a high level relational data interface. The systems provides a high level of data independence by ...
  13. [13]
    SEQUEL: A structured English query language - ACM Digital Library
    In this paper we present the data manipulation facility for a structured English query language (SEQUEL) which can be used for accessing data in an integrated ...
  14. [14]
    [PDF] Access Path Selection in a Relational Database Management System
    This paper describes how System R chooses access paths for both simple (single relation) and complex que- ries (such as joins), given a user specifi- cation of ...
  15. [15]
    System R: an architectural overview - ACM Digital Library
    This paper describes the overall architecture of the system, including the Relational Data System (RDS) and the Research Storage System (RSS). RDS is a data ...
  16. [16]
    [PDF] The Recovery Manager of the System R Database Manager
    Aug 30, 2000 · System R consists of two layers above the operating system. The RSS provides the transaction concept, recovery notions, and a record-at-a-time ...
  17. [17]
    https://dl.acm.org/doi/10.1145/320434.320440
  18. [18]
    [PDF] RDBMS Workshop: IBM - Computer History Museum - Archive Server
    Jun 12, 2007 · Research developed SQL and System R and the role that IBM's Research Division played in getting IBM to finally announce and deliver ...Missing: inception goals<|control11|><|separator|>
  19. [19]
    The 1995 SQL Reunion: People, Projects, and Politics - SQL/DS
    We were able to make a decision to go ahead and use System R as the basis for SQL/DS, and without that being a politically-incorrect decision. Which if we had ...
  20. [20]
    The 1995 SQL Reunion: People, Projects, and Politics - System R
    When we wrote the paper, it said, "System R: A Relational Approach to Database Management"; when it got published, the "A" went away. And the reason for ...
  21. [21]
    [PDF] The Business Value of DB2 UDB for z/OS - IBM Redbooks
    The first installation of System R was 1977 at Pratt and Whitney for inventory control of their parts and supplies that they were using to build jet engines ...
  22. [22]
    [PDF] Oral History Interview with Donald D. Chamberlin
    Oct 3, 2001 · Don Chamberlin is a research staff member at IBM Almaden Research ... At what point does it get renamed SEQUEL or SQL? Chamberlin: Well ...
  23. [23]
    50 Years of Queries - Communications of the ACM
    Jul 26, 2024 · In the early 1970s, work on relational database systems was underway at multiple IBM locations. ... A history and evaluation of System R.<|control11|><|separator|>
  24. [24]
    [PDF] System R: Relational Approach to Database Management
    System R is a database management system which provides a high level relational data interface. The system provides a high level of data independence by ...Missing: skepticism | Show results with:skepticism
  25. [25]
    What is Database Performance | MongoDB
    That changed with IBM's System R in the late 1970s; System R demonstrated that relational databases could be both practical and performant. It introduced ...
  26. [26]
    [PDF] History and Comparison of Relational Database Management ...
    ▫ Larry Ellison (IBM): read publications of the System R group => Oracle. ▫ sold SQL compatible product before IBM. ▫ 1980: ▫ IBM developed SQL/DS => mainframe ...
  27. [27]
    [PDF] An Introduction to Relational Databases - SciNet
    System R and Ingres: Two prototype relational database systems, System R and Ingres, were developed in the mid-1970s, laying the groundwork for future ...
  28. [28]
    [PDF] RDBMS Workshop: Ingres and Sybase
    Jun 13, 2007 · Abstract: Early employees of Ingres and Sybase talk about how both companies were started and how they developed. Those involved with Ingres ...<|separator|>
  29. [29]
    B-trees and database indexes - PlanetScale
    Sep 9, 2024 · B-trees are used by many modern DBMSs. Learn how they work, how databases use them, and how your choice of primary key can affect index ...Missing: R locking modern
  30. [30]
    CS262a: System R & DBMS Overview
    Ellison's Oracle beats IBM to market by reading white papers. · IBM releases multiple RDBMSs, settles down to DB2. · Relational Technology Inc (Ingres Corp), ...
  31. [31]
    [PDF] A survey of B-tree locking techniques - CMU 15-721
    IBM's System R project explored many transaction management techniques, including transaction isolation levels and lock duration, predicate locking and key ...