ORDER BY column_name: The Relational Database as Pervasive Cultural Form
1. ORDER BY column_name
The Relational Database as Pervasive Cultural Form
Bernhard Rieder
University of Amsterdam
Media Studies
2. Starting Point
Despite their omnipresence, both database technology and actual
databases are understudied.
Work in the humanities and social sciences:
- Sociological implementation studies (ERP, …)
- Historical work on companies and packages
- Conceptual work on software as medium
- Work on classification, lists, etc.
- Governmentality, techniques of government, surveillance,…
Next to a steady deluge of technical literature (computer science,
management, etc.).
3. An Approach Focused on Database Technology
Simondon (1958):
- technical objects, like art, have meaning, not only use
- technical rationality is not univocal
Technology is thinking and speaking in the medium of function.
Just because we know how something works, does not mean that we
know what it does. It needs to be interpreted.
Part One: Core Features of the Relational Database Model
Part Two: Relational Database Modeling
Part Three: A Pervasive Cultural Form
4. Preliminary Definitions
Database model: method of data organization a DBMS implements
=> hierarchical, network, relational, object -oriented, graph,….
DBMS: database management system
=> IBM DB2, Oracle DB, mySQL, PostgreSQL, MongoDB, neo4j, …
Data model: the conceptual (semantic) model for a specific database
=> entity-relationship model, database schema, …
Database: concrete set of organized data stored in a DBMS
=> healthcare, client database, storage backend for web platform, etc.
5. Database Models
# Prehistory: File Management Systems, Report Generators
# Navigational approach (record-at-a-time):
- Hierarchical model (1960s, example: IBM IMS)
Modern equivalent: XML, some noSQL
- Network model (1960s, example: GE IDS)
Modern equivalent: XML (with key/ keyref), graph databases
# Declarative approach (set-at-a-time):
- Relational model (1970s, example: Oracle DB, IBM DB2)
# Others: Object-oriented, object-relational, noSQL, graph, etc.
6. Part One: Core Features of the Relational Database Model
Universality principle: every mature database model can
accommodate every conceivable data model. But how?
Differentiation is introduced through variation in local requirements:
domain fit, end user profile, ease-of-use, performance, cost, integrity, maturity,
support, compatibility, interoperability, human resource availability, etc.
1) A simple and universal data structure: the relation
2) Data independence
3) Logical declaration instead of procedural navigation
4) A different form of reasoning about DBMS
7. 1) A Simple and Universal Structure: the Relation
Basis: adaptation of relational algebra (first-order logic) to databases.
A relation is a set of rows (tuples) with the same columns (attributes)
and types (domains).
"[R]elation is basically just a mathematical
term for table." (Date 2004)
Everything is stored in tables; query results are tables as well .
Complex data models are created by connecting tables via primary key
/ foreign key relationships.
10. 2) Data Independence
"Future users of large data banks must be protected from having to know how the
data is organized in the machine." (Codd 1970)
(Physical) data independence means that the logical structure of data
is decoupled from its physical structure in storage. Users interact with
the logical structure only, "machine questions" are blackboxed.
Relationships between data entities (JOIN) are no longer handled by
memory pointers but through integration at runtime (primary/foreign
key relationships or queries).
11. 3) Logical Declaration Instead of Procedural Navigation
"[T]here is also a large class of users who, while they are not computer specialists,
would be willing to learn to interact with a computer in a reasonably high -level, non-
procedural query language. Examples of such users are accountants, engineers,
architects, and urban planners. It is for this class of users that SEQUEL is intended. "
(Chamberlin & Boyce 1974)
All interactions with data are based on logical declaration and not
algorithmic (procedural) navigation.
Retrieving data as asking a question to an "oracle" rather than creating
a pathway to a storage location.
SQL becomes "intergalactic data-speak" (Stonebraker 1993).
13. 4) A different form of reasoning about DBMS
Mathematical elegance and simplicity vs. engineering pragmatism.
Logic is power beyond rhetoric.
A mathematical way of guaranteeing integrity and consistency in cases
of data modification, simultaneity, conceptual change, etc.
=> make DBMS design amendable to mechanization and proof
=> commitment to a method, not an ontological account!
A shift in technology and requirements
=> hardware performance rises, cost decreases
=> increasing bureaucratic complexity (data model and use)
14. Conclusions for Part One
From the 1980s on, the relation model becomes dominant.
Simplicity, uniformity, and integrity of the relational model allows for it
to deal with higher organizational complexity. It moves technological
expression much closer to other management techniques and practices.
SQL does not become an end-user language but its universality allows
for the emergence of new professions in between system programmer
and management: the database *admin, analyst, modeler, …+.
Standardization is pervasive and significant:
- technical: interoperability, a new market for analytics, etc .
- cognitive: mobility of skills, techniques, practices, mindsets, …
15. Part Two: Relational Database Modeling
The relational approach is not only a model for designing DBMS, but
also a set of concepts and methods for creating data models.
Modeling, formalization: "capturing" the real world in a data model.
Relational model is "semantically impoverished" (Stonebraker 1993)
because there are only relations, difficult e.g. to model classes.
Example: difficult to model a tree, easy to derive a hierarchy from data.
A complex combination of decomposition and composition that
emphasizes "conceptual atomism".
16. Creating a Data Model
The relational model is associated
with methods, strategies and best
practices for data modeling.
The relational model only shines if
atomization is fully realized.
Two elements of the formalization
process:
- conceptual modeling
- normalization
(Conolly et al. 1996)
20. Normalization
Some basics:
- No duplicates
- Record (row) order unimportant
- Attribute (column) order unimportant (left to right).
- All attribute values are atomic
Additional "normal forms" proceed by specific trials.
Remove vulnerability to update anomalies, etc.
Conceptual atomism: there are irreducible objects of the same kind.
21. Composition
Composition (of "atoms") always happens through data in the
relations themselves (integration at runtime). We can distinguish two
forms:
- by modeling (primary / foreign key, connecting tables, etc.)
- by query (e.g. data range)
Orderings are either modeled in data or derived from data. Both are
layers.
Normalization reduces expressive power on the level of the unit and
extends expressive power on the level of composition.
22. Composition by SQL Query
Normalization shifts expressive power to the query.
SELECT * FROM table_name WHERE condition
ORDER BY column_name
* = columns (e.g. name), counting, math functions, etc .
Any relational database is already a full-fledged analytics package.
This is the "intelligence" of the relational model, a model of knowing.
23. Conclusions for Part Two
The relational model is connected to a set of standardized techniques,
methods, and practices.
Relational DBMS are boundary objects (Star & Griesemer 1989) and
the relational model creates trading zones (Galison 1997) between
organization, departments, individuals, etc.
Conceptual and methodological atomism implies a movement of
purification that enhances not only coherence and integrity, but also
"calculative agency" (Callon & Muniesa 2005).
24. Part Three: A Pervasive Cultural Form
What kind of cultural form?
A three step argument:
- A tool/instrument for cognition
- A calculative device
- A mechanism for governance
25. A Cognitive Tool
Goody (1977) analyzes the list as "a special kind of lever on 'reality'", a
cognitive technique that has two principal properties. By arranging
words visually in space:
- it allows to manipulate, order, reorder, classify, etc.
- it decontextualizes, reduces complexity, eliminates "frames of
reference", etc.
Two ways in which the relational model goes further:
- software introduces a different performativity
- calculative agency is significantly extended
26. Calculative Agency
DBMS make culture "calculable". The calculative capacities provided
by the relational model are particularly powerful.
Calculation must be understood in a wider sense: commensuration
(Espeland & Stevens 1998), standardization, quantification, embedding
in relational algebra, etc.
"Calculative agency will be all the more powerful when it is able to: a) establish a
long, yet finite list of diverse entities; b) allow rich and varied relations between the
entities thus selected, so that the space of possible classifications and
reclassifications is largely open; c) formalize procedures and algorithms likely to
multiply the possible hierarchies and classifications between these entities. As this
calculative power depends on the equipments that agencies can rely upon, we can
easily understand why it is unevenly distributed among them." ( Callon & Muniesa
2005)
27. A Technique for Governing
This extension of calculative agency encounters a larger shifts:
- the rise of network economies
- the success of (neo)liberal techniques of governing
- the change in management techniques
Rosabeth Moss Kanter, "When Giants Learn to Dance", 1989
DBMS allow organizations to "support people's mobility without
relaxing monitoring." (Boltanski & Chiapello 1996)
The relational model is the perfect ally for " knowing capitalism"
(Thrift 2005) and "liquid modernity" (Bauman 2000).
28. Conclusions
# The relation model purifies and makes calculable
# The relational model changes who defines, closes the rift between
management and IT, "demediation" of control?
# The relational model plays an important role in standardization of
organizational processes.
# Takes part in reconfiguring the social.
Hinweis der Redaktion
We can "stutter" in technology.
no lists, bags, links, sets, arrays, maps, trees, etc.
Could put many other things, timetable, etc.
Physical location matters: <title> is a child of <workshop> because it is placed in this position in the file.