Глава 19. Стандарти за работа с бази от данни

Глава 19. Стандарти за работа с бази от данни

Отношение към работата с бази от данни имат различни стандарти. Разгледан бе стандартът за непроцедурния език SQL от 1992 г., известен като известен като SQL2 или SQL-92. През 1999 г. бе приета обектно-ориентираната версия на мегдународната организация за стандартизация ISO - SQL3. Широко се използуват, преди още да са стандартизирани, и промишлените стандарти на производителите на софтуер и водещите изследователски организации за моделиране на данните UML (Unified Modeling Language) и езикът за управление на обектно-ориентирани данни ОQL (Object Query Language) на групата ODMG (Object Data Management Group). За съгласуване на SQL3 и ОQL е сформирана обединена работна група между представителите на американската организация за стандартизация ANSI (X3H2) и ODMG , която ще прави и предложения за новия стандарт SQL4.

Освен възможностите, осигурявани от SQL-92, SQL3 осъществява допълнително:

• 
  поддържане на големи обекти от данни;
  
• 
  конструиране на съставни типове данни;
  
• 
  потребителски дефинирани типове данни, процедури и функции;
  
• 
  рекурсивни операции.
  

Стандартът SQL3 дефинира и типовете: CHARACTER LARGE OBJECT (CLOB) - за големи символни низове; BINARY LARGE OBJECT (BLOB) и NATIONAL CHARACTER LARGE OBJECT (NCLOB) - за двоични низове, които не са символи. Тези даннови типове дават възможност да се обработват големи текстови и графични файлове като текстови документи, Web страници, снимки, видео. Дължината им се задава с числова стоност последвана от някоя от дименсиите: К - за килобайта, М - за мегабайта, G - за гигабайта.

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

За обработката на големи обекти от данни в SQL3 са включени следните специални оператори за работа с низове:

• 
  конкатенация на низове;
  
• 
  отделяне на поднизове;
  
• 
  отрязване на низове;
  
• 
  припокриване на низове;
  
• 
  определяне на място на низ;
  
• 
  определяне дължина на низ;
  
• 
  участие в операции за сравнение чрез предикат LIKE.
  

Съставните типове от данни, които могат да се дефинират в SQL3 са: гнездови релации, списъци, масиви, подтаблици, връзки.

Гнездовите релации по същество са релации, които се включват в колона от дадена релация. В SQL3 могат да се дефинират само редове-релации. Като пример може да разгледаме записването на трите имена на дистрибуторите на стоки в таблица RAZPROSTRANITELI, разглеждана в том първи.

CREATE TABLE RAZPROSTRANITELI (RasprNo VARCHAR(5)

Ime ROW (SobIme VARCHAR (15),

BaIme VARCHAR (15),

FamIme VARCHAR (15)));

За означаване и използуване на йерархията на класовете от обектното моделиране в SQL3 е въведена клауза UNDER на оператора CREATE TABLE. Както е известно връзките между обектите от надкласовете (надтаблиците) и подкласовете (подтаблиците) са “едно към едно”, а обектите от подкласовете наследяват свойствата на надкласовете. Всяка от операциите за поддържане (отпадане, вмъкване, корекции) предизвиква съответни промени о в двете таблици. Нека като пример разгледаме създаването на таблица за студентите, поемащи преподавателски задачи - STUDPREP, като подтаблица на таблицата на судентите - STUDENTI.

CREATE TABLE STUDPREP UNDER STUDENTI (

FacNom VARCHAR(8),

StartDate DATE,

Predmet VARCHAR(15))

REF is StudID SYSTEM GENERATED;

Тук клаузата REF се използува за указване на колона, която съдържа уникалния идентификатор на съответния ред от надтаблицата.

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

