1. 1 Database Design: DBS CB, 2 nd Edition Logical Database Model: Entity Relationship Model & Object Description Language & Unified Modeling Language Ch. 4

2. 2 High-level RDBMS Models High-level design is intended to cover what information need to be stored, what constraints such as keys & referential integrity may be needed, etc. This session is intended to cover multiple high-level design models (logical models) including:  Entity/Relationship Diagram Model - E/R  Unified Modeling Language - UML  Object Description Language – ODL Map this logical model into the physical model (relational model – relations) Ideas High-level Design RDBMS Schema Relational DBMS

3. 3 Purpose of E/R Model The E/R model allows us to sketch database schema designs  Includes some constraints, but not operations Designs are pictures called entity- relationship diagrams Later: convert E/R designs to relational DB designs

4. 4 Framework for E/R Design is a serious business The “boss” knows they want a database, but they don’t know what they want in it Sketching the key components is an efficient way to develop a working database

5. 5 Entity Sets Entity = “thing” or object Entity set = collection of similar entities; typically implemented as a relation  Similar to a class in object-oriented languages. Attribute = property of (the entities of) an entity set:  Attributes are simple values, e.g. integers or character strings, can be structs, sets, etc Relationships = connection between two or more entity sets – binary or multiway relationships

6. 6 E/R Diagrams In an entity-relationship diagram:  Entity set = rectangle  Attribute = oval, with a line to the rectangle representing its entity set  Relationship = diamond, connecting two or more entity sets

7. 7 Example: Entity set Beers has two attributes, name and manf (manufacturer) Each Beers entity has values for these two attributes, e.g. (Bud, Anheuser-Busch) Beers name manf

8. 8 Relationships A relationship connects two or more entity sets Most common is binary relationship. Ternary (3-way) or more is rare It is represented by a diamond, with lines to each of the entity sets involved Relationship can be bi-directional

9. 9 Example: Relationships Drinkers addrname Beers manfname Bars name license addr Note: license = beer, full, none Sells Bars sell some beers. Likes Drinkers like some beers. Frequents Drinkers frequent some bars.

10. 10 Relationship Set The current “value” of an entity set is the set of entities that belong to it  Example: the set of all bars in our database. The “value” of a relationship is a relationship set, a set of tuples with one component for each related entity set

11. 11 Example: Relationship Set For the relationship Sells, we might have a relationship set like: BarBeer Joe’s BarBud Joe’s BarMiller Sue’s BarBud Sue’s BarPete’s Ale Sue’s BarBud Lite

12. 12 Many-One & One-Many Relationships In a many-one relationship R connecting entity sets E and F: each entity in E is connected to one entity in F. Member in F can be connected to 0, 1, or many entities in E In a one-many relationship R connecting entity sets E and F: an entity in E is connected to 0, 1, or many entities in F. Member in F is connected to one entity in E If R is many-one from E to F, we can say R is one-many from F to E

13. 13 In Pictures: Binary Relationship: many-one

14. 14 Example: Many-One Relationship Favorite, from Drinkers to Beers is many-one A drinker has at most one favorite beer But a beer can be the favorite of any number of drinkers, including zero P.S. There is no requirement however that a specific Beer will need to have a Drinker? To ensure that we need a referential integrity constraint

15. 15 One-One Relationship If R is both many-one from E to F and many-one from F to E, then we say R is one-one. In one- one relationship an entity in E or F can be connected to at most one entity of the other set

16. 16 In Pictures: Binary Relationship: one-one

17. 17 One-One Relationships Example: Relationship Best-seller between entity sets Manfs (manufacturer) and Beers  A beer cannot be made by more than one manufacturer, and no manufacturer can have more than one best-seller (assume no ties)

18. 18 Many-Many Relationships In a many-many relationship, an entity of either set can be connected to many entities of the other set

19. 19 In Pictures : Binary Relationship: many-many

20. 20 Many-Many Relationships Example: Relationship Sells between Bars and Beers  A Bar sells many Beer, and a Beer is sold by many Bars Observation: many-one is a special case of many-many, and one-one is a special case of a many-one relationship

