• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ORDER BY column_name: The Relational Database as Pervasive Cultural Form

ORDER BY column_name: The Relational Database as Pervasive Cultural Form



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

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



Total Views
Views on SlideShare
Embed Views



2 Embeds 3

http://www.docshut.com 2
http://www.docseek.net 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • We can "stutter" in technology.
  • no lists, bags, links, sets, arrays, maps, trees, etc.
  • Could put many other things, timetable, etc.
  • Physical location matters: is a child of because it is placed in this position in the file.

ORDER BY column_name: The Relational Database as Pervasive Cultural Form ORDER BY column_name: The Relational Database as Pervasive Cultural Form Presentation Transcript

  • ORDER BY column_nameThe Relational Database as Pervasive Cultural FormBernhard RiederUniversity of AmsterdamMedia Studies
  • Starting PointDespite their omnipresence, both database technology and actualdatabases 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.).
  • An Approach Focused on Database TechnologySimondon (1958): - technical objects, like art, have meaning, not only use - technical rationality is not univocalTechnology is thinking and speaking in the medium of function.Just because we know how something works, does not mean that weknow what it does. It needs to be interpreted.Part One: Core Features of the Relational Database ModelPart Two: Relational Database ModelingPart Three: A Pervasive Cultural Form
  • Preliminary DefinitionsDatabase 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.
  • 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.
  • Part One: Core Features of the Relational Database ModelUniversality principle: every mature database model canaccommodate 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 relation2) Data independence3) Logical declaration instead of procedural navigation4) A different form of reasoning about DBMS
  • 1) A Simple and Universal Structure: the RelationBasis: 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 mathematicalterm 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.
  • Workshop.sql: Data Model (EER Diagram 1)
  • Workshop.xmlXML (hierarchical model)different concepts and syntaxfor data modeling.XML does not require/favor"homogeneous atomism"."Physical" location matters.
  • 2) Data Independence"Future users of large data banks must be protected from having to know how thedata is organized in the machine." (Codd 1970)(Physical) data independence means that the logical structure of datais decoupled from its physical structure in storage. Users interact withthe logical structure only, "machine questions" are blackboxed.Relationships between data entities (JOIN) are no longer handled bymemory pointers but through integration at runtime (primary/foreignkey relationships or queries).
  • 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 notalgorithmic (procedural) navigation.Retrieving data as asking a question to an "oracle" rather than creatinga pathway to a storage location.SQL becomes "intergalactic data-speak" (Stonebraker 1993).
  • Workshop.xmlSQL statement:SELECT * FROM organizers WHEREaffiliation="Middlesex Uni"Navigate by:- semantic paths- structural paths (children, siblings,…)
  • 4) A different form of reasoning about DBMSMathematical elegance and simplicity vs. engineering pragmatism.Logic is power beyond rhetoric.A mathematical way of guaranteeing integrity and consistency in casesof 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)
  • Conclusions for Part OneFrom the 1980s on, the relation model becomes dominant.Simplicity, uniformity, and integrity of the relational model allows for itto deal with higher organizational complexity. It moves technologicalexpression much closer to other management techniques and practices.SQL does not become an end-user language but its universality allowsfor the emergence of new professions in between system programmerand 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, …
  • Part Two: Relational Database ModelingThe relational approach is not only a model for designing DBMS, butalso 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 thatemphasizes "conceptual atomism".
  • Creating a Data ModelThe relational model is associatedwith methods, strategies and bestpractices for data modeling.The relational model only shines ifatomization is fully realized.Two elements of the formalizationprocess: - conceptual modeling - normalization (Conolly et al. 1996)
  • Entity-Relationship ModelingCreating a "conceptual model" of the real environment. (Chen 1976)
  • Workshop.sql: Enhanced Entity-Relationship Diagram 1
  • Workshop.sql: Enhanced Entity-Relationship Diagram 2
  • NormalizationSome basics:- No duplicates- Record (row) order unimportant- Attribute (column) order unimportant (left to right).- All attribute values are atomicAdditional "normal forms" proceed by specific trials.Remove vulnerability to update anomalies, etc.Conceptual atomism: there are irreducible objects of the same kind.
  • CompositionComposition (of "atoms") always happens through data in therelations themselves (integration at runtime). We can distinguish twoforms:- 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 arelayers.Normalization reduces expressive power on the level of the unit andextends expressive power on the level of composition.
  • Composition by SQL QueryNormalization 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.
  • Conclusions for Part TwoThe relational model is connected to a set of standardized techniques,methods, and practices.Relational DBMS are boundary objects (Star & Griesemer 1989) andthe relational model creates trading zones (Galison 1997) betweenorganization, departments, individuals, etc.Conceptual and methodological atomism implies a movement ofpurification that enhances not only coherence and integrity, but also"calculative agency" (Callon & Muniesa 2005).
  • Part Three: A Pervasive Cultural FormWhat kind of cultural form?A three step argument: - A tool/instrument for cognition - A calculative device - A mechanism for governance
  • A Cognitive ToolGoody (1977) analyzes the list as "a special kind of lever on reality", acognitive technique that has two principal properties. By arrangingwords 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
  • Calculative AgencyDBMS make culture "calculable". The calculative capacities providedby the relational model are particularly powerful.Calculation must be understood in a wider sense: commensuration(Espeland & Stevens 1998), standardization, quantification, embeddingin relational algebra, etc."Calculative agency will be all the more powerful when it is able to: a) establish along, yet finite list of diverse entities; b) allow rich and varied relations between theentities thus selected, so that the space of possible classifications andreclassifications is largely open; c) formalize procedures and algorithms likely tomultiply the possible hierarchies and classifications between these entities. As thiscalculative power depends on the equipments that agencies can rely upon, we caneasily understand why it is unevenly distributed among them." ( Callon & Muniesa2005)
  • A Technique for GoverningThis 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 techniquesRosabeth Moss Kanter, "When Giants Learn to Dance", 1989DBMS allow organizations to "support peoples mobility withoutrelaxing monitoring." (Boltanski & Chiapello 1996)The relational model is the perfect ally for " knowing capitalism"(Thrift 2005) and "liquid modernity" (Bauman 2000).
  • Conclusions# The relation model purifies and makes calculable# The relational model changes who defines, closes the rift betweenmanagement and IT, "demediation" of control?# The relational model plays an important role in standardization oforganizational processes.# Takes part in reconfiguring the social.