Проектиране на структури на база данни. Логически дизайн на база данни. Проектиране независимо от rsubd

Проектиране на база данни

Основни понятия за бази данни и СУБД

Информационна система (IS)Това е система, базирана на компютърна технология, предназначена за съхранение, търсене, обработка и предаване на значителни обеми информация, която има определен практически обхват.

База данниТова е IP, който се съхранява по електронен път.

база данни (DB)- организирано събиране на данни, предназначени за дългосрочно съхранениев външна паметКОМПЮТЪР, постоянно обновяванеи използвайте.

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

Класификация на базата данни:

1. По естеството на съхраняваната информация:

- Фактографски - съдържат кратка информацияза описаните обекти, представени в строго определен формат (картотеки, например: БД на книжния фонд на библиотеката, БД на персонала на институцията),

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

2. По начин на съхранение на данни:

- Централизирано (съхранява се на един компютър),

- Разпределени (използвани в локални и глобални компютърни мрежи).

3. По организационна структура на данните:

- релационни (таблични),

- Нерелационни.

Терминът "релационен" (от лат. Relatio - отношение ) показва, че такъв модел за съхранение на данни е изграден върху връзката на съставните му части. релационнибазата данни по същество е двуизмерна маса... Всеки ред от такава таблица се нарича запис. Колоните на таблицата се наричат ​​полета: всяко поле се характеризира със своето име и горната част на данните. DB полето е колона на таблица, която съдържа стойностите на конкретно свойство.

Имоти релационен моделданни:

Всеки елемент от таблицата е един елемент от данни;

Всички полета на таблицата са хомогенни, т.е. са от един вид;

Идентични записине е в таблицата;

Редът на записите в таблицата може да бъде произволен и може да се характеризира с броя на полетата, типа данни.

Йерархиченсе нарича база данни, в която информацията е подредена по следния начин: един елемент се счита за основен, останалите са подчинени. V йерархиченВ базата данни записите са подредени в определена последователност, като стъпките на стълба, а извличането на данни може да се извърши чрез последователно „спускане“ от стъпка на стъпка. Този моделхарактеризиращ се с такива параметри като нива, възли, връзки. Принципът на работа на модела е такъв, че няколко възела са повече ниско нивоса свързани чрез комуникационни средства с един възел от по-високо ниво.

Възел - информационен модел на елемента, разположен на това нивойерархия.

Имоти йерархичен моделданни:

Няколко възела от по-ниско ниво са свързани само с един възел от по-високо ниво;

Йерархичното дърво има само един връх (корен), то не е подчинено на никой друг връх;

Всеки възел има свое собствено име (идентификатор);

Има само един път от основния запис до по-частния запис с данни.

Йерархичната база данни е Каталогът Windows папкис който можете да работите, като стартирате File Explorer. Най-високо нивозаема папката Desktop. Второто ниво съдържа папките Моят компютър, Моите документи, мрежова средаи Trash, които са наследници на папката Desktop, като са близнаци помежду си. От своя страна папката My computer е предшественик по отношение на папките от трето ниво, дисковите папки (Диск 3.5 (A :), C :, D :, E :, F :) и системни папки(Принтери, контролен панел и др.).

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

Мрежовата база данни всъщност е Световната мрежаглобален компютърна мрежаИнтернет. Хипервръзките свързват стотици милиони документи заедно в едно разпределено мрежова базаданни.

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

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

Основните действия, които потребителят може да извърши с помощта на СУБД:

Създаване на структура на база данни;

Попълване на базата данни с информация;

Промяна (редактиране) на структурата и съдържанието на базата данни;

Търсене на информация в базата данни;

Сортиране на данни;

Защита на база данни;

Проверка на целостта на базата данни.

Съвременна СУБДправят възможно включването в тях не само на текст и графична информацияно също и звукови хапки и дори видеоклипове.

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

Популярни СУБД - FoxPro, Access за Windows, Парадокс.

По този начин е необходимо да се прави разлика между действителната база данни (DB) - подредени набори от данни, и системи за управление на бази данни (DBMS) - програми, които управляват съхранението и обработката на данни. Например, Достъп до приложениетовключен в офис пакетпрограми Microsoft Office, е СУБД, която позволява на потребителя да създава и обработва таблични бази данни.

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

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

