Semantic Data Models - PowerPoint PPT Presentation

1 / 45
About This Presentation
Title:

Semantic Data Models

Description:

Relational Model is value-based. ... Semantic and Object Oriented Models are object-based. ... Structured Query Language (SQL) is based on the relational calculus. ... – PowerPoint PPT presentation

Number of Views:586
Avg rating:3.0/5.0
Slides: 46
Provided by: larryker
Category:

less

Transcript and Presenter's Notes

Title: Semantic Data Models


1
Semantic Data Models
  • Semantic Data Model Primitives
  • Entity-Relationship Model
  • Relational Data Model
  • Case Study
  • Object Modeling Technique

2
Semantic and Object-Oriented Models
  • Data Model is a language to define the Enterprise
    Schema
  • Structure, Operations, Constraints
  • Relational Model is value-based.
  • A relation is simply a collection of tuples whose
    values are taken from domains.
  • Relational algebra and calculus, plus insert,
    delete and modify provide the operations.
  • Key constraints.

3
Semantic and Object-Oriented Models.
  • Entity Relationship Model is entity-based.
  • ER model entities are static entities identified
    by a key.
  • Insert, delete, and modify plus graph-oriented
    query languages.
  • Keys, weak and strong entity types, etc.
  • Semantic and Object Oriented Models are
    object-based.
  • Attempt to capture the meaning of data not only
    in the structure of the objects, but also in the
    operations upon the objects.

4
Semantic Modeling Primitives
  • Aggregation
  • Lower level types can be aggregated into a higher
    level type. This construct is used group
    attributes or properties of a similar object into
    the object type.
  • The relational model aggregates attributes into
    relations.
  • Title and Author types can be aggregated into the
    type Publication
  • Street, City, State, Zip can be aggregated into
    Address.
  • Is-part-of or converselyIs-composed-of
    relationship.

5
Semantic Modeling Primitives
  • Generalization/Specialization
  • Different object types may be differentiated by a
    property (predicate) but when viewed by the
    similarities, can be generalized to a higher
    level type.
  • For example, the concepts of Journal_Paper, Book,
    and Conference_Paper can be generalized to
    Publication.
  • Journal_Paper IS-A Publication
  • Book IS-A Publication
  • Conference_Paper IS-A Publication
  • Publication would have attributes common to all
    publications while the subtypes journal paper,
    book and conference paper would have specialized
    attributes.

Publication
is-a
is-a
is-a
Conference Paper
Book
Journal Paper
6
Semantic Modeling Primitives
  • Classification
  • A collection of object instances can be
    associated to an object type by means of the
    is-instance-of relationship. This relates
    database tokens (instances) to their types.
  • Association
  • A form of abstraction in which a relationship,
    the is-member-of relationship, between member
    objects is considered a higher-level set object.
  • Students enroll in Classes taught by Instructors,
    so the concept of Enrollment is and association
    among students, classes and instructors.

Enrollment
is-member-of
Student
Course
Instructor
7
Entity Relationship Model
  • Entity Relationship Model is a Data Model that
    captures
  • Entities objects that exist and are
    distinguishable from other objects.
  • Relationships capture associations among
    entities. These many be binary associations as
    well as n-ary associations.
  • Entity Sets collections of entity instances
    of the same type or characteristics.
  • Relationship Sets collections of relationship
    instances of the same type.
  • Attributes properties of entities and
    relationships pertinent to the application.
  • Domain the possible values an attribute may
    take.
  • Attribute is a function mapping an entity set
    into a domain
  • Attri ESj Di, where ES and D denote Entity
    Sets and Value Domains, respectively.
  • Each entity is described by Attribute, Value
    pairs.

8
Entity Relationship Diagrams
  • Entity Sets are denoted by rectangles
  • Relationship Sets are denoted by diamonds
  • Attributes and Connectors by arrows and links
  • Value Sets by ellipses

9
Relationship Sets
  • R Í (e1, e2, ...., en) e1 e E1, e2 e E2, ...,
    en e En
  • where ( e1, e2, ...., en ) is a relationship.
  • Roles denote the functions or roles played by the
    entities within a relationship.
  • Consider the relationship of Management in
    which one employee manages several other
    employees.
  • One employee plays the role of worker while the
    other is the supervisor.
  • Note that relationships are bi-directional and
    management-1 (inverse of management) also exists.

