НОВ БЪЛГАРСКИ УНИВЕРСИТЕТ

РЕДОВНО ОБУЧЕНИЕ

CSCB695 Самостоятелна работа по разпределени и обектно – ориентирани бази от данни

ТЕМА

Представяне и описание на конкретна методология за проектиране на база от данни чрез релационен синтез

Програма : Софтуерни технологии в интернет

Курс : CSCB695 Самостоятелна работа по разпределени и обектно – ориентирани бази от данни

Преподавател : доц. д-р Юлиана Пенева

Студент : ******************************

ПРОЕКТИРАНЕ НА БАЗА ОТ ДАННИ ЧРЕЗ РЕЛАЦИОНЕН СИНТЕЗ

1. Увод

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

За подпомагане на управлението на бизнеса се налага съхраняването на големи по обеми данни. За да бъдат полезни, данните трябва да се обработят по начин, който да ги направи полезни и смислени. Данните, които са обработени и структурирани с цел полезност и смисленост за бизнеса се наричат информация. И точно тук, при структурирането на данните в информация се намесва „проектирането на бази от данни”.

Данните са структурирани йерархично. Базовият елемент е „символът”. Съвкупността от символи формира „поле”. Множество от свързани помежду си полета, формира „запис”. Множеството от еднотипни записи формира „релация”/”таблица”. В контекста на базите данни имаме обекти, техните атрибути и релации помежду им. Обекта отговаря на отделна самостоятелна част от обкръжаващата ни действителност (понятие, събитие, факт), която се съхранява в базата данни. Характеристиките на обектите се наричат атрибути. Връзките между обектите се наричат „връзки”(relationships). Практиката е наложила Unified Modeling Language (UML) като ефективен и разбираем начин за изразяване на обектно-ориентирания дизайн. Най-общо UML представлява фамилия от графични нотации, обединени от общ мета модел. Затова с цел онагледяване на описваните концепции ще използваме UML графики.

2. Общ преглед на стратегиите при проектирането на релационни бази от данни.

Съществуват две основни стратегии при проектирането на бази от данни. Основната стратегия е:

I. „Отгоре – надолу” ( top-down)

Тя се състои от следните стъпки:

  • Проектиране на концептуалната схема на базата, например чрез E-R модела
  • Трансформиране на концептуалната схема в логическа схема на базата данни
  • Анализ на отношенията с помощта на функционалните зависимости, като се прилагат четирите неформални мерки за качество:
  • Неформални мерки на качеството при проектиране:
    • Семантика на атрибутите:
      • Моделиране на обекти и връзки в различни отношения
      • Представяне на единствен тип обект или връзка в едно отношение
      • Използване на мнемонични имена на атрибути и релационни схеми
    • Излишество в данните и аномалии при обновяване
      • Елиминиране на повтарящите се данни

(например чрез изнасянето им в нова релация)

  • Нулеви стойности в кортежите
    • Да се избягва използването на атрибути в релационната схема, чийто стойности са в по-голямат си част „null”
      (например чрез изнасянето им в нова релация)
    • Генериране на фалшиви кортежи ( допълнителни (spurious) от изходното състояние)
      • Не трябва в отделните схеми да съществуват еднакви атрибути, които не са ключове (ПК (първичен ключ) или ВК (вторичен ключ)); Наличието на еднакви атрибути, които не са ключове, в две различни схеми, позволява дефинирането на условие за съединение в резултат на което се получават фалшиви (допълнителни) кортежи
  • Функционални зависимости
    • Първа нормална форма
      • Домейните включват само атомарни (неделими) стойности
      • Стойностите на всеки атрибут във всеки кортеж са неделими
    • Втора нормална форма
      • Всеки атрибут, който не участва в главния ключ, е пълно функционално зависим от главния ключ ПК
    • Трета нормална форма
      • Да е във 2 НФ и никой от атрибутите, който не участва в главния ключ, не е транзитивно зависим от него (ПК)
  • Провеждане на нормализация до трета нормална форма, за да се избегнат транзитивните и частичните функционални зависимости
    • Неудовлетворителните релационни схеми се декомпозират чрез разбиване на атрибутите им и групирането им в по-малки релационни схеми, които удовлетворяват желаната нормална форма (обикновено 3 НФ)

