- •3. Предметная область документальных информационных систем. Информационно-поисковый язык, система индексирования, технология обработки данных, поисковый аппарат.
- •4. Фактографические информационные системы. Понятие предметной области, информационный объект по. Понятие сущности, свойства сущности. Реализация сущности. Целостность данных.
- •5. Фактографические информационные системы. Концептуальное моделирование, концептуальные средства описания, модель «сущность-связь». Виды связей.
- •6. Программные средства реализации фактографических ис. Понятие модели данных, основные компоненты модели. Виды моделей данных.
- •7. Программные средства реализации фактографических ис. Общие понятия субд. Классификация субд. Функции субд.
- •8. Программные средства реализации фактографических ис. Архитектура субд, независимость данных, объекты моделирования, схемы субд.
- •9. Типы моделей данных. Сетевая и иерархическая модели данных. Представление данных, операции над данными, ограничение целостности.
- •10. Реляционная модель данных. Понятие отношения. Мощность и кардинальное число отношения. Домен отношения. Схемы отношений. Общие свойства отношений. Объектно-связанная модель.
- •11. Организация процессов обработки данных. Операции обработки кортежей. Операции обработки отношений.
- •12. Организация процессов обработки данных. Функциональная зависимость в отношениях. Нормализация отношений.
- •13. Проектирование информационной системы. Понятия и структура проекта ис. Требования к эффективности и надежности проектных решений.
- •17. Состав работ на предпроектной стадии, стадии технического и рабочего проектирования, стадии ввода в действие.
- •18. Стадии и этапы процесса проектирования ис. Разработка технического задания на проект, этапы.
- •19. Организация разработки ис. Эскизный проект. Технический проект.
- •20. Стадии и этапы процесса проектирования ис. Разработка рабочей документации. Ввод в действие и сопровождение ис.
- •21. Типовое проектирование ис. Понятие типового элемента, предпосылки типизации. Объекты типизации. Методы типового проектирования. Оценка эффективности использования типовых решений.
- •23. Методология быстрой разработки приложений (rad). Содержание rad-технологии прототипного создания приложений.
- •24. Автоматизированное проектирование ис с использованием case-технологии. Методологии моделирования бизнес-процессов. Функционально-ориентированное проектирование. Диаграммы sadt(методика idef0).
- •26. Автоматизированное проектирование ис с использованием case-технологии. Диаграммы потоков данных (dfd).
- •27. Особенности объектно-ориентированного проектирования. Язык uml. Система объектно-ориентированных моделей.
- •28. Современные технологии доступа к базам данных. Двухзвенная и трехзвенная архитектуры ис.
- •29. Проектирование фактографических бд. Методы проектирования; концептуальное, логическое и физическое проектирование.
- •30. Модель реляционной базы данных. Столбцы, домены и правила. Реляционные таблицы, ссылочная целостность. Реляционные представления. Хранимые процедуры. Триггеры.
28. Современные технологии доступа к базам данных. Двухзвенная и трехзвенная архитектуры ис.
Основные понятия модели клиент-сервер.
Независимо от того, как определяется это понятие, в его основе лежит распределенная модель вычисления. В самом общем случае под клиентом и сервером пон-ся 2 взаимосвязанных процесса, из которых один явл-ся поставщиком некоторого сервиса для другого.
Сервер – логический процесс, кот. обеспеч. некоторый сервис по запросу от клиента. Обычно сервер не только вып. запрос, но и управляет очередностью запроса, буферами обмена, извещением клиентов о вып-нии запроса и т.д.
Клиент – это логич. процесс, кот. запраш. обслуживание от сервера, явл-ся инициатором диалога с сервером. Обязанности клиента – запрос на обслуживание, инициирование взаимод-вия с сервером, получение ре-та с сервера, обработка ошибок.
Отличия арх-ры клиент-сервер от файл-сервер
Арх-ра ф-с
Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файлов. сервер принимает запросы, поступающие по сети от комп-в клиентов и передает им требуемые данные. Обработка этих данных вып-ся на комп-х клиентов. Напрмер, база, созданная в субд Аксесс, нах-ся на файлов.сервере, на каждом комп-е-клиенте при обращении к серверу запускается полная копия процессора обработки данных Jet Engine. Люб. копия Jet независимо управляет файлами mdb, содержащимися на комп.-клиенте. Единственная связь м/д этими действиями – файл блокировок, имеющ. расширение ldb.
Недостатки:
1.резкое снижение произв-ти работы с приложениями при увелич. числа пользов-й.
2.Загруженный трафик сети.
Арх-ра к-с
В арх. к-с сервер сам выполняет все необх-е изменения по запросу ПК клиента, контролируя при этом целостность и согласов-ть данных. Клиенту посылаются только рез-ты в виде набора записей или кода возврата.
Распределение функций в арх. к-с
Функцион-ть разрабатываемого приложения зависит от того, как распределена нагрузка ПО м/д клиентской и серверной частью. Пытаясь реш. эту задачу, разработчики получают однозвенные, двухзвенные, трехзвенные и многозвенные арх-ры. Основная задачу, кот решает клиентское приложение – это обеспечение интерфейса с пользователем, т.е. ввод данных в удобном виде и управление сценариями работ. Осн. ф-ции серверной СУБД – это обеспечение надежности, согласов-ти и защищенности данных, управление запросами клиентов, быстр. обработка SQL-запросов. Вся логика работы приложения – прикладной задачи - бизнес-правила распределялись разработчиками м/д 2мя процессами: клиентом и сервером. Сначала бОльшая часть ф-ций решалась с клиентом, сервер занимался только обработкой SQL-запросов. Такая арх-ра получ. название «толстый клиент, тонкий сервер».
Появление возможности создавать на сервере хранимые процедуры (откомпилированные программы с внутр. логикой работы) привело к тенденции переносить всё бОльшую часть ф-ций на сервер. Сервер становился всё более «толстым», а клиент «утоньщался». Однако язык, на кот. пишутся хранимые процедуры не явл-ся достаточно мощным и гибким для реализации сложн. логики приложения. Тогда возникла тенденция поручить выполнение прикл. задач и бизнес-правил отдельному компоненту приложения (или нескольким комп-м), кот. м. работать на спец. выделенном компе – сервере приложения или на том же комп-е, где работает сервер БД. Так появились понятия трехзвенной и многозвенной арх-ры клиент-сервера. Появилось спец. прогр. обеспечение промежуточного слоя, кот. был призван обеспечить совместное функционирование многокомпонентного приложения.
Понятие однозвенной арх-ры (one-tier)
Это система, в кот. все службы БД, приложения и пользов-кий интерфейс размещены в 1 системе. Система такого типа не производит обработку вне тех компонентов, на кот они исполняются.
Двухзвенная арх-ра (two-tier) в двухзвенных приложениях БД и польз. интерфейс размещаются на разных комп-х. Двухзв. приложения встречаются чаще всего. Польз. интерфейс обычно написан на Microsoft C++(для ОС Виндоус)
Трехзвенная арх-ра (three-tier)
В трехз. приложениях уровень Бд, ур-нь приложения и ур. польз.инт-са выделены в 3 разных компонента. Промежуточный ур-нь выполняет значит. объем работы, связанной с реализацией специфики целевых задач, поддерживающих логику предм.области.
Клиент-серверная система SQL-сервер
может менять 2зв. или 3зв. установку. Независимо от варианта установки прогр. обеспечение Бд размещается на сервере БД. В 2зв. системах клиенты исполняют приложения, осущ-щие доступ к серверу и прилож-я, отображающие для пользователя рез-ты доступа к БД. Такие клиенты называются «толстыми», потому что выполняют 2 вида работ. 2зв. арх-ра имеет смысл при относительно небольш. кол-ве пользов-й (до 100-150). В 3зв. установке имеется 3й комп. – серверное приложение. Серверн.прил. исполняет задачи, кот. явл-ся много потоковыми, благодаря чему с ними м. работать много польз-лей одновременно. Достоинством 3зв. арх-ры явл-ся то, что м. позволять сервер. приложению организовывать все клиентские соединения с сервером, осущ-ть доступ к данным, при этом организуется так называем. пул соединения (-очередь), кот. буд. дожидаться ближайшего доступного соединения.
