Infological база данни за моделиране - участник

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

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

Същността на "Отдел", "Заявител", "учител", "обект учебен план", "Групата".

Определяне на същността на "Майор" в модела на ER

Фиг. 2. Определяне на същността на "участник" в модела на ER

Фиг. 3. Определяне на същността на "учител" в модела на ER

Фиг. 4. Определяне на същността на "дисциплина" в модела на ER

Фигура 5. Определяне на същността на "Групата" в модела на ER

Релационна схема на база данни "образователен процес" е представена от следните таблици:

"Група" - съдържа един ред за всяка група;

"Студентите" - съдържа един ред за всеки от учениците;

"Отдел" - съдържа един ред за всеки от отдели;

"Учителю" - съдържа един ред за всеки от преподаватели;

"Относно" - съдържа един ред за всеки от субектите;

"Учебна програма" - съдържа един ред за всеки клас на всеки предмет на отделна семестър;

"Прогрес" - съдържа един ред за всеки резултат от пускането на отделни студенти отделна дисциплина.

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

· Всяка таблица колона е неделима, и в рамките на една маса със същите колоните имат стойности смисъла (1NF);

· Първичният ключ идентифицира еднозначно запис и nonredundant, всички полета на всяка маса зависи от неговия първичен ключ (2NF);

· Стойността на всяка област не е включена в първичния ключ не зависи от стойността на друго поле, не са включени в първичния ключ (3NF).

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

Структурата на базата данни

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

Съобщение "един към много" (1: M), един от "Учител" и много от "участник"

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

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

Субекти, които са разделени на силните и слабите страни. Essence е слаб, ако неговото съществуване зависи от друго предприятие - силен по отношение на него.

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

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

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

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

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

1. "заявителите комбинирани в" групи "(комуникации M: 1).

2. "учител" организира работни "Столове" (М нас: 1).

3. "Учителите" научи "предмет на програма" (връзка 1: N).

5. "Кандидатите" седни "Дисциплините" (връзка M: м).

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

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

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

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

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

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

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

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

1. S. Atre структурен подход към организацията на бази данни. - М. финансов и статистика, 1983 - 320 стр.

2. Бойко VV Savinkov VM Проектиране на информационни системи за бази данни. - М. финансов и статистика, 1989. - 351 стр.

3. К. Дата е на RDBMS DB2 Ръководство. - М. финансов и статистика, 1988. - 320 стр.

7. М. Meyer теория на релационна база данни. - Мир, 1987 - 608 стр.

8. Tiori Т. Дж Фрай. Проектиране структури на бази данни. В 2 книги. - Мир, 1985. Кн. 1-287. Vol. 2. - 320 стр.

10. Дж Хъбард. Компютърна база данни за дизайн. - Мир, 1984 - 294, стр.

11. Г. Tsikritizis Lokhovsky F. Модел на данни. - М. Финанси и статистика, 1985 г. - 344 стр.