Следващите раздели показват как са проектирани релациите между таблиците на базата данни. Имената на обектите са предоставени, така че да можете лесно да ги прегледате в базата данни Northwind 2.0 Starter Edition.
За да отворите диаграмата на релациите, показваща шестте таблици и релациите между тях, изберете Инструменти за бази данни > Релации.
Тази диаграма показва всичките шест таблици. В диаграмата линиите между таблиците идентифицират релации между тях. Знакът 1 и символът за безкрайност (∞) в краищата на линиите представляват една страна на релация (например един клиент) и многостранната на релация. Например един клиент подава много поръчки. За повече информация вижте Ръководство за релации между таблици.
Следните принципи важат за таблиците в Northwind 2.0 Starter Edition, както и таблиците като цяло.
Първични ключове Еднозначно идентифицирайте всеки запис в таблица. Всички таблици имат първичен ключ. В диаграмата на релацията символите на клавишите идентифицират тези първични ключове. Конвенциите за именуване на първичен ключ са наименувани за таблицата, в която се намират, например "TableNameID".
Ефективност За по-добра производителност и по-ефективно съхранение първичните ключове трябва да бъдат числови. Освен това е по-удобно да накарате Access да генерира автоматично новата, уникална стойност за първичния ключ на всеки нов запис. Типът данни "Автономериране" има и двете характеристики. Автономерирането по друг начин не е смислено число и не служи за друга цел. За повече информация вж. Добавяне на поле с автоматично номериране като първичен ключ.
Външни ключове Една таблица може да има един или повече външни ключове в зависимост от това дали е свързана с други таблици в базата данни. Външният ключ съдържа стойности, които съответстват на стойности в първичния ключ на свързаната таблица.
Уникални индекси Други полета в таблиците може също да имат свои собствени уникални индекси, например OrderStatus.StatusCode. Нелогично е да имате две състояния на поръчки в таблицата OrderStatus с един и същ код, въпреки че StatusCode не е самият първичен ключ. Уникалният индекс казва на Access да предотврати дублираните стойности в това поле.
Не уникални индекси Таблиците може също да имат индекси, които да ускорят търсенията и сортират по тези полета, например Orders.OrderDate. Много поръчки могат да бъдат направени в един и същ ден и често искате да търсите и сортирате по дати на поръчки. В това поле има не уникален индекс, който да ускори търсенето и сортирането.
Имена на таблици и полета Можете да наименувате нещата по желания от вас начин, но съгласуваността е важна. Препоръчваме имената на таблиците и полетата да са една или повече думи без интервали между тях и да няма специални знаци, като например наклонена черта (/), знак за диез (#) или процент (%). Например използвайте OrderDate, но не и Order Date; използвайте OrderNumber или OrderNo, но не и Order#.
Камила Използвайте главни букви, за да маркирате отделни части от името, например "Дата на поръчка", но не "Дата на поръчка" или "Дата на поръчка".
Задължителна стойност Този принцип води до важността на бизнес правилата за прилагането. Някои ситуации изискват стойности или дори конкретни стойности в някои полета. Например каква е ползата от поръчката, без да знаете кой я е поставил? Това означава, че CustomerID е задължително поле за таблицата "Поръчки".
Изчисляеми полета Access поддържа изчисляеми полета в таблици, например полето Employees.FullName. Може да предпочетете да създавате изчисляеми полета в заявка, а не в таблица.
Полета за прикачени файлове Access поддържа полета за прикачени файлове, например Employees.Picture, което съдържа снимка на служителя. Прикачените файлове могат да съхраняват изображения, документи, имейли и друга двоична информация. Прикачените файлове заемат много място в базата данни. вместо това е по-ефективно да съхранявате прикачени файлове на файлов сървър.
Многозначни полета Както подсказва името, многозначните полета съхраняват една или повече стойности в едно поле, например Employees.Title. Препоръчваме ви да ги използвате пестеливо, особено ако искате да извършите преоразмеряване на вашата база данни. Повечето други системи за бази данни ги нямат, така че това ще изисква много повторна работа.
За повече информация за типовете данни вж. Въведение в типовете данни и свойствата на полетата.
Този раздел описва най-важните характеристики на всяка таблица. За да прегледате проекта на таблица, изберете я в навигационния екран, щракнете с десния бутон върху нея, изберете Изглед за проектиране или изберете Инструменти за бази данни > Релации и след това щракнете с десния бутон върху обект от таблица. За повече информация вижте Въведение в таблиците.
Важно: Избягвайте използването на запазени думи, които могат да доведат до конфликти при наименуване. За повече информация вижте Научете повече за запазените думи и символи на Access.
Таблица ''Служители''
Тази таблица съхранява информация за служителите на Northwind.
|
Полета |
Описание |
|
СобственоИме, фамилно име |
И двете имена са задължителни и в Northwind заедно трябва да са уникална комбинация. В проекта на таблицата, когато отворите диалоговия прозорец Индекси , можете да видите, че СобственоИме + ФамилноИме имат уникален индекс. Тъй като FirstName и LastName са уникално индексирани, таблицата Northwind не може да съхранява двама служители с едно и също име. В други ситуации можете да използвате друго бизнес правило. |
|
FullNameFNLN, |
Погледнете свойството на израза на изчисляеми полета, за да видите как Access комбинира стойности в изчисляеми полета. За да включите среден инициал, добавете го към съществуващия израз с подходяща разредка между компонентите. |
|
Телефонни полета |
Бизнес правилото за телефони е, че предпочитанията на служителите са по-подходящи от типа услуга. Следователно се използват първични и вторични телефонни номера, а не мобилни, служебни, домашни и т.н. |
|
Поздрав |
Поздравът е поле "Кратък текст". За да илюстрирате многозначното поле в Access, това е разгъващ се списък с редактируем списък с предварително дефинирани стойности. Кратки, статични списъци като този често са кандидати за многозначни полета, защото те не се променят много, ако някога се случват. |
|
Заглавие на задание |
JobTitle е друго задължително поле. |
Таблица "Клиенти"
Тази таблица съхранява информация за клиентите на Northwind.
|
Полета |
Описание |
|
Име на клиент |
Клиентите на Northwind са фирми и се изисква име на клиент. За разлика от имената на служителите обаче, това не е еднозначно индексирано, което позволява на двама или повече клиенти да имат едно и също име. |
|
PrimaryContactFirstName, PrimaryContactLastName, |
Собственото и фамилното име и длъжността на основния контакт не са задължителни, тъй като е възможно клиентите да нямат един човек като свой основен контакт. Контактите не могат да дават длъжност за поръчка. |
|
Служебен телефон |
Northwind изисква само един телефонен номер за всеки клиент, въпреки че това елиминира възможността за заснемане на няколко телефонни номера за клиенти или за контакти от клиенти. В реални ситуации по-сложните бизнес правила обикновено се прилагат към информацията за връзка. |
|
Адрес, град |
Northwind се нуждае от адрес за изпращане на поръчки на клиенти. Има само един общ адрес за клиент. В реални ситуации клиентите често имат отделни адреси за фактуриране, доставка или други. Друго бизнес правило за вашата организация ще изисква допълнителни полета. |
|
Бележки |
Полето "Бележки" е тип данни "Дълъг текст", който съхранява до 1 ГБ текст. Това ви позволява да въведете подробни коментари за клиентите, които да използвате в следващите ситуации на подреждане. |
Таблицата ''Поръчки''
Тази таблица съхранява информация за поръчките на Northwind.
|
Полета |
Описание |
|
OrderDate, ShippedDate, PaidDate |
Поръчките изискват три дати. Всички те са от тип данни "Дата/час", но с два формата. OrderDate има дата и час, тъй като може да се интересувате от анализиране на обема на поръчките за различни части на деня. За другите две дати се изисква само датата. Валидиращо правило за таблица за "Дата на експедиране" и "Платена_дата" гарантира, че тези дати не са преди "Дата на поръчка". |
|
OrderStatusID |
Състоянието на поръчката показва къде се намира поръчката в работния поток Northwind. Поръчките се придвижват през четири фази: Създай – > Фактурирано – > Експедирани – > Приключени.Външният ключ за текущия OrderStatus използва OrderStatusID от справочната таблица на OrderStatus. Използването на таблица за справка "Състояние" гарантира, че само четирите предварително дефинирани състояния могат да бъдат присвоени на поръчка. |
Таблица с подробни данни за поръчката
Тази таблица съхранява информация за подробните данни за поръчката на Northwind.
|
Полета |
Описание |
|
ИД на поръчка |
Всеки реден елемент в таблицата OrderDetails трябва да принадлежи към една поръчка в таблицата "Поръчки". OrderID е външен ключ, идентифициращ тази поръчка. Както беше отбелязано по-рано, една поръчка, съдържаща един или повече редове, илюстрира релация "един към много". |
|
ИД на продукт |
Всеки запис в таблицата "Данни за поръчки" включва "ИД на продукт" за поръчания продукт. ProductID е външен ключ в таблицата OrderDetails, идентифициращ този продукт в тази поръчка. Това е също релация "един към много". |
|
OrderID+ ИД на продукт |
Както видяхте в таблицата "Служители", няколко полета могат да имат уникален индекс. Уникалният индекс върху OrderID+ProductID в таблицата OrderDetails гарантира, че всяка поръчка съдържа продукт само веднъж. Когато отворите списъка със свойства Индекси от лентата, можете да видите този уникален индекс. |
Таблица "Продукти"
Тази таблица съхранява информация за продуктите на Northwind.
|
Полета |
Описание |
|
Код на продукт |
В допълнение към първичния ключ ProductID, продуктите Northwind имат хуманно, уникално индексиран продуктов код. Служителите обикновено препращат към продуктови кодове, а не стойности на първичен ключ. Кодът на продукта е комбинирана стойност, състояща се от обозначение на категория и число, например B-1 за "Напитки", продукт 1. |
|
"Име на продукта", |
В допълнение към кратките текстови имена на продуктите, за продуктите се прилага дълго текстово описание. Тази стойност може да се използва в описание на каталог или за отговаряне на въпроси на клиенти. |
|
Единична цена |
Всички продукти се продават с единична цена за всеки артикул, което опростява базата данни като изложение на функциите. В повечето реални ситуации цените често са значително по-сложни. |
Вж. също