21. 21 Representing “Multiplicity” Show a many-one relationship by an arrow entering the “one” side  Remember: Like a functional dependency Show a one-one relationship by arrows entering both entity sets – an arrow means “at most one” Rounded arrow = “exactly one,” i.e., each entity of the first set is related to exactly one entity of the target set An arrow connecting relationship to an entity set serves as a “functional dependency”

22. 22 Example: Many-One Relationship DrinkersBeers Likes Favorite Notice: two relationships connect the same entity sets, but are different. Many-One Many-Many

23. 23 Example: One-One Relationship Consider Best-seller between Manfs and Beers Some beers are not the best-seller of any manufacturer, so a rounded arrow to Manfs would be inappropriate But a beer manufacturer has to have a best- seller

24. 24 In the E/R Diagram ManfsBeers Best- seller A manufacturer has “exactly one” best seller. A beer is the best- seller for “0 or 1” manufacturer.

25. 25 Attributes on Relationships Sometimes it is useful to attach an attribute to a relationship, i.e., not to an entity set Think of this attribute as a property of tuples in the relationship set

26. 26 Example: Attribute on Relationship BarsBeers Sells price Price is a function of both the bar and the beer, not of one alone.

27. 27 Equivalent Diagrams Without Attributes on Relationships Create an entity set representing values of the attribute Make that entity set participate in the relationship

28. 28 Example: Removing an Attribute from a Relationship BarsBeers Sells price Prices Note convention: arrow from multiway relationship = “all other entity sets together determine a unique one of these.” Serves as a “functional dependency”

29. 29 Multi-way Relationships Sometimes, we need a relationship that connects more than two entity sets Suppose that drinkers will only drink certain beers at certain bars  Our three binary relationships Likes, Sells, and Frequents do not allow us to make this distinction  But a 3-way relationship would

30. 30 Example: 3-Way Relationship Bars Beers Drinkers name addr manf nameaddr license Preferences

31. 31 A Typical Relationship Set BarDrinkerBeer Joe’s BarAnnMiller Sue’s BarAnnBud Sue’s BarAnnPete’s Ale Joe’s BarBobBud Joe’s BarBobMiller Joe’s BarCalMiller Sue’s BarCalBud Lite

32. 32 Roles Sometimes an entity set appears more than once in a relationship Label the edges between the relationship and the entity set with names called roles

33. 33 Example: Roles Drinkers Married husbandwife Relationship Set HusbandWife BobAnn JoeSue…

34. 34 Example: Roles Drinkers Buddies Buddy1Buddy2 Relationship Set Buddy1 Buddy2 Bob Ann Joe Sue Ann Bob Joe Moe …

35. 35 Subclasses Subclass = special case = fewer entities = more properties Example: Ales are a kind of beer  Not every beer is an ale, but some are  Let us suppose that in addition to all the properties (attributes and relationships) of beers, ales also have the attribute color

36. 36 Subclasses in E/R Diagrams Assume subclasses form a tree  I.e., no multiple inheritance isa triangles indicate the subclass relationship of type one-one relationship w/o arrows  Point to the superclass

37. 37 Example: Subclasses Beers Ales isa namemanf color Ales is a special-case entity set (subclass) of the Beers entity set with its own attributes and relationships Ales isa Beers but have special “color” attribute

38. 38 E/R Vs. Object-Oriented Subclasses In OO, objects are in one class only  Subclasses inherit from superclasses In contrast, E/R entities have representatives in all subclasses to which they belong  Rule: for a tree entity set connected by isa relationships, a single entity in a subclass consists of components from that subclass and components in the superclass and recursively up to the root of the tree

39. 39 Example: Representatives of Entities Beers Ales isa namemanf color Pete’s Ale

40. 40 Key Constraint A key is a set of attributes for one entity set such that no two entities in this entity set agree on all the attributes of the key:  It is allowed for two entities to agree on some, but not all, of the key attributes We must designate a key for every entity set

41. 41 Keys in E/R Diagrams Underline the key attribute(s) In an isa hierarchy, only the root entity set has a key (a constraint), and it must serve as the key for all entities in the hierarchy

42. 42 Example: name is Key for Beers Beers Ales isa namemanf color

43. 43 Example: a Multi-attribute Key Courses dept number hoursroom Note that hours and room could also serve as a key, but we must select only one key.

