ODL Design to Relational Designs Object-Relational Database Systems (ORDBS) Extensible Markup Language (XML)

Size: px

Start display at page:

Download "ODL Design to Relational Designs Object-Relational Database Systems (ORDBS) Extensible Markup Language (XML)"

Cornelia Norris
5 years ago
Views:

1 ODL Design to Relational Designs Object-Relational Database Systems (ORDBS) Extensible Markup Language (XML) INF3100, V 2004, U9F1 Chapter 4, Sections 1-5 and 7 Edited By M. Naci Akkøk 25/2-2003, 20/ Based upon slides by Pål Halvorsen (26/2-2002). Contains slides made by Arthur M. Keller, Vera Goebel. Overview 9 From ODL design to relational design (briefly) 9 Object-relational DBS (ORDBS) 9 Semi-structured data 9 Extensible Markup Language (XML) 1

2 ODL Design to Relational Designs Translating ODL to Relations Similar to converting ER-diagrams to relations: 9 Classes without relationships are like entity classes (or sets), but some new problems arise: Keys are optional in ODL (Some situations may require inventing new attributes to serve as a key) ODL may have non-atomic attributes (Resulting relations may be non-normalized and must be redesigned) ODL allows methods as part of design 9 Classes with relationships: Treat the relationship separately, as in E/R. Attach a many-one relationship to the relation for the many. 2

3 Translating ODL to Relations: Attributes and Keys 9 Each atomic ODL attribute translates to a relational attribute. 9 ODL allows non-atomic attributes (structures and collection types): Structure: make one attribute for each field. SET: make one tuple for each member of the set. (More than one set attribute? Make tuples for all combinations.) BAG: make only distinct tuples, add a count attribute LIST: make one member for each member of the list, add a position attribute ARRAY: fixed length, add each field in the array as own attributes DICTIONARY: represent as set, but with a tuple for all pairs that are member of the dictionary 9 ODL class may have no key, but we should have one in the relation to represent OID. Translating ODL to Relations: Attributes and Keys - Example ODL class: class Person (extent persons key name) { attribute string name; attribute Struct Addr{string street, string city} address; attribute Set<string> phone; } name street city phone Relation schema: persons (name, street, city, phone) n 1 s 1 c 1 p 1 n 1 s 1 c 1 p 2 9 Surprise : the key for the class (name) is not the key for the relation (name, phone): name in the class determines a unique object, including a set of phone numbers. name in the relation does not determine a unique tuple. Since tuples are not identical to objects, there is no inconsistency! 9 BCNF violation: name Æ (street, city), name not superkey, separate out name-phone. 3

4 Translating ODL to Relations: Relationships 9 Can create a new relation for each relationship 9 If the relationship is many-to-one from A to B, put key of B attributes in the relation for class A. 9 If relationship is many-many, we ll have to duplicate A-tuples as in ODL with set-valued attributes. Wouldn t you really rather create a separate relation for a many-many-relationship? You ll wind up separating it anyway, during BCNF decomposition. Translating ODL to Relations: Relationships - Example ODL class: class Person (extent persons key name) { attribute string name; attribute Struct Addr{string street, string city} address; relationship Set<Cars> owncar inverse Cars::ownedBy; relationship Person spouse inverse spouse; relationship Set<Person> buddies inverse buddies; } Relation schema: persons (name, street, city, owncar, spouse, buddies) 9 BCNF violation: name Æ (street, city, spouse) 9 4NF violation: name ÆÆ owncar buddies 9 Decomposition into 4NF: persons (name, street, city, spouse) persons_cars (name, owncar) persons_buddies (name, buddies) 4

5 Object-Relational Database Systems (ORDBS) Data Models & Database System Architectures - Chronological Overview - 9 Network Data Models (1964) 9 Hierarchical Data Models (1968) 9 Relational Data Models (1970) 9 Object-oriented Data Models (~ 1985) 9 Object-relational Data Models (~ 1990) 9 Semistructured Data Models (XML 1.0) (~1998) INF 212 database theory 2002 Pål Halvorsen 5

