Chap 3. High-Level Database Models

Chap 3. High-Level Database Models

Contents The Entity/Relationship Model Design Principles
Constraints in the E/R Model Weak Entity Sets From E/R Diagrams to Relational Designs

< the database modeling and implementation process >
Introduction Data model - abstract descriptions of data - descriptions of data: structure, operations, constraints Database design specify a logical structure of database and constraints on it Relational Database Schema High-Level Design convert Relational DBMS Ideas (conceptual design) < the database modeling and implementation process > What information will be stored How information will be related to one another What constraints, such as keys or referential integrities, may be assumed Ideas

Introduction (cont’d)
Relational model for database design relational model has only one concept, i.e. relation, rather than several concepts that more closely model real-world situations Simplicity is a great strength, especially for efficient implementation of database operations is a weakness to express variety of concepts  To use a high-level design model is helpful for preliminary design

Introduction (cont’d)
high-level design model: usually focus on the structure and the constraints Conceptual data models notations for expressing database design Entity-Relationship (E/R) model UML (Unified Modeling Language) originally designed for describing object-oriented SW projects, but has been adapted to describe database schema ODL (Object Description Language) describe databases as collections of classes and their objects

The Entity/Relationship Model
Entity-Relationship(E/R) Model a structure of data is represented graphically, as an “E/R diagram” E/R diagrams graph representing entity set, attributes and relationships entity set /* entity type */ a collection of similar entities, where an entity is an object of some sort attribute: a property of an entity relationship: connection among two or more entity sets three principal elements in the E/R model a property among two or more entity sets

The Entity/Relationship Model (cont’d)
(Ex) An E/R diagram for the movie database Owns Studios length Movies title year genre Stars name Stars-in address Some star appears in some movie Some studio owns some movie Relationship: connection information among entity sets

Skip Instances of an E/R diagram E/R diagram is a notation for describing schemas of databases a database described by an E/R diagram has particular data, i.e., an instance of database For each entity set, a database instance has a set of entities each entity has a particular value for each attribute A relationship R connecting n entity sets E1, E2, , En may be imagined to have an “instance” that consists of a set of tuples (e1, e2, . . ., en), where ei is an entity in Ei

connection of two entities, each from Movies and Stars (Ex) An instance of the Stars-in relationship, visualized as a table. Movies Stars Basic Instinct Sharon Stone Total Recall Arnold Schwarzenegger Total Recall Sharon Stone these tuples are not really tuples of a relation, because components of each tuple is entities, not attributes Each row is an instance of the Stars-in relationship (ex) Consider the first tuple, (Basic Instinct, Sharon Stone). there is a Stars-in relationship between two entities ‘Basic Instinct’ and ‘Sharon Stone’ Entity ‘Basic Instinct’ and entity ‘Sharon Stone’ are connected by the Stars-in relationship

constraints as well as detailed descriptions about the relationship An arrow may be considered a function from one entity set to another Multiplicity of E/R relationships mapping cardinality, cardinality ratio constraint A movie can be connected to at most one studio many-one relationship Movies Studios Owns n 1 A studio can be connected to two or more movies one-one relationship Studios Presidents Runs 1 Movies Stars Stars-in many-many relationship n

Multiway relationships relationships involving more than two entity sets (Ex) Contracts relationship: a studio has contracted with a particular star to act in a particular movie Studios Stars Movies Contracts Contracts: not between Studios and Stars, but among Studios, Stars and Movies multiway relationship is rare binary relationship is common

The meaning of arrows Consider an arrow pointing to an entity set E. If we select one entity from each of the other entity sets in the relationship, those entities are related to at most one entity in E. Stars Movies      Contracts (sd2, sr1, mv1) (sd2, sr3, mv1) (sd2, sr3, mv2)  Instance of Contracts: (studio, star, movie) Owns  Movies Studios Studios

Roles in relationships one entity set can appear two or more times in a single relationship each edge represents a different role in the relationship label the edge by names, which we call “roles” Sequel-of Movies Original a relationship Sequel-of between the entity set Movies and itself Original Rocky I  Sequel-of Movies Rocky II Rocky III Sequel ... Sequel Rocky II is a Sequel-of Rocky I Rocky III is a Sequel-of Rocky I the role Original and the role Sequel differentiate the two movies in a relationship

