Тази глава е от книгата

Тази глава е от книгата

Тази глава е от книгата 

Примери за таблици

Досега обсъждахме теорията на таблиците, но не сте виждали реални. В следващите раздели ще видите някои действителни таблици. Разглеждаме таблица, за да видим как изглежда както в Oracle, така и в Access. Обсъждаме някои от дизайнерските решения, които се използват при конструирането на много таблици. Също така изследваме таблиците на базата данни за обяди, която се използва в много от примерите в тази книга.

информация

1-12 Пример за таблица в Oracle и Access

Този раздел показва една и съща таблица както в Oracle, така и в Access. Това е първата ни възможност да проверим как се сравняват Oracle и Access.

Вие сами ще трябва да решите колко си приличат и колко са различни. За мен този пример показва, че те са около 90 процента сходни и около 10 процента различни. Разбира се, това е само един пример. Може да се запитате кои проценти бихте използвали, за да опишете това.

Таблиците на Oracle могат да бъдат показани в два формата, които са много сходни, но имат няколко малки разлики. За да улесня нещата тук, аз ви показвам само един от тези формати. Следващата таблица на Oracle е получена с помощта на средата “SQL Command Line”. Другият формат на Oracle се среща в средата „Начална страница на базата данни“. Ще го обсъдя накратко в бележките в края на този раздел.

Таблица l_employees: Формат на Oracle

Прилики между Oracle и Access

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

Разлики между Oracle и Access

Дисплейна рамка: Oracle показва редове с символни данни. Access използва графични техники за показване на данните в мрежа и оцветяване на границите на мрежата.

Казус: Таблицата на Oracle е показана с главни букви. Таблицата Access използва главни букви само за първата буква. Обичайната конвенция е да се създават базите данни по този начин. Данни със смесени букви могат да се поставят в таблица на Oracle, но това прави данните по-трудни за обработка, така че данните на Oracle обикновено са или с главна буква, или с малки букви. Данните за достъп се обработват така, сякаш са с главни букви, въпреки че се показват в смесен регистър. Това го прави по-хубав, но понякога може да бъде и измамен. В Access данните изглежда са смесени, но данните се държат така, сякаш са с главни букви. Например, John и jOhn изглеждат различни в Access, но с тях се работи така, сякаш са еднакви.

Заглавия на колони: Oracle може да използва няколко реда за заглавие на колона. Access показва заглавието на един ред.

Формати на дати: Датите по-горе показват Oracle и Access, използвайки същия формат на датата. Направих това да се случи тук, защото исках Oracle и Access да изглеждат подобни. На вашия компютър обаче датите вероятно ще използват различни формати.

Oracle и Access могат както да показват дати в различни формати. Всеки има формат по подразбиране, който да се използва за дати, когато не е посочен друг формат. Oracle обаче използва един метод, за да определи този формат по подразбиране за дати, а Access използва различен метод.

Подравняване по дата: Oracle подравнява датите вляво, докато Access ги подравнява вдясно.

Нула: В тази книга съм настроил Oracle винаги да показва nulls като (null) във всички колони на всяка таблица. Това не може лесно да се направи в Access.

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

Възможност за добавяне на данни: В Access празен ред в долната част на таблица показва, че в нея могат да се въвеждат нови редове с данни. Показва се и допълнителна колона, наречена „Добавяне на ново поле“. Това не се прави в Oracle.

Другият формат на Oracle се използва в средата „Начална страница на базата данни“. Той има няколко технически разлики, но нито една, която няма да оспори разбирането ви за случващото се. Ето няколко от тези разлики:

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

1-13 Някои дизайнерски решения в таблицата l_employees

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

таблица l_employees

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

  • Колоната phone_number съдържа текстови данни, а не числа. Въпреки че данните изглеждат като числа и името на колоната казва число, всъщност има текстов тип данни. Можете да разберете това по подравняването му, което е вляво. Причината таблицата да е настроена по този начин е, че данните за телефонния номер никога няма да се използват за аритметика. Никога не добавяте два телефонни номера заедно или ги умножавате. Използвате ги само такива, каквито са, като текстово поле. Така че тази таблица ги съхранява като текст.
  • Колоната служител_ид съдържа числа. Можете да разберете това по подравняването му, което е вдясно. Сега не правим аритметика с идентификатори на служители, никога не ги събираме, така че защо и това не е текстово поле? Отговорът е, че числата често се използват за колони с първичен ключ, дори когато върху тях няма да се извършва аритметика. Това може да позволи на компютъра да се справи с масата по-бързо.
  • Колоната manager_id съдържа числа, но не е колона с първичен ключ. И така, защо не съдържа текст? Тази колона е предназначена да съвпада с колоната worker_id, така че е получила същия тип данни като тази колона. Това подобрява скоростта на съвпадение на двете колони.
  • Името на таблицата, l_employees, може да изглежда странно. L показва, че тази таблица е част от група таблици. Имената на всички таблици в групата започват с една и съща буква (и). В този случай това показва, че таблицата е част от базата данни за обяди. (Тук използвам термина база данни да означава колекция от свързани таблици.)
  • Хората, които проектират бази данни, влагат значителна работа в последователното именуване на обекти, като използват стандартни префикси, суфикси, съкращения и имена на колони. Това прави целия модел по-лесен за разбиране и по-използваем за кода, разработен за всяка база данни.

