База данни. Концептуален дизайн на база данни

Оставете коментар 6,950

Концептуален дизайн

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

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

Автоматизирани системи за поддръжка на етап идеен проект

Образът на обект или негов компонентимогат да бъдат създадени в човешкото въображение в резултат на творчески процес или генерирани в съответствие с някои алгоритми в процеса на взаимодействие между човек и компютър, използвайки автоматизирани системиподпомагане на етапа на идеен проект. Работа по тази тема е извършена от учени като А. И. Половинкин, М. Ф. Зарипов, В. А. Камаев, Р. Колер, А. М. Дворянкин, В. А. Глазунов, С. А. Фоменков, В. М. Цуриков и др.

Има няколко известни подхода, които са в основата на такива автоматизирани системи [автоматизирана система]:

  • Формализирано описание на естествените науки и научно-техническите ефекти въз основа на онтологията на научно-техническите характеристики.
  • Теория за решаване на изобретателски проблеми (ТРИЗ).
  • Енергоинформационен модел на вериги и структурен метод параметрични вериги(EIMC).
  • Система за структуриране на физически знания и дизайн на търсене.

Литература

  • “Проект за създаване на база от знания за физични и технологични ефекти”, Доклади на международната конференция TC-1. Обучение по измервания и уреди - предизвикателства на Нови технологии: Сборник, Вроцлав - 2002, С. 171-176 ISBN 83-7085-647-0. Зарипова В. М., Зарипов М. Ф., Петрова И. Ю.
  • Приложение на обектни технологии за анализ и проектиране на системи за търсене на нови технически решения (на примера на системите Intellect и Sapfit). Информационни технологии в образованието и медицината: Сборник на международната конференция - 2004 г. - Волгоград: Издателство VolgSTU, 2004 г. Зарипова В. М., Камаев В. А.

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

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

    концептуален дизайн- 3.6.5. концептуален дизайн: Етапът на софтуер за проектиране, извършен чрез системата CAE|CAB (CAE Computer Aided Engineering, CAD Computer Aided Design), по време на който се разработва външният вид на продукта (под формата на геометричен 3D модел)… …

    Процесът на създаване на схема на база данни и дефиниране на необходимите ограничения за интегритет. Съдържание 1 Основни задачи на проектирането на бази данни ... Wikipedia

    Андрей Георгиевич Теслинов [[Файл... Wikipedia

    50.1.031-2001: Информационни технологии за поддържане на жизнения цикъл на продукта. Терминологичен речник. Част 1. Етапи на жизнения цикъл на продукта- Терминология 50.1.031 2001: Информационни технологии за поддържане на жизнения цикъл на продукта. Терминологичен речник. Част 1. Етапи на жизнения цикъл на продукта: 3.7.12. (общо) управление на качеството: Общо софтуери данни... Речник-справочник на термините на нормативната и техническата документация

    R 50.1.031-2001: Информационни технологии за поддържане на жизнения цикъл на продукта. Терминологичен речник. Част 1. Етапи на жизнения цикъл на продукта- Терминология R 50.1.031 2001: Информационни технологии за поддържане на жизнения цикъл на продукта. Терминологичен речник. Част 1. Етапи на жизнения цикъл на продукта: 3.7.12. (цялостно) управление на качеството: Набор от софтуер и... ... Речник-справочник на термините на нормативната и техническата документация

    В Wikipedia има статии за други хора с това фамилно име, вижте Камаев. Камаев Валери Анатолиевич Дата на раждане: 30 май 1940 г. (1940 05 30) (72 години) Място на раждане: Омск Страна ... Wikipedia

    DEMO (DEMOnstration Power Plant) е проект на електроцентрала, използваща термоядрен синтез. Строителството е планирано след успешното пускане в експлоатация на ITER. Времева рамка на проекта През 2004 г. беше предложена следната времева рамка на проекта: ... ... Wikipedia

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

    Спартак Петрович Никаноров Дата на раждане: 30 август 1923 г. Място на раждане: Москва, СССР Спартак Петрович Ник ... Wikipedia

    S1000 е малка неядрена подводница. Съвместна разработка на Италия и Русия. Разработването на проекта започва през 2004 г технически спецификациии с финансиране от италианския флот. Първият етап от работата беше завършен през февруари 2005 г. ... ... Wikipedia

Книги

анотация

ПРОБЛЕМИ НА КОНЦЕПТУАЛНИЯ ПРОЕКТ НА ТЕХНИЧЕСКИ ОБЕКТИ

Бутенко Л.Н.

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

Проблеми на идейния дизайн

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

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

ПРОБЛЕМИ НА КОНЦЕПТУАЛНИЯ ПРОЕКТ НА ТЕХНИЧЕСКИ ОБЕКТИ

Бутенко Л.Н.

Волгоградски държавен технически университет
400131, Волгоград, проспект. В И. Ленина, 28 г., [имейл защитен]

„Който не мисли за далечни трудности,
Неприятностите със сигурност ни очакват“.
Конфуций

„Главата – тя може всичко.“ Граф Калиостро
Григорий Горин "Формула на любовта"

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

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

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

Най-добрите методи за автоматизация на програмирането (логическо, структурно и обектно-ориентирано програмиране, CASE технологии) не включват разработени когнитивни инструменти. Мощните инструменти за автоматизация на дизайна (например AutoCAD) нямат средства за представяне на сложни развиващи се обекти.

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

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

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

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

Синергетиката се занимава с физически или физикалистични процеси.

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

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

Ето някои основни дефиниции:

Концепция(лат. conceptus - понятие) - понятие;

Срок "идеен" обозначава естеството на процес (описание, представяне и т.н.) или обект (модел, структура, резултат и т.н.), характеризиращ се с това, че качествената сигурност на обектите е представена под формата на концепции; Концептуалното мислене е основната способност на човешкото мислене да „свива“ и обобщава информация от всякакъв вид с висока скорост. Конволюцията на информация може да бъде отразена в понятия, числа, времева или пространствена структура.

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

Най-съвременната дефиниция на системата е дадена в

Система= (елементи, взаимоотношения, външна среда, наблюдател, език)

Нека разгледаме проблемите на концептуалния дизайн от гледна точка на съвременното представяне на това, което се нарича система. Първото нещо, което хваща окото ви е, че тази дефиниция е статична; тя не съдържа правила за изграждане на системи. Само в напоследъкв дефиницията се появяват нови обекти, които влияят на ефективността на концептуалния процес на проектиране на системи, например Observer (дизайнер), Language (дизайнерски език). Формулировката на първия проблем е, че за да се гарантират свойствата на системата, трябва да се създадат масиви от правила за тяхното осигуряване. Ето списък с инвариантни свойства на системата, които образуват кортеж:

S = (a, b, c, d, f, … , ),

където: a – първичността на цялото (системата); b–неадитивност на системата;c–размерност на системата;d–сложност на структурата на системата;e–твърдост на системата;f–вертикална цялост на системата;g–хоризонтална изолация на системата;h – йерархия на системата; i – множество (различни по дълбочина) описания на системата; j – взаимозависимост на системата и външната среда; k – степен на независимост на системата; m – съвместимост на системата система;n – наследственост на системата;p – приоритет на системата;r – надеждност на системата;t –несигурност на информационното осигуряване на системата;u–възникване на системата;v–мултипликативност на системата;w–непрекъснатост на функционирането и развитието на системата;x–алтернативност на начините на функциониране и развитие на системата; y – синергия на системата z – адаптивност на системата – ниво на стандартизация на системата.

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

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

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

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

Идея– форма на мислено разбиране на явленията от обективната реалност;

Идеяе термин, заобиколен от съответните знания;

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

Пълната верига на развитие на идеята за обект като система е посочена в: Наблюдателят генерира намерения, т.е. първоначални намерения в границите на аспекта. Следващата стъпка в проявлението на една идея е резултат от развитието на намерението в конкретна среда. Тук знанието вече може да бъде „разгледано”; то е израз на същността на явлението. Следва етапът на проявление на същността. Това е етапът на формиране на системата, тук същността като цяло разкрива различията в нейните части. и „накрая“ етапът на изкачване до класове системи с помощта на нови аксиоми. Както следва от описанието, въпросът за това как се появява една идея е много сложен и процедурите за нейното усложняване, които се случват в Наблюдателя, не са описани достатъчно ясно в психологията. В психолингвистиката беше изяснено понятието понятие и се оказа, че понятието не е еквивалентно на термина понятие. Понятието съществува в човешкия мисловен свят не под формата на ясни понятия, а като „пакет“ от идеи, концепции, знания, асоциации, опит, който придружава думата. Понятията не само се мислят, те се „преживяват“, те са обект на емоции, харесвания и нехаресвания, а понякога и сблъсъци. Концепцията се тълкува като определена основна когнитивна единица, която позволява да се свърже значението с използваната дума, като смислена единица от процеса на концептуализация, чрез който реалността се пречупва в главата на човек.

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

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

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

Библиография:

1. Никаноров С. П. Метод за концептуално проектиране на системи за управление на организацията и неговото приложение. Електронно научно-информационно списание “СИСТЕМНО УПРАВЛЕНИЕ. ПРОБЛЕМИ и РЕШЕНИЯ" http://www.situation.ru/app/j_art_960.htm

2. Теслинов А.Г. Разработване на системи за управление: методология и концептуални структури. М.: “Глобус”, 1998. 229 с.

3. Волкова V.N., Денисов A.A. Основи на теорията на системите и системния анализ

4. Стратегически маркетинг: Р. А. Фатхутдинов. – Санкт Петербург: Питър, 2003.

5. Философски енциклопедичен речник. М: Съветска енциклопедия. 1983

6. Фин В.К. Философски проблеми на логиката интелигентни системи. Вестник на Руската асоциация за изкуствен интелект. „Новини за изкуствения интелект“ № 1. Москва 1999 г., стр. 36.

7. Птушенко А. “Технология на младостта” № 3, 2003 г., стр. 24.

8. Залевская А.А. Въведение в психолингвистиката. руски.държавен.хуманитарни.университет. М., 2000, 382 с.

9. Александров Е.А. Основи на теорията на евристичните решения. М. Съветско радио, 1975, 254 с.

10. Бутенко Дм.В. Връзката между стратегическото планиране и концептуалния дизайн. // XXX годишнина международна конференцияи научен дискусионен клуб IT+SE`2003 Нов информационни технологиив науката, образованието, телекомуникациите и бизнеса. Украйна, Крим, Ялта-Гурзуф, 2003 г., с. 107

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

Тук има три функции:

1. Дефиниране на типове обекти на домейн

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

3. дефиниране на атрибути и свързването им с типове обекти и връзки.

4. създаване на локални концептуални модели на данни под формата на диаграми „субект-връзка”.

5. обсъждане на LCIMD с потребители.

Ориз. 3.1.3.1 Съответствие на фазите на проектиране и ANSI/SPARC архитектурните елементи.

сцена логичен дизайн.

Логическият дизайн е изграждането на информационни модели въз основа на съществуващи концептуални модули. Тези. на този етап концептуалният модел на данни се трансформира в локален логически моделданни и след това в глобалния логически модел на данни (GLDM), като се вземе предвид типът на използваната СУБД. Този етап съдържа 2 подетапа:

На първиподетап изпълнява:

1. местно преобразуване концептуален моделданни (LKMD) в локалния логически модел на данни (LLDM);

2. определяне на набор от релации (таблици) въз основа на структурата на LLMD;

3. проверка на LLMD с помощта на правила за нормализиране;

4. проверка на LLMD във връзка с потребителската транзакция;

5. създаване на окончателната диаграма субект-връзка за всеки LLMD;

6. определяне на изисквания към LLMD от гледна точка на осигуряване на целостта на данните;

7. Обсъждане на FSHD с крайни потребители.

На второподетап изпълнява:

1. вливане на ЛЛМД в ГЛМД;

2. проверка и настройка на GLMD;

3. създаване на окончателната версия на диаграмата „същност-връзка“, показваща GLMD;

4. Обсъждане на GLMD с крайни потребители.

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

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

2 конвертирайте LKMD в LLMD

3 комбинирайте LLMD в GLMD

Физически етап на проектиране

Този етап се състои от 3 подетапа:

1. внедряване на GLMD в средата на конкретна СУБД:

Проектиране на основните таблици в СУБД среда

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

2. създаване на проект за физическо представяне на базата данни:

Избор на конкретна структура за съхранение на данни

Определяне на изискванията за външна памет

3. разработване на инструменти за защита на бази данни:

Разработване и включване на съображения за защита на потребителските данни

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

На този етап е необходимо да се разгледат проблемите на наблюдението и конфигурирането на цялата система.

Избор на СУБД.

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

Общ списъкпараметри включва:

1. физически параметри:

дали в тази СУБД са предоставени файлови структури;

наличие на инструменти за индексиране;

наличие на инструменти за компресиране на данни;

възможност за криптиране на данни;

необходими количества RAM и ROM за дадена СУБД и др.

2. Параметри за дефиниране на данни:

вид на основния модел на организация на данните;

наличие на поддръжка за разширяване на първичен ключ;

наличие на инструменти за поддръжка на целостта на данните;

предоставени типове данни;

3. общи параметри:

цена на СУБД;

наличие на поддръжка за работа на СУБД в Интернет;

производителност на тази СУБД;

4. параметри, които определят достъпността по отношение на създаването на приложения:

възможности за език за заявки;

наличие на многопотребителски достъп;

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

5. група от параметри, описващи средствата за технология за разработване на ИС:

наличие на инструменти за работа с интерфейса на прозореца;

наличие на инструменти за случаи;

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

Разработка на приложения.

Целта на разработването на приложението е:

1. създаване на проект за транзакция

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

Дизайн на транзакция.

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

Обикновено транзакцията се извършва отчасти от персонала на AIS и отчасти от софтуерното приложение или самата СУБД.

Основни видове сделки:

1. сделки екстракция– действия, показващи избор на данни от базата данни

2. сделки актуализации– действия, които водят или до изтриване на определени данни, или до промяната им, или до добавяне на някои данни.

3. смесенсделки

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

1. изходни данни, използвани от сделката;

2. изходни данни, генерирани от транзакцията;

3. функционални характеристикисделки;

4. степен на важност на сделката за потребителя;

5. предполага се интензивността на използване на тази сделка.

7.2. Идеен дизайн по методология IDEF1X

Цел на идейния проект – създаване на концептуална диаграма на данни въз основа на идеи за предметната област на всеки отделен типпотребители. Концептуална диаграма е описание на основните обекти (таблици) и връзките между тях без да се отчита възприетият модел на базата данни и синтаксиса на целевата СУБД. Често такава диаграма показва само имената на обекти (таблици), без да посочва техните атрибути. Потребителски изглед включва данни, необходими на конкретен потребител, за да вземе решения или да изпълни някаква задача.

Последователността от стъпки в концептуалния дизайн е разгледана по-долу [,].

1. Идентификация на субектите.

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

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

Примери и аналогии при описание на обекти (например вместо обобщаващото понятие „служител“ могат да се посочат неговите функции или длъжност: „ръководител“, „отговорник“, „контрольор“, „заместник“);

Синоними (например „допустима скорост” и „зададена скорост”, „разработка” и „проект”, „бариерно място” и „ограничение на скоростта”);

Омоними (например „програма“ може да означава компютърна програма, план за предстояща работа или телевизионна програма).

Не винаги е очевидно какво е то специфичен обект– обект, връзка или атрибут. Например, как трябва да се класифицира „семеен брак“? На практика това понятие може съвсем основателно да се припише на всяка от споменатите категории. Анализът е субективен процес, така че различните разработчици могат да създадат различни, но напълно валидни интерпретации на един и същ факт. Изборът на опция зависи до голяма степен от здравия разум и опита на дизайнера.

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

Трябва да има уникално имеи едно и също тълкуване винаги трябва да се прилага за едно и също име;

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

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

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

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

а) независими б) зависим

