ER and OO modeling - STI Innsbruck · • An entity is a identifiable object that exists in the...

© Copyright 2007 STI - INNSBRUCK www.sti-innsbruck.at

ER modeling OO modeling

Lecture 3

1

www.sti-innsbruck.at

Today‘s lecture

•  ER modeling •  OO modeling

Slides based on „Introduction to Entity-relationship modeling“ at http://www.inf.unibz.it/~franconi/teaching/2000/ct481/er-modelling/

2


ER modeling

Lecture 4

3


Databases

•  Data bases and data base management system – the core information systems technology

•  Example of uses: storing corporate data, web pages, on-line movies, work flow information, documents

•  Databases are one the most applied solutions to business process reengineering (BPR)


ER Modeling

•  Purpose of ER modelling: to create an accurate reflection of the real world in a database

•  The ER model doesn’t actually give us a database description; it gives an intermediate step from which it is easy to define a database


Example

•  Every department within our company is in only one division. Each division has more than one department in it. We don’t have an upper limit on the number of departments that a division can have. For example, the New Business Development---the one managed by Mackenzie---and Higher Education departments are both in the Marketing division.


Definitions

•  An entity type is a collection of entities that share a common definition.

•  An entity is a person, place, concept, or thing about which the business needs data.

•  Example: –  Department is the name of one entity type. –  One instance of this entity type is the New Business

Development department (=entity).


Definitions

•  A relationship is an association between entity types.

•  The defining characteristic of a relationship is that several entity types are involved.

•  Example: Three entity types (Employee, Department, Division) and two relationships among these entity types (manages, contains).


Graphical representation

•  ER models are usually represented graphically. •  The language we are going to use represents entity

types as rectangles and relationships as diamonds. •  Example:


Relationships

•  No direct association between division and employee. This does not mean that there is no relationship between division and employee.

•  An ER diagram should contain the minimum number of relationships necessary to reflect the situation.


Relationships

•  Example: divisions have multiple departments and departments can only be contained within one division.

•  Or, for every one division there can be many departments. In the language of ER modelling this is called a 1:M (read: “one to many”) relationship.

•  Example:


Cardinality

•  A relationship’s cardinality defines the maximum number of entities of one type that can be associated with an entity of another type.

•  1:1 One entity of type X can be associated with, at most, one entity of type Y. One entity of type Y can be associated with, at most, one entity of type X.


Cardinality

•  1:M One entity of type X can be associated with, at most, one entity of type Y. One entity of type Y can be associated with, at most, one entity of type X. –  -correct !

•  M:M One entity of type X can be associated with many entities of type Y. One entity of type Y can be associated with many entities of type X.


Existence

•  A relationship’s existence defines what we know about the existence of any entity on the other side of a relationship from a given entity.

•  Existence is given as –  optional, –  mandatory, –  or unknown.


Existence

•  Example –  optional

•  A department need not have any manager.

–  mandatory •  A department must have at least one manager.

–  unknown •  It is unknown whether or not a department has to have a manager.


Existence

•  Given any (randomly chosen) department, there must be an employee on the other side of the manage relationship. Thus, the relationship is mandatory in this direction. This is indicated by a dash on the line.

•  Given any (randomly chosen) employee, there need not be any department on the other side of the manage relationship. Thus, the relationship is optional in this direction. This is indicated by a circle on the line.


Entity subtypes

•  An entity subtype is a collection of entities of the same type to which a narrower definition and additional attributes and/or relationships apply.


Entity subtypes

•  There are many situations in which subtypes can be created but should not be. Only create subtypes –  if the subtype is involved in relationships that the other

subtypes are not or –  if the subtype needs to have additional facts stored with it.


Entity subtypes

•  Example

•  If a relationship defines the members of a proposed subtype, then use the relationship instead of the subtype.


Attributes

•  An attribute is a descriptor whose values are associated with individual entities of a specific type.

•  The attribute value for any single entity can have only one value at a given time. This value can change over time.

•  Example: –  An attribute of an employee might be salary. At any one

time if you asked for the salary level of a certain employee, then you should get one answer.


Identifier

•  A identifier uniquely identifies a single (at least one, and no more than one) entity.

•  If you know the value of the identifier, then you know exactly which entity you are dealing with.

•  The identifier’s value will never change over time.


Degree of a relationship

•  Relationships can be classified by the number of entity types involved. This is referred to as the degree of a relationship.

•  Common degrees of relationships: –  binary

•  This is a relationship between two entity types.

