As a simplified version of the online image management
system, it does not involve too much data; including categories associated with
the image data, as well as the specific image file related attribute data.
Based on the two kinds of data, we merely need to design two proper tables, and
to determine the relationship between them.
Table Structure
First, we are to list the structures of the two tables--Category and Photo and interpretation
of the relevant fields in table forms.
Table 1. Structure for table Category.
Field name
|
Type
|
Notes
|
ID
|
int
|
Primary Key
|
Name
|
varchar(50)
|
The photo category name
|
Status
|
varchar(50)
|
The status of an image category, and used to indicate whether
this type of image files are public or not. Note, however, we do not use this
field much. I.e., we've just used it in general record operations (such as
edit, insert, delete, etc.).
|
Table 2. Structure for table Photo.
Field name
|
Type
|
Notes
|
ID
|
int
|
Primary Key
|
Title
|
varchar(50)
|
The title to show in the photo album (usually refers to
the name)
|
Url
|
varchar(255)
|
The complete path of the image file
|
CreateDate
|
datetime
|
The date time to upload the file
|
Type
|
varchar(50)
|
Specify the type of the file
|
Size
|
int
|
The size of the image file (bytes)
|
CategoryID
|
int
|
Foreign key (relating to field ID of table Category)
|
Next, let's take a look at the relationships between the
above two tables.
Table Relationship
Figure 7 gives the relationships between the above two
tables Category and Photo.
It is clear that between the two is a one-to-many relationship. The snapshot here
is derived from the entity data model document PhotoAlbumModel.edmx. Note that,
following the end of each of the two entities has a corresponding navigation attribute.
Although the navigation attribute is a unique concept provided by ADO.NET data
services, which allows using ADO.NET data services to handling master-detail
tables and their association relationships, which seems quite different from other
forms of data access solutions, but, in fact, it quite resemble the operations
with master-detail tables provided by them. Fore further discussion of the
navigation attributes, please refer to MSDN, combined with the later modules.
Figure 7-- the one-to-many relationship between
table Category and Photo.

As the above image indicates, in the later on module design,
we must bear in mind one thing: No matter what kind of data manipulation, we
must ensure the association relationship established here is correct to ensure
the consistency and effectiveness of cited data.