44. 44 Referential Integrity Constraints A referential integrity constraint states that a value appearing in one context (column) will necessitate another value in a second context (column. In a many-one relationship like Favorite relationship between Drinkers and Beers. The many-one does not require that given a Beer value we must have a Drinker that this Beer is their favorite! A referential integrity constraint on the relationship Favorite is that for each Beer, a Drinker (entity referenced by the Favorite relationship) must exist in the database!

45. 45 Referential Integrity Constraints Favorite relationship is many-one from entity set Drinkers to entity set Beers Arrow to Beers means many drinkers can have same Beer as their favorite Rounded arrow (exactly once) to Drinkers means that every Beer must have at least one Favorite Drinker in the database DrinkersBeers Favorite Many-One

46. 46 Degree Constraints We can attach a bounding number to the edge connecting a relationship to an entity set The attached number indicates limits on the number of entities that can be connected to any single entity of the related entity set In the above example: only  10 Drinkers can have the same Favorite Beer DrinkersBeers Many-One  10 Favorite

47. 47 Weak Entity Sets Occasionally, entities of an entity set need “help” to identify them uniquely Weak entity set is an entity set with its key’s attributes, some or all belong to other entity sets Entity set E is said to be weak if in order to identify entities of E uniquely, we need to follow one or more many-one relationships from E and include the key of the related entities from the connected entity sets

48. 48 Example: Weak Entity Set Player name is almost a key for football players, but there might be two with the same name number is certainly not a key, since players on two teams could have the same number But number, together with the team name related to the player by Plays-on should be unique

49. 49 In E/R Diagrams PlayersTeams Plays- on name number To identify player uniquely, we need player number + team’s name as the key! Double diamond for supporting many-one relationship Double rectangle for the weak entity set Note: must be rounded because a player can be a member of only one team Note: “Players” is a week entity set because player name & number are not unique unless associated with a team

50. 50 Weak Entity-Set Rules A weak entity set has one or more many-one supporting relationships to other supporting entity sets:  Not every many-one relationship from a weak entity set needs to be supporting relationship  But supporting relationships must have a rounded arrow (entity at the “one” end needs to be guaranteed)

51. 51 Weak Entity-Set Rules – (2) The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets:  E.g., (player) number and (team) name is a key for Players in the previous example

52. 52 Design Techniques 1. Avoid redundancy 2. Limit the use of weak entity sets 3. Don’t use an entity set when an attribute will do

53. 53 Avoiding Redundancy Redundancy = saying the same thing in two (or more) different ways Wastes space and (more importantly) encourages inconsistency:  Two representations of the same fact become inconsistent if we change one and forget to change the other  Recall anomalies due to FD’s

54. 54 Example: Good BeersManfs ManfBy name This design gives the address of each manufacturer exactly once nameaddr m : 1

55. 55 Example: Bad BeersManfs ManfBy name This design states the manufacturer of a beer twice: as an attribute and as a related entity name manf addr

56. 56 Example: Bad Beers name This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer manfmanfAddr

57. 57 Entity Sets Versus Attributes An entity set should satisfy at least one of the following conditions:  It is more than the name of something; it has at least one non-key attribute or  It is the “many” in a many-one or many- many relationship

58. 58 Example: Good BeersManfs ManfBy name Manfs deserves to be an entity set because of the non-key attribute addr Beers deserves to be an entity set because it is the “many” of the many-one relationship ManfBy nameaddr m : 1

59. 59 Example: Good Beers name There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name manf

60. 60 Example: Bad BeersManfs ManfBy name Since the manufacturer is nothing but a name (i.e., no additional attributes), and is not at the “many” end of any relationship, it should not be an entity set name m : 1

61. 61 Don’t Overuse Weak Entity Sets Beginning database designers often doubt that anything could be a key by itself:  They make all entity sets weak, supported by all other entity sets to which they are linked In reality, we usually create unique ID’s for entity sets:  Examples include social-security numbers, automobile VIN’s etc.

62. 62 When Do We Need Weak Entity Sets? The usual reason is that there is no global authority capable of creating unique ID’s Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world

63. 63 From E/R Diagrams to Relations Entity set  relation  with same: Attributes  attributes Relationship  relation whose attributes are only:  The keys of the connected entity sets  Attributes of the relationship itself

64. 64 From E/R Diagrams to Relations (2): Special handling Weak entity sets are not translated directly to relations “Isa” relationships and subclasses require careful treatment Sometime, we may combine two relations, especially entity set E and the relation that comes from a many-one relationship (where E is the many) from E to entity set F

65. 65 Entity Set  Relation Relation: Beers(name, manf) Beers name manf

66. 66 Relationship  Relation DrinkersBeers Likes Likes(drinker, beer) Favorite Favorite(drinker, beer) Married husband wife Married(husband, wife) name addr name manf Buddies 1 2 Buddies(name1, name2)

67. 67 Combining Relations OK to combine into one relation: 1. The relation for an entity-set E 2. The relations for many-one relationships of which E is the “many” Example: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinker1(name, addr, favBeer)

68. 68 Risk with Many-Many Relationships Combining Drinkers (name, addr) with Likes (drinker, beer) would be a mistake. It leads to redundancy, as: name addr beer Sally 123 Maple Bud Sally 123 Maple Miller Redundancy

69. 69 Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own, nonkey attributes. A supporting relationship is redundant and yields no relation (unless it has attributes).

70. 70 Example: Weak Entity Set -> Relation LoginsHostsAt name Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2) Must be the same billTo At becomes part of Logins location