- Минимални разходи. Ниска ценасъхраняване и използване на данни, минимизиране на разходите за извършване на промени.

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

- Лесно извършване на промени.Базата данни може да расте и да се променя, без да нарушава съществуващите начини за използване на данните.



- Възможност за търсене.Потребителят на базата данни може да прави различни запитвания за съхраняваните в нея данни. За постигането на това се използва така нареченият език за заявки.

- Интегритет. Модерни базиданните могат да съдържат данни, използвани от много потребители. Много е важно елементите с данни и връзките между тях да не се прекъсват по време на работа. Освен това хардуерните грешки и различни видове случайни повреди не трябва да водят до необратима загуба на данни. Това означава, че системата за управление на данни трябва да съдържа механизъм за възстановяване на данни.

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

Освен това, използвайки примера на една от най-разпространените системи за управление на бази данни - Microsoft Accessе част от популярните пакет на Microsoft Office - ще се запознаем с основните типове данни, как да създаваме бази данни и как да работим с бази данни.

Проектиране на база данни

Както всеки софтуерен продукт, базата данни има собствен жизнен цикъл (LCBD). Основният компонент в кръговат на живота DB е създаването на единна база данни и програми, необходими за нейното функциониране.

ZHCBD включва следните основни етапи:

1. Планиране на разработване на база данни;

2. Определяне на системните изисквания;

3. Събиране и анализ на потребителските изисквания:

4. Дизайн на база данни:

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

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

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

На етапа на логическо проектиране се взема предвид спецификата на конкретен модел на данни, но може да не се вземе предвид спецификата на конкретна СУБД.

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

5. Разработване на приложения:

Проектиране на транзакция (група от SQL оператори (набор от команди), изпълнени като цяло);

Дизайн потребителски интерфейс;

6. Изпълнение;

8. Тестване;

9. Експлоатация и поддръжка:

Анализ на функционирането и поддръжка на оригиналната версия на базата данни;

Адаптация, модернизация и поддръжка на преработени версии.

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

Основните задачи на проектиране на база данни:

Осигуряване на съхранение в базата данни на цялата необходима информация.

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

Намаляване на излишъка и дублирането на данни.

Осигуряване на целостта на базата данни.

Преди да започнете да създавате база данни, трябва да отделите известно време за нея. дизайн.

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

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

1. Определяне предназначението на базата данни.

2. Решаване какви изходни данни трябва да съдържа базата данни.

3. Определяне на изходните таблици на базата данни.

4. Определяне на полетата, които ще бъдат включени в таблиците, и избор на полета, съдържащи уникални стойности.

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

6. Създаване на таблици, свързването им и експериментално попълване на базата данни с пробни данни.

7. Създаване на формуляри, отчети и заявки за операции с въведени данни.

Определяне на предназначението на базата данни

Разработването на всяка база данни започва с изследване на проблема, който трябва да реши, или необходимостта, която трябва да задоволи.

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

Избор на информация, която да бъде включена в базата данни

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

2. Заглавието на книгата.

3. Място на издаване (град).

4. Издател (име на издателя).

5. Година на издаване.

6. Анотация.

Атрибутите, които позволяват да се характеризират местата за съхранение на отделни копия на книги, включват:


1. Номер на стая (стая за съхранение на книги).

2. Номер на стелажа в стаята.

3. Номер на рафта на стелажа.

4. Номер (инвентарен номер на книгата).

5. Дата на покупка.

6. Датата, на която дадена книга е публикувана на определено място.

7. Датата на изваждане на книгата от определеното място.

Атрибутите, които позволяват да се характеризират читателите, включват:

1. Номер на библиотечната карта (формуляр).

2. Фамилията на читателя.

3. Името на читателя.

4. Патроним на читателя.

5. Адрес на читателя.

6. Телефонен номер на читателя.

7. Дата на издаване на определена книга на читателя.

8. Срокът, за който дадена книга е издадена на читателя.

9. Дата на връщане на книгата.

Дефиниране на изходни таблици

Анализът на обектите и атрибутите, дефинирани по-горе, ви позволява да дефинирате следните таблици за проектираната база данни за изграждане на базата данни:

2. Книги... Таблицата е предназначена да съхранява информация за книги.

3. Издатели.Таблицата е предназначена за съхранение на информация за издатели.

