Database DesignProjects, More DetailsBuilding an Application with a DBMSOutlineSlide 5Database Design Formalisms1. Object Definition LanguageODL PrinciplesODL Class DeclarationsODL ExampleODL DeclarationsODL Example ExtendedODL Declarations, ExtendedODL Example, Extended AgainODL Declarations, Extended AgainTypes in ODLCollection TypesAllowable Types in ODL2. Entity / Relationship DiagramsWhat is a Relation ?Multiplicity of E/R RelationsMulti-way RelationshipsArrows in Multiway RelationshipsSlide 25Slide 26Roles in RelationshipsAttributes on RelationshipsConverting Multi-way Relationships to Binary3. Design PrinciplesDesign Principles: What’s Wrong?Slide 32Database DesignApril 3, 2002Projects, More Details•Goal: build a DB application.•(almost) anything goes.•Groups of 3-4.•End of week 2: groups formed.•End of week 3: proposals, E/R diagrams•End of week 5: project specs due•End of week 7: sample end-to-end app due•June 7th: demosBuilding an Application with a DBMS•Requirements modeling (conceptual, pictures)–Decide what entities should be part of the application and how they should be linked.•Schema design and implementation–Decide on a set of tables, attributes.–Define the tables in the database system.–Populate database (insert tuples).•Write application programs using the DBMS–way easier now that the data management is taken care of.Outline•ODL - Object Definition Language (2.1)•E/R - Entity relationship diagrams (2.2)•Design Principles (2.3)Database Design•Why do we need it?– Agree on structure of the database before deciding on a particular implementation.•Consider issues such as:–What entities to model–How entities are related–What constraints exist in the domain–How to achieve good designsDatabase Design Formalisms1. Object Definition Language (ODL):– Closer in spirit to object-oriented models2. Entity/Relationship model (E/R):–More relational in nature.•Both can be translated (semi-automatically) to relational schemas •ODL to OO-schema: direct transformation (C++ or Smalltalk based system).1. Object Definition Language•ODL is part of ODMG•superset of Corba’s IDL •Resembles C++ (and Smalltalk).ODL Principles•Basic design paradigm in ODL: –Model objects and their pro p erties.•For abstraction purposes:–Group objects into cl a sses.•What qualifies as a good class?–Objects should have common properties.ODL Class DeclarationsClass declaration:Methods: arbitrary function, of little concern for us hereInterface <name> { attributes: <type> <name>; relationships <range type> <name>; methods <type> <name>(param)}Interface <name> { attributes: <type> <name>; relationships <range type> <name>; methods <type> <name>(param)}ODL ExampleProductPersonCompanycategorynamepricenamestockpricenameaddress ssnODL DeclarationsInterface Product { attribute string name; attribute float price; attribute enum Categories {electronics, communications, sports …} category }Interface Company { attribute string name; attribute float stockprice; }Interface Person { attribute integer ssn; attribute string name; attribute struct Address {string street, string city} address; }Interface Product { attribute string name; attribute float price; attribute enum Categories {electronics, communications, sports …} category }Interface Company { attribute string name; attribute float stockprice; }Interface Person { attribute integer ssn; attribute string name; attribute struct Address {string street, string city} address; }So far just simplified C++ with slightly different syntaxODL Example ExtendedProductPersonCompanycategorynamepricenamestockpricenameaddress ssnbuysworksFormadeByODL Declarations, ExtendedInterface Product { attribute string name; attribute float price; attribute enum Categories {electronics, communications, sports …} category; relationship <Company> madeBy; }Interface Person { attribute integer ssn; attribute string name; attribute Struct Address {string street, string city} address; relationship set <Product> buys; relationship set <Company> worksFor;}Interface Product { attribute string name; attribute float price; attribute enum Categories {electronics, communications, sports …} category; relationship <Company> madeBy; }Interface Person { attribute integer ssn; attribute string name; attribute Struct Address {string street, string city} address; relationship set <Product> buys; relationship set <Company> worksFor;}relationship corresponds somewhat to pointers in C++ODL Example, Extended AgainProductPersonCompanycategorynamepricenamestockpricenameaddress ssnbuysworksFormadeByemploysmakesODL Declarations, Extended AgainInterface Company { attribute string name; attribute float stockprice; relationship set <Product> makes inverse Product::madeBy; relationship set <Person> employs inverse Person::worksFor; }Interface Company { attribute string name; attribute float stockprice; relationship set <Product> makes inverse Product::madeBy; relationship set <Person> employs inverse Person::worksFor; }Types in ODLBasic types: Atomic types (e.g., string, integer, …) Interface types (e.g., Person, Product, Company)Constructors:collection types: Set: {1, 5, 6} Bag: {1, 1, 5, 6, 6 } List: [1, 5, 6, 1, 6 ] Array: integer[17]structured types: Struct {string street, string city, integer zipcode}Collection Types•Sets:–order, number of occurrences don’t matter–{4,7,9} = {7,9,7,4} = {9,4,7}•Bags:–number of occurrences matter, order not:–{7,9,7,4}={7,7,9,4}, is different from {4,7,9}•Lists:–order, number of occurrences matter:–[4,7,9] different from [9,4,7]Allowable Types in ODLFor attributes: atomic/struct, or collection of atomic/struct OK: string, set<integer> Not OK: Product, set<set<integer>>For relationships: interface, or collection of interface. OK: Product, set<Product>, list<Person> Not OK: struct {pname Product, cname Company} set<bag<Product>> integer2. Entity / Relationship DiagramsObjects
View Full Document
Unlocking...