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

Важно: Тази статия е преведена машинно – вижте отказа от отговорност. Английската версия на тази статия за справка можете да намерите тук .

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

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

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

В тази статия

Някои база данни на термини, за да знаете

Какво е добра база данни, проектиране?

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

Определяне на предназначението на вашата база данни

Намиране и организиране на необходимата информация

Разделяне на информация в таблици

Превръщане на информационните елементи в колони

Задаване на първични ключове

Създаване на релации между таблици

Уточняване на проекта

Прилагане на правила за нормализиране


Някои база данни на термини, за да знаете

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

изображение, показващо три таблици в работни листове

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

Най-горе на страницата

Какво е добра база данни, проектиране?

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

Добра база данни дизайн е, следователно, един, които:

  • Разделя на вашата информация в тематично базирани таблици, за да намалите излишните данни.

  • Предоставя достъп на необходимата информация за съединяване на информацията в таблиците е необходимо.

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

  • Побира обработка на данни и докладване нужди.

Най-горе на страницата

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

Процеса на проектиране се състои от следните стъпки:

  • Определяне на предназначението на вашата база данни   

    Това ви помага да се подготвите за останалите стъпки.

  • Намиране и организиране на необходимата информация   

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

  • Деление на информацията в таблици   

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

  • Превръщане на информационните елементи в колони   

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

  • Задайте първични ключове   

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

  • Настройване на релации между таблици   

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

  • Допълнителна обработка на вашия проект   

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

  • Прилагане на правила за нормализиране   

    Прилагане на правилата за нормализиране на данните, за да видите дали вашите таблици са структурирани правилно. Направете промени в таблици, както е необходимо.

Най-горе на страницата

Определяне на предназначението на вашата база данни

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

Най-горе на страницата

Намиране и организиране на необходимата информация

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

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

След това помислете за типовете отчети или пощенски съобщения, може да искате да създадете от базата данни. Например може да искате отчет за продажби на продукти за показване на продажбите по регион или наличностите обобщен отчет, която показва продукт инвентара нива. Може също да искате да генерирате Формулярни писма да изпратите на потребителите, които обяви продажба събитие или предлага премия. Проектиране на отчета в мнението си и си как ще изглежда. Каква информация ще поставите в отчета? Списък на всеки елемент. Направете същото за формулярно писмо и за други отчети, предвиждате създаване.

човек, който си представя отчет за запаси от продукти

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

Изискването за изпращане на имейл съобщения до клиенти предлага друг елемент, за да запишете. След като знаете, че клиентът иска да получавате имейл съобщения, трябва да знаете, имейл адреса, на който да ги изпратите. Следователно трябва да запишете имейл адрес за всеки клиент.

Има добра смисъл да съставите модел на всеки отчет или изход списък и Помислете какви елементи ще трябва да създадат отчета. Например когато разгледате формулярно писмо, някои неща, които може да досещаме се. Ако искате да включите правилното приветствие – например "Н", "Г" или "Г" низ, който стартира поздрав, ще трябва да създадете елемент на поздрава. Също така обикновено можете да започнете писмо с "Мили н Христов", а не "мили. Н Илияна пяна". Това показва, обикновено ще искате да съхранявате отделно от собствено име фамилно име.

Ключови точка трябва да запомните е, че трябва да прекъснете всяка част от информацията в частите й най-малкото полезни. В случая на име, за да стане достъпна, фамилно име ще прекъснете името на две части – собствено име и фамилно име. За да сортирате отчет по фамилно име, например е от полза да има фамилно име на клиента, съхранявани отделно. Като цяло ако искате да сортирате, търсене, изчисляване или отчет на базата на елемент от информация, трябва да поставите този елемент в отделен поле.

Помислете за въпроси може да искате да отговори на базата данни. Например колко продажби на вашия Препоръчани продукт затворите миналия месец? Където вашите най-добри клиенти живеят? Кой е доставчикът за вашия най-продаваните продукти? Прогнозирането на тези въпроси ви помага да нула в на допълнителни елементи, за да запишете.

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

Най-горе на страницата

Разделяне на информация в таблици

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

информационни елементи, написани на ръка и групирани по предмет

