КАТЕГОРИЯ:


Астрономия- (809) Биология- (7483) Биотехнологии- (1457) Военное дело- (14632) Высокие технологии- (1363) География- (913) Геология- (1438) Государство- (451) Демография- (1065) Дом- (47672) Журналистика и СМИ- (912) Изобретательство- (14524) Иностранные языки- (4268) Информатика- (17799) Искусство- (1338) История- (13644) Компьютеры- (11121) Косметика- (55) Кулинария- (373) Культура- (8427) Лингвистика- (374) Литература- (1642) Маркетинг- (23702) Математика- (16968) Машиностроение- (1700) Медицина- (12668) Менеджмент- (24684) Механика- (15423) Науковедение- (506) Образование- (11852) Охрана труда- (3308) Педагогика- (5571) Полиграфия- (1312) Политика- (7869) Право- (5454) Приборостроение- (1369) Программирование- (2801) Производство- (97182) Промышленность- (8706) Психология- (18388) Религия- (3217) Связь- (10668) Сельское хозяйство- (299) Социология- (6455) Спорт- (42831) Строительство- (4793) Торговля- (5050) Транспорт- (2929) Туризм- (1568) Физика- (3942) Философия- (17015) Финансы- (26596) Химия- (22929) Экология- (12095) Экономика- (9961) Электроника- (8441) Электротехника- (4623) Энергетика- (12629) Юриспруденция- (1492) Ядерная техника- (1748) Arhitektura- (3434) Astronomiya- (809) Biologiya- (7483) Biotehnologii- (1457) Военни бизнесмен (14632) Висока technologies- (1363) Geografiya- (913) Geologiya- (1438) на държавата (451) Demografiya- ( 1065) Къща- (47672) журналистика и смирен (912) Izobretatelstvo- (14524) външен >(4268) Informatika- (17799) Iskusstvo- (1338) историята е (13644) Компютри- (11,121) Kosmetika- (55) Kulinariya- (373) културата е (8427) Lingvistika- (374) Literatura- (1642) маркетинг-(23702) математиците на (16968) Механична инженерно (1700) медицина-(12668) Management- (24684) Mehanika- (15423) Naukovedenie- (506) образователна (11852) truda- сигурност (3308) Pedagogika- (5571) Poligrafiya- (1312) Politika- (7869) Лево- (5454) Priborostroenie- (1369) Programmirovanie- (2801) производствено (97 182 ) индустрия- (8706) Psihologiya- (18388) Religiya- (3217) Svyaz (10668) Agriculture- (299) Sotsiologiya- (6455) на (42831) спортист строително (4793) Torgovlya- (5050) транспорт ( 2929) Turizm- (1568) физик (3942) Filosofiya- (17015) Finansy- (26596) химия (22929) Ekologiya- (12095) Ekonomika- (9961) Electronics- (8441) Elektrotehnika- (4623) Мощност инженерно ( 12629) Yurisprudentsiya- (1492) ядрена technics- (1748)

Изисквания към бази данни

Основи на Database

Така че, добре проектирана база данни:

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

· Осигурява последователност и целостта на данните. При проектирането на таблици, трябва да се определят техните атрибути, и някои от правилата, които ограничават способността да въведете невалидна стойност от страна на потребителя. За да провери данните, преди да ги пишете директно в базата данни на маса трябва да прилагат правилата на модел за повикване на данни и по този начин се гарантира запазване на целостта на информацията.

· Осигурява естествен, лесен за структуриране на информация. Качествено строителство позволява заявки в базата данни на "по-прозрачна" и лесни за разбиране; Ето защо, по-малко вероятно да се направи лоши данни и подобрява качеството на основната опора.

· Отговаря на изискванията на потребителите за изпълнение на база данни. За по-големи обеми от информация, извършване на консервационно започват да играят важна роля, след като "подчертаване" всички недостатъци на фазата на проектиране.

Стъпки дизайна на базата данни:

1. Идентифициране на нуждите от информация на базата данни.

1. Да се ​​анализират реални обекти, които трябва да бъдат моделирани в базата данни. Форма на тези обекти, естество и характеристики на тези лица (например, за едно предприятие, "т" характеристики могат да бъдат "име", "цвят", "тегло", и други подобни) и да се генерират в списъка.

1. Поставете в духа и характеристики - маси и колони (полета) в нотация избрана базата данни (парадокс, DBASE, FoxPro, достъпът , Clipper, Interbase, Sybase, Informix, Oracle и др).

