1.1 Въведение
Проектирането на база данни е донякъде подобно на проектирането на архитектурата на Java проект. Можете да поставите всички данни в няколко таблици or можете да изградите красива структура от данни от схеми и десетки таблици.
Ето задачите, пред които обикновено се изправя разработчикът, когато проектира база данни:
- Гарантиране, че цялата необходима информация се съхранява в базата данни.
- Осигуряване на възможност за получаване на данни по всички необходими заявки.
- Намаляване на излишъка и дублирането на данни.
- Гарантиране на целостта на базата данни
- Оптимизиране на скоростта на достъп до данни
Основното нещо, което трябва да запомните е, че не можете да създадете идеална структура на базата данни, защото. той, подобно на вашия code, също ще се променя постоянно. Има три неща, които трябва да имате предвид, когато проектирате структурата на вашата база данни:
- Структурата трябва да е достатъчно добра.
- Трябва да има логика във всичко, което другите хора могат да разберат.
- Преждевременната оптимизация е коренът на всяко зло.
Не е нужно да правите най-добрата структура на база данни в света. Тя тепърва ще се променя. Вашата задача е да гарантирате, че след 20 промени в структурата на вашата база данни е достатъчно лесно да я разберете.
Най-вероятно през първите години от вашата работа никой няма да ви се довери да проектирате основа от нулата. Ще правите промени в съществуваща схема. Трябва да се опитате да разберете въз основа на Howви принципи е подредено и да се придържате към тях . С хартата си те не се качват в манастира на някой друг.
Не оптимизирайте базата данни, докато не е необходимо. Ако tableта има само няколкостотин реда, тогава най-вероятно СУБД ще я запази в паметта и ще кешира заявки към нея.
От друга страна, трябва да можете да ускорите работата на важни заявки с десетки or дори стотици пъти. И би било хубаво, ако знаеш How да го направиш. Как казват в гимназията през първата година? "Забравете всичко, на което са ви учor в учorще..."
Ако знаете Howво е нормализиране на база данни, тогава бързам да ви угодя, в работата си най-вероятно ще се занимавате с денормализиране . Нищо не е по-важно за светorщата на проекта от скоростта на базата данни. И ако, за да ускорите избора на данни от базата данни, трябва да комбинирате 200 (!) Таблици в една (с чудовищно излишък), ще трябва да направите това.
1.2 Дизайн на библиотеката
Нека се потопим малко в предметната област и да помислим за дизайна на база данни, използвайки нещо толкова просто като типична библиотека с книги.
Основната задача на всяка библиотека е обработката на книжния фонд. Лесно е да се разграничат три основни групи потребители на системата: читател, библиотекар, администратор . Дейността на всеки от тях е показана в диаграма на случаи на използване.
Още сега могат да се разграничат някои обекти и връзки на бъдещата база данни:
При този подход не е ясно How да се свърже читателят с книгата (читателят няма аритет във връзката „издаване / получаване“. Ако книгата има няколко екземпляра, тогава тя може да бъде издадена на няколко читатели. Дори ако една книга се разбира като едно копие, тогава, когато се запази в tableта с книги на текущия читател, ще бъде невъзможно да се получи информация за това кой (и колко пъти) е взел тази книга по-рано.
Решението може да бъде въвеждането на допълнителен субект - карта за издаване на книжка. При издаване на книгата на читателя се създава карта, а при предаване на книгата върху нея се поставя съответен знак. С помощта на тези карти се определят задълженията на всеки потребител и се изчислява статистика за използването на книги. При резервиране на литература от читателя също се стартира карта, ако резервираната литература не бъде взета от читателя в определен срок, картата се унищожава. Има ограничение за броя книги, които един читател може да резервира.
При избор на литература потребителят преглежда литературния каталог с възможност за филтриране на резултатите от търсенето по автор, заглавие, година на издаване.
Възможно е да се изчисли статистика за всички книги в библиотеката, докато броят на издадените екземпляри от книгата за даден период от време. Можете също да зададете минималния брой екземпляри на книги, за които се извършва изчислението. Въз основа на тази статистика неизползваните книги се отписват от библиотеката.
Могат да се разграничат следните основни обекти на предметната област:
- потребител (библиотекари и администратори);
- четец;
- читалня;
- Книга;
- карта за издаване на книга;
- карта за резервация на книга.
Модифицираната ER-диаграма на базата данни е показана на фигурата.
Според случаите на използване, показани на Фигура 1, базата данни трябва да изпълнява следните заявки (списъкът не е изчерпателен):
- показват книги, които отговарят на посочените условия;
- показват потребители, които имат карти за издаване на книги, които не са затворени навреме (библиотекарят търси длъжници);
- покажете всички книги, които отговарят на дадените карти за заемане на книги на потребителя, които не са затворени навреме (потребителят е дошъл в библиотеката за нови книги - трябва да видите дали е длъжник и да го информирате за това);
- изтрийте всички карти за резервации, създадени преди повече от N секунди;
- показва всички книги, съответстващи на незатворени карти за резервация на книги на посочения потребител (читателят е поръчал книги и е дошъл в библиотеката за тях - библиотекарят трябва да получи този списък, за да го раздаде).
1.3 Формиране на схема
За да формирате схема на данни, първо трябва да допълните ER диаграмата с подробности за обектите (да я прецизирате). Понякога в същото време е възможно да се намерят грешки при конструирането на ER диаграма - в тази задача беше установено, че книгата трябва да бъде „няHow си“ свързана със залата на библиотеката.
Това може да стане чрез поставяне на необходимия „номер на зала“ в книгата, но при този подход една и съща книга ще трябва да бъде описана в базата данни няколко пъти (ако се среща в различни зали). По-правилен подход е да се въведе допълнителен субект "поставяне на книги". Фигурата показва ER диаграма с добавен обект и подпори.
Горната ER диаграма отразява основните таблици, връзки и атрибути; на нейна основа можете да изградите модел на база данни. Няма стандарт за ER диаграмата, но има редица обозначения (Chen, IDEFIX, Martin и др.), но нито стандартът, нито обозначенията могат да бъдат намерени за модела на домейн. Въпреки това, в процеса на изграждане на такава диаграма, ключовите полета (външни и вътрешни) задължително се подчертават, понякога индекси и типове данни.
В този случай в следната диаграма:
- за връзки, нотация на Мартин (използва се "пачи крак");
- таблиците са показани като правоъгълници, разделени на 3 секции:
- име на table;
- вътрешни ключове (маркирани с маркер);
- останалите полета, а задължителните са маркирани с маркер.
При разработването на този модел имаше желание да се присъедини tableта на администраторите към tableта на библиотекарите - добавете обаче tableта на потребителите:
- администраторът не е свързан с конкретна стая (ще трябва да попълните съответното поле с нулеви стойности);
- това вероятно би усложнило разпределението на правата за достъп - сега само администраторът на базата данни (който работи през специален панел за СУБД и няма акаунт в разработваната система) има достъп до tableта с администратори. Въпреки това, когато се съединяват таблици, потребителските заявки ще изискват достъп до новата table.
При изграждането на тази диаграма беше открит и коригиран недостатък в схемата на ER - добавена е table, librarians_roomsкоято обединява библиотекари и зали. Това е необходимо, защото един библиотекар може да работи в няколко стаи, но няколко библиотекари могат да работят в една стая.
Когато проектирате бази данни, трябва да можете да разсъждавате поне като примера по-горе. Ако смятате, че сте успели, нека отидем по-нататък: още повече теория.