Отчет по курсовой работе (1038608), страница 3
Текст из файла (страница 3)
Вычисление размера таблицы. Основываясь на значении Data_Length можно оценить размер обычной таблицы или хэш-таблицы. Формулы для выполнения такой оценки приведены в таблицах 4.2 и 4.3. Различие в методике расчета размера хэш-таблицы заключается в необходимости учитывать параметр загрузки хэш-таблицы (packing_density), который устанавливается при определении такой таблицы.
Таблица 4.2. | ||
Параметр | Формула | |
Row_Lenght | Длина строки на физической странице включает в себя длину заголовка и размер строки таблицы, которая вычисляется по формуле Row_Lenght = 18 + (2 * число_колонок) + Data_Lenght | |
Row_Lenght_with_Stack | Длина строки с размером стека Row_Lenght_with_Stack = Row_Lenght * 100 / (100 - PCTFREE) | |
Usable_Row_Page_Size | Используемая СУБД длина строки на странице. В SQLBASE длина заголовка страницы равна 86 байт Usable_Row_Page_Size = 1024 - 86 = 936 байт | |
Rows_per_Page | Число строк на странице: Rows_per_Page = [Usable_Row_Page_Size / Row_Lenght_with_Stack] | |
Nbr_Row_Pages | Число страниц: Nbr_Row_Pages = [NbrOfRows / Rows_per_Page], где NbrOfRows - предполагаемое число строк в таблице | |
Nbr_Long_Pages | Число страниц, занимаемых длинными строками: Nbr_Long_Pfge = NbrOfRows * Nbr_Long_Pages_per_Long_Col,Nbr_Long_Pages_per_Long_Col - число длинных строк на страницу | |
Total_Data_Page | Число страниц данных: Total_Data_Page = Nbr_Row_pages + Nbr_Long_Pages | |
Таблица 4.3. Оценки размера хэш-таблицы | ||
Параметр | Формула | |
Row_Lenght | Длина строки на физической странице включает в себя длину заголовка и размер строки таблицы, которая вычисляется по формуле Row_Lenght = 18 + 6 + (2 * число_колонок) + Data_Lenght Дополнительные 6 байт необходимы для поддержки хэш-ключа | |
Row_Lenght_with_Stack | Длина строки с размером стека: Row_Lenght_with_Stack = Row_Lenght * 100 / (100 - PCTFREE) | |
Usable_Row_Page_Size | Используемая СУБД длина строки на странице. В SQLBASE длина заголовка страницы равна 86 байт Usable_Row_Page_Size = 1024 - 86 = 936 байт | |
Rows_per_Page | Число строки на страницу: Rows_per_Page = [Usable_Row_Page_Size / Row_Lenght_with_Stack] | |
Nbr_Row_Pages | Число строк на странице: Nbr_Row_Pages = [NbrOfRows / Rows_per_Page],где NbrOfRows - предполагаемое число строк в таблице | |
Nbr_Long_Pages | Число страниц, занимаемых длинными строками: Nbr_Long_Pfge = NbrOfRows * Nbr_Long_Pages_per_Long_Col, Nbr_Long_Pages_per_Long_Col - число длинных строк на страницу | |
Nbr_Hashed_Table_Pages | Число страниц хэш-таблицы: Nbr_Hashed_Table_Pages = Nbr_Row_Pages / packing_density | |
Total_Data_Page | Число страниц данных: Total_Data_Page = Nbr_Row_pages + Nbr_Long_Pages |
Вычисление размера индекса. Для каждого созданного B-Tree индекса его размер оценивается следующим образом: вычисляется размер индексного ключа, оценивается число строк в таблице, затем оценивается число страниц, которое занимает индекс. Расчет выполняется по формулам, приведенным в таблице 4.4.
Таблица 4.4. Оценка размера индекса | |
Параметр | Формула |
Key_Lenght | Длина ключа равна сумме средних длин колонок, которые составляют данный ключ |
Index_Entry_Lenght | Длина размера строки индекса: Index_Entry_Lenght = 9 + число_колонок_ключа_индекса + Key_Lenght |
Usable_Index_Page_Size | Используемый СУБД размер страницы индекса: Usable_Index_Page_Size = (1024 - 74)* (100 - PCTFREE)/100 |
Index_Entry_per_Page | Число входов индекса на страницу: Index_Entry_per_Page = [Usable_Index_Page_Size / Index_Entry_Lenght |
Nbr_Index_Pages | Число страниц, занимаемых индексом Nbr_Index_Pages = [NbrOfRows / Index_Entry_per_Page], где NbrOfRows - предполагаемое число строк в таблице |
Вычисление размера заголовка представления. Для каждого представления существует фиксированная часть заголовка и переменная часть заголовка, которая зависит от его сложности. Формулы для расчета размера заголовка представления приведены в таблице 4.5.
Таблица 13.6. Оценка размера заголовка представления | |
Параметр | Формула |
Fixed_Overhead | = 12 * 1024 |
Variable_Overhead | = 150 * число_таблиц + 170 * число_колонок |
Variable_Overhead_all_Views |
|
Total_View_overhead_in_Page | = [(Fixed_Overhead + Variable_Overhead + Variable_Overhead_all_Views)/1024] |
Проанализируем и вычислим объем базы данных с помощью предоставляемой пакетом ERWin опции Volumetrics (рис. 4.2).
Рис. 4.2. Окно инструмента Volumetrics.
Для расчета зададим настройки для каждой таблицы – начальное число строк, максимальное число строк, рост числа строк в месяц.
1. Таблица Employees.
Туроператор имеет в своем штате 15 сотрудников в каждом из 6 филиалов и 30 сотрудников в главном офисе. Итого 120 сотрудников.
2. Таблица Provider.
Туроператор работает по 10 туристическим направлениям, на каждом из которых имеет по 2 партнера поставщиков туристических услуг. Итого 20 поставщиков туристических услуг.
3. Таблица Tours.
Каждый из поставщиков услуг предлагает в среднем 20 вариантов путешествия. Итого общее число туров - 400.
4. Таблица Tourists.
В среднем каждый день в каждый из офисов фирмы обращается 10 новых клиентов. Следовательно, в месяц (22 рабочих дня) рост клиентов составляет – 22*10*7 = 1540 клиентов.
5. Таблица Orders.
Каждый из клиентов в год совершает в среднем 1,5 заказа, следовательно, в месяц совершается – 2310 заказов.
Общий размер базы данных через год составит 11 Мбайт (рис. 4.3):
Рис. 4.3. Окно инструмента Volumetrics.
На основании полученного результата осуществим выбор оптимального режима архивирования данных.
Рассмотрим вариант полного копирования данных. Учитывая 250 рабочих дней в году, общий объем резервных копий составит:
250 * 11 Мбайт = 2750 Мбайт
Учитывая небольшой объем хранимых данных и относительно невысокую стоимость данный вариант можно признать приемлемым, однако, спецификой работы туроператора является сезонность: наличие летнего и зимнего пика продаж и низкая интенсивность продаж осенью и весной, поэтому выполнение полного копирования данных в указанные периоды будет являться нецелесообразным.
Рассмотрим вариант ежедневного инкрементного копирования и ежемесячного полного копирования. В данном случае объем резервных копий составит:
12 * 11 Мбайт + 220 * 0,016 Мбайт = 135,52 Мбайт
Сравнивая полученные результаты, можем утверждать, что второй вариант позволит существенно снизить затраты на хранения данных, и даже в самом неблагоприятном случае администратору базу данных потребуется произвести инкрементацию не более 22 резервных копий.
Таким образом, более предпочтительным является вариант комбинированного полного и инкрементного копирования базы данных.
Заключение
В результате выполнения курсовой работы были достигнуты следующие результаты:
1. Спроектирована сеть автоматизированной информационной системы
2. Осуществлен выбор оборудования и операционных систем для офисов АИС
3. Разработана модель бизнес-процесса АИС в нотации BPMN.
4. Выбрана СУБД DB2 для использования с «1С:Предприятие 8».
Список использованной литературы
1. Конспект лекций по дисциплине «Супер ЭВМ». 2012 г.
2. Свободная Интеренет-энциклопедия http://ru.wikipedia.org/
3. Официальный сайт компании IBM http://ibm.com/
4. Электронное научно-техническое издание «Образование и наука». http://technomag.edu.ru/
5. Официальный сайт компьютерной газеты «Компьютерра» газеты http://www.computerra.ru/
6. Интернет-сообщество http://habrahabr.ru/