Методология infological дизайн на база данни

(Вж. Проектирането цел infological база данни, семантика на домейн, infological модел домейн, същността на семантичен подход към проектиране Infological параграф 15).

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

Идеен проект (Infological) - създаването на концептуална гледна точка на базата данни, включително и определянето на най-важните видове лица и връзките между тях.

Логически Дизайн - конвертиране на концептуалната на логическата структура на базата данни, включително дизайна на отношенията.

Физическо дизайн - решението за това как логическия модел ще бъде физически реализирани (с маси) в базата данни, създадени с помощта на избраната база данни.

Design методология - структуриран подход, който включва използването на специализирани процедури, техники, инструменти, документация, и има за цел да подпомага и улеснява процеса на проектиране.

Концептуален дизайн на база данни - Процедура за проектиране на информационен модел предприятие, което е независимо от каквито и да било физически условия за изпълнение.

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

Етапи на идеен проект на базата данни:

- Определяне на видовете юридически лица.

- Определяне на видовете връзки.

- Дефиниране на атрибути и да ги свържете с типовете лица и взаимоотношения.

- Дефиниране на атрибути домейни.

- Дефиниране на атрибути, които са потенциални и първични ключове.

- Специалност или обобщение на автономните типове (незадължителна стъпка).

- Създаване на "същност- отношения" диаграма.

- Дискусия на местните концептуални модели на данните за крайните потребители.

Целта - да се създаде местен концептуален модел на корпоративни данни на базата на идеята за предметната област на всеки тип потребител.

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

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

След изолиране на следващия етап на развитие на тези субекти ще бъде създаването на връзки между тях.

Установяване на връзки, които ще се проведат в модела, за да се създаде, трябва да се определи кардиналността на всеки от тях. Всяка връзка може да има всяка кардиналност "12:59" (1: 1) или "един към много" (л М), или "много към много" (М: M). (Виж раздел 5.2.1). Ако знаете, че конкретните стойности на кардиналността или поне горната или долната граница на тези стойности, необходимата информация, за да се определи документацията. Освен това трябва да се анализира степента на участие на всеки един от обектите в по-конкретен вид комуникация. Степента на участие може да бъде или пълна (общо) или частни.

Работата е много опростен, ако сложната система в допълнение към широка текстово описание е визуално представяне. Да представлява субекти и връзките между тях са често използвани лице-връзка диаграма (ER диаграма).

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

Задачата на следващата фаза на изграждане на местен модел концептуална данни е да се определи атрибутите на домейн за всички атрибути, присъстващи в този модел. Домейн е някакъв набор от стойности на елементите, от които са избрани за присвояване на стойности на един или повече атрибути. А пълно модел данни трябва да включва области за всеки от атрибутите, присъстващи в него. Домейните не трябва да съдържат следната информация:

- настроен на разрешените стойности за атрибута;

- информация за размера и формата на всяка от областите на атрибутите.

В следващия етап се задава за всеки ключов лице кандидат (или ключове), следвани от избор на първичния ключ.

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

- Използвайте потенциал ключ с минимален набор от атрибути.

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

- Изберете ключа един кандидат, който има минимален шанс от загуба на уникалността на ценности в бъдеще.

- Използвайте потенциални ключови стойности, които са на минимална дължина (в случая на атрибутите на текста).

- Спрете избора си на потенциален ключов фактор за което е най-лесният начин да се работи (от гледна точка на потребителя на).

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

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

19 Целта на логическото проектиране на базата данни, правилата генерират релационни таблици за прости връзки между лица и отношения като "спецификация / обобщение"

Методология на проектирането на базата данни се състои от три основни фази на развитие: идеен, логически и физически дизайн.

Логически Database Design е процесът на изграждане на модел на информационна структура на компанията се извършва в съответствие с избраната схема за организиране на информацията (например, релационна). Въпреки това, за да създадете логически модел не зависи от характеристиките на конкретните СУБД и други физически условия на изпълнение.

Според основните етапи предложената методология на логическо проектиране на релационни бази данни тип са създаване и проверка на местните логически модел на данните постъпки за индивидуални потребители (стъпка 2); Строителство и проверка на глобален модел логично данни на предприятието (стъпка 3).

Действията, необходими за конвертиране на концептуалния модел на данните в модела логично данни включват: премахване на облигации на M: N, премахването на сложни връзки, отстраняване на рекурсивни отношения, премахване на отношенията с атрибутите, изтриване няколко атрибута повторна проверка облигации на 1: 1 и отстраняване на излишни връзки ,

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

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

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

2. Директно към диаграми ER покаже целия път за достъп до данните, необходими за извършване на сделката.

Целостта на данните Ограничения са ограничения, които са вписани в стаята, за да се предотврати противоречиви данни. Има пет вида ограничения: обвързващи ограничения данни за атрибутите домейн цялост лице, референтна цялостност и изискванията на предприятието.

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

Има няколко стратегии за работа с опити за изтриване на ред от родителски отношения, което се нарича един или няколко реда дете отношения: не се предприемат действия, КАСКАДА, SET NULL, SET DEFAULT и NO CHECK.

Ограничения на предприятието, понякога се нарича бизнес правила. Например, предприятието може да се ограничи до актуализиране на правилата на бизнеса, заложени в изискванията за ръчно изпълнение на определени видове сделки.

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