2004.02.03 - slide 1is 257 – spring 2004 database design: object- oriented modeling university of...

63
IS 257 – Spring 2004 2004.02.03 - SLIDE 1 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management and Systems SIMS 202: Information Organization and Retrieval

Post on 22-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 1

Database Design: Object-Oriented Modeling

University of California, Berkeley

School of Information Management and Systems

SIMS 202: Information Organization and Retrieval

Page 2: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 2

Lecture Outline

• Review– ER Diagrams– Developing the Conceptual Model– Assignment 1 Discussion

• Database Design cont. Object-Oriented Modeling

• Logical Design for the Diveshop database

Page 3: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 3

Developing a Conceptual Model

• Overall view of the database that integrates all the needed information discovered during the requirements analysis.

• Elements of the Conceptual Model are represented by diagrams, Entity-Relationship or ER Diagrams, that show the meanings and relationships of those elements independent of any particular database systems or implementation details.

• Can also be represented using other modeling tools (such as UML)

Page 4: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 4

Developing a Conceptual Model

• Building the Conceptual Model for the Diveshop database

• Names for the Diveshop company?

Page 5: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 5

Developing a Conceptual Model

• We will look at a small business -- a diveshop that offers diving adventure vacations

• Assume that we have done interviews with the business and found out the following information about the forms used and types of information kept in files and used for business operations...

Page 6: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 6

Primary Business Operations

• The shop takes orders from customers for dive vacations.

• It ships information about the dive vacation to the customers.

• It rents diving equipment for the divers going on the trips (these may include additional people other than the customer)

• It bills the customer for the vacation and for equipment rental or sales.

Page 7: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 7

Business Operations (cont.)

• It arranges sub-trips to particular dive sites at the primary location.

• It provides information about the features of various sites to help customers choose their destinations.– Features include sea life found at the location

and shipwrecks

Page 8: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 8

Business Operations (cont.)

• Each dive order (or sale or trip) is on an invoice to one customer.– Invoices contain:

• Line items for each type of equipment ordered,• Total amount due for the invoice,• Customer information:

– Name, address, phone, credit card info.

• Information must be kept on inventory of dive equipment.

• There are multiple types of dive equipment:– The prices charged for sale or rental are

maintained.

Page 9: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 9

Business Operations (cont.)

