|
|
|
Двоични файлове
Двоичните файлове представляват
съвкупност
от битове (единици и нули) записани
под общо
име.
Обикновенно не всяко приложение е в състояние
да чете, редактира и записва съдържанието
на двоичните файлове създадени с помощта
на друго.
Например, когато една програма за обработка
на документи създаде файл, то този файл има
специфичен формат, който позволява да се
укаже къде е началото на нова странница,
коя част от текста е подчертана и т.н.. Един
файл може да съдържа една или няколко странници.
При отварянето на такъв файл, с помощтта
на специално разработената за тази цел програма
тя интерпретира двоичните кодове и извежда
на екрана или отпечатва документа във вида,
в който е бил записан.
Прието е вмъкнатите в документа кодове да
се наричат метаданни (metadata) или казано
с други думи те са информация за информацията.
Проблемът за съвместтимостта
на отделните
програми се състои в различните
по структура
метаданни, които ползват.
Например метаданните, използвани
от програмата
MS Word са различни от данните
използвани
от програмата Excel, независимо
от факта,
че и двете програми са част от
общ, офис
пакет.
Не по-малко сериозни проблеми възникват и
в случаите, когато се налага да се осъществи
прехвърляне на документи, изготвени с конкретна
програма, но за различни платформи, като
например DOS и Windows. Трудно е да конвертираме
дори най-обикновенният текстови документ
без да се налагат доработки.
Предимството на двоичните файлове е, че те
са лесно разбираеми за компютрите, което
означава, че се изисква много по-малко време
за тяхната обработка. Съхраняването им също
предполага редица предимства, като по-висока
сигурност и по-добра степен на компресия.
|
|
| Съдържание ... |
|
|
|
|
|
Текстови файлове
Текстовите файлове също както и двоичните
представляват съвкупност от битове. За разлика
от тях обаче тук битовете са групирани по
стандартни правила. На всяка една група от
битове съответства конкретно число, а на
всяко число определен символ (буква, цифра
или препирателен знак).
Пример:
Нека в текстовият файл се съдържа
следната
група от битове:
1100001
Ако групата бъде преобразувана от двоичен
код се получава числото 97, на което съответства символа "а".
Стандартите позволяват всеки един текстови
файл да бъде четен и редактиран не само
от редакторът, с помощта на който е бил създаден,
а също така и от много други. Най-общо, ако
разполагате с произволно избран текстови
файл то той ще може да се редактира с помощта
на MS Word, Notepad, WordPad, FrontPage,
Netscape, Visual Studio и др..
При своето създаване internet беше почти
изцяло текстово-базиран стандарт, което доведе
до неговото бързо разрастване, тъй като позволяваше
обмен на информация между различни платформи.
Като основен недостатък
на текстовите файлове
може да се посочат трудностите
свързани с
добавянето на метадани.
В секцията визираща работата с MEMO полетата
подробно са разгледани различичта между форматиран
и неформатиран текст.
|
|
|
| Съдържание ... |
|
|
|
|
|
Стандартни езици за форматиране на документи
Очевидно е, че както двоичните така и текстовите
файлове имат предимства и недостатъци. Разбираем
в този случай е стремежът към създаване на
универсален формат за запис и редактиране
на данни, който да съчетава универсалността
на текстовите файлове с ефикасността и богатите
възможности на двоичните такива.
Един от първите подобни опити е създаването
на SGML (Standard Generalized Markup Language).
Това е текстово-базиран език, който позволява
форматиране (mark-up) на данни. Проблемът
при този език е неговата изключителна сложност,
която бе наложена от необходимостта от описание
на сложни зависимости.
Основен наследник на SGML, който се използва
и до момента е HTML (HyperText Markup Language).
Основните предимства на HTML са възможността
да бъдат свързвани отделните парчета информация
както и визуализиране на данните, посредством
приложения, наричани браузъри.
Тъй като HTML е текстово-базиран стандарт,
то на практика всеки един текстови редактор
е в състояние да създаде такъв web-документ,
който да бъде интерпретиран от браузътрите.
Независимо от така изброените предимства
обаче HTML документите имат и редица недостатъци.
Ако например искате да покажете данните за
конкретно изделие с помощта на HTML, то това
не би ви затруднило, ако обаче се наложи
да извършвате някъкъв тип сортировка по зададен
критерий за група изделия, това може да се
окаже непосилна задача, при статична
HTML странница.
Като решение на този проблем се явява XML
(Extensible Markup Language), който обективно
погледнато не е нищо друго освен подмножество
на SGML със същите цели и функции (форматиране
на произволни по тип данни).
XML е проектиран така, че да бъде напълно
съвместим с SGML, което означава, че всеки
документ с XML синтаксис ще може да бъде
прочетен от съществуващите SGML редактори.
Това обаче не е вярно за обратния вариант.
Във високите версии на DB Manager, такъв
проблем не съществува, тъй като посредством
няколко последователни преобразувания се
извършва разбиване на един SGML документ,
на няколко, взаимносвързани XML документа.
Важно е да се знае, че XML не е език за програмиране,
а стандарт за създаване на езици, които да
отговарят на определени критерии. Най-общо
казано XML описва синтаксиса, който трябва
да се спазват когато създаваме приложения
или езици за работа с данни.
Пример:
Нека имаме изделие, което се описва с каталожен
номер, наименование и цена. Възможни са няколко
варианта:
Създаване на текстови файл със следното съдържание:
10275 Планка 15.34
Генериране на HTML файл:
<HTML>
<HEAD>
<TITLE>Product</TITLE>
</HEAD>
<BODY>
<P>10275 Планка 15.34</P>
</BODY>
</HTML>
Представяне на информацията като XML файл:
<Product>
<Code>10275</Code>
<Name>Планка</Name>
<Price>15.34</Price>
</Product>
Както може да се види от така изложеният
пример, при HTML и XML се добавя много нова
информация, съпътстваща основната. В тези
случаи обаче не размерът на файловете, а
представянето на данните са от значение.
Ако размерът е критичен за крайният потребител
то данните винаги могат да бъдат компресирани
в една или друга степен.
DB Manager на практика представя всички данни,
независимо от вида им като таблици. Макар
в това да има някакво сходство с MS Excel
или други подобни продукти, това не е точно
така. Обикновенно е прието представянето
на XML да се извършва под формата на
дървовидна структура, като се добавят и редактират
възли. Тук данните се представят в редове
и колони, което коренно променя характера
на извършваните с тях манипулации.
Очевидно е, че подобен подход, както и използването
на XSLT (Extensible Style sheet
Language
- Transformation), предполага
разделяне на
данните от тахното представяне.
По този начин
се постига една по-голяма пригледност
и достъпност
на информацията.
Основната задача при използване
на XML таблиците
в DB Manager е да се избегне
налагането на
рестриктивни правила и ограничения
при работа
с бази данни.
Всяка една база е структурирана по определена
схема (виж раздел "Бази данни").
Всяка структура и схема е обвързана с правила,
наложени от съпътстващи нейното изграждане
тестове. Ако данните се променят динамично,
това неминуемо води до промяна в методологията
на използването им. Всяка подобна промяна
автоматично довежда до нова поредица от тестове,
което е свързано със загуба на ресурси от
всякакъв характер.
Колкото е по-сложна структурата на данните,
толкова по-сложна е логиката,
която би следвало
да се реализизра, за да бъде
използването
им максимално ефективно.
DB Manager е своеобразен парсер (програма,
която извлича информацията, съдържаща
се
в един XML документ) и я представя
в достъпен
за крайният потребител вид, като
по този
начин позволява съкращаване на
времето за
тестване.
Друга особенност на DB
Manager е, че на практика
няма значение какъв език ще използваме
за
редактирането на един XML документ |
|
 |
