
- •1. Проблема нормализации отношений. Нормальные формы. Способ нормализации отношений.
- •2. Понятие базы данных и субд. Платформы субд.
- •3. Технологии поиска данных (на примере платформы Sybase).
- •4. Применение ключей в субд.
- •5. Правила Джексона и их применение.
- •6. Технологии поддержки целостности в базах данных.
- •7. Реляционная модель данных. Понятие отношения. Свойства отношений. Операции над отношениями.
- •Операции, определённые над отношениями
- •8. Функциональные зависимости на отношениях и их применение.
- •Применение в проектировании бд
- •9. Технология olap и ее применение. Архитектура olap-системы
- •10. Многомерная модель данных olap.
- •11. Язык PowerScript: характеристики, возможности программирования.
- •12. Понятие отношения и его применение. Операции на отношениях.
- •13. Технология DataWindow: назначение, состав, примеры применения.
- •14. Объектная модель в инструментальной субд на примере Power Builder.
- •15. Проектирование Web – приложений в трехслойной архитектуре “клиент - сервер”.
- •16. Жизненный цикл субд. Модели жц. Технологии поддержки жизненных циклов.
- •17. Технологии «клиент-сервер» управления данными
- •18. Оператор select sql.
- •19. Концептуальное моделирование баз данных. Модель "сущность-связь" и ее применение.
- •20. Развитие технологий баз данных: банки данных, хранилища данных, базы знаний.
- •21. Правила Джексона и их применение.
- •22. Функциональные зависимости на отношениях и их применение.
- •23. Ссылочная целостность баз данных.
- •24. Модели данных баз данных.
- •25. Этапы проектирования баз данных: состав, назначение, модели.
- •26. Возвращаемые аргументы в технологии DataWindow.
- •27. Состав современных баз данных: объекты, их назначение, примеры применения.
- •28. Реляционная алгебра: определение, операции, применение.
- •29. Оператор update sql
- •30. Разработка веб-приложений, включающих субд.
- •31. Оператор insert sql
- •32. Обработка ошибок в субд
- •33. Оператор delete sql.
- •34. Принципы и средства разработки Web – интерфейсов.
- •35. Нормальная форма Бойса-Кодда.
- •36. Реляционное исчисление: определение, операции, применение.
15. Проектирование Web – приложений в трехслойной архитектуре “клиент - сервер”.
Трёху́ровневая архитекту́ра, или трёхзве́нная архитекту́ра (англ. three-tier или англ. Multitier architecture) — архитектурная модель программного комплекса, предполагающая наличие в нём трёх компонентов: клиентского приложения (обычно называемого «тонким клиентом» или терминалом), сервера приложений, к которому подключено клиентское приложение, и сервера базы данных, с которым работает сервер приложений.
Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена бо́льшая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
16. Жизненный цикл субд. Модели жц. Технологии поддержки жизненных циклов.
Жизненный цикл СУБД - это совокупность этапов, которые проходит база данных на своем пути от создания до окончания использования. Этот процесс состоит из этапов проектирования, разработки и сопровождения информационных систем. Жизненный цикл включает:
анализ требований к системе,
Проектирование системы,
программирование,
тестирование и отладку,
эксплуатацию и сопровождение.
Этапы:
Исследование и анализ проблемы, для решения которой создается база данных.
Построение Инфологической и Даталогической модели.
Нормализация полученных Инфологических и Даталогических моделей. По окончанию этого этапа, как правило, получают заготовки таблицы БД и набор связей между ними (первичные и вторичные ключи).
Проверка целостности БД.
Выбор физического способа хранения и эксплуатации (технического средства) базы данных.
Проектирование входных и выходных форм.
Разработка интерфейса приложения.
Функциональное наполнение приложения.
Отладка: проверка на корректность работы функционального наполнения системы.
Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.
Ввод в эксплуатацию: отладка ИТ - инфраструктуры, обучение пользователей и ИТ - персонала.
При необходимости добавления выходных форм и дополнительной функциональности. В случае если необходимы более серьезные изменения, следует повторить все шаги с первого.
Вывод из эксплуатации: перенос данных в новую СУБД.
Модели ЖЦ
Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует.
Задачная модель
При разработке системы "снизу-вверх" от отдельных задач ко всей системе единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. достаточно большую эффективную информационной системы таким способом создать невозможно.
Однако в отдельных случаях такая технология может оказаться целесообразной:
Крайняя срочность
Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).
Каскадная модель
В ранних не очень больших по объему однородных информационных систем каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ
Основным недостатком является запаздывание с получением результатов.
Поэтапная модель с промежуточным контролем
В процессе использования каскадного метода обнаружился ряд его недостатков, вызванных тем, что реальный процесс создания систем никогда полностью не укладывался в такую жесткую схему. В процессе создания постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения принимал следующий вид:
Данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.
Спиральная модель
Спиральная модель делает упор на анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.
Тут надо что-то запилить про case-технологии, но я не нашла что именно(((