1. 1 Database Modeling (Semantic data modeling) ER Data Model –A high-level conceptual data model –Proposed by P. Chen (1976) –Widely used in DB design process ODL (object definition language) –Standard language for object DBMS –ODMG release 1.2 (1993), release 2.0 (1997) –An extension of IDL (Interface description language) of CORBA (Common object request broker architecture)

2. 2 Simplified DB design process Ideas E/R ODL Relations Object-oriented DBMS Relational DBMS

3. 3 Phases of database design Requirements collection and analysis Conceptual design Database requirements Conceptual schema (in a high-level data model) Logical design (data model mapping) Conceptual schema (in the data model of a specific DBMS) Physical design Internal schema (for the same DBMS) Functional requirements Functional analysis High level transaction specification DBMS-independent DBMS-dependent Application program design Transaction Implementation Application program

4. 4 Object-oriented design Object, class –Object is the basic modeling primitive in ODMG –class is a set of objects with the same properties Properties of ODL class –attributes are properties whose types are built from primitive types such as integer or string in a restricted way –relationships: reference to an object or a set of such references –methods: functions applied to objects

5. 5 Example of ODL declaration interface Movie { attribute string title; attribute integer year; attribute integer length; attribute enum Film {color, blackAndWhite} filmtype; relationship set starof; }; interface Star { attribute string name; attribute Struct Addr {string street, string city} address; };

6. 6 Relationships in ODL Relationship associates an object (or a set of objects) with other object (or a set of such objects) usually belonging to other class relationship Set stars; relationship Star starof;

7. 7 Inverse relationship relationship Set stars; // in Movie class relationship Set starredIn;// in Star class vs. relationship Set stars inverse Star::starredIn // in Movie class relationship Set starredIn inverse Movie::stars; // in Star class

8. 8 Multiplicity of relationships Uniqueness requirements for a relationship and its inverse are called the multiplicity of the relationships Three most common multiplicities –many-many relationship –many-one relationship –one-one relationship In ODL, we specify these options by using a collection operator like Set in the relationship declaration

9. 9 interface Movie { attribute string title; attribute integer year; attribute integer length; attribute enum Film {color, blackAndWhite} filmtype; relationship Set stars inverse Star::starredIn; relationship Studio ownedBy inverse Studio::owns; }; interface Star { attribute string name; attribute Struct Addr {string street, string city} address; relationship Set starredIn inverse Movie::stars; }; interface Studio { attribute string name; attribute string address; relationship Set owns inverse Movie::ownedBy; }; many-many relationship from Movie to Star many-one relationship from Movie to Studio one-many relationship from Studio to Movie

10. 10 Types in ODL ODL consists of two basic types –atomic types: integer, float, character, character string, boolean, enumeration –interface types: such as Movie or Star Basic types are combined into structured types by the following type constructors –Set: If T is any type, then Set –Bag: Bag –List: List –Array: If T is a type and i is an integer, Array –Structure: If T 1,…,T n are types and F 1,…,F n are field names, then Struct N {T 1 F 1, T 2 F 2,…,T n F n } –the first four types are called collection types

11. 11 Type rules The type of an attribute is built starting with either an atomic type or a structure whose fields are atomic types. Then we may apply optionally a collection type to the initial atomic type or structure The type of a relationship is either an interface type or a collection type applied to an interface type legal attribute type –integer –Struct N {string field1, integer field2} –List –Array Illegal relationship type –Struct N {Movie field1, Star field2} –Set –Set > /* only one application of collection types optionally */

12. 12 Entity-Relationship Data Model

13. 13 Entities and Attributes Entities: objects, concepts, or things that are represented in the database –(ex) employee, department, project, etc. Attributes: properties used to describe an entity –(ex) an EMPLOYEE entity may be described by the attributes Name, SSN, and Address Each specific entity will have a value for each of its attributes –(ex) a specific employee may have Name = "John Smith", SSN = "123456789", Address = "7631 Fondren Road, Houston, Texas, U.S.A.”. Entity type (entity set) –a set of entities with the same attributes

