Клиент-сервер.

Файл-сервер

БД и приложения располагаются на сервере, при этом на компьютере «запускается» копия приложения. Такой вариант соответствует архитектуре файл – сервер. Когда пользователь работает с БД, на его компьютере появляется локальная копия, которая периодически обновляется. Такая архитектура используется, когда в сети немного рабочих станций.

Недостатки такого варианта:

- каждый пользователь работает со своей локальной копией. При каждом запросе с сервера пересылается новая копия всей БД, даже если нужны всего несколько записей. В результате возникает перегрузка в сети, что снижает быстродействие и производительность;

- изменения, сделанные одним пользователем, в течение некоторого времени неизвестны другим пользователям. Кроме того необходима синхронизация работы отдельных пользователей, связанная с блокировкой редактируемых записей;

- затрудняется организация контроля доступа, соблюдение конфиденциальности и поддержания целостности БД.

Для управления совместным доступом к БД необходимы специальные средства контроля и защиты.

Клиент-сервер.

БД размещаются на сервере сети (удаленные), а приложения - на компьютере пользователя. Такая архитектура называется клиент – сервер.

При архитектуре клиент/сервер экранная форма (прикладной интерфейс) и БД находятся на разных компьютерах. Клиент и сервер могут быть соединены в ЛВС или ГВС.

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

Примеры серверных СУБД:

· Файл-серверные: Microsoft Access, Paradox, dBase.

· Клиент-серверные: Oracle, Firebird, Interbase, MS SQL Server, MySQL.

Проектирование реляционной базы данных. Основные этапы разработки реляционной базы данных. Информационно-логическая модель предметной области.

Реляционная БД состоит из взаимосвязанных таблиц. Каждая таблица сожержит информацию об объектах одного типа, а совокупность всех таблиц образует единую БД.

Проек-ие - это поиск способа удовлетворения функц-ых требований сред-ми имеющейся технологии с учетом заданных ограничений. В процессе работы над проектом создаются три типа моделей: КИМ – концептуальная; создается на основе информации, записанной в спецификациях требований пользователей; представляет сущность бизнеса; преобразуется в ЛИМ; ЛИМ – логическая; должна быть полностью нормализована; общепринятым способом представления логической модели - диаграмма «сущность-отношение» (ER-диаграмма); ЛИМ преобразуется в ФИМ, при этом определяются физические свойства и объекты. ФИМ – физическая; состоит из файлов данных, табличных пространств, сегментов отката, таблиц, столбцов и индексов; между этими элементами существуют зависимости, которые определяют последовательность процесса проектирования.

этап 1 - «Исследование предметной области»: цель – оценить объем и цели проекта; выявить суть обследуемого и перспективы развития; опр-ть сущности и ф-ии; опр-ть требования к аппаратным средствам; необходимо оценить затраты на аппаратные средства, ПО и разработку; результат - четко сформулированное заявление о том, что получит заказчик, когда и сколько это будет стоить;

этап 2 – «Анализ»: цель – подробное исследование функций и информации, необходимой для этих функций; результат: процесс разбивается на ф-ии, кот снабжаются подробным описанием их назначения; модель представляется в виде ER-д-мы; каждая сущность сопровождается описанием, набором атрибутов со свойствами и их описанием, а также уникальным идентификатором, составляется план тестирования системы;

этап 3 - «Проектирование»: на базе данных анализа: составляется схема БД; составляет набор подробных спецификаций для всех модулей; описание: какие функциональные возможности реализует и по какому алгоритму; результаты оформляются в единый описательный документ – техническую спецификацию.

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

Задачи проектирования: разбиваются на задачи ранней стадии проекта, непосредственного проектирования БД и проектирование процессов и кода. 1.Ранняя стадия проекта включает: передачу рез-ов анализа; «Прогон» отдельных процессов ч/з спланированную систему с помощью диаграммы потока данных, блок-схемы; опр-ие критических участков; оценку системных ограничений: сроков и сметы; определение целевой структуры: будет ли система клиент/сервер; будет ли БД распределенной; согласование стандартов проектирования и реализации. 2.Проектирование БД включает: построение согласованной и нормализованной информационной модели; построение логической модели данных; создание физ БД для разработки; спроектировать и реализовать денормализацию БД с целью ускорения обработки запросов; выполнить оценку размеров всех таблиц, кластеров и индексов и др. 3.Проектирование процессов и кода:В результате этапа проектирования нужно стремиться получить три документа:1)структура интерфейса – рассчитана на пользователя; 2)структура процессов – как должна быть реализована структура интерфейса; 3)структура данных – задает основные объекты БД, с которыми должны работать процессы;

этап 4 – «Реализация»: 1) проверяется полнота и качество этапа проектирования; 2)на этапе реализации создаются и тестируются программные модули; 3) формулируются требования по безопасности, доступу и обслуживанию: резервное копирование и восстановление и т.д

Дата добавления: 2015-11-14