Етапи на проектиране на база данни. Системи за управление на бази данни. II етап. Анализ на обекта

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

Ръководство за проектиране на база данни.

1. Въведение.

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

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

Базата данни е създадена за съхраняване на информация в нея и получаване на тази информация, ако е необходимо. Това означава, че трябва да можем да поставяме, вмъкваме ( INSERT) информация в базата данни и искаме да можем да извличаме информация от базата данни ( ИЗБЕРЕТЕ).
Езикът за заявки към базата данни е изобретен за тази цел и е наречен Език за структурирани заявкиили SQL. Операциите по вмъкване на данни (INSERT) и изборът им (SELECT) са част от този език. По-долу е даден пример за заявка за извличане на данни и нейния резултат.

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

Релационният модел.

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

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

Примери.

Използвах редица приложения като примери в урока.

RDBMS.

RDBMS, който използвах за създаване на примерните таблици, е MySQL. MySQL е най-популярната RDBMS и е безплатна.

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

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

Визуално моделиране.

Има отличен безплатно приложение MySQL Workbench. Позволява ви да проектирате вашата база данни графично. Илюстрациите на диаграмите в ръководството са взети в тази програма.

Дизайн, независим от RDBMS.

Важно е да знаете, че въпреки че този урок предоставя примери за MySQL, дизайнът на базата данни е независим от RDBMS. Това означава, че информацията се отнася за релационни бази данни като цяло, а не само за MySQL. Можете да приложите знанията от този урок към всякакви релационни бази данни като Mysql, Postgresql, Microsoft Access, Microsoft Sql или Oracle.

В следващата част ще говоря накратко за еволюцията на базите данни. Ще разберете откъде идват базите данни и релационен моделданни.

2. История.

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

Ето как изглеждаха ИТ специалистите през 70-те години. (Бил Гейтс е долу вляво).

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

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

Таблици в базата данни.

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

Компютърна програма може да търси в колоната tutorial_id на таблицата конкретния tutorial_id, за да намери бързо съответното заглавие и категория. Това е много по-бързо от търсенето във файла ред по ред, точно както прави програмата в текстов файл.

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

Историята на релационния модел.

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

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

- Оракул- използва се предимно за професионални, големи приложения.
- Microsoft SQLсървър- RDBMS Microsoft... Предлага се само за операционна система Windows.
- MysqlТова е много популярна RDBMS с отворен код. Широко се използва както от професионалисти, така и от начинаещи. Какво друго е необходимо?! Безплатно е.
- IBM- има редица RDBMS, най-известната е DB2.
- Microsoft Access- RDBMS, която се използва в офиса и у дома. Всъщност това е повече от просто база данни. MS Access ви позволява да създавате бази данни с потребителски интерфейс.
В следващата част ще говоря за някои от характеристиките на релационните бази данни.

3. Характеристики на релационните бази данни.

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

Използване на ключове.

Всеки ред данни в таблицата се идентифицира с уникален „ключ“, наречен първичен ключ. Често, първичен ключтова е автоматично нарастващо (автоматично нарастващо) число (1,2,3,4 и т.н.). Данните в различни таблици могат да бъдат свързани заедно с помощта на ключове. Стойностите на първичния ключ на една таблица могат да бъдат добавени към редовете (записите) на друга таблица, като по този начин се свързват тези записи заедно.

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

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

Няма излишък на данни.

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

Ограничение на въвеждане.

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

Когато създавате таблица на база данни, вие предоставяте тип данни за всяка колона. Например, varchar е тип данни за малки парчета текст с максимален бройсимволи, равни на 255, а int са числа.

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

Тези ограничения ви дават контрол върху целостта на вашите данни и предотвратяват ситуации като следните:

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

Поддържане на целостта на данните.

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

Възлагане на права.

Повечето RDBMS предлагат настройка за разрешения, която ви позволява да зададете определени праваопределени потребители. Някои действия, които могат да бъдат разрешени или отказани на потребителя, са SELECT, INSERT, DELETE, ALTER, CREATE и т.н. Това са операции, които могат да се извършват с помощта на Structured Query Language (SQL).