10
Mapping Constraints in the E/R Model
  • One-to-One an entity in A is associated with at
    most one entity in B.
  • One-to-Many an entity in A is associated with
    any number in B, but one in B with at most one
    in A.
  • Many-to-One entity in A associated with at most
    one in B, but one in B with many in A.
  • Many-to-Many entity in A associated with many
    in B and vice-versa.

11
Constraints in the E/R Model
  • An existence dependency is a constraint that
    states that entity x depends on the existence of
    entity y.
  • If entity y is deleted then entity x should also
    be deleted from the database.
  • y is the dominant entity, and x is the
    subordinate entity.
  • Keys Constraints
  • Superkey is a set of one or more attributes
    which, when taken together, allow the unique
    identification of an entity within an Entity Set.
  • Note that if K is a superkey, then so is a
    superset of K.
  • Candidate Key is a superkey with no proper
    subsets that are superkeys.
  • Primary Key is a candidate key which has been
    designated the unique identifier for an entity
    set.
  • Weak Entity Sets do not have a primary key and
    rely on their Strong Entity Set for key
    information.

12
E/R Diagrams
  • Example Customers have accounts in a bank and
    each transaction against an account is logged.
  • Each customer has a name, social security number,
    street address and city.
  • Each account has an account number and balance.
  • Each transaction has a date, transaction number
    and amount. Note that the transaction is a weak
    entity set in that it depends on the accounts
    existence.

13
Semantic Extensions to the E/R Model
  • Generalization
  • Entity sets may be specialized based on
    properties,
  • Accounts may be saving-accounts and
    checking-accounts.
  • This allows each sub-type entity sets to have
    attributes particular to that type.
  • Conversely, we may generalize to a super-type
    entity set, for example Student, Secretary,
    Mechanic may be generalized to Employee which in
    turn may be generalized to Person.
  • Aggregation
  • The original E/R model does not allow
    relationships involving other relationships.
  • Aggregation is a abstraction by which a
    relationship (and its associated entities) are
    considered as high-level entities.

14
Relational Model of Data
  • Data Model is based on set theory
  • Structure a set of mathematical relations which
    are represented as tables.
  • Operations Relational Algebra which is
    proceduraland Relational Calculus which is based
    on the predicate calculus.
  • Constraints Key constraints and integrity
    constraints.
  • Structured Query Language (SQL) is based on the
    relational calculus.
  • Cartesian Product forms the product of two
    relations.

15
Relational Algebra
  • Select selects tuples from a relation that
    satisfy a predicate.
  • Project is a unary operation that projects a
    relation on certain attributes (or columns) and
    get rid of duplicate tuples.
  • Set Difference the difference of two compatible
    relations.
  • Union forms the union of two compatible
    relations when taken as set of tuples.
  • Rename allows renaming a relation.

16
Relational Algebra (Continued)
  • Set Intersection finds tuples in common in two
    relations
  • Natural Join allow two or more relations to be
    joined based on the Cartesian product and
    selection operations.
  • Division operation which is equivalent to
    universal quantification in the relational
    calculus.
  • Assignment allows the definition of temporary
    relations for storing intermediate results of a
    query.