1. Определяне на атрибутите, които еднозначно идентифицират всеки обект.

1. Да се разработи правила, които ще създават и поддържат целостта на данните.

1. За да се осигури връзката между обектите (таблици и колони), задръжте нормализация маси.

1. Планирайте въпросите на сигурността на данните и, ако е необходимо, запазване на тайната на информацията.

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

Преди да се разгледа в детайли всяка от тези стъпки, ще се спрем на основните концепции на релационни бази данни. В релационна теория на един от най-важните е концепцията за връзка. Математически съотношението се определя както следва. Да предположим, че са дадени п определя D 1, D 2, ..., D п. След R е съотношението на тези групи, където R е набор от кортежи на формата <г 1, D 2, ..., г N>, където г 1 - елемент на D 1, D 2 - елемент на D 2, ... , г н - елемент от г п. Това определя формата <г 1, D 2, ..., г п> се нарича кортежи, и определя D 1, D 2, ..., D Н - домейни. Всеки кортеж се състои от елементи, избрани от техните домейни. Тези елементи са наречени атрибути и техните ценности - стойности на атрибути. Фиг.



, -а ни представя графично представяне на връзката от друга гледна точка.
Лесно е да се види, че съотношението е отражение на реалния свят единици (в този случай - на същността "елемент") по отношение на данни е таблица. Тъй като местните бази данни, всяка маса се поставя в отделен файл, условията на тези споразумения за локални бази данни нагласа могат да бъдат идентифицирани с файла. А кортеж е един ред в таблицата, или че един и същи запис. Същото е атрибут на колоната, или - в областта на запис. Домейн, представлявано от някои генерични тип, който може да бъде източник за видовете полета в записа. По този начин, при следните условия са еквивалентни тройки:

· Attitude, файл маса (за локални бази данни)

· Автоколона, линия, запис

· Умение поле колона.

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

Умение (или набор от атрибути), които могат да бъдат използвани, за да може еднозначно да идентифицира конкретен кортеж (запис ред), наречен на първичния ключ. Първичният ключ не трябва да има допълнителни атрибути. Това означава, че ако се изключат произволен атрибут, останалите атрибути няма да бъдат достатъчни, за да може еднозначно да идентифицира отделните кортежи на първичния ключ. За да се ускори достъпа на първичен ключ във всички системи за управление на бази данни (СУБД) е механизъм, наречен индексиране. Грубо казано, индексът е обърнато изображение на дърво, сочейки към истинската местоположението на записите за всеки от първичния ключ. Естествено, различни кодове DBMS прилагат по различен начин (в местна СУБД - обикновено под формата на отделни файлове), обаче, същите принципи на организацията им.

Може би връзката на индексиране използване атрибути, различни от първичния ключ. Този вид се нарича вторична индекс и индексът се използва, за да се намали времето за достъп за намиране на данни и за сортиране. По този начин, ако отношението не е сортирана по никакъв начин и той може да присъства в низа, след отстраняване на някои от кортежи, индексът (за местните СУБД - индекс на файла), напротив, се сортира.

За поддържане на връзките на данни в много бази данни има механизъм на така наречените външни ключове. Смисълът на този механизъм е, че определен атрибут (или група признаци) се определя на една връзка линк към първичния ключ на друга връзка; като по този начин защитена връзка между отношението на подчинение. В тази връзка, на първичния ключ е посочен от външния ключ на друга връзка, която се нарича майстор-съотношение, или съотношението на Майн; и съотношението, което се основава на връзката нарича детайл-съотношение, или подчинен отношения. След назначаването на такъв референтна база данни има способността да автоматично да следите на въпроса "не-нарушение" на отношенията между отношенията, а именно:

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

· Ако се опитате да изтриете запис от главната таблица, първичен ключ на който има най-малко една справка от подчинен на маса, база данни и генерира грешка.

· Ако се опитате да промените първичен ключ рекорд в основната маса, на която има най-малко един линк от подчинен на маса, база данни и генерира грешка.

Забележка. Има два подхода за премахване или промяна на записи от главната таблица:

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

1. Разпределете всяка промяна в първичния ключ на главната таблица за подчинен на маса, а именно:

о Ако в основната таблица запис се отстранява, в тази таблица трябва да бъдат премахнати всички записи, които сочат за изтриване;

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

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

