Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 of 28

ORDER BY column_name: The Relational Database as Pervasive Cultural Form

2

Share

Download to read offline

My presentation from the "Lived Logics of Database Machinery" Workshop at the Wellcome Collection on June 28, 2012.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

ORDER BY column_name: The Relational Database as Pervasive Cultural Form

  1. 1. ORDER BY column_name The Relational Database as Pervasive Cultural Form Bernhard Rieder University of Amsterdam Media Studies
  2. 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. 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. 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. 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. 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. 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.
  8. 8. Workshop.sql: Data Model (EER Diagram 1)
  9. 9. Workshop.xml XML (hierarchical model) different concepts and syntax for data modeling. XML does not require/favor "homogeneous atomism". "Physical" location matters.
  10. 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. 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).
  12. 12. Workshop.xml SQL statement: SELECT * FROM organizers WHERE affiliation="Middlesex Uni" Navigate by: - semantic paths - structural paths (children, siblings,…)
  13. 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. 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. 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. 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)
  17. 17. Entity-Relationship Modeling Creating a "conceptual model" of the real environment. (Chen 1976)
  18. 18. Workshop.sql: Enhanced Entity-Relationship Diagram 1
  19. 19. Workshop.sql: Enhanced Entity-Relationship Diagram 2
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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.

Editor's Notes

  • 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.
  • ×