|
| Фиг.1. Представяне на XML документ в браузър |
|
| Съдържание ... |
|
|
|
|
|
Документни типове
Един от основните проблеми не само в обмена
на информация, но и в общуването между хората
е, че понякога едно и също явление, събитие
или предмет се нарича с различни имена, което
води до объркване.
Например за едно и също нещо
може да използваме думи като: "автомобил",
"моторно, превозно средство" и
др.. Още по-сложно става, когато с един и
същи термин описваме различни по своята същност
явления.
По принцип всички дефиниции от нашето ежедневие
са не само неястни, но и непълни. Съществуват
цели раздели в математиката (като теорията
на размитите множества), чиято цел е да се
опитат да дефинират правилата, на които се
подчиняват тези определения.
За разлика от базите данни,
където полетата
и връзките (релациите) между
отделните таблици
са ясно дефинирани, при XML документите
не
е точно така.
Всеки един XML документ се състои от няколко
основни елемента както следва:
- Дефиниции и схеми (DTD, Schemas) - Това са
своеобразни шаблони, които ни позволяват
да съвместяваме различни документи.
- Пространства от имена (Name spaces) - служат
за обединяване на множество речници в един
документ.
- Език за заявки (XPath) - позволява извличане
на части от документа, без да се налага да
се използване на цялата информация.
- Хипервръзки (XPointer и XLink) - позволяват
свързването на няколко документа.
- Таблици с каскадни стилове (Cascading Style
Sheets - CSS) - служат за визуализиране на
XML документи в браузърите. В по-високите
версии се използва XSLT (Extensible Style
sheet Language).
- Обектен модел на документите (Document Object
Model - DOOM) - позволява използване на по-традиционен
интерфейс за редактиране на XML документи.
- Отдалечено извикване на процедури (Remote
Procedure Call - RPC) - Протокол позволяващ
дистрибутирана обработка, който дава възможност
на обекти намиращи се на един компютър да
извикват обекти от друг компютър за изпълнение
на дадена задача.
|
|
| Съдържание ... |
|
|
|
|
N - слойна архитектура
Както вече бе споменато
DB Manager
е типично, многослойно приложение
за работа
с бази данни.
N-слойните приложения често имат следните
логически нива:
- Слой данни - това може да бъде както база
данни, така и псевдоним или папка съдържаща
различни по съдържание, но обединени по общ
признак електронни таблици
- Обекти за данни - Обекти, чието предназначение
е да отговарят за комуникацията между базата
данни и бизнес обектите.
- Бизнес-обекти - Обекти, контролиращи бизнес-логиката
в крайното приложение, които са междинни
между представителният слой и слоят за данни.
- Представителен слой - Това може да бъде браузър
или крайно приложение, посредством което
се реализира комуникацията между потребителя
и бизнес-логиката.
Това, което трябва да се
знае е, че тези
обекти могат да бъдат разположени
върху различни
машини.
При работа с N-слойни приложения съществуват
два основни подхода: използване на съхранени
процедури и изикване на стандартна SQL заявка.
При DB Manager се използват и двата подхода,
като при първия, компилираната SQL-конструкция
се включва в крайните приложения или форми.
Освен тях обаче се използват и т.н. опростени
заявки и формули. На практика формулите изцяло
заместват агрегатните функции, но когато
се работи с XML таблици, те не използват
SQL, а собствен набор от правила.
При DB Manager слоят на обектите за данни
връща информация на слоя за бизнесобектите
в концентрирана около данните
форма. Тук
също са възможни два подхода.
При единият се използват ADO обекти. При
този подход ADO осигурява обекти,
които извличат
данни от почти всеки вид, в т.ч.
и капсулирани
SQL заявки (Recordset).
Обектите за
данни изпълняват заявките, получават
група
записи , които на свой ред биват
връщани
към бизнес-обектите.
При DB Manager представителният слой използва
XML таблици. Това позволява изключителна
гъвкавост при формиране на крайните
форми.
Препоръчително е XML документите да се използват
при комуникацията на бизнес-обектите един
с друг.
В този случай при подаване
на заявка вместо
данни (или групи от записи)
ще се връщат XML таблици. По
този начин всеки
път когато един обект от N-слойното
приложение
комуникира с друг, те ще използват
XML. |
|
 |