Стъпки дизайн на база данни

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

· Ще новата система да комбинирате съществуващи приложения, или ще трябва да се променят радикално да работят с новата система;

• Какви данни се използва в различни приложения; Дали вашата кандидатура ще бъде в състояние да споделя някои от тези данни;

· Кой ще влезе данните в базата данни и в каква форма; колко често се променят данните;

· За да бъде достатъчно за домейна на рамка или изискват множество бази данни с различни структури;

· Каква информация е най-чувствителен към екстракта и скоростта му на промяна.

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

Образуване на концептуалния модел на базата данни включва:

· Идентифициране на функционалната активност на вашия домейн.

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

· Идентифициране на характеристиките на тези лица. Например, предприятието служител може да включва такива характеристики като ID на служителите, Фамилия, име, длъжност, заплата.

· Идентифициране на взаимоотношения между субекти. Например, как същество работник, професия, катедра взаимодействат един с друг? Служителят има една професия (за простота!) И се появява в същия отдел, докато в същия отдел може да бъде много работници.

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

След изброени всички взаимоотношения и техните атрибути, дори и на този етап, можете да започнете да се премахнат излишните позиции. Всеки атрибут трябва да се появи само веднъж; и вие трябва да решите какво отношения ще бъде собственик на набор от атрибути.

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

V. Петата стъпка е свързана с развитието на правилата, които ще създават и поддържат целостта на данните. Както е определено, тези правила в клиент-сървър на база данни с автоматично се поддържа - сървъра на базата данни; в локалната база данни, както тяхното поддържане е необходимо да се възложи заявката на потребителя.

Тези правила включват:

· Определяне на вида на данните

· Избор на набор от съответните символи на страната

· Създаването на полета, на базата на домейни

· Стойности настройка по подразбиране

· Определяне на ограниченията за интегритет

· Определяне на условията на изпитване.

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

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

· Комуникация "едно към едно"

· Комуникация "един-към-много"

· Комуникация "много-към-много".

След прилагането на правилата за нормализация на логически групи за данни се намира на не повече от една маса. Тя осигурява следните предимства:

· Данни лесно да актуализирате или изтривате

· Изключва възможността за несъответствие на копия на данни

· Намаляване на възможността за въвеждане на неверни данни.

Процесът на нормализация е да се съберат на таблиците в така наречените нормални форми. Съществуват няколко вида на нормални форми: първата нормална форма (1NF), втора нормална форма (2NF) Трета нормална форма (3NF), нормална форма на Boyce-Codd (BCNF), четвърта нормална форма (4NF), Пето нормална форма (5NF). От практическа гледна точка, само три първите форми - трябва да вземат предвид времето, необходимо на системата за "връзки" таблици, когато те се показва на екрана. Ето защо, ние се ограничаваме до изследването на връзката, за да донесе на процеса за първите три форми.

Този процес включва:

· Премахване на повтарящи се групи (което води до 1NF)

· Премахването на частично зависими атрибути (редукция на 2NF)

· Премахване на преходни зависими атрибути (намаляване на 3NF).

Нека разгледаме всеки един от тези процеси в детайли.

1. Събирането на първия нормална форма

Когато полето в записа включва влизане повече от една стойност за всеки първичен ключови данни такива групи се наричат повтарящи се групи. 1NF не допуска съществуването на такива мулти-ценен полета. Да разгледаме примера на предприятието база данни, съдържаща една маса ОТДЕЛ със следните стойности (курсив на атрибутите, това е основният ключ):
Таблица. A: ОТДЕЛ

Nomer_otdela име глава бюджет местоположение
търговски Москва
търговски Зеленоград
развития Твер
търговски Калуга

За да донесе тази таблица, за да 1NF, ние трябва да се премахне атрибут (област) Местоположение на отдел маса и да се създаде нова таблица RASPOLOZHENIE_OTDELOV, който дефинира първичен ключ, който е номер комбинация отдел и неговото местоположение (Nomer_otdela + местоположение - виж таблица б ..). Сега, за всяко място, отдел, има различни линии; По този начин ние сме елиминира дубликат група.
Таблица. B: RASPOLOZHENIE_OTDELOV

Nomer_otdela местоположение
Москва
Зеленоград
Твер
Калуга

2. Намаляване на втората нормална форма

