Напярэдадні старту чарговага патоку па курсе падрыхтавалі невялікі аўтарскі матэрыял з важнымі парадамі па канструяванні БД. Спадзяемся дадзены матэрыял будзе карысны для вас.
Базы даных паўсюль: ад найпростых блогаў і дырэкторый да надзейных інфармацыйных сістэм і буйных сацыяльных сетак. Не настолькі важна, простая ці складаная база даных, наколькі істотна спраектаваць яе правільна. Калі база спраектавана бяздумна і без дакладнага разумення мэты, яна не проста не эфектыўная, але і далейшая праца з базай будзе рэальнай пакутай, непраходным лесам для карыстальнікаў. Вось некалькі парад па канструяванні базы дадзеных, якія дапамогуць стварыць карысны і просты ў выкарыстанні прадукт.
1. Вызначце, для чаго табліца і якая яе структура
Сёння такія метады распрацоўкі, як Scrum або RAD (хуткая распрацоўка прыкладання), дапамагаюць ІТ-камандам хутка распрацоўваць базы дадзеных. Аднак, у пагоні за часам вельмі вялікая спакуса пагрузіцца адразу ў пабудову базы, цьмяна ўяўляючы, у чым жа сама мэта, якія павінны быць канчатковыя вынікі.
Як быццам каманда накіравана на эфектыўную, хуткасную працу, але гэта міраж. Чым далей і хутчэй апускацца ўглыб праекту, тым больш запатрабуецца чакай, каб выявіць і змяніць памылкі ў праекце базы.
Таму першае, што трэба вырашыць - гэта вызначыць мэта для вашай базы дадзеных. Для якога тыпу дадатку распрацоўваецца база? Карыстальнік будзе толькі працаваць з запісамі і трэба надаць увагу транзакцыям ці яго больш цікавіць аналітыка дадзеных? Дзе база павінна быць разгорнута? Ці будзе яна адсочваць паводзіны кліентаў ці ж проста кіраваць адносінамі паміж імі?
Чым раней каманда праектавання адкажа на гэтыя пытанні, тым мякчэй, больш плаўна пройдзе працэс праектавання базы дадзеных.
2. Якія дадзеныя абраць для захоўвання?
Плануйце наперад. Думкі аб тым, што ў будучыні будзе рабіць сайт або сістэма, для якіх праектуецца база даных. Важна выходзіць за рамкі простых патрабаванняў тэхнічнага задання. Толькі калі ласка, не пачынайце разважаць адразу аб усіх магчымых тыпах дадзеных, якія калі-небудзь будзе захоўваць карыстач. Лепш падумайце аб тым, ці змогуць карыстачы пісаць пасты, загружаць дакументы ці фатаграфіі ці абменьвацца паведамленнямі. Калі гэта так, то ў базе неабходна вылучыць месца пад іх.
Працуйце з камандай, дэпартаментам або арганізацыяй, для якіх у будучыні будзе падтрымлівацца праектаваная база. Майце зносіны з людзьмі розных узроўняў, ад спецыялістаў па працы з кліентамі да кіраўнікоў аддзелаў. Так з дапамогай зваротнай сувязі вы атрымаеце дакладнае ўяўленне аб патрабаваннях кампаніі.
Непазбежна запатрабаванні карыстальнікаў у рамках нават аднаго дэпартамента будуць канфліктаваць. Калі вы сутыкнецеся з гэтым, не бойцеся абаперціся на ўласны досвед і знайсці кампраміс, які задаволіць усе бакі і будзе задавальняць канчатковай мэты БД. Будзьце ўпэўненыя: у будучыні вам прыляціць 100500 у карму і гара пячонак.
3. Мадэлюйце дадзеныя з асцярожнасцю
Ёсць некалькі ключавых момантаў, на якія варта звярнуць увагу пры мадэляванні дадзеных. Як мы ўжо раней казалі, ад прызначэння базы дадзеных залежыць, якія метады выкарыстоўваць пры мадэляванні. Калі мы праектуем базу дадзеных для аператыўнай апрацоўкі запісаў (OLTP), іншымі словамі для іх стварэння, рэдагаванні і выдаленні, то выкарыстоўваем мадэляванне транзакцый. Калі ж база дадзеных павінна быць рэляцыйнай, то лепш за ўсё прымяняць шматмернае мадэляванне.
У час мадэлявання будуюцца канцэптуальныя (CDM), фізічныя (PDM) і лагічныя (LDM) мадэлі дадзеных.
Канцэптуальныя мадэлі апісваюць сутнасці і тыпы даных, якія яны ўключаюць, а таксама адносіны паміж імі. Дзяліце вашыя дадзеныя на лагічныя кавалкі - так нашмат прасцей жыць.
Галоўнае - мера, не перашчыруйце.
Калі сутнасць вельмі складана класіфікаваць адным словам ці фразай, то прыйшоў час выкарыстоўваць падтыпы (даччыныя сутнасці).
Калі ж сутнасць вядзе ўласнае жыццё, мае атрыбуты, якія апісваюць яе паводзіны і яе выгляд, а таксама адносіны з іншымі аб'ектамі, то смела можна выкарыстоўваць не толькі падтып, але і супертып (бацькоўская сутнасць).
Калі занядбаць гэтым правілам, іншыя распрацоўнікі заблытаюцца ў вашай мадэлі і не да канца будуць разумець дадзеныя і правілы, як іх збіраць.
Рэалізуюцца канцэптуальныя мадэлі з дапамогай лагічных. Гэтыя мадэлі нібы дарожная карта для праектавання фізічнай базы дадзеных. У лагічнай мадэлі вылучаюцца сутнасці бізнэс-дадзеных, вызначаюцца тыпы дадзеных, статут ключа кіравала, якія рэгулююць адносіны паміж дадзенымі.
Затым Лагічная мадэль дадзеных супастаўляецца з абранай загадзя платформай СКБД (сістэмы кіравання базамі даных) і атрымліваецца Фізічная мадэль. Яна апісвае спосаб фізічнага захоўвання даных.
4. Выкарыстоўвайце прыдатныя тыпы дадзеных
Ужыванне няправільнага тыпу дадзеных можа прывесці да меней дакладных дадзеных, цяжкасцям у аб'яднанні табліц, сінхранізацыі атрыбутаў і да раздзіманні памераў файлаў.
Каб гарантаваць цэласнасць інфармацыі, атрыбут павінен змяшчаць толькі прымальныя для яго тыпы дадзеных. Калі ў базу дадзеных уносіцца ўзрост, то пераканайцеся, што ў калонцы захоўваюцца цэлыя лікі з максімум 3 лічбаў.
Стварайце мінімум пустых слупкоў са значэннем NULL. Калі вы ствараеце ўсе слупкі як NULL, гэта грубая памылка. Калі ж вам патрэбен пусты слупок для выканання канкрэтнай бізнес-функцыі, калі дадзеныя невядомыя ці яшчэ не маюць сэнсу, то смела стварайце. Бо мы ж не можам загадзя запоўніць слупкі "Дата смерці" ці "Дата звальнення", мы ж не прадракальнікі тыкаць пальцам у неба :-).
Большасць софту для мадэлявання (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) дадзеных дазваляе ствараць прататыпы абласцей дадзеных. Так гарантуецца не толькі правільны тып дадзеных, логіка дадатку і добрая прадукцыйнасць, але таксама і абавязковае заданне значэння.
5. Аддайце перавагу натуральнае
Калі вы вырашаеце, які слупок у табліцы абраць у якасці ключа, заўсёды зважайце, якія палі можа рэдагаваць карыстач. Ніколі не выбірайце іх у якасці ключа - дрэнная ідэя. Адбыцца можа ўсё што заўгодна, а вы павінны гарантаваць унікальнасць.
Лепш за ўсё выкарыстоўваць натуральны, або бізнэс, ключ (natural key). Ён мае сэнсавае значэнне, так вы пазбегнеце дублявання ў базе дадзеных.
Калі толькі бізнэс-ключ не ўнікальны (імя, прозвішча, пасада) і паўтараецца ў розных радках табліцы ці ён павінен змяняцца, то першасным ключом варта прызначыць згенераваны штучны, сурагатны ключ (artificial key).
6. Нармалізуйце ў меру
Каб эфектыўна арганізаваць дадзеныя ў БД, неабходна прытрымлівацца набору рэкамендацый і нармалізаваць базу дадзеных. Існуе пяць нармальных форм, якім трэба прытрымлівацца.
З дапамогай нармалізацыі вы пазбегнеце надмернасці і забяспечыце цэласнасць дадзеных, якія выкарыстоўваюцца ў дадатку або на сайце.
Як заўжды, усяго павінна быць у меру, нават нармалізацыі. Калі ў БД занадта шмат табліц з аднолькавымі ўнікальнымі ключамі, тыя вы захапіліся і празмеру нармалізавалі базу дадзеных. Залішняя нармалізацыя негатыўна ўплывае на прадукцыйнасць базы даных.
7. Тэстуйце крыху раней, тэстуйце часцей
Тэставы план і належнае тэсціраванне павінны быць часткай праектавання базы даных.
Лепш за ўсё тэсціраваць базу дадзеных шляхам Continuous Integration (бесперапыннай інтэграцыі). Мадэлюйце сцэнар "Адзін дзень з жыцця базы дадзеных" і правярайце, ці ўсе гранічныя выпадкі апрацоўваюцца, якія ўзаемадзеянні карыстальнікаў верагодныя. Чым раней вы знойдзеце багі, тым больш зэканоміце і чакай, і грошай.
Гэта ўсяго толькі сем парад, з дапамогай якіх вы можаце спраектаваць выдатную базу дадзеных па прадукцыйнасці і эфектыўнасці. Калі будзеце прытрымлівацца ім, вы пазбегнеце большасці галаўных боляў у будучыні. Гэтыя парады - усяго толькі верхавіна айсберга ў мадэляванні базы дадзеных. Існуе вялікая колькасць лайфхакаў. Якімі карыстаецеся вы?
Крыніца: habr.com