2. Определение требований к операционной обстановке
Для выполнения этого этапа необходимо знать (хотя бы ориентировочно) объём работы с домашней фонотекой (т.е. количество песен, исполнителей, авторов и носителей), а также иметь представление о характере и интенсивности запросов.
Объём внешней памяти, необходимый для функционирования системы, складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные (МД). Для реальных баз данных обычно наиболее существенным является МД.
На основе результатов анализа ПрО можно приблизительно оценить объём памяти, требуемой для хранения данных. Примем ориентировочно, что:
песен в домашней фонотеке примерно 1000 (по 0,1К);
музыкантов, которые написали песни или исполнили, примерно 1000 (по 0,1К);
носителей, на которые записаны песни, примерно 300 (по 0,05К).
Объём памяти для хранения данных за первый год примерно составит:
Mд = 2(1000*0,1+1000*0,1+300*0,05) = 630 К,
Коэффициент 2 необходим для того, чтобы учесть необходимость выделения памяти под дополнительные структуры. Объём памяти будет увеличиваться ежегодно на такое же количество.
Требуемый объём оперативной памяти определяется на основании анализа интенсивности запросов и объёма результирующих данных. Для нашей БД требуемый объём памяти мал, поэтому никаких специальных требований к объёму внешней и оперативной памяти компьютера не предъявляется.
3. Выбор субд и других программных средств
Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (MS Access, Firebird, MySQL и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными.
В качества СУБД я выбрала MySQL 6.0. MySQL – это одна из самых популярных и самых распространенных СУБД (система управления базами данных) в интернете. Она не предназначена для работы с большими объемами информации, но ее применение идеально для интернет сайтов, как небольших, так и достаточно крупных.
MySQL отличатся хорошей скоростью работы, надежностью, гибкостью. Работа с ней, как правило, не вызывает больших трудностей. Поддержка сервера MySQL автоматически включается в поставку PHP.
Немаловажным фактором является ее бесплатность. MySQL распространяется на условиях общей лицензии GNU (GPL, GNU Public License).
4. Логическое проектирование реляционной бд
4.1. Преобразование er–диаграммы в схему базы данных
База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей.
Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы БД). Обозначения, используемые на схеме базы данных:
Схема реляционной базы данных, полученная из ER–диаграммы:
4.2. Составление реляционных отношений
Каждое реляционное отношение соответствует одной сущности (объекту ПрО) и в него вносятся все атрибуты этой сущности. Отношения приведены в таблицах 1-5.
Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N – числовой, C – символьный тип фиксированной длины, V – символьный тип переменной длины.
Потенциальным ключом отношения ПЕСНИ являются сочетания полей Название + Исполнитель. Это занимает много мета, поэтому введем суррогатный первичный ключ.
Таблица 1. Схема отношений ПЕСНИ (SONGS)
|
Содержание поля |
Имя поля |
Тип, длина |
Примечания |
|
Код песни |
S_ID |
N(4) |
суррогатный первичный ключ |
|
Название |
S_NAME |
V(30) |
обязательное поле |
|
Год написания |
S_YEAR |
N(4) |
необязательное поле |
|
Жанр |
S_GENRE |
V(20) |
обязательное поле |
|
Битрейт, Кбит/сек |
S_BIT |
N(3) |
обязательное поле |
|
Качество звука |
S_QUALITY |
V(10) |
обязательное поле |
|
Автор |
S_WRITER |
V(30) |
внешний ключ (к MUSICIANS) |
Потенциальным ключом отношения МУЗЫКАНТЫ являются атрибуты Сценическое имя и Имя + Фамилия. Видно, что меньше места занимает первый, поэтому его выбираем в качестве первичного ключа.
Таблица 2. Схема отношения МУЗЫКАНТЫ (MUSICIANS)
|
Содержание поля |
Имя поля |
Тип, длина |
Примечания |
|
Сценическое имя (название группы) |
M_ID |
V(30) |
первичный ключ |
|
Имя, фамилия (солиста) |
M_NAME |
V(50) |
необязательное поле |
Регистрационный код в отношении НОСИТЕЛИ является уникальным для каждого носителя информации, поэтому этот атрибут выбираем в качестве первичного ключа.
Таблица 3. Схема отношения НОСИТЕЛИ (CARRIERS)
|
Содержание поля |
Имя поля |
Тип, длина |
Примечания |
|
Регистрационный код |
C_ID |
C(3) |
первичный ключ |
|
Вид |
C_TYPE |
V(10) |
необязательное поле |
|
Объем памяти, Гб |
C_MEM |
N(5,2) |
необязательное поле |
|
Емкость, час |
C_TIME |
N(7,2) |
необязательное поле |
Во вспомогательном отношении ПЕСНИ-ИСПОЛНИТЕЛИ потенциальным ключом является комбинация двух полей этого отношения.
Таблица 4. Схема отношения ПЕСНИ-ИСПОЛНИТЕЛИ (A_SINGERS)
|
Содержание поля |
Имя поля |
Тип, длина |
Примечания | |
|
Код песни |
A_SONG_ID |
N(4) |
внешний ключ (к SONGS) |
состав-ной ПК |
|
Сценическое имя |
A_MUS_ID |
V(30) |
внешний ключ (к MUSICIANS) | |
Потенциальным ключом вспомогательного отношения ПЕСНИ-НОСИТЕЛИ является комбинация двух полей этого отношения.
Таблица 5. Схема отношения ПЕСНИ-НОСИТЕЛИ (B_SONG_CAR)
|
Содержание поля |
Имя поля |
Тип, длина |
Примечания | |
|
Код песни |
B_SONG_ID |
N(4) |
внешний ключ (к SONGS) |
состав-ной ПК |
|
Код носителя |
B_CAR_ID |
N(3) |
внешний ключ (к CARRIERS), по умолчанию - 0 | |