CREATE TYPE PersonalType AS (

dateOfRirth DATE CHECK (dateOfBirth>DATE “1960-01-01”),

fName VARCHAR(12),

Iname VARCHAR(12),

FUNCTION wazrast (t PersonalType) RETURNS INTEGER

RETURN

REF IS SYSTEM GENERATAD;

Тук клаузата REF IS SYSTEM GENERATAD дефинира указател от реда за тип към реда на съответната основна таблица.

Рекурсия

Както видяхме в раздел 19.1. рекурсивните операции за определяне потребностите от материали не могат да се изпълнят само със средствата на Access. Подобна е ситуацията с много други задачи, които изискват рекурсия и ползуват релационна база от данни. За решаването на този проблем в стандарта SQL3 са включени възможности за рекурсивна заявка чрез оператор JOIN. Разликата е, че трябва да се укаже кой е външният и кой е вътрешният списък при обхождането на обработваната таблица. Нека желаем да получим общото количество от участието на всеки детайл в произвежданите изделия. Един детайл участва в даден възел (продукт) с някакво количество, той от своя страна участва в по-горен възел (продукт) с количество и т.н. докато се достигне до крайния продукт (изделие). Общото количество за всеки детайл е произведение от всички тези количества, намерени след като се разкрие къде участвува той. Тези участия и количества се дават от таблица STRUCTURA, която веднъж се ползува като външен списък за всички детайли и втори път от нея се разкрива вътрешния списък с продуктите, в които се включва всеки детайл. WITH RECURSIVE

Obchtokolitchestvo (DetailNo, Obchtokol) AS

(SELECT DetailNo, Obchtokol

FROM STRUCTURA

JOIN

FROM STRUCTURA

WHERE in.ProductNo = out.DetailNo);

Глава 20. Многопотребителски бази от даннни

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

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

Четирите гореизброени функции са необходими, независимо от приетата схема за разположение на базата от данни.

При разположение на базата от данни на еднопотребителски персонален компютър в даден момент базата от данни се ползва само от един потребител. Ползването от повече потребители може да става само последователно във времето. Тази стратегия позволява да бъдат опростени функциите за разрешаване на конфликтите, като се сведат само до оторизиране на достъпа до данните. Тя е подходяща за малък брой потребители и ограничени обеми от данни. По-голяма свобода тук има при избора на хардуера и при използуването на потребителския интерфейс. Разбира се, ако имаме ограничен обем памет, обемът на данните в базата от данни също ще бъде ограничен. Тъй като обикновено при тази стратегия с базата от данни работи по-квалифициран персонал, потребителският интерфейс може да бъде с по-широки възможности. Честотата на корекциите тук е съществена за времената за отговор. При по-голяма честота на корекции се губи повече време за индексиране и от там се увеличават времената за отговор. И обратно при по-малка честота на корекции, индексните таблици търпят по-малко промени и съответно достъпът се ускорява. Тази схема е подходяща при ограничен обем на базата от данни и възможност за обслужване на информационната система от едно работно място. При необходимост с базата от данни да работят по-вече от 2-3 потребители е добре да се премине към следващите стратегии за разположението й. Един вариант на тази схема е телепроцесингът. При него към компютъра се включват терминали, които не могат да работят самостоятелно. Всички обработки се изпълняват от компютъра и резултатите се изпращат чрез операционната система към терминалите.

Разположение на базата от данни на файлов сървър се прилага, когато има необходимост от едновременно ползуване на базата от данни от повече потребители и в условията на мрежова среда. При нея потребителският интерфейс и обработката на данните остават на индивидуалното работно място. Променя се разположението на базата от данни и на функциите за разрешаване на конфликтите, възникващи в резултат на заявки за едновременен достъп до данните. Тези две групи функции се концентрират върху централизиран файлов сървър. Това означава, че данните се изпращат за обработка на локалните работни места, но контролът на достъпа до тях се осъществява от сървъра. Тази схема е относително ефтина, но има и недостатъци. Първият й недостатък е, че мрежата се натоварва с трансфериращи операции. При всяка обработка сървърът изпраща участвуващите файлове на индивидуалните работни места. Освен това, за да извършват обработката на данните, индивидуалните работни места трябва да имат достатъчен хардуерен и софтуерен ресурс за пълно копие на базата от данни. При това този ресурс е необходим на всяко работно място. Контролът на достъпа до данните е доста затруднен. Това в крайна сметка води до ограничението, че тази схема е подходяща при брой на потребителите до 10 и обем на информацията до 1 Gbyte.

При тази схема на индивидуалното работно място остава само потребителският интерфейс. Останалите функционални компоненти (за обработка и съхранението на данните, както и за разрешаването на конфликтите за едновременен достъп) се разполагат на централизиран сървър. Това означава, че през локалната мрежа ще се трансферира по-малък обем информация. В този случай към сървъра се изпращат само SQL заявките, които са малки по обем. Вместо пълния обем данни от сървъра към индивидуалните работни места се предават само резултатите от SQL заявките. На индивидуалните работни места ще се работи само с графичния потребителски интерфейс и затова те могат да бъдат с по-скромна конфигурация. Поддържането на базата от данни също може да се извършва по-ефективно, тъй като то става на сървъра, за който може да се осигури по-мощна конфигурация. Контролът на достъпа до данните става централизирано и е по-сигурен. Тази архитектура е по-отворена и дава възможност за развитие и разпределяне на функциите на повече равнища. Такъв сървър може да бъде създаден например с MS SQL Server, както и с Windows NT. Тази схема намира приложение при по-голям брой потребители и по-големи информационни обеми.

Клиент-сървър системата може да бъде изградена и на три равнища, като функциите на сървъра се разделят на две. На едното равнище се предава логиката на клиентските приложения, а на другото - операциите с базата от данни. Триуровневата архитектура намира все по-голямо разпространение и се използва особено при обмен на информация между бази от данни и Word Wide Web (WWW).

Работа с бази от данни

в примери на ACCESS 2003 - 2007

със SQL, VBA и ADO

Корица и оформление Владимир Л. Станчев

Рецензент доц. д-р инж. Светослав Димков Велев
Българска

Първо издание

Формат 60 / 84 / 16

ISBN 954-438-363-8 ????????????????????-------------------?????????

София, 2007

Работа с база от данни е предназначена за решаване на по-сложни бизнес и инженерни задачи, което не може да бъде осъществено само с интерфейсните средства на системите за управление на базите от данни. Изложението е представено по достъпен начин, като където е необходимо, са дадени и теоретичните постановки. То включва следните части: въведение в базите от данни, въведение в ACCESS чрез примери, SQL приложения на ACCESS, многопотребителски бази от данни. Материалът е представен чрез примери и решени типични за нашия стопански живот задачи. Това съдържание ще бъде полезно както за конкретни потребители, така и за целите на обучението.

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

Примерите са достъпни на адрес: ASISBG.NETFIRMS.COM