Румяна Цанкова Владимир Л. Станчев Работа с бази от данни в примери на access 2003 2007


Глава 8. Създаване на нова база от данни



страница7/20
Дата13.11.2018
Размер3.1 Mb.
#104752
ТипГлава
1   2   3   4   5   6   7   8   9   10   ...   20

Глава 8. Създаване на нова база от данни

При отварянето на Access се появява прозорецa на задачите. В него са показани възможни варианти: да се създаде нова празна база от данни, да се ползуват шаблони за създаване на нова база от данни или да се отвори една вече съществуваща такава. Нова база от данни може да се избере и от главното меню File по аналогичен начин както нова папка или нов файл в WINDOWS. По принцип то е аналогично на главното меню в WINDOWS с някои специфични особености. Създаване на нова база от данни може да се избере и от лентата с функционални бутони (фиг. 8.1).



Фиг. 8.1. Лента с функционални бутони в Access 2003.


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

Нека искаме да създадем нова база от данни с име db1 в папка My Documents. След избор на File, New, Blank Database, Save in: My Documents, File name:bd1, Create се появява прозорецът, показан на фиг. 8.2. В него има три режима: за създаване на нова база от данни-New, за моделиране и проектиране-Design и за попълване или работа с вече проектирана база от анни-Open. Всеки от тези режими може да се изпълни за обектите: таблици-Tables, заявки-Queries, форми-Forms, отчети-Reports, макроси-Macros и модули-Modules. Освен това има опции за: създаване на проект на таблица, създаване на таблица със съветник, създаване на таблица чрез въвеждане на данни. Най-напред се извършва проектирането на цялата база от данни като множество от свързани таблици в режим Design, а след това попълването на данните в таблиците в режим Open. От своя страна процесът на проектиране на базата от данни протича на две стъпки: проектиране на таблица след таблица и проектиране на връзките между тях (Relationships).



Фиг. 8.2 . Основно меню за създаване и използване на база от данни (Access 2003).
Тук трябва да се отбележи, че базата от данни се запомня като едно цяло със затварянето на главното меню и не трябва да се запомнят таблиците като отделни файлове.

Продължаваме с опциите New за Tables. В появилия се прозорец се избира режим на проектиране Design View – фиг. 8.3.



Фиг. 8.3. Прозорец за избор на режим на работа (Access 2003).

8.1. Проектиране на таблиците от базата от данни
Пример 1. Нека имаме задача да проектираме база от данни за доставки и пласмент на битова техника от едно малко предприятие.

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

Моделът на базата от данни включва таблиците на класовете от обекти: Nomenklatura, Prodazbi, Klienti, Razprostraniteli, Dostavki, Dostavchici. Връзките между обектите от класовете Nomenklatura и Klienti са „много към много”, тъй като един и същ продукт се доставя на различни клиенти и обратно. За разрешаването на този проблем е въведен обектният клас Prodazbi. С това връзките „много към много” се разпадат на две групи „едно към много”. Аналогично е положението с класовете Nomenklatura и Dostavchici. Тук колизията е разрешена като е включен класът Dostavki. При това положение връзките между класовете от обекти са както следва:

Nomenklatura (0) 1-¥ Prodazbi

Nomenklatura (0) 1-¥ Dostavki

Klienti 1-¥ Prodazbi

Dostavchici (0) 1-¥ Dostavki

Razprostraniteli (0) 1-¥ Prodazbi .

Тук символът 1-¥ означава връзка “едно към много”, а (0) допуска обекти от лявата таблица без съответствие в дясната таблица.

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

Х ХХ ХХХ

½ ½ ½________________ пореден номер

½ ½_____________________ разновидност, марка, габарит

½________________________ тип

Фиг. 8.4. Схема за кодиране номерата на продуктите.

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



