1. About physical design After you have provided your scripts Understand the problems Present a template that can be used to report on the physical design of a DB Context: Analysis of the full process of db development

2. Earlier stages Organisational Activity Existing Database ER diagrams Normalised Model Logical Schema

3. Additional constraints / requirements Logical Schema Volume Usage Transaction Access Integration Distribution Security Queries Users Analyses Physical Schema Create tablespace Create table… Create Cluster… Create Index… Create Views…

4. Volume Analysis Estimates of average and max values for object sizes Number of instances per entity Realistic storage requirements –Day one –Growth over time Headings: row max, row avg., record size, table max, table avg [characters]

5. Usage analysis (internal constraints) Identify major transactions to hit each table and their frequency Insertions / updates / retrievals / deletes or mixtures of all 4 Eg: register a new student day one or year 1 into year 2… Compute Volatile vs non-volatile tables –Turnover / population (eg over month or year) –Bipolar distribution (1 or 100)

6. Transactional analysis (other constraints) Documenting critical transactions to hit DB Impact on systems resources Objects accessed and type of access Any constraints placed on processing –Eg: time Top 20% most important transactions –Transactional map

7. Example – students per course Query Steptype of AccessNo of ref./ transacPer period 1Read110 2Read40400 3Read1(40)10 (400) Course Student Registration 1 23

8. Access Requirements Type of access + type of usage = headache Eg: indexes both increase and decrease performance Conflict between reporting / retrieval and transaction processing (OLTPs) Time sharing or avoidance (forbidden queries)

9. Integrity Analysis Traditional DB territory –Entity constraints (primary key – no duplicates) –Referential integrity (foreign key ref is not null and valid) –Domain constraints (credit limit numeric + accepted value [1000, 5000, 15000]) Enforcing those = big hit on performance (cascading updates)

10. Security analysis Outside frame of DB = physical access to building, logon procedures etc… Difficult to contemplate DB security on its own –Eg: operating systems level Large scale DBMSs provide specific utilities –Preventing unauthorised access to data –Preventing usage of DBMS functions Use usage analysis to derive user profiles with associated access rights

11. Conclusions All these will establish the performance of the DB Denormalisation Indexing strategy Clustering of key relationships Creating views

12. Virtual table with no data in it = structure only Provide easier access to user / group of users: –Simplification (eg: filter) –Function / calculation of aggregated data (eg: age from DOB) –Security restriction (limit to updatable records)

13. Updating through views Can lead to problems if record is not complete in view (vertical simplification) –Especially if primary key not shown Some views are de facto un updatable Other are because they use a distinct select, a group by or order by, or they look at more than one table, or they are based on a union Create view FRED as Select * from students where course = ‘BIS’; Create view FRED as Select name, address, gender from students where course = ‘BIS’;

14. Authority!! Oracle users have ID and password Own objects that they create Have access to other objects if have privileges: –E.g. create table privilege –Select privilege –Delete privilege –Grant privilege

15. Create a user Two users by default: –System: all privilege –SYS used by ORACLE Create user FRED identified by Mypassword Single login can be arranged with external command (e.g. with NT login) Possible to set any limits – e.g. resources, tablespaces, quotas

16. Password management Accounts get locked after failed attempts password history so PW cannot be re-used Characteristics of users’ accounts are set in profiles (create profile command) Profiles include: –Lifetime of PW –Number of allowed failures –Number of days locked –Frequency of changes –Minimum length PW can be change with SQL password command

17. Standard Roles Before users are active need to assign roles CONNECT: access to DB + any other granted rights RESOURCE: creation of objects DBA: unlimited space quotas + grant privileges to other users Grant privilege / role to user [with admin option] Revoke privilege / role from user Drop…

18. Other Grant command CONNECT and RESOURCES don’t give automatic access to other people’s resources Need to grant access Grant OBJECT PRIVILEGE on OBJECT to USER [with grant option] Object privilege = select, insert, update, delete Can be granted on certain column and not on others

19. Security layers Old debate RE best level to implement security Especially in internet age – IOS links with customers and suppliers Databases contain data of increasing value Are increasingly open to the outside Possible layers of security: –By user –By table – using policies –At row level

20. 3 aspects of security Secrecy: info not disclosed to unauthorised users Integrity: modifications of data must be legitimate Availability: authorised users should not be refused access (e.g. by mistake)

21. External security Bear in mind that DBMS security is not only issue Operating system security Network security Logical access (through an application) As well as physical access (directly into files)

22. Security at user level Use views to differentiate access Table with info on all workers Create view YOURAGE as Select * from workers Where name = User; When worker called George queries the table query return his record only Be careful with Ref. Int. constraints

23. Other security layers - Policies Security policies apply to table level - each table can have a separate one They execute everytime a table is accessed by adding a bit of SQL to the where clause No need to write a policy for each table But can have more than one per table- e.g. select, insert, update, delete! Add policy command

24. Row level security Fine-grained access control Add extra column to table Populate column with name of current user Others won’t get to see the column until it is committed Simplest form of locking

25. Cost of security measures Significant performance impact Complexity due to multiple levels Possible errors from conflicting policies Combination of measures may also have unpredictable effects on users queries May conflict with constraints set across tables (e.g. ref. int.)