6 Object-Relational Database Systems (ORDBS) 9 Motivations Allow DBMS to deal with specialized types maps, signals, images, etc. with their own specialized methods. Supports specialized methods even on conventional relational data. Supports structure more complex than flat files. Ö Object-oriented ideas enter the relational world Keep the relation as the fundamental abstraction whereas the OODBS use the class as the fundamental abstraction. ORDBS: New Features 9 Structured types Not only atomic types. ODL-like type system. (Also: BLOB, CLOB, ADT, BFILE) 9 Methods Special operations can be defined for a type. 9 Identifiers Allowing unique IDs for each tuple. 9 References Pointers to tuples. 6

7 ORDBS: Nested Relations 9 Attributes may have non-atomic types Nested-relational data models give up 1NF (atomic values) A relation s type can be any schema consisting one or more attributes. An attribute may even have an own schema as type. 9 Example: moviestar(name, address(street,city), birth, movies(title,year)) name address street Fisher city Maple Hollywood 5. Avenue New York street Hamill birth title 9/9/1950 city Sunset Bvld LA movie year Star Wars 1977 Empire 1980 title 8/8/1962 year Star Wars 1977 Return 1983 ORDBS: References - I 9Non-normalized relation 9Introduce references to allow a tuple t refer to a tuple s rather than including s in t. name address street Fisher Hamill city Maple Hollywood 5. Avenue New York street movie title 9/9/1950 city Sunset Blvd LA birth Star Wars 1977 Empire 1980 title 8/8/1962 year year Star Wars 1977 Return

8 ORDBS: References - II 9 If attribute A has a type that is a reference to a relation with schema R, we denote A as A(*R) 9 If A is a set of references, we denote A as A({*R}) 9 Example: moviestar(name, address(street,city), birth, movies({*movies})) movies(title,year) name address birth movie Fisher street Maple 5. Avenue city Hollywood New York 9/9/1950 title Star Wars Empire year Hamil street Sunset Bvld city LA 8/8/1962 Return 1883 OODBS vs. ORDBS - I two ways to integrate object-orientation into DBS Æ both directions (OODBS and ORDBS) are also reflected in the standard developments Several vendors: commercial OODBS: commercial ORDBS: -GemStone -ORACLE - O2 (now: Ardent) - Sybase - ObjectivityDB - Illustra - ObjectStore - UNISQL - ONTOS POET -Versant

9 OODBS vs. ORDBS - II 9 Objects/tuples: Both objects and tuples are structs with components for attributes and relationships 9 Extents/relations: Both may share the same declaration among several collections 9 Methods: Both has the same ability to declare and define methods associated with a type 9 Type systems: Both are based on atomic types and constructions of new types by structs and collection types 9 References/OID: OODBS OID hidden ORDBS ID visible (may be part of type) 9 Backwards Compatibility: Migrating existing applications to an OODBS require extensive rewriting, but ORDBSes have maintained backward compatibility OODBS: OODBS vs. ORDBS - III 9 simpler way for programmer to use DBS (familiar with OOPLs) 9 seamlessness, no impedance mismatch 9 OO functionality + DBS functionality Æ higher performance for specific applications 9 revolutionary approach, no legacy problems 9... ORDBS: 9 substancial investment in SQL-based rel. DBSs Æ evolutionary approach 9 systems are more robust due to many years of usage and experience 9 application development tools 9 transaction processing performance 9... prediction: both kinds of systems will exist, used for different kinds of applications 9

10 Semi-Structured Data Information Integration - I Problem: related data exists in many places. They talk about the same things, but differ in model, schema, conventions (e.g., terminology). How should one retrieve data from different places? Examples: In the real world, every bar has its own database. 9 Some may have relations like beer-price; others have an Microsoft Word file from which the menu is printed. 9 Some keep phones of manufacturers but not addresses. 9 Some distinguish beers and ales; others do not. 10