II. “Отдолу-нагоре” (bottom-up), или „релационнен синтез”.

При „релационния синтез”, схемата на базата се разглежда като съвкупност о функционални и други типове зависимости, задавани върху атрибутите от проектанта на базата. След дефинирането на зависимостите, с помощта на алгоритъм за нормализация се синтезират релационни схеми в трета нормална форма ( 3 НФ ) чрез групиране на подходящите атрибути. Всяка релационна схема трябва да съдържа логическо смислено множество от атрибути. Схемите които не са в 3 НФ, се декомпозират. Този метод се реализира чрез следните стъпки:

  • Спецификация на зависимостите върху атрибутите на базата
  • Синтезиране на една голяма релационна схема, съдържаща всички атрибути (т.нар. универсална схема), като имената на атрибутите в нея са уникални
  • Декомпозиция на универсалната схема във отделни релационни схеми, като се спазва:
    • Всеки атрибут да попадне в схема
    • Да се запазят функционалните зависимости
    • Да няма фалшиви кортежи
      • релационните схеми да са в 3 НФ

3. Защо и кога стратегията „релационнен синтез”

В общи линии проблемите при стратегията „релационнен синтез”, могат да се обобщят както следва:

  • Проектантът на базата от данни трябва да зададе „всички” функционални зависимости между атрибутите. Тази задача не е лесна, защото пропускането на зависимости води до лош проект.
  • Алгоритмите за създаване на релационн схема в 3 НФ не са детерминирани, защото:
    • Търси се минималното покритие на множество от функционални зависимости, а обикновено съществуват повече от едно минимално покритие и могат да се получат различни проекти
    • Съществен е редът на прилагане на функционалните зависимости, и могат да се получат проекти с различно качество

В общи линии това води до по-ограниченото използване на стратегията „релационнен синтез” спрямо алтернативната стратегия „отгоре-надолу”.

Тогава може ли да се каже „методологията релационнен синтез е по некачествена от нейната алтернатива” и да се отхвърли практическото й използване ? Определено „не” ! И причината не е в сравнението  или в методологията на сравнение, а в конкретния контекст на приложение на методологията. Ако желаете да засадите дръвче в градината си бихте използвали традиционната лопата, но за да изкопаете основите на новата си къща, бихте си наели багер. И сравнението между лопатата и багера е напълно неуместно, в определени конкретни ситуации едното е по-ефективно, а в други – другото. И така кога „релационния синтез” проявява силата си ?

Майкъл Х. Ернандес в книгата си „Проектиране на база от данни” е описал практическа методология за прилагането на стратегията „отдолу-нагоре / релационнен синтез”. В голяма част от реалните проекти, поради силното навлизане на информационните технологии и настъпилата всеобща криза, на практика в малките фирми няма сертифициран специалист по разработка на дизайн на съответните релационни бази от данни. Това принуждава разработчиците на софтуер (програмистите) да разработват дизайна на базата от данни за клиентите си. А това води до лош дизайн. Научаването на релационния модел, предложен от Код през 1970 година не е тривиална задача. Но изучаването и прилагането на конкретна практически изчистена методология е по силите дори на обикновен програмист. И така, по добре е да имате добър дизайн, отколкото лош, след като не можете да имате много добър дизайн на база от данни J

4. Общо представяне на методологията на Майкъл Х. Ернандес за проектиране на база от данни, чрез стратегията „релационнен синтез”.

  • Провеждане на интервюта
    • Дефиниране на предназначението

(цел на базата)

  • Дефиниране на задачите