(Ex) Contracts relationship One studio, having a certain star under contract, may further contract with a second studio to allow that star to act in a particular movie Studios Contracts Studio of star Producing studio Stars Movies Disney studio contracts with Smith. - Smith exclusively belongs to Disney Disney studio contracts with MGM studio. - Smith can act in Movie1 (Disney, MGM, Smith, Movie1) 4-tuples describing the relationship: (studio1, studio2, star, movie)

Attributes on relationships sometimes, we may need to associate attributes with a relationship (Ex) Record a salary associated with a contract Salary is associated with Studios, Stars and Movies altogether; not associated with only Studios, or Stars, or etc. Movies Contracts Studios Stars salary

It is not necessary to place attributes on relationships can invent a new entity set, which has attributes ascribed to the relationship Stars Contracts Studios Movies salary Salaries Possible design, but . . .

Converting a multiway relationship to binary relationships Some data model limit relationships to be binary e.g. UML and ODL a multiway relationship can be converted to a collection of binary, many-one relationships Create a connecting entity set the multi-way relationship is removed Create many-one relationships from the connecting entity set to each of the entity sets involved in the multiway relationship a connecting entity: an entity representing a single instance of the relationship

(Ex) Relationship Contracts where Studios has two roles. multiway relationship  binary relationships Movies Stars Stars Movies Star-of Movie-of Contracts (ct1, sr1) (ct2, sr1) (ct1, mv1) (ct2, mv2) Contracts Studio of star Producing studio Studio of star Producing studio Studios (ct1, sd1), (ct2, sd1) (ct1, sd2), (ct2, sd3) Studios Contracts relationship: (sd1, sd2, sr1, mv1) : ct1 (sd1, sd3, sr1, mv2) : ct2

Subclasses in the E/R Model an entity set may contain certain entities that have special properties not associated with all members of the set subclass special-case entity set which has its own special attributes and/or relationships isa relationship class-subclass relationship notation: a triangle isa relationship is one-one attributes, or relationships an entity in the subclass is associated with an entity in the superclass

(Ex) Cartoons and MurderMysteries are subclasses of Movies length title year genre To Stars Movies Voices isa isa weapon MurderMysteries Cartoons An isa Hierarchy: a tree of isa relationships (does not imply inheritance)

(Ex.-cont’d)  Where is the entity representing the cartoon movie“Ice Age”? length title year genre To Stars Movies Voices isa isa weapon Cartoons MurderMysteries An isa Hierarchy does not imply inheritance

E/R view of subclass Consider a tree of entity sets connected by isa relationships an object in a subclass is also in its superclass an object is represented by an entity in the root of an isa hierarchy together with an entity in the subclass (or entities in the subclasses) Class/subclass in the object-oriented approach an object exists in exactly one class or subclass a subclass inherits all the attributes and relationships of its superclasses every object has a corresponding entity in the root an entity in the root is allowed to have its representatives in a tree of entity set

Design Principles Faithfulness
The design should be faithful to the specifications of the application (Ex) Attribute number-of-cylinders to Stars: not appropriate (Ex) Relationship Stars-in between entity sets Stars and Movies many-many relationship is appropriate (Ex) Relationship Teaches between entity sets Courses and Instructors many-one, or many-many depending on the policy and intentions of the organization Only the information we want to maintain in the database need to be modeled Modeling elements must reflect reality correctly may make sense for an entity set Automobiles

Design Principles (cont’d)
Avoiding redundancy specify everything only once Suppose there is redundancy in an E/R design. When we convert the E/R design to relational implementation, extra space is required update-anomaly can occur (Ex) Owns relationship between movies and studios Suppose we have an attribute studioName in entity set Movies not illegal, but redundant Owns Studios addr name length Movies title year genre studioName

Simplicity Avoid more elements than are absolutely necessary (Ex) Suppose we have an entity set “Holdings” for the ownership of a single movie Movies Repre sents Holdings Owns Studios Technically, no problem in the above structure however, we are better off without it

Choosing the right relationships Entities can be connected in various ways by relationships Adding every possible relationship is not often a good idea if the same information can be deduced from other relationships Choose the relationship without redundancy may lead to redundancy, update anomalies, and deletion anomalies

(Ex) Consider a three-way relationship Contracts. Stars-in title year Stars name address Movies length Contracts genre Owns Do we also need Owns and Stars-in ? Studios address name

(ex. cont’d) Do we need relationship Owns? Owns relationship is not needed if for every movie, there is at least one contract involving that movie, its owning studio and some star for that movie. relationship Owns can be deduced We must retain Owns if there is the possibility that a studio owns a movie, yet has no stars under contract for that movie. relationship Owns cannot be deduced i.e., no contract relationship involving that movie

