Размещено на http://www.allbest.ru/

1. Описание предметной области «домашний архив»

1.1 Описание предметной области

Вкратце рассмотрим схему работы домашнего архива.

При появлении нового экземпляра в домашнем архиве пользователь заполняет следующие поля.

Если этот экземпляр книга:

· название;

· год выхода;

· количество страниц;

· жанр;

· страна;

· фамилия и имя писателя / писателей;

· постоянное место расположения книги в квартире.

Музыкальный альбом:

· название;

· год выхода;

· количество треков в альбоме;

· жанр;

· страна;

· псевдоним (или имя) исполнителя;

· постоянное место расположения музыкального диска в квартире.

Фильм:

· название;

· год выхода;

· продолжительность;

· жанр;

· страна;

· фамилия и имя режиссера / режиссеров;

· фамилии и имена актеров / актера;

· постоянное место расположения диска с фильмом в квартире.

По мере одалживания у пользователя книг, фильмов и музыки, пользователь вводит данные об одалживаемом объекте и о человеке, который одолжил тот или иной объект. По мере возвращения пользователь снова обновляет соответствующую таблицу, путем установки переключателя в противоположное положение.

В разрабатываемом приложении должна быть возможность добавления, редактирования и удаления объектов домашнего архива из БД. Также должны быть предусмотрены отчеты фильмов, музыки и книг по году выхода, жанрам и одалживанию.

1.2 Основные понятия

Сущность - личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области.

Атрибут - это информационное отображение свойств объекта. При реализации информационной модели на каком-либо носителе информации, атрибут часто называют элементом данных, полем данных или просто полем.

Экземпляр объекта - это один набор значений его элементов данных.

Доменом - набор записей данных одного типа, отвечающих поставленным условиям.

Связь - это функциональная зависимость между сущностями.

Концептуальная модель - интегрированные концептуальные требования всех пользователей к базе данных данной предметной области.

Концептуальная схема - это графическое представление данных на концептуальном уровне.

Отношение - двумерная таблица, содержащая некоторые данные (например, отношение Клиент (таблица)).

Схема отношения - список имен атрибутов (например, Товары (КодТовара, КодКатегории, МаркаТовара, Цена, Количество)).

Первичный ключ (ключ отношения, ключевой атрибут) - атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении Товары (КодТовара, КодКатегории, МаркаТовара, Цена, Количество) ключевым является атри-бут «КодТовара». Кроме того, ключ может быть составным (сложным), т.е. состоять из нескольких атрибутов.

Также существует понятие внешнего ключа. С помощью внешних ключей устанавливаются связи между отношениями. Например, имеются два отношения Товары (КодТовара, КодКатегории, МаркаТовара, Цена, Количество) и Заказы (КодЗаказа, КодСотрудника, КодКлиента, ДатаЗаказа, ВидДоставки, СтоимостьДоставки), которые связаны отношением, Заказано (КодЗаказа, КодТовара, Цена, Количество, Скидка, Продано, Продал/ПринялСотр). В связующем отношении Заказано атрибуты КодЗаказа и КодТовара образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений.

В концептуальной схеме для указания связей таблиц производят операцию их связывания.

· 1:1;

· 1:М;

· М:1;

· М:М;

· n - арная.

Причем каждая сторона связи имеет характеристику обязательности, т.е. связь может быть частичной или всюду определенной. Связь всюду определенная, если она имеет место для всех экземпляров сущности. В противном случае связь частичная.

1.3 Цель проектирования, определение пользователя

Основная цель проектирования БД - создание системы для учета, сортировки и поиска, фильмов, музыки и книг в домашнем архиве.

Пользователями создаваемой БД будут владельцы домашнего архива.

1.4 Постановка задач и запросов, реализуемых в курсовой работе

Задачи

· сведения об имеющихся книгах;

· сведения об имеющихся музыкальных альбомах;

· сведения об имеющихся фильмах;

· сведения о писателях, исполнителях, актерах и режиссерах;