(конкретна функционалност)

  • Определяне на теми

(човек, място, предмет, събитие)

  • Определяне на характеристики

(на темите)

  • Информационни изисквания

(отчети – съществуващи в момента, или желани в бъдещето)

  • Съставяне на пълен спъсък с полета
    • Предварителен списък с полета
    • Списък с изчислени полета
    • Създаване на структурата на таблиците
      • Дефиниране на предварителен списък с таблици
        (използване на списъка с теми и формулирани задачи)
      • Дефиниране на окончателен списък с таблици
        (изчистване на имената на таблиците)
      • Асоцииране на полета с всяка таблица
      • Изчистване на полетата
        (подобряване на имената на полетата, използване на идеалното поле, премахване на съставните полета и полетата с множество стойности)
      • Изчистване на структурата на таблиците
        (изчистване на излишните данни и дублиращите се полета, използване на идеалната таблица, създаване на подтаблици)
      • Създаване на ключове за всяка таблица
        (кандидат ключове, първични ключове, алтернативни ключове)
      • Спецификации на поле
        (общи, физически и логически характеристики)
      • Създаване на релациите между таблиците
        • Определяне на съществуващите релации
        • Създаване на релациите
          (тип едно към едно, тип едно към много, тип много към много, тип рекурсивни релации)
        • Изчистване на външните ключове
          (характеристика на външния ключ)
        • Определяне на характеристиките на релациите
          (дефиниране на правила за изтриване, определяне на тип на участие, определяне на степента на участие)

5. Провеждане на итервюта.

Интервютата са полезни поради следните причини:

  • Осигуряват подробности за събраните образци от информационни документи (документи и справки)
  • Осигуряват информация за начина на използване на данните
  • Помагат при дефинирането на таблиците и полетата
  • Помагат при дефинирането на бъдещи инфорамционни изисквания

Основните техники за провеждане на интервю са:

  • Задаване на въпроси
    Бихте могли да започнете с въпроса:
    „Как бихте описали всекидневната си работа ?”
  • Определяне на теми
    Когато задавате отворен въпрос, определяйте темите, подсказани в отговора на въпроса. Можете да откривате теми, като търсите съществителните в изреченията на отговора.
  • Определяне на характеристики
    След като сте определили темите, започнете да задавате конкретни въпроси за да получите описание на темите. Докато откривате подходящите съществителни в отговора, ги изброявайте на лист хартия, това се превръща в списък с характеристики. Използвайте отделен лист хартия за списъка с характеристики. Не записвайте темите и характеристиките на един и същ лист !
  • Преглед на образците
    Прегледайте събраните образци на документи и справки, използвани във фирмата, и им определете темите и характеристиките.
  • Определяне на информационните изисквания
    Разпитайте и определете текущите и бъдещите информационни изисквания към системата. Отново извлечете темите и характеристиките от отговорите.

6. Съставяне на пълен списък с полета

  • Съберете в единен списък с полета, всички характеристики
  • Премахнете елементите с едно и също име
    Внимание ! Често пъти ще откривате, че дублиращото име представлява същия тип характеристика, но на друга тема. В този случай преименувайте полето, за да отразява съответствието му със съответната схема. Например „Име” -> „Име на служител”, „Име на клиент” и т.н.
  • Премахнете елементите, представящи една и съща характеристика
    Например „Продукт номер”, „Продукт пореден номер” -> „Продукт номер”.
  • Уверете се, че елементите представляват „характеристики”
  • Премахнете всяко изчислено поле, като го включите в отделен списък с изчислени полета
    Пример за такива полета: „Средна възраст”, „Общ брои клиенти” …

