|
|
Бази от данни
Определение:
База от данни (database) е структурирано
множество от постоянна информация, съхранявана
от компютърна програма. Терминът постоянна
(persistent) означава, че данните продължават
да съществуват и след прекратяване работата
на програмата.
В DB Manager базите от данни
са представени
като съвкупност от таблици (фиг.1).
Tези
таблици физически може да се
съхраняват като
отделни файлове (dBase, Paradox,
ASCII и
др.) или да бъдат обединени в
един общ (Oracle,
DB2, MS SQL, IntеrBase и др.).
И в двата
случая ако използвате Alias Manager,
вие
ще ги виждате като отделни таблици,
които
могат да бъдат избирани. |
|
|
 |
|
| Фиг.1. Бази данни и таблици |
|
Не всички таблици, намиращи се в една база
са свързани по някакъв начин помежду си.
Група от таблици, между които има връзка
се нарича схема (schema). Всяка база данни
може да съдържа произволен брой схеми.
В зависимост от своето предназначение и използваната
операционна система една СУБД (Система за
Управление на База от Данни), може да обслужва
един или повече потребители. В по-голямата
си част тези системи разпознават отделните
потребители. Потребителя на базата данни
не винаги е еднозначен с потребител на операционната
система.
Пример:
Имате база от данни, съдържаща таблици със
счетоводна информация. Тази база
от данни
се намира на Novell сървър (операционна
система
Netware 6.0). Крайните потребители
използват
персонални компютри с операционна
система
Windows XP. Сървърът е раположен
в централата
на фирмата, а работните станции
са разпределени
по филиалите, които са в различни
градове.
В този случай операционната система,
която
се използва от базата данни и
тази на крайният
потребител се различават.
Много потребители на една операционна система
могат да се включват към базата с едно и
също име, а един потребител може да използва
базата под различни имена. В зависимост от
идентефикатора на потребителя (най-общо под
това ще разбираме име и парола за достъп)
той може да чете, редактира или изтрива информацията,
до която има достъп.
Общото за всички бази данни е:
- Идентификацията, която се реализира по време
на процедурата на влизане. Както бе споменато
при нея се изисква потребителско име и парола.
- След влизане се активира сесия (session),
или връзка (connection) с таблиците в базата
данни. Тя продължава до момента, в който
не бъде прекратена от потребителя. По време
на сесията се задават последователност от
команди (за въвеждане, редакция, копиране,
изтриване и т.н.), които е прието да се наричат
конструкции.
- За всеки потребител са наложени ограничения
(привилегии), които позволяват или забраняват
определени действия с информационните масиви.
- Така както разполагате с достъп до файловете
и директориите на вашия компютър, така разполагате
с достъп до определени схеми (бази данни,
таблици) в конкретна СУБД. Всеки потребител
може да притежава една или повече схеми.
Локални източници на данни: dBase, Paradox, ASCII, FoxPro, Access.
Отдалечени източници на данни: Oracle, Sybase, Informix, InterBase, DB2,
MS SQl, MySQL. |
|
| Съдържание ... |
|
Таблици
Всяка таблица се състои от редове и колони.
Всяка една колона задължително има име и
тип. Прието е колоните да се наричат полета
(fields), а съдържанието им да се нарича
записи (records).
Данните в една колона могат да бъдат само
от един тип. За разлика от използваните електронни
таблици в офис пакетите, тук не може да въвеждате
в една и съща колона имена, дати и числови
стойности. В зависимост от вида на типа на
полетата е възможно допълнително да се изисква
задаване на разрядност или максимална дължина
на записите (size). Това е строго специфично
за различните бази данни, но поне при текстови
такива (данни от тип символен низ - string)
е задължително условие.
В зависимост от използваната база данни полетат
могат да бъдат от различен тип.
Някои бази данни използват
полета, които нямат аналог (FmtMEMO, AutoInc
и др.). Повече информация за това може да
намерите в специализираната литература и
internet.
Общият вид на една таблица може да се види
на фиг.2.
|
|
 |
|
| Фиг.2. Полета и записи |
|
За всяко едно от полетата в
таблицата съществува набор
от параметри,
които го характеризират.
Параметри на полето са неговия тип, максимално
допустимата дължина, дали е уникално като
съдържание, дали е индекс (повече информация
за индексите може да получите в раздела за
използване на таблици), наименованието, с
което ще се извежда на монитора и което може
да бъде различно от наименованието на полето
(display label), дали ще е видимо или скрито
и т.н.
|
|
 |