71. 71 Subclasses: Three Approaches 1. Object-oriented: Treat entities as objects belonging to a single class. For each subtree that includes the root, create a relation, whose schema includes all attributes of all entity sets in the subtree 2. E/R style: One relation for each entity set E (subclass) in the hierarchy:  Key attribute(s) from the root  Attributes of that subclass 3. Use nulls: One relation including all attributes from all entities; entities represented as tuples with NULL in attributes that don’t belong to them

72. 72 Example: Subclass  Relations Beers Ales isa name manf color

73. 73 1. Object-Oriented namemanf Bud Anheuser-Busch Beers name manf color Summerbrew Pete’s dark Ales Good for queries like “find the color of ales made by Pete’s”

74. 74 2. E/R Style namemanf Bud Anheuser-Busch Summerbrew Pete’s Beers name color Summerbrew dark Ales Good for queries like “find all beers (including ales) made by Pete’s”

75. 75 Using Nulls namemanf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark Beers Saves space unless there are lots of attributes that are usually NULL.

76. 76 Other High-Level Design Languages Object Description Language & Unified Modeling Language

77. 77 Object-Oriented DBMS’s Standards group: ODMG -- Object Data Management Group ODL -- Object Description Language, like CREATE TABLE part of SQL OQL -- Object Query Language, tries to imitate SQL in an OO framework

78. 78 Framework – (1) ODMG imagines OO-DBMS vendors implementing an OO language like C++ with extensions (OQL) that allow the programmer to transfer data between the database and “host language” seamlessly

79. 79 Framework – (2) ODL is used to define persistent classes, whose objects are stored permanently in the database:  ODL classes look like Entity sets with binary relationships, plus methods  ODL class definitions are part of the extended, OO host language

80. 80 Object Description Language (ODL) Overview A class declaration includes: 1. A name for the class 2. Optional key declaration(s) 3. Element declarations. An element is either an attribute, a relationship, or a method

81. 81 Class Definitions class { <list of element declarations, separated by semicolons> }

82. 82 Attribute and Relationship Declarations Attributes are (usually) elements with a type that does not involve classes: attribute ; Relationships connect an object to one or more other objects of one class: relationship inverse ;

83. 83 Inverse Relationships Suppose class C has a relationship R to class D Then class D must have some relationship S to class C R and S must be true inverses:  If object d is related to object c by R, then c must be related to d by S

84. 84 Example: Attributes and Relationships This relationship states: A Bar serves a set of Beer objects The :: operator connects ServedAt from Beer to Bar This relationship states: A Beer is servedAt a set of Bar objects class Bar { attribute string name; attribute string addr; } relationship Set serves inverse Beer::servedAt; class Beer { attribute string name; attribute string manf; relationship Set servedAt inverse Bar::serves; } BarBeer serves servedAt m : m