17
In Class Case Study NASA Space Missions
The NASA Space Missions Database Requirements
Specification 1. Each Mission shall have an
identification number, name, Space Shuttle or
Booster Rocket, date of launch. 2. The Space
Shuttle shall have a name, date of launch, crew
member names, and date of return. Note that
Shuttles are reusable so that a shuttle may be
used to launch several missions but only one at a
time. Thus the dates of launch and return from
mission to mission shall not overlap. However, a
shuttle, as part of its mission may be instructed
to repair experiments or satellites associated
with other already launched missions. 3. A
Booster Rocket shall have an identifier, a name,
and type (e.g., SATURN V, ATLAS, etc.). 4. Each
Mission may have several experiments. Each
experiment is denoted by a unique identifier, an
experiment name, a power configuration, and a
physical space requirement. These latter
attributes are used by NASA Engineers to
configure the entire shuttles power requirements
and instrument layout. Each experiment has a
Principal Investigator, or PI, with a given NASA
Identifier, a name, home institution, phone, Fax,
and e-mail address. The experiment also has a
research team associated with it. These may
include Co-Principal Investigators, Research
Associates, Graduate Research Assistants and
Post-Doctoral Students. Each of these, including
the PI, has a Social Security Number, Institution
ID, name, title, and local phone number. 5. Each
experiment has associated with it several "runs
in which data is collected and stored on tape for
eventual transmission to a Ground Control Center
at NASA Goddard Space Flight Center at Greenbelt
Maryland. The transmission makes use of the
TDRSS network of satellites to encode data as
packets that are relayed to Goddard and then
stored in a "History database". The
reconstructed files of data are then made
available to scientists either by access to
NASA's DBMS or via the Internet using FTP within
the TCP/IP protocol. 6. You are to specify a real
or fictitious experiment and define the various
attributes and types of data that the experiment
would be required to measure and store.
18
In Class Case Study NASA Space Missions Queries
Typical Queries that NASA Decision Maker might
ask. Note that these queries are themselves
requirements that you should somehow incorporate
into your Database Schema, either as entity
types, relationship types, attributes,
constraints, etc. Query 1 List the names and
affiliations of PIs for all experiments. Query
2 Which experiments were launched aboard the
shuttle Atlantis during Fiscal Year 1994. Query
3 Which experiments were launched aboard the
shuttle Atlantis during Fiscal Year 1994, whose
PIs were from the University of Wisconsin or
George Mason University? Query 4 Provide the
names of the missions for experiments satisfying
Query 3. Query 5 List the crew members for the
shuttle that launched the Hubbell Space
Telescope. Query 6 What was the total cost of
experiments associated with the COBE mission, and
when was it launched? Query 7 Provide the names
and dates of mission launched using booster
rockets, and list the type of rocket used.
Query 8 List the Shuttle launches, and mission
names, for which 'Anderson' was a member of the
crew. Query 9 Specify a view that provides the
data lineage of a scientific experiment, that is,
a full specification of the experiment, the data
used, the configuration of the instruments, the
location of sensors, the specific algorithms used
of product processing, etc. 1) Design an Entity
Relationship Diagram for the NASA
application. Hint The next slide shows some of
the entity sets and semantic relationships or
links. Use this to draw the E/R Diagram. 2)
Design a Relational Database Schema for the NASA
application, based on your E/R Schema.
19
(No Transcript)
20
Object Modeling Technique (OMT)
  • Object-oriented analysis method
  • J. Rumbaugh et al, "Object-Oriented Modeling and
    Design", Prentice Hall, 1991
  • Addresses
  • Structural (static) aspects of problem
  • Object Model
  • Dynamic aspects of problem
  • Dynamic Model
  • Functional aspects of problem
  • Functional model

21
Objects
  • Objects represent things in real world
  • Provide understanding of real world
  • Form basis for a computer solution
  • An Object (object instance) is a single thing
  • E.g., Johns car
  • Marys account
  • A Class (object class) is a collection of objects
    with the same characteristics
  • E.g., account, employee, car, customer

22
Examples of Object Classes
Customer
Account
23
Classes and Objects
Customer
Objects
(Customer) Larry Kerschberg
(Customer) Alok Kolaskar
24
Attributes
  • Attribute
  • Data value held by object in class
  • Example of Attributes
  • E.g., account number, balance
  • Each object instance has specific value of
    attribute
  • Johns account number is 1234
  • Marys account number is 5678
  • Attribute name is unique within a class

25
Class with Attributes
Account
Account integer Balance real
26
Class with Attributes
Account
Account integer Balance real
Objects With Values
(Account)
(Account)
Account 1234 Balance 525.36
Account 5678 Balance 1,897.44
27
Operations
  • Object has operations
  • Operations are procedures or functions
  • Access data maintained by an object
  • Operations may have
  • Input parameters
  • Output parameters
  • E.g., Read Account (Account , Balance),
  • Input parameter Account
  • Output parameter Balance
  • Update Account (Account , Amount)
  • Input parameters Account , Amount

28
Object Classes and Operations
  • Operation
  • Is function or procedure that may be applied to
    objects in a class
  • All objects in class have same operations
  • Class has one or more operations
  • Operations manipulate values of attributes
    maintained by object
  • Main difference between object classes and entity
    types in entity-relationship modeling
  • Object classes have operations
  • Entity types do not have operations

29
Class with Attributes and Operations
Account
Account integer Balance real
Read Account Update Account
30
Characteristics of Object Classes
  • A Class (object class) is a collection of objects
    with the same characteristics
  • Same attributes
  • Same operations
  • Same relationship to objects in other classes
  • E.g., car, account
  • Different classes may have same attribute name,
    same operation name
  • E.g., class Customer and class Employee
  • Have attributes name and address

