Faculty of ACES © Sheffield Hallam University “ The columns in the tables cover a year at ten day intervals. The decans are placed in the order in which they arise and in the next column, the second decan becomes the first and so on…. Tables to help make these computations have been found on the _____________” What is this describing? inside of coffin lids

© Sheffield Hallam University Some sort of permanency Allows data to be extracted (easily) Can allow data to be appended Can allow data to be inserted, deleted or modified –more difficult pre-computer age Contains data! So what IS a database?

© Sheffield Hallam University I will go first: –ORACLE ! Lets name some databases….

© Sheffield Hallam University Flavours of Database Management System (DBMS) include –Relational –Object-Relational –Hierarchical Databases –Network Databases –Object Oriented But whatever the dbms, they are all about mapping logical constructs to physical ons and offs recorded permanently, normally on a HDD. Ways of managing modern databases

© Sheffield Hallam University BIT 0 or 1, true or false…. BYTE = 8 bits = ascii J FIELD or Column SURNAME (eg Jones) Record or Row Several Fields (Deptno, Desc, Loc) File or Table Several Records Database Several Files Common building blocks

© Sheffield Hallam University Sequential –with n records, n/2 probes required to find data –when n is large, very inefficient So willingly spend time storing records with retrieval in mind: –Order the data itself –Create indexes Issues of Access

© Sheffield Hallam University Whatever the dbms, core physical decisions are being taken It is all about mapping from the logical to the physical disk storage in the most efficient way. This will differ, depending upon what you are trying to do: –query intensive –data quantities –data complexity –user volumes –architecture available From access method to DBMS

© Sheffield Hallam University Driven by both technology and different needs: –Hierarchical developed initially for product assemblies –Network DB driven by need for inventory control (one supplier-several products AND products supplied by several suppliers) –RDBMS the need to keep records –OODBMS: Complex business objects, CAD DBMS - why the differences?

© Sheffield Hallam University Translation needed from real world to relational –one argument for the move to OO paradigm Assumes all rows will contain the same attributes –can lead to masses of virtual empty spaces which slows recovery Constraint checking is a hefty overhead –should some of this be handled by the UI? –Recent impact of middle-tier as a place for rules SQL is non-procedural and was specifically designed to be approachable to non-programmers –hence PL/SQL as a work-around Is all data SET-orientated? RDBMS - some weaknesses

© Sheffield Hallam University Common in the mainframe environment One of the oldest DBMS IMS still performing strongly Organised like the branches of a tree: –single parent can have many children, but can’t be related to other parents record searches and updates can be rapid, as the structure is pre-defined. They always start from the top. Hierarchical Databases

© Sheffield Hallam University Hierarchical cont... Salesman Buyer ABuyer BBuyer C Product 1Product 5Product 4

© Sheffield Hallam University Industry Standards set by ODMG –Object Database management group – ODBMS is defined (by them) as: –..a DBMS that integrates database capabilities with object-oriented programming capabilities Major components include: –Core Object Model –ODL - for specifying objeccts –OQL - for querying (“very close to” SQL92) –Binding to C++,Smalltalk or Java Object DBMS

© Sheffield Hallam University Object (always has an OID) Objects are of a type Types describe a common set of properties (states) and of behaviour (methods) State of Object defined by the values of properties or of relationships with other objects Database has a Object Manager layer between objects and permanent storage. Schema defined in ODL. Much more info at the OODBMD manifesto site: – Common aspects of ODBMS

© Sheffield Hallam University Complex modelling environments because objects allow high levels of abstraction Non record-focused applications: –CAD –Multimedia Reusability focused, modular systems ODBMS is ideal for:

© Sheffield Hallam University Performance, in terms of storing and retrieving data, can be poor RDBMS have a stranglehold on the commercial database marketplace The provision of a “halfway house” Object- Relational model Whilst the Assembler programmer predicts exactly, the architect of complex components is too far removed from the disk access to be able to design efficiently ODBMS - where are they?

Some examples which prove OO is very much still alive: OBJECTIVITY Versant ObjectDB ODBMS - where are they?

© Sheffield Hallam University "XML is a human-readable, machine-understandable, general syntax for describing hierarchical data, applicable to a wide range of applications, databases, e-commerce, Java, web development, searching, and so on. " –Oracle OTN website, my italics Building blocks are: Tags, Elements and attributes Separates Data from validity checking and from presentation –by using DTD or Schemas to validate, and stylesheets to present XML

© Sheffield Hallam University A native XML database... –Defines a (logical) model for an XML document -- as opposed to the data in that document -- and stores and retrieves documents according to that model. –Has an XML document as its fundamental unit of (logical) storage, just as a relational database has a row in a table as its fundamental unit of (logical) storage. –Is not required to have any particular underlying physical storage model. For example, it can be built on a relational, hierarchical, or object-oriented database, or use a proprietary storage format such as indexed, compressed files. Native XML

© Sheffield Hallam University Paradigm conflict: –Hierarchical V Relational XML is not designed to be queriable. –Xpath not as powerful as SQL? –Whole new syntax to learn XML is not normalised ISO SQL does not lend itself to generating XML output Issues with XML in RDBMS

School of Computing and Management Sciences © Sheffield Hallam University Assuming XML inbound, do you: –break it up and store it in relational tables –store the document as a CLOB (Character Large Object datatype) –shred and store in a structured way, applying DTD or Schema rules? Depends how it will be used: –part of an existing rdbmd-based system which allows users to do ad hoc SQL queries –just to forward on, as XML, to other users but seldom queried –Held for use by XPath conversant users –heavily CRUDed –As permanence for Web-based Distributed Authoring and Versioning (DAV). Extensions to HTTP which allows users to collaboratively edit and manage files on remote web servers. How to store XML in RDBMS

Oracle Vs DB2 and SQL Server? In memory databases – Post relational – Shared processing models (grid) The future?