02-Shemi Na Podatoci

С.
Калајџиски
XML шеми на
податоци
Неструктурирани бази на податоци и XML

предавања
д-р Слободан КАЛАЈЏИСКИ
НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски
Содржина на предавањето...
q Регуларни изрази за дефинирање на граматика на

некој јазик
q Document Type Definition (DTD)
q XML Schema
1
Валидност на XML документите

q  XML спецификацијата обезбедува две нивоа за процесирање на
документите: добро-изградени и валидни
q  XML документот кој е изграден според структуралните и

нотациските правила на XML се смета дека е добро-изграден
¨  Документот мора да почнува со XML декларација,
на пример <?xml version “1.0”?>
¨  Сите елементи мора да се содржат во елементот корен;
¨  Елементите мора да се вгнездени во стебловидна структура без
преклопување;
¨  Сите непразни елементи мора да имаат start-tag и end-tag;
q  Процесорот за валидација освен што ќе провери дали XML

документот е добро-изграден, во исто време ќе провери и дали
XML документот е валиден
Валидност на XML документите
q  Валидноста на XML XML

документ
документот се прави со schema
механизам кој треба да ја
провери синтаксичката
точност Schema
processor
q  На овој начин се дава валиден невалиден
значење на податоците
интегрирани во XML
документот Порака
normalized за грешка
instance
document
2
XML јазици
q XML јазик
¨  Множество на XML документи со одредена семантика
q Шема
¨  Формална дефиниција на синтаксата на XML јазикот
q Јазик за шемата
¨  Нотација за спецификација на шемата
Регуларни изрази
q Најчесто се користат во јазиците на шемата за опис на
секвенците од карактери или елементите
q Σ: азбука составена од атоми

(најчесто unicode карактери или имиња на елементите)
q Регуларниот израз над азбуката Σ треба да ги

задоволува следните критериуми:
¨  Секој атом од азбуката Σ е регуларен израз
¨  Ако α и β се регуларни изрази, тогаш и следното е регуларен

израз: α?, α*, α+, αβ, α|β и (α)
каде што ?, *, +, | се оператори во азбуката
3
q Конечна низа од атоми од Σ може да одговараат на
даден регуларен израз α:
¨  σ∈Σ се совпаѓа само со стрингот σ
¨  α? се совпаѓа во нула или едно појавување на α
¨  α* се совпаѓа со нула или повеќе појавувања на α
¨  α+ се совпаѓа со едно или повеќе појавувања на α
¨  αβ се совпаѓа со било која конкатенација на α и β
¨  α|β се совпаѓа со унијата на α и β
¨  (α) се совпаѓа со самото α
q Примери:
(a(b*))|c
q  се совпаѓа со сите стрингови кои се состојат или од едно а
следено од нула или повеќе појавувања на b или од c
0|1|2|3|4|5|6|7|8|9
q  регуларен израз за опишување на цифри
0|-?(1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)*
q  регуларен израз за опишување на цели броеви
4
caption? (col* | colgroup*) thead? tfoot? (tbody+ | tr+)

q  регуларен израз за опис на table елементот во XHTML јазикот
Задача за дома:
Да се напише регуларен израз за опишување на датуми во

формат dd-mm-yyyy
q Постојат и скратени форми на регуларните изрази
q Кога имаме низа од карактери од кои може само еден

да се појави, тогаш наместо 0|1|2|3|4|5|6|7|8|9 може да
се користи и опсег на карактери [0-9]
q Кога имаме повторување на некој регуларен израз

повеќе пати, тогаш α{n,m} означува од n до m
повторувања на α
5
Document Type Definition (DTD)

q DTD е јазик на шемата преку кој може да се
дефинира DTD шема која ја дефинира валидната
синтакса на XML документот преку:
¨  листање на имињaта на елементите кои може да се појават во

документот
¨  кои елементи може да се комбинираат со други
¨  како може да се вгнездуваат елементите
¨  кои атрибути се достапни за секој елемент и сл.
q Секој XML документ треба да содржи декларација за

