Личен сайт - 15
Процесът на проектиране на данни може грубо да бъде разделен на два етапа: логическо моделиране и физическо проектиране. Резултатът от първия от тях е така нареченият логически (или концептуален) модел на данни, обикновено изразен чрез диаграма субект-връзка или ER (Entity-Relationship) диаграма, която е представена в една от стандартните нотации, приети за показване на такива диаграми. Резултатът от втория етап е готова база данни или DDL скрипт за нейното създаване. Логическият модел на данни описва фактите и обектите, които трябва да бъдат регистрирани в бъдещата база данни. Основните компоненти на такъв модел са обектите, техните атрибути и връзките между тях. По правило физическият аналог на обект в бъдещата база данни е таблица, а физическият аналог на атрибут е поле на тази таблица. От логическа гледна точка един обект е колекция от обекти или факти от един и същи тип, наречени екземпляри на този обект. Физическият еквивалент на екземпляр обикновено е запис в таблица на база данни. Подобно на записите в релационна СУБД таблица, екземплярите на обекта трябва да бъдат уникални, т.е. пълният набор от техните атрибутни стойности не трябва да се дублира. И точно като полетата в таблица, атрибутите могат да бъдат ключови или неключови. На етапа на логическо проектиране за всеки атрибут обикновено се дефинира приблизителен тип данни (низов, числов, BLOB и т.н.). Спецификацията се извършва на етапа на физическо проектиране, тъй като различните СУБД поддържат различни типове данни и ограничения за тяхната дължина или прецизност.
Моделиране на данни Една от основните части на информационната поддръжка е информационната база, която представлява съвкупност от данни, с коитозадоволяват се информационните потребности на управленските процеси и задачите, които трябва да бъдат решени. Разработването на база данни се извършва чрез моделиране на данни. Целта на моделирането на данни е да предостави на разработчика на IS концептуална схема на база данни под формата на единичен модел или няколко локални модела, които могат да бъдат сравнително лесно картографирани към всяка система от бази данни. Най-разпространеният инструмент за моделиране на данни са диаграми на връзки на обекти (ERD). С помощта на ERD, единиците за съхранение на данни DFD се детайлизират - диаграми и се документират информационните аспекти на бизнес системата, включително идентифицирането на обекти, които са важни за предметната област (субекти), свойствата на тези обекти (атрибути) и техните взаимоотношения с други обекти (релации).
Основни понятия на ERD Субект (Entity) - набор от екземпляри на реални или абстрактни обекти (хора, събития, състояния, идеи, обекти и т.н.), които имат общи атрибути или характеристики. Всеки системен обект може да бъде представен само от един обект, който трябва да бъде уникално идентифициран. В този случай името на обекта трябва да отразява типа или класа на обекта, а не неговия конкретен екземпляр (например ЛЕТИЩЕ, а не ВНУКОВО). Един субект може да се дефинира като обект, събитие или концепция, за която информацията трябва да се съхранява. обектите трябва да имат име с ясно семантично значение, да се наричат съществително в единствено число, да нямат „технически“ имена и да са достатъчно важни, за да бъдат моделирани. Наименуването на обекта в единствено число улеснява четенето на модела по-късно. Всъщност името на даден обект се дава от името на неговия екземпляр. Пример би бил обектът Клиент (но не и Клиенти!) с атрибутите Номер на клиента, Фамилия на клиента и Адрес на клиента. Нана ниво физически модел може да съответства на таблица Customer с колони Customer_number, Customer_name и Customer_address. Всеки обект трябва да бъде напълно дефиниран с текстово описание. Всеки обект може да има произволен брой взаимоотношения с други моделни обекти.
Връзката е наименувана асоциация между два обекта, която е значима за въпросния домейн. Връзката е асоциация между обекти, при която всеки екземпляр на един обект е свързан с произволен (включително нула) брой екземпляри на втория обект и обратно.
Една връзка може да бъде допълнително дефинирана чрез указване на степен или кардиналност (броя екземпляри на дъщерни обекти, които всеки екземпляр на родителския обект може да създаде). В IDEFIX могат да бъдат изразени следните мощности:
- всеки екземпляр на родителски обект може да има нула, един или повече от един екземпляр на дъщерен обект, свързан с него;
- всеки екземпляр на родителски обект трябва да има поне един екземпляр на дъщерен обект, свързан с него;
- всеки екземпляр на родителски обект трябва да има не повече от един екземпляр на дъщерен обект, свързан с него;
- всеки екземпляр на родителски обект е свързан с някакъв фиксиран брой екземпляри на дъщерен обект.
Атрибут - всяка характеристика на обект, която е значима за разглежданата предметна област и е предназначена за квалификация, идентификация, класификация, количествена характеристика или изразяване на състоянието на обекта. Атрибутът представлява тип характеристика или свойство, свързано с набор от реални или абстрактни обекти (хора, места, събития, състояния, идеи, обекти и т.н.). Екземплярът на атрибута еопределена характеристика на отделен елемент от набор. Екземпляр на атрибут се определя от характерния тип и неговата стойност, наречена стойност на атрибута. В диаграмата на обект-връзка атрибутите са свързани с конкретни обекти. По този начин екземпляр на обект трябва да има една дефинирана стойност за свързания атрибут.
От логическа гледна точка връзката е връзка между обекти, която често може да бъде изразена с обикновени фрази, например: „Клиентът прави поръчка“ („Клиент прави поръчка“ - тази фраза може добре да опише връзката, изобразена на Фиг. 1), където съществителните са имената на свързани субекти. По-голямата част от инструментите за проектиране на данни ви позволяват да създавате ER диаграми визуално, изобразявайки обекти и свързвайки ги с връзки с помощта на мишката. Интерфейсът на такива инструменти често е толкова прост, че позволява не само на разработчика, но и на потребителя, който не е програмист, да овладее логическия дизайн на данните, ако участва в проектирането на данни като експерт в предметната област. Обърнете внимание, че на етапа на логическо проектиране е възможно да се опише поведението на СУБД в случай на нарушение на правилата за референтна цялост, дефинирани от тази връзка (например при изтриване на информация за клиента, който е направил поне една поръчка за връзката, показана на фиг. 1).
Някои инструменти за проектиране на данни ви позволяват да съхранявате техните модели в специални хранилища, както и да извършвате колективен дизайн. Често инструментите за проектиране на данни позволяват също така да се присвояват така наречените разширени атрибути на таблици и полета, тоест свойства, свързани с тяхното показване в клиентски приложения, създадени отизползване на някакъв инструмент за разработка, както и генериране на код на приложение за въвеждане и показване на данни.