Appendix C
Field |
Data Type |
Allow Nulls |
|
|
|
GoalID (Primary Key) |
int |
No |
FixtureID (Foreign Key) |
int |
Yes |
PlayerID (Foreign Key) |
int |
Yes |
Time |
int |
Yes |
Notice that one of the fields in this table is the PlayerID field, which will store an integer value corresponding to the ID of one of the players in the Players table, so if Dave Dickenson scored the first goal for Wrox United, the goal in the table with GoalID of 1 will have a PlayerID of 4. Dave could later score another goal for Wrox United, so another record in the Goal table would be created with another unique value for GoalID, but with the same PlayerID. This type of field is called a foreign key because it relates directly to a primary key in another table.
There is another field in the Goals table for storing ID values, which is the FixtureID field. This links each goal to a particular fixture. Because players could score many goals at a single fixture, the relationship between the Fixtures table and the Goals table is similar to that of the Players table and the Goals table.
This sort of relationship — where one fixture can contain many goals, or where one player could score many goals — is known as a one-to-many relationship.
The Fixtures Table
The Fixtures table is structured as shown here.
Field |
Data Type |
Allow Nulls |
|
|
|
FixtureID (Primary Key) |
int |
No |
FixtureDate |
datetime |
No |
FixtureType |
varchar(10) |
Yes |
GoalsFor |
smallint |
Yes |
GoalsAgainst |
smallint |
Yes |
Notes |
text |
Yes |
Opponents |
varchar(50) |
No |
|
|
|
For each match played by the Wrox United team, there is an entry in the Fixtures table. Because fixtures can be arranged several months in advance, the fixture date has to be entered as soon as the fixture is arranged, and the opponents have to be entered. The number of goals scored can be entered later, after the match has been played.
Wrox United Database Design
The MatchReports Table
After each match has taken place, it’s up to the reporters to write up the details of the match so that fans can read all about it later. These reports are stored in the MatchReports table, which is structured like as shown here.
Field |
Data Type |
Allow Nulls |
|
|
|
ReportID (Primary Key) |
int |
No |
FixtureID (Foreign Key) |
int |
No |
Report |
text |
Yes |
MemberName |
varchar(50) |
No |
This table also links to the Fixtures table by including a FixtureID field in this table, linking a match report to a specific fixture. The MemberName field stores the name of the reporter.
The Gallery Table
The Gallery table is used to store details of pictures uploaded by fan club members. The fields defined in this table are shown here.
Field |
Data Type |
Allow Nulls |
|
|
|
PictureID (Primary Key) |
int |
No |
FixtureID (Foreign Key) |
int |
Yes |
UploadedByMemberName |
varchar(50) |
Yes |
Notes |
text |
Yes |
PictureURL |
varchar(50) |
No |
|
|
|
Each picture can relate to a specific fixture (notice the FixtureID field); however, because this field allows the use of null values, this implies that pictures do not necessarily have to relate to fixtures.
Standalone Tables
The two standalone tables in the database are the Opponents table and the News table.
The Opponents Table
The Opponents table stands on its own in the database, and is defined as shown here. |
|
The reason the Opponents table is on its own is a bit unfortunate, but the opposing team may decide to |
|
change its name at some point in the future, which would change the name of all fixtures that Wrox |
|
United played against them in the past if they were related. By keeping the tables separate, and only |
|
using a name for each team, the name of the opponent in any particular match is preserved. |
669 |
|
Appendix C
Field |
Data Type |
Allow Nulls |
|
|
|
OpponentID (Primary Key) |
int |
No |
Name |
varchar(50) |
Yes |
Won |
int |
Yes |
Drawn |
int |
Yes |
Lost |
int |
Yes |
Points |
int |
Yes |
TotalGoalsFor |
int |
Yes |
TotalGoalsAgainst |
int |
Yes |
This table can be updated with results of matches to maintain a tally of how well the Wrox United team is performing in the league.
The News Table
The News table, described here, contains all of the news stories from the front page of the Wrox United site.
Field |
Data Type |
Allow Nulls |
|
|
|
NewsID (Primary Key) |
Int |
No |
DateToShow |
datetime |
No |
Description |
text |
Yes |
PictureURL |
varchar(50) |
Yes |
Category |
varchar(50) |
Yes |
Title |
varchar(50) |
Yes |
|
|
|
Notice that each news item requires that a date be entered for each story, so that a story can remain hidden until a certain date has passed.
Wrox United Store Tables
The online shopping experience on the Wrox United site relies on data stored in three tables: the Orders table, the Products table, and the OrderLines table. These tables are heavily reliant on each other.
The Orders Table
The Orders table, described here, contains a unique ID containing the main order details for an order.
|
|
|
Wrox United Database Design |
|
|
|
|
|
Field |
Data Type |
Allow Nulls |
|
|
|
|
|
OrderID (Primary Key) |
Int |
No |
|
OrderDate |
datetime |
No |
|
OrderSentDate |
datetime |
Yes |
|
MemberName |
varchar(50) |
No |
|
Name |
varchar(50) |
No |
|
Address |
varchar(255) |
No |
|
County |
varchar(50) |
No |
|
PostCode |
varchar(15) |
No |
|
Country |
nchar(10) |
No |
|
SubTotal |
money |
Yes |
|
Discount |
money |
Yes |
|
Total |
money |
Yes |
In this table, you’ll notice that most of the fields are marked as mandatory (not allowing null values). This highlights the fact that orders must have full address details before an order can be fulfilled. A couple of less familiar field types are in here too. The nchar data type will always take up 10 characters space in the database, and the n in the name indicates that the data stored could contain Unicode characters. The other unfamiliar data type is money, which (as the name implies) can be used to store monetary values.
Notice that there are no details in this table about which products have been bought in a particular order. This information is stored in the OrderLines table.
The OrderLines Table
The OrderLines table, described here, links the Products table to the Orders table, indicating which items have been bought in a particular order.
Field |
Data Type |
Allow Nulls |
|
|
|
OrderLineID (Primary Key) |
int |
No |
OrderID (Foreign Key) |
int |
No |
ProductID (Foreign Key) |
int |
No |
Quantity |
smallint |
No |
Price |
money |
No |
|
|
|
Appendix C
Because an order can contain one or many products, there is a foreign key link here to the Products table. However, because many different orders can be for the same product, there is also a foreign key link here to the Orders table. This means that an individual line in this table stores details of one item, and one order number. If you order more than one of a specific product, the Quantity is increased for the order line, but you won’t end up with a new OrderLineID.
The relationship between the Orders table and the Products table is a many-to-many relationship. In this situation, there has to be a central table that has one-to-many relationships to both tables, and this is called the Join table.
The Products Table
The Products table, described here, contains details of all of the products that can be bought from the shop.
Field |
Data Type |
Allow Nulls |
|
|
|
ProductID (Primary Key) |
int |
No |
Name |
varchar(50) |
No |
Description |
varchar(255) |
Yes |
Price |
money |
No |
PictureURL |
varchar(255) |
Yes |
|
|
|
This simple table provides data about products, and is used both when users are browsing the shop and when they’re buying items from the shop.
D
VWD Database Explorer
When you’re designing pages that work with data, you frequently need to check the metadata, for example, to confirm the data type of a field. You also want to test your pages by quickly modifying the data in tables. Furthermore, in some cases, you want to add a small and simple table to a database, such as a list of shippers. In the past, these database tasks required that you leave your web editor to open a second window with a database management tool. Visual Web Developer offers a built-in tool named the Database Explorer that can perform these tasks without the need for a separate management tool. Some functions are performed directly and others invoke a wizard to step you through the task.
This appendix covers the various techniques for working with the Database Explorer.
Opening the Database Explorer
You can view the Database Explorer either by choosing Menu View or by pressing Ctrl+Alt+S. After it is open, the Database Explorer by default stacks on top of the Solution Explorer on the right side of the screen. You can move it to a new dock location by dragging its title bar.
If you mess up the layout, you can return to the default by choosing
Menu Windows Reset Windows Layout.
Adding an Existing Database to the Database Explorer
The technique to connect the Database Explorer to a database depends on the type of database. The following three sections cover the Microsoft databases. Most other databases (such as Oracle or MySQL) will be the same as connecting to a SQL Server.
Appendix D
Accessing Files
Follow these steps:
1.On the Database Explorer toolbar, click Connect to Database, and from the first page of the wizard, select Microsoft Access Database File, as shown in Figure D-1.
Figure D-1
2.Browse to the file, and then add logon information if needed (see Figure D-2).
Figure D-2
3.You have the option to test the connection and then it is added to your list in the Database Explorer.
VWD Database Explorer
SQL Databases on a SQL Server (Including SQL Server Express)
Follow these steps:
1.On the Database Explorer toolbar, click Connect to Database, and in the first page of the wizard (shown in Figure D-3), select Microsoft SQL Server.
Figure D-3
In the next dialog box, the Data Source section is locked — it actually means the kind of data source, not the name of the database.
2.Continuing on the Add Connection screen, for the Server Name text box, there are two options. If you are using a full install of SQL Server, select the server name. If you are using SQL Server Express (as we do in this book), type the following syntax exactly: (local)\SQLExpress, as shown in Figure D-4.
Figure D-4
Appendix D
Note the potential confusion when using SQL Server Express. Your PC name will be listed in the drop-down box of servers, but that is not the server you want to specify. You must type into the server name box the specific syntax to point to your local machine’s instance of SQL Server Express.
3.Keep the choice for logon information set to Windows (see Figure D-5) unless you have developed an authentication table in SQL Server.
Figure D-5
4.After you have selected the server name, you can drop down the list of databases. Test the connection and then click Finish to see your new data connection.
Saving SQL Databases as an MDF File
For highest performance, data is kept in SQL Server without an external file structure. But for portability, a database can be configured to save its data in a Windows file that can be copied to a new server. The file will have an extension of .mdf. We use an .mdf file to distribute data in this book. (The alternative would be to have you download a long SQL script that would build the entire database internally in your server and populate its data.) Connecting to an .mdf file is very similar to connecting to Access Files. Just follow these steps:
1.On the Database Explorer toolbar, click Connect to Database, and select Microsoft SQL Server Database File, as shown in Figure D-6.
Figure D-6
2.Browse to the file and add logon information if needed (see Figure D-7).
3.You have the option to test the connection and then it is added to your list in the Database Explorer.
VWD Database Explorer
Figure D-7
Viewing Database Diagrams
The VWD Database Explorer provides a visual presentation of your database’s objects along with the capability to drill down into each object’s properties. Follow these steps to walk through a diagram of your database:
1.Within the Database Explorer, expand your Data Connections and then expand your database. When you expand the Database Diagrams (see Figure D-8) the first time, you may be asked to establish yourself as the dbo (database owner). Click Yes. Right-click the Database Diagram object and add a new diagram. If asked, accept the creation of elements needed to build the diagram.
Figure D-8