Структуриран език за заявки (SQL).

За извършване на определени операции върху базата данни, като например записване на данни, извличането им, промяната им, се използва език за структурирани заявки (SQL). SQL е относително лесен за разбиране и позволява вкл. и подредени селекции, като например извличане на свързани данни от множество таблици с помощта на SQL изявлениеПРИСЪЕДИНЯВАНЕ. Както споменахме по-рано, SQL няма да бъде обсъждан в този урок. Ще се съсредоточа върху дизайна на база данни.

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

Преносимост.

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

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

В следващата част ще разгледаме по-отблизо първичните ключове.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• видимост;
• моделите ви позволяват да проектирате бази данни с голяма сумаобекти и атрибути;
• ER моделите се прилагат в много системи компютърно подпомагано проектиранебази данни (например ERWin).

Основните елементи на 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-ро изд. - М .: Интернет университет Информационни технологии; БИНОМИАЛЕН. Лаборатория на знанията, 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" се пренасочва тук; вижте и други значения. База данни, представена в обективна форма, набор от независими материали (статии, изчисления, наредби, съдебни решения и други подобни материали), ... ... Уикипедия

Теми:етапи на проектиране на база данни, проектиране на база данни въз основа на модел от типа обектна връзка.

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

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

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

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

Етапите на проектиране и създаване на база данни се определят от следната последователност:

Изграждане на информационно-логически модел на данните на предметната област;

Определяне на логическата структура на релационна база данни;

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

Създаване на схема на данни;

Въвеждане на данни в таблици (създаване на записи);

Разработване на необходимите формуляри, заявки, макроси, модули, отчети;

Разработване на потребителски интерфейс.

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

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

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

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

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

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

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

Изберете всички зависими атрибути и посочете за всеки всички негови ключови атрибути, тоест тези, от които зависи;

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

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

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

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

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

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

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

Има цяла линияметоди за създаване на информация и логически модели. Една от най-популярните в момента техники за моделиране използва ERD (Entity-Relationship Diagrams). В рускоезичната литература тези диаграми се наричат ​​"обект - връзка" или "обект - връзка". Моделът ERD е предложен от Peter Ping Sheng Chen през 1976 г. Към днешна дата са разработени няколко варианта, но всички те се основават на графични диаграмипредложено от Чен. Диаграмите се изграждат от малък брой компоненти. Поради яснотата си на представяне, те се използват широко в CASE-инструментите (Computer Aided Software Engineering).

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

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

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

Всеки обект трябва да има някои свойства:

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

Имат един или повече атрибути, които или принадлежат на обект, или са наследени от него чрез връзка;

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

Един субект може да бъде независим или зависим. Признак за зависим субект е наличието на атрибути, наследени чрез връзка (фиг. 1).

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

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

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

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

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

Продавачът може да получи възнаграждение за един или повече Договори;

Договорът трябва да бъде иницииран от точно един Продавач.

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

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

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

Атрибутът може да бъде едно от двете задължителенили по избор... Задължителен означава, че атрибутът не може да приема нулеви стойности. Атрибутът може да бъде или описателен (тоест обикновен дескриптор на обект), или част от уникален идентификатор (първичен ключ).

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

Естеството на идентификацията е показано на диаграмата на комуникационната линия (фиг. 4).

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

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

Понастоящем, въз основа на подхода на Чен, е разработена методологията IDEF1X, която е разработена, като се вземат предвид такива изисквания като лекота на учене и възможност за автоматизация. Диаграмите IDEFlX се използват от редица често срещани CASE инструменти (по-специално, ERwin, Design / IDEF).

Един обект в методологията IDEF1X се нарича независим от идентификаторите или просто независим, ако всеки екземпляр на обект може да бъде еднозначно идентифициран, без да се дефинират връзките му с други обекти. Един обект се нарича зависим от идентификатора или просто зависим, ако уникалната идентификация на екземпляр на обект зависи от връзката му с друг обект (Фигура 5).