(ex. cont’d) Do we need relationship Stars-in? Stars-in is not needed if a star can appear in a movie only if there is a contract involving that star, that movie, and the owning studio for the movie. relationship Stars-in can be deduced Necessity of a certain relationship depends on the real world situation for a given application cannot tell whether a given relationship will be redundant, in general

(Ex) Consider the following E/R diagram Stars Stars-in Works- for Movies Owns Do we need a relationship Works-for ? Studios

(ex. cont’d) Do we need relationship Works-for? may depend on the meaning of Works-for no good reason to include it if the meaning of Works-for is “the star appeared in at least one movie of this studio” This information can be deduced from Stars-in and Owns. would not be redundant if the meaning of Works-for is independent of the Stars-in and Owns relationship

Picking the right kind of element Sometimes, we may have options to represent a real-world concept. Use attributes? Use entity set/relationship combination?

(Ex) Consider entity sets Movies and Studios, and the relationship Owns. Remove Studios and Owns, and make attributes of Studios be attributes of Movies title year name title year s-name Owns a Movies Studios Movies s-addr length genre addr length genre Repetition of the <s-name, s-addr> of studio, for each movie Update anomaly if change the address for only some movies Deletion anomaly if delete the last movie owned by a given studio

(ex. cont’d) if we need more information on studios rather than simply its name, desirable to make Studios an entity set if studios has only name as its attributes, no harm in making the studio name as an attribute of Movies

e.g., Studios Conditions to prefer an attribute, instead of an entity set E For all relationships in which E is involved, E must be the “one” in many-one relationships No attribute of E depends on the other attributes /* The key for E is all the attributes */ (ex) In Studios, address depends on name No relationship involves E more than once (ex) Movies and Sequel-of If these conditions are met, we can replace entity set E by attributes No multivalued attribute Multivalued attribute, if E is in “many” side No repetition of information Repetition of information, if attributes depend on the other attributes Thus, Studios does not meet this condition Relationship information is lost No loss of relationship information

Replace entity set E by attributes Suppose R is a many-one relationship to E If R is a binary relationship, remove E and R make attributes of E be attributes of the other entity set F involved in R  Combine two entity sets  Keep all the attributes, while removing the relationship f1 e1 e2 f1 a R e1 F E F e2

If R is a multiway relationship, make the attributes of E be attributes of R delete an arc from R to E salary Salaries salary a Contracts Contracts Movies Stars Stars Movies Studios Studios

Constraints in the E/R Model
key for an entity set referential-integrity constraint degree constraint

Constraints in the E/R Model (cont’d)
Keys in the E/R model E: an entity set key: a set K of one or more attributes any two distinct entities e1 and e2 in E cannot have identical values for each of the attributes in K if more than one key, pick one as the “primary key” In isa-hierarchy, the root entity set must have all the attributes for a key

Representing keys in the E/R model underline the attributes belonging to a key for an entity set title year name Stars-in Movies Stars address length genre no notation for representing several keys for an entity set underline only the primary key

Referential Integrity a value appearing in one context must also appear in another the entity “referenced” by the relationship must exist Owns Runs Movies  Studios  Presidents a rounded arrow the relationship is many-one or one-one the entity pointed by the rounded arrowhead must exist referential integrity: ’one’ must exist in many-one relationship

Degree constraints limit the number of entities that can be participated in a relationship attach a bounding number to the edges that connect a relationship to an entity set Movies Stars-in Stars £ 10 arrow: a synonym for the constraint “≤ 1” rounded arrow: a synonym for the constraint “= 1”

Weak Entity Sets Weak entity set
Studio-A: crew 1, crew 2, . . . Studio-B: crew 1, crew 2, . . . Weak entity set an entity set whose key is composed of attributes, some or all of which belong to another entity set cannot be identified without a supporting entity (ex) A movie studio has several film crews. weak entity set: supporting relationship: number crewChief name address Unit-of Crews  Studios supporting entity set (identifying owner, identifying entity set, strong entity set) weak entity set supporting relationship (identifying relationship)

Weak Entity Sets (cont’d)
Causes of weak entity sets entity sets that are subunits in a hierarchy based on some classifications (Ex) A studio has several crews (Ex) A species is a subunit of a genus Homo Sapiens genus species Names of species are not unique name name Belongs-to Species  Genus To uniquely identify a species, we need both the species name and the genus name