Фиг. 8.5. Схема на базата от данни за доставка и пласмент на битова техника
Процесът на компютърно проектиране на базата от данни протича на две стъпки: проектиране на таблиците и проектиране на връзките между тях. Проектирането на таблиците започва с таблиците с прост главен ключ. Едва като се завърши с всички такива таблици, започва проектирането на таблиците със съставен главен ключ. Докато не е завършил целият двустъпков процес на проектирането, не се попълват данни в таблиците. Изгледът за проектиране на таблиците Design View съдържа две части. В горната част се попълват имената и типът на данните за свойствата на обектите, а в долната част всички останали техни характеристики (фиг.8.6). Нека разгледаме най-напред горната част на изгледа за проектиране на таблиците. Имената на свойствата на обектите, които са колони в таблиците на базата от данни, носят наименование полета и се нанасят в Field Name. Препоръчва се имената на полетата да бъдат писани с латиница, за да се избягнат някои програмни грешки по-нататък. Редовете с данни в таблиците тук се наричат записи. След внасянето на имената на полетата се преминава с клавиш Enter към записване на техния тип в Data Type.

Фиг. 8.6. Изглед за проект Design View на таблица Dostavki.
Определянето на типа на данните се подпомага от съответно падащо меню. Допустимите от Access типове данни са:

Text- буквено-цифров текст, съдържащ до 255 символа;

Memo - по-дълъг текст, съдържащ до 64000 символа;

Number - числови стойности, които в зависимост от формата могат да бъдат цели или реални;

Data/Time - дати и/или време;

Currency - валутни стойности;

AutoNumber - автоматично задавани числови стойности за идентификатори;

Yes/No - логически стойности;

OLE Object - създадени от други програмни средства OLE обекти: графика, диаграми, текст, таблици, видеозапис, звукозапис;

Hyperlink - адрес за връзка с WEB и други HTML документи;

Lookup Wizard - данни по образец.

В най-лявата колона се указва полето, което е главен ключ. За целта най-напред неговият ред се маркира, а след това се избира функционалният бутон за главен ключ Primary Key. Когато главният ключ е съставен, се маркират всички участващи в него полета и тогава се натиска функционалният бутон. В случай, че не сме задали главен ключ, при издаването на Close системата ни пита желаем ли автоматично поставяне на главен ключ - фиг. 8.7.


Фиг. 8.7. Прозорец за автоматично създаване на главен ключ.
При положителен отговор се въвежда начално ключово поле под наименование ID с тип AutoNumber . На фиг. 8.8. е показан един нов проект на таблицата за разпространителите, в която се съхраняват данните за заплатите им за всички месеци, а не само за последния. Затова е въведен идентификационен номер, различен от номера на разпространителя.



Фиг. 8.8. Нов проект на таблицата на разпространителите с автоматично създаване на поле за главен ключ.
При определянето на типа на данните става активна и долната част на проектантския прозорец. Там се задават следните характеристики в панела General:

Field Size - дължина на текстови и буквено-цифрови полета, за текстови полета-до255 символа и 50 символа по подразбиране, за числови полета съгласно таблица 8.1;

Format - формат за извеждане стойностите на това поле съгласно таблица 8.2, без OLE обекти;

Decimal Places - брой на знаците след десетичната точка при извеждане на числови и валутни полета;

Input Mask - маска (образец) на въвежданата информация;

Caption - текст за надпис на кирилица при извеждане.

Default Value - стойност по подразбиране, задавана при началното зареждане, не се отнася за автоматично идентифициране и OLE обекти;

Validation Rule - ограничително логическо условие за въвежданата информация;

Validation Text - съобщение за грешка при нарушаване на логическото условие; не се отнася за автоматично идентифициране, Memo полета и OLE обекти;

Required - задължително въвеждане на стойност в полето, задължителна стойност Yes за главен ключ;

Allow Zero Length - допуска или не нулеви стойности на Меmo и Hyperlink полета, задължителна стойност Yes за главен ключ;
Размер и на поле за различни числови типове Таблица 8.1.


Числов тип данни

Обхват на размера

Брой знаци след десетичната точка

Byte

цели числа 0 - 255

-

Integer

цели числа -32768 - 32767

-

Long Integer

цели числа -2147483648 -2147483647

-

Single

Реални числа -3.4х1038-3.4х1038

7

Double

Реални числа -1.797х1038-1.797х1038

15

Currency