На всеки обект се присвоява уникално име и номер, разделени с наклонена черта "/" и поставени над блока.

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

Идентифициращата връзка между родителския обект и наследствения обект е показана с плътна линия. На фиг. 5: # 2 е зависим обект, Връзка 1 е идентифицираща връзка. Потомствен обект в идентификационна връзка е субект, зависим от идентификатор. Обект родител в идентификационна връзка може да бъде или независим, или зависим от идентификатор обект (това се определя от връзките му с други обекти).

Пунктираната линия представлява неидентифицираща връзка. На фиг. 5: # 4 е независим обект, Връзка 2 е неидентифицираща връзка. Един низходящ субект в неидентифицираща връзка ще бъде независим от идентификатор, ако не е също така низходящ субект в която и да е идентификационна връзка.

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

Следните мощности могат да бъдат изразени в IDEF1X:

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

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

Всеки родителски екземпляр на обект трябва да има най-много един асоцииран екземпляр на низходящ обект;

Всеки родителски екземпляр на обект е свързан с някакъв фиксиран брой екземпляри на потомствен обект.

Комуникационната мощност е посочена, както е показано на фиг. 6 (мощност по подразбиране - Н).

Атрибутите се показват като списък с имена в блока на обекта. Атрибутите, определящи първичния ключ, се поставят в горната част на списъка и се отделят от другите атрибути с хоризонтална лента (Фигура 7).

В резултат се получава информационно-логически модел, който се използва от редица разпространени CASE-инструменти, като ERwin, Design / IDEF. От своя страна технологиите CASE имат висок потенциал в развитието на бази данни и информационни системи, а именно повишаване на производителността на труда, подобряване на качеството софтуерни продукти, подкрепа за единен и последователен стил на работа.

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

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

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

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

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

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

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

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

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

Как да картографирате обекти на домейн към абстрактни обекти на модела на данни? Този проблем се нарича проблем с дизайна на логическата база данни.

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

В случай на релационни бази данни е трудно да се предостави някаква обща рецепта за физически дизайн. Тук твърде много зависи от използваната СУБД. Затова ще се ограничим до въпросите на логическото проектиране на релационни бази данни, които са от съществено значение при използване на всяка релационна СУБД.

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

от какви отношения трябва да се състои базата данни и

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

Има три основни подхода за проектиране на база данни:

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

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

3. структуриране на информация за използване в ИС в процеса на провеждане на системен анализ въз основа на набор от практически правила и препоръки.

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

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

първа нормална форма (1NF);

втора нормална форма (2NF);

трета нормална форма (3NF);

Нормална форма на Бойес-Код (BCNF)

четвърта нормална форма (4NF);

пета нормална форма (5NF или PJ / NF).

Основни свойства на нормалните форми:

всяка следваща нормална форма е в известен смисъл по-добра от предишната;

при преминаване към следващата нормална форма, свойствата на предишните нормални свойства се запазват.

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

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

Определение 1. Функционална зависимост

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

Определение 2 . Пълна функционална зависимост

Функционална зависимост R.X -> R.Y се нарича пълна, ако атрибутът Y не зависи функционално от нито едно точно подмножество на X.

Определение 3. Преходна функционална зависимост

Функционалната зависимост R.X -> R.Y се нарича транзитивна, ако има такъв атрибут Z, че има функционални зависимости R.X -> R.Z и R.Z -> R.Y и няма функционална зависимост R.Z - / -> R.X.

Определение 4. Неключов атрибут

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

Определение 5 . Взаимно независими атрибути

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

Дотолкова доколкото първото изискване за нормална форма е основно изискване на класическия релационен моделданни, ще приемем, че първоначалният набор от отношения вече отговаря на това изискване, т.е. всички атрибути са атомни. Ако таблицата съдържа съставни атрибути, тогава можете да я конвертирате в 1NF, като използвате алгоритъм за нормализиране, предложен от E. Codd:

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

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

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

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