Ориз. 7.1. Субекти

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

2. Дефиниране на атрибути.

Обикновено атрибутите се посочват само за обекти. Ако връзката има атрибути, това показва факта, че връзката е обект. Най-лесният начин да дефинирате атрибути е след като идентифицирате обект или връзка, да си зададете въпроса „Каква информация трябва да се съхранява за...?“ Различна хартия и електронни формии документи, използвани в организацията при решаване на проблем. Това могат да бъдат форми, съдържащи и двете обща информация(например „Списък на коти на външни релси в криви“) и резултатите от обработката на данни (например „Формуляр № 1“).

Идентифицираните атрибути могат да бъдат от следните типове:

Прост (атомичен, неделим) – състои се от един компонент с независимо съществуване (например „позиция на служител“, „заплата“, „изключителна скорост на ускорение“, „радиус на кривата“ и др.);

Композитен (псевдоатомен) – състои се от няколко компонента (например „пълно име“, „адрес“ и др.). Степента на атомарност на атрибутите, включени в модела, се определя от разработчика. Ако системата не е задължена да взема проби от всички клиенти с фамилното име Иванов или живеещите на улица Комсомолская, тогава съставните атрибути не трябва да се разделят на атомарни;

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

Многозначно – съдържа няколко значения (например един клон на компания може да има няколко номера за контакт);