|
| Фиг.2. Комуникация между отделните слоеве |
|
|
Пример:
Диаграмата на фиг.2 нагледно
илюстрира работата
на DB Manager в случаите, когато
се използват
XML документи. На практика няма
никакво значение
къде са разположени данните,
а още по-малко
какъв е характерът на използваните
като презантационен
слой приложения. Напълно допустимо
е това
да бъдат ASP (Active Server Pages)
или CGI
скриптове, генериращи автоматично
HTML странници
от страна на сървъра. Възможно
е това да
са DHTML документи с JavaScript,
използващи
XML документи, базирани на работната
станция.
Това, което е важно да се знае
е, че
всеки един от обектите се създава
и функционира
в пълна независимост от всички
останали.
Този подход е за предпочитане пред CORBA
(Common Object Request Broker Architecture)
и DCOM (Distributed COM, разпределен COM),
тъй като при тях едва ли бихме гарантирали
гъвкавостта, предоставена ни от XML.
Например, ако ползваме DCOM
технология, ще
се наложи да ограничим приложенията
си, единствено
до сървъри ползващи операционните
системи
на компанията Microsoft. В този
случай обаче
освен COM+ на Windows 2000 ще
може да използваме
и Java обекти, намиращи се на
UNIX сървъри. |
|
 |
|
| Фиг.3. Презентационен слой производна форма, генерирана с DB Manager
за XML документ |
|
| Съдържание ... |
|
|
|
|
Генериране на XML таблица
Генерирането на XML таблица, по нищо не се
отличава от нормалното генериране на таблици,
за бази данни. Единствената разлика в случая
са наложените ограничения за вида на полетата.
На практика това, което
се формира е стандартен
XML документ, който може да бъде
разгледан
с произволен парсер, но DB Манагер,
ще ни
го представи или като електронна
таблица
или като форма, в зависимост
от операциите,
които извършваме спрямо него.
Това, което трябва да се
знае е, че структурата
на таблицата може да бъде записана
като XML
документ и използвана в последствие.
Макар
на мнозина това да се стори излишно
не е
така. По този начин вие осигурявате
надплатформеност
на разработените таблици. Ако
една таблица,
създадена на dBase е достатъчно
ефективна,
но се налага да преминем към
DB2 например,
няма да е необходимо да описваме
отново нейната
структура. Ако таблиците са с
относителна
малка сложност това е без значение,
но когато
съдържат повече от двадесет полета,
това
едва ли би било така. |
|
 |
|
| Фиг.4. Генериране на XML документ като таблица |
|
Както може да се види от фиг.4 типът на полетата
е максимално близък до използваните в базите
данни. По този начин не е наложително да
се изготвят сложни описания, а и тестването
на правилността на въведените параметри се
извършва в момента на генерирането на таблицата.
Използването на XML стандарта
е широко застъпено във високите
версии на
продукта. |
|
 |
|
| Фиг.5. Презентационен слой стандартна таблица,
генерирана с DB Manager за XML документ |
|
| Съдържание ... |
|
|
|
