Автоматизированная информационная система “Музыкальный магазин”

 

Таблица 3.2.3 – Компоненты диаграммы декомпозиции процесса «Обслуживание клиента»

Процесс	Входные данные	Выходные данные
Выбор диска	-сведения о компакт-диске	- выбранный товар
Продажа товара	- выбранный товар	- информация о продажах

 

 

 

 

 

4. Инфологическое проектирование автоматизированной информационной системы «Музыкальный магазин»

 

4.1 Описание  средства проектирования ERWin

ERwin - средство разработки  структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных [2, стр.146].

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

Логическая модель данных является универсальной и никак  не связана с конкретной реализацией СУБД.

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

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

- диаграмма сущность-связь (Entity Relationship Diagram, ERD);

- модель данных, основанная на  ключах (Key Based model, KB);

- полная атрибутивная модель (Fully Attributed model, FA).

Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.

Различают два уровня физической модели:

- трансформационная модель (Transformation Model);

- модель СУБД (DBMS Model).

Физическая модель содержит всю информацию, необходимую для  реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area).

 

4.2 Логическое  проектирование системы

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

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

На основе анализа  предметной области выделено 8 сущностей:

- сущность «Компакт-диск» определяется  следующими атрибутами: код диска,  название диска, выпустившая компания (лейбл), оптово-закупочная компания, оптовая цена, розничная цена, дата релиза, количество дисков;

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

- сущность «Песня»  определяется следующими атрибутами: код песни, название песни,  код альбома, код исполнителя,  дополнительная информация о  песне;

- сущность «Альбом» определяется следующими атрибутами: код альбома, название альбома, дата релиза, описание альбома;

- сущность «Исполнитель»  определяется следующими атрибутами: код исполнителя, название исполнителя,  имя стиля, описание исполнителя;

- сущность «Артист»  определяется следующими атрибутами: код артиста, имя артиста, музыкальная специализация, код исполнителя;

- сущность «Музыкальный  стиль» определяется следующими  атрибутами: имя стиля, описание стиля;

- сущность «Связь»  определяется следующими атрибутами: код компакт-диска, код песни.

Значения полей «Объем продаж» и «Выручка от реализации»  функционально зависят от группы полей «Год», «Месяц» и «Номер компакт-диска». Но так как в каждом месяце ииформация о проданных дисках записывается неоднократно, то следует выделить атрибут «Код продажи», который будет уникально идентифицировать каждое внесение данных о продажах базу. Общее количество реализованных дисков и выручки может быть легко вычислено суммированием всех значений в соответствующих полях таблицы.

Однозначно идентифицируем каждый экземпляр сущности - выделим первичные ключи.

Сущность «Компакт-диск» - первичный ключ «Код компакт-диска».

Сущность «Продажи» - первичный ключ «Код продажи».

Сущность «Песня» - первичный ключ «Код песни».

Сущность «Альбом» - первичный ключ «Код альбома».

Сущность «Исполнитель» - первичный ключ «Код исполнителя».

Сущность «Артист» - первичный ключ «Код артиста».

Сущность «Музыкальный стиль» - первичный ключ «Имя стиля».

Сущность «Связь» - составной первичный ключ «Код компакт-диска», «Код песни».

4.3 Разработка структуры  связей

Свяжем таблицы через  внешние ключи.

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

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

Сущности «Песня» и «Альбом» связаны через внешний ключ по полю «Код альбома». Т.к. на альбоме, как правило, записано несколько песен, то эта связь будет «один-ко-многим».

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

Сущности «Исполнитель» и «Артист» связаны через внешний ключ по полю «Код исполнителя». Т.к. одному исполнителю – группе, ансамблю, хору, оркестру и т.д. – может соответствовать группа артистов – вокалистов, инструментальных исполнителей и дирижеров, – эта связь будет «один-ко-многим».

Сущности «исполнитель» и «Музыкальный стиль» связаны через внешний ключ по полю «Имя стиля». Т.к. в одном стиле выступает множество исполнителей, но каждый исполнитель характеризуется одним, наиболее ярко выраженным стилем, то эта связь будет «один-ко-многим».

 

4.4 Нормализация  базы данных

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

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

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

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

Аналогично проводится нормализация в таблицах «Продажи», «Песня», «Альбом», «Исполнитель», «Артист», «Музыкальный стиль», «Связь».

 В отношении «Продажи» добавлен атрибут «Выручка от реализации». Значение этого поля может быть вычислено на основе данных, хранящихся в других полях таблиц. Однако для упрощения запросов и экономии ресурсов, в частности времени извлечения хранимых данных, целесообразно хранить эти данные в отдельном поле таблицы базы данных.

Логическая структура базы данных (ER – диаграмма) представлена на рисунке Б.1.

 

5. Физическое проектирование системы

 

На основе анализа  требований разработку базы данных решено проводить с использованием СУБД MS SQL Server 2000. Этот программный продукт разработан компанией Microsoft и удобен при работе на компьютерах, на которых установлена операционная система Windows.

Типы данных атрибутов сущностей приведены в таблицах 5.1-5.8.

Таблица 5.1 - Типы данных атрибутов сущности «Компакт-диск»

Компакт-диск
Атрибут	Тип данных
Код компакт-диска	Числовой
Название компакт-диска	Текстовый (40)
Выпустившая компания	Текстовый (40)
Оптовая компания	Текстовый (40)
Оптовая цена	Числовой
Розничная цена	Числовой
Дата релиза	Дата
Количество	Числовой

 

Таблица 5.2 - Типы данных атрибутов сущности «Продажи»

Продажи
Атрибут	Тип данных
Код продаж	Числовой
Год	Числовой
Месяц	Текстовый (8)
Объем продаж	Числовой
Выручка от реализации	Числовой
Код компакт-диска	Числовой

 

Таблица 5.3 - Типы данных атрибутов сущности «Связь»

Связь
Атрибут	Тип данных
Код компакт-диска	Числовой
Код песни	Числовой

 

Таблица 5.4 - Типы данных атрибутов сущности «Песня»

Песня
Атрибут	Тип данных
Код песни	Числовой
Название песни	Текстовый (40)
Код альбома	Числовой
Код исполнителя	Числовой
Информация о песне	Текстовый (1000)

 

Таблица 5.5 - Типы данных атрибутов сущности «Альбом»

Альбом
Атрибут	Тип данных
Код альбома	Числовой
Наименование альбома	Текстовый (40)
Дата релиза	Дата
Описание	Текстовый(1000)

Таблица 5.6 - Типы данных атрибутов сущности «Исполнитель»

Исполнитель
Атрибут	Тип данных
Код исполнителя	Числовой
Наименование исполнителя	Текстовый (40)
Название стиля	Текстовый (40)
Описание	Текстовый (1000)

  

Таблица 5.7 - Типы данных атрибутов сущности «Артист»

Стипендия
Атрибут	Тип данных
Код артиста	Числовой
Имя артиста	Текстовый (40)
Музыкальная специализация	Текстовый (30)
Код исполнителя	Числовой

   

Таблица 5.8 - Типы данных атрибутов сущности «Музыкальный стиль»

Надбавки
Атрибут	Тип данных
Название стиля	Текстовый (40)
Описание	Текстовый (1000)

   

ER – диаграмма физической структуры базы данных представлена на рисунке Б.2.

 

6. Проектирование пользовательского интерфейса

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