Connecting entity sets The key for connecting entity sets formed from the attributes that are the key attributes for the entity sets they connect (Ex) Contracts: multiway relationship and connecting entity sets salary Contracts Stars Studios Movies

Connecting entity set: Note the weak entity set and the referential-integrity constraints salary Contracts Star-of Studio-of Movie-of    genre Movies Stars Studios length name addr name addr title year Note: there is no requirement in the E/R model that multiway relationships be eliminated. However, this requirement exists in some other database design models.

Requirements for weak entity sets weak entity set W supporting relationship R many-one, referential integrity strong entity set S Key for a weak entity set W zero or more of its own attributes, and key attributes of S that are reached by R from W W R  S We may need several strong entity set S’s for weak entity set W

R  S Conditions for supporting relationship R R must be a binary, many-one relationship a one-one relationship is a special case of a many-one relationship R must have referential integrity from W to S The attributes that S supplies for the key of W must be key of S If S is itself weak, some key attributes of S will be supplied from elsewhere by steps (1), (2), and (3) above, recursively

From E/R Diagrams to Relational Designs
E/R diagram to relational design (basic method) Convert each entity set to a relation for each strong entity set S, create a relation S with the same set of attributes Convert each relationship to a relation for each relationship R, create a relation R whose attributes are the keys of entity sets connected by R if the relationship has attributes, these attributes also become the attributes of relation R

From E/R Diagrams to Relational Designs (cont’d)
(Ex) From E/R to relational design name address Stars-in title year Stars Movies name address length genre Owns Studios title year length genre Star Wars sciFi Gone With the Wind drama Wayne’s World comedy title year studioName Star Wars Fox Gone With the Wind Disney Wayne’s World Paramount Relation for relationship Owns Relation for entity sets Movies

(Ex) From E/R to relational design (Cont’d) name address Carrie Fisher Maple St., Hollywood Mark Hamill Oak Rd., Brentwood Harrison Ford Palm Dr., Beverly Hills title year starName Star Wars Carrie Fisher Star Wars Mark Hamill Star Wars Harrison Ford Gone With the Wind Vivien Leigh Wayne’s World Dana Carvey Wayne’s World Mike Meyers Relation for entity set Stars name address Fox Hollywood Disney Buena Vista Paramount Hollywood Relation for relationship Stars-in Relation for entity set Studios

(Ex) Convert a multiway relationship to a relation Stars Movies Contracts Studio of star Producing studio Studios Contracts (starName, title, year, studio0fStar, producingStudio,) consists of the attributes from the keys of the entity sets connected by the relationship Contracts

Combining relations we may not need to create a relation for some relationship Many-one relationship If R is many-one, skey is a key for both S and R S (skey, s2) R (skey, tkey, r1) T (tkey, t2) S (skey, s2, tkey, r1)  T R S skey s2 r1 tkey t2 Instead of creating a relation for R, add to S all attributes of R and the key of T This has the effect of combining two relations that have a common key

(Ex) Combining relation Movies with relation Owns title year length genre studioName Star Wars sciFi Fox Gone With the Wind drama MGM Wayne’s World comedy Paramount reduce the number of tables will be more efficient for some queries involving attributes of Movies and Owns relationship

one-one relationship S (skey, s2, tkey, r1) T (tkey, t2) ST (skey, s2, tkey, r1, t2)  S (skey, s2) R (skey, tkey, r1) T R S skey s2 r1 tkey t2 Instead of a relation for R, add to S all attributes of R and the key of T Instead of creating relations for S, T and R combine them into one relation

Combine an entity set with a many-many relationship leads to redundancy Not a good design ! (Ex) Combine the entity set Movies with relationship Stars-in title year length genre starName Star Wars sciFi Carrie Fisher Star Wars sciFi Mark Hammil Star Wars color Harrison Ford Gone With the Wind drama Vivien Leigh Wayne’s World comedy Dana Carvey Wayne’s World comedy Mike Meyers

Handling weak entity sets the relation for a weak entity set W all the attributes of W all the attributes of supporting relationships for W all the key attributes of the supporting entity sets for W the relation for supporting relationships do not construct a relation !!! For a relationship that is not a supporting relationship, - use the general method of converting a relationship to a relation

(Ex) Studios and the weak entity set Crews number crewChief name addr Unit-of Crews  Studios title year Movies WorkOn Studios (name, addr) Crews (number, studioName, crewChief) length genre Unit-Of (number, studioName) Simply a subset of Crews ! Do not make this relation. WorkOn (crewNumber, studioName, title, year) the key for Crews

