Course All lectures for BG purposes - Lecture: Ключови стъпки за проектиране на база данни

2.1. Концептуален дизайн

Проектирането на база данни се извършва на три етапа:

концептуален дизайн;
логически дизайн;
физически дизайн.

Целта на фазата на концептуалния дизайн е да се създаде концептуален модел на данни въз основа на идеите на потребителите за предметната област. За постигането му се извършват серия от последователни proceduresи. Пример за (концептуална) схема на обект:

1. Дефиниция на субекти и тяхната documentация. За идентифициране на обекти се дефинират обекти, които съществуват независимо от другите. Такива обекти са същности. На всеки обект се дава смислено име, което потребителите могат да разберат. Имената и описанията на обектите се въвеждат в речника на данните. Ако е възможно, се задава очакваният брой екземпляри на всеки обект.

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

3. Създаване на ER-модел на предметната област. ER диаграмите се използват за представяне на обекти и връзки между тях. Въз основа на тях се създава единен визуален образ на моделираната предметна област - ER-моделът на предметната област.

4. Дефиниране на атрибути и тяхното documentиране. Разкриват се всички атрибути, които описват обектите на създадения ER модел. На всеки атрибут се дава смислено име, което потребителите могат да разберат. Следната информация се съхранява в речника на данните за всеки атрибут:

име и описание на атрибута;
вид и измерение на ценностите;
стойността по подразбиране за атрибута (ако има такава);
дали атрибутът може да има NULL стойности;
дали атрибутът е съставен и ако е така, от Howви прости атрибути се състои. Например атрибутът „Пълно име на клиента“ може да се състои от прости атрибути „Surname“, „Име“, „Бащино име“ or може да бъде прост, съдържащ единични стойности, като „Сидорски Евгений Михайлович“. Ако потребителят не се нуждае от достъп до отделни елементи на "Име", тогава атрибутът се представя като прост;
дали атрибутът се изчислява и ако да, How се изчисляват стойностите му.

5. Дефиниране на стойности на атрибути и тяхната documentация. За всеки атрибут на обект, участващ в ER модела, се определя набор от валидни стойности и му се присвоява име. Например атрибутът „Тип сметка“ може да има само стойностите „депозит“, „текущ“, „при поискване“, „картова сметка“. Записите в речника на данните, свързани с атрибутите, се актуализират с имената на наборите от стойности на атрибути.

6. Дефиниране на първични ключове за обекти и тяхната documentация. Тази стъпка се ръководи от дефиницията на първичен ключ - като атрибут or набор от атрибути на обект, който позволява уникална идентификация на неговите екземпляри. Информацията за първичния ключ се поставя в речника на данните.

7. Обсъждане на концептуалния модел на данни с крайни потребители. Концептуалният модел на данни е представен от ER модел с придружаваща documentация, съдържаща описание на разработения модел на данни. Ако бъдат открити несъответствия в домейна, тогава се правят промени в модела, докато потребителите потвърдят, че предложеният от тях модел адекватно отразява техните лични виждания.

2.2 Логически дизайн

Целта на етапа на логически дизайн е да трансформира концептуалния модел, базиран на избрания модел на данни, в логически модел, който е независим от характеристиките на СУБД, използвана по-късно за физическото внедряване на базата данни. За постигането му се извършват следните proceduresи.

Пример за логическа схема на база данни.

1. Избор на модел на данни. Най-често се избира релационен модел на данни поради яснотата на табличното представяне на данните и удобството при работа с тях.

2. Дефиниране на набор от таблици на базата на ER модела и documentирането им. Създава се table за всеки обект на ER модела. Името на обекта е името на tableта. Връзките между таблиците се установяват чрез механизма на първичните и външните ключове. Структурите на таблиците и установените връзки между тях са documentирани.

3. Нормализиране на таблици. За да извърши правилно нормализацията, дизайнерът трябва да разбере задълбочено семантиката и моделите на използване на данните. На тази стъпка той проверява коректността на структурата на таблиците, създадени в предишната стъпка, като прилага към тях proceduresата за нормализиране. Състои се в привеждане на всяка една от масите поне до 3-та НФ. В резултат на нормализацията се получава много гъвкав дизайн на база данни, което улеснява извършването на необходимите разширения към нея.

4. Проверка на логическия модел на данни за възможността за извършване на всички транзакции, предоставени от потребителите. Транзакцията е набор от действия, извършвани от отделен потребител or приложна програма за промяна на съдържанието на база данни. И така, пример за транзакция в проекта BANK може да бъде прехвърлянето на правото на управление на сметките на определен клиент на друг клиент. В този случай ще трябва да се направят няколко промени в базата данни наведнъж. Ако компютър се срине по време на транзакция, базата данни ще бъде в непоследователно състояние, тъй като някои промени вече са напequalsи, а други не. Следователно всички частични промени трябва да бъдат отменени, за да се върне базата данни в нейното предишно последователно състояние.