· сведения об одалживании книг, музыки и фильмов;

· возможность просмотра, редактирования, добавления и удаления данных.

Запросы

· список всех книг (включая информацию о годе выхода, количестве страниц, жанре, стране, имени и фамилии писателя, постоянном расположении книги в квартире);

· список всех музыкальных альбомов (включая информацию о годе выхода, количестве треков, жанре, стране, псевдониме исполнителя, постоянном расположении музыкального диска в квартире);

· список всех фильмов (включая информацию о годе выхода, продолжительности, жанре, стране, именах и фамилиях актеров и режиссеров, постоянном расположении диска с фильмом в квартире);

· список одалживаемых книг, фильмов и музыки (включая информацию об одалживающей персоне - фамилия, имя, отчество, адрес и контактный телефон).

2. Концептуальный уровень проектирования базы «домашний архив»

2.1 Описание сущностей и их атрибутов

Фильм

Данная сущность содержит информацию о фильме и имеет следующие атрибуты:

· код фильма;

· название фильма;

· год выхода;

· продолжительность;

· код жанра;

· код страны;

· постоянное расположение.

Книга

Данная сущность содержит информацию о книге и имеет следующие атрибуты:

· код книги;

· название книги;

· год выхода;

· количество страниц;

· код жанра;

· код страны;

· постоянное расположение.

Альбом

Данная сущность содержит информацию об альбоме и имеет следующие атрибуты:

· код альбома;

· название альбома;

· год выхода;

· количество треков;

· код жанра;

· код страны;

· постоянное расположение.

Жанр альбома

Данная сущность содержит информацию о жанре альбома и имеет следующие атрибуты:

· код жанра;

· название жанра.

Жанр книги

Данная сущность содержит информацию о жанре книги и имеет следующие атрибуты:

· код жанра;

· название жанра.

Жанр фильма

Данная сущность содержит информацию о жанре фильма и имеет следующие атрибуты:

· код жанра;

· название жанра.

Исполнитель

Данная сущность содержит информацию об исполнителе и имеет следующие атрибуты:

· код исполнителя;

· псевдоним.

Писатель

Данная сущность содержит информацию о писателе и имеет следующие атрибуты:

· код писателя;

· фамилия;

· имя.

Актер

Данная сущность содержит информацию об актере и имеет следующие атрибуты:

· код актера;

· фамилия;

· имя.

Режиссер

Данная сущность содержит информацию о режиссере и имеет следующие атрибуты:

· код режиссера;

· фамилия;

· имя.

Страна

Данная сущность содержит информацию о стране и имеет следующие атрибуты:

· код страны;

· название страны.

Персона

Данная сущность содержит информацию о персоне и имеет следующие атрибуты:

· код персоны;

· фамилия;

· имя;

· отчество;

· адрес;

· телефон.

2.2 Описание связей

Сущности, их ключи и связи между сущностями изображены на концептуальной схеме базы данных (рис. 2.1).

Концептуальная модель данных отражает самые общие представления о предметной области.

Рис. 2.1. Концептуальная схема БД

3. Логический уровень проектирования «домашний архив»

3.1 Определение реляционной модели данных, ее основные элементы

Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени (т.е. РМД - представление данных в виде совокупности двумерных таблиц). При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.

Элементами реляционной модели данных являются:

· отношение (таблица);

· схема отношений (строка заголовков столбцов таблицы);

· кортеж (строка таблицы);

· сущность (описание свойств объекта);

· атрибут (заголовок столбца таблицы);

· домен (множество допустимых значений атрибута);

· значение атрибута (значение поля в записи);

· первичный ключ (один или несколько атрибутов);

· тип данных (тип значений элементов таблицы).

3.2 Проектирование реляционной модели

Существует 2 метода построения реляционной модели:

· метод декомпозиции (используется при числе ключевых атрибутов не более 20);

· диаграммы сущность-связь (универсальный).