Note: Relations with subset schemas
The attributes of relation R is a subset of attributes of relation W. Schema(R)  Schema(W) we need R when R holds information that is not in W e.g., R has tuples that are not extended to tuples of W (ex) TaxPayers(name, ssn, amount) People(name, ssn) we need not, otherwise (ex) R: relation from a supporting relationship; W: from a weak-entity set for each tuple of R, there is in W a corresponding tuple that has the exactly the same meaning Do we need to eliminate R? Tables in the IRS maintains the amount of tax paid by each person who filed a tax return maintains potential taxpayers even if the persons did not file tax returns. useful in remembering the ssn’s of the persons who are not in Taxpayers.

Converting Subclass Structures to Relations
isa-hierarchy in the E/R model there is a root entity set for the hierarchy the root entity set has a key that serves to identify every entity represented by the hierarchy Note: for every object, there is an entity in the root entity set for a given object, some components may be in the entity sets for subclasses i.e., a given object may have components that belong to the entity sets of any subtree of the hierarchy Subclass modeling  want to manage a certain set of objects separately

Converting Subclass Structures to Relations (cont’d)
Three conversion strategies E/R viewpoint every entity in a subclass is a some entity in the root an object may consist of an entity in the root + some entities in a subtree starting from the root of the hierarchy Object-oriented approach an entity belongs to a single class an object is represented as a single entity, either in the root or in some subclass use null values /* ignore the isa hierarchy */

E/R-style conversion the “isa” relationship connect components of a single object (not distinct objects) i.e., two entities connected by isa represent a single object Do not create relations for “isa” relationships Convert each entity set to a relation for each entity set, create a relation that has all the attributes in the entity set a relation for a subclass includes the key attributes in the root

(Ex) Convert an isa hierarchy into relations length title year genre to Stars Movies(title, year, length, genre) MurderMysteries(title, year, weapon) Cartoons(title, year) Voices(title, year, starName) Movies Voices isa isa weapon Cartoons Murder- Mysteries <The movie isa hierarchy>

(Ex) Consider the isa hierarchy Movies i.e. types of movie objects length title year genre Four possible subtrees: Movies alone Movies and Cartoons only Movies and Murder-Mysteries only All three entity sets to Stars Movies Voices isa isa weapon Movies(title, year, length, genre) MoviesC (title, year, length, genre) MoviesMM (title, year, length, genre, weapon) MoviesCMM(title, year, length, genre, weapon) Voices(title, year, starName) Cartoons Murder- Mysteries <The movie isa hierarchy>

Using NULL values to combine relations use a single relation to represent objects in a superclass and objects in a subclass Convert an entire isa hierarchy to a single relation for an entire isa hierarchy, create a relation that has all the attributes of any entity set in the hierarchy an entity is represented by a single tuple this tuple has NULL in each attribute that is not defined for that entity (Ex) Consider the Movies hierarchy again. Movies (title, year, length, genre, weapon) Voices (title, year, starName)

Comparison of approaches E/R style conversion Query when only attributes in the root are used: advantage e.g., “what movies of 2008 were longer than 150 minutes?” when objects in the subclass are queried: disadvantage e.g., “find the weapons used in cartoons of over 150 minutes in length” Space: a little disadvantage several tuples for each object, and the key is repeated for those tuples every entity in a subclass is a some entity in the root entity set join is required because properties of an object are in multiple tables

Object-oriented approach Query when the relation in which an object is unknown: disadvantage need to access all the relations in the hierarchy e.g., “what movies of 2008 were longer than 150 minutes?” i.e., need to search all Movies, MoviesC, MoviesMM, MoviesCMM when we know the class of object to be queried: advantage every properties of the object is in one relation e.g., “find cartoon movies of over 150 minutes?” Use the minimum space: advantage each object belongs to a single class

Conversion using NULL values handle all the objects in a single relation has one tuple per entity, but this tuple is long Query simple because of only one relation: advantage no need to join when only objects known to be in one subclass are queried: a little disadvantage Waste of space: disadvantage many NULL values may occur Do not keep a particular set of objects separately  Meaning of some subclass may be lost, e.g., Cartoons: disadvantage

Chap 3. High-Level Database Models

Similar presentations

Presentation on theme: "Chap 3. High-Level Database Models"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chap 3. High-Level Database Models

Similar presentations

Presentation on theme: "Chap 3. High-Level Database Models"— Presentation transcript:

Similar presentations

About project

Feedback