11 Information Integration - II 9 Warehousing: Make copies of information at each data source centrally, combine into a global schema. Query data stored at the warehouse. Reconstruct (recopy) data daily/weekly/monthly, but do not try to keep it up-to-date. 9 Mediation: Create a view of all information, but do not make copies. Answer queries by sending appropriate queries to sources (no local data). Semi-Structured Data 9 Semi-structured data model allows information from several sources, with related but different properties, to be fit together in one whole. Thus, suitable for integration of databases sharing information on the Web 9 Semi-structured data is data that may be irregular or incomplete and have a structure that may change rapidly or unpredictably. It generally has some structure, but does not conform to a fixed schema Schemaless and self-describing, i.e., data carries information about its own schema (e.g., in terms of XML element tags) 9 Characteristics Heterogeneous Irregular structure Large evolving schema 9 Major application: XML documents 11

12 Semi-Structured Data: Graph Representation 9 Collection of nodes Atomic values on leaf nodes Interior nodes have one or more arcs 9 Nodes connected in a general rooted graph structure 9 Labels on arcs name of attribute/type relationship 9 Example: Beer-Bar-Manufacturer name bud makes root beer beer name miller serves bar addr name servedat manufacturer Joe s madeby name addr Extensible Markup Language (XML) 12

13 Data Models & Database System Architectures - Chronological Overview - 9 Network Data Models (1964) 9 Hierarchical Data Models (1968) 9 Relational Data Models (1970) 9 Object-oriented Data Models (~ 1985) 9 Object-relational Data Models (~ 1990) 9 Semistructured Data Models (XML 1.0) (~1998) INF 212 database theory 2002 Pål Halvorsen Extensible Markup Language (XML) 9 Standard of the World Wide Web Consortium (W3C) in An XML document is only a file of characters 9 Similar to HTML, but HTML uses tags for formatting (e.g., italic ). XML uses tags for semantics (e.g., this is an address ). 9 Two modes: Well-formed XML allows you to invent your own tags, much like labels in semi-structured data. Valid XML involves a Document Type Definition (DTD) that tells the labels and gives a grammar for how they may be nested. INF 212 database theory 2002 Pål Halvorsen 13

14 Tags 9 Tags are text surrounded by brackets, i.e., <...> 9 Tags come in matching pairs, e.g., <FOO> is balanced by </FOO> 9 Nesting allowed (start and end in same range), e.g., <BAR> <NAME></NAME> </BAR> 9 Unbalanced tags not allowed, e.g., <P>, <BR>, and <HR> in HTML INF 212 database theory 2002 Pål Halvorsen Well-Formed XML 9 Minimal requirement: XML declaration and root tags surrounding entire body <? XML VERSION = "1.0" STANDALONE = "yes"?> <XXX>... </XXX> NOTE 1: XML version NOTE 2: there is no DTD specified INF 212 database theory 2002 Pål Halvorsen 14

15 Well-Formed Example <?XML VERSION = "1.0" STANDALONE = "yes"?> <BARS> <BAR> <NAME>Joe s Bar</NAME> <BEER> <NAME>Bud</NAME> <PRICE>2.50</PRICE> </BEER> <BEER> <NAME>Miller</NAME> <PRICE>3.00</PRICE> </BEER> </BAR> <BAR>... </BAR> </BARS> NOTE 1: only balanced tags NOTE 2: value between two surrounding tags NOTE 3: nesting within the same range Document Type Definitions (DTD) 9 Essentially a grammar describing the legal nesting of tags 9 Intention is that DTD s will be standards for a domain, used by everyone preparing or using data in that domain Example: a DTD for describing protein structure; a DTD for describing bar menus, etc. 9 Structure of a DTD: <!DOCTYPE root tag [ <!ELEMENT name (components)>... more elements... ]> 9 The root-tag is used to surround the document which uses these rules 15

