Основи на дизайна на бази данни, моделиране на слоеве

Жизнен цикъл на базата данни : проектиране - внедряване - внедряване - работа.

При разработването на база данни обикновено се разграничават няколко нива на моделиране, с помощта на които се извършва преход от предметната област към конкретна реализация на базата данни с помощта на конкретна СУБД. Следнитенива могат да бъдат разграничени:

Самата предметна област
Модел на домейн
Логически модел на данни
Физически модел на данни
Собствена база данни и приложения

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

Моделът на домейн. Моделът на домейн е нашето знание за домейна. Знанието може да бъде както под формата на неформално знание в мозъка на експерт, така и изразено официално с помощта на всякакви средства. Като такива инструменти могат да служат текстови описания на предметната област, набори от длъжностни характеристики, правила за правене на бизнес в компанията и др. Опитът показваче текстовият начин за представяне на домейн модела е изключително неефективен. Много по-информативни и полезни при разработването на бази данни са описанията на предметната област, направени с помощта на специализирани графични обозначения. Има голям брой методи за описание на предметната област. Сред най-известните са техниката за структурен анализ SADT и базираната на нея IDEF0, диаграмите на потока от данни Gein-Sarson, техниката за обектно-ориентиран анализ на UML и др. Моделът на домейн по-скоро описва процесите, протичащи в предметната област и данните, използвани от тези процеси. Успехът на по-нататъшното развитие на приложението зависи от това колко правилно е моделирана предметната област.

Логически модел на данни. На следващото по-ниско ниво е логическият модел на данните на предметната област.

Логическият модел описва понятията на предметната област, тяхната връзка, както и ограниченията върху данните, наложени от предметната област. Примери за понятия са "служител", "отдел", "проект", "заплата". Примери за връзки между понятия - "един служител е посочен в точно един отдел", "един служител може да изпълнява няколко проекта", "няколко служители могат да работят по един проект". Примери за ограничения - "възрастта на служителя е не по-малко от 16 и не повече от 60 години."

Логическият модел на данните е първоначалният прототип на бъдещата база данни. Логическият модел е изграден от гледна точка на информационни единици, но без връзка с конкретна СУБД. Освен това логическият модел на данни не трябва да бъде изразен чрез релационния модел на данни. Основното средство за разработване на логически модел на данни в момента са различни версии на ER-диаграми (Entity-Relationship, entity-relationship diagrams).Връзка). Същият ER модел може да бъде преобразуван в релационен модел на данни, модел на данни за йерархична и мрежова СУБД или пост-релационен модел на данни. Въпреки това, тъй като Тъй като разглеждаме релационна СУБД, можем да приемем, че логическият модел на данни за нас е формулиран от гледна точка на релационния модел на данни.

Решенията, взети на предишното ниво, при разработването на модел на домейн, определят някои граници, в които може да се разработи логически модел на данни, и в тези граници могат да се вземат различни решения. Например моделът на домейн за складово счетоводство съдържа понятията "склад", "фактура", "стока". Когато разработвате подходящ релационен модел, тези термини трябва да се използват, но има много различни начини за имплементирането му - можете да създадете една връзка, в която ще има "склад", "фактура", "стоки" като атрибути, или можете да създадете три отделни връзки, по една за всяка концепция.

При проектирането на логически модел на данни възникват въпроси: добре ли са проектирани връзките? Отразяват ли правилно модела на домейна и следователно самия домейн?

Физическият модел на данни. На още по-ниско ниво е физическият модел на данни. Физическият модел на данни описва данните с помощта на определена СУБД. Ще приемем, че физическият модел на данни е реализиран посредством релационна СУБД, въпреки че, както бе споменато по-горе, това не е необходимо. Релациите, разработени на етапа на формиране на логически модел на данни, се преобразуват в таблици, атрибутите стават колони от таблици, създават се уникални индекси за ключови атрибути, домейните се преобразуват в типове данни, приети в определена СУБД.

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

При проектирането на физически модел на данни възникват въпроси: добре ли са проектирани таблиците? Правилни ли са индексите? Колко код под формата на тригери и съхранени процедури трябва да бъде разработен, за да се поддържа целостта на данните?

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

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

По този начин е ясно, че решенията, взети на всеки етап от моделирането и развитието на базата данни, ще повлияят допълнителноетапи. Следователно вземането на правилни решения в ранните етапи на моделирането играе специална роля.