1. Switch off your Mobiles Phones or Change Profile to Silent Mode

2. Physical Database Design

3. Objective is to select physical representations for each relation such that the database has following properties: data may be accessed with acceptable speed database does not use up too much of computer’s store database is reasonably resilient to catastrophes.

4. Physical Database Design Physical design decisions should be based on following: logical database design. quantities and volatility of data. ways in which the data is used. costs associated with storing and accessing data.

5. Physical Database Design Physical database design typically proceeds as follows: an initial design is generated based on anticipated processing. initial design is tested and data manipulations are ‘bench-marked’. modifications can be made is necessary, bottlenecks are identified and rectified. monitoring and continued, appropriate modifications.

6. Representation of Relations Relations are usually represented as computer files in which a record represents a tuple/row.

7. File Handling Files are handled by the operating system, and so RDBMSs usually sit on top of the operating system’s file manager.

8. File Structure Techniques Heap files and Serial search Constructed as a list of pages - when a new record is inserted it is placed in the last page of the file. Advantages fast record insertion economic use of store Disadvantages serial search is slow reclamation of space not possible

9. File Structure Techniques Access Keys When accessing data, a search condition is usually applied to restrict the rows retrieved: SELECT * FROM PART WHERE part_no = ‘P1’ AND price > 22; Part_no is tighter key than price, which is a looser key

10. File Structure Techniques Sorted Files Speed of some retrievals may be improved by ensuring that file records are stored in some specific order. Advantages easy to define access key facilitates the binary search Disadvantages maintenance of the sequence

11. File Structure Techniques Sorted Files - using Binary Search Binary search is technique of repeatedly halving a file and searching the half in which searched record is stored. SELECT * FROM PART WHERE part_no = ‘P9’

12. File Structure Techniques Hash (random) files Hashing is process of calculating location of a record from an access key value. Home address is computed address (page address) Hash key another name for the access key used Hashing function calculation used to compute home address

13. File Structure Techniques Hash (random) files

14. File Structure Techniques Hash (random) files – an example:

15. File Structure Techniques Hash (random) files Advantages potentially very fast Disadvantages collision at home address

16. Normalisation Normalisation is a technique for deciding which attributes belong together in a relation. Result of normalisation is a logical database design that is structurally consistent and has minimal redundancy. Sometimes argued that a normalised database design does not provide maximum processing efficiency.

17. Normalisation There may be circumstances where it may be necessary to accept the loss of some of the benefits of a fully normalised design in favor of performance. Should be considered only when it is estimated that the system will not be able to meet its performance requirements. Normalisation forces us to understand completely each attribute that has to be represented in the database.

18. Denormalisation Denormalisation aids the process of systematically adding redundancy to the database to improve performance after other possibilities. The objectives of Denormalisation is to reduce the number of physical databases tables to be accessed, by reducing the number of joins needed to derive the answer to a query.

19. Denormalisation Denormalisation can improve certain types of data access dramatically, but there is no success guaranteed and there is always a cost. The data model becomes less robust, and it will always slow DML down. It complicates processing and introduces the possibility of data integrity problems.

20. Denormalisation There are four techniques in denormalising duplicate data derived data surrogate keys vector data

21. Denormalisation Duplicate data Individual fields introduced redundantly to reduce number of records accessed.

22. Denormalisation Duplicate data Individual fields introduced redundantly to reduce number of records accessed. name

23. Denormalisation Duplicate data Individual fields introduced redundantly to reduce number of records accessed.

24. Denormalisation Duplicate data Individual fields introduced redundantly to reduce number of records accessed. title_desc

25. Denormalisation Derived data: Summary or calculated fields introduced redundantly to reduce number of records involved in arithmetic.

26. Denormalisation Derived data: Summary or calculated fields introduced redundantly to reduce number of records involved in arithmetic. total_price no_of_items total_qty

27. Denormalisation Surrogate keys: Artificial keys introduced in place of inefficient key fields.

28. Denormalisation Vector data: Concept of multiple repeating fields reintroduced to group data in one record.

29. Denormalisation Relational theory will resolve a situation of storing 12 monthly account balances like this BANK_ACC (account_no, name, address) ACC_BAL (account_no, month_no, balance) Vector data solution is BANK_ACC (account_no, name, address, balance1, balance2,… ……, balance11, balance12)

30. Denormalisation Problem If you Denormalise for performance, you do want to be sure that Denormalisation is truly beneficial and that there is no better alternative. Denormalised tables will almost always be created by combining two or more Normalised tables. rows will be longer each access will require more data transmission

31. Denormalisation Problem Denormalisation makes implementation more complex Denormalisation often sacrifices flexibility Denormalisation may speed up retrievals but it slows down updates. Data which is frequently updated should not be replicated without good reason.

32. When to Denormalise If performance is unsatisfactory and a relation has a low update rate and a very high query rate, denormalisation may be a viable option.

33. Any Questions?