7. Създаване на структура на таблиците

  • Премахнете елементите с едно и също име
    Внимание ! Ако дублиращите се елементи представят различни теми, преименувайте всеки елемент, така че точно да определя темата която представя
  • Премахнете елементите, представящи една и съща тема
  • Дефинирайте окончателния списък с таблици
    Този нов списък включва два елемента, които не присъстват в предварителния списък от таблици. Това са: „тип на таблицата” и „описание на таблицата”. Типовете таблици биват:

    • Данни – представя тема
    • Свързваща таблица – създава връзка между две таблици
    • Подтаблица – съдържа полета, които са свързани с определена таблица за данни и описва темата за таблицата за данни по много специфичен начин
    • Таблица за валидиране – съдържа данни за валидиране на таблицата с данни

Описанието на таблицата осигурява кратка и ясна дефиниция на темата, представяна от таблицата

  • Задайте конкретни имена на таблиците
    Именуването на таблиците е по-сложно, отколкото изглежда. Спазвайте следните общи правила при именуването:

    • Създавайте уникално, описателно име, което има смисъл за цялата организация
    • Името точно, ясно и недвусмислено определя темата на таблицата
    • Използвайте минималния необходим брой от думи
    • Не използвайте думи, означаващи физически характеристики Например „Запис на поръчка” вероятно означава „Поръчка”, „Клиент”.
    • Не използвайте акроними и съкращения
    • Не използвайте характерни ограничаващи думи. Например „Служители от София”, тъй като това би ограничило въвежданите данни и наложило използването на дублиращи структури от таблици.
    • Всяко име трябва да определя точно една тема
    • Използвайте характеристиките на идеалната таблица
      • Представя една единствена тема, която може да бъде обект или събитие
      • Има първичен ключ
      • Не съдържа съставни (от няколко полета) полета и полета с множество стойности
      • Не съдържа изчислени полета
      • Не съдържа дублиращи се полета
        (изключение е само за външните ключове)
      • Съдържа минимално количество излишни данни
      • Асоциирайте полетата с конкретните таблици
        Обходете всички таблици и им присвоете подходящите полета от списъка с полета
      • Задайте конкретни имена на полетата
        Спазвайте следните общи принципи:

        • Създайте уникално, описателно име, което има смисъл за цялата организация. Името е уникално за цялата база от данни.
        • Името точно, ясно и недвусмисленно определя характеристиката, която даденото поле представлява
        • Използвайте минимален брой думи
        • Не използвайте акроними, съкращения разумно
        • Не използвайте двузначни думи
        • Всяко име да представлява само една характеристика
        • Използвайте характеристиките на идеалното поле
          • Представя отделна характеристика на темата на таблицата
          • Съдържа само една единствена стойност
          • Не може да бъде разделено на отделни части
          • Не съдържа изчислени или конкатенирани стойности
          • Името е уникално за цялата база данни
          • Запазва свойствата си, когато присъства в повече от една таблица
          • Съставното поле се декомпозира до съставните си полета
          • Поле с множество стойности се изнася в отделна таблица за данни, с ключ към основната
          • Дублиращите се полета са разновидност на поле с множество стойности. Изнася се в отделна таблица за данни, с ключ към основната.
          • Полета с преобладаваща стойност „NULL” се изнасят в отделна подтаблица за данни, с ключ към основната. Подтаблицата представлява подчинена тема на основната таблица.