Пример 5.1 Разгледайте като предметна област определена организация, която изпълнява някои проекти. Описваме модела на домейна със следния неформален текст:

Служителите на организацията изпълняват проекти.

Проектите се състоят от няколко задачи.

Всеки служител може да участва в един или няколко проекта или временно да не участва в нито един проект.

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

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

Всеки служител е посочен в един отдел.

Всеки служител има телефонен номер, намиращ се в отдела на служителя.

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

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

Всеки отдел има уникален номер.

Всеки проект има номер. Номерът на проекта е уникален.

Всяка задача от проекта има номер, който е уникален в рамките на проекта.

Нека си представим диаграма на връзката (цялата информация в една таблица):

СЛУЖИТЕЛИ-ОТДЕЛИ-ПРОЕКТИ

(SOTR_NUMBER, SOTR_ZARP, DT_NUMBER, PRO_NUMBER, SOTR_SET)

Първичен ключ:

SOTR_NUMBER, PRO_NUMBER

Функционални зависимости:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

COPY_NUMBER, PRO_NUMBER -> COPY_SET

Както можете да видите, въпреки че първичният ключ е съставният атрибут SOTR_NUMBER, PRO_NUMBER, атрибутите SOTR_ZARP и DTD_NUMBER функционално зависят от частта на първичния ключ, атрибута SOTR_NUMBER. В резултат на това няма да можем да вмъкнем в релацията СЛУЖИТЕЛИ-ОТДЕЛИ-ПРОЕКТИ кортеж, описващ служител, който все още не изпълнява нито един проект (първичният ключ не може да съдържа недефинирана стойност). Когато изтриваме кортеж, ние не само разрушаваме връзката на този служител с този проект, но и губим информацията, че той работи в определен отдел. Когато прехвърляме служител в друг отдел, ще бъдем принудени да модифицираме всички кортежи, описващи този служител, или ще получим непоследователен резултат. Такива неприятни явления се наричат аномалиисхеми за взаимоотношения. Те се елиминират чрез нормализиране.

Определение 6 . Втора нормална форма(тази дефиниция предполага, че единственият ключ на връзката е първичният ключ)

Връзката R е във втора нормална форма (2NF), ако и само ако е в 1NF, и всеки неключов атрибут е напълно зависим от първичния ключ.

Можете да направите следната декомпозиция на релацията СЛУЖИТЕЛИ-ОТДЕЛИ-ПРОЕКТИ в две отношения СЛУЖИТЕЛИ-ОТДЕЛИ и СЛУЖИТЕЛИ-ПРОЕКТИ:

СЛУЖИТЕЛИ ОТ ОТДЕЛ (SOTR_NUMBER, SOTR_ZARP, DEPARTMENT_NUMBER)

Първичен ключ:

SOTR_NUMBER

Функционални зависимости:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

Първичен ключ:

SOTR_NUMBER, PRO_NUMBER

Функционални зависимости:

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

Всяка от тези две връзки е във 2NF и аномалиите, отбелязани по-горе, са елиминирани (лесно е да се провери, че всички посочени операции се извършват без проблеми).

Помислете отново за връзката СЛУЖИТЕЛ-ОТДЕЛ във 2NF. Имайте предвид, че функционалната зависимост SOTR_NUMBER -> SOTR_ZARP е преходна; това е следствие от функционалните зависимости SOTR_NUMBER -> DT_NUMBER и DT_NUMBER -> SOTR_ZARP. С други думи, заплатата на служителя всъщност не е характеристика на служителя, а на отдела, в който работи (това не е съвсем естествено предположение, но е достатъчно за пример).

В резултат на това няма да можем да въвеждаме информация, характеризираща заплатата на отдел в базата данни, докато в този отдел не се появи поне един служител (първичният ключ не може да съдържа неопределена стойност). Ако изтрием кортежа, описващ последния служител на този отдел, ще загубим информация за заплатата на отдела. За да променим заплатата на отдел по последователен начин, първо ще трябва да намерим всички кортежи, описващи служителите в този отдел. Тези. все още има аномалии в ОТДЕЛ ЗА СЛУЖИТЕЛИ. Те могат да бъдат елиминирани чрез по-нататъшно нормализиране.