4. Съхранение... Таблицата има за цел да опише мястото за съхранение на книгите.

5. Издаване.Таблицата е предназначена за съхраняване на информация за издадени книги.

6. читателиТаблицата е предназначена за съхраняване на информация за читателите на библиотеката.

Избиране на необходимите полета в таблицата

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

Въз основа на горното определяме полетав избраните таблици и типсъхранени данни.

Книги:

· код на книгата- числово поле, предназначено да идентифицира уникално всяка конкретна книга в базата данни;

· заглавие на книга

· анотация- текстово поле;

· дата на издаване;

· дата на приемане в библиотеката;

· съхранение.
Издатели:

· код на издателя- числово поле, предназначено да идентифицира уникално всеки конкретен издател в базата данни;

· име на издател- поле за символи, не повече от 256 знака;

· град, в който се намира издателството- поле за символи, не повече от 25 знака.

Съхранение:

· код на седалката- числово поле, предназначено да идентифицира уникално всеки конкретен рафт в базата данни;

· номер на стая- числово поле;

· номер на стелаж- числово поле;

· номер на рафтаТова е числово поле.

Издаване:

· код на проблема- числово поле, предназначено да идентифицира уникално всеки конкретен проблем в базата данни;

· номер на издадена книга- числово поле;

· код за четене- числово поле;

· дата на издаване;

· дата на издаване(Номер на дните);

· дата на връщане.

читатели:

· номер на библиотечна карта- числово поле, предназначено да идентифицира уникално всеки конкретен читател в базата данни;

· фамилия

· име- поле за символи, не повече от 50 знака;

· патроним- поле за символи, не повече от 50 знака;

· адрес- поле за символи, не повече от 256 знака;

· телефон- поле за символи, не повече от 20 знака.

Избиране на уникални полета

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

За нашата база данни първичните ключове са следните полета:

Книги - код на книгата.

Издатели - код на издателя.

Съхранение - код на седалката.

Издаване - код на проблема.

читатели номер на билета.

Задаване на връзки между таблици

Връзките на кръстосани таблици свързват две таблици, използвайки общо поле, което присъства и в двете таблици. Има три вида такива връзки:

· едно към едно- всеки запис от таблица А не може да бъде свързан с повече от един запис от таблица Б;

· едно към много- един запис в таблица А може да бъде свързан с много записи в таблица Б (например може да има много ученици във всеки клас);

· много към много- всеки запис в таблица A може да бъде свързан с много записи в таблица B, а всеки запис в таблица B - с много записи в таблица A (например всеки ученик може да има няколко учители, а всеки учител може да има много ученици).

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

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

В нашата база данни ще установим следните типове връзки между таблици:

1. Автори – Книги. Ето линка много към много, всеки автор може да има повече от една книга и всяка книга може да бъде написана от няколко автора. Затова въвеждаме помощна таблица „Автори – книги“ със следните полета:

· код на книгата.

2. Книги – издателства. Ето линка много към много, всяка книга може да бъде публикувана от няколко издателства и всяко издателство публикува повече от една книга. Затова въвеждаме още една помощна таблица "Книги-издатели" със следните полета:

· код на книгата;

· код на издателя.

3. Съхранение - Книги. Ето линка едно към много, можете да поставите много книги на един рафт, но всяка книга може да бъде само на един рафт в хранилището. Следователно полето „Место за съхранение“ в таблицата „Книги“ се дефинира като външен ключ и свързваме таблиците „Съхранение“ и „Книги“ с първичния ключ „Код на местоположение“ и външния ключ „Место за съхранение“.

4. Книги - Издаване. Ето линка едно към много, т.е. една и съща книга може да бъде издадена няколко пъти на различни дати за различни читатели. Следователно полето „Номер на издадена книга“ в таблицата „Издадена“ се дефинира като външен ключ и свързваме таблиците „Книги“ и „Издадени“ с първичния ключ „Код на книгата“ и външния ключ „Номер на издадена книга“ “.

5. Читатели - Изд. Ето линка едно към много, т.е. една и съща книга може да бъде издадена няколко пъти на различни читатели по различно време. Следователно полето „Код на четеца“ в таблицата „Издание“ се дефинира като външен ключ и свързваме таблиците „Читатели“ и „Издание“ с първичния ключ „Номер на библиотечна карта“ и външния ключ „Код на четеца“ .


