Бази от данни Съдържание Необходимост от бази от данни Определение и характеристика
Въведение в базите от данни на Access
Изтегляне 1.04 Mb.
|
- Навигация на страницата:
- Структура на базата от данни
- Data/Time Дата и време Currency
- Counter Дълги цели с автоматично нарастване. OLE
- Отношения между таблиците
- Отношение един-към-един
- Отношение един-към-много
- Отношение много-към-един
- Отношение много-към-много
- Нормализация на базите от данни
Въведениев базите от данни на Access
Структура на базата от данниТелефонният справочник представлява “плоска” база от данни, в която цялата информация се разполага в една единствена таблица. Всеки запис от тази таблица съдържа идентификатор на конкретния човек – име и фамилия и телефонния му номер. По този начин таблицата се състои от записи, информацията в които е разделена на няколко части – полета. В дадения случай полета са “Име и фамилия” и “Телефонен номер”, както е показано на фиг. 3.1.
Фиг. 3.1. Таблица, запис и поле.
За разлика от плоските, релационните бази от данни се състоят от няколко таблици, като връзката между тях се създава чрез съвпадащите значения на едноименни полета. Трябва да се отбележи, че при разработване на системите за управление на базите от данни сега релационния модел на базите от данни се приема за стандарт. Като пример тук е представена базата от данни STUD_Prim baza, съдържаща данни за студенти. За да се разгледа, следва да се отвори файл STUD_Prim baza.MDB чрез MS Access. Съдържанието на файла STUD_Prim baza.MDB е показан на фиг. 3.2. В базата от данни влизат таблици (Tables), запитвания (Queries), форми (Forms), отчети (Reports), макроси (Macros) и модули (Modules).
Фиг. 3.2. Съдържание на файл STUD_Prim baza.MDB.
От фиг. 3.2. се вижда, че базата от данни се състои от таблиците: Stud, Spec, Izpiti и EmailAdr. Всяка от тях съдържа информация за обекти от един тип. От наименованията на таблиците става ясно, че те принадлежат на едни и същи обекти. Всеки ред от тези таблици еднозначно определя един обект от своята група. Въобще, базата от данни може да се състои от една или няколко таблици. Записът, от своя страна, се състои от няколко полета, всяко от които съдържа елемент данни за обекта. Типа на данните, които се разполагат в една таблица, зависят от форматите, допустими за използване. В следващата таблица са включени някои от типовете данни, поддържани за таблиците в Access.
Таблицата Stud (Студенти) съдържа информация за студентите (фак. номер, фамилия, място и дата на раждане, специалност и др.). На фиг. 3.3. и 3.4. е показана структурата на таблицата Stud и нейното съдържание в табличен вид.
Фиг. 3.3. Структура на таблица Stud.
Фиг. 3.4. Съдържание на таблица Stud.
Структурата и съдържанието на таблица Spec e представено на Фиг. 3.5., а структурата и съдържанието на другите две таблици може да се разгледа в средата на СУБД Access. 
Фиг. 3.5. Структура и съдържание на таблицата Spec.
Отношения между таблицитеОтношенията между таблиците установяват връзката между данните, намиращи се в различни таблици на базата от данни. Отношенията между таблиците се определят от отношението между групите обекти от съответният тип. Например, един студент може да се явява на изпити по различни дисциплини, т.е. между студента и изпитите съществува отношение един-към-много. Отношенията, съществуващи между таблиците в базата от данни STUD_Prim baza.MBD са показани на Фиг. 3.6.
Фиг. 3.6. Отношения между таблиците на базата от данни STUD_Prim baza.MBD
Пример за такова отношение може да бъде отношението между таблиците Stud и EmailAdr. Всеки студент може да има само един Е-mail адрес, затова и на Фиг. 3.6. между полетата Fn на тези таблици съществува отношение един-към-един. Отношение един-към-многоПри таблиците Stud и Izpiti между полетата Fn съществува отношение един-към-много, тъй като един студент може да се явява на много изпити, т.е. на един запис от таблицата Stud, може да съответстват множество записи от таблицата Izpiti. Вижда се, че и тук връзката между таблиците се осъществява по съвпадащите полета от двете таблици – полетата Fn. Отношение много-към-единОтношение много-към-един е обратното на отношението един-към-много. Такова отношение съществува между таблиците Stud и Spec, т.е. на един запис от таблицата Spec може да съответствуват много записи от таблицата Stud. Отношение много-към-многоПри отношение много-към-много всеки запис от едната таблица е свързан с няколко записа от другата таблица и обратно. За удобство при работата с таблици, имащи отношение много-към-много, обикновено в базата от данни се добавя още една таблица, намираща се в отношение един-към-много или много-към-един със съществуващите таблици.
Нормализация на базите от данниДанните от всички таблици на базата от данни STUD_Prim baza.MBD могат да бъдат обединени в една единствена таблица. Всички действия по обработката на данните могат да се изпълнят и с една такава таблица, но това очевидно не е най-добрият подход. В една такава таблица ще има много повтарящи се данни – например за иманата на специалностите в които се обучават студентите, или както е сега в таблицата Stud – често се повтарят имената на населените места от където са студентите. Наличието на повтарящи се данни води към неоправдано увеличаване размера на файла на базата от данни. Освен нерационално използване на дисковото пространство, това предизвиква и рязко забавяне на работата на приложенията. Въвеждането на често повтаряща се информация неизбежно води до възникването на грешки. За избягването на тези проблеми, стремежа трябва да бъде към максимално намаляване на количеството на повтарящата се информация. Именно процеса на намаляването на повторяемостта на информацията в базата от данни чрез разделянето й в няколко свързани една с друга таблици се нарича нормализация на данните. Строго погледнато съществува стройна математическа теория за нормализация на данните, но за повечето практически задачи трябва просто да се спазва следното: Таблиците се създават по такъв начин, че записите от всяка таблица да описват обекти от един и същ тип. Ако в таблицата се срещат полета, съдържащи аналогични данни, то таблицата трябва да се раздели. В една таблица не трябва да се включват производни данни, които могат да бъдат пресметнати на базата на данни от другите таблици. Трябва широко да се използват спомагателни таблици – например към таблицата Stud може да се създаде справочна таблица, съдържаща населените места, където са родени студентите. По този начин ще се намалят възможностите за допускане на грешка от потребителите на базата от данни.
Ключове и индексиКакто вече беше споменато при описание на отношенията между таблиците, в релационните бази от данни, таблиците се свързват една с друга посредством съвпадащите значения от ключовите полета. Практически всяко поле може да бъде ключово поле в таблицата. Ключът може да бъде първичен (primary) или външен (foreign). Първичният ключ еднозначно определя запис от таблицата. В примера с базата от данни STUD_Prim baza.MBD, и четирите таблици съдържат първичен ключ, които графично е представен с по-удебелен шрифт за отличаването му от останалите полета на таблицата (вж. Фиг. 3.6.). Същевременно таблицата Stud има и външен ключ (полето Sp), който служи за връзка с таблицата Spec, а таблицата Izpiti има външен ключ (полето Fn), койно служи за връзка с таблицата Stud. По този начин, първичният ключ еднозначно определя всеки запис в таблицата, а външния ключ се използва за връзка с първичния ключ на друга таблица. Ключовото поле може да е “натоварено” със смислово значение, какъвто е примера с таблицата Stud, където ключово е полето Fn. В други таблици обаче, за по-удобно се смята използването като ключово поле на поле от тип “брояч” (Counter field), какъвто е случая с таблицата Izpiti. Поле от този тип съдържа четирибайтово цяло число (Long), което автоматически се увеличава с единица при добавянето на нов запис в таблицата, което осигурява уникалност на създавания ключ.
Едно от основните изисквания, предевявани към СУБД е да дават възможност за разглеждане на записите в последователност, различна от физическата последователност, както и да осигуряват бързо намиране на определен запис. Ефективно средство за решението на това изискване е използването на индекси. Индексът представлява таблица, която съдържа ключовите значения за всеки запис от друга таблица, записани в последователност, желана от потребителя. Индексът се определя на основата на едно или няколко значения от запис на другата таблица и съдържа връзки към съответстващите записи в таблицата. На Фиг. 3.7. е показан фрагмент от таблицата Stud и индекс Ind_Ime, построен на основата на полето Ime на таблицата Stud. Индексът Ind_Ime съдържа значения от полето Ime, подредени в азбучен ред, както и връзки към съответстващия запис от таблицата Stud.
Фиг. 3.7. Връзка между таблица и индекс
Всяка таблица може да има няколко различни индекса, всеки от които представя свой собствен порядък на подреждане на записите. Например, таблицата Stud може да има индекс за датана на раждане, за азбучен ред на населените места и др. По този начин, всеки индекс се използва за представяне на едни и същи данни, но подредени по различни начини. Строго погледнато, таблиците в базата от данни могат въобще да нямат индекси. В такъв случай за една голяма таблица с хиляди записи, търсенето на един от тях може да отнеме доста време – т.е. използването на индекс за съкращаване на нужното време за намирането на един запис е необходимо. Същевременно не трябва да се прекалява със създаването на индекси, тъй като е необходимо време при обновяването на данните и индексите в базата от данни и води до “раздуване” на файла на базата от данни. Най-често в конкретните разработки приложение намират простите индекси, основани на значението на едно поле от таблица. В случаите когато е необходимо, индекс може да се изгради на основата на значенията на няколко полета от таблицата – при това се получава т.нар. съставен индекс. Например, изграждането на индекс само на базата на имената на студентите може да се окаже неудачно, тъй като има студенти с еднакви имена. В такъв случай би трябвало да се изгради съставен индекс от името на студента и датата на раждането му или пък името на студента и ЕГномер на студента. 4.
Каталог: wp-content -> uploads -> 2011 2011 -> Евгений Гиндев световната конспирация 2011 -> Наредба №36 от 30 ноември 2005 Г. За изискванията към козметичните продукти 2011 -> Наредба №36 от 30 ноември 2005 Г. За изискванията към козметичните продукти 2011 -> За минималния и максималния бал по паралелки в рио област софия-град 2011 -> 130 годишнината на ввму “Н. Й. Вапцаров” разкрива новите предизвикателства и перспективи в развитието на флагмана на морското образование 2011 -> Съюз на математиците в българия – секция бургас пробен изпит по математика за 7 клас – март, 2011 2011 -> Член на Приятели на Земята Интернешънъл 2011 -> Права и задължения на учениците 2011 -> В съответствие с ангажиментите в рамките на фаза 1 от мониторинга за изпълнение на задълженията по Конвенцията и Препоръката, през 2000 г 2011 -> Разграничение на трафика на хора от сродни престъпни дейности д-р Ива Пушкарова Изтегляне 1.04 Mb. Сподели с приятели:
|
