Переход от анализа к проектированию (концептуальная разработка, конструирование )

advertisement
Переход от анализа к проектированию
(концептуальная разработка, конструирование )
ОБЗОР

На данном этапе




Совершается переход от анализа к
проектированию
Обсуждаются проблемы, связанные с
проектированием элементов новой системы
Описываются все виды деятельности фазы
проектирования
Описывается проект сети и архитектуры системы
Если «Анализ» концентрируется на том, что
система должна делать – бизнес требования,
 То «Проектирование» ориентируется в
направлении как система будет построена —
определение структурных компонентов

2
ЭЛЕМЕНТЫ ПРОЕКТА


Фаза концептуальной разработки (проектирование) ИС
предназначается для реализации требований
пользователей и решения других проблем,
выявленных на этапе анализа системы
Проектирование – процесс описания, формирования и
структуризации компонентов ИС на уровне проекта
архитектуры и на уровне подробного проектирования




Модель проекта тесно связана с моделью реализации и в
этой связи можно говорить о проектировании и
конструировании как об одной фазе
Концентрируется на подготовке к конструированию и
формирует подсистемы как независимые компоненты
системы
Аналогично разработке конструкторской документации
Решаются три вопроса



Какие компоненты нуждаются в проектировании?
Что является входом и выходом процесса проектирования?
Как выполняется проект системы?
3
ВХОДЫ ПРОЕКТИРОВАНИЯ
АНАЛИЗ
 Цели - понимание:
 Событий бизнеса и
процессов
 Требования к видам
деятельности и
обработке системы
 Требования к
хранилищу
Модели и
информации документы
этапа
анализа
ПРОЕКТИРОВАНИЕ
 Цели – Определить,
специфицировать и
структурировать
компоненты решения
системы, которое
будет служить в
качестве проектной
документация для
конструирования,
которое, как правило,
выполняется
параллельно
4
КОНЦЕПТУАЛЬНЫЕ ПРОЕКТНЫЕ
РЕШЕНИЯ












Обработка данных - Централизованная, децентрализованная,
распределенная
Хранение данных – Магнитная лента, жесткие диски, CD,
твердая копия
Структура данных - Файловая или база данных
Доступ к файлам – Прямой, последовательный, индексный
Ввод данных-С клавиатуры, голосом, electronic data interchange
(EDI), Optical Character Recognition (OCR), point-of-sale (POS),
Место обработки - В компании или в сторонней организации
Обработка на – Мэйнфрейм, кластере или персональной ЭВМ
Вывод информации - На монитор, на бумагу, на оборотный
документ, голосом
Коммуникационный канал - Телефонная линия, коаксиальный
кабель, оптоволокно, спутниковый канал, радиоканал
Обработка операций - Ручная, пакетная, онлайновая в
реальном времени, workflow (выбор уровня автоматизации)
Приобретение программ - Готовые, модифицированные,
разработанные
Выбор и приобретение средств интеграции и среды middleware
(связующее программное обеспечение)(.NET, J2EE, CORBA…)
5
ПЕРЕХОД ОТ АНАЛИЗА К ПРОЕКТИРОВАНИЮ


Проектирование

Преобразует функциональные модели из анализа
в модели, которые представляют решение

Концентрируется на технических вопросах

В меньшей степени требует вовлечение
пользователей чем анализ
Проектирование может использовать
структурированный или OO подходы

База данных может быть реляционная, объектноориентированная или гибридная

Разрабатывается пользовательский интерфейс
6
КОМПОНЕНТЫ ПРОЕКТА СИСТЕМЫ
7
СТРУКТУРНЫЕ
И ОО МОДЕЛИ
8
ВИДЫ ДЕЯТЕЛЬНОСТИ ПРОЕКТИРОВАНИЯ
(СОСТАВ ПРОЕКТА)
Проектирование и интегрирование сети
 Проектирование архитектуры
приложения
 Проектирование пользовательского
интерфейса
 Проектирование и интегрирование базы
данных
 Проектирование и интегрирование
системы управления

9
СОСТАВ ПРОЕКТА И ВОПРОСЫ
Вид
деятельности
Ключевые вопросы
Проектирование и
интегрирование сети
Имеем ли мы подробную спецификацию как различные компоненты
системы будут связываться внутри организации
Проектирование
архитектуры
приложения и ПО
Имеем ли мы подробную спецификацию как каждая операция
выполняется людьми и компьютером
Проектирование
пользовательских
интерфейсов
Имеем ли мы подробную спецификацию как все пользователи
взаимодействуют с системой
Проектирование
интерфейсов системы
Имеем ли мы подробную спецификацию как система будет работать с
другими системами внутри и вне организации
Проектирование и
интегрирование базы
данных
Имеем ли мы подробную спецификацию как и где система будет
хранить всю информацию, необходимую организации
Прототипирование
деталей проектирования
Есть ли у нас прототипы для обеспечения того, чтобы все решения
проекта были полностью понятны
Проектирование и
интегрирование системы
управления
Имеем ли мы подробную спецификацию чтобы гарантирвать, что
система функционирует правильно и что поддерживаемые системой
10
данные надежны и безопасны
КРИТЕРИИ КАЧЕСТВА ПРОЕКТА
Удовлетворяет
требованиям системы
 Устойчив к
изменениям этапа
реализации
 Легко поддерживать
 Понятно как
реализовать
 Легко адаптируется
к изменениям
требований


В начале этапа
проектирования
должна быть
специфицирована
используемая для
реализации
технология,
поскольку это
решение будет
воздействовать на
архитектуру
приложения и весь
проект.
11
ПРОЕКТИРОВАНИЕ И ИНТЕГРАЦИЯ СЕТИ

Сетевые специалисты развивают сеть на основе
стратегического плана (возможно, на основе
структурированной кабельной системы).

Команда разработчиков обычно интегрирует систему в
существующую инфраструктуру сети.

Описываются протоколы связи и промежуточное ПО,
соединяющее уровни.

Описывается обработка и связность для каждого места
размещения системы.

Технические требования пропускной способности должны
удовлетворяться посредством сети.

Технические вопросы должны решаться сетевыми
специалистами.

Получение сетевых адресов, надежность, безопасность, пропускная
способность, синхронизация (таблиц маршрутизации)
12
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ

Определяет как прецеденты выполняются в
системе

На этапе анализа система описана как
логическая модель деятельности системы


После выбора варианта проектирования,
подробная компьютерная обработка
разрабатывается как физическая модель,
такая как физическая диаграмма потока
данных и структурная схема (традиционный
подход) или диаграммы классов и
взаимодействия (ОО подход)
Подходы различаются зависимости от среды
разработки и развертывания (.NET, JavaEE)
13
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ




Качество пользовательского языка является
критическим аспектом системы
Проект пользовательского интерфейса определяет
как пользователь взаимодействует с системой

GUI – окна, диалоговые окна, мышь

Звук, видео, голосовые команды
Для пользователя системы пользовательский
интерфейс и есть система
Специалисты пользовательского интерфейса –
проектировщик интерфейса, консультант удобства,
специалист по социальной психологии
14
ПРОЕКТИРОВАНИЕ ИНТЕРФЕЙСОВ
СИСТЕМЫ

Системные интерфейсы позволяют системам
разделять и обмениваться информацией
Внутренние системы организации
 Интерфейсы с системами вне организации
 Новые системные интерфейсы с пакетами
приложений, которые приобретает и
устанавливает организация

Системные интерфейсы могут быть сложными
 Организациям могут потребоваться весьма
специальные технические знания для работы с
этими интерфейсами

15
ПРОЕКТИРОВАНИЕ И
ИНТЕГРИРОВАНИЕ БАЗЫ ДАННЫХ
Модель данных анализа системы используется
для создания физической модели данных
 Набор традиционных компьютерных файлов,
реляционные базы данных и/или объектноориентированные базы данных
 Технические требования,

время ответа,
 производительность базы данных


В процессе разработки выполняются


Настройка производительности (Буферы обмена,
индексирование,…)
Интеграция между новой и существующей базой
данных
16
ПРОТОТИПИРОВАНИЕ
РЕШЕНИЙ
ПРОЕКТА
Продолжается создание и оценка прототипов во
время фазы проектирования
 Прототипы подтверждает выбор этапа
проектирования

Базы данных (My SQL, MS SQL, Oracle,…)
 Архитектуру сети
 Систему управления
 Среда программирования- Платформа: JavaEE,
.NET;Сервер: SAS, Apache, Jboss, WebLogic, IBM, IIS;
IDE: Eclipse, NetBeans, VisualStudio,…..


RAD проектирует прототипы, развивающиеся в
готовую систему
17
ПРОЕКТИРОВАНИЕ И ИНТЕГРИРОВАНИЕ
СИСТЕМЫ УПРАВЛЕНИЯ (БЕЗОПАСНОСТЬ
СИСТЕМЫ)

Заключительная проектная деятельность для
обеспечения системе необходимого уровня
безопасности (управление системой) для
защиты активов организации, часто, как
отдельная подсистема.
Доступность – это возможность за приемлемое
время получить требуемую информационную
услугу.
 Целостность - актуальность и непротиворечивость
информации, ее защищенность от разрушения и
несанкционированного изменения.
 Конфиденциальность – это защита от
несанкционированного доступа к информации

18
ЗАДАЧИ СИСТЕМЫ УПРАВЛЕНИЯ

Система управления требуются для всех
подсистем проекта:





User interface – разграничение доступа
авторизованным пользователям
System interface – защита от других систем
Application architecture – обеспечивает управление
транзакциями
Database – защита от сбоев аппаратного и
программного обеспечения
Network design – защита коммуникаций
19
ПРОБЛЕМЫ СРЕДЫ
 АО
чувствительно к проблемам
электрического питания. (Uninterruptable
power supplies (UPS) – источник
бесперебойного питания) и фильтры
рекомендуются для всех систем.
 Кабельные системы также должны быть
защищены. (Молниязащита)
 Проектировать системы противопожарной
безопасности
 Также критично рассеяние тепла и
предотвращение влажности (системы
кондиционирования).
 (Кластер- UPS 10 Kva, прецессионный
20
кондиционер)
ВОССТАНОВЛЕНИЕ ПОСЛЕ РАЗРУШЕНИЯ
Надежность системы обеспечивается избыточностью
наиболее важных компонент АО.
 Планируются процедуры по сохранению и
восстановлению ключевого ПО и данных, а также
инсталляцию АО. (Сервер резервного копирования
следует размещать в другом здании)

21
ПРОЕКТ ТОПОЛОГИИ
СЕТИ
 Потребности
22
сети для функционирования ИС
интегрируются в сетевую инфраструктуру
 Описываются виды обработки и связность для
каждого места размещения элементов
системы
 Описываются коммуникационные протоколы
и промежуточное ПО для соединения уровней
 Обеспечивается достаточная пропускная
способность сети
Объем данных по типам доступа (по различным
протоколам: http, mms,…) и средняя величина
Пиковое значение производительности в минуту
или час
22
КОМПЬЮТЕРНАЯ СЕТЬ
 Набор
23
линий передачи (UTP,
оптоволокно,…), специального
оборудования (сетевые карты,
коммутаторы,…) и коммуникационных
протоколов различных уровней OSI
 Позволяет взаимодействовать различным
пользователям и компьютерным системам
 Local area network (LAN)
протяженностью менее чем один километр
– соединяет компьютеры внутри одного
здания
 Wide area network (WAN) превышает
один километр – предполагает значительно
большие расстояния, глобальные
 Router – направляет информацию внутри
и между сетями
23
ВОЗМОЖНАЯ
КОНФИГУРАЦИЯ СЕТИ
24
24
INTERNET, INTRANET И EXTRANET
Internet – глобальное объединение сетей,
которые используют сетевые протоколы TCP/IP
 Intranets

Частная сеть, использующая те же самые
протоколы TCP/IP что и Internet
 Ограничена для внутренних пользователей, как
правило, использованием использование
приватных адресов


Extranets

Intranet сеть, которая расширяется за пределы
организации
25
ПРИМЕР ДИАГРАММЫ СЕТИ
26
26
СРЕДА РАЗВЕРТЫВАНИЯ ИС

Среда развертывания объединяет анализ и
проектирование на основе
Аппаратного обеспечения – платформа
 Системное программное обеспечения
 Архитектура сети

Среда развертывания – окружение в которой
ИС будет функционировать (MS ACCESS, IISTomcat-Jboss, Java-C#, Spring, Seam,
Hibernate…)
 Используются шаблоны проектирования и
архитектуры промежуточного ПО (Framework)
для создания программного обеспечения
приложения (JSP-Forms, …)

27
АРХИТЕКТУРА СИСТЕМЫ



Вообще говоря, модели архитектур системы
обеспечивает высокий уровень на основе
представления взаимодействующих частей,
образующих систему.
Моделируются подсистемы, интерфейсы, компоненты,
модули и правила взаимодействия между подсистемами
(моделируется множество структурных аспектов системы)
–(Модули (классы), Компоненты и коннекторы,
Размещение элементов системы)
Сложные в аппаратном и сетевом отношении системы
требуют более сложных моделей архитектур
28
РАЗНОВИДНОСТИ АРХИТЕКТУР
ПРИЛОЖЕНИЙ ИС

