2.2. The Design of the SMDP Database

The SMDP database is designed to allow for a very dynamic set of information relating to mp3 and ogg files. The basic structure covers the usual entities in a traditional relational model. This is then complemented by a set of tables essentially composing a directory-like storage structure, geared toward both specific attribute classes as well as a completely "free" relations table - ie where the type of the objects are specified on both sides of the relation.

This provides, in addition to the usual information such as artist name, song title, album name and so on, for space to define unique information as well as to establish relationships betewwen any two objects in the database.

Anyways, enough of the hot air...read on for more information.

2.2.1. Database Structure

There are two schemas available for the SMDP database, the core database and the core database with the optional extension.

The schemas break down as follows:

The core schema is meant to be used in situations where the user does not want or care for the extra information available in the optional schema.

2.2.1.1. The Core Schema

The core schema holds all the information that is considered essential to a functional mp3/ogg database. This basically means, all information that can be represented with Id3 tags or Ogg comments minus lyrics information and binary data. [note: binary data can still be refrenced with the core schema, however the actual data will remain in the respective mp3 or ogg file]

Figure 2-1. Core ERD

ERD of the core SMDP Database

2.2.1.2. The Optional Schema

The optional schema adds a few more features to the database that allow for a slightly more full-featured set of data. With the optional schema you can store MusicBrainz and FreeDB data, as well as Lyrics information and binary data.

Figure 2-2. Optional ERD

ERD of the optional SMDP Database

2.2.2. The Feature Tables

For each of the main objects in the database, there exists a companion 'feature' table. The 'feature' tables serves to further describe the records in the object table.

See Appendix B for information on translating Id3 tags and Ogg comments into SMDP records.