–  ternary •  This is a relationship between three entity types.

–  recursive •  This is a relationship involving only one entity type.


Ternary relationships

•  Example: –  Suppose you know the following:

•  works-on –  Lindsey and Mackenzie have worked on projects A and B.

•  applies –  Lindsey has used skills interface design and database design

while Mackenzie only used her database design skill. •  used on

–  Both skills have been used on both projects. –  Figure out on which projects Lindsey used which skills.


Ternary relationships

•  In order to capture the necessary information the database needs a ternary relationship.

•  The used on relationship captures information three pieces at a time. It stores facts such as: –  Lindsey used interface design skill on project A. –  Mackenzie used database design skill on project A.


Recursive relationship

•  A recursive relationship is a relationship that an entity has with itself.

•  Example: –  An employee who is the manager of other employees.

–  A manager is really just another employee


Recursive relationship

•  Reading from left, down, and back up: An employee may not manage any other employees but may manage many.

•  Reading from right, down, and back up: All employees are managed by exactly one other employee.


Attributes of a relationship

•  Relationships can also have attributes •  Example:

–  Store when a person has joined a club •  If the attribute is of the person entity, then this would indicate

when the person joined a club but we would not know which club.

•  If the attribute is of the club entity, then this would indicate (possibly) when the club was founded or (possibly) when the most recent member joined the club but we would not know the dates on which each person joined.

–  Solution: make join date an attribute of the is member relationship.


Entity subtype partitioning

•  Optional versus mandatory –  mandatory

•  He/she can demand that the person be classified as one of the subtypes.

–  optional •  He/she can allow a person to be created without classifying the

person as any subtype.

–  Neither one is preferable to the other. The proper one to choose depends on the business situation.


Entity subtype partitioning

•  Disjoint versus overlapping –  disjoint

•  If entities are allowed to be no more than one subtype, then the subtypes are said to be disjoint.

–  overlapping •  If entities can be classified as several subtypes, then the subtypes

are said to be overlapping.


Aggregation of entity types

•  Subtypes are generally thought of in terms of X is a Y (which is why these are commonly referred to as is-a relationships).

•  Another type of relationship that needs to be represented in a database is the part of relationship, more formally called aggregation.


Aggregation of entity types

•  Example


Parallel relationships

•  Two entities can have more than one type of relationship

•  Example –  the entity types person and insurance policy and the

relationships between them of pays for and is insured under.


Weak entities

•  Weak entities are entities, but with a difference – weak entities only exist because some other entity exists.

•  Example:


Types of attributes

•  Basic –  These are values provided to the business. These are the

types of attributes that we have been discussing so far. Think of name, address, etc. These values cannot be deduced from the values of other attributes.

•  Designed –  This is invented and exists only in the database. An

example might be a unique identifier for a department. This value is not changed once, it is set.

•  Derived –  This is a value that can be calculated from the value of

other attributes in the database. An example might be the age of an employee when the birth date is in the database. These attributes should, generally, not be stored in the database but should be calculated when needed.


Attribute optionality

•  Not all entities have a value for every attribute; however, some attributes must have a value for all entities.

•  optional –  An entity need not have a value associated with an

optional attribute.

•  mandatory –  An entity must have a value associated with a mandatory

attribute.


Attribute optionality

•  Example –  an employee entity type has attributes hire date and

termination date. Hire date would certainly be classified as a mandatory attribute; if the employee didn’t have a hire date, then the person couldn’t very well be an employee.

•  The optionality of an attribute depends highly on the business situation.


More about attributes

•  default –  This is the value that an attribute should take if it is not

assigned a value.

•  permitted range –  These are the values that an attribute is allowed to take.

•  composite –  A composite attribute is an attribute made up of many

other attributes.


More about attributes

•  Examples –  default

•  the state field of an employee table might have the default value of “employed”.

–  permitted range •  the sale_price field of the inventory table might have a permitted

range of sale_price > 0

–  composite •  an employee’s address that is made up of the house number, street,

city, state, and zip


Summary

•  The ER model captures domain knowledge in terms of objects (entities) and relationships among these objects.

•  An entity is a identifiable object that exists in the respective domain.

•  Entities are described in terms of a set of attributes. •  A relationship is an association among several entities. •  The set of all entities or relationships of the same type is

called the entity type or relationship type. •  Cardinalities express the number of entities to which

another entity can be associated via a relationship type.


Assignment 5

a)  What is the cardinality and existence of each of the following relationships in just the direction given? State any assumptions you have to make.