85. 85 Types of Relationships The type of a relationship is either: 1. A class (such as Bar): the object is connected to only one Bar object 2. Set : the object is connected to a set of Bar objects 3. Bag, List, Array : the object is connected to a bag, list, or array of Bar objects

86. 86 Multiplicity of Relationships All ODL relationships are binary Many-many relationships have Set for the type of the relationship and its inverse Many-one relationships have Set in the relationship of the “one” and just the class for the relationship of the “many” One-one relationships have classes as the type in both directions

87. class Drinker { … relationship Set likes inverse Beer::fans; relationship Beer favBeer inverse Beer::superfans; } class Beer { … relationship Set favs inverse Drinker::likes; relationship Set superfans inverse Drinker::favBeer; } 87 Example: Multiplicity Many-many uses Set in both Directions: * One Drinker likes many Beer * One Beer has many fans Many-one uses Set only with the “one”: * Drinker has one favBeer * One Beer has many superfans DrinkerBeer likes fans Beer superfans favBeer 1 : mm : m

88. 88 Another Multiplicity Example class Drinker { attribute … ; relationship Drinker husband inverse wife; relationship Drinker wife inverse husband; relationship Set buddies inverse buddies; } husband and wife are Both Drinkers. They are one-one and inverses of each other buddies is many-many and its own inverse. Note no “::” is needed if the inverse is in the same class

89. 89 Coping With Multiway Relationships ODL does not support 3-way or higher relationships We may simulate multiway relationships by a “connecting” class, whose objects represent tuples of objects we would like to connect by the multiway relationship

90. 90 Connecting Classes Suppose we want to connect classes X, Y, and Z by a relationship R Devise a class C, whose objects represent a triple of objects (x, y, z) from classes X, Y, and Z, respectively We need three many-one relationships from (x, y, z) to each of x, y, and z

91. 91 Example: Connecting Class Suppose we have Bar and Beer classes, and we want to represent the price each Bar sells each beer:  A many-many relationship between Bar and Beer cannot have a price attribute as it did in the E/R model! One solution: create class Price and a connecting class BBP to represent a related Bar, Beer, and Price

92. 92 Example -- Continued Since Price objects are just numbers, a better solution is to: 1. Give BBP objects an attribute price 2. Use two many-one relationships between a BBP object and the Bar and Beer objects it represents

93. 93 Example -- Concluded Here is the definition of BBP: class BBP { attribute price:real; relationship Bar theBar inverse Bar::toBBP; relationship Beer theBeer inverse Beer::toBBP; } Bar and Beer must be modified to include relationships, both called toBBP, and both of type Set BBP Bar theBar toBBP Beer toBBP theBeer 1 : mm : 1

94. 94 Structs and Enums Attributes can have a structure (as in C) or be an enumeration Declare with attribute [Struct or Enum] <name of struct or enum> { } ; Details are field names and types for a Struct, a list of constants for an Enum

95. 95 Example: Struct and Enum class Bar { attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Enum Lic { FULL, BEER, NONE } license; relationship … } Names for the structure and enumeration names of the attributes

96. 96 Method Declarations A class definition may include declarations of methods for the class Information consists of: 1. Return type, if any 2. Method name 3. Argument modes and types (no names):  Modes are in, out, and inout 4. Any exceptions the method may raise

97. 97 Example: Methods real gpa(in string)raises(noGrades); 1. The method gpa returns a real number (presumably a student’s GPA) 2. gpa takes one argument, a string (presumably the name of the student) and does not modify its argument 3. gpa may raise the exception noGrades

98. 98 The ODL Type System Primitive types: int, real/float, string, enumerated types, and classes class names: is a struct with attributes and relationships as components of that class Type constructors: the above types can be combined into structured types called type constructors:  Collection types : Set, Bag, List, Array, and Dictionary that denotes a type whose values are finite set of pairs. Each pair is value of the key type T and a value of the range type S. Dictionary can’t have two pairs of the same key value Structure: struct N {T 1 F 1, T 2 F 2, …, T n F n } denotes type N whose elements are N fields; i th field is named F i and has type T i Relationship types can only be a class or a single collection type applied to a class

99. 99 ODL Subclasses Usual object-oriented subclasses Indicate superclass with a colon and its name Subclass lists only the properties unique to it:  Also inherits its superclass’ properties

