Знайте, Intuit, лекция, моделиране Infological

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

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

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

Проблемът с представяне на семантиката има дълъг заинтересованите разработчици, както и няколко от тези модели са предложени през седемдесетте години, наречени семантичните модели. Те включват семантичен модел на данните. предложен Hammer (Hammer) и Mac-Леон (McLeon) през 1981 г., функционален модел на данните Шипман на (Шипман), също е създаден през 1981 г., моделът "същност- отношения", предложен от Chen (Chen) през 1976 г., както и редица други модели , Всички модели имат своите предимства и недостатъци, но той е издържал изпитанието на времето, само последният. И в момента, това е модел на Чен "субект-връзка" или "субект на връзката", се превърна в де факто стандарт за моделиране Infological бази данни. Стана общоприето съкращение ER-модел, по-голямата част от съвременните съдебна инструменти включват инструменти за описване на данните в формализма на модела. В допълнение, техники, разработени за автоматично преобразуване от проект ER-DB в релационния модел, превръщането се извършва в datalogicheskuyu модел, съответстващ на дадена СУБД. Всички съдебна системи са разработили средства за документиране на процеса на разработване на база данни. автоматични генератори доклад позволяват да се изготви доклад за текущото състояние на базата данни на проект с подробно описание на обектите на базата данни и взаимоотношенията им в графичен вид и под формата на готови стандартни отпечатани доклади, което значително улеснява управлението на проекта.

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

Модел "същност- отношения"

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

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

В сърцето на ER-модел се основава на следните основни понятия:

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

Фиг. 7.1. Пример определяне субект в модела на ER

Между образувания могат да бъдат установени връзка - двоични асоциации. показващ как си взаимодействат корелира юридическото лице или. Съобщението може да съществува между две различни единици или между същество и тя се (рекурсивни връзка) .Той показва как случаи на лица са свързани един с друг. Ако се установи комуникация между двата субекта, той определя връзката между случаи на другото предприятие. Например, ако имаме връзка между същността на "студент" и същността на "учител" и тази връзка - диплома за управление на проекти, като всеки студент има само една глава, но един и същ учител може да доведе много специализанти. Следователно, той ще се свърже "един към много" (1: M), един от "Учител" и много от "Student" (виж Фигура 7.2 ..).

Фиг. 7.2. Един пример за връзката "един към много отношения" в задължителен субект "студент" и "учител"

Различни означения комуникация капацитет е изобразена по различни начини. В нашия пример, ние използваме нотация система CASE POWER дизайнер, тук представена от множество разделителни линии, дължащи се на 3. Комуникацията е общо наименование "завършил дизайн" и има роля имена от двете организации. От страна на студента, тази роля се нарича "Напиши диплома под ръководството" от страна на учителя, тази връзка се нарича "успя". Графичен интерпретация на комуникация дава възможност веднага да се чете по смисъла на отношенията между лица, то се на видно място и лесно да се интерпретира. Съобщенията са разделени на три типа според множеството един към един (1: 1), едно-към-много (1: M), много-към-много (М: М). Едно към едно отношения означава, че например в едно предприятие е свързано само с едно копие на друго предприятие. Съобщение 1: М означава, че един случай на предприятието. разположен от лявата страна на комуникация може да се свързва с множество копия на лице, разположен в дясната връзка. Съобщение "един към един" (1: 1) означава, че един случай на едно лице е свързан само с едно копие на друг субект, и съобщава "много към много" (М: M) означава, че едно копие на първото лице може се свързва с множество копия на второто лице, и обратно, едно копие на второто лице може да бъде свързан с множество копия на първото лице. Например, ако вземем предвид връзката на "обучение" между субекти, "Студентски" и "дисциплина", това е връзката на "много към много" (М: M), така че всеки ученик може да научи няколко дисциплини, но всяка дисциплина с най-различни ученици. Такава връзка е показан на фиг. 7.3.

Между две лица могат да се дават различен брой връзки с различно значение. Например, между две лица "студентски" и "учител" да инсталирате два семантични връзки, един - считат по-рано ", завършил дизайн", а втората може да бъде условно наречени "лекции", и определя лекциите, които учителите слушат студента и как студенти от лекциите на учителя. Ясно е, че този тип връзка, много-към-много отношения Пример за това е показан на Фиг. 7.3.

Фиг. 7.3. Пример комуникация симулация "много към много"

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

Фиг. 7.4. Пример задължителни и незадължителни комуникация между лица