Дизайн на база данни
Пълният цикъл на разработка на база данни включва нейния концептуален, логически и физически дизайн.
Концептуален дизайн на база данни
Първата фаза на процеса на проектиране на базата данни е да се създаде концептуален модел на данни за анализираната част от предприятието.
Този подход започва с разработването на модели на данни, които съдържат множество обекти и връзки на високо ниво, след което продължава като поредица от усъвършенствания отгоре надолу на обекти на ниско ниво, връзки и свързани атрибути.
Подходът отгоре надолу е демонстриран в концепцията за модела на същността и връзката (ER-model), най-популярната технология за моделиране на данни на високо ниво, предложена от P. Chen.
При изграждането наобщ концептуален модел на данниима няколко етапа.
■ Извличане на локални представяния, обикновено съответстващи на относително независими данни. Всеки такъв изглед е проектиран като подзадача.
■ Формулиране на обекти, които описват локалната предметна област на проектираната база данни, и описание на атрибутите, които изграждат структурата на всеки обект.
■ Маркирайте ключови атрибути.
■ Спецификация на връзките между обектите. Премахване на излишни връзки.
■ Анализ и добавяне на неключови атрибути.
■ Комбиниране на местни изгледи.
Създаденият концептуален модел на данни на предприятието е източникът на информация за етапа на проектиране на логическа база данни.
Дизайн на логическа база данни
Целта на втората фаза на проектирането на база данни е да се създаде логичен модел на данни за частта от изследваното предприятие.
Логически модел, отразяващ характеристиките на идеята за функциониране на предприятиетомного типове потребители едновременно, се наричаглобален логически модел на данни.
Процесът на проектиране на база данни трябва да се основава на специфичен модел на данни (релационен, мрежов, йерархичен), който се определя от вида на информационната система СУБД, предназначена за внедряване.
Концептуалният и логическият дизайн са итеративни процеси, които включват серия от усъвършенствания, които продължават, докато се получи продуктът, който е най-подходящ за структурата на предприятието.
Дизайн на физическа база данни
Целта на дизайна на този етап е да се създаде описание на модела на база данни, ориентиран към СУБД.
Стъпките в тази стъпка са твърде специфични за различните модели на данни, така че е трудно да се обобщи. Нека се спрем на релационния модел на данни. В този случай физическият дизайн означава:
■ създаване на описание на набор от релационни таблици и ограничения за тях въз основа на информацията, предоставена в глобалния логически модел на данни;
■ определяне на конкретни структури за съхранение на данни и методи за достъп до тях, осигуряващи оптимална работа на системата от бази данни;
■ разработване на средства за защита на създаваната система
Разработка на приложения
Успоредно с проектирането на системата от бази данни се извършва и разработка на приложения. Основните компоненти на този процес са дизайнът на транзакциите и потребителският интерфейс.
Транзакциите представляват събития от реалния свят. Една транзакция може да се състои от няколко операции, но от гледна точка на потребителя тези операции представляват един обект, който превежда базата данни от едно последователно състояние в друго. Изпълнението на сделките разчитана факта, че СУБД е в състояние да гарантира безопасността на промените, направени в базата данни по време на транзакцията и съгласуваността на базата данни доривв случай на повреда.
Дизайнът на транзакция е свързан с дефинирането на:
■ данни, използвани от транзакцията;
■ функционални характеристики на сделката;
■ изходни данни, генерирани от транзакцията;
■ степента на важност и интензивност на използване на сделката.
Дизайн на потребителски интерфейс
Интерфейсът трябва да е удобен за потребителя и да предоставя цялата функционалност, предвидена в спецификациите на потребителските изисквания.
Експертите препоръчват използването на следните основни елементи и техните характеристики при проектирането на потребителски интерфейс:
■ ясни и разбираеми инструкции;
■ логически групи и последователности от полета;
■ визуално привлекателен прозорец на формуляр или поле за отчет;
■ лесно разпознаваеми имена на полета;
■ съгласувана терминология и съкращения;
■ последователно използване на цветовете;
■ визуално разпределение на пространството и границите на полетата за въвеждане на данни;
■ удобни средства за преместване на курсора;
■ средства за коригиране на отделни грешни знаци и цели полета;
■ средства за показване на съобщения за грешка при въвеждане на невалидни стойности;
■ специален избор на незадължителни полета за въвеждане;
G средство за показване на обяснителни съобщения с описание на полетата;
■ средство за показване на съобщение за приключване на попълването на формуляра.
Внедряване
На този етап се извършва физическото внедряване на базата данни и разработените приложения, което позволява на потребителя да формулира необходимите заявки към базата данни и да манипулираданни в базата данни.
Базата данни е описана на езика за дефиниране на данни на избраната СУБД. В резултат на компилирането на неговите команди и тяхното изпълнение се създават схеми и празни файлове на база данни. На същия етап се дефинират всички специфични потребителски изгледи.
Приложните програми се реализират с помощта на езици от трето или четвърто поколение. Той също така създава други компоненти на проекта за приложение, като екрани с менюта, формуляри за въвеждане на данни и отчети.
Изпълнението на това, както и на по-ранните етапи на проектиране на база данни, може да се извърши с помощта на инструменти за компютърно проектиране и създаване на програми, които обикновено се наричат CASE-инструменти (Computer-Aided Software Engineering).
Зареждане на данни
На този етап празните файлове, създадени в съответствие със схемата на базата данни, предназначени за съхраняване на информация, трябва да бъдат попълнени с данни. Попълването на база данни може да продължи по различни начини в зависимост от това дали базата данни е новосъздадена или е предназначена нова база данни да замени старата.
Тестване
Могат да се използват няколко различни стратегии за тестване, за да се оцени пълнотата и коректността на изпълнението на приложение за база данни:
Тестването отгоре надолузапочва на ниво подсистема с модули, които са представени от мъничета, т.е. прости компоненти, които имат същия интерфейс като модула, но без функционален код. Всеки модул от ниско ниво е представен от мъниче. Постепенно всички софтуерни компоненти се заменят с действителен код и се тестват отново след всяка подмяна.
Тестването нагоресе извършва в посока, обратна на тестването надолу по веригата. Започва с тестване на най-ниските модулинива на системната йерархия, продължава на по-високи нива и завършва на най-високо ниво.
Тестване на нишкисе извършва при тестване на системи в реално време, които обикновено се състоят от голям брой взаимодействащи процеси, управлявани от прекъсвания. Стратегията за тестване на нишки се фокусира върху наблюдението на отделни процеси.
Стратегиятаинтензивно тестванечесто включва поредица от тестове с постепенно нарастващо натоварване и продължава, докато системата се повреди.