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

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

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

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

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

В тази статия

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Следователно, добър проект на базата данни е този, който:

  • разделя информацията в базирани на обекти таблици, за да намали излишните данни;

  • осигурява на Access информацията, която му е необходима за свързване на информацията в таблиците, както е необходимо;

  • помага да се поддържа и гарантира верността и целостта на вашата информация;

  • отговаря на вашите нужди от обработка на информацията и изготвяне на отчети.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Задаване на релации между таблиците    

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Не включвайте изчисляеми данни    

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Колона, зададена като тип данни "автономериране", често е подходящ първичен ключ. Няма два еднакви идентификатора на продукт.

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

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

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


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

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

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

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

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

2. ... таблицата "Служители"...

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

4. ... таблицата "Продукти"...

5. ... и таблицата "Подробно за поръчките".

Access е система за управление на релационни бази данни. В релационната база данни разделяте информацията в отделни таблици, базирани на обекти. След това използвате релации между таблиците, за да обединявате информацията както ви е необходимо.

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

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

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

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

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

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

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

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

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

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

Да разгледаме релацията между таблицата "Продукти" и таблицата "Поръчки".

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Представени ли са всички релации между таблиците чрез общи полета или чрез трета таблица? Релациите "един към един" и "един към много" изискват общи колони. Релациите "много към много" изискват третата таблица.

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

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

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

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

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

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

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

  • Име

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

  • Име1

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

  • Име2

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

  • Име3

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

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

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

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

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

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

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

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

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

Първо правило за нормализация

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

Второ правило за нормализация

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

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

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

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

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

Трето правило за нормализация

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

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

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

  • Име

  • ПЦД

  • Отстъпка

Да приемем, че "Отстъпка" зависи от препоръчителната цена на дребно (ПЦД). Тази таблица нарушава третото правило за нормализация, тъй като неключовата колона "Отстъпка" зависи от друга неключова колона – "ПЦД". Независимостта на колоните означава, че би трябвало да можете да променяте всяка неключова колона, без това да засяга която и да е друга колона. Ако промените стойност в полето "ПЦД", "Отстъпка" ще се промени съответно, което е нарушение на това правило. В този случай "Отстъпка" трябва да се премести в друга таблица, свързана с ключа към "ПЦД".

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

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

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

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

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

×