4.4. Этапы проектирования: исследование проблемы, этап анализа, проектирование, реализация, внедрение, сопровождение.

 

В состав ЖЦ ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

4.5. Проектирование бд.

Проектирование БД осуществляется на логическом и физическом уровне.

Первым шагом в проектировании является логическое проектирование (концептуальное). Недостаточно продуманное логическое проектирование приводит к плохим результатам и к реконструкции уже существующей системы, поэтому необходимо тщательно прорабатывать логическую структуру основных компонентов и только потом браться за физическое проектирование.

Логическое проектирование играет решающую роль в обеспечении целостности данных.

Целостность данных - это взаимная согласованность отдельных фрагментов данных и их корректность.

Согласованность означает, что все порции данных должны быть единообразно смоделированны и включены в систему.

Данные не увязанные между собой - мусор и только объединенные и взаимоувязанные данные являются информацией.

Целостность является непременным условием превращения разрозненных данных в информацию.

На этапе логического проектирования можно предусмотреть и физическую реализацию (выбор средств, техники, СУБД и т.д.), т.е. ошибки допущенные на этапе логического проектирования могут привести не только к реорганизации логической структуры, но и к физическим переделкам.

В целом проектирование БД охватывает три области:

1. концептуальное проектирование- это проектирование конкретных объектов (сущностей), которые будут реализованы в БД . Под объектами понимаются таблицы, представления, индексы, триггеры, процедуры и функции;

2. Проектирование конкретных экранных форм, отчетов и программ, которые будут сопровождать данные в БД и обеспечивать запросы к этим данным;

3. При проектировании необходимо учитывать конкретную среду или технологию;

Проектирование - это поиск способа, удовлетворяющего требованиям средствами имеющейся технологии с учетом заданных ограничений.

4.5.1. Этапы проектирования.

1. Исследование проблемы и определение стратегии. На данном этапе производится оценка действительного объема проекта; получение определенных сущностей, связей и различных функций.

Этот этап требует тесного взаимодействия с основными пользователями проектируемой системы.

Получение от них информации и требований и системе и представления полученной информации в формализованном виде.

Затем осуществляется расчет затрат и сроки выполнения заказа.

2. Этап анализа - это подробное исследование бизнес-процессов и информации, для выполнения этих процессов.

После проведения этого этапа определяются сущности, атрибуты, связи, ключи и т.д.

1. Этап проектирования, выполняется на основе данных этапа анализа, результатом которого будет схема БД, определение и ограничение таблиц,  конкретные формы, отчеты и т.д.

2. Реализация, на данном этапе создаются и тестируются программные модули.

3. Внедрение.

4. Сопровождение.

При логическом проектировании выделяют три основных способа:

1. сбор информации об объекте исследования в рамках одной таблицы и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации.

2. формулирование знаний о системе и получении с помощью Сase-средства готовой схемы БД.

3. структурирование информации до исполнения в информационной системе в процессе проведения системы анализа на основе совокупности правил и рекомендаций.

4.5.2. Принципы логического (концептуального) проектирования. (сбор информации об объекте исследования в рамках одной таблицы и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации);

Рассмотрим процесс проектирования на частном примере.

Предположим необходимо спроектировать базу данных посреднической фирмы по продаже товаров. Собираем все данные по работе данной фирмы. Необходима фиксация следующих данных: дата сделки, тип сделки, заказчик, клиент, заказанный товар, количество заказанного товара, цена и т.д. Все эти данные фиксируются в пределах одной таблицы.

Дале производится дальнейшая декомпозиция данной таблицы на несколько таблиц: в частности, можно выделить таблицу Заказ; Контрагенты - в которой будут фиксироваться сведения как о заказчиках, так и о поставщиках; Товары - в которой будут перечислены типы товаров; Сотрудники - в которой приводятся сведения о сотрудниках фирмы и т.д.

В случае если необходимо дальнейшее уточнение таблиц - то производят дальнейшее разбиение таблиц.

После уточнения состава таблиц, которые будут составлять создаваемую базу данных производят связывание таблиц.

Другой пример.

Предположим, что две девушки решили создать ЧП, работающее в сфере услуг. Назовем фирму «Хозяюшка». Функции «Хозяюшка» входила помощь клиентам по уборке квартир, (уборка полов, окон, чистка ковров, кафеля и т.д. ).

Девушки весьма коммуникабельны и на основе опроса знакомых им удалось получить несколько заказов. Работа выполнялась очень тщательно, добросовестно и не дорого. Эти клиенты посоветовали их другим.

Когда заказов стало больше им пришлось привлекать дополнительных сотрудников. Сейчас их шесть.

Оценивалась стоимость каждого вида работы как произведение стоимости обработки 1 квадратного метра на количество метров.

Общая стоимость выполнения заказа - сумма стоимости каждого вида работ.

Затраты:

1. 30% прибыли с каждого заказа выплачивалась работнику;

2. на получку инвентаря и моющих средств;

3. на рекламу в виде листов и т.д.

4. на офис, но работали дома.

Первый шаг:

- создание концептуальной модели данных. На основе анализа поставленной задачи выделяют сущности.

- схематично изображают как связаны между собой эти сущности.

 

                                                                содержит

                        Производит            делает

                                                                              Выполняет

- определение типы связей между сущностями.

1. Клиент-заказ, один-ко-многим. Каждый заказ регистрируется на одного клиента, но каждый клиент может сделать много заказов.

2. Клиент-оплата, один-ко-многим, т.к. каждый клиент может провести много оплат.

3. Заказ-сотрудник, многие-ко-многим, один заказ может быть выполнен несколькими сотрудниками и каждый работник может выполнить несколько заказов.

4. Заказ-вид работ, многие-ко-многим, каждый заказ содержит много работ, каждая работа в нескольких заказах.

Второй шаг:

Отношения между таблицами регулируются тремя правилами:

1. Если две таблицы находятся в отношении один-к-одному, то поле ключ одной таблицы должно быть помешено и во вторую таблицу.

2. Есди две таблицы находятся в отношении один-ко-многим, то поле ключ таблицы 1 должно быть помещено в таблице 2 много.

3. Если две таблицы находятся в отношении многие-ко-многим, то требуется создать новую таблицу, содержащую ключи обеих исходных таблиц. Такая таблица называется таблицей пересечения.

Третий шаг:

Определение атрибутов и ключей.

Клиент заказ заказ-вид работ

                                   Заказ-сотрудник                    вид работ

                                                сотрудники

 

Важным моментом в процессе проектирования является возможность задания множества вопросов к своей БД.

Например:

1. Сколько клиентов было обслужено весной? (зимой, осенью)

2. Какие клиенты наиболее часто делают заказы, какие редко?

3. Какие сотрудники выполнили наибольшее количество заказов?