Нормализиране на отношенията

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

Правило 1: Всяко поле в таблица трябва да представлява уникален тип информация.

Базата данни, която проектирахме, няма полета различни маси ah, съдържащ същата информация (с изключение на външни ключове).

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

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

Правило 3: За всяка стойност на първичен ключ стойностите в колоните с данни трябва да се отнасят към и да описват напълно обекта на таблицата.

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

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

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

Попълване на базата данни, създаване на формуляри и отчети

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

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

Получено схема за данниразработената база данни в MS Access е показана на фиг. 4.1.

Ориз. 4.1. Схема за данни на разработената база данни в Microsoft Access

Контролни въпроси

1. Дайте дефиниция на информационна система.

2. Обяснете концепцията за база данни.

3. Какво е предметна област?

4. Дайте дефиницията на СУБД.

5. Какво е модел на данни?

6. Обяснете основните принципи на релационния модел на данни.

7. Обяснете характеристиките на СУБД на Microsoft Access.

8. Кои са основните обекти на база данни на Access?

9. Обяснете структурата на таблицата Access.

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

11. Кои са основните етапи на проектиране на база данни?

12. Как се извършва изборът на информация, включена в базата данни?

13. Обяснете понятията: първичен ключ, външен ключ.

14. Каква е целта на връзките между таблиците?

15. Обяснете основните видове връзки между таблиците.

16. Какво представлява нормализирането на връзките с базата данни?

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

Етап I. Формулиране на проблема.

На този етап се формира задача за създаване на база данни. Той описва подробно състава на базата данни, целта и целта на нейното създаване, както и изброява какви видове работа трябва да се извършват в тази база данни (избор, добавяне, промяна на данни, отпечатване или извеждане на отчет и др. ).

II етап. Анализ на обекта.

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

III етап. Синтез на модела.

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

Етап IV. Избор на начини за представяне на информация и софтуерни инструменти.

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

В повечето СУБД данните могат да се съхраняват в две форми:

  • използване на формуляри;
  • без използване на формуляри.

ФорматаСъздаден е от потребителя графичен интерфейсза въвеждане на данни в базата данни.

етап V. Синтез компютърен моделобект.

В процеса на създаване на компютърен модел могат да се разграничат някои етапи, които са типични за всяка СУБД.

Етап 1.Стартиране на СУБД, създаване на нов файл на база данни или отваряне на предварително създадена база данни.

Етап 2.Създаване на оригинална таблица или таблици.

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

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

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

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

4. Базата данни трябва да има първичен ключ. Това е необходимо, за да може СУБД да свързва данни от различни таблици, например данни за клиент и неговите поръчки.

Етап 3.Създаване на екранни форми.

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

Етап 4.Попълване на базата данни.

Процесът на попълване на базата данни може да се извърши в две форми: под формата на таблица и под формата на формуляр. Цифрови и текстови полетамогат да се попълват под формата на таблица, а полета от типа MEMO и OLE - под формата на формуляр.

Етап VI. Работа със създадената база данни.

Работата с базата данни включва следните стъпки:

  • търсене на необходимата информация;
  • сортиране на данни;
  • избор на данни;
  • разпечатване;
  • промяна и добавяне на данни.

Основни задачи на проектиране на бази данни

Основни цели:

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

Основните етапи на проектиране на база данни

Идеен (инфологичен) дизайн- изграждане на семантичен модел на домейна, тоест информационен модел от най-високо ниво на абстракция. Такъв модел се създава без да се фокусира върху някаква конкретна СУБД и модел на данни. Термините "семантичен модел", "концептуален модел" и " инфологически модел„Синоними са. Освен това в този контекст думите „модел на база данни“ и „модел на домейн“ (например „концептуален модел на база данни“ и „концептуален модел на домейн“) могат да се използват еднакво, тъй като такъв модел е едновременно образ на реалността и изображение, проектирана база данни за тази реалност.

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

Най-често концептуалният модел на база данни включва:

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

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

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

На етапа на логическо проектиране се взема предвид спецификата на конкретен модел на данни, но може да не се вземе предвид спецификата на конкретна СУБД.

Физически дизайн

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

Нормализиране

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

Модели субект-връзка