Основни обекти, показан тук са продуктите, доставчици, клиенти и поръчки. Следователно, има смисъл да започнете с тези четири таблици: една за факти за продукти за факти за доставчици, по една за факти за клиенти и една за факти за поръчки. Въпреки че това не завършите списъка, е добра отправна точка. Можете да продължите да прецизирате този списък, докато получите проектиране, който работи добре.

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

Изображение, което показва таблица, съдържаща както продукти, така и доставчици

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

Вторият проблем с този дизайн идва когато трябва да промените информацията за доставчика. Да предположим например, трябва да промените адреса на доставчика. Тъй като тя се появи на много места, може да случайно променя адреса на едно място, но забравите да го промените в другите. Записване на доставчика адрес в само на едно място решава проблема.

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

И накрая да предположим, че има само един продукт, предоставена от Coho Winery, и искате да изтриете продукта, но запазва доставчик името и адреса информация. Как да изтриете записа на продукта без загуба на информация за доставчика? Не можете да. Тъй като всеки запис съдържа факти за продукт, както и факти за доставчик, не можете да изтриете едно без да изтриете другия. За да запазите тези факти отделен, трябва да разделите една таблица в две: една таблица за информация за продукта и друга таблица за доставчика информация. Изтриването на запис за продукт, трябва да изтриете само факти за продукта, не факти за доставчика.

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

Най-горе на страницата

Превръщане на информационните елементи в колони

За да определите колоните в таблица, да решавате каква информация трябва да проследите по темата записана в таблицата. Например за таблица "клиенти", име, адрес, City State Zip, изпрати имейл, поздрава и имейл адресът включва добра отправна списък на колони. Всеки запис в таблицата съдържа същия набор от колони, така че да можете да съхранявате име, адрес, City State Zip, изпращане на имейл, приветствието и имейл адрес информация за всеки запис. Например колоната адрес съдържа клиентските адреси. Всеки запис съдържа данни за един клиент и адресното поле съдържа адреса на клиента.

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

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

Следващият списък показва няколко Съвета за определяне на колоните.

  • За невключване на изчислените данни   

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

  • Съхраняване на информация в най-малкото логически части   

    Може да се изкуши да имат едно и също поле за пълните имена или имена на продукти заедно с описанията. Ако комбинирате повече от един тип информация в поле, е трудно да извлечете отделните факти по-късно. Опитайте да разбивка на информация в логически части; Например създайте отделни полета за собственото и фамилното име, или за име на продукта, категория и описание.

Списък на информационните елементи в процеса на проектиране

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

Най-горе на страницата

Задаване на първични ключове

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

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

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

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

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

Ако нямате предвид колона или набор от колони, които могат да направят добър първичен ключ, обмислете използването на колона от типа на данните с автоматично номериране. Когато използвате типа на данните за автономериране, Access автоматично присвоява стойност за вас. Такъв идентификатор е factless; Тя съдържа няма фактическа информация, описваща реда, който я представя. Factless идентификатори са идеални за използване като първичен ключ, защото те не се променят. Първичен ключ, който съдържа факти за ред – телефонен номер или клиент име, например – е по-вероятно да се промени, тъй като самата фактическа информация може да се промени.

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

1. колона към тип автономериране данни често е добър първичен ключ. Няма две продуктови идентификатори са еднакви.

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

За продукта база данни за продажби, можете да създадете колона с автоматично номериране за всеки от таблици, за да послужи като първичен ключ: ProductID за таблицата "продукти", OrderID за поръчки, CustomerID за таблица "клиенти" и таблицата SupplierID за таблицата доставчици.

Списък на информационните елементи в процеса на проектиране


Най-горе на страницата

Създаване на релации между таблици

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

Формуляр за поръчки

1. Информацията за този формуляр идва от таблицата "Клиенти"...

2... отиват таблица със служителите...

3... отиват таблица "поръчки"...

4... таблица за продукти на различните части...

5... и таблицата подробна информация за поръчката.

Достъп е система за управление на релационна база данни. В релационна база данни можете да разделите вашата информация в отделни, тематично базирани таблици. След това използвайте релации между таблици, за да обедини информацията според нуждите.

Най-горе на страницата

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

Помислете за този пример: доставчици и продукти таблици в продукта поръчки база данни. Доставчикът може да достави произволен брой продукти. Следователно, че за всеки доставчик, представени в таблицата по-доставчици, може да бъде много продукти, представени в таблицата "продукти". Следователно, връзката между доставчици на таблицата и таблицата "продукти" е "един към много".

