Глава 7. Проектиране на базата данни

Глава 7. Проектиране на базата данни

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

1. 
   Схемата съдържа всички нормализирани релации в предметната област.
   
2. 
   Всяка релация е нормализирана поне до трета нормална форма.
   
3. 
   Всяка нормализирана релация от дадена предметна област и база от данни трябва да участвува в релационната схема.
   
4. 
   Нормализираната релация съдържа поне една n-торка (обект, ред в kтаблица).
   
5. 
   Една n-торка (обект, ред) участвува само в една релация.
   
6. 
   Една n-торка (обект, ред) се формира от поне едно свойство.
   
7. 
   Едно свойство трябва да принадлежи на поне една n-торка (обект, ред).
   
8. 
   Едно свойство има един единствен домен.
   
9. 
   Един домен може да бъде използуван от едно или повече свойства.
   
10. 
    Един домен съдържа данни само от един атомарен тип.
    

Фиг. 7.1. Ограничения в релационния модел

Основните правила за създаването на концептуален релационен модел на една база от данни, дефинирани от сина на основоположника на релационното моделиране Е.Ф. Код и прецизирани от Фабиан Паскал, са:

1. 
   Данните от различните класове обекти трябва да бъдат запомнени само в таблици.
   
2. 
   Всяка таблица трябва да има име, поле за главен ключ, имена на колоните и стойности на главния ключ, с което се осигурява уникалност на отделните записи.
   
3. 
   Във всеки модел трябва да се разрешат колизиите от връзки “много към много”, както и да се сведат до релационен вид йерархичните и мрежовите структурни елементи.
   
4. 
   Във всеки модел трябва да се извърши нормализация върху релациите (таблиците) поне до трета нормална форма.
   
5. 
   Във всеки модел да се определи типът на данните за отделните свойства.
   
6. 
   При моделирането да се дефинират индексите (обикновено за главните ключове).
   
7. 
   Трябва да могат да се дават и запомнят указания за третирането на липсващите стойности.
   
8. 
   Базата от данни трябва да съдържа мета данни т.е. данни за данните, които да бъдат организирани в съответствие със структурата й.
   
9. 
   Правилата за цялост трябва да бъдат запомнени също в базата от данни.
   
10. 
    Правилата за цялост трябва да не допускат отпадане на запис с главен ключ, за който продължава да съществува ползуващ го външен ключ, както и добавяне на външен ключ, за който няма запис със съответен главен ключ.
    
11. 
    Трябва да има програмен език, с който да се обработват данните от базата от данни.
    
12. 
    Програмният език за работа с базата от данни трябва да бъде множествено, а не записно ориентиран.
    
13. 
    Не бива да се допуска промяна на правилата за цялост, които са запомнени в базата от данни.
    
14. 
    Трябва да бъде осигурена възможност за прозрачно изменение на структурата на базата от данни (напр. разделяне на таблици, добавяне на индекси).
    
15. 
    Таблиците със заявки трябва да отразяват измененията в базата от данни, както и да могат да приемат изменения в логиката на създаването им.
    

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

• 
  Определяне на целите и обхвата на информационната система;
  
• 
  Идентифициране на реално съществуващите в управленско-информационната система и удовлетворяващи поставените цели класове от обекти;
  
• 
  Разкриване на връзките между класовете от обекти и разрешаване на конфликтните ситуации;
  
• 
  Дефиниране на таблиците за окончателно определените класове от обекти;
  
• 
  Задаване на връзките между окончателно определените класове от обекти;
  
• 
  Дефиниране на ограниченията за цялост;
  
• 
  Изясняване на необходимите на системата форми и отчети;
  
• 
  Проектиране на заявките, необходими за създаване на формите и отчетите;
  
• 
  Създаване на формите и отчетите;
  
• 
  Създаване на потребителски интерфейс, свързващ формите и отчетите в удобни приложения.
  

Създаването на потребителски интерфейс може да стане по следните начини:

• 
  чрез графичен потребителски интерфейс;
  
• 
  чрез макроси;
  
• 
  чрез език за програмиране.
  

Функционалността на графичния потребителски интерфейс може да се разшири чрез използуването на макроси. Даден макрос се създава, за да обхване последователност от потребителски операции върху зададен клас от обекти (включително заявки, форми, отчети) и да позволи изпълнението им, разглеждано като едно събитие, чрез функционален бутон. В МS Access създаването и използуването на макроси става чрез инструменталния бутон Масro.

Програмното кодиране дава възможност за още по-голямо разширение на функционалността на потребителския интерфейс. То може да бъде реализирано например на Visual Basic for Application (VBA) или в интегрираната графична среда Delphi. В известна степен приложението на макросите изисква също познаване на VBA. Затова в много случаи се препоръчва създаването на потребителски интерфейс да бъде осъществено с позаписно ориентирани езици за програмиране като горе цитираните или с множествено ориентирания специализиран за работа с бази от данни програмен език SQL. При работа с VBA може да се извиква програмният код на подобно на исканото приложение, създадено със средствата на графичния потребителски интерфейс, и да се изграждат бързо и лесно желани негови модификации. Програмирането с множествено-ориентираният език SQL специфицира целите класове от обекти (таблици) и по този начин осигурява бърза и ефективна програмистка работа.

В настоящия труд се разглеждат възможностите за създаване на потребителски приложения както чрез QBE (Query by Example), така и чрез множествено ориентирания специализиран за работа с бази от данни програмен език SQL и чрез позаписно ориентираните езици като VBA.

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

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