Существуют следующие широко используемые
подходы (pattern) для архитектуры приложения
Серверная архитектура
 Архитектура Client/server
 Трех-уровневая client/server архитектура
 Архитектура Web services
 Internet и Web-based архитектура
приложений

29
ФУНКЦИИ ПРИЛОЖЕНИЙ ИС
Презентационная логика (т.е.,
пользовательский интерфейс-HCI, )
 Логика приложения (обработка бизнеслогики)
 Логика доступа к базе данных (т.е.
обработка, требующая доступа к данным–
запрос SQL)
 База данных(т.е. файлы данных)
 Существует по крайней мере две альтернативы
для реализации архитектуры обработки:

30
Централизованные системы
Распределенные вычисления
30
ЦЕНТРАЛИЗОВАННЫЕ СИСТЕМЫ
31
• До 1970’s была только одна среда обработки– мэйнфрейм
компьютерная система в центре
• Варианты определялись разновидностью устройств вводавывода (например, система кодирования на перфораторе,
система записи на магнитную ленту или интерактивный ввод с
видеотерминала), а также возможность удаленного
взаимодействия с устройствами ввода, вывода
• Хотя в настоящее время мэйнфреймы не являются
предпочтительным платформами для применения ИС, они всееще широко используются как подсистемы больших, иногда
распределенных ИС или крупномасштабных приложений
пакетной обработки (например, банковские системы, страховые
системы, правительственные системы и т.п.), в которых:
– Нет необходимости обрабатывать транзакции в реальном
масштабе времени
– Централизованная линия ввода данных
– Большое количество периодических выводов производится
31
системой
Существует три типа централизованных систем : один
компьютер, кластер and мультисистема архитектуры
Архитектура на основе одного компьютера
• Все ресурсы ИС размещаются на одной компьютерной системе и
непосредственно соединенным к системе внешних устройствах
• Пользователи взаимодействуют с системой через терминалы,
подключенные к системе
• Требуется, чтобы все пользователи располагались в непосредственной
близости от компьютера
• Все 4 функциональные приложения реализуются на мэйнфрейме (сервер) –
серверная архитектура
Преимущества:
• Простота поддержки: относительно легко проектировать, строить и
эксплуатировать
Недостатки:
• Ограничения мощности делают непрактичной или неиспользуемой такую
архитектуру для больших ИС: не обеспечивает необходимый уровень
обработки, хранения данных и задач представления данных. Однако, многие
32
системы требуют большую мощность вычислений чем может обеспечить
один компьютер (требуется кластеризация или мультикомпьютерная
архитектура)
СЕРВЕРНАЯ АРХИТЕКТУРА
33
КОМПЬЮТЕР И МНОГОУРОВНЕВАЯ АРХИТЕКТУРА

Компьютерная архитектура из одного
компьютера
На основе мэйнфрейма
 Ограничена ресурсами одного компьютера


Кластерная и мультикомпьютерная архитектура
Группа компьютеров для обеспечения необходимой
мощности обработки и хранения данных
 Кластер действует как единая система (Кластеры:
отказоустойчивые- High-availability clusters -HA ,
сбалансированной нагрузки - Load balancing clusters,
вычислительные - HPC)
 Мультикомпьютерное аппаратное и системное
программное обеспечение отличаются от кластерного

34
КЛАСТЕРНАЯ АРХИТЕКТУРА
35
• Clustered architecture группа (или cluster) компьютеров
одного типа, на которых установлена аналогичная
операционная система и распределяются ресурсы
• Компьютеры одной модели и от одного производителя,
объединенные в сеть (как правило высокоскоростную)
• Программы приложения могут выполняться на любом
компьютере кластера без какой-либо модификации благодаря
аналогичному аппаратному и системному программному
обеспечению
• Кластер действует как одна большая компьютерная система
(перемещение программ и доступ к ресурсам других машин
осуществляется быстро и эффективно благодаря скоростному
и прямому взаимодействию на уровне операционной системы)
• Как правило один компьютер (master-управляющий)
35
действует как точка входа, а другие функционируют как
подчиненные (slave) компьютеры
Мультикомпьютерная архитектура
• Мультикомпьютерная архитектура – группа различных компьютеров,
которые связаны друг с другом, но не требуется, чтобы платформа и
операционная система были аналогичными как в кластерной архитектуре
• Аппаратное и программное обеспечение не позволяет перемещать
программы между компьютерами (вместо этого, ресурсы закрепляются за
каждой компьютерной системой)
• Система функционирует как одна большая компьютерная система
• Может иметь центральный компьютер и подчиненные компьютеры
–Главный компьютер может выполнять программы и поддерживать базу
данных
–Коммуникационный компьютер может управлять всеми
коммуникациями с другими компьютерами и простыми терминалами
Замечания по централизованным системам
• Кластерная система может быть экономически более эффективна и
обеспечивать большие общие возможности если используются аналогичные
операционные системы и аппаратное обеспечение
• Мультикомпьютерные архитектуры хороши, когда централизованная
система может быть декомпозирована на относительно независимые
36
подсистемы (для каждой возможна собственная ОС и аппаратная
платформа)
АРХИТЕКТУРЫ
С ОДНИМ КОМПЬЮТЕРОМ,
КЛАСТЕР И НЕСКОЛЬКО КОМПЬЮТЕРОВ
37
37
РАСПРЕДЕЛЕННАЯ АРХИТЕКТУРА
Система распределяется между
несколькими компьютерами,
установленными в различных местах–
распределенные вычисления
 Основывается на сетевых коммуникациях
для обеспечения связности
 Client/server архитектура является
преобладающей моделью для
распределенных вычислений

38
38
CLIENT/SERVER АРХИТЕКТУРА

39
Предпочтительная модель архитектуры для распределения
ресурсов
• Двух-уровневая архитектура делит процессы ИС на два
класса:
– Server: управляет ресурсами системы и обеспечивает
доступ к этим ресурсам к другим компьютерам в сети
– Client computer: использует коммуникационный
интерфейс для запроса сервисов с других компьютерах сети
• Программное обеспечение, которое реализует
коммуникационный протокол в сети называется
промежуточным (middleware)
Преимущества– гибкость развертывания
Размещение, масштабируемость, сопровождение

Недостатки– сложность
Производительность, безопасность и надежность
39
ВЗАИМОДЕЙСТВИЕ НЕСКОЛЬКИХ
КЛИЕНТОВ С ОДНИМ СЕРВЕРОМ
40
40
АРХИТЕКТУРА «ТОЛСТЫЙ КЛИЕНТ»
41
АРХИТЕКТУРА «ТОЛСТЫЙ СЕРВЕР»
42
42
ТРЕХ-УРОВНЕВАЯ АРХИТЕКТУРАCLIENT/SERVER
• Уровень данных (data layer) конфигурации клиент-сервера,
который управляет хранением данных, реализованных как одна
или несколько баз данных
• Уровень бизнес-логики (business logic) содержит программы,
которые реализуют правила и процедуры обработки бизнеса (или
программная логика приложения)
• Уровень презентации (view layer) содержит пользовательский
интерфейс и другие компоненты для доступа к системе
(принимает ввод пользователя, а также формирует и представляет
обработанные результаты)
43
• Этот подход называется Трех-уровневая архитектура (tree-layer
architecture)
 ИС, разделенная на три уровня относительно легко
распределяется и реплицируется в сети (взаимодействие между
уровнями всегда выполняется в форме запрос или ответ)
 Репликация - Механизм синхронизации содержимого нескольких
копий объекта (обычно таблицы). Изменения, сделанные в любой
из копий объекта, могут быть распространены во все копии
43
 Это делает относительно независимыми уровни, и таким образом,
они могут помещаться на различные компьютеры системы с
сетевой связностью и поддержкой промежуточного ПО
Трех-уровневая архитектура
44
ФУНКЦИИ ТРЕХ-УРОВНЕВОГО
ПРИЛОЖЕНИЯ
45
N-уровневая архитектура
Когда сложные требования обработки или ресурсов данных, то
трех-уровневая архитектура может быть расширена на большее
количество уровней (n-layer или n-tiered architecture)
Следующий слайд показывает пример в котором уровень данных
разделен на отдельные уровни: объединенный сервер и сервера,
которые контролируют отдельные базы данных (marketing,
production, accounting).
Уровень бизнес-логики взаимодействует с объединенным
сервером баз данных, который обеспечивает унифицированное
представление, данных, сохраненных в нескольких различных базах
данных.
Ответы от отдельных серверов баз данных объединяются для
создания одного ответа, который посылается на уровень бизнеслогики.
46
N-уровневая архитектура
47
4-Х УРОВНЕВАЯ АРХИТЕКТУРА
48
АРХИТЕКТУРА ПРИЛОЖЕНИЙ НА ОСНОВЕ
WEB
Обычно используются Web-протоколы и браузеры в
качестве клиентских приложений
 Достоинства

Доступность клиентского ПО
 Низкая стоимость связи (используется развитая сеть Internet)
 Широко распространенные стандарты
 Отсутствие необходимости или автоматизация
распространения компонентов системы


Недостатки
Бреши в безопасности
 Изменение параметров пропускной способности сети –
зависимость от загрузки каналов связи
 Пропускная способность может быть ограничена
 Подвержена перерывам в работе

49
АРХИТЕКТУРА WEB-СЕРВИСОВ
Клиент/серверная архитектура
 «Упаковывает» программную
функциональность в серверные процессы
(“сервисы”)
 Делает сервисы доступными приложениям
через Web протоколы (http) на основе TCP/IP
 Web-сервисы доступны как внутренним так и
внешним приложениям


Разработчики могут создавать приложения,
используя существующие Web-сервисы
50
АРХИТЕКТУРА WEB СЕРВИСОВ

Universal Description,
Discovery, and Integration
(UDDI)

Web Service Definition
Language (WSDL)

Simple Object Access Protocol
(SOAP
)
51
ПРОМЕЖУТОЧНОЕ ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ (MIDDLEWARE)
Аспект распределенного приложения
 Расширяет функциональность систем
программирования, позволяет объединять части
приложения и обеспечивает передачу запросов и
данных между ними
 Отслеживает обработку транзакций, вызовы
программ через сеть (object request brokersORB), каталог Web сервисов и мн. мн. другое
 Проектировщики применяют стандартный набор
компонент и протоколов, объединенных в
промежуточное ПО (J2EE, JavaEE, .NET 2.0, 3.0,
3.5)

52
ПРОЕКТИРОВАНИЕ МОДУЛЬНОЙ СТРУКТУРЫ
Цель проектирования – создать правильный
проект, но правильных может быть много
 Найти наилучший из возможных проектов с
учетом ограничений и требований системы, а
также физической и социальной среды ее
функционирования.
 Один из критериев оценки проекта – модульность
 Система является модульной если существуют
отдельные модули, реализованные отдельно и
изменения одного модуля минимально
воздействуют на другие модули.
 Модифицируемость, понятность,
сопровождаемость – производные параметры.

53
СЦЕПЛЕНИЕ И СВЯЗНОСТЬ
 Один
из фундаментальных принципов
проектирования модулей (классов)
заключается в том, что большая система
должна быть расчленена на обозримые
элементы.
 Расчленение должно быть выполнено
таким образом, чтобы модули были как
можно более независимы (критерий
сцепления - coupling), и чтобы каждый
модуль выполнял единственную
(связанную с общей задачей) функцию
(критерий связности - cohesion).
 ЦЕЛЬ => Low coupling & High cohesion
54
СЦЕПЛЕНИЕ - COUPLING
Уменьшение количества соединений между двумя
модулями приводит к уменьшению вероятности
появления “волнового эффекта” (ошибка в одном
модуле влияет на работу других модулей);
 Минимизация риска появления “эффекта ряби”
(внесение изменений, например, при исправлении
ошибки, приводит к появлению новых ошибок),
т.к. изменение влияет на минимальное количество
модулей;
 При сопровождении модуля отсутствие
необходимости беспокоиться о внутренних деталях
других модулей;
 Упрощение системы для понимания, насколько

это возможно.
55
СЦЕПЛЕНИЕ
Задача – для уменьшения сцепления необходимо
уменьшать связи между модулями
 Связь увеличивается в зависимости от сложности и
неясности интерфейса между модулями
 Уменьшение сцепление может быть достигнуто за
счет комбинирования трех следующих способов

действий:
Удаления необязательных связей;
 Сокращение количества необходимых связей;
 Упрощение необходимых связей.

56
ТИПЫ




СЦЕПЛЕНИЯ
На практике существуют три основных типа
сцепления, используемых системными
проектировщиками для связи модулей:
нормальное сцепление,
сцепление по общей области и
сцепление по содержимому.
57
НОРМАЛЬНОЕ




СЦЕПЛЕНИЕ
Два модуля А и В являются нормально
сцепленными, если
А вызывает В,
В возвращает управление А,
вся информация, передаваемая между А и В,
представляется значениями параметров при
вызове.
58
НОРМАЛЬНОЕ




СЦЕПЛЕНИЕ
Существует три типа нормального сцепления:
сцепление по данным (data coupling) ,
сцепление по структуре (stamp coupling) ,
сцепление по управлению (control coupling ).
59
СЦЕПЛЕНИЕ
ПО ДАННЫМ
Два модуля сцеплены по данным, если они
взаимодействуют через передачу параметров и
при этом каждый параметр является
элементарным информационным объектом.
 В случае небольшого количества передаваемых
параметров сцепление по данным обладает
наилучшими характеристиками

60
СЦЕПЛЕНИЕ ПО СТРУКТУРЕ
Если один модуль посылает другому составной
информационный объект, т.е. объект, имеющий
внутреннюю структуру.
 Примером составного объекта может быть объект
Данные о клиенте, включающий в себе поля:
Название организации, Почтовый адрес, Номер
счета
 В случае необходимости передачи одного
значения не рекомендуется передавать всю
запись

61
СЦЕПЛЕНИЕ ПО УПРАВЛЕНИЮ
 Если
один посылает другому информационный
объект - флаг, предназначенный для
управления его внутренней логикой.
Существует два типа флагов - описательный и
управляющий.
 Описательный флаг обычно описывает ситуацию,
которая произошла, и именуются с использованием
существительных и прилагательных: Конец файла,
Введенная кредитная карта.
 Управляющий флаг используется для
декларирования определенных действий в
вызываемом модуле и именуется с использованием
глаголов: Читать следующую запись, Установить в
начало.
 В общем случае управляющие флаги усиливают
сцепление и, следовательно, ухудшают качество
62
проекта.

НЕНОРМАЛЬНОЕ СЦЕПЛЕНИЕ
 Два
модуля являются сцепленными по
общей области (common coupling), если
они ссылаются к одной и той же области
глобальных данных. Сцепление по
общей области является плохим.
 Ошибка в любом модуле, использующем
глобальную область, может неожиданно
проявить себя в любом другом модуле.
 Программы с большим количеством
глобальных данных чрезвычайно трудны
для понимания.
63
НЕНОРМАЛЬНОЕ
СЦЕПЛЕНИЕ
Два модуля являются сцепленными по
содержимому (content coupling), если один
ссылается внутрь другого любым способом,
например, если один модуль передает управление
или выполняет переход в другой модуль, если один
модуль ссылается (или изменяет) значения
информационных объектов в другом модуле или
если один модуль изменяет код другого модуля.
 Такое сцепление делает абсурдной концепцию
модулей как черных ящиков, поскольку оно
вынуждает один модуль знать о точном
содержании и реализации другого модуля. Вообще
говоря, только ассемблер позволяет
проектировщикам применять данный вид
64
сцепления.

СВЯЗНОСТЬ - COHESION

Связность - это мера прочности соединения
функциональных и информационных элементов
внутри одного модуля. Размещение сильно
связанных объектов в одном и том же
модуле уменьшает межмодульные
взаимосвязи и взаимовлияния. Выделяются
следующие уровни связности:
Функциональная,
Последовательная,
Информационная (коммуникационная),
Процедурная,
Временная,
Логическая
и случайная (для полноты).
65
ФУНКЦИОНАЛЬНАЯ
 Функционально
связанный модуль содержит
объекты, предназначенные для выполнения
одной и только одной задачи, например:
Расчет заработанной платы, Считывание
данных кредитной карты. Каждый из этих
модулей имеет одну четко определенную цель,
при его вызове выполняется только одна
задача (при этом она выполняется полностью
без выполнения любого другого
дополнительного действия).
66
 Самый высокий уровень связности и
повторного использования.
ПОСЛЕДОВАТЕЛЬНАЯ СВЯЗНОСТЬ

Модуль имеет последовательную связность, если
его объекты охватывают подзадачи, для которых
выходные данные одной из подзадач служат
входными данными для следующей задачи,
например: Открыть файл - Прочитать запись Закрыть файл.
67
ИНФОРМАЦИОННАЯ (КОММУНИКАЦИОННАЯ)
 Информационно
связанный модуль
содержит объекты, использующие одни и
те же входные или выходные данные.
Предположим, что мы хотим выяснить
некоторые сведения о книге, зная ее ISBN:
название книги, ее автора и цену. Эти три
подзадачи являются связанными потому,
что все они работают с одним и тем же
входным информационным объектом ISBN, который и делает этот модуль
информационно связным.
68
 Более приемлема чем последующие
ПРОЦЕДУРНАЯ
 Процедурно
связный модуль является
модулем, объекты которого включены в
различные (и возможно несвязные)
подзадачи, в которых управление
переходит от каждой подзадачи к
последующей (в последовательно
связном модуле данные, а не
управление, переходили от одной
подзадачи к последующей). Примером
процедурно связанном модуле может
служить цикл или цепочка принятия
решения, которая является общей для
нескольких процедур.
 Содержит только часть полной функции
или часть нескольких функций
69
ВРЕМЕННАЯ
СВЯЗНОСТЬ
Временно связным является модуль, объекты
которого включены в подзадачи, связанные
временем исполнения.
 Модули, которые выполняют действия такие
как “initialization”, “cleanup,” и“termination”
обычно связаны временем
 Имеют большую связность чем логическая, т.к.
нет необходимости передавать флаг
управления и код обычно проще

70
ЛОГИЧЕСКАЯ

Модулем с логической связностью является
модуль, объекты которого содействуют решению
одной общей подзадачи, для которой эти объекты
отобраны во внешнем по отношению к модулю
мире. Например, модуль может выполнять
следующие задачи:
1. Ввод
записи
2. Вывод записи
Логически связный модуль содержит некоторое
количество подзадач (действий) одного и того же
общего вида.
 Необходимо передавать флаг управления для
выбора операции, что является «плохим» способом
связи
 Надо избегать логическую связь, если возможно

71
СРАВНИТЕЛЬНАЯ ТАБЛИЦА ВИДОВ
СВЯЗНОСТИ
72
СТРУКТУРНЫЕ

СХЕМЫ
(STRUCTURE CHARTS)
Основной инструментарий, используемый для
структурного проектирования – структурная схема.
 Структурные схемы используются для
графического изображения проекта модулей
программы.
В частности, они показывают как программы
разделены на меньшие модули, иерархию и
организацию этих модулей и интерфейс
взаимодействия между ними.
 Структурные схемы, однако, не показывают
внутренние процедуры, выполняемые модулем
или внутренние данные, используемые модулем.
Для описания процедур на этапе
проектирования создаюся блок-схемы.

73
СТРУКТУРНЫЕ СХЕМЫ
Модули структурной схемы изображаются
поименованными прямоугольниками.
 Предполагается, что модули структурной
схемы выполняются снизу вверх, слева
направо.
 Дуга, окружающая линию (представляющую
вызов модуля) означает, что модуль выполняет
итеративные вызовы.
 Ромб внизу модуля означает, что модуль
вызывает один и только один раз другой
модуль нижнего уровня, который соединен с
ромбом.
 Программные модули взаимодействуют друг с
74
другом, передавая данные.

СТРУКТУРНЫЕ


СХЕМЫ
Программы могут также взаимодействовать друг с
другом передавая сообщения или управляющие
программы, называемые флаги(flags).
Библиотеки модулей изображаются как
прямоугольники, содержащие вертикальные линии с
каждой стороны.

75
ПРИМЕР
СТРУКТУРНОЙ СХЕМЫ
76
ДИАГРАММА ПОТОКА ДАННЫХ
ПРОГРАММ




Структурное проектирование требует, чтобы DFD
сначала была модифицирована для программ.
Процессы, появляющиеся на элементарных
логических диаграммах DFD могут представлять
модули на структурной диаграмме.
Логические DFD следует пересмотреть, чтобы они
показывали больше деталей для использования
программистами
Может быть необходим следующий пересмотр:
 Процессы, появляющиеся в DFD должны
выполнять одну функцию.
 Должны быть добавлены процессы для
управления доступом данных и
сопровождением.
 DFD должны быть пересмотрены для включения
средств обнаружения и обработки ошибок и
процессов реализации внутренних элементов
управления.
77
ПОЛЬЗОВАТЕЛЬСКИЙ
ИНТЕРФЕЙС
Пользовательский интерфейс - средство
взаимодействия пользователя с
информационной системой
 Два основных типа взаимодействия:

Ввод (Inputs)
 Представление (Outputs)

78
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКОГО
ИНТЕРФЕЙСА
 Основные
цели проектирования
Производительность
 Эффективность
 Обеспечение соответствующей обратной связи
 Легкоcть освоения
 Удобство применения

79
ВАРИАНТЫ
Вариант
взаимодействия
ВЗАИМОДЕЙСТВИЯ
Основные преимущества
Быстрое и интуитивно
Прямое
понятное взаимодействие.
манипулирование
Легок в изучении
Основные недостатки Примеры приложений
Сложная реализация.
Видеоигры, системы
Подходит только там,
автоматического
где есть зрительный
проектирования
образ задач и объектов
Сокращение количества
ошибок пользователя.
Минимальный ввод с
клавиатуры.
Медленный вариант
для опытных
пользователей. Может Главным образом
быть сложным, если
системы общего
меню состоит из
назначения
большого количества
вложенных пунктов.
Заполнение форм
Простой ввод данных.
Легок в изучении
Занимает
пространство на
экране.
Командный язык
Мощный и гибкий, удобен
профессионалам
Труден в изучении.
ОС, библиотечные
Сложно предотвратить
системы.
ошибки ввода.
Естественный
язык
Подходит неопытным
пользователям.
Легко настраивается.
Требует большого
ручного набора
Выбор из меню
Системы управления
запасами, обработка
финансовой
информации.
Системы расписания,
системы хранения
данных WWW
80
ПРИНЦИПЫ
ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА
Принцип
Описание
Учет знаний
пользователя
В интерфейсе необходимо использовать термины и понятия,
взятые из опыта будущих пользователей системы.
Интерфейс должен быть согласованным в том смысле, что
Согласованность однотипные (но различные) операции должны выполняться
одним и тем, же способом.
Минимум
Поведение системы должно быть прогнозируемым.
неожиданностей
Руководство
пользователя
Интерфейс должен предоставлять необходимую информацию в
случае ошибок пользователя и поддерживать средства
контекстно-зависимой справки
Учёт
разнородности
пользователей
В интерфейсе должны быть средства для удобного
взаимодействия с пользователями, имеющий разный уровень
квалификации и различные возможности
81
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Хороший интерфейс обеспечивает
соответствующую обратную связь, улучшает
производительность; он легок в использовании,
поддержке, изучении, а также обеспечивает
оперативную помощь. Кроме того, хороший
интерфейс никогда не «зависает», обеспечивая,
как минимум, понятный выход из любой
операции.
 Для разработки успешного диалога необходимо:

Составить план диалога (STD-диаграмма)
 Выполнить прототипирование диалога и
интерфейса
 Проверить интерфейс «на пользователях»

82
Раскладка
форм для
продажи
видео
83
СТРУКТУРА ИНТЕРФЕЙСА (STD)
84
ТАБЛИЦА
ЭЛЕМЕНТОВ
УПРАВЛЕНИЯ
85
ИНТЕРФЕЙСЫ ВЫВОДА

Варианты вывода


Экраны, принтеры, звук, CD-ROM, DVD, факс, e-mail и
Web страницы, XML, SOAP
Цели проектирования интерфейса вывода






Преследует намеченные цели
 Предлагает пользователям ожидаемую информацию
Приспособлен для пользователя
 Предлагает пользователям необходимые
информацию и взаимодействие (продвинутый,
рядовой, конечный пользователь)
Предоставляет соответствующее количество
 Не слишком много и не слишком мало
Предоставляет в необходимое место
 Соответствующим людям
Предоставляется во время
 Когда это необходимо
Используется соответствующий метод вывода
(таблицы, графики и ..)
86
ИНТЕРФЕЙСЫ ВЫВОДА
 Соответствие
содержания вывода
задачам означает:

Функция определяет форму


От того, что предполагается делать в выходом,
зависит вид формы (Экран-печать-…)
Содержимое для внешнего или внутреннего
использования

Выход для внешнего использования может
требовать совершенно иного представления по
сравнению с внутренним использованием.
87
ИНТЕРФЕЙСЫ ВЫВОДА
 Проектирование отчетов (reports)


Отчет должен обеспечивать пользователя всей
необходимой информацией в удобном формате (по
форме и по содержанию)
В настоящее время доступны различные ПО
«оформители отчетов», которые облегчают
проектирование и управление отчетами,
например, Crystal reports
 Улучшение

качества печати
Расположение страницы
Заголовок, итоги страницы, нумерация страниц,
дата
 Документирование вывода. (Ответственный за отчет)
 Стиль представления – хорошо смотрится и легко
читается
 Точность данных и информации – свободен от