Определение 7. Трета нормална форма(Дефиницията е дадена при допускането, че съществува един ключ.)

Връзката R е в трета нормална форма (3NF), ако и само ако е във 2NF и всеки неключов атрибут не зависи транзитивно от първичния ключ.

Можете да декомпозирате връзката СЛУЖИТЕЛИ-ОТДЕЛИ на две връзки СЛУЖИТЕЛИ и ОТДЕЛЕНИЯ:

СЛУЖИТЕЛИ (CODE_NUMBER, DEPARTMENT_NUMBER)

Първичен ключ:

SOTR_NUMBER

Функционални зависимости:

COPY_NUMBER -> DEPARTURE_NUMBER

ОТДЕЛЕНИЯ (DEPARTMENT_NUMBER, SOTR_ZARP)

Първичен ключ:

DEPARTMENT_NUMBER

Функционални зависимости:

DEPARTMENT_NUMBER -> SOTR_ZARP

Всяко от тези две съотношения е на 3NF и без маркирани аномалии.

Ако изоставим ограничението, че релацията има един ключ, тогава дефиницията на 3NF приема следната форма:

Определение 7 *

Връзката R е в трета нормална форма (3NF), ако и само ако е във 2NF, и всеки неключов атрибут не е транзитивно зависим от нито един ключ R.

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

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

Пример 5.2 Помислете за следния пример за диаграма на връзката:

СЛУЖИТЕЛИ-ПРОЕКТИ (SOTR_NUMBER, SATR_NAME, PRO_NUMBER, SOTR_SIGNED)

Възможни ключове:

SOTR_NUMBER, PRO_NUMBER

ПРОДАДЕНО_NAME, PRO_NUMBER

Функционални зависимости:

COP_NUMBER -> COP_NAME

SOTR_NUMBER -> PRO_NUMBER

COPY_NAME -> COPY_NUMBER

SOLD_NAME -> PRO_NUMBER

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

COPY_NAME, PRO_NUMBER -> COPY_SET

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

Според дефиницията на 7 *, връзката СЛУЖИТЕЛИ-ПРОЕКТИ е в 3NF. Въпреки това, фактът, че има функционални зависимости на атрибутите на връзката към атрибут, който е част от първичния ключ, води до аномалии. Например, за да променим името на служител с даден номер по последователен начин, трябва да модифицираме всички кортежи, които включват неговия номер.

Определение 8. Определящо

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

Определение 9 . Бойес-Код нормална форма

Връзката R е в нормална форма на Бойес-Код (BCNF), ако и само ако всяка детерминанта е възможен ключ.

Очевидно това изискване не е изпълнено за връзката СЛУЖИТЕЛИ-ПРОЕКТИ. Можете да го декомпозирате на отношенията СЛУЖИТЕЛИ и СЛУЖИТЕЛИ-ПРОЕКТИ:

СЛУЖИТЕЛИ (COPY_NUMBER, COPY_NAME)

Възможни ключове:

SOTR_NUMBER

Функционални зависимости:

COP_NUMBER -> COP_NAME

COPY_NAME -> COPY_NUMBER

СЛУЖИТЕЛИ-ПРОЕКТИ (SOTR_NUMBER, PRO_NUMBER, SOTR_SIGNED)

Възможен ключ:

SOTR_NUMBER, PRO_NUMBER

Функционални зависимости:

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

Възможна е алтернативна декомпозиция, ако изберете SOTR_NAME като основа. И в двата случая получените връзки СЛУЖИТЕЛИ и СЛУЖИТЕЛИ ПРОЕКТА се намират в BCNF и не показват отбелязаните аномалии.

Пример 5.3 Помислете за пример за следната диаграма на взаимоотношенията:

ПРОЕКТИ (PRO_NUMBER, PRO_SOTR, PRO_ZADAN)