Изведено (изчислено) – стойността на даден атрибут може да се определи от стойностите на други атрибути (например „възраст“ може да се определи от „дата на раждане“ и текуща датаинсталиран на компютъра);

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

Неключови (описателни);

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

След дефиниране на атрибутите те се задават домейни (области приемливи стойности) , Например:

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

Завъртане на кривата – приемливи стойности са “L” (ляво) и “R” (дясно);

Радиусът на кривата е положително число с не повече от 4 цифри.

Указването на домейни дефинира набора от валидни стойности за атрибут(и), както и типа, размера и формата на атрибута(ите).

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

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

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

- първичен ключ – кандидат ключ, който е избран за уникално идентифициране на екземпляри в рамките на обект;

- алтернативни ключове – потенциални ключове, които не са избрани като първичен ключ.

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

Фамилия;

Фамилия;

Дата на раждане;

Място на раждане;

Номер на групата;

Номер на пенсионноосигурително удостоверение (НПОС);

Паспорт;

Дата на издаване на паспорта;

Организацията, издала паспорта.

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

номер на удостоверение за пенсионно осигуряване;

Паспорт.

Като уникален идентификатор може да се избере комбинацията от атрибути „Фамилия“ + „Собствено име“ + „Бащино име“, ако вероятността двама пълни съименници да учат в университет е нула.

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

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

