Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Recursive RelationSlide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21OSApp. 1App. 2App. 3OSApp. 1App. 2App. 3DBMSOSApp. 1App. 2App. 3O-ODBMSData DesignFiles &DatabasesTraditional File Systems•Advantages:–Simple Data Design - to support single or small group applications–Fast Data Access–Inexpensive•Disadvantages:–Lack of data relation–Redundancy–Lack of standards–Low application development productivityDBMS:•Integration, sharing of data•Increased data accessibility•Minimum redundancy•Easier application development and maintenance•Improved Data security•Logical / Physical data independenceDisadvantages:•Complex data design•Slow access•ExpensiveData Modelling:Modelling Object (Entity) classes, Attributes and relationshipsData Modelling/ Object Structure analysis and designLogical Data DesignPhysical Database designEntity, Attributes, Instances:CustomerCust NameCityZipPhone #Cust # Unique Identifier: Cust# ( Primary Key)Relationships between Object Classes/ Entities:How are instance relates to another(Business rules and Policies)Customer Sales Transactions Customer Sales Transactionsinitiates0 to manyIs initiated by1 and only 1Customer Sales TransactionCardinalityMinMaxMin = 1 Existence DependencyE/ R Model:Customer Sales TransactionMinMaxAAAAAABBBBBB1,35Each Instance of class A is associated with one and only one instance of class BRecursive RelationCourseCourse ID• Subject•CourseCourse TitleCourse CreditIs a prerequisite forHas as a pre-requisiteGeneralization/ SpecializationPersonTeacher Students•Inheritance•No Cardinality ( 1 to 1)PersonTeacher StudentsMutually ExclusiveMajorGPADeptSalarySS#NameAddressComposition Relationship (HAS - A)An object instance is composed of one or more instances of another object classSales TransactionST LineCOURSECourseIDCourse TitleCredit•Subject•Course #INSTRUCTORInstrID•Last Name•First NameSCHEDULEDCLASSSchedClassIDDay of WeekStart TimeEnd Time•CourseID•InstrID•RoomIDROOMRoomIDCapacity•Bldg•Room#N-ary Relationships- Use an AssociationSome Guidelines•Identifying Classes–each class has data it must remember–each class has at least one attribute–class has several attributes–all instances have same attribute ( & methods)•Assigning Attributes to Object classes–each attribute appears only once–assign attribute to object class that it most logically describes•Identifiers (Pks) for each class–sub-class assumes identifier of super-classCompleted Object Relationship ModelObject Relationship Model with Attributes and IdentifiersCASESalesTransactionOrder #Order DateXact. TypeSub TotalSales TaxTotalCashSaleAmt RcvdPmt TypeCredit OrderAmt ChargedApp. CodeOrder PickUpPickup #flightFlightFlt #Dep TimeDep CityArr. TimeArr CityCapacityReservationTicket #Dep DateTicket ClassTicket Condition.FareCustomerCust NameCust AddressCust NumberQ2:DeductionDed-TypeDed AmtDepartmentDept. NameTime CardPay Period EndingTC-LineDateTime-InTime-OutTS-LineHrs-WorkedGross PayTime SheetPay Period EndingEmployeeSSNEmp NameTax StatusExemptsHourly RateYTO-GrossLast UpdateTime Card will have TC-Lines for employees on vacationEach TS-Line is related to only one