Връзката ПРОЕКТИ съдържа номера на проекти, за всеки проект списък на служителите, които могат да изпълняват проекта, и списък на задачите, които проектът предвижда. Служителите могат да участват в множество проекти, а различните проекти могат да включват едни и същи задачи.

Всеки кортеж от връзка свързва проект със служител, участващ в този проект, и задачата, която служителят изпълнява в рамките на този проект (приемаме, че всеки служител, участващ в проекта, изпълнява всички задачи, предвидени от този проект). Поради формулираните по-горе условия, единственият възможен релационен ключ е съставният атрибут PRO_NUMBER, PRO_SOTR, PRO_DASED и няма други детерминанти. Следователно връзката ПРОЕКТИ е в БКНФ. Но в същото време има и недостатъци: ако например определен служител се присъедини към този проект, е необходимо да се вмъкнат толкова кортежи в релацията PROJECTS, колкото има задачи в нея.

Определение 10 . Многозначни зависимости

По отношение на R (A, B, C) има многозначна зависимост RA -> -> RB, ако и само ако наборът от стойности на B, съответстващи на двойка стойности на A и C, зависи само от A и не зависи от C.

По отношение на ПРОЕКТИ има следните две многозначни зависимости:

PRO_NUMBER -> -> PRO_SOTR

PRO_NUMBER -> -> PRO_SPECIFIED

Лесно е да се покаже, че в общия случай по отношение на R (A, B, C) има многозначна зависимост R.A -> -> R.B тогава и само ако има многозначна зависимост R.A -> -> R.C.

По-нататъшното нормализиране на отношенията, подобно на отношението ПРОЕКТИ, се основава на следната теорема:

Теорема на Фейгин

Съотношението R (A, B, C) може да бъде проектирано без загуби в съотношения R1 (A, B) и R2 (A, C), ако и само ако има MVD A -> -> B | ° С.

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

Определение 11 . Четвърта нормална форма

Връзката R е в четвърта нормална форма (4NF), ако и само ако, в случай на многозначна зависимост A -> -> B, всички други атрибути на R функционално зависят от A.

В нашия пример можем да декомпозираме връзката ПРОЕКТИ на две връзки ПРОЕКТИ-СЛУЖИТЕЛИ и ПРОЕКТИ-ЗАДАЧИ:

ПРОЕКТИ-СЛУЖИТЕЛИ (PRO_NUMBER, PRO_SOTR)

ПРОЕКТИ-ЗАДАЧИ (PRO_NUMBER, PRO_ZONE)

И двете от тези връзки са в 4NF и са без отбелязани аномалии.

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

Пример 5.4 Помислете например за връзката

СЛУЖИТЕЛИ-ОТДЕЛИ-ПРОЕКТИ (COP_NUMBER, DEPARTMENT_NUMBER, PRO_NUMBER)

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

Следователно съотношението е 4NF. В него обаче могат да съществуват аномалии, които могат да бъдат елиминирани чрез разлагане на три отношения.

Определение 12. Зависимост от връзката

Връзката R (X, Y, ..., Z) удовлетворява зависимостта на връзката * (X, Y, ..., Z), ако и само ако R се възстановява без загуба чрез свързване на неговите проекции върху X, Y, .. ., З.

Определение 13 . Пета нормална форма

Връзката R е в пета нормална форма (нормална форма на проекция-съединяване - PJ / NF), ако и само ако някаква зависимост на свързване в R следва от съществуването на някакъв възможен ключ в R.

Нека представим следните имена на съставни атрибути:

CO = (COP_NUMBER, DEP_NUMBER)

SP = (SOTR_NUMBER, PRO_NUMBER)

OP = (DT_NUMBER, PRO_NUMBER)

Да предположим, че има зависимост от връзката по отношение на СЛУЖИТЕЛИ-ОТДЕЛИ-ПРОЕКТИ:

* (CO, SP, OP)

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

СЛУЖИТЕЛИ ОТ ОТДЕЛ (COPY_NUMBER, DEPARTMENT_NUMBER)

