отливка независимост

Независимост на данни може да се прилага в две нива: физическа и логическа [1,3], [1,4]. Въпреки това, на този етап, ние се интересуваме само от физическа независимост. Ето защо, неквалифициран термин независимост на данните, ние ще трябва да се разбира само като физическа независимост на данните. (Трябва да се отбележи, че терминът, независимо от данните, не е съвсем перфектно - тя не отразява същността на това, което се случва, но достатъчно точно традиционно се използва този термин, следвайте общото правило ..)

Най-лесният начин да се разбере концепцията на независимостта на данните по примера на ситуация, в която липсва независимост на данните. Заявление, приложена в по-старите системи (dorelyatsionnye или започна преди появата на системи за бази данни), в

до известна степен в зависимост от данните. Това означава, че процесът на организиране на данните във вторичен

памет и как да получите достъп до тях са продиктувани от изискванията на приложението. Освен това, информация за организацията на данни и достъпа до тях са вградени в логиката и код на приложението. Например, да предположим, че в някои приложения използват СЛУЖИТЕЛ файл (вж. Фиг. 1.4). От съображения за изпълнение се съгласиха, че файлът трябва да се индексират на терена, "име на служител" (вж. Приложение D). При по-старите системи, приложението ще бъдат взети под внимание, че съществува такъв индекс, и че последователността на записите във файл, определен от този индекс. Въз основа на тази информация, всички от вътрешната структура на заявлението ще бъде построен. По-специално, от избрания метод за изпълнение на процедурите за достъп и обработка на изключения в голяма степен зависи от характеристиките на интерфейса, предоставен от програми за управление на данни.

Приложения, като е описано в този пример, се наричат ​​данни-зависима, тъй като е невъзможно да се променя физическото представяне (т.е., физическото местоположение на данни на вторичния паметта) или метода за достъп (т.е., по специфичен начин за достъп до данни), без да се променя самото приложения (може би доста радикално). Например, не е възможно да се замени индексиран файл в нашия пример, хешираното файл без да се правят значителни промени в заявлението. Освен това, промените в такива случаи да са тези части на заявлението, че взаимодействат със софтуера за управление на данните. Трудностите, срещнати по този начин, нямат отношение към проблема, решението за който заявлението е написано; то предизвикателствата, породени от структура, използвана от интерфейса за управление на данни.

Въпреки това, системата от база данни е силно нежелателно, зависи от прилагането на данни, които са на най-малко две причини, описани по-долу.

1. Различни приложения изискват различни изгледи на едни и същи данни.

Например, да предположим, че преди преминаването към интегрирана база данни, преди приемането има две приложения, А и Б. Всяка една от тях работят със собствен файл, съдържащ "баланс по сметката на клиента." мислеха

също така, че заявление за записва тази стойност в десетичен формат,

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

стойности на полетата в десетичен формат, всеки препратка към приложение Б

изисква пряка или обратна трансформация стойности от десетична в двоична коефициенти мат.

Това е доста прост пример за разликите, които могат да съществуват в системата на база данни между представянето на данните във формуляра за кандидатстване и тяхното физическо съхранение. Много други възможни различия ще бъдат обсъдени по-долу.

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

По този начин, като се гарантира независимостта на данните - най-важната цел на система за база данни. Независимо от данните могат да бъдат дефинирани като имунитет на заявления за промени в физическото представяне на данните и методите на достъп до тях, което означава, че прилагането на обект, който не зависи от някакви специфични методи на физическо представяне или на избраните методи за достъп. Глава 2 ще бъде описана архитектура на системи за бази данни, предоставя основа за постигането на тази цел. Но преди всичко, нека разгледаме по-подробно някои примери за видовете промени в изпълнението на които може да са необходими и които, следователно, трябва да бъде имунни приложения.

Нека започнем с определението на три нови условия: (. Фигура 1.6) съхранената област, съхранената записва и съхранения файл.

■ съхранявана поле - е най-малката единица на съхранение на данни. Типичен база данни съдържа множество копия (поява или например) на всяка от няколко типа, описани там, съхранени области. Например, една база данни, съдържаща информация за подробностите могат да включват вида на съхранените области с ИПИ го "номер част" за всеки са описани в подробности за вида на данни (винтове, шарнирно покритие и т.н.) ще има отделен случай на директно се държи област.

Забележка. На практика често пропуска квалификациите за тип и копие, като се предполага, че точното значение е ясно от контекста. Въпреки, че има малка вероятност от объркване, е удобна практика, и ние ще следват по време на нея. (Тази бележка се прилага също и за съхраняваните записи, които ще бъдат посочени в следващия параграф.)

■ В съхранява записа - набор от взаимосвързани области съхраняват. Отново, ние просто Lich за тях и вида на инстанция. В този случай, копие от съхранените записи от щандове на група от свързани елементи, съхранени области. Например, копие от съхранените записи в данните на детайла се състои от копия на всяка от следните области съхранява ", номер на част", "име на част", "Цветът на части" и "части от теглото". Ние казваме, че базата данни съдържа няколко екземпляра държат рекорда си тип "подробност" (отново, по един за всяка конкретни подробности за Ной).