31
Polymorphism
  • Polymorphism
  • Greek for many forms
  • Name of operation can be shared among several
    classes
  • Specification of operation is identical for each
    class
  • Each class can implement operation differently
  • E.g. operation Draw is implemented differently
    for circles and squares

32
Identity of Objects
  • Each object
  • Has identity Is distinguishable from other
    objects
  • Two objects of same class have same
    characteristics in all respects
  • Jacks car, Suzies car Johns account, Marys
    account
  • Each object has unique identity
  • Identity should be characteristic of problem
    domain, such as account number, vehicle
    identification number, customer name, mission ID

33
Objects and Classes
  • Decomposition of problem into objects
  • Based on judgement and characteristics of problem
  • No single correct representation
  • Whether objects are in same class or different
    class depends on nature of problem
  • In auto catalog
  • cars, vans, trucks may all be objects in same
    class
  • For vehicle manufacturer
  • cars, vans, trucks may all be objects of
    different classes

34
Object Modeling
  • Object class
  • Also referred to as class or object type
  • Real world entity type about which information is
    stored
  • Represents a collection of objects (instances)
  • Described by means of attributes (data items)
  • Has operations to access data maintained by
    objects
  • Each object instance can be uniquely identified
  • Association
  • Defines relationship between object classes

35
Links and Associations
  • Association is
  • static, structural relationship between classes
  • E.g, Employee works in Department
  • Link is
  • connection between object instances
  • instance of an association between classes
  • E.g, Jane works in Manufacturing
  • Link exists between two objects if and only if
    there is an association between their
    corresponding classes

36
Links and Associations
  • Association names usually read
  • left-to-right
  • top-to-bottom
  • Associations are inherently bidirectional
  • Name of association is forward direction
  • E.g, Employee works in Department
  • Opposite direction of association
  • E.g, Department has Employee
  • Associations are binary, ternary, or higher order

37
Multiplicity of Associations
  • Multiplicity
  • Specifies how many instances of one class may
    relate to a single instance of another class
  • E.g,
  • Employee works in one Department
  • Bank manages many Accounts
  • Car has 2 or 4 doors
  • Customer has zero or 1 debit card

38
Multiplicity of Associations
  • 1-to-1 association
  • Employee works in Department
  • 1-to-many association
  • Bank manages Accounts
  • Many-to-Many association
  • One course has several students
  • One student attends many courses
  • Optional association (0 or 1)
  • Customer Owns Debit Card

39
Aggregation Hierarchy
  • Assembly Structure
  • Shows components of aggregate (more complex)
    object class
  • IS PART OF Relationship between component class
    and aggregate class
  • E.g., Aggregate object class
  • Mission (mission_id, mission_name, mission_dates)
  • Component object classes
  • Spacecraft IS PART OF Mission Satellite IS PART
    OF Mission Instrument IS PART OF Mission
    Launcher IS PART OF Mission

40
Aggregation Hierarchy

41
Generalization/Specialization Hierarchy
  • Some object classes are similar but not identical
  • Have some attributes in common, others different
  • Common attributes abstracted into generalized
    object class (superclass)
  • E.g., Account (Account number, Balance)
  • Different attributes are properties of
    specialized object class (subclass)
  • E.g., Savings Account (Interest)
  • IS-A relationship between subclass and superclass
  • Savings Account IS-A Account

42
Generalization/Specialization Hierarchy
ACCOUNT
CHECKING ACCOUNT
SAVINGS ACCOUNT
43
Generalization / Specialization Hierarchy
  • Discriminator
  • Attribute that indicates which property of object
    is being abstracted by generalization
    relationship
  • E.g., Discriminator in Account generalization
  • Account Type
  • Discriminates between
  • Checking Account
  • Savings Account

44
Discriminator in GSHs
ACCOUNT
Account Type
CHECKING ACCOUNT
SAVINGS ACCOUNT
45
Inheritance
  • Subclass inherits generalized properties from
    superclass
  • Inheritance
  • Allows sharing of features between classes
  • Feature is Attribute or Operation
  • Allows adaptation of parent class (superclass) to
    form child class (subclass)
  • Subclass inherits attributes operations from
    superclass
  • May add attributes
  • May add operations
  • May redefine operations
Write a Comment
User Comments (0)
About PowerShow.com