ТЕХНИЧЕСКОЕ ЗАДАНИЕ
1. Общие сведения
1.1. Наименование системы
Полное наименование: Информационная системы учета абонентов АТС.
Краткое наименование: ИС АТС.
1.2. Основания для проведения работ
Работа выполняется на основании договора № 32 от 19.03.11
1.3. Наименование организаций – Заказчика и Разработчика
1.3.1. Заказчик
Заказчик:ОАО«Заказчик»
Адрес фактический: г. Москва …
Телефон: +7 (495) 2222222
Факс: +7 (495) 2222222
1.3.2. Разработчик
Разработчик: ЗАО Разработчик
Адрес фактический: г. Москва …
Телефон: +7 (495) 3333333
Факс: +7 (495) 3333333
1.4. Плановые сроки начала и окончания работы
Сроки выполнения с 19.03.11 по 30.04.11
1.5. Источники и порядок финансирования
Финансирование производится согласно договора №32
1.6. Порядок оформления и предъявления заказчику результатов работ
Работы по созданию ИС сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.
2. Назначение и цели создания системы
2.1. Назначение системы
Информационная система предназначена для повышения надежности хранения и обработки информации.
Основным назначением ИС является хранение информационно-статистической деятельности в бизнес-процессах Заказчика.
В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:
1. хранение и обработка информации для отчетов;
2. анализ деятельности предприятия и клиентов ;
2.2. Цели создания системы
Информационная система создается с целью:
– обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки отчетности по показателям деятельности;
– создания единой системы отчетности по показателям деятельности;
– повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;
– обеспечения безопасности данных;
-облегчения работы с информацией;
В результате создания хранилища данных должны быть улучшены значения следующих показателей:
– время сбора и первичной обработки исходной информации;
– количество информационных систем, используемых для подготовки аналитической отчетности;
– время, затрачиваемое на информационно-аналитическую деятельность;
3. Характеристика объектов автоматизации
Объектом автоматизации выбран один из отделов организации. В рамках отдела было произведен анализ и выделение основных бизнес процессов.
Выделены следующие процессы в деятельности отдела АТС, в рамках которых производится анализ информации и вынесены соответствующие выводы о возможности их автоматизации:
4. Требования к системе
4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
База данных должна быть централизованной, т.е. все данные должны располагаться в центральном хранилище. Информационная система должна иметь трехуровневую архитектуру (можно привести общую схему, на которой определить уровни. Например, первый – источник, второй – хранилище, третий – отчетность).
В Системе предлагается выделить следующие функциональные подсистемы:
– подсистема обработки данных, которая предназначена для реализации процессов ввода данных необходима для наполнения подсистемы хранения данных;
– подсистема хранения данных, которая предназначена для хранения данных в таблицах;
– подсистема формирования и визуализации отчетности, которая предназначена для формирования отчетности.
Определяются требования к режимам функционирования системы.
-
Система должна быть стабильна в работе.
-
Необходимо установленное антивирусное программное обеспечение.
-
Персональный компьютер должен иметь бесперебойное питание.
4.1.2.3. Требования к надежности технических средств и программного обеспечения
К надежности оборудования предъявляются следующие требования:
– в качестве аппаратных платформ должны использоваться средства с средней надежностью;
– применение технических средств соответствующих классу решаемых задач;
– аппаратно-программный комплекс системы должен иметь возможность восстановления в случаях сбоев.
К надежности электроснабжения предъявляются следующие требования:
– с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация компьютеров источником бесперебойного питания с возможностью автономной работы системы не менее 5 минут;
– должно быть обеспечено бесперебойное питание активного сетевого оборудования.
4.1.2.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.
Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации – по методике разработчика, согласованной с заказчиком, т. е. Использование сети интернет для проверки надежности и целостности программного продукта.
4.1.3. Требования к эргономике и технической эстетике
База данных формирования и визуализации отчетности данных должна обеспечивать удобный для конечного пользователя интерфейс, отвечающий следующим требованиям.
В части внешнего оформления:
– интерфейсы подсистем должен быть типизированы;
В части диалога с пользователем:
– для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
В части процедур ввода-вывода данных:
– должна быть возможность многомерного анализа данных в табличном и графическом видах.
Требования к информационной безопасности
Обеспечение информационное безопасности информационной системы должно удовлетворять следующим требованиям:
– Защита системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.
– Защита системы должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.
– Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики базы данных (надежность, быстродействие, возможность изменения конфигурации).
– Разграничение прав доступа пользователей и администраторов Системы должно строиться по принципу “что не разрешено, то запрещено”.
4.1.3.1. Требования к антивирусной защите
Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов базы данных. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:
– централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;
– централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов;
– централизованное автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов;
– ведение журналов вирусной активности;
– администрирование всех антивирусных продуктов.
4.1.4. Требования к защите от влияния внешних воздействий
Применительно к программно-аппаратному окружению персонального компьютера предъявляются следующие требования к защите от влияния внешних воздействий.
Требования по стойкости, устойчивости и прочности к внешним воздействиям:
– Информационная система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % – 30 %);
– Информационная система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
4.2. Требования к функциям, выполняемым системой
В данном подразделе приводят:
Функция выполняемой системой – это хранение, обработка, и предоставление отчетности по данным из базы данных. База данных должна предоставлять формы для ввода данных и их редактирования. Формы базы данных должны корректно обрабатывать данные и заносить их в таблицы базы данных. База данных должна предоставлять отчеты по различным данным и давать сводный анализ по базе данных.
4.2.1. Подсистема сбора, обработки и загрузки данных
4.2.1.1 Перечень функций, задач подлежащей автоматизации
|
4.3. Требования к видам обеспечения
4.3.1. Требования к информационному обеспечению
Приводятся требования:
1) к составу, структуре и способам организации данных в системе;
2) к информационной совместимости со смежными системами;
3) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
4) по применению систем управления базами данных;
5) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
6) к защите данных от разрушений при авариях и сбоях в электропитании системы;
7) к контролю, хранению, обновлению и восстановлению данных;
8) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).
4.3.2.1. Требования по применению систем управления базами данных
Для реализации подсистемы хранения данных должна использоваться промышленная СУБД FoxPro8.4.3.2.2. Требования к контролю, хранению, обновлению и восстановлению данных
К контролю данных предъявляются следующие требования:
– система должна протоколировать все события, связанные с изменением своего информационного наполнения, и иметь возможность в случае сбоя в работе восстанавливать свое состояние, используя ранее запротоколированные изменения данных.
К хранению данных предъявляются следующие требования:
– хранение исторических данных в системе должно производиться не более чем за 5 (пять) предыдущих лет. По истечению данного срока данные должны переходить в архив;
– исторические данные, превышающие пятилетний порог, должны храниться на ленточном массиве с возможностью их восстановления.
К обновлению и восстановлению данных предъявляются следующие требования:
– для базы данных необходимо обеспечить резервное копирование его бинарных файлов раз в 2 недели и хранение копии на протяжении 2-х месяцев;
– для данных хранилища данных необходимо обеспечить резервное копирование и архивацию на ленточный массив в следующие промежутки времени:
-холодная копия – ежеквартально;
-логическая копия – ежемесячно (конец месяца);
-инкрементальное резервное копирование – еженедельно (воскресение);
-архивирование – ежеквартально;При реализации системы должны применяться следующие языки высокого уровня: SQL и д.р.
Должны выполняться следующие требования к кодированию и декодированию данных: Windows CP1251 для подсистемы хранения данных; Windows CP1251 информации, поступающей из систем-источников.
Для реализации алгоритмов манипулирования данными в базе данных необходимо использовать стандартный язык запроса к данным SQL.
4.3.2. Требования к программному обеспечению
Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:
-операционная система семейства Windows.
– наличие антивируса соответствующий пункту 4.1.7.2. Требования к антивирусной защите.
К обеспечению качества программных средств предъявляются следующие требования:
– функциональность должна обеспечиваться выполнением подсистемами всех их функций.
– надежность должна обеспечиваться за счет предупреждения ошибок – не допущения ошибок в готовых программных средств;
– легкость применения должна обеспечиваться за счет применения покупных программных средств;
– эффективность должна обеспечиваться за счет принятия подходящих, верных решений на разных этапах разработки программных средств и системы в целом;
– сопровождаемость должна обеспечиваться за счет высокого качества документации по сопровождению, а также за счет использования в программном тексте описания объектов и комментариев; использованием осмысленных (мнемонических) и устойчиво различимых имен объектов; размещением не больше одного оператора в строке текста программы; избеганием создания фрагментов текстов программ с неочевидным или скрытым смыслом.
– также на каждом этапе в разработке программных средств должна проводится проверка правильности принятых решений по разработке и применению готовых программных средств.
Необходимость согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ отсутствует.
4.3.4. Требования к организационному обеспечению
Приводятся:
1) требования к защите от ошибочных действий персонала системы.
Основными пользователями системы , являются сотрудники отдела автоматической телефонной станции Заказчика.
Обеспечивает эксплуатацию информационной системы подразделение информационных технологий Заказчика.
Состав сотрудников каждого из подразделений определяется штатным расписанием Заказчика, которое, в случае необходимости, может изменяться.
К защите от ошибочных действий персонала предъявляются следующие требования:
– должна быть предусмотрена система подтверждения легитимности пользователя при просмотре данных;
– для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности;
– для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.
5. Состав и содержание работ по созданию системы
Работы по созданию системы выполняются в три этапа:
Проектирование. Разработка эскизного проекта. Разработка технического проекта
Конкретные сроки выполнения стадий и этапов разработки и создания определяются планом выполнения работ, являющимся неотъемлемой частью договора на выполнение работ по настоящему частному техническому заданию.
6. Порядок контроля и приёмки системы
6.1. Виды и объем испытаний системы
Система подвергается испытаниям следующих видов:
1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.
Состав, объем и методы предварительных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация».
Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».
Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
В перечень основных мероприятий включают:
1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
2) изменения, которые необходимо осуществить в объекте автоматизации;
3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в техническое задание ;
4) создание необходимых для функционирования системы подразделений и служб;
5) сроки и порядок комплектования штата и обучения персонала.
Для создания условий функционирования информационной системы, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в настоящем техническом задании, и возможность эффективного её использования, в организации Заказчика должен быть проведен комплекс мероприятий.
8. Требования к документированию
В данном разделе приводят:
1) согласованный Разработчиком и Заказчиком перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли Заказчика;
перечень документов, выпускаемых на машинных носителях;
требования к микрофильмированию документации;
2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
Вся документация должна быть подготовлена и передана как в печатном, так и в электронном виде (в формате Microsoft Word).
9. Источники разработки
Перечисляются документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.
Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:
– Договор № 32 от 19.03.11
– ГОСТ 24.701-86 «Надежность автоматизированных систем управления».
– ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды».
– ГОСТ 21958-76 «Система “Человек-машина”. Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
– ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».
– ГОСТ Р 50571.22-2000 «Электроустановки зданий».
Библиографическое описание:
Сланбекова, А. Е. Разработка технического задания на создания базы данных для автоматизаций управления предприятием / А. Е. Сланбекова, А. А. Хасенова, Ш. К. Каменова. — Текст : непосредственный // Молодой ученый. — 2017. — № 3 (137). — С. 51-53. — URL: https://moluch.ru/archive/137/38425/ (дата обращения: 18.05.2023).
Базы данных — совокупность данных, организованная по определенным правилам, предусматривающая общие принципы описания, хранения, манипулирования данными, независимыми от прикладных программ.
Первым шагом при создании базы данных является создание плана, который одновременно выступает в качестве руководства при внедрении базы данных и в качестве ее функциональной спецификации в ходе ее дальнейшего использования.
В статье рассматривается создание технического задания базы данных предприятия розничной торговли. При разработке, придерживались следующие основные шаги:
– формулировка задачи;
– описание входных и выходных документов;
– требования к интерфейсу программы.
- Формулировка задачи
Рассматриваемое предприятие — юридическое лицо, которое выполняет функции оптово-розничной торговли и ведет непосредственную работу с клиентами.
В данном предприятии есть следующие отделы: склад, где хранится весь товар; две точки сбыта товара по оптово-розничной цене: базар; магазин, в котором также находится офис для учета движения товара.
Описание бизнес-процессов:
- Связь с поставщиками — исследование рынка поставщиков; поиск конкретных поставщиков; переговоры; составление отчетности по связям с поставщиками; контроль за выполнением вышеуказанных задач.
- Формирование заказа — планирование закупок; заключение договоров с поставщиками.
- Закупка товара и отправка его на склад — исполнение закупки товара; исполнение доставки товара на склад; обеспечение своевременной и качественной доставки товара на склад.
- Хранение товара на складе — прием товара по накладным; учет, размещение, хранение товара на складе; формирование партий товаров; Обеспечение погрузо-разгрузочных работ; контроль за выполнение вышеперечисленных работ.
- Реализация товара. У предпринимателя есть две точки, где товар продается потребителям по оптово-розничной цене.
Ранее весь учет велся, в бумажном виде и этот метод учета был не самый удобный, поэтому основной целью создания базы данных является автоматизация складского учета и учета продаж.
Перечень задач, решаемых СУБД:
- Ввод данных о клиенте, который закупает товар оптом:
– ФИО клиента (вводится с клавиатуры 30 символов);
– ИИН (вводится с клавиатуры 12 символов);
– Контактный телефон (заполняем целое значение с клавиатуры).
- Ввод данных о поставщиках:
– Поставщик (вводится с клавиатуры 20 символов);
– Адрес (вводится с клавиатуры 20 символов);
– Контактный телефон (заполняем целое значения с клавиатуры);
– ФИО директора (вводится с клавиатуры 30 символов).
- Поступление товара на склад:
– Наименование товара (вводится с клавиатуры 60 символов);
– Количество (заполняем целое значения с клавиатуры);
– Цена оптовая (заполняем целое значения с клавиатуры);
– Цена розничная (заполняем целое значения с клавиатуры);
– Цена поступления (заполняем целое значения с клавиатуры);
– Единица измерения (литр, штук);
– Поставщик (вводится с клавиатуры 20 символов);
– Дата поступления.
- Передача товара на реализацию:
– Отделение (магазин или рынок);
– Товар;
– Количество (заполняем целое значения с клавиатуры);
– Дата.
- Продажа товара:
– Отделение (магазин или рынок);
– Дата продажи;
– Наименование товара (вводится с клавиатуры 60 символов);
– Количество;
– Единица измерения (литр, штук);
– Покупатель (частное лицо или оптовый покупатель);
– Сумма (вычисляется по формуле);
– Цена продажи.
- Вывод накладной на печать:
– № накладной;
– Дата продажи;
– Наименование товара;
– Количество;
– Единица измерения (литр, штук);
– Цена продажи;
– Сумма (вычисляется по формуле);
– Покупатель (частное лицо или оптовый покупатель).
- Просмотр сведений о поставщиках — вывод данных о поставщиках (поставщик, адрес, контактный телефон, ФИО директора).
- Просмотр данных о товаре — вывод данных о товаре (будут выводиться все данные, описанные в пункте 3).
- Отчет реализации товара за месяц — формирование отчета, в котором будет отображаться список проданных за месяц товаров, сумма закупа и сумма продажи за месяц, а также чистая прибыль. Отчет должен быть выведен на печать;
- Очистка базы от ненужных данных (должны очищаться данные в таблице «Продажи», после месячного отчета по реализации товара).
- Просмотр накладной (поиск по номеру, покупателю или по дате).
- Описание входных ивыходных документов
Каждая программа имеет входной поток данных, и на основе этого потока ведутся нужные действия, такие как вычисления и нахождение необходимых данных. Входные данные, как правило, берутся из каких либо документов или файлов.
- При вводе данных о клиенте входными документами будут являться удостоверение личности и/или паспорт и ИИН, которые берутся у клиента.
- При вводе данных о поставщиках входными данными будут являться информация, отображаемая на расходной накладной (адрес, контактный телефон, наименование организации и т. п.), а выходными данными будет являться информация, о поставщиках отображаемая на экран.
- При поступлении товара на склад входными документами будут являться расходные накладные, которые берутся у поставщика, а выходными данными будет являться информация, о товаре отображаемая на экран.
- При продаже товара входными данными будет являться список товаров, который заказал покупатель, а выходным документом будет являться накладная, которая выписывается покупателю.
- Для отчета по реализации товара за месяц входными данными будет являться информация о реализации товара (список проданных за месяц товаров, сумма закупа и сумма продажи за месяц, и чистая прибыль), а выходным документом будет являться сам отчет, выведенный на печать.
- Требования кинтерфейсу
Интерфейс — это совокупность средств и правил, обеспечивающих взаимодействие устройств вычислительной системы и программ.
Пользовательский интерфейс — это общение между человеком и компьютером. Общий Пользовательский Доступ — это правила, которые объясняют диалог в терминах общих элементов, таких как: правила представления информации на экране, и правила интерактивной технологии такие, как правила реагирования человека-оператора на то, что представлено на экране.
Пользователь должен распознать информацию, которую представляет компьютер, понять (проанализировать) ее, и переходить к ответу. Ответ реализуется через интерактивную технологию, элементами которой могут быть такие действия как выбор объекта при помощи клавиши или мыши. Все это составляет вторую часть интерфейса, а именно язык действий.
Пользователи могут иметь представление о машинном интерфейсе, что он делает и как им работать. Некоторые из этих представлений формируются у пользователей в результате опыта работы другими машинами, такими как печатающее устройство, калькулятор, видеоигры, а также компьютерная система. Хороший пользовательский интерфейс использует этот опыт. Более развитые представления формируются от опыта работы пользователей с самим интерфейсом. Интерфейс помогает пользователям развивать представления, которые могут в дальнейшем использоваться при работе с другими прикладными интерфейсами.
Интерфейс разрабатываемого программного продукта должен быть понятным. Шрифт программы должен быть крупным, понятным для пользователя. Ввод и вывод информации в программе должен быть понятен, осуществляться удобно для пользователя. Цветовая гамма программы не должна быть сильно яркой, раздражительной, также она не должна напрягать, нервировать пользователя.
В данной программе должно быть предусмотрено отдельное меню, и все задачи будут решаться в отдельных окнах поэтому, в данной программе весь интерфейс будет оконным. Оконный интерфейс — способ организации полноэкранного интерфейса программы, в котором каждая интегральная часть располагается в окне — собственном субэкранном пространстве, находящемся в произвольном месте «над» основным экраном. Несколько окон, одновременно располагающихся на экране, могут перекрываться, виртуально находясь «выше» или «ниже» друг относительно друга.
Автоматизация учета на предприятиях розничной торговли способствует наращиванию темпов развития бизнеса, увеличению товарооборота, позволяет строить бизнес исходя из точных данных, принимать обоснованные решения в стратегическом планировании. Целью автоматизации торговли является повышение эффективности управления предприятием, и как следствие увеличение объема продаж и рост прибыльности.
Литература:
- Шупрута В. Н. Delphi 2006 на примерах (+ CD-ROM); — Москва, БХВ — Петербург, 2006. — 528 с.
- Осипов Д. В. Delphi. Профессиональное программирование — Санкт-Петербург, Символ-Плюс, 2006.- 1056 с.
- Дейт К. Дж. Введение в системы баз данных, 6-е издание; — К.; М.; СПб.: Издательский дом «Вильямс», 2008. — 848 с.
Основные термины (генерируются автоматически): целое значение, клавиатура, ввод данных, данные, контактный телефон, поставщик, реализация товара, Единица измерения, Наименование товара, символ.
-
Проектирование базы данных
Мы рассмотрели
лишь основные понятия баз данных, но,
тем не менее, поднимаем вопрос о
проектировании базы. Это не случайно.
Методически правильно начинать работу
с карандашом и листом бумаги в руках,
не используя компьютер. На данном этапе
он просто не нужен. Неоптимальные решения
и прямые ошибки, заложенные на этапе
проектирования, впоследствии очень
трудно устраняются, поэтому этот этап
является основополагающим.
-
Разработка технического задания.
Техническое задание
на проектирование базы данных должен
предоставить заказчик. Однако для этого
он должен владеть соответствующей
терминологией и знать, хотя бы в общих
чертах, технические возможности основных
систем управления базами данных. К
сожалению, на практике такое положение
встречается не всегда. Поэтому обычно
используют следующие подходы:
-
демонстрируют
заказчику работу аналогичной базы
данных, после чего согласовывают
спецификацию отличий; -
если аналога нет,
выясняют круг задач и потребностей
заказчика, после чего помогают ему
подготовить техническое задание.
При подготовке
технического заданиясоставляют:
-
список исходных
данных, с которыми работает заказчик; -
список выходных
данных, которые необходимы заказчику
для управления структурой своего
предприятия; -
список выходных
данных, которые не являются необходимыми
для заказчика, но которые он должен
предоставлять в другие организации
(в вышестоящие структуры, в органы
статистического учета, прочие
административные и контролирующие
организации).
При этом очень
важно не ограничиваться взаимодействием
с головным подразделением заказчика,
а провести обсуждение со всеми службами
и подразделениями, которые могут
оказаться поставщиками данных в базу
или их потребителями. Так, например, при
подготовке базы данных для учета
абитуриентов и студентов в высшем
учебном заведении необходимо не только
изучить документооборот ректората и
всех деканатов, но и понять, что хотели
бы получить от базы данных службы
университета.
Следует изучить
работу подразделений, распределяющих
учебную нагрузку преподавателей,
отвечающих за распределение аудиторного
фонда, за проживание студентов в общежитии
и других. В расчет должны приниматься
и такие службы, как библиотека, отдел
кадров и прочие. В любой момент может
выясниться, например, что администрация
библиотеки должна периодически поставлять
кому-то отчеты, характеризующие
читательскую активность студентов в
зависимости от пола, возраста и социального
положения. К возможным пожеланиям
заказчика следует готовиться на этапе
проектирования, до создания базы.
-
Разработка схемы данных
Выяснив основную
часть данных, которые заказчик потребляет
или поставляет, можно приступать к
созданию структуры базы, то ecть, структуры
ее основных таблиц.
1. Работа начинается
с составления генерального списка полей
– он может насчитывать десятки и даже
сотни позиций.
2. В соответствии
с типом данных, размещаемых в каждом
поле, определяют наиболее подходящий
тип для каждого поля.
3. Далее распределяют
поля генерального списка по базовым
таблицам. На первом этапе распределение
производят по функциональному признаку.
Цель – обеспечить, чтобы ввод данных в
одну таблицу производился, по возможности,
в рамках одного подразделения, а еще
лучше – на одном рабочем месте. Наметив
столько таблиц, сколько подразделений
охватывает база данных, приступают к
дальнейшему делению таблиц. Критерием
необходимости деления является факт
множественного повтора данных в соседних
записях. На рис. 7 показана таблица
AviaPark, у которой в полеN_Comp(название
авиакомпании) иN_La(тип воздушного судна) наблюдается
повтор данных. Это явное свидетельство
того, что таблицу надо поделить на три
взаимосвязанных таблицы.
4. В каждой из таблиц
намечают ключевое поле. В качестве
такового выбирают поле, данные в котором
повторяться не могут. В том случае, когда
подобное поле невозможно выделить
естественным образом, его вводят
дополнительно. Например, для таблицы
AirCompany(рис.7) данных об
авиакомпаниях таким полем может служить
порядковый номер. Данная таблица
становится каталогом авиакомпаний, в
которой каждый объект имеет свой
уникальный номер. Для таблицы, в которой,
например, содержатся расписания занятий,
такого поля можно и не найти, но его
можно создать искусственным: комбинированием
полей «Время занятия» и «Номер аудитории».
Эта комбинация неповторима, так как в
одной аудитории в одно и то же время не
принято проводить два различных занятия.
Если в таблице
вообще нет никаких полей, которые можно
было бы использовать как ключевые,
всегда можно ввести дополнительное
поле типа Счетчик – оно не может содержать
повторяющихся данных по определению.
|
|
|
|
|
|
|
|
Рис. 7. Если данные
в поле начинают повторяться, это признак
того, что
таблицы следует поделить (провести
нормализацию)
5. С помощью карандаша
и бумаги расчерчивают связи между
таблицами. На рис. 8 показан пример
взаимосвязи между группой таблиц,
составляющих одну базу данных. Такой
чертеж называется схемой данных.
Существует несколько
типов возможных связей между таблицами.
Наиболее распространенными являются
связи «один ко многим» и «один к одному».
Связь между
таблицами организуется на основе общего
поля, причем в одной из таблиц оно
обязательно должно быть ключевым, то
есть на стороне «один» должно выступать
ключевое поле, содержащее уникальные,
неповторяющиеся значения. Значения на
стороне «многие» могут повторяться.
Рис. 8. Схема связей
между таблицами (схема данных)
На схеме данных
эти поля соединены линией связи. С
одной стороны эта линия маркирована
знаком «1», с другой стороны — значком
«бесконечность». Это графический метод
изображения связи «один ко многим». Про
подобные таблицы говорят, что онисвязаны
реляционными отношениями.
Соответственно,
системы управления, способные работать
со связанными таблицами, называют
системами управления реляционными
базами данных,а схему данных в
технической литературе могут называтьсхемой реляционных отношений.
6. Разработкой
схемы данных заканчивается «бумажный»
этап работы над техническим предложением.
Эту схему можно согласовать с заказчиком,
после чего приступать к непосредственному
созданию базы данных.
Следует помнить,
что по ходу разработки проекта заказчику
непременно будут приходить в голову
новые идеи. На всех этапах проектирования
он стремится охватить единой системой
все новые и новые подразделения и службы
предприятия.
Возможность гибкого
исполнения его пожеланий во многом
определяется квалификацией разработчика
базы данных. Если схема данных составлена
правильно, подключать к базе новые
таблицы нетрудно. Если структура базы
нерациональна, разработчик может
испытать серьезные трудности и войти
в противоречия с заказчиком.
Противоречия
исполнителя с заказчиком всегда
свидетельствуют о недостаточной
квалификации исполнителя. Именно поэтому
этап предварительного проектирования
базы данных следует считать основным.
От его успеха зависит, насколько база
данных станет эффективной и будут ли с
ней работать пользователи. Если
отмечается, что пользователи базы
«саботируют» ее эксплуатацию и
предпочитают работать традиционными
методами, это говорит не о низкой
квалификации пользователей, а о
недостаточной квалификации разработчика
базы.
На этом этапе
завершается предварительное проектирование
базы данных, и на следующем этапе
начинается ее непосредственная
разработка. С этого момента следует
начать работу с системой управления
базами данных.
Из приведенного
примера по работе с базой данных были
отмечены такие этапы как составление
технического задания и проектирование.
Однако при разработке информационных
систем, в основу которых положена
концепция баз данных, имеют место
следующие этапы: разработка требований
(составление технического задания),
анализ предметной области, проектирование
информационной системы и базы данных,
разработка базы данных и приложения,
внедрение, сопровождение информационной
системы и т.д.
Все эти этапы или
процессы составляют так называемый
жизненный циклинформационной
системы, который начинается с момента
возникновения необходимости некоторой
информационной системы и заканчивается
моментом ее полного выхода из употребления.
Эти этапы чередуются в определенной
последовательности, которая представлена
моделью жизненного цикла информационной
системы (рис.9,10,11). В зависимости от
специфики информационной системы
применяются несколько моделей: каскадная,
спиральная,V-образная и
т.д.
Рис.
9. Каскадная модель ЖЦ ИС
Рис.
10. Поэтапная модель с промежуточным
контролем
Рис.
11. Спиральная модель ЖЦ ИС
На практике
наибольшее распространение получили
две основные модели жизненного цикла:
-
каскаднаямодель (характерна для периода 1970-1985
гг.); -
спиральнаямодель (характерна для периода после
1986.г.).
Существует целый
ряд стандартов, регламентирующих
жизненный цикл программного обеспечения
(и информационных систем в том числе),
а в некоторых случаях и процессы
разработки.
Соседние файлы в папке лекции
- #
- #
- #
- #
- #
- #
- #
