Добавлен: 21.10.2018
Просмотров: 735
Скачиваний: 5
ПРОЕКТИРОВАНИЕ
БАЗЫ ДАННЫХ «ИЗДАТЕЛЬСТВО»
Системный
анализ предметной области
База данных создаётся для информационного обслуживания
редакторов, менеджеров и других сотрудников компании.
БД должна содержать:
1.
данные о сотрудниках компании
2.
данные о книгах
3.
данные об авторах
4.
финансовое состояние компании
5.
возможность получать разнообразные отчёты.
В соответствии с предметной областью система строится с учётом
следующих особенностей:
а) каждая книга издаётся в рамках контракта;
б) книга может быть написана несколькими авторами(не более 5);
в) контракт подписывается одним менеджером и всеми авторами
книги;
г) каждый автор может написать несколько книг (по разным
контрактам);
д) порядок, в котором авторы указаны на обложке, влияет на размер
гонорара;
е) если сотрудник является редактором, то он может работать
одновременно над несколькими книгами;
ж) у каждой книги может быть несколько редакторов, один из них –
ответственный редактор;
з) каждый заказ оформляется на одного заказчика;
и) в заказе на покупку может быть перечислено несколько книг.
Выделим базовые сущности этой предметной области:
Сотрудники
компании. Атрибуты сотрудников:
•
ФИО
•
табельный номер
•
пол
•
дата рождения
•
паспортные данные
•
ИНН
•
должность
•
оклад
•
адрес сотрудника
•
телефоны
Для редакторов необходимо хранить сведения о редактируемых книгах;
Для менеджеров – сведения о подписанных контрактах;
Для авторов - сведения о написанных книгах.
Книги
. Атрибуты книги:
•
авторы
•
название
•
категория
•
количество страниц
•
аннотация
•
тираж
•
дата выхода
•
цена одного экземпляра
•
общие затраты на издание
•
авторский гонорар
•
авторский знак
Контракты
будем рассматривать как связь между авторами, книгами и
менеджерами. Атрибуты контракта:
•
Номер
•
дата подписания
•
участники
Авторы
. Атрибуты авторов :
•
ФИО автора
•
паспортные данные
•
адрес автора
•
телефоны
•
ИНН
Для отражения финансового положения компании в системе нужно
учитывать Заказы на книги. Атрибуты заказа:
•
номер заказа
•
дату поступления заказа
•
дату его выполнения
•
список заказанных книг с указанием количества экземпляров
•
стоимость заказа
Заказчики
. Атрибуты:
•
номер заказчика
•
адрес заказчика
•
телефоны
•
номер заказа
Функции менеджера:
1.
Принятие заказов
2.
Утверждение плана работ
3.
Подписание контрактов
4.
Формирование базы данных о заказчиках
5.
Контроль оплаты заказов
6.
Координация работы сотрудников
7.
Составление отчетов
Функции ответственного редактора:
1.
Поиск авторов
2.
Формирование базы данных об авторах
3.
Планирование работ
4.
Отбор и редактирование материалов
5.
Оформление книги
6.
Контроль своевременности сдачи редакционных материалов
Функции автора:
1.
Поиск материалов
2.
Своевременная сдача материалов
3.
Подписание контракта
Функции заказчика:
1.
Оформление заказа
2.
Оплата заказа
Выводы.Система должна обеспечивать:
а) Поиск книги по кодам, авторам, названиям
б) Поиск книг авторов
в)Поиск книг, которые редактировал данный редактор
г)Поиск редакторов, работающих над данной книгой
д)Поиск авторов когда-либо печатавшихся в данном издательстве
е)Поиск заказчиков когда-либо делавших заказ
ж)Поиск заказов по номеру заказчика, номеру заказа, коду контракта
з)Поиск заказов по стоимости
и)Поиск контрактов, подписанных данным менеджером
к) Фиксировать дату принятия и сдачи заказа
л) Отслеживать задержки заказов
В редакции около 150 авторов, постоянно печатающихся не более 50.
Срок редактирования каждой книги не более 6 месяцев. Печать новых книг –
до 50 наименований, тиражом до 15000 экземпляров в месяц. В редакцию
ежемесячно обращается до 1000 заказчиков. В среднем каждый из них
заказывает 30 книг тиражом 300 экземпляров. Отпускная цена издательства
составляет примерно 50 рублей за одну книгу средним объемом 300 с.
Логическое проектирование базы данных
Логическое проектирование основано на модели логического уровня и
представляет собой описание и построение схем связей между элементами
данных безотносительно к их содержанию и среде хранения.
Логическая структура БД получается преобразованием концептуальной
схемы в логическую схему (модель), ориентированную на выбранную СУБД.
Применительно к наиболее распространенной реляционной модели
данных общий подход преобразования концептуальной схемы в логическую
состоит в том, что каждую сущность, являющуюся представителем
множества однотипных объектов, задают схемой отдельного отношения
(таблицы), а атрибуты сущности образуют столбцы таблицы. Первичный
ключ сущности образует исходный первичный ключ таблицы, который в
дальнейшем может быть изменен.
Проектирование логической структуры БД должно решать задачи
выбора наиболее эффективной структуры данных, обеспечения быстрого
доступа к данным; исключения дублирования данных, обеспечения
целостности данных таким образом, чтобы при изменении одних объектов
автоматически происходило соответствующее изменение связанных с ними
объектов.
При неправильно спроектированной схеме БД могут возникнуть
аномалии модификации данных. Они обусловлены отсутствием средств
явного представления типов множественных связей между объектами ПО и
неразвитостью средств описания ограничений целостности на уровне модели
данных. Для решения подобных проблем проводится нормализация
отношений, предложенная Э.Ф. Коддом в рамках реляционной модели
данных.
Нормализация
Целью нормализации является исключение избыточности данных,
которая является причиной ошибок при вводе и нерационального
использования дискового пространства компьютера.
Нормализация
представляет
собой
процесс
последовательного
приведения логической структуры базы данных к требуемому уровню
нормальной формы. Существует шесть нормальных форм (НФ): первая НФ
(1НФ), вторая НФ (2НФ), третья НФ (3НФ), нормальная форма Бойса-Кодда
(БКНФ), четвертая НФ (4НФ), пятая НФ (5НФ). Каждая следующая
нормальная форма должна удовлетворять требованиям предыдущей формы и
некоторым дополнительным условиям. Ограничимся рассмотрением первых
трех НФ, поскольку при практическом проектировании баз данных
остальные НФ используются в редких случаях.
Первая
нормальная форма
Таблица находится в 1НФ, если она удовлетворяет следующим
требованиям:
а) не содержит полей с несколькими значениями;
б) ключевое поле не имеет пустот.
Первым требованием обеспечивается атомарность полей, т.е. каждое
поле таблицы должно иметь только одно значение в каждой строке данных.
Иногда неатомарное поле может быть представлено несколькими полями в
виде повторяющейся группы, которая также запрещена в 1НФ. В процессе
нормализации, необходимо повторяющиеся значения в полях превратить в
повторяющиеся строки в других таблицах, а повторяющиеся группы в
отдельные таблицы.
Вторым
требованием
через
определение
первичного
ключа
обеспечивается уникальность записей таблицы. Как правило, в 1НФ
первичный ключ является составным.
Рассмотрим процесс приведения к 1НФ на примере. На рис. 1
представлен список таблиц проектируемой базы данных.
По
определению
логическая
модель
является
отображением
концептуальной
модели, в частности диаграммы классов. В данном случае исходными
данными будут являться пять таблиц (Рис.1) , выделенных при построении
концептуальной модели. Проанализируем их в соответствии с требованиями.
Рис.1– Структура таблиц базы данных «Издательство»
В таблицах на рис.1 не все поля удовлетворяют требованиям 1НФ. В
частности, поле «adres_zakazchika» в таблице “Zakazi” не является
атомарным, т.к. содержит информацию о городе, области, районе, улице ,
доме, квартире. В издательство обращаются заказчики из разных городов,
впоследствии необходимо будет проводить анализ заказов по городам.