modelling for business analysts for modelling Gordon Keith Entity relationship and classEntity relationship INFORMATION BUSINESS MODELLING
Keith Gordon MODELLING BUSINESS INFORMATION 173535 781780 ISBN 978-1-78017-353-5 Computing; IT 9 Cover photo: iStock © nuwatphoto photo: iStock © nuwatphotoCover Matthew West, Information West, Matthew Director Junction, David Hay, Essential Strategies Essential Strategies Hay, David CEO International, toA terrific contribution the field. Senior Consultant, Alec Sharp, Clariteq an excellent Provides in the fullgrounding to of topics related range information modelling. A thoughtful, well- A thoughtful, to do on how done text high-quality business data modelling. analytical
e e s aperback Ebook availabl P availabl Keith Gordon Keith MODELLING BUSINESS INFORMATION BUSINESS MODELLING Explains why business analysts should model information should model business analysts Explains why in and class modelling relationship both entity Covers the basics tandem from syllabus with the BCS Data Analysis Aligned wider topics to include several the syllabus Goes beyond of interest
Entity relationship and class modelling for business analysts business for modelling and class relationship Entity It is almost universally accepted that requirements documents requirements accepted that universally It is almost should business analysts by systems new or enhanced IT for that has to the information to represent include a ‘data model’ the system. be handled by help business this book will principles, first Starting from to construct data models required the skills to develop analysts and of entity relationship explanations comprehensive through syllabus. BCS Data Analysis in line with the class modelling, also the book the topics in the syllabus, In addition to covering an including of interest information extra includes significant model information notations, of other modelling overview quality, and taking a requirement model into database design. model a requirement and taking quality, • • • • THE AUTHOR ABOUT is an independent consultant and lecturer Gordon Keith analysis. specialising in data management and business and training education in technical, 50 years He has spent over data computer consultant, as an engineer, environments manager. and training and education business analyst manager, You might also be interested in: might also be interested You
As the roles of Data and Business Analysts become more intertwined, this book is timely in its publication. Businesses often fail to recognise information is a key resource and are confused by how it is presented or overwhelmed its complexity during use. Keith brings to the forefront of the readers mind the importance of communicating and analysing the relationship between Business, Information, Systems and Data, and the value in developing models cooperatively, gaining ‘consensus, not perfection’ from stakeholders. Simple everyday examples and analogies to support the readers under- standing and make the subject more relatable are used. I enjoyed reading the book and completing the exercises. An excellent learning aid for Analysts who are new to modelling or need reminding of good practice. Katie Walsh, Business Analyst and Mentor
Anyone interested in a thoughtful, well-done text on how to do high-quality business analytical data modelling should definitely proceed with this book. David Hay, Essential Strategies International, CEO
Modelling Business Information provides an introduction to data modelling, to the nomen- clature used by common modelling techniques, and to techniques for representing common patterns. This is a useful book for business analysts who are creating the information model as well as for business and IT users who need to understand a data model. Keith W. Hare, JCC Consulting, Inc., Senior Consultant
Keith Gordon’s wonderfully compact yet thorough introduction to business-friendly information modelling is a terrific contribution to the field. Globally, there’s a surge of interest in data modelling as a powerful tool for improving communication, especially with professionals who used to think business-oriented entity relationship modelling didn’t need to be in their tool kits. Business analysts, Agile developers, data scientists, big data specialists, and other professionals will all benefit from Keith’s work. Alec Sharp, Senior Consultant, Clariteq
Modelling Business Information by Keith Gordon, is aimed at those who are new to busi- ness analysis or information modelling. Keith draws on a wealth of experience in infor- mation management, both as a practitioner, and as a lecturer with the Open University in his writing.
The first six chapters provide an accessible and clear foundation in the topic cov- ering the reasons for developing information models, the basic elements of entity- relationship diagrams, how to develop an information model from basic information requirements, and finally how to normalise existing data. I particularly like that it uses two graphical notations, the Barker-Ellis notation, noted for its readability, and the ubiquitous Unified Modelling Language notation, which helps to demonstrate that there are different notations that entity-relationship models can be developed in. This first part of the book also takes care to cover the syllabus for the Data Analysis certificate that is part of the scheme for the BCS Advanced International Diploma in Business Analysis.
The second part of the book covers a range of more advanced topics from naming con- ventions and yet more entity-relationship model notations, to considerations of quality in information models, corporate data models, modelling for business intelligence applica- tions, and finally goes on to look at data and database topics including an overview of SQL, and moving to database design and optimisation.
Overall, the book provides an excellent grounding in the full range of topics related to information modelling. Matthew West, Director, Information Junction MODELLING BUSINESS INFORMATION BCS, THE CHARTERED INSTITUTE FOR IT
BCS, The Chartered Institute for IT, champions the global IT profession and the interests of individuals engaged in that profession for the benefit of all. We promote wider social and economic progress through the advancement of information technology science and practice. We bring together industry, academics, practitioners and government to share knowledge, promote new thinking, inform the design of new curricula, shape public policy and inform the public.
Our vision is to be a world-class organisation for IT. Our 75,000-strong membership includes practitioners, businesses, academics and students in the UK and internationally. We deliver a range of professional development tools for practitioners and employees. A leading IT qualification body, we offer a range of widely recognised qualifications.
Further Information BCS, The Chartered Institute for IT, First Floor, Block D, North Star House, North Star Avenue, Swindon, SN2 1FA, UK. T +44 (0) 1793 417 424 F +44 (0) 1793 417 444 www.bcs.org/contact http://shop.bcs.org/ MODELLING BUSINESS INFORMATION Entity relationship and class modelling for business analysts
Keith Gordon © 2017 BCS Learning & Development Ltd
The right of Keith Gordon to be identified as author of this work has been asserted by him in accordance with sections 77 and 78 of the Copyright, Designs and Patents Act 1988.
All rights reserved. Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted by the Copyright Designs and Patents Act 1988, no part of this publication may be reproduced, stored or transmitted in any form or by any means, except with the prior permission in writing of the publisher, or in the case of reprographic reproduction, in accordance with the terms of the licences issued by the Copyright Licensing Agency. Enquiries for permission to reproduce material outside those terms should be directed to the publisher. All trademarks, registered names etc. acknowledged in this publication are the property of their respective owners.
BCS and the BCS logo are the registered trademarks of the British Computer Society, charity number 292786 (BCS).
Published by BCS Learning & Development Ltd, a wholly owned subsidiary of BCS, The Chartered Institute for IT, First Floor, Block D, North Star House, North Star Avenue, Swindon, SN2 1FA, UK. www.bcs.org
Paperback ISBN: 9781780173535 PDF ISBN-13: 9781780173542 EPUB ISBN-13: 9781780173559 Kindle ISBN-13: 9781780173566
British Cataloguing in Publication Data. A CIP catalogue record for this book is available at the British Library.
Disclaimer: The views expressed in this book are those of the authors and do not necessarily reflect the views of the Institute or BCS Learning & Development Ltd except where explicitly stated as such. Although every care has been taken by the authors and BCS Learning & Development Ltd in the preparation of the publication, no warranty is given by the authors or BCS Learning & Development Ltd as publisher as to the accuracy or com- pleteness of the information contained within it and neither the authors nor BCS Learning & Development Ltd shall be responsible or liable for any loss or damage whatsoever arising by virtue of such information or any instructions or advice contained within this publication or by any of the aforementioned.
Typeset by Lapiz Digital Services, Chennai, India.
vi CONTENTS
List of figures and tables x About the Author xiii Foreword xv Acknowledgements xviii Glossary xix Introduction xxv
PART 1 THE BASICS 1
1. WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION 3 What is business analysis? 3 Information and data 5 The importance for a business analyst of understanding information needs 6 The role of models in business analysis 7 Data models and data 10 Entity relationship modelling 11 Class modelling 12 Use of data models in business analysis 13 What makes a good data model? 14 Introducing data analysis 14
2. MODELLING THE THINGS OF INTEREST TO THE BUSINESS AND THE RELATIONSHIPS BETWEEN THEM 16 Entities and objects 16 Naming of entity types and object classes 18 Introduction to relationships and associations 19 Relationship notation in entity relationship models 20 Association notation in UML class models 22 Degrees of cardinality and optionality 24 Multiple relationships and associations 27 Recursive relationships and reflexive associations 29 Exercises for Chapter 2 30
3. MODELLING MORE COMPLEX RELATIONSHIPS 32 The problems with many-to-many relationships and associations 32 Resolving entity relationship model many-to-many relationships 33 Resolving class model many-to-many associations 35
vii MODELLING BUSINESS INFORMATION
The ‘bill of materials’ structure 36 Mutually exclusive relationships and associations 39 Generalisation and specialisation in entity relationship models 41 Generalisation and specialisation in class models 43 Aggregation and composition 46 Exercises for Chapter 3 48
4. DRAWING AND VALIDATING INFORMATION MODEL DIAGRAMS 50 The model drawing process 50 Identifying the entity types or the object classes 51 Identifying the relationships or associations 53 Drawing the initial diagram 54 Validating the diagram 56 Exercises for Chapter 4 63
5. RECORDING INFORMATION ABOUT THINGS 65 Revisiting entity types, object classes, relationships and associations 65 Introduction to attributes 66 The naming of attributes 69 Entity type, object class or attribute? 69 Unique identifiers 72 Domains 74 The UML extended attribute notation 75 Showing operations on class models 77 Exercises for Chapter 5 79
6. RATIONALISING DATA USING NORMALISATION 81 What is normalisation? 81 The relational model of data 82 The rules of normalisation 84 Starting the normalisation process 85 First normal form 86 Second normal form 89 Third normal form 90 The third normal form data model 94 Candidate keys, primary keys and alternate keys 95 The relationship of normalisation to modelling 95 Exercises for Chapter 6 96
PART 2 SUPPLEMENTARY MATERIAL 97
7. OTHER MODELLING NOTATIONS 99 The IDEF1X notation 100 The Information Engineering notation 104 The Chen notation 104 Comparison of the notations 107
8. THE NAMING OF ARTEFACTS ON INFORMATION MODELS 108 The naming of entity types or object classes 108 The naming of domains 110 viii CONTENTS
The naming of attributes 110 The naming of relationships in Ellis-Barker entity relationship models 112 The naming of associations on UML class models 112
9. INFORMATION MODEL QUALITY 114 Genericity and specificity in models 114 The nine characteristics of a good data model 116 The six principles of high quality data models 118 The five dimensions of data model quality 120 The layout of models 121
10. CORPORATE INFORMATION AND DATA MODELS 123 The problems 123 Principles for the development of a corporate model 125
11. DATA AND DATABASES 127 The data landscape 127 Databases 130
12. BUSINESS INTELLIGENCE 139 The data warehouse 139 The multidimensional model of data 140 Dimensional modelling 141
13. ADVANCES IN SQL (OR WHY BUSINESS ANALYSTS SHOULD NOT BE IN THE WEEDS) 144 The basics of SQL 144 New SQL data types 145 The future 151 Implications for business analysts and information modellers 151
14. TAKING A REQUIREMENTS INFORMATION MODEL INTO DATABASE DESIGN 154 First-cut database design stage 154 Optimised database design stage 155
APPENDICES 157 Appendix A: Table of equivalences 158 Appendix B: Bibliography 159 Appendix C: Solutions to the exercises 162 Index 172
ix LIST OF FIGURES AND TABLES
Figure 1.1 Three levels of system 4 Figure 1.2 The relationship between data and information 6 Figure 1.3 A rich picture 7 Figure 1.4 A business activity model 8 Figure 1.5 A business process model 8 Figure 1.6 A use case diagram 9 Figure 1.7 Requirements engineering in context 9 Figure 1.8 An example entity relationship model using the Ellis-Barker notation 12 Figure 1.9 An example of a UML class model 13 Figure 2.1 The vehicle hire company using Ellis-Barker notation 16 Figure 2.2 The vehicle hire company using UML class model notation 17 Figure 2.3 A relationship in an entity relationship model 20 Figure 2.4 An association in a UML class model 22 Figure 2.5 The use of role names 23 Figure 2.6 One-to-many (1:n) optional–mandatory relationship and association 25 Figure 2.7 One-to-many (1:n) mandatory–optional relationship and association 26 Figure 2.8 One-to-one (1:1) optional–mandatory relationship and association 26 Figure 2.9 Many-to-many (m:n) optional–optional relationship and association 27 Figure 2.10 Modelling the ‘one-way’ hire situation 28 Figure 2.11 Employee supervision 29 Figure 3.1 Employees and branches 32 Figure 3.2 Introducing the ASSIGNMENT entity type 34 Figure 3.3 Introducing the ASSIGNMENT object class 35 Figure 3.4 Introducing the ASSIGNMENT association class 36 Figure 3.5 Introducing products within products 36 Figure 3.6 The bill of materials structure in Ellis-Barker notation 37 Figure 3.7 The bill of materials structure in UML class model notation 37 Figure 3.8 Employee supervision in a matrix organisation 38 Figure 3.9 Employee supervision in a matrix organisation resolved 39 Figure 3.10 The vehicle hire company as shown in Figure 2.1 39 Figure 3.11 The introduction of an exclusive arc 40 Figure 3.12 The introduction of the {xor} constraint 41 Figure 3.13 An example of a supertype–subtype hierarchy 42 Figure 3.14 Alternative depiction of a supertype–subtype hierarchy 43 x LIST OF FIGURES AND TABLES
Figure 3.15 A UML superclass–subclass hierarchy 44 Figure 3.16 Alternative notation for a UML superclass–subclass hierarchy 44 Figure 3.17 A UML class model with multiple superclass–subclass hierarchies 45 Figure 3.18 Aggregation using Ellis-Barker notation 46 Figure 3.19 An example of the use of the aggregation symbol in a UML class model 47 Figure 3.20 An example of the use of the composition symbol in a UML class model 47 Figure 3.21 Composition using Ellis-Barker notation 47 Figure 4.1 The model drawing process 51 Figure 4.2 A ‘relationship matrix’ 53 Figure 4.3 The initial Ellis-Barker entity relationship model 54 Figure 4.4 The initial UML class model 54 Figure 4.5 The first data navigation path 57 Figure 4.6 The second data navigation path 58 Figure 4.7 The revised Ellis-Barker entity relationship model 59 Figure 4.8 The revised UML class model 60 Figure 4.9 Partial high-level process map 60 Figure 4.10 Completed CRUD matrix 61 Figure 4.11 The final Ellis-Barker entity relationship model 62 Figure 4.12 The final UML class model 62 Figure 5.1 The previous models 65 Figure 5.2 Attribute types shown on an Ellis-Barker entity relationship model 67 Figure 5.3 Attributes shown on a UML class model 68 Figure 5.4 EMPLOYEE expanded (shown in Ellis-Barker entity relationship notation) 71 Figure 5.5 EMPLOYEE expanded (shown in UML class modelling notation) 72 Figure 5.6 Unique identifiers on an Ellis-Barker entity relationship model 73 Figure 5.7 The UML <
xi MODELLING BUSINESS INFORMATION
Figure 7.6 Comparison of the relationship notations 107 Figure 9.1 An example of the replacement of roles by entity types 115 Figure 9.2 The generic to specific continuum 116 Figure 9.3 The cost-balance of flexible design 119 Figure 9.4 The five dimensions of data model quality 120 Figure 11.1 The data landscape 127 Figure 11.2 Example data arranged in tables and columns 128 Figure 11.3 The database chronology 131 Figure 11.4 Hierarchical database schema 131 Figure 11.5 Hierarchical database occurrences 132 Figure 11.6 Network database schema 134 Figure 11.7 Network database occurrences 135 Figure 12.1 A multidimensional data model 140 Figure 12.2 A typical ‘star’ schema for a data warehouse 141 Figure 12.3 A ‘snowflake’ schema 143 Figure 12.4 A ‘galaxy’ schema 143 Figure 13.1 The original ‘workshop’ model 151 Figure 13.2 The third normal form model 152 Figure 13.3 The final model 153
Table 4.1 Identified entity types or object classes 52 Table 8.1 Examples of formal attribute names 111 Table A.1 Table of equivalences 158
xii ABOUT THE AUTHOR
Keith Gordon was a professional soldier for 38 years, joining the Army straight from school at 16 and retiring on his 55th birthday. During his service with the Royal Armoured Corps, the Royal Corps of Signals and the Royal Army Educational Corps (now the Educational and Training Services Branch of the Adjutant General’s Corps) he gained a Higher National Certificate in Electrical, Electronic and Telecommunications Engineering, a Certificate in Education from the Institute of Education of the University of London, a Bachelor of Arts from the Open University and a Master of Science in Design of Information Systems from Cranfield Institute of Technology.
The Master of Science course, held at the Royal Military College of Science, was unclear about what sort of information system the students were supposed to be designing. Was it a business system to be used in the non-operational world of the military? Was it a command and control information system to be used on the battlefield? Was it a real-time system to be used in areas such as weapon control? Or was it a management information system?
The course did, however, cover some really useful stuff. On the technical side this included programming in Ada and Coral-66, which are languages designed for embed- ded and real-time systems. We also studied Soft Systems Methodology (the academic lead for the course had researched for his doctorate at Lancaster University under the supervision of Professor Peter Checkland) and we looked, in particular, at the work of Professor Brian Wilson specialising in the application of Soft Systems Methodology to the development of information systems. The Structured Systems Analysis and Design Method (SSADM) (now called ‘Business System Development’ and the impetus for the Business System Development scheme of BCS which includes the Business Analysis and Solution Development diplomas and used to include a Data Management diploma) also formed a substantial part of the course.
Following the Design of Information Systems course, Keith spent three years as a con- sultant in the Army School of Training Support, where he looked into and procured com- puter systems for use in education and training – computer-based training (CBT). This role was part researcher and part business analyst. The next two years were spent as the Senior Education Officer in the Army’s apprentice college for the training of appren- tice soldier chefs.
In 1992, he was posted to the Ministry of Defence and joined a new team of four officers and a civil servant ‘doing data management’ for the Army. In 1995, he was promoted to Lieutenant Colonel and became the head of that team until he retired from the Army in 1998.
xiii MODELLING BUSINESS INFORMATION
He is now an independent consultant and lecturer specialising in data management and business analysis. As well as developing and teaching commercial courses, he was for a number of years a tutor for the Open University, tutoring general computing and database courses in the undergraduate and postgraduate programmes.
He is a Chartered Member of BCS, The Chartered Institute for IT, a Member of the Chartered Institute of Personnel and Development and a Fellow of the Institution for Engineering and Technology.
He holds the Diploma in Business Systems Development specialising in data manage- ment from BCS – formerly the Information Systems Examination Board (ISEB) – and he is now an examiner for the Business Systems Development scheme.
He represents the UK within the international standards development community by being nominated by the British Standards Institution (BSI) to the international stand- ards committee, ISO/IEC JTC1 SC32 WG2 (Information Technology – Data Management and Interchange – Metadata). In this role, he has contributed to the development of ISO/IEC 11179 (Metadata registries) and ISO/IEC 19763 (Metamodel framework for interoperability).
For a number of years, Keith was the secretary of the BCS Data Management Specialist Group and, as a founder member, was a committee member of the UK chapter of DAMA International, the worldwide association of data management professionals.
xiv FOREWORD
Business analysts have a curiosity about the business environment. They are keen to understand how processes can be improved, how customers can be given better service and, ultimately, how their organisations can be successful. As analysts though, if we want to understand how things work and can be improved, we can’t look at processes alone. The other key dimension that underlies all of these aspects, and provides a firm foundation for the organisation’s work, is the information that makes the business oper- ate. Information is the lifeblood of organisations and the people working within them.
Let’s think about what information offers:
yy evidence for root cause analysis; yy a basis for decisions; yy measures for evaluating performance; yy tangible indications of opportunities; yy parameters for applying business rules.
Information can address all of these areas and more, and provide a means of challeng- ing assumptions and opinions. Surely this is a much better approach than employing gut feel or inventing ideas to suit personal agendas.
However, if businesses require information to operate effectively, they need a clear understanding of their data. If processes are to be efficient and effective, decision-mak- ing is to be precise and customer service is to be of the highest standard, the data needs to be accurate, accessible and available.
Data is at the heart of business. It forms the basis for providing essential information, including:
yy who our customers are and what work they have done with us; yy the nature and characteristics of our products and services; yy the details regarding our financial situation and staff.
If organisations understand the importance of data, and work with it effectively, they can succeed in today’s world of high expectations and intense competition. If organisations fail to acquire, record, manage and utilise data, then business failure will surely follow.
xv MODELLING BUSINESS INFORMATION
Aside from the effective operation of the enterprise, there are also the opportunities that data can clarify or make available to forward looking, receptive organisations. Data can be interpreted to offer information about the changing nature of the business environ- ment. For example, new service requirements, the demographic make-up of customers, areas where product customisation is desired; all of these can provide opportunities for the organisation to learn and grow. We often talk about the learning organisation, but to become one relies on the receipt of good feedback (the data) and acting upon it (the processes).
Over the last couple of decades though, it has felt as if data was a secondary dimension with process improvement taking centre stage. There has been a move to almost ignore data requirements within organisations and place the focus on the business processes and the customer experience. Those of us who have worked as data analysts, model- lers and managers, have long feared the effect this approach could have, predicting that the impact of a reduced focus on data would eventually be recognised and hoping that it wouldn’t be at too high a cost. The advent of popular memes such as ‘big data’ has certainly brought data back to the forefront but there is also the issue of smaller, every day data - the data that makes the wheels go around rather than completely reinventing the wheel. This data may not help us to predict the innovations of the future but without it the organisation can’t operate and will fail to identify where change is required.
A popular misconception has been that analysing data is ‘difficult’ and ‘technical’, and should be the responsibility of those working as software architects or developers rather than the business analysts engaging with business stakeholders. The reality that information and data reflect business requirements seems to have been lost some- where along the way.
Yet, if organisations are to ‘learn’ and benefit from receiving informed feedback in order that they can respond and grow, they have to understand that data is important and should be handled with care. There needs to be an appreciation that the data reflects the operations, policies and rules of the organisation and while these may be embed- ded within software, they originate from people making decisions – including business managers and staff, external customers and suppliers, and regulatory agencies. In other words, data is not a technical domain, it is something everyone needs to appreciate, and the analysis of data needs to be conducted by those with business understanding. There should be people within the organisation who have the expertise and insight to elicit data requirements, analyse the structure and semantics of data, build clear models of the data and manage the data resource. We are in an insecure world where there is increasing recognition of the importance of data and the need to ensure data security and protection.
Which brings me to this book. Those of us who have long-lamented that we regularly encounter a limited data focus should congratulate Keith Gordon for providing such a comprehensive, clear and practical resource in this book. The topics covered take us through the process of eliciting, modelling and validating data. The key approaches to representing and understanding data are explained, including the often-overlooked topic of data normalisation. All in all, the book provides extensive guidance that the busi- ness analyst – and anyone else requiring an understanding of data analysis – needs if they are to work effectively with data. The book helps anyone new to the world of data to learn the techniques and principles behind successful data analysis. The breadth of the xvi FOREWORD
book also helps those with experience in data analysis to encounter new ideas, brush up and broaden their knowledge, and deepen their understanding.
Modelling Business Information encourages readers to understand that data is not just about modelling for the technical solution, it is concerned with understanding the organ- isation, the rules it applies, and the information it needs. In other words, data analysis is a business discipline and the work to understand data should be performed by those with a business mindset.
Organisations require business analysts who can help the business staff to articulate data requirements and ensure that information needs can be met. Tomorrow’s business world needs data to be collected, governed and analysed in order to be an effective resource for organisations. This book helps organisations to do this. You should read it and use it as a key business resource.
Debra Paul Managing Director, Assist Knowledge Development
June 2017
xvii ACKNOWLEDGEMENTS
Understanding and documenting the information needs of the business are an essential part of data management, so my real introduction to modelling these concepts and things came when I joined the Army’s data management team. Among the people to whom I owe a debt of gratitude are my colleagues in that team, Ian Nielsen, Martin Richley, Duncan Broad and Tim Scarlett, as well as the consultants who helped us develop our ‘corporate data model’ and design the resulting database, David Gradwell, Ken Allen, Ron Segal (who is now in New Zealand), Elaine Senior and the wonderful Harry Ellis who has done so much to help the world know how to understand and document information requirements through his pioneering work on data modelling and data management. Later members of that team included, among others, Mark Thurlow, Lucy Finney and Peter Lawson.
Over the last 20 years or so I have had many interesting conversations about infor- mation and data modelling (yes, it is possible!) with, among others: Bob Walker and Gene Simaitis, both formerly of the Institute for Defense Analyses in Washington, DC; Mike Newton and Steven Self from the Open University; Hajime Horiuchi and Masao Okabe from Japan and Ray Gates from Canada, all colleagues in ISO/IEC JTC1 SC32 WG2; Matthew West, author of Developing High Quality Data Models, formerly of Shell and now also a colleague in ISO/IEC JTC1 SC32 WG2; David Hay from Houston, USA, author of many books including Data Model Patterns, Conventions of Thought, Requirements Analysis and UML and Data Modelling, a Reconciliation; and Alec Sharp from Canada, conference speaker and co-author of Workflow Modeling, Tools for Process Improvement and Application Development.
Special mention must go to David Beaumont from Stehle Associates, my constant sounding board for my ideas over the last 18 years.
Homing in on this book, I need to thank Terri Lydiard, a fellow BCS examiner, who reviewed an early draft of Chapter 1 and Keith Hare, of JCC Consulting in Granville, Ohio, USA and convenor of ISO/IEC JTC1/SC32/WG3, who reviewed Chapters 11 and 13. Both provided valuable comments which I have tried to incorporate.
Thanks are also due to Ian Borthwick and Rebecca Youé of BCS who have been respon- sible for getting this book into print.
Finally, a massive thank you to the back-up team at home, my wife, Vivienne. She has found it difficult to understand why I am not wandering around a golf course or sitting in an armchair by the fire instead of enjoying myself running around the world attending meetings, teaching, examining, writing books and generally getting involved in things because of my total inability to say, ‘No’. I have promised Vivienne that I will look up the word ‘Retirement’ in the dictionary one day – but not yet. xviii GLOSSARY
aggregation (Class modelling) A special form of association that specifies a whole–part relationship between an object class representing the aggregate (whole) and another object class representing the component part. alternate key (Relational data analysis) A candidate key that is not selected to be the primary key for the relation. artefact A diagram or supporting description providing a representation of the system of interest. association (Class modelling) A business link between two object classes. The link is required in order to navigate from one class to another. association class (Class modelling) An object class that has both association and object class properties. attribute (Entity relationship modelling and class modelling) A named characteristic of an entity type or object class whose values serve to qualify, identify, classify, quantify or express the state of an instance of that entity type or object class. big data A data set, or a collection of data sets, with characteristics (for example, volume, velocity, variety, variability, veracity) that for a particular problem domain at a given point in time cannot be efficiently processed using current/existing/established/ traditional technologies and techniques in order to extract value. candidate key (Relational data analysis) An attribute, or a set of attributes, that pro- vides the ability to uniquely identify a tuple in a relation without referring to any other data, such that no two tuples in a relation can have the same value, or set of values, for their candidate keys. cardinality (Entity relationship modelling and class modelling) The degree of occurrence indicated on a relationship between two entity types or an association between two object classes. The cardinality reflects part of the business rules for a relationship or association.
CASE Acronym for computer-aided software engineering – a combination of software tools that assist computer development staff to engineer and maintain software sys- tems, normally within the framework of a structured method.
Chen notation (Entity relationship modelling) The original entity–relationship modelling notation. xix MODELLING BUSINESS INFORMATION
class model (Class modelling) A technique from the Unified Modeling Language (UML). A class model describes, using graphics and documentation, the classes in a system and their associations with each other. Within business analysis the classes are limited to the things of significance about which information needs to be held in support of business operations. composite identifier (Entity relationship modelling) A unique identifier formed from a combination of attributes. composite key (Relational data analysis) A candidate key comprising more than one attribute. composition (Class modelling) A form of aggregation which requires that a part instance be included in at most one composite at a time, and that the composite object is responsible for the creation and destruction of the parts. column The logical structure within a table of a relational database management sys- tem (RDBMS) that corresponds to the attribute in the relational model of data. conceptual data model A detailed model that captures the overall structure of organi- sational data while being independent of any database management system or other implementation consideration – it is normally represented using entity types, relation- ships and attributes with additional business rules and constraints that define how the data is to be used. corporate data model A conceptual data model whose scope extends beyond one application system. data A reinterpretable representation of information in a formalised manner suitable for communication, interpretation or processing. data analysis The process of understanding and documenting in a data model the information (or data) requirements of a business or business area; data analysis is a part of business analysis. data mining The process of finding significant, previously unknown and potentially valuable knowledge hidden in data. data model (i) An abstract, self-contained logical definition of the data structures and associated operators that make up the abstract machine with which users interact (such as the relational model of data). (ii) A model of the persistent data of some enterprise (such as an entity–relationship model or class model of the data required to support a business or business area). data modelling The task of developing a data model that represents the persistent data of some enterprise. data type A constraint on a data value that specifies its intrinsic nature, such as numeric, alphanumeric or date. data warehouse A specialised database containing consolidated historical data drawn from a number of existing databases to support strategic decision-making. xx GLOSSARY
database (i) An organised way of keeping records in a computer system. (ii) A collec- tion of data files under the control of a database management system. database management system (DBMS) A software application that is used to create, maintain and provide controlled access to databases. described domain (Entity relationship modelling and class modelling) A domain that is specified by a description or specification, such as a rule, a procedure or a range (i.e. interval); a domain that is not enumerated. domain (Entity relationship modelling and class modelling) A named pool (or set) of values from which an instance of an attribute must take its value; a domain provides a set of business validation rules, format constraints and other properties for one or more attributes
Ellis-Barker notation (Entity relationship modelling) A modelling notation designed by Harry Ellis and Richard Barker while working at the consultancy company CACI with business users in mind so as to reduce interactions with those users. This notation was later used by the Oracle Corporation and by the UK Government’s Central Computer and Telecommunications Agency (CCTA) for its Structured Systems Analysis and Design Method (SSADM). entity (Entity relationship modelling) A named thing of significance about which infor- mation needs to be held in support of business operations. entity occurrence (Entity relationship modelling) A single instance of an entity within an entity type. entity relationship model (Entity relationship modelling) A data model based on entity types and their attributes and relationships. entity subtype (Entity relationship modelling) A subset of the instances of an entity type, known as the supertype, that share common attributes or relationships distinct from other subsets of the supertype. entity type (Entity relationship modelling) An element of a data model that represents a set of characteristics common to a collection of entities that are instances of the type. enumerated domain (Entity relationship modelling and class modelling) A domain that is specified by a list of all its permitted values. first normal form (1NF or FNF) (Relational data analysis) A relation is in first normal form if all the values taken by the attributes of that relation are atomic or scalar values – the attributes are single-valued or, alternatively, there are no repeating groups of attributes. foreign key (Relational data analysis) One or more attributes in a relation that imple- ment a many-to-one relationship that the relation has with another relation or with itself (the reference); the values of the foreign key in a tuple must match the values of the primary key in one of the tuples in the referenced relation.
xxi MODELLING BUSINESS INFORMATION
hierarchic identifier (Entity relationship modelling) A unique identifier where at least one element of the identifier is a relationship; a hierarchic identifier may be either a combination of relationships or a combination of attribute(s) and relationship(s). hierarchic key (Relational data analysis) A candidate key comprising more than one attribute where part of the candidate key is a foreign key.
IDEF1X (Entity relationship modelling) An entity relationship modelling notation from the family of ICAM (Integrated Computer-Aided Manufacturing) Definition Languages (IDEF) used by the US Federal Government. information (i) Something communicated to a person. (ii) Knowledge concerning objects, such as facts, events, things, processes or ideas, including concepts, which have a particular meaning within a certain context. information Engineering notation (Entity relationship modelling) An entity relationship modelling notation that is one of the techniques used in Information Engineering, a methodology developed by James Martin and Clive Finkelstein in the late 1970s. master data management The authoritative, reliable foundation for data used across many applications and constituencies with the goal to provide a single version of the truth. metadata Data about data – that is, data describing the structure, content or use of some other data. multiplicity (Class modelling) A statement, consisting of a lower-bound (or minimum) and upper-bound (or maximum) of the form ‘minimum..maximum’, of the number of elements that may exist in a collection; when applied to an association it represents the cardinality and optionality of the association and when applied to an attribute it repre- sents the optionality of the attribute. multimedia data Data representing documents, audio (sound), still images (pictures) and moving images (video). normal form (Relational data analysis) A state of a relation that can be determined by applying simple rules regarding dependencies to that relation. normalisation (Relational data analysis) Another name for relational data analysis. object (Class modelling) A construct within a system for which a set of attributes and operations can be specified; an instance of a particular object class. object class (Class modelling) A definition of a set of objects that share the same attributes, operations and associations. object-orientation A software-development strategy based on the concept that sys- tems should be built from a collection of reusable components called objects that encompass both data and functionality.
xxii GLOSSARY
object subclass (Class modelling) A subset of the instances of an object class, known as the superclass, that share common attributes and associations distinct from other subsets of the superclass.
ODMG Abbreviation for the Object Data Management Group, a body that has produced a specification for object-oriented databases.
OLAP Acronym for online analytical processing – a set of techniques that can be applied to data to support strategic decision-making.
OLTP Abbreviation for online transactional processing – data processing that sup- ports operational procedures. operation (Class modelling) A set of actions performed on the data within an object. optionality (Entity relationship modelling and class modelling) The ability of an instance of an entity type or object class to exist without being linked to an instance of the related entity type or object class. The optionality reflects part of the business rules for a rela- tionship or association. permitted value (Entity relationship modelling and class modelling) One of the explicit set of values that comprise an enumerated domain. primary key (Relational data analysis) The candidate key that is selected to enforce uniqueness of tuples in a relation.
RDBMS Abbreviation for relational database management system – a database man- agement system whose logical constructs are derived from the relational model of data. Most relational database management systems available are based on the SQL database language and have the table as their principal logical construct. relation (Relational data analysis) The basic structure in the relational model of data – formally a set of tuples, but informally visualised as a table with rows and columns. relational data analysis A technique of transforming complex data structures into simple, stable data structures that obey the rules of relational data design, leading to increased flexibility and reduced data duplication and redundancy – also known as nor- malisation. relational model of data A model of data that has the relation as its main logical construct. relationship (Entity relationship modelling) A named set of characteristics common to a collection of connections between instances of two or more entity types, or between instances of one entity type and other instances of the same entity type. schema A description of the overall structure of a database expressed in a data defini- tion language (such as the data definition component of SQL). second normal form (2NF or SNF) (Relational data analysis) A relation is in second normal form if it is in first normal form and every non-key attribute is fully dependent on the primary key – there are no part-key dependencies. xxiii MODELLING BUSINESS INFORMATION
simple identifier (Entity relationship modelling) A unique identifier formed from a sin- gle attribute. simple key (Relational data analysis) A candidate key comprising just one attribute.
SQL Originally, SQL stood for structured query language. Now, the letters SQL have no meaning attributed to them. SQL is the database language defined in the ISO/IEC 9075 set of international standards, the latest edition of which was published in 2016. The language contains the constructs necessary for data definition, data querying and data manipulation. Most vendors of relational database management systems use a version of SQL that approximates to that specified in the standards. structured data Data that has a high level of organisation in that it conforms to speci- fied data types and relationships and is managed by technology that allows for querying and reporting, such as data within relational databases and spreadsheets. surrogate identifier (Entity relationship modelling) An artificial (i.e. not real world) unique identifier formed from an attribute or a combination of attributes that are either system-generated or allocated by a user. table The logical structure used by a relational database management system (RDBMS) that corresponds to the relation in the relational model of data – the table is the main structure in SQL. third normal form (3NF or TNF) (Relational data analysis) A relation is in third normal form if it is in second normal form and no transitive dependencies exist. tuple (Relational data analysis) A construct in the relational model of data that is equiv- alent to a row in a table or an occurrence of an entity – it contains all the attribute values for each instance represented by the relation.
Unified Modeling Language (UML) A set of diagramming notations for systems analy- sis and design based on object-oriented concepts. unique identifier (Entity relationship modelling) An attribute, a combination of attrib- utes, a combination of relationships or a combination of attribute(s) and relationship(s) that provides the ability for each entity to be uniquely identifiable so that each instance of an entity type is distinctly identifiable from all other instances of that entity type. unstructured data Computerised information which does not have a data structure that is easily readable by a machine, including audio, video and unstructured text such as the body of a word-processed document – effectively this is the same as multimedia data. validation rule (Entity relationship modelling and class modelling) A statement of the validation that may be applied to a described domain; this statement may be a reference to a data type to be applied to attributes, a range of values, or a ‘format mask’, or any other expression that constrains the domain.
xxiv INTRODUCTION
In my previous book,1 I looked at how information, and its cousin, data, should be man- aged as an enterprise-wide resource. In this book, I am looking at the role of business analysts in understanding and documenting the information that needs to be recorded in an information system or its supporting information technology (IT) system to meet the needs of the business for the storage and retrieval of information.
The first part of the book (Part 1, The Basics, Chapters 1 to 6) covers the requirements for the Data Analysis certificate that is part of the scheme for the BCS Advanced Inter- national Diploma in Business Analysis.2
The book will, therefore, be of immediate interest for anybody who is studying for this certificate. It should also be of interest to all business analysts as I have tried to set out how an entity relationship model (also known as an entity relationship diagram) or a UML class model (also known as a class diagram) can help a business analyst under- stand the information needs of a particular business area and then help communicate that understanding, both to the business users and, finally, to the systems developers.
The second part of the book (Part 2, Supplementary Material, Chapters 7 to 14) provides extra information that I believe should be of interest to business analysts.
These chapters are followed by three appendices. Appendix A provides a table to show the equivalence between the concepts used in the various parts of the book. Appendix B provides a bibliography and Appendix C provides solutions to the exercises introduced in Part 1.
1 Principles ofaData Management: Facilitating Information Sharing, Second Edition (BCS, 2013). 2 http://certifications.bcs.org/category/18428
xxv
PART 1: THE BASICS
The first part of the book (Chapters 1 to 6), which provides a general introduction to entity relationship modelling and UML class modelling, covers the requirements for the Data Analysis certificate that is part of the scheme for the BCS Advanced International Diploma in Business Analysis.
Chapter 1, Why business analysts should model information, provides an introduction to business analysis, systems, information, data and modelling and why these topics come together within the development of requirements for an IT system. The notations used within the book, the Ellis-Barker entity relationship notation and the UML class diagram notion, are introduced. The chapter finishes with a discussion of data analysis.
Chapter 2, Modelling the things of interest to the business and the relationships between them, introduces the basic modelling concept of the entity to represent something of interest to the business about which information needs to be recorded and the related concept of the entity types, the representation of a group of entity occurrences with common characteristics. The relationships between entity types are also introduced. Alongside the introduction of these concepts, the comparable concepts of object, object class and association are also introduced.
Chapter 3, Modelling more complex relationships, explores some of the more complex relationships that can exist between entity types or object classes. The topics covered are the resolution of many-to-many relationships and associations (including the oddity known as the ‘Bill of Materials’ structure), mutually exclusive relationships and asso- ciations, which leads to generalisation and specialisation, and, finally, a quick look at aggregation and composition.
Chapter 4, Drawing and validating information model diagrams, introduces a process for drawing an information model diagram. It then considers two techniques for validating an information model – the data navigation path and the Create-Read-Update-Delete (CRUD) matrix.
Chapter 5, Recording information about things, introduces the related concepts of the attribute, the unique identifier and the domain, and their representation on both entity relationship models and class models. The object-oriented concept of the operation is also introduced at the end of the chapter.
Chapter 6, Rationalising data using normalisation, involves a change of direction as we look at the process of relational data analysis (or normalisation). We need to look at the theory of the relational model of data – the ‘model’ that underpins all of the database
1 MODELLING BUSINESS INFORMATION
management systems that use the SQL database language. Having understood the theory, we then look at the process of normalisation and the production of a ‘third normal form’ model.
These chapters should be read sequentially, from Chapter 1 through to Chapter 6. Revision exercises are provided at the end of Chapters 2 to 6.
2 1 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
This chapter provides an introduction to business analysis, systems, information, data and modelling and why these topics come together within the development of require- ments for an IT system. The chapter finishes with a discussion of data analysis.
WHAT IS BUSINESS ANALYSIS?
Business analysis is a discipline that has been evolving for about 20 years. Its main purpose is to ensure that there is alignment between business needs and business change solutions. Many of these business change solutions involve the development of new – or the enhancement of existing – information technology (commonly abbreviated to IT) systems. There is no fixed route to becoming a business analyst. Some business analysts have a strong information technology background and have developed an understanding of busi- ness in general and their business organisation in particular. Other business analysts have a strong business background and, where a solution involving information technology is concerned, they need to have obtained an understanding both of the capabilities provided by information technology and of how an information technology system is developed. The word ‘system’ appears in the two preceding paragraphs because it is important for the business analyst to grasp hold of ‘systems thinking’. Whether the proposed business change solution involves the use of information technology or not, the business analyst is working with or specifying the requirements for systems. These systems may be business systems, information systems or information technology systems. So, what is a system? Professor Michael C. Jackson of the University of Hull has defined a system as
a complex whole the functioning of which depends on its parts and the interactions between those parts.3
Using this definition, the term ‘system’ can be applied to a hard, designed system such as a central heating system or to a soft, or human activity, system such as a business organisation. A central heating system consists of a boiler, radiators, pipes and, importantly, a ther- mostat to keep the whole system under control. This is a ‘complex whole’, the function- ing of which depends on all of those parts working together.
3 Systems Thinking: Creative Holism for Managers (2003), page 3, Michael C. Jackson. 3 MODELLING BUSINESS INFORMATION
A business, whether in the private, public or not-for-profit sectors of the economy, consists of people (employees, suppliers and customers), organisations (headquarters, branches, departments) and processes (including ordering and receiving goods and selling goods). All businesses require information to manage their people, organisations and processes and, for most businesses these days, there is information technology providing support for the management of that information. So, a business can be seen as another ‘complex whole’, the functioning of which depends on the parts, the people, the organisations, the processes, the information and the technology, working together to achieve the goals of the business. There will also be checks and balances to ensure that the business remains effective and efficient – the equivalent of the thermostat in the central heating system. Any business can, therefore, be considered as a system – a business system. Any sys- tem can have a number of subsystems, so a business system can also have subsystems. One of the important subsystems of a business system is the information system, or set of information systems, which supports the business by managing the business’s information. I define an information system as:
a system that gets the right information to the right person in the right place at the right time.
We need, therefore, to think about information systemically. If there is a requirement for Sue in production to receive details of an important sales order as soon as it arrives in the business, then we need to arrange for that to happen. It could be that the arrange- ment is for the salesman, John, who has just completed the sale, to walk along the cor- ridor to production to tell Sue about the sales order. The right information (details of the sales order) is being delivered to the right person (Sue) in the right place (the production department) at the right time (immediately) without the use of any technology. We have a technology-free information system! Yes, that is possible, but that information system still needs defining, developing, implementing and maintaining. Most modern businesses require the information system to be supported by an infor- mation technology system – a collection of hardware, software and networks that func- tion together to store and retrieve information. The business analyst needs to think in terms of three levels of system: the business sys- tem itself; the subsystem that handles the information for the business (the information system); and the sub-subsystem that provides the technology to support the informa- tion system (the IT system). This is shown diagrammatically in Figure 1.1.
Figure 1.1 Three levels of system
BUSINESS SYSTEM
INFORMATION SYSTEM
IT SYSTEM
4 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
Information is a key business resource in all business, even if the senior managers of most businesses fail to recognise that fact.
INFORMATION AND DATA
In my previous book, I explained the relationship between information and data. I repeat that explanation here, slightly edited, because this book is about modelling business information with a view to storing that information as data within an information system or an information technology system.
An often-heard definition of information is that it is ‘data placed in context’. This implies that some information is the result of the translation of some data using some processing activity, and some communication protocol, into an agreed format that is identifiable to the user. In other words, if data has some meaning attributed to it, it becomes information.
For example, what do the figures ‘190267’ represent? Presented as ‘19/02/67’, it would probably make sense to assume that they represent a date. Presented on a screen with other details of an employee of a company, such as name and address, in a field that is labelled ‘Date of Birth’ the meaning becomes obvious. Similarly, presented as ‘190267 metres’, it immediately becomes obvious that this is a long distance between two places but, for this to really make sense, the start point and the end point have to be specified as well as, perhaps, a number of intermediate points specifying the route.
While these examples demonstrate the relationship between data and information, they do not provide a clear definition of either data or information.
There are many definitions of data available in dictionaries and textbooks, but the essence of most of these definitions is the understanding that data is ‘facts, events, transactions and similar that have been recorded’. Furthermore, the definition of information is usually based on this definition of data. Information is seen as data in context or data that has been processed and communicated so that it can be used by its recipient.
The idea that data is a set of recorded facts is found in many books on computing. However, this concept of data as recorded facts is used beyond the computing and infor- mation systems communities. It is, for example, also the concept used by statisticians. Indeed, the definition of data given in Webster’s 1828 Dictionary – published well before the introduction of computers – is ‘things given, or admitted; quantities, principles or facts given, known, or admitted, by which to find things or results unknown’.4
However, starting the development of our definitions by looking at data first appears to be starting at the wrong point. It is information that is important to the business, and it is there that our definitions, and our discussion about the relationship between informa- tion and data, should really start.
We start by considering the everyday usage of information – something communicated to a person – and, with that, we can find a definition of data that is relevant to business analysts. That definition is found in ISO/IEC 2382-1 1993 (Information Technology – Vocabulary – Part 1: Fundamental Terms) stating that data is
4 See www.webstersdictionary1828.com
5 MODELLING BUSINESS INFORMATION
a re-interpretable representation of information in a formalised manner suitable for communication, interpretation or processing.
There is a note attached to this definition in the ISO/IEC standard which states that data can be processed by human or automatic means; so, this definition covers all forms of data but, importantly, includes data held in information systems used to support the activities of an organisation at all levels: operational, managerial and strategic.
Figure 1.2 The relationship between data and information
Knowledge Subject of about information objects, etc.
Information Information
Representation of Interpretation of information data
Storage and Processing
Data Data
Figure 1.2 provides an overview of the relationship between data and information in the context of an information technology system. The user of the system extracts the required information from their overall knowledge and inputs the information into the system. As it enters the system, it is converted into data so that it can be stored and processed. When another system user requires that information to be retrieved, the data is interpreted – that is, it has meaning applied to it – so that it can be of use to the user.
THE IMPORTANCE FOR A BUSINESS ANALYST OF UNDERSTANDING INFORMATION NEEDS
Understanding the information needed by the business, and its representation, data, is vitally important if we are to develop effective information systems and the infor- mation technology systems to support them. In the BCS publication Business Analysis, now in its third edition, the need for a business analyst to take a holistic view of the business is stressed, where the holistic view is defined as encompassing people, organi- sations, processes, information and technology (my emphasis). Yet, as an examiner,
6 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
I am constantly coming across practising or aspiring business analysts who believe that understanding and documenting the information needed by the business is nothing to do with them. There appears to be a view that if the processes are sorted out the information will look after itself. I think this is wrong. We are, after all, concerned with information systems or information technology systems, not processing systems.
THE ROLE OF MODELS IN BUSINESS ANALYSIS
Models in various forms play an important role in business analysis. As described later in the chapter, models help the business analyst understand and communicate require- ments. Modelling is an essential competence for a business analyst.
When trying to understand how a business is currently running, we could draw a rich picture (see Figure 1.3).
Figure 1.3 A rich picture
MManufacturina g Managing Director £ £ £ External Suppliers Sales Finance Director Director We are the experts Call Centre Sales Force
IT/IS Department Trouble brewing ? Where’s our order? New CRM Old Order System Processing System
Customers
When trying to understand what a business should be doing, we can draw a business activity model (see Figure 1.4). Both of these valuable techniques are derived from Peter Checkland’s Soft Systems Methodology.5
5 Checkland, P. (1981) Systems Thinking, Systems Practice. John Wiley & Sons, Chichester, UK provides a useful insight into the use of Soft Systems Methodology. For a shorter read try Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its use for Practitioners, Teachers and Students, John Wiley & Sons, Chichester, UK.
7 MODELLING BUSINESS INFORMATION
Figure 1.4 A business activity model
Define target customers
Decide seasonal fashion range Manage staff Define sales targets Procure stock
Manage branch Distribute stock network to branches
Sell fashion
Monitor sales Monitor staff volume performance Monitor profit margins
Take control action
When trying to understand the current business processes we will probably draw a set of ‘as-is’ business process models (see Figure 1.5). We will then draw a series of ‘to-be’ business process models and discuss those with the business.
Figure 1.5 A business process model
Fulfil Order
Return Receive order to order client Salesman
[status not satisfactory] Check customer status
Sales Record Order [status satisfactory] Administration
Despatch goods Warehous e
Despatch invoice Sales Ledge r
8 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
As we move on to consider the functionality that an information technology system has to support, we might start drawing a use case diagram (see Figure 1.6).
Figure 1.6 A use case diagram
Sales Order Fulfilment
Despatch Receive goods Warehouse order Salesman Team
Record Despatch order invoice
<
All of these models have two main roles. The first of these roles is to help the analyst understand the situation they are analysing as they carry out the analysis. Secondly, once developed, they help the analyst communicate that understanding back to the business (and, in the process, maybe demonstrate their misunderstanding, lead- ing to a correction to the model) and, in the case of an information technology system development or enhancement, forward to the developers of that system. When an information technology system is being developed, the process of eliciting the requirements from the business, analysing those requirements to ensure that they are good quality requirements, validating the requirements with the business, manag- ing and documenting the requirements is known as ‘requirements engineering’. This is shown in context in Figure 1.7.
Figure 1.7 Requirements engineering in context
Models used here Models used here to communicate to communicate with the business with the developers
Business Requirements System Information Development Requirements Engineering
As you can see, we can think of requirements engineering as the filling in a sandwich, with the business and its requirements on one side and the system developers on the other.
9 MODELLING BUSINESS INFORMATION
When eliciting requirements from the business, models can be used in workshops or other interactions with the business to aid understanding. It can sometimes be useful to sketch out a model on a whiteboard or flipchart while talking to the users. Models are vital when you are asking the business to validate a set of requirements – ‘a picture paints a thousand words’.
Models are also essential when passing, or discussing, requirements to, or with, those who will have responsibility for the development of the system. It is not just that ‘IT people’ like to see models. Models will often express ideas and requirements much more clearly than is possible in text alone.
The trick is, of course, to use the same models when validating requirements with the business and when passing those requirements to the developers. ‘Business people’ do not have the time to learn complicated modelling notations and syntax. For them the models must be easy to understand. On the other hand, the developers want the models to be complete, clear, concise and unambiguous, and this can lead to the use of a complex set of notational elements. It can also, in some circumstances, lead to the use of some particular technical constructs that, from a business perspective, are unnecessary.
If we want to use the same models to communicate with the business and to communi- cate with the developers, we need to use modelling notations and conventions that are both easy for the business to understand and sufficiently detailed to completely, con- cisely, clearly and unambiguously convey the requirements to the system developers.
DATA MODELS AND DATA
We have seen a range of models that are in the business analyst’s toolkit. None of those we have seen so far truly helps us to understand what information a system needs to hold to enable it carry out its functions. These information requirements are modelled with a model called, confusingly, a data model.
In fact, data models can have two roles.
Firstly, they can be used to specify what data (or information) the business needs recorded within the system. Here the model is a complete, concise and unambiguous statement of the information requirements of the business for the system under consideration. This model is the responsibility of the business analyst.
Secondly, they can also be used to specify how the data is to be stored and organised within the system, so that it can be retrieved and analysed. Here the model is a specification for the design of the database of the system. This model (or, more probably, a set of models) is the responsibility of the database designer within the system development team.
The what model is a conceptual model, which is also known as a Computer-Independent Model (CIM). It represents the things that are of interest to the business about which information needs to be recorded, the specific information about these things that the business needs recorded, and any business relationships that exist between those things of interest. A model at this level can be considered as encapsulating the rules of the business, for example:
10 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
yy ‘people or organisations cannot be recorded as customers until they have placed an order’; yy ‘customers can place many orders’; and yy ‘customers must be allocated a customer number and we must record their name and address’.
The system development team then develop a series of how data models that lead to the design of the system’s database. The first model the developers will produce will be a logical model (often known as a Logical Data Model (LDM) or a Platform- Independent Model (PIM)) and the final model will be a model that represents the actual physical design of the database (known as a Physical Data Model (PDM) or a Platform-Specific Model (PSM)).
ENTITY RELATIONSHIP MODELLING
Data models have been around for well over 50 years. The earliest data modelling notation that I know of was for Bachman Diagrams. This notation was developed by Charles Bachman, one of the early database management system pioneers, to show the structure of a required database in the days before the advent of the modern ‘relational’ database.
Entity relationship modelling, until recently the most common form of data modelling, was first introduced by Peter Chen.6 There are, however, many ‘flavours’ of entity rela- tionship model. In this book, I am going to stick to just one of these entity relation- ship modelling notations: the notation developed by Harry Ellis and Richard Barker in the early 1980s when they worked for CACI, a UK-based consultancy company. Unsurprisingly, we will refer to this as the Ellis-Barker notation. I will, however, discuss some other common notations in Chapter 7.
The Ellis-Barker notation was specifically designed with business users in mind. In fact, in Richard Barker’s own words, they were ‘striving for even greater accuracy in systems analysis, while minimising redundant interactions with the users’.7 The notation was used by the Oracle Corporation in its computer-aided software engineering (CASE) tool and was later adopted, in a truncated form, by the UK Government’s Central Computer and Telecommunications Agency (CCTA) for its Structured Systems Analysis and Design Method (SSADM). Richard Barker described the use of this notation in a book8 he wrote while working for the Oracle Corporation.
An example of an entity relationship model drawn using the Ellis-Barker notation is shown in Figure 1.8.
This model shows that the business concerned is interested in recording information about its products, its customers and the orders placed by those customers. Each of those orders has a number of ‘order lines’ (the items on the order) and a number of statuses.
6 Chen, P.P.S. (1976) The Entity–Relationship Model: Toward a Unified View of Data, ACM Transactions on Database Systems. 7 In the Foreword to Hay, D.C. (1996) Data Model Patterns: Conventions of Thought. Dorset House. 8 Barker, R (1990) CASE*Method: Entity Relationship Modelling, Addison-Wesley.
11 MODELLING BUSINESS INFORMATION
Figure 1.8 An example entity relationship model using the Ellis-Barker notation
PRODUCT ORDER LINE order for (m) code (m) number (m) designation (m) ordered quantity subject of (m) retail cost
part of
comprised of CUSTOMER ORDER STATUS for ORDER placed by (m) number (m) designation (m) number (m) name (m) effective date described with (m) date placer of (m) address
There are a number of advantages to using the Ellis-Barker notation within business analysis. Specifically, the notation:
yy was designed for use with business users – it names things in a way that the business will understand; yy avoids the use of technical components that have no relevance to the business user and, if included (as in most other notations), would confuse the business user; yy provides a limited, consistent set of symbols; yy with its supporting documentation, provides a complete, concise, clear and unambiguous statement of the information requirements.
In addition, the Ellis-Barker notation is well known in the United Kingdom, having been adopted for use within the Structured Systems Analysis and Design Method (SSADM). Although no specific notation is mentioned in the syllabus for the BCS Data Analysis certificate, it is, I believe, the notation that the originators of that syllabus had in mind for entity relationship modelling.
CLASS MODELLING
In the late 1980s and early 1990s there were a number of disparate modelling initiatives devised to cope with the design of systems based on the object-oriented programming paradigm. In the mid-1990s three proponents of their own notations, Grady Booch, Ivar Jacobson and James Rumbaugh (known as the three amigos) came together to create the Unified Modeling Language (UML)TM. In 1997 UML was adopted as a standard by the Object Management Group (OMG),9 and in 2005 UML was also published by the International Organization for Standardization (ISO)10 as an approved ISO standard. The current version of the UML standard includes 13 diagram types, but we are only interested in one of
9 See www.omg.org/ 10 See www.iso.org/
12 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
those – the ‘class diagram’, which is used to model information and data. We will refer to the models developed using this diagramming notation as ‘class models’.
An example of a UML class model is shown in Figure 1.9. This example uses the same business scenario as that shown in Figure 1.8 using the Ellis-Barker notation.
Figure 1.9 An example of a UML class model
CUSTOMER ORDER ORDER STATUS number [1..1] 1..1 1..* 1..1 0..* number [1..1] designation [1..1] name [1..1] effective date [1..1] address [1..1] places date [1..1] describes
1..1 part of
1..* PRODUCT ORDER LINE
code [1..1] 1..1 0..* number [1..1] designation [1..1] ordered quantity [1..1] retail cost [1..1] order for
USE OF DATA MODELS IN BUSINESS ANALYSIS
Because this book is aimed at business analysts the focus will be on Computer Independent (or conceptual) Models – the models where the ‘what’, the information or data that is required, is specified. There will, however, be some consideration of the other, ‘how’, models.
The shape and form of the ‘how’ models will be determined by the database management system that is to be used to manage the database. There are many types of database man- agement systems available and that means that the business analyst should not assume any particular type of database when developing the ‘what’ model as part of requirements engineering. The job of the business analyst when modelling is to concentrate on develop- ing a model that represents the information that the business needs to be recorded; the business analyst should not be including anything in that model that depends on a specific implementation.
The example models at Figures 1.8 and 1.9 might give the impression that information or data modelling is a simple task leading to relatively simple databases. But these are just simple examples. In practice, information or data models can be very large – I have seen some models that completely cover the walls of a six-person office. Developing an information or data model is not a trivial task. Having said that, information or data modelling should be part of the ‘consultancy toolkit’ of all business analysts.
Developing an information or data model does not mean that we are just documenting in ‘boxes and lines’ what we find in the business. We need to apply the business analyst’s
13 MODELLING BUSINESS INFORMATION
enquiring mind to analyse what we find. As with all requirements elicitation, as we develop the model we are going to find that there are unanswered questions that need to be answered. Through asking questions of the business about the model we can gradually refine the model so that the end result is useful to the business, and allows the needs of the business and its systems to be met. Developing an information or data model is an iterative process that helps us to understand the information that the business needs to record. This process also helps us uncover the business rules and, more importantly, any exceptions to the rules that need to handled.
WHAT MAKES A GOOD DATA MODEL?
The simple answer to this is that a good model should express the totality of the infor- mation requirements of the business clearly, concisely and unambiguously. As with any set of requirements, all of the requirements should be included, there should be no overlapping or conflicting requirements, and no requirements should be hidden within other requirements.
When modelling the processes of the business, the business analyst will think in terms of two sets of models: the ‘as-is’ models and the ‘to-be’ models. The ‘as-is’ models are the result of pure analysis: the documentation of the current situation using boxes and lines. When developing the ‘to-be’ models the business analyst is straying from pure analysis into the field of synthesis or design, albeit using the same set of box and line constructs as for the ‘as-is’ models. The ‘as-is’ models are developed to help us come up with the ‘to-be’ models. The final form of the ‘to-be’ models (the designs) will depend very much on the experience and creativity of the business analyst who is doing the modelling.
When modelling information or data the same is true, although we do not normally produce an ‘as-is’ information or data model. The only time we would produce an ‘as- is’ model is when we are reverse-engineering an existing database or carrying out relational data analysis on existing documents, reports or input screens. Even so, the purpose of the reverse-engineering or relational data analysis is to influence a model of the information requirements to be met by a future information system (or set of information systems). Such a model is a ‘to-be’ model.
All information models that are the output of the requirements engineering process can, therefore, be considered as the start of the design process for the future information system or systems. The experience and creativity of the modeller will impact not only on the model itself but also on the design of any future database developed from the model.
We will look at the subject of data model quality in more detail in Chapter 9.
INTRODUCING DATA ANALYSIS
‘Data analysis’ is a difficult term because it has two meanings.
One meaning of the term is the analysis of an existing collection of data to find patterns, trends or hidden information. The result is some insight that will be useful to the busi- ness.
14 WHY BUSINESS ANALYSTS SHOULD MODEL INFORMATION
The other meaning is the analysis of a business domain to understand the information or data that needs to be recorded in an information system to meet business needs. The result is a data model that may lead to a database design.
While some business analysts may be involved in analysing data under the first of those meanings, especially when that data could be used in strategic decision-making or as input into a business case, it is the second meaning that is of interest to us in this book.
Business analysis helps us understand business requirements. Some of these require- ments are information (or data) requirements. Data analysis helps us understand those information requirements, probably the most important of the overall business require- ments for an information system. Data analysis is not separate from business analysis; it is an essential part of business analysis.
Like many other analysis or modelling activities, data analysis and modelling can be approached from a top-down perspective or from a bottom-up perspective.
The top-down approach involves starting with a blank sheet of paper (or, preferably, a clean whiteboard) and using an appropriate set of requirements elicitation techniques (interviews, workshops, observation, among others) to find out what information the business needs to achieve its goals. This then forms the basis of the information model, whether it is an Ellis-Barker entity relationship model or a UML class model. We will look at the development of Ellis-Barker entity relationship models and UML class mod- els in Chapters 2 to 5.
The bottom-up approach involves looking at existing ‘data sources’ – which could be existing databases, screens and reports for existing information systems or, in a paper- based system, the documents and records that are maintained – to build a model that represents the known information requirements.
Business analysts should use both approaches and then compare the results. They will seldom match. Some detail, absolutely vital to the business, may have been missed when looking at things from the top down. Some new requirements not handled by the current system will probably have been missed when looking at things from the bottom up. Almost certainly, the analyst will need to develop a model that is a composite of the top-down model and the bottom-up model.
When taking a bottom-up approach, we can use a formal technique called relational data analysis (which is also called normalisation) or we can just informally use our intui- tion. Most data modellers will use the formal technique when they start data modelling and then move to do things informally when they are more experienced. We will look at relational data analysis in Chapter 6.
15 INDEX
Page numbers in italics refer to figures or diagrams
1NF (first normal form) xix, 84, Booch, Grady 12 completeness 116, 120–1 86–9 ‘boxes within boxes’ depictions composite identifiers xviii, 73–4 2NF (second normal form) xxi, 41, 43 composite keys xviii 84, 89–90 Boyce-Codd normal form 84 composition xviii, 46–8 3NF (third normal form) xxii, 84, business activity models 8 90–4 computer-aided software business analysis engineering (CASE) xvii and data analysis 14–15 Computer-Independent Models aggregation xvii, 46–8, 136 definitions 3–5 (CIM) 10–11, 13, 19 alternate keys xvii, 94 information needs 6–7 conceptual data models xviii, artefacts xvii 154–5 role of models 7–10 ‘as-is’ models 14 constraints 40–1, 77 use of models 13 association classes xvii, 35–6 corporate models xviii, 123–6 business intelligence associations correctness 120–1 data warehouses 139–40 introduction to xvii, 19 CRUD matrix validation 59–62 dimensional modelling 141–3 identifying 53 multidimensional data models multiple 27–8 140–1 data mutually exclusive 39–41 business process models 8 big data 129–30 naming 22–3, 112–13 business rules enforcement 117 and data models 10–11 notation 22–3 business systems 4–5 definition xviii reflexive 29 and information 5–6 associative entity types 34, 38 candidate keys xvii, 95 master data 130 attribute occurrences 66–7 cardinality metadata 130 attribute types 66–7 overview xvii, 24–7 semi-structured data 129 attributes in model drawing 54–6 structured data 127–9 introduction to xvii, 66–9 problems with 32–9 types xviii, 145–51 naming 69, 110–11 CASE unstructured data 129 UML extended attribute see computer-aided software data analysis xviii, 14–15 notation 75–7 engineering (CASE) data clustering 155–6 when to model concepts as character large object data type data landscape 127–30 69–71 145 data mining xviii Checkland, Peter 7–8 data models Bachman Diagrams 11 Chen notation xvii, 104, 106 and data 10–11 Barker, Richard 11, 100 class models xviii, 12–13, 22–3 definitions xviii bibliography 159–61 class terms 111 requirements of 13–14 big data xvii, 129–30 Codd, Edgar F. 81, 84 third normal form (3NF or bill of materials structure. 36–9 columns xviii, 82, 154–5 TNF) 94 binary large object data type 145 communication 9–10, 117–18 what is a good model? 13–14
172 data navigation paths 57–9 encapsulation 136 IDEF1X notation xx, 100–4 data reusability 117 enquiry access path indexes 156 data types see data navigation paths information xx, 4–6 binary large object type 145 enterprise awareness dimension Information Engineering notation character large object type 120–1 xx, 104, 105 145 entities xix, 16–18 information needs 6–7, 9–10, datalink type 150 entity occurrences xix, 17–18 13–14 definition xviii entity relationship modelling xix, information systems 4–5 distinct type 145–6 11–12, 20–2 information technology systems 4 multiset type 148 entity subtypes xix, 41–3, 109 inheritance 136 row type 149 entity types input parameters 78 structured type 146–8 overview xix, 17–18, 65–6 integration 118 variable array type 149 or attributes? 69–72 IT systems 4 XML type 150–1 identifying 51–2 future developments 150–1 naming 18–19, 108–10 Jacobson, Ivar 12 data warehouses xviii, 139–40 subtypes xix, 41–3, 109 database design supertypes 41–3 key-value stores 138 first cut stage 154–5 enumerated data types 77 optimised design stage enumerated domains xix, 75 155–6 equivalences, table of 158 layout of models, quality of models 121–2 role of models 10–11 European Process Industry link entities 34 database management system STEP21 Technical Liaison (DBMS) xix Executive (EPISTLE) 118–20 Logical Data Model (LDM) 11, 94 databases exclusive arcs 40 lower bounds 23 chronology 131 exclusive-or constraint 40–1 definitions xix exercises mandatory relationships/ associations hierarchical 130–3 end of chapter 30–1, 48–9, 63–4, 79–80, 96 see optionality network 133, 134–5 solutions to 162–71 many-to-many associations/ NoSQL 137–8 extensible record stores 138 relationships 27, 32–7 object-oriented 136–7 see also cardinality relational (SQL) 133–6 final models 153 many-to-one relationships datalink data type 150 first cut database design stage see cardinality DBMS (database management 154–5 master data 130 system) xix first normal form (1NF or FNF) master data management xx denormalisation 156 xix, 84, 86–9 matrix organisation 38–9 derived attributes 77 flexibility 117 metadata xx, 130 described domains xix, 75 flexible design 119–20 model drawing diagrams foreign keys xix, 82, 89 process of 50–1 drawing 54–6 full attribute names 111 identifying entity types or validating 56–62 object classes 51–2 dimensional modelling 141–3 galaxy schema 143 identifying relationships or distinct data type 145–6 generalisation 43–5 associations 53 document stores 138 generic data models 114–15, drawing the initial diagram domains xix, 74–5, 110 119–20 54–6 drawing models genericity 114–16 validating the diagram 56–62 see model drawing graph databases 138 models Gregory, William 120–1 in business analysis 7, 13 elegance 117 communication through 9–10 Ellis, Harry 11, 99 hierarchic identifiers xx, 74 modifier terms 111 Ellis-Barker notation xix, 11–12, hierarchic keys xx multidimensional data models 99–100 hierarchical databases 130–3 140–1 employee supervision 38–9 multimedia data xx
173 multiple associations/ object classes product dimensions 140–1 relationships 27–8 overview xx, 17–18, 65–6 products within products 36–7 multiplicity xx, 23, 68–9 or attributes? 69–72 multiset data type 148 identifying 51–2 quality of models mutually exclusive associations/ naming 18–19, 38, 108–10 characteristics of good data relationships 39–41 Object Data Management Group models 116–18 (ODMG) xxi, 137 five dimensions of data model naming Object Definition Language (ODL) quality 120–1 associations 22–3, 112–13 137 genericity or specificity associative entity types 38 Object Query Language (OQL) 137 114–16 attributes 110–11 object subclasses xxi, 43–5, 109 layout of models 121–2 conventions 108–13 objectives, conflicting 118 principles of high quality data models 118–20 domains 110 object-orientation xx query access path entity types 108–10 object-oriented databases see data navigation paths object classes 38, 108–10 136–7 of object classes and entity objects types 18–19 behaviour of 77–8 recursive relationships 29, 109 relationships 20–2, 112 definition xx reflexive associations 29, 109 tables and columns 154–5 and entities 16–18 Reingruber, Michael 120–1 network databases 133, 134–5 in UML 77 relational (SQL) databases 133–6 non-redundancy 116 one-to-many associations/ relationships relational data analysis xxi, 14, normal form xx 15, 84 see cardinality normalisation relational data analysis process what is it? xx, 81–2 one-to-one associations/ 56 relationships relational model of data relational database management 82–4 see cardinality system (RDBMS) xxi rules of 84 online analytical processing xxi, relational model of data xxi, 141 start of process 85–6 82–4 online transactional processing relations xxi, 81, 82–4 first normal form (1NF or FNF) (OLTP) xxi 86–9 relationships operations xxi, 77–9 second normal form (2NF or overview xxi, 65–6 SNF) 89–90 optimised database design stage 155–6 identifying 53 third normal form (3NF or introduction to 19 TNF) 90–4 optionality xxi, 24–7, 54–6 multiple 27–8 third normal form data model optional-mandatory relationships 94 26, 26 mutually exclusive 39–41 relationship to modelling 95 optional–optional relationships naming 20–2, 112 27, 27 alternate, candidate and notation 20–2 primary keys 94 recursive 29 normalisation forms 86, 87–8, partial high-level process maps repeating groups 86 60 91, 93 representation terms 111 permitted values xxi, 75 NoSQL databases 137–8 requirements engineering notations Physical Data Model (PDM) 11 9–10, 9 Chen xvii, 104, 106 ‘pig’s ear’ associations/ reverse-engineering 14 relationships 29 comparison between 107 rich picture 7 Platform-Independent Model Ellis-Barker xix, 11–12, 99–100 (PIM) role names 23 IDEF1X xx, 100–4 see Logical Data Model (LDM) row data type 149 Information Engineering xx, Platform-Specific Model (PSM) Rumbaugh, James 12 104, 105 11 need for clarity 10 polymorphism 136 schema xxi, 141–3 relationships 20–2 primary keys xxi, 82, 94 second normal form (2NF or UML class model notation prime terms 111 SNF) xxi, 84, 89–90 12–13, 22–3, 75–9, 101 primitive data types 77 semantic dimension 120–1
174 semi-structured data 129 ISO/IEC 9075 (SQL) 144, 151 Unified Modeling Language (UML) simple identifiers xxii, 73 Unified Modeling Language xxii, 12–13 simple keys xxii (UML) 12–13 unique identifiers xxii, 72–4 Simsion, Graeme 116–18 star schema 141–2 un-normalised form (UNF) 86 single valued attributes 68 storage 137 unstructured data xxii, 129 SNF (second normal form) xxi, store dimensions 140–1 upper bounds 23 84, 89–90 structured data xxii, 77, 127–9, use case diagrams 9 snowflake schema 143 146–8 Soft Systems Methodology 7–8 subclasses xxi, 43–5, 109 validation xxii, 56–62 solutions to exercises 162–71 subtypes 41–3, 109 value 129 specialisation superclasses 43–5 values (attribute occurrences) in class models 43–5 supertypes 41–3 66–7 in entity relationship models surrogate identifiers xxii, 74 variability 129 41–3 syntactic dimension 120–1 variable array data type 149 specificity, quality of models systems 3–5 variety 129 114–16 velocity 129 SQL tables xxii, 82–4, 154–5 veracity 129 basics xxii, 144–5 third normal form (3NF or TNF) volume 129 implications 151–3 xxii, 84, 90–4 new data types 145–51 third normal form data model West, Matthew 118–20 94, 152 SQL (relational) databases whole–part relationships 46 133–6 time dimensions 140–1 wide-column stores 138 stability 117 ‘to-be’ models 14 Witt, Graham 116–18 standards top-down approaches 15 workshop models 151 overview 6–7 transitive dependence 92 ISO/IEC 2382-1 1993 tuples xxii, 82–4 (Information Technology XML data type 150–1 – Vocabulary – Part 1: UML class model notation 12–13, {xor} constraints 40–1 Fundamental Terms) 6–7 22–3, 75–9, 101
175
MODELLING BUSINESS INFORMATION and classEntity relationship business analysts for modelling Gordon Keith
Keith Gordon MODELLING BUSINESS INFORMATION 173535 781780 ISBN 978-1-78017-353-5 Computing; IT 9 Cover photo: iStock © nuwatphoto photo: iStock © nuwatphotoCover A terrific contribution toA terrific contribution the field. Senior Consultant, Alec Sharp, Clariteq an excellent Provides in the fullgrounding to of topics related range information modelling. Information West, Matthew Director Junction, A thoughtful, well- A thoughtful, to do on how done text high-quality business data modelling. analytical Essential Strategies Hay, David CEO International,
e e s aperback Ebook availabl P availabl Keith Gordon Keith MODELLING BUSINESS INFORMATION BUSINESS MODELLING Explains why business analysts should model information should model business analysts Explains why in and class modelling relationship both entity Covers the basics tandem from syllabus with the BCS Data Analysis Aligned wider topics to include several the syllabus Goes beyond of interest
Entity relationship and class modelling for business analysts business for modelling and class relationship Entity • • • Starting from first principles, this book will help business will this book principles, first Starting from data models to construct required the skills to develop analysts and of entity relationship explanations comprehensive through syllabus. BCS Data Analysis in line with the class modelling, also the book the topics in the syllabus, In addition to covering an including of interest information extra includes significant model information notations, of other modelling overview • be handled by the system. the system. be handled by model into database design. and taking a requirement quality, THE AUTHOR ABOUT is an independent consultant and lecturer Gordon Keith analysis. specialising in data management and business and training education in technical, 50 years He has spent over data computer consultant, as an engineer, environments manager. and training and education business analyst manager, It is almost universally accepted that requirements documents requirements accepted that universally It is almost should business analysts by systems new or enhanced IT for that has to the information to represent include a ‘data model’ You might also be interested in: might also be interested You