When you installed SQL Server, you also installed several databases by default. Although some of them are more important than others, they all serve some function and can assist you as you move through your own projects. Some of them —and this is critical— absolutely should not be altered; otherwise, you run the risk of doing serious damage to your SQL Server installation and the data stored within your individual databases! That said, the following sections will take you through each of these installed databases so you will know what each one does (and so you will know which ones not to mess with).

1. If it’s not already running, start the SQL Server Enterprise Manager.
2. Expand the Databases node.
3. Although you’ll learn about the individual database components a bit later in this chapter, go ahead and expand one of the individual database nodes so you can see how the components are presented.

 Now that you have the default databases accessible and on your screen, take a closer look at each one.

• Master. The master database is the keeper of a great deal of administrative and functional control information for your entire SQL Server. That said, there is very little reason for you to change the values contained therein. (As a matter of fact, you probably shouldn’t touch this database unless you have a very good reason.) Important administrative functionality, such as storing all user login IDs; specific system configuration settings; names, information, and the location of each database contained within the server; and the initialization configurations of SQL Server, is kept within the master database. So again, unless you’ve got a good reason… leave it alone.
• Tempdb. The tempdb database houses temporary information (not surprising, given its name) for not only the queries you execute, but for SQL Server itself, because various transactions and processes are executed within the application. You can use the tempdb database to temporarily store information for your procedures. This is fine as long as you remember that as soon as the database refreshes itself, the data stored within tempdb will be lost. I’ll talk more about tempdb later in this chapter and in other chapters. For now, though, recognize its general functionality and usefulness as a temporary data storage location. It is also used extensively with SQL Server’s Data Transformation Services.
• Model. The model database is useful because you can indeed "model" your databases (and the specific components within them) so that they all share a uniform structure. For example, if you wanted every database on your SQL Server to contain a specific table, you could include this information with the model database. Note, however, that this only works for new databases that are created.
• Northwind. If you’ve worked with Microsoft Access, you are undoubtedly familiar with the Northwind sample database. (You already accessed it to run some of the query examples in the third project, when you worked with the Database Results Wizard, a feature of FrontPage.) Although you can manipulate or alter the Northwind database to your heart’s content, it’s probably a good idea to leave it alone so you have a reference database to fall back on in case you run into trouble in other areas of SQL Server, or you need to test a query or procedure on a predefined set of data (the information contained with the Northwind database) as opposed to your actual live data.
• Pubs. Another sample database, the pubs database is based on a fictitious publishing company. Like the Northwind sample database, you can alter this any way you want, but it might be useful to leave it fairly unchanged so you can use it as a data reference.
• Msdb. Like the master database, you probably should not alter the msdb database. Used to control the functioning of various processes within SQL Server, any change in this database could have adverse results on other critical function areas of your server.