|
| Фиг.3. Структура на таблицата |
|
| Съдържание ... |
|
Типове полета
Както вече бе упоменато всеки един ред се
характеризира със типа на съдържащата се
в него информация.
За различните бази от данни се използват
различни типове. Съществуват типове, които
се използват във всяка една от СУБД, като
цели и реални числа, символни низове, дата,
час и др. Освен тях съществуват и данни,
с помощта на които могат да бъдат изграждани
доста сложни информационни системи.
Пример за такъв тип данни са Binary Large
OBject (BLOB) данните. Информацията, въведена
в подобни полета може да бъде изключително
разнообразна. От форматирани текстови документи,
през конструктивни чертежи, графични изображения,
аудиофайлове и дори цели филми.
От друга страна при някой бази от данни каквито
е InterBase, няма да може да използвате полета
от типа BSD (Binary-Coded Decimal). Подобно
е и състоянието при много от новите типове
полета, които осъществяват поддръжката за
обектно-релационни бази от данни.
|
|
| Типове полета използвани в DB Manager |
|
| Наименование |
Пълно наименование |
Тип на полето |
String
Smallint
Integer
Word
Boolean
Float
Currency
BCD
Date
Time
DateTime
Bytes
VarBytes
AutoInc
Blob
Memo
Graphic
FmtMemo
ParadoxOlе
DBaseOle
TypedBinary
Cursor
FixedChar
WideString
Largeint
ADT
Array
Reference
DataSet
OraBlob
OraClob
Variant
Interface
IDispatch
Guid
TimeStamp
FMTBcd |
Character or string
16-bit integer
32-bit integer
16-bit unsigned integer
Boolean
Floating-point numeric
Money
Binary-Coded Decimal
Date
Time
Date and time
Fixed number of bytes (binary
storage)
Variable number of bytes
(binary storage)
Auto-incrementing 32-bit
integer counter
Binary Large OBject
Text memo
Bitmap
Formatted text memo
Paradox OLE
dBASE OLE
Typed binary
Output cursor from an Oracle
stored procedure
Fixed character
Wide string
Large integer
Abstract Data Type
Array
REF
DataSet
BLOB fields in Oracle 8
tables
CLOB fields in Oracle 8
tables
Data of unknown or undetermined
type
References to interfaces
(IUnknown)
References to IDispatch
interfaces
Globally unique identifier
(GUID) values
Date and time field accessed
through
Binary-Coded Decimal
|
Фиксиран, символен низ
16-разрядно цяло число
32-разрядно цяло число
16-разрядно цяло число
Логическа променлива
Число с плаваща запетая
Парични стойности
Фиксирано, реално число
Дата
Час
Дата и час
Фиксиран брой байтове
Променлив брой байтове
Автомачтично нарастване
Двоични данни до 2 GByte
Текстов документ
Графика
Форматиран документ
OLE - Само за Paradox
OLE - Само за dBASE
Бинарен запис
Курсор - Само за Oracle
Фиксиран брой символи
16-bit unicode стринг
Целочислен тип (дълъг)
Абстрактни данни
Масив
Указател към обект
Поле от тип таблица
BLOB за Oracle
CLOB за Oracle
Произволен тип за ADO
Указател към интерфейс
Указател към COM интерфейс
COM поле за ADO
Време
Десетичен запис
|
|
|
Няколко от изброените типове данни представляват
интерес за нас.
- BLOB (Binary Large Object - големи двоични обекти)
- Блокове от данни, които поради
факта, че
са двоични позволяват на практика
да съхраняваме
абсолютно всичко, но основно
се използват
за мултимедийни записи, като
аудио, видео
и графика.
- CLOB (Character Large Obgects - големи символни
обекти) - Подобни на BLOB но служат за съхраняване
на текстова информация. В DB Manager са заменени
от т.н. Long String Object - дълги символни
низове, които могат да съхраняват текстова
информация с произволна дължина (от порядъка
на терабайтове).
- Таблици - Една таблица може да бъде тип данни дефинирани
от потребителят. Напримет типът данни "смесител"
може да съдържа следните полета: наименование
(символен низ), серия (символен низ), предназначение
(символен низ), тегло (цяло число), единична
цена (число с плаваща запетая) и т.н. Всички
те са обединени в една таблица, която е прието
да се нарича UDT (typed table) или типизирана
таблица.
- Масиви (колекции) - Списък от елементи от един
и същи тип. Например Integer.
|
|
| Съдържание ... |
|
Релации и връзки между таблиците
Релационният модел е разработен
от Тед Код
от компанията IBM и към момента
е приет като
основен, индустриален стандард
за работа
с бази данни.
Определение:
Релациите представляват логическа или аритметична
зависимост между данните в полета от един
и същи тип на две или повече двумерни таблици.
Релациите имат няколко важни характеристики.
Една от тях е степента (degree) на релацията.
Тя има отношение към броя таблици, участващи
в една релация.
Възможните варианти са три:
Единична или сингуларна/унарна (unary) релация.
При нея може да съществуват още циклична
(circular), рефлексивна (reflexive)
или рекурсивна
(recursive). За да се разбере
това е достатъчно
да познавате процедурата на изготвяне
на
технологична документация. В
този процес
се използва както конструктивна
така и счетводна
или друг тип информация, които
си взаимодействат
по сложен и понякога противоречив
начин.
Двоични или бинарни релации (binary).
Те са едни от най-често срещаните,
При тях две таблици си взаимодействат въз
основа на зададени правила.
Три или повече. Този тип релации се наричат
ен-арни (n-ary) и се срещат по-рядко.
Необходимо е да направим разграничение между
релации и свързване на таблици, така както
то може да се реализира от DB Manager. При
релационните зависимости една таблица може
да бъде обвързана с произволен брой други,
тъй какт няма няложени ограничения в
броя на използваните полета. При подчинено свързаните
таблици връзката може да бъде само една.
Тези разлики са детайлно разгледани
в раздела, за работа с таблици.
При релационните бази е необходимо всеки
един запис да разполага с уникален идентефикатор,
по който да се отличава от всички останали.
Най-често за това се използва цяло число
или символен низ, който е прието да се нарича
първичен ключ (primary key).
Първичния ключ служи за логическа идентефикация
на отделните редове.
Следният пример ще ни позволи
да разберем
защо е необходимо да използваме
ключове.
Пример:
Нека имаме база от данни, съдържаща списък
на изделията вложени в една машина. Да предположим,
че се налага да бъдат използвани метални
планки. Нормално е всяка една от тях да се
нарича "Метална планка". Дори да
въвеждаме размер (например 12Х14 mm) или
наименование на материала, от който са изготвени,
то пак е възможно в процеса на търсене да
получим няколко изделия с едно и също име,
което би ни затруднило. Ако обаче към всяко
едно от съществуващите имена бъде добавен
уникален ключ, който не се повтаря никъде,
системата ще извършва търсенето по него и
ще получим информация само за заявения детайл.
DB Manager предлага два основни начина за
реализиране на релации: посредством описание
в табличен вид (подобен на използваният
в demo версиите) и графично моделиране (Entity-RelationShip
- ER).
Проектирането на бази от данни е итеративен
процес. Това означава, че едва ли ще е възможно
да получим оптимален резултат от първия път.
Практиката е доказала, че е нужно първо да
се изготви предварителен проект, след което
да проверим дали той отговаря на всички условия,
които се изискват за работа с информационните
масиви.
Това, което препоръчваме
е да се откажете
от подхода, при който цялата
информация е
събрана предварително и на нейна
база се
изгражда съвършенният модел.
Много по-добре
е да се работи на принципа на
пробите и грешките,
колкото и абсурдно да ви прозвучи
това.Ако използвате
подхода на постепенното добавяне,
ще бъдете в състояние
да откриете навреме потенциални
проблеми,
които неминуемо възникват в процеса
на практическа
реализация.
Пример:
За да направите една добра система, която
да поддържа информацията съпътстваща
производственият
процес на едно издели е нужно
или много добре
да познавате всички елементи
на процеса или
да проведете серия от разговори
с хората,
които се занимават с това. Всичко,
което
знаете или ще научите, ще ви
помогне да съставите
правилата на работа със системата.
Тези правила
ще определят всички ограничения
свързани
с извличането, редактирането
или премахването
на определен вид информация.
Прието е тези ограничения и норми
да се наричат
бизнес правила (business rules).
Аналогичен е случаят, при който се разработва
система за обслужване на търговска верига.
Продавачите предлагат изделието,
за което
получават сума, която постъпва
по сметката
на фирмата. Счетоводните отдели
изготвят
текущи отчети (оперативна информация),
а
логистичните поддържат изискуемите
запаси
(планиране).
|
|
 |
