Тема 1.2. Виды обеспечения автоматизированных систем предприятия (организации).

11 отделов:

В них по 6-7 компьютеров, сеть  Интернет (в отделе дирекции по средствам WLAN, вне кабинета используются роутеры Wi-Fi беспроводной сети, для обеспечения доступа к сети интернет из других кабинетов).

1 – кабинет для совещаний. В нем компьютер и интерактивная доска.

Так же в офисе имеется:

• 14 учебных классов оборудованны компьютерами.

• 11 лазерных принтеров

• 4 проектора

• 3 интерактивные доски

Имеется сервер докуменооборота. На всех ПК в офисе установлено лицензионное ПО. ОС – Windows 7,XP, Vista.

Так же на всех компьютерах установлен антивирус Dr.Web. Основное ПО, установленное в офисе это – Microsoft Office 2010, 7ZIP, Mozilla Firefox, Chrome, Adobe Reader 9.0, С1 и др.

Раздел 2. Теория проектирования удаленных баз данных

Тема 2.1. Архитектура удаленных баз данных

Рис. 1. Двух­звен­ная ар­хи­тек­ту­ра

Двухзвенная архитектура

Одной из самых старых является двух­звен­ная архитектура (рис. 1). Она раз­де­ля­ет при­ло­же­ние на две части, кли­ент­скую и сер­вер­ную. Сто­ро­на кли­ен­та со­дер­жит ло­ги­ку пред­став­ле­ния, а ло­ги­ка до­сту­па к дан­ным, СУБД и сама база на­хо­дят­ся на сто­роне сервера.

Оста­ют­ся ал­го­рит­мы биз­нес-ло­ги­ки, ко­то­рые могут быть раз­ме­ще­ны как на ма­шине кли­ен­та вме­сте с ло­ги­кой пред­став­ле­ния (кон­фи­гу­ра­ция «тол­стый кли­ент»), так и на сто­роне сер­ве­ра (кон­фи­гу­ра­ция «тон­кий кли­ент»), или даже могут быть раз­де­ле­ны между ними. Кон­фи­гу­ра­ция «тол­стый кли­ент» более рас­про­стра­не­на: сум­мар­ная вы­чис­ли­тель­ная мощ­ность кли­ен­тов, по край­ней мере, в тео­рии, пред­по­ла­га­ет­ся боль­шей, чем мощ­ность един­ствен­но­го сер­ве­ра. По­доб­ный ход рас­суж­де­ний при­вел неко­то­рых из раз­ра­бот­чи­ков к со­зда­нию при­ло­же­ний, где даже ло­ги­ка до­сту­па к дан­ным раз­ме­ща­ет­ся на кли­ен­те, остав­ляя сер­ве­ру толь­ко под­дер­жа­ние самой базы данных.

Двух­звен­ная ар­хи­тек­ту­ра, осо­бен­но кон­фи­гу­ра­ция «тол­стый кли­ент», имеет ряд недо­стат­ков. На­при­мер, как и в ар­хи­тек­ту­ре раз­де­ле­ния фай­лов, — это огра­ни­че­ние, вы­те­ка­ю­щее из вы­чис­ли­тель­ной мощ­но­сти от­дель­ных машин кли­ен­тов. Но еще хуже име­ю­щее фун­да­мен­таль­ный ха­рак­тер огра­ни­че­ния на число од­но­вре­мен­ных со­еди­не­ний с сер­ве­ром. Сервер поддер­жи­ва­ет от­кры­тое со­еди­не­ние со всеми ак­тив­ны­ми кли­ен­та­ми, даже если ни­ка­кой ра­бо­ты нет. Это необ­хо­ди­мо, чтобы сер­вер мог по­лу­чать сиг­на­лы так­то­во­го им­пуль­са, что не так страш­но, когда кли­ен­тов менее 100 ; од­на­ко сверх этого числа про­из­во­ди­тель­ность на­чи­на­ет быст­ро де­гра­ди­ро­вать до недо­пу­сти­мо низ­ко­го уров­ня. Хо­ро­шим при­ме­ром воз­ник­но­ве­ния по­доб­ной про­бле­мы может слу­жить ра­бо­та прокси-сервера.

В неко­то­рых при­клад­ных си­сте­мах биз­нес-ло­ги­ку пы­та­ют­ся ре­а­ли­зо­вать, ис­поль­зуя хра­ни­мые про­це­ду­ры. Идея со­сто­ит в том, чтобы в со­от­вет­ствии с «тон­кой» кон­фи­гу­ра­ци­ей кли­ен­та пе­ре­ме­стить ал­го­рит­мы биз­нес-ло­ги­ки на сер­вер­ную ма­ши­ну, ближе к дан­ным, ко­то­рые тре­бу­ют­ся им по­сто­ян­но. Это вы­гля­дит как хо­ро­шая идея, од­на­ко толь­ко усу­губ­ля­ет глав­ную про­бле­му. Так как осу­ществ­ля­ю­щие биз­нес-пра­ви­ла про­цес­сы те­перь управ­ля­ют­ся СУБД, число поль­зо­ва­те­лей, ко­то­рых может под­дер­жи­вать такая си­сте­ма, огра­ни­че­но мак­си­му­мом воз­мож­ных ак­тив­ных со­еди­не­ний с СУБД. Кроме того, от СУБД к СУБД ме­ха­низ­мы хра­ни­мых про­це­дур раз­нят­ся. Тем не менее, двух­звен­ная ар­хи­тек­ту­ра хо­ро­шо ра­бо­та­ет в ма­лень­ких ра­бо­чих груп­пах . С на­ча­ла 90-х годов по­яви­лась масса ин­стру­мен­таль­ных средств, упро­ща­ю­щих со­зда­ние си­стем в такой ар­хи­тек­ту­ре, в том числе Delphi и PowerBuilder.