Реални числа - 922337203685447.5808 -922337203685447.5808

4


Indexed - при Yes за полето се създава индекс, възможно е и общ за повече от едно поле чрез функционалния клавиш за индексиране Indexes , при Yes и връзки “едно към много” се избира опция Duplicates OK,а при връзки “едно към едно” - No Duplicates. Индексирането е метод за директен достъп до отделните записи. Използва се основно при главните ключове.

New Values - вид на автоматичното индексиране: Increment - последователно със стъпка 1 или Random - с псевдо случайни числа.

Smart Tagsбързо клише за изпълнение на свързани с полето операции, извеждания, приложения.
Формати за типа на данните в полетата Таблица 8.2.


Тип на данните

Формат на данните

Пример

Numeric

General Number (въз-произвежда входа)

6543.7




Currency

6 543.70




Fixed

6543.70




Standard

6 543.70




Percent

0.6543=65.43%




Scientific

6.543E+03

Date/Time

General Date

10.08.2001 11.31.23




Long Date

10 Август 2001




Medium Date

10-август-2001




Short Date

10.08.2001




Long Time

11:31:23




Medium Time

11:31 РМ




Short Time

23:31

Yes/No

Yes/No

да/не




True/False

истина/лъжа




On/Off

включено/изключено

Да разгледаме проектирането на полето EdinichnaCena от таблица Dostavki - фиг. 8.9. Типът на данните за цена е реален и затова е приета опция за дължина на полето Single, форма на представяне Standard с две позиции след десетичната точка. Интерес представлява опцията Validation Rule. Тук с логически израз се записват ограниченията за стойностите, записвани в съответното поле. Полето е задължително, но не е индексирано.




Фиг. 8.9. Проектиране на полето EdinichnaCena от таблица Dostavki.

Панелът Lookup е предназначен главно за даване на указания за източниците на данните. На фиг. 8.10 е показан пример за полето Miarka от таблица Nomenklatura. От Display Control могат да се изберат възможностите: Text Box - за набиране на данните от клавиатурата, List/Combo Box - за избор на данните от предварително подготвен източник (списък или таблица). В Row Source Type се задава видът на източника: Table/Query, Value List, Field List. В Row Source се указват съответно името на източника (таблицата), конкретните стойности от списъка, имената на полетата от списъка. Combo Box е много полезна опция, даваща възможност да се попълват еднакво навсякъде имена например на лица, на продукти и др. Таблицата с тези имена стои пред погледа и от нея могат да се избират необходимите.




Фиг. 8.10. Проектиране на полето Miarka от таблица Nomenklatura.
8. 2. Проектиране на връзките между таблиците

Връзките между таблиците се осъществяват чрез общо, свързващо поле. То трябва да бъде главен ключ във водещата таблица и външен ключ в свързваната таблица. Общото поле може да има различни имена в двете таблици, но трябва да е от един и същи тип и размерност. Поле от тип AutoNumber може да се свързва с такова от тип Number, Long Integer. Добре е да бъде индексирано и в двете таблици, но задължително във водещата таблица.

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

невъзможност да се отстраняват записи от водещата таблица при наличие на записи със същата стойност на общото поле в свързваната таблица;

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

За осигуряването на цялост се указват съответни опции в диалоговия прозорец, задаващ връзката. Връзката между две таблици се създава в следната последователност:

затварят се всички таблици в базата от данни;

избира се функционалният бутон Reletionships , така че се появява съответният прозорец (виж фиг. 8.5);

избира се функционалният бутон Show Table , така че се появява диалоговият прозорец от фиг. 8.11.


Фиг. 8.11. Прозорец за определяне на общите полета от свързваните таблици.
избират се свързваните таблици с помощта на диалоговия прозорец Show Table, като след Add и Close се появява прозорецът Relationships;

маркира се ключовото поле от водещата таблица и появилият се знак се тегли с натиснат ляв клавиш до съответното му поле от свързваната таблица;



задават се условията за цялост чрез диалоговия прозорец от фиг. 8.12 : пълна цялост - Enforce Referential Integrity , обновяване на взаимно свързваните полета - Cascade Update Related Fields, отпадане на взаимно свързваните полета - Cascade Delete Related Records; издаване на опцията Join Type и определяне на типа на съединението - фиг. 8.13.