16 Elements of a DTD 9 An element is a name (its tag) and a parenthesized description of tags within an element. 9 Special case: (#PCDATA) after an element name means it is text. 9 Each element name is a tag. 9 Its components are the tags that appear nested within, in the order specified. 9 Multiplicity of a tag is controlled by: 1. * = zero or more of = one or more of. 3.? = zero or one of. 9 In addition: = or. DTD: Example <!DOCTYPE Bars [ <!ELEMENT BARS (BAR*)> <!ELEMENT BAR (NAME, BEER+)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT BEER (NAME, PRICE)> <!ELEMENT PRICE (#PCDATA)> ]> NOTE 1: BARS is root-tag NOTE 2: multiplicity of tags NOTE 3: name (and price) has a text value NOTE 4: Inside <BARS>-tag we ll find zero or more <BAR>-tags NOTE 5: a BAR has a name and serves one or more beers (which again has components) 16

17 Using a DTD 9 To use a DTD, set STANDALONE = "no": <?XML VERSION = "1.0" STANDALONE = "no"?> 9 Either Include the DTD as a preamble, or Follow the XML tag by a DOCTYPE declaration with the root tag, the keyword SYSTEM, and a file where the DTD can be found. Using a DTD: Example <?XML VERSION = "1.0" STANDALONE = "no"?> <!DOCTYPE Bars [ SYSTEM "bar.dtd"> <!ELEMENT BARS (BAR*)> <!ELEMENT BAR (NAME, BEER+)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT BEER (NAME, PRICE)> <!ELEMENT PRICE (#PCDATA)> ]> <BARS> <BAR><NAME>Joe s Bar</NAME> <BEER> <NAME>Bud</NAME> <PRICE>2.50</PRICE></BEER> <BEER> <NAME>Miller</NAME> <PRICE>3.00</PRICE></BEER> </BAR> <BAR>... </BARS> NOTE 1: DTD may be in a separate file NOTE 2: DTD may be included as a preamble NOTE 3: BARS is root-tag and surround the document which uses these rules NOTE 4: BEER has a name and a price NOTE 5: BAR has a name and serves one or more beers. 17

18 Attribute Lists 9 Opening tags can have arguments that appear within the tag, in analogy to constructs like <A HREF =...> in HTML. 9 Keyword!ATTLIST introduces a list of attributes and their types for a given element in the DTD. 9 Example of declaration: <!ELEMENT BAR (NAME BEER*)> <!ATTLIST BAR type = "sushi" "sports" "other"> 9 Bar objects can have a type, and the value of that type is limited to the three strings shown. 9 Example of use: <BAR type = "sports">... </BAR> ID s and IDREF s 9 ID is used to give a unique name for an element/object 9 IDREF is used to provide pointers to elements/object (by the ID-name), and multiple object references within one tag is allowed. IDREFS is used if there might be a set of references 9 Analogous to NAME = foo and HREF = #foo in HTML 9 Allows the structure of an XML document to be a general graph, rather than just a tree. 18

19 ID s and IDREF s: Example 9 Let us include in our Bars document type elements that are the manufacturers of beers, and have each beer object link, with an IDREF, to the proper manufacturer object: NOTE 1: MANUFACTURER has <!DOCTYPE Bars [ a name-id <!ELEMENT BARS (BAR*)> <!ELEMENT BAR (NAME, BEER+)> NOTE 2: <!ELEMENT NAME (#PCDATA)> BEER has a poiner <!ELEMENT MANUFACTURER (ADDR,...)> to a manufacturer <!ATTLIST MANUFACTURER (name ID)> <!ELEMENT ADDR (#PCDATA)> NOTE 3: <!ELEMENT BEER (NAME, PRICE)> The IDREF value in <!ATTLIST BEER (manf IDREF)> BEER equals the ID <!ELEMENT PRICE (#PCDATA)> value in the ]> corresponding... manufacturer <MANUFACTURER name= ="X">...</MANUFACTURER>... <BEER manf="x"><name>bud</name><price>2.50</price></beer> Summary 9 From ODL design to relational design 9 Object-relational DBSes (ORDBS) 9 Semi-structured data 9 Extensible Markup Language (XML) 19

Object-Relational Database Systems (ORDBS) Contains slides made by Naci Akkøk, Pål Halvorsen, Arthur M. Keller and Vera Goebel.

Object-Relational Database Systems (ORDBS) Contains slides made by Naci Akkøk, Pål Halvorsen, Arthur M. Keller and Vera Goebel. Data Models & Database System Architectures - Chronological Overview - Network