Қатынас айналымы мен нысаналар моделі

Кіріспе

Бір-бірімен байланысты нәрселерді сипаттайтын модель немесе схема

Entity-relationship модельі (немесе ER моделі) белгілі бір білім саласындағы өзара байланысты қызығушылық тудыратын нысаналарды сипаттайды. ER моделінің негізі нысана түрлерінен (қызығушылық тудыратын нысаналарды жіктеу үшін) тұрады және нысаналар арасындағы қатынастарды (осы нысана түрлерінің мысалдары) анықтайды. Бағдарламалық жасақтауда ER моделі көбінесе бизнес процестерін жүзеге асыру үшін бизнестің есте сақтау қажеттігін бейнелеу үшін құрылады. Осының салдарынан ER моделі дерекқорда, әдетте реляциялық дерекқорда іске асырылатын дерек немесе ақпарат құрылымын анықтайтын абстрактілі дерек моделіне айналады. Entity-relationship модельдеуін Питер Чен дерекқор және дизайн үшін әзірледі және 1976 жылы жариялаған, одан бұрын идеяның басқа да нұсқалары болған. Бүгінде ол студенттерге дерекқор құрылымының негіздерін оқыту үшін кеңінен қолданылады. Кейбір ER модельдері жалпылау және мамандандыру қатынастары арқылы байланысты супер және субтип нысаналарын көрсетеді, сондай-ақ ER моделі салалық онтологияларды нақтылау үшін де қолданылуы мүмкін.

Кіріспе