1-14 База данни за обяди

Повечето примери за SQL код в тази книга се базират на базата данни Lunches. Можете да получите пълен списък на тази база данни от уеб сайта. За да прочетете тази книга, ще трябва да разберете историята и данните, така че ето основната история.

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

Това е историята. Сега нека разгледаме данните. Когато наричам това база данни, имам предвид, че това е колекция от свързани таблици. Комплектът маси, взети заедно, разказват историята. В тази база данни има седем таблици:

  • Служители (l_employees)
  • Катедри (l_departments)
  • Константи (l_constants)
  • Обяди (l_lunches)
  • Храни (l_foods)
  • Доставчици (l_suppliers)
  • Обедни елементи (l_lunch_items)

За да покажат, че всички таблици са свързани помежду си и да ги различават от останалите таблици, които можем да използваме, всички имена на тези таблици имат префикс с буквата l. Когато има множество думи, като например обед_елементи, интервалите се заменят с символи за подчертаване. Това помага на компютъра да разбере, че двете думи заедно са едно име.

таблица l_employees

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

Всеки служител има мениджър, който е и служител на компанията. Мениджърът се идентифицира с неговия идентификационен номер. Например колоната manager_id показва, че Джим Керн се управлява от служител 201. Служител 201 е Сюзън Браун.

Сюзън Браун и Карол Роуз са единствените служители без мениджър. Можете да кажете това, защото в колоните manager_id има нула. Тези нули обаче означават различни неща.

Сюзън Браун е ръководител на компанията. Нулата в този случай не означава, че не знаем кой е нейният мениджър. По-скоро това означава, че тя няма мениджър.

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

таблица l_departments

Всеки служител работи за един отдел. Кодът на отдела е показан в таблицата l_employees. Пълното име на всеки отдел е показано в таблицата l_departments. Първичният ключ на тази таблица е dept_code.

Тези таблици могат да бъдат свързани заедно чрез съвпадение на колоните dept_code. Например таблицата l_employees ни показва, че служител 202, Джим Керн, има код на отдел SAL. Таблицата l_departments казва, че отделът по продажбите използва кода на отдела SAL. Това ни казва, че Джим Керн работи в отдела за продажби.

таблица l_constants

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

l_lunches таблица

Таблицата l_lunches регистрира служител, който да присъства на обяд. Той присвоява идентификатор за обяд на всеки обяд, който ще бъде сервиран. Например служител 207, Дан Смит, ще присъства на обяд на 16 ноември 2011 г. Неговият обяд е идентифициран като lunch_id = 2.

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

Таблицата l_lunches показва най-често срещания начин за използване на сурогатен ключ. Обикновено една колона е първичният ключ. Тази колона има различна стойност във всеки ред.

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

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

таблица l_foods

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

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

l_suppliers таблица

Таблицата l_suppliers показва пълните имена на доставчиците на храни. Например таблицата l_foods показва, че пържените картофи ще бъдат получени от ID на доставчика FRV. Таблицата l_suppliers показва, че зеленчуците на Frank Reed’s са пълното име на този доставчик. Основният ключ на тези таблици е идентификаторът на доставчика.

l_lunch_items таблица

Когато разглеждате таблицата l_lunch_items, трябва да знаете, че данните в колоната item_number са подравнени вдясно, защото това е колона с числа. Данните в колоната доставчик_ид са подравнени вляво, защото са колона с текст. Така че, когато погледнете първия ред, 1 ASP не е нито една част от данните. Вместо това стойността item_number е 1, а стойността доставчик_id е ASP.

Таблицата l_lunch_items показва кои храни е избрал всеки служител за своя обяд. Той също така показва дали искат единична или двойна порция. Например погледнете lunch_id 2, който вече знаем, че е обядът на Дан Смит на 16 ноември. Той се състои от четири елемента. Първият елемент е идентифициран като ASP-SW. Тук поставям данните за колоната на доставчика_и и продукта_код заедно, разделени с тире. Поглеждайки в таблицата l_foods, откриваме, че това е сандвич. Таблицата l_lunch_items казва, че иска две от тях, което е показано в колоната количество. Вижте дали можете да разберете всички храни, които той иска за обяда си.

Правилният отговор е:

  • 2 сандвича
  • 1 поръчка пържени картофи
  • 2 чаши кафе
  • 1 десерт

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

Предизвикателни характеристики на базата данни за обяди

Повечето SQL книги имат работа с база данни, която е кротка и не съдържа предизвикателства. Тази книга е различна. Умишлено съм сложил някои функции в базата данни за обяди, които могат да ви накарат да получите грешен резултат, ако не се справите правилно с тях. Показвам ви как да осъзнаете тези ситуации и как да се справите с тях. Много реални бази данни съдържат подобни предизвикателства. Ето няколко от тях:

  • Двама служители не присъстват на нито един обяд - служител 209, Пола Джейкъбс и служител 206, Карол Роуз.
  • В нито един от обядите не е поръчана една храна - броколи.
  • В един от отделите все още няма персонал - служителите в персонала.