14. 14 Types of Attributes (1) simple (or atomic) attribute –each entity has a single atomic value which is indivisible for the attribute the SSN or Sex attributes of an EMPLOYEE composite attribute –the attribute may be composed of several components Address(Apt#, House#, Street, City, State, ZipCode, County) Name(FirstName, MiddleName, LastName) Multivalued attribute –a single entity may have multiple values (a set of values) for the attribute Colors of a CAR, denoted by composite and multivalued attributes may be nested (to any number of levels) –

15. 15 Example of composite attributes 주소 우편번호번지동구시 호수번지수아파트명

16. 16 Types of Attributes (2) derived attribute: value can be derived from the value of the related attribute –(e.g.) entity : person attribute : age, birthdate null value –value of attribute is missing –semantics not applicable (e.g. military id for woman) unknown but exists (e.g. height of person) nonexist (e.g. pager number) and much more

17. 17 Example of an ER diagram –Entity type: rectangular box –Attribute: oval –key attribute: underlined –Composite attribute –Multivalued attribute: double oval –Derived attribute: dotted oval employee SSN salary First namebirthdate LastM.I. hobby

18. 18 Relationships A relationship (or relationship instance) relates two or more entities and has a specific meaning Relationship in the ER model has one name in both direction, while in ODL we separately specify a relationship and its inverse. Relationship in the ER model can involve more than two entities, while ODL relationship involves at most two classes e1 e2 e3 e4 e5... r1 r2 r3 r4 r5... d1 d2 d3... EMPLOYEE WORKS_FORDEPARTMENT

19. 19 Relationship Types relationships of the same type are grouped into a relationship type Entity types participate in a relationship type Entities participate in a relationship instance More than one relationship type can exist between the same entity types –MANAGES, WORKS_FOR are two distinct relationships between EMPLOYEE and DEPARTMENT –each has a specific meaning A relationship type can have attributes

20. 20 ER Diagram Notation A graphical technique to display many aspects of an ER schema (entity types, relationship types, attributes, structural constraints,...) –Entity types displayed in rectangular boxes –Relationship types displayed in diamond-shaped boxes –Weak entities displayed in double rectangular boxes –Attributes displayed in ovals One of the main reasons for the popularity of the ER model and its variation in database design Numerous other notations have been suggested and used ER diagrams (or variants) are used in many CASE tools

21. 21 An ER diagram for the movie database Movies title Stars-in Owns year flimTypelength Studios Stars name addressname address

22. 22 Multiplicity of ER relationships In this textbook, an arrow is used ! Multiplicity is also called cardinality ratio constraint If a relationship is many-one from entity set E to entity set F, then we place an arrow entering F. Studios Runs Presidents

23. 23 Recursive Relationships and Roles Recursive relationship: a relationship may relate two entities of the same entity type each entity type plays a distinct role Example: The recursive relationship SUPERVISION plays two roles of supervisor (1) and supervisee (2) EMPLOYEE SUPERVISION supervisorsupervisee e1 e2 e3 e4 e5... r1 r2 r3... EMPLOYEE SUPERVISION 1 2 1 2 2 1

24. 24 Examples of recursive relationship Stars Contracts Movies Studios Studio of starProducing studio Sequel-of Movies Original Sequel

25. 25 Multiway relationship (1) The number of participating entity types is called degree of relationship –binary, ternary, etc –For a particular star and movie, there is only one studio with which the star has contracted for that movie –A studio may contract with several stars for a movie, and a star may contract with one studio for more than one movie Stars Contracts Movies Studios

26. 26 Multiway relationship (2) In general, an n-ary relationship is not equivalent to n binary relationships (connection trap) In general, a ternary relationship type represents more information than do three binary relationship types SUPPLIER SUPPLY PROJECT SName Quantity ProName PART PartNo CAN_SUPPLY USES PART PartNo SUPPLIER SUPPLIES PROJECT ProName SName N N N M M M

27. 27 Attributes of Relationship Type –relationship type can also have attributes –attributes of 1:1 or 1:N relationship type can be included in entity types (for example, for 1:N case, include the attributes in N-side entity type) –attribute of M:N relationship type must be specified as a relationship attribute i.e. must be in relationship type Movies Contracts Stars Studios titleyear length flimType salary address name addressname

28. 28 Converting multiway relationship to binary Any relationship connecting more than two entity sets can be converted to a collection of binary many-one relationship without losing any information Stars Star-of Contracts Movies Movie-of Studio of star Studios Producing studio

29. 29 Design principles (1) Should be faithful to specifications Avoid redundancy Simplicity Movies Studio owns StudioName Movies Repre- sents Owns Studios Holdings

30. 30 Design principles (2) Picking the right kind of element –Repeats address every time (i.e. redundancy) –Loses studio data if it does not own a movie Movies titleyear flimTypelength studioAddress studioName Movies title owns year flimTypelength Studio addressname

31. 31 Multiway relationship vs. several binary relationships Remember, ODL relationship is always binary ! Suppose that contracts involve one star, one movie, and any set of studios, i.e. (star, movie, set-of-studios) Stars Star-of Contracts Movies Movie-of Studios Studios-of

32. 32 Inheritance in ODL A subclass inherits all the properties (attributes and relationships) of its superclass Reusability ! interface Cartoon: Movie { relationship Set voices; }; interface MurderMystery: Movie { attribute string weapon; }; interface Cartoon-MurderMystery: Cartoon, MurderMystery { }; Movie Cartoon MurderMystery Cartoon-MurderMystery

33. 33 Multiple inheritance in ODL When a class C inherits from several classes, there is the potential for conflicts among property names ODL does not define a specific syntax about it, but implementations of ODL should provide a mechanism that resolves name conflict

34. 34 Inheritance in ER model (1) Suppose class C is a subclass of class D –create a special relationship called isa that relates C and D –Attach attributes or relationship that pertain only to C class to the C box –Properties that apply to both C and D are placed at D Voices Murder- Mysteries Cartoons isa toStars weapon Movies lengthtitleyearflimType

35. 35 Inheritance in ER model (2) In ODL, an object must be a member of exactly one class In ER model –view an entity as having components belonging to several entity sets that are part of a single isa-hierarchy –The components are connected into a single entity by the isa relationships –The entity has whatever attributes any of its components has, and it participates in whatever relationships its components participate in

36. 36 Inheritance in ER model (3) –Note that there is no entity set corresponding to cartoon-murder-mysteries –What if there were some properties that belonged to cartoon-murder- mysteries Voices Murder- Mysteries Cartoons isa toStars weapon Movies lengthtitleyearflimType

37. 37 Integrity constraints Integrity constraint (IC) is an assertion (or condition) that must be satisfied all the times. ICs serve as validity criteria of database instances. In general, details of ICs are tightly related with underlying data model: Details of ICs are different, depending on data model being considered Common examples of ICs include: –key constraints –single-valued constraint –referential integrity –domain constraint –general constraints –functional dependency, multivalued dependency

38. 38 Key constraints In ODL, a set of attributes or an attribute of a class for which each object must have a unique value. Similarly for ER model too. –EmployID of EMPLOYE – 주민등록번호, SSN (social security number) – 차량번호, 학번,... key attribute may be composite –CarRegistration(State, Number) of a CAR an entity type may have more than one key attribute –CarResistration(State, Number) and VehicleId are two keys of a CAR entity type

39. 39 Declaring keys in ODL and ER model Interface Movie (key (title, year))// composite key { … } Interface Employee (key empID, ssNo)// two separate keys { … } ER diagram Movies length titleyear filmType // composite keys

40. 40 Single-value constraint Single-value constraint requires an attribute to have at most one value ODL –declare attribute with appropriate type –If the type is not a collection type, then there can be only one value for that attribute or only one related object for a relationship ER model –each attribute of an entity type has a single value by implication –If a relationship has an arrow to an entity set E, then there is at most one entity of E associated with other entities of the other related entity sets

41. 41 Referential integrity While single-value constraints assets that at most one value exists in a given role, a referential integrity constraint assets that exactly one value exists in that role. Referential constraint = non-null + single-value constraint Referential constraint in ER diagram: rounded arrowhead to F –If a studio ceases to exist, its president can not longer be called a president –Each studio has at most one president, but might have no president at some time Movies Owns Runs Presidents Studios

42. 42 Other kinds of constraint Domain constraints restrict the value of an attribute to be in a limited set ODL supports a rudimentary form of domain constraints –a type of each attribute –Not ranged domain such that 10 < x < 60 In ER model, attach a bounding number to the edges Movies Stars-in Stars <= 10

43. 43 Weak entity set (1) An entity type (or set) that does not have a key attribute of its own –(ex) a Crew entity is identified by a combination of number and the particular Studio name that the crew is related to Entities in weak entity types are identified by being related to specific entities and their attribute values from another entity type A weak entity type (double rectangular) must participate in an identifying relationship type (double diamond) with an owner (or identifying) entity type A weak entity set often has a partial key number name addr Crews Unit-of Studios

44. 44 Weak entity set (2) Another example is the connecting entity sets ! Key of contracts = studio name + star name + movie title + movie year salary Contracts Star-of StarsStudios Movies name addr name addrtitleyear length filmType Studio-of Movie-of

45. 45 Requirements of weak entity set If E is a weak entity set then each of the entity sets F that supplies one or more of E’s key attribute must be related to E by a relationship R –R must be a binary, many-one relationship for E to F –The attributes that F supplies for the key of E must be key attributes of F –If F is itself weak, then the key attributes of F supplied to E may be attributes of some entity set to which F is connected by a many-one relationship –If there are several many-one relationships form E to F, then each relationship may be used to supply a copy of the key attributes of F to help form the key of E

46. 46 Network model We may think of the network model as the ER model restricted to binary, many-one relationships –Logical record types are similar to entity set. The member of the logical record type are called records; they are analogous to entities in the ER model –Link represents a many-one and binary relationship from owner type to member type A B Owner (parent) Member (child)

47. 47 Example of network model Since “stars-in” relationship is many-many, create a new logical record type, called StartsIn StarsStarsInMovies TheStarTheMovie Basic Instinct 1 Total Recall Sharon Stone Arnold Schwarzenegger 23

48. 48 Hierarchical model A restriction of the network model in which the logical record types and links form a forest (collection of trees) In hierarchical model, represent many-many relationships by creating a virtual copy of each of the related types. –Virtual record contains a logical pointer to a physical record Stars Virtual Movies Virtual Stars

49. 49 Hierarchical representation of movie/star Sharon Stone Arnold Schwarzenegger Basic Instinct Total Recall to Basic Instinct To Sharon Stone To Sharon Stone To Arnold Schwarzenegger To Total Recall To Total Recall * : virtual record *** * **

50. 50 Exercise of ER diagram: A COMPANY Database –The company is organized into departments. Each department has a name, a number, and an employee who manages the department. We keep the track of the start date when that employee started managing the department. A department may have several locations. –A department controls a number of projects, each of which has a name, a number, and a single location. –We store each employee's name, social security number, address, salary, sex, and birth date. An employee is assigned to one department but may work on several projects, which are not necessarily controlled by the same department. We keep track of the number of hours per week that an employee works on each project. We also keep the track of the direct supervisor of each employee. –We want to keep the track of the dependents of each employee for insurance purposes. We keep each dependent's name, sex, birth date, and relationship to the employee.