Броят на атрибутите, включени в ключа, трябва да бъде минимален (желателно е ключът да бъде атомен, т.е. да се състои от един атрибут);

Размерът на ключа в байтове трябва да бъде възможно най-кратък;

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

Вероятността за промяна на ключовите стойности беше най-малка (например „Номер на удостоверение за пенсионно осигуряване“ е повече от постоянен параметъротколкото „TIN“ или „номер на паспорт“);

Ключът е най-лесен за работа от потребителите (например „Номерът на пенсионноосигурителния сертификат“ е набор от 11 цифри, а „Номерът на паспорта“ зависи от неговия тип: гражданин на СССР, гражданин на Руската федерация или чужденец).

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

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

Ориз. 7.2. Примери за обекти

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

3. Дефиниране на връзките.

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

Отношения от типа „част-цяло“, обикновено дефинирани с глаголите „състои се от“, „включва“ и т.н.;

Класифициращи връзки (например "тип - подтип", "множество - елемент", "общо - конкретно" и др.);

Индустриални отношения (например „началник-подчинен“);

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

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

Комуникацията се характеризира със следния набор от параметри:

Име – посочва се в глаголна форма и определя семантиката (смисловия фон) на връзката;

Множество (кардиналност, мощност): едно към едно (1:1), едно към много (1:N) и много към много (N:M, N = M или N<>М). Множеството показва колко екземпляра на един обект се определят от екземпляр на друг. Например един участък (описан от ред в таблицата „Пътеки“) може да има един, два или повече пътеки (всеки път е описан от отделен ред в таблицата „Пътеки“). В този случай връзката е 1:N. Друг пример: една пътека минава през няколко отделни точки и няколко пътеки могат да минават през една отделна точка - връзка N:M;

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

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