представа за връзката ''един към много''

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

Колоната ИД на доставчик в таблицата "продукти" се нарича външен ключ. Външен ключ е първичен ключ на друга таблица. Колоната ИД на доставчик в таблицата "продукти" е външен ключ, защото също е първичен ключ в таблицата по-доставчици.

Списък на информационните елементи в процеса на проектиране

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

Най-горе на страницата

Създаване на релации много към много

Помислете за връзката между таблица за продукти и таблицата "поръчки".

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

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

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

релация ''много към много''

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

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

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

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

От таблицата по-подробна информация за поръчката можете да определите всички продукти на определен ред. Можете също да определите всички поръчки за даден продукт.

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

Списък на информационните елементи в процеса на проектиране


Най-горе на страницата

Екранна снимка, показваща налични емотикони и контролата за тяхното включване и изключване

Друг вид на връзката е релация. Да предположим, че трябва да записва някои специални спомагателни продукт информация, която ви е нужна рядко или, която се отнася само за няколко продукта. Тъй като не е нужно информация често и защото съхраняване на информацията в таблицата "продукти" ще доведе до празното място, за всеки продукт, към която не се отнася, можете да го поставите в отделна таблица. Като таблицата "продукти" можете да използвате ProductID като първичен ключ. Релация между тази допълнителна таблица и таблица "продукти" е релация. За всеки запис в таблица "продукти" съществува единичен съвпадение запис в таблицата по-допълнителни. Когато идентифицирате такава връзка, и двете таблици трябва да споделят общото поле.

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

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

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

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

Най-горе на страницата

Уточняване на проекта

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

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

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

  • Забравили сте всички колони? Ако е така, прави информацията принадлежат в съществуващи таблици? Ако е информация за нещо друго, трябва да създадете друга таблица. Създаване на колона за всеки елемент на информация, трябва да следите. Ако информацията не може да се изчисли от другите колони, е вероятно ще трябва нова колона за него.

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

  • Са ви многократно въвеждане на дублирани информация в един от вашите таблици? Ако е така, вероятно трябва да се разделят на таблицата на две таблици, които имат "един към много".

  • Имате ли таблици с много полета, ограничен брой записи и много празни полета в отделни записи? Ако е така, помислете за преработване на таблицата, така че има по-малко полета и още записи.

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

  • Всяка колона съдържа факт за темата на таблицата? Ако колоната не съдържа информация за темата на таблицата, тя принадлежи на друга таблица.

  • Са всички релации между таблици, представени като общи полета или третата таблица? Един към един "и" един към много зависимости изискват общи колони. Много към много отношения изискват трета таблица.

Уточняване на таблица "продукти"

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

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

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

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

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

  • ИД на продукт

  • Име

  • Продукт ID1

  • Name1

  • Продукт ID2

  • Name2

  • Продукт ID3

  • Name3

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

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

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

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

Най-горе на страницата

Прилагане на правила за нормализиране

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

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

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

Първата нормална форма

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

Втората нормална форма

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

  • ИД на поръчка (първичен ключ)

  • ИД на продукта (първичен ключ)

  • Име на продукта

Този дизайн нарушава втората нормална форма, тъй като име на продукта зависи от ИД на продукта, но не и на ИД на поръчка, така че не е зависими от целия първичен ключ. Име на продукта трябва да премахнете от таблицата. Принадлежи в друга таблица (продукти).

Третата нормална форма

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

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

  • ProductID (първичен ключ)

  • Име

  • SRP

  • Отстъпка

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

Най-горе на страницата

Забележка: Отказ от отговорност за машинен превод: Тази статия е преведена от компютърна система без човешка намеса. Microsoft предлага тези машинни преводи, за да помогне на потребителите, които не говорят английски, да се възползват от съдържанието за продукти, услуги и технологии на Microsoft. Тъй като статията е преведена машинно, е възможно да съдържа грешки в речника, синтаксиса и граматиката.

Разширете уменията си в Office
Преглед на обучението
Получавайте първи новите функции
Присъединете се към участниците в Office Insider

Беше ли полезна тази информация?

Благодарим ви за обратната връзка!

Благодарим ви за вашата обратна връзка. Изглежда, че ще бъде полезно да ви свържем с един от нашите агенти по поддръжката на Office.

×