|
| Фиг.4. Пример за релация. |
|
| Съдържание ... |
|
|
Специфика на отдалечените бази от данни
Тези бази от данни,
които
са разположени извън работните
станции
и до които потребителят има гарантирани
физически и логически достъп
ще бъдат
считани за отдалечени.
Физическата връзка с тях може
да се реализира
посредством inranet (локална
мрежа) или internet
(глобална мрежа). Съществува
и трети вариант,
който ще наричаме специализирани
мрежи за
пренос на информация. Този вариант
е тема
на отделни разглеждания и касае
само и единствено
системата Gnosys™, тъй като освен
IP и IPX
протоколи, той използва и редица
други, които
не се генерират в процеса на
работа.
Нека сега разгледаме един специфичен
аспект, свързан с използването
на отдалечени информационни масиви
от DB Manager.
Когато се проектира база от данни, предназначена
да поддържа електронна търговия по internet,
е възможно в един момент тя да натрупа голяма
по обем информация, имаща отношение към потребителската
нагласа на клиентите. Този тип информация
може успешно дабъде използвана използвана
за създаване на крайни приложения, чиято задача е откриването
на съществуващи нагласи и тенденции (data-mining
приложения).
Изискванията, налагани към едно data-mining
приложение са твърде различни от тези на
on-line обработката на транзакции (online
transaction processing - OLTP). Поради чисто
финансови съображения би било добре ако една
и съща база от данни се използва и за двете
цели.
Независимо колко добре са били структурирани
данните, желателно е да се направи моментна
снимка на състоянието (snapshot), т.е. базите
да се копират на отделна машина и всички
обработки да се извършват върху копието,
до постигане на оптимален за конкретният
етап резултат
DB Manager ви позволява да автоматизирате
този процес почти изцяло.
При работа с отдалечени бази от данни се
използва SQL или XML, като двата
случа имат
своя специфика и са предмет на
отделни разглеждания.
|
|
 |
