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

В тази статия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добре е да създадете прототип на всеки отчет или списък с резултати и да обмислите кои елементи ще ви трябват, за да създадете отчета. Например, когато преглеждате формулярно писмо, може да имате на ум няколко неща. Ако искате да включите приветствие – например низа "Mr.", "Mrs." или "Ms.", който започва поздрав, ще трябва да създадете приветствие. Също така, обикновено може да започнете писмо с "Уважаеми г-н Смит", а не "Уважаеми. Г-н Силвестър Смит. Това предполага, че обикновено бихте искали да съхранявате фамилното име отделно от собственото име.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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