■ Накрая, съхранява файла - набор от всички съществуващи в момента на екв zemplyarov съхранява записи от същия тип. (За простота, приемайки, че всяка etsya предварително определен съхраняват файл може да съдържа съхраняват записи

Само един тип. Това опростяване няма да има значително въздействие върху последвалата дискусия.)

В съвременните системи, различни от логиката на базата данни (от гледна точка на програмиста) запис обикновено съвпада със съответния съхранява запис. Както е показано по-горе, в базите данни, не е задължително, тъй като във всеки един момент може да се наложи да направите промени в структурата на съхранение на данни (т.е., съхранявани в областта, записи, файлове), а структурата на данните от гледна точка на приложение трябва остават непроменени. Например, областта на заплатата във файла СЛУЖИТЕЛ, за да запазите паметта могат да бъдат съхранени в двоичен формат, както и приложения, написани на COBOL, това поле може да се види формата на символен низ. В бъдеще, независимо по каква причина, може да се наложи да промените двоичен формат за тази област да е десетична, като същевременно се поддържа молбата за обработка на терена в знак формат.

Фиг. 1.6. Съхранените полета, записи и файлове

Както вече беше посочено, такива разлики (изискващи превръщане тип данни на поле при всяка справка) са относително малки.

Въпреки това, по принцип, разликата между данните, достъпни чрез заявление, както и тези, които се съхраняват в база данни в действителност, може да бъде доста значителен. Разработване на тази идея, ние списък на аспектите на структури за съхранение на информация в базите данни, които са обект на промяна. Читателят е поканен да разсъждават върху собствената си какво трябва да се направи, за да се гарантира, приложения имунитет към база данни за такива промени (и то винаги е възможно да се постигне подобен имунитет).

■ Представяне на числова информация

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

■ Представяне на данните от характера

Поле като низ характер може да се съхранява с използване на съществуващите набори от символи кодиране (например ASCII, EBCDIC, Unicode).

■ единици за числови данни

Единици цифрови полета могат да бъдат модифицирани, например, инча могат да бъдат превърнати см по време на въвеждането на метрична система на единици.

В някои ситуации, може да е необходимо да се представят съхранените данни като кодирани стойности. По-специално, "цветен детайл", който е представен в приложението като низ характер ( "червен", "син", "зелени") могат да бъдат съхранявани под формата на десетични цифри в съответствие с таблица, като 1 = "червен" 2 = "син" и т.н.

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

Структура на записите, съхранявани Две съществуващи съхранявани записи могат да бъдат обединени в един. Например, съхранява запис

могат да бъдат представени под формата:

Тези промени могат да се извършват, когато нови приложения са въведени в системата от база данни. Предполага се, че прилагането на логически запис се състои от една подгрупа, т.е. съответните съхранени области входни Някои области на съхраняваните записи са "невидими" за дадено приложение.

От друга страна, един съхранява запис може да се раздели на две. Ние използваме записите от предишния пример. След това се съхранява запис

Тя може да бъде разделена на две:

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

■ Структурата на записаните файлове

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

Ето защо ние да ограничи списъка на характеристиките на структурата на съхранение на данни, които могат да бъдат обект на промяна. Тук, наред с други неща, се приема, че базата данни може да расте и да се развива, без това да повлияе на заявлението. В действителност, на възможността за развитие на базата данни, без да пречи на логическата структура на съществуващите приложения е един от най-важните стимули за гарантиране на независимостта на данните. Например, може да се разшири съществуващата

тип съхранявани записи, добавяне на нови съхраняват полета, които обикновено са на допълнителна информация за някои от възможните видове лица (т.е. "подробност" можете да добавите "единична цена" на съхраняваните записи). Тези нови области ще бъдат невидими за съществуващите приложения. По същия начин, можете да добавите нови видове, съхранявани записи (и, следователно, нови съхраняват файлове), без да променя съществуващите приложения. Тези записи обикновено са нови видове предприятия (например на базата данни "подробности", "доставчик", можете да добавите тип запис). Тези промени ще бъдат невидими за съществуващи приложения.

Сега е лесно да се разбере, че независимостта на data- още една от причините, поради които моделът трябва да бъдат отделени от неговото прилагане от тях, тъй като вече е била показана в края на раздел 1.3. Също така е важно да се отбележи, че независимо от данните не могат да бъдат постигнати без да се достигне подходяща степен на отделяне на модела на данни от неговото прилагане. Липса на разделяне на модела и неговото прилагане е широкоразпространена липса на модерни системи, използващи SQL език (което е особено тревожна).

Забележка. Последна бележка (по отношение на SQL чрез използване на съвременни системи език), не означава, че не се гарантира независимостта на данните в такива системи. Това само показва, че тези системи осигуряват независимост от базата данни в много по-малка степен, отколкото теоретично е възможно в релационна sistemah4. С други думи, независимо от данните - относително понятие. Различни системи го предоставят в различна степен или изобщо не предвидени. Системите, основани на езика SQL, по-напредналите в тази област от старата система, но, както ще видим в следващите глави, те все още са далеч от съвършенство.