Моделът субект-връзка (англ. "Модел на субект-връзка" ), или ER-моделът, предложен от П. Чен през 1976 г., е най-известният представител на класа семантични (концептуални, инфологични) модели на домейна. Моделът ER обикновено се представя в графична форма, като се използва оригиналната нотация на P. Chen, наречена ER диаграмаили като използвате други графични обозначения ( Пачи крак, Информационно инженерствои т.н.).

Основните предимства на ER-моделите:

Основните елементи на ER-моделите:

  • обекти (същности);
  • атрибути на обекта;
  • връзки между обекти.

Обектът е обект на домейн, който има атрибути.

Връзката между субектите се характеризира с:

  • тип комуникация (1: 1, 1: N, N: M);
  • клас на принадлежност. Класът може да бъде задължителен или незадължителен. Ако всеки екземпляр на обект участва във връзка, тогава класът на членство е задължителен, в противен случай е незадължителен.

Семантични модели

Семантичен модел (концептуален модел, инфологичен модел) - модел на домейн, предназначен да представя семантиката на домейна в самото високо нивоабстракция. Това означава, че необходимостта от използване на концепции на „ниско ниво“, свързани със спецификата на физическото представяне и съхранение на данни, е елиминирана или сведена до минимум.

Дата KJ Въведение в системите за бази данни. - 8-мо изд. - М .: "Уилямс", 2006:

Семантичното моделиране е обект на интензивни изследвания от края на 70-те години. Основният мотив зад подобни изследвания (т.е. проблемът, който изследователите се опитаха да решат) беше следният факт. Въпросът е, че системите за бази данни обикновено имат много ограничени познания за значението на данните, които съхраняват. Най-често те ви позволяват да манипулирате данните само на определени прости типовеи дефинирайте някои от най-простите ограничения за целостта, наложени на тези данни. Всяка по-сложна интерпретация е оставена на потребителя. Въпреки това би било чудесно, ако системите могат да имат малко по-богата база от знания и малко по-интелигентен отговор на потребителски заявки и да поддържат по-сложни (т.е. по-високо ниво) потребителски интерфейси.
[…]
Идеите за семантично моделиране могат да бъдат полезни като инструмент за проектиране на база данни, дори ако не се поддържат директно от СУБД.

Най-известният представител на класа семантични моделие моделът обект-връзка (ER-модел).

литература

  • Дата C.J.Въведение в системите за бази данни. - 8-мо изд. - М .: "Уилямс", 2006. - 1328 стр. - ISBN 0-321-19784-4
  • Когаловски М.Р. Усъвършенствани технологии информационни системи... - М .: DMK Press; IT Co., 2003 .-- 288 с. - ISBN 5-279-02276-4
  • Когаловски М.Р.Енциклопедия на технологиите за бази данни. - М .: Финанси и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
  • С. Д. КузнецовОснови на базата данни. - 2-ро изд. - М .: Интернет университет Информационни технологии; BINOMIAL. Лаборатория на знанията, 2007. - 484 с. - ISBN 978-5-94774-736-2
  • Конъли Т., Бег К.База данни. Проектиране, изпълнение и поддръжка. Теория и практика = Системи от бази данни: практически подход към проектиране, внедряване и управление. - 3-то изд. - М .: "Уилямс", 2003. - 1436 стр. - ISBN 0-201-70857-4
  • Гарсия-Молина Г., Улман Дж., Уидом Дж.Системи за бази данни. Пълен курс... - М .: "Уилямс", 2003. - 1088 стр. - ISBN 5-8459-0384-X

Вижте също

  • Методи за проектиране

Връзки

  • Модел на същност-връзка - стъпка към унифициран поглед към данните - Citforum
  • Разширяване на релационния модел за по-добро отразяване на семантиката - Citforum
  • Ръководство за начинаещи за дизайн на база данни на уебсайтове
  • Метод за проектиране на логическа структура на релационна база данни без нормализиране на таблици

Бележки (редактиране)


Фондация Уикимедия. 2010 г.

Вижте какво представлява "Дизайн на база данни" в други речници:

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

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

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

    Заявката "DB" се пренасочва тук; вижте и други значения. База данни, представена в обективна форма, набор от независими материали (статии, изчисления, наредби, съдебни решения и други подобни материали), ... ... Уикипедия