Списъкът с транзакции се определя от действията на потребителите в тематичната област. Използвайки ER модела, речника на данните и установените връзки между първичните и външните ключове, се прави опит за извършване на всички необходими операции за достъп до данни ръчно. Ако някоя ръчна операция е неуспешна, тогава компorраният логически модел на данни е неадекватен и съдържа грешки, които трябва да бъдат отстранени. Може би те са свързани с пропуск в модела на обект, връзка or атрибут.

5. Определяне на изискванията за поддръжка на целостта на данните и тяхното documentиране. Тези изисквания са ограничения, които се въвеждат, за да се предотврати въвеждането на противоречиви данни в базата данни. На тази стъпка се разглеждат проблемите с целостта на данните, без да се вземат предвид специфичните аспекти на нейното изпълнение. Трябва да се имат предвид следните видове ограничения:

необходими данни. Откриване дали има атрибути, които не могат да имат NULL стойности;
ограничения върху стойностите на атрибутите. Дефинирани са валидни стойности за атрибути;
цялост на обекта. Постига се, ако първичният ключ на обекта не съдържа NULL стойности;
референтна цялост. Разбираемо е, че стойността на външния ключ трябва да присъства в първичния ключ на един от редовете на tableта за родителския обект;
ограничения, наложени от бизнес правилата. Например, в случая на проекта BANK може да се приеме правило, което забранява на клиента да управлява, да речем, повече от три сметки.

Информация за всички установени ограничения за целостта на данните се поставя в речника на данните.

6. Създаване на окончателната version на логическия модел на данните и обсъждане с потребителите. Тази стъпка подготвя окончателната version на ER модела, който представлява логическия модел на данни. Самият модел и актуализираната documentация, включително речника на данните и схемата за връзка на релационната table, са представени за преглед и анализ от потребителите, които трябва да гарантират, че той точно представя предметната област.

2.3. Физически дизайн

Целта на етапа на физическо проектиране е да се опише конкретно изпълнение на база данни, разположена във външната памет на компютъра. Това е описание на структурата за съхранение на данни и ефективните методи за достъп до данните от базата данни. При логическия дизайн те отговарят на въпроса – Howво трябва да се направи, а при физическия дизайн – избира се начин How да се направи. Процедурите по физическо проектиране са Howто следва.

1. Проектиране на таблици на база данни с помощта на избраната СУБД. Избрана е релационна СУБД, която да се използва за създаване на база данни, хоствана на машинен носител. Неговата функционалност за проектиране на маси е дълбоко проучена. След това се извършва проектирането на таблици и схемата на тяхното свързване в СУБД среда. Изготвеният проект за база данни е описан в придружаващата documentация.

2. Внедряване на бизнес правила в средата на избраната СУБД. Актуализирането на информация в таблици може да бъде ограничено от бизнес правила. Начинът на тяхното изпълнение зависи от избраната СУБД. Някои системи за изпълнение на изискванията на предметната област предлагат повече функции, други по-малко. В някои системи изобщо няма поддръжка за прилагане на бизнес правила. В този случай applicationsта са разработени за прилагане на техните ограничения.

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

3. Проектиране на физическата организация на базата данни. Тази стъпка избира най-добрата файлова организация за таблиците. Транзакциите, които ще бъдат извършени в проектираната база данни, са идентифицирани и най-важните от тях са подчертани. Анализира се пропускателната способност на транзакциите - броят транзакции, които могат да бъдат обработени в даден интервал от време, и времето за реакция - периодът от време, необходим за извършване на една транзакция. Те се стремят да увеличат пропускателната способност на транзакциите и да намалят времето за реакция.

Въз основа на тези показатели се вземат решения за оптимизиране на производителността на базата данни чрез дефиниране на индекси в таблици, които ускоряват избора на данни от базата данни or чрез намаляване на изискванията за нивото на нормализиране на tableта. Оценява се дисковото пространство, необходимо за разполагане на създадената база данни. Стремете се да го сведете до минимум.

Взетите решения по горните въпроси се documentират.

4. Разработване на стратегия за защита на база данни. Базата данни е ценен корпоративен ресурс и се обръща голямо внимание на нейната защита. За да направят това, дизайнерите трябва да имат пълно и ясно разбиране за всички защити, предоставени от избраната СУБД.

5. Организиране на мониторинг на функционирането на базата данни и нейното настройване. След създаването на физическия проект на базата данни се организира непрекъснат мониторинг на нейното функциониране. Получената информация за нивото на производителност на базата данни се използва за нейната настройка. За това се включват и средствата на избраната СУБД.

Решенията за извършване на Howвито и да е промени във функционираща база данни трябва да се обмислят и претеглят внимателно.