|
| Фиг.5. Генерирана посредством DB Manager
SQL заявка |
|
| Съдържание ... |
|
Обекти
Основното понятие при работа с бази данни
при DB Manager е обект. Като обект може да
разглеждаме всички онези неща, с които сме
заобиколени. В конкретния случай под обекти
ще разбираме таблиците, а също така и групите
от таблици, обединени в един раздел.
Обектите условно могат да бъдат разделени
на "силни" и "слаби".
Както и таблиците така и обектите взаимодействат
помежду си посредством релации. Релациите
могат да имат характер независещ от характеристиките
на самия обект.
Като обект може да разглеждаме и пълният
пакет конструктивна документация, личният
картон на един служител, учебен или рекламен
филм и т.н.
При съвременните бази данни се работи с обекти.
Всеки обект се характеризира със свойства
(properties), методи (methods) и съпътствъщи
събития (events). Използването на обектно-ориентирани
бази от данни е предмет на много по-обстойно
разглеждане. Такъв тип данни се използват
от Gnosys™, за изграждане на мощни мултимедийни
приложения, а също така и в системите за
технологичен контрол на производствените
процеси.
Пример:
Изделието "смесител" може да бъде
разглеждано като силен обект, а "цена"
като "слаб обект", защото съответстващите
му стойности се влияят от редица фактори,
нямащи пряко отношение към смесителя. Всеки
един смесител се характеризира с техническо
предназначение, вид на покритието, функционално
предназначение и т.н.
Събитията, които могат да произтичат
с всеки
смесител са: проектиране, внедряване,
изработка,
съхраняване, продажба и т.н.
За всеки един смесител можем
да получаваме
информация за неговото текущо
състояние,
качество, а също така да задаваме
стойност
за цената му.
В заключение можем да кажем, че обектите
са мощно средство при изграждането на бази
от данни.
Използването на обектно-ориентиран модел
е заложено в SQL99, под името SQL/OLB (Object
Language Bindings) като най-често се използва
за вграждане на SQL в Java приложения.
Освен него се използват още и
Basic Object
Support, при който потребителят
може да дефинира
нови типове данни (например Clip
- за въвеждане
на видеоклипове, Audio - за съхраняване
на
музикални файлове и др.), както
и Enhanced
Object Support, който позволява
да бъдат
изготвяни собствени конструктори. |
|
| Съдържание ... |
|
|
|