Следващата важна стъпка в процеса на нормализация е да се премахнат всички неключови атрибути, които зависят само от страна на първичния ключ. Такива атрибути се наричат частично зависими. Non-ключовите атрибути съдържат информация за естеството на предметната област, но не го идентифицират еднозначно. Например, да предположим, ние искаме да се разпределят на работниците на протичащите в предприятието проектите. За да направите това, създайте таблица Проект с композитен първичен ключ, който включва редица служител, и идентификатор на проекта (Nomer_rabotnika + ID_proekta в таблица. С курсив).
Таблица. C: ПРОЕКТ

Nomer_rabotnika ID_proekta фамилно име Nazv_proekta проект Opisanie_ продукт
BRZH Иванов обмен <Blob> програма
MLC Петров документи <Blob> програма
EASY Сидоров управление <Blob> adm.mery

В тази таблица, възниква следният проблем. Атрибути Nazv_proekta, Opisanie_proekta и продукти, свързани с проекта като цяло и, следователно, зависи от атрибута ID_proekta (която е част от първичния ключ), но не и от Nomer_rabotnika атрибут. Следователно, те са отчасти зависи от първоначалното композитен ключа. Същото може да се каже за Фамилия атрибут, който зависи от атрибут Nomer_rabotnika, но не зависи от ID_proekta атрибут. За да се нормализира тази таблица (привеждането в 2NF) ще отстрани от него атрибути Nomer_rabotnika и фамилия и да се създаде друга маса (наричаме го RABOTNIK_V_PROEKTE), който ще съдържа само тези две качества, и те също ще бъде основната му ключ.

3. Привеждане в трета нормална форма

Третият етап на таблиците за привеждане на процеса на нормална форма е да се премахнат всички неключови атрибути, които зависят от други неключови атрибути. Всяка не-ключов атрибут трябва да са логически свързани с атрибут (атрибут), е основният ключ. Да предположим, например, че сме добавили поле Nomer_rukovoditelya и телефон в проектите таблицата в 2NF (първичен ключ е ID_proekta поле). Атрибутът Телефон логически свързани с атрибута Nomer_rukovoditelya, извън основната област, но не приписват ID_proekta, е първичен ключ (таб. D).

Таблица. D: ПРОЕКТ

ID_proekta Nomer_ главата телефон проект Nazv_ проект Opisanie_ продукт
BRZH 2-21 обмен <Blob> програма
MLC 2-43 документи <Blob> програма
EASY 2-56 управление <Blob> adm.mery

За да се нормализира тази таблица (за да го приведе в 3NF) Премахнете атрибут Телефон, промените Nomer_rukovoditelya на ръководителя на главата и направи атрибут външен ключ съотнасяне атрибута Nomer_rabotnika (първичен ключ) в таблицата на служителите. След този проект на маса и служителят ще бъде както следва:

Таблица. E: ПРОЕКТ

ID_proekta глава проект Nazv_ проект Opisanie_ продукт
BRZH обмен <Blob> програма
MLC документи <Blob> програма
EASY управление <Blob> adm.mery

Таблица. F: РАБОТНИЦИ

Nomer_ служител фамилно име име бащино име Nomer_ отдел Kod_ професия телефон заплата
Иванов Иван Иванович Ing 2-69
Петров Peter Петрович mndzh 2-56
Сидоров Иван Петрович mndzh 2-45

VII. Седмият етап е последният в нашия списък, но не на последно място по важност в процеса на проектиране на база данни. В тази стъпка, ние трябва да планираме въпросите на надеждността на данните и, ако е необходимо, запазване на тайната на информацията. За да направите това, вие трябва да отговорите на следните въпроси:

· Кой ще има право (и как) да използват базата данни

· Кой ще има право да променяте, добавяте и изтривате данни

· Имате ли нужда да се направи разлика в правата за достъп

· Как да се гарантира пълна защита на информацията режим и т.н.

<== Предишна лекция | На следващата лекция ==>
| Изисквания към бази данни

; Дата: 01.15.2014; ; Прегледи: 312; Нарушаването на авторските права? ;


Ние ценим Вашето мнение! Беше ли полезна публикуван материал? Да | не



ТЪРСЕНЕ:


Вижте също:



ailback.ru - Edu Doc (2013 - 2017) на година. Тя не е автор на материали, и дава на студентите с безплатно образование и използва! Най-новото допълнение , Al IP: 11.45.9.22
Page генерирана за: 0.096 сек.