ER моделі әдетте бизнес-аймақтағы процестерде жасалатын және қажетті деректерді анықтау мен сипаттау үшін жүйелі талдаудың нәтижесі болып табылады. Әдетте, ол бизнес процестерінің өзі емес, бизнес процестері бақылайтын және басқаратын объектілер мен оқиғалардың жазбаларын көрсетеді. Ол әдетте графикалық түрде, объектілер (бұйымдар) ретінде бейнеленеді, олар сызықтармен (қатынастар) байланыстырылады, бұл объектілер арасындағы байланыстар мен тәуелділіктерді көрсетеді. Бұл мәтінмен де айтылуы мүмкін, мысалы: бір ғимарат нөл немесе одан көп пәтерге бөлінуі мүмкін, бірақ бір пәтер тек бір ғимаратта орналасуы мүмкін. Объектілер тек қатынастармен ғана емес, сонымен қатар "бірінші кілттер" деп аталатын идентификаторларды қамтитын қосымша қасиеттермен (атрибуттармен) анықталуы мүмкін. Атрибуттарды, сондай-ақ объектілер мен қатынастарды көрсету үшін жасалған диаграммалар объектілік қатынас модельдері емес, объектілік қатынас диаграммалары деп аталады. ER моделі әдетте деректер базасы ретінде іске асырылады. Қарапайым реляциялық деректер базасындағы іске асыруда кестедегі әрбір қатар бір объекті түрінің бір данасын, ал кестедегі әрбір өріс атрибут түрін көрсетеді. Реляциялық деректер базасында объектілер арасындағы қатынас бір объектінің бірінші кілтін екінші объекті кестесінде сілтеме немесе "шетелдік кілт" ретінде сақтау арқылы іске асырылады. ER/дерек модельдерін екі немесе үш абстракция деңгейінде құру дәстүрі бар. Төмендегі тұжырымдамалық, логикалық, физикалық иерархия басқа да сипаттамалар үшін қолданылады және бағдарламалық жасақтаманы жобалаудағы үш схемалық тәсілден өзгеше. Тұжырымдамалық деректер моделі Бұл ең жоғары деңгейдегі ER моделі, себебі ол ең аз егжей-тегжейлі мәліметтерді қамтиды, бірақ модель жиынтығына кіретін нәрсенің жалпы ауқымын белгілейді. ER-дің тұжырымдамалық моделі әдетте ұйым кеңінен қолданатын эталондық деректердің объектілерін анықтайды. Кәсіпорынға кең ауқымды тұжырымдамалық ER моделін жасау ұйым үшін деректер архитектурасын құжаттауға көмектеседі. ER-дің тұжырымдамалық моделі бір немесе бірнеше логикалық деректер моделінің негізі ретінде пайдаланылуы мүмкін (төменде қараңыз). Тұжырымдамалық ER моделінің мақсаты логикалық ER модельдері жиынтығы арасындағы негізгі деректер объектілері үшін құрылымдық метадеректердің ортақтығын белгілеу болып табылады. Тұжырымдамалық деректер моделі ER модельдері арасындағы ортақтық қатынастарды құру үшін, деректер моделін интеграциялау үшін негіз ретінде пайдаланылуы мүмкін. Логикалық деректер моделі Логикалық ER моделіне тұжырымдамалық ER моделі міндетті емес, әсіресе егер логикалық ER моделінің қолданылу аясына тек бөлек ақпараттық жүйені дамыту кірсе. Логикалық ER моделі тұжырымдамалық ER моделіне қарағанда толықрақ болады. Бастамалық деректер объектілерінен басқа, операциялық және транзакциялық деректер объектілері анықталады. Әрбір дерек объектісінің егжей-тегжейлі сипаттамасы жасалады және осы деректер объектілері арасындағы қатынастар орнатылады. Алайда логикалық ER моделі оны іске асыруға болатын нақты деректер базасын басқару жүйесіне тәуелсіз жасалады. Физикалық деректер моделі Әр логикалық ER моделінен бір немесе бірнеше физикалық ER моделі жасалуы мүмкін. ER физикалық моделі әдетте деректер базасы ретінде құрылады. Сондықтан әрбір ER физикалық моделі деректер базасын жасау үшін жеткілікті егжей-тегжейлі болуы керек және әрбір ER физикалық моделі технологияға тәуелді, себебі әр деректер базасын басқару жүйесі біршама өзгеше. Физикалық модель әдетте деректер базасын басқару жүйесінің құрылымдық метадеректерінде деректер базасы кестелері, бірегей кілт индекстері сияқты деректер базасы индекстері және шетелдік кілт шектеуі немесе ортақ шектеу сияқты деректер базасы шектеулері сияқты реляциялық деректер базасы объектілері ретінде көрсетіледі. ER моделі сонымен қатар реляциялық деректер базасы объектілеріне өзгерістерді жобалау және деректер базасының құрылымдық метадеректерін сақтау үшін де қолданылады. Ақпараттық жүйені жобалаудың бірінші кезеңінде осы модельдерді талаптарды талдау кезінде ақпараттық қажеттіліктерді немесе деректер базасында сақталуға тиіс ақпарат түрін сипаттау үшін пайдаланады. Деректерді модельдеу әдісі белгілі бір қызығушылық саласы үшін кез келген онтологияны (яғни пайдаланылатын терминдер мен олардың қатынастарының шолулары мен жіктелулерін) сипаттауға пайдаланылуы мүмкін. Деректер базасына негізделген ақпараттық жүйені жобалау жағдайында тұжырымдамалық деректер моделі кейінірек кезеңде (әдетте логикалық жобалау деп аталады) логикалық деректер моделіне, мысалы реляциялық модельге бейімделеді. Бұл өз кезегінде физикалық жобалау кезінде физикалық модельге бейімделеді. Кейде осы екі кезең де "физикалық жобалау" деп аталады.

