I. Основи на субд 2

3.2.Външно ниво на системата

За целите на настоящия курс е важно да знаем, че всички тези езици включват едно подмножество (data sublanguage), което се занимава специално с обектите в БД и операциите с тях. Тези подмножества (познати като DSL) се вграждат в кореспондиращ базов език. Базовият език е отговорен за различни манипулации, които не са свързани с БД (локални променливи, изчислителни операции, if-else логика и т.н.). Дадена система може да поддържа различни базови езици, както и различни DSL.

• 
  За изясняване на архитектурата е важно да се различават DSL и базовия език. В действителност за потребителя вероятно е за предпочитане те да са неделими. Ако е така или двете компоненти са трудно делими, ние говорим за 'тясно свързани' (tightly coupled) езици. Ако те са ясно различими и лесно делими ние говорим за 'слабо свързани' (loosely coupled) езици. Съвременните системи поддържат предимно слабо свързани езици;
  
• 
  На практика даден DSL е комбинация от най-малко две подмножества:
  
  • 
    DDL (data definition language) - предоставя средства за дефиниране и описание на обекти в БД;
    
  • 
    DML (data manipulation language) - средства за манипулация и опериране с тези обекти.
    

Понятия:

• 
  Гледна точка (view) - множество от събития (операции, манипулации);
  
• 
  Схема (schema) - дефинира гледни точки. Обикновено използва DDL;
  
• 
  Кореспонденция (mapping) - трансформация от дадена схема в по-долу лежаща схема.
  

3.3.Концептуално ниво

Концептуалната гледна точка се състои от различни събития с различни типове концептуални записи. Тя се дефинира посредством концептуална схема, която съдържа дефиниции за всеки от различните типове концептуални записи. Тя използва друг вид DDL - концептуален DDL. Ако БД притежава свойството “независимост от данните”, концептуалните DDL дефиниции не трябва да съдържат информация за физическите структури или за стратегията за достъп - те трябва да съдържат само потребителски данни.

Ще бъде грешка ако концептуалната схема се схваща само като множество от дефиниции, каквито се срещат в програмите на Cobol, напр. Дефинициите в концептуалната схема са проектирани да съдържат нещо повече - напр. контроли за сигурност и цялостност. В някои проекти се отива още по-далече като се предлага в концептуалната схема да се включат комплексни характеристики на фирмите-потребители - не само оперативните данни, но и информация как да бъдат използвани.

3.4.Вътрешно ниво

Вътрешната гледна точка се описва посредством вътрешната схема, която описва не само различните типове вътрешни записи, но и специфицира какви индекси съществуват, как се представят отделните полета и т.н. Вътрешните схеми се пишат с помощта на вътрешни DDL.

3.5.Кореспонденции (mappings)

Нека се върнем отново на фиг. 3-2. Там са дадени две нива на кореспонденции (mappings):

• 
  Conceptual/internal mapping - дефинира кореспонденциите между концептуалната гледна точка и вътрешната БД. Специфицира начина, по който концептуалните записи и полета се представят на вътрешно ниво. Ако вътрешното представяне бъде променено, тогава този интерфейс се променя също, като запазва концептуалната схема непроменена.
  
• 
  External/conceptual mapping - описва кореспонденциите между отделните външни гледни точки и концептуалната гледна точка. Разликите, които могат да съществуват между двете нива са подобни на тези между концептуалното и вътрешното ниво. Напр. полетата могат да бъдат от различни типове и с различни имена, различни концептуални полета могат да бъдат групирани в едно виртуално външно поле и т.н. В един определен момент могат да съществуват повече от една външни гледни точки, повече от един потребители могат да делят (shared) една и съща гледна точка, различни външни гледни точки могат да се препокриват (overlap).
  

3.6.Администраторът на БД

Както вече казахме администраторът на БД е човекът (или група от хора), отговорен за контрола върху цялата БД. Отговорностите на администраторите включват следното:

• 
  решава каква информация ще съдържа БД (логическо проектиране или изграждане на концепция за БД) - идентифицират се реалните обекти, които ще представляват интерес за управлението на съответната фирма и техните информационни модели. На този етап се програмира и концептуалната схема на БД, като се използва съответен концептуален DDL. Обектната (компилирана) форма на тази схема се интегрира в системата и се използва от СУБД при заявките за достъп на потребителите. Първичният код (некомпилиран) се използва като ръководство за потребителите на системата;
  
• 
  определя структурата за съхраняване на данните в паметта и стратегията за достъп (проектиране на физическата БД) - програмира се вътрешната схема (с помощта на вътрешния DDL). Освен това трябва да се дефинира conceptual/internal mapping. Аналогично на предишната стъпка вътрешната схема се доставя в обектен и първичен формат;
  
• 
  свързване с потребителите - администраторите трябва да гарантират на потребителите, че необходимите им данни ще са налични. Освен това те могат да помогнат да се създадат съответните външни схеми (с помощта на вътрешен DDL). При тази стъпка се дефинира и external/conceptual mapping. Схемата и съответните кореспонденции се предлагат в обектен и първичен вид;
  
• 
  определяне на контроли за сигурност и цялостност - те са част от концептуалната схема. За целта се използва концептуален DDL;
  
• 
  определяне на стратегия за възстановяване на информация след различни откази - щом една фирма е обвързана с определена БД, тя става критично зависима от коректното й функциониране. В случай на пропадане на някоя част от БД (независимо от причината - субективни грешки, отказ на техниката или софтуера), много е важно тя да бъде възстановена възможно най-бързо. Администраторите трябва да създадат подходяща стратегия за възстановяване, включваща напр. процедури за периодично архивиране и възстановяване на БД;
  