типот на документот во следниот формат
<!DOCTYPE root SYSTEM “URI”>
q На овој начин се добива информација за дефиницијата

на валидната синтакса на составните елементи во XML
q Дефиницијата на шемата најчесто се чува со

надворешна датотека
6
Декларација на елементите
q  Декларациите на типот на елементите ги идентификуваат

правилата на појава на елементите во XML документот
<!ELEMENT element-name content-model>
q  Content models:

¨  EMPTY
¨  ANY
¨  mixed content: (#PCDATA|e1|e2|…|en)*
¨  element content: регуларен израз над имињата на елементите
Декларација на елементите
Construct Значење
EMPTY Празна содржина
ANY Било каква содржина
#PCDATA Низа од карактери
element name Друг елемент
, Конкатенација
| Унија
? Опционално
* Нула или повеќе повторувања
+ Едно или повеќе повторувања
7
<?xml version= “1.0” encoding= “UTF-8” standalone= “yes”?>

<?xml:stylesheet type = “test/xsl” href = “staff_list.xsl”?>
<!DOCTYPE STAFFLIST SYSTEM “staff_list.dtd”>
<STAFFLIST>
<STAFF branchNo = “B005”>
<STAFFNO>SL21</STAFFNO>
<NAME>
<FNAME>John</FNAME><LNAME>White</LNAME>
</NAME>
<POSITION>Manager</POSITION>
<DOB>1945-10-01</DOB>
<SALARY>30000</SALARY>
</STAFF>
<STAFFNO>SG37</STAFFNO>
<NAME>
<FNAME>Ann</FNAME><LNAME>Beech</LNAME>
</NAME>
<POSITION>Assistant</POSITION>
</STAFF>
</STAFFLIST>

<!ELEMENT STAFFLIST (STAFF)*>
Asteriks (*) нула или повеќе појавувања на елементот;
Plus (+) едно или повеќе појавувања на елементот;
Question mark (?) или нула или точно едно појавување на елементот;
Име без пунктуациска ознака треба да се појави точно еднаш;
<!ELEMENT STAFF(STAFFNO, NAME, POSITION, DOB?, SALARY)>

Запирките помеѓу елементите го означуваат редоследот на појавување на
елементите. Ако нема запирки може да се појават по било кој редослед
<!ELEMENT POSITION (#PCDATA)>

#PCDATA означува parsable character data
Елементите може да содржат и комбинација на други елементи и #PCDATA
8
Декларација на атрибутите
q Преку декларацијата на листа на атрибути може да се

идентификува кои елементи може да имаат атрибути
<!ATTLIST element-name att-definitions>
q  Секоја дефиниција на атрибутот се состои од:

¨  име на атрибутот
¨  тип на атрибутот
¨  default декларација (опционална)
Тип на атрибут Значење
CDATA character data, содржи било каков текст

се користи за идентификација на индивидуални елементи во
ID документот
IDREF или мора да одговараат на вредностите од единечните ID
IDREFS атрибути за одреден елемент во документот
ENTITY или
мора да одговара на име од одреден ентитет
ENTITIES
NMTOKEN или
ограничена форма на стринг, обично се состои од еден збор
NMTOKENS
Листа на
вредности кои може да ги прими атрибутот
вредности
9
q default декларација на атрибутите:
¨  #REQUIRED
¨  #IMPLIED
¨  “value”
¨  #FIXED “value”
<!ATTLIST p align (left|center|right|justify) #IMPLIED>
<!ATTLIST form
action CDATA #REQUIRED
onsubmit CDATA #IMPLIED
method (get|post) "get"
enctype CDATA "application/x-www-form-urlencoded">

<!ATTLIST STAFF branchNo CDATA #IMPLIED>

#IMPLIED – опционален атрибут,
#REQUIRED – атрибутот е обавезен,
#FIXED – атрибутот секогаш ја прима предодредената вредност
<!ATTLIST STAFF gender (M|F) “M”>

Пример на дефинирање на атрибут кој може да прими една од две вредности
10
Идентитет на елементите, ID и ID референци
q XML резервира тип на атрибут ID кој овозможува

единствен клуч да се асоцира како вредност на
атрибутот
q Типот на атрибут IDREF овозможува дефинирање на

покажувач кон друг елемент кој има атрибут ID
асоцирана на бараниот клуч
q Типот IDREFS е сличен како IDREF, само што

овозможува покажување кон повеќе елементи

q Пример:
<STAFF staffNo = “SL21”>
<NAME>
</NAME>
</STAFF>
<STAFF staffNo = “SL41”>
<NAME>
<FNAME>Julie</FNAME><LNAME>Lee</LNAME>
</NAME>
</STAFF>
<BRANCH staff = “SL21 SL41”>
<BRANCHNO>B005</BRANCHNO>
</BRANCH>
<!ATTLIST STAFF staffNo ID #REQUIRED>

<!ATTLIST BRANCH staff IDREFS #IMPLIED>
Ако ја моделираме врската Branch Has Staff, може да ги дефинираме
атрибутите staffNo и staff за STAFF и BRANCH елементите соодветно
11
Декларација на ентитети
q Декларациите на ентитети асоцираат одредено име со

некој дел од содржината, како дел од регуларниот
текст, дел од DTD, или референца кон надворешна
датотека која содржи текст или бинарни податоци
q Нотациските декларации идентифираат надворешни

бинарни податоци, кои се праќаат од XML пpоцесорот
кон апликацијата

<!ENTITY DH “DreamHome Estate Agents”>

Пример за дефинирање на ентитетот DH како кратенка за текстот
“DreamHome Estate Agents”
<!ENTITY copyrightnotice “Copyright © 2005 Widgets’R’US.”>

Пример за користење на ENTITY copyright:
A gadget has a medium size head and a big gizmo subwidget. &copyrightnotice;
A gadget has a medium size head and a big gizmo subwidget.

Copyright © 2005 Widgets’R’US.
12

<!ENTITY dreamHomeLogo SYSTEM “dreamhome.jpg” NDATA JPEGFormat>

<!NOTATION JPEGFormat SYSTEM “http://www.jpeg.org”>
Процесирањето на надворешните непарсирани ентитети треба да го направи

апликацијата. Одредена информација за внатрешниот формат на ентитетот
мора да се декларира после идентификаторот за локацијата на ентитетот
NDATA означува дека ентитетот е непарсиран, по што се специфицира клуч за

декларацијата на нотацијата која следи. Декларацијата на нотацијата го
споредува ова име со идентификатор кој го користи апликацијата за тоа како да
се справи со ентитетот

<STAFFLIST>
<NAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>
<NAME>
</NAME>
</STAFF>
</STAFFLIST>
13

q Спред претходните дефиниции, DTD за претходниот
XML пример е следниот:
<!ELEMENT STAFFLIST (STAFF)*>

<!ELEMENT STAFF (STAFFNO, NAME, POSITION, DOB?, SALARY)>
<!ELEMENT NAME (FNAME, LNAME)>
<!ELEMENT FNAME (#PCDATA)>
<!ELEMENT LNAME (#PCDATA)>
<!ELEMENT POSITION (#PCDATA)>
<!ELEMENT DOB (#PCDATA)>
<!ELEMENT SALARY (#PCDATA)>
<!ATTLIST STAFF branchNo CDATA #IMPLIED>
Пример за вежбање
<collection>
<description>Recipes suggested by Jane Dow</description>
<recipe id="r117">
<title>Rhubarb Cobbler</title>
<date>Wed, 14 Jun 95</date>
<ingredient name="diced rhubarb" amount="2.5" unit="cup"/>

<ingredient name="sugar" amount="2" unit="tablespoon"/>
<ingredient name="fairly ripe banana" amount="2"/>
<ingredient name="cinnamon" amount="0.25" unit="teaspoon"/>
<ingredient name="nutmeg" amount="1" unit="dash"/>
<preparation>
ЗА ДОМА:
<step>Combine all and use as cobbler, pie, or crisp.</step>
</preparation>
<comment> За дадениот XML
Rhubarb Cobbler made with bananas as the main sweetener. документ да се
It was delicious.
</comment> напише
<nutrition calories="170" fat="28%" carbohydrates="58%" protein="14%"/> соодветната DTD
<related ref="42">Garden Quiche is also yummy</related>
</recipe>
шема за истиот да
</collection> биде валиден!
14
Ограничувања на DTD
q  нема ограничувања за CDATA
q  спецификацијата на вредностите за атрибутите е премногу

лимитирана
q  декларациите на елементите и атрибутите се контекстно

зависни
q  поддршката за модуларност, повторно-користење и еволуција

е многу примитивна
q  ID/IDREF механизмот е премногу едноставен
q  нема поддршка за namespaces
q  не користи XML синтакса!
XML Schema
q W3C предлог за замена на DTD
q Предности на XML Schema

¨  поекспресивна отколку DTD
¨  користи XML нотација
¨  само-опишувачка
¨  едноставна
q Што поддржува XML Schema

¨  namespaces
¨  кориснички дефинирани податочни типови
¨  наследување
¨  еволуција
¨  ...
15
Типови и декларации
q Дефиниција на прости типови:
Дефинира фамилија на unicode текстуални стрингови
q Дефиниција на сложени типови:

Дефинира колекција од барања за атрибутите и под-елементите
кои ќе го користат овој тип
q Декларација на елементите:
Придружување на прост или сложен тип на името на елементот
q Декларација на атрибутите:
Придружување на прост тип кон името на атрибутот
Типови кај XML шемата

тип пример
string било кој unicode стринг
boolean true, false, 1, 0
decimal 3.1415
float 6.02214199e23
double 42E970
dateTime 2008-09-26T16:29:00-05:00
time 16:29:00-05:00
date 2008-09-26
hexBinary 48656c6c6f0a
Стандардни
base64Binary SGVsbG8K прости типови кај
anyURI http://www.brics.dk/ixwt/ XML шемата
QName rcs:recipe, recipe
16
Типови кај XML шемата

q Стандардни прости типови:
q anySimpleType
¨  е унија од сите примитивни типови, односно кога е
специфициран ваков тип, може да се користи било кој
примитивен тип
q anyType
¨  е унија на сите типови, односно кога е специфициран, тогаш
атрибутот може да прими било кој податочен тип
Изведување нови типови на податоци
q Нови прости типови може да се добијат преку

ограничување на вредностите кои може да ги примаат
веќе постоечките прости типови на податоци
q Се користат следните изведувања на веќе постоечките

типови на податоци:
¨  ограничување на вредностите

¨  листа на вредности
¨  унија на вредности
17
Нови типови преку ограничување на постоечките
q Рестрикција на некој постоечки тип (наречен base type)

дефинира нов тип со спецификација на ограничувања
на вредностите од постоечкиот тип
q  Што се може да се ограничува кај основните типови на податоци:
length minLength maxLength
pattern enumeration whiteSpace
maxInclusive maxExclusive minInclusive
minExclusive totalDigits fractionDigits
Примери за изведени типови

<simpleType name=“poeni_od_0_do_100”>
<restriction base=“integer”>
<minInclusive value=“0”/>
<maxInclusive value=“100”/>
</restriction>
</simpleType>
Ограничување на опсегот на вредности на цели бореви
<simpleType name=“procent”>
<restriction base=“string”>
<pattern value=“([0-9]|[1-9][0-9]|100)%”/>
</restriction>
</simpleType>
Тип на податок кој ќе дефинира опсег од 0 до 100 %
18
Примери на изведени типови

Да се дефинира прост тип
<simpleType name=“STAFFNOTYPE”> на податок за типот на
вработените. Имено типот
<restriction base=“string”> на вработените е стринг
<maxLength value=“5”/> со максимална должина
<pattern value=“[A-Z]{2}[0-9]{1,3}”/> од 5 карактери од кои
првите два се секогаш
</restriction> букви, а останатите три се
</simpleType> бројки
<simpleType name=“POSITIONTYPE”>
<restriction base=“string”> Да се дефинира тип на
<enumeration value=“Manager”/> податок за позицијата на
вработените, при што
<enumeration value=“Supervisor”/> позицијата може да биде
<enumeration value=“Assistant”/> една од Manager,
Supervisor или Assistant
</restriction>
</simpleType>
Листи од прости типови
q Преку list елементот може да се специфицира листа

од ставки кои ќе бидат одделени со празни места
<simpleType name=“STAFFNOLIST”>
<list itemType=“STAFFNOTYPE”/>
</simpleType>
q Оваа листа може да се користи во XML документот

како:
<STAFFNOLIST>”SG5” “SG37” “SG999”</STAFFNOLIST>
19
Унии од прости типови

q Со користење на union може да се добие унија на
податочните типови кои влегуваат во дефиницијата на
простиот тип
<simpleType name="boolean_or_decimal">
<union>
<simpleType>
<restriction base="boolean"/>
</simpleType>
<simpleType>
<restriction base="decimal"/>
</simpleType>
</union>
</simpleType>
Дефинирање на нови типови

q Аналогно со ОО парадигма:
се дефинира класа од која потоа се инстанцираат објекти
q Новиот тип треба да содржи име и дефиниција

лоцирана надвор од дефиницијата на елементите и
атрибутите
q Елементите и атрибутите треба да искористат веќе

дефиниран тип во својата дефиниција
20
Поделба на елементите според типот

q complexType
¨  елементот ако содржи други елементи, тогаш тој е сложен
¨  најчесто коренот е од овој тип
q simpleType
¨  елементите кои немаат под-елементи
¨  и атрибути се од прост тип
Елементи кај XML шемата

q Прост елемент:
<element name=“el_name” type=“el_type”/>

*типот на простите елементи треба да биде некој прост тип на податок
q Сложен елемент:
<element name=“el_name”>
<complexType>
<sequence>

</sequence>
</complexType>
</element>
21
Елементи кај XML шемата

q Сложен елемент:
¨  Освен sequence при декларирањето на сложените
елементи може да се користи и:
тип пример
sequence конкатенација
choice унија
all Неподредена секвенца
any Било кој елемент
group Named sub expression
Кардиналност
q Преку XML шемата може да се прикаже и интервалот
на појавувања на инстанците на одреден елемент
преку специфицирање на параметрите:
¨  minOccurs, минимален број на појавувања на елементот

¨  maxOccurs, максимален број на појавувања на елементот
*Ако не се специфицираат, стандардните вредности на овие параметри се 1 и unbounded
22
Дефинирање сложени типови

<complexType name=“card_type”>
<sequence> Се дефинира тип на
податок репрезент на
<element name=“NAME” type=“string”/>
бизнис картичка.
<element name=“TITLE” type=“string”/>
<choice> Структурата на
<element name=“EMAIL” type=“string”/> ваквиот тип на
<element name=“PHONE” type=“string”/> елемент ќе има име,
титула, опционално
</choice>
лого и е-mail или
<element name=“LOGO” type=“pict” minOccurs=“0”/> телефонски број на
</sequence> сопственикот!
</complexType>
Пример
<STAFFLIST>
<NAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>
<NAME>
</NAME>
</STAFF>
</STAFFLIST>
23
Пример
<element name=“STAFFLIST”>
<complexType> Следејќи ја претходната структура
коренот STAFFLIST може да се
<sequence>
дефинира како сложен елемент.

</sequence> На сличен начин ќе се дефинираат
</complexType> и STAFF и NAME елементите
</element>
<element name=“STAFFNO” type = “string”/>

<element name=“DOB” type = “date”/>
<element name=“SALARY” type = “decimal”/>
Дефинирањето на простите елементи е прилично едноставно. Се специфицира името на
елементот и се специфицира соодветниот тип на вредноста која што може да ја прими
<attribute name=“branchNo” type = “string”/>

И дефиницијата на атрибутите е слична како и простите елементи
<element name=“STAFFLIST”>
<complexType>
<sequence>
<element name=“STAFF”>
<complexType>
<sequence>
<element name=“STAFFNO” type = “string”/>
<element name=“NAME”>
<complexType>
<sequence>
<element name=“FNAME” type=“string”/>
<element name=“LNAME” type=“string”/>
</sequence>
</complexType>
</element>
<element name=“DOB” type = “date” minOcurrs=“0”/>
<element name=“SALARY” type=“decimal”/>
<attribute name=“branchNo” type = “string”/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
24
Референци
q  Ако се погледне дефиницијата на претходниот пример, може да

се забележи дека добиената структура е премногу вгнездена и
тешко се следи
q  Со користење на референци до елементите и атрибутите може

да се поедностави изгледот на ваквата дефиниција на
q  Дефиницијата на елементот да биде на едно место во

документот, а повеќекратното користење да оди преку
референци
Користење на референците
q  Ако елементот SALARY го дефинираме како:
<element name=“SALARY” type=“float”/>
q  Тогаш на соодветното место во XML документот може да

повикаме:
<element ref=“SALARY”/>
q  Односно се референцираме кон соодветната дефиниција на

SALARY елементот
q  На овој начин една дефиниција на елемент може да се

искористи на повеќе места!
25
Групи
q  Преку XML шемата може да се дефинираат групи на елементи и
групи на атрибути
q  Групата не е податочен тип, туку е контејнер во кој се чуваат

елементите и атрибутите
q  На овој начин исто така може да се поедностави дефинирањето

на сложената вгнездена структура која ја видовме во примерот
Пример
Со ова се <group name = “STAFFTYPE”>
креира група на
елементи која <sequence>
после може да <element name = “STAFFNO” type = “STAFFNOTYPE”/>
се искористи во
дефинирањето <element name = “POSITION” type = “POSITIONTYPE”/>
на сложениот <element name = “DOB” type = “date”/>
тип на елемент
STAFFLIST
<element name = “SALARY” type = “decimal”/>
</sequence>
</group>
Оваа <element name=“STAFFLIST”>

дефиниција <complexType>
потоа би се <group ref=“STAFFTYPE” minOccurs=“0” maxOccurs=“unbounded”/>
искористила на
следниот </complexType>
начин: </element>
26
Пример за групи на атрибути

<attributeGroup name=“Focus”>
<attribute ref=“xhtml:accesskey”/>
<attribute ref=“xhtml:tabindex”/>
<attribute ref=“xhtml:onfocus”/>
<attribute ref=“xhtml:onblur”/>
</attributeGroup>
Кога еднаш ќе
<complexType name=“SelectType” mixed=“true”> се дефинира
<choice maxOccurs=“unbounded”> групата на
атрибути, таа
<element ref=“xhtml:optgroup”/> може да се
<element ref=“xhtml:option”/> користи онолку
</choice> пати колку што
<attribute group ref=“xhtml:Focus”> е потребно.
. . .
</complexType>
<complexType name=“TextAreaType” mixed=“true”>

. . .
<attribute group ref=“xhtml:Focus”>
</complexType>
Композитори
q Во групата на композитори спаѓаат:
¨  sequence
¨  choice
¨  all
q  Sequence дефинира подредено множество од елементи
q  Choice дефинира избор од неколку можни елементи или групи од

елементи
q  All дефинира неподредено множество од елементи
27
Пример
q  Да се дефинира елементот NAME преку кој ќе може да се

избира дали вработениот ќе има само едно име, или
комбинација од име и презиме.
<group name=“STAFFNAMETYPE”>
<choice>
<element name=“NAME” type=“string”/>
<sequence>
</sequence>
</choice>
</group>
Ограничувања
q XML шемата освен стандардните ограничувања,
обезбедува и XPath базирани ограничувања, како што
се:
¨  Ограничувања за единственост

(uniqueness constraints)
*кои елементи или атрибути не треба да се повторуваат
¨  Ограничувања за клучеви

(key constraints)
*слично како ограничувањата за единственост; овде вредностите не смее да се null
28
Примери
<unique name = “NAMEDOBUNIQUE”>

<selector xpath = “STAFF”/>
<field xpath = “NAME/LNAME”/>
<field xpath = “DOB”/>
</unique>
На овој начин се дефинира не-повторувањето на вредностите кои може да се
појават во елементите LNAME и DOB
<key name = “STAFFNOISKEY”>

<selector xpath = “STAFF”/>
<field xpath = “STAFFNO”/>
</key>
На овој начин се кажува дека вредноста на под-елементот STAFFNO во
STAFF треба да биде неповторлива и единствена.
Слично како клучевите кај релационите бази на податоци!
Пример
<STAFFLIST>
<NAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>
<NAME>
</NAME>
</STAFF>
</STAFFLIST>
29
Решение на примерот (1/3)

<?xml version=“1.0” encoding=“UTF-8”?>
<schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema”>

STAFFTYPE е група
<group name=“STAFFLISTGROUP”> во која ќе се чуваат
<element name=“STAFFLIST”> вработените и ќе биде
<complexType> дополнително
дефинирана
<sequence>
<group ref=“STAFFTYPE” minOccurs=“0” maxOccurs=“unbounded”/>
</sequence>
</complexType>
</element>
</group>

<simpleType name=“STAFFNOTYPE”>
<maxLength value=“5”/>
<pattern value=“[A-Z]{2}[0-9]{1,3}”/>
</restriction>
</simpleType>


<simpleType name=“BRANCHNOTYPE”>
<maxLength value=“4”/>
<pattern value=“[A-Z][0-9]{3}”/>
</restriction>
</simpleType>


<simpleType name=“POSITIONTYPE”>
<enumeration value=“Manager”/>
<enumeration value=“Supervisor”/>
<enumeration value=“Assistant”/>
</restriction>
</simpleType>
30


<group name=“STAFFTYPE”>
<element name=“STAFF”>
<complexType>
<sequence>
<element name=“STAFFNO” type=“STAFFNOTYPE”/>
<element name=“NAME”>
<complexType>
<sequence>
</sequence>
</complexType>
</element>
<element name=“POSITION” type=“POSITIONTYPE”/>
<element name=“DOB” type=“date” minOccurs=“0”/>
<element name=“SALARY” type=“decimal”/>
<attribute name=“branchNo” type=“BRANCHNOTYPE”/>
</sequence>
</complexType>
</element>
</group>
</schema>
31

02-Shemi Na Podatoci

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02-Shemi Na Podatoci

Uploaded by

Copyright:

Available Formats

С.

Неструктурирани бази на податоци и XML

д-р Слободан КАЛАЈЏИСКИ

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

q Регуларни изрази за дефинирање на граматика на

q Document Type Definition (DTD)

Валидност на XML документите

q XML документот кој е изграден според структуралните и

q Процесорот за валидација освен што ќе провери дали XML

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

Валидност на XML документите

q Валидноста на XML XML

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

q Σ: азбука составена од атоми

q Регуларниот израз над азбуката Σ треба да ги

¨ Ако α и β се регуларни изрази, тогаш и следното е регуларен

¨ α? се совпаѓа во нула или едно појавување на α

¨ α* се совпаѓа со нула или повеќе појавувања на α

¨ α+ се совпаѓа со едно или повеќе појавувања на α

¨ αβ се совпаѓа со било која конкатенација на α и β

¨ α|β се совпаѓа со унијата на α и β

¨ (α) се совпаѓа со самото α

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

caption? (col* | colgroup*) thead? tfoot? (tbody+ | tr+)

Да се напише регуларен израз за опишување на датуми во

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

q Постојат и скратени форми на регуларните изрази

q Кога имаме низа од карактери од кои може само еден

q Кога имаме повторување на некој регуларен израз

Document Type Definition (DTD)

¨ листање на имињaта на елементите кои може да се појават во

¨ кои елементи може да се комбинираат со други

¨ како може да се вгнездуваат елементите

¨ кои атрибути се достапни за секој елемент и сл.

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

Document Type Definition (DTD)

q Секој XML документ треба да содржи декларација за

<!DOCTYPE root SYSTEM “URI”>

q На овој начин се добива информација за дефиницијата

q Дефиницијата на шемата најчесто се чува со

q Декларациите на типот на елементите ги идентификуваат

<!ELEMENT element-name content-model>

q Content models:

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

<?xml version= “1.0” encoding= “UTF-8” standalone= “yes”?>

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

Document Type Definition (DTD)

<!ELEMENT STAFF(STAFFNO, NAME, POSITION, DOB?, SALARY)>

<!ELEMENT POSITION (#PCDATA)>

q Преку декларацијата на листа на атрибути може да се

<!ATTLIST element-name att-definitions>

q Секоја дефиниција на атрибутот се состои од:

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

Тип на атрибут Значење

CDATA character data, содржи било каков текст

НЕСТРУКТУРИРАНИ БАЗИ НА ПОДАТОЦИ И XML - предавања д-р С. Калајџиски

Document Type Definition (DTD)

<!ATTLIST STAFF branchNo CDATA #IMPLIED>

<!ATTLIST STAFF gender (M|F) “M”>

Идентитет на елементите, ID и ID референци

q XML резервира тип на атрибут ID кој овозможува

q Типот на атрибут IDREF овозможува дефинирање на

q Типот IDREFS е сличен како IDREF, само што

q Регуларни изрази за дефинирање на граматика на

q Document Type Definition (DTD)

q  XML документот кој е изграден според структуралните и

q  Процесорот за валидација освен што ќе провери дали XML

q  Валидноста на XML XML

q Σ: азбука составена од атоми

q Регуларниот израз над азбуката Σ треба да ги

¨  Ако α и β се регуларни изрази, тогаш и следното е регуларен

¨  α? се совпаѓа во нула или едно појавување на α

¨  α* се совпаѓа со нула или повеќе појавувања на α

¨  α+ се совпаѓа со едно или повеќе појавувања на α

¨  αβ се совпаѓа со било која конкатенација на α и β

¨  α|β се совпаѓа со унијата на α и β

¨  (α) се совпаѓа со самото α

q Постојат и скратени форми на регуларните изрази

q Кога имаме низа од карактери од кои може само еден

q Кога имаме повторување на некој регуларен израз

¨  листање на имињaта на елементите кои може да се појават во

¨  кои елементи може да се комбинираат со други

¨  како може да се вгнездуваат елементите

¨  кои атрибути се достапни за секој елемент и сл.

q Секој XML документ треба да содржи декларација за

q На овој начин се добива информација за дефиницијата

q Дефиницијата на шемата најчесто се чува со

q  Декларациите на типот на елементите ги идентификуваат

q  Content models:

q Преку декларацијата на листа на атрибути може да се

q  Секоја дефиниција на атрибутот се состои од:

q XML резервира тип на атрибут ID кој овозможува

q Типот на атрибут IDREF овозможува дефинирање на

q Типот IDREFS е сличен како IDREF, само што

q Декларациите на ентитети асоцираат одредено име со

q Нотациските декларации идентифираат надворешни

<!ENTITY copyrightnotice “Copyright © 2005 Widgets’R’US.”>

q  спецификацијата на вредностите за атрибутите е премногу

q  декларациите на елементите и атрибутите се контекстно

q  поддршката за модуларност, повторно-користење и еволуција

q  ID/IDREF механизмот е премногу едноставен

q  нема поддршка за namespaces

q  не користи XML синтакса!

q Предности на XML Schema

q Што поддржува XML Schema

q Дефиниција на сложени типови:

q Нови прости типови може да се добијат преку

q Се користат следните изведувања на веќе постоечките

¨  ограничување на вредностите

q Рестрикција на некој постоечки тип (наречен base type)

q  Што се може да се ограничува кај основните типови на податоци:

q Преку list елементот може да се специфицира листа

q Оваа листа може да се користи во XML документот

q Новиот тип треба да содржи име и дефиниција

q Елементите и атрибутите треба да искористат веќе

¨  minOccurs, минимален број на појавувања на елементот