An ER model usually results from systematic analysis to define and describe the data created and needed by processes in a business area. Typically, it represents records of entities and events monitored and directed by business processes, rather than the processes themselves. It is usually drawn in a graphical form as boxes (entities) that are connected by lines (relationships) which express the associations and dependencies between entities. It can also be expressed in a verbal form, for example: one building may be divided into zero or more apartments, but one apartment can only be located in one building. Entities may be defined not only by relationships, but also by additional properties (attributes), which include identifiers called "primary keys". Diagrams created to represent attributes as well as entities and relationships may be called entity attribute relationship diagrams, rather than entity–relationship models. An ER model is typically implemented as a database. In a simple relational database implementation, each row of a table represents one instance of an entity type, and each field in a table represents an attribute type. In a relational database a relationship between entities is implemented by storing the primary key of one entity as a pointer or "foreign key" in the table of another entity. There is a tradition for ER/data models to be built at two or three levels of abstraction. The conceptual logical physical hierarchy below is used in other kinds of specification, and is different from the three schema approach to software engineering. Conceptual data model
This is the highest level ER model in that it contains the least granular detail but establishes the overall scope of what is to be included within the model set. The conceptual ER model normally defines master reference data entities that are commonly used by the organization. Developing an enterprise wide conceptual ER model is useful to support documenting the data architecture for an organization. A conceptual ER model may be used as the foundation for one or more logical data models (see below). The purpose of the conceptual ER model is then to establish structural metadata commonality for the master data entities between the set of logical ER models. The conceptual data model may be used to form commonality relationships between ER models as a basis for data model integration. Logical data model
A logical ER model does not require a conceptual ER model, especially if the scope of the logical ER model includes only the development of a distinct information system. The logical ER model contains more detail than the conceptual ER model. In addition to master data entities, operational and transactional data entities are now defined. The details of each data entity are developed and the relationships between these data entities are established. The logical ER model is however developed independently of the specific database management system into which it can be implemented. Physical data model
One or more physical ER models may be developed from each logical ER model. The physical ER model is normally developed to be instantiated as a database. Therefore, each physical ER model must contain enough detail to produce a database and each physical ER model is technology dependent since each database management system is somewhat different. The physical model is normally instantiated in the structural metadata of a database management system as relational database objects such as database tables, database indexes such as unique key indexes, and database constraints such as a foreign key constraint or a commonality constraint. The ER model is also normally used to design modifications to the relational database objects and to maintain the structural metadata of the database. The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i. e. an overview and classifications of used terms and their relationships) for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model. This in turn is mapped to a physical model during physical design. Sometimes, both of these phases are referred to as "physical design."

Қарым-қатынастар, рөлдер және негізгі қасиеттер

Ченнің алғашқы еңбегінде қарым-қатынас және оның рөлдері туралы мысал келтірілген. Ол "неке" қарым-қатынасын және оның екі рөлін, "күйеу" мен "әйел" деп сипаттайды. Бір адам некеде (қарым-қатынаста) күйеу рөлін ойнайды, ал екінші адам (сол) некеде әйел рөлін ойнайды. Бұл сөздер зат есімдер. Ченнің терминологиясы бұрынғы идеяларға да қолданылды. Кейбір диаграммалардағы сызықтар, жебелер және "қарақас" белгілері Ченнің қарым-қатынас диаграммаларына қарағанда Бахманның бұрынғы диаграммаларына көбірек қарызды. Ченнің моделіне тағы бір жиі қолданылатын кеңейту – қарым-қатынастар мен рөлдерді етістіктер немесе сөз тіркестері арқылы "атау".

Рөлдерді атау

Сондай-ақ, рөлдерді "иесі" және "иеленуде" сияқты тіркестермен атау кең таралды. Бұл жағдайда дұрыс атаулар – ие және меншік. Осылайша, адам ие рөлін, ал көлік меншік рөлін атқарады, адам "иесі" рөлін атқарады деп айтудың орнына. Семантикалық модельдерден физикалық жүзеге асыруды жасағанда атауларды қолдану тікелей пайда береді. Егер адамның көлікке қатысты екі қатынасы болса, "иесі адам" және "жүргізуші адам" сияқты бірден түсінікті атауларды жасау мүмкін.