• 
  организиране на наблюдения върху производителността и при необходимост промяна на параметрите, така че системата да решава оптимално проблемите на съответните потребители;
  
• 
  създаване на процедури за първоначално зареждане, инициализиране и реорганизиране на БД;
  
• 
  създаване на процедури за събиране и анализ на статистически данни.
  

Един от важните инструменти на администраторите е системният каталог (data dictionary). Записите в системния каталог съдържат “данни за данните” (метаданни). Всички схеми и съответните кореспонденции се запомнят (двете им форми) в каталога. Определени каталози могат да съдържат различна справочна информация, напр. кои програми кои части от БД използват, кои отдели на фирмата какви справки изискват, кои терминали са свързани със системата и т.н. Каталозите имат също свои описания.

3.7.СУБД

СУБД е софтуерът, който обработва всеки достъп до БД. Най-общо това се извършва по следния алгоритъм:

• 
  даден потребител дава заявка за достъп, като използва определен DSL (напр. SQL);
  
• 
  СУБД прехваща заявката и я анализира;
  
• 
  СУБД преглежда външната, концептуалната и вътрешната схема, както и съответните кореспонденции;
  
• 
  СУБД планира и извършва необходимите операции върху БД.
  

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

3.8. Обмен на данни

Възможни са заявки от потребители, които физически са отдалечени от БД (посредством отдалечен потребителски терминал). Данните могат да се прехвърлят към отдалечените потребители във формата на комуникационни съобщения. Обменът се извършва под управлението на друга софтуерна система - data communications manager. DCM не е интегрална част на БД, а автономна система. Необходимостта от синхронизирано взаимодействие налага те да се разглеждат като равностойни партньори на едно по-високо системно ниво, наречено database/data communications system (DB/DC System).

3.9.Клиент/Сървър архитектура

От една по-висока (по-абстрактна) гледна точка СУБД може да се разглежда като архитектура, състояща се от две части:

• 
  сървър (също backend);
  
• 
  множество от клиенти (Фиг. 3-3).
  

Сървърът е самата СУБД. Той поддържа всички базови функции, като напр.:

• 
  дефиниране на данните;
  
• 
  обработка на данните;
  
• 
  защита и цялостност на данните.
  

Той доставя всички три нива на БД. Т.е. в този контекст сървърът е самата СУБД.

Клиентите са различни приложения, които работят на върха на СУБД, две големи групи:

• 
  разработени от потребителите приложения;
  
• 
  стандартни приложения - доставяни от производителя на СУБД или друга фирма.
  

Дотолкова, доколкото се ангажира сървъра не съществува разлика между двете групи, те използват единен интерфейс към сървъра.

Потребителски приложения - писани на някои език (С или Кобол, напр.) или на специализирани езици за БД.

Стандартни приложения (често се наричат tools) - основната им функция е да подпомагат процеса на създаване и изпълнение на други приложения. Могат да се разделят на различни подгрупи:

• 
  процесори за заявки;
  
• 
  генератори на справки;
  
• 
  бизнес-графика;
  
• 
  обработка на таблици;
  
• 
  процесори за естествени езици;
  
• 
  статистически пакети;
  
• 
  генератори на приложения, също 4GL препроцесори;
  
• 
  CASE-средства.
  

Обикновено клиентите и сървърът работят на различни машини - потенциално предполагат разпределена обработка, защото обработката е разделена между клиентските компютри и сървър, управляващ базите данни. Сред преимуществата на тази архитектура са:

• 
  Намалени разходи за поддръжка;
  
• 
  Намалено натоварване на мрежата – обработката се извършва на сървъра, управляващ базите данни, или на клиентския компютър;
  
• 
  Множество операционни системи могат да работят заедно при условие, че използват общ мрежов протокол;
  
• 
  Подобрен интегритет на данните заради централизираното им съхранение.
  

Клиент/сървър обработката на информация е модел на работа, при който едно приложение е разделено между много процеси (front-end и back-end) и процесите си сътрудничат (прозрачно за крайния потребител), за да завършат обработката на една цялостна задача.

3.10.Помощни средства

Представляват програми, които подпомагат администратора на БД при различни административни действия:

• 
  инсталиращи програми - за създаване на начална версия на БД;
  
• 
  реорганизиращи програми;
  
• 
  статистични модули;
  
• 
  анализиращи програми.
  

3.11.Разпределена обработка

Разпределена обработка - различни машини могат да бъдат свързани заедно в една комуникационна мрежа, така че една отделна операция за обработка на данни може да се простира върху няколко машини в мрежата.

Възможни са различни нива или варианти на разпределена обработка:

• 
  СУБД (сървър) и клиентите на различни машини;
  
• 
  един сървър - много клиенти;
  
• 
  всяка машина е клиент и сървър.
  

Каталог: sites -> default -> files
files -> Образец №3 справка-декларация
files -> Р е п у б л и к а б ъ л г а р и я
files -> Отчет за разкопките на праисторическото селище в района на вуз до Стара Загора. Аор през 1981 г. ХХVІІ нац конф по археология в Михайловград, 1982
files -> Медии и преход възникване и развитие на централните всекидневници в българия след 1989 година
files -> Окръжен съд – смолян помагало на съдебния заседател
files -> Семинар на тема „Техники за управление на делата" 18 19 юни 2010 г. Хисар, Хотел „Аугуста спа" Приложение
files -> Чинция Бруно Елица Ненчева Директор Изпълнителен директор иче софия бкдмп приложения: програма
files -> 1. По пътя към паметник „1300 години България

Изтегляне 1.28 Mb.

Сподели с приятели: