Group: information
Group: relationship information
Topic: b-trees
Topic: collection class
Topic: database change management
Topic: database implementation
Topic: database keys and indexing
Topic: database record
Topic: database schema
Topic: database queries, joins, and relational algebra
Topic: database transactions
Topic: design for change
Topic: information retrieval with queries
Topic: knowledge representation
Topic: object-defined names
Topic: object-oriented databases
Topic: set construction
Topic: set-oriented languages
Topic: tuples
Topic: uniform data model
| |
Summary
In the relational data model, data is addressed by a relation name, a primary key, and an attribute name, i.e., data is stored in a table of tuples which are identified by a subset of the relation's attributes. Data sets are defined by a query using selection, projection, and join.
The advantages of the relational model are 1) a simple data model that separates the logical structure from the physical structure, 2) operations defined on sets of tuples instead of individual records, and 3) several formal definitions and normal forms.
The disadvantages include 1) complex data structures require multiple relations which must maintain ad hoc constraints, 2) no simple model of order, 3) updates specified at the tuple level, 4) the same structure used for many kinds of information, 5) relationship by coexistence or by implicitly by joins, and 6) soft keys and null values cause difficulties. (cbb 1/90)
Subtopic: relational database
Quote: mathematical relations as foundation for commercial databases: no numbering, no ordering, no storage addresses, no sense of nextness
| Quote: relational model is for commercial and industrial databases; i.e., a large number of assertions of the same type [»coddEF_1990]
| Quote: fundamental laws of the relational model apply to all database management systems [»coddEF_1990]
| Quote: relational model treats entities and relations the same; unlike earlier models [»coddEF6_1970]
| Quote: Codd's relational algebra is like an algebra of punched cards; each card is a record; each step an operator, closed under composition; good abstraction [»grayJ6_2003]
| Subtopic: relationships
Quote: the relational model defines relationships in two ways: by symbol matching in joins and by coexistence in a tuple [»kentW_1978]
| Quote: relational model more flexible because relationships defined by joins [»smitKE10_1987]
| Subtopic: data maintenance
Quote: Codd developed relational databases to solve data-maintenance abnormalities due to failures in referential transparency [»cobbRH11_1990]
| Quote: need discipline of relational model to share large quantities of data by non-programmers acting independently
| Quote: explicitly represent and enforce all database issues of concern to the user community; not hidden in applications [»coddEF_1990]
| Subtopic: data independence
Quote: no "nextness" for rows or columns of a relation; both are position-independent [»coddEF_1990]
| Quote: relational model allows data independence between logical and physical aspects of database management [»coddEF2_1982]
| Quote: relational database handles placement of data and selection of access paths
| Quote: data description does not support collections of data; hard to change without impacting applications [»coddEF6_1970]
| Quote: avoid representational dependencies in data; e.g., ordering, indexing, and access path
| Subtopic: relation as data type
Quote: a relational database has only one type, 'relation', with get and put operations on field values
| Quote: every relation is a table, but a table may be a relationship, an entity, or attribute list [»kentW_1978]
| Quote: relational model easier to use because of tabular data and ad hoc queries
| Quote: relational model is structurally simple; gives a common understanding of data for all kinds of users [»coddEF2_1982]
| Quote: a relation is a subset of the Cartesian product of a set of domains; i.e., n-tuples of elements from each domain [»coddEF6_1970]
| Quote: a mathematical relation is an unordered set of tuples all of the same type [»coddEF_1990]
| Subtopic: database rows, columns, domains
Quote: each row of a relational table represents a tuple; ordering is immaterial; all rows are distinct [»coddEF_1990]
| Quote: a database column is a particular use of a domain; named to convey intended meaning without position or nextness [»coddEF_1990]
| QuoteRef: mcleDJ3_1976 ;;47 domains subset of reals or strings. normalized relations of tuples where each element is in corresponding domain eg name, age, occupation
| Quote: store simple domains as tables with homogeneous columns [»coddEF6_1970]
| Subtopic: duplicate rows
Quote: relations are not tables; e.g., they do not allow duplicate rows [»coddEF_1990]
| Quote: if allow duplicate rows, then all users need to agree on its meaning; no precise, context-independent interpretation [»coddEF_1990]
| Quote: SQL was based on the relational model, but it allows duplicate rows and corrupted relations [»coddEF_1990]
| Subtopic: universal relation
Quote: the universal relation misses useful queries that are not based on keys [»coddEF_1990]
| Subtopic: processing sets of records
Quote: in relational data bases, operations on individuals same as operations on sets; these are different in Algol-style languages [»casiRJ9_1983]
| Quote: relational model makes it easy to process sets of information in one operation [»coddEF2_1982]
| Quote: the relational model does not need iterative or recursive loops to extract information; few bugs and higher productivity [»coddEF_1990]
| Quote: select a record occurrence at the path level instead of the record level; this is effective, easy to use, and flexible [»rohdWF12_1979]
| Quote: LINQ defines operators for querying data in object collections such as XML and SQL; no change to the virtual machine [»bierGM10_2007]
| Subtopic: reorganizing a database
Quote: easily split independent sections of a database [»coddEF_1990]
|
Related Topics
Group: information (46 topics, 1160 quotes)
Group: relationship information (5 topics, 69 quotes)
Topic: b-trees (16 items)
Topic: collection class (11 items)
Topic: database change management (12 items)
Topic: database implementation (18 items)
Topic: database keys and indexing (18 items)
Topic: database record (22 items)
Topic: database schema (29 items)
Topic: database queries, joins, and relational algebra (34 items)
Topic: database transactions (27 items)
Topic: design for change (76 items)
Topic: information retrieval with queries (18 items)
Topic: knowledge representation (41 items)
Topic: object-defined names (15 items)
Topic: object-oriented databases (15 items)
Topic: set construction (20 items)
Topic: set-oriented languages (20 items)
Topic: tuples (17 items)
Topic: uniform data model (19 items)
|