1.  Husband to wife 2.  Student to degree 3.  Child to parent 4.  Player to team 5.  Student to course

b)  For each of the following pairs of rules, identify two entity types and one relationship. State the cardinality and existence of the relationship in each case. If you don’t think enough information is available to define either of these, then state an assumption that makes it clear. Draw the ER diagram.

1.  A department employs many persons. A person is employed by, at most, one department.

2.  A manager manages, at most, one department. A department is managed by, at most, one manager.

3.  An author may write many books. A book may be written by many authors. 4.  A team consists of many players. A player plays for only one team. 5.  A lecturer teaches, at most, one course. A course is taught by exactly one lecturer. 6.  A flight-leg connects two airports. An airport is used by many flight-legs. 7.  A purchase order may be for many products. A product may appear on many purchase

orders. 8.  A customer may submit many orders. An order is for exactly one customer.

40


Assignment 5 (cont‘d)

c)  For each of the following sets of sentences, draw the corresponding ER diagram. 1.  An account can be charged against many projects, though it may

not be charged against any. A project must have at least one, though it may have many, accounts charged against it.

2.  Projects must be classified as either top secret or civilian (but not both). There is information specific to top secret projects and specific to civilian projects that we want to record.

3.  An employee must manage exactly one department. A department may or may not have one employee manage it.

4.  Men are only allowed to supervise men. Women are only allowed to supervise women. We do not want to allow the database to hold data representing a man supervising a woman. An employee, regardless of sex, is assigned to exactly one office, with each office having exactly one employee in it. (Be sure to include the office entity in this diagram.)

41


OO modeling

Lecture 4

42

The structured analysis

• The functional view defines what is to be done and the data flows between the things to be donethe data flows between the things to be done.– Is made up of data flows diagrams.

• The data view captures the static structure of the system. It describes what is in or outside the system. – Is usually made up of entity relationship diagrams.

• The dynamic view describes when things happenThe dynamic view describes when things happen and under which circumstances. – Is usually made up of state transition diagrams.

www.sti-innsbruck.at 4

The object-oriented analysis

• OOA models requirements in terms of objects and services they provideservices they provide.

• The object model (data view) describes the things in or t id th t d th i l ti hioutside the system, and their relationships.

• Interactions are mapped into this object model.

• Difference to structural analysis– Processes change more than objects themselves. Structural g j

analysis: changes in functionality result in changes in the software structure.


The object-oriented model

• The model consists of a collection of objects.• An object contains values stored in instance

variables within the object. • An object also contains methods which are code• An object also contains methods, which are code

that can be executed on the object. An object A can access the data of another object B by invoking the method of object B (message passing).

• An object has an internal part of attributes and methods that is not visible from the outsidemethods that is not visible from the outside.

• Objects have unique identity.


Differences to the ER model

• Both are made up of a collection of objects/entities.

• OO objects may contain other objects (nesting).

• OO objects contain methods• OO objects contain methods.

• Both object collections are organized into hierarchies.

• Unlike ER entities, each object has its own unique identity:– Two objects containing the same values are distinct– Two objects containing the same values are distinct. – Distinction is ensured a the physical level.


Modeling primitives

• Objects– Entity with state, attributes and services.

• ClassesClasses– Collections of similar entities organized in

specialization/generalization hierarchies.

• Attributes– Together represent the state of an object.– Types, visibility, modifiability.


Modeling primitives (cont)

• Relationships– Associations, aggregations, etc. between objects.– Specialization/generalization between classes.

• Methods (services, functions)– Operations that all objects of a class can execute when

called by other objects (message passing)called by other objects (message passing).

• Use cases– Sequences of message passing between objects

representing interactions.


General principles

• Inheritance– Subclasses inherit attributes and methods from

superclasses (multiple inheritance).– Subclasses specialize the superclass by adding new

attributes, methods or modifying existing ones.

• Information hiddingInformation hidding– Internal state of an object is hidden from the outside world.– Objects may contain other objects and hide their services

(abstraction)(abstraction).


UML

• UML stays for Unified Modeling Language – Originally developed at Rational Software – Managed currently by the Object Management Group (see

link). • UML is a modeling language (syntax).• UML is primarily aimed at building models of software. It

can but can be used for any modeling task.y g

• UML provides a number of diagram types that can be d t t k l d i t f ifiused to capture knowledge in terms of specific,

interconnected model elements.


Characteristics of UML

• Syntax.UML ifi h t d l l t d di– UML specifies what model elements and diagrams are available and the rules associated with them.

– UML does not specify what diagrams to create and how.

• Application independence.– UML can be used to model everything and can be

t d d t d t i textended to accommodate user requirements.

• Programming language independence. – UML models can be mapped into code based on a case

tool.


Characteristics of UML (cont)

• Process independence.– UML does not specify the way models should be built.

• Tool independenceTool independence.– A wide range of tools for visualizing UML models are

available. UML as a language is tool-independent.


Diagram types (UML 2.0)

• Structural modeling diagrams define the static architecture of a model. They are used to model the things that make up a model: classes, objects, interfaces and physical components. In addition, they are used to model the relationships and dependencies between elementselements. – Package diagrams divide the model into logical packages

and describe the interactions between them.– Class or structural diagrams define the structural elements– Class or structural diagrams define the structural elements

of a model: the types, classes, attributes, methods etc.– Object diagrams show how instances of structural elements

– objects - are related and used at run-time. – Composite structure diagrams.– Component diagrams.– Deployment diagrams.


http://www.sparxsystems.com/resources/uml2_tutorial/index.html

Diagram types (UML 2.0) (cont)

• Behavioral Modeling Diagrams capture the interactions and the states within a model that runs overinteractions and the states within a model that runs over time.– Use case diagrams model the interaction between users

and system. A ti it di b d t d fi th l– Activity diagrams can be used to define the general program flow, and to capture the decision points and actions within any generalized process.

– State machine diagrams capture the "run state" of a model h it twhen it executes.

– Communication diagrams.– Sequence diagrams show the sequence of messages

passed between objects using at a point in time.p j g p– Timing diagrams.– Interaction overview diagrams.


Class diagrams

• Class diagrams show the static structure of the systems.Th l di h th b ildi bl k f• The class diagram shows the building blocks of any object-orientated system. Class diagrams depict a static view of the model, or part of the model, describing what attributes and behavior it has rather than detailing theattributes and behavior it has rather than detailing the methods for achieving operations. Class diagrams are most useful in illustrating relationships between classes and interfaces. Generalizations, aggregations, andand interfaces. Generalizations, aggregations, and associations are all valuable in reflecting inheritance, composition or usage, and connections respectively.

•


Example

The symbol that precedes the attribute, or method name, indicates the visibility of the element: + means public .

means privatewww.sti-innsbruck.at 17

- means private. # means protected.~ means package-level visibility.

Classes

• Classes are collections of objects sharing the sameobjects sharing the same attributes and methods.

• Attributes capture the data properties of the l i l di tclasses including type,

default value and constraints

• Methods capture the• Methods capture the signature of the functionality -parameters, parameter t ttypes, parameter constraints, return types and the semantics.


Interfaces

• An interface specifies a t i b h i th tcertain behavior that

developers agree to meet.

• Classes realize interfaces.


Associations

• Associations describe i t ti b tinteractions between objects of different classes.

• They can have further properties, and cardinalities.


Generalizations

• A generalization indicates inheritance between classes.

*The class "Shape" is abstract shown byabstract, shown by the name being italicized.


Aggregations

• Aggregations indicate elements that are made of other components.

• A composite aggregation -shown by a black diamond –is used when components can be included in a maximum of one aggregation at a timetime.

• The deletion of the composite element implies the deletion of the parts.

• A part can be individually removed from a composition without having to delete the entire composition.


Weak vs. strong aggregations

• An address book is made up of a contacts andup of a contacts and contact groups.

• A contact group virtually groups contacts.

• A contact belongs to zero or more contact groups.

• Deleting an address book means deleting allmeans deleting all contacts and contact groups.

• Deleting a contact groupDeleting a contact group does not imply deleting contacts.


Object diagrams

• Object diagrams how objects are related and used t tiat run-time.

• They can be considered a special case of class diagramsdiagrams.

• They emphasize the relationship between objects at some point in time.


Objects

• Object elements do t d i t tt ib tnot depict attributes

and methods.

• The display of names is different: object names are underlined and may show the name ofshow the name of the class.


Class and object diagrams


Example


Summary

• OO modeling.

• UML.

• Class and object diagrams.

• Relationships to ER modeling.



Assignment 6

Go back to assignment 1 of the first lecture (business trip management).

Based on what you prepared for that assignment, please draw a UML class diagram.

43

Thank You!

Questions?


ER and OO modeling - STI Innsbruck · • An entity is a identifiable object that exists in the...

Documents

Transcript of ER and OO modeling - STI Innsbruck · • An entity is a identifiable object that exists in the...