Степен на участие – броят на субектите, участващи във връзката. По принцип има двоични връзки между обекти, т.е. асоциации, свързващи два субекта (степента на участие е 2). Например „Дюжет“ се състои от „Пътеки“. В същото време, в зависимост от степента на участие, са възможни следните видове връзки:

o унарен (рекурсивен) – даден обект може да бъде асоцииран сам със себе си. Например таблицата „Служители“ може да съдържа записи както за подчинени, така и за техните началници. Тогава е възможна връзка “началник” – “подчинен”, дефинирана на една маса;

o троичен – свързва три единици. Например, „Студент“ на „Сесия“ получи „Оценка по дисциплина“;

o кватернер и др.

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

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

Таблица 7.1. Видове връзки

Външен вид Вид и задължителност на комуникацията Комуникационна мощност отдясно
1
Задължителен, идентифициращ 0 .. ∞

З		 Задължителен, идентифициращ 0 или 1

П		 Задължителен, идентифициращ 1 .. ∞

<число> 		Задължителен, идентифициращ <число>
Задължителни, неидентифициращи 0 .. ∞
Незадължителен, неидентифициращ 0 .. ∞

Бележки.

1. Идентифициращата връзка е показана като плътна линия, а неидентифициращата връзка като пунктирана линия.

2. Незадължителността е обозначена с диамант.

Следващата фигура показва примери за това как се показват връзките.

а) идентифициране

б) неидентифициращи

в) рекурсивен

Фиг.7.3. Примери за връзки