8. Създаване на релациите между таблиците

  • Ключовете са решаващи за структурата на таблиците поради следните причини:
    • Те гарантират, че всеки запис в таблицата е точно идентифициран. Това се постига чрез първичния ключ.
    • Те установяват и налагат различни типове цялост. Това се постига чрез външните ключове и възможността за съдържане на стойност „NULL”.
    • Те се използват за създаване на релации между таблиците. Това се постига чрез различните видове съединения между таблиците (“INNER”, “LEFT” или „RIGHT” JOIN).
    • Създаване на ключове за всяка таблица
      • Кандидат ключове
        Това е поле или група от полета които определят еднозначно всяка инстанция (ред) на таблицата. Характеристиките на кандидат ключа са:

        • Не може да бъде съставно поле
        • Трябва да съдържа уникални стойности
        • Не може да съдържа „NULL”
        • Стойността му не трябва да нарушава сигурността (т.е. не трябва да е например ЕГН или парола)
        • Стойноста му трябва да е задължителна
        • Трябва да се състои от минимален брой полета
        • Стойността му трябва уникално и пряко да определя(идентифирца) всяко поле в записа
        • Не трябва да се променя
        • Изкуствен кандидат ключ
          Когато определите, че таблицата не съдържа кандидат ключ, можете да създадете и използвате изкуствен такъв. Обикновено това е поле от тип цяло число, с ограничение “not null”.
        • Първични ключове
          • Полето на първичния ключ идентифицира пряко таблицата в структурата на базата данни и помага да се установят релации с другите таблици.
          • Стойността на първичния ключ идентифицира уникално даден запис в рамките на таблицата и представя този запис в цялата база данни. Също така предпазва от дублиране на запис в таблицата.
          • Отговаря на същите характеристики, както и кандидат ключовете
          • Ако имате прост (от едно поле) и съставен кандидат ключ, изберете за първичен простия кандидат ключ
          • В името на ключа да присъства и името на таблицата
          • Уверете се че първичния ключ пряко идентифицира всяка стойност в таблицата. Това е много важно условие. Всяка стойност на поле в таблицата трябва да е пряко определена от първичния ключ. Например „номера на фактура” еднозначно определя „клиента”, но не и телефония му номер (тъй като той е зависим от „клиента”, а не от номера на фактурата).
          • Всяка таблица трябва да има само един първичен ключ
          • Всеки първичен ключ в базата данни е уникален, освен за подтаблиците (които могат да имат първичен ключ на основната таблица)
          • Кандидат ключовете, които не са избрани за първичен ключ, се обозначават като алтернативни ключове
          • Цялостта на ниво таблица, гарантира следното:
            • Не съществуват дублиращи се записи в таблицата
            • Първичния ключ идентифицира пряко всеки запис в таблицата
            • Стойността на първичния ключ е уникална
            • Стойностите на първичния ключ не са „NULL”
            • Преглед на първоначалните структури на таблиците
              След като основните дефиниции на таблиците са завършени, трябва да се проведат интервюта с потребителите и ръководството, за да се верифицира извършената работа. Тези интервюта трябва да изпълнят следните задачи:

              • Да гарантирате, че в базата данни са представени подходящите теми
              • Имената и описанията на таблиците са подходящи и смислени за всички
              • Имената и описанията на полетата са подходящи и смислени за всички
              • Всички подходящи полета са присвоени на таблицата

9. Заключение

„Аз имам просто, но силно верую. Начинът на събиране, обработка и използване на информацията предопределя дали ще спечелите, или ще загубите.” Бил Гейтс

Силата на всяка методология е в последователното й прилагане. Не си спестявайте стъпките по прилагането на методологията. Както се казва „по-лошото от липса на методология, е непоследователното й прилагане”. Така че спазвайте описаните стъпки и ще получите таблици в 3 нормална форма. Поздравления !

  • Използвана литература:
  1. Пенева, Юлиана, доц. д-р
    „Бази от данни”, първа част (2005)
    издателство „Регалия 6”
    ISBN 954-745-088-3
  2. Пенева, Юлиана, доц. д-р
    Тупаров, Георги
    „Бази от данни”, втора част (2004)
    издателство „Регалия 6”
    ISBN 954-745-078-6
  3. Ернандес, Майкъл Х.
    „Проектиране на бази от данни” (2004)
    издателство „СофтПрес” ООД
    ISBN 954-685-301-1
  4. Гейтс, Бил
    „Бизнес със скоростта на мисълта” (1999)
    издателска къща „Сиела”
    ISBN 954-649-211-6
  5. Фаулър, Мартин
    „UML основи” (2007)
    издателство „СофтПрес” ООД
    ISBN 978-954-685-306-6