Добавлен: 21.10.2018
Просмотров: 780
Скачиваний: 5
![background image](https://images.student-it.ru/files/374/page19150_1.png)
ПРОЕКТИРОВАНИЕ
БАЗЫ ДАННЫХ «ИЗДАТЕЛЬСТВО»
Системный
анализ предметной области
База данных создаётся для информационного обслуживания
редакторов, менеджеров и других сотрудников компании.
БД должна содержать:
1.
данные о сотрудниках компании
2.
данные о книгах
3.
данные об авторах
4.
финансовое состояние компании
5.
возможность получать разнообразные отчёты.
В соответствии с предметной областью система строится с учётом
следующих особенностей:
а) каждая книга издаётся в рамках контракта;
б) книга может быть написана несколькими авторами(не более 5);
в) контракт подписывается одним менеджером и всеми авторами
книги;
г) каждый автор может написать несколько книг (по разным
контрактам);
д) порядок, в котором авторы указаны на обложке, влияет на размер
гонорара;
е) если сотрудник является редактором, то он может работать
одновременно над несколькими книгами;
ж) у каждой книги может быть несколько редакторов, один из них –
ответственный редактор;
з) каждый заказ оформляется на одного заказчика;
и) в заказе на покупку может быть перечислено несколько книг.
Выделим базовые сущности этой предметной области:
Сотрудники
компании. Атрибуты сотрудников:
•
ФИО
•
табельный номер
•
пол
•
дата рождения
•
паспортные данные
•
ИНН
•
должность
•
оклад
•
адрес сотрудника
•
телефоны
Для редакторов необходимо хранить сведения о редактируемых книгах;
Для менеджеров – сведения о подписанных контрактах;
Для авторов - сведения о написанных книгах.
![background image](https://images.student-it.ru/files/374/page19151_1.png)
Книги
. Атрибуты книги:
•
авторы
•
название
•
категория
•
количество страниц
•
аннотация
•
тираж
•
дата выхода
•
цена одного экземпляра
•
общие затраты на издание
•
авторский гонорар
•
авторский знак
Контракты
будем рассматривать как связь между авторами, книгами и
менеджерами. Атрибуты контракта:
•
Номер
•
дата подписания
•
участники
Авторы
. Атрибуты авторов :
•
ФИО автора
•
паспортные данные
•
адрес автора
•
телефоны
•
ИНН
Для отражения финансового положения компании в системе нужно
учитывать Заказы на книги. Атрибуты заказа:
•
номер заказа
•
дату поступления заказа
•
дату его выполнения
•
список заказанных книг с указанием количества экземпляров
•
стоимость заказа
Заказчики
. Атрибуты:
•
номер заказчика
•
адрес заказчика
•
телефоны
•
номер заказа
Функции менеджера:
1.
Принятие заказов
2.
Утверждение плана работ
![background image](https://images.student-it.ru/files/374/page19152_1.png)
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 с.
![background image](https://images.student-it.ru/files/374/page19153_1.png)
Логическое проектирование базы данных
Логическое проектирование основано на модели логического уровня и
представляет собой описание и построение схем связей между элементами
данных безотносительно к их содержанию и среде хранения.
Логическая структура БД получается преобразованием концептуальной
схемы в логическую схему (модель), ориентированную на выбранную СУБД.
Применительно к наиболее распространенной реляционной модели
данных общий подход преобразования концептуальной схемы в логическую
состоит в том, что каждую сущность, являющуюся представителем
множества однотипных объектов, задают схемой отдельного отношения
(таблицы), а атрибуты сущности образуют столбцы таблицы. Первичный
ключ сущности образует исходный первичный ключ таблицы, который в
дальнейшем может быть изменен.
Проектирование логической структуры БД должно решать задачи
выбора наиболее эффективной структуры данных, обеспечения быстрого
доступа к данным; исключения дублирования данных, обеспечения
целостности данных таким образом, чтобы при изменении одних объектов
автоматически происходило соответствующее изменение связанных с ними
объектов.
При неправильно спроектированной схеме БД могут возникнуть
аномалии модификации данных. Они обусловлены отсутствием средств
явного представления типов множественных связей между объектами ПО и
неразвитостью средств описания ограничений целостности на уровне модели
данных. Для решения подобных проблем проводится нормализация
отношений, предложенная Э.Ф. Коддом в рамках реляционной модели
данных.
Нормализация
Целью нормализации является исключение избыточности данных,
которая является причиной ошибок при вводе и нерационального
использования дискового пространства компьютера.
Нормализация
представляет
собой
процесс
последовательного
приведения логической структуры базы данных к требуемому уровню
нормальной формы. Существует шесть нормальных форм (НФ): первая НФ
(1НФ), вторая НФ (2НФ), третья НФ (3НФ), нормальная форма Бойса-Кодда
(БКНФ), четвертая НФ (4НФ), пятая НФ (5НФ). Каждая следующая
нормальная форма должна удовлетворять требованиям предыдущей формы и
некоторым дополнительным условиям. Ограничимся рассмотрением первых
трех НФ, поскольку при практическом проектировании баз данных
остальные НФ используются в редких случаях.
![background image](https://images.student-it.ru/files/374/page19154_1.png)
Первая
нормальная форма
Таблица находится в 1НФ, если она удовлетворяет следующим
требованиям:
а) не содержит полей с несколькими значениями;
б) ключевое поле не имеет пустот.
Первым требованием обеспечивается атомарность полей, т.е. каждое
поле таблицы должно иметь только одно значение в каждой строке данных.
Иногда неатомарное поле может быть представлено несколькими полями в
виде повторяющейся группы, которая также запрещена в 1НФ. В процессе
нормализации, необходимо повторяющиеся значения в полях превратить в
повторяющиеся строки в других таблицах, а повторяющиеся группы в
отдельные таблицы.
Вторым
требованием
через
определение
первичного
ключа
обеспечивается уникальность записей таблицы. Как правило, в 1НФ
первичный ключ является составным.
Рассмотрим процесс приведения к 1НФ на примере. На рис. 1
представлен список таблиц проектируемой базы данных.
По
определению
логическая
модель
является
отображением
концептуальной
модели, в частности диаграммы классов. В данном случае исходными
данными будут являться пять таблиц (Рис.1) , выделенных при построении
концептуальной модели. Проанализируем их в соответствии с требованиями.
Рис.1– Структура таблиц базы данных «Издательство»
В таблицах на рис.1 не все поля удовлетворяют требованиям 1НФ. В
частности, поле «adres_zakazchika» в таблице “Zakazi” не является
атомарным, т.к. содержит информацию о городе, области, районе, улице ,
доме, квартире. В издательство обращаются заказчики из разных городов,
впоследствии необходимо будет проводить анализ заказов по городам.