Част 2 – Как да организираме диаграма на голяма база данни

В част 1 от тази серия успешно импортирахме структурата на базата данни SuiteCRM в нашия онлайн инструмент за моделиране на база данни. Тогава видяхме, че моделът съдържа 201 таблици без връзки между тях. Имаме дива купчина маси, които изглеждаха наистина разхвърляни. В тази статия ще ви покажа как можете да организирате такъв голям модел.

Непосредствено след импортирането във Vertabelo, моделът на базата данни на SuiteCRM изглежда по следния начин:

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

Vertabelo предлага три основни инструмента, които да ви помогнат да организирате големи диаграми:

• Тематични области
• Таблици и преки пътища за преглед
• Преки пътища за справка

Ще ги опиша по-късно в тази статия, но можете също да научите повече, като гледате този видеоклип.

Стъпка 1. Деактивирайте автоматичното генериране на чужди ключове

На първо място, ще деактивираме автоматичното генериране на външни ключове. По подразбиране Vertabelo генерира атрибути на външния ключ, когато изтегляме релации от първична таблица към реферирана таблица. Това обикновено е добро нещо, но не и тук. Вече имаме атрибути, които представляват външни ключове. Това, което ни липсват, са „истински“ връзки между таблиците. За да изключите тази опция, щракнете върху „Моят акаунт“ в горното меню и намерете „Лични предпочитания“ раздел.

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

Стъпка 2. Групирайте таблици с префикс с предметни области

След това нека групираме няколко таблици. Ще направим това с помощта на областта за тема инструмент, който позволява да се асоциират таблици въз основа на избрани критерии. В нашия случай се опитваме да идентифицираме таблици, които са свързани или са част от един и същ процес. Това ще доведе до групи като „Обаждания“, „Среща“ и „Кампании“.

Можем да създадем тематична област, като щракнем върху „Добавяне на нова област“ икона в кутията с инструменти:

и след това начертаване на правоъгълник върху нашия модел:

Предметната област е създадена. Можем да го видим в „Структура на модела“ панел вляво:

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

В SuiteCRM има много таблици, които споделят общ префикс. И така, започнах да групирам таблиците с префикс. Разгледайте таблиците „acl“ като пример. В панела „Структура на модела“ намерих всички таблици, чиито имена започват с „acl_“:

След това създадох тематичната област „acl“ в модела и плъзнах всички подходящи таблици в нея. (За по-добра видимост зададох цвета на фона на лилав.)

Сега вече можем да видим групата „acl“ със списък на всички таблици, принадлежащи към нея, под „Subject area“ в „Структура на модела“ :

Повторих същата процедура за всички останали таблици с префикс.

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

Същата таблица два пъти в диаграмата? Преки пътища за таблица!

Има около 80 таблици с префикс. След като ги групирах, ми останаха около 120 „диви“ маси. Те са смислени:съхраняват информация за потребители, клиенти, обаждания, срещи и други CRM неща. Това е много информация, която трябва да остане на свобода, така че нека да сортираме тези таблици.

Функцията, която намерих за най-полезна за подреждането на тези таблици, се нарича преки пътища за таблица . Понякога искате да използвате една и съща таблица повече от веднъж в модел. (Защо? За изравняване на модела и избягване на припокриване.) Лесно можем да направим това с помощта на „Копиране“ и „Поставяне като пряк път“ бутони.

Просто изберете таблицата, за която искате да създадете пряк път и щракнете върху „Копиране“ в горната лента с инструменти (или натиснете Ctrl + C ):

За да създадете пряк път, щракнете върху „Поставяне като пряк път“ (или натиснете Ctrl + K ). След това ще се появи нова таблица с контур с точки:

Това не копие на таблицата, но друг екземпляр на оригиналната таблица. Можем да го поставим навсякъде в нашия модел. Използвах екземпляри на една и съща таблица в различни тематични области, за да избегна припокриващи се препратки. Струва си да се спомене, че всеки екземпляр на таблица има присвоено име на тематична област (до името си), докато е вътре в тази тематична област.

Добър пример за това как работи това са users маса. Може да се намери в „Потребители и акаунти“, „Роли“, „Документи“ и други предметни области. Ще видим това по-късно в модела.

Използвам преки пътища за таблици широко, когато създавам тематични области с установени връзки между таблиците. За да видите как работи това, вижте тематичната област „Възможности“, очертана по-долу. Забележете, че всички таблици в рамките на тази тема са наименувани според това правило:{table name} :{subject area name} .

Когато разширим {име на тематична област в панела „Структура на модела“ можем ясно да видим, че съдържа таблици и препратки:

Направих това за следните тематични области:„Обаждания“, „Случаи“, „Кампания“, „Контакти“, „Документи“, „Среща и потенциални клиенти“, „oauth“, „Проекти“, „Перспективи и имейл маркетинг“, „Роли“ и „Потребители и акаунти“. Всички тези области споделят светлосин фон.

Останалите таблици са групирани въз основа на тяхното име и предполагаемо значение:„Имейли“, „Потребители (допълнителни)“ и „Други таблици“. Цветът на фона на тези групи е зададен на светлочервен.

Подреденият модел

Използвах описаните по-горе опции, за да изгладя модела колкото е възможно повече, като групирах таблиците логично. Резултатът е 26 предметни области, някои от които съдържат само таблици, докато други имат таблици и връзки. Нека направим бърз преглед на всяка категория:

Предметни области, които съдържат таблици и връзки:

„Обаждания“, „Кампании“, „Случаи“, „Контакти“, „Документи“, „Срещи и потенциални клиенти“, „Възможности“, „Проекти“, „Перспективи и имейл маркетинг“, „Роли“, „Потребители и акаунти“

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

Тематични области, които съдържат само таблици:

„acl“, „am“, „aod“, „aok“, „aop“, „aor“, „aos“, „aow“, „Emails“, „fp“, „jwg“, „oauth“, „security_groups ”, „Допълнителни потребители”

Това не означава, че тук не съществуват отношения; те просто не са подчертани.

Темата „Други таблици“ е за таблици, които всъщност не се вписват в конкретна група.

Как изглежда моделът?

Пренареденият модел изглежда така:

Очевидно е използвана конвенция за именуване. Ето преглед на указанията, които следвахме:

1. Имената на таблици са предимно множествено число:users , contracts , folders , roles , tasks . Някои имена на таблици са единствено число, като project .
2. Първичният ключ в повечето таблици се нарича просто id и е тип char(36).
3. Когато възникне релация едно към много, външният ключ обикновено се нарича parent_id . (Пример:contacts_audit.parent_id е препратка към contacts.id .)
4. В отношения много към много, „parent_id ” не може да се използва като име за множество колони. Вместо това се използва единствено име на таблица с суфикс „_id“. (Пример:contacts_bugs.bug_id е препратка към bug.id .)
5. Има ситуации, когато една и съща колона се използва като външен ключ за множество таблици. (Пример:calls.parent_id се препраща към колоната с идентификатор във всяка от следните таблици:accounts , bugs , cases , contacts , leads , tasks , opportunities and prospects . Не съм проверил стойностите в базата данни, но предполагам, че в тези таблици няма същите ключови стойности. Тъй като всички са тип char(36), вероятно се използва някаква комбинация от име на таблица и автоматично увеличение. Ще проверим това в следващите статии.)
6. Използваме едни и същи имена за колони, които имат едно и също значение в различни таблици. (Пример:modified_user_id , created_by и assigned_user_id може да се намери в много таблици в модела. Всички те са препратки към users.id .)

Какво следва?

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

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