Рис. 2. Трех­звен­ная ар­хи­тек­ту­ра

Трех­звен­ная архитектура

С се­ре­ди­ны 90-х годов при­зна­ние спе­ци­а­ли­стов по­лу­чи­ла трех­звен­ная ар­хи­тек­ту­ра, ко­то­рая, как и двух­звен­ная, под­дер­жи­ва­ла кон­цеп­цию кли­ент-сер­вер, но раз­де­ли­ла си­сте­му по функ­ци­о­наль­ным гра­ни­цам между тремя сло­я­ми: ло­ги­кой пред­став­ле­ния, биз­нес-ло­ги­кой и ло­ги­кой до­сту­па к дан­ным (рис. 2). В от­ли­чие от двух­звен­ной ар­хи­тек­ту­ры по­яв­ля­ет­ся до­пол­ни­тель­ное звено — «сер­вер при­ло­же­ний», це­ли­ком пред­на­зна­чен­ное для осу­ществ­ле­ния бизнес-логики.

Имен­но вы­де­ле­ние биз­нес-ло­ги­ки в от­дель­ное звено поз­во­ля­ет пре­одо­леть фун­да­мен­таль­ные огра­ни­че­ния двух­звен­ной ар­хи­тек­ту­ры. Кли­ен­ты не под­дер­жи­ва­ют по­сто­ян­но­го со­еди­не­ния с базой дан­ных, а об­ме­ни­ва­ют­ся ин­фор­ма­ци­ей со сред­ним зве­ном толь­ко тогда, когда это необ­хо­ди­мо. В то же время про­цесс сред­не­го звена под­дер­жи­ва­ет всего несколь­ко ак­тив­ных со­еди­не­ний с базой дан­ных, но ис­поль­зу­ет их мно­го­крат­но; по­это­му про­цес­сы в сред­нем звене могут предо­став­лять об­слу­жи­ва­ние тео­ре­ти­че­ски неогра­ни­чен­но­му числу кли­ен­тов. В срав­не­нии со всеми дру­ги­ми мо­де­ля­ми трех­звен­ная ар­хи­тек­ту­ра об­ла­да­ет столь мно­ги­ми пре­иму­ще­ства­ми. Но пре­иму­ще­ства не да­ют­ся даром. Раз­ра­бот­ка при­клад­ных про­грамм, ос­но­ван­ных на трех­звен­ной ар­хи­тек­ту­ре, — более труд­ное дело, чем для двух­звен­ной ар­хи­тек­ту­ры или при ис­поль­зо­ва­нии цен­тра­ли­зо­ван­но­го под­хо­да. Пре­одо­леть воз­ни­ка­ю­щие про­бле­мы по­мо­га­ет про­грамм­ное обес­пе­че­ние про­ме­жу­точ­но­го слоя .

Жизненный цикл приложения базы данных

Система базы данных является фундаментальным компонентом  более широкого понятия — информационной системы организации. Следовательно, жизненный цикл приложений баз данных неразрывно связан с жизненным циклом информационной системы. Например, при проектировании базы данных могут возникнуть проблемы, для разрешения которых потребуется  вернуться к этапу сбора и анализа требований. Обратные связи  могут возникать почти между  всеми этапами, но в таблице показаны только наиболее важные из них. Основные сведения о наиболее важных мероприятиях, связанных с реализацией каждого  этапа жизненного цикла приложения базы данных, приведены в таблице.

Для малых  приложений с небольшим количеством  пользователей жизненный цикл может  оказаться не очень сложным. Однако он может стать чрезвычайно сложным  при проектировании среднего или  крупного приложения базы данных, с  десятками и даже тысячами пользователей, сотнями запросов и прикладных программ. Ниже в этой главе основное внимание уделяется тем действиям, которые  связаны с разработкой средних  и крупных приложений баз данных.

Основные  действия, выполняемые на каждом этапе  жизненного цикла приложения базы данных:  

Таб.1 Этапы жизненного цикла

Этап  Описание  Планирование  разработки базы данных Планирование  наиболее эффективного способа реализации этапов жизненного цикла системы  Определение требований к системе  Определение диапазона  действий и границ приложения базы данных, состава его пользователей и  областей применения Сбор  и анализ требований пользователей  Сбор и анализ требований пользователей из всех возможных  областей применения Проектирование  базы данных Полный цикл разработки включает концептуальное, логическое и физическое проектирование базы данных Выбор целевой СУБД (необязательный этап) Выбор наиболее подходящей СУБД для приложения базы данных Разработка  приложений Определение пользовательского  интерфейса и прикладных программ, которые используют и обрабатывают данные в базе данных Создание  прототипов (необязательный этап) Создание рабочей  модели приложения базы данных, которая  позволяет разработчикам или  пользователям представить и  оценить окончательный вид и  способы функционирования системы  Реализация  Создание внешнего, концептуального и внутреннего  определений базы данных и прикладных программ Преобразование  и загрузка данных Преобразование  и загрузка данных (и прикладных программ) из старой системы в новую  Тестирование  Приложение  базы данных тестируется с целью  обнаружения ошибок, а также его  проверки на соответствие всем требованиям, выдвинутым пользователями Эксплуатация  и сопровождение  На этом этапе  приложение базы данных считается полностью  разработанным и реализованным. Впредь вся система будет находиться под постоянным наблюдением и  соответствующим образом поддерживаться, В случае необходимости в функционирующее  приложение могут вноситься изменения, отвечающие новым требованиям. Реализация этих изменений проводится посредством  повторного выполнения некоторых из перечисленных выше этапов жизненного цикла