Share this Page URL

Chapter 2. The Basics of Database Design > Planning and Designing the HelloWorl... - Pg. 45

The Basics of Database Design 45 · What sort of security will your database require? For example, will all users have access to the data in every table? Will one group of users need read-only permissions and another read-write permissions? For more information about securing an Access database, see Chapter 19, "Im- plementing Security." Splitting a Database: Using One Database File or More A requirements gathering phase might reveal strong distinctions between how different groups of users will work with a database. For example, some users might be solely responsible for entering data. They'll use only the forms that you design for this purpose; they won't use queries or run reports. Another group of users might not be involved in entering data but will need to retrieve records from the database to analyze them and make decisions based on the data they contain. Creating a form-based prototype Some people understand concepts more clearly when the ideas are presented visually. Designing a form with proposed fields can be a good way to start discussions about what data you need to collect and how that data needs to be presented and analyzed. If you or another person designing a database are familiar with designing forms (or after you read through the chapters in this book that explain how to create forms), you might consider creating a group of forms to use as a prototype for your database. Create the forms using a preliminary set of fields, and then show these forms to the people you're talking to about the database's requirements. After you've used the prototype forms to gather requirements about fields and the relationships between data, you can plan the tables those fields belong to. In our case, the HelloWorld database will be used by people in various countries over a network. (Fictionally, of course we won't create a network in this book.) Under these conditions, the perform- ance of a database will be improved and the database will be easier to maintain if you split the database, storing the tables in one Access file (and storing this file at a network location that all users can get to) and storing forms, reports, queries, and other database objects in another file, linked to the first, that is stored on workstation computers. Splitting a database creates a front end (the file with the forms and reports) and a back end (the file with the data tables). The front-end/back-end structure provides more flexibility. It lets you update the user interface for a database (the front end) without putting the tables temporarily out of com- mission. Access databases designed to be used by more than one person definitely benefit from this approach. You can store the .mdb file with your tables on a network server and the front-end file on individual workstations. Having a separate file for your tables is also helpful if you need to look at information from your database over the Web. You can use data access pages, another standard database object in Access, to connect to data over the Web or over a company intranet. You'll learn about data access pages in Chapter 12, "Access and the Web." Finally, using a front-end/back-end database might involve a database project that's built from Microsoft SQL Server. Access projects, which use the .adp file extension, let you build tables, forms, and other objects that will be used with a database stored on a computer running SQL Server. You'll learn about Access projects in Chapter 14, "Un- derstanding Access Projects." Quick Check Q. What are two of the reasons to plan a database before you start building it? A. You'll develop a more efficient set of tables, and you'll know more about what the users of your database expect. Q. What is the purpose of reviewing printed forms and reports you currently use when designing a database? A. These documents often serve as a source for the forms and reports you create in Access.