
- •Архитектуры баз данных. Преимущества и недостатки
- •Реляционные базы данных, основные понятия.
- •Понятия и терминология, связанные с таблицей реляционной базы данных
- •1.4.1. Отношение "один-ко-многим"
- •Отношение "один-к-одному"
- •Отношение "многие-ко-многим"
- •Понятия терминология, связанные с полем таблицы
- •Понятия ключевых атрибутов для таблиц и индексов.
- •1.7. Индексы и методы доступа
- •Реляционные отношения и целостность данных. Пример
- •1.4.1. Отношение "один-ко-многим"
- •1.4.2. Отношение "один-к-одному"
- •1.4.3. Отношение "многие-ко-многим"
- •1.4.4. Связь между записями одной таблицы
- •1.5. Ссылочная целостность и каскадные воздействия
- •Навигационный и sql ориентированный подход к обработке данных.
- •Нормализация данных. Первая нормальная форма. Пример
- •Нормализация данных. Третья нормальная форма. Пример
- •Индексы. Определение, назначение, характеристики.
- •Жизненный цикл программного обеспечения. Модели жизненного цикла.
- •Основные этапы программирования (структурный, rad технологии, case технологии). Кризис программирования.
- •Методология системного анализа и системного моделирования. Диаграммы idefo.
- •Язык uml. Назначение.
- •Статические диаграммы uml (варианты использования, классов)
- •Диаграммы поведения uml ( состояний, последовательности, деятельности).
- •Основные принципы организации процесса разработки по по rup.
- •Понятие rup. Основные принципы. Структура процесса проектирования. Инструментальная поддержка.
- •Статическая структура описания rup. Понятия исполнителей и артефактов. Основные технологические процессы.
- •Технологический процесс управления проектом.
- •Технологический процесс процесса моделирования производства. 6 сценариев разработки моделей.
- •Технологический процесс управления требованиями
- •Технологический процесс анализа и проектирования
- •Технологический процесс реализации
- •Технологический процесс тестирования
- •Технологический процесс управления конфигурацией и изменениями
- •Технологический процесс управления средой
- •Технологический процесс распространения
- •Конфигурирование и реализация rup
Архитектуры баз данных. Преимущества и недостатки
Под базой данных (БД) понимают хранилище структурированных данных, при этом данные должны быть непротиворечивы, минимально избыточны и целостны.Обычно БД создается для хранения и доступа к данным, содержащим сведения о некоторой предметной области, то есть некоторой области человеческой деятельности или области реального мира. Всякая БД должна представлять собой систему данных о предметной области. БД, относящиеся к одной и той же предметной области, в различных случаях содержат более или менее детализированную информацию о ней. Степень детализации определяется рядом факторов, прежде всего целью использования информации из базы данных и сложностью производственных (деловых) процессов, существующих в пределах предметной области в конкретных условиях.
Имеется четыре разновидности архитектур баз данных:
• локальные базы данных;
• архитектура "файл-сервер";
• архитектура "клиент-сервер";
• многозвенная (трехзвенная N-tier или multi-tier) архитектура.
Требование к БД:
1.Непрерывное расширение, как структуры данных, так и содержимого.
2. расширения-дополнить содержимое
3.поимк информации
4.понизить избыточность данных и повысить их надежность
5. целостность данных- при работе пользователя с информацией не разрушились и данные связи не нарушались
Локальные БД - основной проблемой была явная или неявная обработка транзакций и неизбежно встающая при коллективном доступе проблема обеспечения смысловой и ссылочной целостности БД при одновременном изменении одних и тех же данных.
В ходе эксплуатации таких систем были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к БД. Они состоят в следующем:
• вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентское место, и выборка осуществляется на клиентском месте;
• локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями; не оптимально расходуются ресурсы клиентского компьютера и сети;
Потребности в постоянном увеличении вычислительных мощностей клиентского компьютера обусловливаются не только развитием программного обеспечения как такового, но и возрастанием обрабатываемых объемов информации;
• в БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств
• бизнес-правила в системах "файл-сервер" реализуются в приложении, что позволяет в разных приложениях, работающих с одной БД, проектировать взаимоисключающие бизнес-правила; смысловая целостность информации при этом может нарушаться;
• недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, когда некоторые из них завершились успешно, а некоторые - нет; это может нарушать ссылочную и смысловую целостность БД.
Приведенные недостатки решаются при переводе приложений из архитектуры "файл-сервер " в архитектуру "клиент-сервер ", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер БД (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных - как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к БД из приложений не происходит. Функции прямого обращения к БД осуществляет специальная управляющая программа - сервер БД (SQL-сервер), поставляемая разработчиком СУБД.
Взаимодействие сервера БД и приложения-клиента происходит следующим образом: клиент формирует SQL-запрос и отсылает его серверу. Сервер, приняв запрос, выполняет его и результат возвращает клиенту. В клиентском приложении в основном осуществляется интерпретация полученных от сервера данных, реализация интерфейса с пользователем и ввод данных, а также реализация части бизнес-правил.
Преимущества архитектуры "клиент-сервер":
• большинство вычислительных процессов происходит на сервере; таким образом снижаются требования к вычислительным мощностям компьютера клиента;
• снижается сетевой график за счет посылки сервером клиенту только тех данных, которые он запрашивал;
• упрощается наращивание вычислительных мощностей в условиях развития программного обеспечения и возрастания объемов обрабатываемых данных
• БД на сервере представляет собой, как правило, единый файл, в котором содержатся таблицы БД, ограничения целостности и другие компоненты БД. Взломать такую БД, даже при наличии умысла, тяжело; значительно увеличивается защищенность БД от ввода неправильных значений, поскольку сервер БД проводит автоматическую проверку соответствия вводимых значений наложенным ограничениям и автоматически выполняет необходимые бизнес-правила; кроме того, сервер отслеживает уровни доступа для каждого пользователя и блокирует осуществление попыток выполнения неразрешенных для пользователя действий
• сервер реализует управление транзакциями и предотвращает попытки одновременного изменения одних и тех же данных; различные уровни изоляции транзакций позволяют определить поведение сервера при возникновении ситуаций одновременного изменения данных;
• безопасность системы возрастает за счет переноса большей части бизнес-правил на сервер; падает удельный вес противоречащих друг другу бизнес-правил в клиентских приложениях, выполняющих разные действия над БД; определить такие противоречивые бизнес-правила в приложениях клиента все еще можно, однако намного труднее их выполнить ввиду автоматического отслеживания сервером БД правильности данных.