88
ИНТЕРФЕЙСЫ ВЫВОДА

Принципы проектирования экранного вывода

Простота


Выполнять совместимое представление


Делать навигацию максимально простой, используя
кнопки и иконки
Создавать привлекательный экран


Не представлять новый интерфейс для каждой страницы,
это может лишь сбивать с толку и пользователи сбиваются
Помогать пользователям перемещаться по экрану


Не слишком загроможденные, понятные инструкции,
хорошо именованные элементы управления.
Привлекательный экран проще используется, особенно
если он также эффективный и удовлетворяет требованиям
пользователей
Эти принципы применяются ко всем выходным
экранам, включая web страницы, и к входным
экранам.
89
ИНТЕРФЕЙСЫ ВВОДА

Цели проектирования входного интерфейса






Легкость использования
Эффективность
Точность
Привлекательность
Простота
Логичность
Учет человеческого фактора в значительной
степени определяет успех системы.
 Технологии могут изменяться, но основные
человеческие требования не меняются и
аналитики должны помнить об этом все
время.

90
СПЕЦИФИКА ПРОБЛЕМ ПРОЕКТИРОВАНИЯ
ВВОДА ДАННЫХ
Ввод данных в том же порядке, в котором
они появляются на исходном документе;
 Минимизация ввода данных (например,
автоматический вывод названия по номеру
счета или табельного номера по фамилии
работника);
 Заполнение слева направо и сверху вниз;
 Ограниченное количество данных в одном
кадре;
 Автоматическая проверка правильности
ввода (например, сверка почтового индекса и
названия города) и т.д.
 Группирование связанных элементов
управления (рамкой или цветом)

91
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Тон и терминология (стиль)
 Использовать простые грамматически
корректные выражения
 Не стараться быть забавным
 Не быть снисходительным
 Использовать понятную терминологию
Избегать компьютерного жаргона
 Избегать аббревиатур
 Использовать простые термины
 Использовать непротиворечивые термины

92
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Принципы создания стиля
 Ограничиваться 4 гармоничными цветами
 Ограничения шрифтов до 2, 4 размера

Убедиться, что все читаемо
Заключать в рамки группы связанных элементов
 Ограничить аудио, если звук вообще добавляется

93
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Осведомлять пользователей о последующих
действиях
 Использовать логичное расположение
 Ограничиваться одной целью на зону или
страницу
 Показывать сообщения достаточной для
прочтения длины
 Разумно использовать атрибуты дисплея
(разрешение, например, 800Х600->1024Х768)
 Использовать горячие клавиши для общих
функций
 Определять значения по умолчанию, если
возможно
 Предупреждать общие ошибки

94
ПРОЕКТИРОВАНИЕ
ИНТЕРФЕЙСА
Памятка
 Знать своих пользователей
 Знать требования ваших пользователей
 Предлагать пользователям прототип
интерфейса
 Обеспечивайте простоту
 Используйте понятное расположение
 Будьте последовательны
 Обеспечивайте полезные сообщения
 Приспосабливайте интерфейс для основного
типа пользователей
95
ФАЙЛЫ И БАЗЫ ДАННЫХ
Файл набор однотипных записей.
База данных набор взаимосвязанных файлов (в
том смысле, что записи одного файла физически
связаны с записями другого файла).
96
ФАЙЛЫ И БАЗЫ ДАННЫХ
Information
System
File
File
Information
System
File
File
Information
System
Database
(consolidated
& integrated
data from files)
Information
System
Information
System
97
ЗА И ПРОТИВ ФАЙЛОВ
Против
За
 Легко
 Сложнее
адаптируется для
проектировать
распределения
поскольку
между
ориентируются на
приложениями
одно приложение  Сложнее
адаптируется к
 Высокая
производительность новым требованиям
 Требует
благодаря
дублирования
организации для
98
атрибутов
в
одного приложения
нескольких файлах.
ЗА И ПРОТИВ Б.Д
За
Против
Способность разделять
 Сложнее адаптировать к
данные между
разделению данных
приложениями
между приложениями
 Сокращение и управление  Сложнее адаптировать к
избыточности
новым требованиям
 Независимость данных
 Требует дублирования
увеличивает адаптивность атрибутов в нескольких
файлах
 Отличная
масштабируемость и
 Отчасти меньше
разграничение доступа
производительность
 Язык SQL для доступа к
 Выше стоимость
базам
разработки
 Встроенные средства
 Выше уязвимость данных99
резервирования и
репликации данных

АДМИНИСТРАТОРЫ
Администратор
данных отвечает за планирование,
определение, архитектуру и управление данных.
Один или более администраторов баз данных
отвечают за технологию баз данных, проектирование и
построение баз данных, безопасность, сохранение и
восстановление, а также за обеспечение
производительности.
100
АРХИТЕКТУРА БАЗЫ ДАННЫХ
Архитектура базы данных относится к технологиям баз
данных, включая процессор базы данных(database engine),
утилиты баз данных, CASE средства и средства разработки
баз данных.
Система управления базы данных (СУБД - DBMS)
специализированное ПО, используемое для создания,
доступа, контроля и управления , базы данных. Ядро СУБД процессор базы данных (Engine).
 Язык определения данных(data definition language DDL) – часть процессора базы данных,
используемая для физического определения
таблиц, полей и связей.
 Язык манипулирования данных (data manipulation
language - DML) часть процессора базы данных,
используемая для создания, чтения, замены и
101
удаления записей в базе данных и перемещения между
различными файлами (таблицами) в базе данных.
ТИПИЧНАЯ АРХИТЕКТУРА DBMS
Системный аналитик
и
Дизайнер базы данных
Программист
Конечные
Пользователи
Приложения или
Query tools
Монитор
Обработки транзакций(TP)
DBMS
Data Definition
Language (DDL)
Собственный язык
и Tools
Data Manipulation
Language (DML)
DATABASE ENGINE
METADATA
USER
DATA
102

Многие СУБД обеспечивают монитор
обработки транзакций (transaction
processing monitor или TP monitor), который
управляет доступом к базе данных в реальном
времени и обеспечивает, чтобы транзакции,
воздействующие на несколько таблиц
обрабатывались как единое целое.
103
РЕЛЯЦИОННАЯ БАЗА ДАННЫХ
Реляционная база данных реализует сохраненные
данные набором двумерных таблиц, которые
связываются через внешние ключи.
 Физическая модель называется схема.
 Языки DDL и DML для реляционных баз данных
называются SQL (Structured Query Language).
 Триггеры (Triggers) – программы, встроенные в