СЛУЖИТЕЛИ-ПРОЕКТИ (SOTR_NUMBER, PRO_NUMBER)

ОТДЕЛЕНИЯ-ПРОЕКТИ (DEPARTMENT_NUMBER, PRO_NUMBER)

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

Коментирайте ... Ако отношенията не се нормализират, тогава възникват проблеми. излишък, потенциално несъответствие (аномалии при актуализиране), аномалии при включване, аномалии при изтриване.

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

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

Правилно структурирана основаданни:

• Помага за спестяване дисково пространствочрез изключване на ненужни данни;
• Поддържа точността и целостта на данните;
• Осигурява удобен достъп до данни.

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

1. Анализиране на изискванията или определяне на предназначението на базата данни;
2. Организиране на данните в таблици;
3. Индикация на първични ключове и анализ на връзките;
4. Нормализиране на таблиците.

Помислете за всеки фаза на проектиране на база даннив повече детайли. Имайте предвид, че този урок се фокусира върху модела на релационна база данни на Едгар Код, написан на SQL език (не йерархичен, мрежов или обектен модел).

Анализ на изискванията: Дефиниране на целта на базата данни

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

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

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

Започнете със събиране на съществуващи данни, които да бъдат включени в базата данни. След това дефинирайте типовете данни, които искате да съхранявате. Както и обекти, които описват тези данни. Например:

Клиенти

• Адрес;
• Град, щат, пощенски код;
• Имейл адрес.

Стоки

• Име;
• Цена;
• Количество на склад;
• Количество по поръчка.

Поръчки

• Номер на поръчка;
• Търговски представител;
• Дата;
• Продукт;
• количество;
• Цена;
• Цена.

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

След като решите какви данни ще бъдат включени в базата данни, откъде ще идват тези данни и как ще бъдат използвани, можете да започнете да планирате действителната база данни.

Структура на базата данни: градивни елементи

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

За да конвертирате списъци с данни в таблици, започнете със създаване на таблица за всеки тип обект, като продукти, продажби, клиенти и поръчки. Ето един пример:

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

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

• CHAR - специфична дължина на текста;
• VARCHAR - текст с различна дължина;
• ТЕКСТ - голямо количество текст;
• INT - положително или отрицателно цяло число;
• FLOAT, DOUBLE - числа с плаваща запетая;
• BLOB са двоични данни.

Някои СУБД предлагат и тип данни Autonumber, който автоматично генерира уникален номер на всеки ред.

V визуално представяне DB всяка таблица ще бъде представена с блок в диаграмата. Заглавието на всеки блок трябва да показва какво описват данните в тази таблица, а атрибутите трябва да бъдат изброени по-долу:

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

Атрибутите, избрани като първични ключове, трябва да бъдат уникални, неизменяеми и не могат да бъдат NULL ( те не могат да бъдат празни). Поради тази причина номерата на поръчките и потребителските имена са подходящи първични ключове, но телефонните номера или адресите не са. Можете също да използвате няколко полета едновременно като първичен ключ ( това се нарича композитен ключ).

Когато дойде време за създаване на действителната DB, вие прилагате както логическата, така и физическата структура чрез езика за дефиниране на данни, поддържан от вашата СУБД.

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

Създаване на връзки между обекти

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

Всеки обект може да бъде свързан помежду си с друг чрез един от трите типа връзки:

Комуникация един към един

Когато има само един екземпляр на A за всеки екземпляр на B, се казва, че имат връзка едно към едно ( често се обозначава 1:1). Можете да посочите този тип връзка в ER диаграмата с линия с тире във всеки край:

Когато проектирате и разработвате своите бази данни, ако нямате причина да споделяте тези данни, връзката 1:1 обикновено показва, че е по-добре да комбинирате тези таблици в една.

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

За да сте сигурни, че данните корелират правилно, ще трябва да включите поне, една идентична колона във всяка таблица. Това най-вероятно ще бъде първичният ключ.

Връзка едно към много

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