Модельдің пайдалану мәселесі

Модельделген деректер қорын пайдаланушылар екі белгілі мәселеге тап болуы мүмкін, онда қайтарылған нәтижелер сұраныс авторы күткен нәтижелерден өзгеше болып шығады. Біріншісі – "желкен тұзағы". Бұл бірден көп қатынаста бірнеше кестеге сілтеме жасайтын (негізгі) кестеде пайда болады. Мәселе өз атауын модельдің қатынастар диаграммасында бейнеленген кездегі түрінен алады: байланысты кестелер негізгі кестеден "таралып шығады". Бұл модель түрі деректер қоймаларында қолданылатын жұлдыз схемасына ұқсас. Негізгі кестеде стандартты SQL арқылы жиынтықтардың қосындысын есептеуге тырысқанда күтпеген (және қате) нәтижелер пайда болуы мүмкін. Шешім – модельді немесе SQL сұранысын түзету. Бұл мәселе көбінесе шешімдерді қолдау жүйелерінің деректер базаларында кездеседі, ал мұндай жүйелерге сұрау салуға арналған бағдарламалық құралдар кейде осы мәселені шешудің арнайы әдістерін қамтиды. Екінші мәселе – "қақпа тұзағы". Қақпа тұзағы модель нысандар арасындағы қатынастың бар екенін көрсететін кезде пайда болады, бірақ белгілі бір нысандар арасындағы байланыс жоқ. Мысалы, ғимараттың бір немесе бірнеше бөлмесі бар, онда нөл немесе одан көп компьютерлер орналасқан. Модельге сұраныс жіберіп, ғимараттағы барлық компьютерлерді көруге болады деп күтуге болады. Алайда, қазіргі уақытта бөлмеге тағайындалмаған компьютерлер (жөндеуде немесе басқа жерде болғандықтан) тізімде көрсетілмейді. Ғимарат пен Компьютер арасындағы тағы бір қатынас ғимараттағы барлық компьютерлерді қамту үшін қажет. Бұл соңғы модельдеу мәселесі модельде нақты әлемдегі барлық қатынастарды бейнелеуге қабілетсіздіктен туындайды. Толық мәліметтер үшін Нысандық қатынас модельдеу 2-бөлімін қараңыз.

Семантикалық модель

Семантикалық модель – ұғымдардың моделі және кейде "платформаға тәуелсіз модель" деп аталады. Бұл – интенциялық модель. Кем дегенде Карнаптан бері белгілі болғандай: "Кез келген ұғымның толық мағынасы екі аспектіден тұрады: оның интенциясы және экстенсиясы. Біріншісі – ұғымның ұғымдар әлеміндегі орны, яғни басқа ұғымдармен байланыстарының жиынтығы. Екіншісі – ұғымның анықтамалық мағынасын, яғни нақты немесе мүмкін әлемдегі көрінісін анықтайды".

Ұзарту үлгісі

Экстенсиялық модель – белгілі бір әдістеме немесе технология элементтерімен байланыстырылатын модель, сондықтан ол "платформаға тәуелді модель" болып табылады. UML спецификациясы кластық модельдердегі қатынастар экстенсиялық екенін нақты көрсетеді, және бұл спецификация ұсынған, бұрынғы "семантикалық модельдеу тілдерінің" ешқайсысы ұсынбаған, көптеген қосымша "безендірулер" арқылы өзінен-өзі түсінікті болады. "UML деректерді модельдеу нотациясы ретінде, 2-бөлім"

Философиялық сәйкестік

Чен ежелгі грек философтары Платон мен Аристотельдің философиялық дәстүрлерімен үндеседі. Платонның өзі білімді өзгермейтін Тұлғаларды (яғни, заттардың көптеген түрлерінің және олардың қасиеттерінің архетиптері немесе абстрактілі бейнелері) және олардың бір-бірімен байланыстарын қабылдаумен байланыстырады.