Для начала будем реализовывать классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.

Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером набора ограничений является ограничение первой нормальной формы - значения всех атрибутов отношения атомарные. Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию.

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшей работы нам потребуются несколько определений.

Определение 1. Функциональная зависимость

В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.

Определение 2. Полная функциональная зависимость

Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Определение 3. Транзитивная функциональная зависимость

Функциональная зависимость R.X (r) R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X (r) R.Z и R.Z (r) R.Y и отсутствует функциональная зависимость R.Z > R.X. (При отсутствии последнего требования мы имели бы «неинтересные» транзитивные зависимости в любом отношении, обладающем несколькими ключами.).

Определение 4. Неключевой атрибут

Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).

Определение 5. Взаимно независимые атрибуты

Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

Рассмотрим следующий пример схемы отношений:

Определение 6. Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)

Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.

Таким образом, мы получили вторую нормальную форму.

Определение 7. Третья нормальная форма (снова определение дается в предположении существования единственного ключа).

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Теперь ознакомимся с сущностями-таблицами поближе. Выше по тексту, Вы можете видеть описание отношений и некоторые характеристики соответствующим атрибутам. Теперь дадим некоторые пояснения. Для краткости описания выше изложенного материала мы ввели некоторые обозначения. Атрибуты сущностей характеризуются тремя параметрами: ключевой атрибут или нет, обязательность поля и метод получения. Ключевой атрибут обозначен подчеркиванием имени этого атрибута. Обязательность поля обозначена в скобках (0 - необязательно, 1 - обязательно). Метод получения указан в скобках, через запятую после критерия обязательности (1 - путем ввода, 0 - выбор из предоставленного списка).

Определение 8. Четвертая нормальная форма

Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A (r) (r) B все остальные атрибуты R функционально зависят от A.

Переход от концептуальной модели к реляционной

1. Реализация связи 1:М (один-ко-многим)

Альбом (код альбома, название альбома, год выхода, количество треков, код жанра, код страны, постоянное расположение).

ЖанрАльбома (код жанра, название жанра).

Правило: в этом случае строится по одному отношению для каждой сущности. Ключ односвязной сущности добавляется в качестве внешнего ключа в другое отношение.

2. Реализация связи М:М (многие-ко-многим)

Книга (код книги, название книги, год выхода,; количество страниц, код жанра, код страны, постоянное расположение).

Книга-Писатель (код книги, код писателя).

Писатель (код писателя, фамилия, имя).

Правило: не зависимо от обязательности связи строятся 3 отношения. Ключ отношения для связи состоит из ключей обеих сущностей.

Далее приступим к непосредственному описанию определенных выше элементов реляционной модели и заданию множества их значений:

АЛЬБОМ (код альбома, название альбома, год выхода, количество треков, код жанра, код страны, постоянное расположение).

Описание ключа:

(x, y АЛЬБОМ) [код альбома (x) = [код альбома (y)] x = y,

где x, y - цепочка символов следующих друг за другом;

Dom (код альбома) = {x | 0 < x};

Dom (название альбома) = {x | STR(x)}, где STR - предикат, проверяющий является ли цепочка символов следующих друг за другом x строкой символов;

Dom (год выхода) = {x | 1900 < x};

Dom (количество треков) = {x | 0 < x};

Dom (код жанра) = {x | 0 < x};

Dom (код страны) = {x | 0 < x};

Dom (постоянное расположение) = {x | STR(x)}, где STR - предикат, проверяющий является ли цепочка символов следующих друг за другом x строкой символов;

ПИСАТЕЛЬ (код писателя, фамилия, имя).

Описание ключа:

(x, y ПИСАТЕЛЬ) [код писателя (x) = [код писателя (y)] x = y,

где x, y - цепочка символов следующих друг за другом;

Dom (код писателя) = {x | 0 < x};

Dom(фамилия) = {x | STR(x)}, где STR - предикат, проверяющий является ли цепочка символов следующих друг за другом x строкой символов;

Dom(имя) = {x | STR(x)}, где STR - предикат, проверяющий является ли цепочка символов следующих друг за другом x строкой символов;

ЖАНР (код жанра, название жанра).

Описание ключа:

(x, y ЖАНР) [код жанра (x) = [код жанра (y)] x = y,

где x, y - цепочка символов следующих друг за другом;

Dom (код жанра) = {x | 0 < x};

Dom (название жанра) = {x | STR(x)}, где STR - предикат, проверяющий является ли цепочка символов следующих друг за другом x строкой символов.

3.3 Целостность реляционной модели

Под целостностью понимают свойство БД, означающее, что она содержит полную непротиворечивую информацию, которая адекватно отражает предметную область.

Существует «целостность по ссылкам», анализ содержимого двух таблиц на соблюдение следующих правил:

· каждой записи основной таблицы соответствует ноль или более записей дочерней таблицы;

· в дочерней таблице нет записей, которые не имеют родительских записей в родительской таблице;

· каждая запись дочерней таблицы имеет только одну родительскую запись основной таблицы.

Другими словами, внешний ключ должен быть равным какому-либо значению первичного ключа или может быть полностью неопределенным.

Над данными двух таблиц существуют три основные операции:

· ввод новых записей;

· модификация записей (каскадное обновление связанных полей);

· удаление записей (каскадное удаление связанных полей).

Под каскадным обновлением всех связанных полей понимается то, что при изменении связанного поля родительской таблицы мгновенно меняются все связанные поля дочерней таблицы.

Под каскадным удалением связанных полей понимается то, что удаление записи из родительской таблицы ведет к удалению всех подчиненных записей.

Так же существует понятие «целостность по сущностям». Оно основано на понятии первичного ключа. Не допускается, чтобы первичный ключ базового отношения (или, если ключ составной, какой-либо атрибут первичного ключа) принимал неопределенные значения.

(«x АЛЬБОМ) ((y ЖАНР АЛЬБОМА) (Код жанра (x) = Код жанра (у))),

где x - кортеж отношения АЛЬБОМ, а y - кортеж отношения ЖАНР АЛЬБОМА;

(«x ФИЛЬМ) ((y ЖАНР ФИЛЬМА) (Код жанра (x) = Код жанра (у))),

где x - кортеж отношения ФИЛЬМ, а y - кортеж отношения ЖАНР ФИЛЬМА;

(«x КНИГА) ((y ЖАНР КНИГИ) (Код жанра (x) = Код жанра (у))),

где x - кортеж отношения КНИГА, а y - кортеж отношения ЖАНР КНИГИ.

3.4 Индексы

Наличие в таблице первичного ключа означает автоматическую сортировку записей, контроль отсутствия повторений значений в ключевых полях записей и повышение скорости выполнения операций поиска в таблице - все эти функции в СУБД реализованы с помощью индексирования. При задании ключевого поля, СУБД автоматически создает индекс. /3/

Использование индексов - одно из лучших средств ускорения доступа к данным, так как индексы служат для задания нужного порядка вывода данных и ускорения выборки данных. При отсутствии индексов поиск ведется путем последовательного просмотра строк. Индексы позволяют избежать физической сортировки строк таблиц.

Индексы необходимы для внешних ключей, так как ускоряется работа со связанными таблицами и ускоряется обработка правил ссылочной целостности. Также индексированными будут все первичные ключи.

4. Обоснование выбора СУБД и технических средств

4.1 СУБД Microsoft Access 2002

Microsoft Access - это самая популярная сегодня настольная система управления базами данных. Корень успеха, скорее всего, заключается в прекрасной реализации продукта, рассчитанного как на начинающего, так и квалифицированного пользователя.

Несмотря на свою ориентированность на конечного пользователя, в Access присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, с помощью OLE Automation контролировать работу приложений, которые могут функционировать как OLE-серверы.

Главное качество Access, которое привлекает к нему многих пользователей, - тесная интеграция с Microsoft Office. К примеру, скопировав в буфер графический образ таблицы, открыв Microsoft Word и применив вставку из буфера, мы тут же получим в документе готовую таблицу с данными из БД.

Вся работа с базой данных осуществляется через окно контейнера базы данных. Отсюда осуществляется доступ ко всем объектам, а именно: таблицам, запросам, формам, отчетам, макросам, модулям.

Встроенный SQL позволяет максимально гибко работать с данными и значительно ускоряет доступ к внешним данным.

Пользователям, малознакомым с понятиями реляционных баз данных, Access дает возможность разделять свои сложные по структуре таблицы на несколько, связанных по ключевым полям.

В отличие от других рассматриваемых средств разработки, СУБД Access имеет русифицированный интерфейс и переведенный на русский язык файл контекстной помощи. Причина этого факта заключена в позиционировании этой СУБД на конечного пользователя. /4/

4.2 СУБД MySQL

MySQL (произносится «Май Эс Кью Эль») - свободная система управления базами данных (СУБД). MySQL является собственностью компании MySQL AB, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

MySQL характеризуется большой скоростью, устойчивостью и лёгкостью в использовании, является решением для малых и средних приложений. Наряду с Oracle Database это одна из самых быстрых СУБД на сегодняшний день. Входит в LAMP. Распространение СУБД MySQL на основе GPL и высокая скорость обработки запросов привело к тому, что эта база данных стала стандартом де-факто в услугах сетевого хостинга. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого типа таблиц: пользователи могут выбрать как сверхбыстрые таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и более медленные, но чрезвычайно устойчивые таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующем принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL лицензированию в СУБД MySQL постоянно появляются новые типы таблиц. /5/

4.3 СУБД PostgreSQL

PostgreSQL (произносится «Пост-Грес-Кью-Эл» или просто «постгрес») - объектно-реляционная система управления базами данных (СУБД). Является альтернативой как свободным СУБД (таким как MySQL и Firebird), так и коммерческим (Oracle Database, Microsoft SQL Server, IBM DB2, различные СУБД производства Sybase).

Сильными сторонами PostgreSQL считаются:

· поддержка БД практически неограниченного размера;

· мощные и надёжные механизмы транзакций и репликации;

· расширяемая система встроенных языков программирования: изначально подерживаются SQL, PL/pgSQL, PL/Perl, PL/Python и PL/Tcl, а также имеется поддержка загрузки C-совместимых модулей;

· поддержка со стороны многих языков программирования: C/C++, Java, Perl, Python, Ruby, ECPG, Tcl, PHP и других.

· наследование.

· легко расширяемая сиcтема типов.

PostgreSQL поддерживает много типов полей двумерной оконной графики (точки, прямые, прямоугольники и т.д.). Есть поддержка массивов данных (несколько экземпляров однотипных данных в одном поле одной записи). Также имеется поддержка регулярных выражений в стиле языка Perl. /6/

PostgreSQL является полнофункциональной объектно-реляционной СУБД, готовой для практического использования. Ее функциональность и надежность обусловлены богатой историей развития, профессионализмом разработчиков и технологией тестирования, а ее перспективы заложены в ее расширяемости и свободной лицензии. /7/

4.4 Выбор СУБД

Существует ещё множество СУБД, как коммерческих, так и свободных. Так же, кроме рассматриваемых нами реляционных (Microsoft Access и MySQL) и объектно-реляционной (PostgreSQL) СУБД, существую ещё сетевые, иерархические и обьектно-ориентированные СУБД.

Для разработки нашего проекта выбираем СУБД Microsoft Access, так как данная СУБД популярная, доступная и разработка БД на её основе экономически выгодна. Кроме того, выбор определенной СУБД не являлся критерием, выдвигаемым заказчиком.

4.5 Выбор технических средств

Платформа

Платформа IBM PC популярна, широко распространена и её стоимость ниже стоимости конкурирующих платформ. СУБД Microsoft Access успешно функционирует на данной платформе.

Операционная система

ОС выбираем исходя из выбранной платформы и выбранной СУБД. Учитываем так же современность, стабильность, надежность и удобство использования ОС. Исходя из вышеперечисленных параметров, выбираем наиболее актуальную и современную ОС для платформы IBM PC - Microsoft Windows XP, которая полностью поддерживает СУБД Microsoft Access.

Центральный процессор

ЦП выбираем по следующим параметрам:

· быстродействие (тактовая частота);

· стоимость;

· совместимость с платформой и ОС;

· моральная старость.

Выбираем такое быстродействие процессора, чтобы время ожидания решения расчетных задач не превышало полутора секунд, и таким образом была обеспечена комфортная для пользователя работа с программой. Для выполнения данного условия достаточно процессора Intel Pentium III 500 MHz, но, т. к. данный процессор можно считать морально устаревшим, выбираем Intel Celeron 1000 MHz, который удовлетворяет и требованиям быстродействия, и экономическим показателям: его стоимость ненамного превышает стоимость процессора Intel Pentium III 500 MHz, и совместим с платформой и ОС.

Оперативная память

Для нормальной работы Microsoft Windows XP необходимо 128 Мб оперативной памяти. Для нормальной работы Microsoft Access 2002 необходимо 16 Мб. Никаких дополнительных утилит, не входящих в состав Windows, иметь не обязательно.

Итого: 128+16=144 Мб. Но, так как БД может содержать большое количество информации, для устойчивой работы Microsoft Access и ОС выбираем оперативную память объемом 512 Мб.

Жесткий диск

Минимально необходимый объём жесткого диска мы можем узнать сложив следующие параметры: объем под ОС Microsoft Windows XP, объем под СУБД Microsoft Access 2002 и объем необходимый объем для хранения информации в течение двух лет непрерывной работы с БД.

Объем под ОС Microsoft Windows XP - 1,5Гб. Объем под СУБД Microsoft Access 2002 - 500 Мб. Средний объем одной средне-заполненной таблицы примерно 300 Кб. Всего в БД 19 таблиц. В году 12 месяцев. Тогда в течение двух лет непрерывной работы потребуется 19?2?12?300Кб=137 Мб.

Исходя из получившегося объема и моральной старости, выбираем жесткий диск объемом 40 Гб.

Монитор и видеокарта

Исходя из того, что в таблицах проектируемой БД много столбцов, для удобства их просмотра и безопасности здоровья пользователя, выбираем монитор с диагональю 17 дюймов. Исходя из эргономических и экономических характеристик, останавливаем свой выбор на мониторе, основанном на ЖК матрице.

Для соответствия ЦП, материнской плате и ОС требуется видеокарта с объем видеопамяти минимум 64Мб. Выбираем видеокарту NVIDIA GeForce 128 Мб.

Устройства ввода информации стандартные - клавиатура и мышь.

Мультимедийные устройства не нужны.

Дополнительные периферийные устройства не нужны.

5. Физический уровень проектирования бд «домашний архив»

5.1 Физическая модель

Физическая модель данных представляет переход от логической модели данных по следующей методике:

3. Преобразование таблиц логической модели в физические таблицы: каждой таблице логической модели ставится в соответствии таблица физической модели.

4. Преобразование атрибутов в столбцы таблиц: каждому атрибуту должен соответствовать аналогичный столбец таблицы.

5. Преобразование доменов в типы данных: логический домен на физическом уровне отображается с помощью типов данных с возможным указанием длины и ограничениями на значения.

6. Для создания связи между таблицами необходимо создать первичные и внешние ключи соответственно в родительской и дочерней таблицах. На основе реляционной модели, математического описания, концептуальной модели в СУБД Microsoft Access были созданы таблицы.

Рис. 5.1. Созданные таблицы

Организованы все связи между таблицами (рис. 5.2) в соответствии с их описанием.

Рис. 5.2. Связи между таблицами

В соответствии с каталогом задач и запросов были реализованы требуемые запросы (рис. 5.3), формы (рис. 5.4) и отчеты (рис. 5.5).

Рис. 5.3. Созданные запросы



Рис. 5.4. Созданные формы

Рис. 5.5. Созданные отчёты

5.2 Примеры запросов

Книги

В данном запросе выводится информация обо всех зарегистрированных в БД книгах.

SELECT Книги. НазваниеКниги, Книги. ГодВыхода, Книги. КоличествоСтаниц, ЖанрыКниг. НазваниеЖанра, Страны. НазваниеСтраны, Писатели. ФамилияПисателя, Писатели. ИмяПисателя, Книги. ПостоянноеРасположение

FROM Страны INNER JOIN ((ЖанрыКниг INNER JOIN Книги ON ЖанрыКниг. КодЖанра = Книги. КодЖанра) INNER JOIN (Писатели INNER JOIN [Писатели-Книги] ON Писатели. КодПисателя = [Писатели-Книги].КодПисателя) ON Книги. КодКниги = [Писатели-Книги].КодКниги) ON Страны. КодСтраны = Книги. КодСтраны;

Пример выполнения запроса показан на рис. 5.6.

Рис. 5.6. Пример выполнения запроса «Книги»

Одалживание музыки

В данном запросе выводится информация о том, кому, когда и какие музыкальные альбомы были одолжены.

SELECT Музыка. НазваниеАльбома, ОдалживаниеМузыки. Статус, Персоны. Фамилия, Персоны. Имя, Персоны. Отчество, Персоны. Адрес, Персоны. Телефон, ОдалживаниеМузыки. Когда, ОдалживаниеМузыки. Комментарий

FROM Персоны INNER JOIN (Музыка INNER JOIN ОдалживаниеМузыки ON Музыка. КодАльбома = ОдалживаниеМузыки. КодАльбома) ON Персоны. КодПерсоны = ОдалживаниеМузыки. Кому;

Пример выполнения запроса показан на рис. 5.7.

Рис. 5.7. Пример выполнения запроса «Одалживание музыки»

Заключение

база архив реляционный домашний

В результате проделанной работы по описанию предметной области я разработал концептуальную модель, а потом реляционную модель, по которой создал в СУБД Microsoft Access приложение. Разработанное приложение отвечает всем требованиям предметной области, а так же каталогу задач и запросов.

В связи с тем, что база учебная, а не профессиональная, я решил не включать в базу некоторые данные. Например, не включена такая информация о книгах, как тип переплета, тираж, формат. Для фильмов, не включена такая информация, как формат картинки, информация о звуковых дорожках и т.п. Но разработанную БД легко дополнить, при необходимости разработки профессиональной БД.

В перспективе база данных будет обновляться по мере поступления фильмов, книг или музыки в домашний архив, и по мере их раздачи друзьям, знакомым и родственникам. С учетом этого она и была спроектирована. Надеюсь, что спроектированная БД существенно облегчит учет и поиск имеющихся в домашнем архиве музыки, фильмов и книг. А при правильном и своевременном обновлении, использовании и администрировании так оно и будет. В конечном итоге, после некоторого времени использования разработанной системы, владельцы домашнего архива по-настоящему оценят необходимость такого приложения у них дома.

Список литературы

1. База данных - Википедия - http://ru.wikipedia.org/wiki/База_данных

2. Архив - Википедия - http://ru.wikipedia.org/wiki/Архив

3. А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев. Базы данных. - СПб.: «КОРОНА принт», 2004 г. - 736 с.

4. А. Горев, С. Макашарипов, Р. Ахаян. Эффективная работа с СУБД - СПб.: «Питер», 1997. - 704 с.

5. MySQL - Википедия - http://ru.wikipedia.org/wiki/MySQL

6. PostgreSQL - Википедия - http://ru.wikipedia.org/wiki/PostgreSQL

7. Что такое PostgreSQL? - http://citforum.ru/database/postgres/what_is/

Размещено на Allbest.ru