На фиг. 7.3b връзката е незадължителна, тъй като някои служители не е задължително да принадлежат към който и да е отдел (например директор на предприятие), и неидентифицираща, тъй като персоналният номер е уникален за всеки служител.

4. Дефиниция на суперкласове и подкласове.

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

Супер класа – обект, който включва подкласове.

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


Ориз. 7.4. Йерархия на наследяване (непълна категория)

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

За всяка категория трябва да посочите дискриминатор – атрибут на генеричен предшественик, който показва как да се разграничи един обект от друг. В горния пример дискриминаторът е атрибутът „Тип“.


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

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

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

Следващата фигура показва фрагмент от концептуалната диаграма на информационния модел за задачата за определяне на допустимите скорости, изграден с помощта на ERwin v9.2.

Ориз. 7.6. Фрагмент от концептуалната диаграма на информационния модел

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

Нормативна и справочна информация;

Информация за пътни участъци;

Изчислителна задача;

Списъци с допустими скорости;

Проектна поръчка „N” (не е показана на фиг. 7.6);

Форми № 1, 1а и 2 (не са показани на фиг. 7.6).

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

Концепцията за концептуален дизайн се отнася до началния етап на проектиране на IS и приблизително съответства на етапи 1-3 от развитието на AS съгласно GOST 34 или етапи от определяне на изискванията до проектиране в модели на жизнения цикъл.

Определянето на изискванията към ИС се предхожда от определяне на целите, за които ще се разработва системата. Целите на ИС определят границите на предметната област, чиито обекти, техните свойства и връзки са значими от гледна точка на поставените цели и които ще бъдат представени в ИС (това е информация за предметната област - софтуерна информация) . Целите на IS също определят кои потребители и какви информационни нужди ще обслужва системата (това е информация за потребителските нужди - PP информация). Тези два компонента: софтуерна информация (която е обективно отражение на предметната област) и софтуерна информация (която отчасти отразява субективните възгледи на потребителите) са еднакво необходими и важни за изграждането на концептуален модел, както е показано на фиг. 14 7. Понякога вторият термин преобладава в концептуален модел, основан на отчитане на текущи и предвидими приложения, т.к това прави по-бързо и по-лесно създаването на система. Такива системи обаче се оказват неподходящи за обработка на неформализирани, променящи се и непредвидени задачи и заявки. Адекватното отразяване на софтуерната информация в системата й дава необходимата гъвкавост и адаптивност към променящите се условия.

ОТНОСНО Обща схема на идеен проект:

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

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

IS модели и техники за проектиране

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

Две области на дейност са пряко свързани с проектирането на ИС: 1) действителното проектиране на ИС за конкретни организации на базата на готови софтуерни и хардуерни компоненти с помощта на специални средства за разработка; 2) проектиране на споменатите компоненти и инструменти на ИС, ориентирани към многократно използване при разработването на множество специфични информационни системи. 8

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

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

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

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

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

По този начин функции (отговарящи на въпроса „Какво да правя?“) В комбинация с първоначални данни („Какво да предприемем?“), ограничения (време, финансови и материални ресурси, нормативни документи или бизнес правила и т.н.), означава изпълнението („Какво да направя?“) и резултатът („Какво е направено?“) описват проектираната ИС.

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

    принципът на „разделяй и владей“ - принципът за решаване на сложни проблеми чрез разбиването им на много по-малки независими задачи, които са лесни за разбиране и решаване;

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

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

    принципът на абстракцията - състои се в подчертаване на съществените аспекти на системата и абстрахиране от маловажните;

    принципът на формализиране - се състои в необходимостта от строг методологичен подход към решаването на проблема;

    принципът на последователност - лежи в валидността и последователността на елементите;

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

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

    DFD (Data Flow Diagrams) - диаграми на потока от данни или SADT (Structured Analysis and Design Technique) диаграми, илюстриращи функциите, които системата трябва да изпълнява;

    ERD (Entity-Relationship Diagrams) - диаграми на обекти и връзки, които моделират връзките между данните;

    STD (Диаграми за преход на състояние) - диаграми за преход на състояние, които моделират зависимо от времето поведение на система (аспекти в реално време).

В допълнение към тези модели, на етапа на структурно проектиране се използват техники на структурна карта за описание на връзките между модулите (структурни карти на Константин) и вътрешната структура на модулите (структурни карти на Джаксън).

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



© Copyright 2024, https://qzoreteam.ru