100. 100 Example: Subclasses Ales are a subclass (linear inheritance) of beers: class Ale extends Beer { attribute string color; } With multiple inheritance: class Ale extends Beer : Liquor { attribute string color; }

101. 101 ODL Keys You can declare any number of keys for a class After the class name, add: (key ) A key consisting of more than one attribute needs additional parentheses around those attributes

102. 102 Example: Keys class Beer (key name) { … } name is the key for beers class Course (key (dept,number),(room, hours)){ … } dept and number form one key; so do room and hours

103. 103 Unified Modeling Language - UML UML is designed to model software, but has been adapted as a database modeling language Midway between E/R and ODL:  No multiway relationships as in E/R  But allows attributes on binary relationships, which ODL doesn’t  Has a graphical notation, unlike ODL

104. 104 Classes Sets of objects, with attributes (state) and methods (behavior) Attributes have types PK indicates an attribute in the primary key (optional) of the object Methods have declarations: arguments (if any) and return type

105. 105 Example: Bar Class Bar PK Name: string Addr: string setName(n) setAddr(a) getName() : string getAddr() : string sellsBud() : boolean Class Name Attributes Methods

106. 106 Associations Binary relationships between classes Represented by named lines (no diamonds as in E/R) Multiplicity at each end:  m..n means between m and n of these associate with one on the other end  * = “infinity”; (1..*) means “at least one”

107. 107 Example: Association BarBeer 1..50 0..* Sells Association is represented by a line (not diamond); we place the association name below the line, and the constraints on the number of objects from each of its classes

108. 108 Comparison With E/R Multiplicities E/R UML 0..* 0..* 0..1 0..* 1..1 name many-many many-exacltyOne …… (If object on the right side box ceases to exist, the corresponding left entries need to be deleted many-one (many –atMostOne)

109. 109 Association Classes Attributes on associations are permitted.  Called an association class  Analogous to attributes on relationships in E/R

110. 110 Example: Association Class BarBeer 1..50 0..* Sells price: float

111. 111 Subclasses Like E/R, but subclass points to superclass with a line ending in a triangle Primary key comes from the root; similar to E/R UML permits a class C to have four different kinds of subclasses:  Complete (every object is in at least one subclass) or partial or incomplete  Disjoint (object in at most one subclass) or it is overlapping

112. 112 Example: Subclasses Beer name: string manf: string Ale color: string class subclass

113. 113 Conversion to Relations We can use any of the three strategies outlined for E/R to convert a class and its subclasses to relations: 1. OO-style: relations store attributes of subclass and all superclasses 2. E/R-style: each subclass’ relation stores only its own attributes, plus key 3. Nulls: One relation, with NULL’s as needed

114. 114 Aggregations Relationships with implication that the objects on one side are “owned by” or are part of objects on the other side Represented by an open diamond at the end of the connecting line, at the “owner” side. Implication that in a relational schema, owned objects are part of owner tuples

115. 115 Example: Aggregation Beer name: string manf: string Award title: string year: int 0..1 0..* Won Award object is owned-by or part-of a Beer object Label (constraint) at the diamond end must be 0..1 Aggregation is many-one association from class Award to class Beer at the diamond end. An award object is connected to at most one Beer object Aggregation do not need to be named

116. 116 Compositions Like aggregations, but with the implication that every object is definitely owned by one object on the other side; label at solid diamond must be 1..1 or every object on the opposite side of the solid diamond must be connected to exactly one object at the diamond end Represented by solid diamond at owner side Often used for sub-objects or structured attributes

117. 117 Example: Composition Beer name: string manf: string Award title: string year: int 1..1 0..* Won

118. 118 Conversion to Relations We could store the awards of a beer with the beer tuple Requires an object-relational or nested- relation model for tables, since there is no limit to the number of awards a beer can win

119. 119 Example: Composition Bar name: string phone: int Addr street:string city: string zip: int 1..1 0..1 Won

120. 120 Conversion to Relations Since a bar has at most one address, it is quite feasible to add the street, city, and zip attributes of Addr to the Bars relation In object-relational databases, Addr can be one attribute of Bars, with structure

121. 121 END