Това е част трета от поредицата, Пет нормални форми. Заглавията на първите две части (уроци) са Първа нормална форма, следвана от Втора нормална форма. В тази част от поредицата е обяснена третата нормална форма.
Обяснението следва сюжетната линия: Баща е починал и е оставил пари за сина си. Синът решил да инвестира парите в смесен магазин. Смесеният магазин, известен също като магазин за смесени стоки, е малък бизнес за търговия на дребно, който получава ежедневни артикули от доставчици и ги продава на отделни клиенти в квартала.
Към този момент магазинът вече е зареден и вече са направени някои продажби. Синът, който е собственик на бизнеса, има няколко служители, които в този урок се наричат чиновници. Собственикът и всеки служител могат да получават доставки и да извършват продажби след записване на продуктите.
Въпреки това, преди да започне магазинът, нито собственикът, нито служителите знаеха нещо за нормалните форми. И така, те записваха всичко като транзакции в една таблица и една тетрадка. Те нямаха компютър.
Вие, читателю, завършихте петте части от тази поредица от уроци; вече сте разработчик на база данни. Собственикът на магазина е ваш приятел. Посетихте магазина преди два дни и обучихте собственика и служителите да произвеждат маса в първата й нормална форма. Вие също посетихте магазина вчера и ги обучихте как да създадат таблица във втората нормална форма от първата нормална форма.
Днес току-що пристигнахте в магазина за посещение, за да ги обучите как да произвеждат маса в третата нормална форма от втората нормална форма. Всички таблици, които имат в момента, са във втората нормална форма. Таблиците (по име и заглавия на колони) са:
Продукти (ИД на продукт, ИД на категория, продукт)
Категории (categoryID, категория)
Продажби (идентификатор на продажба, клиент, служител, дата)
Подробности за разпродажба (идентификатор на продажба, идентификационен номер на продукт, брой продадени, продажна цена)
Поръчки (ID на поръчката, доставчик, служител, дата)
OrderDetails(orderID, productID, numberBought, costPrice)
Единичните или съставните клавиши са подчертани.
След като обобщи наученото през предходните два дни и преди да можете да направите нещо, собственикът пита:
„Какво ще кажете за телефонни номера, адреси и т.н. за клиенти и служители?
Какво ще кажете за количеството на склад, нивото на повторна поръчка и т.н. за продукти?
Имат ли нужда от собствени отделни маси или трябва да бъдат поставени в настоящите маси?“
Вие, разработчикът на база данни, отговаряте:
„Поздравления, собственик! Вие индиректно поставихте въпроса за Третата нормална форма.
Вие продължавате.
Други необходими колони
Други необходими колони първо се добавят към предишните таблици, които са в 1NF и 2NF. Някои от предишните имена на колони са променени.
Като минимум таблицата с категории трябва да има следните колони:
Категории (идентификатор на категория, име на категория, описание)
Описанието е кратък параграф, който описва категорията. Тази таблица с категории вече е в 1NF, 2NF и 3NF. 3NF е обяснено по-долу:
Като минимум таблицата с продукти трябва да има следните колони:
Продукти (ИД на продукт, ИД на категория, ИД на доставчик, име на продукт, цена на единица, количество в наличност, ниво на повторна поръчка)
Тъй като всеки продукт се продава, ще бъде достигнато ниско ниво (брой) на продуктите, когато продуктът трябва да бъде поръчан отново, така че клиентите не трябва да идват в магазина и да нямат продукта. Такова отсъствие не е добре за бизнеса. quantityInStock е броят на определен продукт в наличност. Това включва какво има в магазина и какво има на рафта.
categoryID и доставчикID са външни ключове. Ето защо те имат подчертано тире вместо единично подчертаване. Външният ключ е обяснен по-долу. В предишната част от поредицата (втора нормална форма) categoryID беше част от първичния ключ с едно подчертаване поради начина, по който се стигна до него. Въпреки това, от обяснението по-долу, ще стане ясно, че categoryID трябва да бъде външен ключ (с подчертано тире).
Тази таблица с продукти вече е в 1NF, 2NF и 3NF. Вижте защо е в 3NF по-долу:
Като минимум таблицата SaleDetails трябва да има следните колони:
SaleDetails(saleID, productID, unitSellingPrice, quantity, discount)
Очаква се стойността на отстъпката да бъде нула през повечето време. Отстъпката е отстъпката, която магазинът дава на клиент.
Като минимум таблицата OrderDetails трябва да има следните колони:
Подробности за поръчката (ID на поръчката, ID на продукта, unitCostPrice, количество, отстъпка)
Очаква се стойността на отстъпката да бъде нула през повечето време. Отстъпката тук е отстъпката, която доставчикът дава на магазина.
Както се вижда по-долу, таблицата с продукти може да се разглежда в 2NF или 3NF. Таблиците за продажби и поръчки имат проблем с 3NF. За обяснение на проблема и решението ще се използва само таблицата с продажбите. 3NF за таблица с поръчки и таблица с продукти следват подобни разсъждения и просто ще бъдат цитирани.
Докато добавяте колони, таблицата Продажби ще бъде:
Продажби (идентификатор на продажба, дата на продажба име на клиент, телефон, адрес, град, регион, пощенски код, държава, служител)
Седем колони са заменили колоната за клиенти в оригиналната таблица. Тъй като клиентите са хора от квартала, клетките за колоните за град, регион (щат), пощенски код и държава могат да бъдат оставени празни, въпреки че не са оставени празни в тази статия.
Тази таблица за продажби все още е в 2NF, тъй като правилата 1NF и 2NF не са нарушени. Трябва обаче да се разбере, че в ред на таблица Продажби клиентът (име) е заменен от седем клетки на ред на клиента.
Забележка: клетката за адрес съдържа номера на къщата, името на улицата или пътя и името на града, всички разделени със запетаи. Един град може да се разглежда като съставен от няколко града. Въпреки че запетаите разделят тези конкретни компоненти на низ, те образуват стойност на една клетка, а не три стойности на клетка.
Колоната за служители също трябва да бъде заменена със седем такива колони. Това обаче не е направено в този урок, за да се спести време и място за преподаване. И така, таблица Продажби с данни може да бъде:
Таблица за продажби – 2NF – Без идентификатор на клиента
Колоната тип данни SaleID е цяло число или, по-добре, автоматично нарастване. Типът данни на колоната dateSold е дата, а не число, тъй като има знака „/“, който не е цифра. Типът данни за останалите колони, включително колоната за телефон, е низ (или текст). Телефонната стойност има знака „-“, който не е цифра.
Имайте предвид, че за всеки ред клиентът (име), както беше в предишната част от серията, е заменен със седем клетки, една от които все още е име на клиент. Това означава, че клиентските данни са обект. В момента името на клиента идентифицира неговите други шест данни в един ред. Ако тази таблица е програмирана, ще бъде удобно да се идентифицира обектът клиент във всеки ред с цяло число (не автоматично нарастване). В този случай колона customerID трябва да предшества customerName. Предишната таблица става:
Таблица за продажби – 2NF – С идентификатор на клиента
Има три идентификатора на клиента: 1, 2 и 3, като 1 се среща пет пъти за Джон Смит, 2 се появява два пъти за Джеймс Тейлър и 3 се появява веднъж за Сюзън Райт.
Обърнете внимание, че някои идентификатори на клиенти и техните зависими се повтарят.
Правила за трета нормална форма
Една таблица е в Трета нормална форма, ако спазва следните правила:
- Вече трябва да е във втората нормална форма.
- И не трябва да има транзитивна зависимост.
Тогава един от чиновниците (служителите) пита: „Какво е преходна зависимост?“. И вие, разработчикът на база данни, отговаряте: „Това е добър въпрос!“
Транзитивна зависимост
Вярно е, че в ред SaleID идентифицира всички стойности в реда; въпреки това, customerID идентифицира своите седем стойности на данни, но не идентифицира останалите стойности, идентифицирани от SaleID в този ред. Казано по друг начин, SaleID зависи от десет стойности на клетки във всеки ред. CustomerID обаче зависи от седем стойности на клетки в един и същ ред, но customerID не зависи от SaleID и другите стойности, от които зависи SaleID.
Такава зависимост за custumerID е транзитивна зависимост. А customerID се нарича външен ключ и е подчертан с тире в тази серия от уроци, Петте нормални форми.
Да предположим, че неосновен атрибут (неосновна стойност на клетка) зависи от други неосновни атрибути и въпросният неосновен атрибут (напр. customerID и неговите зависими елементи) не зависи от първичния ключ и останалата част от клетката стойности в реда. Тогава това е преходна зависимост.
Предишната таблица Продажби с външния ключ и неговите зависими би причинила счетоводни проблеми (аномалии).
Таблица на продажбите от 2NF до 3NF
За да разрешите проблема, породен от външния ключ и неговите зависими, премахнете външния ключ и неговите зависими, за да формирате нова таблица без повторения. Въпреки това, дори ако външният ключ не зависи от първичния ключ, първичният ключ зависи от външния ключ. Така че копие на външния ключ трябва да остане в родителската таблица. Новата таблица за продажби в този момент е съвместима с 1NF, 2NF и 3NF; това е родителска таблица. Новата дъщерна таблица от предишната таблица Sales също е съвместима с 1NF, 2NF и 3NF. Името на дъщерната таблица с външен ключ и нейните зависими е Клиенти. Ако не може да се намери подходящо име, значи нещо се е объркало с анализа. Новата таблица на продажбите в 3NF е:
Крайна таблица на продажбите в 3NF
Тази таблица в 3NF има същия брой редове като тази в 2NF, но с по-малко колони.
Нотацията на таблицата за тази крайна таблица Продажби в 3NF е:
Продажби (saleID, dateSold, customerID, EmploeeID)
saleID е първичният ключ с едно подчертаване. customerID е външен ключ, с подчертано тире. employeeID също е външен ключ с подчертано тире. Обърнете внимание, че ситуацията на служителите в таблицата Продажби в 2NF е същата като ситуацията на клиента. EmployeeID и неговите собствени зависими трябва да бъдат изтеглени, за да се образува друга таблица; остава копие от личната карта на служителя.
Забележка: saleID, customerID и EmploeeID не образуват съставен ключ. saleID зависи от customerID и EmploeeID.
Връзката между saleID и customerID е много към едно.
Клиентската маса в 3NF
Тази таблица има три реда вместо 9 реда в таблицата 2NF Sales. В тази таблица customerID е първичен ключ. Той е същият като външния ключ в таблицата Sales, но без повторения. Външният ключ в таблицата Sales и първичният ключ в таблицата Customer свързват двете таблици.
Повтарящите се редове в таблицата Customer са премахнати, за да не се нарушава 1NF.
Както читателят може да види, поставянето на таблица в 3NF също би решило проблема с повтарящите се редове (излишък).
Нотацията на таблицата за Customers Table е:
Клиенти (идент. № на клиента, име на клиента, телефон, адрес, град, регион, пощенски код, държава)
Преглед на таблицата с продукти
Таблицата с продуктите, дадена по-горе в нотационна форма, е:
Продукти (ИД на продукт, ИД на категория, ИД на доставчик, име на продукт, цена на единица, количество в наличност, ниво на повторна поръчка)
Първичният ключ тук е productID. categoryID и доставчикID са външни ключове. Подобно на таблицата Customer, има таблица Categories, където categoryID е първичният ключ, и има таблица Supplier, където доставчикID е първичният ключ.
Ако стойностите за клетките за unitPrice, quantityInStock и reorderLevel ще останат фиксирани, тогава таблицата Products, каквато е, наистина е в 3NF. Ако тези стойности ще се променят, тогава таблицата „Продукти“, както е, е в 2NF. В тази част от серията уроци се приема, че тези стойности остават фиксирани във времето.
Всички маси
Всички маси вече са в 3NF. Те са показани като:
Служители (идент. № на служител, име, телефон, адрес, град, регион, пощенски код, държава, дата на раждане, дата на наемане, дата на освобождаване)
Доставчици (ID на доставчика, име, телефон, адрес, град, регион, пощенски код, държава)
Продукти (ИД на продукт, ИД на категория, ИД на доставчик, име на продукт, цена на единица, количество в наличност, ниво на повторна поръчка)
Категории (идентификатор на категория, име на категория, описание)
Продажби (saleID, dateSold, customerID, EmploeeID)
Подробности за разпродажба (идентификатор на продажба, идентификационен номер на продукт, брой продадени, продажна цена)
Клиенти (идент. № на клиента, име на клиента, телефон, адрес, град, регион, пощенски код, държава)
Поръчки (идентификатор на поръчка, дата на продажба, идентификационен номер на доставчик, идентификационен номер на служител)
OrderDetails(orderID, productID, numberBought, costPrice)
Създадени са до девет професионални таблици само от една таблица, създадена от начинаещи, за да се предотвратят излишни и счетоводни проблеми (аномалии от вмъкване, изтриване и актуализиране). Само масата за начинаещи би довела до финансови загуби.
Тестване на персонала
В този момент всички служители, включително собственикът, трябва да са разбрали 1NF, 2NF и 3NF. Те обаче трябва да бъдат тествани. Всички те, включително собственикът, ще седнат на различни места и ще изпълнят теста. Тестът, състоящ се от един въпрос, ще отнеме един час и е както следва:
Въпрос: Използвайки правила за 1NF, 2NF и 3NF, докажете, че всички горни девет таблици вече са в първа нормална форма, втора нормална форма и трета нормална форма. Не е задължително клиентите и доставчиците да са реални лица. Данните за таблици трябва да архивират нотациите на таблицата.
Докато те завършват теста, вие като разработчик на базата данни излизате да хапнете и да пиете бира, за да се върнете след един час.
Близкото и далечното бъдеще
Докато вие, разработчикът на база данни, сте навън, вие също обмисляте какъв съвет да им дадете, ако всички преминат теста.
Освен това, докато ги обучавахте и сега, когато се явяват на теста, клиентите идваха и си тръгваха, без да бъдат обслужени. Това не е добре за бизнеса и вие, разработчикът на база данни, знаете това. Някои клиенти може да отидат в магазините на конкурентите и никога да не се върнат.
Вие, разработчикът на база данни, сте на 30 години. Собственикът, като ваш приятел, също е на 30 години. Чиновниците (служителите) са на възраст от 18 до 24 години. Всички качества, необходими за работа при собственика са: да са здрави, да могат да четат и пишат, да могат да събират, изваждат, умножават и делят. , както и да могат да използват компютър и интернет.
Когато една таблица е в 3NF, повечето уязвимости са премахнати от базата данни. Много търговски бази данни не надхвърлят 3NF и фирмите или компаниите са удобни.
Така че, ако всички преминат теста, ще помолите чиновниците да отидат и да продължат да работят. Освен това ще ги посъветвате да спестяват част от заплатите си, за да могат да притежават своите магазини. Утре ще продължите да обучавате само собственика в 4NF и 5NF. Със знанието на 4NF и 5NF всички известни уязвимости се премахват.
Оценка
След един час вие, разработчикът на базата данни, се връщате. Маркирате сценариите им. Отлична новина! Всички те, включително собственикът, имат по 100%. ура! Това е отлично!
Така че поздравления за всички вас: учителя и учениците.
В този урок не остава нищо друго освен да завършите.
Заключение
Една таблица е в първа нормална форма, ако не нарушава някое от следните правила:
- Всички колони в таблицата трябва да имат уникални имена на заглавки.
- Всяка клетка трябва да има само една стойност.
- Стойностите, съхранявани в колона, трябва да бъдат от един и същи тип.
- Редовете трябва да са различни.
- Редът на колоните или редовете няма значение.
Една таблица е във втора нормална форма, ако не нарушава някое от следните правила:
- Таблицата вече трябва да е в първа нормална форма.
- Не трябва да има частична зависимост.
Една таблица е в Трета нормална форма, ако не нарушава нито едно от следните правила:
- Трябва вече да е във втората нормална форма.
- И не трябва да има транзитивна зависимост.
Вие, разработчикът на база данни, кажете на чиновниците, че са научили достатъчно. Предоставяте съвет и ги молите да се върнат на работа и да останат на станциите си по подразбиране.
Уговаряте среща само със собственика, която да се проведе утре в неговия офис за обучение по 4NF и 5NF.
