65
сайта и соответствующей базы данных, каждый из них требует тщательного
проектирования, чтобы работать эффективно, а также надежно.
Для всех вариантов структуры баз данных есть набор стандартных
правил и лучших практик, которыми следует пользоваться. Они будут
способствовать базе данных оставаться организованной и сделает ее
взаимодействие с сайтом более разумным и эффективным способом.
Первый метод, используемый при планировании, это обычный
мозговой штурм, делая записи на бумаге или как-то еще, в зависимости от
того, что требуется хранить в базе данных, и что будет требоваться сайту.
Старайтесь не думать об конкретных полях, таблицах, которые будут
использоваться в конкретном случае — все специфичные моменты будут
рассмотрены вами позже. Наша цель на данном этапе состоит в том, чтобы
получить общую и полную картину структуры базы данных, которую потом
будете уточнять и делать более подробной. Зачастую в дальнейшем может
быть более трудным добавить какие-то элементы в ваш план, нежели на
первоначальном этапе.
В базе данных должна быть предусмотрена возможность хранить
рецепты, «закрытые» записи, доступные определенному кругу
пользователей, информацию о продуктах, а также возможность связи
определенного продукта и пользователя.
Следующий этап заключается в том, чтобы определить, какие именно
таблицы и поля потребуются в базе данных. Это ядро разработки и самая
сложная её часть. Использование правильных методов связки таблиц,
определение структуры данных в каждой таблице, выявление необходимости
разброса этих данных по разным таблицам, — все эти проблемы всплывают
при непосредственном проектировании базы данных. Теперь необходимо
определить список очевидно необходимых таблиц и полей, будьте как можно
более конкретным. В ходе этого процесса, какие-то элементы могут быть
перестроены либо реорганизованы в целях повышения эффективности и
безопасности базы данных.
66
Очень уместным здесь окажется инструмент для проектирования баз
данных, особенно имеющий возможность создавать визуальные модели базы
данных, например, MySQL Workbench либо DBDesigner4. Gliffy является
отличным бесплатным он-лайн инструментом для создания различных блок-
схем и моделей баз данных.
Есть также более известный, качественный, инструмент — Microsoft
Visio (только под Windows, цена $249.99).
Большинство баз данных являются реляционными базами данных.
Это означает, что таблицы в базе данных связаны между собой каким-либо
образом. Например, если существует «пользователь» на сайте интернет -
магазина, то он наверняка может быть связан с определенными продуктами,
на основании информации об их заказах либо указании желаемых продуктах.
Для базы данных блога авторы должны быть как-то связаны с записями,
которые они написали, а авторизованные пользователи должны быть связаны
с оставленными ими комментариями.
С помощью определенных методов реляционных баз данных мы
можем хранить огромное количество информации в организованном виде в
отдельных таблицах: одна для пользователей, одна для записей, одна для
комментариев, для продуктов и т.д. Теперь мы можем связать данные в
разных таблицах, использую уникальные ключи.
Любая запись в каждой таблице должна иметь уникальный ключ. Это
типа «номера социального страхования» или «штрих-кода» для записи. Он
является уникальным для каждой записи. И никакая другая записи не может
иметь такой же идентификатор в той же таблице.
Наличие уникальных имен или названий продуктов в базе данных
недостаточно. Гораздо более эффективным является использование
уникальных первичных ключей. Даже несколько уникальных полей в базе
данных не защищают ее от возможности дублирования данных, что
впоследствии может негативно сказаться на работе сайта.
67
Для связи двух таблиц мы используем внешний ключ, который
является всего лишь идентификатором, ссылающимся на уникальный ключ в
другой таблице, обычно это первичный ключ. В примере ниже мы видим, что
первая таблица содержит информацию о трех авторах с уникальным
идентификатором (id). Во второй таблице мы связываем каждую запись о
статье с автором через этот идентификатор. Теперь мы можем найти автора
первой статьи, и наоборот, видеть, что Том написал две статьи, Мэри —
одну, а Джейн еще ни одной.
Это простая модель отношения вида один-к-одному.
Что касается полей, также важно знать, когда группировать
определенную часть данных, а когда нет. Хороший способ определить, какая
информация должна быть в одном поле или наоборот, подумать, будет ли
необходимость изменять какую-либо её часть.
Например, нужно ли хранить адрес, разбив его на составляющие:
1) улица,
2) город,
3) штат,
4) почтовый код,
5) страна.
Это неотъемлемая часть функционала сайта (возможно, пользователи
или администраторы захотят искать других пользователей по адресу или
штату), или просто увеличение места, занимаемого базой данных на диске.
Если это не столь важно, зачем тогда нагружать базу данных на
изменение 5 полей, когда можно обновить всего лишь одно строковое поле.
Более удобным может быть вариант получения этих данных из
HTML-формы, где поля разделены, а уже перед добавлением адреса в базу
данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее
эффективные способы организации полей таблицы, когда объединять их,
когда содержать отдельно, ради поддержания функциональности сайта.
68
Нормализация представляет набор руководящих принципов,
созданных для организации более эффективного хранения информации. Мы
уже упоминали о некоторых важных основных практиках, которые входят в
наиболее популярные нормальные формы. Есть пять нормальных форм. Было
бы полезным ознакомиться с этими нормальными формами и разрабатывать
базы данных в соответствии с их требованиями.
Нормализация базы данных большая тема, но уже понимание ее основ
может вам чрезвычайно помочь.
Проектирование баз данных — обширная тема, но от вас не
потребуется многого, чтобы изучить основы и иметь представление о
правильной структуре баз данных. Может быть, наиболее важным этапом
проектирования базы данных является само его начало и мозговой штурм.
Это то, что позволяет любому разработчику получить всю необходимую
информацию заранее и реализовывать задуманное по мере необходимости.
Только имея всю необходимую информацию для проектирования,
можно создать эффективную базу данных с правильно связанными
таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные
постоянно редактируются, добавляются, удаляются, поэтому важным будет
содержать базу данных организованной таким образом, чтобы поддерживать
этот постоянно изменяющийся набор данных. Стоит убедиться, чтобы в
создаваемой базе данных удалялась только та информация, которая должна,
не дублировались бы записи и можно было бы ссылаться на другие данных
легко и просто
С позиции пользователя системы номинальными требованиями
являются:
- возможность проведения необходимых операций с исходными
данными и результатной информацией (разграничение доступа, ввод,
обновление, удаление, поиск);
69
- наличие понятного и удобного пользовательского интерфейса при
работе с базой данных;
- интерфейса, приближенного к привычным журнальным и карточным
формам регистрации документов.
- добавление/изменение/удаление групп пользователей – сотрудников,
подразделений организации (для администратора системы);
- добавление/изменение/удаление записей регистрации документов и
самих документов;
- формирование поисковых запросов по наиболее актуальным
атрибутам поиска;
- формирование отчетов за периоды времени и по наиболее
актуальным атрибутам поиска (например, договора определенного партнера
организации).
Поиск информации и формирование отчетов. ИС должна позволять
проводить поиск информации по нескольким ключам поиска информации:
- поиск документов по номеру – позволяет осуществлять поиск
документов по номеру;
- поиск документов по номеру и дополнительным атрибутам
позволяет осуществлять поиск документов по ряду параметров;
- поиск документов по наименованию – позволяет осуществлять поиск
документов по наименованию;
- поиск документов по дате регистрации – позволяет осуществлять
поиск документов по дате регистрации;
- поиск сотрудника организации по должности – позволяет
осуществлять поиск сотрудника по должности (например, сотрудника,
который регистрировал документ);
- поиск сотрудника организации по фамилии – позволяет
осуществлять поиск сотрудника по фамилии;
- отчеты по различным видам документов за определенные периоды
времени;
70
Возможные атрибуты поиска могут уточняться на этапе опытной
эксплуатации системы.
Рассмотрим общие требования к системе в целом и ее программным
компонентам. Экранные формы. ИС должна обеспечить ввод и модификацию
данных посредством экранных форм, представленным в виде таблиц. Форма
предполагает наличие полей для ввода и модификации данных. Программное
обеспечение должно быть независимым от структуры таблиц базы данных.
Интерфейс пользователей. ИС должна предоставлять интуитивно
понятный интерфейс пользователей, обеспечивающий простоту работы на
всех ее этапах. Защита от несанкционированного доступа. Вход в
защищенные области системы, БД, поисковые компоненты должен
осуществляться после ввода пользователем логина и пароля.
Для этого разрабатывается или используется подсистема
аутентификации пользователя. После ввода логина и пароля, система
определяет статус и полномочия пользователя по доступу к данным и
функциям системы. Сохранность информации. Для сохранности информации
администратор системы производит операции по созданию дампов базы
данных (резервных копий). Частота создания резервной копии определяется
на этапе опытной эксплуатации системы.
Требования к базовым программным средствам. Клиентская часть
информационной системы работает в среде Windows. Программное
обеспечение серверной части ИС реализуется в ОС Linux. Языком
программирования серверной части ИС является PHP.
Разрабатываемая ИС предполагает хранение большого объема
информации, должна обеспечивать анализ и оценку данных. Указанным
требованиям отвечают системы управления базами данных (СУБД), одна из
которых и должна быть выбрана для практической реализации данного
дипломного проекта.
Современные СУБД обладают следующими свойствами:
представляют собой удобный и современный, предназначенный для
71
разработки и эксплуатации информационных систем, предоставляя
интегрированную среду проектирования, работа в которой базируется на
манипулировании с объектами и их атрибутами; позволяют для обработки
информации и быстрого формирования решений привлекать все
преимущества реляционных баз данных.
С позиций распространенности и доступности рекомендуется
использование при программировании среды СУБД MySQL.
Возможны следующие виды рисков и причины их вызывающие.
Организационные риски: Отсутствие или некорректное формирование целей
или задач проекта приведет к непониманию целесообразности разработки
Недостаточное изучение объекта автоматизации влечет за собой
неправильное формирование требований и функций системы
Технологические риски: Недостаточное обследование компании
может привести к разработке неполного функционала, что приведет к
неверному ожиданию заявленного функционала на стадии эксплуатации
Субъективные риски: Сопротивление со стороны сотрудников или
руководителей компании к внедрению системы, отсутствие желания
обучаться новому программному продукту и методам работы
Данные риски могут затянуть разработку системы на неопределённый
срок, или серьезно повлиять на ожидаемый конечный результат со стороны
компании.
Для минимизации или полному исключению данных рисков, следует
применить следующие аспекты:
На стадии проектирования вести активные переговоры, как с
руководителями, так и с рядовыми сотрудниками компании, чтобы учесть
все пожелания для обеспечения более благоприятных условий работы в
новой системе; Применение типовых решений там, где это возможно, для
ускорения процесса разработки.
72
3.3 Расчет затрат на разработку ИС
Рассчитать себестоимость любого программного продукта или услуги
- это определение совокупности затрат, которые можно разделить на
следующие позиции:
1. Заработная плата основной деятельности;
2. Накладные расходы. Расчет первой категории производится в
соответствии с трудоемкостью программного продукта. Фонд времени работ
по плану – 22 дня при 8-ми часовом рабочем дне, что в свою очередь
определяет общее количество рабочих часов в месяц – 176.
На разработку информационной системы затрачено 31 день. Из чего
следует, что объем затраченного времени составил 248 часов. Размер средней
заработной платы PHP-программиста начального уровня в Пермском крае
составляет 24000 рублей.
Начнем с определения часовой тарифной сетки (Сч) по формуле (1):
где ФРВ – плановый фонд рабочего времени за месяц.
Сч= 136,4 руб. в час Основную заработную плату следует рассчитать
по следующей формуле (2):
где Тож - затраченное время на создание ИС, которое составило 31
день (248 часов).
В расходы включены затраты на электроэнергию, потребляемую
компьютером за время разработки программы и амортизационные
отчисления.
73
Таблица 6
Затраты на электроэнергию
Вид
оборудования
Кол-во
(шт.)
Мощность,
кВт
Стоимость
1 кВт/час,
руб.
Время работы
оборудования,
час
Сумма
затрат,
руб.
Компьютер
1
0,15
3,37
248
125,36
Итого:
-
-
-
-
125,36
В таблице 8 выполнены расчеты по затрате ресурсов на
электроэнергию по формуле (3):
Сумма = (М * С) * Т=0,15*3,37*248=125,36, (3)
где:
М - мощность, кВт;
С - стоимость 1 кВт/час, руб.;
Т - время работы оборудования, час.
Оборудование имеется в наличии, соответственно рассчитаем
годовую сумму амортизации.
Таблица 7
Амортизация оборудования
Вид
оборудования
Первоначальная
стоимость, руб.
Количество
рабочих
часов
Норма
амортизации,%
Сумма отчислений
по амортизации,
руб.
Компьютер
22800
248
12,5
357,69
Итого:
-
-
-
357,69
В таблице 7 рассчитана сумма амортизационных отчислений за
период разработки программного продукта в часах. Амортизация
оборудования за период работы над созданием ИС определяем по формулам
(4) и (5):
74
где:
Аг – сумма отчислений по амортизации в год, руб.;
Сп – стоимость оборудования на начало эксплуатации, руб.;
На – годовая норма амортизации, %;
Афакт – амортизация за период разработки программы, руб.;
Тфакт – количество затраченных часов задействованного
оборудования (44 часа);
N – годовой объем рабочих часов (247 дней * 8 часов = 1976 часов).
Накладные расходы суммируются из затрат на электроэнергию и
отчисления по амортизации. Сумма накладных расходов = 357,69 + 125,36 =
483,05 руб.
За счет использования бесплатных и trial-версий программных
продуктов удалось снизить стоимость эксплуатационных материалов до
нуля.
Таблица 8
Эксплуатационные материалы
№
Наименование
Стоимость 1 ед.,руб.
Сумма, руб.
1
Open Server
0 руб.
0 руб.
2
Rational Rose
0 руб.
0 руб.
3
Erwin Process Modeler
0 руб.
0 руб.
4
Erwin Data Modeler
0 руб.
0 руб.
5
NetBeans
0 руб.
0 руб.
Итого:
0 руб.
В таблице 9 отражены фактические расходы на разработку ИС.
Таблица 9
Калькуляция затрат на разработку программного продукта
Статья затрат
Сумма затрат, руб.
Общая сумма з/п
33827,2
Накладные расходы, в т.н. амортизация
483,05
Итого:
34310,25
Следовательно, затраты на разработку программного обеспечения
составили 34310,25 рублей.