Фиг. 8.12. Диалогов прозорец за задаване на условията за цялост между таблиците Dostavki и Dostavchici.
Видът на връзката “едно към едно” или “едно към много” се определя автоматично в зависимост главните ключове в проекта на таблиците. Връзки от вида “едно към много” с изисквания за цялост се означават графично със символиката 1 - ¥.

Фиг. 8.13. Определяне начина на съединяване на таблиците Dostavki и Dostavchici.
Както се вижда от фиг. 8.13. съществуват три типа съединения на таблици, незаисимо какъв е видът на връзката между тях:


  • включване на записи, за които стойностите в общото поле са равни, графична символика , пример - обработка на доставчици, които са направили доставки;

  • включване на всички записи от водещата таблица и само записите с равни стойности за общото поле от съединената таблица, графична символика , пример - обработка на всички доставчици вкл. и тези без доставки;

  • включване на всички записи от съединената таблица и само записите с равни стойности за общото поле от водещата таблица, графична символика , пример - обработка на доставчици, които са направили доставки, ако се изисква цялост съвпада с тип 1.

Запомнянето на проекта за базата от данни става със затварянето му. Възможни са и други опции като запомняне във външни файлове и др., което се задава от менюто File.
8.3. Внасяне на данните в таблиците
Внасянето на данните в таблиците става чрез въвеждането им в декларираните чрез проекта полета запис след запис. Най-напред се попълват водещите таблици, а след това - свързаните с тях таблици. Задължително е попълването на идентифициращите полета и полетата, за които при проектирането е зададено Yes за Required. В случай на пропуск да се зададе стойност в тези полета се появява съобщение за грешка и не е възможно да се премине към следващ запис, без тя да се отстрани. За останалите полета е допустимо да останат непопълнени. Системата сама следи и стойностите в полетата, за които е зададен контролиращ логически израз във Validation Rule. При невярна стойност също се появява съобщение за грешка.

За да се внесат данни, таблицата се отваря чрез опцията Open от прозореца за избор на режим, показан на фиг. 8.3 Появява се изгледът Datasheet - фиг. 8.14.



Фиг. 8.14.Изглед Datasheet за внасяне на данни в таблица Dostavki
Той може да се извика и от режим Design чрез View, Datasheet View. Когато базата от данни не е отворена, тя трябва да се отвори предварително чрез File, Open Database или чрез функционалния бутон .

Попълването на данните става винаги на последния ред. Придвижването между полетата става най-лесно със стрелките от клавиатурата. При новото отваряне на таблицата записите са подредени по главния ключ, независимо в каква последователност са въвеждани. Въвеждането на данните обикновено става от клавиатyрата, а за полетата, обявени като List Box, Combo Box в LookUp - от предварителен списък. На фиг. 8.15 е показана таблица Dostavki след допълване с доставките, направени през месец февруари 2006 година.



Фиг. 8.15. Изглед Datasheet с добавени данни в таблица Dostavki
Всеки въведен запис или клетка може да се премахва чрез маркиране и Delete, ако не се нарушават изискванията за цялост. Появява се диалогов прозорец за потвърждение на изтриването. След потвърждението записите не могат да се възстановяват с командата Undo.

Корекции на данните в клетка се прави след избирането й чрез попълване отново и при съблюдаване на целостта. Корекции на отделни символи докато не е напусната дадената клетка се правят чрез изтриване с Backspace.

Преместване и копиране на данни между клетки може да става с командите Cut, Copy и Paste, които могат да се избират от менюто Edit, от функционалните бутони или от контекстното меню и се използуват по известните от другите WINDOWS приложения начини. Преместване на данни на поле става в последователността: маркиране на цялата колона; позициониране на курсора на мишката в средата на името на полето до появата на преместващото правоъгълниче; теглене на полето до желаното място, показвано с плътна линия. Копиране на повтаряща се информация от предходен запис може да става само, ако е запомнена преди да започне попълването на дадения запис.

