1. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Database Design Methodology Lecture 1, Term 2, 2004

2. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Outline sfront end applications and back end databases smethodology for database design – overview srequirements specification sER/EER modelling elements of EER modelling stransformation of an ER/EER model into a relational model smotivation for normalisation

3. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Front-End Applications and Back-End Databases database DBMS application 1 application 2 application 3 application 4 application k application k+1 application n

4. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Back-End Databases sone database per information system scentral to the information system sstores data in a consistent way smechanisms for data retrieval and update snot responsible for complex calculations nowadays DBMSs provide means for server based computations trade-off between calculations performed on server and calculations performed in the front end snot responsible for data formatting

5. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Front-End Applications sresponsible for complex calculations sresponsible for data formatting

6. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College … when designing a database smust decide what is to be represented in the database what is to be represented in the front-end because many aspects may be represent-able at both ends give an example in class

7. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Database Design Methodology - Overview swhat is a methodology? stop down methodology requirements specification ER/EER modelling (conceptual design) refinements of higher level ER/EER models validation of ER/EER model construction of relational model (logical design) validation of relational model normalisation physical design monitoring and tuning

8. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Requirements Specification srequirements data transaction even by specifying the user interfaces sspecification informal English combined with diagrammatic representations selicitation for each view do you know the term database view?

9. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Fact Finding Techniques stechniques interviewing questionnaires examining documentation observing the enterprise in operation research syou may need to uncover things for the user tell them what may be possible requirements identification is a two way process you will need to understand the operation of the enterprise at least to some considerable extent

10. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Requirements Specification sexercise in class …

11. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Requirements Specification sbe as comprehensive as possible sdefine the scope clearly describe as clearly as possible what is to be part of the database specify clearly what is not to be included in the database (at this point it may be possible to decide, for certain aspects, whether they are to be part of the back-end or the front-end) sinfer requirements for future growth, if applicable sif this step is not carried out correctly, the final database system is bound to fail

12. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College ER/EER modelling sidentify entities identify attributes the set of attributes defines an entity identify candidate keys identify domains for attributes sidentify relationships identify multiplicity identify attributes (if applicable) identify domains for attributes s(possible) combine view models into unitary model svalidate model discuss the order in which these steps are to be performed

13. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College ER/EER modelling sdifferent people may produce different models they may all be correct could they express the same requirements? some may be better than others, though how do we measure good? it is a matter of experience … however, if the methodology is correctly followed, the design cannot be too bad …

14. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Identify Entities svery informal definition an entity (type) is something about which we want to store information in the database, and which has more than one instance sin text (requirements) entities are nouns spossible problems: you may identify different entities that represent the same thing (information object) you may attempt to represent two information objects with the same entity

15. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Identify Entities sgive example if needed

16. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Identify Relationships svery informal definition a relationship (type) is a link between entities that need to be recorded in the database sidentify multiplicity consider future growth spotential problems unlinked entities un-represented relationships may be due to fan and chasm traps

17. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Identify Attributes ssingle/composite ssingle/multi-valued sderived sidentify candidate keys sdefine domains spotential problems entities with no attributes entities with the exactly the same set of attributes impossibility of associating an attribute with any of the existing entities

18. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College EER Modelling Concepts sgeneralisation (sub-class / super-class) is-a relationship saggregation part-of relationship scomposition special type of aggregation the existence of the parts (instances) is not motivated (in the database) if the whole (instance) disappears (from the database) a part (instance) can only be part-of one single whole (instance) at any one time I am not so sure about this! snotation and examples on white board

19. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College EER Modelling Concepts sgeneralisation/specialisation participation: mandatory or optional disjoint constraint: disjoint or non-disjoint saggregations can be represented as a has relationship some people name aggregation relationships in this case, the distinction between an aggregation and a simple relationship is blurred scomposition vs aggregation the distinction may not be clear example of an aggregation: disk ( format, location, …) and recording ( actor, length, topic …)

20. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Validation of EER Model scheck for redundancy scheck for completion validate against requirements review model with user

21. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College ER/EER Model into Relational Model sproblems in class multi-valued, composite and derived attribute many-to-many relationship relationship with attributes recursive relationship ternary relationship difference between 1––* and 0––* difference between 1––(0..*) and 1––(1..*) generalisation mandatory vs optional OR vs AND

22. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Relational Model show do we know that the resulting relational model is good/correct? there is a formal way of checking whether a relation is in a good form or not this is through normal forms we shall study normal forms in the following two weeks

23. Term 2, 2004, Lecture 1, Database Design MethodologyMarian Ursu, Department of Computing, Goldsmiths College Summary sRequirements Specification – essential data and transactions be as thorough as possible sER/EER modelling it is possible to devise two or more correct models based on the same requirements specification experience leads to better design (obviously!) sEER concepts stranslation of ER/EER structures into specifications within the relational model