• 
  избор на единен принцип, по който се определят задачите (функционален, ресурсен, структурен и др.);
  
• 
  изчерпателно дефиниране на задачите според единния принцип;
  
• 
  осигуряване непротиворечивост на задачите;
  
• 
  съобразяване с обема на обработваната информация;
  
• 
  задаване периодичността на задачите.
  

Фиг.7.2. Технологична блок-схема за проектиране на управленска информационна система

• 
  Изходящата информация се определя най-напред задават се имената на обектите, имената и вида (резултантни или не, тип и дължина) на свойствата
  
• 
  Входящата информация се определя след като е определена изходящата и в зависимост от нея;
  
• 
  Зависимостта между входящата и изходящата информация може да изисква алгоритъм за преобразуване, както и съгласуване по време и място;
  
• 
  При определяне на входящата информация трябва да се осигури възможност за обхващането й максимално близко до източника й;
  
• 
  При определяне на входящата информация трябва да се избягва повторението на еднакви или синонимни свойства;
  
• 
  Да се предвидят средства са осигуряване на коректност, сигурност и защита на информацията;
  
• 
  Да се предвидят точни идентификатори за отделните екземпляри в множествата от обекти.
  

• 
  типа на данните (например “име” е от символен тип);
  
• 
  граничните стойности на свойствата (например “дата” може да се изменя в интервала 1-31);
  
• 
  минимален и/или максимален брой на подчинените елементи (например декартовите координати в равнина трябва да бъдат две);
  
• 
  самопроверяващи се кодове за особено отговорните и с по-голяма дължина данни.
  

½ ½ ____________ група

За установяване на верността на съответните идентификатори се използуват самопроверяващи се кодове, включващи допълнителен разряд т.н. контролно число. Контролното число се получава по определен алгоритъм и се записва неразделно към всеки код. То се проверява при всяко въвеждане на кода и различието му от алгоритмично изчисленото за кода контролно число е сигнал за грешка. По-горе бе разгледан примерът с пет позиционния идентификатор а₅ а₄ а₃ а₂ а₁. В резултат на алгоритъма к₁ к₂ = а₅.2 + а₄.1 + а₃ .3 + а₂.2 + а₁. 1 се създава новият идентификатор с контролно число а₅ а₄ а₃ а₂ а₁ к₂. Алгоритмите за определяне на контролно число са много разнообразни, но най-често се основават на принципа на делимост по даден модул.

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

N=n₁+B₁.n₂+B₁ .B₂.n₃+…+B₁ .B₂…B_i._ni+1+…+B₁ .B₂…B_k-1.n_k,

където N - нов шифър;

B_i - основа на бройна система i;

N_i – стойност на позиция в старата бройна система, n_i< B_i;

k- индекс на последната бройна система.

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

Информационният анализ, както се вижда и от фиг. 7.2., включва стъпките:

• 
  определяне на класовете от обектите;
  
• 
  изясняване на връзките между обектите (1:1, 1:М, М:1, М:N);
  
• 
  обосновка и избор на модел за външна схема на всяка задача;
  
• 
  описание свойствата на отделните класове от обекти;
  
• 
  определяне на главните и групови ключове;
  
• 
  нормализация;
  
• 
  преобразуване и обединение на отделните външни схеми в обща концептуална схема;
  
• 
  съставяне на технология за навигация в базата от данни и формиране на извежданията.
  

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

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

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

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

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

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

изнасяне на операциите проекция, селекция и сечение в колкото е възможно по-ранни етапи на обработката;

оставяне на операциите съединение, обединение и декартово произведение в последните етапи на обработката;

осигуряване еднаква наредба на данните, участвуващи в операциите съединение, обединение, декартово произведение.

Пример за конкретно технологично решение е даден на фиг. 7.3.

Фиг. 7.3. Технология за обработка и получаване на извеждане.

Нека желаем да изведем графика за изменението на екологичния параметър разтворен кислород, обхващан в база от данни за екосистема за реките през последните десет години във важни пунктове по течението на река Искър. Базата от данни съдържа времезависима (текстова и числова) информация за измерванията по реките, точките и периодите на измерване. Обработката започва със селекция на реката. Следват проекции, с които от базата от данни се избират само интересуващите ни свойства. След това следват селективни операции измежду сезоните и параметрите, което намалява броя на навигациите в следващите етапи на работата. За определяне на средно аритметичните измерени стойности на желания параметър за избраните сезон - пролет и параметър „разтворен в речната вода кислород (OKISL)” се използуват библиотечни агрегиращи процедури. С така получените резултати могат да се правят анализи и да се подготвят варианти на управленски решения. Така се създават условия за осмисляне на данните и за по-ефективни аналитични техники.

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

Част II. Въведение в ACCESS чрез примери

Въведение в Access

чрез примери

Каталог: lib
lib -> Преводач Елена Атанасова Коректор Ива Данева Формат 84/108/32 Печатни коли 15 дф „абагар" Велико Търново ик „сова" Варна как да се използва тази книга
lib -> За медитацията ошо въведение
lib -> Поредица ние обичаме животните
lib -> Тайната на скорпион
lib -> Разчупване на оковите Победа над: Отрицателните мисли
lib -> Въведение

Изтегляне 3.1 Mb.

Сподели с приятели: