Помогни ни да направим Uroci.net по - богат! Добави урок

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

Microsoft Access » Microsoft Access
kubala   трудност:    видян: 110221



Създаване на връзка "един към един"

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

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

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

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


Прецизиране на проекта

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

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

Докато изпробвате началната база данни, може би ще откриете място за подобрение. Ето няколко неща, които трябва да проверите:

  • Не сте ли забравили някои колони? Ако е така, дали информацията принадлежи на съществуващи таблици? Ако информацията е за нещо друго, може да се наложи да създадете друга таблица. Създавайте колона за всеки елемент от информация, който искате да проследите. Ако информацията не може да се изчисли от други колони, вероятно ще ви е необходима нова колона за нея.
  • Има ли някои ненужни колони, които може да се изчислят от съществуващите полета? Ако даден елемент информация може да се изчисли от други съществуващи колони – например цена с отстъпка, изчислена от цената на дребно – обикновено е по-добре просто да се направи изчислението и да се избегне създаването на нова колона.
  • Въвеждате ли многократно дублирана информация в някоя от таблиците? Ако е така, вероятно ще трябва да я разделите на две таблици, които имат връзки "един към много".
  • Има ли таблици с много полета, ограничен брой записи и много празни полета в отделните записи? Ако е така, помислете за ново проектиране на таблицата, така че тя да има по-малко полета и повече записи.
  • Дали всеки информационен елемент е разбит на най-малките си полезни части? Ако искате да съставяте отчети, да сортирате, да търсите или да изчислявате един елемент от информация, поставете този елемент в собствена колона.
  • Дали всяка колона съдържа факт за предмета на таблицата? Ако една колона не съдържа информация за предмета на таблицата, то тя принадлежи на друга таблица.
  • Представени ли са всички връзки между таблиците, било чрез общи полета или трета таблица? Връзките "един към един" и "един към много" изискват общи колони. Връзките "много към много" изискват трета таблица.

Прецизиране на таблицата "Продукти

Да предположим, че всеки продукт в базата данни за продажба на продуктите попада в една обща категория като напитки, подправки или морски храни. Таблицата "Продукти" би могла да съдържа поле, показващо категорията на всеки продукт.

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

Едно по-добро решение е като нов предмет за проследяваната база данни да се направят "Категории" със своя собствена таблица и собствен първичен ключ. След това първичният ключ от таблицата "Категории" може да се добави като външен ключ към таблицата "Продукти".

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

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

  • ИД на продукт
  • Име
  • ИД1 на продукт
  • Име1
  • ИД2 на продукт
  • Име2
  • ИД3 на продукт
  • Име3

Тук всеки продукт е една повтаряща се група от колони, която се различава само по добавяния номер на края на името на колоната. Когато видите колони, номерирани по този начин, трябва да преразгледате проекта си.

Такъв проект има няколко недостатъка. При стартиране сте принудени да поставяте горна граница за броя на продуктите. Щом превишите тази граница, ще трябва да добавите нова група колони в структурата на таблицата, което представлява голяма административна задача.

Един друг проблем е свързан с това, че за доставчиците, имащи по-малък брой на продуктите от максималния, ще се хаби известно място, тъй като допълнителните колони ще са празни. Най-сериозният недостатък на подобен проект е, че той затруднява изпълнението на много задачи като сортирането и индексирането на таблицата по ИД или име на продукт.

Винаги когато видите повтарящи се групи, преглеждайте внимателно проекта за възможности за разделяне на таблицата на две. В горния пример е по-добре да се използват две таблици – една за доставчици и една за продукти, свързани с ИД на доставчик.


Страници: «3 4 5 6 7 »

Сподели |

Коментари (1)

Tarat0rcho95 на 06.02 2010 в 16:44ч.
Работенето с микрософт повер поинт 2007 е доста лесно.. Който иска помощ да пише на скупе (скайп) ediinstwen8!!

Регистрирайте се, за да добавите коментар


Калдейта ЕООД - © 2003-2010. Всички права запазени.
Препоръчваме: IT Новини