• Destination information includes:– Name of the destination– information about the location (accomodations,

night life, travel cost, average temperatures for different times of the year

• Destinations have associated dive sites.• Dive Sites have associated features

– Sea life – Shipwrecks

Page 10: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 10

Business Operations (cont.)

• One record is kept for each order by a customer and will include the method of payment, total price, and location information. (I.e. Customers may have multiple orders)

• The company needs to know how an order is to be shipped.

• The shop has to keep track of what equipment is on-hand and when replacements or additional equipment is needed

Page 11: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 11

Entities

• Customer

• Dive Order

• Line item

• Shipping information

• Dive Equipment/ Stock/Inventory

• Dive Locations

• Dive Sites

• Sea Life

• Shipwrecks

Page 12: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 12

Diveshop Entities: DIVECUST

Name

Customer no

Street

State/ProvCityZIP/Postal

Code

Country

First Contact

PhoneDiveCust

Page 13: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 13

Diveshop Entities: DIVEORDS

CustomerNo

Order no

SaleDate

ShipVia

DestinationCCExpDate

CCNumber

PaymentMethodDiveOrds

No ofPeople

VacationCost

ReturnDate

DepartDate

Page 14: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 14

Diveshop Entities: DIVEITEM

Item no

Order no

Rental/Sale

Qty

Line Note

DiveItem

Page 15: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 15

Diveshop Entities: SHIPVIA

Ship Via

ShipCost

ShipVia

Page 16: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 16

Diveshop Entities: DIVESTOK

Description

Item No

EquipmentClass

ReorderPoint

On Hand Cost

SalePrice

DiveStokRentalPrice

Page 17: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 17

Diveshop Entities: DEST

Destinationname

Destination no

Avg Temp (F)

SpringTemp (F) Avg

Temp (C)Summer

Temp (C)

SummerTemp (F)

TravelCost

WinterTemp (C)

FallTemp (F)

FallTemp (C)Dest

WinterTemp (F)

Accommodations

Body ofWater

NightLife

SpringTemp (C)

Page 18: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 18

Diveshop Entities: SITES

Destinationno

Site no

Site Name

SiteNotes

SiteHighlight

DistanceFrom Town (M)

DistanceFrom Town (Km)

Skill Level

Visibility(ft)

Depth (m)

Depth (ft)Sites

Visibility (m)

Current

Page 19: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 19

Diveshop Entities: BIOSITE

SpeciesNo

SiteNo

BioSite

Page 20: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 20

Diveshop Entities: BIOLIFE

Category

Species no

CommonName

Length(cm)

SpeciesName

Length(in)

Notesexternal

GraphicexternalBioLife

Page 21: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 21

Diveshop Entities: SHIPWRCK

Site no

Ship Name

Category

InterestType Tonnage

Length (ft)

Beam(m)

Beam(ft)

Length(m)Shipwrck

Cause

Commentsexternal

DateSunk

Passengers/Crew

Graphicexternal

Survivors

Condition

Page 22: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 22

Functional areas

• Ordering

• Inventory

• Supplies

• Shipping

• Billing

• Location/Site Selection– We will concentrate on Ordering and

Location/Site Selection (these are joined tasks)

Page 23: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 23

Ordering

Orders(DIVORDS)

Customer(DIVECUST)

Customers place OrdersEach Order needs Customer information

Page 24: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 24

Ordering

DiveOrdsOrdersDiveCust

Customer No ship

ShipVia

Order No

Ship Via

DiveItem Repeatingattribute

Customer No

Page 25: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 25

Ordering Normalization

DiveCust Orders

Customer No

DiveOrds

Ship

ShipVia

Order No

Ship Via

DiveItemContains

Item No

QtyOrder No

Customer No

Rental/sale

Page 26: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 26

Details of DiveItem

DiveStokSuppliesSupplier

Company# Has

DiveItem

Item No

Item No

On Hand

Sale Price

Order No

m n

We’re ignoring this part...

Page 27: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 27

Ordering: Full ER

CustomerNo

ShipVia

DestShipVia

DiveStok

DiveItem

DiveOrds

DiveCust

CustomerNo

ShipVia

OrderNo

OrderNo

ItemNo

ItemNo

DestinationName

Destination

Destinationno 1

1

1

1

1n

n

n

n

n

Page 28: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 28

Location/Site Selection

DestGoing

to?DiveOrds

DestinationNo

DestinationName

Destination

Page 29: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 29

Destination/ Sites

Dest

Sites

DiveOrds

CustomerNo

OrderNo

DestinationName

DestinationSite No

Destinationno

Destinationno

1

1

n

n

Page 30: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 30

Sites and Sea Life 1

BioLife

Sites

Site NoDestination

no

Multiple occurrencesof sea life...

Page 31: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 31

Diveshop ER diagram: BioSite

SpeciesNo

SiteNo

BioSite

Page 32: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 32

Sites and Sea Life 2

Sites

BioSite

BioLifeSpeciesNo

Site No

Site No

Destinationno

SpeciesNo

1

1

n

n

Page 33: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 33

Sites and Shipwrecks

Sites

ShipWrck

Site NoDestination

no

Site No

1/n

1

Page 34: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 34

DiveShop ER DiagramCustomer

No

ShipVia

Dest

Sites

BioSite

ShipVia

ShipWrck

BioLife DiveStok

DiveItem

DiveOrds

DiveCust

CustomerNo

ShipVia

OrderNo

OrderNo

ItemNo

ItemNo

DestinationName

Destination

SpeciesNo

Site No

Destinationno

Site No

Destinationno

SpeciesNo

Site No

1

1

1

1

1

1

1/n

1

1n

n

n

n

n

n

n

n

1

Page 35: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 35

What must be calculated?

• Total price for equipment rental?

• Total price for equipment sale?

• Total price of an order?– Vacation price– Equipment (rental or sale)– Shipping

Page 36: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 36

What is Missing??

• Not really an “enterprise-wide” database– No personnel

• Sales people• Dive masters• Boat captains and crew• payroll

– Local arrangements• Dive Boats• Hotels

– Suppliers/Wholesalers for dive equipment• Orders for new/replacement equipment

– No history (only current or last order)

Page 37: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 37

Lecture Outline

• Review– ER Diagrams– Developing the Conceptual Model– Assignment 1 Discussion

• Database Design cont. Object-Oriented Modeling

• Logical Design for the Diveshop database

Page 38: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 38

Object-Oriented Modeling

• Becoming increasingly important as– Object-Oriented and Object-Relational DBMS

continue to proliferate– Databases become more complex and have

more complex relationships than are easily captured in ER or EER diagrams

• (Most UML examples based on McFadden, “Modern Database Management”, 5th edition)

Page 39: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 39

Object Benefits

• Encapsulate both data and behavior

• Object-oriented modeling methods can be used for both database design and process design– Real-World applications have more than just

the data in the database they also involve the processes, calculations, etc performed on that data to get real tasks done

– OOM can be used for more challenging and complex problems

Page 40: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 40

Unified Modeling Language (UML)

• Combined three competing methods

• Can be used for graphically depicting– Software designs and interaction– Database– Processes

Page 41: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 41

CLASS

• A class is a named description of a set of objects that share the same attributes, operations, relationships, and semantics. – An object is an instance of a class that encapsulates

state and behavior.• These objects can represent real-world things or conceptual

things.– An attribute is a named property of a class that

describes a range of values that instances of that class might hold.

– An operation is a named specification of a service that can be requested from any of a class's objects to affect behavior in some way or to return a value without affecting behavior

Page 42: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 42

UML Relationships

• An relationship is a connection between or among model elements.

• The UML defines four basic kinds of relationships: – Association– Dependency– Generalization– Realization

Page 43: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 43

UML Diagrams

• The UML defines nine types of diagrams: – activity diagram– class diagram

• Describes the data and some behavioral (operations) of a system

– collaboration diagram– component diagram– deployment diagram– object diagram– sequence diagram– statechart diagram– use case diagram

Page 44: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 44

Class Diagrams

• A class diagram is a diagram that shows a set of classes, interfaces, and/or collaborations and the relationships among these elements.

Page 45: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 45

UML Class Diagram

DIVEORDS

Order NoCustomer NoSale DateShipviaPaymentMethodCCNumberNo of PeopleDepart DateReturn DateDestinationVacation Cost

CalcTotalInvoice()CalcEquipment()

Class Name

List of Attributes

List of operations

Page 46: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 46

Object Diagrams

307:DIVORDS

Order No = 307Customer No = 1480Sale Date = 9/1/99Ship Via = UPSPaymentMethod = VisaCCNumber = 12345 678 90CCExpDate = 1/1/01No of People = 2Depart Date = 11/8/00Return Date = 11/15/00Destination = FijiVacation Cost = 10000

Page 47: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 47

Differences from Entities in ER

• Entities can be represented by Class diagrams

• But Classes of objects also have additional operations associated with them

Page 48: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 48

Operations

• Three basic types for database– Constructor– Query– Update

Page 49: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 49

Associations

• An association is a relationship that describes a set of links between or among objects.

• An association can have a name that describes the nature of this relationship. You can put a triangle next to this name to indicate the direction in which the name should be read.

Page 50: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 50

Associations

• An association contains an ordered list of association ends. – An association with exactly two association

ends is called a binary association– An association with more than two ends is

called an n-ary association.

Page 51: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 51

Associations: Unary relationships

PersonIs-married-to

0..1

0..1

Employeemanages

*

0..1 manager

Page 52: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 52

Associations: Binary Relationship

EmployeeParkingPlace

One-to-one

Is-assigned0..1 0..1

ProductLine

Product

One-to-many

contains1 *

Student Course

Many-to-many

Registers-for* *

Page 53: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 53

Associations: Ternary Relationships

Vendor Warehouse* *Supplies

Part

*

Page 54: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 54

Association Classes

Student CourseRegisters-for

* *

Registration________________TermGrade________________CheckEligibility()

Computer Account_________________

acctIDPassword

ServerSpace* 0..1issues

Page 55: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 55

Derived Attributes, Associations, and Roles

Student_________

namessn

dateOfBirth/age

Course Offering

____________term

sectiontime

location

Registers-for

* 1

Course ____________

crseCodecrseTitlecreditHrs

* *

Scheduled-for

{age = currentDate – dateOfBirth}

* *

/Takes

/participant

Derivedattribute

Derived role

Derived association

Page 56: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 56

GeneralizationEmployee

____________empName

empNumberaddress

dateHired____________

printLabel()

Hourly Employee_______________

HourlyRate_______________computeWages()

Salaried Employee_______________

Annual Salstockoption

_______________Contributepension()

Consultant_______________contractNumber

billingRate_______________

computeFees()

Page 57: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 57

Other Diagramming methods

• SOM (Semantic Object Model)

• Object Definition Language (ODL)– Not really diagramming

• Access relationships display

• Hybrids

Page 58: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 58

Application of SOM to Diveshop

DIVECUST

Address Street City StateProvince ZIPPostalCode CountryPhoneFirstContact

Name

DIVEORDS

1.1

1.1

1.1

1.1

1.1

1.1

1.1

1.1

1.N

1.1

Page 59: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 59

DIVEORDS

DIVEORDSid OrderNoSaleDate

SHIPVIA

DESTINATION

DIVEITEMPaymentMethodCCNumberCCExpDateNoOfPeopleDepartDateReturnDateVacationCost

DIVECUST

Page 60: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 60

DiveShop ER DiagramCustomer

No

ShipVia

Dest

Sites

BioSite

ShipVia

ShipWrck

BioLife DiveStok

DiveItem

DiveOrds

DiveCust

CustomerNo

ShipVia

OrderNo

OrderNo

ItemNo

ItemNo

DestinationName

Destination

SpeciesNo

Site No

Destinationno

Site No

Destinationno

SpeciesNo

Site No

1

1

1

1

1

1

1/n

1

1n

n

n

n

n

n

n

n

1

Page 61: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 61

Entities

• Customer• Dive Order• Line item• Shipping information• Dive Equipment

Stock/Inventory• Dive Locations

• Dive Sites• Sea Life• Shipwrecks

Page 62: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 62

Assignment 2: Due Oct. 1

• The following information should be turned in for the preliminary design of your personal database project.

1. A general description of the data you will be using for the database, and what uses you might expect the database to have.

2. A preliminary data dictionary for the entities and attributes and format of the data elements of the database. You should have at least 5 entities with some logical connections between them. The data dictionary consists of all of the attributes that you have identified for each entity, along with indication of whether the attribute is a primary key (or part of a primary key), and what format the data will be (e.g.: text, decimal number, integer, etc.)

3. Produce an entity-relationship diagram of the database OR a UML diagram.

• These will be preliminary design specifications, so do not feel that you must follow everything that you describe here in the final database design.

Page 63: 2004.02.03 - SLIDE 1IS 257 – Spring 2004 Database Design: Object- Oriented Modeling University of California, Berkeley School of Information Management

IS 257 – Spring 2004 2004.02.03 - SLIDE 63

Next Time

• Moving from a Conceptual Model to a Logical Model for a RDBMS

• Normal Forms

• Normalization