таблицы, которые автоматически вызываются
изменениями в других таблицах (изменение,
дополнение, удаление,…).
 Сохраненные процедуры (Stored procedures)
программы, встроенные в таблицы, которые доступны
из приложений (MS SQL – язык Transact-SQL, Oracle
– язык PL/SQL).
104
 Обычно используются для проверки данных или
управление доступом.
ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
105
ФИЗИЧЕСКАЯ МОДЕЛЬ (РЕЛЯЦИОННАЯ СХЕМА)
106
ЦЕЛИ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
 База
данных должна обеспечить
эффективное хранение, корректировку и
извлечение данных.
 База данных должна быть надежной—
хранимые данные должны иметь
высокую степень интеграции и
способствовать доверию пользователей
этим данным.
 База данных должна быть адаптивной и
масштабируемой для новых и
непредусмотренных требований и
приложений
107
МЕТОД ПРОЕКТИРОВАНИЯ Б.Д.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Создать таблицу для каждой сущности.
Создать поля для каждого атрибута.
Создать индекс для каждого первичного и
альтернативного ключей.
Создать индекс для каждого группового критерия.
Назначить внешние ключи для связей.
Определить типы, размеры, область допустимых
значений, NULL, значение по умолчанию для
каждого атрибута.
Проверьте логическую модель данных.
Создайте и объедините таблицы для реализации
структур категоризации.
108
Оцените и определите ограничения целостности
данных (referential integrity constraints).
ЦЕЛОСТНОСТЬ БАЗЫ ДАННЫХ
Целостность ключей - уникальность
 Доменная целостность – значения атрибутов из
ОДЗ.
 Ссылочная целостность-соответствие между
связанными таблицами
Ошибки ссылочной целостности
(referential integrity) возникают, когда
значение внешнего ключа в одной таблице не
совпадает со значением первичного ключа в
связанной таблице.
 Нет ограничений (No restriction)
 Каскадное удаление (Delete: cascade)
 Ограниченное удаление (Delete: restrict)
 Удаление с обнулением (Delete: set null)

109
ПРИМЕР ОПРЕДЕЛЕНИЯ ЦЕЛОСТНОСТИ
create table orders
( ...
,customer_id integer not null
,foreign key (customer_id)
references customers (id)
on update cascade
on delete restrict
, ... )
110
ПРОТОТИПЫ БАЗЫ ДАННЫХ
Прототип не является альтернативой
тщательно продуманной схемы базы данных.
 С другой стороны, как только схема завершена,
прототип базы данных обычно может быть
получен очень быстро.
 Большинство современных СУБД включают
мощные генераторы баз данных, которые
создают скрипт DDL, на основе которого
создается прототип базы данных.


Затем база данных может быть загружена
тестовыми данными, которые будут
способствовать прототипированию и
тестированию входов, выходов, экранов и других
компонентов системы.
111
ПРИМЕР SQL ИЗ DESIGN/IDEF
CREATE TABLE STUDENT
(
soc_sec_no CHAR(18) NOT NULL,
student_name
CHAR(18),
student_address
CHAR(18)
);
CREATE UNIQUE INDEX IXSTUDENT ON STUDENT
(
soc_sec_no ASC
);
CREATE TABLE ENROLLMENT
(
date_enrolled
CHAR(18),
…..
112
ПЛАНИРОВАНИЕ ОБЪЕМА Б.Д.

База данных хранится на диске и
Администратору б.д. необходимо оценить объем
дискового пространства для новой базы данных
для обеспечения достаточного объема.

Простая процедура вычисления объема
состоит в следующем:
1. Для каждой таблицы суммируется размер
полей в байтах.

Это размер записи в таблице.
2. Для каждой таблицы, умножается размер
записи (record size) на количество
экземпляров сущности, содержащихся в
таблице.

Это размер таблицы.
113
ПЛАНИРОВАНИЕ ОБЪЕМА Б.Д.
3. Просуммируйте размеры таблиц.

Это размер базы данных (database size).
4. По возможности, добавьте
дополнительный буфер (например, 1015 %) для учета непредвиденных
факторов или неточностей оценки.

Это ожидаемой емкости д.б.
114
РАСПРЕДЕЛЕНИЕ И РЕПЛИКАЦИЯ
Анализ распределения данных
устанавливает места необходимого доступа
для различных логических элементов
данных.

Анализ определяется решениями типа
распределения:
Централизованное
 Горизонтальное распределение – в различных
местах
 Вертикальное распределение – проблемная
ориентация
 Репликация – дублирование определенных
таблиц, записей и/или полей в несколько
физических баз данных

115
Customer
.Customer Number
.Customer Name
.Customer Address
.Customer Credit Rating
.Customer Balance Due
Order
.Order Number
.Order Date
.Order Amount
Ordered Product
.Quantity Ordered
.Ordered Item Unit Price
Product
.Product Number
.Product Name
.Product Description
.Product Unit of Measure
.Product Current Unit Price
.Product Quantity on Hand
INDV
R
RU
RU
X
R
INDV
SRD
SRD
SRD
INDV
SUD
SUD
ALL
R
R
R
R
R
X
R
R
R
ALL
R
R
R
ALL
R
R
ALL
CRUD
CRUD
CRUD
CRUD
CRUD
CRUD
CRUD
CRUD
CRUD
CRUD
ALL
R
R
RU
R
R
SS
R
R
SS
R
ALL
R
R
R
R
RU
ALL
CRUD
CRUD
CRUD
R
R
ALL
CRUD
CRUD
CRUD
ALL
CRUD
CRUD
ALL
R
R
R
R
R
R
ALL
R
R
R
RU
RU
R
R
R
R
R
SS
CRUD
CRUD
CRUD
R
R
SS
CRUD
CRUD
CRUD
SS
CRUD
CRUD
ALL
R
R
R
R
R
R
INDV = individual
ALL = ALL
SS = subset
X = no access
S = submit
C = create
R = read
U = update
SS
R
R
R
SS
R
R
R
SS
ALL
R
R
R
R
R
RU
SS
CRUD
CRUD
CRUD
R
R
SS
CRUD
CRUD
CRUD
SS
CRUD
CRUD
ALL
R
R
R
R
R
R
. Warehose
San Diego
. Sales
San Francisco
. Warehouse
. Sales
Boston
. A/R
. Sales
. Warehouse
. Advertsing
. Marketing
Kansas City
Customers
Entity . Attribute
Location
МАТРИЦА РАСПРЕДЕЛЕНИЯ ДАННЫХ CRUD
SS
R
R
R
SS
R
R
R
SS
ALL
R
R
R
R
R
RU
116
D = delete
Download