За да приложите връзка 1: M, добавете първичния ключ от „една“ таблица като атрибут към друга таблица. Когато първичен ключ е посочен в друга таблица по този начин, той се нарича външен ключ. Таблицата от страната „1“ на връзката е родителската таблица за дъщерната таблица от другата страна.

Връзка много към много

Когато множество обекти на таблица могат да бъдат свързани с множество други обекти. Казват, че имат връзка " много към много» ( М: Н). Например, в случай на студенти и курсове, тъй като студентът може да посещава много курсове и всеки курс може да бъде посещаван от много студенти.

В диаграмата ER тези връзки се показват с помощта на следните редове:

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

За да направите това, трябва да създадете нов обект между тези две таблици. Ако има връзка M:N между продажбите и продуктите, можете да наречете това нов обект « продадени_продукти„Тъй като ще съдържа данни за всяка продажба. Както таблицата за продажби, така и таблицата с продуктите ще имат връзка 1: M с sold_products. Този вид междинен обект в различни моделинаречена таблица с връзки, асоциативен обект или таблица с връзки.

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

Задължително ли е или не?

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

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

Рекурсивни връзки

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

Допълнителни връзки

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

Нормализиране на базата данни

След предварително проектиране на базата данни могат да се приложат правила за нормализиране, за да се гарантира, че таблиците са структурирани правилно.

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

Бази данни с интерактивни аналитична обработка (OLAP), които правят анализа на данните по-лесен и по-бърз, могат да бъдат по-ефективни с известна степен на денормализация. Основният критерий тук е скоростта на изчисленията. Всяка форма или ниво на нормализиране включва правила, свързани с по-ниските форми.

Първата форма на нормализиране

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

Може да се изкушите да заобиколите това ограничение, като разделите данните на допълнителни колони. Но това също е против правилата: таблица с групи от повтарящи се или плътно свързани атрибутине отговаря на първата форма на нормализиране. Например таблицата по-долу не съвпада с 1NF:

Вместо това, по време на физическия дизайн на базата данни, разделете данните на множество таблици или записи, докато всяка клетка съдържа само една стойност и няма допълнителни колони. Такива данни се считат за дезагрегирани до най-малките полезен размер... В горната таблица можете да създадете допълнителна маса « Подробности за продажбите», Което ще отговаря на конкретни продукти с продажби. „Продажби“ ще има връзка 1:М с „ Подробности за продажбите».

Втора форма на нормализиране

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

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

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

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

• Номер на поръчката (първичен ключ);
• Идентификатор на продукта (първичен ключ);
• Име на продукта.

Третата форма на нормализиране

Третата форма на нормализиране ( 3NF) : всяка неключова колона трябва да бъде независима от всяка друга колона. Ако при дизайн на релационна база даннипромяна на стойност в една неключова колона причинява промяна в друга стойност, тази таблица не съответства на третата форма на нормализиране.

Според 3NF, не можете да съхранявате никакви извлечени данни в таблица, като например колоната Данъчни, която в примера по-долу директно зависи от крайна ценапоръчка:

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

Многоизмерни данни

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

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

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

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

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

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

Добавяне на индекси и изгледи

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

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

Изгледът е запазена заявка за данни. Изгледите могат да включват данни от множество таблици или да показват част от таблица.

Разширени свойства

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

SQL и UML

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

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

Системи за управление на бази данни

Структурата на проектираната база данни зависи от това коя СУБД използвате. Някои от най-често срещаните:

• Oracle DB;
• MySQL;
• Microsoft SQL Server
• PostgreSQL;
• IBM DB2.

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

Превод на статията " Урок за структура и дизайн на база данни»Приятелски екип по проекта

В първата статия от поредицата "Данни в WordPress" направих преглед на използването на релационни бази данни в WordPress: какви таблици се използват и какви данни ...

За да защити поверителни данни, MySQL 5.7 въведе възможността за криптиране на данни с помощта на двигателя InnoDB. В тази статия ще обясня принципите на криптиране на база данни, ...