Възможно е да се показват и свързаните записи-фиг.8.16.



Фиг. 8.16. Заявка за указване на свързване на записи
Отваря се таблицата, в която са главните записи и в нея с позициониране върху знака плюс се указва записът, чиито свързани записи се търсят. Появява се падащо меню, в което се задава името на свързваната таблица и имената на свързваните полета. В случая е показан запис от таблица Nomenklatura и свързаните с него записи от таблица Prodavbi-фиг. 8.17. Те се разполагат като влагане в главните записи, т.е. показва се конкретната връзка „едно към много” между екземплярите. Пред съответния главен запис се е появил знакът минус, а след него са подредени взаимосвързаните записи.

Фиг. 8.17. Записи, свързани „едно към много”
Промяната на ширината на колоните на дадена таблица се прави в последователността: позициониране на курсора на мишката в десния край на съответното поле от антетката на таблицата до появата на кръстче със стрелки; изтегляне в съответната посока до достигане на желаната ширина. По аналогичен начин се променя ширината на редовете.Запомнянето на попълнените данни става с издаването на командата Close.

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



Tаблицата Nomenklatura с въведени начални данни според следващата фигура е проектирана с вид и тип полета, достатъчни за обхващане на номенклатурата на продуктите в предприятието.

Таблицата Razprostraniteli с въведени данни е проектирана с брой и тип полета достатъчни за обхващане на разпространителите към предприятието.

Таблицата Klienti обхваща всички клиенти на предприятието.

Tаблицата Prodazbi представя ежедневните продажбите на предприятието, осъществени от даден разпространител.

8.4. Корегиране на проекта на таблиците
Гъвкавостта на всяка информационна система, работеща с база от данни, зависи от възможностите за внасяне на корекции в проектираните структури. Внасянето на изменения става в изгледа Design. Eдно често срещано изменение е необходимостта да се изменя дължината на полетата Fiеld Size, за което в общия случай няма проблеми. Възможно е да се променя редът на полетата в следния начин: маркира се редът на описание на полето, което желаем да преместим; изтегля се с мишката целият ред до новото място; издава се Close, като се потвърждава желанието за изменение. Възстановяване чрез команда Undo може да се прави само преди потвърждението. Изтриване на поле се прави чрез маркирането му и издаване на Delete и то само при запазване на цялостта.

Връзките между таблиците също могат да бъдат променяни. На фиг. 8.18. е показано изменение във връзката между таблици Dostavchici и Dostavki. Приема се, че не всички регистрирани доставчици имат реализирани доставки и е важно да се получават списъци, от които да се вижда кои са те. Това означава, че типът на съединението от фиг. 8.13 трябва да се измени от 1 на 2 и това се отразява на графичния модел на връзките. За внасяне на изменението се осъществяват стъпките:



  • маркира се изменяната връзка в диалоговия прозорец Relationships;

  • издава се командата Delete;

  • задава се нова връзка;

  • попълва се новопоявилият се диалогов прозорец Relationships;

  • попълва се новопоявилият се диалогов прозорец; Join Properties.



Фиг. 8.18. При съединение водещата таблица Dostavchici ще се извежда изцяло.
Както се вижда моделирането на класовете от обекти и на връзките между тях има много голямо значение. То е отправната точка за вярно и ефективно решаване на проблемите в различни предметни области.
Аналогичен на разглеждания в пример 1 от глава 8 модел на базата от данни имат и предметните области на дадените по-долу примери.

Пример 2. Да се проектира с помощта на MS Access база от данни за работата на една брокерска къща, която се занимава с покупко-продажба на акции.

Пример 3. Да се проектира с помощта на MS Access база от данни за работата на една къща за покупко-продажба на недвижими имоти.

Пример 4. Да се проектира с помощта на MS Access база от данни за работата на една къща за даване под наем на видео и други записи.

Пример 5. Да се проектира с помощта на MS Access база от данни за работата на една застрахователна компания.





Сподели с приятели:
1   2   3   4   5   6   7   8   9   10   ...   20




©obuch.info 2024
отнасят до администрацията

    Начална страница