Schemele de date sunt baza tuturor paginilor XML. Ele definesc obiectele, relațiile lor, atributele lor și structura modelului de date. Fără ele, documentele XML nu ar exista.
Schema de date, cu toate aspectele tehnice deoparte, este modelul de date cu care sunt transmise toate informațiile XML. Are o structură ierarhică, care începe cu un element rădăcină (care va fi explicat mai târziu) și merge până la capăt pentru a acoperi chiar și cel mai mic detaliu al modelului, cu pași detaliați între ele. Schemele de date au două părți principale, entitățile și relațiile lor. Entitățile conținute într-o schemă de date reprezintă obiecte din model. Au identificatori unici, atribute și nume pentru ce fel de obiect sunt. Relațiile din schemă reprezintă relațiile dintre obiecte, destul de simple. Relațiile pot fi unul la unu, unul la mai mulți, mulți la mulți, recursive și de orice alt tip pe care l-ați putea găsi într-un model de date. Acum vom începe să creăm propria noastră schemă de date.
Începeți schema corect
Toate schemele încep la fel, indiferent de tipul de obiecte pe care le reprezintă. Prima linie din fiecare schemă este această declarație:
<?xml version="1.0" encoding="UTF-8"?>
Expunerea 1: Declarația XML
Expunerea 1 spune pur și simplu browserului sau oricărui fișier/program care accesează această schemă că este un fișier XML și utilizează structura de codificare „UTF-8”. Puteți copia acest lucru pentru a-l utiliza pentru a începe propriul fișier XML. Urmează declarația Namespace:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified">
Expunerea 2: Declarația Namespace
Namespace (spațiile de nume) sunt practic dicționare care conțin definiții ale majorității codurilor din schemă. De exemplu, atunci când creați o schemă, dacă declarați un obiect ca fiind de tip „String”, definiția tipului „String” este conținută în Namespace împreună cu toate atributele sale. Acest lucru este valabil pentru majoritatea codului pe care îl scrieți. Dacă ați făcut sau ați văzut alte scheme, cea mai mare parte a codului este prefațată de „xsd:”. Un exemplu bun este ceva de genul „xsd:sequence” sau „xsd:complexType”. sequence și complexType sunt ambele obiecte definite în Namespace care a fost legat de prefixul „xsd”. De fapt, teoretic ați putea denumi orice spațiu de nume implicit, atâta timp cât l-ați referit în același mod în schemă. Cel mai comun spațiu de nume care conține majoritatea obiectelor XML este http://www.w3.org/2001/XMLSchema. Acum trecem la expunerea 2.
Prima parte permite oricărui fișier/program să știe că acest fișier este o schemă. Destul de ușor de înțeles. La fel ca declarația XML, aceasta este universală pentru schemele XML și o poți utiliza în a ta. A doua parte este declarația Namespace; xmlns înseamnă XML NameSpace. Aceasta definește spațiul de nume implicit al schemei și este de obicei cel dat în cod. Din nou, aș recomanda să utilizați acest cod pentru a vă porni schemele. Ultima parte este greu de înțeles, dar iată o explicație destul de detaliată. Utilizarea „necalificată” este cea mai aplicabilă până când ajungeți la un cod cu adevărat complicat.
Entitățile în general
Entitățile sunt practic obiectele pentru care o schemă este creată pentru a le reprezenta. După cum s-a spus anterior, ele au atribute și relații. Acum vom merge mult mai departe în a explica exact ce sunt acestea și cum să scriem cod pentru ele.
Există două tipuri de entități: simpleType și complexType. Un obiect simpleType are asociată o valoare. Un șir (string) este un exemplu perfect de obiect simpleType, deoarece conține doar valoarea șirului. Cele mai multe simpleTypes utilizate vor fi definite în Namespace implicit; cu toate acestea, vă puteți defini propriul tip simplu în partea de jos a schemei (acesta va fi afișat în secțiunea de restricții). Din acest motiv, singurele obiecte pe care va trebui să le includeți cel mai adesea în schemă sunt complexTypes. Un complexType este un obiect cu mai mult de un atribut asociat și poate avea sau nu un element copil atașat. Iată un exemplu de obiect complexType:
<xsd:complexType name="GenreType">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="movie" type="MovieType" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
Expunerea 3: Elementul complexType
Acest cod începe cu declararea unui complexType și a numelui acestuia. Când alte entități se referă la el, cum ar fi un element părinte, se va referi la acest nume. A doua linie începe secvența de atribute și elemente copil, care sunt toate declarate ca „element”. Elementele sunt declarate ca elemente cu prima parte a liniei de cod, iar numele lor la care se vor referi alte documente este inclus ca „name” ca a doua parte. După primele două declarații vine declarația „type”. Rețineți că pentru elementele name și description tipul lor este „xsd:string”, ceea ce arată că șirul de tip este definit în spațiul de nume „xsd”. Pentru elementul movie, tipul este „MovieType” și, deoarece nu există spațiu de nume înainte de „MovieType”, se presupune că acest tip este inclus în această schemă. (s-ar putea referi la un tip definit într-o altă schemă dacă cealaltă schemă a fost inclusă în partea de sus a schemei. Nu vă faceți griji pentru asta acum) „minOccurs” și „maxOccurs” reprezintă relația dintre Genre și MovieTypes. „minOccurs” poate fi fie 0, fie un număr arbitrar, în funcție doar de modelul de date. „maxOccurs” poate fi fie 1 (o relație unu la unu), un număr arbitrar (o relație unu la mai mulți) sau „nelimitat” (o relație unu la mai mulți).
Pentru fiecare schemă, trebuie să existe un element rădăcină. Această entitate conține toate celelalte entități de sub ea în ierarhie. De exemplu, atunci când se creează o schemă care să includă o listă de filme, elementul rădăcină ar fi ceva de genul MovieDatabase, sau poate MovieCollection, doar ceva care ar conține în mod logic toate celelalte obiecte (cum ar fi genul, filmul, actorul, regizorul, plotul etc.) Se începe întotdeauna cu această linie de cod: <xsd:element name=”xxx”> care arată că este elementul rădăcină și apoi continuă ca un complexType normal. Toate celelalte obiecte vor începe fie cu simpleType, fie cu complexType. Iată un exemplu de cod pentru un element rădăcină MovieDatabase:
<xsd:element name="MovieDatabase">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Genre" type="GenreType" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Expunerea 4: Elementul rădăcină
Aceasta reprezintă o bază de date MovieDatabase în care elementul copil al bazei de date MovieDatabase este un Genre. De acolo se trece la mivie, etc.
(Include texte din Wikibooks traduse și adaptate de Nicolae Sfetcu)
Marketing ecologic în Uniunea Europeană
Într-o economie globalizată, nivelurile medii de consum sunt în creştere ca urmare: a populaţiei mondiale în creştere; sporirii numărului de consumatori cu venituri medii şi mici şi extinderii unei culturi generale a consumului; sistemelor economice din societăţile industrializate bazate pe … Citeşte mai mult
Ghid pagini Facebook – Campanii de promovare pe Facebook
Paginile Facebook sunt cea mai simplă modalitate de a dezvolta o afacere online. Sunt gratuite, relativ ușor de configurat, și foarte flexibile. Indiferent dacă vrei să vinzi un produs sau un serviciu, sau să promovezi o organizaţie, o idee sau … Citeşte mai mult
Filosofia tehnologiei blockchain – Ontologii
Despre necesitatea şi utilitatea dezvoltării unei filosofii specifice tehnologiei blockchain, accentuând pe aspectele ontologice. După o Introducere în care evidenţiez principalele direcţii filosofice pentru această tehnologie emergentă, în Tehnologia blockchain explicitez modul de funcţionare al blockchain, punând în discuţie direcţiile ontologice de dezvoltare … Citeşte mai mult
Lasă un răspuns