1 / 26

EER vs. UML Terminology

EER vs. UML Terminology. EER Diagram Entity Type Entity Attribute Domain Composite Attribute ~ [Derived Attribute] Relationship Type Relationship Instance Cardinality & Participation. UML Class Diagram Class Object Attribute Domain Structured Domain Operation Association Link

frances
Download Presentation

EER vs. UML Terminology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EER vs. UML Terminology EER Diagram Entity Type Entity Attribute Domain Composite Attribute ~ [Derived Attribute] Relationship Type Relationship Instance Cardinality & Participation • UML Class Diagram • Class • Object • Attribute • Domain • Structured Domain • Operation • Association • Link • Multiplicities

  2. D# DNAME Is In E# NAME FNAME LNAME P# %TIME PNAME EER Example Participation Department 1 N Cardinality Employee N Assigned To M Project

  3. E# Employee E# NAME: NameDom FNAME LNAME … FNAME NAME Employee LNAME DiagramsEER vs. UML Class Attributes Methods Structured Domain Entity Type vs. Class Attribute Composite Attribute vs. Structured Domain

  4. D# DNAME E# Employee E# NAME: NameDom FNAME LNAME … NAME FNAME Department D# DNAME … Employee LNAME P# Project P# PNAME … AssignedTo %TIME %TIME PNAME EER vs. UMLComplete Diagram 1..1 Min participation (0 or some int n: n>0) 0..* Department 1 Is In N Max Cardinality N 0..* Assigned To M 0..* Project

  5. Department D# DNAME AvgSal Member Of AvgSal Salary EER Derived Attributes - Include in Department the average salary of the employees in the department. Employee Department Class Method

  6. Student … … Major Major_Program Major … Has Major EERMulti-valuedAttributes EER Multi-valued as Entity N 3 Student Student Major_Program Major UML 0..* 0..3

  7. 1 N Employee Name Name SSN Employee SSN Name … UML Qualified Association Dependent Name Dependent Dependent … … Dependents Of Weak Entities EER Weak Entity

  8. Department Name No … … Aggregations Location Location Department Project No No Name No Name Project Name No … 0..* 1..1 1..* 0..* Location Name

  9. total disjoint overlap partial U superclass subclass d o o d Name Class SSN Salary Major Dept Degree Program EmpID Example: University Database • Superclasses & Subclasses • Generalization & Specialization • Inheritance Employee U Person U Grad Student U Student U Superclass instance must always exist. Undergrad Student

  10. Person SSN Name … Employee EmpID Salary … GradStudent DegreeProgram … Student MajorDept … UndergradStudent Class … o d UML Superclass/SubclassInheritance EER UML disjoint overlapping

  11. Object-Oriented Databases (OODB) Add persistence to object-oriented programming languages Object Relational Databases (ORDBMS) Add user-defined methods to relational databases Allow grouping of relations into more complex “objects” Object-Oriented Approach Motivation

  12. Relational is Good For • Fixed format data • Transaction processing: simple short transactions • Concurrency control • Recovery from crashes • Query processing and Query optimization • relational algebra and mathematical logic operations.

  13. Problems • The relational model has no notion of a single object. • Context with the real world e.g., spatial context. • Aggregation functions may be desired • The notion of re-use cannot be exploited • There may also be versions or variant configurations i.e variations of the same design.

  14. Problems With the Relational Model - 1 • Nonhomogeneous collection of design objects. • Data Types: images, matrices, vectors; variable length. • Temporal and/or spatial data. • Many data types; few instances of each type.

  15. Problems With the Relational Model - 2 • Schemas evolve during design. • Long running transactions: "checkout a design". • Versions; design log.

  16. Problems With the Relational Model - 3 • Functions needed: • Making a design permanent, • Releasing design to production, • Archiving design, • etc. • Library of design objects: • minimize redundancy.

  17. Object-Oriented Concepts - 1 • Complex Objects: • sets, • bags, • lists, • arrays, • tuples.

  18. Object-Oriented Concepts - 2 • Object Identity: identify by object id (oid) rather than by an attribute value, never changes. • Encapsulation: Operations and Data available to user. • Implementation hidden. No other operations available.

  19. Object-Oriented Concepts - 3 • Types and/or Classes: • Type: • Interface and Implementation. • Types declared, checked at compile-time • Class: • Instances created at run-time

  20. Object-Oriented Concepts - 4 • Class or Type Hierarchies: • Inheritance: both data and function example: student: undergraduate, graduate • Overriding, overloading, and late binding: • Polymorphism

  21. Object-Oriented Concepts - 5 • Computational Completeness: • Extensibility: • Means to define new types. • User types not distinguished from system types. • Persistence: • Not present in OO programming languages. • Should be implicit not explicit.

  22. Object-Oriented Concepts - 6 • Secondary Storage Management: • Concurrency: • Recovery: • Ad Hoc Query Facility:

  23. Review: Object • State (value) • Behavior (operations) • Signature or interface: operation name and arguments • Method or body: implementation • Identified by unique Object Identifier (OID)

  24. Class • Group of similar objects • Class hierarchies • Inheritance • Persistence must be specified explicitly • Via entry point • Via reachability

  25. Type Hierarchies and Inheritance(EER – superclass/subclass relationship) PERSON: Name, Address, Birthdate, Age, SSN EMPLOYEE: subtype-of PERSON: Salary, HireDate, Seniority STUDENT: subtype-of PERSON: Major, GPA EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA

  26. Object Data Management Group (ODMG) • Object Model • Object Definition Language (ODL) • Object Query Language (OQL) • Bindings to object-oriented programming languages • C++, Java, Smalltalk

More Related